Rich Martin • 00:07

So now let’s take a look at the second use case here. So I’m going to close out this data. And so the second use case is this one. And so in this use case, what we’re doing is we’re gonna add a little bit more to what we’re doing. This is about qualifying a network service. So imagine if you will, somebody requests a network service. What is a network service?

Rich Martin • 00:32

I’m being general here, but it could be connectivity between an application and a site or a VLAN or a user, or it could be an internet connection of some sort for a customer. Whatever that service is, if you think about what a network service is, it’s usually multiple resources that need configuration on multiple devices and data maybe from other sources. In some cases, what if we could make an application in our ServiceNow environment really smart? Here we go. if a user is requesting a network service that’s made up of all of these resources, what if instead of going ahead and attempting to configure everything only to find out within the provisioning process we don’t have enough resources somewhere later down the provisioning workflow, what if we could just query, run a query from a flow to say, hey, a user’s requested this, do you have the resources for it? And then get an immediate response back that says yes or no. Because then you don’t have to have the user filling out long forms only to find out after they could submit somewhere down the line there was enough resources for it, right?

Rich Martin • 01:42

So this opens up a lot of potential as a particular use case, but then this data could be used in all kinds of different ways as well. But this is one way you can start to think about it and wrap your mind around how to use this. Once we’ve opened up the ability to run network automations through the ITENTIAL platform, we can query for information, we can determine if services are available or not. And then I wanna get really specific with what this one does. Even if it’s not available, it can tell you which parts of a service were not available. So all of this can now be used in a flow to make these IT processes much smarter and much more efficient. So let’s take a closer look at this.

Rich Martin • 02:20

So we have our trigger condition, of course, is required. We’re still getting a token. We’re also running the same kind of endpoint API call here through this itential start, this itential action start endpoint. You’ll notice a couple of things here. The trigger name is different because we’re running a different automation, but more importantly, you’re seeing we’re passing a data payload, okay? This payload is a JSON object. It’s called form data, and it’s got one variable that we’re defining called interface name, loopback 100.

Rich Martin • 02:51

I want to do this. This may not always be relevant to your use case, but it’s important to illustrate the fact that data can come from a ServiceNow flow and passed into an automation on the Itential platform so that it can be leveraged in that automation. Because this is really about allowing both platforms to coexist and work together. And so sometimes you may need data to come from ServiceNow. In other cases, you may want the Itential automation that the network team has built to make it as simple as possible and do all of the complex work on the backend, including things like determining interfaces for particular services, things like that. But this is just to show you the ability to do that and really how to do it and what this opens up for you. We’re adding that piece in, passing data to the Itential Automation.

Rich Martin • 03:40

We’re also doing something a little different now. With this, do the following. Basically, we’re opening up a loop here. Instead of waiting 10 seconds, that’s not optimal. What we ought to be doing is waiting the prescribed amount of time it takes for an automation to finish. In this case, we don’t know how long it’s going to finish, so we should query for the status to determine whether it’s complete, and that’s exactly what this does. This is a part of the ServiceNow flow logic to be able to create a loop.

Rich Martin • 04:07

In this case, we are calling another Itential action here called GetStatus. GetStatus is exactly what it sounds like. We are querying the Itential platform through an API call in this action with a specific automation ID. That’s the job ID. That’s the job that we started in step 2. We’re asking the Itential Platform, tell us the status of that job. Continue to loop, it’s going to wait five seconds until the status that comes back from the Itential Platform for that particular job is complete. Once it’s complete, then we can query and get the results to another Itential Action like we did in the last one, and then we can take a look at those results as well.

Rich Martin • 04:47

Now, let me flip back over to the Itential Platform and let’s look at the workflow and walk through what’s going on. Here is the Use Case 2 service qualification workflow that’s going to be running in that flow. This particular workflow, like I said, I’m trying to keep things simple, so services can be very complicated. Sometimes they can be simple. But in this case, I’m going to break down this service into really two components or two resources. We need an IP address and I need a port. This could be, like I said, much more complex in a real-world use cases.

Rich Martin • 05:20

You might need VLANs, you might need VXLANs, you need mapping, you need IP addresses, you might need ACLs, firewall, all kind of changes, things like that. The point here is that all of those things can be done within an itential workflow because we can orchestrate that across multiple domains and talk to all of your devices, controllers, and systems. For here, just as an example, we’re going to use NetBox to provide our IP address. In this first step, we’re going to query NetBox and ask it for an IP address that’s relevant for this service. This next step here is a query, so I’ll double-click this and we’ll take a look at the data in the query. Similar to the first use case that I talked about, I want to extract just the most relevant information, and so I want to query that data out. But in this case, I am going to also present it again as a unique variable when it’s passed back to the ServiceNow Flow.

Rich Martin • 06:11

So when we respond to the ServiceNow Flow through that result action, it’s going to have that. So I’m simply querying out the address, the first address that gets returned because this particular NetBox API call will give us a list of addresses. I really just want to see the first one to know that there is an address available. That data source is coming from the previous task here. And the key here is on the output, I am creating a new job variable called IP address. That’s going to hold the IP address that we queried out from here. So that’s going to be available kind of globally to pass back into the ServiceNow Flow so that it can make use of that data.

Rich Martin • 06:48

On the second piece, I’m going to run a command template. A command template is a really useful asset in our Automation Studio application that allows a network engineer to query a device in real time using standard CLI configuration for showing interfaces or showing route tables. So if you’re on a Cisco device, you would use the Cisco CLI nomenclature to query for operational data, and then to parse out that data with a set of rules to determine if something passes or fails certain criteria. So in this case, I’m going to request that I’m going to run a CLI command in this command template on a Cisco iOS device that’s going to determine if a port is in use or not. And. I’m passing this variable called formData. Remember when I showed you the ServiceNow flow, we were passing data into this automation through that API call, and formData included a field called interfaceName.

