Some failed BPEL processes are not tracked in BPEL Console (not hydrated)

Question

Hi all.
I'm experiencing a problem at a customer which has a standalone BPEL install (they use BPEL 10.1.3.1 only)
The customer is complaing that, due to some process errors, the BPEL process fails but, the process final state is not hydrated to database, so it's not possible to track the process execution.
I built a simple test case and tested against BPEL 10.1.3.1 and 10.1.3.3. The test consists of:
1 - A synchronous BPEL process using an Assign activity.
2 - In the assign, I force an error condition, for example copying the expression parseEscapedXML('some bad xml string') to a variable.
3 - I execute the BPEL process using the console
4 - The process finishes with error, but you don't get any instance in the "Recently Completed BPEL Process Instances"
This is a critical problem as we cannot track both what was successfully executed and what has failed.
Failed instances like this one are obviously logged in appserver files, but this is not an accpectable monitoring alternative.
This is even more critical because the customer does not have Enterprise Service Bus to mediate execution, where I could certainly track those failed ones.
Any ideas?
Is it possible to force hydration of all types of failed processes?
Thanks
Denis
Message was edited by:
[email protected]
Message was edited by:
[email protected]

Answer 1

Additional info: Having the process "In Flight" due to the checkpoint and subsequent "error", if I manually abort the instance and visualize the audit flow, I can see which activity has caused the error.
For example:
1 - I execute the process. It executes the checkpoint() and the ora:parseEscapedXML(), which causes the process to terminate unexpectedly.
2 - The process remains "In-Flight". If I go to the audit flow, it shows that the process has reached the checpoint activity, and nothing further.
3 - I manually abort the instance
4 - I check the audit flow again. This time I can see the flow beyond the checpoint, until the activity that caused the process to terminate (in this case the assign containing the parseScapedXML)
What I conclude is that, when I manually abort the instance, BPEL hydrates the process part that was only "in memory" (the actual point where the process has stoped)
Denis
Message was edited by:
[email protected]