Recording Studio method

This is the most effective method of creating a message-based stub if you have access to "live" systems from which you can record events, and it enables you to create very quickly stubs that behave like real services.

IBM® Rational® Integration Tester Recording Studio perspective provides Event Monitors, which enable you to determine which parts of the environment you want to record. For example, you might want to record events relating to specific parts of the system’s infrastructure, or you might want to record events relating to specific services that use the system’s infrastructure. After you have decided what you want to record, you can start recording events.

Note: For general information about using Rational Integration Tester’s Recording Studio, including the use of Rational Integration Tester proxies for recording events, refer to Rational Integration Tester reference.

The environment must modelled in Rational Integration Tester’s Architecture School perspective (Logical and Physical Views) before it can be recorded. However, for many technologies, you need to model only the transports (for example, a web server or an IBM WebSphere® MQ Queue Manager), so there is no need to define any operations.

While events are being recorded, they are displayed on the Recording Studio perspective’s Events View window; and you can add or remove Event Monitors, and filter which events are displayed on the Events View window by selecting different monitors on the Event Monitors window.

Note: Recording events does not usually interfere with the operation of the system under test. For many (but not all) transports, events will still be dealt with in the same way that they would have been if Rational Integration Tester was not being used. The only difference is that the events will be accessible through Rational Integration Tester.

After you have completed recording events, you can use them to create any of the resource-types outlined in the following table by saving the events and using the Save wizard provided.

Resource-Type Description
Unit tests The data within recorded events may be hard-coded into a unit test.
Integration tests The data within recorded events may be hard-coded into an integration test.
Stubs The data within recorded events may be hard-coded into a basic stub that always returns the same response.
Triggers Events can be reused in the form of triggers, which enable you to simulate the system under test directly from Rational Integration Tester.

You can then record what happens in response. However, this will not necessarily be the same as what happened when you created the triggers, and you will not be validating any events recorded in response to the triggers.

Thus, you can send events to the system under test and bypass the GUI layer (and any other layers of the system that you might want to bypass) and determine how the system reacts to various inputs.

Requirements You may want to save a message for subsequent use but not specify how it will be used.

You could choose to save the message as an example message that can be viewed in Rational Integration Tester Requirements Library and (optionally) imported into other Rational Integration Tester resources.

Operations If you have an incomplete model of the system under test, events recorded from the transports within the system can enable you to create new operations within your system model.
Test data sets The data within recorded events may be entered into a data set, such as a comma-separated value (CSV) file, or a data model, which maps the relationships among data items in the system under test.

The following describes how to use the Recording Studio perspective to create the following message-based stub-types:


Feedback