Rich Martin • 00:00

Hello, everyone. My name is Rich Martin, Director of Technical Marketing at Itential. And I want to welcome you to another Itential webinar and demo. And for today’s session, we will be talking about GitHub and really using it as a common data source with your network automations in the Itential platform. What we will be going over today is pretty straightforward. I wanna show you how we first do an integration with GitHub. I’m gonna show you the fact that we have an adapter that’s already available.

Rich Martin • 00:30

I’ll be using that, but I think it’s also important to understand how you can self-generate an integration with GitHub and really any other tool or system or platform that you want to automate with inside of our platform. So I’ll show you that process. Then we’ll take a look at those tasks that now are available to us from that API specification file from GitHub and how we can start to utilize those in a visual workflow canvas. And we’ll start to build out that workflow canvas a step at a time so you understand the fundamentals of how to get started. Then we’ll use a data transformation task to extract and format data. And I’ll show you and step you through how we build that and why it’s so important to have these as part of your automations and how to solve this problem of data formatting in a reusable and visual way in our platform. And ultimately, we’re gonna walk away with a couple of very straightforward workflows on how to read, do other tasks like read a file, update and create files, as well as how we can integrate them into a network automation.

Rich Martin • 01:35

And then we’ll be using this iterative technique of building and running and testing the workflow in an area of our platform called Operations Manager. Thank you. And so what that looks like from a high level on the right-hand side here is that we’ll be doing an integration with GitHub to our platform so we can utilize that to build an automation so that we can make changes on a Cisco device, which is available through another part of our platform called Automation Gateway. And with that, let me share my screen and we’ll get started. Okay, so let’s start off with onboarding and integration into a system and I’ve logged in and this is kind of the main home screen here and I go to admin essentials. This is where you administrate different features of the platform. You’d have to be in an admin to get into this.

Rich Martin • 02:34

And so what we want to do here is go through the process of self generating and integration into GitHub specifically using an open API specification file. So this open API specification file is published by GitHub or any other vendor. Again, this is a universal thing you can do with any platform, a vendor in your IT ecosystem. If you can get an open API spec file or swagger spec file, or even you can generate a set of postman calls to that particular set of APIs for that platform or system, then you can do an integration. You can self create an integration and the process is pretty straightforward. Assuming you have that file, we’d click import here. I’m going to select this dropdown and select integration model.

Rich Martin • 03:27

This is where we now will import this file, this JSON file into the system. And right here, I have the API GitHub. That was the last one published by GitHub. And that was pulled directly from their GitHub site that they posted. Once I have it integrated, it brings it into the system. I can click validate. It’s going to validate since it’s a JSON file, it can validate it and ensure that the integration model is valid.

Rich Martin • 03:55

It reads the name and the description, as well as all the API methods and tasks from the file itself. Once you do that, you click Import. Now, once it’s imported, it’s just created an integration model. You now have to instantiate the integration itself, and that’s where you would do things like I would click here to create an integration, and that’s where I would select the integration model I want to use. I can call it Webinar GitHub. And this is where you would also fill out, once the integration is done, you would fill out things like, you know, the URL, the port, the authentication methods, things like that. And this is universal for anything, any types of integration you want to generate into the different systems that you have available to you that you want to automate.

Rich Martin • 05:01

I’m going to take a step back and let’s take a look, a little look at the integration model itself because it gives us some really interesting things to look at that are very helpful once we start building automations. And again, I’m showing you the process of doing this, but we actually have an adapter that’s available. And so what’s the difference between an adapter and an integration model or an integration you generate? An adapter is available through a prebuilt library that we as Itential publish to all of our customers. As long as it’s open source, you can go and browse it from our website. It’ll take you to where it’s published in GitLab, so you can kind of peruse it as you will. But we publish a bunch of adapters as well to different systems, whether they’re networking or IT ecosystem type systems, or…

Rich Martin • 05:45

pre-built automations for different use cases, other things like transformations, which we’ll talk about today. These are developed by us and published by us so that you can use them and they import directly into the system. The advantage of an integration is, well, quite honestly, you don’t have to wait for us. This is a great advantage for our customers. It runs alongside one of our guiding principles, which is our customers need to select the right tool for the right job for them. This allows them to now generate through an API spec file or a Swagger spec file just like we did, integrations to any system. As long as that vendor publishes them, what you start to do once they’re imported is now you can start to see all of these API endpoints that have become available in our automation platform.

