'Impacted Services/CIs' related list is showing different results in Incident vs change form :O

[Suggy]

I have a windows server - Win_test

It is associated with the Application services - A,B,C

For both Incident and change, the property 'Populate Impacted Services based on Affected CIs' is set to True.

1. On Incident form, when I chose the CI as 'Win_test' and clicked on 'Refresh Impacted services', then the 'Impacted Services/CIs' is populated with - A,B,C

2. On Change form, when I chose the CI as 'Win_test' and clicked on 'Refresh Impacted services', then the 'Impacted Services/CIs' is populated with - A,B,C, X

where X is a Configuration item (DB instance) running on that Windows server.

Questions:

1. Why X is not populated in incident management?

2. What is actually expected to populate in 'Impacted Services/CIs' related list? Only impacted Services or both 'Impacted services and CIs' as the name says?

[Mathew Hillyard]

Hi @Suggy,

I can see the same result in my PDI.

The reason for this is because when using the Change Property Impacted CIs/Services related list is generated via events. When enabled the refresh will be executed in the background and the user will be notified on completion. then an Event is inserted and Script Action "Trigger refresh impacted cis" runs, which calls ChangeUtils().createRefreshWorker(). This does the same as I mentioned previously - getting App Services from the CIs in Affected CIs - via function "_getImpactedServicesFromAffectedCIs", but it also calls function "_

_addAdditionalServices"), supplying the Change and the (App) Services. 

If Service Mapping is activated, this function then calls ChangeRequestDiscovery().getApplicationsByChangeId().

This function gets Applications (and any child classes of cmdb_ci_appl) and that Application's parent CI(s) that have a Runs on::Runs relationship with the Affected CI, and adds them to the list of (App) Services in the previous step.

As your two CIs in the screenshot above fit the criteria (parent of the Windows Server with a Runs on::Runs CI Relationship), they've found and added to the list of "services".

This is unique to Change and does not happen on Incident, as you say.

In short, it is adding records within the cmdb_ci_appl hierarchy of tables into Impacted Services/CIs, so clearly the related list is actually named appropriately! However I've never seen a use case as to why you'd add parent CIs of an affected CI into Impacted Services, when typically you would find parent CIs and add them into Affected CIs.

I hope this helps!

[CMDB Whisperer]

Thanks for the additional investigation and information Mathew!

[Suggy]

Thanks a lot for providing that info @Mathew Hillyard  

[CMDB Whisperer]

FWIW I have replicated your findings.  I did a cursory search of the code and it does seem like significant development has occurred in this area since the last time I looked, which to be fair was probably a couple of years ago.  The ChangeUtilsSNC script has a last updated date of 2023-12-04.  Hopefully a deeper dive into the code will illuminate when and why the change occurred.  But if I had to venture a guess it would be that someone just thought it would be a good idea to include all up stream CIs.  @Barry Kant not sure if you can do any digging here.  It seems to me like this is a fairly fundamental question, whether upstream CIs or just upstream Services are impacted by a Change.  That said, I still don't fully understand why the algorithm for Incidents is different from that of Changes either.

[Mathew Hillyard]

Hi @CMDB Whisperer,

Thinking about this further, this feels like a legacy piece of code that needs updating. The reason why is that in a CSDM environment you really shouldn't have any application CIs that are not a part of an Application Service (or perhaps Dynamic CI Group if Discovery is not yet implemented). This being the case, its parent Application Service would be found and added to Impacted Services, but only if this parent Application CI is in Affected CIs and not in Impacted Services/CIs.

So in short I feel the _addAdditionalServices() function should be removed from the refresh of impacted services - and renamed as it is not adding services but regular CIs - and instead code added on insert of an Affected CI to locate parent App CIs with a Runs on::Runs CI relationship to add this to the Affected CIs related list instead.

This would then provide a more sensible separation - CIs are in Affected CIs and (App, Business and Technical) Services are in Impacted Services/CIs. It would also help to rename that related list to just Impacted Services.

There is a fair few missing links in the codebase when it comes to implementing CSDM. I'm planning a blog post to bring these and other implementation observations together reflected in a rather unique engagement.