A business process management project using a WebSphere business process management solution can be initiated by first modeling business processes using WebSphere Business Modeler and then implementing new services or integrate existing services within the business processes using WebSphere Integration Developer. However, this is seldom a one-way path to deployment for various reasons, for example, continuous process improvement and ever-changing business requirements. The lifecycle of such business process management projects usually involves iterative development between WebSphere Business Modeler and WebSphere Integration Developer.
This article discusses a few recommendations when modeling for runtime in WebSphere Business Modeler V7 that can make iterative development with WebSphere Integration Developer easier. There are guidelines for:
- Minimizing the impact of model changes introduced in WebSphere Business Modeler to artifacts in WebSphere Integration Developer.
- Modeling business processes in ways that make the comparison and merging of model changes easier.
- Dealing with inline Web Service Description Language (WSDL) as definitions for business items and services.
For any development process that involves hand-offs between two products, one of the most frequently asked questions is how to model and organize the artifacts so that the impact of model changes is minimal. Here are a few tips:
As shown in Figure 1, the WebSphere Business Modeler project is exported into three modules or libraries in WebSphere Integration Developer using the Recommended Export Option:
- Business logic module
- Implementation module
- Library project
The business logic modules contain BPEL definitions directly transformed from WebSphere Business Modeler models; whereas the implementation modules contain “black box” constructs that require concrete implementation to be completed in Websphere Integration Developer.
Figure 1. WebSphere Business Modeler Export dialog
A task node can be a new service yet to be implemented or an existing service that needs to be integrated. You can leverage a mediation flow component in WebSphere Integration Developer to perform mapping to and from the external services to avoid having to update the process model each time the external service interface is changed. To create the mediation flow in WebSphere Integration Developer, make sure Create mediation flows for tasks and services is selected in the Export dialog.
Integration developers should modify the implementation modules only by refining the implementation details in these modules in WebSphere Integration Developer and leaving the business logic changes to be done by the business analysts in WebSphere Business Modeler.
If the change is business relevant, the user can update the execution model in Business Modeler, re-export the model, then synchronize in WebSphere Integration Developer using the Synchronization dialog to merge the changes between WebSphere Business Modeler generated artifacts and artifacts in the WebSphere Integration Developer workspace. For more information on using the Synchronization dialog to facilitate iterative development, refer to Merging changes from the model into the workspace in the WebSphere Integration Developer Information Center.
The following sections describe some recommendations for business process modeling to make the comparing and merging of changes easier.
By default, decision nodes in WebSphere Business Modeler generate BPEL links with transition conditions in WebSphere Integration Developer. In WebSphere Process Server mode, WebSphere Business Modeler provides the option to transform the decision node into a BPEL Switch activity, which is then transformed into choice node in the WebSphere Integration Developer Technical Attributes tab. However, this is generally not recommended.
The decision node in WebSphere Business Modeler depicts a graph-based process flow representation that conforms with BPMN notation, whereas a choice node in WebSphere Integration Developer requires each decision branch to be well-structured and self-contained. To maintain a better traceability between the WebSphere Business Modeler process and BPEL, it is recommended that you maintain a one-to-one mapping of the graph-based process flow. This facilitates a much smoother iterative development by reducing complexity in the comparing and merging in WebSphere Integration Developer.
There are two ways to specify data flow in WebSphere Business Modeler: Modeler-style and BPEL-style. Modeler-style specifies the data on the links, as shown in Figure 2; whereas BPEL-style uses a local repository, as shown in Figure 3.
Figure 2. Modeler-style data flow modeling
Figure 3. BPEL-style data flow modeling
Try to avoid mixing the two styles. WebSphere Business Modeler may generate a more complex BPEL if a mixture of styles is used, which may lead to redundant variables being passed around in the business process. It is generally more intuitive to use the Modeler-style data flow modeling. However, if you would like to have more control over the variable name, you should use the BPEL-style because you can specify variable name in BPEL using the Technical Attributes tab, as shown in Figure 4. You might think that defining a local repository will make the process flow look more cluttered, but WebSphere Business Modeler provides an option to hide the local repository so that the process diagram looks cleaner.
Figure 4. Technical Attributes tab of local repository
A WebSphere Business Modeler process is a BPMN-based process graph. To transform the process to an executable BPEL process, the process branch regions must be sound and well-formed. For example, exclusive branches mixing with parallel flows creates a mixed process region that cannot be correctly merged or joined later in the process flow. Figure 5 illustrates such an example. Note that the last XOR merge node does not offer a valid synchronization point for the parallel gateway, nor can it be changed to an "AND" join node because this would create a potential deadlock situation for the exclusive gateway.
WebSphere Business Modeler has validation rules to validate the semantics of a process flow to ensure it is well-formed. The same set of validation rules are also used in the BPEL editor in WebSphere Integration Developer to ensure that the process logic is deployable and executable.
Figure 5. Mixed parallel and exclusive branch region
When a WSDL has inline XSD, this means that other WSDL or XSD elements that reside outside the file cannot reference the inline types in that WSDL. For this reason, when importing WSDL with inline XSD into WebSphere Business Modeler, the business service objects become “private.” To link a task that references the inline types, you need to use the Map node to map the data of the business service defined by the “private” schema to and from other tasks or business services in the process.
An alternative is to extract XSDs out of WSDLs before import, so that there is no inline element in the WSDL. You can do this when exporting the WSDL in WebSphere Integration Developer, by selecting the option to extract the inline schema and create a standalone “public” schema. You can then import the WSDL and the standalone schema into WebSphere Business Modeler. However, this may not be ideal when the WSDL comes from a third party or the organization doing the business process modeling does not have control on the WSDL.
This article provided some recommendations for iterative development between WebSphere Business Modeler and WebSphere Integration Developer, including how to minimize the impact of model changes made in WebSphere Business Modeler to WebSphere Integration Developer, tips on modeling business processes, and things to look out for when dealing with inline WSDL/XSD as the business service and business service object definitions.
Iterative development in business process management
solutions (developerWorks, 2010): This article describes
iterative development approaches in the context of business process
management. It recommends a model-centric iterative development
approach to accelerate and improve your BPM experience using
WebSphere® Business Modeler and WebSphere Integration Developer.
Model business processes for flexibility and re-use: A
component-oriented approach (developerWorks, 2009): This
article describes a component-oriented approach to business process
modeling that allows you to capture process variability and ensure
that your model is reusable. It describes modeling patterns and
practices in WebSphere Business Modeler that will help you achieve
- Modeling for WebSphere Integration Developer
implementation: This topic in the WebSphere Business
Modeler Information Center describes how to develop business models
for use in WebSphere Integration Developer.
- Recommendations for iterative development: This topic
in the WebSphere Business Modeler Information Center describes best
practices for iterative development.
- WebSphere Business Modeler Advanced V7 Information
Center: Get complete product documentation for WebSphere
- WebSphere Integration Developer V7 Information Center:
Get complete product documentation for WebSphere Integration
developerWorks BPM zone: Get the latest technical
resources on IBM BPM solutions, including downloads, demos,
articles, tutorials, events, webcasts, and more.
Diana Lau is a Software Developer on the WebSphere Business Process Management SWAT team at the IBM Toronto Software Lab, Canada. She works closely with customers to resolve technical issues and provide best practices for implementing BPM solutions.