Rich Martin • 00:02

Hello, everyone. My name is Rich Martin, Director of Technical Marketing at Itential. Welcome to another Itential webinar, and today’s topic is how to extend the reach of your network automations through orchestrated workflows. Now I know that’s a mouthful, so let’s kind of break down what we’ll be doing today and really the context of why you’d want to know on how to do this on our platform. Let’s start off with the fact that I really want to focus on having a hopefully a conversation or at least communication with the network DevOps team or the network DevOps engineer, the network automation engineer on the team. or the network engineer who’s brave enough and bold enough to walk forward into starting to learn and understand how to use automation tooling, maybe a programming language in order to start to build, or maybe they’re already building network automations. Because what this is focused on is this team, as well as other people on the team, but this team, how they can take all of that work they’ve been doing, building network automations through whatever tooling they’re using.

Rich Martin • 01:07

It could be, in this case, we’ll show Python programs and Python scripts, it could be Ansible, could be OpenTofu, or a number of tools. You’ve invested in that, you might actually have an entire library full of scripts, and what you’re doing is you’re automating network changes, and they’re saving you lots of time. Well, what we found as we’re talking to prospects or customers is that what they want to do once they hit a certain point is try to layer in other parts of the process before and after a network automation tool is run. That’s what we want to get into. We want to talk about automation, automating these automated scripts and tools, automating changes in network domains, but then you really, once you start looking at the further process that leads up to it, and even after making those changes through your tools, that’s really getting into orchestration and that opens up a wide array of things you’re going to have to integrate with, but also there’s a lot of challenges that come with that. So the hope here is that I can show you a lot of things in our platform, but really instead of just showing you bells and whistles and knobs, showing you another way of how to do things. Because a lot of times the idea of getting into the world of orchestration means writing more code and with that comes a lot of challenges.

Rich Martin • 02:26

And what we want to show you here today is that you can take the programs and the tools you’re already using and to do network automation. And without any changes, you can integrate them into our platform and use them in an orchestrated workflow. And this not only can possibly save you a lot of time as the developer of network automations, it might be something you don’t even want to write a lot of integration code and data transformation code. Because one of the things about that is you have to manage that over time. And since we’re talking about processes, as processes, as you’re building out more integrations to different systems to incorporate more of the process, all of that code gets more complex and harder to manage over time. Even looking at this diagram here, let’s start at the bottom.

Rich Martin • 03:12

You’re gonna start with, we’ll start with a Python program that can do something basic as an automation. Your automation might be more complex, but here it’s going to make changes on Cisco routers here at the bottom. This Python script will be running to make those changes. I’ll show you running it on the command line, just like you normally do on a day-to-day basis. But what we want to do is we want to incorporate that automation asset into part of our platform called IAG. We call it Automation Gateway or the I-tential Automation Gateway. I’ll walk you through Automation Gateway, show you how we onboard, test and even execute and run your scripts, your automation assets, your playbooks, things like that.

Rich Martin • 03:53

But really that’s the gateway to get started into using these automations as part of an orchestrated workflow on a canvas inside of our platform. So I wanna show you right after that how you can start using that in your platform. And then typically, when we start talking about orchestration, I really like to start pretty simple with folks. How you can get your automation in the platform, how you can run it from the platform in a workflow, and then how you can start to add in more automated tasks so you can orchestrate these together. And so that’s what we’ll be going through today. adding that to the automation gateway, so it can be used in the automation platform. Inside of a workflow, we’ll create a workflow.

Rich Martin • 04:34

We’ll add data gathering steps, so things like querying NetBox for IP addresses. And then we’ll talk about prechecks and postchecks, how you can implement those, whether you use the tools within our platform or you do that within your scripting. And then things like now we can start to think about since we’re doing orchestration, things that are really big parts of the process that may be overlooked because the automation tooling may not have the ability to do these things or maybe it’s very complicated. Things like integrating with your ticketing system whether it’s ServiceNow or JIRA or something else. And then maybe things that are like we would like to be able to do that, but we’re not sure how to. This would be a nice thing to do, but right now we’re focused on other things, building automations and maybe some light orchestration. Things like sending teams or Slack notification.

Rich Martin • 05:18

In this case, we’ll use MS Teams to send updates to those platforms so that you can notify an entire team of the automation being run, the statuses, things like that. So I’ll introduce you on how to do all these things. Of course, there’s a lot going on here. What you’ll find is that I’m gonna show you the basics. And if you ever want a deep dive, please go to our website and search for any part of our platform. You’ll find a deep dive into each part of these things. But I’ll give you an overview because again, I wanna show you a different way of maybe accomplishing how to get into orchestration without having to write a lot of code, manage code over time.

