This article was originaly published in 2016.10.03

Managing WebSphere configurations with JSON snippets

You can use IBM UrbanCode Deploy and the WebSphere Application Server – Configure plug-in to manage WebSphere Application Server configurations by storing configuration data in templates. Templates can then be applied to various WebSphere environments. To change a configuration, you update the configuration data and then apply it to the environment. Because templates can have versions, an example workflow might follow these steps:

1. Apply version 1.0 of the configuration data to WebSphere Application Server.
2. Edit the configuration data to increase the JVM heap size.
3. Save the updated configuration data as version 2.0.
4. Apply the updated configuration data to your environments, thus increasing the server JVM heap size in all of them.

Configuration data is stored in JSON format. You can break large configuration files into smaller pieces, or snippets, to make the data more manageable. This document describes one approach for managing WebSphere configurations with JSON snippets. Components manage collections of snippets In this approach, the configuration data is broken into multiple files (snippets) that are stored in one component. At deployment time, the configuration data files are merged into one file and applied to your environment. For example, if you manage configuration data for a server in a component, the configuration data might be stored in a file named Server.json. Later you decide to add a JDBC provider to the server configuration. You add a snippet that represents the JDBC provider (call it JDBCProvider.json) to the component. The new version of the component contains two files in the component version artifacts: Server.json and JDBCProvider.json. When the new version of the configuration data is applied to an environment, the Server.json and JDBCProvider.json files are merged and applied as one. For more information about this approach, see Managing configurations with snippet collections.

Benefits

Typically, you manage your configurations with components at the following WebSphere scopes only:

• Cell
• Node
• Server
• Cluster

Using components at only these scopes offers the following benefits:

• Simplicity, because you manage fewer components.
• Improved portability. To deploy a server to a new environment, you need only one component and you run only one apply process.
• Live comparison compatibility. You can use the live comparison feature to detect differences between what you expect to be in a WebSphere Application Server environment (configuration data) and the actual “live” configuration in the environment.

To understand these benefits, consider an example scenario where you want to deploy a WebSphere Application Server configuration to a new environment. The target environment includes a cell, two nodes, a node agent, a deployment manager, and a cluster with two application server cluster members. The resource tree is shown in the following screen capture:

 The components manage their respective resources (cell, node, server, or cluster). To deploy the configuration, you deploy these components. If you want, you can further limit the number of components. For example, a node and all of the servers that it contains can be managed by a single component. A cell and all of its nodes, clusters, and servers can be managed in a single component as well. These scenarios have fewer components to manage, but deployment time for incremental changes increases. A change to a single server still requires processing a large amount of configuration data. In these scenarios, the amount of configuration data to manage in a component might be large. If you want to add a JDBC provider and three data sources to the testClusterMember1 server, you add snippets that represent the new JDBC provider and the new data sources to the Server – testClusterMember1 component. The result is five configuration files that are stored as component version artifacts:

 You can automate the process to add snippets to components as component version artifacts. For an example, see Tokenizing values in snippet files. To apply the updated server configuration to the WebSphere Application Server environment, deploy version 2.0 of the Server – testClusterMember1 component. When you are ready to deploy version 2.0 of the Server – testClusterMember1 component to a new environment, add a server resource and the Server – testClusterMember1 component to the new environment's resource tree and deploy. Now, say that you hear a rumor that a WebSphere Application Server admin logged in to the admin console and made some configuration changes to the testClusterMember1 server, despite being warned that configuration changes must be made with IBM UrbanCode Deploy only. You can use the live comparison feature of the WebSphere Application Server – Configure plug-in to check whether the configuration data for the testClusterMember1 server match what is stored as version 2.0. If a user really did change the configuration, you can discover the exact changes by using this feature. The live comparison feature compares the server's actual configuration to the stored configuration data and highlights any differences.