byungwoojun [
http://community.jboss.org/people/byungwoojun] created the discussion
"Re: A bug? Ksession.signalEvent and ProcessInstanceWaitingForEvent"
To view the discussion, visit:
http://community.jboss.org/message/609670#609670
--------------------------------------------------------------
To me, that the name query ProcessInstanceWaitingForEvent used by the ksession.signalEvent
does NOT return with the correct process/subprocess instance which has the intermediate
event type when there are some left-over data entries in the EventType database table due
to:
- multiple process instances for the same process defintion are running (i.e., there are
more data entries in the EventType database table). Of course, the process instances have
the same event type name.
- previous sessions failed and didn't clean up data entries from the EventType
database table.
There could be several ways to solve this. At this time, my team didn't want to add
additional column to the database table, we 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.
e.g.,
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.
bwj
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/609670#609670]
Start a new discussion in jBPM at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]