(JDeveloper 12.1.3,
WLS 12.1.3, SOA/BPM Suite 12.1.3)
In this blog, I will show some
of many possible ways to assign a
Human Task to one or more Assignees and observe their behavior.
If a task has to be assigned
to more than one user, the simplest way is to assign it to a Group, but only if
all the users are in that Group. But if there are some users in the group which
the task should not be assigned to, or not all the users are present in the
group, then assigning the task to a Group may not work exactly how we want it to.
In such cases we can set the
assignees to a task in any of the following ways.
1.
Separate Parallel
Participants within same Stage
We
can modify the Human Task Assignees to add a new Participant as shown below. In
this example, I will set the first participant to be derived from the Swimlane. (User is assigned in Organization file)
And
the second participant to be derived from the payload.
Both
the above assignees are defined in the same stage, so considered to be
Parallel. That means the task will be assigned to both the assignees at the
same time.
When
one of the assignees responds to the task, the task is still assigned to the
second user and is not automatically completed.
The
second user also has to complete the task, only then the whole human task is set
to completed status. After the second user completes the task, below is the
human task status.
Note
that the ‘Voting’ concept is not applicable here since the task assignee Type
is still ‘Single’. So the human task is not completed until all the assignees
complete their tasks. (Voting is applicable when the Assignee Type is
‘Parallel’)
Also,
Note that ‘Claim’ also will not be applicable here. Even if the first user
Claims the task, the second user also have to submit the task. Until then, the
human task is not set to completed status. (Claim is applicable when assigned
to a Group or a comma separated users)
2.
Separate Serial
Participants within same Stage
For
this I will just change the participants sequence as shown below.
In this case when the task is created, the task will be first assigned to the Participant1.
Only
when first participant submits, the task will be then assigned to the
Participant2.
Only
when all the assignees in the chain submit their tasks, the human task is set
to completed status.
3.
Task Assignee Participant
Type : Parallel
For
this I will change the Participant type to ‘Parallel’ and get both the
assignees from the Payload.
In this, the task will be
assigned to all the assignees at the same time.
For
Parallel type of assignee, we can specify the task completion condition by vote
percentage in the Voting tab.
Following
condition means that if 50% of the assignees vote, irrespective of the outcome,
the human task is said to be completed.
For example, if we set the following condition, and both the assignees select REJECT action, then the default outcome SUBMIT will be applied to the human task.
Note
that the ‘Claim’ option is not available for the assignee in this case.
4.
Task Assignee
Participant Type : Serial
Works
similar to 2. (Separate Serial Participants within same Stage)
5.
Comma
Separated Users
For
this I will set the participant from only one payload attribute, but pass a
comma separated assignee name value to it while calling the process.
In
this case also, the task is assigned to both the users at the same time.
Note
that the Claim option is available to the users in this case.
When
one user ‘Claims’ the task, the other user will only be able to see the task in
his queue but will not be able to perform any actions on the task.
When
any one of the users submits the task, the human task is completed and is
removed from the other users Queue.
It is logically similar to
the behavior when both the users are in a Group and the task is assigned to the
Group.
6.
Group
Assignees
For
this I created a group ‘sdarbhaGroup’ in WLS and added 2 users sdarbha1 and
sdarbha2 in the group.
The
behavior is similar to 5. (Comma Separated Users)
7.
Complex
Assignees
This
is a very powerful way to set assignees based on complex business requirements.
Let
us assume that a particular human task has to be performed by many users with
different business responsibilities and in a particular sequence etc.
For
example, a task has to be completed by a data entry operator who enters some
basic information, then has to be assigned to 2 of his peers and a group for
review, and further has to be sent over a management chain, and finally a notification
to the administrator.
First assign it to a data
entry operator.
Then
assign it to his 2 peers.
Along
with a group at the same time.
Then
send it to a management chain for review.
And
finally send a notification to the Administrator.
When the task is generated following is the sequence of assignees.
The
Final FYI Notification will not be visible in the task flow audit trail, but is
sent to the administrator and will be visible in the BPM Workspace.
8. Multiple
Participants of different types in a Single Task Assignee Type
We can
also assign the task to multiple users, groups and application roles,
keeping the Assignee type as Single.
In this case the task will be assigned to all the users, users in the group,
and users from the application at the same time.
Any one from the above users can claim the task and work on it.
The task will be marked as completed when one user submits the task.
9. Multiple
Participants of different types in a Serial Task Assignee Type
We can
also assign the task to multiple users, groups and application roles,
keeping
the Assignee type as Serial.
In this case first the task will be assigned to sdarbha3 only.
When he submits, then only the task will be assigned to sdarbha4.
Even though the users sdarbha3, sdarbha4 are assigned at the same time in the task definition, when the task is created, they will be assigned one after the other since the task type is Serial.
But, the task is assigned to the group, all the users in the task will be assigned at the same time and anyone can claim the task and work on it.
