Application Services: How to use them?

[David Skowronek]

Application Services are essential part of the Common Service Data Model (CSDM). This article focuses on how to use Application Services for manually maintained Service Maps in the situation when Service Mapping is not deployed. Proper usage of Application Services is critical for correct behavior of some features, e.g.:

• Impacted Services (e.g. in the Change Management)
• Event Management (service impact, priority calculation, Operator Workspace etc.)

It is highly important to understand how Application Services are working: they DO NOT USE RELATIONSHIPS, they are WORKING WITH CI ASSOCIATIONS.

What is a CI Association?

ServiceNow Documentation says: "The Service Configuration Item Association table [svc_ci_assoc] binds an application service and a CI to track which CIs are part of each application service."

In practice, it is flattened table that contains "relationships" among Configuration Items and Application Services. I am having word relationships in quotation marks because CI Associations are separate data model that can be different from the relationships. And in this situation, when relationships and CI Associations are different, unexpected situations resulting in "Why my Service is not listed among Impacted Service when I have relationships in place?" may happen.

It is highly critical to have CI Associations populated correctly and in sync with Relationships. For performance reasons, traversing through all Relationships in the Impact analysis etc. is not possible. Therefore, Service Configuration Item Association [svc_ci_assoc] table is used for fast search.

How to make sure that Service Configuration Item Associations are populated?

This chapter will focus to 2 Application Service types:

• Mapped Application Service [cmdb_ci_service_discovered]
• Calculated Application Service [cmdb_ci_service_calculated]

There are 3 more Application Service types available:

• Application Service [cmdb_ci_service_auto] where no CI Associations are created at all
• Dynamic CI Group [cmdb_ci_query_based_service] where CI Associations are automatically created based on the specified CMDB Group
• Tag Based Application Service [cmdb_ci_service_by_tags] where CI Associations are automatically created based on Tags

You may check my previous Community Article CSDM 3.0: Paris release CMDB changes where they are visualised.

Mapped Application Service

This Application Service type may be created and maintained by:

• Service Mapping, and in this case you do not need to take care about the CI Associations as they are created automatically
• Manually, where you need to build Service Map and CI Associations manually

The following picture shows a new Application Service being created with Manual population method. You can add multiple Configuration Items into the manual map however: only directly added configuration items will create CI Associations.

If the added Configuration Item, DEMO Server on the example used, have some child relationships, they are ignored and CI Associations are not created for them. It means, Impacted Services etc. will work for directly listed Configuration Items but not for their children.

Once the Mapped Application Service is created, you may need to populate remaining Configuration Items manually, based on the existing relationships. Open the Mapped Application Service in the form view (the most easy is to type cmdb_ci_service_discovered.list in the filter navigator) and use "Update with changes from CMDB" UI Action (highlighted on the screenshot below). There is a need to use this UI Action after every change in the relationships, to ensure Service Map and CI Associations are in sync with CMDB relationships.

This approach is manual, with risk that CI Associations are not in sync with CMDB relationships, as people simply forget to click this UI Action. If you want to have the synchronization automated, you may need to use Calculated Application Service.

Calculated Application Service

A Calculated Application Service [cmdb_ci_service_calculated] is a type of the Application Service that is populated automatically based on the CMDB relationships. Changes in the CMDB relationships are detected automatically and Service Map together with CI Associations are adjusted automatically (through a scheduled job). You may control what Configuration Item classes are imported, for details please check my Community Article Application Services: Tips and Tricks.

Creation of the Calculated Application Service not straight-forward in the Quebec release, there is a need to:

• Create a Mapped Application Service
• Open the service form and use "Convert to Dynamic Service" UI Action

Once this UI Action is clicked, Mapped Application Service is re-classified as Calculated Application Service with few additional parameters populated.

Attribute "Levels" is highly important in here. This number says how many levels of CI Relationships is imported to the Application Service. Default value (set by the "svc.manual.convert.levels.default_value" property) is 3.

Attribute "Levels" is in practise attribute with element name "metadata" that needs to be populated with a JSON String: {"levels" : <number>}.

Summary

