Application Service (cmdb_ci_service_discovered vs. cmdb_ci_service)

J Shone · ‎04-20-2020

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?

Giles Lewis · ‎04-20-2020

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

amititp · ‎02-04-2021

in addition , you may also look into following, for any previous old table transformation.

https://community.servicenow.com/community?id=community_article&sys_id=a777f564db9dbfc4d58ea345ca961996

Regards,

Amit.

Alec Hanson · ‎02-08-2021

But interestingly for Manual Application Service the docs say:

"The Manual method for populating an application service, is based on selecting an entry point CI, which lets users access the application service. To populate the application service, you then manually add CIs to the new application service."

So you still need to create an entry point for Manual application services, which seems slightly at odds with the "Manual" nature.

jimmillet · ‎02-08-2021

I was able to create an "empty" Application Service CI using the procedure in the first link provided by Casper above. So I have Application Service CI with no relationships and was able to move to "Operational". I used this procedure to test out the concept. Since I had over 200 of these CI's to move from Application (cmdb_ci_appl) to Application Service, I just went to cmdb_ci_appl.list and used "list edit" to change the class to Application Service. So I am good now, and positioned for future manual mapping when the client is ready (as I mentioned, this small client does not have SN Discovery or SN Event Management).

Thanks to all who replied.

Alec Hanson · ‎02-08-2021

Super, I see if you do not choose a Population Method it will created it under cmdb_ci_auto. Useful to know.

Les1 · ‎11-18-2021

additional detail, we're on Quebec

we found that this PRB fix is still not fixed in our Quebec instance:

Configuration Management Database (CMDB) PRB1411702	Two cmdb_ci_service tables (_auto and _discovered) share the same display name 'Application Service'	Two separate application service tables share the same displayed label of 'Application Service', whereas the cmdb_ci_service_ discovered table should be showing 'Mapped Application Service'.	Navigate to the Tables module. Search for tables with a name starting with 'cmdb_ci_service_'. Notice that both cmdb_ci_service_auto and cmdb_ci_service_discovered have the label 'Application Service'. If you search these same results for the label = 'Mapped Application Service', cmdb_ci_service_ discovered will come back as a result even though the label column shows 'Application Service' due to getDisplayValue().