Oneway Process With Correlation Does Not Respond Anymore In Case Of Exception

(Doc ID 1495503.1)

Last updated on MARCH 14, 2013

Applies to:

Oracle(R) BPEL Process Manager - Version 11.1.1.4.0 to 11.1.1.5.0 [Release 11gR1]
Information in this document applies to any platform.

Symptoms

When running a process containing multiple one way receive (using correlation), if an exception is raised inside the process, process is still running but do not react to any message sent to it.

Steps to reproduce the case :

1. Deploy composite Project1

Composite Project1 contains one process that has 2 receive nodes and a correlation id based on element ns1:descripteurSocleBPMVO/ns1:idAffaire  inside the message sent to the process.

2.Go to the Enterprise Manager, select the Project1 composite and click the button test.

Select operation process and fill payload:

Send the message.

 

Monitor the process, it should be waiting for Receive 1.

 

3. Go back to the test form to send the second message:

Select operation etapeE1 and fill payload:

 

Monitor the process.

Process is still in running state, but an exception was raised, as indicated in the audit trail below:

 

 

 

0-      4. Go back again to the test form to send the third message:

Select operation etapeE1 and fill payload.

 

After sending the message, click button below:

As you can see below, message was not routed to bpel instance:

Behaviour is not correct !!!

 

If you will run:

select * from DEV_SOAINFRA.dlv_subscription where operation_name='etapeE1';

 

update DEV_SOAINFRA.dlv_subscription set state=0;

commit;

 

Display the content of table DLV_SUBSCRIPTION

 

State should be 0, and it is 1.
Modify value from 1 to 0, and commit the change.
Then, reproduce step 3.


Monitor the process, as below:


This time, message was correctly routed to the process, which ended properly.

 

Now, if we go still deeper in the BPEL, and try to trace all SQL request to the technical database, we see that in Step 3, BPEL engine uses up to 4 transactions to process the request, and only the second is rollbacked (sql request below).

 

First transaction (TX=BEA1-22B4FB6E479DD3430D20)  sets the state column of DLV_SUBSCRIPTION to 1. It was committed, since value is seen through SQL Developer.
Second transaction (TX=BEA1-22B6FB6E479DD3430D20) was rollbacked, since we do not see in SQLDeveloper update that was applied to WORK_ITEM table.
Third transaction (TX=BEA1-22B8FB6E479DD3430D20) inserts exception WLI_FAULT table.
Fourth transaction (TX=BEA1-22BBFB6E479DD3430D20) logs results in audit tables.

 

 

Project1.zip

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms