2 Questions on CSDM view for Service Mapping

Lucky1
Tera Guru

Hello all,

 

Good day!!

I am working with Service Mapping currently and I have 2 questions to get clarified.

Lucky1_0-1757514907464.png

 

So, while configuring the business application, we are considering the "Architecture type" field on it, 

If the Architecture type selected is Platform Application, then "Platform Host" field is visible and mandatory. (oob feature). So, if we select a platform Host, then under that Platform Host, the Business Application with Architecture type "Platform Application" will be shown up. (like in the pic I have shown)

Question:1)

So, is it really needed for every business application there should be platform Host to be shown on the top of it?

If there are two business applications or more than that, then showing all of them under a platform Host is fine. But If we have only one business application then is it really required to map it with platform host and showcase that also? 

 

Question:2)

The infrastructure (like Servers, Databases, VMs),

So, should these be mapped with Native application (cmdb_ci_appl) or can be directly mapped to Application Services itself?????

 

 

Our current CSDM design is:

Business Application (Platform Host - hosted on server) ------ > Business Application (Platform Application) ------> Application Service (Mapped Application Service) ------> Application -------> Infrastructure (Linux, VMs etc).

The Technical and Business Service Offerings are connected with Application Services.

 

 

Please make me understand on these two questions.

 

 

 

Regards,

Lucky

 

6 REPLIES 6

Hi @Lucky1 

Please review the linked article below: https://www.servicenow.com/community/itsm-articles/how-to-configure-incident-management-to-align-wit...

 

This gives the preferred method of populating the fields. However to add to that article my recommendations are as follows:

  1. Make the Service field read only
  2. Make the Service offering field change in response to populating the Configuration item (either auto-populate if CI is related to only one offering, or set the reference qualifier on offering)
  3. Make the Configuration item field change in response to populating the Service offering (as above, either auto populate if offering is linked to only one CI, or set the ref qual if there is more than one linked CI).
  4. If all fields are empty, then the reference qualifiers on the fields should filter out non in use records (e.g. retired).


The advantages of this is that you only really need to populate one field (if you know the CI) to have the rest populate in a cascade (generally avoid a single CI supporting multiple offerings, so it should be an edge case), but the "friendly" name - the service offering - is available.

 

Note that there is no coding in the platform to handle any of this - handily I've provided the script include mentioned below to accommodate this.

 

I hope this helps!

Mat

 

Ashish77
Tera Contributor

@Mathew Hillyard Thanks for the explanation, 

What are your recommendations on customizing reference qualifier for Service and Service Offering fields on Incident and Change to only show Published services and offerings.

I am planning on triggering approval by enabling and customizing OOTB subflow "Service builder publish". I want only state = published should be visible on ITSM task tables.