This will be really troublesome, as we will not be able to identify whether the problem lies in the external system driving the BPEL instance or within the BPEL process itself after consumption of data. In such cases, you can use the checkpoint(); Java method inside a Java embedding activity to force the instance to be dehydrated as soon as the instance gets triggered in BPEL. This will ensure that the BPEL instance is shown up in the BPEL console if it is instantiated. You can use the following piece of code in your BPEL process to force dehydration.
<bpelx:exec name="CheckPointOne" language="java" version="1.5">
<![CDATA[checkpoint();]]>
</bpelx:exec>
Now, all your BPEL instances will be available in the BPELConsole for debugging issues that are not actually propagated/thrown to BPELConsole by the OPMN.
However, there are certain drawbacks while using the force dehydration mechanism, as this will cause drop in performance of the BPEL process during run-time due to the additional overhead of persisting the instance whenever this method is called. So please make justified use of this method before using this.
No comments:
Post a Comment