Associating WebSphere Lombardi V7.2 attributes with users defined in OpenLDAP and routing tasks

This article demonstrates a design pattern using WebSphere® Lombardi attributes along with users defined in an OpenLDAP server for activities such as decision making or routing. If user attributes (such as language) are defined in an LDAP server and used for routine activities, such as routing in WebSphere Lombardi, there is some cost involved in querying the attributes using a JNDI API from an LDAP server. The recommended design pattern can help improve performance and can be adopted without using the User Synchronization option in WebSphere Lombardi.


Sateesh Balakrishnan (, IT Specialist, IBM

Photo of Sateesh BalakrishnanSateesh Balakrishnan is an IT Specialist with IBM Software Services for WebSphere (ISSW). He has over 10 years of experience and currently working on the BPM and BRMS tracks, specializing in WebSphere Lombardi and WebSphere ILOG. In his previous assignment at ISSW, he worked on application infrastructure stream in WebSphere Application Server, J2EE application migrations, and performance troubleshooting and tuning of WebSphere Application Server. He has worked in various capacities, including design and development of J2EE solutions. His current interests are in BPM and BRMS systems.

18 January 2012

Also available in Chinese


IBM® WebSphere Lombardi Edition V7.2 (hereafter called Lombardi) includes an internal security provider that you can use to create and maintain Lombardi users and groups. You can use the internal Lombardi security provider in conjunction with an external LDAP security provider, such as OpenLDAP that is registered with the Lombardi embedded application server. When you use the internal Lombardi security, users and groups from both providers are available for selection throughout Lombardi; for instance, while binding users to participant groups during process development.

This article describes the following steps to associate Lombardi attributes with users defined in an OpenLDAP server 2.4 and uses the association for a dynamic routing scenario.

This article assumes that an OpenLDAP server is installed and configured with Lombardi.

Defining Lombardi attributes

This section describes the steps to define user attributes in Lombardi.

User attribute definitions

A user attribute definition is an attribute (parameter) that you can configure on user definitions in Lombardi. For example, if you need to route a process task to the manager of a user, you need know the manager of every user. Through the creation of a user attribute, a user can be associated to his or her manager. You can create a user attribute definition from within the Data category of the Library as shown in Figure 1.

Figure 1. Define the user attribute
Define the user attribute

When created, a dialog appears asking for a name for this attribute as depicted in Figure 2.

Figure 2. Define the attribute
Define the attribute

The definition parameters for a user attribute looks as follows in Figure 3.

Figure 3. Attribute details (seeenlarged Figure 3)
Attribute details

For this use case, an attribute called "Reporting Manager" has been created.

Associating attributes to users defined in LDAP server

This section describes the steps to assign value to an attribute and associate the attribute to the user.

Bulk user attribute assignment

You can set up attributes associated with users in this area. Log into the Lombardi Process Admin Console. Click on the User Management option, and under that, Bulk User Attribute Assignment.

Under this option in the Select an Attribute section, all the attributes defined are listed. For user "user" (from the LDAP server), user "Jeni" (from the LDAP server) is associated as a Reporting Manager as shown in Figure 4.

Figure 4. User attribute assignment (seeenlarged Figure 4)
User attribute assignment

Associating users defined in LDAP server to groups defined in Lombardi

This section describes the configuration of groups in Lombardi.

User administration

Lombardi manages its own model of users and groups. User administration is performed through the Process Admin Console in the User Management section. Here, groups are defined out of users from the LDAP server and the internal security provider. These groups are later used as participant groups.

Security groups

Group management is performed in the Process Admin Console under User Management > Group Management.

In Figure 5, a group called "TSO" has been defined with two users, "user" and "tso1". They are defined in OpenLDAP and the Lombardi internal repository, respectively.

Figure 5. Group management (seeenlarged Figure 5)
Group management

Similarly, another group called "TCGroup" has been defined with two users from OpenLDAP, as shown in Figure 6.

Figure 6. Group management (seeenlarged Figure 6)
Group management

A dynamic routing use case using these associations

Now you will define a Business Process Definition (BPD) and implement a routing scenario using the attribute definition ReportingManager. Figure 7 shows a snap shot of the process in question. There are two activities, Call Customer and TC approve. They are housed in the participant groups TSO (Telesales officer) and TC Group (Team Coordinator), respectively.

Figure 7. Business Process Definition (seeenlarged Figure 7)
Business Process Definition

Under the variable section of the Business Process Definition, the following variables are defined in a private scope as shown in Figure 8. Of interest is the complex variable TSODetails of type TSO, which contains variables, name, and reportingTo.

Figure 8. BPD variables
Business Process Definition variables

The activity Call Customer has been implemented as a human service as shown in Figure 9. Also, the logic as represented in Listing 1 to extract the user attribute and assign it to a variable is implemented here. This variable value is later used in the routing logic of the next activity in the Business Process Definition.

Figure 9. Implementation of Call Customer activity
Implementation of Call Customer activity
Listing 1. Fetch the user attribute and assign it to a variable
tw.local.TSOreportingTo= user.getAttributes().get("ReportingManager");

In Listing 1, the Lombardi system APIs are used to fetch the attribute for the logged in user. The method getAttributes().get("ReportingManager") dynamically returns the defined attribute value for the corresponding user. The user object is obtained by invoking the method findUserByName(), which takes username as an argument.

Subsequently, for the activity TC approve, under the Property tab in the Routing section, Assign To is selected to List of Users and is bound to the reportingTo variable as shown in Figure 10. Thus, when the work item is routed from Call Customer to the next activity, the manager of the corresponding user who initiated the request gets the work item.

Figure 10. Routing definition (seeenlarged Figure 10)
Routing definition

In the above scenario, user "user", who belongs to the TSO participant group, takes action on the activity Call Customer. After completion, the task is routed to activity TC approve and assigned dynamically to user "Jeni", who belongs to the TC participant group. User "Jeni" is also the manager for user "user". The routing logic is configured in the routing section of the Properties tab.


This article showed how to use a user defined in an external repository, such as LDAP, with attributes defined in WebSphere Lombardi. The article also listed an API for retrieving attributes and showcased a dynamic routing scenario based on the attribute.


The author would like to thank Harsha Bushana for his efforts in reviewing the article.



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

Zone=Business process management, WebSphere
ArticleTitle=Associating WebSphere Lombardi V7.2 attributes with users defined in OpenLDAP and routing tasks