Rich Martin • 05:56

And the other thing about this that’s interesting is you can also increase participation, not just in who can run your automations, which if you’re writing automated scripts and things like that, you want it to be run, you want it to be used, but also who can participate in utilizing those in an orchestrated workflow. So we’ll talk a little bit more about that. So with that, let me share my screen and we can get started. Since we’re talking about network automations in Python, let’s start right at the very beginning at a shell prompt. Let’s imagine I have a series of network automations that I’ve written in Python. In this case, I’ve got one called create interface iOS. Let’s take a look at it. It’s a Python script.

Rich Martin • 06:46

It uses NetMECO. It does some very basic things, but if I run it from the command line, you’ll see that it requires some argument values here. It needs a host name, interface, description, IP, and netmask. Very simple stuff, very basic stuff, and probably very similar to what you’re doing. Normally, when you run a script, you would just run it. Let’s see. Just run it from the command line. Okay, I need to, you know, if I, without arguments, it catches that and says, ah, give me some data here, give me some information.

Rich Martin • 07:23

So if I start populating that, we’ll use a loop back for testing. Description, we’ll just use it as a test. IP address, 11, 11, 11, 12. Net masks, since this is a loop back, we’ll do 255, 255, 255, 255. I run the script and boom, it pushes the changes. Again, this is simple. Your scripting may be a lot more complicated than this and probably is, but as a test, this is what you normally do when you’re writing network automation scripts, you’re pushing a lot of configs.

Rich Martin • 08:00

But that’s automating a basic or straightforward task, even if it’s a lot of config changes. Really what we’re, even before we can get to this point to populate the argument values that I need for the script, I need to do something before that, right? In fact, I probably need to do several somethings before that. So the reality is that it probably looks a little more like this. I’m about to make a change. At the very least, I should probably spend some time in service now. in my favorite place, opening tickets.

Rich Martin • 08:31

So I fill out a lot of forms. I make sure I double check. I put some notes in here. I click Submit Ticket. It submits the ticket. Maybe this change doesn’t have to be approved. Maybe it does.

Rich Martin • 08:43

At some point, I have to do the ticket. And I know at some point, I’m going to update the ticket, right? I’m probably updating the ticket with the changes I intend to make beforehand. So even before I can fully update the ticket, I probably need to visit somewhere like an IPAM system. Could also be an inventory system. We won’t go into all the systems that you would manually have to go into. But I’d have to log in the NetBox.

Rich Martin • 09:04

I’d have to do something like this, request a new IP address because this new interface needs an IP address. I’d have to look up the right subnet to get it from or get it from the right prefix. Fill out some information here. Click Create. Then I get to. Copy and paste, maybe I’m using notepad to do that. So here’s the IP address I’ve been given.

Rich Martin • 09:28

Now I can maybe fill this back out in my notes on the ticket, update the ticket. Then when I’ve done all the prerequisite stuff, now I can actually make the change, right? So given that we just pulled an IP address, I can use that IP address now. So I’m copy and pasting it. And since that’s a loop back, I’m just gonna use 255s again. And now this is more like what it really looks like before I run that script. We have the script, it has argument values, but those values have to come from somewhere.

Rich Martin • 10:02

And then there’s an entire process ahead of this. And I skipped a lot. If you start thinking about what your process looks like, it’s a lot more complicated than that, but we need to start somewhere. So a lot of times opening tickets, data gathering, in this case, I’m just looking up an IP address. I might actually have to look up the right router, right? Because maybe there was a ticket that opened up that requested this change. And so maybe I have to look up which router I need to utilize.

Rich Martin • 10:26

And maybe there’s another inventory system, or maybe it’s NetBox where that’s gonna give me the next usable interface to use. So all of these things can come from other sources of records and sources of truth. So a lot of that is done manually. So when we talk about orchestration, it’s all of these steps before, not to mention things like pre-check and post-check. Thank you. and all the things afterward that you want to do and start to use, to start to automate all these steps together in an orchestrated way. And so there’s lots of ways to do that, right?

Rich Martin • 10:56

You could write code to do this, right? So we could extend our Python code to start to integrate with all kinds of systems, to replicate all of this tasks. But again, adding a system might be straightforward, but when we get to adding four systems or five systems and then doing data transformation across them, and then think about managing all of that over time, that becomes very, very, very much more complex and more tedious. And then also maybe even limits the ability for other people to go in and make changes, even to things like some of the network configurations and the network automation that’s now embedded inside of this much larger orchestration and automation script. So one of the things we want to help our customers with is you make the decision on how much you want to use in your scripts, how much you want to build in there based off of what you want to do, the capabilities of your tooling, things like that. And let’s bring that on board into our platform. So our next step here is to go into Automation Gateway.

