Using CA Service Virtualization › Using the Workstation and Console with CA Service Virtualization › Creating Service Images › Using Data Protocols › Generic XML Payload Parser Data Protocol

Generic XML Payload Parser Data Protocol

The Generic XML Payload Parser identifies that the requests and responses are XML strings. Using this protocol, you can identify variables out of the XML messages that the recorder uses.

Note: For the Delimited Text Data Protocol, Copybook Data Protocol, and DRDA Data Protocol, this functionality is enabled by selecting the XML Elements as request arguments check box on the data protocol configuration windows.

Identifying Conversations and Transactions

The quality of the recorded service image is directly dependent on how much information VSE has to identify the conversations and the individual transactions in them. Specifically, VSE needs help differentiating the transactions from each other:

• As part of a conversation: Identifying some unique ID representing a session.
• As an individual operation: Identifying some information specific to the semantics of the operation. For example, distinguishing an "order creation" operation from an "order listing" operation.

VSE internally knows many patterns for which to search. For example, for HTTP virtualization (if the server is a Java server) VSE sets a cookie that contains the value of a special variable that is named as sessionid. The sessionid variable uniquely identifies the session. VSE can use the variable to distinguish different sessions.

However, VSE sometimes needs further help, which can be supplied as follows:

• In the HTTP recording, VSE lets you identify tokens.
• For the JMS protocol, you could identify whether VSE uses a JMS correlation ID, custom JMS headers, or all JMS headers for this identification.
• VSE lets you specify a dynamic data protocol that lets you get meaningful information from the message itself. The following section describes this technique.

Using the Generic XML Payload Parser is a technique to help VSE inspect the body of the recorded messages (payload) and extract meaningful information from them to help identify the transactions. This technique can be the only way to get meaningful conversation information, especially for opaque protocols like the WebSphere MQ native protocol.

Note: When using both the Generic XML Payload Parser and the Delimited Text data protocols, add the Delimited Text data protocol before the Generic XML Payload Parser. Otherwise, the request never appears as parsed in the recorder.

Follow these steps:

1. To use a dynamic data protocol, in the Data Protocols tab of the VSI Recorder, select Generic XML Payload Parser, if the payload is a well-formed XML.
2. Go through the rest of the steps, up to the cleanup step.

   After the cleanup step, the following window opens:

   

   By default, no starter transactions are identified, so DevTest does not know which data to review to identify the conversations. However, the Other Transactions list shows the recorded transactions.

3. To see the XML payload in the Content area, click the first transaction.

   

   The XML tab in the Content area shows the classic XML view. The DOM Tree tab shows the payload in the tree format.

   Note: This portion of the window is similar to the panel that appears when you create an XML XPath filter. As described in "XML XPath Filter" in Using, you can use the lisa.xml.xpath.computeXPath.alwaysUseLocalName property to ignore the namespace.

4. To identify a specific node as a parameter for VSE, click the node on the DOM Tree tab. The XPATH Query box displays the query that corresponds to the selected node. To evaluate the XPath query on the current payload, click .

   The result of the evaluation is shown under the heading Filter Run Results.

5. To add this XPath query to the parameter list, click Add .

   A menu displays where you can set an operation, an argument, a meta parameter, or the request body. For example, use the menu to select an embedded SOAP document to the request body so that the WS SOAP protocol can be used to parse the document.

   

6. Click Protocol Control Info. DevTest remembered the XPath string that you identified and gave it an argument name. You can rename the argument. Also from this panel, use the Save and Restore buttons to save your list of XPaths to a file, or to load a list of XPaths from a file. By saving and loading, you can easily copy and paste from one XML Payload Parser to another.

   

   Likewise, you can pull other variables from this transaction or others. It is not required for all transactions to have the specific argument. At the time of processing, if a specific argument is not present in the payload then it is ignored.

   If you scroll to the right on the Protocol Control Info panel, you see an NS column in which you can add or edit namespace definitions. To locate and import an XML file from the file system and use the namespace definitions from that file, use the Browse button.

7. Double-click a transaction in the XML tab and you can see a dialog showing the content of the transaction.
8. Click Next when you are satisfied with your choice of variables. You are then directed to the post-processing window.