Introduction

Part 3 of this series introduced the notion of iterative development within the UTE. It showed how WebSphere Business Monitor V6.1 now supports iterative development, using the mortgage lending monitor model as an example.

This article continues the discussion by focusing on one essential aspect of the development process: testing. Testing is an integral part of any development methodology. Testing can be viewed as the driving force behind iterative development, because testing determines when development has finally accomplished its job.

One goal of iterative development is to make each step as easy to execute as possible. With testing, you can achieve that goal in various ways. One way is to enable the user to create and send events on the fly. Another goal of iterative development is to make each step repeatable. It is essential that users be able to execute their test cases consistently to determine if problems in a previous iteration are indeed fixed. The turn-around time of this step is an important consideration.

In this article, learn about the ITC, a tool that can achieve the above-mentioned goals. The ITC was introduced in WebSphere Business Monitor Development Toolkit V6.1, and is available for IBM Rational® Application Developer V7.0.0.5 and IBM WebSphere Integration Developer V6.1 platforms. The ITC is installed with the WebSphere Business Monitor model editor. Part 3 gave an overview of what the ITC can do and how it fits in our iterative development story. This article uses the mortgage lending monitor model to illustrate how the ITC works.

Testing and verification in the UTE

The ITC is a graphical tool for testing monitor models that are published in a monitor test server of the UTE. WebSphere Business Monitor models consume only one event format: common base event (CBE). Testing a monitor model is nothing but sending one or more events. However, monitor models selectively consume and process events, so testing involves sending the right events. This means sending instances of events whose event definitions exist in the monitor model being tested.

Testing and verification are two activities that coincide. Verification ensures that events are consumed, evaluated, and processed correctly when testing monitor models. There are several ways to perform verification. One is to inspect the monitor database directly, but this is quite involved and requires an understanding of how metrics are stored in the database. The recommended way to perform verification is to use the WebSphere Business Monitor dashboard that is available in the UTE (discussed in Executing the test script).

Figure 1 shows an overview of the testing and verification methodology offered by the WebSphere Business Monitor V6.1 UTE. Every monitor model can be tested using its own instance of the ITC. The ITC is used to send events to IBM WebSphere Business Monitor Server, where the monitor model is published by the common event infrastructure (CEI). You can configure the WebSphere Business Monitor dashboard can to verify that events are consumed and processed correctly. The CBE browser is a Web-based tool that you can use to verify that events have been created and sent to the server.

The test scenario, which is a well thought-out plan of sending a set of events in a specific order, is fundamental to testing. When all events are sent, the expected result is based on the processing of these events. The state of the database is dependent upon the model logic, order of events, their actual contents, network traffic, availability of Web services, system clock, and so on. The dashboard reads the contents of the database and renders them for the user to see.

A test scenario in the ITC is expressed as a test script in which a user can define what events to emit and in which order. The ITC parses the monitor model and allows users to quickly create a test script. After the script is complete, it can be executed and the events will be sent to the WebSphere Business Monitor test server for consumption.

Three major design characteristics of the ITC are:

Usability

The forms and graphical interface make it very easy to create an event instance, especially when dealing with version 6.1 style of events. The ITC provides a pull-down menu for all the monitor contexts and their respective inbound-event definitions. It guides the user according to what events are valid for the given model and within a chosen monitor context.

Creating a test script is also rather easy. The editor lets the user rearrange event ordering, and it also lets the user add or delete an event. In the edit mode, the user can easily update the contents of an event. Users can also reuse an existing event, modify it, and add it as a new event. These are just a few features that make the ITC more usable than writing a set of CBE events in a file.

Repeatability

It's very important that users are able to recreate exactly the same test scenario when necessary. Hence, test scripts can be executed as many times as desired. To be able to execute the same set of commands and events at a later time, the user can save the script on a secondary storage. With the ITC, the user is empowered with more control over event creation and transmission.

Flexibility

When testing with the ITC, the user can selectively decide what set of events to send by building and saving a collection of test scripts. When loading an existing test script, the user can also reorder the events and change field values. Users can create new events on the fly, so the user experience is very dynamic and flexible.