Rich Martin • 11:57

So Automation Gateway is another application that we have as part of our solution. One of the things it’s really focused on is taking all of that awesome network automation that is being built in all kinds of organizations, by DevOps teams, network automation engineers, or network engineers that are, like I said, taking that step forward and learning how to use tools to automate. We want to bring that into our platform for a number of reasons. For number one, there’s some of the challenges that you’re going to experience as you even go just from automation is how do you share your scripts out to your team? How do you encrypt sessions? How do you give access to everybody? How do you ensure scripts are being run correctly?

Rich Martin • 12:40

These are things you have to solve. When you go from command line scripts, how do I just get that to my team? Do I put it on a file share? Do I put it on a box folder or something like that, so that everybody can download it? Do I teach everybody to use Git so I can check it into a Git repository? Then how do I get them to run it? Do they all run it on their local machines?

Rich Martin • 12:59

Do I have a centralized server? How do I provide access and encrypted sessions to that? Then how do I audit that? All of those challenges you’ll have to solve as you start to go from automation and extend participation on who can use your automation. Automation gateway is there to help teams get to that point and solve those problems. Again, they can be solved in a number of ways. This is our way of solving it.

Rich Martin • 13:20

So that create interface iOS Python script is onboarded into our platform. This is the script that we just ran from the command line. Now it’s made accessible here through an account that I have, but other people on my team can have access to this account. And remember, we have arg values, right? We have to have these arguments set here so before the script can run. So once it’s in our platform, it allows execution of the script. But before you do that, you really need to define the parameters so that our backend system can run it.

Rich Martin • 13:50

So if you look at this, we define those parameters to match the arg values that you’ve created in the script one for one, but we’re defining it in a JSON object here, right? And so we’ve got our description interface, IP address, netmask and router. It’s once it’s in our system, it likes to alphabetize it. So sort it by alphabetical. So that’s why it’s in that certain sort right there. But that being said, all the information is there. Now,

Rich Martin • 14:21

I’ve listed all of these as required because we need that. Otherwise we’ll generate an error when it runs the script. And then I’ve defined the order here. So this is how it knows the order, despite the fact that the properties are rearranged alphabetically here. This is how it knows the order because the order is important, right? And there are different ways. You don’t have to do it this way.

Rich Martin • 14:40

We can, you can create a decoration as we call it in the JSON schema to fit the model of whatever your command line arguments are. So if you have things like flags in front of it and things like that, you can build a schema to match that. But the idea here is that we want to, we want to define the inputs to that script, right? And we use it with a JSON object. And you can even, because it’s a JSON object, I could have created the IP address and net mask, not just as a string, but as a format IPV4. So you can actually do some validation checking here because the idea is that even from automation gateway, I can run the script here. So if I wanted to similarly run the script from here, I could.

Rich Martin • 15:27

Give it a whirl. Then what you’ll see is it comes back to success. It’s running it just as if it ran it from the command line. If we’ve generated a form here based off of the parameters we set in the JSON decoration, and now it knows how to run the script. But what’s really interesting here is that once it’s an automation gateway and we’ve applied that decoration on it to define the parameters to pass to your command line script, then it basically generates an API. Now it knows a payload to pass to it, and it’s API accessible from within our main platform, which is called the Itential Automation Platform. And specifically, where we go to start building these orchestrated workflows is Automation Studio here.

Rich Martin • 16:11

So I’ve created a project for this. And a project, you can think of it as just what it is. It’s a container of all of the workflows and different assets that I want to group together to comprise, you know, it could be a workflow, a set of workflows to orchestrate, you know, a process that can utilize both your tools, integrations into other systems, and even tooling that’s available within our platform as well. So we start off here with main workflow. There’s really not a lot going on here. There’s one task, we call this a stub task. It just sits there and it’s a placeholder, right?

Rich Martin • 16:49

This is useful because it allows us to model things out. So before we know exactly which assets, so which tasks, which scripts, or even API calls we want to use, we can stub it out by using this particular task. If I double click on any task on this line here, you’ll get a set of variables that are defined for this, okay? And this will make sense in just a minute. So for a stub task, it’s unique, we can name it, we can rename it something a little more descriptive, and then it’s got a set of variables that are assigned to this particular type of task. We’re not using that because we’re going to replace that.

Rich Martin • 17:27

So one of the things I want to do is, we ran the network automation from the command line, we ran it from Automation Gateway, now we want to run it from a workflow. And because the workflow is going to orchestrate a process, so we’ll start the event of orchestrating a process directly with your script. So the first thing we want to do is we want to bring that script in. So to do that, we have a palette here that’s available to us that has all of our tasks that are available to be used in the system. Now tasks, you’ll see, if you look at these dropdowns, are possibly like logic, data types, and integrations to other systems. So you’ll see AWS, EC2, Azure, GitLab. We integrate with all these systems because when you think about orchestration, you’re not just talking to the network.

