The IBM WebSphere Portal family provides ready-to-use tools and components to build personalized and highly-interactive user interfaces for enterprise applications. The IBM BPM product suite, in contrast, provides excellent tools for modeling, running, and monitoring BPM applications, but lacks the more general enterprise portal features in its built-in, BPM-specific user interface. This article explores the options for leveraging the strengths of both technologies, and integrating them into a single, unified solution.
Previous treatment of this subject matter has focused on WebSphere Portal as a user interface to BPEL processes. The integration of Lombardi® technology into the IBM Business Process Manager family has prompted us to revisit this topic. Lombardi provides a distinctive feature for agile development of the web pages needed for human interactions that has been embraced by IBM in subsequent BPM product development. These user interfaces, or "Coaches," are developed and managed together with the business processes. This allows a very short development-test-feedback cycle, delivering on the promise of agile development. On the other hand, custom-developed user interfaces based on the published APIs can be integrated more tightly into the portal environment.
We'll start by recapping the motivation for integration. Since IBM Business Process Manager Standard ships with an embedded user interface, and the Advanced edition also includes Business Space, it's natural to ask what might compel a solution designer to consider a Portal integration. Putting two different products together is more complex than using only one. It's reasonable to consider the costs and benefits before proceeding.
The out-of-box user interfaces in the IBM Business Process Manager platform provide ready-to-use, web-based user interfaces that are well suited for human interaction with business processes. These tools are a good choice when the user interface is primarily within the context of a process flow. But very often, a business user requires more tools in the context of the broader business environment. IBM WebSphere Portal is an enterprise-ready portal platform to address such requirements. It provides the ability to integrate different user interface components to present web content and collaboration capabilities in the context of a human task. For example, an integrated IBM Lotus® Sametime® portlet can show a listing of the users who have worked on a specific process instance. Such a feature would allow a business user to easily start a chat session with any of these individuals, to share information about the process instance.
Other possible use cases might include:
- Presenting product information using IBM Lotus Web Content Management in the context of a purchase order process.
- Using the integrated IBM Lotus Connections portlets to search for people when working on human resources processes.
- Downloading an order document from the Lotus Quickr portlet when releasing an invoice receipt.
Finally, WebSphere Portal allows the solution developer to leverage assets in the IBM Lotus and WebSphere Portal Business Solutions Catalog. This repository contains thousands of ready-to-use user interface components provided by IBM and IBM business partners. Leveraging these components can save time and expense.
Let's now explore the use cases that a WebSphere Portal - Business Process Manager integration must support.
Overview of the integration use cases
BPM is a management discipline supported by technology. BPM as a technology has grown out of workflow automation (to distribute tasks to users based on information technology instead of paper) and has added analysis and reporting, backend integration (enterprise application integration, or EAI) and SOA, as well as business rules and document management. Looking at Business Process Manager V7.5 from an end-user interface point of view, the workflow aspects are still the most frequently used. Part 1 of the Business spaces for human-centric BPM series lists a set of typical BPM user interaction patterns. We will look at the following minimal subset of these patterns in more detail in this article :
- Initiating a process or service
This pattern usually begins with viewing a list of process templates that can be started by the currently logged-on user. Some business processes are kicked off in an automatic fashion, such as an accounts payable process, which is typically started by an OCR software scanning an incoming invoice. On the other hand, some business processes are started by humans, and need a user interface to initiate the process based on a certain template. Depending on the BPM technology, processes may require template-specific input data structures to start. In that case, the user interface must also provide a form for the user to enter the required data.
- Get next task from list
While some business processes run automatically in a straight-through fashion, most business processes require human interaction. For instance in an invoice receipt process, invoices must be accepted by an authorized person. For this, Business Process Manager creates a task, which is assigned to a certain user or group. A user can view the work that is available, sort it based on certain criteria (such as priority, due date or maybe some scenario-specific attributes) and trigger the Completing Work pattern from there.
- Completing work
To work on a task, such as approving an invoice, the user must be able to view the task input data, to enter the task's results and to complete the task, telling the process engine to advance. These task-handling user interfaces are likely to be specific to a task and developed individually. In a portal context, these are typically portlets that run beside task supporting portlets, which support the decision process of the user. For example, for an invoice receipt process, the actual task portlet could display the scanned invoice data and the UI controls for approving or rejecting the invoice, while a supporting portlet could provide the user with tools to search and display the complete order history.
Measurements and reporting are one key factor that distinguishes BPM from workflow automation. This is what provides decision makers with visibility into their business processes and gives them new capabilities to manage those processes. We will therefore add a fourth pattern:
Viewing performance reports and tracking in-flight processes allows decision makers and team leads to judge team performance and to subsequently improve the process performance. This data is automatically collected in a performance warehouse by the BPM engine and needs to be visualized to the end user.
Since BPM is a complex discipline and today's BPM software packages offer many features, there are many more use cases not covered in this article. These include canceling a process, escalating or deferring a task, requesting help, viewing a list of running processes, and more.
There are at least two considerations that must be handled for all integration approaches. We'll review those in this section.
Single sign-on prerequisite
Single sign-on (SSO) is a common prerequisite that applies to all Portal-BPM integration options. With SSO, the user's authentication with Portal is automatically propagated to the BPM system. Without this feature, the user would have to perform a separate authentication with with the BPM system before accessing its features. SSO is achieved by establishing a common security context between WebSphere Portal and the BPM system.
Readers who are already familiar with WebSphere architecture will be aware that every WebSphere instance is created within an administrative domain, known as a cell. Each cell establishes a trust relationship among its members. Most WebSphere products create a new, unique cell when they install (containing only the installing product), unless some specific configuration actions are performed. This is true for WebSphere Portal and for Business Process Manager. By default, both will install into separate cells, and the trust relationship between the cells needs to be explicitly configured.
You could establish the trust relationship by federating Portal and Business Process Manager into a single cell. This would, however, introduce additional dependencies, such as common version levels for the deployment manager in a clustered environment. A frequently used alternative in WebSphere server environments is cross cell authentication. Cross-cell authentication is relatively straightforward and provides a more general purpose solution for satisfying this requirement.
SSO builds on the trust relationship by automatically exchanging user credentials among participating members. Participating cells must reference a common user repository, and LDAP is typically used. In addition to configuring LTPA and setting SSO enablement, you will also need to set a custom property in the Business Process Manager stack to provide for reusing the Portal's session ID. For more information, see Resources.
In at-the-glass approaches, defined below, Business Process Manager V7.5 Coach UIs are displayed within the portal pages. In those approaches, a full page reload will also cause the Coach UI to be reloaded - without the data that has been entered into the Coach being submitted to Business Process Manager V7.5. This means that this information will be lost. It is therefore preferable not to use full page refresh, but instead to use client-side aggregation techniques. This way, only the changed sections of the portal page are refreshed. In recent Portal versions, this is an out-of-the box capability of the Portal product that needs to be enabled.
Overview of the integration approaches
Now that we have identified our key interaction patterns and the need for satisfying the SSO prerequisite, we are ready to consider the alternatives for implementing Portal - Business Process Manager integration. The best approach for a specific project is determined by the relative weighting of each factor in that project's decision criteria. A summary of frequently used decision criteria is provided at the conclusion of this section, but at least one of these factors needs to be explained here.
When integrating existing enterprise applications in a portal environment, you must make a strategic choice between two alternate strategies.
Integration at the glass describes the approach in which the portal server simply renders existing user interface components from various sources on a single page. This usually requires little effort because existing user interface content can be reused and the integration is very generic. However, integration across applications, such as with other portlets, is limited or non-existent. On the other hand, programmatic integration leverages the application programming interfaces (APIs) of the underlying application (the Business Process Manager platform, in our case). This approach usually incurs a higher development effort, but allows very specific user interfaces to be developed. Those user interfaces may even integrate with other back-end applications in the same portletm and can provide very specific inter-portlet communication methods.
Additional factors that are often heavily weighed include the availability and level of formal support for the approach, functional capabilities in the context of each required use case, consistency of the resulting user interface across all portlets, compatibility with security and other operational factors. We will consider these factors and others as we explore the integration options that follow.
Business Process Manager Advanced widget
The native user interface of Business Process Manager Advanced is provided by the Business Space component. Business Space is not a product, but is a web application that provides a user interface framework for aggregating content and delivering it via a browser. Conceptually, it provides a mashup container that is specifically designed for BPM applications. IBM iWidgets are the pluggable user interface components that you use to populate these mashup pages. iWidgets are supplied with various IBM products related to BPM, including IBM Business Monitor, IBM Case Manager, WebSphere Business Events and WebSphere Registry and Repository. Many of these products also support running the iWidgets supplied with their product in IBM WebSphere Portal. For example, Figure 1 shows two of the widgets supplied with Business Process Manager Advanced running on WebSphere Portal pages.
Figure 1. Sample iWidgets supplied with Business Process Manager Advanced running on WebSphere Portal pages
Business Process Manager widgets in Portal follow the integration at the glass paradigm. The Business Process Manager Advanced widget catalog is loaded into Portal V7.0, and the widgets become available as portlets. As such, they can be added to portal pages together with other portlets. Aside from some administrative differences, the widgets have all the same capabilities as if they were running in Business Process Manager Business Space. Since all required components for this integration approach are provided with the products, this is the preferred integration approach if the capabilities provided by these widgets suffice and the version prerequisites can be met.
Business Process Manager Business Process Definitions (BPDs) allow for two ways to start a process. Under the first scenario, a BPD instance is created without input data. The first task in the process is assigned to the initiating user, where he or she enters the process input data. In the second scenario, an exposed human service, that is, a human service that has been configured to be started outside a BPD, collects the process input data and triggers the BPD instance using inter-process communication facilities. The first approach is simpler and commonly used in the Business Process Manager process portal, an out-of-box dashboard for viewing and managing processes. (For more information, refer to Starting Process Portal) in the Business Process Manager Information Center.) However, this has a drawback: if the first task is canceled, there are process instances without useful instance data in the system. The second approach is a bit more involved from a development point of view. The Business Process Manager Advanced widgets only support the second approach (see Business spaces for human-centric BPM, Part 2). This means that existing processes might have to be adapted to be able to be started from WebSphere Portal. The Task Definitions widget displays the exposed human services - if such a service is started, the Coach will be rendered in the Task Information widget.
The "Get next task from list" pattern is supported through the Tasks widget, which can use custom queries to show exposed business data in the task list. This allows users to prioritize and filter their task lists. Once a task is opened, its Coach UI is shown in the Task Information widget, where users can work on the task ("Completing work" pattern). There are no specific reporting widgets available. However reports can be embedded into Coaches, which are then exposed to be viewed through the Task Information widget.
This approach requires a little additional development effort on the Business Process Manager side, and is explained in great detail in the developerWorks series Business spaces for human-centric BPM. Part 1 provides an overview of the available widgets and supported patterns, while Part 2 details how to interact with BPD processes. A planned future part will explain how to set up the widget - Portal integration.
Unified Task List package
The IBM Lotus and WebSphere Portal Business Solutions catalog provides a number of ready-to-use Portal-based solutions to address different integration requirements. The catalog includes the Unified Task List package (available for download), which is IBM developed and supported, and available for download at no charge. This technology is also included in the Beta 2 release of WebSphere Portal V8. The Unified Task List package contains a portlet that displays a user's work list from a single workflow engine or federated across multiple engines. It has a customizable user interface and can launch configurable actions to process a task, covering the "get next task from list" process interaction pattern. The Unified Task List is based on the concept of task providers, which provide a service to retrieve tasks for a specific process or workflow engine. The base package contains task providers for IBM WebSphere Process Server V7.0 and IBM WebSphere Lombardi Edition V7.2.
Figure 2. The Unified Task List and Coach detail portlets
For the "completing work" pattern, the Unified Task List package contains a Lombardi Coach portlet that integrates a specific Lombardi Coach in an IFrame. There are two flavors of this portlet. The first receives the selected task by way of inter-portlet communication, while the second receives the task ID from the page context. The latter can be used to place this portlet on a dynamic portal page, that is, a page that is created during run-time based on a template and inserted into the navigation tree of the current user. That way, a user can work on multiple tasks concurrently: each task is opened on a separate page, and the user can switch back and forth among the open pages.
There is a restriction in the current implementation for services implemented as external activities. Unlike human services, an external activity does not contain an internal processing flow, but rather, only defines a set of inputs and outputs. When a running process encounters a task implemented as an external activity, the process flow is suspended until an external system uses one of the available APIs to set the service's output values and mark the task as "Finished." The Unified Task List can display these external activities in its task list, but cannot launch them as it can with human services. This is due to the nature of the Unified Task List's task provider for BPD tasks, which does not provide for the necessary configuration steps for external activities.
The Unified Task List package does not support the "starting a process or service" interaction pattern for the Lombardi component of Business Process Manager, only for the BPEL component. It can work with a custom-developed portlet that starts a process by displaying a Coach as the first activity of the process. As with the Business Process Manager widgets, there is no portlet for reporting, but you can embed a report within a Coach.
The Unified Task List can be used either out of the box, or as a starting point for custom development. As an IBM Web Experience Factory application, the package includes models, profiles and web resources to generate web applications and portlets. It contains the configured models for the task list portlet and the Coach integration portlets, and the task provider models for WebSphere Process Server and WebSphere Lombardi Edition. Samples, builders to integrate Process Server tasks and launch dynamic portal pages, as well as additional task providers are available in the IBM WebSphere Portal Unified Task List Developer Pack, which is also available free of charge from the catalog.
Custom development using the REST API
If you have specific integration requirements that cannot be met with the pre-built options described above, it may make sense to build your own portlets to integrate Portal and Business Process Manager. This is a programmatic integration approach, which can therefore pull together information from multiple sources into a single portlet, and can provide very specific inter-portlet communication methods. Custom development naturally requires a higher level of effort to create, test and maintain the solution, but the advantages are a very customized integration which exactly fits your project's specific needs.
As described in Advanced techniques and patterns for business process client development, written by one of the authors of this article, a process engine must provide an appropriate API to enable personalized UI development. Business Process Manager products expose their internal user interface models through both web services and Representational State Transfer (REST)-based APIs. REST is a lighter weight approach as compared to SOAP, and is particularly well suited to user interface construction.
Figure 3. UI model for BPD processes
A process is defined by a set of orchestrated services. A task is an instance of a service within the context of a specific process execution. When building a custom UI, you will be using the API provided for interactions with the Process Instance, Service, and possibly Task interfaces. It's possible to either build an alternate UI for an existing human service (essentially building a facade for the Coaches which make up that service, and which can also be used to automate those Coaches), or to build an external UI where only a placeholder (an external activity) is specified in the process definition.
Business Process Manager V7.5 Advanced provides a "federated" version of the API, in addition to the native API provided in BPM Standard. The native API provides a richer interface for BPD resources (more resources, more request methods). The latter provides only a subset of functionality, but provides federation across multiple (different) BPM systems. This means that it aggregates the data from multiple Business Process Manager back-ends for the user, and routes changes to the appropriate back-end system transparently. The federated REST API is only available in Business Process Manager V7.5 Advanced, while the native REST API is available in all product editions.
Some tools and assets are available for accelerating custom development. IBM Rational® Application Developer provides wizards and editors to create and consume RESTful web services. The Web Experience Factory included with WebSphere Portal provides a dedicated REST Service Call builder for consuming REST services. It generates an XML schema that describes the result structure and methods to execute the REST call and transform the result to XML by providing a restructure handler. This allows for wrapping the REST service call in a service provider model which can be consumed by user interface specific models. The separation of service and user interface models is a Web Experience Factory best practice that allows a clean separation of responsibilities.
Also, as mentioned earlier, the Unified Task List asset is built on WebSphere Experience Factory technology. The source for the WebSphere Experience Factory models is included in the distribution package. A developer is free to download and use these models as a starting point for developing other custom portlets.
Custom development using the web API (SOAP)
A fully supported SOAP API has been provided with the standard product since Lombardi Teamworks V6. This API provides for programmatic integration under a HTTP/SOAP protocol, and supports all patterns. To ensure compatibility with older clients, this API is not based on the WebSphere Application Server web services stack, but has its own Apache AXIS implementation. This means that single sign-on via LTPA is not supported. However, it can be implemented using MS Active Directory / Kerberos (Refer to this Technote). Integrating Business Process Manager V7.5 using the SOAP API is similar to the REST API approach and results, however the lack of a common SSO technology with WebSphere Portal makes this approach less convenient to use.
Coach - portlet interaction
The final integration approach is not an alternative, but rather a supplement to the at the glass approaches presented earlier. Its core idea is to provide a method so that Coaches can send data to other portlets and portlets can send data to Coaches. This bridges the at the glass and programmatic approaches, making Coaches a first-class citizen in the portal environment that are able to interact with others. Figure 4 shows an example of this approach, where a coach displayed in the Task Information widget interacts with a Google Map® portlet, so that the map reflects the location information in the task.
Figure 4. IBM BPD Coach portlet interacting with Google Map portlet
- Work around the browser's same origin policy: For this, both the Coach and the portal page need to appear as if they are coming from the same server (name and port). You can achieve this in two ways: In the first approach, an HTTP server is configured to serve content from both Business Process Manager and Portal, and the browser retrieves the content from that HTTP server. In the second approach, the portal's AJAX Proxy is used to retrieve the Coach and serves it directly from the Portal. The latter approach is used when using the iWidget integration.
- Make it seamless: A full page refresh would lose any data entered in a Coach that has not yet been submitted. To prevent this from happening, enable client-side aggregation, which will cause only the target portlet of the interaction to be refreshed.
Summary of integration options and evaluation criteria
We conclude this discussion by summarizing how each integration approach performs with respect to a comprehensive range of evaluation criteria.
|Approach vs.Criteria||BPM iWidgets||UTL asset (out-of-box)||Custom development with REST API||Custom development with Web API||Custom development with Coach-Portlet|
|Integration strategy||At the glass|| Programmatic (task list),|
At the glass (Coach)
|Programmatic||Programmatic||At the glass and programmatic|
|BPM product supported version||BPM V7.5 (Advanced only)||Task List portlet: WLE 7.2 out-of-box, other versions require WEF development. Coach portlet: Any BPM / WLE version.||WLE 7.x (community support only), BPM V7.5 (any edition)||WLE 7.x, BPM V7.5 (any edition) and earlier||All|
|Portal supported version||7.0.1 +||7.0 (earlier versions should work if rebuilt with WEF)||All||All||All versions with full page refresh, 6.1.5+ with partial page refresh|
|Supports "Initializing Processes and Services" pattern||Yes, via Task Definition and Task Information widget. May require BPD redesign.||No (other portlets must start the BPD)||Yes||Yes||No (other portlets must start the BPD)|
|Process initiation via exposed human service or invoking the process without business data||Exposed human service only||Supports both approaches||Both||Both||Supports both approaches|
|Supports "Get next task from list" pattern||Yes, via Task list portlet||Yes, via Task list portlet||Yes||Yes||No|
|Federated Task List||Yes (BPM V7.5 BPD and BPEL processes)||Yes (WLE V7.2, Lotus Workflow and WPS BPEL processes, others available but unsupported)||Yes (provided API availability in target BPM system)||Yes (provided API availability in target BPM system)||n/a|
|Business data from tasks in task list||Yes||No (Yes with custom development)||Yes||Yes||n/a|
|Supports "Complete work" pattern||Yes, via Task Information widget||Yes, via WLE Coach portlet||Yes||Yes||Yes|
|Can launch external activities||Yes, but widget interaction supporting external activity must be custom developed.||No||Yes||Yes||n/a|
|Supports "Reporting" pattern||Partially, by embedding reports in a Coach and viewing them in the Task Information widget||Partially, by embedding reports in a Coach and viewing them in the Coach portlet||Yes||Yes||n/a|
|Re-uses Coach UI||Yes||Yes||No||No||Yes|
|Content inherits Portal look and feel||No||Task list: yes; Coaches: no.||Yes||Yes||n/a|
|Portal constraints||Requires Page Builder Theme and client-side aggregation||Client-side aggregation preferred for Coach UI||None||None||Client-side aggregation preferred for Coach UI|
|Single sign-on mechanism||LTPA||LTPA||LTPA||Kerberos / Microsoft Active Directory||n/a|
|Required development effort||Low||Low||High||High||High|
|IBM support||Full product support||Business Solutions Catalog support (if asset not modified)||Full product support for the API in BPM V7.5, community-based support for earlier versions||Full product support||No|
|Other||Configurable actions allow for custom interaction scenarios, constraints on the operational model (AJAX Proxy)||REST API changed from WLE 7.x to BPM V7.5. Need to plan for migration efforts.||Constraints on operational model (HTTP server / AJAX Proxy) – see text|
Note: For the purposes of this table, the following abbreviations have been used:
- BPM = IBM Business Process Manager
- WLE = WebSphere Lombardi Edition
- WEF = WebSphere Experience Factory
- WPS = WebSphere Process Server
The latest releases of WebSphere Portal and IBM Business Process Manager provide solution designers with new options for leveraging the strengths of both products in a unified solution. This article originated from the authors' collective effort to understand the range of options for integrating these technologies, and the relative costs and benefits of each approach. We believe that these new product capabilities, as well as the recent updates to the Unified Task List asset in the Business Solution Catalog, will enable the you to deliver more compelling BPM solutions, and at lower cost, than was previously possible. We hope that this overview will help you, the solution architect, to select the best integration approach for your environment.
We would like to thank Michael Friess for the insights he provided into Business Process Manager Advanced widgets and Business Space. David Rockett provided considerable help with our understanding of the Unified Task List, and also provided thoughtful review of an earlier draft of this article. Likewise, Eric Wayne provided review and guidance in the creation of this article.
- For matters relating to user interaction patterns with BPM, iWidgets, and the Business Space technology, refer to Business spaces for human-centric BPM. Specifically, refer to Part 1 for human interaction patterns with BPM, Part 2 for more technical information regarding iWidget integration, and Part 4 for custom widget development.
- The WebSphere Application Server Information Center provides guidance for configuring LPTA, SSO, and cross cell authentication in the topic Developing client applications using IBM BPM REST APIs. The WebSphere Portal wiki topic Setting up single sign-on for WebSphere Application Server provides an alternative set of instructions to perform the same tasks.
- When configuring BPM for SSO with portal
for the at the glass approaches, the custom property
HttpSessionIdReusemust be set to true in the BPM stack. This ensures that the
JSESSIONIDvalue from the WebSphere Portal is reused in the BPM stack (instead of creating a new one and overwriting the Portal's session id value). Refer to Session management custom properties in the WebSphere Application Server Information Center for further discussion.
- The tech note How to setup Single Sign-On (Kerberos) on WebSphere Lombardi Edition 7,1 on Windows provides instructions for configuring SSO in the absence of LPTA support (as required if using the web API).
- Refer to Developing client applications using IBM BPM REST APIs in the IBM Business Process Manager Information Center for more information on the REST API.
- Make sure to check out the REST API testing tool if you are developing code that uses the REST API. Nikhil Thaker provides an API overview in Introduction to REST API in IBM Business Process Manager, Version V7.5.
- Refer to Sandro Schwedler's Advanced techniques and patterns for business process client development (developerWorks, 2008) for a discussion of prerequistes for general BPM engine integration.
- developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
- IBM BPM Journal: Get the latest articles and columns on BPM solutions in this quarterly journal, also available in both Kindle and PDF versions.
Get products and technologies
- Download the Unified Task List from the IBM Lotus and WebSphere Portal Business Solutions Catalog.