[rules-users] Drools 5.1.0.M1 - Process Task JPAWorkItemManager

[Vijay K Pandey]

This is what our scenario is:



a) Sample Process A: --> Start -->Human Task 1 ---> Human Task 2 -->. End



When the above process is started it will wait at "Human Task 1". Let's says after some time/days based on some external application data - Human Task 1 needs to be skipped/aborted and then the process moves to Task 2. In that case if we simply call this



ksession.getWorkItemManager ().abortWorkItem (workItemId);



I was expecting the above call to also call the handler's abortWorkItem method so that the external Task can also be skipped/aborted.



I understand that when we add a new Task 3 different types of events are registered for the TaskEvent and if we complete the task (complete/failed/skipped) - the registered handlers will get called back and will then internally call the workitemamanger.abortWorkItem if it is failed/skipped and that will resolve the issue, but the problem I am facing is after the server gets restarted all the added listeners are lost and there won't be any callbacks.



May be I can manually call the skip of the Task associated with the work item but I thought to have this call non intrusive.



Thanks

Vijay



-----Original Message-----
From: rules-users-bounces at lists.jboss.org [mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Kris Verlaenen
Sent: Tuesday, December 15, 2009 7:42 PM
To: Rules Users List; Vijay K Pandey
Cc: Rules Users List
Subject: Re: [rules-users] Drools 5.1.0.M1 - Process Task JPAWorkItemManager



After a work item has been created, the work item manager expects the

handler to either signal the completion of the work item, or the

abortion if it could not be executed normally.  Note that, if the

handler decides to call the abortWorkItem method, the abort method of

the handler is not called again (as the handler just told the engine

that the work item could not be executed, so no need to call that again).



The abortWorkItem method is called when the work item should no longer

be executed, for example when the process it was executing in was

aborted.  In that case, the abortWorkItem method of the handler will be

called, so he can also cancel the work item in the external system.  For

example, if the work item is a user task on a task list, this will

usually remove the task from the task list again.



Hope this helps!



Kris



Quoting Vijay K Pandey <VPandey at mdes.ms.gov>:



> Hi,

>

> I am using Drools 5.1.0.M1. My question is there any reason why

> JPAWorkItemManager does not call the workitemhandler when we abort a

> work item.

>

> a)       Step 1 - Obtain the stateful knowledge session - set the

> work item handler

> b)       Step 2 - Abort the work item. But this call does not call

> back the abortWorkItem of the work item handler.

>

> ksession.getWorkItemManager().abortWorkItem(workItemId);

>

> I checked the JPAWorkItemManager and it does not call the handler to

> execute the abortWorkItem method of the work item handler.

>

> I do see that from

>             public void internalAbortWorkItem(long id) ---- there is

> a call for the work item handler method but no call from

> abortWorkItem method

>

> Any reason why?

>

> Thanks

> Vijay

>









Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

_______________________________________________

rules-users mailing list

rules-users at lists.jboss.org

https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091215/56892122/attachment.html