You can create an empty business-level application, and
then add assets, shared libraries, or business-level applications
as composition units to the empty business-level application.
Before you begin
Before you can create a business-level application, determine
the assets or other files to add to your application.
Also,
verify that the target application server is configured. As part of
configuring the server, determine whether your application files can
run on your deployment targets.
About this task
You can use the wsadmin tool to create business-level applications
in your environment. This topic demonstrates how to use the AdminTask
object to import and register assets, create empty business-level
applications, and add assets to the business-level application as
composition units. Alternatively, you can use the scripts in the
AdminBLA script library to set up and administer business-level applications.
Procedure
- Start the wsadmin scripting tool.
- Import assets to your configuration.
Assets
represent application binaries that contain business logic that runs
on the target runtime environment and serves client requests. An asset
can contain an archive of files such as a compressed (zip) or Java archive (JAR) file, or an archive of archive
files such as a Java Platform, Enterprise Edition (Java EE) enterprise
archive (EAR) file. Examples of assets include EAR files, shared library
JAR files, and custom advisors for proxy servers.
Use the importAsset command
to import assets to the application server configuration repository.
See the documentation for the BLAManagement command group for the
AdminTask object for additional parameter and step options.
For
this example, the commands add three assets to the asset repository.
Two of the assets are non-Java EE assets and one is an enterprise
asset. The following command imports the asset1.zip asset
to the asset repository and sets the returned configuration ID to
the asset1 variable:
asset1 = AdminTask.importAsset('-source c:/ears/asset1.zip')
![[Linux]](../images/linux.gif)
![[Solaris]](../images/solaris.gif)
![[HP-UX]](../images/hpux.gif)
![[AIX]](../images/aixlogo.gif)
![[IBM i]](../images/iseries.gif)
asset1 = AdminTask.importAsset('-source /ears/asset1.zip')
The
following command imports the asset2.zip asset
metadata only, sets the asset name as testAsset.zip,
sets the deployment directory, specifies that the asset is used for
testing, and sets the returned configuration ID to the testasset variable:
testasset = AdminTask.importAsset('-source c:/ears/asset2.zip -storageType METADATA
–AssetOptions [[.* testAsset.zip .* "asset for testing"
c:/installedAssets/testAsset.zip/BASE/testAsset.zip "" "" "" false]]')
![[Linux]](../images/linux.gif)
![[Solaris]](../images/solaris.gif)
![[HP-UX]](../images/hpux.gif)
![[AIX]](../images/aixlogo.gif)
![[IBM i]](../images/iseries.gif)
testasset = AdminTask.importAsset('-source /ears/asset2.zip -storageType METADATA
–AssetOptions [[.* testAsset.zip .* "asset for testing"
/installedAssets/testAsset.zip/BASE/testAsset.zip "" "" "" false]]')
The
following command imports the defaultapp.ear asset,
storing all application binaries, and sets the returned configuration
ID to the J2EEAsset variable:
J2EEAsset = AdminTask.importAsset('-source c:/ears/defaultapplication.ear
–storageType FULL –AssetOptions [[.* defaultapp.ear .* "desc" "" "" "" "" false]]')
![[Linux]](../images/linux.gif)
![[Solaris]](../images/solaris.gif)
![[HP-UX]](../images/hpux.gif)
![[AIX]](../images/aixlogo.gif)
![[IBM i]](../images/iseries.gif)
J2EEAsset = AdminTask.importAsset('-source /ears/defaultapplication.ear
–storageType FULL –AssetOptions [[.* defaultapp.ear .* "desc" "" "" "" "" false]]')
The assets of interest are registered as named configuration
artifacts in the application server configuration repository, which
is referred to as the asset registry. Use the
listAssets command
to display a list of registered assets and verify that the settings
are correct, as the following example demonstrates:
AdminTask.listAssets('-includeDescription true -includeDeplUnit true')
- Create an empty business-level application.
Use
the
createEmptyBLA command to create a new business-level
application and set the returned configuration ID to the
myBLA variable,
as the following example demonstrates:
myBLA = AdminTask.createEmptyBLA('-name myBLA
-description "BLA that contains asset1, asset2, and J2EEAsset"')
The system creates the business-level application. Use
the listBLAs command to display a list of each
business-level application in the cell, as the following example demonstrates:
AdminTask.listBLAs()
- Add the assets, as composition units, to the business-level
application.
Composition units can represent deployed
assets, other business-level applications, or external artifacts that
are deployed on non-Application Server run times without backing assets.
Business-level applications contain zero or more composition units.
You cannot add the same composition unit to more than one business-level
application, but you can use one asset to create more than one composition
unit.
Use the
addCompUnit command to add
assets as composition units to business-level applications. The following
command adds the
asset1.zip asset as a composition
unit in the
myBLA business-level application, and
maps the deployment to the
server1 server:
AdminTask.addCompUnit('-blaID myBLA –cuSourceID asset1
-CUOptions [[.* .* compositionUnit1 "composition unit that is backed by asset1" 0]]
-MapTargets [[.* server1]]
–ActivationPlanOptions [[.* specname=actplan0+specname=actplan1]]')
The
following command adds the
testAsset.zip asset
as a composition unit in the
myBLA business-level
application, and maps the deployment to the
server1 and
testServer servers:
AdminTask.addCompUnit('-blaID myBLA –cuSourceID asset2
-CUOptions [[.* .* compositionUnit2 "composition unit that is backed by asset2" 0]]
-MapTargets [[.* server1+testServer]]
–ActivationPlanOptions [.* specname=actplan0+specname=actplan1]')
The
following command adds the
defaultapp.ear asset
as a composition unit in the
myBLA business-level
application, and maps the deployment to the
server1 and
testServer servers:
AdminTask.addCompUnit('[-blaID bla1 -cuSourceID ' + J2EEAsset + ' -defaultBindingOptions
defaultbinding.ejbjndi.prefix=ejb#defaultbinding.virtual.host=default_host#defaultbinding.force=yes
-AppDeploymentOptions [-appname defaultapp] -MapModulesToServers [["Default Web Application" .*
WebSphere:cell=cellName,node=nodeName,server=server1] ["Increment EJB module" .*
Websphere:cell=cellName,node=nodeName,server=testServer]]
-CtxRootForWebMod [["Default Web Application" .* myctx/]]]')
- Save your configuration changes.
Use the following command example to save your configuration
changes:
AdminConfig.save()
- Synchronize the nodes.
Use
the syncActiveNodes script in the AdminNodeManagement script library
to synchronize each active node in your environment, as the following
example demonstrates:
AdminNodeManagement.syncActiveNodes()
- Start the business-level application.
Use
the
startBLA command to start each composition
unit of the business-level application on the deployment targets for
which the composition units are configured, as the following example
demonstrates:
AdminTask.startBLA('-blaID myBLA')
Results
The system adds three composition units backed by assets
to a new business-level application. Each of the three assets are
deployed and started on the server1 server. The testAsset.zip and defaultapp.ear assets
are also deployed and started on the testServer server.