In this section:

Introduction

The Request/Response Files input mode makes use of a directory of request/response pairs, checking incoming requests against the files in the directory and, when a match is found, using the paired response as the reply. This mode will match incoming messages to request files and then return the paired response. This can make it easier to add new data since correlations are automatically configured for any new request files based on the tool’s configuration.

Pairs in the designated directory are identified by their filenames. In order to be identified as a pair, files should have identical filenames with the exception of the request file's name ending with "_request" and the response file's name ending with "_response". For example, the following files would be identified as pairs:

• getAssets_request
• getAssets_response

• createAccount_request.txt

• createAccount_response.txt

If the body of the request or response is binary, you can store it and the headers in separate files. For example, you can put the headers in the "getAssets_response" file and store the body in a file named "getAssets_response.bin". The name of accompanied binary file should be the name of the request or response file plus ".bin" (including any file extension; for example, if your headers are in a file called "getAssets_response.txt" then your bin file should be called "getAssets_response.txt.bin").

HTTP, MQ, JMS, and custom protocols are supported. It is strongly recommended that you store files of different protocols in separate directories.

Request/Response Files Options

When the Request/Response Files input mode is used, you only need to designate the directory that should be used to locate request/response pairs. You can enter the path manually or browse the File System or Workspace.

Enable Persist as Relative Path if you want the path to this directory to be saved as a path that is relative to the current configuration file (rather than a full absolute path). Using relative paths makes it easier to share responders across multiple machines.

Learning Mode Data Retention Options

Request/Response Files responders can learn to emulate live endpoints. For the learning mode process to work, a proxy must be configured with the asset containing this responder as an endpoint and it must have Learn responses enabled (see HTTP Forward Proxy or HTTP Reverse Proxy for more information).

When learning mode is enabled in the message proxy, observed traffic will be used to write request/response pairs into a data_learning folder that is automatically created in the location designated in Request/Response Files Options above. These request/response pairs can then be used by the responder along with any other pairs in the parent directory. The learning process does not affect request/response pairs in the parent directory. While learning mode is enabled, requests inside the data_learning sub-directory will be automatically updated as warranted when new responses come in.

Request/response pairs in the parent directory (that is, the location designated in Request/Response Files Options above), take precedence over those in the data_learning sub-directory. If you move one of the learned request/response pairs from the data_learning sub-directory into the parent directory, it will effectively disable learning for that request as the request/response pair in the parent directory is the one that will be used regardless of updates made in the data_learning sub-directory.

You can limit the amount of learned data that is retained. To do so, enable Number of days to keep learned data and enter the number of days' worth of data that you would like to keep. Any learned request/response pairs in the data_learning sub-directory older than that will be automatically deleted.

File Structure Options

Enable Files start with a message headers section... when the request and response files contain both headers and body. This option is enabled by default. Disable the option when the files contain only the body. In this case, the responses will get the default HTTP code as set on the Options > Return Status tab.

See Request/Response File Requirements for file requirements.

See Request Items Considered for Correlation for more information about what is used for correlation.

Exclude Patterns for Request Message Correlation

You can use the Exclude Patterns for Request Message Correlation table to define patterns that are excluded for URL query parameters, payload elements, or payload attributes. Any URL query parameters, payload elements, or payload attributes matching an exclude pattern will be ignored. Element names are specified as exact matches or using a wildcard (*) to match everything. Value patterns are specified as regular expressions. For example, the table below demonstrates an exclude pattern to ignore timestamps.

When you create a new responder, any global exclude patterns in Preferences (Parasoft > Preferences > Parasoft > Traffic File Processing) are automatically copied here. Click Add enter the Element name and Value pattern (entered as a regular expression) in the dialog that opens to create a new exclude pattern. To edit or delete an existing exclude pattern, select it and click Modify or Remove.

Request/Response File Requirements

When Files start with a message headers section... is enabled (see Message Headers Options), request and response files are expected to have the headers and body separated by one empty line. In addition:

• For HTTP, the first line in a request file should specify the HTTP method, path, and protocol, while the first line in a response file should specify the HTTP status code.
• For MQ, response files where the "messageId" header is present will have its value used as the response message ID. If the MQ client in your environment relies on a dynamically generated response message ID to correlate with the request, do not include the "messageId" header in the MQ response file.

