Rich Martin • 00:00

Hello and welcome everyone to another Itential webinar and demo. Thanks for joining. Today, we will be going through how to automate your change management process with Jira and Itential. My name is Rich Martin, Director of Technical Marketing at Itential. Once again, thanks for joining. What we’ll be going over today is really focusing on how to use JIRA and automate the steps of a typical change management process with automating those processes in JIRA. Really, we’re going to start at the very beginning, how to self-generate an integration using an OpenAPI specification file. This is really important because it allows you, as the customer of Itential, to build the integrations that you need for your IT ecosystem when you need them.

Rich Martin • 00:55

We’ll talk a little bit about that in a moment when we go through that, but that’s really the first step. You need to get JIRA integrated into Itential before you can start automating any of those steps. Then we’ll take a look after we’ve integrated that, we’ll take a look at the different tasks that are now available for managing issues in JIRA and utilizing them in our visual workflow canvas. Then we’ll start to build. I’ll show you step-by-step some of the tasks we’ll use, which are the API calls that we’ve onboarded. Then I’ll show you how to use a data transformation to build a JSON payload so that we can create and modify and update these JIRA issues. We’ll eventually create several workflows, two workflows.

Rich Martin • 01:39

One very simple, showing you all the foundational bits, and then how to integrate that into a network change workflow. Then you also see this whole process will allow you to discover how we can test, view, modify, run as a typical way of building these workflows in our platform. But again, this is very specific to Jira. So the focus is going to be Jira and how we can do the integrations and automate these steps that are a typical part of your process for change management. So anytime you do a network change, there’s going to be the network change itself and then a series of other steps that are part of the process. So adding Jira to this will alleviate you as the network engineer who is now getting into automation, to not only automate network changes, but maybe all of the steps that you would typically spend in Jira creating tickets, updating tickets, moving from one stage to the next stage, and constantly copying, pasting things from the network into the ticket itself or the issue itself as part of documentation. If you look at what you can do to automate those pieces, you’re going to recover even more time by augmenting your network change automations with these steps to automate the steps in Jira ticket creation and management.

Rich Martin • 02:54

That’s what we’ll do today. We’ll spend time in the platform, we’ll take a little bit of a look into Jira as well, to give us some foundational understanding of what we’re looking for when we start to build these tasks that are using the API calls in the Jira. Ultimately, we’ll be talking to a Cisco iOS device and extracting some data from it that we can use in a Jira issue. With that, let me share my screen and we can get started. We’re starting here in the Itential Automation Platform. Again, the first step that I said we would take would be to onboard an adapter. We need to be able to get the automation platform integrated or an integration put in so that we can talk to the Jira platform.

Rich Martin • 03:38

In this example, I’m using Jira Cloud, a trial example. I just signed up for a personal trial and then did the integration. We do the integration through one area called the Admin Essentials area of the platform. If I click here into Admin Essentials, you’ll see we have some administration functions here. I’ve already onboarded the Jira and everything. For the sake of time, I’m going to take you through the process so that you can see for yourself what needs to be done. It always really starts with, if you’re going to generate your own integration, it starts with getting

Rich Martin • 04:14

finding the OpenAPI or Swagger specification for their API. If you do a couple of Google searches, you’ll find right from the Atlassian website, I’m sorry, you’ll see that they do publish the Jira Cloud Platform REST API as an OpenAPI spec. Our platform can now digest this, consume it directly as a file. If you save this as a file, which I actually have already done, then you can import this in as an integration model and then create your integration to your Jira platform from there. And I’ll show you the steps. Now, in our platform as well, we have the ability for our customers to leverage a pre-built library of both what we call adapters and automations and transformations. There is a Jira adapter that’s pre-made by us that you could also download from Admin Essentials and install and get working with your Jira installation.

Rich Martin • 05:14

However, The integration that we’ll be doing today puts that control into your hands. Again, this is very great for the end-user, our customer to be able to generate integrations to that ecosystem systems and platforms that you’re using, that you want to automate with part of your network change process without having to wait for us, the vendor, to publish an integration for you or publish an adapter for you. You’ll see when we get into the workflow canvas, we have a JIRA adapter installed for our local use, but we’re doing an integration and you can have multiple of these available within your automation platform. The first thing you would normally do is you would do import here and then I would select an integration model. This is where we take that file that I showed you from the Atlassian website where they published the integration or the OpenAPI file. You could literally just drag it into here or I’m going to click it.

Rich Martin • 06:13

I’m going to browse it from my desktop. As soon as we do that, it imports into the platform. It’s always a good idea since this is a JSON file, it can be validated and now the integration model is valid. If I click Import here, it’ll bring it into the system. It’s already been done for the sake of time, so I’ll show you the integration model. That integration model shows up here as the JIRA Cloud platform. And what you’ll notice here is that open API specification file lists all of the available APIs that have been published that are available in the Cloud Platform.

Rich Martin • 06:50

So there’s quite a few of these for sure. So we can start to take a look at some of these now. Jira Work Management Platform is an extensive platform with a lot of customization. There’s a lot of features in it. We’re going to be focusing really primarily on issues, being able to open issues, tickets if you want to call them that, updating them, things like that. It’s a great idea to browse and kind of peruse this list in this integration model section here. So you can get an idea of all of the different API tasks that now will become available on our workflow canvas.

