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

[Kris Verlaenen]

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