Question on actual usage of cmdb_ci.attributes field

[treidfrb]

Hello CMDB community,

RE: we are on UTAH version

We are building a special decommission process using APM and server/database to APM relationships.  We need a way to identify a database server as being a shared database server,   I have a database view to connect windows server to instance to database, and I can identify windows servers that are database servers that have multiple MSSQL databases,  Once I vet the list of windows servers that are shared database servers, we want to mark the server CI as such and exclude them from the server decommission process, without doing the fancy lookups and decisions.  The DBAs will tell us which are shared and which are not.  I have reviewed the two KBs on the topic of custom tables and fields prefixed with "u_" but in this case, I would like to know how to use the 65000 byte field called cmdb_ci.attributes.

KBs:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0832206
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0832208

I could see the benefit in giving the dictionary at the top level (cmdb_ci.attributes) a default value, but I really don't need it above cmdb_ci_server, but the question still applies.

Questions:

1. should I or should I not use a default value?  It seems I should for the downstream evaluation to always have a value to test against.

2. should I add the value to the records in cmdb_ci_server.attributes?  From the KB example of cmdb_ci_hardware I think this is the proper level to add it to.  There may be a linux server that needs this, or some other OS vendor or version.

3. what should be the format of the data added to the field cmdb_ci_server.attributes?

Format of the data in the field:

All I am looking for is to have a boolean field I can test in cmdb_ci_win_server that tells me this is or is not a shared database server.  If it is shared, then do not perform decommission, leave that for the DBAs to do later when all apps are decommissioned.

//---------------------------------------------------------------------------------------------------------------------------------
// data entered into the attributes field in cmdb_ci_server:
// shared_database=true
// Idea#1 For multiple values, comma separated key=value
// shared_dattabase=true,linux_flavor=redhat6
// Idea#2 For multiple values, JSON format
// "shared_database":"true","linux_flavor":"redhat6"
//---------------------------------------------------------------------------------------------------------------------------------

Is there some documentation with examples on how this field is to be populated?

Thank you!  Happy Holidays

Tim Reid

[Maik Skoddow]

Hi @treidfrb 

you are mixing some different concepts.

Inside a CMDB we don't talk about tables but classes, and we also don't talk about fields (table columns) but attributes.

That shouldn't be mixed with the attribute "attributes" at class "cmdb_ci". 

And to be honest, it's the first time I come across that "attributes". I also couldn't find anything about it anywhere. Therefore, I assume it's a left-over from the beginning but was never used.

To my mind, the best solution is a CI upgrade to a newly created child class "MSSQL database (shared)". This can be done easily, see https://docs.servicenow.com/bundle/vancouver-servicenow-platform/page/product/configuration-manageme... 

The problem with usage of the "attributes" attribute: it is difficult and maybe also impossible to query the respective information from a 64K string type.

Maik

[treidfrb]

Hello Maik,

Thank you for your reply and your point of view.  I find creating a new class in CMDB as a solution to identifying a Windows Server in a particular role does not align with my philosophy of a simpler solution is better.  I did a bit of reading on the usage of the attributes attribute and the links I provided showed that ServiceNow has had a purpose for this field, to help customers get away from creating custom attributes in OOTB classes, and even to correct those types of changes made in the past.  My focus was to follow their guidance on this.  The links I provided are dated 2023.  I have had no issue searching on XML data placed in the attributes field.

Regards,

Tim

[treidfrb · Accepted solution]

There have been no other replies so I will consider our use of this field, as described in the KBs provided by ServiceNow, to be the best solution possible.  I didn't previously mention it, but looking at the entire CMBD from cmdb_ci parent to all children, only the classes of "Web Application" and "Tomcat" are being populated by Discovery.  In our case the "Denodo" web application is deployed to Tomcat, so the use of the attributes field for these two classes for storing the server.xml file which controls the application. 

https://docs.servicenow.com/bundle/washingtondc-it-operations-management/page/product/discovery/refe...

 It does seem odd to me that the attributes field would be created for the purpose described in the KB, yet some seemingly arbitrary data from discovery is being placed there, for only a couple of classes.  At my next opportunity with a CMDB SME from ServiceNow I will raise this question about this field.  

[Sohail Khilji]

@treidfrb ,

Just a quick question, As part of your decommission are you just setting the CI state to > non-operational, or do you have to take any other actions as part of your decommission ?

Thanks,

Sohail Khilji