In WebSphere Lombardi Edition (hereafter called Lombardi Edition), you define and implement the activities, such as steps, that are carried out to complete a business process. Part 1 of this series discussed routing of those activities, with a focus on how to dynamically compute the list of users that execute an activity in a business process. Part 2 discussed integrating external activities with an external system using the REST API. The last part of this series, Part 3, will cover execution of multiple instances of a single activity in parallel.
Executing an activity multiple times in parallel
It is common in many business processes to have an activity that is executed multiple times in parallel by different participants. For instance, let’s say that you have a business process where a proposal document is reviewed by N number of users. Let’s also say that these reviewers are determined at run time using a given set of rules and that it is acceptable from a business perspective to conduct the reviews in parallel (such as a reviewer does not need to wait on another reviewer to provide their feedback). Under such a scenario, once the list of reviewers is computed, you can execute the review step in the business process multiple times in parallel (one instance of the step per reviewer).
A basic sample business process that encapsulates the logic described above
is used throughout this article to show how an activity can be executed
multiple times in parallel. This sample business
Process with Multi-Instance Loop, is shown in
Figure 1 and is included with this article so you can import it into
Figure 1. The sample business process
We will first start by describing the data model used by the business
process shown in Figure 1. Once we have gone over that data model, we will
describe the steps that are carried out in the process. In Figure 2, you
can see all the variables used by the sample business process,
Process with Multi-Instance Loop:
tw.local.reviewers: List of reviewers (login names) for the proposal document.
tw.local.comments: List of remarks made by the reviewers.
tw.local.proposal: Object that represents a proposal document and its status.
tw.local.reviews: List of
Figure 2. Variables for Process with Multi-Instance Loop
Review data types are complex structure types
that were defined for the
Process with Multi-Instance Loop sample
business process. Figure 3 and Figure 4 show the
definition for these data types.
Figure 3. Definition for the Proposal data type
Proposal object consists of three simple
- proposalText: Textual component (a string)
- category: Proposal classification (a string)
- approved: Approval flag (a boolean)
In this sample business process, the category field can have one of the following predefined values:
The value of the category field is used to determine the list of reviewers who will review the proposal document, which is shown later.
Figure 4. Definition for the Review data type
Review object consists of two simple data
- reviewer: Login name of the reviewer (a string)
- comment: Remark made by the reviewer (a string)
A list of
tw.local.reviews) is built during the
execution of the business process from the
tw.local.comments variables, which you will see
Now that we have described the data model, let’s describe the workflow in
Process with Multi-Instance Loop. The first
step in the business process,
is implemented as a human service. This step simply allows a user to
create and submit a proposal document for review and approval. Once a
proposal document is submitted, the second activity,
Compute Reviewers, is executed to determine at
run time the list of users who will review the proposal. This system
activity receives a
Proposal object as input,
applies a set of predefined business rules to determine the list of
reviewers, and returns this computed list as the output variable (a list
of login names). Figure 5 shows the data mapping for the
Compute Reviewers system activity.
Figure 5. Data mapping for the Compute Reviewers step
Compute Reviewers activity is implemented as
a rule service in Lombardi Edition. Figure 6 shows the business rules
definition for this step. In this step, the category property value of the
Proposal object is inspected to determine the
list of users who will review the proposal document. A different list of
users is returned from this service for each category value. For instance,
let’s assume that the value for the category property is
category_1. Under such scenario, according to
the business rule shown in Figure 6, the list of reviewers returned from
this service contains only the following two users:
Figure 6. Rules definition for the Compute Reviewers step
The third step in the business process,
Review Proposal (shown in Figure 7), is the
activity that is instantiated multiple times in parallel. In Lombardi
Edition, a multi instance loop is used to execute an activity multiple
times concurrently. The two bars on the left bottom corner of this
activity indicate that it is implemented as a multi instance loop. On the
Step section (Properties tab) of an activity, you can find the option to
specify that the activity is implemented as a multi instance loop. As
shown in Figure 7, the
Loop Type value (for the
Review Proposal activity) is set to
Multi Instance Loop. The
Start Quantity field is used to specify the
number of instances that are created for this step. Since an instance of
this step is needed for each reviewer, we assign the length of the
tw.local.reviewers list to this field as shown
in Figure 7.
Figure 7. The Review Proposal activity
The Routing section (see Figure 8) shows that each instance of the
Review Proposal activity is routed to a
specific user in the
variable. Note that the
variable is used to index the right element in the
tw.local.reviewers list. This is a read only
variable that Lombardi Edition exposes to indicate the instance number of
the multi instance loop activity that Lombardi Edition is instantiating.
Since the number of instances needed for the
Review Proposal activity is equal to the number
of elements in the
tw.system.step.counter variable goes
0 to the length of the
tw.local.reviewers list minus
Figure 8. Routing definition for the Review Proposal activity
On the Data Mapping section (see Figure 9), the
tw.system.step.counter variable is used to
assign the remarks entered by the reviewer to the right spot in the
tw.local.comments list. Once all reviewers have
entered their remarks, the
list will contain the remarks entered by each one of them. The element
location in the
tw.local.comments list and
tw.local.reviewers list is used to associate
the remarks with the corresponding reviewer.
Figure 9. Data mapping for the Review Proposal activity
Figure 10 shows the state for the sample business process if a proposal
document was submitted for review with a category value of
category_1, and if the list of reviewers was
just computed. In such a case, as mentioned earlier, there are only
two reviewers in the
tw.local.reviewers and, consequently, Lombardi
Edition creates two instances of the
Review Proposal activity (note the two
tokens above the
Review Proposal activity in
Figure 10). Also, note that each instance of this step is routed to a
reviewer contained in the
list (see the Owner column in Figure 10).
Figure 10. Inspector view for Process with Multi-Instance Loop
The fourth step in the process,
code. This step simply creates instances of the
Review data type and adds each one of these
instances to a list data structure
tw.local.reviews). To create an instance of
Review data type, this step iterates over
the elements in the
tw.local.reviewers list and
gets the associated remarks from the
tw.local.comments list, as shown in Figure 11.
Having a list of
Review instances will come in
handy as you will see next.
Figure 11. Implementation for the Populate Reviews step
After all reviewers have entered their remarks, a supervisor is expected to
see the remarks from each of the reviewers and make a final decision as to
whether or not the proposal is approved. The last step in the business
Do Final Review, is implemented as a
human service that displays the remarks entered by each reviewer along
with the login name of the reviewer in a tabular format. A table widget is
used to format the display of the reviews in a tabular layout. Now, to
populate a table widget, you need to bind it to a list of variables that
have a complex data type (such as
type). This is the reason for creating a list of
Review instances in the
Populate Reviews step. Figure 12 shows that the
tw.local.reviews list is the variable bound to
the table widget. Doing so automatically generates the columns
Comment) that are displayed in the table widget
by introspection of the
Review data type.
Figure 12. Coach for the Do Final Review Step
Finally, Figure 13 shows the user interface for the
Do Final Review step (note the table widget
that shows the list of
Figure 13. Human service for the Do Final Review step
The sample business process diagram named Process with
Multi-Instance Loop is included with this article. To execute this
business process, import the
Common_Modeling_Situations_-_Part_3 - CMS_3_7711_432_PM.twx
file into Lombardi Edition. Before executing this business process,
you need to add the following proposal reviewers to the user registry:
Figure 14 shows how to add a user via the Lombardi Edition Process Admin Console.
Figure 14. Adding a user to the user registry
When an activity in a business process is implemented in Lombardi Edition and needs to be executed multiple times in parallel, consider implementing the activity as a multi instance loop. This allows you to use different input values, when needed, for each instance of the activity that is created. It also allows you to route each instance to a different participant. Finally, it allows you to capture the output returned from each instance execution. In this article, you learned how to implement an activity as a multi instance loop and how to pass and collect data from it.
The author would like to thank Owen Cline for reviewing the technical content of this article.
- For information about using Lombardi Edition and its features, see the WebSphere Lombardi Edition V7.2 Information Center.
- For the latest how-to technical information in the BPM space, see the IBM Business Process Management zone.
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.