Starting with version 14 of the WebSphere Application Server – Configure plug-in for IBM UrbanCode Deploy, you use JSON files to manage WebSphere Application Server configurations.

The configuration data is stored in a series of JSON files. The JSON files can be grouped to represent cell and Deployment Manager configurations, node and node agent configurations, cluster and cluster member configurations, and so on. You can then associate the groups of JSON files with IBM UrbanCode Deploy components and assign version numbers to the JSON files. Finally, you can create processes to apply configurations and configuration changes to WebSphere Application Server instances.

Benefits

Scope-specific application of changes

Because you can group JSON files into components such as cell configuration, node configuration, and so on, you can apply changes for one component without affecting the other components. For example, you can choose to apply only cell configuration changes. Changes to the cell configuration are then applied, but the node configuration remains unchanged.

Version numbering and comparison

Because the JSON files are stored as component artifacts, they have version numbers. You can compare versions to identify configuration changes by using the IBM UrbanCode Deploy user interface.

Template creation for multiple clusters and environments

You can build a JSON template that represents a server cluster member. Users can then create any number of server cluster members based on the template. For example, in a development environment, users might want to deploy a cluster with two servers on each node. A QA environment might have four servers on each cluster. You can use the JSON server template with IBM UrbanCode Deploy to create these multiple servers.

Discovering WebSphere Application Server configuration data and converting data into templates

For more information, see Converting WebSphere Application Server configuration data into templates.

Creating components

After you create templates and group JSON files by cells, clusters, and nodes, you create IBM UrbanCode Deploy components to represent these groups.

Import the provided demonstration application as a guide for creating components. For more information, see the sample documents. Store your JSON files as artifacts in the components. For example, the following screen captures show how the node component artifacts might be stored:

The components that are provided in the demonstration application each include a process that is named Apply. The following screen capture shows an example of the Apply process:

The processes typically include the following steps:

1. Clean the working directory.
2. Download component artifacts (your JSON files).
3. Replace tokens. For example, replace @websphere.cell@ with the actual cell name.
4. Combine JSON information. To add an object to your configuration, you do not need to edit the existing JSON information. Instead, you can create a JSON snippet and add it to your component artifacts. For example, to add a JDBC provider at the cell scope, create a JSON file similar to the following text:
   

Next, add the JSON snippet to the component artifacts of the cell.

When the Combine Cell step runs, the step merges all of the JSON files in the cell folder. This approach makes it easier to add and remove objects from a configuration (as opposed to manually editing JSON each time that you want to change a configuration). For more information, see Configuration snippet overview.

5. Apply the configuration changes. In the previous screen capture, changes are applied to the cell and then the Deployment Manager configurations.

Creating Applications

Use the provided demonstration application as a guide for creating applications. For more information, see the sample documents.

The demonstration application includes a process that is named Deploy. The following screen capture shows the steps in the Deploy process:

Each step is a Run Process for Each Version step. These steps run the Apply process for one of the components.

Set Max # of concurrent jobs to 1. Attempting to apply multiple changes to a WebSphere Application Server configuration simultaneously causes errors.

Set up the process to first apply the configuration to the cell, then the node, then the cluster.

Applying a configuration to a new environment

To apply the WebSphere Application Server configuration to a new environment, follow these steps:

1. Provision a WebSphere Application Server environment.
2. Install the IBM UrbanCode Deploy agent on the new WebSphere Application Server environment.
3. In IBM UrbanCode Deploy, go to the Resource page and then click Create Top-Level Group.
4. Enter a name for the top-level resource, and then click Save.
5. From the Actions menu for the top-level resource, click Add Agent and then select the agent that is running on the computer where WebSphere Application Server is installed.
6. Wait 10 – 30 seconds, and then click Refresh. Repeat this step until a WebSphereCell resource is displayed under the agent
   
   
7. Edit the WebSphereCell resource to add your WebSphere login and connection information.
   
   

8. From Actions menu for the WebSphereCell object, select Configure using WebSphere Topology Discovery.
   
   
   
   

9. After topology discovery finishes, add the components to the discovered resource tree. To start adding the components, expand the WebSphereCell resource until the Nodes folder is displayed.
   
   
   

10. From the Actions menu for the node that contains Deployment Manager, select Add Component. Select the cell component that you created. Optionally, specify aliases for the default_host virtual host.
    
    

    

11. Under each node that will contain application servers, add the node component.
    
    

12. If you are adding a server cluster, ensure that a WebSphereCluster resource role is under the Server Clusters folder. If not, click Show and then select Resource Roles.
    
    

Enter WebSphereCluster in the search field to find the resource role that is named WebSphereCluster.

Drag the WebSphereCluster resource role from the Resource Roles pane to the ServerClusters folder.

Enter a name for the WebSphereCluster resource and then click Save.

13. If you are adding a server cluster, add the cluster component under the WebSphereCluster resource role.
    
    
    

For the SERVER_COUNT property, enter the number of application servers that each node will contain.

For the NODELIST property, enter a comma-separated list of the names of nodes that will contain cluster members.

The ENDPOINTPORTMAPPINGS property describes the ports that the endpoints will use. The first server that is created on a node uses the port number specified. The port number is then incremented by one for each additional server on a node so that port numbers remain unique. Enter the value in the specified format: each mapping is in the format endPointName->endPointHost->endPointPort. Separate values with \n. If you use a period in place of the endPointHost, the host name of the node is used. The following text shows an example value of the ENDPOINTPORTMAPPINGS property:

BOOTSTRAP_ADDRESS->.->50000\nSOAP_CONNECTOR_ADDRESS->.->50100\nORB_LISTENER_ADDRESS->.->50200\nSAS_SSL_SERVERAUTH_LISTENER_ADDRESS->.->50300\nCSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS->.->50400\nCSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS->.->50500\nWC_adminhost->.->50600\nWC_defaulthost->.->50700\nDCS_UNICAST_ADDRESS->.->50800\nWC_adminhost_secure->.->50900\nWC_defaulthost_secure->.->51000\nSIP_DEFAULTHOST->.->51100\nSIP_DEFAULTHOST_SECURE->.->51200\nOVERLAY_UDP_LISTENER_ADDRESS->.->51300\nOVERLAY_TCP_LISTENER_ADDRESS->.->51400\nIPC_CONNECTOR_ADDRESS->.->51500\nSIB_ENDPOINT_ADDRESS->.->51600\nSIB_ENDPOINT_SECURE_ADDRESS->.->51700\nSIB_MQ_ENDPOINT_ADDRESS->.->51800\nSIB_MQ_ENDPOINT_SECURE_ADDRESS->.->51900\n

The following screen capture shows where to find the port names for endpoint port mappings:

The SERVERNAMEFORMATS field describes how the servers are named. The SERVERNAMEFORMATS field is a list, which is separated by newline characters, with the following format: nodename->pattern. Patterns can contain %c, %n and %i, where %c represents the cluster name, %n represents the node name, and %i is the index. The default value of *->%c-%n-%i names servers in a cluster name-node name-index format for all nodes.

Click Save.

14. Under the application folder, create an environment. Alternately, if you are using the provided sample application, use the TEST application that is included in the sample.
15. Select the environment. Click Add Base Resources. Select the top-level resource where you added components, and then click OK.
    
    
    

16. Go to the environment and then click Run. In the Process list, select Deploy. Select the versions of your components to run. Click Submit
    

The process runs and your configuration changes are applied.

Applying changes at a specific scope

In the previous example, the sample application process applied configurations at the cell, node, and cluster level. To apply configurations at only one level, either remove a component’s Run Process for Each Version step from the application process, or run a component’s component process directly.

Making configuration changes manually

You can change configurations by editing the JSON files manually. You can tokenize values in the JSON file and take advantage of properties to change values among configurations. See how the @DEFAULTHOSTVIRTUALHOSTALIASES@ value was tokenized and set as a property previously in this documentation for an example.

You can also take advantage of the Combine steps and create JSON snippets to add objects and properties to a configuration. The Combine step automatically merges JSON files. You can create configuration objects by adding a small snippet of JSON to your configuration instead of manually editing a large JSON file. See the previous example where a JDBC provider was added at the cell scope by using a JSON snippet.

Comparing configuration versions

Because configuration information is stored as component artifacts, and those artifacts are JSON files, you can compare versions in the IBM UrbanCode Deploy user interface to examine differences in configurations.