Dynamically passing the file name to read adapter

Sync Read option in BPEL file adapter allows us to read the file from the middle of the process, this is different from the Read option which polls for the new files and is the start of the BPEL process.

As we design the file adapter for sync read it asks for the file name whcih is static, this means that only file with this given name will be read. Now suppose if we need to read files having same format but different names. How are we going to do that?

I found this question posted on the oracle forums http://forums.oracle.com/forums/thread.jspa?threadID=935976&start=0&tstart=0 that is when I worked on it and found the solution.

There's a simple way to do this. Whenever we create an adapter a fileAadapterOutboundHeader.wsdl file is created. If we open this file we'll find an inline schema having the fileName element. Below is the fileAadapterOutboundHeader.wsdl file:

<definitions

name="fileAdapter"

targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/file/"

xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/file/"

xmlns="http://schemas.xmlsoap.org/wsdl/" >

<types>

<schema attributeFormDefault="qualified" elementFormDefault="qualified"

targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/file/"

xmlns="http://www.w3.org/2001/XMLSchema"

xmlns:FILEAPP="http://xmlns.oracle.com/pcbpel/adapter/file/">

<element name="OutboundFileHeaderType">

<complexType>

<sequence>

<element name="fileName" type="string"/>

</sequence>

</complexType>

</element>

</schema>

</types>

<!-- Header Message -->

<message name="OutboundHeader_msg">

<part element="tns:OutboundFileHeaderType" name="outboundHeader"/>

</message>

</definitions>

While invoking the adapter we only need to set this fileName element with some dynamic generated value. Below are the steps to do this:

1. Double click the invoke activity which invokes the sync read adapter.


2. Go to adapters tab and click the torch icon.



3. Click on Variables and create a new variable.



4. Give some name like OutboundheaderVariable, choose message type and click the torch.



5. Drill down to fileAadapterOutboundHeader.wsdl > Message Types and select OutboundHeader_msg. Click Ok till you are back in the diagram.



6. Place an assign activity above this invoke and copy the file name to the OutboundHeaderVariable > fileName variable.

That's it.

Now we can give the name of the file at runtime as the input parameter or we can define deployment descriptor to give the file name.

We can also set the input/output directory at runtime which I'll write in my next post.

Using BPEL Variables in Transformations

Sometimes we do require to use the variables in the BPEL process into the xslt transformation but we cannot use bpws:getVariableData() function in the transform activity to fetch the values.

Here is a solution which I learned recently during my project.

The signature of the transform function is as below:

ora:processXSLT('template','input','properties'?).

Generally we only use the first two parameters i.e. template and input which is the name of the transformation file and the input parameter respectively. With the help of third parameter 'properties' we can pass the desired variables from the process to the xslt.

'properties' is an xml element which has name/value pairs. The xml is based on the following schema which we need to import in the BPEL process.

<xml version="1.0" encoding="windows-1252" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:p="http://schemas.oracle.com/service/bpel/common"

xmlns="http://schemas.oracle.com/service/bpel/common"

targetNamespace="http://schemas.oracle.com/service/bpel/common"

elementFormDefault="qualified">

<xsd:element name="parameters">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="name" type="xsd:string"/>

<xsd:element name="value" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Now we can assign the values to the name/value pair and pass the parameters element into the xslt.

The sample xml will look like:

<parameters>

<item>

<name>parameter1</name>

<value>value1<value>

</item>

<item>

<name>parameter2</name>

<value>value2</value>

</item>

<parameters>

Suppose the name of the xsl file is Transformation.xsl and the source variable is source then the transformation function will look as below:

ora:processXSLT('Transformation.xsl', bpws:getVariableData('source'),bpws:getVariableData('parameters'))

To access the passed values in the transformation we have to add xsl:param tag in the xsl file.

Open the xsl in the source view and add the following tag:

<xsl:param name="parameter1"/>

<xsl:param name="parameter2"/>

Now we can access the variables in the transformation by appending the '$' sign before the parameter for eg: $parameter1, $parameter2.

Converting Synchrous BPEL process to Asynchronous BPEL process

This article is about how to convert a synchronous BPEL process to an asynchronous one.

Whenever we create new bpel process three files are created by default viz.

• [processName].bpel
• [processName].wsdl
• bpel.xml

But the difference between the Synchronous and Asynchronous process remains in the .bpel and .wsdl files only.

If we open the .bpel and .wsdl file of both the processes we do not find much difference in the two therefore it's very easy to convert an asynchronous process to synchronous one and vice-versa.

