Welcome back.
In our last video, we showed you how to create a virtual service from a service definition. In this video, we'll show you how to take that to the next level by taking advantage of the Advanced Workflow Tools Available on Virtualize.
We will demonstrate this by covering these topics, Configuring additional virtual services, Creating dynamic responses from request data, and Creating dynamic responses from generated data. Previously, what we did was we created a virtual service that supplied us with some of the account information that came back to our demo application. Now, what I want to do is continue to work through the application and create some additional services and then extend them. So here in my demo application, when I click on the Accounts Overview, it does give me the response from the virtual service.
However, when I click on those available accounts, what I get in the back-end is a failure, because those APIs have not been simulated yet. So, what we can do is we can go into the accounts' details perspective, because I was monitoring that virtual service and see exactly what calls are being made. So as you can see, all the call information goes from top to bottom.
We'll go ahead and look at the first call that comes in, which was to the customer's API, which did have the response that we created initially. The next call that was made was to the service that was looking for accounts. So accounts 12122 to which we hadn't provided a response, but that's easy since we created the virtual service with the service definition, we can find the exact call that was being made and just like before, add the information into it.
So, let's go ahead and provide this information. And what you'll see this scenario works like a common application where one service calls other services to get that additional information. It's a very powerful use case for service virtualization because you can get these different services to talk to each other and to create a scenario that you control.
Okay, to save some time. I do know the third thing that is going to happen and it's going to go and, call the Transactions API. So, I'm going to go ahead and add that in ahead of time here. Each service can have multiple transaction pieces to it, so we'll just input something simple. And now what I'll see is that there are these three building blocks working for me.
And I can again go through my application and see that indeed when I do click on this, I get that account information. I see that the money was deposited into the account and now I have a nice scenario available in my virtual service.
Well, let's continue to extend this because there is some information that I can use to make the service a little bit more intelligent. So, the first thing that you probably noticed was when I went through my different responses, I kept having to put in this ID, and this ID is really going to be dependent upon the ID of the account that was being requested, which means it could potentially be dynamic. So, one of the things that I can do is I can handle the dynamic nature by taking advantage of additional tools. Let me just show you what this means.
So, here I am in my accounts responder. And on every responder, you have the ability to add an output. What is an output? And output lets you work with the incoming request or outgoing response and add tools there.
So as you can see, there are many tools that are available from our toolbox. What I'm going to be using is one of the tools that I consider to be an MVP. And that tool exists on the transport header. It is called the URL databank. Tools basically transform incoming request information, outgoing response information, and captures pieces of information, and allow us to manipulate the requests and responses of virtual services prior to sending out the actual response. Now, any tool that's a databank allows us to extract pieces from the incoming request. For example, in this case, I'm going to extract a path now. The exact path segment that I need depends on what the nature of the URL looks like.
But what I want is I want the account ID whatever it ends up being. And what I'm going to do is I'm going to store that account ID into a variable called ID. I can then use the account ID for any of my responses. And it's quite simple. You can just go into the response. And here, instead of providing the flat value of account 12122 what I'll do is I'll parameterize that value. Parameterizing means grab the value from an external location that is, in this case, the database. Now, just to show you how this works, what I'm going to do is I'm going to go back into my customer's virtual service, and I'm going to say that the account flips back around.
What I'm going to do is I'm just going to change it. It's a number, let's call it 55555. And now when I do my scenario, what I'll see is that the new account 55555, when I click this button, it will flip back around to my virtual service, thus ensuring stability with my functional testing because I know that the values that I have in my virtual service are dynamically generated at runtime. I'm going to do the same thing and flip it back, flip that value back around into my deposit virtual service using the same technique.
I'm going to right-click Add an Output incoming Request Header. Choose that tool, choose a path, and you'll notice we can extract on anything. We also have the ability to extract on the incoming body. So, then we'll say the same thing here. I just used a slightly different variable this time. And in that when that response goes back out, I can then parameterize that to the incoming account ID. Now I have a very dynamic virtual service.
I want to do one additional thing, and that is I want to make sure my virtual service has some additional information generated on the fly. Now, when I do click on my account, one of the things that comes up is the date available here and my transaction history. And the problem is that I've generated this from the data that I put into the virtual service. And let's say that my requirement says that the date must be today's date. It would be important for me to be able to have a virtual service that will always be able to provide the correct date. And this is very simple. We can use this again to chain a tool to provide dynamic date into the virtual service.
So let's go ahead and look at that tool. It's called the Data Generator Tool. And it does exactly what it sounds like. It generates data simple data. In this case, I want to go ahead and generate a date. And what I can do is I can go ahead and let's say use this date, but let's do a little bit of offsetting to it. Let's say we'll go back two days just to show that there's a particular date that we can put in here. We can slightly shift it and make a dynamic. And then what we'll do is we'll go ahead and name this column and generate the date. Just like the databank. I can swap out the value into my date format here. Now, let's go ahead and save this, and then we'll use it. All right. Let's go ahead and start a new log. And then we'll go into the application here. And we'll go and say click on account. And this value is dynamic. We also have the current time being dynamic.
A good virtual service should be a combination of fixed data, data that was generated from traffic, data that was generated on the fly, and dynamic data that was collected to run at runtime being able to extend your virtual service in this way will allow you to create virtual services that will be long-term.
They will live for a while, and they will be easier to maintain.
Thank you for watching.
Up next, Advanced Data Source Correlation and Parameterization.
Comments are closed.