DataPower deployment policies allow for “tweaking” device and domain configuration for different environments. Let’s face it, there are always differences between environments. Sometimes, these differences are small, such as different back-end hosts, and in other cases these differences could be significant, such as different security policies.

Deployment policies do a decent job of dealing with differences between environments. Deployment policies support changing, adding and deleting configuration, so it is possible to implement fairly complex transformations.

However, dealing with deployment policies could be confusing. Deployment policy’s match rules utilize xpath, but the syntax of the rules is not pure xpath. Consider this simple deployment policy match rule:


The part before “?” looks like xpath. But what schema is this xpath based on? There is no “protocol” element in the DataPower XML management schema. The part after “?” that uses name-value parameters is even more odd. Why use this instead of proper xpath? After all, DataPower has an XML-processing engine with full xpath support, so it would certainly be more logical to rely on XML standards.

The bottom line is that while deployment policies are useful, they have limitations. They have to be developed using Deployment Policy builder in WebGUI. They can only be applied to configuration elements supported in WebGUI. For example, creating a deployment policy that updates RemoteEndpointPort of a Web Services Proxy proves to be a non-trivial task.

This is why we added support for xpath-based transformations to our DPBuddy DataPower management tool. Instead of dealing with the obscure syntax of DataPower deployment policies, developers can simply look at the configuration export file and specify an xpath expression against this file. It is also possible to specify filters based on the types and names of DataPower objects.

XML transformation is supported by all key DPBuddy tasks, including “import”, “export”, “copy” and “modifyConfig”.

Consider this simple example:

<dp:import file="${}">
        <setText xpath="//LocalPort"  value="${ws.port}" />

This import task automatically extracts “export.xml” from the zip file, applies the transformations, updates the zip file and finally performs the import. You can see the result of the transformation if you run Ant in verbose mode or if you look at the files in DPBuddy’s working directory (which could be configured using “workDir” attribute).

In addition to “setText”, DPBuddy supports “add”, “update”, “delete”, “setText”, “replaceText”, “include” and “exclude” transformation actions. Some actions support Groovy expressions. Bottom line, the transformation actions allow for supporting the most complex differences between environments. They can also be used for transforming any XML file, not just DataPower configuration.

Other benefits of DPBuddy’s XML transformation capabilities include:

  • Supports Ant and Groovy/Gradle variables inside XPath or in XML fragments.
  • Reusable — you can define a reusable group of transformation actions and then reference it from any other group.
  • Can be turned on and off depending on a Boolean expression that can reference any Ant property or Groovy/Gradle variable. For example, a transformation action can be triggered only for certain environments.
  • Easy to debug– transformed files are saved locally and also logged using verbose/debug mode.
  • Can be developed locally without having to connect to a DataPower devices. Both “import” and “copy” tasks support “transformOnly” mode which runs transformations but does not connect to the device.

You can find more details in the DPBuddy User Guide.

If you’re interested in trying XML transformations and in automating your DataPower deployment and administration tasks, download DPBuddy and give it a try. Here you can find various examples of DPBuddy’s tasks, including transformation-related examples.

5 thoughts on “Easy-to-Use Alternative to DataPower Deployment Policies

  1. The example downloaded from the dpbuddy does not contain

    while dp:import i have to provide deployment policy.

    syntax for the XML structure is not present in the example.
    I think i am looking in to the wrong example, can some one guide me. Thanks.

  2. Hi Shariff,
    You’re right, the deployment policy is not there. However, the deployment policy is irrelevant for this example, you can plug in any policy file. Nevertheless, I will update the examples in the next release.
    Also, what “XML structure” are you referring to?
    – Alexander

  3. Hi Alexander,

    I want to

    1. Store encrypted strings of username and password inside the config file

    2. Retrieve them into an XSLT for building in a username-token of a SOAP header.

    Can you help me how I get about doing it (editing the config file). I would deeply appreciate it, if you can guide me step by step to write code inside the config file for this modification.


  4. Hi Satish,
    Could you please elaborate a bit more? Why do you need a username token? XML management does not use WS-Security.

Comments are closed.