- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 02:10 AM
Use case: I have an application APP01 and it runs on servers named like this LVNAPP01, ROMAPP01, PARAPP01, ...
I can link all these servers to the application service APP01 using Dynamic CI group and selecting a CMDB query that filters all servers that contain "APP01'.
But, what I can't do is set a relationship that says that that the application APP01 runs-on these servers.
And if I enter an incident for the APP01 or for one of the servers, I don't find the relationship between both in the dependency view.
Is this not possible or am I missing something?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 07:24 AM
According to how an Application (cmdb_ci_appl and subclasses) is defined, it represents a specific application running on a specific server. It should run on multiple servers. Rather, you should have an application running on each server. For example:
APP01@LVNAPP01 == Runs on ==> LVNAPP01
APP01@ROMAPP01== Runs on ==> ROMAPP01
APP01@PARAPP01== Runs on ==> PARAPP01
There are two common scenarios where you would have this pattern: in one case you are looking to represent an Application resource that is running on multiple nodes of a Server cluster; in the other case you are running the same Application on multiple servers that are each part of different instances of the overall Business Application, i.e. separate Application Services. In each case, there would be a separate Application CI for each Server, as the Application represents a distinct running process and software installation. How this looks in the Dependency Map will be different depending on which scenario you are looking at.
As for creating an Incident against the Application, typically a user isn't going to be selecting the application directly, but rather, would focus on the Application Service that depends on the specific Application(s); the CI would only be set to the Application either as a result of application monitoring / event management which would automate the incident creation based on where the issue was detected, or based on further analysis by the support team who is working the incident as they get closer to refining the root causes of the incident. However, if the user does select the specific application, they would see only the specific server it is running on. If they wanted to see the Application Service which contains multiple Applications running on multiple Servers, they can refocus the dependency map on the Application Service node.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 06:45 AM
Hi Anne,
ootb incident checks on cmdb_rel_ci table.
ootb change check on svc_ci_assoc table.
Can you check the same in change mgmt and see for the results?
My guess is that you will have to expected outcome (not 100% sure).
If so then there are 2 options:
convert the system property for incident refresh impacted services (use affected CIs).
That is a technical version of this quest.
Personally I wouldn't use Dynamic CI Groups to link to Application Services. I would use the Calculated Application Service and yes you need to make the relations for this.
You can also use tag based Application Services then instead of query by name you can use the tag value for the same.
I use Dynamic CI Groups for relation to technical service offerings and to group assets to business service offerings (sometimes).
Not sure if that helps.
BR,
Barry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 11:21 PM
Hi Barry,
interesting info. I was not aware of the difference between the incident and change difference ootb.
I can't check how it looks in change as the application service (dynamic CI) cannot be selected the way we build it. If we continue to use this, I'll need to have this updated.
When using the Calculated Application Service we would need to linkt the servers to the app manually. That was what I was trying to avoid.
I also tried to use Tag based Application Services but I can't get it to work. I tried several ways but I do something wrong or do not understand how it works.
See example of servers that I tagged
This is one example how I did the setup. but whatever I try, I never get results.
As you mention, it probably does not make sense to use dynamic ci groups for application services
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-14-2024 02:05 PM
I know this is over a year old, but just in case another person comes across it, the tagging you have listed in your example is the "platform" based tagging. That is not the tagging you need for the "tag-based" mapping. To use those tags, typically pulled from discovery, but you can manually create them, they are created in the [cmdb_key_value] table. There is a field for the CI, key (the tag) and a value of the tag.
To use tag-based mapping, you need to setup a few other records before it will work properly. You need to create a Tag Family, then within that you would put in the categories. The categories themselves have some details you need to fill out, which are the actual "tags" you are looking to match up (tag key).
This link might help you or others out on this topic:
https://docs.servicenow.com/csh?topicname=map-service-tag.html&version=latest
Good luck all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2023 07:24 AM
According to how an Application (cmdb_ci_appl and subclasses) is defined, it represents a specific application running on a specific server. It should run on multiple servers. Rather, you should have an application running on each server. For example:
APP01@LVNAPP01 == Runs on ==> LVNAPP01
APP01@ROMAPP01== Runs on ==> ROMAPP01
APP01@PARAPP01== Runs on ==> PARAPP01
There are two common scenarios where you would have this pattern: in one case you are looking to represent an Application resource that is running on multiple nodes of a Server cluster; in the other case you are running the same Application on multiple servers that are each part of different instances of the overall Business Application, i.e. separate Application Services. In each case, there would be a separate Application CI for each Server, as the Application represents a distinct running process and software installation. How this looks in the Dependency Map will be different depending on which scenario you are looking at.
As for creating an Incident against the Application, typically a user isn't going to be selecting the application directly, but rather, would focus on the Application Service that depends on the specific Application(s); the CI would only be set to the Application either as a result of application monitoring / event management which would automate the incident creation based on where the issue was detected, or based on further analysis by the support team who is working the incident as they get closer to refining the root causes of the incident. However, if the user does select the specific application, they would see only the specific server it is running on. If they wanted to see the Application Service which contains multiple Applications running on multiple Servers, they can refocus the dependency map on the Application Service node.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.