The scripting library provides Jython script procedures
to assist in automating your environment. Use the resource management
scripts to configure and manage your Java™ Database
Connectivity (JDBC) configurations.
About this task
The scripting library provides a set of procedures
to automate the most common application server administration functions.
There are three ways to use the Jython script library.
- Run scripts from the Jython script library in interactive mode
with the wsadmin tool. You can launch the wsadmin tool, and run individual
scripts that are included in the script library using the following
syntax:
wsadmin>AdminServerManagement.createApplicationServer("myNode", "myServer", "default")
- Use a text editor to combine several scripts from the Jython script library, as the following
sample
displays:
#
# 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")
Save
the custom script and run it from the command line, as the following syntax
demonstrates:bin>wsadmin -language jython -f path/to/your/jython/file.py
- Use the Jython scripting library code as sample syntax to write
custom scripts. Each script example in the script library demonstrates
best practices for writing wsadmin scripts. The script library code
is located in the app_server_root/scriptLibraries directory.
Within this directory, the scripts are organized into subdirectories
according to functionality. For example, the app_server_root/scriptLibraries/application/V70 subdirectory
contains procedures that perform application management tasks that
are applicable to Version 7.0 and later of the product. The subdirectory
V70 in the script library paths does not mean the scripts in that
subdirectory are Version 7.0 scripts.
The
data access resource management procedures in the scripting library
are located in the
app_server_root/scriptLibraries/resources/JDBC/V70 subdirectory.
Each script from the directory automatically loads when you launch
the wsadmin tool. To automatically load your own Jython scripts (
*.py)
when the wsadmin tool starts, set the wsadmin.script.libraries system
property to the script location.
Best practice: 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.
You can use the scripts to perform many combinations
of administration functions. Use the following sample combination
of procedures to configure a JDBC provider and data source.
Procedure
- Verify that all of the necessary JDBC driver files are
installed on your node manager. If you opt to configure a user-defined
JDBC provider, check your database documentation for information about
the driver files.
- 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 JDBC provider.
Run the createJDBCProvider
procedure from the script library and specify the required arguments.
To run the script, specify the node name, server name, name to assign
to the new JDBC provider, and the implementation class name. You can
optionally specify additional attributes in the following format: [["attr1",
"value1"], ["attr2", "value2"]]
. Custom properties for specific
vendor JDBC drivers must be set on the application server data source.
Consult your database documentation for information about available
custom properties.
The following example creates a JDBC provider
in your configuration:
bin>wsadmin -lang jython -c "AdminJDBC.createJDBCProvider("myNode", "myServer", "myJDBCProvider",
"myImplementationClass", [["description", "testing"], ["xa", "false"], ["providerType", "provType"]])"
You
can also use interactive mode to run the script procedure, as the
following example displays:
wsadmin>AdminJDBC.createJDBCProvider("myNode", "myServer", "myJDBCProvider", "myImplementationClass",
[["description", "testing"], ["xa", "false"], ["providerType", "provType"]])
The script returns the configuration ID of the new JDBC
provider.
- Use a template to configure a data source.
Run
the createDataSourceUsingTemplate procedure from the script library
and specify the required arguments. To run the script, specify the
node name, server name, JDBC provider name, configuration ID of the
template to use, and the name to assign to the new data source. You
can optionally specify additional attributes in the following format: [["attr1",
"value1"], ["attr2", "value2"]]
.
The following example
uses a template to create a data source in your configuration:
bin>wsadmin -lang jython -c "AdminJDBC.createDataSourceUsingTemplate("myNode", "myServer", "myJDBCProvider",
"Derby JDBC Driver DataSource(templates/system|jdbc-resource-provider-templates.xml#DataSource_derby_1)",
"myDataSource", [["authDataAlias", "myalias"], ["authMechanismPreference", "BASIC_PASSWORD"],
["description", "testing"], ["jndiName", "dsjndi1"], ["logMissingTransactionContext", "true"],
["statementCacheSize", "5"]])"
You can also use
interactive mode to run the script procedure, as the following example
displays:
wsadmin>AdminJDBC.createDataSourceUsingTemplate("myNode", "myServer", "myJDBCProvider", "Derby JDBC Driver
DataSource(templates/system|jdbc-resource-provider-templates.xml#DataSource_derby_1)", "myDataSource",
[["authDataAlias", "myalias"], ["authMechanismPreference", "BASIC_PASSWORD"], ["description", "testing"],
["jndiName", "dsjndi1"], ["logMissingTransactionContext", "true"], ["statementCacheSize", "5"]])
The script returns the configuration ID of the new data
source.
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.