Rich Martin • 00:00

Hello, everyone, and welcome to another Itential webinar. My name is Rich Martin, the Director of Technical Marketing here at Itential and you’ve tuned in today to learn how to enable network automation and a ServiceNow flow using Itential Actions. That was a mouthful. But let’s continue on and learn what exactly this means. So by way of context, I think it’s good to understand how we integrate with different platforms and specifically with ServiceNow. So with the ServiceNow platform, if you’re familiar with Itential, then you’re probably already familiar with our ability to integrate with the ServiceNow platform using Itential adapters, which we publish as part of a pre-built collection, or using an open API or some sort of API documentation file so that you can generate your own integrations into the platform. But in either case, those integrations or adapters are installed inside the Itential platform.

Rich Martin • 01:01

to enable the platform and really the workflows that you build within the platform to consume ServiceNow services that are available through an API. So we’re just leveraging the ServiceNow APIs. And so then what that opens up is the capability for an intentional workflow that you’re building in the platform to operate like a ServiceNow user in order to do common tasks like opening tickets, updating tickets, running queries, and really anything that the ServiceNow API exposes and allows, we can now leverage inside the intentional platform in a workflow. So what we’re talking about today is enabling ServiceNow flows to run an intentional automation, and that’s on the right-hand side. So we’ve already released previously an intentional app for the ServiceNow platform. That’s been available in the store, but with the most recent release, we have now enabled a couple of more features, but the general idea is exactly the same as it has been. We want to enable users and now developers and flow designers in the ServiceNow platform using a certified app that’s available in the ServiceNow app store.

Rich Martin • 02:13

Make it super simple once you install that app into the ServiceNow platform to be able to do some basic configuration to authenticate with an intentional platform in your environment, and to leverage these APIs that are now exposed so that ServiceNow users, and now the flows that run under the ServiceNow platform can directly run intentional automations, enabling and kind of enriching the ability to do network and network infrastructure type queries, requests, and even receive results from the network so that you can open up an entire slew of use cases. Really, when you’re in the ServiceNow platform, it’s all about automating IT processes. Things like querying for network operation data, real-time queries for network operation data, so you can open up things like building dashboards for reporting. Being able to now go to a network portal in ITensil, run an automation to provision or deploy new network services so you can do connectivity between applications or sites, things like that, all in a self-service way. Or even things like updating or migrating network services, so if a service exists, making changes to those services. That’s really what’s at play here when we’re talking about the ITentual app for the ServiceNow platform.

Rich Martin • 03:35

It’s really allowing with this new update, enabling at the flow level, and we’ll talk about what flows and actions are, but at the flow level, the ability to leverage any Itential automation and allowing a ServiceNow developer or designer to operate in the ServiceNow environment using native assets that they’re used to and allowing the Itential network automation team to leverage that platform to build their automations and giving them a common and easy way to operate and collaborate together so that both sides can utilize the APIs that are available in order to make the IT and process much more efficient than it’s ever been before. So that’s why we’re super excited about this. So let’s get a little bit under the hood and get technical as we kind of get into our demo here in a few slides. So what are these Itential actions? So an action in the ServiceNow platform is something that we’re publishing as part of the new update to the ServiceNow app. So you install the app. Not only do you get all the previous features like the ability to quickly configure it and connect to and authorize to your Itential automation platforms in your environment.

Rich Martin • 04:51

You also get a self-service dashboard that users can use to visually run automations that have been published in our platform, in the itential platform. But now you also get the ability we install a set of Itential Actions from the Flow Designer application. In ServiceNow, there’s an application called Flow Designer where they build flows. Flows are a series of actions that are run one after another. The Itential Actions that are now available when you install the Itential app for ServiceNow, enable you to interact directly with these configured Itential platforms so that you can, well, primarily run automations, but also some job control like getting status of an automation to determine if it’s running, get the results of an automation once it’s already run, even listing the automations that are available to you. Allowing you as the now designer or developer at the layer that you’re working at natively and naturally, to be able to leverage network resources, infrastructure resources directly from a flow using these actions.

