Building Low-Code Workflows for Orchestrating Network Processes with Itential

Rich Martin • 00:00

Hello, everyone. My name is Rich Martin, Director of Technical Marketing at Itential. And welcome to another webinar. In this webinar, I’m going to give you an introduction to Itential’s new workflow canvas. And this is an introduction to an entire webinar series. Now, stay tuned. After the actual webinar and the demonstration is done, I’ll talk to you a little bit more about what that series entails.

Rich Martin • 00:21

But we’re super excited to kick this off with our new workflow canvas. So before we get started, in the Intentional Automation Platform 23.1, one of the major things we’ve done is we’ve reimagined the Workflow Builder. So in Automation Studio is where you build workflows. So a network automation engineer can go in and start creating workflows. We’ve updated that and modernized that Workflow Canvas. So I want to show you quite a bit of that today. So what you’ll first see is that we’ve really redesigned the user interface. We’ve added some quality of life features as well as some real strong features to help developers in the platform or automation engineers in the platform get things done faster. So I think you’re going to find a mix of helping people. This is the focus we had of helping people who are just getting started, making it more intuitive, a little easier to understand, a little easier for them to get started as well as balancing features in this new Canvas that help our existing experts get things done even more quickly. So the modernized Canvas is going to be a mix of that. We’ve taken a modular approach to a lot of the user interface elements like menus, libraries, and palettes. That’s one of the things I’ll show you today. Along with that, of course, is what about if I’m an existing user of your platform, what about all of the automations that we’ve done before with the previous generation canvas? I’ll talk about that. I’ll show you the process of taking one of those previous generation workflows that you’ve had built and transitioning them into the new workflow canvas.

Rich Martin • 02:00

We’ve enriched the workflow builder capabilities. So again, these are very, very nice quality of life things, especially for features, especially for folks who are very, very used to the platform and it really helps them get done building automations a lot faster. So things like multi-select, lots and lots of hotkeys, the ability to do copy and paste, undo, redo, and a bunch more we’ll talk about, as well as intelligent transitions between tasks and the ability to kind of make that a much cleaner and faster feature in the platform. And then finally, with building the automations, you’ve also got to, as you run them, render them correctly too. So we’ll take a, at the end of the demonstration, we’ll take a visit into a job manager, which is located under the operations manager section of our platform. And I’ll show you how the rendering has been updated and we actually can take advantage of some new features there as well. So in this demo overview, it’ll be a little different from the normal ones we do because I’m not building a workflow or anything like that.

Rich Martin • 03:05

But I am giving you a tour of this new Canvas. Again, this is an introduction to an entire series we’ll talk about after we wrap up the demo. But what I do want to make sure that you’re aware of is how to convert the previous generation workflows to the new Canvas. I’ll give you an overview of all of these features and a deep dive into these enhancements on the Canvas so that you can actually see and understand how these work and how helpful they can be. Then again, we’ll run a workflow that we’ve converted, and I’ll show you what that now looks like under Operations Manager as the job executes. So let me share my screen here and we can get started. Okay, so we get started here at the main home screen of the Itential Automation Platform.

Rich Martin • 03:59

And again, the new canvas is located under Automation Studio. This is where network engineers and network automation engineers can quickly build workflows that become automations that you can run and share with your team or share it within other platforms and publish and expose them. So we start here. Normally when we create a workflow, we do the same process here. I click the plus button and we can create a multitude of things here. What we want to do is create a workflow and then I’m gonna create a new one and I’m gonna call it webinar. Oops, Modern Workflow for the modern canvas.

Rich Martin • 04:37

And you’ll note here that there’s a switch here to use the legacy canvas. So if you want to continue to create in the legacy canvas, you certainly can do that. By default now, though, it’s going to put you into the more modern canvas. But this is your option to go back to that if you want to for a new workflow. So when I click Create here, you’re going to immediately, if you’re already familiar with our previous canvas, you can go back. you’re already going to see some differences here. The first thing that probably stands out, the first one of the two things that probably stands out immediately is the fact that the task palette is now on the left-hand side.

Rich Martin • 05:17

Normally, that was kind of embedded on the right-hand side in our previous workflow canvas, which, again, is still accessible on the system. But now it’s on the left-hand side, and it looks a little different. One nice thing about this, again, this is to help however you want to build an automation. We’ve noticed that a lot of our customers wanted the option to put this on different sides. So now it can be repositioned anywhere as well on the canvas to facilitate how you want to build your workflows. So you can get it completely one side or the other. And in some cases, as you’re looking through a workflow, maybe you’re not adding to it.

Rich Martin • 05:52

Maybe you’re going through it, you’re taking a look at it, you’re understanding the flow. Getting rid of the workflow palette, the task palette itself is simple here with this triple stack here. That shows. We can close it out. And you also notice, too, we’ve got a lot more tool tips where you can see the hotkeys. And I’ll hit as many hotkeys as I possibly can through this demonstration, but there’s a ton of them here. But this one is for Shift-T. It allows us to pop up our task palette as well.

Rich Martin • 06:25

It’s still very similar to the original task palette. So not only can I reposition it, though, but I can search it just like before. So if I go to Service Now. It will show all my service now integrations that I have currently on the system. We can also expand and collapse as well. So I’ll tell you what, let me pull in a few things. So we’ll build kind of a test workflow here.

Rich Martin • 06:55

Something that’s always part of this is creating the change request. So notice now I can also drag and drop onto the canvas here. So I’ll take that and then normally as well, there’s always an update for service now if you want to update the change request. So I’ll drag that into position here as well. And if I clear the filter, it’ll go back to all of this. And notice all of the different integrations or if they’re built in tools into the platform are now here. We’re highlighting the first five of them, but you can also expand them as well.

Rich Martin • 07:29

So if I go to, I don’t know, let’s see. Service now is always a good one. I can expand them, get all of the API tasks that are part of the task pallet or collapse them again. Let’s also pull in another task. So just using the new pallet, I can go to stub. And what I’m looking for is the stub task, which is a good placeholder as we create some steps in our workflow here. So I’ll pull that in.

Rich Martin • 07:57

And now I’m kind of done with the pallet for now. So I can get rid of it. And this gives me all of this real estate to use. Now, the second thing you’ll notice is the fact that the canvas is dotted. This is actually a grid that allows us to snap. And you’ve probably seen where I’ve got these tasks. They’re snapping to the grid now, which is nice because this allows you to line things up, especially if you’re like me and you like to see everything in nice rows.

Rich Martin • 08:26

This allows you to do that. But if you right-click on the canvas itself, you’ll see that there’s also a hide grid. So if you really want to go freeform here, you can. And then you also see that there’s some hotkeys here. So Shift-G would give us our grid back. Of course, Shift-G again would take it away. I love the grid.

Rich Martin • 08:47

I’m going to keep the grid. It makes it really easy to line up things horizontally or vertically. And along those lines, you’ll notice that when we started a new workflow, it started it up and down vertically. But there is no reason why you can’t go horizontal with anything you want. That’s perfectly up to you. The way that the task palette is kind of floating now, you can use it either way. But some people might find that they want to go vertically.

Rich Martin • 09:17

Some people want to go horizontally. Completely your call. The real estate is yours. That’s the point, is that it’s flexible enough to take it wherever you want to go with it. So I’m going to just build this this way for right now. I’ll put everything back in order here. Normally, a workflow, a pretty standard workflow is make a network change.

Rich Martin • 09:44

Before you make a network change, we want to pre-check and a post-check. Maybe there’s some evaluation to figure out if the pre-check worked or not. Then adding in things like ServiceNow tickets. Usually, you create the ticket at the top of the workflow for maybe a new change. And then at the very end, you do an update or a close, close and an update are the same API call. Let’s just spec that out as a test. We’ve already got some ServiceNow tasks in here.

Rich Martin • 10:13

I’ve got one StubTask. Again, a StubTask is just a placeholder. It’s really nice to be able to drop these in and give them new names. But it’s a great example for us to build a workflow out as an example. And then we’ll use this task quite a bit. A few things we can do here is, just like before, I can select a task. If I right-click, I can do a copy. And then I can paste here. If I right-click again, I can select paste.

Rich Martin • 10:38

Again, that is also accessible through hotkeys. One of the other things that’s interesting is now we’ve added the ability to do multi-select and do some functions like copy and paste on those. If I hold down the Shift key and use my mouse, I can select these two, right-click, copy, and then paste the selection here, and it’s given me now those two tasks, which is useful because now, let’s say if I want to create this workflow, I’m going to do a pre-check. I want to make the network change, maybe update the ServiceNow ticket, do a post-check, and then finally close the ServiceNow ticket. That works out pretty well. Let’s do, let’s see. Notice here that it’s kind of jumbled up a bit.

Rich Martin • 11:35

So this is another really unique feature that we’ve added here. Let me kind of stack them a little close. A lot of times, especially as you’re viewing things, you want to change the views or if you’re making something new or if you’re adding something to an existing workflow, there’s a couple of new features and tools here that are really nice. So if things are jumbled up like this a bit, you can also use the spread task control. So I can space these out or bring them together. You’ll notice I’m going to use that in the next portion of the demonstration where I convert a workflow. What’s nice about this is it gives me more space and I don’t have to touch every single task to create space across all of it.

Rich Martin • 12:15

So for instance, now, if I wanted to do that, I could pop up my palette here. Maybe I want to put an evaluation task in here so I can throw an evaluation task on the canvas, get rid of this. And now I can start to add this in and give myself some room to add it in. So I can do something like this. And you’ll also notice too, that with all of the tasks kind of spread out like this, Maybe I want to see everything at a direct view. Maybe I want to see everything specifically to a particular task.

Rich Martin • 12:55

We’ve got a ton of zoom, so we already have the ability to zoom in and out using your mouse or a touchpad like this. But we also have added quite a few zoom features here. So one of the nice ones is zoom to fit. So if I right click on the canvas itself, I can fit the entire workflow from start to end into there. Or I can zoom to a selection. So if I select a certain area, I can zoom into that. It gives me a big view.

Rich Martin • 13:24

But that allows me to also zoom back out a bit, too, to see a little bit more of the workflow that I want to work on. Of course, these also have hotkeys. And we can do a reset zoom here. So this really makes it nice if you’re building a lot of this. So if I reset the view, it’s going to give me a readable view in the middle of the workflow. If I go to zoom to fit, it’s going to show me everything in totality. Being able to hit the hotkeys and immediately go as you’re building these things is super, super useful.

Rich Martin • 13:59

This is also something new. It’s similar to before, but if you’re already aware of all of this, being able to double-click a task brings up the data, usually variables for the input and the output of the task. So double-clicking does that now. There’s also a hotkey for hitting Enter to do it, and also doing it from the context-sensitive menu as well. So we’ve redesigned this part of the task variables to make it easier for you to get around, so everything’s tabbed. We’re putting it in a position in a way to make it very, very simple to go directly where you want to go for any particular task. Again, to make it super easy for you to build these, or if you’re starting your journey and you’re just getting started in the platform, giving you access to all of the different variables that are required without having to kind of.

Rich Martin • 14:56

hunt and peck in through different tabs and things like that. So we’ve tried to make it super easy. So for example, for this stub, I might want to rename it pre-check. Right, and as soon as I’ve updated it, you’ve seen it here. It’s updated to pre-check here. Now let me go back to fit to view. Let’s see. The other thing too that’s also really, really great is the fact that we’ve put in undo and redo features into the new platform.

Rich Martin • 15:36

One of the things that we’ve done when we’ve redesigned this new platform, it really serves as an enabler for lots of other features to come after this. This is one of those things that obviously is super helpful as you’re building these things out, as you’re stubbing things out, or if you just want to copy and paste. Maybe you copy and pasted the wrong thing or you remove the wrong thing to be able to undelete and those things or undo and redo. If I deleted that task, I can undo it, bring it back. If I deleted this task and then this task, I can undo both of them and bring it back. If I deleted it and decided I shouldn’t have deleted that one, it was a different one. undo it, and then you can also redo the delete.

Rich Martin • 16:21

There’s multiple ways, again, so that we want to make it as easy as possible for beginners and existing power users. We want to enable power users to become more powerful users of the platform. With that also, you’ll notice here, we are missing something, we’re missing those arrows, so we call those transitions. The transitions themselves in our previous Canvas, let me do a little zoom in here. Transitions themselves in our previous Canvas required either one of two ways of doing it. You can do it with a hotkey or you had to click an icon up here. Now, we’ve changed things a bit.

Rich Martin • 16:56

We’ve made it a lot easier. If you click on a particular element in your workflow, so if I start with here or any of the tasks themselves, you’ll notice that it becomes highlighted in this dotted box. That’s a drag zone. What that means is now I’ve clicked on it, I’ve gotten that drag zone, and if I click within the drag zone to the next task, it’s going to automatically add it in. I’m going to show you a couple of other things too. We can finish that out if I go to another task, same thing. I’m just going to finish this all out.

Rich Martin • 17:33

So we go step-by-step, all the way to the end. OK. So you notice I have this evaluation now that’s not part of this. One of the things we also added is to be able to drop into the existing workflow transition and have it auto-insert. So that’s, again, a nice, useful feature, quality of life, making it saving you a little time. And a little time over a lot of building adds up to a lot. So it’s all about being efficient, more efficient with time, and making it easier.

Rich Martin • 18:10

And making it a tool that tries not to get into your way. It actually is just more intuitive. And that totally makes sense. And a lot of this comes from feedback from our existing users. So we love to get feedback and funnel that back into our development team. So as we start to build this out, there’s a couple of things here. So we’re doing a pre-check here.

Rich Martin • 18:31

We’re doing an evaluation, which is going to evaluate whether the pre-check was done. This, if I double-click here and I change this to maybe make network change, it’s fairly. So if I wanted to return a success from this drop-down, or we could add anything here from a previous job or statically, we could do that. All of that is available here for the input. And that’s the most important piece for as you’re building the automations, is being able to access and set those variables quickly. This could be an update to a change request that we’ve opened earlier in our first step here. This sub-task could be renamed post-check.

Rich Martin • 19:23

And then we could do, this could be a close. So we’ve kind of stubbed out with some real API calls, like ServiceNow and Evaluation. And then we’ve stubbed out with some network change calls. This is kind of what you would do as you were starting to build something new. Again, it’s just so much faster and easier now. I go back to the full view mode. Another thing I can do here, before we get off of transitions, is if I can just copy and paste this, I can use the hotkeys.

Rich Martin • 20:03

we can start to build transitions again, just like before using those transition tasks. But if I go here, let me zoom in a little bit so you can see it. If I go here, I have hotkeys to change the type of transition. So green is obviously a success. What we want to do is we want to run an evaluation and if there was a failure condition, I could hit F here and I could change the color. There’s a couple of ways to do it actually. If I create a, if I do it again, you’ll notice as soon as I have the drag zone highlighted, if I hit F here, I hit F while I’m dragging, it will go ahead and change it.

Rich Martin • 20:45

So I can change it while I’m dragging, I can change it after I’m dragging, I can change it to error, success, fail. Or of course, if I hit right click here, it’ll give me the different statuses as well. Also, if I’m building, so this could be a failover. Well, let’s make network change. We are going to change this to, this could be fallout and rollback. So we could have a task here that falls out and rolls back something. If this check doesn’t work, this is going to do an evaluation.

Rich Martin • 21:18

If this is a fail, then this could be a series of steps or tasks to roll back and maybe update the service now, take it at the end and close everything out with the new information. So I can now do this as well. and position it with my snap grid like that. So it makes it easy to do that. And if there are other types of transition changes that you might need within your workflow, the transition zones work the other way too. So for instance, if this evaluation were to take another transition change to error, something like that, I could go upwards. So I could go the opposite way.

Rich Martin • 22:03

And I could change this to air, for instance. And you’ll notice it’s going the opposite way. It’s red, so I’ve changed the type to air. But that can also be done as well. So we can also create transitions going the opposite way. And it immediately knows that since it’s going a different direction, it’s going to dot the line so that I understand that this transition going the other way. So this could be a loop.

Rich Martin • 22:30

It could be an evaluation that gets run. And maybe we’re doing fallout or rollback or something like that. But this gives you a great idea of all those different features and how you can start to use all of these new features in the modern canvas in order to start to build things very, very, very quickly and take advantage of all that real estate and screen space that you have going for you. If I save this here, and then let me transition now to showing you how to do the conversion and then what this looks like when something is run in the platform. So the next thing we want to do is we want to open up an existing workflow. So let’s take a workflow that’s part of our typical demo workflows that we use here. Port turn up end to end is what I’m going to take.

Rich Martin • 23:26

So I’m going to load this in. And you’re going to notice if you’re familiar with the platform that this is a previous generation workflow. In fact, most of your workflows might look like this. This makes a change to a data center port, the switch on a data center switch, a port on the data center switch. It opens up a change request ticket. It broadcasts through Microsoft Teams. This is a fairly typical workflow that a customer might use.

Rich Martin • 23:52

Built into, you know, using the previous generation workflow canvas. Notice it loaded up into that because we automatically identify it as a previous generation canvas. I’m going to go ahead and clone this. So I’m not going to change the original. I’m going to call it port turn up into E2E end to end modern. Save that. So now I have a copy of it.

Rich Martin • 24:17

And now here’s how you transition this into the new canvas. If I go under the three dots here, you’ll see I have the view metadata option under view metadata. You’ll see it’s already turned on to use the legacy canvas. If I just simply turn that off and save. It’s going to transition this back over into a legacy or to the modern canvas from the legacy one. And now I can kind of make some some changes now that I have this snap view, but you’ll notice there’s a lot of space between the two. And that’s where this feature, the spread task feature comes in handy because now I can kind of shrink it down a bit.

Rich Martin • 24:53

Go back to end-to-end view. And you can see this is horizontally written as well. So it preserved that. And now I can start to use this modern canvas and all the features and maybe modify this or test it or do whatever I want to do. But it’s as simple as that. It’s as simple as taking that. You don’t have to make a copy of it, but I made a copy of it, turned it into a modern canvas using that simple metadata, that switch to use the modern canvas.

Rich Martin • 25:19

And that’s that. So if I save it, this thing is ready to go. I don’t have to make any changes. And I can show you what that looks like if we go to operations manager. In operations manager, this is where we typically publish the automation. So it could be run manually or even through an API. So it could be run from another platform.

Rich Martin • 25:38

You’ll notice here that we already have a port turn up end-to-end. And in that, we specify the workflow that we want to run with this automation entry. This is using the original one. Again, I’m just going to clone this. And I’m just going to call it modern. the modern canvas. And now I can change this to our new workflow that we saved a moment ago using the modern canvas.

Rich Martin • 26:03

So it’s the exact same workflow, but it’s now visualized and saved off as a modern canvas. And if I save those changes and then run this manually, it’s got a form associated to it. So I’m going to keep that. And we’ll just go. I’m going to test 1, 2, 3. If I run manually, now it’s going to take us to the Job Manager, which is under Operations Manager. And it’s going to show us the new visualization.

Rich Martin • 26:30

So you’ll notice here, it’s showing us the visualization of the modern canvas that we just converted to. And we’re seeing step-by-step the status updates as they go through the automation. So right now, it’s working on this child job, which is called Port Turnip. And see, this is a workflow that was created using a lot of smaller child, modular child workflows that are run under these child jobs. The overall workflow is this one, the Port Turnip End-to-End Modern. So when we converted this, this particular workflow was converted. But it’s still using child workflows that are still using the previous generation canvas.

Rich Martin • 27:15

I’ll show you this. So this Port Turnip task is running another workflow. Uh-oh, let’s see here. Sign back in, timed out there, of course. This is the previous generation workflow that’s part of port turn up. So you can still leverage all of your existing older workflows on the previous generation canvas with a more modern workflow as well. So there’s no limitation to how you want to use this.

Rich Martin • 27:46

Think of it strictly as a way that we’ve changed the visualization of it. So you can continue to use the module workflows that you might already have in your own libraries or from our pre-built libraries that we’ve made freely available to our customers. So something like that can leverage both. So I can now have a modern workflow leveraging older stuff. And I don’t have to convert the older previous generation workflows for them to still be usable in the modern canvas as well. So again, we just wanted to make this as simple and as easy as possible and visualize each workflow based off of what its original origin is, unless it’s been changed, it’s going to show the original workflow. And if you’ve created a new workflow on the modern canvas, it’s going to visualize it as it’s run in the new modern visualization.

Rich Martin • 28:35

With that, that is a lot of the highlights of the demo. Again, there’s a lot of other things like hotkeys that we won’t get into every single hotkey. But one of the things that is critical to understand there is the more you’re in the system, the more you’ll learn. But these were definitely the bigger parts of the system and the updates that we’ve done. With that, let’s finish off. I promised you that this was an introduction into a series, and what is that series? Well, that series is I’ve introduced you to this new canvas.

Rich Martin • 29:09

Now that series is we’re going to walk through building a network automation workflow step-by-step, including integrations, pre-checks, post-checks. We’re gonna do it entirely in the new canvas. And at the very end of this five-part series of which this is the introduction, so technically six parts, you’re going to have an incredibly deep understanding of how this works. And if you’re already an existing customer, how to use the new canvas to your greatest advantage. So we’re really excited about sharing that with you, and that’ll be kicking off next week, I believe. And it will run through all parts, all five parts here. And with that, I want to say thank you very much.

Rich Martin • 29:48

Appreciate the time. And once again, we are looking forward to upcoming webinars with you.

Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. In today’s webinar, we will be continuing in Part 2 of our series on building network automations, and we will cover adding pre-checks, post-checks, and evaluations to the workflow that we started in Part 1. As a reminder of the series overview, we’ve done an intro in part 1, so the intro gives you this new overview of the workflow Canvas features that we’ll be leveraging in this series. Part 1, we laid out the foundations of our workflow. We created logical steps using stubs, and actually we started filling that out. We actually made a network change, talked about CLI and API, and just basically the overall logic and how to start building your use case in an automated workflow. Today, we’re going to add on to that.

Rich Martin • 00:53

We’re going to add pre-checks, post-checks, and evaluations. This is a standard part of your process, whether you’re doing things manually or you’re starting to go from manual to automated. You want to create pre-checks and post-checks, especially before you make changes and after you make changes, to ensure that the state of the network is ready for the change, and then you make the change, and then everything that you anticipate would occur. Everything that was up before is still up after the change, and then the new thing that you’ve created is working as well. That’s what we’re going to focus on today. Then going forward from that, and we’ll talk about some of these as well. We’ll touch a little bit about part 3 on integration and data transformation at the end of this webinar, but that and modularization, and then publishing and sharing are upcoming.

Rich Martin • 01:38

For today’s demo overview, these are the main things that we’re going to hit upon today. We’re going to create pre-check and post-check tasks or processes, tasks as part of a process using command templates as a building block. We’ll talk about how you can extend that to utilize other things if you want, but this gives you again the foundations of building an automated workflow on our platform. We’re going to query and use evaluation tasks with these command template outputs for path control. How do you determine if something was successful or if something failed? Then how do you change the execution of the workflow to respond to those statuses from each task? We’ll start implementing those and talk through that.

Rich Martin • 02:24

Of course, during this whole process, we’re doing this live and we’re going to run and test and iterate. Then at the very end of it, we’ll bring in some concepts on how to add external systems because for the most part, we’ve been using internal calls, but external system calls as tasks for things like Netbox, Infoblox, ServiceNow. This is where we got started last time or we ended last time. Let me zoom in a little bit, but you can see the whole workflow that we’re working with here. This is from session 1, so part 1 rather. Let me zoom in a little bit. Let’s just very quickly give you an overview if you missed part 1.

Rich Martin • 03:05

We started building this out with what we call stub tasks, which are just placeholder tasks that allow us to at least get our logic out. Then we started replacing some of those tasks with actual executable steps in a workflow. We started with getting input from a user at this first step. We stubbed out querying inventory. This goes into our next session. We’ll talk a little bit about that at the end, but this is integrating all those IT systems that might be part of the process. We did a data transformation, which takes the input that we got from the user and translates it, transforms it, if you will, or manipulates that data in a way that can be used on a later task.

Rich Martin • 03:44

In this case, it’s making a change to a Cisco device. But before we get there, we also stubbed out something for opening up a ticket, which tends to be part of a process of making network changes. But here’s where we’re going to focus on. We’re going to update this stub task, which is really doing nothing, just a placeholder to a real pre-check process before we make the network change, and then the post-check process, and then eventually this would close out the ticket. We’ll get to that in a later session. But these are the ones we’re focusing on today, the pre-check process, the post-check process. Before we get started, I’m going to just duplicate this workflow so I can keep the original.

Rich Martin • 04:31

There we go. Now, let me pop back up my task palette here. Again, if I double-click this, we’ve covered this. This is how you look at the variables within a particular task. This opens everything up. Let’s zoom in. If I hit nine, gives me the full view, but if I hit zero, that’s my hotkey for zooming in, and we can take a look at this pre-check process. Your pre-check process can be, it’s going to depend on, what is it going to look like? It’s going to depend on the nature of the change you’re making. If you’re making a lot of changes relative to something that to a ticket that’s come in, maybe a new service or something like that.

Rich Martin • 05:11

You might have many steps, even across many different devices, or it could be through two IT systems. You could be talking to your monitoring system or something like that. You might be looking at inventory system. Whatever it may be, that may be part of the pre-check process. This could be one step or multiple steps. Now, I’m going to simplify it and show you a feature that we have in our platform to make it easy to get started, especially this is specifically for CLI devices when you’re automating CLI devices. We’re automating a Cisco device here, CLI driven.

Rich Martin • 05:42

We’re actually pushing CLI config to it. That’s why I have this here. You can see that in our previous session. We made a Cisco CLI. We’re pushing the commands through the transformation. So this transformation builds the set of CLI commands that get executed here on a particular device. Because of that, we want to use a CLI process in order to do the pre-check and then the post-check. And so that feature in our platform is called Command Templates.

Rich Martin • 06:12

And it’s available here on this side of Automation Studio. And again, this is Automation Studio. This is where we’re building our workflow in a drag and drop low-code canvas. So we’re going to create a new Command Template here. And I’m just going to preserve this and go to a new tab where I have Automation Studio loaded up without any automations, just so I can quickly flip back and forth for the sake of time. So if I hit up here, I can create a new element. And in this case, I want to create a Command Template.

Rich Martin • 06:43

And I’m going to call this, we’ll build to pre-check. It’s going to take us to another section here of the platform where we can now start to institute CLI commands on a device. to take a look at the state of the network, the state of the configuration, whatever it is that we want to do. And again, this is something that we’ve built within our platform to make it super simple and really easy for network engineers to start translating some of that, you know, built-in network intelligence that’s in your head, because you almost instinctively know what to look for. I want to execute this show command on the CLI before I make a network change. So depending on the nature of the change, you kind of already know. And maybe this is already documented, which makes it super easy.

Rich Martin • 07:41

So if you’ve got a document, like a mop document or something like that, you can literally just translate. But I could sit next to a network engineer or and have the network engineer drive and build these command templates, which is the whole point of them. So commands template starts with questions like, what is the state we’re looking for before I configure this, make this configuration change? In this case, before I configure this new interface, that’s what we’re making the change on in the device, which we’re gonna configure a loopback interface, but it could be any kind of interface, right? What kind of CLI commands would I execute at the command line in order to be able to determine the correct state? And that’s where we start here. So in this case, if I’m going to create a new interface, that I would probably log in first and just check out to see if the interface exists.

Rich Martin • 08:33

So on a Cisco device, I could do a show interface and we’re protesting here, we’re using loopback 301. Oops, 301. And so we have the command we want to look at. Now we just need to tell it a device. And since we have a federated inventory and the device we’re testing off of in this series is this one right here, which is a Cisco iOS device. That have everything I need to test now. Now here’s the interesting thing.

Rich Martin • 09:01

What is the state of the device and interface loopback 301 based off of what I did in the last session? Well, it should exist, but since this is my lab environment, maybe somebody deleted it, maybe got reset. Don’t know. This is precisely why we have prechecks. So the idea here is before I make a change to loopback 301, should there be anything on there? Should it be configured at all? So this is a great example of that.

Rich Martin • 09:30

I’m kind of unsure what that looks like in my test environment, but in a production environment, we want to make sure. So if I click test this command, it’s gonna execute the command in real time and give us the… the results from the show command and this should look very familiar to a lot of you. If I did this on the command line, this is precisely what I would get. I would get all this. Now, what’s interesting here is this is telling me that that interface is up. If I was assuming that should be a net new interface and nothing should be on it, This would cause me some concern, maybe, whoa, hold on, I’m expecting for this interface to not be up, and clearly there’s something on it because the interface is up, the protocol is up, and there’s an IP address on it.

Rich Martin • 10:16

This is a perfect example of why we want to create pre-checks, and now I’m going to show you how to do this. The command that you would execute is the first step. The second step is, how do I determine if it’s in the right state? In the case here, since we can test within this application or this part of the platform, this command template, we can test right here. I can see in real-time what the output would be. I don’t have to guess, I don’t have to look at scroll back buffers from something. I can literally just take a look at it.

Rich Martin • 10:47

I’m looking for this. If this shows up, and maybe I just look at this because now I can make this more dynamic instead of saying loopback 301. I can literally just search for is up, line protocol is up, this text. I can copy it and paste it here under the rules. Now I can start to build out the command set and what I’m looking for in the output of that command. Now I can start to apply some rules here. It must contain this, it doesn’t contain that. We can do regular expressions and different comparisons.

Rich Martin • 11:20

The simplest case to get started is, does it contain this or does it not contain this? We won’t go too deep into command templates. We’ve done similar webinars around specific command templates in the past, but you can use variables in command templates. We can make this truly dynamic by variablizing the interface and replacing that with a variable, and then passing a variable into the command template from a workflow. But for the case of simplifying it, we’re just going to keep it like this. Now if I test this command, What I’m saying is, show me the output of this command, and if it contains this is up, it will pass, is what it’s saying.

Rich Martin • 11:57

We’re ultimately getting to a pass or fail type situation. Let me test this, and you’ll see the results here are pass, and we see a green check there. There’s your visual reminder. Now, if I take this, and I say if it doesn’t contain this, I can invert. And so now, because this interface actually exists, and I’m looking for it. to not contain this information, which means it doesn’t exist, then it fails. Now we have our two conditions.

Rich Martin • 12:31

If I’m doing a pre-check and I’m about to create and configure an interface, I want the interface to not be in use, especially if this is something net new. My inventory system, if we were going to use an inventory system, might think, hey, this loopback 301 is the next one in the series. It’s not supposed to be in use, but then I actually go to the network, where I’m doing here in a pre-check and it’s actually in use, I should probably not make any changes at that point and investigate further why this is configured, what’s it being used for. In this case, the description is test. Is it okay to delete? But in any way, we want to set up a pass or fail situation.

Rich Martin • 13:15

Something as simple as this gives us that ability to sit down with a network engineer and say, what is the command? What are you looking for? Let’s set up some rules. Now we have an asset that we can use in our automation as a very simple pre-check. Now I say it’s simple, but in reality, I could take the same command and parse the output with more rules. We could take a look at the description, and I can create a rule here that say, must contain something in the description or regular expression in the description. Or I could check the IP address, and we can create another rule that says, in the IP address must look like this, or must be this, or maybe doesn’t contain this.

Rich Martin • 13:55

Now we can start to build even more complex rules. We’ll keep it simple here, but also you can create a whole other command. Now I can execute a second command on the device as well. Maybe I’m going to not show the interface, maybe I’m going to show the routing table or something like that, and I can have another set of rules. For all of these rules, you have the ability to choose that all rules must pass, one rule must pass for commands, or for all of the commands. Up here, it gives you the ability to determine the contingency of these rules. It starts off very, very simple.

Rich Martin • 14:32

but it can get very complex depending on your needs. This is just one thing you can do in a pre-check or a post-check. There are a lot of other things you can do. Like I said earlier, you could go into a whole other IT system monitoring or something like that, and do a query for a specific network state or something like that. That could be part of your pre-check and your post-check. But again, just to keep it simple, this is really giving us on creating some net new interface, we should probably say it shouldn’t already exist. In this case, it shouldn’t create this contain something that’s configured allowing it to be up, both the interface and the line protocols up.

Rich Martin • 15:18

This makes a perfect example for that. Let’s save this as our pre-check. Now, if we were going to do a post-check after we make the change, then the post-check should actually contain is up and line protocol is up. So we can make a copy of this. We’ll do and we’ll just call it build to post-check. Save that. Timeout again. No worries, we’ll just create a new one. How about that?

Rich Martin • 15:54

Create command template. As quickly as it did before, show interface, back 301, do our test. We have a federated inventory so it can quickly give me the correct name. Then if I test this command, There’s our results. I can go into here, paste that in, and then change the rules. No, it actually should contain this because this is the post-check.

Rich Martin • 16:40

So we created the interface. Now the interface ought to be up and the line protocol should be up as well. Then that would be a pass condition. Since that interface does actually exist as a result of our last session, then this would pass. So there’s our green check and there’s our pass. We’ve created our pre-check and our post-check right there, just as quickly as that. Again, you can make it as complex as you need to.

Rich Martin • 17:04

But for our case, just simplifying things, that’s pretty straightforward. So let’s roll back over to our workflow. Now let’s start removing these sub-tasks and let’s start replacing them with the command template. So we created that asset in the Automation Studio. command templates. So they exist here, but now we want to put them into the workflow. So every workflow task is accessible through the palette here, the task palette.

Rich Martin • 17:35

So the internal command to do that is simply run command template. This is part of our mop section, so methods and operations. So if I drop this into here, this allows us to execute what we just created. And of course, I’m going to now, well, I could do this. I can delete and merge this so that it keeps our line and then I could drop it right on there. And now we’ve created this. So if I double click this, this opens up the variable.

Rich Martin • 18:06

So every task is gonna have a set of variables. Some of them are gonna be required for the task to execute. In this case, we need the name of the template that we just created. So this is webinar build to pre-check. And really that’s all we need for here. The, some of the other variables we can create, I talked about it being, you could create variables so we can pass variables here. And in this case, we’re not using variables in that command template.

Rich Martin • 18:36

So there’s no need to pass variables. So this is an empty object. There’s nothing in it. Yeah, we do need the device. In this case, since we’re statically assigning everything, we want to use the device that we’ve been testing on. So this is here. So let me put the device in here.

Rich Martin • 19:04

And actually, I think if I go back to task, remember every variable can be statically assigned, but it can also use variables that have been created as an output of a previous task, in this case, a transformation. So I’m remembering back to our last session where we did the transformation, this is called build a workflow one transformation. If I click on it, we did create a variable called host name. So I could have statically assigned it there, but let’s just leverage that since we’ve already created it. Again, this is probably best practice to do something like this because your workflows need to be used dynamically across multiple environments, different devices, things like that. Ultimately, when you’re testing, you probably wanna test it in your lab or in a subset of devices, but then as you go forward, you want to make this workflow reusable across different devices, those kinds of things. So we’re gonna use a variable from this transformation here.

Rich Martin • 19:59

So that’s saved. Let’s see. Well, one thing we can do that’s probably a good practice here is call this pre-check process. Whoops. Change the name of it. And so that gives us the new name there that makes it helpful to understand. And now the cool thing is I could take this, I can copy it, and I can paste it in here.

Rich Martin • 20:32

And now here’s our post-check process, because we’re going to run a command template. Now we’re going to run a different command template, but we’re still going to run a command template nonetheless. So I can delete and merge this and drop this right onto the transition line here. And now we’ve created this. And so we do make a change here because this is going to be a different command template we want to run. Remember, the difference between the two, they’re executing the same command, but one should not contain the is up, protocol is up, and the other one should contain is up, protocol is up. So we’ll save that here.

Rich Martin • 21:07

And so now we’ve just removed those stub tasks that we stubbed out from our last session. We’ve created actual runnable tasks here. So we should probably save this and give it a run. Let’s run it and let’s take a look. So if I click here, that gives me the ability to run it more in a testing mode. When these are exposed in our final session, you’re gonna see that we’re not really, you know, executing the workflow here is really for testing and building for the network automation engineer. But when you’re exposing it to the team to be used, you know, kind of in a self-service way, there are other methods of running the workflow, but for testing, it’s useful for doing it here because we’re gonna iterate and make changes all the time.

Rich Martin • 21:55

So our first step, as I talked about earlier, is to get some input from a user. So that’s us, we’re gonna be the user here. So I want to get to this task. This is a flow of the task kind of in a text form, but it allows me to now work this task, which is a form. It stops the workflow because it’s asking for the user to input some information. This is where we do the variable for that. And I’m just gonna do test.

Rich Martin • 22:24

I’m going to go ahead and do a little bit of a seminar here. Confirm. This will move the task forward. You’ll see that it did the transformation. Of course, this is stub. Now, the first thing here is that this is the net new thing that we’ve added. So we’ve seen that we run command template here.

Rich Martin • 22:40

So this is the command template we’ve created. I’m going to double-click it, and I’m going to expand it a bit so we can take a look at what’s going on. You’ll notice this is the incoming variable. So I double-click this. This is the task pre-check process. This is the one we just inserted in. This is the data.

Rich Martin • 22:57

When I double-click the task and entered the variables, these are the variables that we entered. The webinar, this is the template that it’s going to run. Remember the variables I said we don’t need to input any variables, so it’s an empty object. And then this is the devices. This came from, not statically, but from this task here, this output, this variable, and now we’re inputting it here. And so when this task runs, we have a set of outgoing variables. Notice here that the output of this run command template process gives us a lot of data, like a lot of data, right?

Rich Martin • 23:31

Probably more data than we need. What we really want to find out was, what is the ultimate result of the rules? In fact, this is just one rule here, but what is the ultimate result? False, which means it’s a fail, right? And so why did it fail? Because remember, that interface already exists. So it failed and gave us the result of failing here, which is important because that’s how we understand when we create our evaluation step, which is what we’re about to do now, understanding how to capture that result data and then how to create pathing to respond to that.

Rich Martin • 24:08

So we want to understand when this task executes, how do I know, what to look for because it’s executed this command. And then the task is saying, well, this was a fail because that interface did exist. And this is not a surprise to us because we knew that going into this because of our testing. So now if I go to the run template here, so this is the, I need to rename it to post-check. I forgot to do that, but I’ll rename it in a minute when we go back to the workflow. Notice the result was true because here’s the rule.

Rich Martin • 24:37

The rule was, you know, show that interface and I’m looking for is up, line protocol is up. And that’s true, that resulted in true. So that’s good. So what we’ve just done is we’ve executed it, but we haven’t done any kind of evaluation to change the paths. So when I delete that, if I were to delete that interface and go back to the pre-check and run it again, it would pass through, it would say the result was true. And then it would create the interface. So if we look at the create step here, so in between the pre-check and the post-check, it also has a lot of data before it makes this change, a lot of data.

Rich Martin • 25:13

But what we really want to do is look for the ultimate results. And you might need to do a little deep digging, both into here and maybe into some of the documentation. In this case, we’re looking for the results. Sometimes it’s useful to like collapse some of the output so you can find the results that you’re looking for in the JSON. So in this case, the results we’re looking for is the status success, right? So this means that the execution of that command was a success. Because we’re going to get to that in a minute, but every task can have some sort of output at a result that you can now evaluate.

Rich Martin • 25:46

So let’s focus on evaluating the pre-check process. So let’s go back to Automation Studio. And I said I was going to update this name. This is after the change. So now I’m going to update this to post check. So I copied it, but I should have updated the name. Now we’ve updated it.

Rich Martin • 26:05

Now, let’s focus our attention on the command template here for the pre-check process. So what we want to do is we want to evaluate the output and look at that result variable. In order to do that, one of the built-in commands we have here is called Evaluate or Evaluation. And if I bring that onto the canvas, this is going to give us the ability to do that kind of evaluation. So I can drop it onto here. Maybe I make a little room for it. We can kind of resize everything in a minute.

Rich Martin • 26:33

But at least this gives us the ability to now take the output of this, run the evaluation task, and then determine if it passed or failed, and then create another subsequent path. If it passed, we continue forward down. If it failed, it needs to do something else because that’s the sign that we were looking for that maybe we shouldn’t execute a change here. So if I double-click on the evaluation, it’s going to ask us, kind of similar to the command templates, it’s looking at very particular evaluations are met. I’m going to click Add Evaluation Group. So again, like the command templates, you can have several forms of evaluation if you need. We’re just going to keep it simple and just evaluate the particular output for this.

Rich Martin • 27:22

So if any of the following are met, if I click on Add Evaluation, so this is my first evaluation, and what it’s asking for is, what am I looking at? What output am I looking at? And in this case, I want to take the output from a task, and particularly the pre-check process task, which is the previous check. So it’s going to automatically fill that in. It’s the previous task to this, so it’s going to fill that in, but I have access to everything before it. I can take that and it automatically says the output variable of this particular task is this, so I’m going to leave it there. But remember, that output variable, if I click back on the operations managers, this is the job that ran, and this is helpful to have up because then I can see the output of what this looks like when it’s run.

Rich Martin • 28:08

Remember, all of that data in MOP template results, this variable, all of this data is now going to be available to that evaluation. Really, we’re only interested in this, this result and determining if it is true or false. If I go back here to the evaluation, we’re going to take that variable, and I want to enable a query because I want to be very specific about what field I’m looking at. In this case, since this is a JSON object, it can do a JSON query and extract just the field that I’m looking at. JSON query is a standard space thing. You can look at a lot of documentation on JSON query. But in this case, I can just type in result and I can double-check here because that’s the name of this that I’m looking at, result, and it appears at the root of this JSON object.

Rich Martin • 29:03

It’s not under something else like command results or anything like that. I’m looking at result, which is the overall result. You could query for results, a result under a particular rule. That would be a little more complex query you could do, but you could certainly do that. All of this data would be available on a query. This is a query task that’s built into the evaluation task to make it somewhat more easy. We actually have another query task that’s a standalone task that you could also use here or something else if you needed to.

Rich Martin • 29:32

But this is a bit of a time-saver here. Now I’m going to say, okay, the result is what I’m looking for in this big variable of results. Just pull out the top-level results, and I want to make sure it contains true. Because in our pre-check, we’re looking for it should not contain the interfaces up, essentially, and line protocol is up. If it doesn’t contain it, then it’s true. But if it’s false, like we just saw when we ran it, because the interface exists, that would be a fail. We’re looking for the true here instead of the false.

Rich Martin • 30:08

That’s it. We’ve created our evaluation. The true task or the past will take us this way. Now, we can create an alternate path here for the failure. If it doesn’t pass, it’s going to fail, and it’s going to come on this way. We can use a stub for this, and I can just copy and paste this here, and I’m going to double-click it, and I’m going to change it to, let’s see, we should call it written, pre-check, failed. And I’m not going to do anything. It’s just a placeholder, right?

Rich Martin • 30:49

And if I double-click this, probably a good idea would be… Did pre-check. Pass. So now we have a little more description if somebody is coming in behind us saying, oh, okay, that’s what that does. Did pre-check pass. Now I’m gonna create a evaluation line here, but notice this is green. This is a pass.

Rich Martin • 31:18

So we don’t wanna do this. If I were to run this this way, then on a pass, it would execute both routes, right? It would, the execution would go to here and to here. And really what we wanna do is on a pass, it should execute this way and on a failure, it should execute this way. So we need to change the transition line type. So I can do a hotkey here. I can change it to failure, or if I wanna right click, I can also change it failure here.

Rich Martin • 31:42

You can also trap for an error. An error means the task had some sort of error. It’s different from failure, but there was an error in executing that. Maybe you didn’t have enough information or something like that. In this case, we’re just testing for the pass fail. So in this case, if the pre-check failed, then it’s gonna run our stub. This is something we could fill out later.

Rich Martin • 32:02

If there was a pre-check, what should we do? We’ll certainly stop execution, certainly not configure anything. Maybe you open up a ticket, maybe you notify an SE or an engineer through the ticket or through Slack or Teams or something like that. This becomes something you could expand later, but we’re now just creating our fail or fallout condition. And from here, I can do a transition to end to kind of bypass all the other stuff. So let’s take a look at that. Let’s save this.

Rich Martin • 32:35

And so now we are gonna do our run command template. It’s gonna evaluate right now, because the interface exists, it should now take this fail path and bypass any new changes here. And so that’s what we’re gonna look for. So now if we run this again, It’s going to take us to Operations Manager. We can take a look at the job as it’s executing here. I’ll zoom in a bit, make it easier to read.

Rich Martin • 33:02

Now, the first step is to get input, so that requires us to work this form. This input is going to be used for the config change and the host name. I’ve put in the network device that we’ve been testing on in the description. I click confirm to move this along. Now it executes the transformation, the update. Here’s your command template. Let’s double-click this.

Rich Martin • 33:33

Let’s expand this so we can take a look at it. This is the incoming, so this is the data we set for the task, but really what we want to see is now that the task is executed, what is the output? Remember, the interface exists, so the result should be false, and it is. Because it’s false, take a look at our pathing now. You see the green check marks, they identify the pathing that everything took. So in this case, it did the evaluation and bypassed the rest of it because our failure condition based off of the evaluation that we did. So now it’s taking our fail-out path.

Rich Martin • 34:07

The pre-check failed. And from there, going to end. So it did bypass everything that we were wanting to do. So that’s pretty cool. Now let’s do this. We can run it one last time and test for the pass condition because that’s probably a good idea. So what I’ll do here is I have off-screen here, I have another automation that will reset that interface.

Rich Martin • 34:33

So let me run that now. I just ran it, it executed, so the interface should be now deleted. So now we should be able to run this again and the evaluation should pass through because it should now see that it meets the conditions of the interface doesn’t exist. So again, if I run this. We’re getting our form. Let’s quickly fill this out. Okay, we’ll select our device.

Rich Martin • 35:07

There we go. up in the description. And now we’ve moved forward. We’re in our run command template process. So it’s executing those CLI commands. The evaluation gets that CLI commands output from that task, pass or fail, true or false, in this case. And then it moved forward to make the change.

Rich Martin • 35:31

So our pre-check passed, in this case, so that it went ahead and made the change and then ran our post-check condition. And we can take a look at that as well. So in this case, it should also be a pass, because now if this command executed correctly, this should also be a pass. So it should have been a pass here, which it was. We’re not doing an evaluation here, but we’ll drop that in in a minute. So let’s take a look at this. So this was also a pass, because the result was true.

Rich Martin • 36:01

So our pre-check and our post-check conditions are now operating as we intended them to be, because we tested it in the command template section of the application. Now we’ve implemented them into the workflow and created at least an evaluation here. And so our next step would be, hey, let’s create an evaluation for other things, right? So if I did a pre-check and I need an evaluation, then I should be able to do a post-check and do an evaluation, and absolutely. So where would that go? It would go, let’s see. It would go here.

Rich Martin • 36:37

So we can do something like this, move this down and make a little space, right? And then if I take this, oops. Copy, I can paste this evaluation. Probably easier to do it this way. So coming off of the iOS config, we want to do… Actually, we want to do it a little bit differently. We’ll do that in a minute.

Rich Martin • 37:07

We’re going to do our evaluation afterwards. So let’s move this up. And now I’ll break this and then pull this in. And then we’ll tidy it up. Okay. And now we’ve got our other evaluation for our post-check. So now I double-click this.

Rich Martin • 37:33

And so what changes do I need to make? Well, obviously, description, probably a good thing. But we also… Let’s take a look at this. So our evaluation is referencing, in this case, since we copied it from here, it’s referencing this previous task, the pre-check task. So we do need to update this to reference the post-check process, because that’s the output that we’re looking for. So this is tied to this one.

Rich Martin • 38:04

The output of this is really what we’re evaluating. Had I not changed that because I copied and pasted it, it would have referenced this and given us a false positive or false negative, perhaps. So if I had pulled this in net new from our task pallet here, it wouldn’t have any of this details in here. So you would have to. put the right information in. But that’s a good tip. You want to make sure you want to double-check your variables to make sure it’s referencing the same variables from the right task here.

Rich Martin • 38:35

So in this case, the query is OK, because the command template, regardless of which one we run, is going to have that result variable. And that’s what we’re looking for. So that would be perfectly fine. And then for this, we could drop that into there. And now that’s our path. And it’s green, because this is a fail path. This is going to succeed.

Rich Martin • 38:56

So this is a path forward. Even if there’s no check, it’s going to take the green path. So this gives us two. And of course, we could do another one here as an example. So should we evaluate the change? Absolutely, we should evaluate the change. So let’s make a little room.

Rich Martin • 39:17

Let’s drop this evaluation in. All right. And we can start to, if your OCD gets to you, you can start to make this look a little prettier. There we go. And with the grid, it makes it real easy. So we’ll space that out a bit. So if I double-click this, obviously, we have to make changes.

Rich Martin • 39:38

Maybe, let’s see. Was config change successful? Now, we want to reference the task previous to that, which was to make the change. We still want to do our query, but since this is not executing a command template, what we’re going to query for is going to be different. How do I find that information? Let’s go back to our Operations Manager. Let’s take a look at the output of the task, the last thing that was successfully run.

Rich Martin • 40:12

If I double-click the change task, we took a look at this a little earlier. I could take a look at this object, and really what I’m looking for is response. Let’s see, I’m looking for, like, response.completed, I think, or response.let’s see, where is it? I had it here, status. So response status is what I believe we’re looking for here. So you would reference that variable as the variable we’re looking for, and you would want to make sure it’s set to success. And so as we were adding more of these in here, this is how you would end up testing and iterating our query, and that should contain, let’s take a look at it again, response, no, sorry, response.status, and that should be success.

Rich Martin • 41:15

So this should be response.status, and then we are looking for it to be success, right? And that will define our path, our green path forward. If it doesn’t reply to that or it doesn’t respond to that after that’s executed, then you would take another failure path out. So I’ll paste that here, and then we’ll do that on the evaluation. So that comes out green by default. We want to turn it to a fail. And then we can also logically drop that back in to here.

Rich Martin • 41:52

And then you can space these out to make it nice and clean. And so this is how you would start to now build out your evaluations, your paths, your checking, your failbacks scenarios. I need to change this. And so we’ve stubbed this out, and as we would continue, we’d figure out, OK, what do I need to do on a pre-check if something went wrong there? What do I need to do on the config change, right? Maybe this is a rollback. Maybe this is a notify.

Rich Martin • 42:27

This is a rollback. And on the post-check, if something happened, depending on the nature of how it happened, you have all the logic and the ability now to start building these out, even if it includes automating or remediating or rolling something back automatically through a workflow, or if it says, hey, I need a human being to take a look at this, what are the steps and processes to do that? So you have all of that available to you here. And so hopefully that lays the foundation of now how you can start to not only stub this out, but start task by task going through, testing, iterating, understanding how a task runs, feeding it the right variables, and then seeing the output of it so that you can now build evaluations as needed as part of the logic of what you’re going to do. And obviously, the pre-check and the post-check is the most standard that every network engineer does, even if it’s inside their head. So finally, we’ll set up for our next session where we’re going to take a look at some of these other stub tasks that need to be updated. So in our next session, we’ll talk about integrations and data transformation.

Rich Martin • 43:32

We’ll take a little deeper dive here. So something like this stub task, right? There are other IT systems out there. Maybe you have NetBox, right? And we can do something with IP address management. Or maybe you have Infoblox, right? And you want to pull a task here for maybe inventory or DNS or something like that, or for these change request tickets, right?

Rich Martin • 43:56

Maybe you have ServiceNow or JIRA and you want to now use these tasks. These are the IT systems that are external even to the network. We’ve been building things with more internal or tasks that are part of the platform itself. Now we’re going to start building these steps with external systems in our next session. I’m going to show you how to do that because we normalize it. It’s basically what I’ve showed you here. But how do you bring those systems in so that they appear in the task palette here?

Rich Martin • 44:27

We’ll go through and talk about that, and then we’ll start to rebuild some of these steps so that we actually have live calls into those. I want to thank you so much for joining us. We look forward to our next session where we will continue. I laid the groundwork here for what we’re going to do next with integrations, but I look forward to that next session where we can start to put those pieces of the puzzle together and continue learning. Thank you very much.

Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. My name is Rich Martin, Director of Technical Marketing here at Itential. Today, we’re in part 3 of our ongoing series on building network automations. We are going to focus on integration and data transformation, two really important aspects of building your automation, not just with Itential, but also really if you’re going to build automations in general, these are things you have to really address and take a look at. That’s where we’re currently at today. We’ve covered some more foundational things, and we’re moving forward in our automation as we’re building an automation out. Upcoming, we are going to be talking a little bit about module automation library in our next series, and eventually finishing up with publishing and sharing automations.

Rich Martin • 00:46

For today’s demo overview, we are going to take a look at how to do an integration in our platform. We make it super easy using a specification file, ideally OpenAPI or Swagger spec, but we also support Postman collection. We’re going to target Netbox for this because they have an excellent API implementation and you’re going to probably need some source of truth in your network automation that’s usually part of the process. What we’ve done is we’ve stubbed that out and so we’re going to take a look at how we can now implement that in our automation today. Eventually, we are going to be integrating things like ServiceNow and Teams into this automation, but the process is what I want to get through to you in this session. Because the process is going to be very, very similar for anything that you want to integrate into the system and things you want to use to put into your automation. We’ll focus on Netbox, but rest assured, we will definitely get to these other ones.

Rich Martin • 01:49

as they fit into the sessions. We’re also going to use the, so once we’ve integrated Netbox, we’re going to use these API tasks for something very similar like IP address requests. Again, this is an example, you could definitely do anything that’s available to API, including querying data center infrastructure or anything like that. Big part of this is data transformation. How you take data from one API call or one API task, receive it, and format it, manipulate it. In some case, just map it straight through. You could do that too, but it occurs in a task, we call it data transformation task.

Rich Martin • 02:32

You’ll see how flexible, but also how important it is that you spend time understanding data transformation. It’s awesome because in our previous session, we did a lot of that. We did some data transformation, but we’ll spend a little more time on that today. Then eventually, as we’re iterating through this process to build, to run, to test through an area of our application called Operations Manager. With that, let me share my screen and we will continue on. Okay, so let’s start with creating an integration in our platform. With our platform under Admin Essentials, this is where a lot of the administration tasks occur or show up in our platform.

Rich Martin • 03:12

Really what we want to do is we want to take a look at a couple of things here, adapters, integrations, and integration models. We’ll start with adapters. In our platform, you can download some pre-built adapters that we have in our library. They’re freely available. In fact, we have some for NetBox. These are a form of integration that we provide to our users, and you can freely download them and use them in the platform, like I said, and they will integrate into whatever IT system or a network controller or whatever that adapter is for. And that’s very powerful and that’s very useful, but really what we want to focus in on is an integration.

Rich Martin • 03:48

So that’s a different type of way to connect to your systems. In this case, it allows you, the end user, the customer, to generate your own integration into a system on your own. So let me repeat that again. Instead of relying on a vendor like us to create an integration into a system that’s part of your ecosystem that you would like to automate across or against or with, you don’t have to wait for us to create that integration. You can generate it yourself using an API specification file that that particular vendor provides. Ideally, if they’re using something like a Swagger spec or an OpenAPI file to document their API, we can take that file in, ingest it into the system and immediately generate, or you can immediately generate an integration and start using that today.

Rich Martin • 04:43

That’s incredibly valuable and incredibly flexible for you, and it’s quite honestly a lot different from probably what you’re used to. That’s what I want to show you today. The first step of that is I can import that particular file and create an integration model. The integration model is built based off of, like I said, a specification file. One of the things I’ve pulled down is a NetBox 3.3, OpenAPI specification file. It’s a JSON format. It’s freely available.

Rich Martin • 05:14

If you’ve already running NetBox, you can access it through their API documentation in your installation. If you do a couple of Google searches, you’ll find it. We’re seeing more and more providers providing OpenAPI documentation or Swagger spec in a JSON format. Once you have that, literally, I just dropped it into here. If I validate, we can just ensure, because it’s in a JSON format, where this import wizard is going to validate that. At the very least, the integration model is a valid JSON. With that, I just click Import.

Rich Martin • 05:49

Now it’s going to go and create an integration model for me. With that, inside of that JSON file, that API documentation, it defines all of the API endpoints that are published in this particular API file. Now, here’s the great thing. This is NetBox API 3.3. They probably have a later version. This allows you to go and grab that later version. Maybe you want to set that up.

Rich Martin • 06:17

If you’re looking at it, you can set up your lab and you can even create another integration to the later version of this application and run them both concurrently. I’ll show you what that looks like in a moment. But just for the case of example here, this is what we’ve done. The first step is to create the integration model. This gives us the ability now to take a look at the way the API is laid out. It’s going to be different per vendor. They’re going to have different things, but Netbox does a great job.

Rich Martin • 06:43

You get to see pretty quickly how they’ve categorized the different features and functions and laid that into their API files or their API endpoints. So, and this is helpful. I would recommend if you’re going to get into automation is to learn to read these kind of the API documentations and also how to use the application if possible so that you can kind of see how all of this fits together. So, in our example today, really, we want to request an IP address. That would probably fall under IP address management here and it actually does. But this allows you to now from here, just in this first step, to see what’s all being published and how they’ve categorized it. So, if I wanted to do something and like query some sort of part of the inventory, it would probably be under data center DCIM, data center inventory management or infrastructure management.

Rich Martin • 07:35

And so, I can click into that and take a look at these files. So, you could, or these endpoints. So, you could take a, you know, you could take some time and investigate the API documentation. So, if I go with the IPAM, let’s take a closer look at this. So, because now you can kind of see. how the URL endpoints are laid out, gives you some idea of the organization. You see get, post, put, patch, delete.

Rich Martin • 07:56

These things will all be covered in their actual API online documentation. You can see how all of this is laid out and what their expectation of values are. But it also gives you an idea of what you can automate even at this first step, because all of these are going to be available inside of all these API endpoint calls are going to be available inside of the Automation Studio Canvas, so that you can start to utilize these. What we’re looking for is IP address. how do we get a new IP and I’ll give it a shortcut. It’s really going to be under IPAM prefixes, ID, available IPs in the post call is what allows us to request an IP and even set up some variables so that we can identify it, maybe set a description and a status. That’s what we want to do.

Rich Martin • 08:44

If I click this down arrow, you’ll see that from that API spec file that we just imported, it’s defining the values that are required here for this particular call to run. We have an ID and then a request body. Because this is all laid out inside of that, this is what you’ll start to see inside when we start to automate this and we pull the task that’s associated with this inside of the canvas. You’ll see that these fields are what are represented, and this is all coming from that spec file. This is why this is so powerful, is it allows you to go in here and based off of the ecosystem you have, and the fact that hopefully a vendor has published this to go and quickly do an integration. This is a model. If I click here on integration, now I can instantiate a version of this and it’s for test.

Rich Martin • 09:38

Give it a name. I selected the integration model that we’ve created. If I just save it, it’s now, we’ve created integration model and now an instantiation. From here, all I would need to do is fill this out to the right protocol host port depending on how it’s deployed on your network and then your authentication information, and now the system would have access to those API endpoints. This allows us to basically act like a super user. As I’m building automations, I’m just leveraging the APIs that are available, which are usually also tied to the front-end management for that application too. We’ll take a look at that in a minute, but that’s really the gist of it.

Rich Martin • 10:22

That quickly you can generate an integration model and an integration and bring all of these different systems in your environment, integrate it into the automation platform. Now you can start leveraging those APIs to automate, not just network tasks, but all of the tasks that are part of the process that support it before you even make the network. In this case, it’s gathering data, grabbing IP addresses, things like that, querying for inventory. Okay, so now let’s transition over to Automation Studio. This is where you actually build automations. And if this looks familiar, that means you paid attention to our previous episode where we’ve built this out. And so I just wanna go through it.

Rich Martin • 11:09

So what we’ve been doing just as a process now is we started off with a little bit of code. Using these stub tasks, they’re just placeholders. It helps us to whiteboard it, if you will, what all the different steps are as we’re building an automation. In this case, we’re making a network change to a CLI-driven device, a Cisco router. We put some pre-checks and post-checks in, we did some evaluations. That’s awesome. Now, we’re asking the question, in order to make a network change, or in this case, I’m bringing up a new interface, a lot of times you need a unique IP address, right? I need to gather data from some source, and that’s what we’re gonna take a look at today.

Rich Martin • 11:47

We’re gonna take a look at this step right here, querying inventory. I need, what is the inventory of IP addresses for this? And how do I access it? And then how do I leverage that API call into Netbox so that I can pass it on so that it ends up here as part of a set of configuration changes that I’m gonna push to a network device? So this is what we’ll focus on here. We’ll return to that in a moment. But for now, I’m gonna go back to this tab where we can go back into Automation Studio, and now we can create a new workflow.

Rich Martin • 12:22

And so this is the first step in kind of building that out. I would probably go ahead and create a net new automation here. I’m gonna give it the name. I’m gonna create a workflow. I’m gonna give it the name Builder Workflow 3 Netbox. Then of course, we get our start and end, and then our task list here. Now, remember a moment ago, we went back into when we onboarded the NetBox integration.

Rich Martin • 12:52

We had access to all those API calls, and the one I wanted to point out was how to grab an IP address. Again, you probably need to spend some time looking at API documentation just to understand, like I said, the format, how it’s laid out. There’s a logical format for these. But just to save some time, that particular task that I pointed out was a post, and it was IPAM prefixes ID available IPs. I know that’s a mouthful, but if I go down here to, well, let’s just go down to NetBox, this is our task palette. As we onboard different systems, whether they’re network systems or IT systems, whatever it may be, all of those API endpoints become available through here.

Rich Martin • 13:43

Under NetBox, this is all the things we looked at in the API documentation we integrated. This becomes useful here. This is already an existing one because it’s tied into our lab system but the API calls are all there. What we want to do is we want to find the API call that correlates to requesting an IP address, not just asking or getting or querying for an IP address, but actually requesting for it. It was that post version of the IPAM prefixes ID available IPs. If I go post IPAM prefixes, You’ll see that we have a couple here.

Rich Martin • 14:25

If I hover over this, I want the one that says available IPs at the end. Yeah, this is the one. They’re slightly different. You’ll notice when I did a hover, you’ll see some documentation that comes again from the spec file. I’m going to drag that here. I’m going to make this small. Since we’re just testing this step, we just want to test to make sure it works the way we want it to work. Before I merge it into the bigger workflow, it’s always good to test these individual elements and understand how they work. That first part was looking at the API documentation.

Rich Martin • 14:58

Remember, it had some required variables. I’ll zoom into this a little bit. Now that I’ve dropped that into here, build my transitions, just like that. And when I double click on this task or any task for that matter, you’ll see the variables that are required for it to run, or at least that it’s requesting and ideally run and run successfully to execute that task. Remember when we looked from the API documentation, when we first imported it and created an integration model, there was an ID, gives us a little description here, a unique integer value identifying this prefix. And then there’s a data object here.

Rich Martin • 15:37

So where does this information come from? Well, if I put the number 32 in here, that like, how did you pull that out of the air? Well, let me show you. And this is why it’s so valuable to understand if possible, to understand how this particular system works. So you can correlate the API call to how this is actually being done inside the system, maybe where this data comes from inside the actual system, like the console or the dashboard. So let me show you. So I’m specifying value 32 for this ID.

Rich Martin • 16:08

And where that comes from is here’s the net box that I’m going to be integrating into. And I’ve gone under prefixes here just to list all of the prefixes. So in this case, I want to make sure that the IP address assigned is assigned in a certain prefix because maybe this is a part of the data center and this is what’s being used. So just for testing purposes, we’ve set this up in the past. So I’m going to use this particular prefix here. So I want to assign an IP address from this prefix, 10.48.132. and click under IP addresses, we can see what’s already been assigned.

Rich Martin • 16:43

We should get the next one, assuming we get the next one here, when it’s served through the API call, so it should be 11. But note up here, IPAM prefixes, and we get the number 32. This is the unique internal to NetBox prefix ID that is assigned to this one. If I wanted to select a different prefix, I would go to that and I would navigate to that, and I’d find that prefix too. There are other ways to find it, but if you’ve got access to the dashboard, this is probably the easiest way, because you can say, okay, yes, this is the prefix that is assigned to this particular part of the network, and this is the right prefix to use. So I would use 32 here, that’s where that comes from. So that’s why I put that here.

Rich Martin • 17:21

Now, let me paste this data object in, and now this is where you would spend a little more time trying to understand what is acceptable to pass to this API call. Here, I’m filling this in. Notice, so notice this was a number, this is the required type. We talked about types last time. So I gave it a value of 32, because it’s a number, we are only going to accept numbers here. We want to make sure it’s a number, and we can go up and down from there, or you can type it in directly. 32 is here.

Rich Martin • 17:53

In this case, data is required, and it’s an object. So when it’s an object, it’s going to be expressed as a JSON object. JSON object is identified with the curly braces open and closed. And in this case, I’m putting in some values here. Status is active. Remember our keys and our values. So the key status, the value active, the key description, and then webinar build a workflow test.

Rich Martin • 18:17

I’ve, where did I find that from? Well, that came again, this is where it helps to spend some time in the API documentation that Netbox publishes, and they’ll describe these fields and what’s valid for them. And they have to, and again, they expect it in an object. So we’re gonna pass it in as a JSON object. And I’m statically doing this here, but it can also be done dynamically, but since we’re testing, and in this case, how are we gonna use this status is okay. I mean, static is okay, but in the future, if we’re gonna do something else with this, maybe this becomes modular. Maybe this, we pass these values, or maybe the entire object in from a transformation or from some other source, and we can certainly do that.

Rich Martin • 18:57

But for testing, it’s easier to do it static until we understand how everything works. So where does that come from? Again, API documentation, but to give you a clue, and this isn’t always the case, but to give you a clue, if I go back to the IP addresses, remember, this is going to request a new IP. So when I’m requesting an IP from this particular prefix 32, You also see some statuses that can be set here. And in this case, description and status, role tenant assigned. So that already gives me some hints that for the post, at least, because it’s requesting an object, it’s allowing me to set something.

Rich Martin • 19:30

And in this case, it’s allowing me to set the status as active and the description with the text blurb that I want to set it to. So that’s what’s there. You can’t always make that assumption. You really need to read the API documentation just to ensure because it’ll specify from that vendor’s documentation what they expect those fields to look like, what are acceptable and not acceptable. But in this case, again, it gives you some hints as to, oh, okay, this is how I can set this, or this is available for me to set. So that’s where that comes from. And I always like to cover that so we don’t just pull things out of the air.

Rich Martin • 20:03

So with that being said, that should be good. Now, if I save this, and remember for testing purposes, running from here is kind of helpful. Oh, actually, there is one more thing because I mentioned earlier before I run it. that we can support multiple versions of your IT systems as integrations and adapters. If I click on this again, this is an API call to a NetBox instance, but if I have multiple, which one? In this case, I actually want to go under Advanced. I double-click this task, I go to Advanced.

Rich Martin • 20:36

If I go to Task Options, if there are multiple integrations or adapters, I can select those different systems. I can have a production system, and a lab system, and a dev system, and we can now select it there. Now I’ve pointed it to the right version because we can have multiple of those on here, so you can build automations across those. Again, great to dev or test and then move to production. Now if we save it, and I run. Let’s take a look at what this looks like.

Rich Martin • 21:08

Now we’re in Operations Manager looking at the job itself. You’ve noticed here that it’s already finished. It’s got this. If I double-click this, so this instantiates the automation and it’s one step, but again, we’re testing. It instantiates it and runs it and executes it. When I double-click this, I see the variables that are incoming. These are the variables that were fed into this API task or this API endpoint call to NetBox.

Rich Martin • 21:35

This is what we statically assigned when we double-click that variable in the Automation Studio, this ID, and then this data object active in this description. We did that. That means that that’s the data it used to make the API call into NetBox. If I click here, this is the outgoing. This is all the data that NetBox has returned subsequent to the API call, and there’s a ton of data in here. That’s the point. There’s a lot of data in here, and not all of it may be relevant to what we want to use in our automation. In fact, At least for what we want to do, most of it is not relevant.

Rich Martin • 22:10

The most relevant is this field right here, the address that was returned. You’ll notice 10.48.132.11 slash 24, that’s the address that was returned to us. If I click over back to the NetBox dashboard and if I reload this, this is exactly what happened. That test was successful, I made the successful call in. Not only did it respond back with the next IP here, but it also accepted our object that set the status as active and the description as webinar build workflow test. This gives you an idea, this is how we can iterate. If I wanted to do a query into the datacenter management side of NetBox, you would find that particular task, drag it in.

Rich Martin • 22:55

Let’s take a look at the variables, understand what they relate to, maybe look at the API documentation, maybe look at the application itself, the NetBox console or dashboard of the system, and then start to understand how all of this fits together and ties together. With that, if I go back to here, now we can take this, and remember, this data is being fed back to us as a result from a successful call into the NetBox. It’s got the data we want along with a lot of data that we don’t necessarily need. If I’m going to utilize this IP address to make a change in the network, I need to modify this data in some way so it’s acceptable to the API task that will actually make the network change. In this case, if it’s a CLI command, that certainly doesn’t look like a CLI command that would be acceptable or usable on a Cisco device. We have to do something with this device or with this data, specifically this piece of it, and that’s what the data transformation is all about.

Rich Martin • 24:00

This is what’s so useful. If I go to here, these three buttons, I can copy this whole object here. That’s what I want to do. I want to copy the whole object because now we’re going to work on our data transformation. Because everything around our platform is JSON objects, JSON schemas, things like that, I want to copy this because this is going to be the input for our data transformation. The output of a successful call should be the input of our transformation so that we can extract this, manipulate it any way we want so that it’s usable in a subsequent call in our automation. That’s what we’ll do next. So let me go over to this tab here.

Rich Martin • 24:42

We’ll keep that one in the background for now. And if I go back into Automation Studio, this is also where we would build the transformation. So I can create here, instead of a new workflow, I’m going to create a transformation. We’ll give it the name, basically the same name, because it’s a transformation and not a workflow itself, but at least it already exists. Name it two. So now you’ll see that we have an incoming schema and an outgoing schema. Let me reload this and see if I can get that.

Rich Martin • 25:22

There we go. Now this is our data transformation canvas. It looks similar to the automation canvas, but we’re not building an automation, we’re building a transformation here. We will use this transformation in the workflow in a moment, but we’ll build it and test it from here first. So what we want to do is first create an incoming schema. Every transformation is going to have at least one incoming schema and at least one outgoing schema. However, you could have multiple incoming schemas and multiple outgoing schemas.

Rich Martin • 25:53

That’s perfectly okay. And in some cases, that’s exactly what you would want. In some cases, maybe not. You have that flexibility. So we can create an incoming schema. So this is gonna be a JSON schema that defines the data format that the transformation should expect to get, right? And this is also a form of data validation.

Rich Martin • 26:13

If it doesn’t fit this format, then the transformation says this doesn’t match up and it’s not gonna run. So the best way to ensure that we create the right schema is to infer it from an actual API call. And that’s exactly what we did here. When I copy this, this is the output from an actual API call. We wanna use that as the input here. So if I paste that into the right side, this is the JSON object, the payload that came from that. But if I click infer schema, this is going to turn it back into a JSON schema that defines exactly what we should expect to get data-wise.

Rich Martin • 26:51

And then the cool thing about this is it also preserves any of the values because they become examples. And this is great for testing. So I can call this from netbox. This is data from netbox. So I’m just gonna give it a unique name. And now you’ll see that all of the framework of that data has now appeared here on the left side in the incoming schema. And remember what we really wanted, if I go back to our job that’s finished and run, is I want this value here from this key address and it appears right here at the top under result.

Rich Martin • 27:31

If I go up here and I go into result and I follow this down, you’ll see I get to address here, and we can see it’s defined as a string. I could take that now, and just as an example, I can click on outgoing schema, and it’s going to infer based off of the fact that it’s string, I don’t actually have to fill anything out. If I want to do some direct mapping, if that address string is in the exact format I need it in, I can just map it directly over. I don’t have to do any data manipulation. So I could save this and we could run it. It’s going to show me, so what I’ve done, I haven’t run an automation, this is a testing feature inside data transformation. Because data transformation is incredibly important, even in our platform, but even if you’re writing code, you’re going to take data from an API call and you’re going to manipulate it in some way so that it fits a subsequent API call or some other format that’s required for that data.

Rich Martin • 28:31

It’s the same idea except we’re taking that concept and making it visual, so it’s easier to map and understand. In this case, what we’ve done is we’ve just taken this as it would appear coming from the API call and mapping it over. If a subsequent API call that we used, that we needed an IP address for, required it in this particular format and that exact format, we could take that variable and map it straight over. Remember, this is going to be a task, so when data transformation receives the data from the NetBox API call, in this case, it’s going to extract just the address and make that available to another task as a variable it can use as well. But a lot of times you’ll see that that could be useful sometimes, and a lot of times you’re going to have to make changes to something. And so I always think about two questions. What data do I want?

Rich Martin • 29:25

We answered that here by looking at the output from this call. This is the data that I want. Then when I created the schema, I identified it here, this is the data that I want. But then I have to ask the question, how am I going to use that data? In this case, I want to use that data as a CLI command. Now, that data could also be part of a payload, a JSON payload for another API call. If you’re talking to a network controller to make a change, this would be a little different looking.

Rich Martin • 29:55

But for the sake of as an example, let’s format that as a CLI call. A CLI command so that we can configure an IP address on this interface, and then add that to the list of commands that we push to a particular device. So we can’t use it here, especially if it’s a Cisco iOS device. We need to have this change. We need to have the core of it, the IP address, but we need to have some changes made to this. So in order to do that, we need to do some manipulation, some transformation. And so if I click here, this gives us access to all of these methods.

Rich Martin • 30:33

Now, don’t get overwhelmed by all these methods. A lot of them you’re gonna use over and over and over again, and you can always access documentation to understand what these methods are. I’m gonna delete this for a moment. We kind of already see what that’s about, but let’s make some methods and some modifications to this. So the first thing is, if we want to extract just this part of it from the string, we really need to separate this somehow from the rest of it. And that’s where these methods come into place. So since we’re operating on a string, right?

Rich Martin • 31:10

The address is defined as a string, that’s its type. Then a lot of the operations that we, the methods we want to use may come from here. And in this case, we, one of the things that is really useful is something called split. Now there’s a different, there’s several ways you could do this. And as you start to become familiar with these different methods, you’ll start to understand which ones work well in certain situations, and which ones work well in other situations. The split is nice because you can take a larger string and split it up based off of a character. And so since the Netbox API call is always going to return something that looks like this, with a slash, it’s going to give us the slider notation, and it’s going to have a slash in front of it.

Rich Martin • 31:51

We can do a split and split the string into two different strings. based off of that character right there, the forward slash. And so to do that, I would just drag this into the canvas. And it’s going to give you some parameters. Very similar to a task, I guess you could think of it in that terms. Instead of double-clicking a task and seeing the parameters of the values of the variables it needs, when you drag a task, a method, onto the canvas, it’s going to give you all the required or optional values here, too. So at this point, it’s just a matter of mapping.

Rich Martin • 32:25

So string can map to another string here. That’s valid. It’s not going to allow you to map it to something else that’s not a string, or it’s not acceptable type. So that’s our first parameter. And by the way, on any of these, you can hover over here to get some basic documentation. Or if you click on it, we won’t do it. But if you click on it, you’ll get to a lot more deeper documentation on how this particular method is used.

Rich Martin • 32:48

So in this case, we take the string. So this is the full string. And now we need the separator. So it was the separator, that forward slash. So if I do the forward slash and the limit, we’re not going to use here and notice it’s not required. But you’ll also see that this returns an array. Now, an array is different from a string.

Rich Martin • 33:07

We talked about that type last time. An array is a series of elements. In this case, it’s going to be an array of strings. But let’s take a look at what this looks like. So we did a direct map to address. We saw what it natively looked like coming from that box in our example. So if I click over here and add this, it’s going to say ID, say IP address.

Rich Martin • 33:37

Guess I could have kept it the same. Array, save. Now I can map it over to here. Now I’ll save it, and if we run our test again, now we can take a look at our array output. This is showing the final output of our outgoing schema, if this were to run using that example data. You’ll see this split method now has successfully split that string into two different. strings as part of an array.

Rich Martin • 34:07

So now we’ve got this forward, the first portion here, which is element 0, and then the second portion, which is the CIDR mask of value for the net mask, which is 24. Now, we don’t need 24 for this, but you might need 24 in some other use case. We don’t necessarily need it for this. So we’re just going to take this. Now, if I were going to turn this into a Cisco CLI command to configure an interface, then I certainly will need to add a little more to it. But the first action here is it’s an array, and I really need it as a string. And we know it’s an array.

Rich Martin • 34:40

Remember, of our last session, the array has the square brackets open and close. So how do we access that? So now we get to go up here and use this method called getIndex. So this returns, in this case, a string at the value. So we feed it an array, and then we tell it the index number or the element number that we want to output. And then it will output it, in this case, as a string, because it is a string. So if I click off of that, delete it, and now give the parameter array here to getIndex and give it index 0, because that’s the first value that we want.

Rich Martin • 35:18

Now what I want to do is I want to edit this, and instead of the type array, I’m just going to give it string. I’m going to change the type so that we can match what’s going to come out of this because it’s going to give us a string instead of an array now. I’ll save it, we’ll test it, we’ll run it, and as you can see here, that’s exactly what we’ve got. We’ve gotten the IP address that we need. We’ve done some transformation. It came in as a IP address slash 24. We’ve broken the first part of it out, just the IP address.

Rich Martin • 35:52

We’ve extracted it from the array, now it’s a string. Now if I want to turn it into a CLI command, I have to do something. I have to surround it by interface, or I’m sorry, IP space address, space the IP, and then the net mask. In this case, since it’s a loopback, I’m going to do 255.255.255.255. There’s a couple of ways you could do this. One of those ways is you could use some of these other string methods that are available. But really flexible way to do it, that’s basically a single step is using a template literal.

Rich Martin • 36:30

This allows us to create a custom template. and embed certain variables. We can pass variables into it, and we can embed text before and after it. And it makes it perfect for CLI commands or formatting messages for like Slack or ServiceNow, or if you need to format something for HTML, it allows you to have that kind of flexibility. So when I drag that on here, there’s not a whole lot going on until I click this button. And when I click that button, I’m given basically a free form access here. And so what you do is you type in the text you want, and in this case, I’m going to format it as a CLI command.

Rich Martin • 37:09

that you would type in because we want to push that to an iOS device. So this is the command you would type in from the command line. However, I’m embedding a variable here, and your variables are going to start with a dollar sign, and then the curly and closed brackets along with a name. That name just has to be unique to the template literal. So these are static IP space address space, and then the IP address that we want to use in this template is a variable. And then this part here, which is the net mask and dotted quad is static as well. Now, when I click update, this particular method, the template literal now understands the variable that we assigned as IP, gives it that name.

Rich Martin • 37:52

And so now what I can do is I can feed it into here. So now the actual IP address that we extracted through these first two steps is going to be input into this template. It’s going to be replaced here with the actual IP trust that we got in the right format, and then it should output that as a string. And instead of calling an IP address this time, let’s change the name. Let’s call it iOS command. Now, if we save that and then run this test again, there we go. So we’ve taken the address string and we’ve turned it into a proper CLI-formatted command for a Cisco iOS device that now can be pushed.

Rich Martin • 38:40

And so this is just the data transformation. We’ve just been testing. This isn’t an actual automation. But this gives us the framework to manipulate the data and change it into the format that’s acceptable for an iOS command. So that’s what I mean by, where does the data come from, what is the data that I want, and how am I going to use that data? I’m going to use that data in a format that’s a CLI command. If I was talking to a network controller, right?

Rich Martin • 39:10

I might have to, I would not might, I would definitely need to build another data payload. It may be a JSON object, right? I could use the template literal there for that as well. I could create what looks like a JSON object, save that and output that as a JSON object that could be passed to that network controller API call in my automation. And so this is why this is so important because between two different systems, the data is not gonna be in the right format most likely. And so you’re gonna have to do something to make that data in the right format. And the cool thing is these are reusable.

Rich Martin • 39:46

So anytime I’m doing a likewise function, I’m pulling something, pulling an IP address from NetBox and I need to configure it for a CLI command, this could be used, right? So we can actually use this as a reusable modular asset. So if I click save there, we’ve completed our data transformation. And now let’s go back to our automation. And so we can now attach that into our workflow here. So to do that, I can just type in transformation. This is going to pull up the transformation task, which is part of our platform.

Rich Martin • 40:26

And if I drop it on here, it’ll attach itself. And now I can click on this, and it’s going to ask me for the transformation. We gave it build a workflow 3. Didn’t we call it build a workflow 3? Yeah, I think so. Build a workflow 3 netbox 2. That’s the one.

Rich Martin • 40:50

OK, so when I click on that, it’s saying, OK, here’s the variable that you need to define. Now, where did that come from? From netbox. If I click over here real quick, remember when we created our incoming schema? I called it from netbox, and I pasted in the output from the operations manager call as our live data that we want to use as an example, and we inferred the schema. That’s what it’s asking for. So it understands, now that that transformation has been defined, it understands this is what’s required because we defined that.

Rich Martin • 41:24

Now, where does the data come from? In this case, it needs to come from the task before it. The output of this should be the input of this, and then this should output the correct CLI command for us. That’s the way we’ve done it. If I go to task here, instead of statically assigning it, I go to task here. What I really should have done was I really should have renamed this task because it’s pulling the name from here. But we’ll just leave it here. But that’s the correct task, because it’s the only task that’s in here that can be selected.

Rich Martin • 41:54

I’ll keep it here, I’ll click that, and I’ll double-click this and we’ll just say, Fit IP address. That makes it a nice cleaner. So now the previous task is named get IP address from that box. That makes it easier to understand the previous tasks and the output. So again, that previous tasks output now becomes the input for here. And then on the output side, this is the iOS command that we’ve set. There’s always an error that can be set to for every task if there’s an error in running the command or running the API task.

Rich Martin • 42:35

But in this case, this is what we’ve defined in our data transformation. So this is what we should expect as output. Okay, and with that, we have finished adding the transformation and now we can test it and run it to see it all working together. So if I click run here, and we go into the job manager, you’ll see that the first task, which was the API call to Netbox completed, we could double click that and we can take a look at the variables, most importantly, the outgoing variables. We know what we fed to it. Now we need to see what came out of it. And of course, now we’re seeing an IP address here that was given to us.

Rich Martin • 43:12

And now the key piece of this that we just added is the transformation. So if I double click on that, let’s take a look at the incoming. So remember the outgoing with this is set up to be the incoming of this. That’s what we set up in the transformation task. So you can see the incoming variable map here, that object came from the Netbox call. That’s what we mapped in the workflow task just a moment ago. And then if I click outgoing, so this is the output of the transformation task.

Rich Martin • 43:39

So this is the transformation we built and it’s putting it into the right format. And indeed it has the same IP address as what we received from the NetBox API call. So that’s a good example of how to test and work different, do an integration, how to identify the API task that you’re looking for, how to leverage API documentation, both in our system and of course, external to it from the vendor. And then also how to take a look at the application itself, the dashboard or console that you log into and determine how this all maps and works together. So with that, now we can turn our attention to the following. We can go back to our overall workflow here. And what we’ve normally been doing, let me zoom in a bit so we can take a look.

Rich Martin • 44:30

What we’ve normally been doing is as we’ve created these stub tasks, when we first started this series, we’ve been slowly replacing them with working tasks. So we could do that same thing here. So if I remove this, I can delete and merge this. Let me… Give it some more room. If I open my task palette, recall that the task that we were just been testing is post-iPan prefixes available IP, so that’s what we’ve been doing. I can drag that onto the canvas here and drop it in, give it a little room there, and then the second task we could have is a transformation.

Rich Martin • 45:14

We can drop that in. Then by double-clicking, we could start filling out these variables. It’s like we did in our testing procedure a moment ago. And then we continue to do that for the transformation. But I want to pause here, because every good series has a cliffhanger. And the cliffhanger is this. If you think about what we just did, we could merge this back into our primary workflow, replace that one sub-task with these two tasks that we’ve just been testing across.

Rich Martin • 45:52

But I want you to think about what we’ve done. We’ve created a standalone. It’s two tasks right now, but a standalone function, if you will, that could be usable. in many different environments. Anytime you need an IP address, this simple two-step task, and maybe we can flush it out a little bit, but the simple set of tasks can be an independent workflow. Maybe we need to tweak it a little bit. Maybe instead of statically defining some of the input variables, maybe we create variables that we pass into that.

Rich Martin • 46:22

But the idea here is thinking in terms of modularity. This being able to query and get an IP address from a system, or open a ticket, or send a message to a Slack channel, or a Teams channel. All of these things are going to be done quite often in all kinds of different automations, and as part of a process. And so now you should start thinking about how we can modularize some of these things so we don’t have to go back and recreate all of this. So literally, I’m going back and recreating these steps in a larger workflow. Instead of that, so instead of merging that in like we have been doing, this is a great opportunity to now start to take a look at this and say, this should be a modular task. Maybe we tweak this a little bit.

Rich Martin • 47:04

We go through our testing procedures, we tweak it a little bit, but then we turn it into a standalone workflow that can be run as a child job from within larger workflows. And that is our cliffhanger. We won’t merge this into this until our next episode. And when we do that episode, the focus of that is creating your own modular library, which fits right into this. So in that episode, we will definitely take this, we’ll flush it out a little bit, we’ll turn it into a child job that’s standalone that can now be leveraged not only in this workflow, but many others. And then we will also show you how to leverage some of the modular libraries that you may also create for other systems or may come from our pre-built library as well, and how you can leverage those. And then we’ll end up finishing out the episode.

Rich Martin • 47:55

automation that we’ve been working on in this series. Stay tuned, that’s your cliffhanger. We will merge it in, but we’re going to show you a different way to now merge these changes into this workflow that leverages modularity. I think that’s something that every network engineer and every network engineer that’s working in automation should start thinking about modularity in the sense of, we’ve done it once, this is a repeatable task, let’s leverage it so people don’t have to go through and recreate all of this again. And that way we make building automations even more efficient with our time. And with that, that would conclude our webinar for today. I want to say thank you so much, and again, we look forward to having you on with the next webinar, and where we start to finish this out.

Rich Martin • 48:48

We’ve rounded the corner, and we’re going to finish this out and complete this in the next two episodes of the series. Thank you very much, and I hope you have a great day, great afternoon, or great evening. Bye-bye.

Rich Martin • 00:00

Hello, everyone. Welcome to another Itential webinar. In today’s session, we will be going over building your modular automation library. This is part four in our webinar series. And of course, I am Rich Martin, Director of Technical Marketing at Itential. Like I said, this is the fourth in this series. So technically the fifth, if you have watched the intro, but we have been building on in this series so that we can take kind of logical progression one session at a time, so that we can start to build and understand kind of the fundamentals, the foundations, and start adding to your workflows so that you can end up with an end-to-end workflow that matches your needs and the processes that you are following in your organization.

Rich Martin • 00:46

And so for today’s, I kind of left you at a cliffhanger last time. So for today’s, we’re gonna be talking about building your modular automation library. As we always do, here’s the overview of it. We’re going to continue where we left off before. We’re going to take this workflow that we’ve built. It obviously has some integrations to a network device. This is a Cisco network device.

Rich Martin • 01:09

It’s a CLI-driven device that’s accessible through Automation Gateway. We’ve already implemented some integrations, some data transformations. In previous sessions, we’ve sat down and really went through some data transformations. We started to do an integration, well, we’ve already integrated NetBox through the APIs, and now we’ve started to build an automation to bring net querying NetBox for inventory and IP address information and create an automation to do that. Now, we haven’t put it into the main automation yet, and that’s where I left you last time, but we’ll also discover how we can do the same thing with ServiceNow. We already have an integration, and how can we build an automation, a modular automation that can be leveraged in other… other multiple workflows.

Rich Martin • 01:52

So in order to do that, we’re going to talk about and identify some common reusable tasks, what makes for a good modular task, reusability, obviously. Then we’re going to talk about how to create a modular workflow. I think this is going to go pretty quickly because, surprise, spoiler alert, once you build a standalone workflow, there’s not much more that you need to do in order to make it modular, and that’s what I want to show you today. Then how do you call that modular workflow from, let’s say, a parent workflow? We use that using something called a child job task, so I’ll show you how to do that. Then of course, transformations are just a critical component to building automations, and so we’re going to see how transformations are leveraged to format data to and from child jobs. So passing data to and from child jobs, and then extracting that data or formatting that data through transformation.

Rich Martin • 02:43

So like I said, we’ve used transformations before. This is the exact same concept, And so you will already have the foundation for that as it applies to child jobs. It’s really the same concept of manipulating data and formatting it. And then finally, how we’ll implement everything, test the parent workflow, step through it when we run, and we can see how the modular nature works with everything. And then hopefully you get the full overall idea of how all this works together. So with that, let me share my screen and we’ll go into the Itential automation platform.

Rich Martin • 03:15

So this is where we left off last time, and I know this is hard to see, so I’m gonna zoom in in a minute, but let’s take it a little bit at a time. We started off our workflow with querying the user with a form so that we can get the input for their data. Remember a stub task is a holder, we’ve used it to kind of like stub out or basically as a placeholder for different processes or tasks. So one of these is to get an IP address from a NetBox server that we have on the network. We have our transformation. This transformation originally we built it so that it would take the user input form that gave us the network device and a port description, because we’re bringing up a new interface, and then turn that into a set of CLI commands that can be used to push to a network device that we have selected from that form. That’s that transformation.

Rich Martin • 04:08

That’s what it was built for. We’re going to be updating it because now we’re getting more information that can be used for the config changes. In this case, it’ll be an IP address from NetBox. We’re going to update that in a minute. This is part of that process of building modular workflows and how you will integrate those back into your parent workflow. Here’s another stub task of creating a change request ticket. This is for service now.

Rich Martin • 04:31

We’ll be addressing that as well with a modular workflow. We have our command template. This is our pre-check process. It looks at that network device and it says, hey, we’re about to make this interface change. Does this interface actually already exists? Because if it does, we probably shouldn’t make that change. That’s what our evaluation does.

Rich Martin • 04:51

It gives us a fallout routine if something doesn’t look right with the state of the network before we make the network change. Then we go on to make the network change. And of course we do an evaluation there to ensure that the network change we made was successful. So that’s our fallout condition here that we’ve already built. And then finally a post-check process, which is another command template that we’ve built previously that allows us to say, okay, now that the change is made, we know the change was successfully called. Now let’s look at the network state through a show command to ensure that the interface is up and it’s actually showing up in a show interfaces command. So that’s what we do here.

Rich Martin • 05:27

And then we evaluate that. And then our last stub task that we’ll update here as part of the primary workflow is to update the ticket state. So after everything’s done. So that’s a quick review. So let’s now take a look at what would make for a really good modular workflow. In this case, we’ve already identified the fact that sometimes querying a source of truth like Netbox for inventory information or IP address information would make a really good modular workflow. Why? Because it’s reusable.

Rich Martin • 06:01

Is it something that occurs quite often in your day-to-day processes? Every time I have to bring something up on the network or bring up a new interface or assign something to a server, I have to pull an IP address. from Netbox or other source of truth could be Infoblox. That probably makes for a good reusable modular workflow because you can build it once and then reuse it in multiple parent workflows. That’s why we isolated that. But also change requests tickets, creating new change request tickets, updating them also makes for a nice reusable workflow. A reusable workflow can be something network related.

Rich Martin • 06:41

It could be querying a router or a switch for a set of data, that you want to document in a ServiceNow ticket. If this is something that occurs quite often, that might make a nice reusable workflow, as well as a reusable workflow for making network changes. This is where you can sit down, especially during the process where you’re blocking and stubbing out your workflow, thinking through what would be really good reusable use case here. Then as you’re building those workflows, incorporating this idea of reusability so that you can, as you’re testing the workflow, you can say, here are the variables that I need to be input, here are the variables that we need to be output, and then building it in such a way to make that possible. It’s really not that hard. In fact, quite honestly, everything we did to build the previous Netbox workflow that’s going to be here, is really the same step as building just a regular standard parent workflow. and I’ll show you that.

Rich Martin • 07:43

So that’s really what makes for a good reusable workflow. And it’s just thinking about the mindset of making this instead of something standalone, something reusable. So where we left last week or last time in our last session is here. This is the workflow we built to query Netbox for an IP address. So this does a direct API call to Netbox. And then we created a transformation to turn that response data because the data that we get in response is basically the IP address slash in the CIDR net mask. We needed to turn that into a CLI command.

Rich Martin • 08:21

So what we did here in this transformation is we built, we took, we extracted that data from the first call and built the CLI command around that using a series of different methods and string manipulation methods. You can go back to the previous series to see that. But that’s where we left it. And so the idea here was now that we’ve done this, can we just replicate all of these steps and this information and put it back into our original workflow, replacing the stub task that we have here. with those two workflow steps? And the answer is, yes, we could do that for sure, but we’re not going to because we want to now transition this into a single step that calls this workflow. So just by example, Let’s just take a look at some of what we’ve got going on here, just so I can show you, again, by a refresher, how this works, and then we’ll run it and I’ll show you.

Rich Martin • 09:19

This is a direct call into the NetBox installation that we have here. We’ve defined an ID number which is, this is data that’s all required from NetBox. When we did the integration, these are already defined in the NetBox API, so we’re reflecting them here so that data can be filled out, either statically or through another task, or as we’ll see in a moment, you can pass variables to and from different jobs. That’s part of the modular nature of building workflows that way. In this case, 32 is assigned to the IP address prefix for this, for where we want to query against. Then we’re just passing some data in an object here, so we can update the status to active and then set a description up. It’s as simple as that.

Rich Martin • 10:06

This data comes from the documentation for NetBox, for this particular API call, and we covered that in our last session. Then this is the transformation. The important bit here is when you build your transformation in our Canvas, you’re going to have an input schema and an output schema. When the input schema is defined, and you now reference that in a task, that transformation that we built in the canvas, you save it, now you reference it in a workflow with this transformation task. That input schema is read in, and it’s displayed here. So now we know that there’s an input schema that matches, that’s an object that we called it from NetBox when we created this transformation.

Rich Martin • 10:53

And then we have the ability to source the data for this object from a previous task. In this case, a previous task here in this workflow, which is this task, get IP address from NetBox. You can see it here. And then that particular variable that is the result variable is going to be passed into here. So that’s the source data from which we are, we’re taking the data to do the manipulations. And then we defined an output schema. And so I’ll show you this here.

Rich Martin • 11:20

The output scheme is understood as well. So we created something called iOS command. And by default, there’s an error. If anything happens in transformation, we can capture the error and store it. Now notice here, we didn’t check these boxes. And this is where we take this from a standalone automation workflow that can be run to a modular workflow. If I click this here, and I won’t do it yet because I want to show you the difference in a moment when we run this.

Rich Martin • 11:47

But if I click this here, it makes this particular variable, which was defined in our transformation that we defined available to a job. or a parent workflow that can run this workflow, and we’ll put this all together in a minute. Let me run this without that checkbox. So you can see the difference. So when I click that and run, you’ll see very quickly everything finishes. Again, we’re taking a look. A job is an instantiation of a workflow as it’s running, and now it’s doing the dynamic calls, API calls, and the transformations, and we can take a look at the data that’s coming in and out.

Rich Martin • 12:27

So the incoming data here from our transformation, I’m taking a look at our transformation, is the outgoing data that came from the API call. So the NetBox API call provided this data to us. Now the transformation is gonna take that as the source, and it’s going to extract it and format it the way we defined it in our transformation. We’ve built it on the canvas, and it outputs this command. So this is the data that is output, this iOS command. This iOS command obviously is in the format of pushing for a Cisco CLI command, so that’s usable for the parent workflow that we’re going to use this with. But if I click on end here, you’ll see that the end task has got these two default variables, ID and initiator.

Rich Martin • 13:14

What we want to do is we want to have this outgoing variable passed so that it’s available in this end task, so that makes it available to any job that calls this one. And this is really one of the key components of a modular workflow, is that you’re gonna have data that you want to preserve after this workflow ends and make it accessible by a workflow that has called this one. If I go back to this workflow, so I’m gonna close out that operations manager where we ran that job, and I’m gonna now click on this. This is what preserves that variable that we defined in our transformation so that it’s available at the end task, and therefore passed back into a calling workflow, a workflow we call a parent workflow that calls this modular workflow. Let’s save this. Close this out, we’ll save the whole workflow here, and then we’ll just run it again, and it should do the same thing. It’s going to get a new IP address obviously, because it’s the next one in the list there that Netbox is using.

Rich Martin • 14:19

But if I double-click on this transformation, you’ll see nothing has changed here. We still have the iOS command. But now when I double-click on the end, we have now passed that iOS command to the end task, which will now make it available to something that calls this through a task called child workflow. That’s the first step. We built this workflow no different than building the original workflow, the main workflow. We built it the same way, but now I get to extract certain information and pass it along, helping to make this a modular workflow that came up by something else. How do we call it? That’s the next step. Let’s go back to our build a workflow, parent workflow here, and I’ll zoom in.

Rich Martin • 15:06

Now we want to take this sub-task and replace it with our modular workflow. In order to do that, the key component here is to leverage a task called child job, and that’s an internal workflow engine job here. It’s called child job, and I can drag it over to here. Let’s get rid of this. We can delete and merge this. This will preserve our line, and then if I drop this right onto it. It’ll put it in line, and now we have something called child job.

Rich Martin • 15:38

So this is a task like anything else, but the purpose of this task is to run another job, and this job is going to be our modular workflow. We call it Build a Workflow 3 for Netbox. So all I have to do here is select the workflow by name. Now, if I click on this little eye, it’s going to show me the input and the output schema. So we’re not passing any data to this workflow. It’s just doing a static query to Netbox at that particular ID, so we can get an IP address from that particular prefix. So we’re really not passing anything to it.

Rich Martin • 16:19

We could, if you wanted to make this workflow a little more modular, you could pass an ID value so that somebody could select a different ID and therefore access a different prefix to use. But in this case, we’re going to keep it simple, and we’re just going to not have an input schema, but we do have an output schema because remember, when we click that checkbox to export the job variable, now iOS command shows up in the output schema when we add this to this child workflow task, and we reference that. So we can change the name here to make this a little bit easier. It’s IP address, and really, that’s all we have to do. That’s it. It’s as simple as that. There’s really no difference other than thinking ahead, and I know I led you into this in the last session, but there’s really no difference, and exposing those job variables that you want. It does require a mindset of thinking ahead and saying, okay, how modular do I want this to be?

Rich Martin • 17:26

Do I want to allow somebody to provide the prefix ID? or do I want to keep that static? Now, this particular modular call, maybe it should be named something like, get IP address from Netbox for prefix x, y, z, or whatever that prefix name is. To be more specific because it’s nailed down to that particular ID we set statically. But if I wanted to pass a variable to it, we could do that, thus making it a little more modular. Those are some of your options as you’re building these things out. I’m keeping it simple, but I’m going to show you an example of input.

Rich Martin • 18:06

This is an example of outputting variables, but I’ll show you in a moment when we do the ServiceNow ticket creation, the example of input and output. So let’s think this through in our next step. So we’ve now added a new data source here, and that data source is the IP address from Netbox, but the transformation is turning it into a CLI command. So by default, that variable is now available, but we have to integrate it back into the workflow somewhere, somehow. So the thought is, okay, when we make our iOS change, where does that data come from? And if you remember our previous sessions, it’s this transformation here. This transformation, if I double-click it,

Rich Martin • 18:46

was created to get data from our form. Remember, our form is going to ask the user for which network device you want to make a change on, and it’s a drop-down. Then it’s also going to ask for what’s the port description for this new interface. That data comes from this task, and it’s being referenced from this task. This transformation can now manipulate that data to create the CLI commands to push to the Cisco device. We want to now put an additional command into this that comes from this data source from NetBox, and it’s now setting the IP address from the next IP in that prefix that we just pulled. So that’s that iOS command that comes from this particular task.

Rich Martin • 19:31

So now what that means is once you start to integrate these child workflows that are modular, you may have to update your transformations to match those. And so I’ve already updated the transformation because the change is not that big, but I’ll show you when we update it here, build a workflow, and I just called it four because this is session four. you’ll notice that the form data is still there and we’ll have to define it, get input from user. So I’m saying the form data that this is requiring as one of the sources is gonna come from our input form and that variable is called export, but you’ll notice this is new. This is what I added to the transformation. We’re now saying there’s another source of data that we want to include in this transformation. And I’m just calling it from NetBox query because that’s what we did.

Rich Martin • 20:24

We created NetBox for the next IP address. And that also is gonna come from another task. And that task is this child job, get IP address from NetBox. And it’s already selected because it was the immediately previous task and job details. That’s the output that it’s gonna come from. I’ll save this, and then let’s take a look at this transformation and the change that I made to it. Again, if you’re going to start to integrate these modular workflows, they become sources of data that you’re going to use in other places most likely when you output their variables.

Rich Martin • 21:01

Now you might have to update some transformations to utilize those. In this case, everything up here, the only thing new I’ve added was this particular input schema here and it mapping into this array, and I’ll explain it, so I’ll give you a good look there. This is the only thing I added. From our previous session, we already had form data, we already created this. This is extracting the two pieces of information from the form we’re showing the user in our very first step in this automation. We’re doing all the manipulations so that we can provide two variables, a host name, an iOS command that’s required by making the task that makes the change to the network device. All we’re doing now is I’m adding another source and that source comes from our child workflow that we’ve just created, and that’s the iOS command.

Rich Martin • 21:55

Now what this is saying is, this transformation requires another input schema coming from another task, and that’s going to be coming from child workflow, and we expect it to give us this variable called iOS command, and when this variable is there, we’re going to map it into our array. That array holds all of the iOS commands that we’ve generated, and then it’s going to save that as an array that gets pushed out into this variable iOS commands. When it does that, that sets everything up so that it can be used when we make the network change, that particular task that makes the network change. If we run this now, You’ll see as our example output. We’re running this with example data that we derive from our inference from JSON objects, and you can see the net last sessions on how to do that. It makes it super simple to create these incoming JSON schemas.

Rich Martin • 22:55

But you’ll see here the addition of this. This came from that child job that we just made modular. It used to be just these two lines, now we’re adding this. That’s that Netbox query, getting the next IP address, and then putting it in the format that’s applicable for an iOS command for that particular change. And now we’re defining that as an input source and then utilizing that. So this is the whole transformation to accommodate that new data source that was our child workflow. So now let’s go back to our main workflow.

Rich Martin • 23:31

Yeah, I’m OK. I really didn’t make any changes there. Let’s go back to our workflow. And let’s talk a little bit about the next two tasks that are StubTasks that we can now update and turn from StubTasks into actual modular workflow. So those two are around service now. So this is creating a ticket and updating a ticket. So these two is what we’ll tackle next.

Rich Martin • 24:00

Again, these will be child jobs as well. The key to this here is that knowing that a regular workflow can also be utilized as a child job in a bigger workflow is the key to this. And so what opens this whole thing up is let me step away from our platform for a moment. And let me take you to our website. So if you go to itential.com, if you just navigate to Products in our pre-built collection, This is so key because as you’re working and building automations in our platform, all of this whole entire pre-built library is accessible inside of the platform. This is a great way to view it outside of the platform, but all of this is accessible inside the platform.

Rich Martin • 24:46

When you start to search, like for instance, we’re about to do some service now, modular workflows, you already see that we’ve created several workflows and any of these automations can be utilized in your parent workflow. We want to make it easy to start to leverage a lot of these reusable tasks that we’ve published so that you can just bring them right into the platform and utilize them because that particular workflow is usually built so that it can be done in a modular way to save you a lot of time. Now, that’s one option. Obviously, another option is to build one from scratch like we’re doing, or to take something that’s already been published in our pre-built library and modify it based off of what your organizational process is or your unique needs or those things. We want to give you all those options, and any one of those three options is super simple to do because you’re just building a new workflow, and you’re just determining which variables to pass on to a parent workflow as a child workflow. That’s really it. I’ve just created very simplified versions of this because this is hopefully giving you all the foundations on how to build these. Let’s take a look at this. This is creating a change request ticket.

Rich Martin • 26:03

I’ve named it Modular ServiceNow CreateChangeRequest, and this looks very similar to the Netbox one. The first thing we do is we identify the direct API call to ServiceNow. We talked about that in the last session and probably the session before of how to identify those things. It’ll require a little bit of looking through the documentation or looking through the API documentation that’s onboarded in our platform or perhaps in their platform and their documentation resources because those API calls are defined by them and we just read them in through whatever documentation they have available that gets imported into the system, integrated in the system, so that could be OpenAPI or Swagger spec. And so when we choose those API calls, remember, we pull them from the task palette, drop them down here and then once they’re there, we understand the variables that are required or defined by that API call. And so in this case, it takes some identification of the object because they’re a little less specific for this particular API call and service now instead of defining each one of these variables individually, they prefer to pass an object with these variables set. You’ll see it both ways, like for instance, in Netbox, they define a lot of variables that can be set.

Rich Martin • 27:23

So they’re very specific. In cases like in the ServiceNow particular ServiceNow call, they’re saying, hey, just pass us an object called body, and you define the variables as keys and values. Go back to our integrations and transformations to understand the basics of JSON and how to set this up in an environment. But basically, I’m statically assigning all of this just for a test. Obviously, we could take an input variable for summary or name or any of those things and dynamically change those that would make this a little more modular. But in this case, we’re just going to use this statically set because this is, again, another example of outputting data from the change request. This is important because when you’re creating the net new change request, if you want to update that change request later, you have to know the particular ID of the change request, and that’s given to you when you create the change request.

Rich Martin • 28:18

When this call is completed, we want to pull that data in to this transformation, and this transformation is simply going to extract the ID that we need. This is going to take data from the ServiceNow request, and it’s going to output our change request ID. That’s the transformation variable that I’m calling it, change request ID. Notice I’ve already pre-clicked store output as job variable because I intend to use this as a job modular workflow. That’s an example of that. Now, let’s take a look at the, I call it close change request, it’s really update change request. Because all you’re really doing here is you’re updating the state, and the state can be new, it can be review, it can be implement, it can be close.

Rich Martin • 29:06

Closing is just changing the state, that’s what this does. But you’ll notice I’m putting a transformation before the API call directly into service now. The reason why is because this is an example of passing a variable or data from the parent workflow into the child workflow. This is the other side of creating a modular workflow. If you want to make this modular in this case, I want to be able to change the state of a request, but I don’t know that request ID, so it has to be passed in. We got that from our initial create. and so that gets saved as an output variable.

Rich Martin • 29:44

I just showed you that in this last one. Now, when this gets called, this transformation is going to expect that data to come in, and be available, and when it is available, then it’s going to extract it and then pass it to the change request call to service now. In this case, you’ll see the change ID that’s being derived from this previous task, and then the body similar to the last one where we set the body with a bunch of notification, information, and title, and things like that. I’m just changing the state to zero, and this is going to move it from new to review. There are some other processes depending on how you implement your service now that may require certain steps before you can close. But even a close is just a change of state based off of a particular process. But changing the state is really what we’re going for here.

Rich Martin • 30:40

Okay, so with that, let’s take a look at the whole workflow as it sits. We don’t really need to show creating new child jobs. It’s the same process as we did before. So I just took those modular workflows for create a ticket and updating a ticket. I created the change, the child job, I drag it in, I replace the stub task, I reference the modular workflow that we created, and basically that’s that. And so now when we run this, let’s take a look, we’ll take a look at, it’s gonna complete pretty quickly, but we can take a look at the individual tasks and identify that data as, you know, the data being passed through child jobs, through transformations, things like that, as it progresses through. Let’s run this and then I’ll zoom in.

Rich Martin • 31:31

Again, our first step is to require the input from a user. If you remember, I can work this task. It’s going to give me a form to fill out. This is all definable in our platform through a low-code Canvas. The first section here is a drop-box with elements in it. I’m going to choose this. This is the device we’ve been testing on. Then an interface description so that we can set the port interface description.

Rich Martin • 32:01

I’m just going to give it that. Click confirm, and now it will progress through, and that data is now going to be used in this transformation. But before it gets there, it’s going to run our child task, our child job task, and let’s take a closer look at that. It’s already successfully executed, but we can take a look at it as we’re managing this job and looking at it task by task. If I double-click this, I can see the incoming variables, there are none. Because remember, we didn’t define any incoming variables for this one, but we did for the close or the update task for service now at the end. We don’t have anything here, but the outgoing variables, we should have something.

Rich Martin • 32:39

In this case, this is the outgoing variable that was created from our transformation, that we click that checkbox to say, hey, pass this along as a job variable so it can be used in this parent workflow. The other thing to note here, if I right-click on this and click open because this is a child workflow and it runs as an independent workflow under that child task. Sometimes it’s helpful to see the independent steps from that. If I right-click and open, then I can see the independent steps from each one of these. Then ultimately, what we got and what we’re looking for is the job variables coming out of this, so that this was passed along. This makes the data from this workflow usable in the parent workflow. If I want to go back to the parent workflow, I click here.

Rich Martin • 33:29

Now, that was the task we looked at. We can take a look at the transformation. In the transformation task, we were passed that iOS command. Remember, the outgoing should give us the host name and now all three of those commands to pass to the network change task that we have a little bit later. Now, here’s our next child workflow, modular workflow, child job. This was the create change request ticket. It doesn’t require anything incoming as a variable, but it does give us the change request ID.

Rich Martin • 34:08

This is critical because we need this to pass to the update task at the very end of this. This is why we exported this out. This is why we clicked that checkbox that says change request ID, pass it on as a job variable. This makes it accessible on this child workflow. Now, this is pretty standard stuff from our last session. We run a command template, we do an evaluation, it passed it. Now, it’s actually pushing the change command.

Rich Martin • 34:35

If we double-click here, we can take a look at the outgoing. This is after this is run, and we can see here that the commands we pushed are those three commands. This validates that our transformation that we updated up here, is taking that in and appending it to the array, that came from the NetBox child workflow. Then of course, the status is success, which is what we’re evaluating here. Because the status is success, it’s continuing down. It’s running the command template for our post-check process to make sure the device interface is up. Finally, the evaluation is passed because it is up and it’s online.

Rich Martin • 35:13

Then finally, here’s the last piece, is the child job that we created, a simplified child job to update the change request ticket. In this case, this requires data coming in, and remember that change ID, and the form data is what we’re really looking at here. Sorry, the form data is passed in. We’ll take a look at the job in a minute. But outgoing is the validation that everything was complete when it made the update call. Really, the final evidence of that is if I go into, we’ll take a look at one thing here. Let’s go back up. We did this ticket in this child job.

Rich Martin • 35:54

and we look at the incoming data. Actually, we probably need to open it so we can look at the direct API call. This is the direct API call to create that new change request ticket. This is the ID that we extracted, but we want to take a look at this. This is the human readable number. That’s output and it’s 34553, that’s the ticket number. If I go into our ServiceNow instance, we refresh it, 34553, I believe that’s what it was.

Rich Martin • 36:32

34553, here’s the ticket. It created the ticket, obviously. Now, initial state when a ticket is open is new. This pushed it to review, which was that last task. So it needed that ID in order to execute that last task, which was our child workflow to do the update, and that changed the state to zero, which turns it into review, and then from there, you could close. So that brings us to the end of the demonstration. We hope that I was successful in showing you that while I left you at a cliffhanger last time, it really wasn’t that much of a cliffhanger.

Rich Martin • 37:13

All of the hard work had already been done. And really, it’s a matter of we’re thinking about creating modular workflows. A lot of times, you’re creating them as standalone to test them anyway, to test workflows. And now it’s just a matter of saying, what data do I need to export? What data do I need to import, if any at all? And then how do I fit this? Is it reusable enough to actually become a modular workflow?

Rich Martin • 37:39

Hopefully so, because if it’s something that you’re running into all the time, then that makes it a perfect candidate for that. But it’s really about thinking about how you want to pass data in and pass data out, just like a task, a common task. And so with that, hopefully that’s helpful. As you start to build your own library of modular workflows, you’ll see that you no longer have to rewrite all of these things. And that’s going to save you and your team and your organization a lot of time, and investigate modular workflows that are already available in the Itential pre-built library to save you even more time. So that in many cases, you may not have to write anything. You can just leverage what’s already out there.

Rich Martin • 38:16

With that, I want to say thank you very much. Hope to see you in our next episode of this session, which is the final one where we learn how to take this completed workflow and publish it and turn it into something that can be useful for self-service. With that, thank you very much. See you next time.

Rich Martin • 00:00

Hello, everyone. Welcome again. My name is Rich Martin, Director of Technical Marketing at Itential. Thank you for joining us for our part 5, the final part of our webinar series on building network automations, where we focus and discuss how to and why you would want to publish and share your automations. So it’s always a good idea to look back to see where we’ve started and how much ground we’ve covered to enjoy this journey. So like I said, we’re in part five but we have covered a lot of ground. So I wanna thank you so much for joining us through all of that. Everything from the introduction to the canvas to how to create and kind of map out your use case and the logical steps, everything from that to actually building and spending lots of time building and testing and evaluating and adding more to your workflow.

Rich Martin • 00:55

And now we’re getting to the point where you’re gonna take our workflow and publish and share it. What we’ll be doing today is on the right-hand side, this looks very familiar. We have a workflow we’ve been working on. It has integrations to ServiceNow and NetBox. It integrates and works with a Cisco CLI device to make a change. But in this case, we’re going to take our workflow and we are not going to spend a lot of time where we were in the platform previously in Automation Studio, where we’re building and testing. We’re going to spend more time today in another part of the platform called Operations Manager, where we take the workflow and turn it into an automation that we can publish and then define how we want the methods we want to use to run that workflow.

Rich Martin • 01:41

We’ll be doing that. I’ll be showing you the four different methods or triggers that can be used to run a defined automation and then we’ll talk about how this helps the automation become more valuable as you open up the opportunity to do self-service for network teams and self-service for other teams, teams outside of the networking team. Doing this through APIs and then something special we have called ecosystem applications. So with that, let’s jump over, let me share my screen, and we’ll get into the platform. Okay, now I know this might be a little hard to see, we’ll zoom in in a minute, but what I wanna show you is we are in Automation Studio, we won’t be spending too much time, we’ll just be here briefly, but we now need to take the workflow that we created. So this is the workflow from our last session that we created, we modularized, and now we need to operationalize it. And I want you to think about it in this way, Automation Studio is all about building and testing and automation, and we’ve been doing this solo.

Rich Martin • 02:49

But now we need to operationalize this workflow so that we’re going from just us using it, just a single person, a single execution of this automation, to now allowing more people, multi-user execution of this automation. This increases value, if there’s value, if there’s value assigned to this automation when I run it as a lone person, imagine the value that we can reap when we allow more than one person to use it. So maybe your team of network engineers, or you’re opening up to your network operations team so that they can, it enables them to become better at addressing or provisioning things that come in on a day-to-day basis, thus saving you maybe a lot of backlog and then increasing the value to the end user. whether that’s internally or externally to your company. That’s what we’re talking about here, operationalizing it. Let’s start tactical. We created this workflow and I want you, I’m going to flip between my first two tabs here, because what I’ve done in this first tab is taken the workflow that we’ve built, and then I’ve operationalized it so that it can be used in Operations Manager to be published and shared.

Rich Martin • 04:02

The second tab, what did you see different here? You’ll see this first task has been removed. You see that? Let’s start here. Let’s talk about that for a second. We removed this task, so what was the first task? Let’s zoom in a bit. And our first task from our last workflow here is that show JSON form.

Rich Martin • 04:24

Remember, this was a task that essentially stops the workflow when we execute it and brings up a form that the end user wants to fill out. Now, when we are testing this and we’re running it, certainly this is useful for us. But now when we want to operationalize it, we have to think a little bit differently. Do we want the very first step in the workflow to always be to show a form and interrupt the workflow? So it’s no longer a zero-touch workflow. It requires manual intervention. In some cases, yes, but in other cases, no.

Rich Martin • 04:52

And we’ll talk about what those cases are when we publish this automation. So what we want to do now to operationalize this is remove this task so that it doesn’t cause as a first step to show a form. But you might ask the question, well, OK, well then, where does the data from the form come from? Well, it can still come from a form, but it’s not being run in this automation. And by clearing out this first task so it doesn’t stop the automation from executing and wait for a manual intervention from a human, this now operationalizes it so that data can be passed in to this workflow from another source. That source could be a form. That source could be an API call into the system.

Rich Martin • 05:30

And now we’re operationalizing it. So if we remove this task, that data has to come from somewhere, which we’ll address when we get to Operations Manager. And the second thing is, we’re working on that data. So we reference that data usually in a transformation. And that transformation is right here. So the two things that I’ve done ahead of time here is to remove that front task, just delete it from the workflow like we’ve done several times. And then the other thing that I’ve done here is updated this transformation task.

Rich Martin • 05:59

So this is what it looks like now. If I double-click it, you can see the variables. And remember, I’ll show it in a moment. This used to come from that task that used to be here. We were referencing variables from that task. Now I’m referencing form data, but instead of a previous task’s variables that I’ve deleted, now it’s coming from a job. So what does that mean?

Rich Martin • 06:21

That means that when this is executed as a job in Operations Manager, it’s going to look for these variables to be passed in externally. And this is really how we operationalize it. Now, could we have done this from the very beginning? Could I have always run this from Operations Manager manually? Absolutely. But I wanted to show you how all of this works and how operationalizing it works. And you may still, as you build automations within Automation Studio, you may still choose to do it this way because removing a task and updating the source of a variable is very, very quick and easy.

Rich Martin • 06:56

As you’ve seen, we’ve done this over and over and over in our iteration of this workflow. So I wanted to show you that originally, this is what it originally looked like. This was a transformation task. It still had this form data object that it was requesting that data from to work on, but it came from a previous task and not from the job. So that’s what we changed. Delete the task, update the transformation so that it references it from outside. And then once we have this workflow built and it’s ready to go as a final operational workflow, then we move into another area of our platform called Operations Manager.

Rich Martin • 07:33

Now, quickly, Operations Manager is where we publish automation. So we’ve created a workflow. Now we want to publish this as an automation. You’ve actually already seen the other side of Operations Manager, which is managing jobs. So a job is an automation that’s been run. And then so you can run jobs and then manage those jobs. So I’ve showed you that.

Rich Martin • 07:54

Whenever we’ve tested our automations from Automation Studio and we’ve tested those workflows, they were running as a job. And then when we manage those, we double-clicked into those tasks that were running. We saw the variables, we copied and pasted them. We use that as part of the build process, creating transformations. We did all of that through the job section of Operations Manager. But now we’re going to focus on the automations side of Operations Manager. So if you look on the list on the left here, you’ll see a lot of these automations that have been published.

Rich Martin • 08:28

Think of this as self-service for your team. Or any group operating within the Itential platform. If my user account has access into this, then I have access into either viewing or running these published automations. Just like we created a workflow, we’re going to create a publish and automation that will now show up in this list. These are things that already exist. Now you can see there’s this great catalog of different network and infrastructure automations that I have access to that we can use on a day-to-day basis. If my team has access to this, I can now create essentially a catalog here for them to do to run automations and do their work on a day-to-day basis.

Rich Martin • 09:16

So let’s now create a new entry into this automation. And very similar to other areas, we hit this create button here, and it’s going to ask us a name. We want to do webinar, what do we call this? Webinar Build a Workflow, okay? We could put a description here. And we click Create. Now we’ve successfully created an entry here.

Rich Martin • 09:48

You’ll see at the bottom, this is where our entry webinar Build a Workflow now exists. But of course, it’s not really doing anything yet. The first thing that is required of us is to select the workflow that we want to reference. And of course, this is going to be the one we’ve been working on. So I’ve called it Build a Workflow Final. So this is that final one I just showed you that we’ve operationalized. So now we’ve done that.

Rich Martin • 10:14

And you’ll notice here that we can, here’s the description we added, but we also have the ability to create some authentication and access around this, right? So this is critical, because as you start to publish workflows, you want to maybe give some workflows access to certain groups and other groups not. As my account here is admin, but I can specifically tie this back into admin, the admin group. that’s defined in the system. And as part of managing the itential platform, you have the ability to define locally groups or integrate with your LDAP system. And then we’ll learn those groups and now they’re accessible here. So you can start to create groups, identify users with those groups, and then limit and create access to what automations for what groups you want to provide.

Rich Martin • 11:08

So if I wanted to give the operators, the network operations team, access to this, I could certainly do this. They could view it or they could actually run it. And I could just save my changes from there and that’s gonna give me some ability to do some access control and authorization on this particular entry. So that’s one piece that you get, and you really want to leverage and utilize in Operations Manager. But how do we actually run the workflow? We’ve referenced the workflow, we’ve created some rules around who can use the workflow. So that is done through creating a trigger.

Rich Martin • 11:44

So think of this as a method as to how we want to run this automation. And there’s several different methods, and I’ll show you them very quickly here. If I click the plus button, it’s going to open up this dialogue here on the right. Of course, we need a name. The first one I’m going to show you is maybe one that’s important, but maybe more advanced. I’m going to call this event. Test.

Rich Martin • 12:11

And this is going to be an event-type trigger. And I’m going to fill that out to avoid a pop-up. We’ll talk about JST in a moment. But that’ll avoid a pop-up that’ll pop up to warn us about something. OK, so this is a type of event trigger. It’s going to ask us the event name. So think of event trigger as how we want to respond to an event.

Rich Martin • 12:35

So what is an event? An event is either an internal or an external event that is available within the Itential platform. So you’ll see here there’s a lot of internal events that exist already as part of our own platform. And then there are some external events through integration. So there’s some email adapters through NSO. And of course, as you build more and more integrations in your systems, you can create more, integrate with event systems, and they can appear here so that you can choose them. So what you want to do is you want to choose the type of event.

Rich Martin • 13:10

So we have an area, you know. maybe a failed trigger and operations manager. And then the next thing you want to do is you want to define the payload. So when we’re connected to an event, we can receive a payload and then we can create a schema. And this you’ll see as a JSON schema to define the payload that matches the event in order for us to respond to it. So this is how we do some filtering because especially if you worked with any kind of event notification systems, there’s all kinds of messages and you want to be very, very specific to what events that you want to respond to. So this is where you would create that payload filter schema, it’s a JSON.

Rich Martin • 13:53

So again, we’re using JSON all over the platform and you can define it here. And this is probably one of the more advanced methods of doing it, but certainly is an important one because being able to respond quickly to an event, especially something around security is incredibly important. So that’s why we give you the opportunity to use this method. So that’s the first one. The second one I’ll show you is a scheduled event. And this is probably a more relatable and easier to understand for a lot of folks, especially if you come from a network engineering background. So I’ll just call this one a schedule test.

Rich Martin • 14:29

So in this case, schedule is the event type, or the MSR, not event type, the trigger type, or the method here. And this is just running in automation at a particular point in the future, and either optionally repeating or not. So in this case, we could select tomorrow at a certain time. At this time, we could repeat a certain amount of days, seconds, months, weeks. However you want to do it. Process. So if we miss a run for some reason, process it.

Rich Martin • 15:05

And then we can optionally attach a form to it. And you’ll notice that it identifies all the forms, including the form that we’ve been using before. Because form data has to come from somewhere. So if I select that form, you’ll see that it’s pulling up the form that we created for our example workflow. Ideally, though, you don’t use a form for this. And so where would you use a scheduled method? Think about in terms of a compliance check or an audit that you want to do.

Rich Martin • 15:38

Whether or not even you’re doing some automated remediation, you’re letting the automation remediate things. Even if you don’t do that, it’s useful to do that to generate reports or anything. For instance, perhaps you need to see some weak, you need to call some data from a lot of different places on the network, routers, switches, things of that nature. And you want to pull that data together, maybe even to generate a report. You could do that, or you could pull data on a weekly, daily, even hourly basis for some critical thing and send it off. Remember, because of our ability to integrate with all kinds of systems in your IT environment, think about pulling data on a schedule from your network and then sending that out to email or Slack or Teams or whatever chat system you’re using. Even opening up a ticket in service now or JIRA, updating an inventory system like NetBox or even just a general database maybe that you’re using to store data or sending it to a telemetry system.

Rich Martin • 16:39

All of these things are possible in our platform, in a workflow as we’ve seen through our integrations. And then you can use that to immediately or send them all to all of these different outputs if you wanted to. And that’s a great way of using the schedule method for an automation, just so that you can run things on a repeating fashion or in the future in an automated way. I can save that and you’ll notice every time I save it, it’s creating an entry. Let’s see, the third way we’ll talk about is manual. What is manual? Manual is exactly what it sounds like. Remember when we first started just a few minutes ago, we had to operationalize our workflow.

Rich Martin • 17:24

In order to do that, we had to remove the JSON form task as the first step, and then update our transformation to reference data outside of the platform. That data is still the same form data we need to capture because that was utilized in that transformation to generate a set of CLI commands to push to a Cisco device. Manual will do the same thing. This is what we talked about. This is why we operationalized it. I’m going to create a new method here called manual test. I’m going to select manual here, and you’ll notice it’s asking me for one field when I select manual, what’s the form we want to use?

Rich Martin • 18:03

Now if I pull in this build workflow one form, this should look very familiar. When we were building that automation workflow as that first task, when I ran it, it immediately, we had to go into the job manager, and I had to basically work that particular task, and it popped up that form, this form here. Now I’ve associated that same form with this workflow as part of this manual method of running this workflow. And so now that, because I’ve done that, this becomes the operational way. to start running that workflow. Again, Automation Studio, where we have been spending majority of our time is for building and testing workflows, but when we’re ready to publish them, a whole other group might be, ideally, a whole other group and a whole other team of people, and not just us, can now have access to run this. That’s why we want to operationalize it.

Rich Martin • 19:02

That’s what this does here. Now that we’ve assigned that form, you’ll notice that form is exactly what we’ve been using to test with. I can select that. It asks us for our description. If I click Run Manually, it would run this just like we’ve been running it. Now though, we have access and control around it, who can run it when we publish it, and we still get all the auditing, all of the logging, all of the variables, the entire execution task-by-task of that workflow is available in Job Manager, and it tells us who’s run it. You get all of that when we publish this and we create more of the self-service way of operationalizing our workflows.

Rich Martin • 19:45

That’s manual. You’ll use that a lot, and in fact, you’ll start building based off of both who can read and write this particular entries and publish automations. You’ll start building these catalogs for different teams and different groups, or maybe even different individuals. We’ve done manual. The final one, think about manual as self-service for your team, internal to the platform. They have access to the platform, they log into the Art Itential platform, and now we can publish these workflows so that they can use them. The last one that I’ll show you, we’ll call this API test. and similar to the last time, I’m going to just go ahead and fill this out and I’ll describe it in a minute. We’ll spend a little time here on the API method of running a workflow.

Rich Martin • 20:37

When I select API, think of terms of now, how can we give access in a very secure and controlled way to Teams, applications, or even other platforms outside of the Itential platform? You have Teams that are using the platform internally. Manual is a great way to publish those for them to use. But what about Teams outside the platform? There’s a logical progression here. We’re talking about self-service, and we’re talking about self-service, and we’re talking about self-service. We’re talking about self-service, and we’re talking about self-service.

Rich Martin • 21:10

First of all, it’s just individual use of a workflow or an automation. Now we’re self-serving to maybe our colleagues on our team, and now we’re self-serving maybe to other network teams like the operations team. And now we’re talking about self, and maybe all those folks are using our platform, but what about teams outside of our platform that still need things like network infrastructure? They want to be able to order it, and we should be able to deliver it in an automated way so that it’s available really in a cloud-like experience. And so API is one of the two ways that we can expose our automations, and like I said, in a secure way externally in other systems. And so what this really means is just like we integrate through APIs, Itential has APIs into itself, and so this allows you to create an API endpoint for this particular automation. And then given the right credentials, allowing some external system platform user application to call back into it and run the automation as if they were running it inside the platform.

Rich Martin • 22:14

And this opens up self-service beyond the Itential platform, so we really can start to talk platform to application, to our platform, or even platform to platform, which we’ll look at in just a minute. In this case, when we’ve created this, we’ve got the name, I’ve called it API test type API, action post because this is a RESTful API. There’s a post action here because we want to be able to accept data passed in through the REST API call. We’re using post here and this is critical because as part of securing this, it is about having the right credentials and authorization, which we provide in the system. In order to make this call into the system, you have to have the right credentials, you have to know what the endpoint is, and that’s definable here. We can call this webinar. build, for instance. So now this becomes the endpoint, I can copy it here so that we can test it, access to it. But you still need authorization credit credentials, and your credentials have to have access to this workflow, as we just defined a moment ago, where we added the operations team to this. So you see, there’s multiple levels to this. And just like running a workflow manually, or in any other way here that’s being published, honestly, you still have full access to auditing and logging and all of the data and information that you would need to ensure that the right people are running the right automations and seeing what the exact results of those automations are. And of course, that’s also available under jobs in operations manager. And we’ve seen a lot of that just building it. But that’s where everything is kind of congregated together.

Rich Martin • 23:52

So you get all of this when you publish in our platform. These are all things that are absolutely necessary. Okay, so there’s another thing that we want to do here as well. And if you look here at this post body schema, this allows us to put up very, very specific guardrails on the data that gets passed in from the API call. So if an API call comes in to run this automation, it has the right access credentials. So, and it has the right authorization to this workflow entry or this automation entry, then it’s gonna pass data to us. And once it passes the data to us, we have an opportunity here by defining yet another JSON schema, because we’re using it all over the place, but this JSON schema defines what the data needs to look like that’s being passed in. And if it doesn’t match this schema, guess what? We won’t run the automation.

Rich Martin • 24:46

So this is a form of input validation. And it’s a very quick way of being able to do this, because if you go back and remember when we created a form, for instance, when we started building this automation and we created a form, we used our form builder and we could generate the underlying JSON schema for the form that we built. So we built a form in a visual way, we generated the JSON schema, we leverage that to infer the inference from that to build a transformation. And all of these tools can actually also be used here as well, so that we know what the form looks like, we know what the fields are, we know exactly what to expect. Let’s strictly define what the input looks like. That way we reduce error, we reduce mistakes, and it gives you another tool to ensure that the data that’s coming in is as accurate as possible so we can have a high degree of confidence that our automations are gonna run successfully. So by default, you get a very general generic one here, this basically says we’ll accept essentially anything without any tightly defined object here, but really, and that’s great for maybe testing, but when you come down to it, you really want to tightly define

Rich Martin • 25:58

your input schema so that it defines the data that needs to come in. In this case, I’ve updated it. This is based off of the form we’ve created, and all this says is we need an object. We expect an object for an API call calling this particular automation. We’re expecting an object, it should be called FormData, which is what we’ve been using. Remember when we operationalize that automation, we said, hey, there should be an object called FormData, and that object should have two properties. One of them is network device, that is a type string, and interface description as a type string.

Rich Martin • 26:38

These are absolutely required, and there can be no other properties attached to this JSON, the data payload that comes in as a JSON. This tightly defines it. Now we can even more tightly define it by specifying which network device, the entire list like we had before, of network devices that are applicable here, we could go that further step. Or we could do something like interface description could have a regular expression attached to it that has also be passed. So this gives you input validation, like I said, to make sure that the data coming in. Not only are they authorized through credentials, they have access to this particular automation entry, but now the data actually coming in passes this filter, and it meets all the requirements just like a form would, just like we’re strictly defining the data that comes into a form. You can do this from here as well.

Rich Martin • 27:34

Then finally, JST, I mentioned this in the event, and it’s used in the same way. When you see JST, that’s a transformation. So we spent a lot of time building transformations. JST, JSON Schema Transformation, it’s taking a schema coming in and a data payload coming in and then mapping it and even manipulating it and mapping it to data going out. You can leverage a JSON, JST, a JSON Schema Transformation or a transformation here as well by identifying it here in this field, and then that can be used to now manipulate the data that’s coming in so that you can map it to values that might be further used in the automation workflow. And again, this is a way of decoupling and operationalizing things so that you can provide the data that’s needed in a workflow in as flexible a way as possible. So now you could leverage a transformation here to do what we’ve done in that transformation step if you wanted to.

Rich Martin • 28:38

Thank you. So if we save the changes here, that’s pretty much it. We’ve been able to define the automation, identify the workflow that we’ve built as our final workflow, create different methods of testing, not testing, but different triggers or different methods of running them based off events, schedule, manual, or API. So this opens up a world of self-service inside the platform and outside the platform. We have the ability to disable everything at once or individually if we needed to. And this is really super flexible and gives us a lot of power and control over the automations that we’ve spent so much time building and testing and iterating off of. And now this is kind of that final step of self-serving out.

Rich Martin • 29:29

And so one last thing I want to show you is, we talked about the API test being kind of the gateway to integrate into other applications and, you know. different tools, your DevOps teams can now access infrastructure creation through an API that you publish. Now they have access to spin-up network, perhaps network infrastructure that you’ve built the workflow for. But there’s also another way where we can start to integrate with platform to platform. We call that applications or ecosystem applications, and they’re a little bit different. We’ll talk about service now because that’s our first one. But really, when we talk about APIs, we’re really talking about external self-service.

Rich Martin • 30:14

How can we allow other systems outside of Itential to access our automations and run them in a safe and secure way? Well, applications gives you another more streamlined method of integrating with a very specific platform that you may be using in your environment. ServiceNow is clearly one of those. let me log back in here, an ecosystem application is something that you would install on the other platform to give you access into the Itential platform to run automation. So in a way, it’s similar to APIs, but it’s more streamlined. It is something that Itential writes and publishes in that ecosystem storefront, or whatever their storefront is. So if you go to ServiceNow, if you’re familiar with ServiceNow, they have an app store.

Rich Martin • 30:59

If you go to the app store and search for Itential, you’ll find our application. It has been validated and verified just to even be in the ServiceNow store by ServiceNow. So it’s credentialed by ServiceNow. It’s installed in their platform. And with a little bit of configuration, now it exposes the automations that we have published in Operations Manager into the ServiceNow platform and makes it simple now to do self-service in another platform. I’ll show you that. This is our ServiceNow instance. I’ll show you from the main menu or the main dropdown here.

Rich Martin • 31:36

Once that application is installed, you have access as admin. I have access to several other new Itential items here. But the one thing we really want to take a look at is this Itential Automation Services. This is the result of installing the ServiceNow app in ServiceNow that connects back to Itential and then configuring the credentials for Itential service to access the Itential services in our platform. Once that’s done, we can connect to an instance, and the instance we’re using here for this demo is this one. Once that’s done, it does a live API call into our system and the workflow that we’ve published as an automation should appear here. Remember, it was called webinar, build a workflow, but it’s not.

Rich Martin • 32:24

The reason why is because we haven’t given it authorization. While we have access to talk to the system, the account that I’m using in ServiceNow doesn’t have authorization. We can do that here by updating this. The account that we’re using in ServiceNow, it belongs to group EAS, demo as a service is what we call it. I save this here. Now, if I reload here, we’ll reselect our on-prem lab. Now, when I select this automation, our webinar build a workflow as a service exists, and it pulls up the form.

Rich Martin • 33:04

It’s technically using the manual method that we’ve published because it’s associating a form with it. Because what we’re actually doing with this application, and this is what makes it so streamlined, is our app is written so that not only does it access the list of automations that are published that we have access to now, but it also pulls the associated manual forms that were associated with the manual entry for this, and then it builds the forms in the ServiceNow platform so that it can be populated and run manually. I won’t run it here. We’ve run this 100 times in our series here. But you can see now this opens up self-service inside of ServiceNow, given I have the proper credentials and authorization that are defined in Operations Manager, and a portion, of course, is defined in ServiceNow as well. With that, I just want to say thank you so much. I know we’ve covered a ton of territory, but hopefully this has been valuable to you.

Rich Martin • 34:03

Hopefully, this is something you can reference in the future if you want to go back and look. Of course, reach out to us if you have any questions. You can contact us with the information here. We look forward to future webinars and helping you guys out in your automation journey. Thank you very much.