The rest of this article discusses the ITC in greater detail using the mortgage lending monitor model (used in the previous article).

ITC basics

The classic scenario for using the ITC involves:

• A user developing a business monitoring project, such as the mortgage lending project shown in Figure 2.
  
  Figure 2. Developing the mortgage lending business monitoring project
  
  
  
• The user publishes the project into the WebSphere Business Monitor Server, as shown in Figure 3. You should start the server, as well as the generated Java™ 2 Enterprise Edition (J2EE) application, for the project.
  
  Figure 3. Published J2EE application for the mortgage lending project
  
  
  
• The user launches the ITC to start testing the business monitoring project. The ITC is launched from a monitor model (.mm file).

  Right-click the monitor model file and select Launch Integrated Test Client, as shown in Figure 4. An instance of an ITC is specific to the monitor model where you launched it from. If you are working on several monitor models, you would need the same number of ITC instances.

  
  
  Figure 4. Launching the ITC
  
  
  

Figure 5 shows the main interface for the ITC. There are two tabs at the bottom: Events and Server. You will perform most of your work in the events tab, which is where you create your events and test scripts, before you send them to the test server. The server tab is used only for configuration.

The events tab has two major parts: the event editor on the left side (with the heading "Monitor model events"), and the test script editor on the right side. Both editors comprise several buttons that will be very useful as you develop your test scenarios. See the annotations for each button in Figure 5.

Because an ITC instance is specific to a monitor model, the event editor presents the monitor model and the list of monitor contexts defined in that model. The user chooses a specific monitor context from the drop-down menu, and the ITC will automatically provide a list of all inbound-event definitions in that monitor context. The interface provides guidance on what event instance the user can create given the current monitor context.

Selecting the WebSphere Business Monitor test server

The server tab lets you specify the consumer of the events sent by ITC, for example, the target WebSphere Business Monitor test server. This is the test server where the generated J2EE application for your business monitoring project was published. ITC automatically detects the WebSphere Business Monitor test servers that you created in your UTE and presents them in a drop-down menu. As shown in Figure 6, ITC also provides the values of the following fields:

• Host name of the machine where the test server is running. In many cases, this is the local host.
• Object request broker (ORB) bootstrap port of the chosen server. The ITC uses remote method invocation (RMI) to talk to the test server. The default RMI port for WebSphere servers is 2809.

  Make sure that you have started the server before sending any events.

• WebSphere profile directory for the target WebSphere Business Monitor test server. Verify that this directory exists in the specified host name and that it has a valid installation of WebSphere Business Monitor.
• WebSphere username and password are provided if the target test server is security-enabled. These are the same credentials you use to log in to the server's administration console. If you're running on IBM WebSphere Integration Developer V6.1, then security is enabled by default. Incorrect username or password will prevent the test server from consuming the events.

The fields are not editable. The ITC guarantees that the retrieved information is correct. You can specify only one test server at a time, so multicasting the events to several test servers is not supported. However, you can reconfigure the server any time during the testing cycle. The first time you launch the ITC, it will default to the first WebSphere Business Monitor test server it detects. If you configured it to point to a different test server, the ITC will remember to use that test server the next time you launch it. This configuration is used for all instances of the ITC, regardless of the monitor model.

The ITC also supports sending events to a remote server, such as a test server that is not embedded within WebSphere Integration Developer 6.1 or Rational Application Developer 7.0.0.5.

The following sections provide details about using the ITC.

Back to top

Event editor

The most important component of the ITC is the event editor. This editor lets you create an instance of an inbound-event definition in a monitor context. As described above, the monitor context drop-down menu is populated with every monitor context defined in the monitor model. Selecting one will populate the inbound events list drop-down menu defined for this monitor context. Once an event is selected, a user can fill in the event-instance specific information.

In WebSphere Business Monitor V6.1, there are two supported event styles, which we'll call the 6.0.2 event style and the 6.1 event style. The two differ mainly in how the business payload is represented inside the CBE. The 6.0.2 event style simply uses the extended data element section of the CBE protocol to store the business payload. The 6.1 event style uses the xs:any slot of the CBE protocol to store any XML data that represents the business payload. Hence, the 6.1 event styles are also called XSD-based events.

