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?
