![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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.
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
Figure 2. 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
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
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.
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
Figure 6. 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
Figure 8. 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
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
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
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
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
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
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
REVIEWERtable 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
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.
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.
The author would like to thank Owen Cline for reviewing the technical content of this article.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample code | Part_1_code_samples.zip | 457KB | HTTP |
Information about download methods
-
Configuring a data source in WebSphere Lombardi Edition V7.1
-
WebSphere Lombardi Edition V7.2 Information Center
-
IBM
Business Process Management zone
-
IBM Business Process Manager Standard product page
<strong>Ricardo Olivieri</strong> is a Software Engineer in <a href="http://www.ibm.com/developerworks/websphere/services/">IBM Software Services for WebSphere</a>. 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.
