The Business Process Accelerator (BPA) is an extension to an existing WebSphere Portal Server environment, adding integrated forms handling and presentation capabilities as well as end-to-end business process automation.
The following diagram represents a high level view of the participant components of WebSphere Portal, WebSphere Process Server and Lotus Forms involved in designing, deploying, and running BPA applications:
As this diagram indicates, there are two primary design steps:
Designing Business Processes and,
Electronic Forms as their human interface.
Each design process results in artifacts that are then stored in repositories available to the BPA runtime framework.
To get a more detailed view of the BPA framework you can divide up the BPA components into different layers. The following diagram shows the respective components in the UI, Application, Business and Data Layer.
There are different participating roles accessing the BPA design and runtime components through the UI Layer. The client and portal administrator use a standard browser to access the BPA environment within WebSphere Portal. The client will access the form list and Forms View Portlet to either start a new business process or participate in a running process. The portal administrator will configure the WebSphere Portal environment to match the BPA topology.
The following sections describe the components contained within each of the layers shown in the diagram above.
The business analyst would typically begin by using the WebSphere Business Modeler (WBM). WebSphere Business Modeler (WBM) is an excellent tool for defining business processes at a high level and then exporting technical artifacts from WBM for more detailed process definition within WebSphere Integration Developer (WID). WBM is designed for non-IT users who can start the definition from a purely business perspective and generate artifacts that can be directly imported into the WID environment.
The process developer would leverage the process design capability of WID, which has been augmented by the Business Process Accelerator framework to make it much simpler to associate specific electronic forms with process tasks. This also allows for presenting highly personalized information in context to an active process using a more automated approach. WID has been engineered (via the BPA framework) to generate forms that contain schemas that represent the state and embedded information necessary for a portal user to complete a step in the business process.
As a next step, the form designer would then enhance the WID generated forms by modifying the layout and presentation, as well as adding business logic to them. Since the Lotus Forms Designer can be plugged into both the WBM and WID, there is a single integrated development environment for both the business process and form design work.
In the application layer you will find the WebSphere Portal Server as well as the Lotus Forms Webform Server and Services Platform, all running on a WebSphere Application Server environment.
The business layer contains the respective business process management servers, which in case of the BPA framework is the WebSphere Process Server. There are plans to support additional workflow engines like the WCM CheckList or FileNet P8 Process Engine.
The data layer covers the necessary repositories to store forms, templates, instances and metadata. The BPA framework in its first release currently supports Lotus Quickr and the filesystem as repositories. For future releases, there are plans to support additional systems including FileNet P8 and DB2 CM.
The following section describes the role and functional benefits provided by WebSphere Portal and Lotus Forms as underlying components within Business Process Accelerator. (See also 1.1 Underlying technologies to Business Process Accelerator)
WebSphere Portal provides a highly personalized experience for customer staff, business partners, or customer clientele who may be participants in business processes. Portal provides the necessary authentication and authorization services to enable work tasks to be delivered to the right person at the right time. Waiting tasks can generate alerts which can be signaled to the portal user; task lists can provide information which allows the portal user to claim and work on items in context; and task processing can be integrated back into the running business process in a way that eliminates delays and accelerates the completion of work.
The role of the Forms server is to deliver electronic forms agents on demand. Lotus Forms provides an excellent way to not only collect data from human task participants, but also to pre-populate personalized, contextually appropriate data into forms to help those participants respond more quickly, and to create “documents of record” which can help satisfy legal and audit requirements. In the BPA scenario, this means that portlets exercising the Forms Server API can build lists of forms and load form templates, as well as pre-populating data into forms. It is important that the data schema definitions match between the process definitions with its corresponding business object and the instance data defined to the form. WebSphere Process Server is not forgiving about empty data elements where it expects a value to be present in the business object, so there is some consideration to be made here regarding the data definitions in the persistence layer.
BPA Run Time Topology
The following diagram shows the BPA run-time topology with the respective components and their interactions.
The Unified Task List Portlet presents a list of available tasks for the current user in Portal by connecting to the Process Server via web services.
The Forms List Portlet presents a list of available forms from the designated template repository.
The Forms View Portlet then renders the previously selected form through the Webform Server and stores the filled form in the form repository. Additionally, it communicates with the Process Server through the BPA framework to either initiate a business process or satisfy a human task for a running process.
The BPA currently supports the File System and Lotus Quickr as repositories through the Quickr REST API.
Example of Run Time Topology used for fictitious scenario exercise
The runtime topology is represented by the following diagram showing the overall framework including security, networking, and high availability options. This depicts a baseline architecture, as well as illustrating which elements were and were not implemented for this redbook exercise due to limitations of scope and available time. (Note that the boxes shown in gray are recommended as best practices, but were not actually implemented in our sample lab environment.)
This diagram includes elements (shown in gray) that are recommended best practices components like a user registry (LDAP) or fault tolerant redundant components. As mentioned above, the elements shown in gray were not implemented for this redbook exercise due to limitations of scope and available time.
On the WebSphere Portal side, the BPA frameworks ships a set of three highly configurable portlets, the Forms List Portlet, the Forms View Portlet and the Unified Task List Portlet.
In the BPA scenario, this means that a task-processing page could be populated with the following useful portlets:
A portlet that shows a list of tasks available to work on – the Unified Task List Portlet – in our case this means a list of orders in progress. (See Step 2 Review Order for an example of the Unifiied Task List Portlet used in the Redbooks Wiki Sample Scenario.)
A portlet that shows detail information for a selected form – the Forms View Portlet. (See Step 1 Initiate Order for an example of the Forms View Portlet used in the Redbooks Wiki Sample Scenario.)
A portlet that shows a list of forms ready to be claimed by the logged-in user (as a member of a group that can ‘claim’ work of that type) – the Forms List Portlet – in our case this means a list of forms that can be used to Create a new PO. (See Step 1 Initiate Order) for an example of the Forms List Portlet used in the Redbooks Wiki Sample Scenario.)
A properly configured BPA environment will result in the portal being able to retrieve forms from the forms repository and to then use them as templates to create new business processes, or to participate in running business processes.
Forms List Portlet
The Forms List Portlet presents a list of available forms to the client either generated automatically from the form repository or through a given page handling list URL. When the user selects a form, the Forms List Portlet pushes that information to the Forms View Portlet, which then opens the form from the repository and renders it through the Webform server. The client can then fill the form and submit it back into the Forms View Portlet which then stores the form in repository and triggers the configured business process through the BPA framework application.
When the user navigates to a Portal page containing the Forms List Portlet, the portlet requests a list of forms available to the current user from the BPA Framework. The BPA then queries the Process Server for process templates that the current user can start and maps available forms in the repository to these accessible processes from the published metadata. A list of respective forms is then returned to the Forms List Portlet and presented to the user on the Portal page.
The Forms List Portlet is one of the pre-packaged components included in the BPA framework. It is constructed to be sensitive to the role of the person involved in the processing of human tasks, and is able to filter the list of forms so as to personalize the list contents. In the case of this redbook exercise, we needed to be able to allow a Purchaser to initiate a business process by submitting a form and a Reviewer to review the contents of the order and either approve or send back for rework. (See Overview of the Process Flow for additional information on the flow and the roles.) Finally, a Supplier can complete the order fulfillment process. The Forms List Portlet provides a mechanism to receive a filtered list of forms, tailored to the role.
Forms View Portlet
The Forms View Portlet is used to render either the selected form from the Forms List Portlet or the corresponding form to a claimed task in the Unified Task List Portlet. The following diagram shows the task flow of a form request through the Forms View Portlet, while the path through the Unified Task List is described in the following section (Unified Task List Portlet).
Flow involved in submitting a form
The next diagram in this sequence represents the flow involved in submitting a form. There are two use cases for a form being submitted through the BPA related to the Process Server.
It can either start a new business process or,
It can complete a human task that is part of an already running process.
The following diagrams illustrate the specific set of steps the BPA framework will accomplish on behalf of the logged-in user and the WPS-maintained business process for the two use cases:
Note: It is at submit time that the data entered into the form may be optionally extracted and sent to any back-end system involved in the larger process flow, as well as archival of the form in its entirety for retention purposes.
In this next diagram, this illustrates the case of a human interfacing task completed with the data from the Lotus Form. The difference to the previous diagram is concerning the communication of the BPA with the Process Server.
Unified Task List Portlet
The Unified Task List Portlet is sensitive to the current tasks on WebSphere Process Server for an authenticated user. The logged-in portal user will be presented with a list of running tasks which are in a state that allows involvement by the portal user (typically either available to be claimed, or already claimed by the user or someone else in the user’s role). Claimed tasks will then provide a link to a dynamic portal page which contains the Forms View Portlet again to display the configured for the claimed task for the client. In this case, there is also a direct interaction with WebSphere Process Server when a task is claimed. This step allows WPS to mark the task claimed, changing the state for all other interested parties and participants. The following diagram shows the task flow when a form is selected through a claimed task in the Unified Task List Portlet. (See also Step 2 Review Order for an example of how the Unified Task List was used in the context of the fictitious scenario.)
After communicating the task id through the Property Broker to the Forms View Portlet, the task flow is the same as through the Forms List Portlet described in the previous section.
The Unified Task List has been constructed to show all available tasks associated with the role of the logged-in portal user. These tasks may be in any of several states:
available to be claimed;
claimed and “in progress”, or,
claimed by others in the same role.
Furthermore, the Unified Task List includes different task provider implementing data access to different workflow systems. This can be a WebSphere Process Server or Lotus Domino Server, but also any other workflow engine through a standard interface as shown in the following diagram.
To store the forms and the respective metadata on the server, the BPA needs four dedicated repositories as shown in the diagram below:
The forms need to reside in a repository; IBM provides two options:
publish to and retrieve from the File System, and
publish to and retrieve using a REST API which can be used with any repository supporting such an interface, including Lotus Quickr.
Using the File System is simple and is the option used by the redbook team for this exercise. The following diagram shows the structure of the file system repository when publishing a form with the Forms Designer.
Quickr using the REST API
The use of Lotus Quickr was beyond the scope of this redbook exercise; however standard REST API procedures are supported. Please see this link (http://www-10.lotus.com/ldd/lqwiki.nsf/dx/search-services) containing an example of invoking Quickr’s search service through the REST API for more information on using Quickr or any other REST compliant repository to store forms and metadata.
Other Repository Options
The BPA Framework employs the Quickr REST API to create and interact with the Form, Template, Instance and Archive repositories. The underlying technology for any one of these repositories could be any content management system which provides a Quickr REST API interface (Lotus Quickr, FileNet P8 ECM, DB2 CM, etc).
The BPA framework is flexible enough to work with a wide variety of back-end systems as necessary for process integration as well as for persistent storage of critical data where appropriate.
WebSphere Process Server (WPS) is a necessary and critical back-end for the BPA environment, particularly as it pertains to the example this redbook team exercised, although the BPA architecture is open enough to allow the use of other process runtimes. Using WPS has many advantages:
Combining both automated and human tasks together to simplify the design, definition and runtime execution. Short-lived, “straight-through processing” tasks can be fully automated and fulfilled without involving people, while long-lived human tasks can be efficiently delivered in a personalized, role-based manner to as many human agents as might be needed to provide the necessary throughput.
Awareness of the identity of portal users through WebSphere’s authentication mechanism and the Single Sign-On (SSO) architecture of WebSphere makes it possible for the process designer to target tasks for specific roles or groups, knowing that the WebSphere Portal server is tied into the same security model and can direct those tasks to only those human actors who are designated to work on them.
Persistent safeguards for in-progress work. Processes may run for very long periods – days, weeks, months or longer in some cases. WebSphere Process Server is designed to persistently manage long-running processes and to retain state information across system shutdowns and restarts.
Extensive auditing options. Long running business processes and individual tasks are timestamped and logged extensively through the work life-cycle. As a result, monitoring can be performed through WebSphere Business Monitor or less formal mechanisms to afford management a constant “dashboard” view of how work is flowing through the system and where corrections can be made to handle abnormal situations. Analysis of workflow becomes straightforward, as well as the ability to satisfy auditing requirements.
FileNet P8 BPM
Since IBM’s acquisition of FileNet a few years ago, FileNet’s capabilities have grown beyond the traditional Enterprise Content Management (ECM) heritage; FileNet Business Process Management (BPM) is also an excellent process runtime, particularly well suited to architectures where FileNet is being used for content management, imaging and retrieval requirements.
The Business Process Accelerator offers the same architectural approach for FileNet BPM as has been described here for WebSphere Process Server. While the deeper integration of development tools (e.g. BPA plug-ins for WID) is not identical, the loosely-coupled nature of the process runtime interacting with WebSphere Portal and Lotus Forms (largely through web services invocation mechanisms) makes FileNet another excellent candidate to fulfill the process runtime role.
BPA Framework DesignTime Topology
The BPA framework provides components and plug-ins to the topology that facilitate an integrated form design lifecycle with automated form generation and deployment to the runtime environment.
The next diagram illustrates how the BPA framework (plug-ins to WID and Lotus Forms Designer) fit into the design time architecture:
The diagram shows that there are four existing extensions to WID and the Forms Designer that allow for automated test and deployment of business process and forms. The WebSphere Integration Developer lets you deploy your business process application directly into the WebSphere Process Server run-time for test and deployment purposes. Also, the WID plug-in shipped with BPA can generate Lotus Forms for all human interfacing tasks of a business process that contain the schemas and information necessary for the user to complete the input or output message of a given task.
The Lotus Forms Designer lets you test and preview a form right in your design environment as a rendering of the Lotus Forms Webform Server. Also, the Forms Designer Plugin shipped with BPA permits you to deploy a given form directly to the configured repository along with its necessary metadata for business process integration.
WebSphere Integration Developer is the primary development environment for building out the BPA-based solution. Part of the functionality of the BPA framework is delivered through the tight integration of Lotus Forms Designer as a plug-in to the Eclipse underpinning of WID – once installed, it becomes a matter of two clicks to move from process design to forms design. This next screenshot is an example of the Business Integration perspective in WID:
This Business Integration perspective can immediately be switched to the Advanced (or Standard) Lotus Forms designer perspective by selecting it from the upper right corner of the IDE:
Although it is typical that the tasks of forms design and process design are performed by different developers, being able to build and test in this integrated environment provides a level of acceleration to the overall design process.
Plug ins for WID
The next diagram illustrates how WBM and WID can exchange design information as the business process is taken from a conceptual level to an implementation level:
Both, the WebSphere Business Modeler and the WebSphere Integration Developer are very sophisticated tools to create a process definition and a business object for a BPM project, which can then be published directly into Process Server from WID. In addition to this, the BPA plug-ins for WID enable you to generate Lotus Forms from Human Tasks that contain the respective data from the business object. The Lotus Forms Designer perspective can then be used to modify the layout of the form and add validation and business logic to the form. (For more information on this topic, please also refer to Section V - Building out the Business Process
Note that the existence of a process step that requires human intervention (Human Task) can automatically generate all the elements of a Lotus Form to facilitate the completion of that human step.
This diagram provides an example of how this automatic generation of a “Lotus Form for BPA Framework” might look. As mentioned previously, the use case for this redbook exercise was the initiating and processing of a purchase order with conditional logic being invoked to trigger additional workflow tasks if order quantity exceeds a pre-defined level; this screen shot shows the auto-generation option for the Lotus Form within WID:
This makes it much simpler to ensure that the data model is consistent between WebSphere Process Server and the form delivery mechanism being used to accomplish human tasks. Once generated, the form(s) can be further enhanced (rearranging data elements, adding decorative theme elements using the embedded Form Designer that is tightly integrated with WID and is simply another perspective in the same toolset.
Plug ins for Forms Designer
Lotus Forms Designer can work independently from the other design elements, but the native integration provided by the BPA framework is highly desirable and is recommended.
Forms can then be published out to the designate forms repository, and metadata about those forms (association with processes, for example) is also publishable to a separate but similar repository, as illustrated by the following diagram:
Note that the format of Lotus Forms is based on an open standard (W3C) called XForms, which provides powerful data manipulation and integration capabilities. The forms are defined as XFDL file types – eXtensible Forms Definition Language. The publishing of form metadata creates or updates the ‘mapping.xml’ file in the repository.
On the other hand, it is also possible to begin with the definition of the form (with its data model) and engineer the business process to match. The integrated tools provided with the BPA framework make it easier to start with any aspect of the business problem to be solved and rapidly construct the technical implementation elements.
Furthermore, the output of the WID/Form Developer is injected (through a “publish” process) directly into the runtime components, where they are available on demand in a highly context-driven manner. As the business process moves from task to task, the user interface (portlets delivered on a portal page) will dynamically present content to the human task participant which will make it easy for that actor to complete his or her task.
The BPA framework installation similarly affords the forms designer direct access to the data model(s) being used in the process design stage, making it much more efficient to ensure that the bindings between form elements and data elements in the schema / instance(s) are consistent and synchronized. Note the data instance information provided in the lower right pane of the Forms Designer below:
The same data instances bound to the form are utilized in the business objects being managed by WebSphere Process Server, making it more simple to use the Lotus Form as an intelligent agent for data collection and submission.
The following diagram represents the main administrative tasks necessary to prepare the portal components to deliver the personalized task information mentioned previously. For example, this first diagram shows the steps involved; notice that the Portal and BPA framework remove the necessity to use programming skills, and make this more an administration process:
Define processing pages(s) where in-context information will be delivered
Populate those pages with the special task-oriented portlets provided with the BPA framework – capable of delivering lists of forms, detailed views of single forms, and lists of tasks available for the logged-in user to take action on (in their role)
Configure each portlet so that content can flow into the portlet from the back-end information sources involved in the BPA runtime model
Once this page has been created and populated, the logged-in portal user has the ability to be involved in business processes in either of two modes: (1) to initiate a business process, or (2) to take action to complete a human task in a business process that is already running. The Forms List Portlet is designed to present to the portal user a list of forms that they can use to initiate a new business process.
In the case of our redbook exercise, here is an example of what this looks like:
*Note: this portal page has been populated with a special portlet (upper right) to allow the portal user to select from a historical record of previously processed orders to make the human task easier. This ability to present data from historical forms also allows the BPA framework to pre-populate the new order (entered using the Lotus Form) with existing customer data, streamlining the process and simplifying the human task elements.