Delivering Business Process as a Service (BPaaS) on the IBM SmartCloud, Part 2: Sharing the BPM middleware among multiple tenants

This article looks at how to set up a multi-tenant business process management environment in the cloud so that you can support more teams creating and deploying their own business processes with fewer installations and configurations. The goal is to provide as much isolation and sharing as possible between tenants using the same installation of the middleware. We also discuss how the different BPM components are set up in the development, test and production environments that are typically used in a BPM project lifecycle. This content is part of the IBM Business Process Management Journal.


Christina Lau (, Distinguished Engineer, IBM

Author photoChristina Lau is a Distinguished Engineer in WebSphere, focusing on emerging technologies such as cloud and mobile computing. Her current focus is on developing advanced technologies that support the delivery of multi-tenant SaaS solutions across the IBM SWG portfolio.

developerWorks Contributing author

Murali Vridhachalam (, IT Architect, IBM

Murali Vridhachalam photoMurali Vridhachalam, an Open Group certified IT architect, has been involved with XBRL since early 2005. He was the lead architect for IBM's first ever submission of financial reports using XBRL, as part of the SEC's XBRL voluntary filing program. His current interests include SOA and Software as a Service offerings built using the IBM enterprise software portfolio.

Valentina Birsan, Senior Developer, IBM

Valentina Birsan's photoValentina Birsan is a senior developer in WebSphere, currently focused on cloud projects. Previously Valentina was a technical lead on Rational Application Developer. She was one of the initial members of the Eclipse TPTP open source project, and served as the chair of the TPTP Architecture Group. Valentina was also the lead architect for the Cosmos Service Modeling Eclipse open source project and a member of the SML open standard.

Bhadri Madapusi, Advisory Software Developer, IBM

Bhadri MadapusiBhadri Madapusi is an Advisory Software Developer in WebSphere, currently focused on cloud projects. Bhadri has over 10 years of software development experience. Previously he worked on business process management and WebSphere Commerce.

Daniel Bauman (, Advisory Software Engineer, IBM

Daniel Bauman has been a Software Engineer with IBM since 1999. He has worked with many enterprise BPM projects and is a consultant specializing in WebSphere Application Server and BPM software.

06 June 2012

Also available in Chinese


Recently our team has been working with the IBM® CIO organization to create a virtualized IBM business process management (BPM) environment that can be shared by multiple teams to lower the cost of adopting BPM and to foster better collaboration by sharing of best practices, tips and techniques. Incidentally, a number of our enterprise customers have also asked us how they can implement multi-tenancy with IBM BPM products. The common reasons for sharing between teams or business units are:

  1. Increase the efficiency for managing the infrastructure by having fewer installations and configurations.
  2. Reduce license fees for the software.
  3. Reduce deployment time and efforts.
  4. Reduce time to on-board a new tenant because the underlying stack is shared and the on-boarding process is automated.
  5. Increase time to value for their customers by enabling new innovations to be deployed faster.

In this article, you'll learn step-by-step how to achieve these goals with the IBM BPM products.

Sharing BPM middleware

The scenario for sharing the BPM middleware is as follows:

  • A tenant is defined as a team of users that wants to collaborate and develop their business processes. In an enterprise environment, this may map to a business unit, or a team inside a business unit.
  • A tenant is on-boarded to the system via some form of a self-service portal that provides tenant management. After the tenant is on-boarded, the users from the tenant can start authoring and testing processes in the shared IBM Business Process Manager Process Designer and Process Center. Their processes will not be visible to other users from other tenants.
  • A dedicated Process Server is provisioned for each tenant and is connected to the shared Process Center. Only users from the tenant can deploy, run and monitor processes on the Process Server dedicated to the tenant. This can be clustered to meet the different SLA requirements for each tenant.

Figure 1 shows the overall topology.

Figure 1. Sharing BPM Middleware
Sharing BPM Middleware

Components in this topology are:

  • The BSS (Business Support Services) self-service portal supports registration of tenant and users within a tenant. Behind the scenes, the software provisions the BPM Process Servers per tenant and automates their configurations in a secure manner. An advanced deployment may include subscription and billing services for your infrastructure.
  • The IBM Tivoli® Access Manager (TAM) for e-business (WebSeal, Policy Server, and Directory Server) is used to enforce security constraints and to provide tenant awareness. When an HTTP request arrives, WebSeal works with the Policy Server to determine whether the requested resource is protected. If it is protected, WebSeal ensures that the user is authenticated. WebSeal is also used to establish a tenant context for the request. The tenant context includes metadata to identify which tenant the user belongs to so that the user can be routed to the appropriate Process Server. Our Best Practices [2] article explains how to provide access control in multi-tenant cloud solutions using Tivoli Access Manager.
  • Process Designer and Process Center – the authoring environment for processes can be shared among multiple tenants. Each tenant is identified by a unique tenant ID. The tenant ID is used to create a Group in the shared Process Center and all users from the same tenant are automatically added to the Group. With this configuration, a tenant processes can be isolated from another tenant processes.
  • Tenant-aware Process Server – each tenant is provisioned their own Process Server so that they can run and monitor their processes in their own Process Server. If a tenant is removed from the system, their Process Server is automatically de-provisioned.
  • Shared TAM Directory Server – during tenant registration, all the users are added to the same shared LDAP. The LDAP schema has additional attributes that identify the tenant name and tenant ID for a user.
  • Shared DB2 server – it is possible for the tenants to share the same database server with some constraints. See Sharing a database server for more information.

Customizing BPM middleware

In order to realize the topology shown in Figure 1, you need to customize the software products as follows:

  1. Enable the Process Center and Process Server(s) to use the same shared LDAP.
  2. Enable single sign-on between servers.
  3. Create reverse proxy rules in WebSeal virtual machine to route a tenant user to the right Process Server.
  4. Set up appropriate BPM roles for each tenant user.
  5. Determine the database server configurations.

The following sections describe how to do these tasks. To make the tasks easier to understand, we will describe how to use the products user interface to perform the tasks.

It is also possible to develop scripts to automate these tasks. In our lab, we use the Image Construction and Composition Tool and IBM Workload Deployer to capture the customization as virtual images and patterns so that we can easily deploy to different cloud environments, including IBM SmartCloud Enterprise [5] and IBM PureApplication Systems [6].

Enable Process Center and Process Server to use the same shared LDAP

The Tivoli Directory Server is used as a shared LDAP where tenants, users and groups are defined. The shared Process Center and the tenant dedicated Process Servers must be configured to use federated repositories. You can use the administrative console to add the shared LDAP, as shown in Figure 2. Part 1 of this series on using ICON to extend BPM cloud images shows how you can automate this step.

Figure 2. Enable federated repositories
Enable federated repositories

Enable single sign-on

Single sign-on (SSO) allows a user to log in once and then gain access to the Process Center, Process Portal, and so on, without being prompted to log in again to each of them. The LTPA token is used to implement SSO between WebSeal, the shared Process Center and the tenant-specific Process Server. The LTPA key file is exported from WebSeal and then imported into the Process Center as well as each tenant-specific Process Server, as shown in Figure 3.

Figure 3. Import LTPA key file into Process Center and Process Servers
Import LTPA key file into Process Center and Process Servers

Because the Process Designer is running on a Windows® virtual machine, Remote Desktop Connection is used to connect to it rather than WebSeal. On the Windows virtual machine, you should add a user ID to the operating system for each user, so that each tenant user can log in using their Windows ID.

Create Reverse Proxy Rules in WebSeal virtual machine

The Apache HTTP Server on the WebSeal virtual machine provides reverse proxy support and distributes the incoming HTTP requests to the appropriate location. The URL is rewritten based on the tenant context so that the request can be distributed to the shared Process Center applications and the tenant aware Process Server applications. To accomplish this, you need to update two files on this virtual machine: /etc/hosts and /etc/httpd/conf/httpd.conf.

The hosts file defines a logical name for an IP address. For example, when we on-board a tenant to our environment, an entry such as the following is automatically added to the hosts file: bpm200001

The IP address ( represents the Process Server IP that is provisioned for the tenant. The logical name is made up of a prefix (bpm) and the tenant unique ID (200001).

The httpd.conf file allows you to define a number of conditional rewrites [7]. For example, you can define a rule that will route a user to their tenant Process Server Admin console as follows:

RewriteCond "%{HTTP:tenantid}" !^$
RewriteRule "^/ProcessAdmin/(.*)$" "http://bpm%{HTTP:tenantid}/ProcessAdmin/$1" [P,QSA,L]

The conditional rewrite checks whether the HTTP request header has a tenant ID. If the tenant ID is available in the request header, then the rewrite rule routes all the requests for /ProcessAdmin to a tenant-specific Process Server.

In our example a tenant with tenant ID 200001 would be routed to Process Server http://bpm200001/ProcessAdmin/. This is the same as routing to because of the logical mapping that is defined in the /etc/hosts file.

Set up appropriate BPM roles for each tenant user

In a multi-tenant system where services are shared, there are generally three distinct user roles:

  • Tenant user – this role represents a tenant user.
  • Tenant administrator – this role represents a user that is responsible for managing operations and users from the tenant. A tenant must have at least one tenant administrator.
  • Super admin – this role represents the super admin who is responsible for administering the entire multi-tenant environment.

The IBM BPM software requires certain user roles to be set up for authoring, deploying and monitoring to work. As the super admin for your multi-tenant BPM deployment, you need to consider how to map the tenant roles to the BPM roles to support the typical BPM lifecycle and to provide the desired isolation. For example:

  1. How do you allow tenant users to create business processes in the shared Process Designer and Process Center?
  2. How do you constraint tenant users from each other, and enable them to deploy only to their tenant-specific Process Server?
  3. How do you allow the tenant administrators to use the Process Admin console to manage their tenant users and processes on their tenant-specific Process Server?

Let's look at how the super admin can perform these three configurations in a multi-tenant environment.

Configuration 1:

To enable each tenant user to do authoring, each tenant user needs to be added to the tw_authors group on the shared Process Center, as shown in Figure 4.

Figure 4. Add all tenant users to tw_authors group
Add all tenant users to tw_authors group

Configuration 2:

To constraint tenant users from each other, and to enable them to deploy only to their tenant-specific Process Servers, on the shared Process Center, create a unique group name for each tenant (such as tenant1, tenant2) and add all the users from a tenant to their specific group.

On the tenant-specific Process Server, update the 100Custom.xml file to specify the corresponding group name for the tenant [8]. In our example, on tenant1 Process Server, this would be:

  <server merge="mergeChildren">
    <process-center-install-group merge="replace">tenant1</process-center-install-group>

Configuration 3:

To enable the tenant administrators to manage their tenant users and processes, perform the following on each tenant-specific Process Server:

  1. Add the tenant administrator to the tw_admins group, as shown in Figure 5.
    Figure 5. Add all tenant administrators to tw_admins group
    Add all tenant administrators to tw_admins group
  2. Add the tenant administrator to the administrator role in WebSphere Application Server, as shown in Figure 6.
    Figure 6. Add all tenant administrators as WebSphere Application Server administrators
    Add all tenant administrators as WebSphere Application Server administrators

With these configurations complete, users from each tenant should be able to follow the BPM lifecycle to author, deploy and monitor their processes.

Sharing a database server

The default install and configuration for the Process Server is that each tenant has his or her own database server and the BPM databases are installed on the database server as shown on the left side of Figure 7.

In a multi-tenant environment where more sharing is desirable, it is possible to have a shared database server, give each tenant their tenant-specific BPM databases, and configure each tenant-specific Process Server to the tenant-specific databases, as shown on the right side of Figure 7 [4].

Figure 7. Sharing a database server
Sharing a database server

End-to-end user experience

With the configurations described above, a tenant user will be able to use the IBM BPM products from their Windows or Mac® by using a browser and a Remote Desktop Connection. For example, Figure 8 shows a tenant user using Remote Desktop to connect to the IBM Process Designer that is running on the SmartCloud Enterprise.

Figure 8. Using Remote Desktop to connect to Process Designer on SmartCloud Enterprise
Using Remote Desktop to connect to Process Designer on SmartCloud Enterprise

The same user can also log into the BSS self-service portal and access the shared Process Center or his or her own tenant-specific Process Server as shown in Figure 9.

Figure 9. Using a web browser to access Process Center and Process Server
Using a web browser to access Process Center and Process Server

Sharing BPM in development, test and production environments

In a typical BPM project lifecycle, IT teams use different environments for development, test and production. Figure 10 shows how a single shared Process Center can be used to promote process snapshots to Process Servers in development, test and production environments. Separation of duties can also be enforced with BPM software where developers may promote the process snapshots to a development Process Server, but only an authorized tester may promote process snapshots to the Process Server in the test environment, and only an administrator can promote process snapshots to Process Center in th production environment. This capability allows for minimal components to be owned by a project team in a BPM project lifecycle, further reducing costs.

Figure 10. Sharing BPM in development, test and production environments
Sharing BPM in development, test and production environments


This article showed you how you can achieve a good level of sharing and isolation with IBM BPM products. It demonstrated how to create a virtualized shared service environment, in which your application development teams can quickly get started without the need to install any software on their personal workstations. Establishing a centralized organization to manage a shared environment should enable more standardization, consistency and reuse.

A shared environment also brings new business and technical challenges. For example, coordination and agreement on software versions between tenants is required. The load of the system now becomes the sum of the load from N tenants instead of 1. In future articles, we'll share with you additional techniques for dealing with these issues.



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, Cloud computing
ArticleTitle=Delivering Business Process as a Service (BPaaS) on the IBM SmartCloud, Part 2: Sharing the BPM middleware among multiple tenants