Rich Martin • 18:21

And in fact, you could be talking to every network domain. So it’s not just a single network domain. So a lot of automation tools are really good at automating something in a very specific network domain, the data center, cloud, SD-WAN. But what about the fact that when an application gets deployed, you may need to modify devices in the datacenter, modify something on your firewalls, modify something in the Cloud infrastructure to support that application or to make an application change. All of these probably have different automation tools. The idea of orchestration is pretty common sense. Application gets deployed, we need three or four different groups with three or four different tools to run their tools, their automations to automate changes to their domains.

Rich Martin • 19:08

But it has to be done in a sequence, it has to be done one after another, and sometimes it’s contingent. The network team needs to generate the IP addresses to give to the server, The firewall team can’t update firewall rules until they know what those IP addresses are. Sometimes there’s contingency. Orchestrating this process and orchestration means really integrating with lots and lots of things. That’s why we have lots of integrations here. Your process is going to touch a lot of different systems that aren’t just unique to networking.

Rich Martin • 19:41

One of the things we talked about already is NetBox. You need the ability to do that. With Itentials Platform, we do integrations in a very quick and simplified way. We make it super easy. You can download integrations and adapters from our Git repository. Those are also accessible to be viewed from our website. We’ll show you that in a minute, as well as all kinds of other automation assets to get you started early.

Rich Martin • 20:07

All that’s freely available, and then we even allow you to generate your own adapters and integrations to whatever systems you may have using standards-based API documentation that’s available. We want to make it super easy and super simple, because again, when we’re talking about orchestration, we’re talking about processes as different systems and that changes over time. What you have today might be different from what you have tomorrow, probably will be. With that being said, let’s add your, we know all the things that are available here. Now let’s add that script. Create interface. You’ll see here under AG Manager, that’s Automation Gateway.

Rich Martin • 20:45

It’s managing all of the assets, in this case, the scripts that are available on this. I’ve just searched for this and we found it. If I drop it on our, our workflow here, and then I can delete this and merge it. And now if I double click it, you’ll see that All of the ARG values that we defined with that JSON object are now communicated here when we double click into a task. So the task understands, based off of the type of task, in this case, a script, because it’s accessible through Automation Gateway and we’ve defined the variables to pass to it, it now knows what to use when it calls this particular task.

Rich Martin • 21:36

And this task is going to run the script that’s on Automation Gateway to make changes to the network. So let’s go ahead and do that right now. So our description, as we know, test interface, we said loopback 333. IP address, well, where does that come from? Again, we could go back to here and use and generate another IP address. And now we use 140. And then our netmask, and notice I’m defining these statically just like you would when you’re running your script.

Rich Martin • 22:21

So it’s a start, right? This is how we get started, just as an example. So I’m going to give the router router1, so the host name, close it, save. And now we can test run it here. So as I’m developing this workflow, I could run it directly from the Automation Studio. And we can see the inputs and the outputs. So if you’re used to developing or using automation tools, especially programming languages, this might look pretty familiar.

Rich Martin • 22:51

So when I double click this, this is the execution information. So this is the details that I passed. We just filled all of this out in that form when we double click the task. So I’m looking at the job now. It’s already executed. And it’s this step executed successfully. That’s why we have this screen checkbox here.

Rich Martin • 23:07

And now I’m looking at the variables that we passed to the task. So these were all statically defined. But we can also take a look at the variables that came from the task that was executed, in this case, running the script. And again, just like on the command line, we get output. We get a status success that it was correct. And we get an output here. And we can verify that the output is correct, that it operated correctly here.

Rich Martin • 23:34

So here’s the new IP address that we passed to it. And everything looks just like it did before. So that being said, let’s go back to our script because what we did was we simply manually entered all that data, but specifically, we could have automated this step here of the IP address, right? I had to manually go to NetBox, and then I did the swivel chair, logged in, got the new IP. That’s part of a process when we’re talking about orchestration, how do we incorporate that into now this workflow? And again, with Python, there are libraries to do that. You could go download a library or set of modules to do that.

Rich Martin • 24:17

You could do low level through requests and HTTPS. There are a number of ways to do that. And maybe doing something like gathering IP addresses from your IPAM system is something you do wanna incorporate in your script. You have options with this methodology. But remember, if you continue to build in more and more integration, and then code to translate data back and forth, that becomes complex. And again, there’s fewer and fewer people who could probably have the skillset to follow all of that.

