Common business process modeling situations in WebSphere Lombardi Edition V7.2, Part 3: Executing an activity multiple times in parallel in a business process

This third and final article of the series will cover how to execute multiple instances of a single activity in a business process concurrently.

Ricardo Olivieri (roliv@us.ibm.com), Software Engineer, IBM

Ricardo OlivieriRicardo Olivieri is a Software Engineer in IBM Software Services for WebSphere. His areas of expertise include architecting, designing, and developing software applications (mainly web and database centric applications), administrating and configuring WebSphere Application Server, and distributed software architectures. Ricardo has several years of experience in Java development as well as in Groovy, Perl, and Python development, with a strong background in backend development (server side, business logic, databases, SQL) and frontend development. Ricardo has recently added BPM development to his bag of tricks using Business Process Manager. Through his years at IBM, Ricardo has learned and used many open source frameworks, libraries, and projects such as Drools, Spring, Struts, Restlet, Hibernate, Dojo, and JasperReports. He has a B.S. degree in Computer Engineering from the University of Puerto Rico, Mayagüez Campus.



03 August 2011

Introduction

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.

Assumptions

A thorough understanding of Lombardi Edition V7.2 is not required to understand the topics discussed in this article. However, you should be familiar with the product’s basic functionality and with the general concepts of business process management. Also, knowledge of JavaScript and programming languages in general is assumed.


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, Process with Multi-Instance Loop, is shown in Figure 1 and is included with this article so you can import it into Lombardi Edition.

Figure 1. The sample business process
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 Review objects.
Figure 2. Variables for Process with Multi-Instance Loop
Variables for Process with Multi-Instance Loop

The Proposal and 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
Definition for the Proposal data type

The Proposal object consists of three simple data fields:

  • 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:

  • category_1
  • category_2
  • category_3

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
Definition for the Review data type

The Review object consists of two simple data fields:

  • reviewer: Login name of the reviewer (a string)
  • comment: Remark made by the reviewer (a string)

A list of Review objects (tw.local.reviews) is built during the execution of the business process from the tw.local.reviewers and tw.local.comments variables, which you will see later.

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, Create Proposal, 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
Data mapping for the Compute Reviewers step

The 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:

  • james@xyz.com
  • john@xyz.com
Figure 6. Rules definition for the Compute Reviewers step
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 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 tw.local.reviewers list variable. Note that the tw.system.step.counter 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.local.reviewers list, then the tw.system.step.counter variable goes from 0 to the length of the tw.local.reviewers list minus 1.

Figure 8. Routing definition for the Review Proposal activity
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 tw.local.comments 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
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 tw.local.reviewers list (see the Owner column in Figure 10).

Figure 10. Inspector view for Process with Multi-Instance Loop
Inspector view for Process with Multi-Instance Loop

The fourth step in the process, Populate Reviews, is implemented in JavaScript 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 the 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
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 process, 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 Review data 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 (Reviewer and Comment) that are displayed in the table widget by introspection of the Review data type.

Figure 12. Coach for the Do Final Review Step
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 Review instances).

Figure 13. Human service for the Do Final Review step
Human service for the Do Final Review step

Companion file

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:

  • james@xyz.com
  • john@xyz.com
  • mark@xyz.com
  • mary@xyz.com
  • pete@xyz.com
  • admin@xyz.com

Figure 14 shows how to add a user via the Lombardi Edition Process Admin Console.

Figure 14. Adding a user to the user registry
Adding a user to the user registry

Conclusion

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.

Acknowledgments

The author would like to thank Owen Cline for reviewing the technical content of this article.


Download

DescriptionNameSize
Sample codePart_3_code_samples.zip467KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=750436
ArticleTitle=Common business process modeling situations in WebSphere Lombardi Edition V7.2, Part 3: Executing an activity multiple times in parallel in a business process
publish-date=08032011