Bug 854419 - cleanup in deploy.xml does not work as expected on failure
cleanup in deploy.xml does not work as expected on failure
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: riftsaw (Show other bugs)
5.3.0 GA
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Yu
Depends On:
  Show dependency treegraph
Reported: 2012-09-04 19:56 EDT by Jason Shepherd
Modified: 2013-07-01 21:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-10 05:32:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Reproducer based on Blueprint3 tutorial (13.21 KB, application/x-gzip)
2012-09-04 19:58 EDT, Jason Shepherd
no flags Details

  None (edit)
Description Jason Shepherd 2012-09-04 19:56:29 EDT
Description of problem:
When adding the cleanup tag as described in the community docs, [1], would expect that when a fault of any kind occurs messages would not be deleted from the BPEL_XML_DATA table. However we found that only some faults cause the data to remain in the table.

[1] http://ode.apache.org/instance-data-cleanup.html

Version-Release number of selected component (if applicable):
SOA-P 5.3

How reproducible:
Use the BPEL_Blueprint3 tutorial shipped with the Riftsaw 2.3.6 source code.

Steps to Reproduce:
1.Modify the deploy.xml like so, also attached in tar.gz

<?xml version="1.0" encoding="UTF-8"?>
<deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:POService="http://www.seebeyond.com/eInsight/POService" xmlns:bp3="http://manufacturing.org/wsdl/inventory/bp3" xmlns:bp3_1="http://manufacturing.org/wsdl/purchase/bp3" xmlns:newuntitled="http://www.seebeyond.com/eInsight/newuntitled">
  <process name="newuntitled:InventoryService">
    <process-events generate="all"/>
    <provide partnerLink="inventorySevicePLink">
      <service name="bp3:inventoryService" port="inventoryServicePort"/>
    <cleanup on="success" >
  <process name="POService:POService">
    <process-events generate="all"/>
    <provide partnerLink="POServicePLink">
      <service name="bp3_1:purchaseOrderService" port="purchaseOrderPort"/>
    <invoke partnerLink="requestInventoryPLink">
      <service name="bp3:inventoryService" port="inventoryServicePort"/>
    <cleanup on="success" >

2. Send either 'invalid', or 'throw_po_fault' to the service using the attached SOAP-UI project.
Actual results:
A WS Fault is returned by the webservice, and the data is deleted from BPEL_XML_DATA table.

Expected results:
For any kind of fault, the data should remain.

Additional info:
The 'throw_inv_fault' message works as expected, the data remains in the data after the call returns.
Comment 1 Jason Shepherd 2012-09-04 19:58:09 EDT
Created attachment 609814 [details]
Reproducer based on Blueprint3 tutorial
Comment 2 Gary Brown 2012-09-05 04:31:26 EDT
Hi Jason,

Thanks for the information.

The two examples you have provided highlight the reason for the difference. The cleanup defines what should happen when a process instance completes 'successfully'.

A BPEL process instance completes successfully if the messages are handled by defined paths in the process, which also includes fault handlers.

So in the cases of 'throw_po_fault', the POService.bpel has a fault handler to catch this WSDL fault and deal with it - so the process comes to a successful conclusion.

However the 'throw_inv_fault' throws a fault that is not caught by the POService.bpel - thus causing the process instance to terminate in an 'unsuccessful' state - causing the cleanup criteria to be ignored.

Not sure it would be possible to make this current cleanup mechanism understand whether a WSDL fault has been processed by the process instance, and react accordingly, as it is using the completion state of the process instance.

It might be worth investigating what information is required when a BPEL process is handling a fault, as possibly this information can be recorded using the event listener mechanism?
Comment 3 Jason Shepherd 2012-09-10 18:56:15 EDT
You explanation of the throw_po_fault is reasonable, if an exception is handed by the POService, it is reasonable that the data is cleaned up. However I don't think you explained what happens in the case of an 'invalid' order. Is there also some exception handling which allows this execution to return a success?

Could you please explain why the clean-up also happens in the case of an invalid order?
Comment 4 Gary Brown 2012-09-11 05:17:02 EDT
With the 'invalid' message, the description field starts with "OrderInvalid", which when passed through to the InventoryService, results in a normal response, but with an inventoryStatus of false.

When this normal response is received by the POService, it checks the inventoryStatus for being true - if this is not the case, it returns a "cannotCompleteOrder" fault with a fault code of 404. This logic is at the bottom of the POService.bpel.

Therefore in this case, as with the throw_inv_fault case, the POService and InventoryService process instances are completing successfully.

Note You need to log in before you can comment on or make changes to this bug.