VSE Transactions

In lsv, a transaction consists of the request that the client sends to the service and the one or more responses that the service sends to the client.
dts105-10-4
In 
Service Virtualization
, a 
transaction
 consists of the request that the client sends to the service and the one or more responses that the service sends to the client.
The following graphic shows a transaction that has one request and one response:
VSE Transaction
A transaction typically has only one response. However, some protocols can return multiple responses from a single request.
 
 
2
 
2
 
 
Request
The request side of a transaction has the following components:
  •  
    Operation
    A categorization of similar transactions.
  •  
    Arguments
    Name/value pairs that are associated with an operation.
    An argument can represent information that the service needs to fulfill the request. For example, the service might need a user name or the amount of money to deposit.
  •  
    Body
    The payload of the request.
  •  
    Attributes
    Name/value pairs that contain information about the request.
  •  
    Metadata
    Name/value pairs that can impact how requests are handled during playback.
    For example, a messaging service might need the name of the queue to which to send the response.
  •  
    Match tolerance
    A setting that defines the criteria for matching against an inbound request at runtime.
Response
The response side of a transaction has the following components:
  •  
    Body
    The payload of the response.
    If you want to use nested CDATA sections in the response, replace the 
    ]] >
     substring in CDATA section with 
    ]] ]] ><![CDATA[>
    . These escape sequence characters
     
    prevent a CDATA section from being prematurely terminated during parsing.
  •  
    Metadata
    Name/value pairs that can impact how responses are handled during playback.
  •  
    Think time
    A setting that indicates how long to wait before sending the response.
VSE Transaction Example
Assume that an HTTP-based virtual service is created for a service that provides weather information. Let's examine one possible transaction for this virtual service.
The transaction has an operation with the name 
GET /api/weather
.
For each request, the service needs the city and the country. Therefore, the transaction has two arguments:
Name
Value
city
Dallas
country
US
The operation and arguments are derived from the request body that the virtual service environment received during the recording of the virtual service:
GET http://api.example.com/api/weather?city=Dallas&country=US
During playback, the virtual service can receive requests that have different values. For example:
GET http://api.example.com/api/weather?city=Seattle&country=US
GET http://api.example.com/api/weather?city=London&country=UK
The transaction has no request attributes.
The request metadata contains a number of HTTP-related items. For example:
Name
Value
Host
api.example.com
HTTP-Method
GET
HTTP-Version
HTTP/1.1
The match tolerance is set to Signature.
The response body contains the weather information that was requested:
{
"temp": 88,
"temp_max": 90,
"temp_min": 78,
"wind": 4.1
}
The response metadata contains a number of HTTP-related items. For example:
Name
Value
HTTP-Response-Code
200
HTTP-Response-Code-Text
OK
HTTP-Version
HTTP/1.1
The think time is set to 174 milliseconds. This value is based on the behavior that was observed during the recording of the virtual service.
Synchronous and Asynchronous
With most service protocols, including web services, HTTP, and Java, transactions happen synchronously. The request and response are directly related to each other.
With web services and HTTP, the request and response are contained in a single socket connection, and the response typically follows the request. With Java, the request and response are contained in a single thread. The response (the return value) always follows the request (a method call).
Messaging is different because it is asynchronous. The request and response messages do not have to occur in the same socket connection, the same thread, or even the same day. The client sends a request message and continues working while waiting for the response. When the response is sent from the service, the client receives it and matches it to the original request, completing the transaction.