App Services mapped to a CI - SNC.BusinessServiceManager()?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2023 09:20 AM
I'm looking to build an easy way to determine the application services a CI is mapped to so I can use one of the group fields on it for notifications. I found a script include ApplicationServiceGraphDataAPIs that has a promising method,
var ci = new GlideRecord('cmdb_ci');
ci.get("a30667e29744f91066673f11f053af0d");
// ADZCFLS01 sys_id a30697e29744f91066673f11f053af0d
var app = new ApplicationServiceGraphDataAPIs();
var useSvcCiAssoc = true;
var ciList = [ci]; // starting with CI name
var svcList = app.getApplicationServicesAssociatedWithCi(ciList,useSvcCiAssoc);
var svc = new GlideRecord('cmdb_ci');
gs.print(svcList);
for (var i in svcList){
gs.print(i);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2023 12:30 PM - edited 10-30-2023 12:46 PM
Hi Kelly,
This API is private but is partly documented: https://docs.servicenow.com/en-US/bundle/vancouver-api-reference/page/app-store/dev_portal/API_refer...
The function you are looking at is not included so I would advise against using this API as you won’t know if/when ServiceNow changes the specification, meaning your code would break.
The Service Configuration Item Association (SCIA) table is absolutely the right place to find your data. The Service Id field should only contain a record within the Automated Business Service table hierarchy - basically all Application Service types. The good news is that it is automatically populated for most classes (only the Mapped Application Service table requires some manual logic). The bad news is that in populating this table, lots of Manual Endpoint records get created (one per CI). However you can easily filter what you need. Do bear in mind that every target CI needs to be connected to an App Service, but how many levels in the CMDB hierarchy depends on settings inside each Application Service. All types of Application service use SNC.BusinessServiceManager().populateApplicationService() - this function takes the number of levels. The maximum that can be chosen is 8 and for Mapped Application Services I believe there is a hard limit of 1,000 records per manual calculation. Dynamic CI Groups use a CMDB Group so effectively have one “level”, which means that they are always up to date in the SCIA table.
Therefore, I would advise investigating how Application Services are being populated and at how many levels in the instance you are working with. Just because you fail to find a CI in the table, doesn’t necessarily mean it’s not linked to the Application Service.
On a side note, I’m not sure whether the API has defects as I’ve noticed anomalous behaviour - one of the other parameters of the populateApplicationService() function is a list of blacklisted CI relationship types. My testing on both customer instances and a PDI is that these exclusions are sometimes ignored and the excluded types result in records being created in the SCIA table. However, as the code is hidden, I cannot identify the root cause.
It also depends on how mature the CMDB is - if Service Mapping is not in use and best practices have not been followed, then there may be unexpected CIs in the SCIA table.
If your customer is using impacted service calculation and the SCIA table, it might be prudent to add some logic to prevent inserts for classes/types that you don’t want to include in impacted service calculation.
I hope this helps!
Mat