On October 1, 2008 IBM announced WebSphere Process Server V6.2, a powerful software platform that enables business process management (BPM) applications for your enterprise. This new release provides enhanced flexibility and control over process instances, a simplified and improved process for application deployment, and support for the latest technologies and standards, such as SOAP 1.2 and the WebSphere Application Server Web Services Feature Pack. Business Space powered by WebSphere, the Web 2.0 front end for WebSphere BPM, has been updated with new and improved widgets. Support has been added for newer versions of several platforms, as well as for WebSphere Adapters V6.2. The integrated WebSphere ESB has been updated to support policy-driven mediations including integration with WebSphere Service Registry and Repository.
This article is based on the WebSphere Process Server V6.2 Beta release.
Design to deploy from WebSphere Business Modeler
In previous versions of the WebSphere Business Process Management stack, the process lifecycle has been business modeling in WebSphere Business Modeler, followed by export to WebSphere Integration Developer for service assembly, before the process module is deployed into WebSphere Process Server. WebSphere Process Server V6.2 enables a new direct deploy scenario, where users of WebSphere Business Modeler can directly deploy modules into the WebSphere Process Server runtime.
This new capability enables business users with WebSphere Business Modeler to define and test their business processes, shortening the time between requirements and having an executable business process. Information technology can be brought in for complex problem determination scenarios, while maintaining traceability and governance.
Web interface enhancements
WebSphere Process Server V6.2 includes a selection of Web interfaces, offering flexibility of choice. Version 6.2 brings a variety of enhancements.
Business Space enhancements
Business Space powered by WebSphere is a Web 2.0 application that is included with each of the products in the WebSphere BPM suite of products. Users can create their own space using applications called widgets. WebSphere Process Server V6.2 enhances the widgets for worklist and task management by adding the capability in the workflow diagram to view the history of a business process or a task. For dynamic process scenarios using ad-hoc subtasks, the widgets have been enhanced, enabling you to view, create, modify, cancel and verify the status.
A new widget called the Business Calendar Manager has been added into Business Space. This widget enables users to maintain calendar event information for business operations. The widget enables authorized users to add, delete, and update calendar information, as shown in Figure 1.
Figure 1. Business calendar manager
A new Security Manager widget can configure security roles for the Business Calendar Manager widget. The BPMAdmin ID has the authority to add and remove members from a role called BPMRoleManager, which in turn has the authority to add and remove members from resource roles.
The Health Monitoring widget, shown in Figure 2, is a new widget that aggregates health information for system applications, topology, user applications, messaging, and queue depth. Rather than having to refer to multiple applications, an administrator can see the health of everything at one glance.
Figure 2. Heath Monitor widget
The Task Information widget has been enhanced to exploit subtasks for ad-hoc scenarios. You can create a subtask to refer work to another user, view subtasks, and view their status. The MyTasks widget can view task status on pending subtasks. You can cancel subtasks and view the results of completed subtasks. You can create the subtask by selecting New from the actions menu for a task in the task information widget, as shown in Figure 3.
Figure 3. Creating a subtask
When subtasks are created, you can view them by clicking Related Tasks in the task information widget. Information on the subtasks is displayed, as shown in Figure 4. The icons on the right enable you to open or cancel the task.
Figure 4. Related tasks
You can use a new widget called the security manager, shown in Figure 5, to configure role assignments for business calendar usage. The default ID BPMAdmin has the authority to add and remove users from the BPMrolemanager role, which in turn has the authority to remove members from resource roles.
Figure 5. Security manager widget
BPC Explorer enhancements
WebSphere Process Server has included two Web applications for the Business Process Choreographer that you can use for administration: the BPC Explorer and the BPC Observer. At the top left, you can select Views, which displays the classic BPC Explorer information, as shown in Figure 6. You can also select Reports to view the information previously available in the BPC Observer. The reports tab is also available on views such as process instance.
Figure 6. BPC Explorer
Reporting capabilities from the BPC Observer have now been moved into the BPC Explorer, enabling you to leverage the reporting capabilities while administering human tasks and business processes. New capabilities enable the definition of custom views. These views can include time constraints for when the view is used.
Service Integration Bus Browser
A new explorer-style Web application is available for the Service Integration Bus (SIBus). The interface enables you to look at buses defined at the cell level, then drill down to view queue points, publication points and mediation points on the bus.
To access the Service Integration Bus Browser:
- Logon to the administrative console.
- Click Service integration to expand it, and then click Service Integration Bus Browser.
- Click + to expand the folder for BPC.widCell.Bus, drill down into widNode.server1 => widNode.server1-BPC.widCell.Bus => Queue Points.
- The queue points current queue depth is displayed, as Figure 7 shows.
Figure 7. Service integration bus browser
Installation, standards, and platform enhancements
Installation has been improved with several new features and options. WebSphere Process Server V6.2 includes a full version of WebSphere Application Server Network Deployment, along with the WebSphere Application Server Feature Pack for Web Services. When creating your profile for WebSphere Process Server, a new option for profile augmentation enables you to select the Web Services Feature Pack. The Web Services Feature Pack includes support for Web service standards that emerged after WebSphere Application Server V6.1 was released. These standards include Web Services Reliable Messaging, Web Services Addressing, SOAP Message Transmission Optimization Mechanism, and many others.
You can now create an Installation Factory Integrated Install Package along with scripting capabilities to configure production environments. A new installation verification tool can be used to validate that the server was configured successfully. In the case of errors during installation, error determination has been improved.
On the IBM z/OS platform, installation has been improved by reducing the number of authentication aliases generated. You can now use the zPMT configuration tool to create augment response files. Finally, the generation of Data Definition Language has been improved to be more readily consumable.
WebSphere Process Server V6.2 includes several updates to remain aligned with the latest platforms. WebSphere Application Server V6.1 is now supported.
Windows® Vista is now supported as a runtime platform, along with support for IBM z/OS and z/OSe V1.9 or later. zFS is now supported, so you can leverage native z/OS facilities. IBM IMS V10 is now supported as well.
Interoperability has been improved by adding support for WS-I Reliable Secure Profile, SOAP 1.2 and WS-Reliable Messaging. The Web Services Binding has been improved with support for JAXWS 2.0, JAXB 2.0, SAAJ 1.3 and StAX 1.0. Service discovery now supports JAX-WS and JAXB2-based Java™ services. True support for arrays is also included now.
When working with processes that invoke Web services, Web Service policy sets are now supported. This simplifies administration. Rather than having to define the QoS qualifiers for each service call, a policy set can be specified. Available default policy sets include WS-Reliable Messaging, WS-Security, WS-Transaction, WS-Addressing, HTTP Transport and SSL Transport.
WebSphere Process Server V6.2 complies with the security settings as defined by the Federal Desktop Core Configuration (FDCC) for the United States federal government. FIPS 140-2 cryptographic functionality is managed by the underlying WebSphere Application Server Network Deploy environment.
WS-BPEL 2.0 support has been enhanced in WebSphere Process Server V6.2. A new construct supports the RepeatUntil Loop. Whereas a While Loop runs while a condition is true, a RepeatUntil loop runs at least once, then continues to loop until a condition is true. Figure 8 shows a repeat until loop.
Figure 8. Repeat until loop
In previous versions of WebSphere Process Server, the WS-BPEL 1.1 style of
XPath variable references was used, requiring the GetVariableData()
method. A new enhancement enables WS-BPEL 2.0 style variable references,
using the $variable notation. Rather than using
can now simply use
WebSphere Process Server V6.2 includes a number of improvements to human tasks. In previous versions, a step in a process could be an inline human task, or an external participating task. Participating tasks had a disadvantage of not having access to the process context, which limited the available staffing scenarios. WebSphere Process Server V6.2 can propagate the process context to a participating task, enabling the business process to manage the task’s lifecycle, as well as enabling the task to use substitution. An option in the task properties enables you to bind the lifecycle of the task to the invoking business process, as shown in Figure 9. The task is said to be a “child task” of the process in this scenario. When a human task is bound to the lifecycle of the process, terminating the process also terminates the human task.
Figure 9. Binding human task lifecycle to the invoking process
A new feature enables a history log for human tasks. You can enable human task history in the administrative console, using panels for the BPC container and HTM configuration, as shown in Figure 10. When enabled, you can view the history of various task states, along with who did it, and when. Business users can then view task history. Human task history is not an audit mechanism like the Common Event Infrastructure though; its lifecycle is tied to the human task. When the task is deleted, the task history is deleted along with it.
Figure 10. Enabling human task history
To view this option:
- Logon to the administrative console.
- Click Servers to expand the list, and then select Application Servers.
- Click server1 to select it.
- Expand Business Process Choreographer, and select Human Task Manager.
- Select the option, and save the configuration update.
WebSphere Process Server V6.0.2 introduced a new capability for page flows,
where a single user performs multiple consecutive tasks in a process. The
completeAndClaimSuccessor API enables this
capability. Many page flow processes are also initiated by the user who
will perform the work. To support this scenario, WebSphere Process Server
V6.2 includes a new API named
initiateAndClaimFirst, which initiates a
process instance, then claims the first work item, all in one API
In a high-volume environment, users might need to sort through hundreds of thousands of tasks to find the right one to work on. A query can be used, specifying properties of the task such as its state, description, and process data. Although the query can be complex, it is important to keep the user interface fast and responsive. To support such scenarios, query tables can now be created. An Eclipse plug-in, available as a Support Pac is used to create an XML file, which can then be imported using a wsadmin script called manageQueryTables.py. This script creates optimized SQL to be used for the queries, without needing extra views or tables created in the database. Using this feature, even large queries can often be processed with subsecond timing.
Some business processes are very structured, following the same paths through the process for every process instance. A traditional WS-BPEL process handles this class of processes. However, there is a class of business processes where a rigid process would be an unacceptable constraint on the needs of the business. A process is needed to provide guidance on what to do next, but users may need to skip or redo previous steps, as well as add in new steps on the fly.
For such dynamic process scenarios, a new construct is available in a business process, called a Collaboration Scope. This process element is a container, like a BPEL scope activity. A collaboration scope is different in that steps contained within can be skipped by business users, or redone. Figure 11 shows the menu for a human task in Business Space, where you can select Skip or Redo as actions on a human task.
Figure 11. Redo a step in a collaboration scope
Faults can be handled through a fault link, as shown in Figure 12. If the task completes normally, the regular link is followed. In the case of a fault, the fault link is followed. Fault links are indicated by a double line in an alternate color from normal links.
Figure 12. Collaboration scope with fault link
A collaboration scope also includes a special variable called a collaboration folder, which can be used to attach document links to the business process. These features give business users far greater control over the process flow, enabling the process to be adaptable instead of rigid.
Other WebSphere Process Server enhancements
Steps in WebSphere Process Server now include exit conditions that can be evaluated on entry or exit of a process step. When evaluating the condition on entry of a task, if the condition evaluates to true, the activity is skipped, and the process navigates to the next activity. This eliminates the need to have conditional logic in your process to jump around the step, if it does not need to be run. When evaluating the condition on exit of a task, if the condition is true, the task is considered to have completed successfully; if the condition evaluates to false, the activity is considered to have a problem, and is set to stopped. This eliminates the need to add extra steps into your process to test if a step was completed successfully. This capability will lead to cleaner models which don’t require extra activities to perform checks.
These conditions can be used to specify when the step should be automatically skipped. The condition can be checked when entering the step, exiting, or both.
A new feature enables dynamic invocation in SCA, available for WS-BPEL processes, mediation components, and Java components. The capability enables greater flexibility and dynamicity in an application. The endpoint reference is dynamically composed at runtime, without requiring a pre-existing SCA import. With this capability, rather than being limited to the wired import, you can overwrite the endpoint address, use a different import than the one which is wired, or perform a purely dynamic invocation without the use of an import.
Fault handling has been improved in version 6.2. Just as a function selector can be used to map an invocation to the proper operation in a WSDL, a new fault selector can be used at the operation or binding level to return the native name for a fault. Fault handling across all import bindings is able to determine if the invoked service returned a fault. A new capability enables the mapping of fault data. You can also classify the fault as being business or technical. These new capabilities make fault handling consistent for all service invocations.
In previous versions of WebSphere Process Server, you needed to stop a process template or task template before uninstalling the application it was deployed with. If there are no running process instances for a template, you can now uninstall the application without having to first stop the template.
The WebSphere Process Server REST API has been expanded to support new functions and resources, including the ability to work with subtasks, view the history of a human task, along with greater functionality for process templates, process instances, and activities.
The process starter can now transfer ownership to another user. Administrators can now provide transition condition values for outgoing links of an activity, to force the process down the chosen branch. It is now possible to explore and change values for variables, including variables for activities which have not yet been navigated. Figure 13 shows the activity variables screen from the Business Process Choreographer Explorer, which can be access by clicking Variables on the activity page.
Figure 13. Activity variables
Before WebSphere Process Server, there were several products from IBM for business process management. Capabilities from each of these products were designed into WebSphere Process Server. In order to have a smoother migration from these legacy products to WebSphere Process Server, there have been several new enhancements in version 6.2.
WebSphere MQ Workflow
WebSphere MQ Workflow enables long-running business processes with human tasks as well as automatic steps. WebSphere Process Server V6.2 includes an updated version of the FDL2BPEL tool which creates a more highly optimized WS-BPEL. Merge has been optimized to generate fewer Java snippets. Sharing of WS-BPEL variables has been improved, resulting in fewer of them being generated. New WS-BPEL constructs are exploited, and redundant sequence and flow activities are removed. This results in a cleaner process.
Human task query performance has been improved to bring it closer to parity with WebSphere MQ Workflow. A new cleanup service enables you to schedule deletion of completed instances from the database, bringing functional parity with the cleanup server. You can specify when the service should run, how long to let it run, and how many instances should be deleted in a transaction. This option improves performance by enabling you to temporarily leave completed process instances in the database, and then delete them at a later time when the system is less busy. By deferring the work, there is less load on the database during peak times. Figure 14 shows the dialog for adding a new cleanup service job.
Figure 14. Navigating to cleanup server jobs
The ability to schedule the cleanup a completed process instances bring parity with the WebSphere MQ Workflow cleanup server.
WebSphere InterChange Server
WebSphere InterChange Server enabled automated business processes for integration using WebSphere Business Integration Adapters. Application Specific Business Objects (ASBOs) from the end-points could be mapped to Generic Business Objects (GBOs) for use in the collaboration logic. WebSphere Process Server V6.2 enables the use of migrated maps with WebSphere Adapters, generating native SCA bindings, using WebSphere MQ Series, JMS, HTTP or EJB. The migrated maps support text-based heritage data handlers. Along with improved runtime performance, these new enhancements improve the migration experience from WebSphere InterChange Server.
WebSphere ESB enhancements
WebSphere Process Server includes an integrated Enterprise Service Bus called WebSphere ESB, which can also be purchased separately. WebSphere ESB enables message routing, transformation, transport mediation, and event support. Version 6.2 adds increased flexibility by enabling policy driven configuration of service mediations. WebSphere Service Registry and Repository is used for policy management and governance.
In version 6.2, there are several new mediation primitives, as well as improvements to many of the existing ones. Figure 15 shows the available mediation primitives.
Figure 15. Mediation primitives
Type Filter primitive. A new Type Filter primitive has been added. Rather than routing based on values as the Message Filter does, a Type Filter routes based on message type. If multiple message types are processed by the same mediation flow, you can use this new primitive to define XPath expressions to direct messages out different terminals. A default terminal is provided if none of the XPath expressions evaluate to true. This feature can be used to support a services gateway pattern.
Data Handler primitive. A new Data Handler primitive converts physical formats to and from logical structures. In previous versions, you could use a data handler in the import and export for a module. For service gateway scenarios where the incoming message is of anyType, the data handler logic can now be moved into the mediation flow.
Set of primitives. A set of new primitives is provided for setting message headers for WebSphere MQ, SOAP, HTP and JMS. These message header setters can create header properties and set their values, find existing header properties and set their values, find existing header elements and copy its value to another location in the Service Message Object, or find an existing message header element and delete it.
Policy Resolution primitive. A new Policy Resolution primitive works with WebSphere Service Registry and Repository to retrieve policies and convert the effective policies into a set of dynamic property values.
In previous versions of WebSphere Process Server, each mediation flow component required its own module. In version 6.2, multiple mediation components can be placed into a single module. If you had twenty mediation flow components, you can now choose to deploy them all in one single module, rather than needing twenty. This can simplify administration and deployment of your mediation flow components.
In addition, mediation flow components can now be added into a business integration module, enabling you to wire your process directly to the mediation flow component, rather than requiring a hop over SCA. This improves performance, making the call locally, rather than having to send a message out to an external module.
Services Gateway pattern
A common implementation pattern for an enterprise service bus is called Services Gateway. In this pattern, an incoming message is routed to an endpoint, based on some attribute of the message. A typical mediation flow for a services gateway is shown in Figure 16. A filter node is used to direct the flow to different branches, where message transformation takes place, then invocation of the correct endpoint. In previous versions of WebSphere ESB, the implementation of this pattern could be termed as “static”, since any changes to the endpoints required modifications of the mediation module.
Figure 16. Static services gateway pattern
WebSphere ESB V6.2 enhances this scenario by enabling a dynamic services gateway, using the latest mediation primitives. Rather than hard-coding the branching and logic into the flow, WebSphere Services Registry and Repository can be leveraged to perform a dynamic lookup. The example flow in Figure 17 retrieves the endpoint from WebSphere Services Registry and Repository, sets SOAP header information, then invokes the endpoint. If an endpoint is ever changed or a new endpoint is added, the work would be done in WebSphere Services Registry and Repository. The mediation flow does not need to be modified, making this implementation dynamic. The endpoint lookup could also come from a database, an element of the message, or custom logic, which enables use of third-party products. The gateway can use Web Services (SOAP 1.1 or 1.2), HTTP, JMS, or MQ as the transport protocol.
Figure 17. Dynamic services gateway pattern in WebSphere Process Server v6.2
In previous versions of WebSphere ESB, properties for mediation primitives could only be specified at design time, in WebSphere Integration Developer. Version 6.2 enables promoted properties, which can be determined at runtime. The Service Mediation Object (SMO) now includes at dynamic property context, which can be used to override the value of the promoted properties. A second option is to use policies from WebSphere Service Registry and Repository to specify the values. A new policy resolution primitive is used in the mediation component to enables this capability. Either option provides a more flexible and dynamic mediation framework.
In previous versions of WebSphere Process Server, business processes and human tasks could be versioned, enabling you to have multiple versions installed at the same time. In WebSphere Process Server V6.2, version support has been added for SCA modules and libraries, as shown in Figure 18. When selecting a library in the dependency editor, you can now specify a required version, ensuring that the module uses artifacts from the correct version of the library. When using an SCA import, the version to use can be specified as well. The endpoint lookup primitive also supports version. With this new capability, you can deploy multiple versions of the same module, with the same name, on the same server. Late-binding interfaces will always select the newest version, while early-binding interfaces can specify the version to use.
Figure 18. Setting module version
A new API for business objects has been added to improve ease of use for
development when dealing with nested business objects. In previous
versions, before you could set a property, you had to explicitly create
and initialize all nested business objects. In version 6.2, the new
boFactory.createByType API enables you to
simply create the high level business object, making it immediately ready
for use. For a business object with three levels of nesting, two lines of
code can perform what used to require seven.
Abstract business objects are now supported. The business object editor has a new option to mark an business object as abstract. Abstract business objects do not pass outside the boundaries of the SCA binding; they are internally used to create new business objects, similar to the “implements” concept in Java programming. As such, abstract business objects cannot be converted from XML to SDO.
WebSphere Service Registry and Repository interaction
Interaction between WebSphere Process Server and WebSphere Service Registry and Repository has been improved in version 6.2. When defining an instance of a service registry and repository, a new button enables testing of the connection. Changes to the proxy definition no longer require a restart of the server. Registry and repository information held in the cache can now be cleared from the administration console as shown in Figure 19, or from the command line.
Figure 19. WebSphere Service Registry and Repository definitions
To create a new WSRR definition:
- Log on to the administrative console.
- Click + to expand Service integration, then click WSRR definition.
- Click New to add a new definition.
- Enter a name, and then click Apply.
- Click Connection Properties, then enter the registry URL, authentication alias and SSL configuration, then click OK.
- Click Test connection to ensure that the values are correct.
- Click Save to update the local configuration. The connection now appears in the list.
In this article, you learned about the new features in WebSphere Process Server V6.2 as summarized below:
- Updates to Business Space powered by WebSphere
- New and improved capabilities for process deployment and control of process instances
- Updates for the latest standards and platforms
- Ability to work with the WebSphere Application Server Web Services Feature Pack
- Support provided for WebSphere Adapters V6.2
- WebSphere Process Server V6.2 announcement letter
- developerWorks WebSphere BPM
Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
- Feature Pack for Web Services for WebSphere Application Server V6.1
- What's new in WebSphere Integration Developer V6.2