hello there i'm emily walker i'm a solutions consultant here at servicenow specializing in the itom platform today i'm going to present a quick video on top down approach to service mapping which includes both pattern and traffic based service mapping here's our safe harbor notice for today we won't be discussing any road map items but this is just a friendly reminder so what we're looking at here are the three different approaches to service mapping these various approaches can be used in combination for what works best for specific application services within your company today in this video i'm going to dive deeper into top down which is a mix of pattern and traffic based we're going to look at both of these individually and how they work together so top-down discovery is more of that traditional method of collecting data about devices and applications that are used in application services top-down mapping is also traditionally used for on-prem and legacy applications and has the benefit of giving the most accurate and detailed service maps like all three of these approaches after service mapping collects data it then creates a map of the application services and stores the collected data in the cmdb we'll talk more about traffic and pattern-based service mapping and the advantages and disadvantages in the next slide and then we'll jump into a short demo so here we have partner one in our top down duo this is really our bread and butter here a pattern is essentially a series of steps that run during discovery whose purpose is to go out and find all of the attributes of a configuration item and its outbound connections so as discovery is going out to map an application the pattern is telling it here are the attributes and connection points i want you to look for and then for me a map as discovery is running we're able to see in the logs specifically what patterns are being launched automatically and how discovery is getting its instructions for how to map these cis and identify the relationships between them a typical service map consists of separate algorithms for identifying cis and finding those ci connections you can think of this as casting a wide net to pull in all of that ci all of the data for those ci's that are relevant to this application and the difference between this approach and others is really the upfront time and effort it takes to set up because this is so heavily dependent on horizontal discovery this requires configuring credentials users and user permissions to let service mapping access application applications inside your company's private network this process can take time and effort and can sometimes be seen as a disadvantage but the major benefit with pattern-based mapping is that with this approach it creates the most precise and complete maps that you can fully trust so next we have traffic based mapping which is our other partner in this top down duo traffic based mapping discovers maps discovers and maps configuration items following their traffic based connection and this method complements the pattern-based approach traffic based connections look for how those ci's are talking to one another what traffic is spilling between them the tcp connections what it's listening to and what it's connecting to or listening on and connecting to and it's going to create these maps using that data with traffic we're getting more specific about what connections we have to see eyes with pattern-based mapping that's over a wide cast net where we're pulling in as much information as we can but with traffic we're getting more granular we're using a finer net to see what traffic connections dictate the relationships the other great way that traffic helps to complement pattern-based mapping is when discovery patterns fail to find cis so while traffic based discovery creates a more inclusive map it may also result in some redundant ci's that do not influence the application service and this could actually lead to cluttering an application service with irrelevant cis so because of this it's best practice to use traffic based discovery at the initial stages of discovering an application service and disable it once you've completed discovery and fine-tune your application service but again the great advantage here is that with pattern and traffic based discovery they work hand-in-hand to provide you the most precise and complete service maps and one last slide before we jump into the demo we're going to take a look at how to configure and get started with top down mapping the first step we have is to enable discovery here we want to make sure that you have an active and valid mid server running and that you have credentials set up so that you can actually run horizontal discovery and this is so important because service maps use those configuration items and data within your cmdb to build out these maps so once we have our cmd populated we're going to define an entry point so for example to map your electronic mailing application service you need to define an ip address or hostname of the email server as that entry point if you already have these services and entry points tracked somewhere maybe on a spreadsheet you can upload these in bulk as well and this segues us into the third step which is running top down discovery so basically once an entry point is defined top down discovery automatically starts and it will look for that host ci in the cmdb maybe it was already there from a previous horizontal discovery and if so great but if not it will automatically launch horizontal discovery to search for that specific ci across your network once it defines that once it identifies that host it's then going to look for those outbound connections from a pattern and traffic perspective and it's going to keep looking for those outbound connections until it can't reach anything else and it's going to present you with its initial findings of that service map after that process takes place we need to review our maps which brings us to step four here's where where you will work with your service owner to make sure that that map looks correct and then we can put it into an operational state and the last step is regularly running discovery to keep our maps current that's it from a high-level rundown of top-down service mapping let's jump into the demo portion all right so now that we're in my demo instance the first area that we're going to be starting in is this mapped application services and whether you're coming to this video either from the how-to clinic just looking for some more advanced information on pattern and traffic top-down mapping or if you're looking at this because you already own service mapping i'm not going to really jump into creating a new application we'll take a look at one really quick and then we'll kind of spend the majority of the time on patterns and traffic so again giving your application service a name an owner adding in that entry point and then from here giving it a business criticality and an operational status and then from there once you have that then you get this nice service map which gives you a full topology of those entry points as you can see right now i think i have my host view turned on yep so if we turn that off then we get a better view of exactly where this service map is taking us and we can always expand clustered items too so this is for creating a single application map if your team already has service applications defined with an entry point and a service name and these are listed on maybe a csv file you can always go into additional options and click import service map list and you can choose a csv file to upload this really helps to kind of speed up that time to value where your service maps are then being bulk imported and you can kind of just go in and fix and tune accordingly to what's actually appropriate for your organization so i won't spend much time in here the part that i want to go back to is our top-down service mapping um our application services here and i want to take a look at a custom application that i have created i actually already have this open over here on my next window and as you can see we're getting some errors over here which is fine i know that this is the case because i haven't fully finished building out this application map right now but there are a couple points that i want to go over today and so the first one is how do we understand what discovery is doing the with the discovery log and looking through those patterns so we're going to open up this clustered item and we're going to look at the discovery log and how to see what patterns were being used to discover and map this particular application service and so this is this custom application uh that i have built and so we're going to take a look into the discovery log and this is really going to give us some better insight into you know a what happened and b what is the overall process of service mapping discovery specifically which patterns were tried and executed which identification and connection sections were tried and which steps were successful and which steps failed and so what we see here in this initial incoming uh incoming connections we have this one one of mine right here and discovery went through and it tried several out of the box patterns and if we expand these we can see that discovery failed to actually identify or connect this pattern to this particular end point here and so it tries several out of the box patterns and then it finally gets uh when it finally gets to this amazon aws classic elb service we can expand that and we can see that this was successful so unlike horizontal discovery where it runs the running process against process classifiers and on those process classifiers whose condition determines true which patterns to run so here on service mapping we have an entry point which is typically what gives gives us a poor and a host but does not give us necessarily you know us being servicenow discovery process an idea of what type of application is listening is lurking behind that particular port so it tries patterns in somewhat of a random order but if we see you know these expanded patterns here we we see that these are not um these are failing right away and patterns are designed to fail early if it's not the right pattern so it keeps trying patterns until it can run through the whole process of identification to connection and we see that down here when we get uh to the creating ci and connection to the ec2 instance and so the next part i'm going to show you is where you can actually go in and build your own custom pattern or modify a certain pattern and so for this particular instance i have gone into my customer application here i'm going to open my discovery log again and these two we can see that all these connections are failing it's using that tomcat tomcat war pattern it's identifying it it's creating that ci but it's not actually making the connection to anything um well it's making this connection to this relational database but there's another connection i have a database and i needed to make a custom connection pattern or a custom connection so that it would actually connect to this and how i can show you this is if we go into debug mode which will launch our pattern designer and i already have this pre-loaded because as soon as you open this and click on debug it actually runs through that connection and retries all of the steps from pattern to identification to connection to fully be able to test this and so over here i've added two steps one i needed my i needed discovery to be able to get that config file that i know is living on this particular uh server or this particular instance here and so what i've done is i've added in where i know this config file lives i've retrieved the content and then i've defined some parsing here i've set this up as delimited text and then created specific variables pulling out the ip and the port and once i finished that then i went in and created a second part to this which was create connection and over here i was able to select the connection type as an application flow giving it that tcp endpoint and then adding in the host and the port and once i saved this i actually well before i saved it i was actually able to go through and test this just to make sure that it was all successful once i saved it or test it and saved it then i was able to publish it and from there then it was able to make that second connection the other part i want to show you about actually we'll move on to traffic so where can we see all of the traffic related data in the cmdb so let's just uh let's dive in to get an understanding of where you can find all of this so let's move over to our cmdb table our tcp table and from here we're able to see that service mapping retrieves all of this data from the tables to detect nci inbound and outland connections and so let's we're able to take a look at this on this particular table and you can see that we have over 9000 connections happening in our environment so let's drill down further and take a look at just how to look at one of these systems so we'll look at this first ip address and we can see now we have 29. so we'll go into this particular computer ci and we see that it's a windows server vm and down here we see all of the connections all the tcp connections that this particular windows server is connecting to and listening on and all of the running processes and so that gives you a good idea how traffic related data is working and being stored in the cmdb that is everything i have for you today thank you so much for watching and please don't hesitate to reach out if you have any questions thank you for your time you