Rich Martin • 07:27

And so you can get a lot of documentation from here. So this issue section here, again, it comes from what was published by the vendor. So when we import all of this, this all comes from that file and we expose it here. And you can actually take a look at. a lot of the details that are required for some of these. I’ll call out this under issues. We’ve got a group of API calls that are related to issues.

Rich Martin • 07:55

We’ll be using some of these. One of them specifically is to create an issue. If I click down on here, and this is a great thing for you to lock in your mind. we’re getting more documentation on what are the requirements when we do an API call into the JIRA Cloud Platform, what are the requirements that we need to pass to it? There’s some variables we need to pass to it, and some example JSON schemas or JSON payloads that we need to pass to it in order for a, let’s say, a call to create a new issue to be successful. This is where you can get a lot of the examples that we’ll be using here today. Also, the quick Google searches.

Rich Martin • 08:38

Since these are defined by the vendor themselves, we’re not defining these, we’re just extracting these fields and these requirements from their documentation. You’ll find that a lot of developers or DevOps teams, even if they’re doing something in code, maybe they’re using cURL on a command line or they’re writing something in Python or in JavaScript, they will, you’ll see if you do some Google searches, people posting example JSON objects for things like creating issues. So you can pull a lot of information from a lot of different sources that are still going to be relevant in our platform because this is, again, is standardized by the, inside the JIRA Platform API calls themselves. So you’ll see a lot of data here, and you might want to reference this back as you start building these workflows and testing these API calls. But you’ll see a lot of this here, and I’ll break all of this down as we start to continue building these workflows. So that’s the integration model. That’s actually not an integration yet.

Rich Martin • 09:37

In order to create an integration, so you can think that this is a framework in order to do an integration with this platform, but then you would actually create an integration itself. So this would instantiate an integration. Again, I’ve already built one, but once the integration model exists, you would select it here, you would give it a name, you’d hit save, and then you would create an integration. This is where we get very specific. Here’s what I called it. I called it JIRA integration for this webinar. This is where we get very specific about the access and the authentication to a particular server. I’ve created a trial server at this URL.

Rich Martin • 10:17

This is where we would point it to your particular JIRA platform instance. I’ve generated a token. Again, this comes from the JIRA documentation, the ability to generate tokens, create an API token for use by different platforms like ourselves or programs, things like that. You can follow their documentation to do that, but that’s what I’ve done here. I’ve created an API token so that we can use that here. I’ve input that here and the token type is basic. Once that’s done, the integration is completely done, and now we can start building a workflow based on the API calls that now are exposed because we’ve created the integration model and the integration itself.

Rich Martin • 10:59

That becomes available to us in our visual workflow canvas. Before we get started there, I want to spend a moment in the JIRA platform itself, because this becomes foundational and it’s really going to help you understand as you’re building these workflows and using these tasks in JIRA, it’s to understand where this data comes from, and maybe the process and procedure that’s required. Now again, Jira is a very complex and a very customizable platform. This is the default installation. I haven’t touched anything from a trial. It creates a great lab environment, but this is to give you the foundations. I guarantee you, if you’re using Jira inside of your organization, it’s going to be much more complex.

Rich Martin • 11:43

You’ll have many more custom fields, probably different status, transition buckets here, workflows that allow to transition from one to another. But when you get through with this, you’ll see fundamentally how you can access all of that and build it according to how your Jira instance and project is set up. So let’s just go through creating a ticket, because if we want to automate this process, so imagine now we’re doing network automation, we’re automating network changes, but, and that’s a great place, I always say that’s a great place to start with your network automation strategy or your journey, because it’s the most fundamental, it’s the most focused thing, especially if you’re a network engineer, as a practitioner, you’re thinking about how can I, you know, automate all of these network changes that must be done maybe every single day, maybe I’ve got a backlog of changes that needs to be done, if I could automate those things, that would be great. And once you figured out how to automate those things, the next thing you ought to be thinking about is, what is the process around, you know, that is required before I even make a change, there’s usually a pre-check and a post-check before I make, what does the network look like before I make the change, what does the network look like after I make the change, but there’s also maybe a lot of data gathering, maybe you’re looking at different data sources, you’ve got an iPad, you’ve got an inventory system, maybe you’re gathering all of that manually and copy and pasting it into different templates or text files or forms or things like that. And then there’s the time you spend, you know, if you’ve got a very mature change management process, there’s the time you spend inside of, you know, that change management system, whether it be ServiceNow or like JIRA here, updating and creating tickets. Now, all of these things you should be looking at automating because you’re gonna save a tremendous amount of time by automating these steps, by, you know, removing the need to swivel chair around, reducing air, things like that, and freeing up a lot more time as a practitioner so that you can focus on making the network better, fixing things in the network themselves, securing it, things that are quite honestly super important, but you almost never have the time to get around to it.

Rich Martin • 13:54

