Application Services: Tips and Tricks

[David Skowronek]

In my previous Community Article Application Services: How to use them? I have described usage of Mapped and Calculated Application Services. In this article I will focus on useful tips and tricks:

• How to control what Configuration Item classes are imported
• How to improve CI Relations in the form view and BSM view

Limit Configuration Item classes imported

There few classes excluded from the import to the Application Service:

• cmdb_ci_endpoint
• cmdb_ci_translation_rule
• cmdb_ci_config_file
• cmdb_ci_qualifier
• cmdb_ci_application_cluster

In a large implementations, especially when Discovery is enabled, there are many various Configuration Item classes used. Not all of them are actually needed to be imported to the Service Map. Also, there are few scenarios where exclusion of a Configuration Item class is needed to prevent "explosion" of the Service Map. Example is DataCenter class ... it may happen that e.g. VMware Instance depends on the DataCenter. But at the same time DataStore class makes a "triangle" that leads to a situation where VMware Instance has DataCenter as a child and through the DataStore as a parent. Import of such a "triangle" situation lead to very large maps being created and therefore impact the performance.

What you can do in this situation?

• You can limit the amount of relationship levels being imported either by adjusting the global property "svc.manual.convert.levels.default_value" or adding JSON string {"levels" : <number>} to the "metadata" attribute of the Calculated Application Service ("metadata" attribute exists for Calculated Application Service only)
• You can exclude defined Configuration Item classes from being imported. Such classes needs to be defined in the "sa.mapping.user.manual.citype.blacklist" property. This property works with extensions, it means adding cmdb_ci_server will exclude all child classes for Windows, Unix etc.

In practise, you may combine both approaches. Set a good default value based on your size of CMDB relationships and use individual "metadata" attributes as an override.

Improvement of CI Relations in the form view and BSM view

From the historical point of view the current Application Services come from the Service Mapping product. Service Maps are drawn based on the endpoints. During the import of relationships into the Application Service system at first create endpoints (Manual Endpoint - cmdb_ci_endpoint) followed by creation of CI Associations.

You may see the endpoints in the CI Relations and BSM view as well. This is needed for the situation when you populate the Application Service using the Service Mapping. Service Mapping does not create relationships, only endpoints and CI Associations. Therefore, both relationships and endpoints are displayed in the CI Relations and BSM View.

The following screenshot shows how the endpoints are displayed in the CI Relations.

As the endpoint-based relationships actually duplicate the "normal" relationships (for non-Service Mapping populated Application Services), this view may be confusing of the users. You may decide to hide endpoint-based relationships. Warning: you should do this only when you do not have Service Mapping deployed!

Hiding the endpoint-based relationships does not require any development. Navigate to menu Configuration => Relationships => Relationship Type Exclusion List [cmdb_rel_filter] and add 2 records into this table as shown on the screenshot below.

As a result, both CI Relations and BSM view will use only "normal" relationships and ignore the endpoint-based ones. The screenshot below shows the same example as above, after the exclusion records were created.

[midjoule]

Hi David and all,

Thanks for sharing this knowledge.

In fact I'm in the same situation (manual entries), but instead of seeing the Implement end point from  relationship, both relationship are identical. This is the view from the business application: 

 

However, I could notice a difference in the list of relationships (child = Manual Endpoint):

So I created this filter:

But I still see the duplicate entries in the business application view.

Any idea on how to get rid of the duplicate entries ? 

Best regards

NB: we are on Quebec release.

[NikEng1]

Hi,

I am currently in the same situation. Based on the documentation it seems like the relationship cannot be excluded from the formatter, as the endpoint is removedin the UI:

If an endpoint is a child in one relationship and the same endpoint is a parent in another relationship, then that endpoint is hidden and does not appear in the relations formatter view. Similarly, relationship qualifier chains are also hidden and do not appear in the relationship formatter view.

• Example: CI1 > endpoint > CI2

  In this example, CI1 is related to CI2 through relationships with endpoint. A single relationship appears in the relations formatter:

  CI1 > CI2 (These relationships appear as a direct relationship without endpoint, because endpoint is a parent in one relationship and a child in another relationship)

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/concept/c_CIRelationsFormatterNG.html

In other words, the relationship between:
Business App > Appliation Service> Manual Endpoint > Server

is replaced in the formatter with simply:
Business Application > Application Service > Server

So there is no way of getting rid of it without blocking out the servers completely.

The only way I've found to fix it is to forgo endpoints completely, by creating the application without a population method (class: Automated Business Service) and setting up the relations between the application service and the infrastructure CI:s by cmdb_rel_ci entries. But that seems like a bad solution.

Really, if ServiceNow says that manual population of an application service is an option they must have a way to do this without having duplicates in the CI Relations Formatter?

[David Skowronek]

This is quite a strange that relationship type Depends on::Used by is used together with Manual endpoint. You may check if there is a customization related to this, whether the "Use endpoint ..." type exists. It may be so that you have changed the label while the sys_id exists, and you have multiple Depends on::Used by types now.

If this is not not the case and you did not do any customization, you may need to raise a Support case to check it. This would require to have access to the instance, to check what is going on.

[midjoule]

Thank you @NikEng for your comment and for sharing your situation.

In fact, I raised a case and the answer is: this is an issue in Quebec that will be resolved in Rome.

Ref : KB0994978 

[midjoule]

Thank you @David Skowronek for your advice.

I raised a case and the answer is: this is an issue in Quebec that will be resolved in Rome.

Ref : KB0994978 

[Mathew Hillyard]

Thank you @David Skowronek for this helpful article.

For anyone reading this today, it's worth knowing that the facility to exclude defined Configuration Item classes from being imported is no longer defined in the "sa.mapping.user.manual.citype.blacklist" property. This has been deprecated and replaced with the Manual CI Inclusions / Exclusions [svc_manual_ci_exclusions_inclusions] table as referenced in this Docs site page. If you attempt to create this property you are directed to the table. I should also say this table is critical because for most CMDBs, even if you set an Application Service's "Level" to the default of 3, you will bring a lot of "noise" populated by Discovery that most organisations will not be interested in for ITSM processes or impact calculation. Customers need to strike a fine balance between visibility and bloat as you can quickly end up with hundreds of thousands of new CI Relationship records just relating to, or referencing Manual Endpoints!

Your point about cleaning up the CI Relations Formatter by excluding endpoint type relations in the Relationship Type Exclusion List [cmdb_rel_filter] table is also very helpful. I had located this module but hadn't realised that you need to specify the Configuration Item [cmdb_ci] table for both the parent and child tables. It seems obvious now!

I have two observations:

1. It would be helpful to have both the Service Configuration Item Association and Manual CI Inclusions / Exclusions tables as modules within the Application Navigator - otherwise for people new to this process the functionality is effectively "hidden".
2. There is a defect with Tracked Configuration Files. I have proved this across Tokyo, Utah and Vancouver with both a completely stock PDI and customer/partner instances. When you set up a calculated application service, the Service Config Item Assoc table gets populated with Tracked Config Files below the number of "Levels" specified in the App Service and even if you add this class into Manual CI Inclusions / Exclusions. I have created a post about this.