Properties tab

This tab enables you to set up states for your stub and input parameters that can determine how the stub should behave while it is executed.

The upper half of the tab comprises fields and lists that enable you to specify response times that control the performance of the stub, the input tags that should be available to the stub at run time if the stub is part of a test suite, and the number of concurrent instances that can be running at any one time.

The following table describes the fields and lists on the upper half of the Properties tab.

Control	Description
Delay Distribution	This list controls the stub’s performance, enabling you to create realistic system conditions in a single stub (that is, without having to create multiple stub instances). Delay pattern options are as follows: Fixed Uniform Gaussian
Minimum Delay (ms)	This field specifies the minimum delay time (in milliseconds) for the delay-type selected in the Delay Distribution list.
Maximum Delay (ms)	This field specifies the maximum delay time (in milliseconds) for the delay-type selected in the Delay Distribution list.
Disable performance optimizations	When selected, this check box prevents IBM® Rational® Integration Tester from attempting various performance optimizations when running the stub. The optimizations are designed for use in performance tests and they are disabled by default because they might affect the functionality of a stub. If you choose to enable the performance optimizations, verify that your stub still behaves correctly. Clearing this check box causes Rational Integration Tester to attempt to reduce the amount of processing between when a stub receives a request and sends a response. The performance optimization actions taken will depend partly on message contents, including the following examples: When receiving requests, all validations are disabled, and for all XML payloads, store and filter actions are converted to use XPath expressions. When sending responses, any store actions set on a message are disabled, and any XML content is collapsed when the stub is compiled instead of being collapsed every time a response is sent. Note: This check box is available on in Rational Integration Tester 8.5.0 or later.
Input	The window and the buttons provided enable you to define the input tags that should be available to the stub at run time if the stub is part of a test suite. All tags are available at run time because they are in the Tag Data Store. These input tags are available to test suites. Specifically, they are displayed on the Data Drive tab of the Scenario Editor dialog box where values can be entered for these tags when the currently selected stub is being started. (For more information about this, refer to Rational Integration Tester reference.) When creating or modifying a tag, the interface definition can be set by selecting the Expose as input check box on the Create Tag dialog box. (For more information about creating and managing tags, refer to Rational Integration Tester reference.)
Workers	This field specifies the maximum number of concurrent instances of this stub that can be running at any one time. Default value: 10.
Style	This list enables you to control how the stub will execute. Options are as follows: One-to-one, no looping: For each new request (message or connection) made to the stub, a thread will be taken from the pool of worker threads. After the stub’s actions have completed, the thread will be returned to the pool. If there are no worker threads available, the request will wait until one becomes available. One-to-one, looping: A thread will be assigned from the pool of worker threads to each connection. Each connection's thread will be used for all requests from that connection until the connection is closed. This enables tag values to persist between requests on a connection. If the number of open connections equals the value entered in the Workers field, there will be no further connections until a thread becomes available. This style should be used only for long-lived connections to stubs, such as TCP clients. For other connection types, the behavior of this style is identical to that of the One-to-one, no looping style. Many-to-one: If this style is selected, the Workersfield is ignored, a new thread will be created for each incoming request and destroyed once the request has been processed. This means that Rational Integration Tester will attempt to process a message immediately upon receipt but overall performance will degrade if a large number of requests occur simultaneously.
Data model	This list is used to specify the data model (if any) of the stub.
Version (major.minor)	These fields enable you to implement a version-numbering system for your stubs (if necessary).

The lower half of the tab enables you to define pass-through actions, the session states that should be available to the stub, and any environment tasks that need to be run before the stub starts. The following table describes the fields and lists on the lower half of the Properties tab

Control	Description
Pass Through	The Pass Through window lists only the set of operations for which the stub is providing virtual services (refer to the Events tab) and which have transports that have sift-and-pass-through capability. Note: For background information about this window, refer to Sift-and-pass-through capability. To configure an event’s pass-through action: Under Configuration on the Pass Through window, click the event. The Pass Through Configuration dialog box is displayed. In the Pass through action list, click one of the following options. For more information about the options, refer to Configuring transports to use sift-and-pass-through capability. Discard: HTTP and IBM WebSphere® MQ transports only. Pass Through: See the reference above in step 2. Simulate Error: HTTP and webMethods Integration Server transports only. Note: The list of options displayed depends on the transport type associated with the currently selected operation. Click OK.
States	This field specifies the session states that should be available for the stub. These will be added automatically when you add states on the Events tab. One or more states can be entered in this field by: Clicking New beside the field. Entering details about each state in the New State dialog box. Clicking OK. Note: You can also add new states on the Events tab by selecting any row under From or To on the list table and clicking Add new. When a message case is used within the stub, the state of the stub can be checked before any actions in the case are executed, and a new state can be optionally set after the actions in the case have complete executing. The session state is also stored in a system tag named `SESSION/STATE`. If required, the session state could be set by using the setTag function.
Initial State	This field specifies the stub's initial state.
Conversation Keys	This field specifies the conversation (session) keys that can be used to identify a particular conversation. For example, if you are building a stub that can track user sessions, you might want to have a conversation key called `SessionID`. One or more keys (separated by a semicolon) can be defined. These keys are mapped to a system tag named `SESSION/KEY/<KeyName>`. When an incoming message is received, key values should be stored in these tags, which are then used to identify the conversation to use.
Environment Tasks	Configure any environment tasks that must run before the currently selected stub starts. Click the plus sign icon (+) to open the Environment Tasks window. All environment tasks that were created in Architecture School are displayed. You can select one or more environment tasks. To select multiple tasks, hold the Ctrl key and click each task.
Prevent stub startup upon task failure	Select this check box to prevent the stub from starting if the task fails.

Feedback