Rich Martin • 05:57

Again, this enables an entire new set of abilities, capabilities that are all really focused on making your IT automation more and more efficient. Along with the Itential Actions that are part of the ServiceNow app that you can install, we’ve also thought it was important to provide you a set of example flows so that you can see how these actions operate, how to configure them, how they can be utilized. Along with this, you can also find a set of example Itential Flows. These flows leverage the Itential Actions to do things like authenticate, query or run automations, get the status. We’re going to cover a lot of these here, but these are also available to you as reference once you’re in the flow designer and the ServiceNow platform so that you can leverage them and reference them as needed. With that, let’s talk a little bit about the demo that we’re about to get into. On the left-hand side, the most important thing that we want to show is how easy it is and what this opens up.

Rich Martin • 07:08

Actions are something that every ServiceNow developer or anybody who’s designing a flow in the Flow Designer, they’re already used to seeing an entire group of actions available to them. What’s publishing actions is great, but really what the most important focus of this is, is what this enables you to do in some of the use cases around this that open up now by exposing the automations down at the action and flow level. These use cases that we’re going to talk about, hopefully, will spark some creative thought around, wow, we can now start doing these things where we couldn’t do those things before. I will show you how to publish an automation for use by ServiceNow users and flows. There’s really nothing that’s changed here, but the context, it’s really good, so you can see how this fits together. We’re going to take a look at how to build a ServiceNow with Itential Actions. Most of the flows will already be built because if you’re already in Flow Designer on a day-to-day basis as a ServiceNow developer, you already know how to do that.

Rich Martin • 08:06

But I’ll show some flows in use and we’ll add an Itential Flow and configure it, and we’ll step through all the flows that have been configured already. Then we’ll talk about three use cases. Those three use cases are, how can we leverage a flow that can query the network, or in this case, Itential, for certain network operational data, right? And this could be a lot of things. It could be the status of routes on your transit routers, or it could be certain resources on the network. In this case, it could be inventory.

Rich Martin • 08:37

And so I’ll show you one that queries ITENTIAL and to ask for a federated list of inventory devices that it has onboarded. The point about this is, there could be some very interesting things. If you had access to operational data from a ServiceNow flow, there could be some really interesting things that you can use that data for as part of a dashboard, reporting, or even as dynamic data as part of another, like a larger IT process. So this opens up the potential to do that. So we’ll show you how to do that in a flow. Another use case is to qualify a new network service. So instead of asking to provision a service, there are cases where maybe there’s not enough resources available to provision that service.

Rich Martin • 09:18

So instead of asking for the entire service, querying to see if the service, if it’s possible or to qualify or to validate that a service could be allocated based off of resources that are available today. So we’ll show you a flow that can request that kind of qualification for a service by running an Itential automation that will validate different resources and determine if it’s possible, and then send that response back, that data back to the ServiceNow flow so that it can be used by the designer or developer later. in that flow as they build it out. And then finally, probably one of the most important use cases and probably top of mind is more of the self-service network portal. How can we, from a flow, ask for a particular network service, connectivity between sites, connectivity for an app, connectivity for a customer? How can we request that and receive that? And especially when it crosses multiple domains is in the more complex use cases where a service may cross multiple network domains like cloud, a data center, and SD-WAN.

Rich Martin • 10:27

And of course, if you’re familiar with Itential, that is precisely what we do, automation in every network domain, and then being able to tie all those automations together and orchestrate not only across multiple network domains, but bringing in the systems that are relevant and necessary in order to accomplish that orchestrated request. With that, let me share my screen and we’ll go right to the demo. We’re going to start right here in ServiceNow Flow Designer. If you’re familiar with the Itential platform and you’ve built automations in our platform, you’re probably familiar with Automation Studio. We’re going to take a look at that in a minute when we look at some workflows but by context, if you’re a designer or developer in the ServiceNow platform, and you’re building their version of workflows, which are just called flows, you’re going to be spending a lot of time in Flow Designer. So it’s similar in concept to Automation Studio in the Itential platform. What we’re looking at is a very small flow here, just as for a demonstration to walk you through the actions and what a flow looks like.