So now think about automating this process. And incidentally, we’ve heard over and over from prospects and now customers that are network practitioners that talk about how much time they spend in a ServiceNow or a JIRA managing tickets, updating tickets, things like that. So in many times, they’re spending more time doing that than actually making the network change. So that kind of illustrates just how more efficient your automations can be if you can start to integrate these into your network automation process. So let’s start with the fundamentals. Would you normally create a ticket? Probably, in this case, it’s an issue in JIRA, right?

Rich Martin • 14:29

So that would be something right here. So we would create something. We just call it issue one and I’ve created that. Oops, Issue 1, there we go. I’ve created that issue, now it’s giving me an issue number here. If I click to it, now if I’m doing this manually, there’s a lot of other things that I may have to fill out. I’d have to just add a description here.

Rich Martin • 15:09

We would add a description of the issue. What about assigning it to somebody? Obviously, if it’s sitting in the request, then it needs to be assigned at some point. I’m the only user on the system, so I’ll assign it to me. What about the priority? Should we have a priority? By default, it’s medium. That’s just set by the default workflow.

Rich Martin • 15:30

Maybe it’s low, maybe it’s high. These are all things we need to set. That’s what we’ll be playing around with today. I’ll show you how to automate these things. But there could be a lot of custom fields in yours as well. Things like due dates, start dates. These will be part of the business practice, and all of these things can be automated as well.

Rich Martin • 15:48

So once you create an issue, maybe it’s helpful to add comments, and these comments aren’t just comments. Maybe it’s documentation of the change, right? And so your automation should be able to, at different steps, update comments with things. Normally, you might copy and paste something in here from another data source, right? But that should be something that gets automated as well. And then finally, one of the things that also needs to happen is the ability to transition from one stat to another state, right? So we have three states here.

Rich Martin • 16:18

We have a request that comes in. It’s sitting in the queue. Maybe it’s assigned to me. Now I can move it to in progress. And then I can work on it at this point. And I should also be able to progress it to complete. Then it moves over to the complete section here when I’m finished with it.

Rich Martin • 16:38

These are typically tasks that you’re manually having to do. You’re doing something in the network, you’re updating it, you’re creating a ticket, you’re doing something in the network, you’re pasting it into the documentation, maybe it’s the comments. Then you’re moving it into the in-progress, you’re maybe doing some updates here, you’re flipping around between different dashboards, different screens, terminals, things like that. What if we could automate this whole process? According to the network changes that you’re automating as well. That’s the key, that’s the goal here. We want to show you how to be able to do that with the Itential platform.

Rich Martin • 17:12

Now we’ve got that as the background. Let’s go into the automation platform itself, and let’s go into Automation Studio. Automation Studio is where we build in a low-code Canvas automation workflows. If I go here and I can just search for JIRA, I’ve already set up some workflows here. I’ve got a step-by-step, this is a blank workflow. This is a blank canvas and we’re going to build this one step at a time similar to what we just did in the JIRA platform itself. We’re going to create an issue, we’re going to update it with some comments, we’re going to build the transitions, and we’ll just do that step-by-step and I’ll try to show you where all of this data comes from.

Rich Martin • 17:57

Again, once we’ve onboarded our JIRA integration, we have access to it from inside this task palette here. So everything that we’ve onboarded in the system becomes a series of categories and tasks that we can now drag and drop into our visual canvas. So you’ll see this, we have an instance of JIRA here, this is the adapter that we’re using internally, but I’ve onboarded this, this is the cloud platform itself. And so when I click into here, you’ll see that we have all of those API tasks that were onboarded and documented from the OpenAPI file that we integrated, now are here and we’re able to use them as drag and drop tasks. So because there are so many, it’s very helpful. We want to start with issue. Very helpful to…

Rich Martin • 18:48

There should be create issue here. Do a search, create issue. There we go. I don’t want to confuse it with the existing JIRA adapter. This one’s called the JIRA Cloud Platform REST API. You’ll see here we have create issue. This is what we investigated initially when I on-boarded when we did the integration from the OpenAPI file. If I drag it and just drop it into here,

Rich Martin • 19:16

and we’ll try to zoom this in a little bit to make it easier. I’ve got create issue as my first task. This would be automating that first step, just clicking that plus and creating an issue, a new issue. Let me make that a little cleaner here. Now, since this is an API call defined by that document, the OpenAPI document, that spec file, it’s going to have a series of required variables that we pass to it. In this case, the one we’re focused on really is this request body payload. Remember, I showed that JSON object that had all of those values in it, those keys and values in that JSON object in the Admin Essentials section.

Rich Martin • 20:01

That’s where your examples can come from. But I’m going to give you a simplified example here so that we can see how the basics of everything works. Let me paste something in here and I’ll go through it with you. From here, you can see update history. This will add something to the history file. Again, I don’t have to set this for this particular API call. We’re going to let it be here.

Rich Martin • 20:29

Body content type is handled automatically, that’s going to be a JSON object. What we’re really focused here is this request body payload, which is an object, so it’s a JSON object, and I’ll zoom into it here, and we’ll take a look at that. Again, this comes from understanding the API documentation, whether that’s in the Admin Essentials or you’re doing some Google searching and you’re seeing other people asking this on the Atlassian website under their documentation and their forums. A JSON object is a JSON object, so whether you’re passing this through our platform or a curl call on the command line or a Python or JavaScript code, an object is an object, so they will all be valid for this particular version of the platform. You can get those from any sources. The key pieces of this to understand here are, we’ll start here, we need to specify a project because if we go here, I have multiple projects, so if I’m creating an issue, which project do I create an issue with? That makes perfect sense.

