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.