Even if you publish messages from the FileAdapter in a certain order, it does not guarantee the order in which BPEL would process these messages. In order to maintain message ordering, you will need to do the following:
i) Set oracle.tip.adapter.file.numProcessorThreads=1 (see FAQ entry "How do I configure number of threads for FileAdapter")
ii) Model the BPEL process as a synchronous FileAdapter BPEL process:
Normally the File adapter wizard only creates OneWay WSDLs so you will have to manually tweak it a little, i.e. modifying the generated WSDL so it becomes a Request-Response type WSDL with input and output messages.
For example:
Lets first create a XML schema type for the (dummy) Response (output) message.
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/file/fileService/">
<import namespace="http://TargetNamespace.com/fileService" schemaLocation="FileSchema.xsd" />
...
<element name="empty">
<complexType/>
</element>
...
Then we define the WSDL message:
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/file/fileService/">
<import namespace="http://TargetNamespace.com/fileService" schemaLocation="FileSchema.xsd" />
...
<element name="empty">
<complexType/>
</element>
...
Then we define the WSDL message:
<message name="ignore_msg">
<part name="empty" element="file:empty"/>
</message>
<part name="empty" element="file:empty"/>
</message>
Now we can add an output message to the file read operation:
<portType name="Read_ptt">
<operation name="Read">
<input message="tns:records_msg"/>
<output message="tns:ignore_msg"/>
</operation>
</portType>
<operation name="Read">
<input message="tns:records_msg"/>
<output message="tns:ignore_msg"/>
</operation>
</portType>
We also need to add an output element in the binding section:
<binding name="Read_binding" type="tns:Read_ptt">
<pc:inbound_binding />
<operation name="Read">
<jca:operation .../>
<input>
<jca:header message="hdr:InboundHeader_msg" part="inboundHeader"/>
</input>
<output/>
</operation>
</binding>
<pc:inbound_binding />
<operation name="Read">
<jca:operation .../>
<input>
<jca:header message="hdr:InboundHeader_msg" part="inboundHeader"/>
</input>
<output/>
</operation>
</binding>
Now the WSDL is OK.
In the BPEL Process you simply add a Reply activity as shown:
<variables>
<variable name="ignore" messageType="ns1:ignore_msg"/>
..
<variable name="ignore" messageType="ns1:ignore_msg"/>
..
<correlationSets>
<correlationSet name="dummy" properties="ns1:dummy"/>
</correlationSets
<correlationSet name="dummy" properties="ns1:dummy"/>
</correlationSets
<sequence name="main">
<receive partnerLink="FileReader" portType="ns1:Read_ptt" operation="Read"
variable="Receive_1_Read_InputVariable" createInstance="yes">
variable="Receive_1_Read_InputVariable" createInstance="yes">
<correlations>
<correlation initiate="yes" set="dummy"/>
</correlations>
<correlation initiate="yes" set="dummy"/>
</correlations>
</receive>
[...] <!-- processing -->
<invoke partnerLink="...."/>
<invoke partnerLink="...."/>
<reply partnerLink="FileReader" portType="ns1:Read_ptt" operation="Read" variable="ignore"/>
[...] <!-- optionally more processing -->
</sequence>
Notice the use of a Correlation set on the Receive activity, which is needed establish/determine the FileReader partnerlink conversation ID. The Correlation property can be defined in the file read WSDL, e.g.
<bpws:property name="dummy" type="xsd:string"/>
<bpws:propertyAlias propertyName="tns:dummy"
messageType="tns:records_msg" part="..." query="..."/>
<bpws:propertyAlias propertyName="tns:dummy"
messageType="tns:records_msg" part="..." query="..."/>
Thus using a synchronous flow will guarantee ordering between the Receive and the Invoke right before the (first) Reply. Note - the process can still continue after the Reply if need be.
0 comments:
Post a Comment