The following table explains different types of Application Services and how Service Configuration Item Associations are populated.

Using Mapped Application Service [cmdb_ci_service_discovered] is not recommended for manually maintained maps. There is a significant risk of incorrect Service Configuration Item Associations. Use Calculated Application Service instead.

Table below shows limits for some Application Service types however it is NOT recommended to add more than 1000 Configuration Items into a single Application Service.

Application Service type	CI Associations population	Note
Application Service [cmdb_ci_service_auto]	Not populated
Mapped Application Service [cmdb_ci_service_discovered]	Automatically when Service Mapping is used Manually using "Update with changes from CMDB" UI Action
Calculated Application Service [cmdb_ci_service_calculated]	Automatically based on the existing Relationships
Dynamic CI Group [cmdb_ci_query_based_service]	Automatically based on the CMDB Group	This Application Service type supports max. 10 000 Configuration items
Tag Based Application Service [cmdb_ci_service_by_tags]	Automatically based on the Tags	This Application Service type supports max. 5 000 Configuration items

Check my next Community Article Application Services: Tips and Tricks for useful tips on how to influence behavior of Application Services.

[Rob50]

Great article as ever, David.

Thank you.

[Robin Chytil]

Thanks for the useful article David.

One quick question: what is the rational behind the Dynamic CI groups, to be an extension of the Application service table? From the CSDM, I understand that Dynamic CI groups should/could also be for creating and maintaining automatically Technical services such as:

• Sets of PC in a specific locations (and suported by a specific on-site support team)
• Sets of Access points (network gear) in a building, providing WiFi access

I would rather consider that as technical services, and Dynamic CI groups would fit the need perfectly?

Your thought?

Robin

[David Skowronek]

Hi Robin, there are few reasons:

• Dynamic CI Group may work also as an Application Service, in the low-maturity CMDB without a real Application Services
• This class was originally labeled Technical Service, part of the Event Management (do not mix with the current Technical Service, cmdb_ci_service_technical). It was used by Event Management to display status of CIs (groupped into this Service) on the Dashboard, as Event Management can consume only Services that extends cmdb_ci_service_auto

Usage of this class has been extended as originally it was just a filter and now you may use Filter, Query Builder or direct CI subscription.

Its usage is exactly for use cases you have mentioned ... "Sets of something" where this CI Class automatically detect what belongs to it, without manual maintenance.

May may create:

• Technical Service [cmdb_ci_service_technical] e.g. "Access Points" where you describe your in-scope and out-of-scope items
• Service Offering [service_offering] e.g. "Access Points Management" where you describe your commitments (SLA, Availability etc.)
• Dynamic CI Group e.g. "All Access Points" where you define a query to the CMDB to include all operational access points, and they are self-maintained based on defined filter

So it is a chain of elements, each of them has different usage.

[Robin Chytil]

Thank you David for your answer.

Very clear.

Robin

[Abhinav Duvvuri]

Thanks for the article David. Helped me understand more about application services.

I have a doubt. 

I have a requirement wherein I am required to create calculated application services using a business rule or some kind of scripting when ever a business application is created. So, for this I need to create a calculated application service using a script( and not via the UI).

Can that be done? If yes, can you show me how?

Thanks,

Abhinav

[David Skowronek]

Hi, Abhinav,

you can create Calculated App Service like any record in Service. You only need to populate few (3) extra fields to have it working correctly. Those fields are described in my older article Dynamic Application Services, in the last section.

var grAppService = new GlideRecord("cmdb_ci_service_calculated");

grAppService.initialize();

// Populate attributes like name etc.
// Also Service type attribute should be set to Dynamic

grAppService.service_populator = "11f01e3dc3f23300daa79624a1d3ae32";
grAppService.metadata = "{'levels' : <number of levels>}"; // you can keep empty, it will use default 3
grAppService.populator_status = 1;

grAppService.insert();

[Stefan K_]

Thanks for the useful article!

I do have some topics I am wondering though:

1: Multiple application service classes, why?

I am having trouble understanding the fundamental reason why there are so many different tables for application services.

