Hello, and welcome back.
In the last two videos, we covered how to create virtual services from traffic. And this is a great approach to creating virtual services because you get everything all at once, you get all of your data, and you get the correlations of Virtualize server really handles well with removing a lot of the complexity. Before that, we are creating virtual services that were very simple like Hello World.
In this video, we're going to focus on the more common virtual service, which is somewhere right in the middle. And we're going to create a virtual service from a service definition file. To demonstrate this, we are going to cover these topics, Service definition introduction, Creating virtual assets from a service definition, Deploying those virtual assets, Monitoring virtual assets, and finally Configuring those virtual assets.
The idea behind creating virtual services from the service definition is that early in the development of an application, you can get the service definition and start to create a virtual service that can be used by both the consumer of the service and somebody who wants to ultimately test that service to get earlier access. As it turns out, in the Parabank application, we do have access to service definitions and the one that we're going to be working with today can be found on the Admin Page and it is the Swagger documentation or the documentation associated with RESTful Services. When we are interacting with the UI, there is a series of services in the back-end actually being called, so it'll be very easy for us to create a virtual service using the service definition.
So, then what we'll do is take the actual service definition, and download it here. Then we can load this up inside Virtualize. So to this, we can simply choose our virtual asset, say right-click, Add New Virtual Asset. And then I'm going to name this the same name as the service which it is, which is Parabank account.
This time I'll choose my service definition and you'll notice that we have RAML, Swagger, WSDL, or XML schema. And in this case, we're going to be using a Swagger. And I'm simply going to point it here and say, Finish. Now, Virtualize, or read through this Swagger doc and create a nice virtual service for us with all the resources predefined and all the responders created automatically. Now the really neat part about this is that for these particular virtual services, the schema already exists and is already taken care of as well as immediately start providing value to ourselves.
So, let's start using this virtual service.
When the virtual service was created, it also created this deployment here on the right. And this deployment will have the same name as the endpoint of the regular service. So it'd be very straightforward for us to take that endpoint and to provide it right here into Parabank. So in the administration's pane, you have the ability to supply additional endpoints. And just like when we created the virtual service for the REST or for traffic, this one will now point directly to this test to the service that we made. So go ahead and click submit, and then we should be able to start using our application. So, if I go ahead and click on Accounts that now made a REST API call down to my virtual service. I can tell that it's calling my virtual service because I have the ability to monitor the endpoints.
So let's go ahead and monitor this and then what we'll do, we will then open up our event details perspective. Then I'm going to simply call that again. It is always recommended that before you start really working with the virtual service, you make sure that the recommendations and the connections are sound.
So here we see a request coming into my virtual service, and the very first call that gets from my demo application is the one to get a customer account. And you'll notice that this is calling the endpoint because we created a virtual service from the service definition. When we go back here in the Virtualize, what we will see that these service resources are all listed by name. And we automatically populate that, and it makes it really easy to find the exact service that you're looking for. So in this case, we are making a call to this customer service because this has the same name and it looks like, oh, wait, that's wrong. Not update customer account. And there's a response that can be generated for that. And this is where the real power of using a service definition comes in.
Because we have this schema, all we have to do is simply start including the optional elements. In this case, we can have an array of accounts, so we'll just insert an account, and then we can provide some information for that account and then maybe a customer ID. Let's say for my first case, I want to use $1,000 and all that is available. And let's say that account was created as part of the loan process. I'll save that. We'll redeploy the service and I can go back to my application and make the same call. And there we go. It's quite simple to create those virtual services from the definition.
But it's even more simple to start consuming those because you know that your virtual services are semantically correct and the endpoint information is all going to make sense.
So, it's a very nice starting point when you're going to create a virtual service to choose the service definition and that Virtualize works with all the proper pieces in place. And this is how we've created a virtual service using a service definition file within Virtualize.
Coming up next, Creating Dynamic Virtual Services.
Comments are closed.