Common business process modeling situations in WebSphere Lombardi Edition V7.2, Part 1: Role-based and dynamic routing of activities

In the first of a 3-part article series, you will learn how to route activities, execute activities in parallel, and integrate activities with an external system using WebSphere® Lombardi Edition V7.2. Part 1 covers routing of activities, with a focus on computing users at runtime to execute a step in a business process.

Share:

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.



29 June 2011

Introduction

In WebSphere Lombardi Edition (hereafter called Lombardi Edition), you define and implement the activities, such as steps, that must be carried out to complete a business process. In this article, routing of those activities is discussed, with a focus on how to dynamically compute a list of users that execute an activity in a business process. Part 2 will discuss integrating external activities with an external system using the REST API. A future article in this series will cover execution of multiple instances of a single activity in parallel. 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 WebSphere 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 functions and with general concepts of business process management. Also, knowledge of Java™, JEE, DB2® Universal Database, WebSphere Application Server, REST architecture, and programming languages in general are assumed.


Role-based routing

In business process modeling jargon, specifying which users can claim and complete an activity is known as the routing of the activity. In many cases, this is simply a matter of assigning a predefined group of users to the activity. For instance, let’s say that only users with the manager role can execute an activity (or step) in a workflow defined in Lombardi Edition. Using the Lombardi Edition Authoring Environment, you can create a participant group that is mapped to users or groups of users who have manager roles, and specify that only members of this participant group can execute the activity.

Figure 1 shows a business process with a single activity (such as Review Salary Increase) that is reviewed only by managers. Routing of this activity is assigned to any lane participants. The swim lane has “Managers” as the default participant group (see Figure 2). The Managers participant group contains only users who have the role of manager. This configuration guarantees that only managers see this activity as a task in their work items inbox.

Figure 1. Lane participant can execute activity
Lane participant can execute activity
Figure 2. Managers group assigned as the lane participant
Managers group assigned as the lane participant

Figure 3 shows that two users are mapped to the Managers participant group. Therefore, Lombardi Edition routes the Review Salary Increase activity to only these two users. Note that users (and groups) in your user registry can be easily added or removed from a participant group by using the buttons on the right of the Participant Group panel.

Figure 3. Users mapped to the Managers participant group
Users mapped to the Managers participant group

A sample process diagram named Salary Increase Review, which implements the above scenario, is included with this article in the Part_1_code_sample.zip file. This sample process is found in the companion file, Common_Modeling_Situations_-_Part_1 - CMS_1_62111_631_PM.twx. You can import this file into your Lombardi Edition environment and execute the Salary Increase Review process. Before doing so, you should have in your user registry the users associated with the Managers participant group. For instance, you can use the Process Admin Console to add these users as shown in Figure 4.

Figure 4. Adding users to the user registry via the Admin Console
Adding users to the user registry via the Admin Console

Dynamic routing of activities

Let’s now explore a similar, but more complex scenario. Let’s say that for a given activity in a business process only users that meet the following criteria will execute it:

  • Located in Texas.
  • Have a security clearance.
  • Have been certified on X, Y, or Z.
  • Have been certified on A, B, and C.

Boolean logic

Note the difference in Boolean logic between the last two items in the bulleted list. In the first of these, being certified on either one of the certifications (for example, X, Y, or Z) is enough while in the last bullet, it is required to be certified on all certifications (for example, A, B, and C).

In other words, the right to execute the step is not granted simply because the user has one role (such as being a manager or a supervisor). Instead, there are different “dimensions” (for example, properties or qualities of the user) that are verified to determine whether or not the user has enough rights to execute the step. Let’s also assume the properties that need to be verified to determine which users execute the activity change on a frequent basis (monthly, quarterly, and so on).

Lombardi Edition capabilities provide the function needed to implement a routing strategy that satisfies the above business rules. Instead of routing the activity to users who have a specific role (such as a role-based approach), you can create a service in Lombardi Edition that queries a storage containing the users’ attributes (location, certifications, and so on), and dynamically computes the list of users that have enough rights to claim the task. The routing of the activity in the workflow is then assigned to this list of users, which guarantees that Lombardi Edition routes the activity to only those users in the list.

The above approach is adaptive to changes in business rules. For instance, if users located in other states execute the activity, or if additional certifications are required, updating the query to collect the users from the storage is the only change needed to accommodate such changes.

Let’s assume that a set of database tables is used to store users and their properties (it is also common to store user information in an LDAP server). Figure 5 and Figure 6 show the structure of the REVIEWER and CERTIFICATION_OWNED tables.

Figure 5. The REVIEWER table
The REVIEWER table
Figure 6. The CERTIFICATION_OWNED table
The CERTIFICATION_OWNED table

As their names imply, the REVIEWER table contains reviewers and their properties (for example, location, user ID, and so on), while the CERTIFICATION_OWNED table holds the certifications reviewers have obtained. A foreign key column (such as REVIEWER_ID) in the CERTIFICATION_OWNED table links the content of this table with the corresponding record in the REVIEWER table. Note that there is a one-to-many relationship between the REVIEWER table and the CERTIFICATION_OWNED table, such as a reviewer may have multiple certifications.

Let’s now also say that the query in Figure 7 returns the results shown in Figure 8.

Figure 7. SQL query
SQL query
Figure 8. SQL results
SQL results

Given the results shown in Figure 8 and the business rules described earlier in this section, Lombardi Edition routes the activity to the following user IDs only:

  • pete@xyz.com
  • john@xyz.com
  • james@xyz.com

