Automating messaging resource configurations using wsadmin scripting

The scripting library provides Jython script procedures to assist in automating your environment. Use the resource management scripts to configure and manage your Java™ Messaging Service (JMS) configurations.

About this task

Scripting 程式庫提供一組自動執行最常見應用程式伺服器管理功能的程序。 Jython Script 程式庫有三種使用方式。
  • 利用 wsadmin 工具,以互動模式執行 Jython Script 程式庫中的 Script。 您可以啟動 wsadmin 工具,然後利用下列語法來執行併入 Script 程式庫的個別 Script:
    wsadmin>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")
  • 利用文字編輯器,依照下列範例所示,將 Jython Script 程式庫中的若干 Script 結合起來:
    #
    # My Custom Jython Script - file.py
    #
    AdminServerManagement.createApplicationServer("myNode", "Server1", "default")
    AdminServerManagement.createApplicationServer("myNode", "Server2", "default")
    
    # 使用其中一個作為叢集的第一個成員
    AdminClusterManagement.createClusterWithFirstMember("myCluster", "APPLICATION_SERVER",
        "myNode", "Server1")
    
    # 新增第二個成員到叢集中
    AdminClusterManagement.createClusterMember("myCluster", "myNode", "Server3")
    
    # 安裝應用程式
    AdminApplication.installAppWithClusterOption("DefaultApplication",
        "..\installableApps\DefaultApplication.ear", "myCluster") 
    
    # 啟動節點上的所有伺服器和應用程式
    AdminServerManagement.startAllServers("myNode")
    請將自訂 Script 儲存起來,然後依照下列語法所示,從指令行執行它:
    bin>wsadmin -language jython -f path/to/your/jython/file.py
  • 利用 Jython Scripting 程式庫程式碼作為撰寫自訂 Script 的語法範例。 Script 程式庫中的各個 Script 範例示範撰寫 wsadmin Script 的最佳實務。 Script 程式庫程式碼位於app_server_root/scriptLibraries 目錄中。 在這個目錄內,Script 是先依照功能組織成子目錄。 例如,app_server_root/scriptLibraries/application/V70 子目錄所包含的程序會執行適用於產品 7.0 版及更新版本的應用程式管理作業。Script 程式庫路徑中的 V70 子目錄不表示 在該子目錄中的 Script 為 7.0 版 Script。
The messaging resource management procedures in the scripting library are located in the app_server_root/scriptLibraries/resources/JMS/V70 subdirectory. Each script from the directory automatically loads when you launch the wsadmin tool. To automatically load your custom Jython scripts (*.py) when the wsadmin tool starts, save your automation scripts to a new subdirectory in the app_server_root/scriptLibraries directory.
最佳作法 最佳作法: To create custom scripts using the scripting library procedures, save the modified scripts to a new subdirectory to avoid overwriting the library. Do not edit the script procedures in the scripting library.bprac

You can use the scripts to perform multiple combinations of administration functions. Use the following sample combination of procedures to create a JMS provider and configure JMS resources for the JMS provider.

Procedure

  1. Optional: Launch the wsadmin tool.
    Use this step to launch the wsadmin tool and connect to a server, or run the tool in local mode. If you launch the wsadmin tool, use the interactive mode examples in this topic to run scripts.
    • Enter the following command from the bin directory to launch the wsadmin tool and connect to a server:
      bin>wsadmin -lang jython
    • Enter the following command from the bin directory to launch the wsadmin tool in local mode and using the Jython scripting language:
      bin>wsadmin -conntype none -lang jython
    When the wsadmin tool launches, the system loads all scripts from the scripting library.
  2. Configure a JMS provider.
    Run the createJMSProvider procedure from the script library and specify the required arguments. To run the script, specify the node, server, JMS provider name, external initial contextual factory name, and external provider URL. You can optionally specify additional attributes in the following format: [["attr1", "value1"], ["attr2", "value2"]]. The following table provides additional information about the arguments to specify:
    Table 1. createJMSProvider script arguments. Run the script to create a JMS provider.
    Argument Description
    Node name Specifies the name of the node of interest.
    Server name Specifies the name of the server of interest.
    JMS provider name Specifies the name to assign to the new JMS provider.
    External initial contextual factory name Specifies the Java class name of the initial context factory for the JMS provider.
    External provider URL Specifies the JMS provider URL for external JNDI lookups.
    The following example creates a JMS provider in your configuration:
    bin>wsadmin -lang jython -c "AdminJMS.createJMSProvider("myNode", "myServer", "myJMSProvider", "extInitCF",
     "extPURL", [["description", "testing"], ["supportsASF", "true"], ["providerType", "jmsProvType"]])"
    You can also use interactive mode to run the script procedure, as the following example displays:
    wsadmin>AdminJMS.createJMSProvider("myNode", "myServer", "myJMSProvider", "extInitCF",
     "extPURL", [["description", "testing"], ["supportsASF", "true"], ["providerType", "jmsProvType"]])
    The script returns the configuration ID of the new JMS provider.
  3. Configure a generic JMS connection factory.
    Run the createGenericJMSConnectionFactory procedure from the script library and specify the required arguments. To run the script, specify the node, server, JMS provider name, name of the new connection factory, JNDI name, and external JNDI name. You can optionally specify additional attributes in the following format: [["attr1", "value1"], ["attr2", "value2"]]. The following table provides additional information about the arguments to specify:
    Table 2. createGenericJMSConnectionFactory script arguments. Run the script to create a generic JMS connection factory.
    Argument Description
    Node name Specifies the name of the node of interest.
    Server name Specifies the name of the server of interest.
    JMS provider name Specifies the name of the JMS provider.
    Connection factory name Specifies the name to assign to the new connection factory
    JNDI name Specifies the JNDI name that the system uses to bind the connection factory into the name space.
    External JNDI name Specifies the JNDI name that is used to bind the queue into the application server name space. As a convention, use the fully qualified JNDI name; for example, in the form jms/Name, where Name is the logical name of the resource. This name is used to link the platform binding information. The binding associates the resources defined by the deployment descriptor of the module to the actual (physical) resources bound into JNDI by the platform.
    The following example creates a JMS connection factory in your configuration:
    bin>wsadmin -lang jython -c "AdminJMS.createGenericJMSConnectionFactory("myNode", "myServer", "myJMSProvider",
     "JMSCFTest", "jmsjndi", "extjmsjndi", [["XAEnabled", "true"], ["authDataAlias", "myalias"],
     ["description", "testing"]])"
    You can also use interactive mode to run the script procedure, as the following example displays:
    wsadmin>AdminJMS.createGenericJMSConnectionFactory("myNode", "myServer", "myJMSProvider", 
      "JMSCFTest", "jmsjndi", "extjmsjndi", [["XAEnabled", "true"], ["authDataAlias", "myalias"],
     ["description", "testing"]])
    The script returns the configuration ID of the new generic JMS connection factory.
  4. Create a generic JMS destination.
    Run the createGenericJMSDestination procedure from the script library and specify the required arguments. To run the script, specify the node, server, JMS provider name, generic JMS destination name, JNDI name, and external JNDI name. You can optionally specify additional attributes in the following format: [["attr1", "value1"], ["attr2", "value2"]]. The following table provides additional information about the arguments to specify:
    Table 3. createGenericJMSDestination script arguments. Run the script to create a generic JMS destination.
    Argument Description
    Node name Specifies the name of the node of interest.
    Server name Specifies the name of the server of interest.
    JMS provider name Specifies the name of the JMS provider.
    Generic JMS destination name Specifies the name to assign to the new generic JMS destination.
    JNDI name Specifies the JNDI name that the system uses to bind the connection factory into the name space.
    External JNDI name Specifies the JNDI name that is used to bind the queue into the application server name space. As a convention, use the fully qualified JNDI name; for example, in the form jms/Name, where Name is the logical name of the resource. This name is used to link the platform binding information. The binding associates the resources defined by the deployment descriptor of the module to the actual (physical) resources bound into JNDI by the platform.
    The following example uses a template to use a template to create a generic JMS destination in your configuration:
    bin>wsadmin -lang jython -c "AdminJMS.createGenericJMSDestination("myNode", "myServer", "myJMSProvider",
     "JMSDest", "destjndi", "extDestJndi", [["description", "testing"], ["category", "jmsDestCatagory"],
       ["type", "TOPIC"]]))"
    You can also use interactive mode to run the script procedure, as the following example displays:
    wsadmin>AdminJMS.createGenericJMSDestination("myNode", "myServer", "myJMSProvider",
     "JMSDest", "destjndi", "extDestJndi", [["description", "testing"], ["category", "jmsDestCatagory"],
       ["type", "TOPIC"]]))
    The script returns the configuration ID of the new generic JMS destination.

Results

The wsadmin script libraries return the same output as the associated wsadmin commands. For example, the AdminServerManagement.listServers() script returns a list of available servers. The AdminClusterManagement.checkIfClusterExists() script returns a value of true if the cluster exists, or false if the cluster does not exist. If the command does not return the expected output, the script libraries return a 1 value when the script successfully runs. If the script fails, the script libraries return a -1 value and an error message with the exception.

By default, the system disables failonerror option. To enable this option, specify true as the last argument for the script procedure, as the following example displays:
wsadmin>AdminApplication.startApplicationOnCluster("myApplication","myCluster","true")

What to do next

Create custom scripts to automate your environment by combining script procedures from the scripting library. Save custom scripts to a new subdirectory of the app_server_root/scriptLibraries directory.


指出主題類型的圖示 作業主題



時間戳記圖示 前次更新: July 9, 2016 11:18
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_7libresource2
檔名:txml_7libresource2.html