Rich Martin • 11:33

At the very top, we have a trigger. A trigger is required and it determines when this particular flow is going to actually get executed in the ServiceNow platform. We won’t go into all the details, but you can basically trigger a flow to occur when a new request is created and based off of the request, certain fields of the request if they’re set, so in this case, the short description as I potential test and then other things like state, in this case, approval is approved, so that you can be very direct and specific on when a flow should run. In this case, since we’re just testing these, we need a trigger, so we have created a trigger. When we do our testing, we’re really not going to use this particular trigger to run the automation or run this flow. We’ll bypass that in testing mode, but it’s important to understand that and know how these things interact together. But what’s really critical here are the actions that comprise this flow.

Rich Martin • 12:32

You’ll see we have three actions right now. The first two are itential actions. This is what you get when you install the ServiceNow app. You get a series of itential actions that can be used. Now, I’ve already built out the first two, but we’ll add another action here in a moment. The first step here, this first itential action is authentication. In order to authenticate to a server, we need to get a token.

Rich Martin • 12:57

The authentication method here we’re using is name and password. This is defined in another part of the application. When you install the itential app for service now, there is a admin portal that allows you to define the itential platforms you’d like to connect to, as well as the authentication method. That’s already pre-configured for this, that’s already defined somewhere else. I’m just selecting which service I want and the authentication method I want to use here. This is going to return a token when this is run. Of course, that token is now going to be used for any subsequential actions into the platform that we use.

Rich Martin • 13:30

More specifically here for this next step, step 2. Action 2 is another ITential action, which is automation start endpoint. What this is, is it allows us to run an automation that’s been published on the ITential platform. A couple of things to look at here. Again, I’m choosing the IAP that I want to run this on. Of course, that’s very important. Make a note of this. This is the trigger name.

Rich Martin • 13:57

This is what’s defined as the API endpoint when I publish this in the ITential platform. This has to match and I’ll show you where that exists in the ITential platform. Here is the token. We need the token that we used from step 1. You’ll see it’s numbered step 1 here. That’s simply dragged in and dropped into the token field, makes it really easy. Now we have all of the elements we need to start an automation to run the automation from this flow. Our next step is part of the flow logic that’s built into service now.

Rich Martin • 14:27

This is just a wait for 10 seconds. This is certainly not the optimal way to do things, and I’ll show you the more optimal way in the next flow. But just for simplicity sake, we’re going to wait 10 seconds for this automation to complete. Then once it’s complete, we want to be able to get the results of the automation itself. But before we get to that and add that step here after the wait, let’s flip over to the ITential platform into Automation Studio and take a look at the automation that we’ll be running. Here’s Automation Studio. Again, Flow Designer is like the Automation Studio of the ServiceNow world, in the ITenture world, Automation Studio is where we build workflows.

Rich Martin • 15:07

Step-by-step boxes here, we call these tasks. In this case, I’ve made it very simple. Remember, the concept here is I want to flow to be able to get some real-time network data because I want to use that later on in the ServiceNow flow as part of an overall IT process that I’m automating. This particular workflow right here is basically just going to return a set of inventory that we understand, and we’ve learned about in the iTensile platforms. The iTensile platform has the ability to federate inventory from another number of sources. If you’re familiar with our platform, those sources can be physical inventory, individual routers that can be onboarded through part of our solution called Automation Gateway. We can get inventory like SD-WAN devices from a controller, we can query a controller and grab inventory and then federate that into our environment.

Rich Martin • 16:00

Or it can even be cloud-based assets like VPCs and VNets can be federated into the Itential platform. And what’s useful here is the ability to now ask the Itential platform for a set of inventory that could be useful for, like I said, something in a flow to show to a user or a customer that’s using, that’s filling out a form in the ServiceNow environment. So being able to pull this network data in real time and then give it back to ServiceNow so that it can be used in those instances, that’s what we’re looking at here. And of course, we are one source, we federate a source of inventory, but if you’ve got other inventory, if you’re doing something like a single source of truth, or even want to query multiple sources of truth of inventory, or even if ServiceNow is your inventory, because that’s where you’ve decided to put it, you can query all of those sources. from an Itential workflow using integrations and adapters. We don’t limit you to only certain things, we want to expose as much of your environment into our platform for automation where it makes sense. That’s what’s going on here, we’re just simply using a built-in call.

