Skip to main content

ServiceNow Event Management: tracing back the impacted services from the incident and alert

 

Tracing impacted services:

 

I checked and total impacted on the incident description comes from the alert management rule:


 

 

(BTW Here’s an interesting KB, it’s maybe worth clicking the ‘refresh impacted services’ button from the CI to see what happens https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0856121 )

 

The inputs impactedServicesList seems to be calculated from the incoming alert

The CI as recorded on the incident description is: prdatl01acXXXX

Mapped from the Alert:

You can view its relationships on this record:

https://xxxxx.service-now.com/nav_to.do?uri=cmdb_ci_linux_server.do?sys_id=424212ed1b05b8907bdaddf0b24xxxx

 

I’ve located the code for the impactedServices calculation and it’s out of the box:

 

(function execute(inputs, outputs) {

    if (inputs.impactedServicesList){

        var impactedServicesArr = inputs.impactedServicesList.split(",");

        for (var i=0; i<impactedServicesArr.length; i++){

            var gr = new GlideRecord("task_cmdb_ci_service");

            gr.initialize();

            gr.setValue("cmdb_ci_service", impactedServicesArr[i]);

            gr.setValue("task", inputs.taskGr.getUniqueValue());

            gr.setValue("manually_added", false);

            gr.insert();

        }

    }

})(inputs, outputs);

 

Looks like the purpose of the code is to create task_cmdb_ci_service entries against the incident

This above code seems to match the following list:

 

https://xxxx.service-now.com/task_cmdb_ci_service_list.do?sysparm_query=manually_added!%3Dtrue%5Etask%3D0b33fbce1b4d8d107bdaddf0b24xxxx&sysparm_view=

 

all of these 166 entries are mapped application services so you can click into them to see how it relates to the configuration item

one such example from the “view map” button:

 (ServiceNow )

Comments

Popular posts from this blog

ServiceNow check for null or nil or empty (or not)

Haven't tested these all recently within global/local scopes, so feel free to have a play! option 1 use an encoded query embedded in the GlideRecord , e.g.  var grProf = new GlideRecord ( 'x_cls_clear_skye_i_profile' ); grProf . addQuery ( 'status=1^ owner=NULL ' ); grProf . query (); even better use the glideRecord  addNotNullQuery or addNullQuery option 2 JSUtil.nil / notNil (this might be the most powerful. See this link ) example: if ( current . operation () == 'insert' && JSUtil . notNil ( current . parent ) && ! current . work_effort . nil ())  option 3 there might be times when you need to get inside the GlideRecord and perform the check there, for example if the code goes down 2 optional routes depending on null / not null can use gs.nil : var grAppr = new GlideRecord ( 'sysapproval_approver' ); var grUser = new GlideRecord ( 'sys_user' ); if ( grUser . get ( 'sys_id' , current . approver )){

Get URL Parameter - server side script (portal or classic UI)

Classic UI : var sURL_editparam = gs . action . getGlideURI (). getMap (). get ( ' sysparm_aparameter ' ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); } Portal : var sURL_editparam = $sp . getParameter ( " sysparm_aparameter " ); if ( sURL_editparam == 'true' ) { gs . addInfoMessage ( 'parameter passed ); }