When choosing an inbound-event definition, the ITC knows which event style the event definition is using and automatically expands the extended data element section if the event definition uses the 6.0.2 event style (or the event details section if it uses the 6.1 event style). For example, choosing the Automated_Loan_Setup_Complete event definition of the Mortgage_Lending_BAM_MC monitor context automatically expands the event details section, because it uses 6.1 event style. See Figure 7 for an example.

The business payload for 6.1 event style is composed of one or more event parts. These event parts are listed in the first box in Figure 7, where there is only one event part called automatedLoanSetupCompletePart. Each event part has a type, which determines the structure of that part's details.

1. To see the detail of an event part, click on that event part. The details will appear in the second box right below it.

   In Figure 7, the details show four fields with their corresponding values.

2. You can provide specific values for these fields to create an instance of the event definition. Click on the cell under the Value column, and you'll be able to edit the cell.

   For Date, Time, and DateTime fields, click on the three dots in the cell, and you will be prompted with a calendar.

3. You can choose the date and time values, including the time zone, as shown in part (a) of Figure 8.

   A completed form for the automatedLoanSetupCompletePart event part is shown in Figure 8, part (b).

Hybrid event definition is supported (an event definition that has both event parts and extend data elements in its business payload). In such a case, both sections will be expanded. The predefined data element section is part of the CBE protocol. Both styles of event use this section. The same is true with the property data elements, which are equivalent to the context data element of the CBE protocol. Users can choose to enter values in these sections. They are not mandatory. Default values will be provided by the ITC for the predefined data elements. Figure 9 shows some of the predefined fields in the predefined data elements section. To fill in values, click on the cell under the Values column and you will be able to edit the cell.

If you are satisfied with the values you have entered in the different sections of the event editor, click Add to append this event instance to the current test script. The ITC will perform a simple type check on your input values. You'll be prompted for any incompatible types, such as a string entered in a decimal field.

You will not be able to proceed until all values are type-compatible. When all values have passed the type checking, you'll be prompted to enter a label for the event instance you just created, as shown in part (a) of Figure 10. It is recommended that you assign a unique label for each event instance. The event instance is then appended to the current test script, as shown in Figure 10 (b). You can proceed to either continue creating new events for the current event definition, or choose a different event definition.

Back to top

Test script editor

The test script is central to the ITC; events can be emitted only through a test script. The objective is to either create a new working test script, or load an existing one from your file system. The test script editor, located on the right side of the ITC, lets you formulate a test script and save it to your local disk. The editor can process only one test script at a time. By selecting Play, the script is executed serially from top to bottom by an interpreter. A test script is an ordered list of simple commands, as follows.

Emit <event instance>

Indicates that an event instance (passed as a parameter) is to be emitted to the target WebSphere Business Monitor test server. You create the command by clicking Add in the event editor.

Sleep <milliseconds>

During execution of the script, the sleep command causes the interpreter to pause for a specified number of milliseconds. The sleep command is useful for controlling the rate of event arrival to the test server and ensuring event ordering. To add a sleep entry in the script, select Clock (as shown in Figure 5). A pop-up appears, and you can enter the sleep duration.

Import <path name>

Allows you to import an existing XML file that contains sample CBEs. The interpreter sends the CBEs serially in the same order they are written in the file. There is no pausing between these events.

To import an XML file, click Import (shown in Figure 5). A pop-up appears to let you navigate the file system and choose the XML file. Importing CBEs from a file is a powerful feature of the ITC. A more advanced discussion on this topic is reserved for the second part of this article.

Pause

Causes the interpreter to wait indefinitely. This is a variation of the sleep command and is useful when you want to manually control when the interpreter can continue executing the test script. To add a pause entry, select Pause. To break the pause and continue with the execution of the script, select Play, as shown in Figure 5.

If you want to start from the beginning of the script after a pause, select Reset. When the interpreter reaches the end of the script, an automatic reset takes place.

For illustration, let's create a test script based on a test scenario with eight main events. The same loan number is used for each event instance.

• Mortgage lending process start
• Loan application upload
• Wait until user wants to continue
• Processor validator complete
• Underwriting complete
• Closing complete
• Funding complete
• Post-closing complete
• Shipping complete

