Put new capabilities of business activity monitoring (BAM) to work, Part 6: Integrating high-level and low-level monitor models

Document options PDF - Fits A4 and Letter 1368KB (27 pages) Get Adobe® Reader® Document options requiring JavaScript are not displayed Sample code Rate this page Help us improve this content

Level: Intermediate

Curtis Miles (crmiles@ca.ibm.com), WebSphere Business Monitor Tools Lead Developer, IBM
Ann Ewan (ewan@ca.ibm.com), WebSphere Business Modeler Information Developer, IBM　

08 Apr 2008

In this series, learn about the dramatic changes in IBM® WebSphere® Business Monitor V6.1 — a major release that extends capability and simplifies how you monitor and manage the performance of your business. This article describes how you can connect two monitor models when one is a result of exporting business measures from IBM WebSphere Business Modeler and another is a monitor model from an IBM WebSphere Integration Developer module. Learn a two-tier approach that involves creating a high-level model in WebSphere Business Modeler by exporting the model to the WebSphere Business Monitor development toolkit, generating a monitor model from WebSphere Integration Developer, and creating outbound and inbound event definitions to communicate between the models.

Introduction

In this article, learn about options for integrating high-level and low-level models. Benefits, pitfalls, and considerations of each integration style are discussed. You'll follow a scenario as a developer uses the WebSphere Business Monitor model editor to integrate two monitor models: a high-level model created in WebSphere Business Modeler and a low-level model generated from the WebSphere Integration Developer application that implements the business process described in WebSphere Business Modeler.

You'll also learn how to:

• Create an XML event definition.
• Send an event based on that event definition from the low-level model.
• Receive the event in the high-level model.
• Update the metrics and KPIs in the high-level model with the information from the event.

The model editor is a component within the WebSphere Business Monitor development toolkit. The toolkit is packaged with WebSphere Business Monitor, but installs into WebSphere Integration Developer.

Because this article requires a model from WebSphere Business Modeler, it uses a scenario that's different from the others in this series. You can download the sample WebSphere Business Modeler project file and sample WebSphere Integration Developer project interchange file.

Figure 1 shows the events that are covered in this article.

Integration options

When you create processes and business measures in WebSphere Business Modeler, you typically end up with two monitor models:

High-level model

The business-level monitor model that you exported from WebSphere Business Modeler and then imported into the model editor.

Low-level model

The IT-level monitor model that you generated from the WebSphere Process Server application that implements the business process designed in WebSphere Business Modeler.

To develop a monitoring solution that uses the information in both these models, you have the following options for integrating the models:

1. Keep both monitor models and have them communicate through events.
2. Keep only the high-level monitor model and update it with run time events.
3. Keep only the low-level monitor model and update it with business measures.

This article discusses the pros and cons of each of option and takes you through a detailed scenario for using the first option, in which two monitor models communicate through events.

Option 1. High-level and low-level models communicate through events

With this option, you keep both monitor models and use them in the solution. The two monitor models communicate through custom events that are sent by the low-level model and received by the high-level model. This option is the most flexible and the most complicated.

Table 1 shows the pros and cons of this option.

Implementation details of this option are described in the scenario, where two monitor models are created and set up to communicate through custom events emitted by the low-level model and received by the high-level model.

Option 2. High-level model is updated with run time events

With this option, you keep only the high-level monitor model and update it with run time events. It is most useful when the low-level application is stable but the business-measures requirements are changing. Use this option only when there are a small number of events of interest that carry the majority of the information required.

Add inbound events of interest directly to the high-level monitor model produced by WebSphere Business Modeler using New -> Create from Application. Then copy and paste each of the events from the generated monitoring context into the top-level monitoring context.

You might need to adjust the generated filter condition and correlation expressions for some of the copied events. Usually, you'll be able to keep the filter condition, which is designed to isolate the given event from all of the other events that are emitted by the WebSphere Process Server application. The correlation expression that is generated compares some or all of the ECSCurrentID, ECSParentID, and WBISESSION_ID values in the event to a key representing the module instance ID, process instance ID, activity instance ID, and so on.

