Petr works as Product Owner at Broadcom with focus on Continuous Testing products and solutions. In past he worked in architect and product roles in areas of workload automation, application security and blockchain research. His current passion is finding of innovative ways how to take Continuous Testing solutions to the next level and make them developer-friendly.

Become a JMeter and Continuous Testing Pro

Start Learning
Slack

Test Your Website Performance NOW!

arrow Please enter a URL with http(s)
Dec 10 2019

BlazeMeter Continuous Testing Expands into the Land of Full Enterprise Service Virtualization

BlazeMeter Continuous Testing platform has contained Mock Services capability since its inception. Mock Services provides a frictionless way to create lightweight mocks for HTTP services (learn more about Mock Services in our other blog). This is especially important for agile teams where it’s critical to have a quick and easy way to create mocks for development and testing and also have the ability to deploy them on demand.

 

But what if your development and testing depend on a service that is not based on the HTTP protocol? Despite the fact that HTTP became an industry standard for what we call “API” today, there are other commonly used protocols that play very important roles not only in proprietary systems, but also in modern architectures. For example, there could be TCP involved for protocols running directly over this network stack layer.  There are JMS, MQ or Kafka protocols for message, event-driven and stream-oriented architectures. Your application may depend on services based on mainframe CICS. These examples, among many others, is where Service Virtualization power is required to remove constraints and dependencies on real services based on these protocols.

 

You may be using Service Virtualization already – so many of these services are already virtualized and are ready to be used. However, as a developer or tester using the BlazeMeter Continuous Testing platform, you would like to have access to services that are available for you and provision them when needed. Wouldn’t it be cool to bind them to your tests so they will be automatically provisioned during test execution?

 

That is why it makes perfect sense to introduce Service Virtualization, a sibling of Mock Services, to BlazeMeter Continuous Testing and that is why full Service Virtualization integration has been recently introduced in our BlazeMeter Continuous Testing platform.

 

One of the key aspects for success for agile teams and shift-left practices is independence. You know that in the world of Mock Services we are talking a lot about dependencies on external services and systems which Mock Services help to eliminate. However, this is just one level of independence. Besides the systems and services your application depends on, it is also important to achieve relative independence for the external stakeholders or SMEs that could be bottlenecks, or blocking points for the team’s progress. 

 

This means access to the right tools, data and artifacts is very important. And this is why we have introduced the Asset Catalog into BlazeMeter. Having the Asset Catalog of available transactions and virtual services helps teams to quickly identify what assets are available and provision them easily if needed. The following graphic shows the Asset Catalog which lists the available virtual assets that can be used by anyone on your testing team.

 

Mock Services Asset Catalog

 

The Asset Catalog is capable of storing .mar files (file archive of virtual services created in Service Virtualization), categorizing and organizing them via BlazeMeter Service hierarchy or tags, displaying their meta-data and also providing a look inside the.mar file to see what defines the virtual service. Developers and testers can see what virtual services are available and find the one they require for their development and testing needs. As shown below, you can review the assets in detail.

 

mar files Mock Services

 

The ability to see what is available is important, but it is still not enough to act as a truly agile team under the full shift-left paradigm. 

The ability to provision a required virtual service in a “self-service” way is the next important step which is also now available in the BlazeMeter platform. Simply take a .mar file, wrap it under Mock Services and choose one of the VSEs available within your network as a target location where to deploy. Once deployed, the endpoint of the newly deployed Mock Service is available and can be used for all your development and testing needs.

 

You may know that Mock Services can be bound to BlazeMeter tests to enable “Self-defined test assets” – tests that can declare what Mock Services they require and what configuration (content, parameters settings) they expect in order to successfully execute particular scenario that depends on specific responses and behavior from Mock Services.

 

This approach is available also for Mock Services hosting the.mar files. When bound to tests, the test will make sure that the particular virtual service represented by a .mar file will be deployed (if necessary) and started before the actual test execution.

 