Rich Martin • 24:48

So maybe now with something like this, where you can take your high code assets and use them in a low code canvas with a low code workflow, it allows people to more easily follow the logic, add and modify things as needed. And maybe this gives you a chance to focus on the really, really critical stuff like building the network automation and integrating even a series of pre-checks and post-checks within that that are relevant to that. And allow everything else to be managed in a workflow through the Itential platform where other members of the team who aren’t as skilled in programming can now understand what’s going on and modify it as necessary as changes to the processes even within the network are occurring. And so that’s really what we wanna show here. So we start with this. So let’s add a task to do what we just did to Netbox, which is basically query for an IP address. So I already know what it’s called.

Rich Martin • 25:45

So post IPAM prefixes, this is something you would need to gather from from API documentation to determine which one of these NetBox calls are available. For instance, if I go to NetBox and I click on the arrow here and I show you all of these calls. These are all available as tasks to drag and drop onto here. It’s not just IP address management. What you’re actually seeing is when we integrate to NetBox or really to any other platform or service or system or application, when we do an API-based integration.

Rich Martin • 26:25

We’re basically exposing all of their API endpoints as drag and drop tasks into our Canvas. This gives you the ability to really do anything from a workflow. Again, orchestration means integrating lots of stuff and doing lots of different things to all those different systems. In this case, this gives you exposure to everything. Now, you can limit what you want to expose here. Maybe you just want to limit the API endpoints to just IPAM related, or maybe data center infrastructure management related tasks. You can certainly do that when you create the integration.

Rich Martin • 27:00

But the idea here is that you have basically all kinds of stuff available to you. In this case, this is going to give us the ability to do a query directly to that IPAM to NetBox at IPAM. If I double-click it, it’s going to request a couple of pieces of information here, an ID number. I know this is 123, and this data object is just a JSON object that you can pass. I’m going to leave it as an empty object. It’s still required. You can see here’s an object and this little asterisk means it’s required. I’m just going to leave it at that.

Rich Martin • 27:30

The ID, if you’re familiar with NetBox, you can get a number of different ways. Obviously, up here in the URL, but at the same time, they usually expose it here for these different prefixes, so that ID is 123. That’s where you can gather that. I’m just going to use this as this task. We’ll save it and we’ll run it. Again, I’ll execute this in a test run as we’re building this workflow out. So you’ll see we both had successful tasks here, successful runs on these tasks.

Rich Martin • 28:03

If I double click the Netbox query, you’ll see this is the information we passed to it. And here’s the outgoing information. You’ll see that this is what was returned from the API call. It’s a JSON. Everything in our platform is going to be reflected as a JSON. You’ll see the response data, we got a code 201, so that was successful. Here’s the URL, and here’s the IP address that was returned to be used next. That was next in the pool.

Rich Martin • 28:35

Now, that was an independent task from this. We didn’t actually pass that data into here because that’s another step in this workflow that we would have to do, because now it’s a data manipulation. We’re still leveraging what we statically assigned here. But I wanted to show you adding that task and now, how do you transmit data or translate data between two different tasks? That’s our next step here. We can do this by using what we use in our platform called transformations. In my project, I’ve created a transformation.

Rich Martin • 29:06

This is called GetNextIPFromNetBox, and I’ll show you what it looks like. If I go into Assets, right here is Tasks. These are all the integrations, including all of the scripts you can onboard into our system through Automation Gateway. If I go to Assets, these can be pre-built assets inside of our platform. So they can be other workflows. So I’m building a workflow here. This could be a whole other workflow.

Rich Martin • 29:27

So think in terms of a subroutine or a function. We can have another workflow that runs as a task. So this allows you to now build modular workflows, which I’ll show you here shortly. But we also have transformations, JSON forms, command templates. We’ll talk about a few of these today. But again, you can deep dive by going to our website and looking for media and material on that. We’ve pretty much done videos for deep dives into each one of these things.

Rich Martin • 29:55

But a transformation is a special task. It’s focused is, and let me rename this while I talk. So we can rename any task get IP from Netbox. A transformation is that bridge between a successful API call and the data it’s returned, and then manipulating that data so it can be passed to a subsequent task in the workflow. Remember, we’re orchestrating. How do you take data from an API call and give it to another task? In this case, it’s an API call to your script.

Rich Martin • 30:32

You have to manipulate, you have to get the data, you have to extract it, and in some cases, you have to manipulate it because the information that was returned from NetBox was the IP address slash and a slash 25, which is a CIDR expression of the NetMask. Really, when we’re passing that along to the script, it really needs to be in the dotted quad NetMask format. In this case, since it’s a loopback, we always want to use 255.255.255.0. We need to make some modifications, and that’s what a transformation is for. If you’ll see here, I’ve created a transformation already. It’s called GetNextIPFromNetBox, and I’ve added it to my project. If I just click on Transformation and then GetNextIP, it’ll pop up from here, and we can just drop this right here in between.

