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
스크립트 라이브러리는 가장 일반적인 애플리케이션 서버
관리 기능을 자동화하는 프로시저 세트를 제공합니다. Jython 스크립트 라이브러리를
사용하는 방법에는 다음 세 가지가 있습니다.
- wsadmin 도구를 사용하여 대화식 모드에서 Jython 스크립트 라이브러리의
스크립트를 실행합니다. wsadmin 도구를 실행한 후 다음 구문을 사용하여
스크립트 라이브러리에 포함된 개별 스크립트를 실행할 수 있습니다.
wsadmin>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")
- 문서 편집기를 사용하여 다음 샘플에 표시된 것과 같이 Jython 스크립트
라이브러리의 여러 스크립트를 결합합니다.
#
# My Custom Jython Script - file.py
#
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")
사용자 정의
스크립트를 저장한 후 다음 구문 데모에 표시된 것과 같이 명령행에서 이
스크립트를 실행합니다. bin>wsadmin -language jython -f path/to/your/jython/file.py
- 샘플 구문과 같이 Jython 스크립트 라이브러리 코드를 사용하여 사용자
정의 스크립트를 작성합니다. 스크립트 라이브러리의 각 스크립트 예제는
wsadmin 스크립트를 작성하는 우수 사례를 보여 줍니다. 스크립트 라이브러리 코드는
app_server_root/scriptLibraries 디렉토리에 있습니다.
이 디렉토리에서 스크립트는 기능에 따라 서브디렉토리로
구성됩니다. 예를 들어, app_server_root/scriptLibraries/application/V70 서브디렉토리에는
버전 7.0 이상 제품에 적용 가능한 애플리케이션 관리 태스크를 수행하는 프로시저가 있습니다.스크립트
라이브러리 경로의 서브디렉토리 V70은 해당 서브디렉토리의
스크립트가 버전 7.0 스크립트임을 의미하지 않습니다.
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
- 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.
When the wsadmin tool launches, the system
loads all scripts from the scripting library.
- 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.
- 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.
- 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.