Stateful Virtual Services: The Next Level of Service Simulation

When we hear the term mocks or simulated services, what often comes to mind are pre-configured transactions consisting of request/response and associated criteria to match for transactions.

Solutions like BlazeMeter Service Virtualization take traditional mocks to the next level by offering mechanisms to make them dynamic by integrating test data using data-driven services, or using parameter options and helper functions to make the response more realistic and dynamic.  

However, some use cases require state maintenance, or remembering the updates to the data, and this is an area where there are gaps with many existing mock service solutions. This type of scenario is where stateful virtual services (also known as stateful mock services) can be useful. 

This blog will take a closer look at stateful virtual services and how this latest BlazeMeter capability makes the already-innovative capabilities associated with service virtualization even more cutting-edge. 

What Are Stateful Virtual Services?

Stateful virtual services are virtualized services that replicate a variety of state changes.  

This type of virtual services can manifest itself in a few different ways:  

1. Maintaining updates to certain fields of data. For example, an update to the address field will change the address of the customer. 
2. Incremental changes to certain fields, such as how a deposit of funds into an account will change the state of the account balance.  
3. Maintaining an object state. In some complex scenarios, this may refer to maintaining a hash map of key-value data instead of storing individual values. 

Service Virtualization vs. Stateful Virtual Services 

Let us consider the scenario of updating demographics for a banking customer. If there is an address change for a customer in the bank using the address update service or API, the updated address will appear the next time we search for customer details.  

Yet address changes are not a typical use case for teams to use service virtualization, as they do not cause an actual update to the backend. This lack of updating the backend is helpful in scenarios like performance testing, which typically involves a huge data set up to deal with data burnout.  

Once an update is made, the script cannot reuse that data element and needs to move on to the next. However, since there are no true updates with a virtual service, the data element can be used several times. 

When to Use Stateful Virtual Services  

There are certain scenarios where stateful virtual services are useful: 

1. Functional Testing scenarios.
2. Training environments.
3. Sandbox environments. 

Let us take a closer look at each use case. 

Stateful Virtual Services & Functional Testing 

While doing Functional Testing, it is sometimes important to determine how the application under test behaves once the updates are made. For instance, if we update the balance amount or if we enable a certain flag on the customer account which may enable a different flow in the application etc.  

If the state is not maintained, it may not be a true end-to-end flow validation.  

Stateful Virtual Services in Training Environments 

In training environments, the trainees will want a real-world experience of how the application would behave. If they do not see the updates reflected in the application, it can be confusing and may not provide them with the real-world experience they can rely on as part of their training.  

Stateful virtual services can be helpful in addressing this scenario by providing a more realistic portrayal of application behavior. 

Stateful Virtual Services in Sandbox Environments  

In sandbox environments, instead of setting the end-to-end systems, using stateful virtual services provides a cost-effective way for developers and other team members involved in testing to do their early-stage testing without any disruptions. This is also helpful as a third-party service provider to provide environments to the number of consumers as a sandbox environment in a quick, cost-effective manner.  

Stateful Virtual Services in BlazeMeter 

We are excited to announce that BlazeMeter now supports stateful virtual services. With this new feature, BlazeMeter enables users to perform virtual service state updates and maintain global counters as part of test runs. These state updates persist between stops and restarts of the virtualized services.  

This feature is available under the processing actions of a virtual service along with other advanced features such as HTTP Calls (for making external calls synchronously) and Webhooks (for making external calls asynchronously).  

The state updates are made to data parameters in the service data and to global data parameters. Global data parameters are available to the whole service and are listed in the global scope section of the service data panel.  

The different operations that can be performed as part of state updates are as follows. These operations happen when the transaction match happens.  

• Store Object – Adds a row of values to the data entity.

• Update Object – Updates a specific value or values in an existing row in a data entity.

• Delete Object – Deletes a specific column value in an existing row in a data entity.

• Update Value – Updates a global value.

• Incremental Value – Increases or decreases a global value incrementally (typically counters).

A combination of test data and stateful updates takes Blazemeter Service Virtualization to the next level by offering a stateful virtual services capability which is a unique offering and can deliver a lot of value for its users.

Experience this latest BlazeMeter feature today with our free trial. 

Start Testing Now