If you've created a key in the high-level model that does not correspond to any of these pieces of information, for example by using an OrderID, you must modify the correlation expression of the copied event to compare the OrderID value in the monitoring context with the value contained in the event.

Table 2 shows the pros and cons of this option.

Option 3. Low-level model is updated with business measures

With this option, you keep only the low-level monitor model and update it with business measures. It is most useful when the business-measures requirements are stable, but the low-level application is changing. Use this option only when there are a small number of business measures to be monitored.

Copy the metrics, key performance indicators (KPIs), and anything in the dimensional model from the high-level model to the low-level model.

Specify tracking keys in the low-level model generated from WebSphere Integration Developer for any business measures whose values are to be imported into WebSphere Business Modeler to update simulation attributes. You write your own tracking keys in the model. For more information, see the product documentation Returning results using tracking keys.

Table 3 shows the pros and cons of this option.

The rest of this article takes you through a scenario using Option 1. Two monitor models are created and set up to communicate through custom events that are emitted by the low-level model and received by the high-level model.

The scenario: KateWay Animal Park

Kate started KateWay Animal Park 10 years ago, and it has been a local success story. Recently it was written up in a national travel magazine as a "must see" for visitors to that part of the state. Besides wandering the park, visitors can pay at the gate to spend the afternoon at a show, such as "Think Like a Gorilla" and the more recent "Meet the Tigers." Much of the park's revenue comes from the shows. Last year, KateWay Animal Park added a Web site where customers can order tickets in advance, which has significantly boosted Kate's business.

Kate has been running local radio ads for years, but now, seeing how well the national publicity from the magazine worked, she's considering a television campaign. Kate hopes that the TV campaign will bring in more visitors and encourage more of them to attend a show. Ideally, she would like about 200 visitors a month to attend each show. Kate plans to run a one-month trial of the TV ads, from April 1 to April 30.

Kate has asked her business analyst, Brian, to track the impact of the TV campaign. She wants to know how many visitors buy tickets for each of the shows and which of the two shows they are more likely to attend. She would like to be able to monitor the results immediately, instead of having to wait for the monthly reports.

The high-level model

Brian, the business analyst, initially used WebSphere Business Modeler to create a model of the online ticket sales process, as shown in Figure 2.

He used the TicketOrder business item, shown below, to pass information from task to task.

Brian now adds business measures to the model so he'll be able to monitor the results in WebSphere Business Monitor. He right-clicks the Record order into database task and creates a predefined business measure based on the input of the TicketOrder business item. Specifically, he wants to capture the ShowID of any show that the customer purchased so he can determine which show it was. He names the new instance metric Purchased Show ID, as shown in Figure 4.

Brian creates a KPI named Total Number of Visitors for "Think Like a Gorilla." He sets a target of 200 visitors per month, as shown in Figure 5, and adds a set of three ranges as a percentage of the 200-visitor target.

Brian then:

• Specifies a fixed time period of one month (April 1, 2008 to April 30, 2008) to monitor the number of visitors who attend during the TV campaign.

• Copies the KPI in the business-measures summary table and pastes it into the row below.

  He changes the name of the new KPI to Total Number of Visitors for "Meet the Tigers."

• Adds another KPI named Total Number of Visitors.

  He leaves that KPI empty and does not specify any target or ranges.

• Exports the preliminary monitor model, using the WebSphere Business Monitor development toolkit export.

Brian and Darcy, the integration developer who implemented the online process in WebSphere Integration Developer, discuss how to get Kate the information that she wants to see.

The low-level model

Darcy already has an application with a Web front end running on WebSphere Process Server. This application was created in WebSphere Integration Developer, and is based on the earlier model that Brian exported from WebSphere Business Modeler using the WebSphere Integration Developer export (before he added the business measures).

Darcy:

• Right-clicks her existing KateWayAnimalPark module in WebSphere Integration Developer and selects Generate -> Monitor Model.
• Names the new project KateWayAnimalParkMonitor.
• Names the monitor model KateWayAnimalParkMonitor_LowLevel.

In the Generate Monitor Model wizard, Darcy:

