Data Modeling

The data model enables you to customize message requests and responses to manipulate the simulated behavior of a virtual service.


Each virtual service is associated with at least one data model which can contain the recorded behavior of the service and also customized data for simulation. Each data model contains a set of rules defining data behavior for each operation in the service, and tracks to determine the order of stateful behavior.

When you create a virtual service, Service Virtualization creates a data model associated with it. The data model can be customized to set specific data rules for its individual operations.

Each virtual service can have multiple data models. Prior to a Learning session, in which real service behavior is recorded, you can select the data model to which you want to save the learned behavior. After recording, you can use this data model to mimic real service behavior during simulation.

Back to top

Data Rules

The data model consists of a set of data rules for each operation in the service. You can configure the model using the Service Virtualization default rules and functions, or create your own to customize simulated behavior.

The following types of rules are available:

Learned Data Rule The Learned Rule stores the requests and responses from learning sessions. In general, you do not customize this data but you may want to set conditions to ignore parts of the requests and responses and add service call activity.
Default Response Rule The Default Response provides a custom response for each response type or data format, to apply in cases where there is no other data, or where you want to ignore specific parts of recorded response data. The default responses are generated automatically, but you can edit them. The Default Response is used if no other rule matches the response data.
Custom Rules

Custom Rules enable you to manipulate some aspect of the simulated behavior. You can set custom responses and service call activity to specific requests enabling you to perform various testing use cases.

There are two types of custom rules:

  • Blank rules. New, empty rules enable you to customize any element of a message. For example, you may find that your learned data rule is too specific, providing you with an incomplete response. You can create a new rule to customize one element of the message, enabling you to continue to use learned data for other elements.
  • Data driven rules. Data driven rules are used to bind request and response data from an external data source. The data can then be used by multiple applications or exported from external applications, such as HPE LoadRunner or HPE Unified Functional Testing. The data source can be edited by an external application and then refreshed in the data model.

Back to top

Data Rule Configuration

You can configure rules in the following ways:

Rule Prioritization

You can set the priority of multiple rules to determine the order in which each rule is applied during simulation. This enables you to meet various simulation testing use cases. Generally, rules are applied in the following order:

  1. Custom rules or external data rules. Custom rules can be used, for example, for requests that cannot be recorded or have not yet been recorded.

    They can be placed before or after the Learned Data rule.

  2. The Learned Data rule, to provide typical responses and service call activity of the real service.

  3. The Default Response rule, to provide a single generic response or generic parts of response data where other rules do not apply.

You can also temporarily disable a rule. A disabled rule is not applied during simulation.

Service Call Activity

In many cases, the simulated service can call another service to perform some particular operation or to receive some additional data. Virtual services can simulate this behavior by adding service call activity to an operation. You can define static request data for the service call activity for any row in the rule or copy data from the virtual service request or from the response of another service call activity. If a called service also has a response, you can copy some response data from a service call activity to a virtual service response.


Another main feature of the data model are tracks. Tracks determine the order of the simulated service behavior.

In many test cases, the order of requests is important because a service may return different responses for the same request depending on the current state of the service. Service Virtualization enables you to simulate this stateful behavior using tracks. Tracks enable you to construct sequences of requests and responses in the data model for the service. During a simulation session, Service Virtualization moves along the tracks according to test requests that match the requests in the track and returns the appropriate response. For example, if the simulated service can return an approve or deny response which is determined by a particular state of the service, you can determine which response to return by specifying the sequence of requests and responses in the track.

Import Messages

New rows can be added to a rule by learning new data, by adding a new row and manually editing its cells, or by importing messages.

Importing messages is useful in the case when it is not possible or it is difficult to learn communication between a tested application and a simulated service directly, but it is possible to listen to the communication and log transported messages via another tool. It is possible to import a request and/or response part of the message in the same format as it is sent via communication protocol from a clipboard or from a file. For example, you may have an SDK that includes sample messages which you can copy. If a message is imported from a file, the file may contain only the request or response part of one message.

Multi Response

In addition to the simple simulation of a request-response pattern, Service Virtualization can simulate a request-response pattern where 0 to n responses are given per request. The number of responses can vary based on the service state. An operation may have a one-way pattern, such as clearing a shopping cart, or may include multiple responses. For example, as part of an order processing update, responses could include “order received”, “order opened”, and “order shipped”.

Service Virtualization enables both the learning and editing of multiple responses, their types, and their service states. For performance simulation, learning and simulation is limited to the response time of the first response. If learned data includes multiple responses, Service Virtualization looks only at the first response time. During simulation, all responses are sent at that first response time.

These features are available on both the Service Virtualization standalone server, and the embedded server. The supported protocols are XML and binary services over WebSphere MQ and JMS.

Back to top

See also: