IBM Business Automation Workflow Team Filtering and Direct Assignment
Another way to set task assignment when the default doesn’t meet user requirement
Authors: Leonard Blunt , Greg Ekaprana, Okka Sudaryanto, Diorella Mari Tom
Code Repository
You can find all the artifact used for the example that will be explained below in the toolkit in Git repository
Introduction
When creating process flow in IBM Business Automation Workflow, user assignments are completed through the assignment of a team to a swim lane. However, commonly, the business may have reasons that they wish to customize the team dynamically based on business rules or data. IBM Business Automation Workflow supports several ways that assignments can be made programmatically. In this article we will explore the programmatic assignment of tasks using team filters and direct assignment through scripting.
Team Filtering
Team Filter Service is a service that could be used on a task and filter the team so it will be assigned to a specific user or team. This service usually used if there is a big team that consists of a smaller team rather than the user. It will create a temporary team where the member of the team only the selected team and/or user.
Let’s simulate this by creating a process with one user task, imagine that the task in this process is done by 2 separate groups of users, depending on the previous process the task can be done by either groups or just one of the selected groups. In the process app, those 2 groups are set within the same team, so when the task needs to be done by one of the groups we need to filter out this team. In this example, we create a team with 2 User Groups: GroupA and userC. And we put the team on the lane as shown in Figure 1.
Both group consist of 2 users, userA and userB for GroupA, userC and userD for GroupB as shown in Figure 2.
When we start the process, that task will be assigned to the team and all members in Team A will be able to see it in their inbox and claim it. We can test to run the process and see the users that are allowed to claim the task. One way to check this is by opening Process Inspector, find and select the process instance that you run and then on the right-side section expand the Tasks then click on a task you want to assign.
Click on Assign to user and the Reassign dialog window will appear. Now on the Reassign to textbox, type a character and delete it so it will leave the textbox blank. Now you can see the list of users that allowed to claim the task as shown in Figure 3.
With team filtering, we can manipulate the members on the team that able to claim the task. In this example, we will reduce the team member from 3 to 2. To do this we need to create a team filter service. To create one in the user task that you want to have a team filter, click new as shown in Figure 4 below.
A pop-up will appear to give a name for your service, let the template service to use Team Filter Service Template, and then click on Finish and a service flow will be created. Different from regular service flow as shown in Figure 5 below. This service template has a fixed input and output both used a system data business object called Team for the variable. You can add more input, but you can’t add more output. The fixed input called originalTeam will automatically fill with the team configured in the process activity. In our example’s case, this originalTeam will be filled with Team A data. The fixed output filteredTeam will consist of a team we build in this service and will be used as the assigned team for the process activity.
To set the team member with only one group, we create a script task. In order to do this, we need to know the group name we want to set, as shown Figure 6 we set the group name in the script.
And by that, we have finished creating a filtered team service. We can test to run the process and see the users that are allowed to claim the task. One way to check this is by opening Process Inspector, find and select the process instance that you run and then on the right-side section expand the Tasks then click on a task you want to assign.
Click on Assign to user and the Reassign dialog window will appear. Now on the Reassign to textbox, type a character and delete it so it will leave the textbox blank. Now you can see the list of users that allowed to claim the task as shown in Figure 6.
We can see that only 2 members of A Team are listed which is the members of GroupA, that means our team filtering service is giving expected result.
Team Filtering with Input
The previous example shows how we can manipulate the existing team and creating a filtered team by script. Now to make the code more dynamic and can adjust to the process, the team filter service allows us to put more input into the service, let’s create another team filter service and variable in the input in the team filter service flow as shown in Figure 8.
Let’s say we have a process that has a user task where the owner of the task is decided based on the location the user is stationed, so in this case, there will be system service that will determine the user and output it to be used for our team filter. Let’s look at the process flow example called shown in Figure 9.
As you can see in the above figure, we reuse Team A and put it as the default lane team in the process flow. For the sake of the example, the dummy User Location Filter system task is set to output userC. Now let’s see where the user variable is mapped in the process, Figure 10, 11 and 12 shows the variable in the process, which is mapped in the output of the user location filter and also mapped on the input for the User Task’s team filter service.
The system task in Figure 11 is hard-coded to userC but in a real-world case, there can be a requirement where the owner of the task need to be selected based on some other data input and is looked up to the database, for example in the active directory we have the geolocation of each user and based on the task also have a requirement to be done by the closest user and this system task will look up the user geolocation with user task’s geolocation in the database.
Figure 13 shows that we use the service input and assigned it to the filtered team member. So, this means that the filtered team member only consists of the value entered in the service input. As a best practice, it is recommended to validate the inputted user with the original team set in the task. The Team in BPM may be out-of-sync with the service that determines the selected user. In a case like this, we should throw an error message.
Figure 13: Filter the members based on service input
Now we run the process and as we can see in Figure 14, only userC are allowed to be assigned for the task.
Direct Assignment
Applying team filtering on a task sets the team assignment. In our scenario discussed in ‘Team Filtering with Input’ section, a team is dynamically filtered to one user which means the task cannot be easily reassigned to another user/s. Team Managers and Users have no option but to return the task to the pool.
In our previous project, we have a requirement in some process where the client has identified which individual/user can claim the task. At first, we used team filtering which satisfies the assignment to a direct user however as described, we quickly identified that we cannot reassign the task to another user if the team has been filtered to a sole user. Instead of using team filtering, we came up with a solution that when the task is created, we can directly assign the task to a user. The assigned task is sent to the user’s inbox but because the overall assignment remains with the “Team” the Team manager and User can still interact and complete actions such as reassignment if required.
For direct assignment to work, the task needs to be created and is not a part of the provided configuration on a task. We show below the programmatic approach to support the direct assignment.
For this example, we create another process called Direct Assignment which shown in Figure 15, the example is based on Dynamic Team Filtering that we use in the previous example. You can also find these example artifact in the toolkit we put in git repository.
As shown in Figure 15, we need two extra components to put in the process, first is a timer which is an intermediate event component and a system task put after the timer is fired.
For the timer, we put it on the task that we want to directly assign. Here’s shown in figure 16 the configuration for the timer. We must uncheck the Interrupt activity option as it is checked by default. If the Interrupt activity is selected, the attached activity is closed when the timer event is triggered and the process won’t continue.
Now for the system task itself, we create a new service flow with these 3 inputs:
1. instanceID : instance ID of the process
2. user: user ID that will be assigned to the task
3. taskName: Name of the task in the process flow diagram
For the service flow, we need to put one script which shown in Figure 17. The script we are using will retrieve the process instance based on the instance ID that inputted to the service, find the task based on the task name, and assign that task with the user ID given in the input.
Back to the process, we need to set the input for the system task as shown in figure 18. We can use BPM JavaScript API to get the instance ID with the following code: tw.system.process.instanceId. For the user we use the variable selectedUser which also used in the previous example, the output of the location filter dummy service is userC. And for task name, set the value with the name of the task, in this example, the name is User Task.
Now we have finished with the code and configuration, we can test by running the process. Then we can check the result by opening the process inspector, and as shown in figure 19 the task is now assigned to User C instead of to Team A Filtered. Unlike using the team filter, we can still reassign the task to the other user in the team, we can also return the task to the team so everyone and the team can claim.
