3 tips for creating virtual services for an Enterprise Service Bus (ESB)

How much of an approximation virtual services might be?

I have been asked this question recently by a senior technical test infrastructure architect. After drilling down to details, I have found that an example he was interested in was, for example, virtualizing an existing ESB (Enterprise Service Bus) in an environment where there are no stubs or virtual services used yet.

I would rate virtualizing a whole ESB a medium or hard difficulty task, depending on the details. Ideally, I would avoid virtualizing large ESBs as your first service virtualization project if possible and pick other simpler APIs to start with. If you have to do it though, here are my top 3 tips. Please bear in mind there is a possibility they might not apply in your case. Every case is different, especially when visualizing large APIs sets.

Don’t boil the ocean

I have made this mistake myself on one of the projects. We were very confident we will be able to deliver virtual services for the whole ESB in a few months, but after a month we have realised the APIs are so complex that there is no way we could even understand some of them without spending weeks in discussions with the developers.

If you have more than 50 endpoints in your ESB, do not try to virtualise everything in one go and spend months doing it. Find a small subset of 1 to 10 APIs that cause problems for the test team and virtualize them in a week or two. Then let the testing teams use those virtual services.

Do service virtualization in small increments of work, delivering value to testing teams on a regular basis. Don’t make them wait for months; it is too risky.

Use record-replay if possible

I was once on a project where the requests and responses contained a lot of data. A SOAP request or response could have included a hundred of different key-value pairs. The XML structure was simple, but the complexity was in the data.

If you have an existing environment with many requests and responses going through the ESB, it is likely those are quite complex APIs. Creating virtual services from a WSDL file will generate the data in the virtual services for you that is unlikely to be representative. It is very likely to be invalid data. To avoid problems like that, use record-replay to create virtual services, this way you capture the request and response structure as well as the data.

Is virtualizing the ESB a good idea at all?

Ask yourself this question, are you virtualizing in the best place? Maybe it would make sense to virtualise some of the backend systems “below” the ESB instead? Maybe it would be valuable and easier to virtualise somewhere “above” the ESB instead? The answer to this question depends heavily on your environment. Contact us to schedule a free 20-minute consultation to help you understand what is the best plan of action in your case.

What is your experience with virtualizing ESBs?

Reducing Third Party Test Transaction Costs

If you have never heard about stubbing or service virtualization, this article should be a good basic introduction for you on how to reduce test transaction costs. If you already know about stubbing and service virtualization have a look at Traffic Parrot introduction or browse other posts on our blog instead.

Test transaction costs in banking and insurance

Many banking and insurance systems connect to third party services that charge for usage on a per-transaction basis. This will often include but is not limited to accessing market data or detecting fraud.

Testing and test transaction costs

When software is tested together with a third party service, you have to pay for the requests your systems make. In many cases, those costs become significant reaching more than $1k per test suite run. This results in unhealthy decision dynamics, like reducing the amount of testing done or decreasing the frequency of test cycles which later increases the technical debt accumulation.

Reducing the costs

There is a simple solution to that problem. Instead of testing the system always connected to the third party service you can introduce a new testing phase and test with a test double pretending to be the real system. After the system has been tested in isolation, you can proceed integration testing but do only a minimal amount of it. This should reduce the third party test transaction costs to the absolute minimum. We have seen a reduction in third party transaction of up to 93%.

Other benefits

Service virtualization is a popular practice across the industry. Implementing it will not only reduce third party test transaction costs. It has other advantages as well, for example resolving test data setup and environments uptime issues. For more details have a look at our introduction to service virtualization video.

Next steps

Contact us for a free 20-minute consultation call to help you get started with service virtualization or have a look at our introduction to service virtualization video.