• Selects the main process (TicketSalesProcess).
• Selects only the Record order into database activity, because Kate is interested only in finding out about show tickets and the number of visitors who buy them.
• Clicks the Emitted Events tab, as shown in Figure 6, and selects the ENTRY and EXIT events, which are all she has to monitor to get the required information.

The elements shown in Figure 7 will be generated when Darcy finishes the wizard.

A Record order into database monitoring context is created. It contains two inbound events: one that is received when the Record order into database task starts, and another that is received when the Record order into database task ends.

Two keys are created to deliver the inbound events to the correct monitoring context:

• One based on the activity instance ID (because Darcy chose to monitor an activity in the process).
• One based on the process instance ID.

Integrating the models

After completing the low-level monitor model, Darcy copies the files that Brian exported from WebSphere Business Modeler (TicketSalesProcess.mm and two SVG files) and pastes them into her KateWayAnimalParkMonitor model project. She now has two monitor models in the project, as shown below.

To complete Brian's KPIs, Darcy goes into the high-level model and adds two more metrics: Number of Visitors and Ticket Date. She does not yet enter any expressions for the metrics, because that information will need to come from the low-level model.

Darcy decides that the two monitor models will communicate through custom events that are emitted by the low-level model and received by the high-level model.

To make this happen, Darcy needs to:

1. Create an XML event definition for the models to share.
2. Create an outbound event based on the event definition in the low-level model.
3. Create an inbound event based on the event definition in the high-level model.
4. Write expressions to set the values of the metrics and KPIs in the high-level model based on the elements and attributes in the event definition.

At run time:

1. The low-level model will receive events emitted by the application as the Record order into database task executes.
2. The low-level model will send an event each time the Record order into database task ends.
3. The high-level model will receive the event sent by the low-level model.
4. The metrics and KPIs in the high-level model will receive their values based on information in the event.

Creating the XML event definition for the models to share

First, Darcy creates the event definition for the custom event that will be passed from the low-level model to the high-level model. Because she is specifically creating an event definition to use for communication, she must keep in mind what the event definition should contain, how it should be described, and how to name it.

• The event definition must contain:
  • Information that can be used to set and refer to the key value for the high-level monitor model. Choosing the key for the high-level model is an important decision; it defines the granularity of the high-level monitoring context. Generally, the key used in the high-level model should correspond to the key used in the low-level model. For example, if the low-level model has a key that represents process instances (there is a monitoring context instance for each process instance), the high-level model should also have a key that results in one monitoring context instance for each process instance.

    The keys need not use the same value. For example, if the lower-level model is using the process instance ID, the high-level model can use an order ID, as long as there is one process instance for each order ID. The high-level model does not need to be complicated with technical information (such as process and activity ID information) from the low-level model, as long as the keys have the same granularity.

  • Information that allows the high-level monitor model to distinguish the communication event from any other events that are received by the model. This information will be used to create the filter condition.

  • Any information that is required to calculate the metrics and KPIs defined in the high-level model.
• The event definition must be described by an element declaration within the XML schema definition (XSD). This element declaration can then act as the data type for an event part in the inbound and outbound events.

• The name of the event definition should describe its usage as a communication event.

Darcy clicks the Event Definitions folder in the Project Explorer and selects New -> Event Definition (XSD). In the XML schema editor, she names the new event definition TicketSalesEvent.xsd. To contain the required information, Darcy creates a new complex type called TicketSalesEventType for the data type definition, as shown in Figure 9.

Darcy knows that this element declaration can now act as the data type for an event part in the inbound and outbound events that she will create in the monitor models. She:

1. Clicks the TicketSalesEventType type and completes the definition by adding elements. First, she adds the element that will be used to identify the event as a communication event, and calls it EventIdentifier.

   This element will have a constant value so that the high-level model will recognize the event as coming from the low-level model.

2. Adds the ID that will be used to correlate the instances from the low-level model with monitoring context instances in the high-level model. She can use the TicketOrderNumber from the WebSphere Business Modeler business item to deliver the event from the low-level model to the correct instance of the high-level model.

3. Adds all the information she wants to pass from the low-level to the high-level model: ShowID, ShowName, PurchaseDate, and NumberOfVisitors. See Figure 10.

Creating the outbound event in the low-level model

