DevOps Automation

 View Only

Managing configurations with snippet collections

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

  

This article was originaly published in 2016.09.29

Using JSON snippets to add objects to a configuration

To add an object to a WebSphere Application Server configuration, create a JSON file that represents the object. Use the provided WebSphere – Create Configuration Snippet step to create snippets. For example, let’s say you used the WebSphere – Create Configuration Snippet step to create a JDBC provider snippet. Let’s say the snippet file is named jdbcProvider.json.

If you are storing configuration data as component version artifacts, add the JSON file to the component version artifacts in the cell directory, as shown in the following screen capture:


When the Apply process runs, the Cell.json and jdbcProvider.json files are merged and applied to the target instance of WebSphere Application Server.

Tokenizing values in snippet files

To learn more about tokenizing values in snippets, see Tokenizing values in snippet files.

JSON hierarchy

When you use the WebSphere – Create Configuration Snippet step to create snippets, JSON paths and hierarchy are managed automatically for you. If you want to create snippets manually, read on for more information about configuration data JSON structure.

The JSON information that represents a WebSphere Application Server configuration resembles a directory hierarchy. For example, the following JSON information represents three JDBC providers:

    {
        "name": "JDBC Providers",
        "path": "/CloudBurstCell_1/Nodes/CloudBurstNode_1/JDBC Providers",
        "teamMappings": [],
        "description": "Discovered JDBC Providers",
        "inheritTeam": "true"
    },
    {
        "name": "first JDBC Provider",
        "path": "/CloudBurstCell_1/Nodes/CloudBurstNode_1/JDBC Providers/first JDBC Provider",
        "teamMappings": [],
        "inheritTeam": "true",
        "description": "Discovered WebSphereJDBCProvider",
        "roleName": "WebSphereJDBCProvider",
        "roleProperties": {
            "websphere.jdbcprovider.xa": "false",
            "websphere.jdbcprovider.name": "first JDBC Provider",
            "websphere.jdbcprovider.classpath": "${WAS_INSTALL_ROOT}/derby/lib/derby.jar",
            "websphere.jdbcprovider.implementationclassname": "org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource",
            "websphere.jdbcprovider.isolatedclassloader": "false"
        }
    },
{
        "name": "second JDBC Provider",
        "path": "/CloudBurstCell_1/Nodes/CloudBurstNode_1/JDBC Providers/second JDBC Provider",
        "teamMappings": [],
        "inheritTeam": "true",
        "description": "Discovered WebSphereJDBCProvider",
        "roleName": "WebSphereJDBCProvider",
        "roleProperties": {
            "websphere.jdbcprovider.xa": "false",
            "websphere.jdbcprovider.name": "second JDBC Provider",
            "websphere.jdbcprovider.classpath": "${WAS_INSTALL_ROOT}/derby/lib/derby.jar",
            "websphere.jdbcprovider.implementationclassname": "org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource",
            "websphere.jdbcprovider.isolatedclassloader": "false"
        }
    },
{
        "name": "third JDBC Provider",
        "path": "/CloudBurstCell_1/Nodes/CloudBurstNode_1/JDBC Providers/third JDBC Provider",
        "teamMappings": [],
        "inheritTeam": "true",
        "description": "Discovered WebSphereJDBCProvider",
        "roleName": "WebSphereJDBCProvider",
        "roleProperties": {
            "websphere.jdbcprovider.xa": "false",
            "websphere.jdbcprovider.name": "third JDBC Provider",
            "websphere.jdbcprovider.classpath": "${WAS_INSTALL_ROOT}/derby/lib/derby.jar",
            "websphere.jdbcprovider.implementationclassname": "org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource",
            "websphere.jdbcprovider.isolatedclassloader": "false"
        }
    },

You can think of the four previous JSON entries as a directory hierarchy, with the first entry representing a folder and the other entries representing objects contained in the folder.

|
--- JDBC Providers
     |
     --- first JDBC Provider
     |
     --- second JDBC Provider
     |
     --- third JDBC Provider

This structure is reflected in the path value for each of the JSON entries.

The parent JSON entry is required, and there must be only one parent entry. Keep this in mind when creating snippets. For example, if you use a snippet to add a JDBCProvider object at the cell level, the final JSON file must contain the following JSON entry only once:

    {
        "name": "JDBC Providers",
        "path": "/@websphere.cell@/JDBC Providers",
        "teamMappings": [],
        "description": "Discovered JDBC Providers",
        "inheritTeam": "true"
    }

When you use the WebSphere Application Server – Configure plug-in, WebSphere Application Server configuration data is stored in JSON format. You can split up the JSON file and add entries to the JSON file by using snippets.

Important: The path to the JSON file must be unique for a configuration objection. For example, an entry for a JDBC provider might looking like this example:

{
        
"path": "/@websphere.cell@/JDBC Providers/myJDBCProvider",
        "teamMappings": [
           
        ],
        "inheritTeam": "true",
        "roleProperties": {
            "websphere.jdbcprovider.providertype": "Derby JDBC Provider (XA)",
            "websphere.jdbcprovider.xa": "true",
            "websphere.jdbcprovider.classpath": "${DERBY_JDBC_DRIVER_PATH}/derby.jar",
            "websphere.jdbcprovider.description": "Built-in Derby JDBC Provider (XA)",
            "websphere.jdbcprovider.name": "Derby JDBC Provider (XA)",
            "websphere.jdbcprovider.isolatedclassloader": "false",
            "websphere.jdbcprovider.implementationclassname": "org.apache.derby.jdbc.EmbeddedXADataSource"
        },
        "name": "Derby JDBC Provider (XA)",
        "roleName": "WebSphereJDBCProvider",
        "description": "Discovered WebSphereJDBCProvider"
    },

When you work with snippets, extract a piece of JSON from an existing config file, and then use it as a template to facilitate adding objects to a configuration. If you create a snippet this way but fail to ensure the path is unique, some configuration objects are ignored. For example, assume that a user wants to add a second JDBC provider to a configuration, which already has a JDBC provider. The user can complete these steps:

  1. Extract a copy of the JDBC provider configuration from the full configuration data. (Let’s say it’s the preceding JDBC provider.)
  2. Change the JDBC provider configuration in some way, but leave the path as it is:
    {
            
    "path": "/@websphere.cell@/JDBC Providers/myJDBCProvider",
            "teamMappings": [
               
            ],
            "inheritTeam": "true",
            "roleProperties": {
                "websphere.jdbcprovider.providertype": "Different TYPE",
                "websphere.jdbcprovider.xa": "true",
                "websphere.jdbcprovider.classpath": "${DERBY_JDBC_DRIVER_PATH}/derby.jar",
                "websphere.jdbcprovider.description": "Built-in Derby JDBC Provider (XA)",
                "websphere.jdbcprovider.name": "Derby JDBC Provider (XA)",
                "websphere.jdbcprovider.isolatedclassloader": "false",
                "websphere.jdbcprovider.implementationclassname": "org.apache.derby.jdbc.EmbeddedXADataSource"
            },
            "name": "New Name",
            "roleName": "WebSphereJDBCProvider",
            "description": "Discovered WebSphereJDBCProvider"
        },
    
  3. Add the snippet to the configuration.
    Result: Apply ignores one of the objects.

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

Permalink