Application Service (cmdb_ci_service_discovered vs. cmdb_ci_service)

J Shone
Kilo Expert

Looking at the white paper I am a little confused on Application Service.

 

Application Service is defined as "Logical representation of a deployed application stack"

It maps to cmdb_ci_service_discovered and the white paper does not mention cmdb_ci_service (classification=application).

That said the PDI examples of Application Service are using cmdb_ci_service.  And the service classification is available on cmdb_ci_service for Application Service.

What are ServiceNow saying or what is your real-world experience?

If you haven't enabled Discovery do you use cmdb_ci_service (classification=application)?  

Once you enable discovery do you convert to use cmdb_ci_service_discovered?  

Or are both tables meant to be used in parallel?

 

 

1 ACCEPTED SOLUTION

Giles Lewis
Giga Guru

Great question!

cmdb_ci_service_discovered is a legacy table that was created several years ago as part of the Service Mapping product. When CSDM was introduced they decided to repurpose the existing table. You are supposed to ignore the fact that "discovered" is part of the name, and feel free to manually populate the Application Service table. (I am not sure what happens later if you decide to install Service Mapping; but I assume they have figured this out and there are no worries.)

Note that in the class model cmdb_ci_service_discovered inherits from cmdb_ci_service. If you add a record to Application Service [cmdb_ci_service_discovered] then it is automatically added to Business Service [cmdb_ci_service]. You can also convert a Business Service to an Application Service.

View solution in original post

19 REPLIES 19

Darin2
Tera Contributor

If you are starting down the path of building out your App Services, I highly recommend using the table that is recommended in the CSDM. This is the structure that other products within ServiceNow are going to start to leverage. 

I agree that the use of discovered in the table name is confusing, but it is no longer just for Service Mapping. By putting your App Service records in this table, it will set you up for doing Service Mapping in the future. But with the Paris release, more and more products are going to align to the table structure in the white paper.

My recommendation is to follow the recommended tables unless you have a reason (very strong reason) based on your organizations use cases to deviate from it. 

amititp
Giga Contributor

Absoulately, keeping it scalable towards upcoming releases of SNOW has much better leverage. In addition, following hiearchiey pic would hint you on the aspect of CSDM alignment.

Darin, Alec, feel free to correct.

 

find_real_file.png

Perfect Picture example!

Community Alums
Not applicable

To add more context to the diagram above with technical names of the table. So it is easier to follow which technical table should be used for an application service identified in a specific manner.

find_real_file.png

Runjay Patel
Giga Sage

Check out this video, it will clear all your doubts and help you to understand Service Mapping queries in details.

Link: https://www.youtube.com/watch?v=VN33mZiHBj0&t=1s&ab_channel=ServiceNowHelpdesk

 

It help you to understand below points.

  • Service Mapping Overview
  • Service Mapping Plugins Required
  • Service Mapping roles management
  • Service mapping credentials for different ci type
  • Verify that Service Mapping is set up properly (Readiness)
  • Service Mapping setup step by step
  • Service Mapping troubleshootings

 

Please mark reply as Helpful/Correct, if applicable. Thanks!!