This topic provides an overview of how to create parameterized test clients, such as SOAP Clients, REST Clients, and EDI Clients, from traffic that is captured in traffic logs. Sections include:

Prerequisites

  • You team must have a Data Repository Server installed and running. For details, see Installing a Remote Data Repository Server
  • Message contents must be well formed. SOAP messages must have only one top-level XML element.
  • The Data Repository does not support parameterization of JSON arrays with mixed types. If a JSON array does have mixed types, SOAtest will assume that all elements in the array are the same type as the first element.

Monitoring the Console View

It’s helpful to keep the Console view visible as you are creating tests 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 Adding a New .tst File to an Existing Project and Adding a New Test Suite for additional details.

  2. Specify the following information in the Traffic wizard and click Next:
    1. Specify the location of the traffic file. This is optional if using a Service Definition file.
    2. Change the character encoding if needed.
    3. (Optional) Specify the service definition file. Providing a service definition helps SOAtest create better message groupings.

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

  3. Click Next and choose one of the following modes from the Connection Mode dropdown and configure the connection details accordingly:
    • Host/Port:
      1. Enter the Data Repository Server's host and port. You can also choose the embedded server or an existing remote server from the dropdown menu.
        • If you select the embedded server, the Port, Username, and Password fields will be grayed out. If you select a remote server, the Port, Username, and Password fields will be automatically populated, but these can be adjusted if necessary.
      2. Select or enter the name of the repository you want to use in Repository name. If you enter the name of a new repository, that repository will be created.
      3. Specify your credentials to access the data repository server (if required).
      4. To use SSL to connect to the server, enable Use SSL.

    • Connection String: Enter the MongoDB connection string. An example of a connection string that connects to a local server with SSL is shown below. See https://www.mongodb.com/docs/manual/reference/connection-string/ for more information about MongoDB connection strings.

      MongoDB Connection String Example
      mongodb://localhost:2424/?tls=true&tlsAllowInvalidHostnames=true

      If an authentication database is specified in the connection string, you should use the /defaultauthdb component; only use the ?authsource=defaultauthdb option if credentials are specified in the connection string.

  4. Click Validate to verify the connection settings. 

  5. Click Next and configure the message format and grouping strategy:

    1. Verify that Request message format is 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. Conversion options are available for some formats, such as EDI or custom formats. Click the Conversion Options button and make the desired changes. 

    2. 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 (that is, 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.

    3. If you specified a service definition or template file, you can enable the Constrain option in the Message Group Creation Options section. If this option is enabled, only the message groups defined in either the template or service definition file will be grouped. All other messages will be ignored. If this option is disabled, SOAtest will group all messages that appear in the traffic file. If a service definition and template file are provided and this option is enabled, groupings will be constrained according to the template file prior to being constrained by the service definition. As a result, a message will be ignored if it is defined in the service definition but not in the template file. The Constrain option is enabled by default. 
    4. If you specified a service definition or template file, you can enable the Empty groups option in the Message Group Creation Options section. If this option is enabled, groups will be created based on a service definition or template file even if the traffic file does not contain messages that match the group criteria. When this option is disabled, groups without messages will not be created. The Empty Groups option is set to false by default if a traffic file is specified alongside a service definition or traffic template. The Empty Groups option is set to true by default if no traffic file is specified.
    5. Click Next and review the information about the operations and messages in the Message Grouping Review screen. 

      1. The columns included are based on the grouping strategy applied. 
      2. 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. 

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

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

      5. If you want to specify a WSDL/schema, enable the option in the Configure column and click Next to specify the appropriate values.


        The service definition options will appear based on the type of traffic. For example, if the traffic is JSON, you will have the option to specify an OpenAPI/Swagger, RAML, or WADL file. For XML traffic, you will be able to specify WSDL or Schema.

        Should you specify a WSDL or Schema?

        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.

  6. Click Finish to complete the wizard or Next to configure how the data reuse settings for the imported traffic.
    1. 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. 
    2. The tree indicates identity fields with green arrow icons. Existing data sets are noted with annotations.

    3. You can control how new data from the traffic file will extend and/or update existing repository data sets. 

      • Replace: Erase existing data then add the new data.

      • Append: Adds new records without first erasing the existing data.

    4. 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. Additional details about specifying identities and choosing among the available data reuse/updating options in SOAtest is available at Configuring Data Reuse and Updating. 

  7. Click Next and specify any additional configurations in the Final Options screen:
    1. 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).   

    2. 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. (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. See Using Configuration Templates to Reuse and Share Wizard Settings in SOAtest for details about creating and using templates.

    3. Click Finish.

The following items will be created and configured:

    • One or more test clients with parameterized values. The tools created will be SOAP Clients, REST Clients, EDI Clients, or Messaging Clients, depending on the message format. The tools will default to Form Input / Form JSON view unless the message is XML or JSON and is so large that a performance impact is expected; in that case, Literal view is used.

    • For new data repositories, a repository with applicable data sets and record types will be added. One data set will be added per message group identified by analyzing the traffic. For existing data repositories, new data sets and record types will be added to the existing repository.

    • A repository data source will be added for each added data set and each test client or message responder will be configured to use the associated data source.

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.

Custom transport headers and any SOAP Headers (for example, WS-Security Headers) that are present in the traffic file are not configured automatically into the generated assets or data repository data sets.

Completing the SOAtest Wizard: Advanced Topics

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


  • No labels

Need assistance? Visit our support page