This topic explains how to create fixed message responders from traffic that is captured in traffic logs.

Sections include:

Creating "Fixed Message" Virtual Assets from Traffic


Prerequisites

HTTP headers for the request and responses must contain a Content-Type header with xml or json content types. 

Examples:

Content-Type: application/json; charset=UTF-8
Content-Type: text/xml; charset=UTF-8

Message contents must be well-formed; otherwise, auto-creation of Message Responders from the traffic might fail. 

Tip: Monitoring the Console View

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


To automatically create and deploy "fixed message" Message Responders from traffic files:

  1. Choose the Traffic> Generate Fixed Messages option in one of the available creation wizards.
  2. Complete the first page of the Traffic wizard as follows:
    1. Specify the location of the traffic file.
    2. Change the character encoding if needed.
    3. Specify the desired message grouping option (see the box below for details), then click Next.


    Message Grouping Options

    Available options are:

    None: No grouping. A responder is generated for each response messages in the traffic file. Use this option if you want every request/response pair in separate Message Responders.

    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. This option is used in order to generate Message Responders that are optimized for data source parameterization. Since all responses within a Message Responder are similar, a data source can be generated more easily for each responder to create data-source-driven assets.

  3. (MQ and JMS only) Specify your connection settings in the next wizard page, then click Next.
  4. Complete the Deploy Virtual Asset wizard page as follows:
    1. Specify the desired name and deployment path for the virtual asset that will be created. It will be deployed at the listed endpoint. For details, see Configuring Individual Virtual Asset Deployment Settings.
    2. Click Next.
  5. Complete each Request Parameter Selection page as follows:
    1. Use the available controls to specify which parameter values should be used to deter-mine the response messages of the virtual asset. You do not need to configure these selections; you can leave the default automatic selection enabled, if desired. See Completing the Request Parameter Selection Wizard (below) for details.
    2. Click Next.
  6. (Optional) If you want to set up dynamic messages (using data extracted from the incoming message to parameterize the response message or header elements), complete the Configure Dynamic Messages page for each operation that you want to parameterize. Upon completion of each wizard page, click Next to advance to the page for the next operation.
  7. Click Finish.

Virtualize will then create Message Responders and deploy them to the local Virtualize server.

Request Messages will be analyzed for grouping based on the different operations detected in the set of messages. Each operation results in a Message Responder. In the case of SOAP messages, the element name directly under Body is used as the operation name. In the case of Plain XML, the root element is used to determine the operation.

For JSON content, a responder will be created for each response message read from the log. You will need to configure the desired responder correlation criteria after the .pva creation is finished. 

Completing the Request Parameter Selection Wizard

The Request Parameter Selection wizard will present you with a step for each operation detected in the traffic file. At this step, 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. 

  • With the automatic option,  Virtualize will analyze the differences in the request elements, then use the results of this analysis to generate XPath expressions for the multiple 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 manually select the request parameters, then you can select one or more request parameters to use for generating these multiple responses XPaths.
  • We recommend the manual option if you want control over how the correlations are generated. The automatic option is intended for quick generation/configuration in simple cases.

Completing the Configure Dynamic Messages Wizard

For each operation in the request message, Virtualize presents a Configure Dynamic Messages wizard page. The Response tab shows Aall of the possible elements for the response message and allows you to parameterize these elements with values extracted from the incoming request message. The Transport Header tab allows you to parameterize header values and properties.

To parameterize a value in the Response or Transport Header tab:

  1. Select the item that should use the extracted value.
    • If you are parameterizing an element in the response message, select that element in the response tree in the left pane of the Response tab.
    • If you are parameterizing a header value or property, select the appropriate transport and category in the Transport Header tab. If you want to parameterize a header value that is not yet shown, add it now.
  2. Choose Parameterized, then Use Data Source Wizard.





  3. In the wizard that opens, do the following:
    1. At the top of the page, select the incoming request message that you want to extract a value from, then specify whether you want to extract values from the message body or the message header.
    2. Using the controls on the left side of the panel, indicate what you want to extract and add it to the right side of the panel. The right panel lists the values you have configured for extraction, and shows the name of the data source column where they will be stored (if you keep the default setting).
    3. (Optional) If you want to specify additional options (e.g., if you want to change the name of the column used to store the value, you want the value saved to a writable data source, or you want the value stored to an existing variable) —or if you want to modify advanced XPath settings— then select the appropriate element in table on the right and click Modify. Next, configure the options as needed, then click OK. Available options are described in Options for Each Extracted Element.

After you click Finish to complete the wizard, XML Data Bank tools (or Header Data Bank tools, for headers) will automatically be added to the Message Responders that are generated. 



These tools will already be configured to perform the extractions you specified in the wizard (the ${} notation will be used to access the parameterized values). For instance, note how the following Message Responder is set to use the value that is extracted from the message request and saved into the titleKeyword column:



If you want to modify the extractions, open the tool’s configuration panel, then customize the available settings as described in XML Data Bank and Header Data Bank.

Deploying the Virtual Assets

If the .pva was created in the Virtual Asset folder, the virtual assets is automatically deployed to the local Virtualize server as the wizard completes. Otherwise, you can deploy it to local or remote servers whenever you are ready. 

For a more detailed discussion of deployment procedures and options, see Deploying Virtual Assets.

Customizing the Virtual Assets

For details on how to customize the Message Responder’s behavior, see Message Responder Overview.

  • No labels