Rich Martin • 06:34

It’s always useful to go through this, especially as you start to automate these different systems, especially if you’re a network engineer coming into the world of network automation. Eventually, you’re going to move from just automating network changes to integrating things like data gathering. In this case, why would we use GitHub? Well, GitHub has a lot of uses. It’s an entire platform to itself. Typically, it’s great for, and it’s used primarily for programmers and maybe your DevOps team. But as network teams start to kind of get into network automation, what you’ll find is there may be a lot of centralization of files and processes around GitHub.

Rich Martin • 07:19

And it’s a great place to maybe start to store some files that could be useful for configuration changes. The first things that always pop up with our customers is, hey, we’re using GitHub as kind of the data store or a source of truth for things like ACLs. That way, we have a singular place where we can make changes that get applied to all the other network devices. Typically, we have to do something like log into GitHub, copy and paste that ACL, and then feed it to a script. or do the changes manually, feed it into a notepad, and then we can make the changes on network. But it gives us an authoritative place for the most up-to-date ACLs for different devices. This also gives you the ability to identify who’s making changes because that comes with that platform and different versioning and things like that. So the idea here is, well, if you’re starting to make network changes,

Rich Martin • 08:13

and you’re still doing manual process of data gathering, then you should be able to automate that too. And that’s what this is going to be about. So even though there’s so many features, and I’m sure at Itential, we will be uncovering a lot more of webinars and details on things you can interact with and automate with through GitHub. One of the basic primary foundational things is how do we pull files? How do we pull authoritative information from files that are stored on GitHub? And that’s what this is about. And so it’s very useful to kind of peruse through a lot of these, once the integration model’s done, you’re given the ability to take a look at the documentation and to figure out what exactly is available to us.

Rich Martin • 08:52

And as you can see, there’s a lot available to us. And so I would also recommend looking at GitHub’s REST API, their website as well, to kind of figure out what’s available to us and the process that you would use in order to do things like access files in a repo. It will take a little bit of work, to understand the documentation. It will also take some time using the platform itself. So we’ll spend a little time in the platform as we automate some of these steps to show you where data comes from. But you really do have to get your mind into like, what are the steps to automating it?

Rich Martin • 09:25

And at the end of the day, I’ll give you some shortcuts here. One of the things we wanna do when we take a look at automating GitHub with a massive amount of things we can do, if we wanna do something as simple as accessing and updating files, that’s gonna be under this repos section. So as I was kind of minimizing a lot of this, you can see they’re put into different sections. And so it makes it easy as you start to research the documentation to say, oh, okay, under repos, this is where I start accessing files individually under different repos themselves. And so this is where we’ll spend some time pulling these tasks. And every one of these has a definition that allows you to do some sort of function. So this is an API call coming from the open API spec, and they will now become available to us on our visual canvas as tasks that we can drag and drop.

Rich Martin • 10:19

So we wanna take a look at that and understand that it’s important to look through that documentation as well. Now, before we start building an automation, so we can onboard something. Now, before we start building an automation, let’s take a quick look at the repository I’m going to be working from. Now, I’ve just created a GitHub instance just for this particular demo. You’ll see here as I’m the owner, I’ve created this name, RMITNL. I have one repository. We’ll click into that.

Rich Martin • 10:49

We’ll see it’s called network. It’s private. We would set up our credentials and Itential once we’ve created the integration model. You can use username, password, or you can generate a token from inside GitHub so that it can be used in Itential. But once you have access into these repositories with that particular authorization, then we should have access to be able to view open, read, edit, or even create new files. And so that’s some of what we’ll be doing today.

Rich Martin • 11:18

So here I have the repository open. This is the repository name is Network. And I have a single file in here. I’m calling it iOS ACL. And this is going to be a fairly typical example. And again, it’s a demo. This is not a real ACL.

Rich Martin • 11:32

It’s just to show you, as an example, some of the data that can. And we have customers storing in their GitHub repository for things like ACLs. The sky’s the limits, right? You could put inventory in here. You obviously could put ACLs for all the different vendors, operating CLI vendors and their operating systems in here. All of this is available. The key is, how do we get an automation to go in and pull that data out when we need it as part of a network change?

Rich Martin • 12:00

So I’ve created this demonstration ACL here, just so we can use that as an example. So I’ll go back to this. Now, let’s go into another section of the Itential Automation platform, where we start to build automations. And that’s called Automation Studio. So once we’re in Automation Studio, I want to create a new workflow. So doing that is pretty straightforward. I go Create.

Rich Martin • 12:27

I have a dropdown that gives me a lot of different elements to create. In this case, it defaults to Workflow, since that’s primarily where we’ll be spending time in here doing. And I’m going to give it a name called Webinar GitHub. And file. Create, and it’s going to give me essentially an empty canvas with a start, an end, and then the ability to start dragging and dropping tasks from the left-hand side here. And so on the left-hand side, you can think of it as a bit of a palette. Everything that’s been onboarded, either through an adapter or through the integration process that we just went through, is available here on the left-hand side.

Rich Martin • 13:09

You’ll see not only is that GitHub integration popped up here, but the adapter that we also have onboarded here. Since the adapter itself is already configured with the right access and authentication, I’m going to be using that. And if I click down into it, you’ll see under GitHub all of the different API tasks or tasks once they’re on the visual canvas that are available to us. This is what we just kind of browsed through a moment ago in Admin Essentials when we onboarded the API file. Now, these all become tasks that we can drag and drop here. And a lot of times, the fastest way is to, once we understand which tasks we need, remember it was under Repo. That’s where you kind of edit, modify, read different files.

Rich Martin • 13:49

That’s where you want to go. And sometimes searching it is quick. So to save some time, put Repo. Let’s see, repos owner. So you’ll see here under Git, this is using the GitHub adapter. What we want to do is get the tasks that we’re looking for here. So put repos by a particular owner.

Rich Martin • 14:15

And then this allows us, well, in this case, this allows us to create a file. Jumped ahead a little bit. Actually, what we want to do first is get. The get repos is the one we’re looking for. Get repos, we need repo content, owner repo content. Owner repos content. Okay, so this allows us to get the contents of a file.

Rich Martin • 14:52

Let me zoom this in a little bit too, so you can see a little bit better here. I just dragged that in, so this is associated with an API call into GitHub that has been onboarded to the system. Now, it’s represented as a visual task, I can drag and drop into the platform. In order to get this workflow started, we drag a transition line from start to the task, and then one to the end. This gives us a starting point and an ending point and a single task to execute. And now that I have a task on here, a task doesn’t run necessarily by itself, it needs a certain amount of data in order for it to run. So double-clicking the task will pop up a list of the data that is required.

Rich Martin • 15:35

And of course, this comes from the API, the open API spec file. It specifies in that JSON what data it needs, and so we’re representing it here. The first thing I like to do is I just like to rename this something, like get ACL data. So that’s a little bit easier to understand as we kind of build out a workflow. So here we have the owner. And so where does that come from? It’s a required field.

Rich Martin • 16:06

And so the owner is essentially what I showed you here, RMINTL. So I’m back on GitHub. This is where it comes from. It’s going to specify the owner that we should have access to that repository. ITNL for Itential, RMITNL. The repo itself, what is the name of the repository? In this case, it was network.

Rich Martin • 16:30

OK, under Param Path or Path Parameters, this is going to be the name of the file that we want to access here. So if I go back to here, you’ll see that I’ve named the file iOS underscore ACL. So that’s what we’ll input here. And then Path Parameter Query, we don’t need to add anything to here. And then the last bit here is a reference. This is the string name of the branch. By default, it will be OK.

Rich Martin • 17:02

But if we want to start using different branches or different versions, we can call it main, because that’s what it’s called here. It’s on the main branch. If I left it empty, it would be perfectly fine as well, because it would default to whatever the default is. So if I close that, now I can save this. And in a single step, we’ll be able to now access that very specific file. Now, all of this is statically assigned, you’ll notice in these variables. As we start to build out a little bit more complex workflow, we’ll start to see how your data necessarily isn’t always going to be statically defined.

