This topic describes how to create virtual assets in CTP from traffic captured with a Parasoft proxy. See Creating Virtual Assets from Service Descriptions for information about creating virtual assets from service definitions. In this section:
You can create parameterized virtual assets from recorded HTTP/S, JMS, or MQ traffic from the Create Virtual Assets screen in CTP. For each pass through the wizard, CTP creates one virtual asset (.pva) file with Message Responders that are automatically parameterized with values from a repository that's created on a Parasoft Data Repository server. Data values can then be manipulated independently of the virtual asset.
The virtual asset creation functionality is designed to process JSON or XML format messages. To create virtual assets from traffic files using other message formats (e.g., EDI, plain text, etc.), refer to the Creating Parameterized Message Responders from Traffic section in the Virtualize desktop documentation.
Creating virtual assets from traffic requires:
|
To create virtual assets from traffic:
If you want to modify the automatically-configured request correlations and/or specify the correlated WSDL/schema, expand the associated table row, then configure the correlations and/or WSDL/schema. See Customizing Data Source Correlations for details on how to configure correlations.
Specifying a WSDL or schema ensures that data definitions are tailored to the WSDL/schema rather than inferred by the traffic. Moreover, when you're working with this virtual asset in Virtualize desktop, you also gain richer editing functionality and Change Advisor capabilities. |
If you want to save the settings you used in this wizard, check Export a reusable template and indicate the desired file name. By default, traffic will be recorded in a file named %n_%d_%t.traffictemplate within the current server's recorded_traffic folder (this will be created if it does not exist). When specifying the file name, you can use variables such as %d (current date) %t (current time), %n (name), and %u (unique time-based id).
Click Create Asset.
The following items will be created and configured:
Video Tutorial: Creating a Virtual Asset from Recorded TrafficLearn how to create virtual assets from recorded traffic in this tutorial. |
When you create virtual assets from traffic, the associated Virtualize server groups request/response pairs by operation/type. The grouping method is influenced by both a) Virtualize’s analysis of the given traffic and b) the grouping criteria that you choose to apply. Recommended grouping strategies are automatically selected; these recommendations can be adjusted and overridden as you see fit.
Virtualize takes the approach of analyzing the traffic in two stages: first, it recommends what grouping strategies should be enabled, and then it uses the selected strategies to divide the messages into groups. When creating PVAs, one responder is generated for each group.
The recommended grouping strategies are selected based on the following heuristics:
When grouping, Virtualize:
The following grouping strategies can be applied:
Split the generated Message Responders based on the HTTP method (POST, GET, PUT, etc.). When this strategy is enabled, each unique HTTP method results in a Message Responder getting generated.
For example, if the traffic contains 10 POST messages and 15 GET messages (regardless of their order), Virtualize will create 2 responders in the generated PVA: one for the POST messages and one for the GET messages (assuming that no other grouping strategies have triggered further splits in the groups).
The resulting groups can be customized so that a group can capture messages of more than one HTTP method. For example, if both POST and PUT are enabled within a group, then messages using the POST method and messages using the PUT method will match the group and get assigned to it. In other words, the responder that is generated based on that group will correlate with both POST and PUT messages (it will accept either one).
Split the generated Message Responders based on the uniqueness of URL paths. Each unique HTTP URL path results in a Message Responder getting generated. The configuration for grouping by HTTP URL Paths essentially defines that uniqueness.
When groups are first generated based on this strategy, the paths are analyzed to produce a set of path expressions that would best characterize the type of messages. That characterization uses a path analysis algorithm that is inherently subjective. It is designed to account for the most common patterns in REST services, but it is possible that the generated path criteria need to be adjusted for optimal results.
For example, if the traffic contains the following HTTP URL paths (omitting HTTP methods, URL parameters and other factors for brevity)
/service/order/v1/1/summary/service/order/v1/2/summary/service/order/v1/2/summary/service/customer/v1/a/contact/service/customer/v1/b/contact/Foo/Foo
Virtualize will create three responders in the generated PVA:
These responders will be generated using Ant-style wildcards, where * matches zero or more characters and ** matches zero or more directories.
Virtualize configures URL path segment indexes when creating a new PVA so that each group (responder) can respond to the same requests with varying URL Path values. It configures URL path parameters by providing a segment index. For example, given the following URLs
Virtualize will designate the fifth path segment (the one with the 4 digit number) to be parameterized with a data source. Response data for each of these IDs can then be data-driven without the need to edit the PVA. |
Split the generated Message Responders based on the presence of HTTP URL parameters. Each set of one or more URL parameters results in a Message Responder getting generated.
For example, if the traffic contains the following URL parameters
?oid=1&category=women?oid=2&category=women?oid=1&category=babies?ssn=1234567890&state=CA&category=silver?ssn=1234567891&state=CA&category=gold
Virtualize will split the responders in the generated PVA based on the presence of oid, ssn and state parameters as follows (each responder to have the following responder correlation criteria)
Split the generated responders based on a list of XPath expressions that are evaluated on the request content. Each XPath expression represents a group and XML Message correlation criteria.
When this strategy is enabled, SOAP messages are (by default) grouped based on first element name under Body. For non-SOAP XML content, messages are grouped based on root element name.
Note that when a custom message format (or a built-in non-XML one) is used, the XPath expressions are based on the converted XML format of the requests
Responder correlations (described above) determine which messages a Message Responder tool accepts and processes. Various messages sent to the virtual asset URL are routed to specific Message Responder tools (each of which handles different operations) based on the settings here. For example, one Message Responder tool might respond to customer registration messages, another might respond to payment messages, and another might function as a default "catch all" that is used when none of the others match.
After the automatically-configured responder correlations are processed,values in the incoming message are compared (matched literally or with an expression) to values in a data source and the responder uses the matching row data to create a response message. If no data source row is found matching the specified incoming message value, then (with the default failover settings) Virtualize will continue searching the responder suite for a responder with matching responder correlation.
Virtualize automatically populates the following data source correlations (if applicable) and allows you to customize the initial correlations:
The following configures a correlation between the loanAmount value in incoming messages and the Amount column within the ApprovalLists data source:
For each incoming request, the loanAmount value will be matched to one of the rows in the Amount column. The response will then be parameterized with values from other columns for that same row. |
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.
If you want to have everything in the message processed, disable data source correlations by checking the Disable data source correlation option. |
To customize the automatically-configured data source 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 look like 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. See Specifying XPaths for details on using the XPath selector.
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=HGcountryCode=Uk&brandCode=HG&channelCode=3countryCode=UScountryCode=UKbrandCode=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. For example, if you wanted to configure a data source correlation for the productCode parameter, you might use:
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.
For example, if you wanted to use path index 2 and match it to the account data source column, you would configure the correlation as follows:
