von Roman Seibold
Anlässlich einer jüngst gehaltenen Schulung zum Thema "WebSphere Application Server V7 Upgrade for Administrators" (im IBM-Jargon WU702) möchte ich die Gelegenheit nutzen und den interessierten Leser auf ein neues Feature des WebSphere Application Servers V7 (WAS V7) und gleichzeitig auf einen Fehler im zugehörigen Redbook ("WebSphere Application Server V7 - Administration and Configuration Guide" [http://www.redbooks.ibm.com/abstracts/sg247615.html])
aufmerksam machen.

Aber fangen wir langsam an.

Der WAS V7 bietet ein neues administratives Feature, um Information von einem Server zu erhalten und Werte in einem Server zu verändern. Neben den üblichen - komplexen - Schnittstellen wie wsadmin, ant und JMX oder der für das geplante Einsatzgebiet in diesem Fall zu umständlichen Variante, der Web-Administrationskonsole.

Die Idee ist, auf einfache Weise Konfigurationsdaten in einem simplen Format vom Server zu erhalten, diese zu modifizieren, und dem Server auf ebenso einfache Weise wieder zurückzuspielen. Man hat sich hier auf das jedem Java-Entwickler geläufige Format der Property-Dateien geeinigt. Eine Property-Datei hat allgemein den Aufbau

schlüssel1=wert1
schlüssel2=wert2 
# ...

Im WebSphere-Kontext wird es allerdings etwas komplizierter, da hier im Gegensatz zum normalen Property-Format, in dem alle Schlüssel parallel und gleichberechtigt nebeneinanderstehen, auch noch die Reihenfolge bzw. Abfolge der Daten wichtig ist. Daher ergibt sich das oben skizzierte Vorgehen eigentlich von selbst, dass man sich die Datei zunächst vom Server generieren lassen sollte und diese danach mit geänderten Werten wieder zurückspielt. Ganz auf eigene Faust und sozusagen auf der "grünen Wiese" will man eine solche Datei dann auch nicht erstellen.

Leider gibt es in WAS V7 kein Admin-Skript analog startServer und Co., um mit Property-Dateien umzugehen, sondern dies ist eine Funktionalität, die in wsadmin eingebettet wurde. Eine entsprechende Property-Datei erhält man vom Server mit dem wsadmin-Befehl (hier in Jython):

AdminTask.extractConfigProperties(
  '-propertiesFileName data.props')

Das zugehörige File landet bei nicht konkreterer Pfadangabe im aktuellen Verzeichnis, ist relativ groß und enthält die wichtigsten, aber bei weiten nicht alle, Einstellungen des Servers. U.a. findet sich in der Regel so ca. "kurz vor der Hälfte" folgender Abschnitt:

#
# SubSection 1.0.32 # Ports Section
#
ResourceType=EndPoint
ImplementingResourceType=Server
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}
#

#
#Properties
#
SOAP_CONNECTOR_ADDRESS=8880:!{hostName} # integer
SIP_DEFAULTHOST_SECURE=5061:!{hostName1} # integer
SIP_DEFAULTHOST=5060:!{hostName1} # integer
SIB_ENDPOINT_ADDRESS=7276:!{hostName1} # integer
WC_defaulthost_secure=9443:!{hostName1} # integer
DCS_UNICAST_ADDRESS=9353:!{hostName1} # integer
SIB_MQ_ENDPOINT_SECURE_ADDRESS=5578:!{hostName1} # integer
WC_adminhost_secure=9043:!{hostName1} # integer
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=9402:!{hostName} # ...
ORB_LISTENER_ADDRESS=9100:!{hostName} # integer
BOOTSTRAP_ADDRESS=2809:!{hostName} # integer
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=9403:!{hostName} # ...
IPC_CONNECTOR_ADDRESS=9633:!{hostName2} # integer
SIB_ENDPOINT_SECURE_ADDRESS=7286:!{hostName1} # integer
WC_defaulthost=9080:!{hostName1} # integer
SIB_MQ_ENDPOINT_ADDRESS=5558:!{hostName1} # integer
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=9401:!{hostName} # ...
WC_adminhost=9060:!{hostName1} # integer

Hier kann man beispielsweise die Porteinstellungen von Admin- und Default-Host nun bequem ändern und das File danach wieder abspeichern.
Natürlich lassen sich die abgefragten Informationen auch einschränken und filtern, um die Dateigröße und die Vielzahl von Informationen zu begrenzen. Aber dazu vielleicht zukünftig mehr.

Mit

AdminTask.validateConfigProperties(
  '-propertiesFileName data.props')

kann man die Datei auf Gültigkeit validieren lassen. Ein sinnvoller und notwendiger Schritt, wenn man viele Veränderungen vorgenommen hat.

Schließlich lässt sich die Property-Datei mit den geänderten Werten leicht wieder vom Server einlesen:

AdminTask.applyConfigProperties(
  '-propertiesFileName data.props')

Danach muss man noch speichern, sonst ist alle Mühe vergebens:

AdminConfig.save()

Beim Validieren eines Konfigurationsfiles ist uns nun aber in einem konkreten Fall ein Fehler aufgetreten. Der Validator erzeugte eine Exception, die allerdings zu unserem Leidwesen nicht wirklich konkretere Mehrinformation beinhaltete. Das Redbook und auch die Schulungsunterlagen sehen für diesen Fall den zusätzlichen Parameter -reportFile filename.txt vor, damit sich der Validator etwas aussagekräftiger verhält.
Beim Einsetzen dieses Parameters in den Befehl, also so:

AdminTask.validateConfigProperties(
  '-propertiesFileName data.props 
   -reportFile error.txt')

erhielten wir die unangenehme Nachricht

exception information: 
com.ibm.ws.scripting.ScriptingException:
com.ibm.websphere.management.cmdframework.
  CommandNotFoundException:
ADMF0006E: 
Step reportFile of command validateConfigProperties 
is not found.

Da uns das Infocenter zum damaligen Zeitpunkt aus verbindungstechnischen Gründen nicht zur Verfügung stand, habe ich mich einer Technik bedient, die "inspiriertes Raten" genannt wird und analog zu den übrigen immer sehr ausführlich benannten Kommandos den Befehl -reportFileName versucht, obwohl eben explizit im Redbook und den Schulungsunterlagen gegenteiliges stand. Und, oh Wunder, es funktionierte.

Wer also die Validierung seiner Konfigurationsdatei mitprotokolliert haben möchte, der bediene sich folgender Variante:

AdminTask.validateConfigProperties(
  '-propertiesFileName data.props 
   -reportFileName error.txt')

Netterweise wäre die richtige Antwort auch über die Hilfe in wsadmin verfügbar gewesen, aber wie immer, wenn man schon zwei Quellen genutzt hat, wird nicht noch unbedingt die dritte des selben Herstellers ebenfalls abgefragt. Und welcher Informatiker liest denn schon Anleitungen...? Die notwendige und diesmal richtige Information hätte man also auch ohne
inspiriertes Raten wie folgt herausfinden können:

print AdminTask.help('validateConfigProperties')

Also, kurzes Fazit: WAS7-Konfigurationen in Form von Property-Dateien sind sehr interessant, auf, sagen wir mal, akzeptable und relativ einfache Weise zu besorgen und wieder aufzuspielen und vor allem sehr einfach zu editieren. Eine daraus sich ableitende weitergehende Anwendung ist das Cloning von Serverumgebungen, wo man mit Hilfe von Konfigurations-Archiven (.car-Files) die komplette Umgebung übernehmen und danach mit Property-Dateien noch einzelne Einstellungen nachträglich verändern kann. Wenn man auch noch die richtigen Parameterbenennungen weiß, dann wird es ein Kinderspiel.

In diesem Sinne viel Erfolg mit WebSphere, Ihr

Roman Seibold