Rich Martin • 17:40

It can come from dynamic sources, things like that, other API calls into other systems or other functions in the platform. So from here, I can, as a test, as a way to test it really quickly, I can hit this run button right here and we can run it. And of course, this is the way we would test it as we’re iterating and developing. And so this takes us to Operations Manager where we can take a look at the job running as each task is executed. Of course, this is an API call directly to a system, so it’s gonna happen very, very quickly. You’ll see this checkbox once it’s run and it’s run successfully. And unlike where we’re building the workflow, if I double-click this now, it’s gonna show me the variables that were passed to this particular task in the workflow.

Rich Martin • 18:23

This should look familiar because this is what we just all filled out. So this is data going into the API call, which is this task. So this is what we fed to it when we double-clicked it and we were starting to fill it out. And then more importantly than that, we wanna see the data that was coming out of it. So as that API call was successfully made, GitHub returns data back to us and that data in this case is not just the ACL information from the file, but we get a lot of other information here. And this becomes important to understand because we’re going to use this data in a moment, but we don’t need all of the data.

Rich Martin • 18:59

Really, we need this piece of the data, this content and all the other stuff. While it may be important for other functions, if we’re going to apply this to a Cisco device, we really only need this data and we need it put in a particular format that’s acceptable to making a change on a Cisco device. So we’ll get to that in a moment. But this is your very first step into grabbing data, authoritative data from a GitHub located file in a single step after we’ve onboarded this into our API. So that’s Operations Manager. I’m going to leave that open because we’re going to access that data in a moment. I’ve saved this.

Rich Martin • 19:36

So now let’s do something different. So we’ve gotten information. It’s just as simple also to create information on a file, create a new file in the GitHub repository and populate it with some data as well. So we’ll do that next. And we’ll create a brand new workflow. We’ll call this Webinar GitHub and we want to call this Put File. Create, this will open up a new one.

Rich Martin • 20:16

Similar to what I just showed you a moment ago, in fact, I pulled the other task instead first. This is going to be put repos owner, repo contents, I drop this one down. This is the one that creates a file. Let’s take a look at what the values for that are defined as. We’ll zoom into that a little bit so we can see it. I’ll double-click this. The put is a create that, again, comes from the API spec that GitHub has published.

Rich Martin • 20:55

You’ll see some very similar fields here. In order to put a file, we need to know what the owner of the repository is. This will be the same, RMITNL. It’s what I’ve defined it as. Which repo, I’m going to put it in the same repo, network, path parameters. This is, and when we were getting a file, this was the name of an existing file. In this case, it’s going to be the name of the new file we want to create.

Rich Martin • 21:20

So let’s just call it test.txt. And now we have a new one called body. So this is a set of data that we need to pass into the API call. Before we go here, I’m going to show you something as well. This is defined as an object. Again, this comes from the API, the GitHub API, saying if you’re going to make this API call, you’ve got to pass us a field called body. It’s got to be an object.

Rich Martin • 21:50

And so that’s what I’ve pasted into here, and we’ll take a look at it. This comes from their documentation. So in order to understand what the body looks like and how it should be set up, in fact, there’s a lot of fields that you could set because GitHub is a very deep platform. There’s a lot of fields you can set when you want to put a file or create a new file and populate it with data. But the minimal amount defined by them is you need to have something called a message, and this becomes the message for the commit. And then, the actual content for the file itself.

Rich Martin • 22:19

And in this case, it’s just a text file. So I’m just populating it with two sentences. This is a new file and I formatting it because this is important as well. Every different system is going to have its own way of handling and requirements and formatting of different API calls into the system. And when you’re creating a file, GitHub has its way of formatting things. So in this way, if you want a new line, you have to represent it with a backslash N, which is the new line character that it will translate it to. So in this case, you have to know the formatting.

Rich Martin • 22:55

This is going to be unique for GitHub. It’s going to be unique for ServiceNow. It’s going to be unique for Jira and all the different systems. This is part of understanding and researching that documentation so you know how to format something so that it looks correct in the system. So in this case, I’m just giving it two sentences. This is a new file, new line created by an Itential automation. And that’s what I’m passing to it.

