Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 854419

Summary: cleanup in deploy.xml does not work as expected on failure
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Jason Shepherd <jshepherd>
Component: riftsawAssignee: Jeff Yu <cyu>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.3.0 GACC: gbrown, kconner, soa-p-jira
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-10 09:32:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproducer based on Blueprint3 tutorial none

Description Jason Shepherd 2012-09-04 23:56:29 UTC 
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">
    <active>true</active>
    <retired>false</retired>
    <process-events generate="all"/>
    <provide partnerLink="inventorySevicePLink">
      <service name="bp3:inventoryService" port="inventoryServicePort"/>
    </provide>
    <cleanup on="success" >
      <category>variables</category>           
      <category>correlations</category>
      <category>events</category>
    </cleanup>
  </process>
  <process name="POService:POService">
    <active>true</active>
    <retired>false</retired>
    <process-events generate="all"/>
    <provide partnerLink="POServicePLink">
      <service name="bp3_1:purchaseOrderService" port="purchaseOrderPort"/>
    </provide>
    <invoke partnerLink="requestInventoryPLink">
      <service name="bp3:inventoryService" port="inventoryServicePort"/>
    </invoke>
    <cleanup on="success" >
      <category>variables</category>           
      <category>correlations</category>
      <category>events</category>
    </cleanup>
  </process>
</deploy>

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 23:58:09 UTC 
Created attachment 609814 [details]
Reproducer based on Blueprint3 tutorial
Comment 2 Gary Brown 2012-09-05 08:31:26 UTC 
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 22:56:15 UTC 
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 09:17:02 UTC 
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.