Virtual Service represented by .mar file

 

This enables true agility – there is no need to keep mapping between the particular tests and virtual services in various spreadsheets or internal wiki pages or creating scripts that will make sure that the particular virtual service is deployed for the particular test. 

 

Now the test knows all of that and the BlazeMeter Continuous Testing platform will handle the necessary orchestration automatically.

 

If you are familiar with BlazeMeter and Service Virtualization, I can imagine you may be tempted to ask this question: “Ok, BlazeMeter is cloud-based solution, and Service Virtualization is deployed in my network – how is it possible these two solutions could be technically integrated together?”. The linkage is created by leveraging of BlazeMeter’s Private locations concept. In this blog I won’t take a deep-dive tour into how Private locations work in BlazeMeter – but let’s describe this concept in a nutshell in relation to the subject of integration with Service Virtualization (if you are interested in details, please take a look at this detailed article in BlazeMeter’s Knowledge Base).

 

BlazeMeter Private locations enables you to run specific BlazeMeter functionalities like load engines or Mock Services runners on your on-premise (i.e. behind your firewall). This is critical in cases where you need to generate load to the application that is not exposed to the internet or to connect a Mock Service to the application that cannot reach endpoints outside of the private network. Private locations relies on agents you can easily deploy and spin up on your premise. Once an agent is running, BlazeMeter can control it and use it to perform operations within the on-premise network.

 

Here’s how it works.

 

Service Virtualization for Enterprise

 

Integration between BlazeMeter and Service Virtualization makes use of Private location agent concept. There is “Service Virtualization Bridge” (SV Bridge) agent functionality, that can be turned on. Once the agent is deployed you will point the SV Bridge to your Service Virtualization Enterprise Dashboard. Enterprise Dashboard know about all connected Registries and Registries know about all connected VSEs. This way, the SV Bridge gets a full picture about the available VSEs. This is necessary to display a list of available VSEs in BlazeMeter as well as to enable deployment of the .mar files to the selected VSE (see image below.)

 

list of available VSEs in BlazeMeter

 

To make sure that the security of Service Virtualization is fully met, all of these interactions between BlazeMeter and Service Virtualization have to be authorized – connection between SV Bridge to Enterprise Dashboard requires “SV - Enterprise Dashboard” credentials to be defined in BlazeMeter. This essentially establishes the connection between BlazeMeter and Service Virtualization Enterprise Dashboard via SV Bridge and it is a one-time task. Then, every user interaction with on-premise SV environment (i.e. ability to deploy .mar file to VSE) requires Service Virtualization credentials that every user should define in BlazeMeter. For that, BlazeMeter now supports “private” credential type that is accessible and visible only for the user that created that credential.

 

Here’s how to set it up.

 

Set up Service Virtualization in BlazeMeter

 

To summarize the steps needed to set up a connection between BlazeMeter and Service Virtualization:

 

  1. Create BlazeMeter Private Location with “Service Virtualization Bridge” functionality enabled
  2. Deploy an agent to a machine within your network from where it is possible to connect to Enterprise Dashboard
  3. Create Enterprise Dashboard credentials in BlazeMeter and specify the URL of your Enterprise Dashboard
  4. Link your Private Location agent with your Enterprise Dashboard credentials in SV ED Connections workspace settings (see the graphics below)

 

SV Enterprise Dashboard Connections

 

Please visit the BlazeMeter Guide for a detailed step-by-step instructions how to setup integration between BlazeMeter and your Service Virtualization.

 

Now you are set to connect your Service Virtualization installation with BlazeMeter and let your colleagues leverage the combined power of BlazeMeter, BlazeMeter Mock Services and Service Virtualization.

 

Feel free to check out our recent webinar where we have shown the BlazeMeter and Service Virtualization integration in action: Expand Service Virtualization Across the Enterprise: Continuous Testing with No Bottlenecks. 

 

     
arrow Please enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!