Rich Martin • 17:04

This get devices filtered, calls the Configuration Manager app, which is part of our platform, to get a list of devices and I’m limiting it to 10 devices just for the sake of simplicity. The next step here is this query. What this query does is the previous task is going to give us a list of the devices that are federated, at least the first 10 that are federated in the environment, but there’s a lot of extraneous data that comes with it. This query is just going to extract the list itself. Because I want to simplify the data that we return back to the ServiceNow flow as much as possible so they don’t have to query out a bunch of things. I’m going to query just for this list, and that’s what’s going on here. I’m saying the previous task, all of the variables that it returns to me under devices, just give me under that JSON, just give me that list variable.

Rich Martin • 17:58

Then the most interesting thing here is I’m going to create a new variable and this variable is going to be called deviceList. I want to present this variable as a job variable so that it can stand alone as a deviceList by its name and a JSON, or the key in the JSON, so that when the ServiceNow data’s flow, gets the return data from us in the ServiceNow flow, and we’ll take a look at that in a minute. It’s very clear what this is. I’m defining a unique variable that just holds the list of the devices that we just queried for as part of the inventory. That’s why I’m creating this new variable here. Okay, so once you’ve created an automation or a workflow within the Itential platform, in order to publish it, it’s a very simple process. If I go into operations manager, this is where we can do job control or we can publish automations.

Rich Martin • 18:52

I’ll show you how I’ve published this. So if I search for ServiceNow, this is the particular webinar. All we have to do is from a dropdown, identify the workflow. So this is the workflow we just looked at. And then under triggers, I can define a different types of triggers. In this case, I’ve defined an API trigger and I’ve called it API and I’ve given it an endpoint name. So snow app UC1, that’s the endpoint name.

Rich Martin • 19:18

And this is when we go back to the ServiceNow flow. and we take a look at the automation start endpoint. You can see the trigger names, snow app UC1, that’s where it comes from. This is how we will execute that automation from the flow. We’re missing one piece though. Just because I run the application, I don’t get the results of the data that I want from the automation. The last step that we’ll add in here to show how to add an action in is to get the results from that particular automation.

Rich Martin • 19:57

We’ll add an action if we do a search for Itential. It will bring up the Itential automation services. So when you install the app, you’ll get all this. You’ll notice that there are authentication actions. We support different types. We can get tokens through Usernames, Passwords, or use API keys through OAuth. We also see a series of actions for job control, like canceling or getting metrics.

Rich Martin • 20:27

We also support direct and mid-servers as well. So you’ll see different actions for mid-servers or direct if we want direct, in this case, in our test environment where we’ve got direct connectivity. But you also see the ability to get results, and that’s what we’re looking at here, as well as starting an automation, getting the status automation, which we’ll use here shortly, and also getting a list of the applications that have been published. So all of these are available to you for use. In this case, we want to get the results of an automation that’s run. So that’s the action we’ve chosen. The automation ID is going to come from the response from step 2, when we start the automation, that’s a unique ID.

Rich Martin • 21:07

So if we look over here on step 2, we get this job ID. If I drag that straight in, that will give us the data we need. Then I’m going to select the Itential platform that we’re running the automation on. The last part is the token that comes from step 1, the Itential action for authentication. I can drag that there, and now that data is populated, and then click ”Done” here. Now, we’ve got authenticate, run the automation, wait 10 seconds for the automation to finish, and then we’ll get the results. So we can save it.

Rich Martin • 21:45

Then from Flow Designer, I can test. And this is what I was talking about. We can bypass the trigger for this. I need to have a record selected. That’s part of the table that I’ve picked for the trigger. But in this case, we’re not actually waiting for those trigger conditions to run. We can run them directly.

