Not correlation receive instance in Running state

Damir Dev

My process, correlation (over element id) successful :

1) BPEL one-way invoke WebService_1

<xml>

<id>123</id>

<userId>userId_1</userId>

</xml>

2) BPEL wait correlation receive from WebService_2

3) WebService_2 one-way invoke BPEL

<xml>

<id>123</id>

<userName>userName_1</userName>

</xml>

As result I have two instance in Completed state. It is ok.

My process, correlation (over element id) unsuccessful:

1) BPEL one-way invoke WebService_1

<xml>

<id>123</id>

<userId>userId_1</userId>

</xml>

2) BPEL wait correlation receive from WebService_2

3) WebService_2 one-way invoke BPEL

<xml>

<id>456</id>

<userName>userName_1</userName>

</xml>

As result I have two instance. First instance (BPEL one-way invoke WebService_1) in Running state, It is ok. But second useless instance (WebService_2 one-way invoke BPEL) in Running state also. So I think useless instances utilize resources. What should I do for automatic stopping useless instance?

Martien van den Akker

Hi,

You should try to invoke webservice_1 with id 456, after you Invoked Webservice 2 with 456. I mean, perform your second test case, and then invoke another Webservice 1 with id 456. You should see that then it will pickup the correlated message from Webservice 2. Webservice 1 in the second case will wait until a correlated webservice 2 with the same id is invoked.

This is intended behavior that exists pre BPEL 10g. It's in the original product even before Oracle acquired it.  And I learned that back then this was a differentiating feature.

What happens is that when Webservice 1 is invoked, it will intiate a correlation set. Then it will wait for an incoming message.

Two cases can happen.

1. It can happen that the invoke of webservice 2 of Webservice 1 with the correlation message didn't took place yet. In that case at the receive, the process manager will dehydrate the instance of Webservice 1. It will stay in the active/running state, but it does not take resources. BPEL won't leave it in memory doing nothing. But it will register the receive with a relation to the correlation set. It will use the DLV_* tables for that.

Now when webservice 2 comes along, it will do an invoke of the Webservice 1 with correlated message. BPEL will take a look into the table to see if there is an instance waiting for that message that matches the correlation set. In this case it will find it, loads the instance again will go on with processing the receive and further.

2. It can also happen that Webservice 2 was first. It will do the invoke of the message, but does not find an instance with a receive matching the invoke. It will save the message into the table. Because it does not know if the instance that needs the message hasn't arrived the receive yet. It may even never get there.... It will go on with processing Webservice 2 instance until it finised or it reaches a state where it gets dehydrated itself. Side note, I assume it is not a synchronous webservice call. Now, at a later stage Webservice 1 gets to the receive, BPEL concludes that the message from Webservice 2, matching the correlation set is already in the table. It will pick it up and go on processing right away.

In neither of the cases, active resources are kept in memory running, although the instance list will show the instances running.

Hope this helps your understanding

Correlation sets are really a cool feature in BPEL. Although BPM uses the same process engine, the first two releases of BPM 11g lacked this feature. So you had to use a parallel BPEL instance to be able to use this. Since 11.1.1.5 or 11.1.1.6,  I think, also  BPM has this feature. And also Process Cloud Service can do this. I wrote about it years ago: https://blog.darwin-it.nl/2017/07/pcs-and-correlations-next-big-thing.html

Kind regards,
Martien

Martien van den Akker

Hi,

You should try to invoke webservice_1 with id 456, after you Invoked Webservice 2 with 456. I mean, perform your second test case, and then invoke another Webservice 1 with id 456. You should see that then it will pickup the correlated message from Webservice 2. Webservice 1 in the second case will wait until a correlated webservice 2 with the same id is invoked.

This is intended behavior that exists pre BPEL 10g. It's in the original product even before Oracle acquired it.  And I learned that back then this was a differentiating feature.

What happens is that when Webservice 1 is invoked, it will intiate a correlation set. Then it will wait for an incoming message.

Two cases can happen.

