Over a million developers have joined DZone.

Managing Websphere Configurations With JSON Snippets: Two Approaches

In this post, we take a look at how to manage your WebSphere configurations using JSON and the Configure plugin. Read on to find out more.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

You follow one of two different approaches for managing configuration data with snippets:

Approach 1: Components Manage Collections of Snippets

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.

Approach 2: Components Manage Individual WebSphere Objects

A component is created to manage an individual WebSphere configuration object. With this approach, to add a JDBC provider to a server’s configuration you create a component that contains only the JDBC provider configuration data. Your server is then managed by two components: one managing all of the server configuration except for the JDBC provider, and one managing the JDBC provider only. For more information about this approach, see Managing individual configuration objects with snippets.

To learn more about creating snippets, see Creating configuration snippets.

Benefits of Approach 1

Typically, you use the first approach and manage your configurations with components at the following WebSphere scopes only:

Using components at only these scopes offers the following benefits:

  • Simplicity. 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:snippetblog1

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 use the first approach and 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:snippetblog2

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.

Potential Drawbacks of Approach 2

Think about the previous scenario, where you add a JDBC provider and three data sources to the testClusterMember1 server, only this time, use the approach where you create individual components to manage the JDBC provider and data sources.

The resource tree is more complex when you use the second approach. Previously, one component managed the testClusterMember1 server:snippetblog3

Now it takes five components to manage the server:snippetblog4

To apply the configuration changes to the environment, you must deploy the JDBC provider first. Then, you can deploy the data sources one by one. You must deploy the JDBC provider first because it is a parent of the data sources and must exist before the data sources can be created. Complexity increases because you must remember the required component deployment order.

To deploy the new server configuration to a new environment, you must add the server resource, the server component, the JDBC provider component, and the three data source components to the resource tree. You then must apply the Server component, then the JDBC provider component, and then the data source components in that specific order. This procedure is more complicated than adding a resource and a single component to the resource tree and running one apply process.

Again, say that you hear a rumor that someone bypassed IBM UrbanCode Deploy and directly changed the configuration of the testClusterMember1 server. You want to make sure that what is deployed in the environment matches the stored configuration data. Unfortunately, the live comparison feature does not work across multiple components. The only way to make sure that the live environment matches the configuration data is to deploy everything again. What if the rogue user made a critical fix in the WebSphere Application Server environment? You would want to know what they changed and include that in the configuration data. Without the live comparison feature, you can’t easily detect those changes with IBM UrbanCode Deploy.


Always use the approach that works best for you and your organization. The information that is provided here can help you decide which approach is right for you.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today


Published at DZone with permission of Anitha Mathew. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}