Rich Martin • 22:02

And now it’s going to run this test flow and give us the results in a minute. And so once that’s done, we’ll take a look at the details. So it says it’s finished running. It hasn’t completely finished running yet because it’s waiting on this timer, but you can see step one is completed. Step two is completed. So we got our token. So we can see the details here.

Rich Martin • 22:21

We got our authentication token. Then we ran the action to start the automation based off of the endpoint. And so we can see here from the response, the information that was returned from the IAP as it was running it. So this is not the result, right? This is just the status of as it was running it along with all the details for that. So if I hit refresh here. This should tell us that now our wait is complete and the results is what we’re looking for here.

Rich Martin • 22:55

If I click on Get Results, we’ve referenced, so we made another API call through this action into the platform. We’ve given it the automation ID, so this was the ID that was started here when we ran this job. We got the action status, which was at least the API call was successful. But now if I click on the results, this is the data that was passed back in that very specific device list. Remember, I defined a variable called deviceList, and I passed back, and I know this isn’t formatted in JSON, so maybe eventually ServiceNow will have a field here where we can look at it in JSON format. But you’ll see that this is a JSON object with the very first key here is deviceList, that’s the variable we created that we passed back in. You can see by this open bracket that this is an array and there’s 10 devices in here as well.

Rich Martin • 23:43

This is how we can return operational data back from the network through an Itential automation, requested and run from a ServiceNow flow using these Itential actions. Now, let’s take a look at the second use case here. 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.

Rich Martin • 24:20

What is a network service? 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? 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.

Rich Martin • 25:23

Because then you don’t have to have the user filling out long forms only to find out after they click submit, somewhere down the line there wasn’t enough resources for it. 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. Then I want to 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. All of this can now be used in a flow to make these IT processes much smarter and much more efficient.

Rich Martin • 26:08

Let’s take a closer look at this. We have our trigger condition, of course, is required. We’re still getting a token. We’re also running the same endpoint API call here through 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.

Rich Martin • 26:32

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. 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 service now 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.

Rich Martin • 27:20

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. 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.

Rich Martin • 27:45

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. 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.

Rich Martin • 28:20

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 through another Itential Action like we did in the last one, and then we can take a look at those results as well. 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.

Rich Martin • 29:02

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. 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.

Rich Martin • 29:45

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. 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.

Rich Martin • 30:26

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. 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.

Rich Martin • 31:27

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. 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.

Rich Martin • 32:15

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. 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 valid 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.

Rich Martin • 33:42

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. 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.

Rich Martin • 34:25

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. 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.

Rich Martin • 34:55

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. 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.

Rich Martin • 35:34

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. 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.

Rich Martin • 36:05

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. 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.

Rich Martin • 36:48

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? It should come back as no, it is not in use, and therefore, at least 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. 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.

Rich Martin • 37:36

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. 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 qualifies as 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.

Rich Martin • 38:05

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. 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.

Rich Martin • 38:42

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 it could be activated anytime you want it in any one of these interactions with an automation on the ServiceNow platform and the automation in the Itential platform. So this is how you can collaborate both teams together and pass this data back and forth to make these processes much more efficient. Okay, so let’s take a look at our last use case. And again, this is probably the most most thought about use case probably has the most top of mind. Being able to provision network services, and this is more of a complex network service.

Rich Martin • 39:25

This is multi-domain with different systems, both Netbox, Infoblox, all of these sources of truth and reporting systems, and this is the bread and butter of where a lot of IT organizations and service providers are really getting at. How can we use a flow to request resources from the network even very complex resources in real-time, make those requests and ideally receive them as soon as possible. But even if I can’t receive that, what is the status of it? Being able to get those results. Hopefully, from the first use case, the second use case, we’ve built upon that. We’ve shown that you have that ability to do that. The third use case is just provisioning these things end-to-end.

Rich Martin • 40:09

