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.

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 and message 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 both URL query parameters and payload elements. Any URL query parameters and payload elements 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": "New New York",
		"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.

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 payload in a request file without headers:

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

You can exclude certain traffic patterns from the request matching process using the Exclude Patterns for Request Message Correlation table. For example, if you want to ignore the "phoneNumber" element 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==