Automate messaging resource configurations using the scripting library

 

+

Search Tips   |   Advanced Search

 

The scripting library provides Jython script procedures to assist in automating the environment. Use the resource management scripts to configure and manage the JMS configurations.

There are three ways to use the Jython script library...

• Run scripts in interactive mode...

  wsadmin>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")

• Create a script...

  ###
  ### CreateServers.py
  ###
  
  ## Create two servers
  AdminServerManagement.createApplicationServer("myNode", "Server1", "default")
  AdminServerManagement.createApplicationServer("myNode", "Server2", "default")
  
  ### Use one of them as the first member of a cluster
  AdminClusterManagement.createClusterWithFirstMember("myCluster", "APPLICATION_SERVER", "myNode", "Server1")
  
  ### Add a second member to the cluster
  AdminClusterManagement.createClusterMember("myCluster", "myNode", "Server3")
  
  ### Install an application
  AdminApplication.installAppWithClusterOption("DefaultApplication", "..\installableApps\DefaultApplication.ear", "myCluster")
  
  ### Start all servers and applications on the node
  AdminServerManagement.startAllServers("myNode")

  Save the custom script and run it from the command line...

  bin>wsadmin -language jython -f /path/to/CreateServers.py

• Use the Jython scripting library code as sample syntax to write custom scripts. The script library code is located in...

  APP_ROOT/scriptLibraries

  Within this directory, the scripts are organized into subdirectories according to functionality, and further organized by version. For example...

  APP_ROOT/scriptLibraries/application/V70

  ...contains procedures that perform application management tasks that are applicable to V7.0 and later of WAS ND.

The messaging resource management procedures in the scripting library are located in...

WAS_HOME/scriptLibraries/resources/JMS/V70 sub

Each script from the directory automatically loads when you launch wsadmin. To automatically load the custom Jython scripts (*.py) when wsadmin starts, save the automation scripts to a new subdirectory in...

WAS_HOME/scriptLibraries

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

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.

1. Launch wsadmin.

   Use this step to launch wsadmin and connect to a server, or run the tool in local mode. If we launch wsadmin, use the interactive mode examples in this topic to run scripts.

   • Enter the following command from the bin directory to launch wsadmin and connect to a server:

     bin>wsadmin -lang jython

   • Enter the following command from the bin directory to launch wsadmin in local mode and using Jython:

     bin>wsadmin -conntype none -lang jython

   When wsadmin launches, the system loads all scripts from the scripting library.

2. Set a JMS provider.

   Run the createJMSProvider procedure from the script library and specify the required arguments. To run the script, specify...

   • node
   • server
   • JMS provider name
   • external initial context factory name
   • external provider URL

   We can optionally specify additional attributes in the following format...

   [["attr1", "value1"], ["attr2", "value2"]]

   The following table provides additional information about the arguments to specify:

   Argument	Description
   Node name	Name of the node of interest.
   Server name	Name of the server of interest.
   JMS provider name	Name to assign to the new JMS provider.
   External initial contextual factory name	Java class name of the initial context factory for the JMS provider.
   External provider URL	JMS provider URL for external JNDI lookups.

   The following example creates a JMS provider in the 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...

   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. Set 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. We can optionally specify additional attributes in the following format: [["attr1", "value1"], ["attr2", "value2"]].

   The following table provides additional information about the arguments to specify:

   Argument	Description
   Node name	Name of the node of interest.
   Server name	Name of the server of interest.
   JMS provider name	Name of the JMS provider.
   Connection factory name	Name to assign to the new connection factory
   JNDI name	JNDI name that the system uses to bind the connection factory into the name space.
   External JNDI name	JNDI name used to bind the queue into the appserver 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 the 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. We 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

   Argument	Description
   Node name	Name of the node of interest.
   Server name	Name of the server of interest.
   JMS provider name	Name of the JMS provider.
   Generic JMS destination name	Name to assign to the new generic JMS destination.
   JNDI name	JNDI name that the system uses to bind the connection factory into the name space.
   External JNDI name	JNDI name used to bind the queue into the appserver 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 the 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 script...

AdminServerManagement.listServers()

...returns a list of available servers.

The script...

AdminClusterManagement.checkIfClusterExists()

...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. To enable, specify true as the last argument for the script procedure...

wsadmin>AdminApplication.startApplicationOnCluster("myApplication","myCluster","true")

 

What to do next

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

WAS_HOME/scriptLibraries

JMS configuration scripts
JMS query scripts

 

Related tasks

Use the script library to automate the application serving environment