When you create a test script, it's very useful to have the model open in the WebSphere Business Monitor model editor. You can check on conditions and values needed for filters, metrics, and triggers. To create a test script that contains eight event instances, first select the Mortgage_Lending_BAM_MC monitor context. The event list will be populated with all the valid inbound events for this monitor context. The tables in the event editor will be populated with the fields that this inbound event references. The XSD or CBE that this event is based on may contain other fields or elements, but only those fields that are actually defined in the model for this event are shown.

Add the first event in the test script using the mortgage lending process start event. The important values that need to be supplied for this event are the loan number and the event name. Loan number can be any number, but you need to use the same value for all your events: this is the key correlation value for event processing. You can obtain the event-name value from the model. Notice the string for this field in the inbound event's filter-condition expression, as shown in Figure 11.

Figure 12 (a) shows an example of a test script that corresponds to our test scenario. We saved this test script as TestScenario1.xml using Save. You can also use Save as. A common use of Save as is when loading an existing test script and optionally modifying it, you can choose to save it with a different name. Figure 12 (b) shows an example of modifying the test script by adding a sleep command. Remember that new commands are always appended at the bottom of the script.

Using the editor, you can reorder the commands by using the move-up or move-down buttons. First, you need to highlight the command you wish to move. Figure 12 (c) shows how to move the sleep command toward the middle of the script. You can also remove any command in the script by selecting the command first and clicking Delete.

When you select New, the current test script is wiped out, and a blank test script starts. If the current test script needs to be saved first, be sure to save it. You will know that a test script needs to be saved if you see the asterisk mark above the filename in the script filename field, as shown in Figure 12. Load allows you to navigate the file system and load an existing test script that you've saved previously. The current test script will be wiped out and the contents of the chosen test script will be shown. This function is very useful when you have several different test scenarios to run against the monitor model.

Edit mode

An important feature of the ITC is the edit mode, which lets you modify or change values associated with existing commands in the script. For example, you can highlight one of the emit commands in your test script, then change the field values of the event instance associated with it. However, you can do this only by switching to the edit mode first. To switch to the edit mode, select Edit, as shown in Figure 5. To edit the first command in our sample test script, see Figure 13.

You'll know that you're in edit mode if the edit button is surrounded by bold lines, as shown in Figure 13. The contents of the event instance associated with the selected emit command is loaded in the event editor. You are then able to change or add values in the event. The procedures are the same as when you were initially creating the event instance, with the only difference being the Add button is grayed-out or disabled while both Commit and Cancel are enabled. After you're finished editing, you can either commit or cancel your changes.

Figure 14 illustrates committing the event instance after changing the loan number. In the same fashion, the event editor performs type checking and prompts you with a label for this event instance. You leave the edit mode the moment you commit or cancel your changes.

This feature is quite useful; it lets you send new events very quickly based on the existing script, thus improving the iterative testing experience. Often, it's adequate to change only a few fields in an event to create a completely new test scenario. Editing extends to the other commands. For example, you can change the time duration for a sleep command or the XML file for an import command. Similarly, you leave the edit mode as soon as you select OK for these commands. After a test script has been edited, an asterisk is shown in the script filename field, indicating that you need to save the current test script.

Back to top

Executing the test script

The test script is now created for the test scenario, and you're ready to execute it.

1. To start executing, select Play to start interpreting the test script. In this case, the interpreter sends the first two event instances.
2. You can monitor the progress of the interpreter through the ITC console. You can select the ITC console from the console list of WebSphere Integration Developer or Rational Application Developer. You should see something similar to Figure 15.

   The ITC is now paused and will remain so until the you select either Play or Resume.

   
   
   Figure 15. The ITC console
   
   
   
3. Launch the CBE browser to verify that the events were emitted and received by the CEI server. To launch the CBE browser, right-click on the server and select Common Base Event Browser, as shown in Figure 16.
   
   Figure 16. Launching the CBE browser
   
   
   
4. Log in to the CBE browser and click All Events. You will see the events whose server is the ITC test, as the ones shown in Figure 17. You may also find other events as a result of creating outbound events by the monitor model.
   
   Figure 17. Contents of the CBE browser
   
   
   

