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

[treidfrb]

Hi Sohail,

That's a great question as I would like to hear what others are doing with the two state fields, install_status and operational_status.  In context of my post, we are retiring applications in the Business Apps table cmdb_ci_business_app, and also the servers and databases.  Generally speaking we change those two attributes for various reasons, not always in lock step, but at decommission they would be set to Retired and Non Operational.  The APM record uses Lifecycle Status as the attribute identifying its actual state.

Best,

Tim

[treidfrb]

Hi Sohail, apologies for the slow response.  The official setting of "Retired" on install_status is the result of our decommission workflows.  We have this of server, network device, database, and APM app.  Operational_status is reserved for additional times when the application may be offline but not decommissioned.  Operational_status does follow Install_status when install_status is retired, but can also in certain use cases be set to non-operational when the CI may not be decommissioned yet.  HTH, Tim