Share this page
Data modeling
The data model enables you to customize message requests and responses to manipulate the simulated behavior of a virtual service.
Overview
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.
Data model rules
The data model consists of a set of 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 several types of custom rules:
|
Rule scope
Depending on your needs, you may need to create a general rule (valid for all virtual service operations) or a specific rule which applies to a specific service operation (or subset of service operations). When you select a new rule, you specify its scope.
Tip: If you change your mind about the scope, you can modify it from the rule's context (right-click) menu.
Data Rule Configuration
You can configure rules in the following ways:
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:
-
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.
-
The Learned Data rule, to provide typical responses and service call activity of the real service.
-
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.
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.
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.
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.
See also:
- To learn more about how simulation works in Service Virtualization, see The Simulation Process.
- For task details, see Modify Virtual Service Behavior.
