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
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
Messages must be well-formed so that responders can successfully be created from traffic automatically.
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:
- Choose the Traffic> Generate Fixed Messages option in one of the available creation wizards.
- For details on accessing the wizards, see Adding Projects, Virtual Assets, and Responder Suites.
- Click Next and choose the following options:
- Specify the location of the traffic file in the Traffic file field.
- Choose a character encoding for the Character encoding drop-down menu if needed.
- (Optional) Specify the service definition file. Providing a service definition helps Virtualize create better message groupings.
- Choose a default responder mode in the Response Strategy section (see Response Strategies).
- Click Next and Specify the message grouping option (see Messaging Group Options).
- 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, Virtualize 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.
- (MQ and JMS only) Click Next and specify your MQ or JMS connection settings.
- Click Next and complete the options in the Message Grouping Review screen (see Message Grouping Review Screen).
- Click Next and specify the name and deployment path for the virtual asset you are creating in the Deploy Virtual Asset screen. See Configuring Individual Virtual Asset Deployment Settings for additional information.
- Click Finish to create the asset. For XML messages, you can click Next to configure dynamic messages (optional).
- Dynamic messages use data extracted from the incoming message to parameterize the response message or header elements. You can complete the Configure Dynamic Messages screen for each operation that you want to parameterize. Click Next after completing each screen to advance to the next operation. For details on how to configure dynamic messages, see Completing the Configure Dynamic Messages Wizard.
- 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.
Response Strategies
The response strategy determines the default responder modes for the message groups you are configuring. You can change the responder mode for individual message groups in another screen in the wizard, but this option configures the baseline behavior for the responders added to the suite. You can specify one of the following response strategies.
| Correlated | This option generates a responder in Multiple Responses mode. In this mode, response messages will be sent based on request correlation. See Multiple Responses for additional information. In some cases, the wizard may fall back to Sequence Response or Literal mode. This may occur if Virtualize does not detect correlation criteria. If falling back to an alternate mode is necessary, Virtualize will use Sequence Response mode (see Sequence Responses) if different responses for the same request are detected in the traffic file. If all responses are the same, Virtualize will fall back to Literal Response mode (see Literal). |
|---|---|
| Sequence | This option generates a responder in Sequence Responses mode. See Sequence Responses for additional information. |
| Single response | This option selects a single message pair from the message group and generates the responder in Literal mode. See Literal. |
Messaging Group Options
You can specify the following messaging group options.
| 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. |
Message Grouping Review Screen
The columns in in the Message Grouping Review screen 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. Complete information for using this screen is in the Customizing Grouping Criteria section.
The correlation criteria will be processed in the order in which they appear in the table (from top to bottom). For details on how these groupings were created, see Understanding Heuristics for Grouping by Operation - Type.
You can use the controls to add, modify, reorder, and remove grouping criteria. If you change the criteria, be sure to click Regroup before proceeding.
The Autoconfig option enables Virtualize to automatically configure Message Responders for the specified groups. Disable the Autoconfig option to manually configure Message Responders for each message group (see Configuring Request Mapping Options).
Auto-configuration is typically available when there are multiple requests within a message group and there are differences in the paths, the parameters, or the body. If the Autoconfig box is grayed out, this means that auto-configuration is not available for this group; for more details on why a specific group cannot be automatically configured, see the tooltip for that item.
For more details on any of the items listed at the top of the panel (processed pairs, unprocessed pairs, messages that don’t match groups, etc.), click the associated hyperlinks.
To review the messages associated with a particular responder—and/or to change the responder and data set name—click the related row in the Count column.
Configuring Request Mapping Options
The Request Matching screen enables you to remap the request/response pairs and customize which parameter values are used to determine the response messages of the virtual asset. Complete details about configuring the options in the Request Matching screen are in the Customizing Request Matching and Correlations chapter.
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 all 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:
- 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.
- Choose Parameterized, then Use Data Source Wizard.
- In the wizard that opens, do the following:
- 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.
- 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).
- (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 asset 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.
