Stubs with multiple operations

You can create a single stub to manage multiple operations as a unit. Such a stub is required if you need to share state across several operations.

You can create a stub with multiple operations by monitoring and recording events that use different operations. For more information, see Creating a stub that manages multiple operations using recorded messages. Alternatively, you can create a stub for a single operation and then add more operations to it. For details, see Creating basic stubs or Creating a stub by using MEP.
  1. On the Events tab, click the green plus button (Add event) to add a new row to the table.
  2. Click the new row's cell in the Event column of the table and select the operation that you are adding to the stub.
  3. Depending on which row is selected, the Input and Activity tabs configure how the stub behaves for the operation that is in the selected row.

Create a stub with multiple operations by monitoring and recording events that use different operations. For more information, see Creating a stub that manages multiple operations using recorded messages.

If the operations that the stub contains require shared state to form a consistent response, click the Session tab for options for sharing a tag data store between events.

When you run a stub that contains multiple operations, Rational® Integration Tester generates a separate stub process for each operation. If multiple operations use the same transport, all of the stub processes for a transport receive messages that meet the following conditions:
  • The stub process has the appropriate subscription
  • The message passes any applicable filters or guard conditions
For example, consider a project that has a single WebSphere® MQ transport. Three operations use that transport:
  • op1 and op2 both receive messages on Queue1
  • op3 receives messages on Queue2

A stub that contains events for all three operations generates three stub processes (s1, s2, and s3, corresponding to op1, op2, and op3). A message put to Queue1 is made available to both s1 and s2; a message on Queue2 is sent only to s3.

Typically, only a single stub process responds to a message, though it is theoretically possible for more than one process to respond. To prevent messages from being sent to multiple stub processes, you have several options:
  • Set guard conditions for each event in the stub. See The Input tab.
  • Use the filters that some transports provide to exclude certain messages before they reach a stub. For example, HTTP-based transports can filter messages by resource path, by HTTP method, or by HTTP headers.
  • Filter by content, specifying values that must be matched in the input message for a particular event.