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

[Salaboy]

You can do both approachs.

- Ing. Mauricio Salatino -

On Mar 27, 2010, at 4:30, tolitius <webakaunt at gmail.com> wrote:

>
> 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-WORKITEM-ID-tp607507p679600.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users