The low-level model must send an outbound event (to be received by the high-level model) when each ticket sales order finishes.

In the low-level model, Darcy creates a new outbound event and calls it TicketSalesOutboundEvent. She adds an event part called TicketSalesInfo. To specify the type of the event part, she clicks Select Type and chooses the element declaration (TicketSalesEvent) that she just created, as shown in Figure 11.

For convenience, she changes the namespace prefix from the default tns (for target namespace) to ticket.

When Darcy clicks Finish, the path attribute is completed for her because she described the structure of the event part by selecting the element declaration within the XSD file instead of directly selecting the complex type. Choosing the element declaration provides information about the structure of the event information (as would choosing the complex type). It also allows the WebSphere Business Monitor model editor to guess at the name and location of the element that will contain that information within the event.

Darcy moves down to the Event Attributes Details table and clicks Add. She selects the TerminationTrigger event as the trigger, because she wants this event to be sent to the high-level model each time that a ticket sales process ends.

Darcy enters the information to be sent in the outbound event. For the EventIdentifier, she types in a fixed value that will be used in all communication events. She chooses TicketSalesCommunicationEvent.

For the TicketOrderNumber, Darcy presses Ctrl+Space for content assist and opens the inbound event called Record order into databaseEXIT that is generated each time the Record order into database process ends. From the Output, she selects the Ticket Order Number, as shown in Figure 13.

Darcy enters the information for ShowID, ShowName, and PurchaseDate the same way.

Finally, for the NumberOfVisitors field, Darcy adds the NumberOfAdults and NumberOfChildren attributes to come up with the total number of visitors.

There are other ways to add the values. Darcy could have created metrics to temporarily hold the values, especially for performing any calculations.

Creating the inbound event in the high-level model

The high-level model needs an inbound event so that it can receive the outbound event from the low-level model. The inbound event must use the same data type as the outbound event.

In the high-level model, Darcy:

1. Creates a new inbound event and calls it TicketSalesInboundEvent. She gives it one event part called TicketSalesInfo, and chooses the same data type (TicketSalesEvent) she chose for the outbound event. Again she changes the default prefix to ticket.
   
   Figure 16. Creating the event part for the inbound event
   
   
   
2. Adds a filter condition so that only the correct type of event will be accepted as an inbound event. To achieve this, she creates a filter condition that references the piece of the event definition that is used to identify the event as a communication event. She called this piece of information the EventIdentifier when she created the event definition, and she gave it the fixed value of TicketSalesCommunicationEvent when it is sent from the high-level model.
   
   Figure 17. Adding the filter condition
   
   
   
3. Sets the inbound event to create a monitoring context when it arrives.
   
   Figure 18. Setting the event to create a new monitoring context
   
   
   
4. Adds a key to the high-level model for Ticket Order Number. This key is an integer type. The following shows the key value expression for the key.
   
   Figure 19. Adding the value expression for the key
   
   
   
5. Adds a correlation condition to the inbound event, so that the inbound event creates a monitoring context in the high-level model that corresponds to the correct process instance in the low-level model. The correlation expression compares the value in the key to the value of the Ticket Order Number in the inbound event.
   
   Figure 20. Adding the correlation expression to the inbound event
   
   
   

Setting the metrics and KPI values

Darcy can now write the expressions to set the values of the metrics and KPIs when an inbound event arrives.

The Purchased Show ID metric gets its information from the ShowID attribute in the TicketSalesInboundEvent.

Similarly, the

• Show Purchased metric gets its information from the ShowName attribute.
• Purchase Date metric gets its information from the PurchaseDate attribute.
• Number of Visitors metric gets its information from the NumberOfVisitors attribute.

Because the three KPIs are calculated from the metrics, no further implementation is required.

Testing the monitor models

The next step is for Darcy to test the monitor models and verify that they are generating the information Kate wants to see.

Darcy right-clicks one of the monitor models in the Project Explorer view and clicks Generate Monitor J2EE Projects. She is shown the names that will be given to the three parts:

• The Model Logic EJB project that contains the logic of the monitor model.
• The Moderator EJB project that receives events from the business applications and routes them to the target monitor model.
• The enterprise application (EAR) project that contains the two EJB projects.

