Introduction:
When a JMS adapter consumes a message from a Weblogic JMS queue/topic, the message is removed from it. Imagine a situation where a SOA process consumes a messages from a JMS through JMS adapter but the process fails before its execution is complete. This will lead to message loss as the message was already removed from the JMS and cannot be recovered even if the SOA transcation is rolled back. JMS adapter in Oracle SOA behaves as an asynchronous service (one-way service). This will cause the BPEL engine to split the execution into two parts.
Following way we can rollback the JMS messages without losing them in case of any error in the BPEL process.
Solution: Using Synchronous process
we modify the wsdl of the JMS adapter.
The wsdl of the JMS adapter that is generated is asynchronous(one-way) we change it to synchronous.
Add an empty element in the schema of the wsdl.
<element name="empty"/>
Create a new message type.
<wsdl:message name="Ignore_Message_msg">
<wsdl:part name="ignore" element="empty"/>
</wsdl:message>
Add an output to the operation in the wsdl with the newly created message.
<wsdl:output message="tns:Ignore_Message_msg"/>
This will make the wsdl as synchronous.
In the BPEL, add a reply activity and connect it to the JMS adapter, when asked for variable just mention the message type you have just created in the wsdl.
Note: In this approach we need not to add following properties in the Composite.xml file.
When a JMS adapter consumes a message from a Weblogic JMS queue/topic, the message is removed from it. Imagine a situation where a SOA process consumes a messages from a JMS through JMS adapter but the process fails before its execution is complete. This will lead to message loss as the message was already removed from the JMS and cannot be recovered even if the SOA transcation is rolled back. JMS adapter in Oracle SOA behaves as an asynchronous service (one-way service). This will cause the BPEL engine to split the execution into two parts.
- First, and always inside the caller transaction, the insert into the dlv_message table, and
- secondly the transaction & new thread that executes the workitems, and creates a new instance.
Following way we can rollback the JMS messages without losing them in case of any error in the BPEL process.
Solution: Using Synchronous process
we modify the wsdl of the JMS adapter.
The wsdl of the JMS adapter that is generated is asynchronous(one-way) we change it to synchronous.
Add an empty element in the schema of the wsdl.
<element name="empty"/>
Create a new message type.
<wsdl:message name="Ignore_Message_msg">
<wsdl:part name="ignore" element="empty"/>
</wsdl:message>
Add an output to the operation in the wsdl with the newly created message.
<wsdl:output message="tns:Ignore_Message_msg"/>
This will make the wsdl as synchronous.
In the BPEL, add a reply activity and connect it to the JMS adapter, when asked for variable just mention the message type you have just created in the wsdl.
Note: In this approach we need not to add following properties in the Composite.xml file.
- bpel.config.transaction
- bpel.config.oneWayDeliveryPolicy
No comments:
Post a Comment