For the past three years, my work as a developer has focused in part on developing API-first microservices for the migration of a sizeable e-commerce system into the AWS Cloud.
One of the challenges I’ve faced in that role is finding a service virtualization product that is simple enough to allow for a short learning curve while also providing enough functionality to enable the range of responses that you need for thorough software testing.
That’s why I was excited to review the Community Edition of CA Service Virtualization, which simulates unavailable resources during software development in order to enable faster software delivery and more efficient, parallel workflows. It’s a handy tool for making your software delivery lifecycle more productive without increasing the size of your team or making other major new investments.
In this article, I review Service Virtualization Community Edition by setting it up and using it to work with APIs. Specifically, I’ll be running CA Service Virtualization Community Edition version 1.0.3 on Windows 10.
Installation and Getting Started
The process to register for and download the Community Edition appeared to be very straightforward. Given the size of the download, I was eager to see what features were offered and how I might be able to utilize them.
My initial impression of the Getting Started community page was that it was a little overwhelming. The page is packed with information and was apparently designed for a wider view than I initially opened it in.
Fig. 1 Initial View from the Getting Started Link
The Sign up for Free! button appeared to return me to the registration page to download the product. However, I was able to return and use the Login link to find where to register for the community. The actual link on the homepage for Getting Started was not immediately apparent. Perhaps taking the user directly to the Getting Started page, and providing an introduction to the community and a link to sign up directly from that page would allow developers to get up and running with more ease.
Having clicked on the Getting Started link first, the documentation didn’t exactly match my experience. I assumed that to follow the steps, I would need to create a new project. I was also unsure whether links should have been present in the documentation or whether there would be options in the default project when the documentation stated I should "Click any of the items to proceed with that particular method."
The documentation did do an excellent job of explaining different parts of the home screen. I found the navigation relatively intuitive and was able to rename the project and get to my first set of tasks with relative ease.
For this review, I’ll be looking specifically at the four usages highlighted on the Service Virtualization home page, specifically:
- Using the built-in API Explorer
- Recording live transactions
- Using API design specifications
- Using sample data (I have some request-response pairs from my review of CodeSV.)
Using Sample Data
I decided to start with the sample data option since I have some request/response pairs which were generated by CodeSV, and I’m interested to see how they will work with this product.
After selecting the File(s) option, I clicked the Browse File(s) button and was returned to the main screen. (I’m not sure if this was because I left the page open for a while, or changed the name of the project while I had it open.) Once I returned and clicked on File(s) again, I was given a dialog to add files to the project.
I was able to successfully import the pairs into the project, and identify and delete a duplicate pair. At this point, I returned to the documentation, as I was not sure what my next step would involve.
I was able to create a virtual service using the request/response pair. However, I ran into some difficulties. The call I was attempting to virtualize is to https://www.zipcodeapi.com. The requested URL includes an API key and several additional path parameters. A complete request would look something like this:
http://www.zipcodeapi.com/rest/JZyKNKvzMavcTNzziyPB2tm9upKOTccHLCumREmXz14CfwCgjcwy4RO0
wH3rmeV5/distance.json/97229/84015/mile
Within the transaction bundle, I was able to see the entire URL; however, when I started up the virtual service, the last two parameters were omitted from the virtual service URL. When I edited the bundle and removed the last two parameters, then saved, deleted, recreated and restarted the Virtual Service, it appeared to function as I would have expected.
I noticed, too, that of the two request/response pairs I imported, both had the same base URL, based on what appears to be a character limit. The penultimate parameter was the differentiating part of the URL. This did not appear to differentiate them in the Bundle Manager.
I did like that the virtual service created from the bundle appeared to be immutable. Up until that point, I hadn’t read anything in the documentation indicating this, but I would consider it a very desirable feature.
I also noticed that the primary transaction appeared to be the default transaction (if the last parameter was not matched with any other transactions in the bundle, provided it was only the last parameter which was changed, but not the rest of the URL).
Built-In API Explorer
The API Explorer was easy to use and proved to be a handy tool. I found the interface very clean and intuitive to use. I typically use Postman to perform API calls and test them out, but I found the API Explorer more intuitive and might use it in the future instead. I also found the Saved functionality similar to the way Chrome has implemented bookmarks in their browser, which helped make it more intuitive.
I did find out that the contents are not saved until you send the request, which wasn’t initially apparent from the interface, and there was no indication whether the request was in a changed and not saved state. (Other applications I’ve used use an asterisk, or some other small indicator that changes have been added, but not yet saved.)
Taking the saved queries and using them in the Bundle Manager was simple and intuitive.
In my daily development activities, I typically interact entirely with REST web services. (At one point in my career, I may have communicated with SOAP web services, but it’s been years if I have.) The SOAP explorer was handy, and I could see this being a great tool if I were interacting with SOAP services. I was also able to interact with a SOAP web service and better understand the API and what options were available to me.
Recording Live Transactions
The recording of live transactions was highlighted as a feature when I first started using the application, but it wasn’t clear from the interface where to do this, and it wasn’t featured in the Getting Started documentation. With the API Explorer, I was recording live transactions and adding these to the Save Transactions window. I was then able to import these into the bundle manager.
While exploring the Bundle Manager, I ran into the live recording option. It wasn’t immediately clear how it worked, and so I did some additional exploring. I assumed that if I set up a local web service, I could use the record to intercept and record calls made to the service.
I started up a small Spring Boot application on my local development machine and started the recorder. Calls to the web service did not appear to be captured by the recorder.
The transaction recording tool sounds like it would be useful, but I was unable to determine exactly how it should function.
API Design Specifications
When I read about the API Design Specification topic, I was wondering if there was a way to feed an API specification into the service and use this to virtualize the service. Like the live transaction recording, this functionality wasn't identified in the Getting Started documentation, and I had to poke around to find it.
I navigated to the Bundle Manager, clicked on File(s) and saw that I was able to import request/response pairs and Swagger and WSDL files. I used a Swagger file that I have on my local system, and instantly the Bundle Manager was populated with the specified endpoints from my file. This was likely the highlight of my experiences with the tool.
I did try to run a virtual service using the results of this. The virtual service started on port 8080—or at least it attempted to start on port 8080. There was no indication that there were any problems with the virtual service, but my attempts to interact with it were not successful.
I realized after a few minutes of unsuccessful attempts that I had previously started a web service on my machine to test the transaction recording feature, and it was also running on port 8080. Shutting down that web service and restarting the virtual service appeared to resolve my problem.
There are a couple of minor surprises that I noted with this experience. First, I’m not entirely sure why the virtual service started on port 8080. There didn’t appear to be anything in the Swagger file indicating this, so maybe it’s just a built-in default. Second, the virtual service must have failed when it tried to start, but there wasn’t a warning given that this had happened. Ideally, it would not have failed silently, but worse things have happened.
Running the Virtual Service
Overall, my experiences creating and running the Virtual Services were very positive. I did run into some problems which appear to have been caused either by the length of the URLs I was using or by the number of path parameters.
Mixing SOAP calls and the request/response pairs that I initially used when experimenting with the Bundle Manager appeared to create a virtual service which was in a weird state. The Copy URL button would respond, and it seemed that all of the URLs I tried to use defaulted to use the SOAP query, even though it was the last transaction on the list. I don’t think mixing SOAP and REST requests like this is a valid use case for the service, but it was interesting to see how the application handled it.
Conclusions
Service Virtualization fills a need for any organization whose services rely on API calls between development teams and with external service providers. Frustration with tools often leads to the development of homegrown solutions and other measures to enable development and testing to continue amidst dependencies, but that’s rarely a best practice.
I thought that the solution provided by CA Service Virtualization addressed most, if not all, of the requirements I have seen for a virtual service solution. I particularly liked the ability to import an API document, and have a virtual service serve up responses with just a few clicks.
I also liked the way in which the tool allows for the storing of transactions and enables multiple services to be created and managed. Personally, I’d be interested in seeing how this tool might be able to assist in daily development activities for my team.
