Advanced techniques and patterns for business process client development
Running efficient business processes is a key factor for the success of a company. By running these processes, highly optimized and automated, companies can gain an advantage. Even though automation is always an objective for process designers, most processes require human interaction, at least in the cases of errors and exceptions. For these human interactions, enterprise IT must provide role-based and intuitive user interfaces.
Interaction between humans and processes
A business user client for a business process provides a user interface to work on tasks or work items generated by the process. For example, this can be an approval step for a vacation request or reviewing an invoice within an invoice complaint process.
From an abstract perspective, there are three different approaches for providing a process client. If the process primarily handles forms like an insurance application, presenting the form together with options to alter the form could be a very simple process client.
If an e-mail client like IBM® Lotus Notes® is the primary work place of the employee, the process engine can send and evaluate mail to communicate with the user.
Finally, Web-based business user clients can provide a modern and intuitive interface to the process with minimal requirements on the client system. WebSphere® Portal provides features like dynamic user interfaces and client side aggregation to fulfill such requirements. Additionally, Portal Factory expedites the development of Web and portal applications without Java™ coding.
Accessing the programming interface of the process engine
For the purpose of user interface development, a process engine must provide appropriate APIs, for example, process initiation, generating task lists, or complete a task. Depending on the process engine, this can be a Web Service, Java Interface, or proprietary programming interface, for example, DIIOP for Domino or Remote Function Calls (RFCs) for SAP R/3 systems.
Process Server provides an Enterprise Java Bean (EJB) and a Web Services based interface to fulfill these jobs (see Resources for more information about Process concepts and architecture).
Figure 1. IBM WebSphere Process Server provides an EJB and Web Services interface for client interaction
Using the EJB Interface, applications running in a J2EE (client) container can access Process Server functions in a J2EE environment. For authentication and authorization, the security context from the client container is passed to Process Server.
The Web Services interface provides a more loosely coupled approach to access Process Server operations. Although it provides only a subset of operations available in the EJB interface, all operations required for client development are available. The Web Services interface of Process Server requires a WS-Sec authentication header to enforce security. This can be an LTPA token or username-password combination.
WebSphere Portlet Factory as a business process client development tool
There are a number of different tools available that you can use for process client development. Form-oriented tools, such as IBM Lotus Forms Designer, provide a WYSIWIG editor to create forms visually but require more coding on the server side to program the code to execute functions of the process engine. Rational Application Developer provides a full set of wizards and editors for the complete J2EE development lifecycle.
WebSphere Portlet Factory (hereafter called Portlet Factory) provides a wizard-based and code-free approach for the development of Web and portlet applications.
Portlet Factory applications are based on code generators called builders (see Resources for an introduction to Portlet Factory). There are builders for data integration like the SQL Call or SAP Function Call builder and more user interface oriented builders like the View & Form or Dojo Drag Source builder. The capability to combine these builders without programming dramatically improves developer productivity.
Builders for integrating process engines
Portlet Factory provides different builders to access process engines:
- Lotus Domino based (for example Lotus Workflow). Use the Domino Access builder to access Domino-based workflow application like Lotus Workflow.
- SAP R/3. Use the RFC interface to access applications like SAP Business Workflow. Portlet Factory provides an SAP Function Call builder to leverage this interface.
- WebSphere Process Server interface: You can use
different builders to access the Process Server interface. For a
simple technical integration, you can use the Web Services Call or EJB
The Business Process Integration Extension for WebSphere Portlet Factory introduces new builders to access Process Server functions in a solution-oriented manner. It includes the Task Processing builder to work on human tasks (for example, initiating an Originating Task or completing a Processing Task) and the Human Task Query builder to generate task list applications. See Resources for a detailed introduction to this extension package.
Table 1. Describes the process engines and available builders
|Process Engine||Programming Interface||Authentication||Builders available for Portlet Factory|
|IBM Lotus Domino based, for example, Lotus Workflow||DIIOP||LTPA, Username/Password||Domino Data Access|
|SAP R/3 based, for example, SAP Business Workflow||SAP Remote Function Calls (RFC)||SAP Logon Ticket, Username/Password||SAP Function Call|
|IBM Process Server||Enterprise Java Beans, Web Services||J2EE Security Context, LTPA, Username/Password||Task Processing Action, Human Task Query|
Service provider as an abstraction layer for process engine programming interfaces
A common best practice in Portlet Factory development is to separate the user interface logic from the data access logic by introducing a service provider. A service provider is a separate Portlet Factory model that provides a well defined interface to data access and business logic.
The Business Process Integration Extension for WebSphere Portlet Factory provides âready to useâ provider for the Process Server Web Services interface. In fact, the Task Processing builder and Human Task Query simply generate code to include and execute this service provider.
Figure 2. It is a recommended best practice to separate the data access logic from the user interface
User interface patterns for business process client development
Personalized task lists for task management
A task list is an application that displays a personalized list of tasks that must be completed by the business user. Typically a task list displays generic information like task owner, creation date, or description.
For the implementation of a task list, the Process Engine must provide operations to retrieve the list of tasks and their related attributes. Process Server provides an SQL-like query language to retrieve these attributes. By defining a select, where and order by clause, this âTask Queryâ language allows you to retrieve all or a subset of tasks available for the current user.
These clauses are parameters of the query operations available in the Process Server EJB and Web Services interface of Process Server.
When using Portlet Factory as a client development tool, the Human Task Query builder available in the Business Process Integration Extension for IBM WebSphere Portlet Factory provides a very comfortable way to define and execute task queries. By defining the clauses of the task query, the builder generates a result variable that holds an array of tasks as well as an operation to fill this variable with the results from the task query.
Listing 1. Sample task query that displays the task attributes. The select clause selects the columns available in the result set. The where clause defines the rows included in the result set
A sample task query displaying the task attributes id, name, originator and owner for all participating tasks in state ready. Select Clause: DISTINCT TASK.TKIID AS TKIID, TASK.NAME AS TASKNAME, TASK.ORIGINATOR AS ORIGINATOR, TASK.OWNER AS OWNER Where Clause: TASK.PRIORITY<5 AND TASK.STATE=TASK.STATE.STATE_READY AND TASK.KIND = TASK.KIND.KIND_PARTICIPATING
Displaying business properties in a task list
Generic task attributes like description and creation date provide basic information about a task. Often a business user needs more attributes specific to a certain business process, for example, a job description in a hiring process or origin in a travel request process.
The query language of Process Server allows querying such custom properties, which have been initialized during process execution.
Listing 2. . Sample task query that displays standard task attributes and one custom attribute âjobIDâ.
A sample task query displaying the task attributes id, name, originator, owner and a custom property âjobIDâ for all participating tasks in state ready. Select Clause: DISTINCT TASK.TKIID AS TKIID, TASK.NAME AS TASKNAME, TASK.ORIGINATOR AS ORIGINATOR, TASK.OWNER AS OWNER, TASK_CPROP1.STRING_VALUE AS JOB_ID Where Clause: TASK.PRIORITY<5 AND TASK.STATE=TASK.STATE.STATE_READY AND TASK.KIND = TASK.KIND.KIND_PARTICIPATING AND TASK_CPROP1.NAME='jobID'
To initialize and set such a property, the process developer can add a Snippet Action and use the setActivityCustomProperty method of the HTM API of Process Server.
Processing and completing tasks
A task list works as a starting point to process and complete a task. By completing a task, the process engine continues the execution of the process and processes the data provided by the business user. Depending on the user interface technology, there are three approaches for providing user interfaces for task completion.
For simple actions that do not require additional user input, a task list can provide action buttons or actions menus, to complete a task. For example, for a simple approval step in an HR process, a task list can provide a menu with Approve and Deny actions. When you use Portlet Factory as a business process client development tool, you can use builders like the Contextual Menu and Image Button builder. If the task list displays tasks of different types, the menu entries can be different based on the type of task. To implement such a requirement, the Contextual Menu builder lets you dynamically enable and disable an entry based on data from a table cell. To hide an image button dynamically, you can use the Visibility Setter builder.
Figure 3. A custom task list portlet providing a menu for task completion
Opening tasks in parallel in an IBM WebSphere Portal based process client
A very common requirement for business process client development is the capability to open different tasks in parallel so the user can work on a task, launch a second task, and return to the first task if required.
By leveraging the Dynamic User Interface API in WebSphere Portal, you can implement this requirement by dynamically adding new portal pages to the navigation tree. These dynamic pages can provide different portlets to complete the task. These pages can also include portlets that provide additional information or functions. For example, these âTask Supportingâ portlets can show a Google Map widget or display a dynamic Sametime contact list presenting all persons involved during process execution.
The out-of-the-box Task List of WebSphere Portal uses this approach to integrate Process Server based tasks.
Figure 4. Dynamic pages in WebSphere Portal are transient pages only visible until task completion. In a business process client application transient pages include task portlets to complete human tasks.
The Portal Server information center provides more detailed information about how to use this API programmatically. If you want to use this feature in Portlet Factory-based portlets, you can use the Dynamic Portal Page Processing builder from the above mentioned Business Process Integration Extension package.
This builder provides two different modes. If you want to launch new dynamic pages, you can select the âLaunch Dynamic Portal Pageâ to let you enter properties of the new dynamic page as well as letting you enter properties transferred to the new page. For example a task portlet requires the task id of the task to work on. This task id can be transferred as page property to the transient page.
Figure 5. The builder interface of the Dynamic Portal Page Processing builder
Besides the Action Type, the builder provides the following inputs:
Table 2. Displays the inputs provided by the builder
|Unique Name of Dynamic Page||The unique id of the dynamic page template. Using the portal administration tools, you can define the unique id of a portal page working as template for dynamic pages.|
|Unique Name of Extension Node|| The unique id of a portal page
that works with a container for the dynamic page. The new page
becomes a child of this container. Tip: to
run as an Extension Node a page must be enabled for that. To
do that run, the appropriate config task, for example, in
WebSphere Portal 6.1: |
wp_profile_path$/ConfigEngine.bat action-enable-page-as-extension-node-wp.dynamicui.config -DPageUniqueName=wps.dynamicUIContainter -DPortalAdminPwd=wpadmin -DPortalAdminId=wpadmin (See Resources for a link to the Portal information center for more information)
|Title of Dynamic Page||The title of the page to be created.|
|Dynamic Page Properties||A list of properties to be transferred to the new page, for example, the id of a selected task a task portlet has to work on.|
|Dynamic Page Instance Identifier||This input is optional and identifies the instance of dynamic page. By changing this input, you can define how a page instance is identified when relaunching a page that is already open.|
If a portlet runs on dynamic portal pages and has to receive properties, the builder provides the mode âInitialize Properties from Dynamic Pageâ. In this mode, a Portlet Factory simple lists the name of properties to be received. For every property the builder creates a variable which can be used as input for other builder calls.
Redirection to a generic user interface
Very often the process engine already provides a generic user interface for task and process management, for example, Domino Web Access for Domino based processes or SAP Web Dynpro for SAP based processes. Sometimes it is required to reuse such an existing interface. In this case the task list can redirect to user this interface when opening a task. To implement such an approach, the process engine must provide this dynamic URL or the URL must be constructed dynamically.
Efficient business processes require an intuitive user interface. Investing in user interface design and development, increases the acceptance of a business process. By leveraging a standard programming interface and modern development tools, providing such an interface is easy and straightforward. This article introduced you to techniques and patterns that you can use to develop personalized user interfaces for business processes using WebSphere Process Server.