Rich Martin • 31:17

Now, there’s a couple of things we have to do. When I double-click Transformation, it’s going to ask me, what’s the input information that I should be transforming? And that comes from the output of the netbox call, right? So if I click on task, this is basically saying, get the input into this transformation step is going to be the output from a previous task. In this case, the task is called get IP from netbox. It’s already populated it. And the task variable is known as result.

Rich Martin • 31:48

And then you’ll see here as outputs, it’s going to output an IP address as a string and a netmask as a string. And then an error, which is always available for every task in case there’s an error status. So what does this actually look like? How do you actually build these things? Is this code? Because if you’re used to writing Python or something like that, you do this in code. Maybe you do something and you use a modifier like toString or something like that to turn a number into a string.

Rich Martin • 32:16

Or there are a number of ways of doing it. Well, again, this is visual. This is a visual canvas. It’s a low code canvas. So what we want to do is we want to allow this to be built in a visual way so that it can not only be reused, but understand by other groups who may not be programmers. So if I double click on it, I can open the transformation here. We can take a look at it, what it looks like, and I’ll step you through it.

Rich Martin • 32:37

Here on the left side. is our object that I’ve called from NetBox. This is a JSON schema that is defined based off of the information that NetBox passes back from a successful API call. When the API call to NetBox for getting that next IP address is returned, remember it’s returned when we looked at the job that task executing, it was returned as a JSON object. I can literally take the output of that. and I can infer the schema from the output of that. So it’s actually a very simple one-step process, and then I name it something.

Rich Martin • 33:12

I give it a unique name, front netbox. From that, I have exposed all the information that netbox will return. So now I get to pick what I want. In this case, I want the address. But remember, I can’t just map the address to my outgoing schema. So this is what’s going to be returned from this transformation task. I can’t just map it because I need to do some manipulation on it.

Rich Martin • 33:32

So that’s where all of these methods come in. So I can drag and drop. I can expand any of these methods. In this case, since I’m working on a string, I want to split the string because remember the string is IP address slash CIDR. I want to split the string on the forward slash. That’s going to output an array of two values, two strings, the IP address, and then the next value of the array, the next element of the array is going to be the netmask 25. I really only want one of that.

Rich Martin • 34:00

So this shift. element here, the shift method, allows me to basically just grab the very first one of the array. And now, since that’s a string, I can map that directly to an output schema. And you can define as many outputs as you want as variables, because you want to use these to be put in the right format to be used, in this case, by our script, which is really running on command line. So we need to make sure it fits that format. And then simply here, so that gives us our IP address without a slash anything, gives us that basic IP address. And then, since we’re always using a netmask, 255.255.255, I’m just defining a new string and mapping it here.

Rich Martin • 34:42

You could take the slash 25, and you could do a lookup table, even with these elements and these methods, to do a lookup table to determine the right dotted quad netmask to give to it. So all of that is possible here. Actually, we’ve done that in previous videos. So those are things you can change. But this is really powerful. And again, it allows somebody who may not know how to code to actually visually go in here and take a look at what’s going on and start to understand how this works. And again, this is a reusable component.

Rich Martin • 35:12

We can use it here. But any time you get an IP from Netbox and you need to manipulate it this way, this is a reusable component as a transformation, so that you can use it in other workflows as well. So now that we’ve got that, the last thing we need to do here is go back to our script, remember. And since we statically assign that value, we now want to get that value from another task. In this case, the transformation task, which is called GetNextIPFromNetbox. It gives us our variables if I click down here. In this case, IP address is what we want.

Rich Martin • 35:42

But we also want to go ahead and grab the netmask from there. And so the task variable here, same previous task, but I’m now choosing the other variable that was defined netmask. And so I can close that, save it, and then as a test, we can run it. And now we can see how we’ve taken our first step into orchestration, right? We no longer need to do a swivel chair into NetBox before we run the script, whether it’s on the command line or through an automated workflow here. We can actually start to integrate with these other systems. So here’s our call to NetBox.

Rich Martin • 36:22

We got 142 as the next available IP, which makes sense. Here’s our transformation. So let me expand this a bit. Remember, we’re looking at the input to this transformation step. That was the output from here, which we defined. We said, hey, your input is the output from this, which was defined by that schema. Now it knows which field to look at, because we mapped IP address or address here as the field.

Rich Martin • 36:44