Darcy does the same with the other monitor model. When she has generated projects for both monitor models, Darcy goes to the Server view, right-clicks her WebSphere Business Monitor server, and clicks Start.

After the server is started, Darcy:

1. Right-clicks the server and selects Add and Remove Projects. The two enterprise application projects show up in the list of available projects. She clicks each of them, then selects Add.

   When she clicks Finish, the two projects are added to the server.

2. Starts to create a dashboard that includes the metrics and KPIs that Kate wants to see. She clicks the server again and selects WebSphere Business Monitor Dashboard. She clicks Dashboards -> Manage -> New and adds a new dashboard called KateWayAnimalPark. She clicks Add to Dashboard and selects Instances. She clicks Personalize.

   On the Advanced tab, she selects the TicketSalesProcess model (the high-level monitor model) to monitor. On the Show/Hide tab, Darcy chooses to display all the metrics and clicks OK.

   
   
   Figure 22. Adding all metrics to the instances dashboard
   
   
   
3. Clicks Add to Dashboard again and selects KPIs. She clicks Personalize and selects the TicketSalesProcess (the high-level monitor model) from the list of models.

   On the layout tab she chooses to display the half-gauge view.

4. Runs the WebSphere Process Server application within the test environment, using the module or component testing capabilities or the Business Process Choreographer explorer within WebSphere Application Developer, to test that the events are generated and passed correctly.

Finally, Darcy comes back to the dashboard to make sure that the KPIs and metrics are displaying correctly. It looks as if the new projects are ready to be put into production.

Conclusion

Darcy was able to integrate the low-level model generated from WebSphere Integration Developer with the high-level model that Brian developed in WebSphere Business Modeler. Kate is now able to view the results in the dashboards, which gives her the information she needs to evaluate the effectiveness of the TV ad campaign as it is running.

Kate is delighted with the spike in attendance that resulted from the TV ads, and has decided to continue the ad campaign.

Because she is getting such timely information from WebSphere Business Monitor, Kate can monitor the total number of visitors during the month and even adjust her marketing strategy mid-month based on a dramatic increase in attendance for "Meet the Tigers," which has already met its goal of 200 visitors that month.

Kate decides to make her ad for "Meet the Gorillas" more like the "Meet the Tigers" ad. The whole campaign is very successful, and Kate is planning to create a new series of ads next year using Conan the Cat Man, the celebrity tiger-wrestler.

Back to top

Downloads

	Information about download methods

Resources

• Check out the other parts of this series:
  • Part 1, "What's new in WebSphere Business Monitor 6.1" (developerWorks, Dec 2007)
  • Part 2, "WebSphere Business Monitor 6.1 installation improvements" (developerWorks, Jan 2008)
  • Part 3, "Improved Unit Test Environment in IBM WebSphere Business Monitor Development Toolkit V6.1" (developerWorks, Feb 2008)
  • Part 4, "Use the Integrated Test Client to improve iterative development with WebSphere Business Monitor V6.1" (developerWorks, March 2008)
  • Part 5, ""Managing failed and unrecoverable events In IBM WebSphere Business Monitor V6.1'' (developerWorks, April 2008)
  
  
• Browse the WebSphere Business Monitor 6.1 online documentation for more details and reference material.
  
  
• Learn more about IBM WebSphere Business Monitor.
  
  
• developerWorks has more information on WebSphere business process management.
  
  
• Check out the Jump-start business activity monitoring (BAM) series for a wealth of WebSphere Business Monitor how-to information and samples.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  
• Get an RSS feed for the series Put new capabilities of business activity monitoring (BAM) to work.

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

		Curtis Miles currently leads the development effort for the business measures capabilities within IBM WebSphere Business Modeler as well as the Monitor model editor in the WebSphere Business Monitor Development Toolkit. He previously worked on many other aspects of WebSphere Business Modeler, including process simulation and transformation of Modeler processes to BPEL.

		Ann Ewan is a senior information developer with the WebSphere Business Modeler team. She also documents the WebSphere Business Monitor Development Toolkit. Ann has 16 years of technical writing experience and is also a published author of fantasy novels.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top