This topic explains how to configure monitoring for events that occur on Parasoft Virtualize Servers.
Sections include:
Visibility into what messages are sent to and from Parasoft Virtualize Servers—and what validations and errors occur at the virtual asset level—enables you to:
For example, in a common test situation, SOAtest will send a message to a system, such as an available service or a web browser, which will then send a message to a virtual asset deployed on a Parasoft Virtualize server (for example, because the actual resources is not yet available or is not accessible for testing).
By adding an Event Monitor tool to the test suite, you gain insight into messages 2 and 3 and well as messages 1 and 4. You also see the result of any validation tools you may have attached to the virtual asset (for instance, XML Assertor tools) and receive details on any errors that may have occurred (for instance, because the virtual asset was not properly configured to process valid messages, or because invalid messages were sent).
By default, the Virtualize event monitoring service uses a built-in provider based on WebSocket. For details on how to use another provider, see Using an Alternative JMS System for Virtualize Server Event Monitoring. |
Add an Event Monitor tool to the test suite that drives the interaction with the Virtualize Server you want to monitor. Click the Event Source tab of tool’s configuration panel and choose Virtualize Server from the Platform dropdown menu and configure the following settings.
If you are connecting to a Virtualize Server 9.6 or newer and require user authentication:
Under Event Subscriptions, enable the type of events you want to monitor.
| Request messages | The message sent to a virtual asset (for example, message #2 in the diagram under Why Monitor Server Events?) |
|---|---|
| Response messages | The message that the virtual asset returns (for example, message #3 in the diagram under Why Monitor Server Events?) |
| Message validation results | The result of any validation tools you may have attached to the virtual asset, such as XML Assertor tools (for example, the tool is represented by the Validation marker in the diagram under Why Monitor Server Events?). |
| Errors events | Any errors that may have occurred, such as if virtual assets were not properly configured to process valid messages or because invalid messages were sent. In the diagram under Why Monitor Server Events?, if the virtual asset was not configured to route message #2 to a specific responder, this would be reported as an error. This also includes events from custom extensions that are designated to be at the INFO level. |
| Info events | Informational events, such as server startup and shutdown events as well as events from custom extensions that are designated to be at the INFO level. |
| Debug events | Events from custom extensions that are designated to be at the DEBUG level. |
| Warn events | Events from custom extensions that are designated to be at the WARN level. |
Specify the test failure criteria in the Test Failure Criteria section. If a validation tool is chained to the current Event Monitor tool, the following settings not applicable because the outcome of the chained validation will determine this test’s success or failure.
| Error events | The test will fail if any errors occur (for example, because responders were not properly configured to process valid messages, or because invalid messages were sent). |
|---|---|
| Validation failure events | The test will fail if a failure is reported by any validation tool (such as an XML Assertor tool) you may have attached to a responder. |
| No events received | The test will fail if the virtual asset does not receive any events before the current test suite (the one that includes the Event Monitor tool) completes execution. |
Click the Options tab, modify settings as needed.
| Clear the event viewer before each event monitor run | Enable this option to automatically clear the Event Monitor event view (both text and graphical) whenever Event Monitor starts monitoring. |
|---|---|
| Include test execution events in the XML event output to chained tools | Enable this option to show only the monitored messages and events in the Event Viewer tab and XML output display. This option also indicates when each test started and completed. Enabling this option is helpful if you have multiple tests in the test suite and you want to better identify the events and correlate them to your test executions. |
| Wrap monitored messages with CDATA to ensure well-formedness of the XML event output | Enable this option if you do not expect the monitored events’ message content to be well-formed XML. Disabling this option will make the messages inside the events accessible via XPaths, allowing the message contents to be extracted by XML Transformer or validated with XML Assertor tools. Enable this option if the message contents are not XML. This ensures that the XML output of the Event Monitor tool (that is, the XML Event Output for chaining tools to the Event Monitor, not what is shown under the Event Viewer) is well-formed XML by escaping all the message contents. This will make the content of these messages inaccessible by XPath since the message technically becomes just string content for the parent element. The Diff tool’s XML mode supports string content that is XML. As a result, the Diff tool will still be able to diff the messages as XML, including the ability to use XPaths for ignoring values, even if this option is disabled. |
| Maximum time to wait for the monitor to start (milliseconds) | Specify the maximum length of time the Event Monitor should wait to finish connecting to the event source before SOAtest runs the other tests in the suite. This enables SOAtest to capture events for those tests and prevents SOAtest from excessively blocking the execution of the other tests if the Event Monitor is having trouble connecting to its event source. Increase the value if connecting to the event source takes more time than the default. The default is 3000. |
| Maximum monitor execution duration (milliseconds) | Specify the point at which the test should timeout if, for example, another test in the test suite hangs or if no other tests are being run (for example, if you execute the Event Monitor test apart from the test suite, then use a custom application to send messages to system). |
| Event polling delay after each test finishes execution (milliseconds) | This field is not applicable. |
The Event Viewer tab will display details about the events received. It indicates the virtual asset name, the name of responder that processed that message, the response message, results of validation tools (if available), and errors that occurred. Double-clicking an item opens a dialog with additional details.
If you no events or specific error messages are reported by Event Monitor, then disable your firewall. Firewalls running where SOAtest is running can sometimes block communication between the Event Monitor and a remote Virtualize Server. If you are using the Windows firewall, it needs to be disabled prior to using Event Monitor with a remote Virtualize Server. Other firewalls may also need to be disabled.
By default, Virtualize Server events are monitored using the built-in WebSocket provider. Alternatively, you can use one of the built-in providers or another JMS system that you have. Be aware that enabling or disabling the event monitoring service or changing your provider to or from the Parasoft JMS Provider will require you to restart your Virtualize server to capture event messages.
If you have upgraded to Virtualize 2024.1 or later from a previous version, your default monitor will be the legacy built-in JMS provider. You can use the method described below to change to the built-in WebSocket provider, which can be advantageous when, for example, you want to secure events with SSL (so your Tomcat is configured to have secure ports) or when deploying in Kubernetes, where it can make setting up Ingress easier by granting single port access for virtual assets and events. |
To configure this:
If you selected a provider other than one of the built-in options (Parasoft JMS Provider or Parasoft WebSocket Provider), specify the connection settings.
Note that a default event monitoring destination and type are specified in the available controls. You need to either: - Configure your JMS system to use this default destination, or - Change the Parasoft settings to another destination that is available on your system. |
For details on the connection settings, see: