This topic explains how to create fixed message responders from traffic that is captured in traffic logs.
Sections include:
HTTP headers for the request and responses must contain a Content-Type header with xml or json content types. Examples:
Message contents must be well-formed; otherwise, auto-creation of Message Responders from the traffic might fail. |
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:
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. |
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.
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.
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:
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.
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.
For details on how to customize the Message Responder’s behavior, see Message Responder Overview.