Real-time CMDB: Mapping as a Service

[ben_yukich]

It seems like a lifetime ago that we discussed Real-time CMDB: Disco as a Service. Let's revisit this topic, this time with a focus on Service Mapping rather than simple CI discovery.

As you may already know, Service Mapping is a unique method to automate the mapping of application deployments (aka business services). The mapping process always begins with an Entry Point to the business service you wish to map. The most intuitive (for me) entry point is a URL, though it is an extensible concept, typically distilling down to a hostname/IP, a port, and likely additional metadata to convey the context of a request. It's the job of Service Mapping to take that Entry Point and uncover all the technical dependencies that make the service available - I'm talking load balancer, down to web tier, to app tier, to database tier, etc... however your service happens to be constructed. Now, this is not magic, it's a technique that takes some effort to ensure all the discovery patterns needed are in place, but that's a discussion for another day.

Let's assume we've already implemented Service Mapping and it understands the patterns for the various applications typically used in our environment (like nginx, tomcat, mysql, etc.). Ordinarily, to add a new business service we need to log in to our ServiceNow instance, create a new Business Service record, add an entry point, and we're good to go. Not bad, but why do something manually that we can just as easily script?

Just like last time when we created CI Disco as a Service, to start we'll create a new Scripted REST API, define a Scripted REST Resource, and take it for a spin in the REST API Explorer. Here's a Scripted REST Resource script for a POST action where we're relying on the body defining a JSON object with a serviceName and url defined, and returning a URL that will take us directly to the graphical service map. It's slightly more complex than last time, but still quite approachable:

(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {   
       var businessServiceGr = insertRecord('cmdb_ci_service_discovered', {'name':request.body.data.serviceName, 'operational_status':'1', 'traffic_discovery':'false'});
       var entryPointGr = insertRecord('cmdb_ci_endpoint_http', {'url':request.body.data.url});
       new SNC.BusinessServiceManager().addEntryPoint(businessServiceGr.sys_id, entryPointGr);
       var mapUrl = gs.getProperty('glide.servlet.uri') 
                             + '$sw_topology_map.do?sysparm_bsid=' + businessServiceGr.sys_id 
                             + '&sysparm_bsname=' + businessServiceGr.name 
                             + '&sysparm_plugin_mode=mapping';
       return {'mapUrl': mapUrl};   
       function insertRecord(table, properties) {
               var gr = new GlideRecord(table);
               for (var key in properties) {
                       gr[key] = properties[key];
               }
               gr.insert();
               return gr;
       }
})(request, response);

As before, we can easily test this in the REST API Explorer, just be sure to pass a JSON object in the request body such as:

{"serviceName":"There's no place like home","url":"http://127.0.0.1"}

You should receive a 200 response, and your output will give you a deep link to the newly discovered service:

{
       "result": {
               "mapUrl": "https://your_instance.service-now.com/$sw_topology_map.do?sysparm_bsid=806519d5dba13a00f3223ecf9d961... no place like home&sysparm_plugin_mode=mapping"
       }
}

Pretty nifty, right? Now you can automate the creation of a service topology in ServiceNow with a simple REST request. Maybe next time we'll tackle partial refresh of a business service map, perhaps in response to a specific component being changed... what do you think?