AdminTask Object in wsadmin scripting

Use the AdminTask object to access a set of administrative commands that provide an alternative way to access the configuration commands and the running object management commands.

The administrative commands run simple and complex commands. They provide more user friendly and task-oriented commands. The administrative commands are discovered dynamically when you start a scripting client. The set of available administrative commands depends on the edition of WebSphere^® Application Server that you installed. You can use the AdminTask object commands to access these commands.

Administrative commands are grouped based on their function. You can use administrative command groups to find related commands. For example, the administrative commands that are related to server management are grouped into a server management command group. The administrative commands that are related to the security management are grouped into a security management command group. An administrative command can be associated with multiple command groups because it can be useful for multiple areas of system management. Both administrative commands and administrative command groups are uniquely identified by their name.

The AdminTask object enables the execution of available admin commands. AdminTask commands operate in two modes:

the default mode is one which AdminTask communicates with the WebSphere server to accomplish its task. A local mode is also available, in which no server communication takes place. The local mode of operation is invoked by bringing up the scripting client using the command line "-conntype NONE" option or setting the "com.ibm.ws.scripting.connectiontype=NONE" property in wsadmin.properties file.

ObjectName, Attribute, and AttributeList classes using wsadmin scripting

WebSphere^® Application Server scripting commands use the underlying Java Management Extensions (JMX) classes, ObjectName, Attribute, and AttributeList, to manipulate object names, attributes and attribute lists respectively.

The WebSphere Application Server ObjectName class uniquely identifies running objects. 

The ObjectName class consists of the following elements:

• The domain name WebSphere.
• Several key properties, for example:
• type - Indicates the type of object that is accessible through the MBean, for example, ApplicationServer, and EJBContainer.
• name - Represents the display name of the particular object, for example, MyServer.
• node - Represents the name of the node on which the object runs.
• process - Represents the name of the server process in which the object runs.
• mbeanIdentifier - Correlates the MBean instance with corresponding configuration data.

When ObjectName classes are represented by strings, they have the following pattern:

[domainName]:property=value[,property=value]*

For example, you can specify WebSphere:name="My Server",type=ApplicationServer,node=n1,* to specify an application server named My Server. on node n1. (The asterisk (*) is a wildcard character, used so that you do not have to specify the entire set of key properties.)

 

Example

Obtain the object name with the completeObjectName

server1 = AdminControl.completeObjectName('node=mynode,type=Server,name=server1,*')

Obtain the object name with the queryNames command

server = AdminControl.queryNames('node=mynode,type=Server,name=server1,*')

                             

If there are several MBeans that match the template, the completeObjectName command only returns the first match. The matching MBean object name is then assigned to a variable. If there are more than one running objects returned from the queryNames command, the objects are returned in a list syntax.

To display the operations for the server MBean

print Help.operations(server)

To Invoke the operation

traceServ = AdminControl.completeObjectName('type=TraceService,process=server1,*')

AdminControl.invoke(traceServ,'appendTraceString',"com.ibm.ws.management.*=all=enabled")

You can modify multiple attribute name and value pairs  for  server ts1

ts1 = AdminControl.completeObjectName('type=TraceService,process=server1,*')

AdminControl.setAttributes(ts1,[['ringBufferSize',10],['traceSpecification',  'com.ibm.*=all=disabled']])

Another way,

ts1 =AdminControl.completeObjectName('type=TraceService,process=server1,*')

AdminControl.setAttributes(ts1,'[[ringBufferSize 10] [traceSpecification  com.ibm.*=all=disabled]]')

AdminControl object in wsadmin scripting

The AdminControl object is similar in many ways to the AdminConfig object. The primary difference between the two is that the AdminConfig object is used to manipulate configuration objects (represented using XML), and the AdminControl object is used to manipulate active application server objects (by interacting with managed beans—MBeans). One implication of this is that in order for this object to function, wsadmin must be connected to an active application server (the AdminControl object is not available when wsadmin is used in local mode)

The AdminControl object enables the manipulation of MBeans running in a WebSphere server process.  The number and type of MBeans available to the scripting client depends on the server to which the client is connected.  If the client is connected to a Deployment Manager, then all the MBeans running in the Deployment Manager are visible, as are all the MBeans running in the Node Agents connected to this Deployment Manager, and all the MBeans running in the application servers on those nodes.