Rich Martin • 23:16

So this is a JSON object. It’s formatted as a JSON object. So it meets the requirement of it being an object as defined by the API call. It includes two different keys, message, which is defined and content, which is defined, which are requirements based off of the API call documentation, saying we need at least these two things. And there could be a multitude of other fields that are available, again, available in their documentation. But as a minimum, we configure these two and define these two, and we should be good to go. And so now if I save it and we run it from our test environment here.

Rich Martin • 23:52

it’s going to make an API call into the same GitHub repository. You can see we got the blue check, so it finished and it finished successfully. If I double-click it, again, the incoming variables should be very straightforward. This is what we just input into the system. What’s really important for us to understand is the outgoing variables. In this case, it gives us the I-code, which is a successful code that everything was committed correctly. We can always validate that by going into the application.

Rich Martin • 24:23

I’m in the RMITNL network repository. This is where we told it to create the new file. If I refresh it, we see our test.txt, which is what we defined as the file name. If I click on it, this is the contents that we defined in that API call. We did an automation, a very simple automation, single-stepper to show you how you can get started with the foundations and fundamentals for this. So we’ve read a file, we’ve created a file, updating a file is basically the same. It’s just updating the contents of an existing file.

Rich Martin • 24:57

So we really don’t have to spend much time. And quite honestly, most of the time you’re going to be reading authoritative data from a file in GitHub when you’re doing this in a network automation. There could be times when you’re initially populating and that’s why I wanted to show this. Maybe you’re gonna extract some data from a set of routers or switches on the network and now you can push them up, push those configs or some network state into a file and save it onto GitHub. These tasks will help you and accommodate that so that you can do those types of automations. The next part of this is now we’ve been able to read something, we’ve been able to put something in GitHub. Let’s now start to tie this to a network automation because really that’s what this is about.

Rich Martin • 25:45

Automating network changes is a great first step, we call that task automation, but really you want to start layering in all of the other parts of the process. One of the parts of the process that leads up to automating a network change is gathering data from authoritative sources. You might have multiple, you might have one depending on what your environment looks like. In this case, we have customers who do store a lot of ACLs on GitHub. That’s their platform of choice, that’s the tool they want to use, and we want to accommodate that. We make it easy to accommodate that by allowing you to do an integration to it on your own and then use these API tasks very quickly and simply to access that information. Now let’s layer in a network change and tie these two things together.

Rich Martin • 26:29

What I want to do here as soon as this reload is done, is this refresh is done, is I want to make a duplicate of this. I can duplicate or just clone this flow, and I can call it Webinar GitHub. Let’s see, we’ll just call it Update Router. So now I can leave the original one as is. I’m going to be working on this one. It already includes, obviously, the first task that we did, which is get the ACL data. As you start using the platform, you will start to understand how, as you onboard different systems, how to make changes to the network, whether it’s from a CLI device or if it’s through an API call into a controller for your SD-WAN network or something like that.

Rich Martin • 27:22

You’ll start to recognize these different features and functionalities that are available to you. Just to save time, since this is a Cisco iOS device, we have the ability to put changes on a Cisco iOS device with a task, and it is Cisco iOS, iOS config. So now I can drop this right into our workflow. It becomes another step. I’m going to leave some space between this. So this is a simple data gathering step, right? We’re getting the ACL data.

Rich Martin • 27:58

This is a step that allows us to now kind of make a config change. Again, the first thing I like to do is call this something that makes sense. I’m going to call it Update ACL on Router. So then we’re starting to look at the totality of a workflow, especially as they get more and more complex. We understand very quickly what’s going on in each step. So this is getting the ACL data from GitHub. This is updating it on the router.

Rich Martin • 28:30

Like I said before, we just took a look at, we double clicked into these two GitHub tasks to understand what data they define as required in order to execute those tasks successfully. So when we added this new one in, we want to do the same thing. We want to understand what are the required values and variables that we need to fill out in order for this task to do an update to a device with this ACL data? What is necessary here? So the first one we see here is something called hosts. This makes a lot of sense. What is the device that you want to make the change on?

Rich Martin • 29:05

Now, as for our test, we’re going to make a change on a very specific device in our lab, but you’ll see that it’s defined as an array. So an array is defined, especially because we do everything in our platform is with JSON. So to define an array in JSON looks like this. It’s the square brackets open and closed, and it could be one or more of a list of strings. It doesn’t have to be strings. They’re elements of the array, basically separated by commas, except for the last one. We can have multiple devices in this list.

Rich Martin • 29:39

In fact, we can have in a whole inventory. That inventory could even come from a GitHub file, and we could format that and create an automation that way. But we’re doing a test, we want to keep it simple for everybody to understand. I’m going to make the change on this device. I have an array with a single element. That element is the host name that’s been onboarded into our system. Because we’re a network automation platform, we have an area of our platform called Configuration Manager, which allows us to onboard an inventory of not only CLI devices, but API-driven devices.

Rich Martin • 30:10

So things like network elements on AWS, like VPCs, things like that are available in the inventory so that they can be quickly used in automations. If it’s a CLI-based device like this, I can pull the configuration. So here we have no ACLs on this device. There are no ACLs at all. So we’ll be able to use this without even leaving the platform to understand when we make changes to take a look at them and make sure that they were applied. So this is the device that’s already onboarded into our platform, iOS CSR ATL03. If I go back to our automation that we’re building out here, that’s what I’ve referenced here, iOS CSR ATL03, since that’s the known host name in our platform.

Rich Martin • 30:53

It’s a single element. Groups, I don’t have to set anything to. It’s not necessary. But the other thing that’s critical here is this section called line. So this is a variable that’s also an array. And it’s a set of commands that should be configured in the section. Essentially, what this means is we need to have an array passed to this API task that’s a line-by-line list of the config commands that we want to inflict on this system.

Rich Martin • 31:25

So, and this is critical to understand, because this is where transformations come in. All of the data that was returned from this task from this task. it, all of that data is not needed in order to make this change. So we have to extract that data, but not only do we have to extract that data, but we have to put it in the format that’s acceptable for this next step, this next task. And again, once you’re doing integrations to all different systems, those are defined by those systems based off of the APIs that they’ve published. And so it’s important now to say, okay, what is the mechanism that we need to use in order to extract that data and then modify it in a way that fulfills the requirements so that we can make the network change? And that’s why I’ve left this space. This is where we’re going to drop in a transformation, which is another part of our platform that helps you do these things. So let me save this real quick, and then we’ll get back to this and fill this out. But what we need now is a transformation that will take the data that comes from here and make it available in the right format so that we can make the change on the iOS device. So in order to create a transformation, I go back to my Create. Instead of Workflow, I select Transformation. We are going to call this Webinar GitHub ACL. I’ll call it Make ACL. and create.

Rich Martin • 32:49

Very similar to our workflow canvas. This is a visual canvas as well. We’re gonna be working side by side here. So we’re gonna start with an incoming schema and an outgoing schema. So what does that mean? So imagine those tasks again. I can flip over here and we can take a look.

Rich Martin • 33:08

Imagine these tasks, the data that comes out of this, we need to understand the format that that data is in. So there’s gonna be an intermediate task here, the transformation task. The data that gets output from this needs to be understood so that it can go into the transformation task so that it can actually extract that. And then the data that comes out of it needs to be available in the right format for this particular call. So we’re gonna grab the information that’s available from here, and I’ll show you how to do that quickly and easily and create a schema, JSON schema for that. And then we’re going to publish the data once it’s manipulated in the right format so that it fits the requirement for here. And remember this requirement we’re looking at is for lines as an array.

Rich Martin • 33:49

So essentially we need to have an array as an output that meets the requirements of the data that is contained in that ACL that we’ve pulled down from GitHub. So if I click over here, go back to our transformation, this is the transformation canvas. The first thing I wanna do is create my incoming and outgoing schemas. So the easiest way to do that is to use the data that we already have available to us from testing. So where was that? Recall when the first workflow that we created was getting the file data from GitHub. When we run that in Operations Manager, I showed you the data that was returned.

Rich Martin • 34:26