Rich Martin • 21:30

If I click on itential, this is the project we want to set and it’s asking for a key. That comes from, if I click on Project Settings, you’ll see there’s a key set for IT. If I go back into Automation Studio and we look at that payload, I’m setting the project key to IT, that’s where that comes from. The summary is that title that we would normally set. Here I’m just going to say, Add VLAN to Data Center Switch. We set a description. Remember, we had to create the ticket first and then click into it, and then we could set the description.

Rich Martin • 22:02

Now I can set the description from this create issue. I’m going to set the issue type to task, that’s a default type. There could be multiple different types of issue types defined. This is one that’s by default set, so I’m going to use task here. Now I’m going to assign it to a particular person. Since I’m the only person in the system, I’ll assign it to myself, and this is my ID. Now, where does that come from?

Rich Martin • 22:24

Well, that’s a good question. There’s a couple of ways to do it. One of the ways is you could do another API query to show the IDs on the system, and then identify that ID. Sometimes you’ll need to do that. Other times you can find these things from within the platform, and this is why it’s good to go through. Even though you might be using this particular platform a lot, going in with a viewpoint of trying to understand what the API fields are asking for, you can find that in some places here. I’ll give you an example. If I go back into this project.

Rich Martin • 22:53

and if I go into this issue here, you’ll see there’s an assignee here. If I hover over this and do a view profile, this is a little tricky, but you can find the assignee ID from here. It’s in the URL. It doesn’t show you that anywhere in here, but it’s in the URL itself. Sometimes if you know the platform well enough, you can find these values that you need. The cool thing is once you find the value, they basically, it’s embedded into your payload, so you don’t have to change it or it’s embedded into the workflow or into something we call a transformation, so you don’t necessarily have to go and query these things all the time. Once you’ve figured them out, they usually stay pretty static. And remember, we also had a priority.

Rich Martin • 23:37

We can give the priority name here, so we can set the priority when we create these particular issues. By default, it’s set to medium, and we’re going to set it to medium here as well. And so that’s where the basic payloads coming from, and that’s where the data fields come from. So the format is defined by the vendor and their documentation. These are the fields that it’s gonna probably have a minimum set of required fields. This is kind of the minimum set. You might have custom fields.

Rich Martin • 24:08

Those are things you’ll have to figure out in your environment, but this is how you can go through the process of finding them. Sometimes it’s API queries. Sometimes it’s working with your JIRA admin. Sometimes it’s looking through the application itself through the front end, and you can find these things. So that’s the payload we’re gonna pass to it. And with that, we should be able to run this. and see issue get created.

Rich Martin • 24:33

From here, as I’m testing this, I’ll hit the Run button here. We’ll run this and I’ll go into what we call Job Manager, which shows us the job executing step-by-step. Since this is an API call, it immediately finished. You can see the green check mark here. If I double-click that task and expand it, it’s going to show us the incoming data. This is the data we passed to that task from when I double-clicked and we set this payload, so you’ll see that there. Then most importantly is the outgoing.

Rich Martin • 25:06

It shows us that the status was 201, which is a success. Then it gives us some other information as the output from that API call from the Jira server. Now if I go over here to the application itself, here is we’ve just automated the creation of that ticket. Along with the creation of that ticket, we set the title, we set the description, we put the assignee, we set the priority. You’ll notice that we didn’t put a comment in here, and you’ll see this with certain applications and certain platforms. This is very similar in ServiceNow. You can create an issue, but you can’t embed a comment.

Rich Martin • 25:41

That has to be another API call. ServiceNow, you can create a change request, but in the initial creation of the change request, you can’t embed a work note. You have to update that in another API call. That’s the same thing here. You’ll find these procedural requirements as you start to work in these different platforms. Let’s now extend our automation workflow and add a comment into this. Now, in addition to creating an issue, we’ll do add comment, which again is part of the API set here that you can investigate.

Rich Martin • 26:23

If I drop this into here, it’ll drop it right into the workflow. Now, if I double-click it, you’ll see that these are the variables that need to be set. Now, we’ve got something new here. We’ve got the request body payload, we’ve got the body content type, we’ve got something called expand, which we’re not gonna be using here. This has to do with rendering in HTML, but we have something here called issue ID or key that’s a requirement and it’s a string. Now, this totally makes sense because if I’m adding a comment, I need to add a comment to a particular issue. Otherwise, what are we adding the comment to?

Rich Martin • 27:00

So in this case, I need to extract the issue ID, or it’s asking for a key here, from this create and add it. And so make that available as a variable to use here in this comment. So I can’t go directly from here to here. I have to have a transition step, which extracts that data from the create issue API call and makes it available to the add comment call. So then we can append the comment to a previously created issue. And so that’s what we’ll do now. So we can do that.

Rich Martin • 27:30

