1 Reply Latest reply on Jan 5, 2012 6:39 AM by melc

    Human Task Assignment -- actor status changed

    jemmerling

      Sorry, I couldn't think of a better subject line.

       

      I would like to know, given 2 nodes in a process definition:

       

      A task associated with the first node can be claimed by any member of a given group. When complete, the subsequent task can also be claimed by any member of some group (possibly a different one). However, the id of the actor that completed the previous task is retained as a process variable.

       

      So here is the scenario. For the 2nd task, the actor completing that task will set "approved" to true or false. If "approved" is false, then:

       

      --the process should return to the previous node and be assigned to the actor that completed it before...

       

           unless:

       

                --either that actor no longer exists

                     or

                --that actor exists but is no longer a member of the group that can claim the task

                     ...in which case, the task should be claimed by some other member of this group

       

      I would think this a common scenario but I would like to know how straightforward this is to implement in jBPM5. Is this standard behavior or must it be implemented programmatically?

       

      I am evaluating jBPM5 in comparison with some competing products and the above scenario is the one that was presented to me as an important one for jBPM5 to be able to support easily -- preferably "out of the box".

       

      TIA and sorry this isn't more concise.

       

      --JE

        • 1. Re: Human Task Assignment -- actor status changed
          melc

          Hi,

          I'll try to see how each of your reqs are solved with "out of the box" functionality

           

           

          A task associated with the first node can be claimed by any member of a given group. When complete, the subsequent task can also be claimed by any member of some group (possibly a different one). However, the id of the actor that completed the previous task is retained as a process variable.

          - So, task1 and task2 are assigned to a group - ok

          - The id of the actor that completed task1 will have to be mapped to a process variable - ok ( can be done either by using #{some expression} or a little magic around kcontext within the on exit action etc )

           

           

          So here is the scenario. For the 2nd task, the actor completing that task will set "approved" to true or false. If "approved" is false, then:

           

          --the process should return to the previous node and be assigned to the actor that completed it before...

           

               unless:

           

                    --either that actor no longer exists

                         or

                    --that actor exists but is no longer a member of the group that can claim the task

                         ...in which case, the task should be claimed by some other member of this group

          - Assigning the actor based on the variable value is ok..... however i'm not sure what happens if both actorid and groupid are present in task1.... whether the actorid will supersede....-> although you can always place a task3 which is the same as task1 and everything works fine.

          - Regarding the "unless" part this is a little strange, because if the actor no longer exists and you assign the actorid

          the following might happen (sry havent tried it)

          a. the system complaints that the specific user no longer exists

          b. the system has no problem that the users no longer exists and the group part works - then all ok

           

          ....keep in mind that i'm talking about zero code situations  i.e. not even user-group callback etc....

           

          If the actor exists but no longer part of the group then this gets complicated. Because, if the user exists then the actorid will be assigned along with the groupid, but you want the engine not to assign it to this user since is not a member of the group - not ok (this i'm almost certain that will not work for this engine as well as two more i.e. activiti and intalio, .... in jbpm this can be achieved with a little programming in a clean manner).

           

          Somehow you need to check it the user is a member of the group or some logic before assigning the user.