BPEL Deployment Framework

One of the coolest features in BPEL 10.1.3.4 is the deployment framework which makes the job of moving processes between dev, test and production environments much easier.  Modifying the bpel.xml file or altering descriptors through the console provide a degree of customisation for different environments, but it is all done on a single property at a time basis and requires a lot of work for each environment, especially when it is considered that individual WSDL files may also need to be updated. There is a better way in SOA Suite 10.1.3.4; the deployment framework.

The deployment framework combines the BPEL suitcase with a deployment plan that updates multiple files in the BPEL suitcase with the correct values for the deployment environment. Different deployment plans can be created and maintained for each deployment plan.

It is possible to generate a template BPEL deployment plan from a BPEL suitcase which can then be customised and used with the base BPEL suitcase at deployment time to update the various URLs and properties.

The steps to customise the BPEL Suitcase for each environment are as follows.

• Create a deployment template from the BPEL project or suitcase which will be used as the basis for the deployment plans.
• Create a deployment plan based on the template for each target environment.
• Attach the appropriate deployment plan to the BPEL suitcase or project prior to deploying in the target environment.
• Deploy the BPEL process into the target environment.

Creating a Deployment Plan Template

To create a deployment template we need to add the following commands to the build.xml ant file that is built by JDeveloper and found in the Resources folder of our BPEL project.

<target name="generate_plan_from_project">
  <generateplan planfile="${process.dir}/planfile.xml"
                verbose="true"
                overwrite="true"
                descfile="${process.dir}/bpel/bpel.xml"/>
</target>
<target name="generate_plan_from_suitcase">
  <generateplan planfile="${process.dir}/planfile.xml"
                verbose="true"
                overwrite="true"
                suitecase="${process.dir}/output/bpel_${BPELSuitcase.BPELProcess(id)}_${rev}.jar"/>
</target>

This creates two new ant targets, generate_plan_from_project and generate_plan_from_suitcase. These both create a template deployment plan, either directly from the project files, or from a generated suitcase. A BPEL suitcase is only generated when a BPEL project is deployed or when the project is “made”, so if using the option to generate from a suitcase it is necessary to ensure that the suitcase has previously been created. If the suitcase generated is a revision other than 1.0 then it is necessary to set the revision property in the build.properties file that is found in the Resources folder of the BPEL project in JDeveloper.

# Change below if deploying with process revision other than 1.0
rev = 1.1

The generateplan command in ant uses four attributes

• suitecase or descfile is the source information for the deployment plan.



• planfile is the location of the planfile template to be generated.



• overwrite will replace any existing planfile of the same name.



• verbose turns up the level of reporting.

A sample deployment plan template is shown below. Note the use of two elements:

• <replace> is used to replace the value of a property within a specific part of the bpel.xml



• <searchReplace> is used to <search> for a string in WSDL and XSD files and <replace> it with another string.

<?xml version="1.0" encoding="UTF-8"?>
<BPELDeploymentPlan xmlns="http://schemas.oracle.com/bpel/deployplan">
  <BPELProcess id="SimpleFileProcess">
    <configurations/>
    <partnerLinkBindings>
      <partnerLinkBinding name="ReadNewCustomerFileService">
        <property name="wsdlLocation">
          <replace>ReadNewCustomerFileService.wsdl</replace>
        </property>
      </partnerLinkBinding>
      <partnerLinkBinding name="WriteNewCustomerDBService">
        <property name="retryInterval">
          <replace>60</replace>
        </property>
        <property name="wsdlLocation">
          <replace>WriteNewCustomerDBService.wsdl</replace>
        </property>
      </partnerLinkBinding>
      <partnerLinkBinding name="CardValidatorService">
        <property name="wsdlLocation">
          <replace>CardValidatorService.wsdl</replace>
        </property>
        <property name="location">
          <replace>http://w2k3/chapter18/CardValidatorServiceSoapHttpPort</replace>
        </property>
      </partnerLinkBinding>
    </partnerLinkBindings>
  </BPELProcess>
  <wsdlAndSchema name="CardValidatorService.wsdl|DBAdapterOutboundHeader.wsdl|fileAdapterInboundHeader.wsdl|NewCustomerFile.xsd|ReadNewCustomerFileService.wsdl|WriteNewCustomerDBService.wsdl|WriteNewCustomerDBService_table.xsd">
    <searchReplace>
      <search/>
      <replace/>
    </searchReplace>
  </wsdlAndSchema>
</BPELDeploymentPlan>

Creating a Deployment Plan

Having created a template we can use this to create deployment plans for each specific environment. We do this by creating a copy of the deployment plan by selecting Save As from the file menu in JDeveloper and then editing the <search> and <searchReplace> tags to match our target environment.

We will search and replace all instances of our local development machine hostname, w2k3, with the name of our test server, testserver, across wsdl and xsd files. To do this we modify the search and replace elements as shown below.

<wsdlAndSchema name="*">
  <searchReplace>
    <search>w2k3</search>
    <replace>testserver</replace>
  </searchReplace>
</wsdlAndSchema>

This will cause the BPEL process manager to search all WSDL and schema files “*” in the suitcase at deployment time and replace the string “w2k3” with the string “testserver”. Note that it is possible to have multiple <searchReplace> elements.

Attaching a Deployment Plan to a BPEL Suitcase

Having created and saved a deployment plan specific for one or more specific environments we will want to deploy our process into an environment. Before doing this we must first attach the specific deployment plan to the BPEL suitcase. We do this using the following ant command.

<target name="attach_plan">
  <attachplan planfile="${planfile}" verbose="true"
               overwrite="true"
               suitecase="${process.dir}/output/bpel_${BPELSuitcase.BPELProcess(id)}_${rev}.jar"/>
</target>

This will create a file bpeldeployplan.xml in the BPEL suitcase. This is the deployment plan that will be used at deployment time by the BPEL process manager. Note that the name of the deployment plan to use is encoded as an Ant property planfile that must be set in the build.xml. Once attached the deployment plan will be executed when the BPEL suitcase is deployed.

Modifying Ant to Use Deployment Plan

In addition to adding the two tasks above to the build.xml file, it is possible to add the attachment of the plan file as part of the regular deploy process by modifying the dependencies of the process-deploy task by adding the attach_plan dependency after the compile dependency.

<target name="process-deploy"
          depends="validateTask, compile, attach_plan, deployProcess,
deployTaskForm, deployDecisionServices" />

Now when building and deploying with ant the deployment plan will be attached to the suitcase before the suitcase is deployed to the target environment. This allows us to provide a different deployment plan for each environment, which can then be deployed from the command line in a reproducible fashion.

Summary

The deployment plans allow a lot of automation in the move from development to production, and because they can be used with editable files and command lines they are easy to include in the version control systems and automated build environments.  Congratulations to the BPEL developers on a useful piece of functionality that appeals to those responsible for ensuring consistency of environments rather than developers.