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&containerType=14&container=2034]
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
