Re: [rules-users] Resuming the Flow: SESSION_ID, PROCESS_INSTANCE_ID, WORKITEM_ID

I understand it is persisted (with WS handler out of the box), what I need to be able to do is to find _this particular_ WorkItemID once the flow is resumed not relying on WS handler. WS implementation of Human Task handler, persists workItemID and have a task associated with it, therefore, when the task gets completed, the framework knows how to find that workItemId, since it is associated with _that_ particular task. But let's say I am not using WS human task handler, and I have my own workItemHandler. What I need to be able to do is having SESSION_ID and PROCESS_INSTANCE_ID to find that _particular_ workItemId, that causes the flow to wait. I understand I can get all the node instances, and all the subflow node instances, etc.. iterate over all the workitems... But instead what I want to be able to do is something similar to: processInstance.findWorkItemsInWaitState() where it gives me [most of the time a single, but can be] a list of only those work items that _currently_ cause the flow to wait. And if I do not do any kind of parallel processing (true async parallel processing), it is always going to be just that one work item that I need. Is that something I can do, or do I need to come up with a different approach (one of which I talked before [saving a work item id as a flow variable])? Thank you, /Anatoly -- View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WOR... Sent from the Drools - User mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users