The following message-based actions are available for IBM Rational Integration Tester tests:
All message actions are opened in the message editor. For information about the parts of a message that you can edit, see Messages.
The default timeout and tolerance values of actions created by means of message exchange patterns are specified in the Default Timeout and Default Tolerance fields on the Test Editor page of the Preferences window.
The Publish action is used to send messages to a subject, topic, or queue. To publish messages, at least one transport must be configured in the project.
Both the header and the body of the message are evaluated.
Before you consider the body of the message to send, you must first configure the context of the message on the Config page:
The message configuration varies according to the transport in use. For more information, see Message bodies. Note, however, that the header and the body of the message must both be defined. The body has meaning for the applications that consume, receive, or subscribe to the message. Typically, the body structure is either arbitrary or defined at design time and stored in a schema.
The Subscribe action is used to receive messages from a subject, topic, or queue. For each Subscribe action, a transport and formatter must be selected, and you must specify the requirements for the messages that are received. The success or failure of the action depends on whether the received messages conform to the requirements.
In the example, the field called "ID" is set so that the subscriber does not attempt to validate its content, but stores the content in a tag also called "ID". The content of the field called "Live" is set to be validated but not stored.
Both the header and the body of the message are evaluated.
For information about the Timeout and Tolerance fields, see the Common concepts section of this topic.
When you are using JMS messaging, it is possible to subscribe to a topic-based destination by using a durable subscription. This can be enabled by selecting the Durable option when you are creating or modifying a Subscribe action. A durable subscription instructs the applicable messaging broker to retain any messages that arrive while the subscription is inactive. These retained messages will be presented to the application the next time it connects.
If you want to stop receiving such messages without changing the subscription, you can use the Unsubscribe action.
To unsubscribe, specify the Transport, the Durable subscription name and the Destination that were configured previously in the applicable Subscribe action.
The Send Request action is essentially the same as a Publish action, except that the request is intended for another specific action, the Receive Reply. When you are creating a Send Request, the corresponding Receive Reply is created at the same time.
You can insert different step actions between the Send Request and Receive Reply, so a list of mappings is offered for each response.
In the Receive Reply, the name that is displayed in the "Reply to" combination list is a numbered step, unless the step is renamed in the Business View. In this case, the assigned name is shown instead, but a tooltip on each entry in the combination list will detail the Technical View name for that step.
If the mapping selected in a Receive Reply action becomes invalid (that is, the action is place above the Send Request action or the Send Request action is deleted, then a red border appears around the combination list to warn the user.
The Receive Reply action is essentially the same as a Subscribe action, except that the transport is defined in the Send Request action, so there is no need (or ability) to set it. For more information, see Send Request.
For information about the Timeout and Tolerance fields, see the Common concepts section of this topic.
A Receive Request action is identical to a subscriber, except that it is used together in a test with a Send Reply action (and must come before the Send Reply in a test).
For more information, see Send Reply.
A Send Reply action is the same as a Publish action. The only difference is that a Send Reply action must be used somewhere after a Receive Request action (since it is supposed to reply to it). Therefore, instead of selecting a transport, you select an existing Receive Request action. The remainder of the action and the message are edited in the normal way.
The name that is displayed in the "Reply to" box is a numbered step, unless the step is renamed in the Business View. In this case, the assigned name is shown instead, but a tooltip on each entry in the combination list will detail the Technical View name for that step. For more information, see Test views.
Within the message switch, you can add Message Cases, described later. Each case is intended to handle a different message. The final case (created with the message switch) is the Default case that catches any message in case none of the other cases are matched. Matching a received message occurs sequentially, from top to bottom, until a match is found. The matching is manipulated with filters in the Message Case.
Within each Message Case, users can insert more actions to be carried out when the case is matched (for example, send a reply to the request, insert a value in the database).
Message cases are not actions in themselves, but are used in Message Switch actions. To add a Message Case to an existing Message Switch action, right-click the Message Switch action and select Add Message Case from the menu.
Each Message Case is configured to match a specific message that was captured (more generically) by the Message Switch action. When combined, the Message Switch action and any one of its message case work like a complete Subscribe action. The Message Switch action specifies the general transport and destination information, while the Message Case performs detailed filtering and contains the assert and store options.
If the Message Switch action is part of a stub, the Config tab provides the option to check and set the state of the stub. Under Start State and Finish State, you can select one of the available session states (configured under the Properties tab of the stub). If a start state is selected, the actions within the message case are executed only if the stub session equals the selected state. If a finish state is selected, the session is set to that state once the actions under the message case finish executing.
Additionally, before any of the actions within the Message Case can be executed, any filter expressions that are added on the Config page must evaluate to true (or at least one if the ‘OR’ expressions option is enabled). Filter expressions are available for Message Cases in both tests and stubs. Filter expressions can use either ECMAScript (such as JavaScript) or legacy functions; see Options for scripting.
The standard Filter, Assert, and Store tabs are available. For more information, see the Subscribe action in this topic.
The Message Case contains its own actions that can be carried out when a matching message is received.