There’s a variety of ways to do that. But one of the simplest ways, especially for something like this, is to use a query in our platform. So this is another task that’s built into the system under workflow engine. So if I drop this onto here, And it’s going to attach that to our workflow. And now if I double-click Query, it’s going to ask us for a couple of variables here. It’s going to ask us for a query.

Rich Martin • 27:53

And this is a JSON query. So everything we do in the platform is represented. All data is represented as JSON, as a JSON object, because it makes it very, very easy to extract data, manipulate data. It’s really easy for a human to read as well. But it’s really easy to extract data, manipulate data for machines, programs, automations, things like that. So everything is going to be represented and passed as JSON objects. And we have webinars that go through the basics of JSON objects if you need a refresher on that or if you want to understand those more.

Rich Martin • 28:30

But we try to simplify it as much as possible. But in this case, we just need to query. We need a string to query for. And I’m going to show you what that looks like, what we’re going to put into here. And then we need to know the object, the JSON object, that contains the data that we’re going to try to extract. So the query allows us to extract. this key that’s going to be part of the output of this APK call so that it can be used as the input or at least one variable of input into the add comment call.

Rich Martin • 28:56

We’ll learn a little bit later, we can use transformations for this and much, much, much more, especially when we have multiple steps for manipulating data into different formats. But for this query works really, really well. So how do we get started? So first, we know create issue requires, well, I’m sorry, add comment. So if I double click that, needs an issue or key. So we need to identify where that comes from as the output of the create issue. So if I go back into our operations manager and this is the completed job, right?

Rich Martin • 29:29

So if I double click on that, we get to see the variables that were incoming and outgoing. So we looked at that for a moment. Now let’s take a closer look at this. So what we really want to do is we want to find where this new key is passed back to us or this ID. And in this case, it’s represented in several places, but I’m going to extract it from this section right here, object OBJ. So, and then ID holds this new key. So this create issue, when it creates, it’s going to pass back to our workflow, this data.

Rich Martin • 30:00

And if we could extract OBJ and then under OBJ, it’s kind of a hierarchy. They have got a field called ID or a key called ID. If we can get what, if we can extract that information, then we’ll have exactly what we need to pass to the add comment task call. And that’s exactly what the query is going to do. So if I double click here, the query is simply OBJ.ID. I’m sorry, is that ID or key? Let’s double check.

Rich Martin • 30:29

Let’s use key, let’s use key. Either should be fine. We use OBJ key. And now we’re back to our object here. So where’s that data coming from? So now the object is of this query is, okay, you’ve told me the key to look for. Where is the object?

Rich Martin • 30:49

Where’s the data set? And it’s going to, we’re gonna reference the data that gets returned from this particular task. So we can define it to look at a task. It’s gonna say the previous task is create issue and the variable that holds all of that data that we just looked at in operations manager is held in this variable called response. So we’re referencing that. So it’s gonna say, okay, grab the output from this and then query for this object.key. And then when we find that, we make that available so that the ad comm can now use it.

Rich Martin • 31:22

So now with add comment, we can reference this query task and extract that key, well, reference the key that was extracted. So if I hit task by default, it defaults to the last task. And that task is gonna hold return data, which should hold that key, because we’ve just defined that query to hold that information. And then finally, we have a body request payload. So again, this comes from the documentation. It can get a lot more complex than this, but I will paste in the very basics that you need. And all we need really is the body to hold the string that we want to add as a comment, in this case, added this comment to this issue.

Rich Martin • 32:01

So now if I close that, save it, all right? Now we should be able to run this and take a look at it again. If I run this, it’s going to open up another instance. You’ll notice here, it created the issue. We did the query task step, so that should have extracted that key, and then we added the comment. If we go to our board, all right, here’s the latest one, IT 62. If I double-click that, you’ll see all the things that we initially set up when we created the issue and now we’ve added the comment to the issue.

Rich Martin • 32:35

This is that second task that we added. Now, we have the ability to create an issue, populate those fields on the initial creation to add a comment. This comment could be useful for adding documentation. The next thing we need to do is to be able to progress something to another step. I’m going to clean this up a little bit. We’ll delete some of these. Now, we’ll add on to our automation, create, we’ll do the comment, and then we’ll progress this to the next stage.

Rich Martin • 33:12

Let’s go back to here. We’ve got our create, so we’re going to add one more to the bottom piece here, so I’ll extend this out. In this case, moving from one stage to another is called a transition. If we do a new transition, You’ll see under the JIRA Cloud Platform REST API, we have this do transition here. I can drop it on our workflow, and if I double-click it, it’s going to ask us a couple of things. Just like in the add comment, if we’re going to transition, we need to know what issue we’re transitioning.

Rich Martin • 33:48

In this case, we need that issue ID. The cool thing about that is we can now reference the same query that we’re referencing here to get that ID. That’s a task. If I click task, and now it’s going to say, which previous task are we going to reference? We’re going to use that query data, and then the task variable by default is the return data. Now, we’re referencing the right ID. Body content type is JSON, and now we’re asked another payload. Then let me paste that payload in, and I will.

Rich Martin • 34:19

