Using custom properties when deploying WebSphere configurations and applications

Use custom properties on a component to differentiate configurations between environments.

Before you begin

Set up and deploy WebSphere configurations and applications without custom properties. Examine the deployment to determine where you need to differentiate deployment environments.

About this task

Typically multiple environments are used in a staged software development process. The environments are segregated, for example into Development, Test, and Production areas. Code is promoted from one area to the next after exit criteria are met.

Configuration data for a deployed WebSphere instance may need to vary according to the environment where it is deployed. For example, a different database may be used for backing a JDBC resource in each environment. Defining custom properties allows you to customize deployment into each environment.

You define custom properties on the component you create for the deployment. When you generate the template, the custom properties are scanned and tokens are created in the configuration template. The tokens are substituted with values from the environment during deployment.

Property values can be either an explicit value or an XPath expression. You typically use XPath if the value could be confused with another value or part of a value if you used a simple value. For example, specifying 80 (HTTP port) could be confused with another value (9080) and result in an incorrect token. Note that only some XPath functionality is available for this purpose.

Procedure

  1. Click Components.
  2. Click on the component, then the Configuration tab, then Enviroment Property Definitions.
  3. Add custom tokens prefixed with websphere. You can assign values directly (using key-value pairs) or you can use an XPath expression. You can also add default values to be substituted for the tokens during the configuration process for the environment.
    Note: These properties should be for values in your configuration that you know need to be different between your different websphere cells.
    1. Add properties using key-value pairs. These properties are ones that can use an explicit, unambiguous value. See Using XPath to specify property values for a full example in the context of IBM UrbanCode Deploy.

      For example, the database port may be different for your development and production environment. In this case you would create a property with the following name:

      websphere.dbport.value=50000

      The string 50000 is extracted from the configuration when it is read. It is replaced with the token @dbport@. The token is later replaced during deployment with the value for the environment where you are applying the configuration data.

    2. Add properties that require an XPath expression for a value.

      For example, the following XPath expression locates and updates a value in the jdbc.xml data file. It looks for a DataSource with the name widgetDB and updates the J2EEResourceProperty attribute to 50000 where the name attribute is portNumber.

      websphere.dbport.xpath=//DataSource[@name='widgetDB']/J2EEResourcePropertySet/J2EEResourceProperty
          [@name='portNumber']/@value

      Why use XPath?

      The token creation process uses a simple string substitution method. In some cases tokens can be created incorrectly because one property is represented as a property that is itself a substring of another property.

      A common case for this is in defining multiple HTTP ports within a configuration. The following custom property could be encountered during configuration.

      port='80'

      The property is converted into the token @port@.

      However, if another assignment to the port is encountered during configuration, the token is formed improperly. The following custom property could be encountered.

      port='9080'

      When it is scanned, the previous token creation causes an incorrect token to be created: 90@port@.


Feedback