(This page assumes that you've already gotten DCM installed. See the Quick Start page for details on that process.)

DCM, either command line or UrbanCode Deploy (UCD) plugin, can be used in a variety of ways. This flexibility is very useful but it can also increase the effort requires to get DataPower configuration management up and running. The approach described here is straightforward and well suited to most people's needs, either as a complete solution or as a starting point for a more customized solution.

DCM is based on the principle that a particular version of a service can be deployed to a particular environment on a particular appliance.

Each time DCM (ant) is run on the command line, it is targeting a single service in a single environment on a single appliance. Deploying a service to multiple appliances requires multiple command line runs. Plugin steps similarly deal with a single service+domain+appliance at a time, relying on Resources and Environments to fire each step as needed.

Note that “version” is different, from DCM's perspective, from “service”, “environment”, and “appliance”. Versioning and source control integration is discussed later, but the short explanation is that you'll take care of it while setting up DCM.

• I recommend that you follow this narrative for setting up DCM to be used from the command line and do this work yourself. If you are targeting the plugin then don't worry about wasted effort since almost all of this work carries directly over to using the plugin. In addition, you'll have the ability to use the command line when should the need arise.

• Install DCM to operate from the command line before proceeding. (See the Quick Start.)

1. The backend URL (e.g. protocol, hostname, port, URI) for a web service proxy based on the target environment.

2. The key/cert used for identification credential may vary based on target environment and appliance.

3. The members of a load balancer group may vary based on the target environment.

4. Host aliases may vary based on the appliance.

The environment (e.g. dev, SIT, prod) and appliance (eg. dp01, dp02) values show up frequently as part of filenames and sometimes within XML configuration files. In fact, laying out the directories and file names is one of the decisions to be made and is discussed later.

Easy start is based on these design decisions:

• Each DataPower appliance is an individual device and its configuration is managed separately from all other appliances. It is easy to deploy the same configuration to two or more appliances and so keep them in sync with each other.

• An orderly process of promotion of services from development, through various testing environments, and finally into production.

• Services are managed independently of one another even when they are closely related.

• Files are managed separately (with a handful of exceptions) from service exports.

• Versioning of services and files is important and is handled by one or more source control systems.

• Promotion happens by deploying a “golden” copy of a service and files from source control into each target environment/appliance – there is no copying of services or files from one environment to the next.

Your particular requirements may not fit exactly into this pattern but this is a good place to start.

The first step is define the appliances and environments. In this example we'll use the appliances hosting these environments:

• dp01 – hosts dev, SIT
• dpUAT1, dpUAT2 – hosts UAT (also functions as preprod)
• dpProd1, dpProd2 – production DataPower appliances

It is clear, then that we have these four environments:

• dev
• sit
• uat
• prod

We have five appliances to manage:

• dp01
• dpUAT1
• dpUAT2
• dpProd1
• dpProd2

This is the service we'll deploy:

• ucdDemo – listens on some port via SSL and passes the request to backend(s) via a load balancer group

The directory that contains all the ucdDemo assets looks like this (scc is the root directory that is under source code control):

scc/ucdDemo/files/
scc/ucdDemo/crypto/
scc/ucdDemo/ucdDemo.zip      (export file)

(I considered creating a subdirectory names “exports” and placing ucdDemo.zip in there, but since there will only be one export file and it will be named ucdDemo.zip, I decided to leave it as an immediate child of scc/ucdDemo/. Other than this exception, the scc/ucdDemo/ directory is dedicated to organizing the deployment of the service, not to the files and objects that compose the service itself. This is an important but subtle distinction.)

DCM is based on Ant so we'll use a lot of properties. Here are some property files for the appliances and environments:

scc/device.dp01.properties
scc/device.dpUAT1.properties
scc/device.dpUAT2.properties
scc/device.dpProd1.properties
scc/device.dpProd2.properties

scc/env.dev.properties
scc/env.sit.properties
scc/env.uat.properties
scc/env.prod.properties

(Note that filenames contain the same strings that we defined earlier for the environments and appliance ids.)

So now we have a straightforward file structure that nicely fits with Ant properties:

1. Given a property “service.name” then scc/${service.name} references the service directory (e.g. scc/ucdDemo)

2. Given a property “device” then device.${device}.properties references the correct property file for that appliance

3. Given a property “environment” then env.${environment}.properties references the correct property file for that target environment

So three properties are required to deploy a particular version of a service to a particular environment on a particular appliance. That sentence mentions four properties but only three of them are discussed in the preceding text. The missing property is the version of the service/files to deploy, which is related to the source code control system. DCM doesn't attempt to integrate directly with the source control system because Ant and UCD both do an excellent job of that. We'll come back to the source control integration in a moment.

(Many people are fortunate to have all their DataPower assets under a single source control system. Others, however, have their assets spread across multiple source control systems. For example, development and testing are associated with one source control system while another source control system drives production. I wish I had some good advice to offer to folks in this position but I don't. Perhaps someone who has to deal with this problem will update the wiki.)

Define the scc/device.*.property files like this:

host=192.168.13.10  
hostname=192.168.13.10  
port=5550  
uid=dcmadmin  
pwd=passw0rd  

The host and hostname properties are duplicates and reflect the fact that, currently, underlying parts of the DCM code reference both properties in different places.

The port is the XML Management Interface port.

The userid is some DataPower userid with sufficient permissions to do configuration management. The password is optional and should not be supplied in the properties file for environments where security is important (e.g. prod). DCM on the command line will prompt the console for the password if it is not supplied. (UrbanCode Deploy handles the password problem entirely differently than the DCM command line. This is one of the few places where the command line and the plugin are noticeably different.)

Next define the scc/env.*.property files like this:

domain=SIT

This simple naming scheme for domains just uses the environment name, in upper case, as the name of the target domain. This is one of the areas that varies widely across DataPower customers. For now, lets stick with this simple approach.

We now have enough set up so that we can deploy a service, though without making any changes to it during the import process. It is possible to do a deployment right now, running “ant -f deploy.ant.xml” with some properties, but it will be easier in the long run if we first set up a custom Ant build file that will be used to launch all deployments in the future. Copy the easyStart.ant.xml file to some name that you like, and then open it in an editor.

Begin with the critical changes required for the build file to work at all:

Ensure this line points to the correct directory:

<property name="dcm.dir" location="/home/me/dcm"/>  

Modify this line to reflect the dcm.version that you specified when you built DCM:

<property name="dcm.jar" location="${dcm.dir}/dist/dcm.1.jar"/>  

These “cosmetic” changes are not required but will make the output of the build file slightly more meaningful.

Modify name="easyStart" on this line to reflect the name that you have given the build file:

<project name="easyStart" default="help" xmlns:props="antlib:ibm">  

Modify this line to give an example that is more meaningful to you:

<fail message="The 'device' property is required (e.g. dp01)" unless="device"/>  

Modify the “help” target at the bottom of the build file to reflect suitable information about your appliances, environments, and such.

Now we're ready to try a deployment. Given that the current directory is “scc”, this should deploy service ucdDemo to domain UAT on dp01:

ant -f easyStart.ant.xml -Ddevice=dp01 -Denvironment=uat -Dservice=ucdDemo domain-create import-changed save  

The “UAT” domain (see env.uat.properties) was created on dp01, the ucdDemo service was imported into that domain, and the modified domain configuration was saved.

Note the pattern in that command line:

• Specify the easyStart.ant.xml build file (whatever you renamed it to)
• Set up a bunch of properties
• Specify the “build targets”, which are executed in order

All invocations of the build file follow the same pattern. This is true as well for the plugin, which is Groovy code that builds the same kind Ant command line, based on the values supplied by UCD, and executes it.

The DataPower import operation pulls in the contents of a DataPower export (.zip) file, importing objects and/or files into the specified domain. The operation was enhanced several years ago to include a deployment policy object, which is a set of rules that specify changes to be made while importing. Roughly, a deployment policy object can do these kinds of things:

• Exclude certain objects or files from being imported
• Include specific objects or files for import
• Change existing properties of objects
• Add properties to objects when they are not already present
• Delete properties from objects

Deployment policy objects have one limitation: they are unable to deal with properties that may occur a variable number of times. One example are load balancer group members and another are validation credential certificates. That limitation aside, deployment policies are quite useful.

Importing an export while applying a deployment policy object is simple. The import-dpo target requires two Ant properties:

• import.file – the full path of the export file to import
• deployment.policy.object – the name of the deployment policy object contained in the export

(The potentially inconvenient aspect is that the deployment policy object must already exist in the domain when the import begins.)

Define these two properties in scc/ucdDemo/ucdDemo.properties, then imagine executing this command line:

ant -f yourEasyStart.ant.xml -Ddevice=dp01 -Denvironment=sit -Dservice=ucdDemo import-dpo  

This command won't actually work because there aren't any deployment policy objects defined for this example. Instead, we're going to illustrate the alternative method of defining deployment policy object in a DCM definition file.

The main DCM build file is deploy.ant.xml which provides many targets (e.g. domain-create, save). These targets are driven entirely by Ant properties. A small subset of these targets are named *-from-def (e.g. import-from-def, idcred-from-def) and these are driven by a combination of properties and DCM definition files. Here is an example DCM definition file suitable for use with import-from-def:

<dcm:definition xmlns:dcm="urn:datapower:configuration:manager">  

  <dcm:deployment-policy environment="dev">  
    <modify-property name="ucdDemo-https" prop-name="LocalAddress" new-prop-value="192.168.13.79"/>  
  </dcm:deployment-policy>  

  <dcm:deployment-policy environment="sit">  
    <modify-property name="ucdDemo-https" prop-name="LocalAddress" new-prop-value="192.168.13.71"/>  
  </dcm:deployment-policy>  

  <dcm:deployment-policy environment="uat">  
    <modify-property name="ucdDemo-https" prop-name="LocalAddress" new-prop-value="192.168.13.72"/>  
  </dcm:deployment-policy>  

  <dcm:deployment-policy environment="prod">  
    <modify-property name="ucdDemo-https" prop-name="LocalAddress" new-prop-value="192.168.13.74"/>  
  </dcm:deployment-policy>  
  
</dcm:definition>  

This definition file modifies the HTTPS front side handler “ucdDemo-https” to listen on an environment-specific IP address. Deployment policies are applied during import operations (and that is the only time that they are applied).

Note that the scc/ucdDemo/ucdDemo.properties file has been updated to this:

import.file=${user.dir}/ucdDemo.v1.zip
import.changes.file=${user.dir}/ucdDemo.dcm.xml

Here is the Ant command line for importing using the definition file:

ant -f yourEasyStart.ant.xml -Ddevice=dp01 -Denvironment=sit -Dservice=ucdDemo import-from-def

The import-from-def target will convert the <dcm:deployment-policy environment="sit"> elements to actual deployment policy objects that are applied to the ucdDemo service as it is being imported.

The ucdDemo service also relies on additional environment-specific configuration for:

• ID credentials for identifying itself when accepting new HTTPS connections
• Validation credentials for determining whether an HTTPS client or server is trusted
• Load balancer groups to work with multiple backend systems

The idcred objects are defined in scc/ucdDemo/ucdDemo.idcred.dcm.xml:

<dcm:definition xmlns:dcm="urn:datapower:configuration:manager">

  <dcm:idcred environment="dev" name="ucdDemo-frontside">
    <dcm:key file="${crypto.dir}\ucdDemoDev-privkey.pem"/>
    <dcm:certificate file="${crypto.dir}\ucdDemoDev-sscert.pem"/>
  </dcm:idcred>

  <dcm:idcred environment="sit" name="ucdDemo-frontside">
    <dcm:key file="${crypto.dir}\ucdDemoSIT-privkey.pem"/>
    <dcm:certificate file="${crypto.dir}\ucdDemoSIT-sscert.pem"/>
  </dcm:idcred>

  <dcm:idcred environment="uat" name="ucdDemo-frontside">
    <dcm:key file="${crypto.dir}\ucdDemoUAT-privkey.pem"/>
    <dcm:certificate file="${crypto.dir}\ucdDemoUAT-sscert.pem"/>
  </dcm:idcred>

  <dcm:idcred environment="prod" name="ucdDemo-frontside">
    <dcm:key file="${crypto.dir}\ucdDemoProd-privkey.pem"/>
    <dcm:certificate file="${crypto.dir}\ucdDemoProd-sscert.pem"/>
  </dcm:idcred>

</dcm:definition>

The valcred objects are defined in scc/ucdDemo/ucdDemo.valcred.dcm.xml:

<dcm:definition xmlns:dcm="urn:datapower:configuration:manager">

  <dcm:valcred environment="dev" name="ucdDemo-backends">
    <dcm:certificate file="${crypto.dir}\ResponderDev-sscert.pem"/>
  </dcm:valcred>

  <dcm:valcred environment="sit" name="ucdDemo-backends">
    <dcm:certificate file="${crypto.dir}\ResponderSIT-sscert.pem"/>
  </dcm:valcred>

  <dcm:valcred environment="uat" name="ucdDemo-backends">
    <dcm:certificate file="${crypto.dir}\ResponderUAT1-sscert.pem"/>
    <dcm:certificate file="${crypto.dir}\ResponderUAT2-sscert.pem"/>
  </dcm:valcred>

  <dcm:valcred environment="prod" name="ucdDemo-backends">
    <dcm:certificate file="${crypto.dir}\ResponderProd1-sscert.pem"/>
    <dcm:certificate file="${crypto.dir}\ResponderProd2-sscert.pem"/>
  </dcm:valcred>

</dcm:definition>

The load balancer group objects are defined in scc/ucdDemo/ucdDemo.lbg.dcm.xml:

<dcm:definition xmlns:dcm="urn:datapower:configuration:manager">

  <dcm:loadbalancergroup environment="dev" name="ucdDemo-backends">
    <dcm:member server="192.168.13.89" port="443" enabled="true"/>
  </dcm:loadbalancergroup>

  <dcm:loadbalancergroup environment="sit" name="ucdDemo-backends">
    <dcm:member server="192.168.13.81" port="443" enabled="true"/>
  </dcm:loadbalancergroup>

  <dcm:loadbalancergroup environment="uat" name="ucdDemo-backends">
    <dcm:member server="192.168.13.82" port="443" enabled="true"/>
    <dcm:member server="192.168.13.83" port="443" enabled="true"/>
  </dcm:loadbalancergroup>

  <dcm:loadbalancergroup environment="prod" name="ucdDemo-backends">
    <dcm:member server="192.168.13.84" port="443" enabled="true"/>
    <dcm:member server="192.168.13.85" port="443" enabled="true"/>
  </dcm:loadbalancergroup>

</dcm:definition>

Note that these files could be combined into a single XML file since the various *-from-def targets ignore any dcm:\* elements that aren't relevant to that particular target. Different people prefer to organize definition files differently:

• One definition file covering all environments and deploy.ant.xml targets (e.g. scc/ucdDemo/ucdDemo.dcm.xml)
• Definition file per environment (e.g. scc/ucdDemo/ucdDemo.${environment}.dcm.xml)
• Multiple definitions files per deploy.ant.xml target (shown in this example)

Continuing with the example, the scc/ucdDemo/ucdDemo.properties file has been updated to this:

import.file=${user.dir}/ucdDemo.zip  
import.changes.file=${user.dir}/ucdDemo/ucdDemo.dcm.xml  
idcred.file=${user.dir}/ucdDemo/ucdDemo.idcred.dcm.xml  
lbg.file=${user.dir}/ucdDemo/ucdDemo.lbg.dcm.xml  
valcred.file=${user.dir}/ucdDemo/ucdDemo.valcred.dcm.xml  

Here is the Ant command line for importing using the definition file:

ant -f yourEasyStart.ant.xml -Ddevice=dp01 -Denvironment=sit -Dservice=ucdDemo domain-create import-from-def idcred-from-def load-balancer-group-from-def valcred-from-def save  

As above, the import-from-def target imports the ucdDemo service based on the deployment policies specified in scc/ucdDemo/ucdDemo.dcm.xml. Following the import, the idcred-from-def, load-balancer-group-from-def, and valcred-from-def targets are executed in order. These targets upload the correct key and certificate files from the ${crypto.dir} directory, then create (or overwrite) the necessary DataPower objects to fix up the necessary idcred, valcred, and load balancer objects.

The ucdDemo service contains idcred, valcred, and load balancer group objects so these targets are overwriting them. Note that the service export includes dummy key and certificate files and that these files, and their matching crypto objects, are not deleted during this processing. The dummy files and objects should be deleted as a matter of proper housekeeping but it would just clutter the example and so it not done.

Fetching files from your source control system prior to deployment is done at this point in the build file that you derived from easyStart.ant.xml:

<!-- 
  Pull the required code from source control.
-->
<!-- ***************************************************************** -->

Most source control systems support Ant tasks directly, or via the <exec> task to run commands from a command line. Begin with a <fail> that checks for the required “version” property:

<fail message="The 'version' property is required" unless="version"/>

Alternatively, if you are willing to use a default version, simply define the default instead of failing:

<property name="version" value="HEAD"/>  

The next line in the build file will be the line that actually fetches the correct assets from source code control into the current directory.

SVN is accessible at http://192.168.13.1/repos in this example. The “easystart” project has already been added to SVN based on easystart.example.zip file. Near the top of your derivative of the easyStart.ant.xml file add these property definitions, or add them to a property file if you prefer since the effect is the same:

<property name="svn.url" value="http://192.168.13.1/repos/easystart"/>
<property name="svn.uid" value="someSvnUser"/>
<property name="svn.pwd" value="passw0rd"/>

Replace the source control placeholder:

<!-- 
  Pull the required code from source control.
-->
<!-- ***************************************************************** -->

with:

<!-- 
  Pull from SVN into the current directory.  SVN is executed from the command line
  rather than fiddling around with the svnant project, which seems to have some
  trouble keeping up with the latest version of SVN.
-->
<if>
  <and>
    <isset property="version"/>
    <not>
      <equals arg1="${version}" arg2=""/>
    </not>
  </and>
  <then>
    <!-- Fetch the specified version of the service. -->
    <exec executable="svn" dir="${user.dir}" failonerror="true">
      <arg value="co"/>
      <arg value="--username"/>
      <arg value="${svn.uid}"/>
      <arg value="--password"/>
      <arg value="${svn.pwd}"/>
      <arg value="${svn.url}/${service}?r=${version}"/>
    </exec>
  </then>
  <else>
    <!-- Fetch the HEAD revision of the service. -->
    <exec executable="svn" dir="${user.dir}" failonerror="true">
      <arg value="co"/>
      <arg value="--username"/>
      <arg value="${svn.uid}"/>
      <arg value="--password"/>
      <arg value="${svn.pwd}"/>
      <arg value="${svn.url}/${service}"/>
    </exec>
  </else>
</if>

If the “version” property is specified then that particular revision fetched from SVN, otherwise the head revision is fetched. The remainder of the Ant processing continues as expected from this point forward.

(One thing that I haven't worked out yet is how to check out mine.ant.xml and the device.*.xml and env.*.xml files. At this point I just do that process manually, which is not ideal.)

The build file that was derived from easyStart.ant.xml, the env.*.properties files, and the device.*.properties files are not used with the plugin, since the plugin itself provides those same capabilities. Everything else that you set up in the previous sections migrates directly from the command line to the plugin. In fact, the values in the env.*.properties and device.*.properties files will be copied into UrbanCode Deploy.

Prerequisites:

• UrbanCode Deploy server has been successfully installed
• UrbanCode Deploy agent has also been successfully installed
• UrbanCode Deploy DataPower plugin has been built and installed (see Settings → Automation Plugins in the UCD browser interface)

This section details how to set up a UCD configuration that can be deployed to several environments (dev, sit, uat, prod), targeting two DataPower appliances (appliance1 and appliance2). This example uses a single UCD agent (DPAgent). This is intended simply as an illustration of a pattern to be adjusted to suit your requirements.

UrbanCode Deploy is a very powerful deployment platform that can deal with a wide variety of source control systems and target systems. The example in this section uses UCD in only the most rudimentary manner.

If you aren't familiar with UCD, as I wasn't when I began this project, I can share a few things that I learned. (If you are already familiar with UCD's organizing principles then just jump to the next section.)

At a very high level, UCD allows you to specify what sorts of things should be deployed, where they should be deployed to, and under what particular conditions. It uses a database of some sort to track the history of deployments, as well as to store all the information regarding what to deploy, etc.

UCD seems to follow a general pattern that Components represent things like DataPower services, web server applications, databases, and so on. Applications layered on top of Components, combining Components into, well, applications. For example, a line-of-business application may be composed of a DataPower web service proxy, a web service running on WAS, and a database used by that web service. A UCD Application would combine those three pieces into a single deployment.

Resources are deployment target kinds of things like DataPower appliances and WAS clusters. These can be referenced by multiple Applications.

Environments were a little surprising to me since they are defined locally within an Application rather than globally in the manner that Resources are defined.

Properties show up everywhere in UCD. These properties are used only within the UCD server, they are not implicitly passed to the agent and the DP plugin during a deployment. The only properties that are passed to the agent and DP plugin are those properties defined for that step in the plugin.xml file. (I was quite confused until I came to understand that point, which isn't called out anywhere in the UCD documentation that I've read so far.)

UCD has a ton (metric or imperial, your choice) of features that this example does not explore. I encourage you to explore them in detail.

This example is built bottom-up (lowest level objects, then higher level, then the application) for the simple reason that UCD only allows references to things that already exist. For example, you can't define an application that references a component that doesn't yet exist. This means that while it might feel most natural for you to start with the application and build your way downward, you must plan your work so that you can build the pyramid from the bottom up rather than from the top down.

The UCD server integrates with the UCD agent to do deployments to DataPower. Most UCD deployment targets (e.g. WebSphere Application Server) require a UCD agent on the same system. For example, if you have some number of WAS clusters then you'll have an equivalent number of UCD agents installed on those clusters. DataPower is a little different since it isn't possible to install an agent on a DataPower appliance. Instead, we simply use any existing agent that can access the target appliances across the network. (I run my UCD demonstration in a Windows VM where I have installed both the UCD server and the UCD agent. I use a pair of DataPower VMs as target appliances.)

An agent can be installed either via the command line or via the UCD browser interface (see Resources → Agents → Install New Agent button). Once an agent is installed it will show up the in the list of agents. Its status should be “online”, otherwise investigate and correct the problem.

A Resource in UCD is a deployment target, so create a Resource (see Resources → Resources → Create Top Level Group button) named “appliance1”. Use the “Actions” dropdown to assign the agent (DPAgent) to each of the appliances.

The Resource defines the information (as properties) needed to find and use the target, in this case a DataPower appliance. Click on the “appliance1” link and then the Configuration tab associated with that Resource. (This is not the Global Configuration tab near the top of the browser.) Click on Resource Properties. Use the Add Property button to define these properties:

• dpHostname
• dpPassword
• dpUserid
• dpXMIPort

These are the same values (with different property names) that you collected in device.*.properties. These values will be used automatically by the DataPower plugin steps when we define a Component, in the next section.

Repeat the process by defining “appliance2”.

This completes the foundation for deploying anything to these two appliances.

A UCD component generally describes a single DataPower service. Set up a component for the ucdDemo service:

1. Use the Components → Components → Create New Component button to create the new component object

(Component templates are a good thing to use when you have a bunch of similar services, if you get to that point in applying UCD to DataPower deployments.)

2. Assign a name (e.g. ucdDemo) and description

3. Choose a Source Config Type and fill in the required information

(For this example I used Subversion and pointed it to the same subversion server that I used for the command-line example. I accepted most of the defaults. I also had to install subversion on my Windows VM since the UCD agent runs “svn” from the command line.)

4. Select Import Version Automatically

5. Save the Component object

6. Open the ucdDemo link and move to the Processes tab (NOTE: This is the Processes tab associated with this particular object, not the global Processes tab near the top of the browser.)

7. Use the Create New Process button to create a process named “deployUcdDemo” and save

8. Open the deployUcdDemo link, which automatically brings up the Design tab with prepopulated Start and Finish steps.

This is a drag-and-drop user interface where you can define the steps for the UCD agent to follow while deploying the ucdDemo service. Expand the Step Palette's Infrastructure → WebSphere DataPower and review the set of deployment steps that are available.

9. Drag a Create Domain step from the palette into the process. It will automatically bring up the Edit Properties dialog:

image goes here

Change the name to something that you like and accept the remaining defaults. Note that the ${p:dpDomainName} property will be defined later, as part of the Environment.

10. Drag a Load Balancer Group from Definition into the process, again setting the name to something meaningful. Accept all the default values with this one exception: Definition file. This is the filename where the agent will be able to access scc/ucdDemo/ucdDemo.lbg.dcm.xml.

11. Drag a Save Configuration step into the process and set a meaningful name for the step. The default values are all fine.

Arrange the steps so that they are neatly aligned and “wire” them together. The end result may look something like this:

image goes here

This component process will:

1. Ensure that the target domain exists on the appliance

2. Create the Load Balancer Group

3. Save that updated configuration.

I chose to start with the load balancer group because it is the simplest of the steps, since it only creates one object. The crypto valcred and idcred steps that we will add later are more complex because they upload files in addition to creating several objects, and the import operation (that we'll add after those steps are working) is the most complex step in the process.

Save the entire process by clicking on the little floppy disk icon in the Tools palette.

Before we leave the component process there is one thing worth seeing. Edit the Create Domain step (click on the little pencil icon) and then click the Show Hidden Properties checkbox. Every step provided by the DataPower plugin has these same hidden properties, which tell the agent how to connect to each DataPower appliance. These properties are defined in the appliance1 and appliance2 Resources.

1. Create the Application (see Applications → Create New Application) and give it a meaningful name (e.g. ucdDemo). The browser will automatically click the ucdDemo link for you. Later you can click that link to get to this same page.

2. Use the Create New Environment button to create the “dev” environment, then click on the “dev” link.

3. Click on the Configuration tab for the “dev” Environment (not the global Configuration tab near the top of the browser), then click on Environment Properties. Use the Add Property button to define the “dpDomainName” property (e.g. ucdDemoDev). This is the name of the domain on the target appliance(s) for the domain.

4. Switch back to the Resources tab for the Environment and use the Add Base Resources button to begin adding appliance1 to the “dev” environment. Click the checkbox for appliance1 and its subordinate DPAgent and then click OK.

5. Repeat this process for the sit, uat, and prod environments. In my example, I assigned appliance1 to dev and sit, and both appliance1 and appliance2 to uat and prod.

6. Return to the main page for the Application (the title is “Application: ucdDemo” and the breadcrumb trail above the title is Home > Applications > ucdDemo).

7. Click on the Components tab for the Application and click on the Add Component button.

8. Add the ucdDemo component to the Application. UCD requires that you explicitly define which Components may be referenced by a particular Application. This avoids an Application inadvertently referencing a Component that should not be referenced by that Application.

9. Click on the Processes tab for the Application and use the Create New Application button to create an application named deployUcdDemo. Accept all the defaults and press Save.

10. Click the deployUcdDemo link. This brings up a process editing tab similar to the Component Process tab. Note that the Step Palette is very different from the one presented in the Component Process tab.

11. Drag an Install Component step into the process, give it a meaningful name, and choose the ucdDemo Component and the deployUcdDemo Component Process.

12. Wire the Start, Install Component, and Finish steps together and Save the Process.

UCD requires that each component be explicitly declared is being deployed by each Resource.

1. Go to the global Resources tab and expand appliance1

2. Click the link for the agent (e.g. DPAgent)

3. Choose Create New … Component

4. Select the component to deploy (e.g. ucdDemo) and Save

(When I forget to do this part of the process I'm always puzzled because when I deploy the application the status is “not mapped”.)

fix this

1. Return to the main page for the ucdDemo Application (see step 6 in previous section).

2. Press the “play” button associated with the dev environment.

3. Uncheck the Only Changed Versions checkbox, since we want to deploy regardless of whether the underlying ucdDemo service has been changed

4. Choose the deployUcdDemo process in the Process dropdown then choose Submit.