In our last video, we showed how to extend virtual services by adding additional responders to handle scenarios inside of your application flows.
We also showed how you could extend a virtual service by chaining tools to that service to handle the dynamic nature of your API calls. In this video, we're going to focus on Extending the Virtual Services Data Source. This will allow us to create virtual services that are much more flexible and easier to maintain because the data is external. Also, will create a scenario for us where we don't necessarily have to handle every type of call that comes in.
We can be a little flexible. So, in order to show this, we have a little bit of setup. What I did between the last video and this video, was I went into the customer virtual service that we had created and I added some additional accounts. This is all very simple. All I have to do is go to the top level and indicate I want to make a new account. Then just go to the account and start populating the information.
What I'll do here is I'll go ahead and say that the ID coming back for this one is going to be 98765. We'll put a balance on this one of $2,000 and a $500 available balance. And this will also be a type of loan. And then inside our application, where we originally saw 2, now we see 3 accounts. And here's the third account that we just added. The interesting thing about this service is that the way we have configured this is that it is looking for incoming requests to come. And when it does, it will forward that account information to two services, the account detail service and the transaction service transaction we've made dynamic, and it will take the incoming ID, and swap that back around. And the same thing in the account with the account detail.
The interesting thing is on this page, because of the way that we have our service set up, all calls that come in will get the same details information. What we really want to do is we want to tie that detailed information into the first API call that we made. So that for each account we click on, we get different behavior.
We do this not only to make sure that our application is functionally sound and that there is data interoperability. We also want to make sure that all of the functional use cases, be they positive or negative, are covered within a single service. And that's really where data management comes in and it's important. I want to make a data source whereby each one of these accounts provides a different piece of information to the subsequent page. This is quite easily accomplished. All we have to do is go into our service that we know will be handling those requests. We don't really have to focus on transactions anymore.
In this virtual service, the way that the virtual service responds is by first taking a look at the incoming requests and decide whether it's a type of account. You'll also notice we have an asterisk repopulated here because it doesn't really matter which account numbers come in. We'll handle that piece of information later. But now what we want to do is we want to focus on the incoming ID because depending on which account we've clicked on, this ID will change. And we want different behavior based on those changes. That's an additional layer of correlation known as data source correlation.
There are many ways that we can look at this. I've actually pre-configured the virtual service to take a look at this incoming ID, which is path segment 4, and I've mounted it to a column in the data source. I've generated a column called Incoming ID. Well, what does all that mean? Well, I think to answer that question, we should look at the data source. So, here's my data source. And in my data source, what I've said is that when an incoming ID comes in, if it matches, then provide these values back to the virtual service. So for 12212, we have an account balance of $1,000 and a loan account. For account number 55555 it has $2,000 and it's a checking account. To see this in action. What we have to do is we have to validate that incoming ID column is the one that will be analyzed upon request in the virtual service. And that's exactly what we were looking at.
So now if we look at this, it should make a little bit more sense. And through that now, when we use our virtual service, we should be able to see a difference between this account, which provides $1,000, and this account which provides $2,000. But notice how it is still indicating $1,000. That is because we need to map the data source to our virtual service so that the virtual service knows to get its values from the external location as opposed to its internal location. That's the final piece of the puzzle. So in the previous video, we showed you how you could parameterize a value to external variables or to additional chain tools.
In this case, what we're going to do is we're going to put parameterized those values to our data source. This is actually quite easily done. We simply choose parameterized and then choose different values for the customer ID. We're going to link to customer ID balance. We're going to link to balance for available balance we're going to be linking to the available balance and for type, we'll link to type.
Now, when we use our virtual service, it should be able to make decisions 1000, 2000. Now, the final piece of the puzzle is what do we do with this account? Account 98675. Notice how 98675 doesn't actually exist in our data source. And as such, if we were to call this account, we would see that no data exists for it. Now what we could do is go into the data source and add 98675 and then we would get a response.
But that's not very scalable because I could potentially want to add thousands of scenarios where I'm validating different accounts. A different way to handle this is to use criteria expression. So in criteria expression, I could say something like any incoming ID or we could say any ID or any ID that's greater than 10,000, in which case would be spent around a customer ID. In this case, in which in this case I'm going to use 12345. And if the account is greater than 10,000, maybe we'll give them a balance of $10,000 with a $1,000 available balance. And we will make it type long. If the account clicked on is less than 10,000 then we'll give a different behavior and I'll just copy this to make it easier for myself and we'll say the account balance and that is $999. Doing a data source in this way allows us to create a data source that'll respond to all incoming requests. It makes it easier to maintain incoming request data without having to work so hard on the virtual service.
Well, we know that the incoming requests of this one will be 9999, which will be less than 10,000, and should allow us to hit this final row. Let's Save and we'll see this in action. So, we'll go back to our account. 98765 which is less than 10,000. Well, I guess actually that's greater than 10,000. So, what we would expect is 10,001. So, let's go ahead and click on that 10,001. And it really doesn't matter what that number came in because we dynamically swap that back around. Now, let's just change this a little bit and decrease the account ID to something less than 10,000.
How about account ID 9999? Now, the scenario is going to be different. We've come into our application. We see that the account number is changed to 9999 and as such we get the $999 account balance. So this is really the way that you want to create your virtual services, a mixture of dynamic information, fixed information, and data-driven information, as well as criteria, expression, and correlation so that your virtual service can not only think but make decisions and put the right data at the right time making for a much more flexible virtual service.
Thank you for watching. Next step, Configuring Basic Performance Characteristics.
Comments are closed.