The AdminApp object for scripted administration

The AdminApp object interacts with the WebSphere Application Server - Express management and configuration services to administer applications. For example, you can use the AdminApp object to install and uninstall applications, list the modules for an application, and export an application.

You can invoke most of the AdminApp functions in local mode, which means that the client does not communicate with the server to accomplish the function. To run in local mode, use the -conntype NONE option when you start the scripting client. If a server is running, it is not recommended that you run the AdminApp tool in local mode.

For additional information about the AdminApp object, see these topics:

The following public methods are available for the AdminApp object:

deleteUserAndGroupEntries
Deletes users or groups for all roles, and deletes userids and passwords for all of the RunAs roles defined in the application.

Parameters: appname

Example usage:

edit
Edits an application or module in interactive mode.

Parameters: appname, options

Example usage:

Note: The edit command changes the application deployment. Specify these changes in the options parameter. No options are required for the edit command.

editInteractive
Edits an application or module in interactive mode.

Parameters: appname, options

Example usage:

Note: The editInteractive command changes the application deployment. Specify these changes in the options parameter. No options are required for the editInteractive command.

export
Exports the application appname parameter to a file you specify by file name.

Parameters: appname, filename

Example usage:

exportDDL
Extracts the description definition language (DDL) from the application appname parameter to the directoryname parameter that a directory specifies.

Note: This command is not supported when running from a system with only standalone scripting client install.

Parameters: appname, directoryname, options

Example usage:

help
Displays help for the AdminApp object and AdminApp commands.

Parameters: operation name (optional)

Example usage:

install
Installs an application in non-interactive mode, given a fully qualified file name and a string of installation options.

Note: This command is not supported when running from a system with only standalone scripting client install.

Parameters: earfile, options

Example usage:

There are many options available for this command. You can obtain a list of valid options for an EAR file with the following command:

You can also obtain help for each object with the following command:

installInteractive
Installs an application in interactive mode, given a fully qualified file name and a string of installation options.

Note: This command is not supported when running from a system with only standalone scripting client install.

Parameters: earfile, options

Example usage:

list
Lists the applications installed in the configuration.

Parameters: none

Example usage:

Example output:

wsadmin>$AdminApp list 
adminconsole 
DefaultApplication 
ivtApp

listModules
Lists the modules in an application.

Parameters: appname, options

Example usage:

Example output:

wsadmin>$AdminApp listModules ivtApp 
ivtApp#ivtEJB.jar+META-INF/ejb-jar.xml 
ivtApp#ivt_app.war+WEB-INF/web.xml

This example is formed by the concatenation of appname, #, module URI, +, and DD URI. You can pass this string to the edit and editInteractive AdminApp commands.

options
Displays a list of options for installing an EAR file.

Parameters: earfile

Example usage:

publishWSDL
Publishes WSDL files for the application specified in the appname parameter to the file specified in the filename parameter using the soap address prefixes specified in the soapAddressPrefixes parameter.

Parameters: appname, filename, soapAddressPrefixes (optional)

Example usage:

taskInfo
Provides information about a particular task option for an application file.

Parameters: earfile, task name

Example usage:

Example output:

MapWebModToVH: Selecting virtual hosts for Web modules
Specify the virtual host where you want to install the Web modules contained in
your application. Web modules can be installed on the same virtual host 
or dispersed among several hosts.
Each element of the MapWebModToVH task consists of the following 3 fields: 
"webModule," "uri," "virtualHost."
Of these fields, the following may be assigned new values: "virtualHost"
and the following are required: "virtualHost"

The current contents of the task after running default bindings are:
webModule: JavaMail Sample WebApp
uri: mtcomps.war,WEB-INF/web.xml
virtualHost: null

updateAccessIDs
Updates the access id information for users and groups assigned to various roles defined in the application. The access ids are read from the user registry and saved in the application bindings. It is recommended that you call this method after you install an application or after you edit security role information for an installed application. The scripting client must be connected to the application server when you invoke this command.

The bAll boolean parameter retrieves and saves all access IDs for users and groups in the application bindings. Specify false if you want to retrieve access ids for users or groups that do not have an access id in the application bindings.

Parameters: appname, bAll

Example usage:

view
View the task specified by the taskname option parameter for the application or module specified by the name parameter. Use -tasknames as the option to get a list of valid task names for the application. Otherwise, specify one or more task names as the option.

Parameters: name, taskname (optional)

Example usage:

Example output:

MapRolesToUsers: Mapping Users to Roles

Each role defined in the application or module must be
  mapped to a user or group from the domain's user registry.

Role:  administrator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  operator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  configurator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  monitor
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
MapWebModToVH: Selecting Virtual Hosts for Web Modules

Specify the virtual host where you want to install the Web
  modules contained in your application. You can install Web
  modules on the same virtual host or dispersed among several hosts:

Web Module:  adminconsole
URI:  adminconsole.war,WEB-INF/web.xml
Virtual Host:  admin_host
MapModulesToServers: Selecting Application Servers

Specify the application server where you want to install
  modules contained in your application. You can install
  modules on the same server or dispersed among several servers.

Module:  adminconsole
URI:  adminconsole.war,WEB-INF/web.xml
Server:  WebSphere:cell=juniartiNetwork,node=juniartiManager,server=dmgr
AppDeploymentOptions: Specifying Application Options

Specify the various options available to prepare and install your application:

Directory to Install Application:  $(APP_INSTALL_ROOT)/juniartiNetwork
Distribute Application:  Yes
Use Binary Configuration:  No
Application Name:  adminconsole
Create MBeans for Resources:  Yes
Enable Class Reloading:  No
Reload Interval in Seconds:  0

Example usage with the taskname option:

Example output:

Specify the application server where you want to install
  modules contained in your application. Modules can be installed
  on the same server or dispersed among several servers:
Module: adminconsole URI: adminconsole.war,WEB-INF/web.xml Server:
  WebSphere:cell=juniartiNetwork,node=juniartiManager,server=dmgr
  AppDeploymentOptions: Specifying Application Options
Specify the required options to prepare and install your application:
Directory to Install Application: $(APP_INSTALL_ROOT)/juniartiNetwork
  Distribute Application: Yes Use Binary Configuration: No Application Name:
  adminconsole Create MBeans for Resources: Yes Enable Class Reloading:
  No Reload Interval in Seconds: 0

Example usage with the taskname option:

Example output:

MapRolesToUsers: Mapping Users to Roles

Each role defined in the application or module must be
  mapped to a user or group from the domain's user registry.

Role:  administrator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  operator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  configurator
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
Role:  monitor
Everyone?:  No
All Authenticated?:  No
Mapped Users:
Mapped Groups:
MapWebModToVH: Selecting Virtual Hosts for Web Modules