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.
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
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.
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
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
In this section, you'll learn some ways you can customize event handling in the sample process.
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:
- 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 Paymentas 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 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.
- 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
- 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
- Create an event-based UCA called
Settle Payment UCAto wrap the newly created Payment Service. Specify On Event for the schedule type, as shown in Figure 7.
Figure 7. Create Settle Payment UCA
- Attach the Undercover Agent to the message event.
- 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.
- 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.
- 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.
- 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
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
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
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:
- Create a general system service called
Call Payment UCA Service. - Drag an Invoke UCA element into the diagram, and specify
Kickoff Settle Payment UCAas 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
- 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. - In the Operations section, click Add to choose an
existing service (the Call Payment UCA Service) to add. Specify
callPaymentUCAas 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
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.
| Description | Name | Size | Download method |
|---|---|---|---|
| Purchase Order process file | PurchaseOrderProcess_V3.zip | 452KB | HTTP |
| Payment integration service | payment.jar | 2KB | HTTP |
Information about download methods






