hello and welcome back to part two of building a cmdb integration my name is Nick Ryan hopefully you were able to get comfortable with your Source system that you're going to be integrating with based on some of the points outlined in part one of this series today we're going to be talking about understanding the data model and mapping that Source data into the servicenow cmdb data model we're going to look at these high level areas we're here in step two of our five-step process so let's go into a little bit more depth of how we're going to go about understanding the data model and so we're going to take a look at the class manager which is a hierarchical representation of the servicenow cmdb it's also very useful to search servicenow documentation and not just look for classes under the cmdb section of the documentation but it can also be very useful to look at the servicenow discovery documentation and see how servicenow Discovery actually Maps into different classes of the cmdd based on the technologies that it is discovering and if you don't find things very easily that way another option is to just search all the tables in the servicenow system and so if you open up this DB object you'll get a list of all the tables in servicenow and you can pretty quickly search uh just based on the description or the name or what have you and maybe find find what you're looking for that way another important consideration here in step two is to understand do I need an entirely new class is there something that just doesn't fit anywhere in the service now hierarchy or is it just missing attributes attributes are pretty common to be added by customers for their different use cases or workflows but there are some things to consider around that which is do I want to add attributes to an out of the box class or do I want to extend an existing class and add attributes to that for my specific needs and the latter is more of a safeguard on upgrades so you're not touching the base class which may have impacts on upgrades versus if you extend that class if it is extensible not every class in the cmdb has the little check mark to say that it's extensible and we'll take a look at that here in a second but if it is you might consider just making a class specific to your company's needs and adding the attributes to that a third item that's very important and useful is to understand if you need to have a related list of data points and as we walk through our example of integrating with the Kong Gateway we'll see a number of these that we'll have some of the ones that exist currently in different places are things like serial number so that might surprise some folks but if you look at the actual table it's cmdb serial number and not cmdb CI serial number which is a little bit of an indicator that it may not be an actual cmdb class not that all of them start with cmdb underscore CI but most of them do and software instances are another one of those where it's a related list of software that's installed or found on a on a piece of Hardware but not actually a CI table and then our last steps and really what we want to get out of this entire part of the process is to come up with a document that shows us how we're going to map data from The Source system into our Target cmdb tables but let's take a quick look at servicenow instance so you can come in search for the CI class manager you click on that it'll open up this you can see the hierarchy here and start looking for what it might be that that you need so in our case we have apis and API gateways that I want to map this data into so I'm just going to start by searching API I'll see what that brings up so I can see here that there's already this API class and there's something called managed API here so that's good maybe I'll click on this it's always useful to understand the attributes here and especially um the added ones so what this means is that there's all the CI classes in the CNB have everything that's on the configuration item class and then you know as you start to build out different hierarchies there are more attributes added at each layer potentially and it doesn't always have to be the case but here let's see if there's any added so this particular managed API class doesn't have anything new let's go back and look at the API class so here there actually are some new classes or some new attributes the base URL ID type version so on understanding the identification rules also very important here knowing that this ID field is the highest priority identification Rule and then secondary to that there's a name and version combination that can be used for enforcing uniqueness I can see that this is an independent identification rule so that's important to understand as well so you can populate this API class without having to populate anything else see about this managed API so in this case it's got the same identification rules but this one is actually a dependent rule which means that it needs something else to actually uniquely identify it as well so you can see under the identification rule if it is dependent it'll have defined what the dependent relationships are so in this case I can see my this managed API class is actually dependent on an API Gateway so this means that I will have to at the same time that I'm populating this managed API I will actually also have to provide enough information that I can identify this API Gateway class so that'll actually be important let's go ahead and look at that API Gateway class to the what it needs as well so here that class it has an ID attribute it's not dependent on anything else as an independent rule see what extra attributes it might have so it just says this ID column which is actually the identification rule for it that's important I did see there was another one so actually this is convenient for our example there's actually a calm Gateway class so this has a couple of added attributes as well so that's good to know and this one also is a independent rule so it's just inheriting it looks like for the most part what was on the API Gateway but then there's these related entries which are important to understand because it means we can load in these tables and and just reference back to the Gateway itself so there's a couple of items that are specific to Kong here these other ones look like maybe they're more General in the consumer and the plug-in so so far things are looking pretty good for mapping things out how I want but the the next step is really to understand all right what do I want my data model to look like and so here there's a lot in this but going left from right this is effectively how I at the end of the process I want the data to lay out so I want to have my Gateway my Kong Gateway it'll have some apis which seem like they go more into that managed API class and then the data model and we didn't continue to explore this but we kept looking in the the class manager we would see that there's some of these other pieces that are also related to apis with these front ends and then they go to these back ends and so on and there might be multiple front ends that go to back ends and then in the case of Kong when I was doing the source analysis the first step I saw that actually a a service a calling service can actually point to what's called an upstream in Kong but it's really just a load balancer that has multiple back-end targets behind it and so this will be an important part of my data model to also understand and then these blue boxes are my related items so these related items are things that aren't necessarily CIS but they are part of the con Gateway that I want to capture and store as being related to the column Gateway so this is the the high level view of things which really now should translate into what we're really after in terms of a a mapping document and so you may start with something less complicated than this but at the end it should start to fill out hopefully so that uh when you go to actually building this integration you can actually make use of this and follow along and not just have it as a piece of documentation um so I I have a list of my tables that I want to populate the Gateway I know that there's workspaces in Kong that load balancer and targets we were talking about my managed API class back in and front end and then those consumers and plugins and so these are the actual formal table names these data sources don't have to be named exactly like this but it's useful to be able to identify them pretty easily and then as we were doing our source analysis and the first step we did find that there are all of these apis which can be used so it's useful just to list these out um in the case of the apis we're going to use in this example this workspace is an optional part of the API that can be used but it can be very useful in understanding or being able to limit what you query for so if you the workspaces in Kong are more of a logical collection that different teams may work on to to group their apis and the different constructs around it and so you can potentially limit what you import into the cmdb maybe you don't want certain workspaces to be brought in and so we'll see how that plays out when we get to building it but just to note it here that we can inject that in as a limiting point and then I have a tab for each of the each of these CI classes down at the bottom or related tables they're not all exactly CI classes but within each one of these this is where we start the process of the mapping so you know again in the the first step of the source analysis hopefully you were able to grab some example data maybe you were able to stand up an environment and run some Postman or insomnia queries or something like that or just curl commands from the terminal and get some example output and then you can take that output and start doing this mapping where we say all right this is the source system these first couple columns you know some example data in the second column but these are the source fields this is the table I want to map them to and then here's the service now attribute in the CI class that I want to use to store that data there's a couple of important things that here at the end this SNK is going to be very important when we actually go into the mapping capability Within servicenow and SNK stands for Source native key and we'll talk about that in more detail but it's important to know what this is um because it it really drives our ability to identify these as well and so Source native key is really what it what it sounds like it's a an identifier from The Source system that is unique for that Source system and so in this case there's not really something I I feel comfortable about I mean in this payload that does that and so I I actually am going to use the assist ID of the connection and credential Alias that I'll make in in the build process so most of the time when we build one of these we're going to start with a connection in credential alias so that we can move it between environments maybe from Dev and test into prod and this connection and credential Alias will be used in our um integration Hub actions that will create and so we don't have to modify those because we're using an alias so that'll be this will be important and make more sense when we get to this building phase but this transform section here also can be used to just denote you know how you might map or concatenate Fields together and so on and so we just go through that process for each and every one of the classes and you may also have notes in here for how to what the relationships need to build out like as well so it's important to to know that as well in terms of import especially when in this case as we saw the managed API actually has a dependency on the API Gateway which calm Gateway is a child of that and so we have to build this relationship as we're loading these managed apis and so it's going to be important as this note says for us to also have the connection Alias this ID available in this load process as well and so just go down the line and hopefully at the end of it you've got all of your tables mapped and can start the process from there so rounding out this is our desired states with all of those attributes mapped as we noted there and the next exercise that we'll go through will actually be to start doing the build process and I know this was a short video for the most part but I don't want you to underestimate the level of effort here this is probably the most difficult part in doing this mapping and potentially creating new tables or attributes so take your time at this step get your mapping down to feel comfortable with because it will help us streamline the next step of building out this integration all right thank you and we'll see you next time