And remember, it went through those transformation steps so that when it outputs information, it gives us just the IP address and just the net mass that we were looking for. Of course, that net mass was statically assigned. But then the key here is. We are just now, those inputs, 142 and 255, 255, 255, 255 came from that transformation. It was passed into the shell script, which was run on the command line, and now we have the ability to no longer swivel chair to that particular netbox for this particular part of the process. We’ve just started our first step into orchestration. So it’s basically like that.

Rich Martin • 37:24

When I work with prospects and customers in our platform, I show them how to take your first step. And it’s usually around data gathering. But then you quickly start to realize, what more can we do here? And there’s a lot of tools on our platform that allow you to do that. So obviously, before you make any change, you’ve got to do some pre-checks and post-checks. So here’s something to consider. Do you want to do a series of pre-checks and post-checks inside of your tooling?

Rich Martin • 37:54

So do I want to write this inside of my script? Do I want to extend the script programmatically so that before I make that change, I do some checking? Well, the answer can be yes or no. There’s no right answer. What we’re giving you is options. Or maybe it’s both. Maybe you say, you know what, I’m going to do a subset of steps here inside of the script.

Rich Martin • 38:17

But. I’m going to also allow the network engineering team to add their own set of checks here, which may be different from mine. They may be looking at other systems. They may be looking at discovery systems, or a digital twin, or something like that, whereas you’re looking at more network operational state, and you’re stripped. That’s absolutely fine to do. You have those options with our platform once you go down this route into orchestration. So in this case, I’ll show you what some of our tooling looks like.

Rich Martin • 38:47

If I go into Automation Studio, we have these assets called command templates. And so these are the ones I’ve created here. They’re very simple to understand. This is why it makes it so nice for network engineers, again, that don’t have a background in writing code to be able to do something like this. So imagine the ability to now just execute a command. In this case, it’s on an iOS device. And we can test it live.

Rich Martin • 39:16

I do a show interface. In this case, it could be the loopback. So if this is a pre-check, the loopback shouldn’t exist. And it shouldn’t contain that interface is up, line protocol is up. Notice I have a variable, I’ve variabilized interface here. So if I test this command, it’s going to ask me, give me a value for this variable. So if I go loopback 333, now it’s going to execute the command and it’s going to give us a pass or a fail based off of the results, right?

Rich Martin • 39:43

So in this case, loopback 333 is up because we’ve already created it. So the rule is it shouldn’t create that. So it failed the test. So if this was a pre-check and this interface shouldn’t already exist, so I’m deploying, provisioning something net new, then this could be a step in a pre-check. And in fact, you can have multiple steps in this, or you can have an entire workflow related to pre-checks and post-checks that can not only talk to network devices directly and get operational state. But like I said, talk to other devices, inventory systems, management systems, monitoring systems, things like that, through APIs. You could do all of that.

Rich Martin • 40:20

Similarly with post-check, it’s the same thing, except now the interface should exist. So then we changed the rule from doesn’t contain to contains, and then you could do the same thing. And these provide inputs back to tell you pass or fail on the status so that you can go back into your, into your workflow and start to build in some logic around that to evaluate whether things have failed, passed or failed. So in this case, we could just literally go over to our command templates. Here’s my post-check and here’s my pre-check. I can drag them into here. So then I can start to add this.

Rich Martin • 40:58

Now we’re doing pre-checks and post-checks. right inside of our platform. So we’re adding more to the orchestration. What about things like ServiceNow tickets? Creating and updating ServiceNow tickets. At the very beginning, that’s one of the things that are part of the process that may seem at least if you’re starting down the road of automation, writing that code may seem something like, I’d like to do that one day. Well, maybe you don’t have to.

Rich Martin • 41:24

Maybe you can leverage our platform, our ability to integrate quickly with all of these different systems and simultaneously both to the production ServiceNow and the development ServiceNow so that you can even test workflows across both. There’s no, you know, you can have both of them going on at the same time so that it makes it easy to manage integrations through our platform so that it leaves the network DevOps or the network automation engineer gives them more time to focus on really cool, writing these awesome scripts and whatever tools they want or learning new tools to write network automation scripts. So this gives you lots of options. So one of the cool things here is that, you know, maybe we want to do a ServiceNow, creating a ticket and updating tickets. And then, you know, some things I mentioned earlier, like it would be great if we could also now take some of that information, update the ticket, but also send that information to a team’s channel so that the network engineering team that’s, you know, currently working on the clock can see what was going on when an automation is run. All of that is possible. And all of that is, now we’re talking about orchestration.

Rich Martin • 42:32

