Content-Based Correlation

This lab features enables you to define content-based correlation for operations in your virtual service.

Overview

The request-response communication pattern used by the majority of virtualized services needs to be able to correlate (pair) requests sent from client to server with their responses sent from the server back to the client.

Typically, transport level correlation is used. For example:

  • Services using HTTP transport, such as SOAP or REST, use HTTP-based correlation in which the response is sent in the same HTTP (TCP) connection as the request.
  • Many other types of services using messaging transports, such as JMS, WebSphere MQ, or Microsoft MQ, typically use Message ID & Correlation ID headers to correlate requests with their responses.

In some services, however, message correlation is carried out on the application level instead of using the more common transport level correlation. For example, there may be a “correlation ID” stored somewhere in the XML message body of an XML over MQ service, such as in the following example:

 

Example:
Request:

<StockOrder>
    <OrderNumber>17931868</OrderNumber>
    ....
    <OrderLines>
      ....
    </OrderLines>
</StockOrder>

Response:

<CustomerOrderConfirmation>
    <CompanyId>MyCompany</CompanyId>
    <OrderConfirmation>
        ...
        <OrderNumber>17931868</OrderNumber>
        ...
    </OrderConfirmation>
</CustomerOrderConfirmation>

This example shows messages from an XML service that is using content-based correlation. In this case, the correlation ID is stored in the /StockOrder/OrderNumber path of the request and in the /CustomerOrderConfirmation/OrderConfirmation/OrderNumber path of the response.

The path of the correlation ID is specific (proprietary) to each application and is not defined by any well-known specification. This means that since Service Virtualization cannot know how requests and responses are correlated, it cannot, by default, learn and analyze this communication.

The Service Virtualization Content Correlation lab feature allows you to select the message nodes containing correlation IDs, enabling you to learn & analyze a service that uses proprietary correlation. In this example, the following needs to be configured in Service Virtualization to successfully learn these messages:

  1. Ignore the standard transport related correlation.
  2. Use the value of the node (XML element or attribute) on path /StockOrder/OrderNumber of each request as the request correlation ID.
  3. Use the value of the node /CustomerOrderConfirmation/OrderConfirmation/OrderNumber of each response as the response correlation ID.

Then Service Virtualization can automatically pair request and response messages with the same correlation ID value.

You can define multiple nodes holding correlation IDs for each operation of a virtual service. Service Virtualization looks for nodes in processed messages in the same order as the paths of the correlation ID nodes are defined in the service description. The first such node found is taken as the correlation ID of the message. Definition of multiple nodes per message may be useful if messages have several optional parts holding a correlation ID or with multiple responses of different structures.

Back to top

Implement content-based correlation

  1. Prerequisites:

    1. On the Labs page, review the list of supported protocols, and enable the Content Correlation lab feature.

      For details, see Enable Lab Features.

    2. The service description of the virtual service must first be familiar with the message schema of the real service, to allow you to browse and select its nodes. A virtual service with a known message schema may be created by selecting XSD files during service creation, or by importing sample messages into the data model from the Data Model Editor.

  2. In the Service Description Editor, under Message Correlation, define correlation details:

    1. For each operation, select User-defined by Message Content.
    2. Click Add or Edit to select the message nodes to use for correlation.
  3. Depending on your application, the following two steps are usually necessary for successful simulation after learning.

    In the Learned Data rule in the date model:

    1. Set the Ignore function on the request column containing the correlation ID, according to the nodes you selected in step 2. This is required because the ID is usually unique. If correlation ID is not set to Ignore, future requests to the virtual service during simulation that have different values than the correlation ID will not match the recorded rules and will return default responses only.

    2. Set the Copy from function on the response column containing the correlation ID, according to the nodes you selected in step 2. This copies the proper value of the correlation ID from the request to the simulated response. If the correlation ID is not copied, your real client application may not be able to correlate its own requests with the responses received from the virtual service.

Back to top