I’ll walk through what that looks like. So in this case, the payload is, again, defined by the Jira platform in their OpenAPI doc. This, it could get more complex than this. And you’ll find, probably, as custom workflows and a workflow in Jira is not to be confused with a workflow in our platform, a workflow is that process of how things can go from one stage to another. And every transition, so when you go from one stage to another, is given an ID. In this case, how do you get the IDs? It’s a little bit trickier.

Rich Martin • 34:52

There’s an API call that can show you the IDs for a transition that are applicable to a particular issue. That’s where I pulled it from. You could also, in more complex workflows, go into the workflow editor and see the transition numbers that have been assigned. Those are a couple of ways to get it. Here, you could create another test workflow. I think it’s called Get Transition. Yeah, Get Transitions.

Rich Martin • 35:23

You could create a one-step workflow, fill out the variables for this, and show the transitions so that you can get an idea of what the IDs are. That’s how you would get that data that you have to pass to it. But in this case, this defines, 31 ends up defining the transition that moves it from the first bucket, which is a request, into the second one in progress. And really, once we have that, that’s all we need. And so if we save this and run it again. Going back to Operations Manager, which shows us the job executing, it’s finished. Now, if we go back here, we should see, well, because it already transitioned, it started here like we saw earlier, but now we’ve added that do transition step and it moved it to in-progress.

Rich Martin • 36:09

Then there’s another transition number that would move it to complete. If we did a second do transition, and that particular number is 41, that would move it from in-progress to complete. If we double-click this, we should see all the same things that we’ve seen before. Title, Description, Assignee, Priority, Comment, and now we have the ability to transition from one stage to the next stage. Really, this gives us the foundation for now integrating these types of automation steps into a network change automation workflow as well. Because now we can create an issue, we can assign it, we can populate it with fields and data, and then as we move it to in progress, you’re actually starting to do the work in your automation. Maybe you’re pulling some information from the network and assigning it into a comment.

Rich Martin • 37:03

That could be part of the documentation of what the network looked like before. You can actually make the change, document that in comments or some other field if you have custom fields, document what the change looked like after, what’s the network state look like afterwards, put that into a comment, and then when it’s complete and final, you can progress that to done or completed in the same automation, and you’ve saved yourself all of those manual steps that you would normally apply before you did the network automation. So you could run the automation, but you’re still doing a lot of steps even in the middle of the automation perhaps, or if you’re doing everything manually, you’re really bouncing between multiple dashboards and consoles and things like that and terminals to be able to do all of this. And so that’s the real benefit of this. So now let’s take a look. at what this would look like built into a network automation workflow and how we can extend the typical network automation into integrating all of these change management steps and how that looks. So I’ve already built this out.

Rich Martin • 38:13

This is a very simplified workflow. I’ll zoom in, and we’ll go step by step. But you’ll see that all the work we’ve already done just a moment ago with just those. a handful of steps are represented here as well. In this workflow, you’ll see I’m using something called a stub. A stub task is a task that’s available here, just like all these other tasks are available in this palette here. A stub task is really great for as you’re starting to build a workflow out, and you’re just stubbing out the steps.

Rich Martin • 38:42

You’re just saying, okay, step 1, I want to do this, step 2, I want to do this, step 3, I want to do this. You could use a stub task, they’re just placeholders. They don’t really do anything other than placehold, but they also have the ability to cause a delay, and I wanted to put a couple of delays in here so we could watch this progress from JIRA itself. So the first step is a pause. In an actual production workflow, you wouldn’t necessarily put these pauses in unless they were maybe intentional for different parts of the process. Maybe the pause wouldn’t be just for a number of seconds, but the pause would be for something to get done or manually a ticket to be moved or some sort of approval or something like that to happen. Those would not be stubs, they would be different types of tasks.

Rich Martin • 39:22

But sometimes you might want to put pauses in, but for this case, it’s just for demonstration purposes. So I put a pause in for five seconds before we create the issue. That gives me time to flip over to the JIRA board when we run this and you can see the whole thing progress. So the first thing is create issue. This is exactly what we did before when we created that smaller workflow. Really, I’m passing to it. the payload that was required.

Rich Martin • 39:47

Using the same fields, a little bit different though, I’m just giving it a different summary. This is more like updating a route table. The network automation change we’re doing is we’re adding routes to the route table. The description could be very specific. I’m adding this route to this particular device. It’s already assigning to me, we did this earlier, and then I’m setting the priority high this time. That would be creating the issue.

Rich Martin • 40:10

Of course, because we have to do other things that reference that particular ticket, we need to create issue data so that we can get the object ID. I’m using the ID here. We also use the key. Before, you can use either or, but you see how this is useful. Now that we get that, this particular task can be referenced later on so that we can reference the issue that we’ve created for this particular automation. The next thing we need to do here in this is, I’m doing a slight pause so we can see this when we view it in the JIRA platform. But the next thing I do here is a transition. We’ve done this before.

Rich Martin • 40:47

I’m transitioning from the request stage to the in-progress stage. We’ve assigned a person to it, me, and now the automation is going to actually do the work. We’re transitioning to that next stage because that’s part of the business process. Of course, we’re referencing the query that we’re using for the JIRA ticket ID here. So here, we’re doing the transition from request to in-progress. That’s the 31 we’ve done before. Now, we’re doing something a little different here.

Rich Martin • 41:24

