CSDM Service Impact - Service Config Item Assoc table - defect with Tracked Configuration Files

[Mathew Hillyard]

Steps to reproduce:

• Create a Calculated Application Service and set the Levels to 1
• Associate a Tracked Configuration File with an Application (or any other infra) CI via a CI Relationship where Parent CI - <any CI Rel type > - Tracked Configuration File
• Now associate that parent CI with your Application Service via a CI Relationship where App Service - <any CI Rel type> - CI

Result: Even though you set "Levels" to 1, meaning that only directly-connected CIs should be considered, the child of the CI (the Tracked Configuration File, which is actually 2 Levels below the Application Service) is added to the Service Config Item Assoc [svc_ci_assoc] table. No other CIs at Level 2 are added.

Screenshots from Vancouver instance attached as proof.

The system property "sa.mapping.system.manual.rel_type.blacklist" used by the Script Include that populates the Service Config Item Assoc table ("SMDynamicManualServicePopulator") only excludes CI relationship types at the Level set in the Calculated Application Service so adding any CI relationship types here has no effect. Unfortunately the code that does the work of populating the Service Config Item Assoc is hidden - SNC.BusinessServiceManager().

I have validated this on a PDI running Vancouver, a customer instance on Utah, and an internal instance on Tokyo. It appears to be a defect as the CI is at a greater depth in the CMDB Hierarchy than chosen for the App Service population. This isn't a massive issue in that users are highly unlikely to choose a Tracked Configuration File as a CI in Incident or Change, but it has the potential to unnecessarily bloat the Service Config Item Assoc table.

I wonder if anyone from the Community or from ServiceNow can comment on this issue?

[Mathew Hillyard]

I should update this to also include that I have added the Tracked Configuration File CI Class to the Manual CI Inclusions /Exclusions [svc_manual_ci_exclusions_inclusions] table, but it has had no effect - the CIs are still being brought into the Service Config Item Association table.

[Josh P1 · Accepted solution]

Heya Mathew,

I am not sure if this will work, but have you looked at the svc_traversal_rules table?  I noticed an entry in there for tracked configuration files.

Servicenow docs refer to this table only in reference to tag mapping but the Used by column indicates Service Recomputation which makes me think there is more to this table than the docs are letting on.  🙂

Hope this helps get you what you need.

[Mathew Hillyard]

Hey Josh,

I just tried that in my PDI and it seems to work. With an App Service connected to an App, connected to a server, that contains a tracked configuration file, when setting the App Service to a dynamic service with 3 levels, and having created a Manual CI Exclusion for the Tracked Config File class, deactivating the Traversal Rule seems to exclude this class from being populated in the Service Config Item Association table.

One of the challenges with this entire part of the platform is that all the calculation is hidden, therefore troubleshooting is trial and error. I suspect the reason why the code is hidden is because it goes directly to the database rather than via the application server to populate the Service Config Item Association table - I have seen the table populated with >100,000 records in just a couple of seconds, so it is clearly not

It still seems strange that with Service Mapping not activated, and with an Exclusion class explicitly set, one needs to tweak a "base" table installed with a vanilla instance to achieve the expected behaviour. It is surprising there isn't a PRB record for this, or at least a KB Article. I will suggest one to ServiceNow.

Thanks!

[Community Alums]

Hi Matthew,

Are you manually adding records to the Tracked Configuration File table? This table usually gets populated as part of horizontal discovery, but if you're manually adding these records, you could add them to the Configuration File table instead - and then the Traversal rules won't pick it up.

It's just a thought - I know it's not a fix. 

Regards, Jason.