Application Service attributes

[Stuart J]

Hello,

We are in process of planning the migration from the "old"  Business Service approach  to a CSDM, and would llke the forums advice please

There is a debate within the team about adding  existing custom attributes to the Application Service  table.  The reason being that some of these are "environment specific"   The other side of the argument is that Applications Services is  the logical "glue" that brings everything else together and should be kept as simple as possible.  Is there any downside with adding lots of custom attributes to the Application Service ?

Also if we initially populate these Applications Services manually ie cmdb_ci_service_auto,   Is is simple to convert these to Mapped or Calculated applications services at a later date

[s4scott]

It is perfectly fine to add custom attributes to the Application Service table, but think carefully about the scope of those attributes, it may be better to place them higher in the class structure, in the base service class (cmdb_ci_service)  or the base cmdb class (cmdb_ci). If there is any chance you will use a particular value accross multiple classes, place that field higher in the structure.
In general you should only add fields to a form that yield positive productivity benefits. Depending on the size of your environment, there can be a performance cost as the field count goes up. In my experience though, related lists tend to drive most of the UI delay.
The cmdb_ci_service_auto, cmdb_ci_service_discovered and cmdb_ci_service_calculated will contain the same type of records, but have different purposes. Check out this article for more details: Application Services: How to use them?

[SteveMacWWT]

I'm curious as to what type of custom attributes you are adding. One thing I've seen is where companies will add custom fields at that level that either exist at a different level (e.g. Business App) or that can be found by looking at related tables where the information is more appropriate. 

The first step I try to follow is: A LOT of other companies use this out of the box, what is special about my implementation that means I can't follow the same process. Sometimes there is a good reason, most times there is not. 

I'd also caution about taking the phrase 'If there any chance...' too liberally. This can lead to bloat where it is not needed, as well as those attributes being used for something different than what was intended. I know of a company that added most attributes at the cmdb_ci level and had a hell of a time unravelling that mess when they wanted to take advantage of new features that SN provided. 

[Barry Kant]

hi, 

for a data (class) remediation is is always needed to investigate the current custom attributes as in:
does the attribute belong on Business Application Business Service Offering or Application Service.

I would not recommend to add custom attributes on base tables. (overhead)
in general you can inherit attributes by parent records. 

A lot of fields also means (manual) administration.

an intermediate step could be to map all know attributes and consolidate all unmapped attributes from the source table in a JSON string and write it to the attributes attribute in the target table. So at least you have the information. Then when the investigation is done i can be administered accordingly without creating overhead upfront.

BR,
Barry