[jboss-user] [jBPM] - Re: Trying to set ActorId in On Entry Action - work item is null

jemmerling do-not-reply at jboss.com
Thu Jan 26 13:59:32 EST 2012

jemmerling [https://community.jboss.org/people/jemmerling] created the discussion

"Re: Trying to set ActorId in On Entry Action - work item is null"

To view the discussion, visit: https://community.jboss.org/message/648926#648926

Sorry, I believe the terminology can cause some confusion.

What I am trying for is (in the scenario given) 2 tasks and 3 task instances in this case. I will use letters to designate tasks and numbers to designate task instances.

Also I cannot see a strong distinction between a node and a task other than to argue that not all nodes are tasks. So when I say (human) task I could also mean node. When I say task instance I could also mean node instance. Also I will confess that I am not entirely certain just what a work item is as opposed to a task or a node instance. I suppose I will only understand fully when I have looked at enough code (which so far has been a fairly productive way of learning).

So task A and task B are as you described them (worker/approver) although the real-world problem I want to address is more complicated. Both have GroupId specified in their static definition and neither has ActorId specified (in fact in our model, we would never want to have to think about a given individual).

So the scenario is:

1.) Task A -> Task Instance 1: Actor 1 (member of Task A's group) claims this task instance, works on it, and completes it.
                              ..also Actor 1's ID is saved as a process variable so we know who completed this task instance
2.) Task B -> Task Instance 2: Actor 2 (member of Task B's group) claims this and "rejects" it by not setting an "approved" variable (which is a process variable).
                              ..so the sequence branches at an XOR gateway which in the BPMN model leads back to Task A
3.) Task A -> Task Instance 3: Actor 1 now sees that the task has been assigned to them immediately, they will not need to claim it; it is already reserved for them to work on.
                              ..Steps 2.) and 3.) could repeat an arbitrary number of times but will eventually lead to a hypothetical step 4.) which should involve Task C or be an end node.

This same pattern will in reality occur 4 or more times in the real-life business process so I don't want to have to define a Task A', B', etc. for every task just to allow for "rework".

Of course, an admininstrator would always have the ability to reassign any task instance to a different actor, but of course that would require said administrator's intervention.

However, suppose I did go with the A', B'..Z' approach as you seem to be suggesting. Then I would still need to know how to assign the ActorId from a process variable. Would I use some expression such as #{variable}?

And I would still like to know if there is a way to programmatically override the ActorId and/or GroupId specification for a task/node using either MVEL or Java, within a script node or within a entry or exit action. If you know how this would be accomplished, could you please refer me to an example!




Reply to this message by going to Community

Start a new discussion in jBPM at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20120126/1d672707/attachment.html 

More information about the jboss-user mailing list