Using CA Service Virtualization › Understanding CA Service Virtualization › How Virtualization Works › How Conversational Requests are Handled

How Conversational Requests are Handled

The navigation tolerance that you can specify for every node in the tree plays an important role in how the VSM handles a conversation request. The navigation tolerance is used to determine where in the conversation tree a VSM searches for a transaction that follows the specified transaction.

Navigation Tolerance Levels

• Close: The children of the current transaction are searched.
• Wide: A close search, including the current transaction plus siblings and nieces/nephews of the current transactions.
• Loose: A wide search, plus the parent and siblings of the current transaction, followed by the children of the starting transaction. If both fail to find a match, then the starting transactions for all conversations are checked, resulting in searching the full conversation.

The following graphic shows how the navigation tolerance affects the transactions to be searched in a conversation tree. A star marks the current transaction.

At the time of recording, the VSE recorder allows for initializing the navigation tolerance on transactions the following settings:

Default navigation

Defines the default tolerance on all Meta transactions that have child Meta transactions.

Default: Wide

Last

Defines the default tolerance for Meta transactions that are "leaf" transactions without any child Meta transactions.

Default: Loose

You can change these parameters later for each node through the Service Image Editor in DevTest Workstation.

The defaults provide a better match on "right" behavior. VSE responds correctly more often in situations when current run-time sessions restart a conversation without the need to start a new conversation.

Handling Unknown Requests

An unknown request occurs in the following situations:

• When there is an active conversation
• When there is not an active conversation

  If there is not an active conversation, a request is identified as unknown if there are no stateless transactions that can satisfy the request. In this case, the service image response for unknown stateless requests becomes the reply.

If a request cannot be matched to a follow-on transaction:

• If the navigation tolerance is not CLOSE, the conversation starter transactions are given the chance to satisfy the request.
• If the request is still unmatched and a stateless transaction can produce a reply, then that is sent. The current session continues to remember where it is in its conversational tree.

If that fails, the service image response for unknown conversational requests becomes the reply.