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.
- On the Events tab, click the green plus button
(Add event) to add a new row to the table.
- Click the new row's cell in the Event column of the table and select the
operation that you are adding to the stub.
- 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 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.