Modeling your business processes with IBM WebSphere Lombardi Edition, Part 3: Advanced modeling

Part 3 of this series shows you how to use the advanced features of WebSphere Lombardi Edition V7.1 to enrich a business process in order to meet more complex requirements, including nested processes, milestones, event mechanisms, exception handling and Lombardi web services exposure.

Share:

Xin Li (lixincdl@cn.ibm.com), Staff Software Engineer, IBM

Xi Lin photoXin Li is a staff software engineer at the IBM China Development Lab, focusing on SOA-related design and development. Li Xin has rich experience in Telecom domain system integration, and also has deep insight in Telecom standards and technologies.



Xi Ning Wang, Staff Software Engineer and Development Lead, IBM

Xi Ning Wang photoXi Ning Wang is an advisory software engineer on the IBM China Cloud Labs team in IBM Software Group, where he focuses on cloud computing related technologies development and customer solutions. He was designated an IBM developerWorks Contributing Author in 2009.



07 December 2011

Also available in Chinese

Overview

Part 1 of this series gave you an overview of the features and architecture of WebSphere Lombardi V7.1 (hereafter called Lombardi). In Part 2 you learned how to use the most common features of Lombardi, including business process definition (BPD), and integration, human and rule services, to model the sample process.

In this article, you'll learn how to use the advanced features of Lombardi to enrich a business process to meet more complex requirements, including nested processes, milestones, event mechanisms, exception handling and Lombardi web services exposure. We'll illustrate these capabilities using the purchase order scenario introduced in Parts 1 and 2.


Enriching the process capability

In this section, we'll look at some ways you can enrich the capabilities of the sample process.

Add milestones to the process

You can add milestones to a process diagram to illustrate the phases of process execution. To do this, drag the Milestone element into the process diagram and enter a name for the milestone. For example, you can add an Order Submission milestone to capture the activities across lanes that occur in the initial order submission phase of a process, as shown in Figure 1.

Figure 1. Milestones within a process
Milestones within a process

You can also import and unzip the Lombardi .twx export file from the Download section to step through the complete business process definition.

Besides an Order Submission milestone, two other milestones are defined for important phases for our scenario, as shown in Figure 1:

  • Order Validation milestone - used to validate the order including whether the order need the buyer’s reconfirmation, and the supplier’s response, etc.
  • Order Fulfillment milestone – used to illustrate the final order generation, shipment and payment activities.

Create nested processes

You can use nested processes to encapsulate activities that are related to each other within a parent process. Using nested processes enables you to manage the complexity of a business process while retaining a high-level view of the overall process represented in the parent process definition. Each activity in a business process definition (BPD) can have a nested process attached to it, and each activity in the nested process can have a nested process attached to it, and so forth.

When an activity that is implemented by a nested process is triggered at run time, the attached nested process is executed. After the nested process has run to its completion, the parent process resumes execution.

In the sample purchase order process, the GenerateOrder activity in the ERP lane is implemented using a nested process called Generate Order, which includes three activities: Calculate Price, Select Shipper, and Schedule Shipper. The implementation of the nested process is similar to the general BPD development.

You can link the nested process to the GenerateOrder activity within the parent process. To do this, in the Purchase Order Process BPD, click the GenerateOrder activity and select the Implementation tab in the properties. Under Implementation, select Lombardi Nested Process from the drop-down menu. Click Select to choose the BPD from the existing business process definitions list, then select Generate Order BPD from the list, as shown in Figure 2.

Figure 2. Implement an activity using a nested process
Implement an activity using a nested process

Within the Oder Validation milestone, all the activities are combined as one nested Order Confirmation Process, as shown in Figure 3. Except for the timer event attached to the Buyer Confirms Order activity, which we'll discuss later, all other activities and gateways are the same as those you implemented in the earlier parts of the series.

Figure 3. Nested Order Confirmation process
Nested Order Confirmation process

Customizing event handling

In this section, you'll learn some ways you can customize event handling in the sample process.

What are Undercover Agents

Before we get into event handling implementation, you should understand the Lombardi concept of an Undercover Agent (UCA). A UCA is started by an event that can be either triggered by a message or on a specific schedule. When a UCA is started, it will invoke an attached service in response to the event.

From Part 1 of this series, you already know that the Event Manager is the part of the Process Server that handles event scheduling and queuing. The Event Manager needs a UCA to find the service that it should run. Therefore, if you want to invoke a service when an incoming message event is received or if you want to invoke a service as the result of an event that occurs on a regular schedule, you should create a UCA Agent. We'll cover this in more detail later in this section.

Incoming messages can originate from a web service that you create or from a message that you post to the JMS Listener. In the sample, we'll use web services to initiate inbound requests from external systems.

What event types does Lombardi provide?

Lombardi provides a flexible and robust event mechanism that enables the event at the beginning, during, or at the end of a runtime process. Lombardi provides ten different event types, including the following four events that we'll use in our sample scenario:

  • Start event - A start event is automatically included each time you create a BPD. Use this event to model the start of a process or a nested process. There is only one start event within each BPD.
  • End event - An end event is automatically included each time you create a BPD. After a nested process has run to its completion, the parent process resumes execution.
  • Intermediate message event - A BPD can include more than one intermediate message event. Use this to model a message event received while a process is running. The event is triggered by the UCA that you select.
  • Timer event - Use the timer event to model escalation paths or delays in your BPDs. Using a timer event, you can specify a time interval after or before which some activity is performed.

Create an intermediate message event

In the Generate Order nested process of the sample scenario, the requirement is that the buyer pay for the order before the Select Shipper activity is executed. This means that the process needs an intermediate message event to wait for payment notification, and then executes the Select Shipper activity.

Let's select an intermediate message event to illustrate the event handling mechanism in Lombardi:

  1. Create an event by dragging an Intermediate Message Event element from the palette into the Generate Order BPD diagram, and specify Wait for Buyer's Payment as the name. Wire this message event between the Calculate Price activity and the Select Shipper activity, as shown in Figure 4.
    Figure 4. Create an intermediate message event
    Create an intermediate message event
  2. Create an integration service called Payment Integration Service, or use the already created payment.jar provided for download.

    In the Designer view, click the plus sign (+) next to Files in the library, and select either server file in order to add JAR file. In the New File dialog, click Browse to select the JAR file.

    Now you can use this external Java™ class in the Java integration.

  3. Drag a Java Integration component from the palette to the service diagram and then use sequence lines to connect the component to the Start and End events. Click on the Java Integration component in the diagram and then select the Definition option in the properties. Click Select next to the Java Class field to choose the JAR file and the class of the JAR file, as shown in Figure 5. The input data type of the operation pay in this Java class is String, and the output data type is decimal.
    Figure 5. Java integration
    Java integration
  4. Create a general system service that called Payment Service, and drag the Payment Integration Service into this diagram, as shown in Figure 6. Click the auto-map icon in both the Input Mapping and Output Mapping sections to automatically create the variables for the service in order to correlate the general system service.
    Figure 6. Payment Service
    Payment Service
  5. Create an event-based UCA called Settle Payment UCA to wrap the newly created Payment Service. Specify On Event for the schedule type, as shown in Figure 7.
    Figure 7. Create Settle Payment UCA
    Create Settle Payment UCA
  6. Attach the Undercover Agent to the message event.
  7. Select the Wait for Buyer's Payment intermediate message event in the Generate Order BPD, and click the Implementation option in the properties. In the Message Trigger section, click Select next to the Attached UCA field to select Settle Payment UCA from the Undercover Agent list.
  8. Consume Message is checked by default. If you don't want the incoming message to be consumed after it has been received by the message event, uncheck it.
  9. If Durable Subscription is checked it means the message event can receive an incoming message, even when the message event is not in an active state.
  10. In the UCA Output Correlation section, you need to map an appropriate UCA output variable to a local variable in the BPD to correlate the message event with the BPD instance. Here the order ID is used as the UCA output correlation, as shown in Figure 8.
    Figure 8. Attach the UCA to the intermediate message event
    Attach the UCA to the intermediate message event

