Using cyclic flows to enable loopbacks in WebSphere Business Modeler and WebSphere Integration Developer

This article teaches you a simple technique you can use to convert loopback flows in business models created with WebSphere Business Modeler into cyclic flows in WebSphere Integration Developer so that the looping behavior can be executed on WebSphere Process Server.

Dr. Johny Mathew (jmathew@us.ibm.com), Senior Software Engineer, IBM

Johny Mathew photoJohny Mathew is an architect with the IBM Business Process Management (BPM) suite of products. Prior to this, he worked on Tivoli® products as an architect and designer, and Communication Server products as Chief Programmer and developer. Johny received his doctorate in Electrical Engineering (Computer Networks) from City University of New York. You can reach Johny at jmathew@us.ibm.com.



Billy Rowe (browe@us.ibm.com), Senior Software Developer, IBM

Billy RoweBilly Rowe is a senior architect and manager focused on BPM strategy and partner integration within the IBM BPM suite of products. Billy has held various positions within IBM as a developer, architect, and consultant. You can reach Billy at browe@us.ibm.com.



11 June 2008

Introduction

WebSphere Business Modeler (hereafter called Modeler) is the premier tool used by business and process analysts to model business processes. Analysts document their company’s business processes and optimize them using the powerful simulation, what-if, and analysis capabilities in Modeler. Once the process model is optimized, it is exported to WebSphere Integration Developer (hereafter called Integration Developer) to generate an executable process.

Modeler provides multiple modeling modes that enable analysts to document processes, even if those processes can't run on IBM run-time servers such as WebSphere Process Server (Process Server). If the process is to run on Process Server, the analyst sets the modeling mode to "WebSphere Process Server" before exporting the model to Integration Developer. However, not all the flow options in Modeler can be exported into Integration Developer. One of the flow artifacts you can't import into Integration Developer is a loopback, or cycle. The reason for this is that loopbacks are not supported in the WS-BPEL standard, and the Integration Developer import function is based on WS-BPEL standard.

However, loopbacks do exist in commercial processes and must be accommodated. In this article, we'll show you a technique you can use to capture a loopback in Modeler for modeling and analysis purposes, and then make a small change to the loop so you can export it to Integration Developer. To do this, you'll need to add a Cyclic Flow activity in Integration Developer to do the equivalent loopback function. This function is available for WebSphere Integration Developer V6.1.0.1 or higher.


Overview of the scenario

For our scenario, we'll use a fictitious dry cleaning company to illustrate the use of a loopback in a process model. This dry cleaning company washes clothes once and dries them multiple times until a quality inspector certifies that they are dry. The drying task and the quality inspector dryness test constitute the loopback. This loopback is modeled in the Drying subprocess so that the top-level process is easy to understand; however placing the loops in its own subprocess is also a key simplification technique in modeling the loopback for implementation in Integration Developer.

Once the quality inspector certifies that the clothes are dry, the flow continues to the next task, where it is marked as ready for customer pick-up. Figure 1 illustrates the top-level dry cleaning process.

Figure 1. Dry cleaning process
Figure 1. Dry cleaning process

The process flows from the Wash task to the Drying subprocess, which contains the Dry task and the Quality Inspector human task and loopback. The quality inspector inspects the dryness of the clothes and decides whether to repeat the Dry task. Once the quality inspector certifies an item is dry, the flow exits the subprocess and continues to the Mark Ready for pickup task.

Figure 2 shows the Drying subprocess.

Figure 2. Drying subprocess
Figure 2. Drying subprocess

The process uses a business item called CustomerData for the information flow between various tasks in the process. The Boolean variable Washed is set by the Wash task after it completes washing. The Number of times dried variable is incremented by the Drying task every time it is invoked. The Is it Dry variable is set by the Quality Inspector human task when the clothes are dry.

Figure 3 shows the CustomerData business item.

Figure 3. CustomerData business item
Figure 3. CustomerData business item

Enable the loopbacks for exporting to Integration Developer

To prepare the loopbacks in the model for export to Integration Developer, we'll break the loopback in the subprocess as shown in Figure 4, then export the model in Process Server mode. Again, encapsulating the loopback in a subprocess makes the changes needed in Integration Developer simpler.

Figure 4. Break the loopback in the subprocess
Figure 4. Break the loopback in the subprocess

After you've exported the model for importing into Integration Developer, restore the loopback to the state prior to breaking the loop, and save the process model to reflect the business analyst's view of the business process. Breaking the loop was simply to allow for export to Integration Developer.

Figure 5. Loopback restored
Figure 5. Loopback restored

Implement the business process in Integration Developer

After the model is imported into Integration Developer, the process diagram should look like Figure 6:

Figure 6. Initial process diagram
Figure 6. Initial process diagram

