Oracle WebLogic plugin

You can use the Deploy Oracle WebLogic server (WLS) plugin to manage deployments and resources on a WebLogic server. It can deploy and undeploy application artifacts, as well as datasources and other JMS resources. You can extend the plugin to support more deployment options or management of new artifacts or resources on WebLogic. For more information , see Extend the Deploy WebLogic Plugin.

For information on WebLogic requirements and the configuration items (CIs) that the plugin supports, see WebLogic Plugin Reference.

Features

• Deploy applications:
  • Enterprise application (EAR)
  • Web application (WAR)
  • Enterprise JavaBean (EJB)
  • J2EE Shared library
• Staging modes:
  • Stage
  • NoStage
• Deployment strategies:
  • Classical
  • Versioned
  • Side by side
• Deploy resources:
  • Datasource
  • JMS Queue
  • JMS Topic
  • JMS uniform distributed Queue
  • JMS uniform distributed Topic
  • JMS connection factory
  • Mail Session
  • Persistence Store (file and JDBC)
• Deploy files and folders
• Discover middleware containers

Use in deployment packages

The WebLogic plugin works with the standard deployment package (DAR) format. The following is a sample deployit-manifest.xml file that can be used to create a WebLogic-specific deployment package. It contain declarations for an EAR file (wls.Ear), a datasource (wls.DataSourceSpec), and two JMS resources.

<?xml version="1.0" encoding="UTF-8"?>
<udm.DeploymentPackage version="1.0" application="SampleApp">
    <deployables>
        <jee.Ear name="sampleApp.ear" file="sampleApp.ear">
        </jee.Ear>
        <wls.DataSourceSpec name="testDatasource">
            <jndiNames>jdbc/sampleDatasource</jndiNames>
            <url>jdbc:mysql://localhost/test</url>
            <driverName>com.mysql.jdbc.Driver</driverName>
            <username>{{DATABASE_USERNAME}}</username>
            <password>{{DATABASE_PASSWORD}}</password>
        </wls.DataSourceSpec>
        <wls.QueueSpec name="sampleQueue">
            <jmsModuleName>{{JMS_MODULE_NAME}}</jmsModuleName>
            <jndiName>jms/testQueue</jndiName>
        </wls.QueueSpec>
        <wls.ConnectionFactorySpec name="sampleCf">
            <jmsModuleName>{{JMS_MODULE_NAME}}</jmsModuleName>
            <jndiName>jms/sampleCf</jndiName>
        </wls.ConnectionFactorySpec>
    </deployables>
</udm.DeploymentPackage>

Deploying applications

You can adjust how an application is deployed to a container by modifying the properties of the corresponding deployed. For example, if an EAR file is to be deployed as a versioned application using nostage mode, you can specify these properties in the deployed EAR module (wls.EarModule):

• versioned = True. To enable this setting: In the Deploy user interface, select the Versioned checkbox.
• stage mode = NoStage To enable this setting: In the Deploy user interface, select NoStage from the drop-down list.
• staging directory = Absolute path of the directory where the EAR file should be uploaded

If the deployed application needs to be upgraded using the side by side deployment strategy, modify these properties in the deployed EAR module (wls.EarModule):

• staging directory = Directory path where the new EAR version will be uploaded.
• deployment strategy = SIDE_BY_SIDE To enable this setting: In the Deploy user interface, select SIDE_BY_SIDE from the drop-down list.
• retire timeout = A timeout period, in seconds, to retire the previous version of the application, if required.

Note: If retired timeout is set to -1 and deployment strategy is set to SIDE_BY_SIDE, the WebLogic plugin handles retiring the versioned application and does not handle the application undeployment or the removal of artifacts.

Updating shared libraries

When updating a shared library (wls.SharedLibraryWarModule or wls.SharedLibraryJarModule), the plugin will query the repository to find all the applications (wls.Ear and wls.War, property sharedLibraries) that depend on it. For each dependent application, the plugin will add: stop, undeploy, deploy, and start steps before and after the library update.

The wls.War and wls.Ear types have a SharedLibraries property. The default value can be set to {{SHARED_LIBRARIES}} in the deployment package. A dictionary may contain the value and this value can be a list of configuration item IDs.

For example, a deployed EAR module must to link two deployed shared libraries, libfoo and libbar. The target is a wls.Cluster (/Infrastructure/wlsDomain-103/cluster-1). The dictionary can be set up as follows:

Key	Value
SHARED_LIBRARIES	{{TARGET}}/libfoo,{{TARGET}}/libbar
TARGET	/Infrastructure/wlsDomain-103/cluster-1

Targeting multiple containers

Certain deployables can be targeted to multiple containers. For example, an EAR file can be targeted to two clusters. Similarly, a datasource can be targeted to two clusters.

Create steps

To handle multiple targets, the WebLogic plugin generates steps for each targeting. For example, if a datasource is targeted to Cluster-1 and Cluster-2, Deploy will create two datasource creation steps:

• The first step will create the datasource on Cluster-1, with all the properties of the deployed datasource.
• The second step will add Cluster-2 to the target list of the datasource created in first step. If differences are found in the datasource values of this deployed, the WebLogic plugin will override the previous value.

Important: The second target overrides the properties of the first target. You must ensure that the properties of the deployeds, of the same deployable, are uniform.

Destroy steps

The following sequence of steps occurs if a destroy operation takes place for a datasource with multiple targets:

• The first step will remove Cluster-1 from the datasource target list.
• The second step will remove Cluster-2 from the datasource target list, and now that the datasource has no target set on it, it destroys the datasource.

Deploy steps

By default, when deploying wls.Ear, wls.War, wls.EjbJar, and shared library artifacts to multiple target servers, the WebLogic Plugin will create a separate deployment step for each target server.

For example:

1. Deploy PetClinic-1.0.ear on wlserver-1.
2. Deploy PetClinic-1.0.ear on wlserver-2.

Multi-target deployment mode

The WebLogic Plugin also supports targeting multiple managed servers in one command by setting deployment mode on wls.Domain to MULTI_TARGET. In this case, the plugin will generate a deployment plan containing only one deployment step for all target servers in the domain.

For example:

1. Deploy PetClinic-1.0.ear on wldomain: wlserver-1, wlserver-2

Creating resources

Deploy handles the creation of resources in the same way that it handles deploying an application. If needed, you can trigger a restart by setting the restartTarget parameter to "true".

Copying files

Deploy handles the copying of files targeted on a wls.Server or wls.Cluster. If needed, you can trigger a restart by setting the restartTarget parameter to "true".

Managing JMS resources

The WebLogic Plugin simplifies the management of JMS resources by automatically managing JMS modules and sub-deployments needed for JMS resources.

For example, the following is the sequence of steps that occurs when a JMS resource, such as a queue, is created:

1. You specify the JMS module name in a deployed resource. For example, the jmsModuleName property of wls.Queue.
2. If a module is not present, the WebLogic plugin creates the module. If modules are present, the plugin adds the deployed container to existing module targets.
3. If a sub-deployment is not present, the WebLogic plugin creates the sub-deployment. If the sub-deployment is present, the plugin adds the deployed container to existing sub-deployment targets.
4. The WebLogic plugin creates/updates the JMS resource and assigns the sub-deployment created in the previous step as the resource sub-deployment.

The destruction of a JMS resource is handled as follows:

1. The resource container is removed from its sub-deployment targets.
2. If the sub-deployment target list is empty, the JMS resource is destroyed. Note: If a sub-deployment contains no targets, it is destroyed automatically.
3. If no other JMS resources are using the JMS module, it is destroyed.