Oneway Process With Correlation Does Not Respond Anymore In Case Of Exception (Doc ID 1495503.1)

Last updated on DECEMBER 01, 2023

Applies to:

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:

xIMGx

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:

 xIMGx

Monitor the process.

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

xIMGx

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

Select operation etapeE1 and fill payload.

xIMGx

After sending the message, click button below:

xIMGx

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

xIMGx

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

xIMGx

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:

xIMGx

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

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.