Synchronizing Operational Status and Status

[Daniel Needles1]

What is the best practice for synchronizing Operational Status and Status across the generations and is there a document indicating which tables need to be touched for which classes of devices?  I am seeing the way ServiceNOW handled issues with table joins was to simply break normalization and duplicate certain fields across great grand parent/grandparent/parent/child relationships.  Lol.  Ah yes. I love co-dependency and triangulation in my databases. Lol  https://en.wikipedia.org/wiki/Triangulation_(psychology)#:~:text=harmful%20to%20children.-,Child%20d....

Anyway I wanted to see if there was a best practice on keeping Status in sync across the generational change and prevent Triangulation and other fun database to psychology equivalents such as cmdb_ci Operational Status updating cmdb_ci_linux_server but skipping over all the tables inbetween.

Because status information is duplicated everywhere, there really needs to be a doc on what should be touched (I believe 5 tables in the case of a Linux Server) in order to keep the integrity of the Status information intact across all the CMDB.

[Mike Marson · Accepted solution]

Hi @Daniel Needles,

It would be good to understand if by "generations" you mean the hierarchy of parent-child classes in the ServiceNow data model?   For example, your example of cmdb_ci_linux_server is at the 6th level of the cmdb hierarchy:

cmdb_ci_linux_server, extends

cmdb_ci_server, which extends

cmdb_ci_computer, which extends

cmdb_ci_hardware, which extends

cmdb_ci, which extends

cmdb.

The columns you refer to, Operational Status and Status, exist at the CI/Base CI level.

From a logical perspective, there is only one set of these attributes, and they originate at the aforementioned level.   They may be viewed at different levels of the hierarchy, in the same way that every Linux Server _IS A_ Server, and thus can be found in cmdb_ci_server (as the same record with the same sys_id), and _IS A_ Computer, and thus can be found in cmdb_ci_computer (as the same record with same sys_id), and so on.   Physically, how it is actually realized in the actual MariaDB schema depends on the Extension Model used for the table/hierarchy, and can differ from instance to instance.   But that should all be abstracted away from you as the user.

So whether there is a true, single field at a database level, or if there are multiple realizations of it, should not matter to you as a user.   If you update the Operational Status (or any other attribute) of a CI in cmdb_ci_linux_server, you should _not_ have to also update any representations of Operational Status of the same CI in any the parent tables.  The instance should keep everything in sync automatically as necessary.  

If you are seeing a different behavior in your instance, it would be good for you to share specifics.  You might need to open a support case for it too.

Regards,

Mike

[Daniel Needles1]

Yes, hierarchy = generational.  And thanks for providing the insight of the internals!  It is good these are synched up.  I got a side response on a ticket that said they were independent.  Glad to hear that was false!!  Had me freaking out a bit. Lol.

[VaranAwesomenow]

https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/configuration-management/concept/cmdb-ci-lifecycle-mgmt.html

[Daniel Needles1]

Under Rome it says (Legacy) as a Caveat.  Is this outdated Rome forward?