We’re running a command template, and so I’ve labeled this get data before a change. Normally, in a change process, manual or automated, you’re going to do a series of pre-check and post-check steps before you just blast out a bunch of changes. You want to make sure something in the network looks right, there’s nothing out of ordinary. We have tools and functions and features on our platform to build this process out as complex as you need it to be or as simple as you need it to be. One of these tools is something we call the command template. We’ve done other webinars focusing on command templates, but basically, it’s a series of CLI commands that can be run on a router or a switch or any network device, and we can capture the output, and it makes it a great way to be able to capture the output of the network state. In this case, it could be the routing table.

Rich Martin • 42:17

We want to use this data because this is very typical. You want to capture some network information and put it into the ticket. This is where we’re starting to talk to the network now. This particular command template is something that I’ve already built. It’s given a name, webinar-jira-show-ip-route. We’ll take a look at it in a sec. But we’re running this task, which runs this command template, which is going to extract the data that we need from the command that it runs, and then we’re giving it the device to run on.

Rich Martin • 42:44

In this case, this is the name of a router we have on the network. So what does that look like? This is a command template. We won’t go into details, too many details here, but it’s very simple to understand and I’ll show you. Basically, you have a series of one or multiple commands. In this case, I’m just doing a show IP route. You have the ability to create rules so that you can look for certain things.

Rich Martin • 43:09

You can search for certain things and then certain things must or maybe shouldn’t be represented in that output so that you can maybe trigger another type of workflow or a evaluation. So your workflow can be a little more complex with more logic. In this case, we just wanna output something from this device. In this case, it’s the output of the show IP route. From a command template, we can run it from here. We have a federated inventory, so I can choose this router, I can test this command, and then this is the output. When this runs as a task in our workflow, this is the output that will be available to us in our workflow.

Rich Martin • 43:46

This is what we want to capture. I want to capture this data and put it into the comments, because this creates a way to document something before a change is made. That’s what a command template is, and so that’s what this step does. It runs that template so that that output is available to us. Now, here’s the thing. We want to take that output and put it into a comment. But remember, the comment needs to be in a very specific payload type that was defined by that request body payload.

Rich Martin • 44:15

Remember, when we just built this comment, we did a JSON object and I statically put in, you know, this comment was added to this issue. Okay, so we have to take the data that came out of this, and not all of the data, just a subset of that data, and we need to put it in a format that Jira will accept as a comment. And that’s what this piece right here, this task right here is called a transformation. We did a query earlier, which extracted one bit of information that was already in the format we needed. A transformation can not only do those kind of queries, but can do multi-stage, multi-step data transformations, so that the data you’re extracting from one or maybe multiple tasks that came subsequent to the transformation can be used and formatted in a way that subsequent tasks, in this case, the add comment, can be used in the right format. So it can pass that data in the right format and update successfully when it does the API call. And you’ll notice it sits between here, it doesn’t always have to immediately sit between two different tasks, but in this case, it gives you a hint.

Rich Martin • 45:17

This transformation is going to take the output of this or extract some of the output of this and put it in a format that’s usable for this. So it’s going to extract data from the command template, put it in a format that’s usable for Jira to add a comment. So we’ll take a quick look at this. And just like many of the other features in our product, the transformations, we have webinars that go through a lot of detail on these. So don’t let this scare you. I’m going to explain it to you, give you an overview. But on the left-hand side here, we have an incoming schema.

Rich Martin • 45:49

This basically says, this is the data I expect to be plugged into this task. And you’ll notice here, I’ve named it from command template. And you’ll notice here, I’ve named it from command template. Whatever gets passed out from the command template, this is what the data is going to look like. This is the structure of the data. We get a lot of that from Operations Manager as we start to test and we can see the data just like what we did with the create issue. I said, we need to pull that object.id or object.key and extract that.

Rich Martin • 46:14

That’s what we’re doing here as part of this process. When you’re looking at that data, you’re going to say, okay, there’s a particular piece of that data that we need to extract from here, and really it’s the command results. It’s the output of that show IP route that we’re trying to do. The first thing I’m going to do here is a query. This is very similar to the query we did in a task, except I’m doing it here inside of a transformation. If I didn’t need to do any more than that, just like we did with the object.key or object.id, I could use the query task instead. But we need to do a little bit more here because we’re going to grab that data and we need to manipulate it in a way that

Rich Martin • 46:52

a comment object that we can pass to that add comment task for Jira. So a couple of things that are going on here is, and you’ll notice these might be idiosyncratic things with different platforms. When you’re passing data to a comment, whether it’s in ServiceNow or Jira or some other platform, it may not like certain control characters, right? So in this case, I need to remove the control characters for a new line, and I’m just going to replace them with a return. This will put it in the right format. So the way I do that is I create a method here. It’s very similar to what we do with our low-code canvas.

Rich Martin • 47:31

This is a low-code transformation. I can take any of these methods here, and in this case, I can say, extract this object from this query. Now we need to take that object, and I need to replace anything, and I’m using a regular expression here, anything in there with a slash n or a new line, and I want to replace it with a return character. This will make Jira happy now that it’s a comment. It won’t give me an error. Again, this is something that the Jira platform is requiring. From that, now I have a string that’s useful for a comment, but now I need to put it into a JSON object because I need to pass that into the add comment.