Request Items Considered for Correlation

For request files with HTTP headers, the HTTP method, URL path, URL query parameters, and the request body are considered for correlation. Non-HTTP headers (for example, MQ, JMS) are not used for correlation. Ensure that Files start with a message headers section... is enabled when your files contain headers.

For example, assume you have the following payload in a request file with headers:

POST /parabank/services/bank/billpay?accountId=54321&amount=100 HTTP/1.1
Host: parabank.parasoft.com
Connection: keep-alive
Content-Length: 160
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=UTF-8
Origin: https://parabank.parasoft.com
Referer: https://parabank.parasoft.com/parabank/billpay.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: JSESSIONID=C86B598044C4F61C21A0DCFE019AC19B

{
	"address": {
		"street": "West 57th Street",
		"city": "Manhattan",
		"state": "NY",
		"zipCode": "10019"
	},
	"name": "Hubert J. Farnsworth",
	"phoneNumber": "212-123-4567",
	"accountNumber": "56789"
}

The HTTP method, URL path, and URL query parameters from the first line will be considered for correlation. The request body specified after the headers will also be considered. Headers specified in the file are not used for correlation.

For path matching, an incoming request can have any number of additional URL path segments prepended, but the last path segments must match those specified in the request file. In the event that multiple matches are found, the one with the most matching segments is selected. If multiple files are found with the same number of matching segments, the one whose filename comes first alphabetically is used.

If you want to exclude certain traffic patterns from the request matching process, you can use the Exclude Patterns for Request Message Correlation table. For example, if you want to ignore the URL query parameter "amount" and the "phoneNumber" element when matching requests, you could enter the following:

Request files without headers have no HTTP method, URL path, or URL query parameters to consider for correlation; only the request body is used. Ensure that Files start with a message headers section... is disabled when your files do not contain headers.

For example, consider the following XML payload in a request file without headers:

<customerDetails>
    <address>
        <street>West 57th Street</street>
        <city>Manhattan</city>
        <state code="NY">New York</state>
        <zipCode>10019</zipCode>
    </address>
    <name title="Prof.">Hubert J. Farnsworth</name>
    <contactDetails>
        <phoneNumber type="home">212-123-4567</phoneNumber>
    </contactDetails>
    <accountDetails>
        <accountNumber>56789</accountNumber>
    </accountDetails>
</customerDetails>

For example, if you want to ignore the "phoneNumber" element and the "type" attribute" when matching requests, you could enter the following:

Copying Request and Response Messages from HTTP Traffic Files

You can create the request and response files by copying request and response messages from the HTTP traffic files produced by Virtualize message proxies. When doing so, copy the entire MIME part, especially if the body is base64-encoded (as in the example below), or if the charset of the message is not UTF-8 and the message body contains non-ASCII characters. Be sure to include the beginning boundary marker, but not the boundary marker at the end of the message.

--Q29udGVudC1Cb3VuZGFyeQo
Content-Type: text/plain; charset=UTF-8
Serialization-Encoding: base64
Secure: true
Timestamp: 1565995246000
 
POST /parabank/services/bank/billpay?accountId=54321&amount=100 HTTP/1.1
Host: parabank.parasoft.com
Connection: keep-alive
Content-Length: 160
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=UTF-8
Origin: https://parabank.parasoft.com
Referer: https://parabank.parasoft.com/parabank/billpay.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: JSESSIONID=C86B598044C4F61C21A0DCFE019AC19B
 
ewogICAgImFkZHJlc3MiOiB7CiAgICAgICAgInN0cmVldCI6ICJXZXN0IDU3dGggU3RyZWV0IiwKICAgICAgICAiY2l0eSI6ICJOZXcgTmV3IFlvcmsiLAogICAgICAgICJzdGF0ZSI6ICJOWSIsCiAgICAgICAgInppcENvZGUiOiAiMTAwMTkiCiAgICB9LAogICAgIm5hbWUiOiAiSHViZXJ0IEouIEZhcm5zd29ydGgiLAogICAgInBob25lTnVtYmVyIjogIjIxMi0xMjMtNDU2NyIsCiAgICAiYWNjb3VudE51bWJlciI6ICI1Njc4OSIKfQ==