1. It can happen that the invoke of webservice 2 of Webservice 1 with the correlation message didn't took place yet. In that case at the receive, the process manager will dehydrate the instance of Webservice 1. It will stay in the active/running state, but it does not take resources. BPEL won't leave it in memory doing nothing. But it will register the receive with a relation to the correlation set. It will use the DLV_* tables for that.

Now when webservice 2 comes along, it will do an invoke of the Webservice 1 with correlated message. BPEL will take a look into the table to see if there is an instance waiting for that message that matches the correlation set. In this case it will find it, loads the instance again will go on with processing the receive and further.

2. It can also happen that Webservice 2 was first. It will do the invoke of the message, but does not find an instance with a receive matching the invoke. It will save the message into the table. Because it does not know if the instance that needs the message hasn't arrived the receive yet. It may even never get there.... It will go on with processing Webservice 2 instance until it finised or it reaches a state where it gets dehydrated itself. Side note, I assume it is not a synchronous webservice call. Now, at a later stage Webservice 1 gets to the receive, BPEL concludes that the message from Webservice 2, matching the correlation set is already in the table. It will pick it up and go on processing right away.

In neither of the cases, active resources are kept in memory running, although the instance list will show the instances running.

Hope this helps your understanding

Correlation sets are really a cool feature in BPEL. Although BPM uses the same process engine, the first two releases of BPM 11g lacked this feature. So you had to use a parallel BPEL instance to be able to use this. Since 11.1.1.5 or 11.1.1.6,  I think, also  BPM has this feature. And also Process Cloud Service can do this. I wrote about it years ago: https://blog.darwin-it.nl/2017/07/pcs-and-correlations-next-big-thing.html

Kind regards,
Martien

Damir Dev

Glad to see you again, Martien Thank you for feedback, very helpful information.

Actually I try to foresee case when WebService_2 will send the some correlation value in element id, which WebService_1 never to get. As result instance will be in Running state and in DLV_* tables forever. I guess should be special properties for protection from this. But I did not find any information about it in manual.

Martien van den Akker

Hi Damir,

I'm not sure in what way this will be purged. But the thing is with correlation sets is that one process can interact on another process based on an identifier that both processes have agreed upon.  So I think you need to review if this can functionally be the case. Because Webservice 1 apparently initiates the correlation set. So either it gets it from out side, where Webservice 2 would have known it as well, or Webservice 1 generates in one way or the other and communicates it in a certain way to Webservice 1.

In either way it can be that Webservice 1 would have come along the receive at one point or it fails to get there because of an earlier exception, or it reaches some time out limit.

In those two last cases you could come up with a way to check if the message of Webservice 2 is still applicable.

But if Webservice 1 initiated the correlation set in an earlier stage, but gets in an error or completed, then the correlation set is disabled as well. So related data should be purged along the way. You would need to test.

Kind regards,

Martien

Damir Dev

Of course, when bpel try to invoke WebService_1 and then it has fault (http 500, timeout, etc), I catch fault and stop bpel process. So I dont utilize resources.

Martien van den Akker

Hi Damir,

Of course it's good to handle the fault and end the BPEL process in a nice and controlled way. But even when you don't, the SOA infrastructure changes the state to recovery or faulted and it won't consume resources. The only time a BPEL processes is using resources is when it has still activities left to execute, excluding those activities that lets the service wait. So activities like wait, Pick, Receive will drive the engine to dehydrate the process. Thus a running state in the console does not mean it is actually busy with executing statements and therefor using up resources.

It's because BPEL is a statefull engine it can do that. For OSB it's a whole different story: OSB is stateless, and therefor using up resources while running. As soon as OSB is done working on activities, the service is complete. But a nasty situation in OSB can occur when using service call-outs: that will block a thread and needs another thread to deliver the incoming message to the process. It then actually waits in a weblogic thread. With BPEL you won't have that kind of situation.

Kind regards,
Martien

Damir Dev

Exactly. If use callout also in the OSB, this creates a new thread, and the old thread continues to work waiting for the callout to complete. It need in more resources.

But it is another topic for discussion.