Based on this article I see that the table controls how the association records are created in the association table, but why isn't this just an attribute (choice list field) on one "master" application service table/class? CI class normally describes what the thing is (e.g. personal computer, printer, server) and in my mind this setup should apply for application service too.

Sure, it might be the case there are different flavours of application services same way as under servers we have a child class linux servers...but in the case of linux server it is still just a more drilled down class of what the thing is.

For me these different application service classes are not following this model (describing what the thing is), but instead seem purely technical distinction to control how ServiceNow itself treats them and what rules it applies internally in the platform.

The reason I am questioning the approach is simply as overall the extra classes bring unnecessary complexity. Imagine a situation where you have stored all your thousands of application services to cmdb_ci_service_auto table...but then realise that you have an issue in change management as the very important "Impacted services" functionality will not work now as you don't have any associations.

Now then, you face an interesting task to transform them to a new class (likely calculated application service) with a lot of things to check they still work (form views, business rules, client scripts, working instructions, interfaces that use your previous data...list goes on). Instead could have just changed some attribute on the existing application service record in the existing table to tell the system to generate associations?

2: Why association table in the first place and not filtering how much relationships are traversed?

Ok, so the association table is a "cheat sheet" data table to avoid performance issue of going through the actual relationship data which can be massive. I do struggle a little with this one too (sorry).

For example, the calculated application service is copying data from relationships to the associations (limited by the level how many layers of relationships it copies).

What is the reason to duplicate the data and read this duplicate data, and not just simply cap the levels on the query that traverses the "normal" relationships?

[Yuri Yoshinami]

Hi @David Skowronek ,  

Thank you for your post! It  helped me capture the usage of Application Service. 

I have some questions.

1.If the customer implement APM before Discovery/Service Mapping which method should we choose when implementing APM only at first? When I chose the method called "Manual" ServiceNow automatically made the record in [ cmdb_ci_service_auto] table not in Calculated Application Service [cmdb_ci_service_calculated], whose table is not recommended to use explained in your post.

2. Do we need to change the population method later when implementing Discovery/Service Mapping?

Hope you find my post.

Kind Regards,

Yuri 

[David Skowronek]

Hi,

add 1) I am not sure what your APM stands for, whether it is Application Portfolio Management or something different. As you shown in the screenshot, option to use Calculated Application Service directly is missing there. I have raised this already with our product management but without success so far. You may raise a Case for this, to get higher attention 😉 Meanwhile, you may automate it e.g. by Business Rule. In this case you need to populate few attributes, and I described them in separate article (old one but still this automation part is valid): https://community.servicenow.com/community?id=community_article&sys_id=0bda344a1bcd5010a59033f2cd4bcbe3

add 2), changing the population method may have unpredictable results, when you jump from Calculated to Mapped Application Service - from relationships to Service Mapping. In this situation I would rather retire the current Calculated Application Service and create a new one where population is done by Service Mapping. But this applies only to situation where you are using Service Mapping for that app service. If you already have Mapped Application Services but populated manually, you may simply change to Calculated and they will recalculate and update correctly. With Service mapping, where you need to specify entry points etc., in here I would be careful.

[David Skowronek]

Hi,

add 1), this is nothing I can really answer, as I am not from the development team. 😞 I am also not a big fan of those extensions, but this is how it is. In general, you should not have big problem with your current reference qualifiers. If you are using cmdb_ci_service_discovered (Mapped Application Service), Calculated App Service extends from this table and your references should work without any problem. You may also have Business Rule (after insert) on cmdb_ci_service_auto that would automatically move this record to Calculated App Service ... you may check in the bottom of my another article, what fields you need to set: https://community.servicenow.com/community?id=community_article&sys_id=0bda344a1bcd5010a59033f2cd4bcbe3

add 2), using the CI Associations is MUCH faster, and in fact the only way to avoid performance issues. For small customers, having just few CIs and small maps it would not be a problem to traverse relationships. I am working with customer having 10000+ app services, where some maps have > 1000 CIs. With complex infrastructure, especially when you have shared services and shared components - and deployed discovery - your CIs may have many parent Application Services, and maps may have many levels.

If you would add e.g. 100 CIs as affected CIs in the change (e.g. when you have change for patching), calculation may take tens of minutes, resulting in memory issues. Why the system should always traverse all relationships, instead of using pre-calculated flat table? It is really good that it exists.

[Johannes]

Great article, David.

One comment, you wrote: 

It is highly important to understand how Application Services are working: they DO NOT USE RELATIONSHIPS, they are WORKING WITH CI ASSOCIATIONS.

I believe you mean:

It is highly important to understand how Service Maps are working: they DO NOT USE RELATIONSHIPS, they are WORKING WITH CI ASSOCIATIONS.

[David Skowronek]

Thank you, Johannes. Your statement about Service (Topology) Maps is incorrect. Service (Topology) Maps are shown based on Endpoints, not CI Associations. Impact (for Event Management, Changes, Incidents etc.) is using CI Associations.

You may test this based on Dynamic CI Groups. This table extends Application Service and if you add some CIs there, you will see impact in the Event Management or Change. But no Service Map. This is because it creates only CI Associations, no Endpoints.

[Johannes]

You are of course correct about the Service (Topology) Maps.

But is the statement "It is highly important to understand how Application Services are working: they DO NOT USE RELATIONSHIPS, they are WORKING WITH CI ASSOCIATIONS" correct?

All records in cmdb_ci_service_auto can have records in cmdb_ci_rel, i.e. relationships to other CIs. Does not that mean that Application Services use relationships? Is what you mean by the statement that the relationships are not used for 

[David Skowronek]

Of course you may have relationships with Application Services. But they are used for BSM View only. However, for impact analysis, Event management etc. they are not used. They are working with CI Relationships only. The only Application Service type that automatically covert relationships to CI Associations is Calculated Application Service.

Mapped Application Service, when you are using Service Mapping, does not create relationships. Only endpoints.

Mapped Application Service populated manually (or using "Update with changes from CMDB" UI Action) will convert relationships to endpoints and CI Associations. But this is manual operation. Calculated App Service does that automatically.

Tag-based App Service is working based on tags, relationships are ignored.

Dynamic CI Group is working based on Query Builder / Filter / direct CI subscription, relationships are ignored.

[Ahmet Damli]

Hello @David Skowronek,

great article.

I have 2 questions:

1. I struggled to find the scheduled job, which updates the CI associations for "Calculated" Services. Can you provide the name or link?

2. When the schedules job runs for "Calculated Services", does it also remove all associations for all removed CI-relationships?

[David Skowronek]

Hi, @Ahmet Damli, thank you 🙂

There are 2 jobs doing the recomputation:

- Service Mapping Recomputation
- Service Mapping Fast Recomputation

They are running in a 5-second internal inside all nodes, so there is 1 job per node. They are responsible to keep Endpoints and CI Associations in sync with relationships. If you delete some relationship, one of those jobs will delete corresponding Endpoints and update CI Association table.

[Ahmet Damli]

Hi @David Skowronek ,

great, it works fine and thx for such a fast reply.

Please let me ask another question:

As we are a global company, we have couple of Services, which manage up to 30 - 50 Thousands of CIs (as example Laptops, mailboxes). Right now we covered them by "Dynamic CI Groups". I just realized the limit of 10.000. So is the right way to go for us with "Calculated Services" for this kind of Services (Nevertheless i saw you recommendation not to add more than 1.000 CIs to a Service...)

[David Skowronek]

You are welcome, @Ahmet Damli. To your question about the Dynamic CI Groups. Yes, they have hard limit of 10 000 records inside them. For Calculated App Service, I would not recommend to use them for a flat model like Laptops. In fact, they are not matching definition of Application Service as a deployed application stack. The right model in here a depends on your design and usage, you can:

- have multiple Dynamic CI Groups e.g. per location ensuring that each of them has less than 10 000 CIs

- have direct relationship from the Service Offering to the Laptop

- have a custom reference from the Laptop to the Technical Service Offering that is managing it

- and other ...

There are multiple options and the right one depends on usage of the model by processes. Model itself has no value, its value is realized by the processes that consume it. But as you are already working with Dynamic CI Group, the split per e.g. location may be the most easy way forward.