Create a timer event

There are two types of timer event: one is an attached timer event, which is attached directly to an activity in a BPD, and the other is an intermediate timer event, which is connected to other process steps using sequence lines. If a timer event is not attached to an activity, it causes a delay. The process waits for the timer to trigger before proceeding to the next activity. You can use timer events to specify a time interval before or after which some activity is performed or another path in your process is taken.

Let's look at how we might use the timer event mechanism in the sample scenario. In the nested Order Confirmation Process, if the supplier changes the quantity or price of goods, the rule service will validate the order change following the business rules. In that case, the buyer may need to reconfirm the order. In this case, it is assumed that if the buyer does not confirm within 1 week (7 days), this means that the buyer has accepted this order by default.

Figure 9 shows a sample attached timer event. In the sample, the timer ensures that if a specific amount of time (in this case, 1 minute) passes after the process arrives at the Buyer Confirms Order activity, the activity will be passed and the process will proceed to the next step (end event).

Figure 9. Attached timer event example
Attached timer event example

Adding exception handling

When the processes that you develop require integration with external systems, server scripts, and other complex implementations, you need to anticipate potential exceptions and create the components required to handle those exceptions when they occur.

There are two exception events for BPDs: the intermediate exception event, which is used to catch process execution exceptions and handle exceptions with an error handler activity or further process flow, and the end exception event, which is used to throw an exception to parent processes.

In the sample purchase order scenario, the Shipper Selection is done automatically by system, which is exposed as a web service. In the Generate Order nested process, if an exception is thrown when this service is called, it is assumed that the system needs to notify the supplier.

To meet this requirement, drag the Intermediate Exception Event element from the palette into the Select Shipper activity, then add a new activity called Send Exception to Supplier to the process. Wire the Intermediate Exception Event component to the new activity, as shown in Figure 10.

Figure 10. Add intermediate exception event
Add intermediate exception event

This completes the exception handling for the Select Shipper activity. When you get errors in the Select Shipper activity, the process will automatically go to the Send Exception to Supplier activity.


Exposing a Lombardi web service

A web service definition exposes a Lombardi service (or a set of Lombardi services) as a SOAP-callable web service. This allows enterprise applications to access business process management applications developed in Lombardi. You can create and publish a web service to enable external applications to initiate a particular Lombardi service or set of services.

In the sample scenario, we'll create a web service with the appropriate inputs to call the Settle Payment UCA to send the event (caller service). To do this, complete the following steps:

  1. Create a general system service called Call Payment UCA Service.
  2. Drag an Invoke UCA element into the diagram, and specify Kickoff Settle Payment UCA as the name. On the Implementation tab, select Settle Payment UCA as the attached UCA, as shown in Figure 11.
    Figure 11. Call Payment UCA service
    Call Payment UCA service
  3. Next, you need to expose the Call Payment UCA Service as a web service for external invocation. In the Designer view, select the plus sign (+) next to the Implementation category and then select Web Service from the list to create a web service called PaymentWS.
  4. In the Operations section, click Add to choose an existing service (the Call Payment UCA Service) to add. Specify callPaymentUCA as the operation name, as shown in Figure 12.

    To view the XML description of the resulting web service and its elements and operations, click the WSDL URI in the Behavior section.

    Figure 12. Create a web service
    Create a web service

Conclusion

In Part 3 of this series, you leraned how to use some of the advanced features of WebSphere Lombardi Edition V7.1 to enrich the sample process to meet more complex requirements, including adding nested processes, milestones, event mechanisms, exception handling and exposing Lombardi web services. In future articles in the series, you'll learn how to use coaches to build human services.


Downloads

DescriptionNameSize
Purchase Order process filePurchaseOrderProcess_V3.zip452KB
Payment integration servicepayment.jar2KB

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
ArticleID=777652
ArticleTitle=Modeling your business processes with IBM WebSphere Lombardi Edition, Part 3: Advanced modeling
publish-date=12072011