The AdminControl scripting object is used for operational control. It communicates with MBeans that represent live objects running a WebSphere^® server process. It includes commands to query existing running objects and their attributes and invoke operation on the running objects. In addition to the operational commands, the AdminControl object supports commands to query information on the connected server, convenient commands for client tracing, reconnecting to a server, and start and stop server for network deployment environment.

Note that many of these commands support two different sets of signatures: one that accepts and returns strings, and one low-level  set that works with JMX objects like ObjectName and AttributeList. In most situations, the string signatures are likely to be more useful,  but JMX-object signature versions are supplied as well.  Each of these JMX-object signature commands has "_jmx" appended to the command name. Hence there is an "invoke" command, as well as a "invoke_jmx" command.

To see a list of all available commands for the AdminControl object:

Print  AdminControl.help()

Methods in AdminControl

Name	Description
completeObjectName	Return a String version of an object name given a template name
getAttribute_jmx	Given ObjectName and name of attribute, returns value of attribute
getAttribute	Given String version of ObjectName and name of attribute, returns value of attribute
getAttributes_jmx	Given ObjectName and array of attribute names, returns AttributeList.
getAttributes	Given String version of ObjectName and attribute names,returns String of name value pairs.
getCell	returns the cell name of the connected server
getConfigId	Given String version of ObjectName, return a configuration ID for  the corresponding configuration object, if any.
getDefaultDomain	returns "WebSphere"
getDomainName	returns "WebSphere”
getHost	returns String representation of connected host
getMBeanCount	returns number of registered beans
getMBeanInfo_jmx	Given ObjectName, returns MBeanInfo structure for MBean
getNode	returns the node name of the connected server
getObjectInstance	Given String version of ObjectName, returns  ObjectInstance object that match.
getPort	returns String representation of port in use
getType	returns String representation of connection type in use
help	Show help information
invoke_jmx	Given ObjectName, name of method, array of parameters and signature, invoke method on MBean specified
invoke	Invoke a method on the specified MBean
isRegistered_jmx	true if supplied ObjectName is registered
isRegistered	true if supplied String version of ObjectName is registered
makeObjectName	Return an ObjectName built with the given string
queryNames_jmx	Given ObjectName and QueryExp, retrieves set of ObjectNames that match
queryNames	Given String version of ObjectName, retrieves String of ObjectNames that match.
queryMBeans	Given String version of ObjectName, returns a set of ObjectInstances object that match.
reconnect	reconnects with server
setAttribute_jmx	Given ObjectName and Attribute object, set attribute for MBean specified
setAttribute	Given String version of ObjectName, attribute name and attribute value, set attribute for MBean specified
setAttributes_jmx	Given ObjectName and AttributeList object, set attributes for the MBean specified
setAttributes	Given String version of ObjectName, attribute name and value pairs, set attributes for the MBean specified
startServer	Given the name of a server, start that server
stopServer	Given the name of a server, stop that server.
testConnection	Test the connection to a DataSource object
trace	Set the wsadmin trace specification

Example of AdminConfig Object

Use the AdminConfig object listTemplates command to list available templates

AdminConfig.listTemplates ('JDBCProvider')

Assign the ID string that identifies the existing object to which the new object is added. 

You can add the new object under any valid object type. The following example uses a node as the valid object type:

To obtain configuration ID

wsadmin>print AdminConfig.getid('/Cell:win2k3/Node:win2k3/Server:server1/')

server1(cells/win2k3/nodes/win2k3/servers/server1|server.xml#Server_1183122130078)

wsadmin>print AdminConfig.getid('/Cell:win2k3/Node:win2k3/')

win2k3(cells/win2k3/nodes/win2k3|node.xml#Node_1)  

wsadmin>print AdminConfig.getid('/Cell:win2k3/')

win2k3(cells/win2k3|cell.xml#Cell_1)  

Administration objects that deal with configuration information require a config ID, whereas objects that deal with active application server resources require an MBean identifier.

 

In the documentation, the most common technique uses the AdminConfig.getid() method to obtain a config ID. However, this call requires that a containment path be provided. 

A containment path is a collection of one or more name/value pairs in a specific order. The name portion is required and is a configuration object type and is followed by a colon and an optional value. The name/value pairs are delimited using the slash character ’/’. Some example containment paths would be ’/Cell:/’, or ’/Cell:myCellName/’. Each containment path, when passed to the AdminConfig.getid() method, result in zero or more config IDs.