The next step is to check to see if the events were processed by the mortgage lending monitor model. Up to this point, you have not yet configured the dashboard. First, you need to log in to the dashboard. Right-click on the server and select WebSphere Business Monitor Dashboard, as shown below.

Use the following steps to set up your dashboard:

1. After you launch the dashboard, select the Dashboards tab at the top.
2. Click New, and name your dashboard. Accept the default layout.
3. Click on Add to dashboard link in the new layout.
4. Select Instances.
5. Click Personalize.
6. Select all the fields that do not start with "aux."
7. Accept the default number of rows and refresh rate.
8. Click OK.

Your dashboard instance view should look like Figure 19 after the first two event instances.

Resuming the test script

Select Play again to run the rest of the test script. The remaining six event instances will be sent, and you should have a fully completed loan process now. Your ITC console should look like Figure 20.

Before sending one more series of event instances to the server, you must first put a new loan number in for each event instance. To do so, go back to the first event instance and edit it as discussed previously. Remember to highlight the first event instance, then click Edit. The final state of the dashboard is shown in Figure 21.

You can see what some of the key performance indicators (KPIs) are by creating a dashboard view of those that interest you.

Use the following steps to set up your dashboard:

1. After you launch the dashboard, select the Dashboards tab at the top.
2. Click New, name your dashboard, and accept the default layout.
3. Click Add to dashboard link in the new layout.
4. Select KPIs.
5. Click Personalize.
6. Select the KPIs you want in your view.
7. Click OK.

A sample KPI dashboard is shown in Figure 22.

Back to top

Summary

The ITC is one of the many improvements in WebSphere Business Monitor Development Toolkit V6.1. With this tool, you can complete the cycle of the iterative development approach commonly used in the UTE. (To test monitor models in older versions of the toolkit, you either run an application that emits events for the monitor model being tested, or run an external tool that can emit events defined in an XML file.)

You can easily create test scripts based on your test scenarios and run them directly from the development environment. The easy-to-use interface lets you create instances of inbound event definitions declared in the monitor model in question. Above all, you can re-run the same test scripts repeatedly during the development process. For verification of the test results, WebSphere Business Monitor dashboard is recommended.

Stay tuned for the next installment of this series, which will discuss more advanced scenarios, including sending events to a remote server, simulating concurrency, and more.

Resources

• Participate in the discussion forum.
  
  
• Check out the other parts of this series:
  • Part 1, "What's new in WebSphere Business Monitor 6.1"
  • Part 2, "WebSphere Business Monitor 6.1 installation improvements"
  • Part 3, "Improved Unit Test Environment in IBM WebSphere Business Monitor Development Toolkit V6.1"
  
  
• Visit the IBM WebSphere Business Monitor V6.1 main site.
  
  
• Browse the IBM WebSphere Business Process Management information center.
  
  
• Learn more about IBM WebSphere Application Server V6.1.
  
  
• Visit the WebSphere zone on developerWorks for more information about business process management.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

About the authors

Dr. Wilfred C. Jamison is currently a manager and team lead for the Code Generation, Validator, and UTE components of WebSphere Business Monitor. He has been with IBM for eight years and worked on products including IBM Firewall and IBM WebSphere Application Server. His expertise includes network security, performance analysis, concurrent and distributed systems, J2EE, Linux, and others. He also worked on incubation projects for the On-Demand Software Development team. He has worked with customers found on the New York Stock Exchange, eBay, and Toronto Dominion Bank.

Joel Maner is a software engineer on the IBM WebSphere Everyplace Mobile Portal development team in Research Triangle Park, NC. He graduated with a BS and MS in computer science from the University of Florida. He has over five years of industry experience with WebSphere and J2EE.

Nabeel Abdallah works on the development team for the Code Generation, Validator, and UTE components of WebSphere Business Monitor.

Bret Harrison works on the development team for the Code Generation, Validator, and UTE components of WebSphere Business Monitor.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Testing and verification in the UTE
• ITC basics
• Event editor
• Test script editor
• Executing the test script
• Summary
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community