Rich Martin • 48:10

And remember, it needs a JSON object that has a body. key and then a value of the actual data itself. This is where I’m using a template literal. This is another step. I’m taking the string, I’m passing it to here, and this is going to format it into the right format for that JSON object. It’s going to have body. I’m putting some other text in here that says current routing table, putting a couple of returns. These aren’t new lines, but they’re returns, so they’ll do the same thing in the comments.

Rich Martin • 48:35

Then I’m passing this variable routes. Where does this routes come from? It came from the output of the replace method here. That step is now the routes. Now I’ve got a string and I’m turning it back into an object so that I can make it available as a variable, as the output for this particular task. This is a transformation. It can be simple, it can be complex, you can have multiple transformations.

Rich Martin • 48:59

The cool thing about this is this transformation is now reusable. All of the steps we’ve defined, anytime I need to take something from a command template and extract the results and put them in a comment, this can be called as a task on a workflow over and over again. This is really a reusable asset once you’ve defined it. So let’s go back to here. So that’s our transformation. So when that multi-step transformation is done, it’s going to give us the comment body for the comment we need. So we’re referencing this task, the JIRA build comment.

Rich Martin • 49:34

So this is that transformation task. The output variable is the JIRA comment. That’s what we define as the output variable. So now that comment should now be updated into the ticket or the issue with the data that came from the network router that we just did a show IP route on. The next step here is a stub. This is make network change. Because the focus of this is not changing the network, it’s really how do we integrate all of these tasks into a network change.

Rich Martin • 50:02

I’m not focused on making network changes, but this is where you would put your actual network change into it. So this could be another workflow. This could be a single network change step, whatever the complexity or simplicity of the network changes, this is where you would put it. But it’s just a stub here for time. And then finally, we’re running a command template again. This is actually the same command template as here. If I double click it, you’ll see webinar JIRA show IP route, because this would be kind of your post check after your change is made.

Rich Martin • 50:33

Maybe you want to capture this data again. Now, what I didn’t do is I didn’t add this transformation and comment into here. So we’re not updating the comment, but it’s the exact same process. In fact, you could literally copy and paste drop them onto here, change a couple of references in the transformation. and the comment, and then it would do the add comment with the after change as well. But since we’re not actually making a change, it’s just going to show the same route table. So for simplicity’s sake, how to do that has already been shown here in these steps.

Rich Martin • 51:05

But you would do that in kind of a more production environment, certainly. And then finally, the do transition. So if I double click here, we’ll take a look at this. This transitions from in progress now that the work is done, and our post check has been completed. And as we build this out, maybe you have more complex post checks, and you make sure everything’s good. Then you would go to your do transition, which would take it from in progress to completed. And again, we’re referencing our original issue that we created way up at the very beginning with a create issue.

Rich Martin • 51:35

And then we’re passing this payload that’s the ID of 41. That’s the transition from that middle stage to the last stage in progress to completed. That’s the whole workflow that we’ve been through. Obviously, we built these things in a test environment. Now, we’re adding them to a more structured network workflow where you have stages and progression. This could be the framework for obviously you getting started to being able to build these things too. Again, it’s all foundational.

Rich Martin • 52:05

Your environment is going to be somewhat different for sure, because this is the default environment. But hopefully, it gives you all of the tools and procedures necessary to start building these out. So let’s run this. Since we’ve already been spending a lot of time in Operations Manager, I’m going to go over here to the JIRA board. We’re going to take a look at this. Remember, we put some pauses in. When it creates, we should be able to see an update here.

Rich Martin • 52:29

Here’s your updated routing table. We did a comment in that first stage, and then it should do a transition to the in-progress. Once it’s done that, it’s hopefully captured some of that data, put the comments in that we’ll take a look at in a minute. Eventually, it should transition at the very end, right before it completes to the complete stage. Now, the ticket’s complete. This is the way you should be automating. This is the view you should be looking at.

Rich Martin • 52:53

As soon as you guys are successful automating network changes, start layering in some of these other processes. This is a great one to start layering in. We’ll double-click this and do a final check. Our create did the title, did the description, did the assignment, did the priority at high. Obviously, then we did the call into the network so that we could get the data from the routing table. Our transformation turned that into a comment that we can now pass as a JSON object into the add comment. Then obviously, you saw all the transition states go from one to another to another until we finally completed everything.

Rich Martin • 53:33

That ends the demo and the webinar. I just wanted to say thank you very much. Hopefully, this was helpful in helping you to understand how you can do not only network automation, but also now layer in more of the process. You’re looking more at orchestration across JIRA, ServiceNow, or your data sources, your sources of truth, your IPAMs, your network monitoring systems. Take them a step at a time, integrate them a step at a time in our platform, and start building these things layer at a time until eventually you’re automating the entire network change process. We say from ticket open to ticket close, and all the systems, and data gathering, and monitoring updates, and things like that, all in between. You can do that on our platform, and hopefully, we’ve showed you here how simple it is to get started with JIRA.

Rich Martin • 54:21

Thank you very much, and we look forward to working with you in the future.