Recommendations for iterative development in WebSphere Business Modeler

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. It includes tips for minimizing the impact of model changes in Modeler to artifacts in Integration Developer and things to look out for when using XSDs and WSDLs as definitions for business items and services. This content is part of the IBM Business Process Management Journal.

Diana Lau (dhmlau@ca.ibm.com), Software Developer, IBM

Diana Lau photoDiana 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.


developerWorks Contributing author
        level

Raymond Kong, Senior Software Developer & Release Architect, IBM

Raymong Kong photoRaymond Kong is an advisory software developer at the IBM Toronto lab, Ontario, Canada. He currently works in the WebSphere Business Integration Modeler development team and specializes in model to model transformation.



19 January 2011

Introduction

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.

Minimize the impact model changes

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:

Use the Recommended Export Option

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
WebSphere Business Modeler Export dialog

(See a larger version of Figure 1.)

Leverage the mediation flow component when calling external services

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.

Make business-driven changes WebSphere Business Modeler

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.


Modeling business processes to make merging of changes easier

The following sections describe some recommendations for business process modeling to make the comparing and merging of changes easier.

Decision nodes

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.

Data flows and variables

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
Modeler-style data flow modeling
Figure 3. BPEL-style data flow modeling
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
Technical Attributes tab of local repository

Well-formed processes

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
Mixed parallel and exclusive branch region

(See a larger version of Figure 5.)


Artifacts based on inline XSD/WSDL

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.


Conclusion

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.

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=608243
ArticleTitle=Recommendations for iterative development in WebSphere Business Modeler
publish-date=01192011