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
If you want to remap the request/response pairs, disconnect/reconnect the mappings in the Request/Response Pairs tab as desired. 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 (or unrepresented) messages will not. 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, ensure that the Autoconfig box is cleared, then specify the desired correlation options in the Request Correlation tab shown in the subsequent 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:
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.
Disabling Request Correlations to Create Single-Response Responders
For groups that don’t have data source correlations or only have a single response, you might want to create a responder that always returns the same response. To do this, clear the Enable Request Correlation box at the top of the Request Correlation tab.
Understanding How Correlations are Used
Any custom correlations specified here are used to configure the data source correlation in the generated responder. For example, assume you specify this XPath as a Request Body correlation (in the Request Correlation tab):
That XPath will be used in the generated responder’s Data Source Correlation tab as indicated below.
Note that automatically-generated data source column names can be customized if desired.
For another example, assume you specified the following Request URL Paths correlation
The following would be used in the generated responder’s Data Source Correlation tab:
Modifying the Initial Correlations
You can modify the automatically-configured configurations using the controls available in the various correlation sections. If you have modified the settings but want to restore the page to its initial state, just click the Restore Default button.
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 Virtualize) 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.