I double-clicked on this. We clicked on the outgoing data, which is the data that was sent from GitHub after we successfully grabbed that data or it was sent to us from the successful API call that this particular task. We can copy all of this data right here and infer the schema. This is a really useful way of doing it. I’m back into my transformation, I can add an incoming schema. On the right-hand side here, if I paste that information, there’s a ton of information here for sure. But what we really want to do is that is the format that’s going to be sent back from an API call for the Git file content.

Rich Martin • 35:06

If I infer that, now we can create the schema. All I really need to do now is give it a unique name, and I could say from GitHub. GitHub file, how about that? But once I’ve created that incoming schema, now it’s represented here to allow us to access each one of these elements. Then if we have an incoming schema, we also need an outgoing schema. A lot of times your outgoing schema can be a lot simpler because we’re extracting a smaller amount of data and making it available. In this case, I can click on Add Outgoing Schema.

Rich Martin • 35:45

I can give it a name, ACL data. Remember what the type was we’re looking for, array. That’s what we need to feed to that task to make the change on the Cisco device. Now I have the content that we’re looking for. Where does that come from? Let me go back to this. The ACL data that gets returned is in this field called content. The value of the key content is what I’m looking for.

Rich Martin • 36:14

But notice it’s a string, it’s actually not in an array value. When we go back to our schema, you’ll see it’s defined as a string. The content piece right here is a string. Because a string and array are two different data types, I can’t do a direct map into this, it’s a no-go. So we have to take a step to turn this string into the array that we need to pass to the iOS update command, the iOS config command. And that’s where this palette of here on the right-hand side is useful for us. We want a method that will allow us to take a string, and so that’s our hint.

Rich Martin • 36:51

We need to probably start to look under the string elements here, and split it up so that we can turn it into a list of strings in an array. And so as we continue to go down here, you’ll see pop-ups that will help us to understand what these functions do. Over time, they’ll be natural. But the one we really are looking for that will help us out here is this split. Turns a string into an array of strings by separating the string at each instance of a specified separator. So I can just simply drop this in here now, and it’s gonna give us the parameters to pass to it. If I ever need help, I can click here for documentation and get a ton of documentation on this.

Rich Martin • 37:32

But in this case, it’s pretty straightforward. We know our content is the source. So this is the string we want to break up. And our separator here, we can very easily do this by identifying those newline characters. So that’s slash n. We don’t want a limit on it, because that allows us to specify only do this for a certain amount of elements. We want all of them.

Rich Martin • 37:55

And then we can return it now as an array, which meets the data type that we need to output here and make available after this task is completed. So when this transformation task is completed, it’s going to have data coming in that matches this format, coming in from that API call to GitHub. The contents of the file are going to be in this content. We’re going to extract it in the transformation task. Using the split method, split it based off of the newline character. And then turn that into an array, which is now going to be available as a variable called ACL data. We can save that and within the transformation canvas, we can actually also run this and test it.

Rich Martin • 38:41

Because we’ve actually captured a lot of the example data when we did the infer schema from the JSON object. It captured that data and you can use it as example inputs. If we run this now, what we’ll see is the results of this transformation process. You’ll see we have an array, remember the square brackets open and closed. Then each line of the array now instead of one string has been broken up because of the split method into individual elements that we pulled from GitHub. Now it’s ready to be fed into the iOS config command. If I go back to the workflow here.

Rich Martin • 39:28

pull up our canvas. Now we can insert this task that needs to go in here that’s going to reference our transformation. So if I search for transformation, you’ll see it’s part of a workflow engine, which is an internal task to the platform. It’s not part of an API interface or anything, integration like that, or an adapter. It becomes a task I can drop right in the middle. If I double click it, I see the variables that are available. In this case, I want to just call this, I give it a new name.

Rich Martin • 39:59

Let’s see, ACL array. That gives it a name that’s a little easier for us to understand. So we get the ACL data. We make the ACL array. Then we’re going to pass it to the iOS command. So now we need to reference the transformation we just created. So we can do that here, webinar, GitHub, make ACL.

Rich Martin • 40:25

