Custom fields on Application Service (cmdb_ci_service_auto + child tables)

[Tomas Lozano]

Hi all

I have the requirement to add a custom field that separates application services into 'types' - in the past this was something that was achieved as part of the name, however this time the type controls view and certain field logic.

Can someone advise on the following:

• Impact of custom fields towards interoperability with existing and new wizards/workspaces (service builder, digital portfolio manager workspace etc.)
• e.g. are the Service Builder, Digital Workspace Manager experiences able to include custom fields?
• the current ‘wizard’ is a Page that is not extendable with any custom fields  KB0993250

Many thanks,

Tomas

[Barry Kant]

Good day Tomas,

Service Builder and DPM are configurable as of Tokyo if I am correct. 

Side notes:
1 - Application Services are not part of Service Builder neither in DPM. 
They have their normal views and 1 specific CSDM view --> $csdm_app_service.do. The last view is static.

2 - before adding custom fields check if this can be inherited from parenting relations like:
Business Application

Technical Service Offering
If this is possible then a lookup might be a better option (depends on the use case). Adding fields in general means manual maintenance.

BR,
Barry

[Tomas Lozano]

Thanks Barry for your comments.. i was looking for someone writing about any complications/limitations who has maybe gone through the process of extending it. I'd be surprised if i was the first one tackling these requirements 😋

So far, you're correct in that (in Utah) they're both configurable:

Service Builder

via ui builder --> catalog wizard component and leveraging a catalog wizard, so you'd have to extend the sections/questions in there

Digital Portfolio Manager

In the DPM exerience, you have to copy the relevant sub-page(s) and update with necessary sections/components

2- i've already gone through that evaluation - see my answer to Jim above...

[Jim Zeigler1]

Hi Tomas,

Application Services have a class attribute that identifies the type of Application service..

Each subclass of Application Service has unique attributes to capture data needed to populate the Service.

Each Application Service class has its own List and form Views that can be customized to include custom fields. You can always create a new view if the default view doesn't have what you need.

For example, during Service Mapping, we need to capture the mapping status for all the different types of Application Services. There is no OOTB Mapping Status attribute for the Application Service class so I had to add a Mapping Status(u_mapping_status) attribute to the Application Service class(which is inherited by all subclasses). Then I added he attribute to the list and form views for each subclass of Application Service.

If the Application type you are looking for is something that you can get from the Business Application (e.g. COTS, 3rd Party,...), I recommend getting it from the business Application. BTW, the Service Classification attribute on the Service class is only used by SPM Services(ITOM uses the class name) so you could potentially use it instead of adding a custom attribute. You would have to assign new Choice values for the Application Service Class so you don't inherit the SPM service choices that were added to the Service class.

I'm hoping that all the SPM specific attributes on the Service class get moved to the new SPM classes in a future release.

[Tomas Lozano]

Hi Jim

The 'Class' field is an internally used field to separate the type of application service in technical terms (extended table) and I can't see it to provide the 'logical/organisational' classification required.

What i'm looking for is an organisational field that cannot live in another table because it directly influences:

- type of application service, e.g., whether it's a shared application service

- unique numbering on type e.g., SHR123)

- controls logic (mandatory:true)  and/or visibility of fields for the base table cmdb_ci_service_auto and all the extended tables (classes)

Thanks for suggesting the 'Service Classification' field, but unfortunately it's legacy and but who knows what relies on it and when it's being removed... I wouldn't want to build on quicksand for such a central attribute 😉

The one field i've looked at using as-is is the 'Category' string fields, but only if we delegate the creation of the record to a wizard of sorts. Then we have full control, but i'd rather not go that way tbh.

Cheers,

Tomas