Realizing the value of IBM Business Process Manager in the WebSphere Portal environment, Part 1: Integrating WebSphere Portal with IBM Business Process Manager

The IBM® WebSphere® Portal family provides ready-to-use tools and components to build personalized, highly-interactive user interfaces for enterprise applications. The IBM Business Process Manager family has recently introduced a new, tightly integrated UI for task processing. By combining the strengths of both products, enterprises can gain a competitive advantage and reduce costs. In this article, you'll learn about the options for integrating WebSphere Portal with IBM Business Process Manager products, and how to select the right approach based on the needs of your particular integration project. This content is part of the IBM Business Process Management Journal.


Wolfram Richter, Certified IT Specialist, IBM

Wolfram Richter photoWolfram Richter is a consultant with the IBM Software Services for WebSphere organization. He has a 9-year history in IBM middleware and BPM technology, and specializes in integrating SAP solutions with IBM software. Before his current assignment, he worked as a pre-sales IT specialist and in education and training. Wolfram lives and works in Germany. In his spare time, he likes to spend time with his family, go jogging and fix things in his house. As he writes this, Wolfram realizes that there can never be enough spare time.

Sandro Schwedler, Certified IT Specialist, IBM

Photo of author, Sandro SchwedlerSandro Schwedler works as an Certified IT Specialist for IBM Software Collaboration Services. His areas of expertise include middleware, XML, Portlet, and Java Enterprise Edition (JEE) development. He holds a degree in Information Technology from the Berufsakademie Stuttgart, Germany.

developerWorks Contributing author

Kip Harris, Certified IT Architect, IBM

Kip Harris photoKip Harris is a consultant with the IBM Software Services for WebSphere organization, where he works with IBM business partners to deliver solutions across a broad spectrum of IBM products. His past work ranges from robotics to Assistive Technologies to smart electrical grids. Kip enjoys distance running and equestrian pursuits with his family in his off time.

29 September 2011


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:

  • Reporting

    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.

Common prerequisites

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.

Client-side aggregation

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
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
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.

The REST API is available out of the box in Business Process Manager and as a community-supported asset in previous versions of Lombardi. The API syntax changed as the feature became part of the formal product, so that the complete product API is more consistent across both BPD- and BPEL-based processes. All interaction patterns introduced earlier are fully supported, including initiating processes, claiming and completing tasks, and querying reporting data. The API leverages the four HTTP methods GET (list, retrieve), POST (create), PUT (update) and DELETE to access and modify server resources. A REST call can return its result as either a JavaScript Object Notation (JSON) or XML structure. Using the REST APIs in IBM Business Process Manager V7.5 provides an overview of the UI model and API. Figure 3 shows some of the objects in that model and their relationships.

Figure 3. UI model for BPD processes
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
IBM BPD Coach portlet interacting with Google Map portlet

This approach is realized using JavaScript. Coach-specific portlets provide JavaScript functions which can be invoked by or manipulate the Coach. This is usually prevented by the browser's same origin policy, but this prevention can be worked around through a specific infrastructure set-up. Data received from the Coaches can then be sent to other portlets using the Portal APIs and vice versa. Client-side aggregation makes the interaction appear seamless, since the data "magically" appears at the target without the page being reloaded. There are four major steps to realize this approach:

  1. 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.
  2. Enable Portal to receive data from a Coach: You can achieve this with a portlet that contains a JavaScript function that is invoked from the Coach. This function, which runs on the portal client-side, can then invoke inter-portlet communication methods. Note that this function can be provided by any portlet as long as it is on the same HTML page as the Coach portlet/widget itself. This means that you can develop scenario-specific portlets and use them in conjunction with a general-purpose Coach integration portlet/widget.
  3. Enable Business Process Manager to send data: The Business Process Manager Coach designer allows developers to add event handlers to any data field. An onClick handler on a data field could be used to collect the data that is to be sent and then invoke the JavaScript function on the embedding page. Since the same origin policy does not apply, JavaScript code inside the Coach (which is usually embedded in an IFRAME) can invoke the JavaScript function on the page by using a window.parent reference, such as window.parent.performSomeFunction(dataFromCoach).
  4. 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.

This approach also works in the opposite direction, that is Coaches can receive data from other portlets by a JavaScript function which modifies the Coaches' document object model (DOM).

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
Coach-Portlet interaction No No n/a n/a 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.



Get products and technologies


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 WebSphere on developerWorks

ArticleTitle=Realizing the value of IBM Business Process Manager in the WebSphere Portal environment, Part 1: Integrating WebSphere Portal with IBM Business Process Manager