It reads that transformation file and it understands that we need that from GitHub file. So remember this object that we created as the incoming schema? It’s read that and it says, OK, I understand I need a certain set of data that was defined by the incoming schema. Where does that data come from? And so in this case, instead of defining it as a static task, we want to reference the data from a previous task. In this case, so instead of using the static like we’ve been doing by default in our testing, I want to click Tasks. So this says, get the data from a previous task.

Rich Martin • 41:01

In this case, it defaults to the previous task right before it. If we had a longer set of tasks in our workflow, we would have multiple options here of anything previous to this particular transformation task. But in this case, it’s the only one before it is this one. So that’s the only source that we can really get it from. And it’s called get ACL data, which is what we defined here. So that’s the GitHub repo call to pull the file data. So that’s where that data is going to come from.

Rich Martin • 41:31

By default, it’s sent in this task variable called result, which we’ll leave as is. And so we can save that. And so now it should pull the same file from the GitHub repo, do a transformation to turn it into an array. And the last bit is now we need to update this task in the lines to reference the array as well. So now we need to reference the output of the transformation task. So this is the line. So this is where we define the array.

Rich Martin • 42:03

It’s not static. We need to reference a previous task. It’s referencing the transformation task here, webinar GitHub make ACL. And it understands that the output, remember the outgoing schema that we created in the transformation canvas is called ACL data. So it reads that. So that’s going to hold the ACL in that array format. So we’re referencing that to use for this particular line here.

Rich Martin • 42:29

So with that, we can save it. And now we should all be good to go. OK, let’s click Run now. And we’ll run the automation. And we’ll check it out step by step. So the first step was to query GitHub for the ACL data from that particular file. So if we look at the output here, we see the content.

Rich Martin • 42:52

But again, the content needs to be put in the right format for the configuration update. So our transformation task, if we double click it, we can look at the incoming data and see that we received the content from the previous task, just like we mapped it. And then the outgoing should give us now the array that we need to feed into the iOS config update task. So if I click that now, and we take a look at that. So we’re feeding in the host name that we defined along with this dynamic data. So this came from the transformation task that we worked on. And it’s in the right format.

Rich Martin • 43:25

And if we look at the outgoing data, we can see it was completed with the 200 code, which is successful. And then we can see the data that was passed to it. And really, what we want to do is go to Config Manager. So this is the device we made the change to. If I click refresh on the config, this pulls the configuration back in real-time. Now we should be able to scroll down here and identify, here it is. I identify our webinar demo ACL that was pulled from the GitHub file.

Rich Martin • 44:02

We can take a look at that now. Now this gives you your single source for this particular ACL. Now this allows you to give access to people that should have access to this file. We can edit the file here and even add. As this now create, we add new rules to this. We can do this. We can make this 80. We’ll add this new rule into here.

Rich Martin • 44:33

We’ll commit the change, put it right into the main branch, and now we’ve added this new rule. This gives us one more opportunity to go back to our automation, run it one more time. This should pick up the change in GitHub since we just updated it. execute it again, and then we can take a look at the router task. In fact, it did pick up now that new line we just put into GitHub. So it grabbed it from GitHub, did the transformation, pushed the change to the configuration on that device. Then if we do another refresh, we should see that ACL line with the host.80 in there as well.

Rich Martin • 45:15

We can scroll down here and here’s the new line. Now when somebody updates our GitHub ACL file for this, our automation will automatically pull it down and update the ACL on this particular router. Of course, this was statically done for demonstration purposes, your inventory on our platform. We have an inventory that’s federated across many different devices, many different systems. So this could easily grow into a more complex workflow that can break your devices into groups and start doing updates so that they’re all showing the same ACL information across time. This automation could be extended to be published and run on a schedule as well. And so this opens up all the different possibilities to use, you know, the fundamental workflow steps in these tasks after you’ve done your integrations so that you can continue to build and iterate and grow this workflow into a process that’s going to be valuable for you and your team.

Rich Martin • 46:19

And so with that, we will close out the webinar. I want to say thank you very much for joining us again. Again, we’ve scratched the surface on what you can do, but we think this is a really good way to start the fundamentals on how to use GitHub, especially with reading files and using it as a data source or a source of truth for whatever information you may want to store on there. If you want information on this or more details on Itential on our platform and how we can help you, feel free to reach out. Once again, thank you very much.