[JackJackNow]

Does Svc_ci_assoc table allow ServiceID to be a Service Offering and Configuration Item.Class be an Application Service? I can't seem to do this in my instance.

[JackJackNow]

I'm trying to show Service Offering to Application Services in the CI association table. Should it be Service Offering as [ServiceID] and Application service as [Configuration Item]? I mean this can be done in a simple cmdb_ci_rel table too but I was wondering if svc_ci_assoc can do the same.

[David Skowronek]

Hi @JackJackNow . The CI Association table shows only Application Services, nothing else, in the Service ID attribute. If you would like to display the impacted Service Offerings, you may create a custom Related list that is populated based on the information in the CI Association table. The additional query to find the parent relationship with the Service Offering will provide you those results. But not baseline, it is a custom solution.

[Barry Kant]

hi @JackJackNow 

check this article
the related list is ootb. Some properties needs to be set to true and you need to tweak a script (design bug..).

then it works fine in my opinion.

BR,
Barry

[Johnathan R]

@David Skowronek This thread has great info, really solves the mystery!

All our App Services are currently stored in 'cmdb_ci_service_auto' and manually related to their components. Thus Change and Event impacts are not working well or at all.

How can I migrate these over to Calculated Service? I believe you added a link but it just says 'this content is archived'. 

Thanks!!

EDIT: I think I found my answer. Open the app service and add a population method (Dynamic) via the wizard. You have to open the App Service from the 'Configuration' module navigation, to make the wizard view appear again vs the classic form view. 

[Jyothi Malkared]

HI @David Skowronek 

I just started working on Service Mappings past 5 months. But seeing few issues. Any help is Appreciated.

1) we are working Service Maps from csdm_app_services_list, recently our Instance Upgraded to Utah from San Diego. We downloaded Json files for Service Maps in San Diego and when we upload in Utah it is giving below errors. How to fix Below issues?

 0 rows removed from ldap_group_import

 Removing data from import set table u_bnr_import where import set=ISET0675522

2) for Server Based Mapping, is there any different way to approach? right now we are seeing maintenance problems.

3) Need more steps on How to ML Based Mapping? (ML Based Mapping is a better version for Server Based Mapping) 

4) Cloud POC approach?

5) How to do Mapping for Mainframe applications, since Mainframe servers are not discoverable. We have one application it has 113 Servers (combo of Application and Database Servers) 

[EladLevy]

Thanks you for this article David! 

[Karen_K]

When we are retiring an application, we do not remove decommissioned devices from the application service as we wish to maintain a historical view of those devices, such as servers, that were providing service to the business application. Unfortunately, when viewing the application service, we cannot tell which devices have been decommissioned unless we drill down to the CI. Is there a view for application services where we can filter out any devices that have been decommissioned?

[David_Skowronek]

Hi, @Karen_K . I am not aware of any functionality like you describe. I usually solved this type of need by storing the removed relationships in the Description field of the Configuration Item. Appended this to the end of the current text. In this case, we were able to drop relationships so the CI did not appear any longer in the impact analysis etc., and also we were able to archive it after a while to keep the CMDB clean.

[jeevitha gopi]

@David Skowronek when we create a new application service by selecting cmdb groups on the service popuation methods..I want to create a CI Relationship between Applcation Service and CI's that are under the cmdb group? is it possible?

and can you tell me what are the oob process,why we need to use the dynamic ci group for population method and select a cmdb group on the application service as population method?

[David Skowronek]

Hello, @jeevitha gopi . The Dynamic CI Group actually is one of the Application Services. If you look into the CI Class Manager, you will see that it extends the Application Service. Therefore, you cannot use it as a population methods for another Application Service.

You may look in to the CSDM 4.0, page 18, where the description of Dynamic CI Group says:

The use cases for Dynamic CI Group include but are not limited to the following:
• As a Query Based Application Service – You don’t have Service Mapping yet, but you know these 12 servers and 3 database instances are part of MyAppServiceProd. Eliminate the old spreadsheets and use a Dynamic CI Group as an Application Service.