This topic provides details on completing the Request Matching wizard screen when generating parameterized messages from traffic using the wizard. In this topic:
Introduction
This screen enables you to specify the following settings:
- Request/response pairs - configure how message groups map to responders
- Request correlation - configure which parameter values are used to determine which response messages in the virtual asset are sent
- Service definition: specify a service definition file that contains group and correlation definitions.
The Request Matching screen appears when the Autoconfig option is disabled in Message Grouping Review screen of the traffic wizard.
The Autoconfig option may be disabled if Virtualize is unable to automatically determine message grouping or correlations.
The wizard will present a page for each message group that you want to manually configure.
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.
Request Correlation
You can configure the responder mode and specify custom correlations based on request body, URL paths, and request headers in the Request Correlation tab.
Initial Correlations
Virtualize automatically configures initial correlations based on the traffic file, template file, and/or service definition file according to the following scenarios.
- If neither a template file nor a service definition file is provided, Virtualize will automatically generate data source correlations based on the traffic file.
- If a service definition is provided, Virtualize will determine correlations based on the service definition file. Virtualize may create additional correlations if they are detected in the traffic file.
- If a template file is provided, Virtualize will only apply the correlations saved in the template.
- If a service definition and a template file are provided and the Constrain option is enabled (default), Virtualize will determine correlations based on the template file.
- If a service definition and a template file are provided and the Constrain option is disabled, Virtualize will first apply template correlations for messages defined in the template. Virtualize will then apply correlations based on the service definition for any remaining messages that are not defined in the template. Correlations will be created based on traffic for any messages that do not match the template or service definition.
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 initial correlations that were automatically configured 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. The Parameterized Responses responder mode must be enabled to configure the data source correlations (see Configuring the Responder Mode).
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 Service Definition File
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.