Rich Martin • 07:50

Well, I’m going to reference that here because that variable is going to be used to check for that particular interfaceName. I’m doing that for particular reasons to show that you can pass the data through, but also you can see the results from whether a interface is in use or is not in use, whether or not the service is validated or not validated. I’m actually leveraging that formData here. On this next step, similar to the last query, I’m just extracting just the data that I want from that JSON. In this case, it’s the result, and this is a Boolean value or yes or no or true or false value. I’m storing that again as more of a global job variable to pass back to the Snow flow called portAvailable. This should be either a yes or a no.

Rich Martin • 08:37

And then the last piece is this evaluation. So this service is comprised of two resources. We’re going to either determine whether those resources exist or don’t exist, if they’re viable or not, if they’re available or not. But I also want a variable that’s very specific. It’s a single variable that’s a yes or no. We can qualify this or we can’t. We can validate this as available or we can’t. So that the ServiceNow developer can use that as the single variable to look at, but then have access to these other resources to see which variables, if the answer is no, we can’t qualify it, they would at least get an idea of what was not available. Maybe IP addresses are available, but the port’s not available. And that’s exactly what we’ll look at here. So this evaluation takes a look at the two variables that we’ve created with these queries, determines that they have, if the first variable has a valid IP address, it’s not null and has a IP address, then it passes that check. But it also needs to pass this check, that the variable from the port availability is also set to true, meaning that port is available. If those two conditions are met, Then later on it takes this path where we create a new variable. This variable is called service underscore qualified. This is going to be presented back to the service now flow. And it’s going to be set, it’s a Boolean, and it’s going to be set to true.

Rich Martin • 09:58

However, if the evaluation fails, because one of these two resources is not available, I’m still setting the same variable name, service qualified, but I’m setting that variable to false now to identify that the service was not qualified. So this gives you your ability to now operate and define these interfaces to pass data back and forth, very, very simple and easily through both platforms so that the information is available, it’s immediate, and it’s useful to both sides. So with that, let’s go back to the service now platform. Let’s go back to this flow. And now we can take a look at testing it. And again, I have to pick a test record here. But if I run the test, now recall, this is we’ll take a look at what loopback is set.

Rich Martin • 10:49

We’re passing the interface to verify if it’s available or not to the automation on the Itential platform. It says it’s finished running. But of course, it’s not quite finished running because it’s got to wait for the status to go complete. So this is that loop that’s going on. But until we get to that point, I’ll reload in a minute. We sent loopback 100 back to the automation so that it could be used as the loopback to verify or the port to verify in the automation as part of one of the resources we need. Now, I can tell you that that loopback 100 is actually in use on that particular router we’re querying.

Rich Martin • 11:29

And so because of that, the status for is that port available should come back as failed. And therefore, the overall services qualified variable should also come back as failed. So hit reload here. This should now show us that everything’s completed. Once everything’s completed in our loop, so that loop. looped around until the entire job was completed in the automation platform. Once I click Get Results, we should see the automation results what we’re looking for.

Rich Martin • 11:58

So this is the data that was passed back to us from the itential platform in regards to the automation. So this is what we built into that automation to return back. Service qualified, so that was the main variable is false. Of course, this is the form data we pass to it. This is the job ID, but the other pieces that we embedded into the automation that we published to be used here is IP address. So in this case, you see we have a valid IP address. So that resource was available, but here when it did the check for the port availability, that’s where this came back false and this is why the service is not qualified.

Rich Martin • 12:36

So what we can do now is let’s rerun it again. And now let’s change the interface from the service now. payload that we’re passing to 200. So 200 does not exist. So this should come back as a pass because now we’re asking, is port loopback 200, does it exist because we want to use it for the service? If it should come back as no, it’s just not in use, and therefore, at least that resource should pass, that resource check should pass, and if the IP address request passes, then our main variable for service qualified should be true. So again, it’s going to take a couple of seconds here.

Rich Martin • 13:28

We can investigate this. Yes, we did pass the loop back 200 in our form data. And this is statically assigned, but as a developer or designer, you can dynamic just as easily as we dragged and dropped other elements into fields in the flow or in an action. That data could be dynamic as well. We’re just simply doing this statically for an example. So if I reload this, now it should show as completed. Once the job’s completed and we can look at the automation results.

Rich Martin • 13:58

And we take a look at our automation results here. This is the payload that was returned back from the Itential platform. You’ll see that the service qualified says this is the overall variable that we could check to see if this is valid, if this is qualified is now true. Again, we have an IP address that’s available to us. Since we didn’t activate the IP address, it’s still available on the pool. That’s the IP, that same IP is available to us. But now this is what’s changed because we changed the port request that we’re looking for.

Rich Martin • 14:27

This came back as true because that report was not currently in use. That came back as true, and because both of these existed and met the qualifications, the overall qualification is now true. Now you can have a very intelligent ServiceNow application that can validate that a service could be available before actually requesting the service or even asking a user to fill out a form with more specific details on what they want. Yeah, that service is available. Okay, now let’s reveal the rest of the form so that they can fill it out. And even working with the team, you know, these resources could be held or could be activated anytime you wanted in any one of these interactions with an automation on the ServiceNow platform and the automation in the iTenture platform. So this is how you can collaborate both teams together and pass this data back and forth.

Rich Martin • 15:16

to make these processes much more efficient.