Die Scripting-Bibliothek enthält Jython-Scriptprozeduren, die Sie bei der Automatisierung Ihrer Umgebung unterstützen.
Verwenden Sie die Scripts für die Ressourcenverwaltung, um Ihre JMS-Konfigurationen (Java™ Messaging Service) zu konfigurieren und zu verwalten.
Informationen zu diesem Vorgang
Die Scripting-Bibliothek enthält eine Reihe von Prozeduren für die Automatisierung der meisten gebräuchlichen Verwaltungsfunktionen
des Anwendungsservers.
Die Jython-Scriptbibliothek kann auf verschiedene Arten verwendet werden.
- Sie können Scripts aus der Jython-Scriptbibliothek im Dialogmodus
über das Tool "wsadmin" ausführen. Sie können das Tool "wsadmin" starten und einzelne Scripts aus der
Scriptbibliothek mit der folgenden Syntax ausführen:
wsadmin>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")
- Verwenden Sie einen Texteditor, um mehrere Scripts aus der Jython-Scriptbibliothek zu kombinieren, wie im folgenden Beispiel gezeigt wird:
#
# My Custom Jython Script - file.py
#
AdminServerManagement.createApplicationServer("myNode", "Server1", "default")
AdminServerManagement.createApplicationServer("myNode", "Server2", "default")
# Ein Member als erstes Member eines Clusters verwenden
AdminClusterManagement.createClusterWithFirstMember("myCluster", "APPLICATION_SERVER", "myNode", "Server1")
# Dem Cluster ein zweites Member hinzufügen
AdminClusterManagement.createClusterMember("myCluster", "myNode", "Server3")
# Anwendung installieren
AdminApplication.installAppWithClusterOption("DefaultApplication",
"..\installableApps\DefaultApplication.ear", "myCluster")
# Alle Server und Anwendungen auf dem Knoten starten
AdminServerManagement.startAllServers("myNode")
Speichern Sie das angepasste Script, und führen Sie es über die Befehlszeile mit der folgenden Syntax aus:
bin>wsadmin -language jython -f Pfad/zu/Ihrer/Jython/Datei.py
- Verwenden Sie den Code aus der Jython-Scripting-Bibliothek als Verwendungsbeispiel, um eigene Scripts zu schreiben.
Jedes Scriptbeispiel in der Scriptbibliothek demonstriert bewährte Verfahren für das Schreiben von wsadmin-Scripts. Der Code der Scriptbibliothek
befindet sich im Verzeichnis Stammverzeichnis_des_Anwendungsservers/scriptLibraries.
In diesem Verzeichnis sind die Scripts in Unterverzeichnissen nach Funktionalität organisiert.
Das Unterverzeichnis Stammverzeichnis_des_Anwendungsservers/scriptLibraries/application/V70 enthält beispielsweise
Prozeduren, die Tasks für die Anwendungsverwaltung in Version 7.0 und höher des Produkts ausgeführt werden. Das Unterverzeichnis
V70 in den Scriptbibliothekspfaden bedeutet nicht, dass die darin enthaltenen Scripts Scripts der Version
7.0 sind.
Die Prozeduren für die Verwaltung von Messaging-Ressourcen befinden sich im Unterverzeichnis
Stammverzeichnis_des_Anwendungsservers/scriptLibraries/resources/JMS/V70.
Alle Scripts im Verzeichnis werden automatisch geladen, wenn Sie das Tool "wsadmin" starten.
Wenn die angepassten Jython-Scripts
(
*.py) beim Starten des Tools "wsadmin" geladen werden sollen, speichern Sie Ihre
Automationsscripts in einem neuen Unterverzeichnis im Verzeichnis
Stammverzeichnis_des_Servers/scriptLibraries.
Bewährtes Verfahren: Wenn Sie über die Prozeduren in der Scripting-Bibliothek angepasste Scripts erstellen möchten,
speichern Sie die geänderten Scripts in einem neuen Unterverzeichnis, um zu vermeiden, dass die Prozeduren in der Bibliothek überschrieben werden.
Bearbeiten Sie keine Scriptprozeduren in der Scripting-Bibliothek.
bprac
Sie können die Scripts verwenden, um verschiedene Kombinationen von Verwaltungsfunktionen auszuführen.
Verwenden Sie die folgende Beispielkonfiguration von Prozeduren, um einen JMS-Provider zu erstellen und
JMS-Ressourcen für den JMS-Provider zu konfigurieren.
Vorgehensweise
- Optional: Starten Sie das Tool "wsadmin".
Verwenden Sie diesen Schritt, um das Tool "wsadmin" zu starten und eine Verbindung zu
einem Server herzustellen oder um das Tool im lokalen Modus auszuführen.
Wenn Sie das Tool "wsadmin" starten, verwenden Sie für die Ausführung der Scripts
die Dialogmodusbeispiele in diesem Artikel.
Beim Starten des Tools "wsadmin" lädt das System alle Scripts aus der Scripting-Bibliothek.
- Konfigurieren Sie einen JMS-Provider.
Führen Sie die Prozedur "createJMSProvider" aus der
Scriptbibliothek aus und geben Sie die erforderlichen Argumente an.
Zum Ausführen des Scripts geben Sie den Knoten, den Server, den Namen des JMS-Providers, den Namen der externen
Ausgangskontextfactory und den externen Provider-URL an.
Optional können Sie weitere Attribute im folgenden Format angeben:
[["Attr1", "Wert1"], ["Attr2", "Wert2"]]. Die folgende Tabelle enthält zusätzliche Informationen zu den festzulegenden Argumenten:
Tabelle 1. Argumente für das Script "createJMSProvider". Führen Sie das Script aus, um einen JMS-Provider zu erstellen.Argument |
Beschreibung |
Knotenname |
Gibt den Namen des gewünschten Knotens an. |
Servername |
Gibt den Namen des gewünschten Servers an. |
Name des JMS-Providers |
Gibt den Namen an, der dem neuen JMS-Provider zugeordnet werden soll. |
Name der externen Ausgangskontextfactory |
Gibt den Namen der Java-Klasse für die Ausgangskontextfactory des JMS-Providers an. |
Externer Provider-URL |
Gibt den URL des JMS-Provider für externe JNDI-Lookup-Operationen an. |
Im folgenden Beispiel wird ein JMS-Provider in Ihrer Konfiguration erstellt:
bin>wsadmin -lang jython -c "AdminJMS.createJMSProvider("myNode", "myServer", "myJMSProvider", "extInitCF",
"extPURL", [["description", "testing"], ["supportsASF", "true"], ["providerType", "jmsProvType"]])"
Sie können
die Scriptprozedur, wie im folgenden Beispiel gezeigt, auch im Dialogmodus ausführen:
wsadmin>AdminJMS.createJMSProvider("myNode", "myServer", "myJMSProvider", "extInitCF",
"extPURL", [["description", "testing"], ["supportsASF", "true"], ["providerType", "jmsProvType"]])
Das Script gibt die Konfigurations-ID
des neuen JMS-Providers zurück.
- Konfigurieren Sie eine generische JMS-Verbindungsfactory.
Führen Sie die Prozedur "createGenericJMSConnectionFactory" aus der
Scriptbibliothek aus und geben Sie die erforderlichen Argumente an.
Zum Ausführen des Scripts geben Sie den Knoten, den Server, den Namen des JMS-Providers, den Namen der neuen
Verbindungsfactory, den JNDI-Namen und den externen JNDI-Namen an.
Optional können Sie weitere Attribute im folgenden Format angeben:
[["Attr1", "Wert1"], ["Attr2", "Wert2"]]. Die folgende Tabelle enthält zusätzliche Informationen zu den festzulegenden Argumenten:
Tabelle 2. Argumente für das Script "createGenericJMSConnectionFactory". Führen Sie das Script aus, um eine generische JMS-Verbindungsfactory zu erstellen.Argument |
Beschreibung |
Knotenname |
Gibt den Namen des gewünschten Knotens an. |
Servername |
Gibt den Namen des gewünschten Servers an. |
Name des JMS-Providers |
Gibt den Namen des JMS-Providers an. |
Name der Verbindungsfactory |
Gibt den Namen an, der der neuen Verbindungsfactory zugeordnet werden soll. |
JNDI-Name |
Gibt den JNDI-Namen an, den das System verwendet, um die Verbindungsfactory
an den Namespace zu binden. |
Externer JNDI-Name |
Gibt den JNDI-Namen an, der verwendet wird, um die Warteschlange an den Namespace des Anwendungsservers zu binden.
Verwenden Sie als Konvention den vollständig qualifizierten JNDI-Namen, z. B.
im Format jms/Name. Dabei bezeichnet Name
den logischen Namen der Ressource. Dieser Name wird verwendet, um
die Bindungsinformationen für die Plattform zu verlinken. Die Bindung ordnet die im Implementierungsdeskriptor des Moduls definierten
Ressourcen den "echten" (physischen) Ressourcen zu, die über die Plattform
an JNDI gebunden sind. |
Im folgenden Beispiel wird eine JMS-Verbindungsfactory in Ihrer Konfiguration erstellt:
bin>wsadmin -lang jython -c "AdminJMS.createGenericJMSConnectionFactory("myNode", "myServer", "myJMSProvider",
"JMSCFTest", "jmsjndi", "extjmsjndi", [["XAEnabled", "true"], ["authDataAlias", "myalias"],
["description", "testing"]])"
Sie können
die Scriptprozedur, wie im folgenden Beispiel gezeigt, auch im Dialogmodus ausführen:
wsadmin>AdminJMS.createGenericJMSConnectionFactory("myNode", "myServer", "myJMSProvider",
"JMSCFTest", "jmsjndi", "extjmsjndi", [["XAEnabled", "true"], ["authDataAlias", "myalias"],
["description", "testing"]])
Das Script gibt die Konfigurations-ID der neuen
JMS-Verbindungsfactory zurück.
- Erstellen Sie ein generisches JMS-Ziel.
Führen Sie die Prozedur "createGenericJMSDestination" aus der
Scriptbibliothek aus und geben Sie die erforderlichen Argumente an.
Zum Ausführen des Scripts geben Sie den Knoten, den Server, den Namen des JMS-Providers, den Namen des generischen
JMS-Ziels, den JNDI-Namen und den externen JNDI-Namen an.
Optional können Sie weitere Attribute im folgenden Format angeben:
[["Attr1", "Wert1"], ["Attr2", "Wert2"]]. Die folgende Tabelle enthält zusätzliche Informationen zu den festzulegenden Argumenten:
Tabelle 3. Argumente für das Script "createGenericJMSDestination". Führen Sie das Script aus, um ein generisches JMS-Ziel zu erstellen.Argument |
Beschreibung |
Knotenname |
Gibt den Namen des gewünschten Knotens an. |
Servername |
Gibt den Namen des gewünschten Servers an. |
Name des JMS-Providers |
Gibt den Namen des JMS-Providers an. |
Name des generischen JMS-Ziels |
Gibt den Namen an, der des neuen generischen JMS-Ziels zugeordnet werden soll. |
JNDI-Name |
Gibt den JNDI-Namen an, den das System verwendet, um die Verbindungsfactory
an den Namespace zu binden. |
Externer JNDI-Name |
Gibt den JNDI-Namen an, der verwendet wird, um die Warteschlange an den Namespace des Anwendungsservers zu binden.
Verwenden Sie als Konvention den vollständig qualifizierten JNDI-Namen, z. B.
im Format jms/Name. Dabei bezeichnet Name
den logischen Namen der Ressource. Dieser Name wird verwendet, um
die Bindungsinformationen für die Plattform zu verlinken. Die Bindung ordnet die im Implementierungsdeskriptor des Moduls definierten
Ressourcen den "echten" (physischen) Ressourcen zu, die über die Plattform
an JNDI gebunden sind. |
Im folgenden Beispiel wird eine Schablone verwendet, um ein generisches JMS-Ziel in Ihrer Konfiguration zu erstellen:
bin>wsadmin -lang jython -c "AdminJMS.createGenericJMSDestination("myNode", "myServer", "myJMSProvider",
"JMSDest", "destjndi", "extDestJndi", [["description", "testing"], ["category", "jmsDestCatagory"],
["type", "TOPIC"]]))"
Sie können
die Scriptprozedur, wie im folgenden Beispiel gezeigt, auch im Dialogmodus ausführen:
wsadmin>AdminJMS.createGenericJMSDestination("myNode", "myServer", "myJMSProvider",
"JMSDest", "destjndi", "extDestJndi", [["description", "testing"], ["category", "jmsDestCatagory"],
["type", "TOPIC"]]))
Das Script gibt die Konfigurations-ID des neuen
generischen JMS-Ziels zurück.
Ergebnisse
Die wsadmin-Scriptbibliotheken geben dieselbe Ausgabe wie die entsprechenden
wsadmin-Befehle zurück. Das Script "AdminServerManagement.listServers()"
gibt beispielsweise eine Liste mit verfügbaren Servern zurück.
Das Script "AdminClusterManagement.checkIfClusterExists()" gibt den Wert
true zurück, wenn der Cluster vorhanden ist, bzw. den Wert false, wenn der Cluster nicht vorhanden ist.
Wenn der Befehl nicht die erwartete Ausgabe zurückgibt, geben die Scriptbibliotheken
den Wert 1 bei erfolgreicher Ausführung des Scripts zurück. Scheitert das Script, geben die
Scriptbibliotheken den Wert -1 und eine Fehlernachricht mit der Ausnahme zurück.
Standardmäßig wird die Option "failonerror" vom System inaktiviert.
Zum Aktivieren dieser Option geben Sie
true als letztes Argument für die Scriptprozedur an, wie im folgenden
Beispiel gezeigt wird:
wsadmin>AdminApplication.startApplicationOnCluster("myApplication","myCluster","true")
Nächste Schritte
Erstellen Sie angepasste Scripts für die Automatisierung Ihrer Umgebung, indem Sie Scriptprozeduren aus der Scripting-Bibliothek miteinander kombinieren.
Speichern Sie die angepassten Scripts in einem neuen Unterverzeichnis des Verzeichnisses
Stammverzeichnis_des_Anwendungsservers/scriptLibraries.