Note that these three users are located in Texas, have security clearance, have the X, Y, or Z certifications, and have the A, B, and C certifications.

Figure 9 shows a process diagram in Lombardi Edition, where the REVIEWER and CERTIFICATION_OWNED tables are queried to dynamically compute the list of reviewers that an activity is routed to.

Figure 9. Compute users for an activity at run time
Compute users for an activity at run time

The Compute Reviewers activity in the Review Process workflow queries the database tables to gather the list of reviewers that the Do Review activity is routed to. The list of users returned by the Compute Reviewers activity is assigned to the tw.local.reviewers list, as shown in Figure 9.

Figure 10. Route activity to computed list of users
Route activity to computed list of users

Figure 10 shows the routing mechanism selected for the Do Review activity. Note that this activity is explicitly routed to the users contained in the tw.local.reviewers variable. Hence, Lombardi Edition routes the Do Review activity to only users contained in the tw.local.reviewers list.

Figure 11. Implementation of the Compute Reviewers service
Implementation of the Compute Reviewers service

The Compute Reviewers activity in Figure 10 is implemented by the Compute Reviewers service shown in Figure 11. This service executes a SQL query against the REVIEWER and CERTIFICATION_OWNED tables, parses the results from the query, and puts together a list of the user names (such as login IDs), which is then returned to the calling activity. The logic in the SQL query ensures that only reviewers that meet the business rules described earlier are returned in the SQL results. Note that if for some reason the SQL query does not return any results, the Compute Reviewers service sends an email notification to the administrator (this is implemented in the Send Notification nested service). If this occurs, the business process does not move forward until this situation is corrected. This can happen if, for instance, the database does not have any users that meet the criteria specified in the business rules.

To execute the SQL query, the Compute Reviewers service uses the out-of-the-box SQL Execute Statement integration service. It is easy to configure this service, as shown in Figure 12. At a minimum, this service needs to know the SQL query to execute, the data storage to query, and the variable to store the results.

Figure 12. Configuration of the SQL Execute Statement service
Configuration of the SQL Execute Statement service

Note that the SQL query statement used in this service is defined in the server scriptlet named SQL Query. As reference, this SQL query statement is shown in Figure 13.

Figure 13. Definition of the SQL query
Definition of the SQL query

Figure 14 shows the result of executing the Review Process workflow in Lombardi Edition. Note that the user IDs, which are contained in the tw.local.reviewers list, are only those that meet the business rules. Therefore, those users have enough rights to claim the Do Review activity.

Figure 14. Executing the Review Process
Executing the Review Process

A sample process diagram named Review Process, which implements the approach discussed above, is included in the zip file in the Download section of the article. This sample process is also found in the companion twx file. Before executing the Review Process business process in your Lombardi Edition environment, you need to:

  • Create and populate the database tables.
  • Define a corresponding data source in WebSphere Application Server (see Configuring a data source in WebSphere Lombardi Edition V7.1).
  • Make sure the users contained in the REVIEWER table are found in the user authentication registry. Figure 4 shows how to add users to the authentication registry via the Process Admin Console.

A DB2 DDL file named demo-db-init.txt is provided in the zip file with this article to create and populate the database tables. This script creates a database named DEMO_DB to hold these tables. You can use the DB2 command shown in Listing 1 to execute this file (this DDL script was successfully tested on DB2 V9.7).

Listing 1. Creating demo database and tables
db2 –vtf demo-db-init.txt > demo-db-init.out

After processing the DDL instructions contained in the demo-db-init.txt file, you can inspect the demo-db-init.out file to ensure that no errors occurred.

The JNDI name of the data source for the DEMO_DB must be jdbc/DemoDB. If you happen to use a different JNDI name for this data source, then make sure you update the data source environment variable for the Review Process (see Figure 15).

Figure 15. Data source environment variable
Data source environment variable

It is worth mentioning that the approach discussed here is not the only possible mechanism to assign users to an activity based on a set of user attributes. For instance, you can add custom attributes to users and define a routing policy that inspects such attributes to determine how to route an activity. In my experience, this works fine when you have a low finite number of attributes to inspect in the routing policy, and when these attributes are pretty much static (for example, user attributes are not being removed or added frequently).

Another possible option is to write a Lombardi Edition service that uses Lombardi Edition’s JavaScript API to update a participant group’s membership or users’ attributes and call this service periodically. Another possible implementation is to write a Lombardi Edition service that runs a ruleset in ILOG JRules to return the matching list of users.

Choosing an implementation depends on the requirements of the project and the complexity of the required routing rules.


Conclusion

WebSphere Lombardi Edition gives you several options when it comes to routing an activity to users. For complex rules where several attributes and qualities of a user (or some other entity) need to be inspected to determine which users execute an activity, you may want to consider a dynamic approach where the list of users is computed at runtime. In this article, we discussed how to dynamically compute the list of users that can execute an activity by querying a database.

Part 2 will discuss integrating external activities with an external system using the REST API. A future article in this series will cover execution of multiple instances of a single activity in parallel. The last part of this series, Part 3, will cover execution of multiple instances of a single activity in parallel.

Acknowledgments

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


Download

DescriptionNameSize
Sample codePart_1_code_samples.zip457KB

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=696002
ArticleTitle=Common business process modeling situations in WebSphere Lombardi Edition V7.2, Part 1: Role-based and dynamic routing of activities
publish-date=06292011