Thursday, September 27, 2007

Using custom headers in BPEL

Sending messages to a BPEL process mostly done via the web service interface. In general the message is packed in a SOAP envelope in the body part. The header part of the SOAP envelope id not touch. This is mostly done automatically between the client and web service.

Sometimes you need information to send or retrieve information to the BPEL process that is not part of the message. This information is mostly technical and not functional related to the message in the SOAP body. In these cases you could manipulate the SOAP header to add your own message.

The next example describes a solution of retrieving headers from the SOAP request. The example is very simple it just an 'HelloWorld' application that reads the SOAP header. If the custom header exists it returns it, otherwise it does not. The BPEL process is show as follows:

Now this is simple. The trick is in the WSDL specification and the 'receive' step in the BPEL process. A few changes have been made in the default WSDL (after you create a default async BPEL process in jDeveloper).

The WSDL is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="HelloHeader"
<schema xmlns="">
<import namespace=""
<import namespace=""
<!-- SOAP HEADER -->
<message name="RelatesToHeader">
<part name="RelatesTo" element="wsa:RelatesTo"/>
<message name="MessageIDHeader">
<part name="MessageID" element="wsa:MessageID"/>
<message name="ReplyToHeader">
<part name="ReplyTo" element="wsa:ReplyTo"/>
<message name="CustomHeader">
<part name="CustomHeader" element="client:HelloHeaderHeaderMessage"/>
<message name="HelloHeaderRequestMessage">
<part name="payload" element="client:HelloHeaderProcessRequest"/>
<message name="HelloHeaderResponseMessage">
<part name="payload" element="client:HelloHeaderProcessResponse"/>
<portType name="HelloHeader">
<operation name="initiate">
<input message="client:HelloHeaderRequestMessage"/>
<portType name="HelloHeaderCallback">
<operation name="onResult">
<input message="client:HelloHeaderResponseMessage"/>
<binding name="HelloHeaderBinding"
<soap:binding style="document"
<operation name="initiate">
<soap:operation style="document" soapAction="initiate"/>
<soap:header message="client:MessageIDHeader"
part="MessageID" use="literal"/>
<soap:header message="client:ReplyToHeader"
part="ReplyTo" use="literal"/>
<soap:header message="client:CustomHeader"
part="CustomHeader" use="literal"/>
<soap:body use="literal"/>
<binding name="HelloHeaderCallbackBinding"
<soap:binding style="document"
<operation name="onResult">
<soap:operation soapAction="onResult" style="document"/>
<soap:header message="client:RelatesToHeader"
part="RelatesTo" use="literal" required="false"/>
<soap:body use="literal"/>

<plnk:partnerLinkType name="HelloHeader">
<plnk:role name="HelloHeaderProvider">
<plnk:portType name="client:HelloHeader"/>
<plnk:role name="HelloHeaderRequester">
<plnk:portType name="client:HelloHeaderCallback"/>

In the WSDL we overwrite the binding of the web service. Here we specify the custom header. We should not forget to use the normal headers as MessageId and ReplyTo.

Note: In the XSD-file we added a message":
 <element name="
<element name="message" type="string">

Now the message and the WSDL are correct we could change the BPEL file to add the code to read the SOAP Header. In the variable declaration add:

<variable name="customHeader"
<variable name="messageID"
<variable name="replyTo"

Now change the receive task to add the "bpelx:headerVariable" statement.

<receive name="receiveInput"
bpelx:headerVariable="customHeader messageID replyTo"

After the receice step the headers, if the exist, are put into the variables. Now you could use normal assign/copy tasks to use this data.

You can download the example code here.

To test the BPEL process, use a tool as (open source). Here is a SOAP request with a custom header:

<hel:message>This is the custom header</hel:message>
<hel:input>Hello World</hel:input>

Tuesday, September 18, 2007

Compile error BPEL against SSL

If you compile a BPEL proces that is using partner links based on SSL. You run into an compile error:

ValidatorException: PKIX path building failed

This can be solved by importing the certificate form the server into your local key store. This is the keystore from which JDeveloper is started.

Make sure that you apply this also on the SOA Suite server. The BPEL process is deployed and compiled again on the server.

cd [jdevhome]\jdk\jre\lib\security
..\..\bin\keytool.exe -import -file "Vijfhuizen.cer"
-keystore cacerts -storepass changeit -alias myRootCA

Owner: O=Vijfhuizen, C=Issuer: O=Vijfhuizen, C=com
Serial number: 1
Valid from: Mon Sep 21 08:00:00 CET 2007
until: Thu Feb 28 20:00:34 CET 2012
Certificate fingerprints:
Trust this certificate? [no]: yes
Certificate was added to keystore

Tuesday, September 11, 2007

Cancel workflow / human-task

Work with human work flow in Oracle SOA Suite is very powerful. Within Oracle BPEL you can create a human task for a particular user or user-group. But as these tasks are assigned to users, the BPEL process is waiting on result. Depending on the task configuration, you could assign time-outs and escalation paths.

From business perspective, you could have a rule that says; reject all open task for a particular user or group. So how do we approach this issue? Oracle Suite has a rich Java API to control the human work flow. In this case you could create a java program that collects information from the work flow engine to cancel the tasks. This java program could be a:
  • A java client.
  • A web application, using the java api.
  • Embedded Java in the BPEL process.
But a closer look in the human task call in the BPEL process, shows another solution. Apart of initiating a human task you could also call various other operations:

The advantage to use BPEL code, you do not need any (embedded) Java API calls to fulfill this function. In our case we could invoke the human work flow via the 'updateTaskOutcome' operation. The are a few restrictions. Before you could set the outcome of an task (REJECT, APPROVED, DENIED, etc.) you must known the TaskID for that particular task and the session token of the task. This information is available in the BPEL process that creates this task. You could store this information in a database table to make it available for the process that wants to set the outcome.

A question was asked, how to obtain the TaskID and the session Token. This is easy. When a human-task is created, after the invoke in the human-task scope, a result is send back to BPEL. In this result you can retrieve information on this task. In our case you could read the TaskId and the Token. Saving this data in a table or file, you can use it by other processes to update the outcome.