how can we relate 2 application services using relationships so that they both reflect on the impac

chaithra10
Tera Contributor

how can we relate 2 application services using relationships so that they both reflect on the impacted sevices on CHG or INC?

Ex: we have a legal hold-prod app that uses the MID servers which are connected to ServiceNow-prod application service.

Now if a CHG is created on " legal hold-prod" , the impacted services should reflect "ServiceNow-Prod " app as well. How do I acheive this?

7 REPLIES 7

Its_Azar
Mega Sage

Hi there @chaithra10 

 

If your goal is to see both services in Impact Analysis for CHGs/INCs, I'd recommend creating a service-to-service dependency between the two Application Services (e.g., Legal Hold-Prod Depends on ServiceNow-Prod). Then make sure the relationship type is included in your impact analysis traversal rules.

If you're already modeling the dependency through MID Servers, check whether Impact Analysis is configured to traverse those infrastructure relationships. In many cases, a direct Application Service dependency is the easyy approach and gives the expected results.

☑️ If this helped, please mark it as Helpful or Accept Solution so others can find the answer too.

Kind Regards,
Azar
Serivenow Rising Star
Developer @ KPMG.

Tanushree Maiti
Tera Patron

Hi @chaithra10 

 

Refer this Get Well PlaybookKB0831505 Application Services with Business Application Relationships 

 

Also check: https://www.servicenow.com/community/common-service-data-model-forum/how-do-you-relate-dependencies-...

 

https://www.servicenow.com/community/common-service-data-model-forum/how-to-create-relations-between...

 

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti

Pratiksha
Mega Sage

You can create relationships between them as follows:

Service Instance → Depends on / Sends data to → Service Instance (CSDM 5.0)

However, this relationship will not be reflected in the Impacted Services section because impacted services are populated through the CI-to-Service Association table.

The svc_ci_assoc mapping should be automated and not maintained manually. Operators, on the other hand, can open the service instance and view the relationships directly.

I would recommend exploring the concept of a Parent Application Service. Also, review how the svc_ci_assoc table works and how associations are populated within it.

 

Regards,

Pratiksha

Mathew Hillyard
Giga Sage

Hi @chaithra10 

The above replies are not correct.

 

Impacted Service calculation does not take account of App Service to App Service relationships. So if App Service A depends upon App Service B, then when you choose App Service B as either the Configuration item, or add it to Affected CIs in a Change or an Incident, Impacted Services will not show App Service A. It only takes account of the records in the Service Configuration Item Association [svc_ci_assoc] table, and App Service to App Service relationships are not populated into this table.

 

This functionality is quite old in the platform - it hasn't changed in years - and this is IMHO a weakness of the original design.

 

You can customise to achieve this - you need to look at the TaskUtilsSNC().triggerRefreshImpactedServices() function, which eventually calls CIUtils()._getImpactedServicesFromAffectedCIs(). In this function, you'll need to check each Affected CI - if it is an App Service (which remember can be several different classes under the parent Service Instance class), then go look for a CI Relationship where the Child is the current CI, the Relationship Type is Depends on::used by and the parent Class is one of the App Services Classes, and add whatever records are found to the impactedServices object. This is not as easy as it seems as you'll have to get the Task record, then any of the Affected CIs that are an App Service Class, and then finally the Parent App Service(s).

 

Don't be tempted to go recursive (parent of parent of parent etc) or you could easily end up with 100+ Impacted Services in a large environment, which will make change approvals almost impossible.

 

I hope this helps!

Mat