For explaining how to convert the synchronous process to asynchronous one I have created a BPEL process SynchBP. I’ll be converting SynchBP which is a Synchronous BPEL process to an asynchronous one. As earlier said the difference is only in .bpel and .wsdl file so we'll concentrate only on these two files.

For ease of understanding I have used colours in the text so as to highlight what to change and what to add.

So, first start with SynchBP.bpel file.

There are three places where we have to make changes viz. partnerlink, receive, and reply element.

Partnerlink:

This is how the partnerlink element is of a SynchBP:

<partnerLink name="client" partnerLinkType="client:SynchBP" myRole="SynchBPProvider"/>

Add another attribute partnerRole="SynchBPRequester" to this element. The partnerlink will look like this:

<partnerLink name="client" partnerLinkType="client:SynchBP" myRole="SynchBPProvider" partnerRole="SynchBPRequester"/>

Receive Element:

Below is the receive element of SynchBP

<receive name="receiveInput" partnerLink="client" portType="client:SynchBP" operation="process" variable="inputVariable"

createInstance="yes"/>

Change the value of attribute operation from process to initiate. The partnerlink will look like this:

<receive name="receiveInput" partnerLink="client" portType="client:SynchBP" operation="initiate" variable="inputVariable" createInstance="yes"/>

Reply element:

Below is the reply element of SynchBP

<reply name="replyOutput" partnerLink="client" portType="client:SynchBP" operation="process" variable="outputVariable"/>

Do the following changes to make it for asynchronous process:

• Change the element name from reply to invoke.
• Change the name attribute value from replyOutput to callbackClient.
• Change the value of attribute portType from client:SynchBP to client:SynchBPCallback (or simply [processName]Callback ).
• Change operation=”process” to operation=”onResult”.
• Change the name of last attribute i.e. variable to inputvariable.

<invoke name="callbackClient" partnerLink="client" portType="client:SynchBPCallback" operation="onResult" inputVariable="outputVariable"/>

Here we are done with SynchBP.bpel, now we need to edit SynchBP.wsdl.

There are very few changes to be made in the .wsdl file.

The elements that need to be changed are portType and partnerLinkType.

portType:

This is how a portType is defined in a synchronous process:

<portType name="SynchBP">

<operation name="process">

<input message="client:SynchBPRequestMessage" />

<output message="client:SynchBPResponseMessage"/>

</operation>

</portType>

Create another portType element with name SynchronousProcessCallback and operation as onResult. Now delete the output element from both portTypes and in the SynchronousProcessCallback portType, change the attribute value from client:SynchBPRequestMessage to client:SynchBPResponseMessage. (Help: Copy & paste the already defined portType and do as below)

<portType name="SynchBP">

<operation name="initiate">

<input message="client:SynchBPRequestMessage" />

<output message="client:SynchBPResponseMessage"/> ……Remove this

</operation>

</portType>

<portType name="SynchBPCallback">

<operation name="onResult">

<input message="client:SynchBPRequestMessage"/>……. Remove this

<input message="client:SynchBPResponseMessage"/>

</operation>

</portType>

partnerLinkType:

This is how partnerlink information is provided in a wsdl of a synchronous process:

<plnk:partnerLinkType name="SynchBP">

<plnk:role name="SynchBPProvider">

<plnk:portType name="client:SynchBP"/>

</plnk:role>

</plnk:partnerLinkType>

Inside partnerLinkType create one more role element and give it a name as SynchronousProcessRequester. Now inside the role element for portType element change the value of name attribute to client:SynchronousProcessCallback.

<plnk:partnerLinkType name="SynchBP">

<plnk:role name="SynchBPProvider">

<plnk:portType name="client:SynchBP"/>

</plnk:role>

<plnk:role name="SynchBPRequester">

<plnk:portType name="client:SynchBPCallback"/>

</plnk:role>

</plnk:partnerLinkType>

Here we are done with .wsdl file and the SynchBP process is now an asynchronous BPEL Process.

Asynchronous vs. Synchronous BPEL process

This article explains the difference between an asynchronous and a synchronous process.

I have tried to explain the difference with the help of a simple example below:

Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.

Case 1: Client invokes SynchronousBPELProcess.

1. Client invokes SynchronousBPELProcess.
2. SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
3. SynchronousBPELProcess completes its operations and sends a response back to Client.
4. Client continues and completes its processing.

Case 2: Client invokes AsynchronousBPELProcess

1. Client invokes AsynchronousBPELProcess.
2. AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
3. AsynchronousBPELProcess completes its operations and callback the Client with the response message.

Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.

Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.

What makes the difference?

Synchronous Process:

The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.

Asynchronous Process:

In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.

Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.

Fig 3: An image showing a call to asynchronous and synchronous process.

We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.

* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.