Impacted Services/Cis population

[Sam Ogden]

Hi All,

I have a question around the impacted Services/Cis tab on the change request form.

We are expecting that this populates all the CIs that are downstream of the Configuration item that has been entered on the form.   Does anyone know how this population works?

In our instance this is not working as we are expecting.   An example CI below:

We have a CI of 1Answer 1Aces UAT_Strata Release, Diagram below:

We would expect that all the CIs in the highlighted box would then be put into the impacted Services/CIs tab.

As you can see below this is not happening - The only CI that is being populated is the one we have added to this field.   I would like to know what populates this tab and what changes we need to make to get this to work as expected.

I have seen the following business rule which I think is currently being used to populate this, but not sure what changes need to be made to this:

function onAfter(current, previous) {

//current.update();

action.setRedirectURL(current);

removeAffectedServices();

addAffectedServices();

//checkAffectedServices();

function removeAffectedServices()

{

  var m2m = new GlideRecord('task_cmdb_ci_service');

  m2m.addQuery('task',current.sys_id);

  m2m.addQuery('manually_added','false');

  m2m.query();

  m2m.deleteMultiple();

}

function addAffectedServices()

{

  var ciu = new CIUtils2();

  //Find all impacted business services

  var services = ciu.cisAffectedByTask(current);

  //var services = ciu.cisAffectedByTask(current, ["cmdb_ci_service", "cmdb_ci_windows_server"]);

  //var services = ciu.cisAffectedByTask(current, ["ALL"]);

  var m2m = new GlideRecord('task_cmdb_ci_service');

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

    m2m.initialize();

    m2m.task = current.sys_id;

    m2m.cmdb_ci_service = services[i];

    m2m.manually_added = 'false';

    m2m.insert();

  }

}

/*function checkAffectedServices()

{

  var ciu = new CIUtils2();

  //Find all impacted business services

  var services = ciu.cisAffectedByTask(current);

  //var services = ciu.cisAffectedByTask(current, ["cmdb_ci_service", "cmdb_ci_windows_server"]);

  //var services = ciu.cisAffectedByTask(current, ["ALL"]);

  var m2m = new GlideRecord('cmdb_ci_service');

  m2m.addQuery('sys_id','IN',services.toString() );

  m2m.query();

  while(m2m.next())

    {

    var service_name= m2m.name;

    var owner= m2m.owned_by;

    gs.eventQueue("incident.impact.notify",current,owner,service_name);//Triggers the event for generating email Notification.

  }

}*/

}

Any help on this is greatly appreciated.

Thanks

Sam

[Dave Smith1]

depends on: used by looks more like it.

You're effectively saying "Swinton Live depends upon CDLSA36, CDLSA36 is used by Swinton Live" .. i.e.: any change on CDLSA36 could affect Swinton Live.

[Sam Ogden]

Hi Dave,

Thanks for the clarification on this.   It has been a big help for me to understand the diagrams structure.

I suspect that once we get the relationships rectified then the impacted services tab will then populate more along the lines that we are expecting.

Thanks once again for all your help.

[Dave Smith1]

I suspect that once we get the relationships rectified then the impacted services tab will then populate more along the lines that we are expecting.

That's my feeling, also.   You may want to consider things like Discovery or Service Mapping toolset to help query your infrastructure and build up the CMDB and relationship diagrams.

[Chad Hall · Accepted solution]

Your CMDB relationships appear to be backwards. Normally the business services are at the very top as the highest parent. The components that run a business service (applications, servers, databases, etc.) would then be children downstream of it. Any additional business services which consume your first service would be upstream parents of it. When changes are opened for one of those child infrastructure CIs I would expect the Impacted Services/CIs tab to show the upstream service CIs that depend on it. The way yours are defined it would be searching the wrong direction.

In our instance we do something similar to what you're wanting, but our relationships have the services at the top. And we want our Impacted Services/CIs tab to show ALL types of CIs impacted, not just services. We also want to include not just CIs impacted by the main CI on the change but by any affected CI in the change. We go to great lengths to keep this current because changes to the affected CIs list or to any of the relationships between any of those CIs or their downstream related CIs could change which CIs are impacted and such changes would not be detected simply by a modification of the cmdb_ci field on the change request itself. So we have a scheduled job that runs hourly. It looks at all open change requests and incidents and rebuilds the full Impacted Services/CIs list for all of them that have had an affected CI updated since our last job run. It also looks at each impacted CI to see if they have had any new child relationships added since our last job run. If it finds anything updated on those it rebuilds the entire Impacted Services/CIs list for that task. We opted to do this in a scheduled job since (a) its such an intensive query process, (b) it would be overkill and a performance hog to run it in a business rule, and (c) a business rule on change requests still wouldn't detect changes to affected CIs or downstream relationship changes. 

In summary - reverse your relationships. If you want it more robust do a deeper check like we did.

On a related note, I have a new need to return a list of downstream CIs for a given service CI. This is not for something within our instance but an external monitoring system needs to know which CIs it should be on the lookout for events from to determine if they may impact a particular service. For example, an event on a particular server being down should indicate visually on their dashboard that Service ABC which depends on it may be experiencing problems. I'm looking for a way to make a single web service call, feed it a parameter of a particular CI, and have it return a full list of the downstream CIs that may impact it up to N number of levels (another parameter could specify the levels to dig). As best I can tell I'd need to create a new function to walk the tree in the opposite direction of cisAffectedByCI() and then call that in a scripted web service. I had really hoped there was a built-in way to do this, or that someone had crossed this bridge before.

Has anyone else done this?

[Sam Ogden]

Hi chahal,

We are in the middle of a CMDB project that is rectifying the issues you highlighted in our relationships.

I am now seeing the impacted Services populate correctly.  As you mentioned this OOTB only runs for changes to the main CI record (cmdb_ci), however our change manager wants it to be updated with all the impacted services from all the affected CIs in the related list (tack_ci).  You mentioned that you have something similar in place, I was wondering if you were able to share how you achieved this as I am struggling to get this to work?

Thanks 

Sam