[jboss-user] [jBPM] - Re: A question on the external event using event Correlation

byungwoojun do-not-reply at jboss.com
Fri Jun 10 11:09:39 EDT 2011

byungwoojun [http://community.jboss.org/people/byungwoojun] created the discussion

"Re: A question on the external event using event Correlation"

To view the discussion, visit: http://community.jboss.org/message/609667#609667

After my previous post, using ksession.signalEvent(eventType, eventData) without the process instance id, I realized that the method does NOT work well. The jBPM engine is supposed to find the proper process instance id in the session, but many times it did NOT point the correct process instance id when there are some left-over data in the EventType database table (due to multiple process instances for the same process definition are running (of course they have the same eventType name) or previous sessions failed and did not clean up the database table entries). When I used the intermediate message event in a nested subprocess, the engine confused more. Once the engine returned a wrong process instance id, a wrong process instance ened up being processed. Then, subsequent process instances got null pointer exceptions, etc. It was NOT pretty.

I reported this problem, see  http://community.jboss.org/thread/166536 http://community.jboss.org/thread/166536, that the name query ProcessInstanceWaitingForEvent used by the ksession.signalEvent didn't return with the correct process/subprocess instance which has the intermediate event type.

So, my team solved the issues as follows:

1. When we start the process, we store a unique correlation id, a session id and a process instance id (it will be the top-level process instance id) in a database table (e.g., correlation id, session id, process instance id). 

2. When an intermediate message arrives, we restore the session using the incomig correlation id from the database table. Using this table, we also find the top-level process instance id. 

3. Using this process id, we query the EventType database table to find the process or sub-process which has the proper event type. The EventTypes database table has two columns: instance id and element. 

InstanceID              Element
1356                       processInstanceCompleted:1357
1357                       eventType1

As you can see, the 1356 row points the 1357 row. In my opinion, the proper way to find a correct pid is drilling down the chain from the top-level pid which is getten from the startProcess. Instead of embedding the next pid part of the text data in the Element field, if we have the third column to point the next pid, we could use SQL chain query. Using the current schema, I need to get the 356 instance id, parse the element text (after the colon), then, get the row 1357 instanceid, so on....

Since we don't want to add additional column at this time, we created a function with two parameters: eventType, topLevelProcessInstanceId:

- the function queries the EventType database table using the topLevelProcessInstanceId.
- it parses the element column. 
     - If the element contains the same eventType, it returns the processInstanceId.
     - Otherwise, it gets a sub-string after ":" (e.g., 1357). Use this sub-string (need to convert it to long) as a parameter along with the eventType (unchanged), and call the same function recursively until the element is equal to the event type.  

4. After the function, we call ksession.signalEvent(eventType, eventData, foundProcessInstanceId);

As you noticed, this method may end up querying multiple times depending on the depth of sub-processes. There could be some performance penalties. But, it works reliably regardless the EventTypes database table entries. 

If jBPM engine itself supports the correlation out-of-the-box, it would be great. But for now, we need to code for the correlation support.

Any suggestions would be appreciated.



Reply to this message by going to Community

Start a new discussion in jBPM at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20110610/5b5e4171/attachment.html 

More information about the jboss-user mailing list