Again, we’re doing authentication step. There’s really no change here in the overall logic of the flow and what we’re doing. The only thing different here is we’re running a different endpoint. This is called App Connectivity Service. This is something that we use in a lot of our demonstrations, and the nice thing about this is we use this for self-service portals inside of the ITential platform, so that network teams could run this automation from inside their platform. This is also available in the ServiceNow self-service catalog dashboard that is part of the ITential app for ServiceNow that you get when you install it. Immediately, this becomes something that could be run when it’s published, and now we’re exposing this in a flow as well.

Rich Martin • 40:54

The same automation built in the ITential platform could be leveraged in multiple ways through multiple different platforms, programs, and applications. That’s really important to think about the flexibility and the reusability to publish an automation, especially a complex automation that can do multi-domain orchestration, and being able to use it in different ways in different platforms with really no changes necessary other than maybe defining a new API endpoint to give to it. In this case, we’re also passing some data back. We showed how to do that and the hows and whys to do that. In this case, it’s really more about running it and then taking a look at it as it runs. In this case, we can just hit test like we’ve been doing. I’ll give it a dummy record to use.

Rich Martin • 41:45

Now that this is starting to run, it’s going to get kicked off. We can actually go into Operations Manager on our platform, the Itential platform, and this is where it’s just kicked off. You can see it’s running. It started from an API trigger, so we can take a look at what’s going on here. From here, this is the job running on our side of it, in our Operations Manager. We can take a look at all the variables that are going on. But the idea here is that you can build as complex an automation as you want.

Rich Martin • 42:18

In this case, we would call this an orchestrated workflow. because not only are we integrating with the ServiceNow app, it’s passing data to us, but we are doing things like querying Netbox for a list of interfaces or the next available interface. We’re integrating a source of truth into this workflow. We’re getting an IP address from Infoblox. Another whole other system that’s authoritative for IP addresses for this particular service. We’re doing some transformations here. Transformations are important because it allows you to manipulate data between the payload from an API, the result of an API call, so that it can be used in subsequent API calls.

Rich Martin • 42:57

One of the big use cases is building CLI configurations or data to pass to another script. This is part of what we do in the Itential platform, is we can leverage any existing automations that you’re using in particular domains. In this case, maybe in the campus or the data center, you’re leveraging Python scripts and this one creates an interface. We can onboard that and leverage those automations and use those as part of an orchestrated workflow. We can automate changes in your campus or your data center if they’re using Python scripts. Here in the data center, they’re using Ansible, so we’re leveraging a playbook. In this case, that team has selected the tool of choice is Ansible.

Rich Martin • 43:37

In order to update an ACL, we’re going to leverage their playbook to do that as part of the service. We’re hitting multiple domains here, multiple systems. In this case, the service may also interact with SD-WAN. We need to activate a policy to allow some user on the other end of a remote SD-WAN site to access this new service. It could be an application. In this case, we’re talking to a controller or the telecontroller directly, and doing the API calls in order to activate a particular security policy on a SD-WAN device. Then eventually, the last piece of this is integrating with all of the different notification systems or like Slack, and in this case, MS Teams, so not just you, but your teams or different teams can be aware and have oversight in automations as they run.

Rich Martin • 44:30

So this is kicked off from the service now side of things, but you can see it’s provisioning all of this and contacting the systems. And then when it’s finished, you can see here, this is a new notification in our MS Teams chat here for this channel. And this gives us insight into the fact that something was completed, an application connectivity service update was made and it was completed. It successfully activated all of these different domains. And of course this was requested from a service now flow. using Itential Actions. Hopefully, that helps to illustrate the power and potential that you have available to you with the new ServiceNow app update as we expose Itential Automations that are built by network teams, published, and then made available, not only from a user level in ServiceNow, but now from a developer level and a flow designer level, so that they can increase the efficiency of the automated IT processes they’re working on or applications they’re working on ServiceNow, leveraging infrastructure, both for querying for operational data, validating services, or even provisioning new services or updating existing services.

Rich Martin • 45:47

So with that, thank you very much, and we look forward to our next webinar with you. Bye-bye.