This article will cover a use case that has surfaced both with customers as well as in the product, and describe one option to solve it using ad-hoc activities in Business Automation Workflow (BAW).
The use case: you need to provide an activity in your process that has the following characteristics:
- It can be started at any time and as many times as needed, and
- Each task instance must manage its own data, which is different from the others
This is best illustrated with a scenario. You are building a process to resolve out-of-stock situations. The process starts when inventory is low for a particular item in the warehouse. Upon start, a task is assigned to an individual that can resolve the situation by requesting a stock transfer from other locations. The user may work with a search interface to look at the stock availability in other locations, and for each of these, may initiate an inventory transfer request. One such request may work as follows:
- Upon initiation, a task is routed to an approver on that location and may include the following information
- the item number being requested
- the quantity required
- the destination (your location)
- Upon completion, the response from the approver may include the following
- units approved for transfer
- expected arrival date
The process may also track the result of each inventory transfer request to determine if the required quantity has been fulfilled.
This article describes how to define a process, with the characteristics above, using a repeatable ad-hoc activity. Before we get into the details though, let's define a couple of concepts. What is an activity and how is it different from a task? An activity consists of one or more tasks. Starting an activity will spawn the task or tasks that must be completed for the activity to complete. This is applicable both to activities in a Case as well as ad-hoc activities in a process. This article refers to the latter.
1 - On-Demand Activities - Startable and Repeatable
This is probably the simplest one to tackle. If you have explored ad-hoc activities in BAW processes you've come across this concept. To provide the desired behavior you can use an ad-hoc activity configured as follows:
How do these settings help:
- Making the activity start Manually means that the user must explicitly starts it by executing some action. This could be through the Process Instance UI or a custom control that you build into your process interface. In our scenario, this would be triggered by the UI that initiates an inventory transfer request.
- Making the activity Optional allows the process to complete without any instance of it. In our example, the user may decide that no transfer is needed, maybe because the item is no longer carried. This allows the process to complete without any transfer requests.
- Finally, making it Repeatable means that this activity can be started as many times as needed. In our example, the user may need to transfer from multiple locations to get the quantity required.
Adhoc activities in a BAW process can be implemented as a User Task, Subprocess or Linked Process. Both User Task and Linked Process have a specific data mapping defined. Subprocess can be used to encapsulate a structured flow, with no explicit data mapping but the ability to leverage variables defined in the parent process. It can also define its own local variables. For these reasons, Subprocess is the choice for this scenario.
The next section goes into more details on data handling. As for the flow structure, in our example, the subprocess defines a flow that includes a User Task to review and approve a transfer request. The subprocess would take care of preparing the input as well as saving the output into the parent process for later evaluation.
A very simple version of this process may look something like this:
- Start: the process could be launched manually by a user, or automatically by an external event.
- Verify Stock: this is the task our user completes to determine how much and where to get additional stock from. The user may choose to transfer from multiple locations using this task.
- Start Inventory Transfer script: if transfers are required, this script programmatically starts one or more instances of the Inventory Transfer activity.
- Inventory Transfer: this is our ad-hoc activity and the subject of this article. It is a subprocess configured as described below.
The Inventory Transfer subprocess may look like this.
- Setup task input: this script sets up local subprocess data used in this activity and required by the user task that follows it.
- Inventory Transfer Form: the user task that will be executed to do the actual work. In this example, to approve an inventory transfer.
- Save task result: takes the output of the preceding task and saves it to the parent process.
What is omitted in this example is handling the results and determining if additional transfers need to be initiated. This could be achieved by another ad-hoc activity that reacts on a precondition that checks the quantity requested matches what was approved.
2 - Managing activity data
The use of a subprocess allows us to manage a local copy of the data associated with the activity. This cannot be done with a User Task or Linked Process unless you push the logic into them, which is not ideal.
The diagram above shows the data (i.e. variables) for the process and subprocess and how they are used when these execute:
- The Verify Stock task collects all the transfers from the user and stores them in a list.
- The Start Inventory Transfer script will initiate an instance of the ad-hoc subprocess for each item in the list and store the activity ID/transfer request list index into a map.
- The Inventory Transfer ad-hoc subprocess will retrieve the relevant data from the list by looking up the index from the map using its activity ID.
- The work is done using the local copy of the data (Perform TR)
- The updated business object (Transfer Request) is updated in the parent process.
The above technique can be applied to any scenario. The basic principle is to:
- Store activity data in a list
- Maintain a map of activity ID to list index
- Have the activity instance use the map to access and modify its data
The parent process can provide additional logic based on items on the list to summarize progress or launch additional activities to handle special cases, for example.
Conclusion
The pattern above is one example of how the scenario can be implemented using repeatable activities. There may be other ways to solve the same problem but this works well. This approach has been used to deliver the Approval activity in IBM Automation Workstream Services.