Figure 6 shows the imported process diagram with the broken loopback flow in the subprocess. You need to replace the Subprocess_Flow in the process diagram with CyclicFlow. The following steps describe how to implement the cyclic flow and business process.

  1. Add a CyclicFlow activity just above the Subprocess_Flow and drag all the elements from the SubProcess_Flow into the CyclicFlow, as shown in Figure 7.
    Figure 7. Process diagram after adding CyclicFlow
    Figure 7. Process diagram after adding CyclicFlow
  2. Delete the Subprocess_Flow.
  3. Add an empty activity called Start_subprocess and wire that to the Dry activity.
  4. Add a wire from the output of the Quality Inspector human activity to the input of the Dry activity (this is the equivalent of the loopback in Modeler).
  5. Rename the Output_Criterion activity to End_subprocess.

    The resulting process is shown in Figure 8.

    Figure 8. Process diagram after wiring the CyclicFlow
    Figure 8. Process diagram after wiring the CyclicFlow
  6. Add Boolean conditions to the links outbound from the Quality Inspector human activity by doing the following:
    1. Click the link from Quality Inspector to the End_subprocess activity.
    2. Click the Properties tab and then the Details tab.
    3. In the Expression language field, select No Expression.
    4. Click Create a New Condition, expand CustomerDataVariable, and select Isitdry.
    5. Click the arrow and select == followed by true.
    Figure 9 shows the completed condition.
    Figure 9. Boolean condition on the link from Quality Inspector to End_subprocess
    Figure 9. Boolean condition on the link from Quality Inspector to End_subprocess
  7. Click the loopback link from the Quality Inspector to the Dry activity, and set the condition as shown in Figure 10.
    Figure 10. Boolean condition on the link from Quality Inspector to Dry
    Figure 10. Boolean condition on the link from Quality Inspector to Dry

    The updated process diagram is shown below.

    Figure 11. Revised process diagram with link conditions
    Figure 11. Revised process with link conditions
  8. Select the DryCleaningReceive activity, and click the Properties tab, then the Authorization tab.
  9. Click New to create an Invocation task. The human task editor opens. Save the new human task and close the tab.
  10. Open the assembly diagram as shown in Figure 12.
    Figure 12. Assembly diagram
    Figure 12. Assembly diagram
  11. Delete DryCleaning Export.
  12. Right-click the Wash activity and select Generate Implementation => Java.
  13. Replace the following method:
    public DataObject InputCriterion(DataObject input) {
    	//TODO Needs to be implemented.
    	return null;
    }

    with:
    public DataObject InputCriterion(DataObject input) {
    	System.out.println("WashImpl is invoked");
    	input.setBoolean("Washed", true);
    	return input;
    }
  14. In the same manner, generate a Java implementation for the Dry and MarkReadyforpickup components.

    Replace the following method in DryImpl.java:

    public DataObject InputCriterion(DataObject input) {
    	//TODO Needs to be implemented.
    	return null;
    }

    with:

    public DataObject InputCriterion(DataObject input) {
    	System.out.println("DryImpl is invoked");
    	int numberoftimersdried = input.getInt("Numberoftimesdried");
    	input.setInt("Numberoftimesdried", ++numberoftimersdried);
    	return input;
    }

    Replace the following method in MarkReadyforpickupImpl.java:

    public DataObject InputCriterion(DataObject input) {
    	//TODO Needs to be implemented.
    	return null;
    }

    with:

    public DataObject InputCriterion(DataObject input) {
    	System.out.println("MarkReadyforpickup is invoked");
    	input.setBoolean("Readyforpickup", true);
    	return input;
    }
  15. Save all your changes.
  16. Generate the business client to invoke the process and provide the input for the Quality Inspector human activity by right-clicking DryClean and selecting generate User Interface (JSF Custom Client). Specify DryCleanUI for the dynamic Web project name.

Deploy and run the artifacts

To deploy and run the artifacts, do the following:

  1. From the context menu of the integrated test environment server, select Add/Remove Projects to deploy the two projects.
  2. Open a Web browser to http://localhost:9080/DryCleanUI to launch the generated client.
  3. In the left navigation pane, select New under Business Case.
  4. On the resulting page, select DryCleaning_InputCriterion.
  5. Specify input data as shown in Figure 13, and click Create.
    Figure 13. Create an instance of the business process
    Figure 13. Create an instance of the business process
  6. Select Open under My ToDo’s, then select the task listed under Task Name, and click Claim at the bottom of the form. This claims the task so you can work on it, and the buttons change to Complete, Save, and Release.
  7. Notice that the Washed variable is checked (set to true) and the number of times dried is 1. Now you'll perform the actions of the quality inspector. Click Complete without checking the Isitdry variable. The business process loops through the drying process again.
  8. Click Refresh and open the process again.
  9. Click Claim. Notice that the Number of times dried is now 2, as shown in Figure 14.
    Figure 14. Quality Inspector’s user interface
    Figure 14. Quality Inspector’s user interface
  10. To complete the drying process, set Isitdry to true by checking it and clicking Complete.
  11. If you click Refresh, you'll see that the task lists is now empty. This is because the process flow activity, completed programmatically, and then completed the process.

Summary

In this article, you learned a technique for isolating a loopback into a subprocess and temporarily breaking the loopback so that you can export the model for implementation in Integration Developer. After exporting, the loopback is restored in the model to preserve the business view of the process. You can use this technique in small or large projects. In Integration Developer, you replace the exported subprocess with the CyclicFlow construct, which is an extension added to Integration Developer V6.1.0.1.


Acknowledgments

The authors would like to thank Simon D. Moser for helping them with the development of the CyclicFlow in WebSphere Integration Developer, and for acting as a technical reviewer for this article.


Downloads

DescriptionNameSize
Project Interchange fileDryClean.zip6.6MB
Completed modelDryCleanmar.zip31KB

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 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=313044
ArticleTitle=Using cyclic flows to enable loopbacks in WebSphere Business Modeler and WebSphere Integration Developer
publish-date=06112008