Choose the Traffic> Generate Parameterized Messages option in one of the available creation wizards. See the following chapters for additional details:
- Specify the location of the traffic file.
- Change the character encoding if needed
If you want to populate the wizard with a previous group of settings saved in a template, enter the location of that template.
In the Parasoft Data Repository Settings page, specify which data repository should store the data used to parameterize the test clients or message responders and click Next.
In the Server field, specify which server you want to connect to (either the embedded server or a remote server). If you select the embedded server, the Port, User, and Password fields will be grayed out. If you select a remote server, the Port, User, and Password fields will be automatically populated and can be adjusted as needed.
- In the Repository name field, select or enter the name of the repository you want to use. If you enter the name of a new repository, that repository will be created.
When defining a repository connection, you can check the connection by clicking Validate.
When you’re working with a remote (e.g., not embedded) Data Repository server, the repository that you specify here will be locked until the wizard completes. If you want the lock to display as "locked by [your_username]" rather than "locked by [tmp]", check Configure authentication for locking, then specify the URL of the CTP server that you use, as well as your username and password for that CTP server. To learn more about locking, see Locking and Unlocking Repositories in CTP.
Configure the settings in the Message Format screen:
Verify that Request message format and Response message format are set to the correct format. If not, select the appropriate format. will attempt to identify the message format of the request and response based on the first message in the traffic file. All requests in a single traffic file are expected to have one format, and all responses in that same file are expected to have one format. The request format may be different than the request format. If the message format is not detected, Plain Text will be selected.
Conversion options are available for some formats, such as EDI or custom formats. Click the Conversion Options button and make the desired changes.
Choose one of the message grouping options:
Based on operation/type: Group messages based on the operation or message type. This is useful for service traffic that contains messages that are distinctly identifiable either by operation or by the format's message type (i.e., the name of the element under the SOAP Body, the name of the root element in plain XML messages, or the message type of a specified message format). A responder is generated for each operation/type discovered within the traffic file.
- Based on similar requests: Group messages based on request message structure. This tells Virtualize to analyze the request message structures and group the request/response into responders so that each responder will contain responses that correlate with requests that have a similar structure. Messages are considered "similar" when they have an identical DOM tree model, even if they have different values. This option is used to optimize and simplify the rules for correlating requests to responses within each Message Responder.
Based on similar responses: Group messages based on response message structure. This tells Virtualize to analyze the response message structures and group the request/response pairs into responders so that each responder will contain responses that have a similar structure. Messages are considered "similar" when they have an identical DOM tree model, even if they have different values.
None: No grouping. A responder is generated for each response message in the traffic file. Use this option if you want every request/response pair in separate Message Responders.
- The columns included are based on the grouping strategy applied.
- Each table row represents the criteria for defining a group. One group will be generated for each table row. One responder will be generated for each group.
The correlation criteria will be processed in the order in which they appear in the table (from top to bottom).
Add, modify, reorder, and remove grouping criteria using the available controls.
If you change the criteria, be sure to click Regroup before proceeding.
- Click the Request/Response pairs tab and verify that the correct correlations have been made. You can click and drag the points connecting the requests and responses to change the match.
- Click the Request Correlation tab choose a Responder mode from the drop-down menu.
- The defined record identity is used to determine which data is new and which new records match existing records. If it has not already been specified for this data set, the identity can be added/modified from the data tree in this page.
- The tree indicates identity fields with green arrow icons. Existing data sets are noted with annotations.
You can control how new data from the traffic file will extend and/or update existing repository data sets.
You can also control whether matching data (data that matches existing record types, as determined by the identity) reuses existing record types or updates an existing record. The Reuse option enables you to reuse/share the existing records that match. The Update option enables you to update the existing records’ corresponding fields with data from the traffic and add new records for new record types.
- The Infer constraints from option enables the Virtualize to determine the characteristics of the data stored in the repository. You can infer constraints based on the data or a service definition.
- You can configure the wizard to create messages in Form or Literal mode. These modes present a Form Input view (see Form Input) or a Literal view (see Literal).
You can enable the Export configuration data into a reusable template option and specify a file name and location to save the settings you used in this wizard as a template.
- Click Finish.