And so one of the things that we’ve done also is I mentioned the fact that you can run another workflow as part of a, as a single task here. So think of that like, again, as a subroutine or a function call. If you go to our website, and under Products, go to Automation Marketplace. A lot of our customers or prospects will go here and search for things that are in their environment. So if we look at ServiceNow, one of the things that you’ll find here is we have these modular automations. These modular automations are pre-built workflows that are freely available.

Rich Martin • 43:09

So you can see them here, but you can install them in our platform so that you can immediately start to use them. And so you’ll see here, we’ve already published some pre-built workflows to do things like create change requests, update change requests. So you don’t even have to go into the API. that list of API endpoints that are tasks and figure out which ones are there. We actually have built some basic modular workflows so that you can start to use those immediately in our platform. So if I click on technical documentation, I can look at create change request. And it’s going to show me the inputs and the outputs for that particular workflow when you run it as a task and as a child workflow.

Rich Martin • 43:51

So all of this is here. This is great as you start getting into our platform and this will save you tons and tons of time. So if I go back here now, I’ve already imported all of that in here. So if I go into workflow and actually I have them here. So if I create change request, There might be several, but I want the one that’s embedded into my project. Now you’ll see here, I’ve created a change request.

Rich Martin • 44:19

This is a child job. That child job has a set of inputs and outputs that are required for the child job to run. If we wanted to look, and those were defined again in the workflow, but you can see it in our documentation that I just showed you. But if I go to Open Workflow now, you actually get to see what the workflow looks like. So this is what was available freely from our Git repository very quickly through the system, imported into the system so it can be used. And then it shows up in your task palette that I showed you earlier when we build these workflows. And so this is what it looks like.

Rich Martin • 44:54

It’s very simple, straightforward. It takes all that information that’s input into the child job that’s required as inputs. It creates the JSON payload, calls the ServiceNow API call to make the change request, to create the change request, passes that payload to it, and then it does an evaluation here. Well, if there was an error, so this red line is an error. So if the API call had an error to it, there’s your fallout. So it’ll stop the automation so you can view data to see what was going on. It’ll pass that information into there.

Rich Martin • 45:23

If it was successful, it does an evaluation. the call was successful, but did we get the correct inputs back with the new ServiceNow change request ID? If we got that, then it ends and it’s gonna pass that data along to the parent workflow so that you can use it to do things like update the ServiceNow ticket later. And so these are the kind of modular workflows and libraries that we have available once you start building and orchestrating workflows in our platform. So again, things like creating and updating change requests in ServiceNow or Jira or doing things in MS Teams become drag and drop elements in your workflow. So your orchestration Just to summarize here, so again, this is another child job that is a part of a module or library that’s available.

Rich Martin • 46:14

And you can check it out on our automation marketplace from our website. And you can see that this is a whole other workflow that takes all of the elements of broadcasting something to a channel. So now all you need to do is manipulate the data through transformations to pass the data in to the correct payload and the information you want. So it could be broadcast in the channel, or it could be updated or created as part of a ticket, or it could be updated as part of a ticket. All of these things are available to you. And again, we started with just this piece right here, your script, without any changes, without having to say rewrite it or modify it or include this library in order for it to work, just onboarding it into gateway, and then building a declaration around it to define what you’ve already defined as argument values on the command line. And then quickly integrated with NetBox through a direct API call, manipulated the output from that so that it can be used as the input for your script.

Rich Martin • 47:13

And then leveraged other things like entire library, modular library assets to do things that would be normally a lot more complicated, like opening and updating ServiceNow tickets or sending job notifications in MS Teams to different channels, all kinds of information to your team. All of those elements now become drag and drop elements here. And again, this will save you time as somebody who’s building network automations. And it allows you to determine the level of integration that you want to put into your scripts. Maybe you want to collapse the NetBox query into there. That’s pretty straightforward and makes a lot of sense. But all of the other stuff, perhaps you don’t, perhaps you want to, or maybe you want to do certain command templates, I mean, pre-checks and post-checks that are very relevant to what’s going on in here.

Rich Martin • 48:02

But now the network operations team has the ability to add their own set of pre-check and post-checks, which could be, like I said, querying other systems. This allows you to continue to focus on the things that are… important and quite honestly fun to do as the one using the tools to write the network automations and still increasing participation, not to a small group who only understand how to use these tools or write the code, but to an entire network engineering team who can leverage your automation as is or even leverage it inside of an orchestrated workflow. And again, once you get into orchestration, the next step to that is self-service, which is a whole other webinar in the future. So with that, I wanna say thank you very much. I know this was a lot of information. We covered a lot of stuff, but at the same time, you can deep dive into any one of these topics.

Rich Martin • 48:59

We hope it was helpful. If you wanna speak to a live human being, we’re more than happy to do that. Just reach out to us on our website and until next time, thank you very much.