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-boun...@lists.jboss.org [mailto:rules-users-boun...@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 <vpan...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
