DevOps Automation

 View Only

More flexibility improves configuration data management in WebSphere Application Server – Configure plug-in

By Laurel Dickson-Bull posted Mon July 25, 2022 10:47 AM

  

This article was originaly published in 2017.03.13

For version 49 and later of the IBM® WebSphere® Application Server - Configure plug-in, the WebSphere – Create Configuration Snippet step was enhanced to give you more flexibility in managing configuration data.
To begin working with the WebSphere – Create Configuration Snippet step, you must have configuration data stored in a .json file. The WebSphere Configuration Discovery step returns a .json file of configuration data when you run the step.
After you have your configuration data in a .json file, you can use the WebSphere – Create Configuration Snippet step to extract pieces of your configuration. Reasons why you might want to do so include these capabilities:

  • Creating templates from subsets of configuration data
  • Dividing configuration data into smaller pieces and restricting who may manage certain pieces
  • Dividing configuration data into smaller pieces for easier configuration data management

We’ll walk through some examples, but first, let’s look at the properties of the WebSphere – Create Configuration Snippet step:


Original Configuration File: Specify the location and name of the configuration data .json file. This is the file where extracted snippets come from.
Paths of Resources to Extract: Enter a new-line separated list of paths that correspond to the resource to extract from the configuration data. For example, let’s say you want to create a snippet based on a JDBC provider named CellJDBC. Locate the CellJDBC JDBC provider in your configuration data:
The path for this resource is highlighted in the following figure. To extract this resource, enter the /@websphere.cell@/JDBC Providers/CellJDBC path in the Paths of Resources to Extract field.


Object Types to Extract: Instead of listing individual configuration objects to create snippets of, snippets can be created by specifying object types. For example, if you specify JDBCProvider in this field, all objects of the JDBCProvider type in your configuration data will have snippets created for them. This field accepts a new-line separated list of object types. Values can be specified in both the Object Types to Extract and the Paths of Resources to Extract fields. For a list of WebSphere object types, run this wsadmin command: print AdminConfig.types().
Extracted Snippet File: The file to be created to contain the extracted resources. If the Create Snippet File for each Resource option is selected, the file name format is based on the value that is entered in the Extract Snippet File field. For more information, see the Create Snippet File for each Resource property that follows.
Create Snippet File for each Resource: If this option is selected, a new .json file is created for each object to be extracted. For example, if you specify JDBCProvider in the Object Types to Extract field, have five JDBC provider objects in your configuration data, and select this option, five .json files are created. If this option is not selected, one file is produced, and it contains configuration data for all extracted resources. If this option is selected, the created files have the name format of the file that is specified in the Extracted Snippet File field with [object type]_[integer] appended to the file name. For example, if the value of my Extracted Snippet File field is C:\tmp\mySnippet.json, and I extract five JDBC provider resources with this option selected, the resulting files are as follows:

  • C:\tmp\mySnippetJDBCProvider_1.json
  • C:\tmp\mySnippetJDBCProvider_2.json
  • C:\tmp\mySnippetJDBCProvider_3.json
  • C:\tmp\mySnippetJDBCProvider_4.json
  • C:\tmp\mySnippetJDBCProvider_5.json

New Configuration File: Specify the location and name of the configuration data file to be created, which contains all initial configuration data minus the data that was extracted as snippets. This field is useful for removing objects from configuration data.

With an understanding of how the WebSphere – Create Configuration Snippet step works, let’s work through some scenarios you might encounter.

Scenario 1: Creating a template for application developers

In this scenario, let’s say application developers add only JDBC providers to WebSphere Application Server configurations as part of their application development. You want to create a template of a JDBC provider so that developers can make a copy of the template, set certain properties, and then deliver the template as part of their configuration changes. To do so, complete these steps:

  1. Find the resource path of an existing JDBC provider in the configuration data.
  2. In the Paths of Resources to Extract field, enter the path.
  3. In the Original Configuration File field, specify the configuration file location and name.
  4. In the Extracted Snippet File field, specify a file name.
  5. Run the step.

Result: A .json file is created with the contents of the JDBC provider configuration. Users can then use the WebSphere – Templatize Snippet Configuration Data step to templatize values further.

Scenario 2: Removing resources from configuration data

In this scenario, configuration data contains ten data sources. The data sources are in a server’s Server.json file. Changes require that the three data sources be removed: DataSourceA, DataSourceB, and DataSourceC. To do so, complete these steps:

  1. Find the resource paths of DataSourceA, DataSourceB, and DataSourceC.
  2. In the Paths of Resources to Extract field, enter the three paths.
  3. In the Original Configuration File field, specify the configuration file’s location and name.
  4. In the New Configuration File field, enter the location and name of the configuration file to be created.
  5. Run the step.

Result: A configuration file is created and contains the same results as the original configuration file, minus the three data sources.

Scenario 3: Splitting configuration data among teams

In this scenario, you ran the WebSphere Configuration Discovery step against a cell, producing a Cell.json file. Different teams in this organization manage different parts of the cell configuration. Team A manages the JAAS configuration (JAASAuthData objects). Team B manages key stores. Team C manages JDBC providers at the cell scope. There is a need to split up the configuration data among these teams, so each team can touch only the pieces they are responsible for. To do so, complete these steps:

  1. 1. In the Original Configuration File field, specify the configuration file location and name.
  2. 2. In the Object Types to Extract field, enter JAASAuthData, KeyStore, and JDBCProvider.
  3. 3. Select the Create Snippet File for each Resource check box.
  4. 4. Run the step.

Result: Multiple files are created. Files that contain JAASAuthData objects might be assigned to Team A. Files that contain KeyStore objects might be assigned to Team B. Files that contain JDBCProvider objects might be assigned to Team C.

Scenario 4: Dividing configuration data while migrating to UrbanCode Deploy

In this scenario, a team is new to using UrbanCode Deploy for managing WebSphere Application Server configurations. In their configuration data, they have 40 namespace bindings. They want to organize their namespace bindings by grouping them with the application that they are associated with. To do so, complete these steps:

  1. 1. In the Original Configuration File field, specify the configuration file location and name.
  2. 2. In the Object Types to Extract field, enter NameSpaceBinding.
  3. 3. Select the Create Snippet File for each Resource check box.
  4. 4. Run the step.

Result: Forty configuration files are created. Each file represents an individual namespace binding. Users can then organize the files by application.

These are just a few scenarios you might run into when you manage configuration data. Hopefully, this blog post inspired some approaches you can take when you manage your own configuration data.


#WebSphereApplicationServer(WAS)
#UrbanCodeDeploy
#json
0 comments
2 views

Permalink