DPM: application services not visible on service offering run tab if tag based or calculated

[damianfell]

We are implementing DPM alongside our service portfolio implementation and have found an oddity in the workspace that we cannot find a configuration setting for.

On the service offering run tab there is a list of application services that are dependencies of the offering, however it looks like the default selection is specifying only the mapped application service table, not it's child tables of calculate application service and tag-based application service.

Has anyone found a easy way to fix this to show tag-based services other than editing and customising the workspace itself?

Seems like a big dropped-ball in the workspace design as the tag based tools seem to be a strong direction of travel for the service mapping product.

[Mathew Hillyard]

Hi @damianfell,

Yes, I can confirm this is a defect in an OOTB instance with DPM installed. It does not change no matter portfolio status or phase you select for the Service Offering - in the Run tab Calculated Application Services that are connected to the Service Offering via a CI Relationship do not appear. However if you related a Mapped Application Service to the same Service Offering and refresh the "Application Service dependencies" section on the Run tab in a Service Offering record, it does appear. It appears to be filtering out everything except records whose sys_class_name is cmdb_ci_service_discovered. There is no facility within Admin Center to configure anything on the Run tab - it just references setting up KPI Groups.

Short of customizing the UI Builder component that renders Application Service dependencies or reporting a defect to ServiceNow I cannot see an alternative.

[damianfell]

Ugh - I was hoping someone would tell me it was just a system property I hadn't found 😞 time to hit the support portal then.

[damianfell]

I've also now found the culprit - it's a filter script buried in UI builder - they used a 'child.sys_class_name=cmdb_ci_service_discovered' rather than 'child.sys_class_nameINSTANCEOFcmdb_ci_service_discovered' operator in their script definitely needs fixing by the core product team.

I've logged a ticket because cloning it just for a minor fix to a scripted filter seems a crazy way of adding tech debt to our instance. - hopefully they'll sort it asap.

[Mathew Hillyard]

Yes, it seems that there are few crucial settings that should be properties buried in scripts within Workspaces. Not sure if it is still the case but Service Operations Workspace access used to be itil role only by default, and the role(s) were contained in an array in a script somewhere. The best bit being you could add roles to the array but the user needed all of the roles, not just one of them!

I think the filter you mention should be for any child app service class, not just Mapped/Calculated App Services -  e.g. 'child.sys_class_nameIN,cmdb_ci_service_by_tags,cmdb_ci_service_calculated,cmdb_ci_service_discovered,cmdb_ci_service_manual,cmdb_ci_query_based_service'