Feature in focus: Modeling for execution made easier with WebSphere BPM V6.2 products

Improvements in IBM® business process management (BPM) tooling and runtimes have eased some of the primary difficulties associated with modeling for execution. This article highlights these improvements and how they make it easier to perform this important function. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Peter Xu, Senior Managing Consultant, EMC

Peter Xu is a Senior Managing Consultant with IBM Software Services for WebSphere, working directly with IBM's largest customers and helping them design and deploy SOA-based solutions on broad range of IBM Software offerings. Peter specializes in business process analysis, modeling for execution and end-to-end BPM solutions. Peter is an OMG-Certified Expert in BPM (OCEB Business Track Advanced).


developerWorks Contributing author
        level

William R Lange, Jr (langewr@us.ibm.com), Senior IT Specialist, WSO2 Inc

William R Lange Jr is the ISSW Worldwide Technical Lead for WebSphere Business Modeler and Publishing Server, specializing in Business Process Management (BPM) adoption and facilitation, including WebSphere Business Modeler adoption, business modeling, business process improvement, and model driven development.



20 May 2009

Also available in Chinese Spanish

Introduction

An earlier article discussed modeling for execution methodology and established why it's the most rewarding usage pattern -- and the most difficult in general to perform. One of the major reasons for this difficulty is the functional mismatch between modeling and development tools. With the V6.2 release of IBM’s business process management (BPM) product suite -- particularly IBM WebSphere® Business Modeler (hereafter referred to as Modeler) and IBM WebSphere Integration Developer (hereafter referred to as Integration Developer) -- process modeling for execution is not only much easier, but is also applicable to a much broader set of BPM implementation projects.


Modeling improvements

There are three major improvements in process flow modeling in Modeler V6.2 (and supported in Integration Developer):

Cross boundary link workaround

Prior to Modeler V6.2: The paths are separate in the sub-process, but must be combined before exiting the sub-process, and then broken out again by a decision in the parent process. If you want to export to Integration Developer for process development, you need to model this pattern yourself explicitly in Modeler.

  • Cross boundary link

    This is a pattern where multiple outputs (or flows) from a single sub-process (or loop) exist. Each output needs to lead to a different task in the parent process after the loop or sub-process is completed. Before V6.2, this concept was supported as a documentation pattern in Modeler, but not as an Integration Developer export pattern. (See the workaround in the sidebar.) Modeler now supports multiple outputs in V6.2 and will automatically generate the right paths for BPEL and all the appropriate output criteria to paths that occur outside the sub-process. You no longer need to model the merge and split yourself.

  • Loopback link

    It is very common for business analysts to connect one task back to a preceding task in a process flow. This pattern is often necessary to model non-linear and graph-based process flows. However, a process modeled as such cannot be exported from Modeler prior to V6.2 because this technique is not permitted in the WS-BPEL standard. Modeler V6.2 supports this construct through a run time extension to BPEL and, thus, graph-based models can now be exported.

  • Fault link

    In many process modeling diagrams, it is necessary to be able to depict not just the normal path, but also an exceptional path. Defining exceptional output is not supported in Modeler prior to V6.2, but is supported in V6.2, greatly expanding modeling capabilities when you export to Integration Developer.

Let’s look at an example in action, skipping the steps to create a process and add tasks. Before you continue, download the Modeler project file included with this article. This file contains a pre-built process for examining the sample modeled process.


Examining artifacts in Modeler

After you download and import the artifacts into Modeler, expand the project and double-click to open the ProcessWithFaultLinkLoop business process. This fictional process contains three major structural links for you to examine (Figure 1): loopback link, fault link, and cross-boundary link.

Figure 1. Overall Modeler process
Figure 1. Overall Modeler process
  • Loopback link

    You can now link from the output of a task back to the input of an upstream task, as shown in the figure. This is not a new feature, since you can also do this in Modeler V6.1. What’s different is that you can now directly export this pattern as is to Integration Developer without a workaround. You will see how this looks in the exported BPEL later.

  • Fault link

    In order to model fault, you need to define at least two outputs (one for normal, one for exceptional) for a particular task. You will also need to define two output criteria as shown in Figure 2.

    Figure 2. Exceptional output
    Figure 2. Exceptional output

    Be sure to associate each output criterion with one output, and to mark one of the output criterion as Exceptional output. You will see how this pattern looks like in Integration Developer later.

  • Cross boundary link

    In Figure 3, you can see how V6.2 enables you to have two outputs in the local process that are connected to different paths in the main flow. This model is directly exportable without any modification.

    Figure 3. Cross boundary link
    Figure 3. Cross boundary link

You can now export this Modeler project and import it into Integration Developer.


Examining artifacts in Integration Developer

In Integration Developer, expand the project and double-click to open the generated BPEL process (Figure 4).

Figure 4. Generated BPEL overview
Figure 4. Generated BPEL overview

Pay attention to the outer scope, which is a generalized flow; a generalized flow is an extension to BPEL standard. Only in a generalized flow can you have a fault link and a loopback link. Generalized flows support a graph-based process flow diagram, and thus more closely resembles what is modeled in Modeler by a business analyst.

  • Loopback link

    From the output of Task 3, you go back directly to the input of Task. You can only do this inside a generalized flow.

  • Fault link

    Remember defining an exceptional output in Modeler? The code generation pattern from Modeler to Integration Developer translates this output to a WDSL fault (Figure 5).

    Figure 5. Fault definition
    Figure 5. Fault definition

    A fault link will also be generated that catches this specific fault and directs to the task that handles the fault (Figure 6).

    Figure 6. Fault link and conditions
    Figure 6. Fault link and conditions
  • Cross boundary link

    If you pay close attention, you will see that additional assigns and conditions are created inside the process scope (Figure 7).

    Figure 7. Cross-boundary Links in BPEL
    Figure 7. Cross-boundary Links in BPEL

In this model, the Assign From variable is updated to True, which will be used in the control link to determine the path. As you can see here, the code generator has become smarter in V6.2 to generate the necessary BPEL artifact to support cross boundary links so you don’t have to.


Summary

With this brief exploration of some of the new and exciting improvements in IBM WebSphere Business Modeler V6.2, you can see how exporting a model to IBM WebSphere Integration Developer has been simplified. This functionality is made possible by a generalized flow, introduced in Integration Developer, which supports graph-based flow and some smart code generation patterns from Modeler. These improvements offer tremendous help for model driven process implementations, and make techniques for modeling for execution feasible in more use cases than ever before.


Download

DescriptionNameSize
Code sampleModeler62Sample.zip39 KB

Resources

Learn

Get products and technologies

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, SOA and web services
ArticleID=389821
ArticleTitle=Feature in focus: Modeling for execution made easier with WebSphere BPM V6.2 products
publish-date=05202009