It’s helpful to keep the Console view visible as you are creating tests and/or message responders from traffic. This view will display any warnings, errors, and informational messages that are generated while processing the traffic file.

Using the Wizard

  1. Choose the Traffic> Generate Parameterized Messages option in one of the available creation wizards. See the following chapters for additional details:Adding a New .tst File to an Existing Project and Adding a New Test Suite.

  2. Complete the first page of the Traffic wizard:
    1. Specify the location of the traffic file.
    2. Change the character encoding if needed
    3. If you want to populate the wizard with a previous group of settings saved in a template, enter the location of that template.

      See Using Configuration Templates to Reuse and Share Wizard Settings for details about creating and using templates in SOAtest.

    4. Click Next.

  3. 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

  4. Complete the Message Format and Grouping Strategy page, then click Next.

    1. Verify that Request message format and Response message format are set to the correct format. If not, select the appropriate format.

      SOAtest 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.

    2. If you want to configure any conversion options that are available for the selected formats (e.g., for EDI or custom formats), click the Conversion Options button to the right of that format and make the desired changes. 

    3. Specify the desired message grouping option (see the box below for details), then click Next.

      Available options are:

      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.

  5. In the Message Grouping Review page, review the information about the operations and messages found. 

    The types of columns shown depends 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). URL paths and parameters will be parameterized against a field from the record type. The fields will have an automatically-generated name and will be visible in the Data Reuse page (later in the wizard).

  6. Add, modify, reorder, and remove grouping criteria using the available controls. See Customizing Grouping Criteria for details on configuring grouping criteria in SOAtest.If you change the criteria, be sure to click  Regroup before proceeding.

  7. In the Data Reuse page, configure how you want the imported traffic to reuse or impact existing data.
  8. In the Export Template page, specify template export settings (if desired), then click Next

    (MQ and JMS only) Specify your connection settings in the next SOAtest wizard page. These settings will be applied to the tools created from this traffic. For details, see Configuring MQ Options and Configuring JMS Options.

  9. Click Finish.

The following items will be created and configured:

For example, here is a sample REST Client parameterized with data repository values:

Here is part of the corresponding repository:

This parameterized, data-driven REST Client can now be run with a broad and varied scope of test values—without requiring any modification to the tool itself. Rather than edit the tool, you would modify or extend the associated data repository values.

For details on how to edit and extend the data stored in the data repository, see Viewing and Modifying the Repository Structure and Contents.

Note that custom transport headers and any SOAP Headers (e.g. WS-Security Headers) that are present in the traffic file are not configured automatically into the generated assets or data repository data sets. You can specify them in the generated Message Responders.

Completing the SOAtest Wizard: Advanced Topics

The following topics provide additional details that will help you complete the wizard: