This topic provides details on completing the Request Matching wizard page in the "Generate Parameterized Messages from Traffic" wizard. This page allows you to remap the request/response pairs, customize which parameter values are used to determine the response messages of the virtual asset, and specify the WSDL or schema associated with this message.
Sections include:
Remapping Request/Response Pairs
You can remap the request/response pairs by clicking on a connecting line and dragging its and dragging the endpoint to a different request or response. For example, if response 3 actually correlates to request 2, you would indicate this as follows:
Connected messages will be used in the generated Message Responder and data repository. Disconnected are unrepresented messages and will be ignored. If you do not want a message used in the Message Responder or data repository, you can either delete that message block or disconnect it.
To view message details, select the related message block.
Customizing Correlations
If you want to customize which parameter values are used to determine the response messages of the virtual asset, disable the Autoconfig option and configure the correlation options in the Request Correlation tab in the Request Matching screen of the wizard pages. The wizard will present a page for each message group. The Request Correlation tab automatically populates the following correlations (if applicable) and allows you to customize the initial correlations:
The Parameterized responses responder mode must be enabled to configure the data source correlations in the Request Matching screen (see Configuring the Default Responder Mode).
If you did not specify a template, the page’s initial state shows the data source correlations that were automatically-generated from the current traffic file. If you specified a template, the page’s initial state shows the data source correlations defined in the template. In this case, data source correlations won’t be automatically-generated from the current traffic file.
Understanding How Correlations are Used
Custom correlations specified in the wizard are used to configure the data source correlation in the generated responder. For example, assume you specify the following XPath as a Request Body correlation in the Request Correlation tab:/*:Envelope/*:Body/*:confirm/text()
That XPath will be used in the generated responder’s Data Source Correlation tab as indicated below.
Automatically-generated data source column names can be customized.
As another example, assume you specified the Request URL Paths correlation per the following image:
The following would be used in the generated responder’s Data Source Correlation tab:
Configuring the Responder Mode
The Responder mode option enables you to configure the response type for the message group you are configuring. You can change the responder mode for individual message groups in the Responder Correlation tab for each generated responder.
You can specify one of the following responder modes.
| Parameterized responses | This option enables you to configure the data source correlations in the Request Matching screen. The generated responder will be parameterized with values from a data repository. |
|---|---|
| Sequence responses | This option generates a responder in sequence responses mode. See Sequence Responses for additional information. |
| Single response | This option selects a single message pair from the message group and generates the responder in Literal mode. See Literal. |
Modifying the Initial Correlations
You can modify the automatically-configured configurations using the controls available in the various correlation sections. If you've modified any of the configurations, you can click the Restore Default button discard changes and restore the initial, automatically-configured settings.
If you specify the same column name multiple times (e.g., in URL Parameters and URL Paths), only one value will be set; the previous value(s) will be overwritten.
Request Body Correlations
Virtualize will generate a "name"-based XPath for each operation/group; this will be used to set the Responder Correlation for that operation. For example, if the element name under the SOAP Body is "SubmitOrder", then the XPath expression set to the responder correlation section would resemble the following:
local-name(/*/*[local-name(.)="Body"]/*)="SubmitOrder".
Note that when the message is not XML, XPaths and parameter selections are applied to the converted XML version of the request message.
For each group of messages belonging to the same operation, requests are mutually compared to determine the parameters that differ among the requests. Virtualize’s auto-configuration from traffic will automatically analyze the differences in the request elements, then use the results of this analysis to generate XPath expressions for the responses available within that operation/group. The goal is to automatically generate a response for each distinct request element. If the traffic is a SOAP Envelope, then structural differences are allowed as long as the messages share the same operation element (this is the first element under the SOAP Body). If the traffic is generic XML, then structural differences are allowed as long as the messages have the same root node.
If you want to override the initial configuration shown in the wizard page, use the available controls to specify the XPath(s) and column name(s) that you want to use.
Ignoring Certain Values for Matching Purposes
Sometimes it’s desirable to ignore certain values (such as timestamps) for matching purposes. Virtualize is automatically configured to ignore timestamps—based on the following regular expression:
[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}([.][0-9]{1,3})?(([+-][0-9]{2}:[0-9]{2})|Z)?
If you want to review, modify, or add exclusions, click the Exclusions button at the bottom of the page, then edit the values in the table. Element names are specified as exact matches or using a wildcard (*) to match everything. Values are specified as regular expressions.
If you always want to ignore certain values for matching purposes, you can enter them once in the Preferences> Parasoft> Traffic File Processing area, and have them applied every time that a parameterized virtual asset is created from traffic. See Traffic File Processing Settings for details.
Request URL Parameter Correlations
For request URL parameters, if there is any difference in the URL parameters in the invocations belonging to a message group, such as a different number of parameters, different parameters (names), or different parameter values, then Virtualize’s auto-configuration from traffic will automatically configure correlations based on those differences.
For example, assume the following parameters in the invocations for a specific message group:
countryCode=US&brandCode=HG
countryCode=Uk&brandCode=HG&channelCode=3
countryCode=US
countryCode=UK
brandCode=HG
Based on the differences in the parameters, Virtualize would automatically configure 3 data source correlation rows for this message group: countryCode, brandCode, and channelCode.
If you want to override the initial configuration shown in the wizard page, use the available controls to specify the parameter(s) and column name(s) that you want to use.
Request URL Path Correlations
For URL path, if there is any difference in the URL paths in the invocations belonging to a group, then Virtualize’s auto-configuration from traffic will configure correlations based on those differences.
For example, assume the following paths in the invocations for a specific message group:
/customer/123/account/1920384
/customer/203/account/4922434
/customer/302/account/7349463
Based on the differences in segments 1 and 3 (using 0-based indexing), Virtualize would add 2 data source correlation rows for this message group: one for path index 1, and one for path index 3.
If you want to override the initial configuration shown in the wizard page use the available controls to specify which path segment to use for correlations. Path segments can be matched with one or more data source column name, then be parameterized with various data source columns. In the dialog that opens, specify the path segment you want to use (you can click the related path segment or enter the desired path index), then specify a name for the data source column.
Request Header Correlations
Request header correlations are not added during Virtualize’s auto-configuration from traffic. If you want to correlate based on header values, provide the headers for the request values you want to extract and match, then map each to a data source column. The extracted values will be matched with values from the mapped data source columns.
Specifying a WSDL or Schema
If you want to provide a WSDL or Schema for this traffic, enter it in the WSDL/Schema tab. Advantages of specifying the WSDL or schema include:
- The generated Form Input model will be based on that WSDL/Schema, which provides type richness when you are editing and maintaining the resulting Form Input.
- Change Advisor (described in Change Management) is available to help you keep your assets in sync with evolving services and changing environment conditions.
If you notice that the generated Form Input and its data parameterizations do not match the original messages, this is a sign that the messages do not fully match the WSDL/Schema or that mapping the raw messages failed. If you are experiencing such issues, you should omit the WSDL/Schema to ensure that the generated Form Input model fully matches the traffic messages.
If you do not specify a WSDL or schema and messages, use choice or extension types, see Understanding Choice/Extension Type Support.
