This topic explains how to configure and apply the Event Monitor tool, which traces the internal events within systems (for example, ESBs, Java applications, databases, and so on) and allows you to make them part of SOAtest’s end-to-end test scenarios. Sections include:

Understanding the Event Monitor

The Event Monitor tool provides visibility into intermediary messages without requiring direct access to the messaging system’s interface. Additionally, you can apply the available tool set to validate whether messages satisfy functional expectations.

SOAtest provides built-in support for monitoring many systems, including:

• TIBCO Enterprise Messaging System
• Sonic Enterprise Service Bus systems
• Oracle Service Bus
• Software AG webMethods Broker
• IBM WebSphere ESB
• Other JMS-based systems
• Java applications
• Relational databases

You can also configure the tool to monitor any custom API-based events source, such as non-JMS systems from other vendors, custom logging frameworks, and so forth. 

To configure it, you tell SOAtest how to connect to your system and what you want it to monitor.

When you run the test suite, SOAtest will start the event monitor and then keep it running as the test suite’s tests execute. SOAtest monitors and reports the specified events/messages as they occur. Additional tools can then be chained to validate or further process the monitored events/messages.

Tool Configuration

The configuration procedure depends on what type of system you’re monitoring. This tool can be used for:

• Monitoring Oracle Service Bus
• Monitoring Software AG webMethods Broker
• Monitoring Sonic ESB
• Monitoring TIBCO EMS
• Monitoring Other JMS Systems
• Monitoring Databases
• Monitoring a Custom API-Based Events Source

You can monitor more than one target component by adding additional Event Monitors to your test suite and configuring each one accordingly.

Test Suite Execution

Test suite execution is the typical and recommended usage of the Event Monitor tool. Add an Event Monitor tool to your test suite and make it the first test before the test step where you want it to start monitoring. When you select and run the parent test suite, the Event Monitor will start automatically at the appropriate step and continue monitoring while the rest of the tests in the test suite execute. It will stop when the first of the following two events take place:

1. The last test in the test suite (or last row in the data source, if the test suite tests are iterating over a data source) has completed execution, the last event has been retrieved, and the monitoring connection has been destroyed.
2. The maximum monitor execution duration (this value is configured in the tool’s Options tab) has been reached.

You do not need to set the Event Monitor's parent test suite to Tests run concurrently. SOAtest will automatically recognize the Event Monitor as a special tool and manage its concurrent execution accordingly.

Stand-Alone/Ad-Hoc Execution

You may configure the connection settings of an Event Monitor and execute it on its own while exercising your target systems outside of SOAtest. For example, you may wish to monitor JMS messages in a back-end middleware system while you manually browse the Web interface of your application.

To watch the events being logged in real time, open the Event Viewer tab. The Event Monitor tool will run for the duration that is set under Options tab’s Maximum monitor execution duration (milliseconds) setting. Such ad-hoc execution is not applicable when the Custom events source option is enabled with the Poll after each test execution pattern.

Viewing Monitored Events

Events will be reported and visualized in the Event Viewer tab within the Event Monitor tool configuration panel.

To view monitored events during in real time, keep the Event Viewer tab (in the Event Monitor tool’s configuration panel) open during test execution.

There are two tabs available: the graphical view and the text view.

In the graphical view, click on an event to see message details.

Using Data Sources

Event Monitor itself is not parameterizable with a data source. However, if the tests inside the test suite that includes the Event Monitor tool are parameterizable, it will start monitoring before the first actual test (following the Event Monitor test) and first data source row executes, and it will stop monitoring when all data sources rows have been used. This ensures that you will obtain a single, seamless log of events regardless of how the tests iterate inside the test suite.

Retrieving Events from Other Platforms

The Event Monitor tool has extensibility hooks that allow it to obtain events from a variety of sources besides the built-in platforms and systems that it supports. See Extensibility API Patterns for details.

Validating Monitored Messages

If the transaction executes correctly, you can add regression controls for monitored messages as described in Configuring Regression Testing. In addition, you can add validations as described in Adding Test Outputs. The available validation tools are listed in Validation Tools.

You can also monitor the system while the transactions execute (for example, trigger the transaction from the Web interface), and then generate tests automatically from these messages. This includes tests for transaction entry/exit points, as well as tests for intermediate parts of the transaction. In this way, you can reproduce issues quickly, create tests with real values rapidly, then isolate the system and create regression tests around the pieces and components of the transaction. For details on how to do this, see: 

• Creating Tests from Sonic ESB Transactions
• Creating Tests from TIBCO EMS Transactions
• Creating Tests from JMS System Transactions