Dehydrate activity in BPEL to commit transaction

You can understand the concept of dehydrate activity with a typical use case.

One of my soa process was having following requirement

First get the data from client and insert it in to table 

then call a procedure which will use this data you have inserted in the table.


Challenge- When we call an apps procedure/package we use a non xa data source as all the transaction is handled in EBS

The error that was coming in this use case was that for an insert activity with non xa datasource the commit was not happening

which was throwing error in the procedure call as no data found in the table.


Reason - The reason for the same was that since we were using a non xa data source after inserting the data in to staging table the soa process was not commiting it hence it was not available to the procedure as all the process was going on in a single transaction.

So my process was looking something like this

Now in order to commit the insert we used this dehydrate activity which complete one transaction and start another hence the records get committed in the staging table. So after inserting the activity my process was able to achieve the functionality i was looking for.



though the functionality is achieved this is not a good practice to design the process as dehydrate activity commits the transaction and ideally a synchronous process should execute in a single transaction.

This can be better understood by following example.

Create a simple synchronous bpel process and use a dehydrate activity 



Now if you will execute the process you will get the following error


java.lang.Exception: oracle.sysman.emSDK.webservices.wsdlapi.SoapTestException: Client received SOAP Fault from server : Waiting for response has timed out. The conversation id is null. Please check the process instance for detail. at oracle.sysman.emas.model.wsmgt.WSTestModel.invokeOperation(WSTestModel.java:813) at oracle.sysman.emas.view.wsmgt.WSView.invokeOperation(WSView.java:385) at oracle.sysman.emas.view.wsmgt.WSView.invokeOperation(WSView.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.el.parser.AstValue.invoke(AstValue.java:187) at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297) at org.apache.myfaces.trinidadinternal.taglib.util.MethodExpressionMethodBinding.invoke(MethodExpressionMethodBinding.java:53) at org.apache.myfaces.trinidad.component.UIXComponentBase.broadcastToMethodBinding(UIXComponentBase.java:1415) at org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:183) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent$1.run(ContextSwitchingComponent.java:92) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent._processPhase(ContextSwitchingComponent.java:361) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.broadcast(ContextSwitchingComponent.java:96) at oracle.adf.view.rich.component.fragment.UIXInclude.broadcast(UIXInclude.java:103) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent$1.run(ContextSwitchingComponent.java:92) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent._processPhase(ContextSwitchingComponent.java:361) at oracle.adf.view.rich.component.fragment.ContextSwitchingComponent.broadcast(ContextSwitchingComponent.java:96) at 

This is because the dehydrate activity has forced dehydration and caused the process to commit , however a synchronous process should commit in a single transaction.

If you have a use case as mentioned above it is always better to go ahead and make your process as asynchronous process.

In case of database transaction using local data source this might work in case of a synchronous process but is still not a good practice to use dehydration point in a synchronous process.