Best Practice for non IT CMDB setup

AlanK
Tera Contributor

Hi All 

I have an interesting scenario where a customer wants to manage the operations of a number of non -IT items in the CMDB. I would like to know where should i extend off? 

Some more criteria/ background

  1. There is no need to generate a dependency map, just leverage the operational lifecycle
  2. if I add the branch at the cmdb level I can at least extend to be u_cmdb_class
  3. if I add at cmdb_ci it by default will show in all the CI fields at task layer.
  4. it seems the relationship table of cmdb_rel_ci operates at the cmdb_ci level instead of the cmdb layer, so i am stuck with using rudimentary parent child relationships instead of contains and depends on. 

It seems guidance says start at the cmdb_ci table, but it doesnt make sense as CI is all stuff IT related.

 

Anybody have any ideas?

1 ACCEPTED SOLUTION

Hi,

Despite the extra attributes, the way to go is extending from the cmdb_ci, but you don't need to create these Vehicle classes as custom, since ServiceNow has already created Aircraft, Train, Vehicle, and Ship classes in their "CMDB CI Class Models" application: link to Store.

These tables are extended from a "Transport Type" class which is extended from cmdb_ci as seen below.

find_real_file.png

Hope this helps.

EDIT: I just checked the default form view for the Vehicles class and.... well... there's some work to be done. But at least the tables are already there OOB.

find_real_file.png

Cheers,

--Mikko

View solution in original post

4 REPLIES 4

mikkojuola
Giga Guru

Hello,

I don't see any reason why you should not extend the cmdb_ci table to achieve what you want. For the extended classes you can anyway define their own form layouts and decide which attributes to use and what not. CI relationships can be defined per class as well. ServiceNow has lots of capabilities that rely on CIs being extended from cmdb_ci instead of cmdb, so I would not extend from cmdb.

May I ask, what type of non-IT CIs you are working with?

Best regards,

--Mikko

AlanK
Tera Contributor

Hi Mikko

Thank you for the insights

The main reason for wanting to extend from the base table is simply CI is very much IT related and as such touches all parts of the ITSM suite. The end result is ongoing technical debt.

the non IT components are Vehicles, Aircraft and heavy plant equipment. The argument i have heard is that these are assets, but no, we are looking to maintain an operational lifecycle for them. 

Defining a clean set of attributes from the base class makes more sense than having IT attributes floating about .

By the same token, you would really create your own class of "vehicles" on the asset side instead of lumping all these models into hardware, so why shouldnt the cmdb follow the same data model?

 

  

regards

 

Alan

Hi,

Despite the extra attributes, the way to go is extending from the cmdb_ci, but you don't need to create these Vehicle classes as custom, since ServiceNow has already created Aircraft, Train, Vehicle, and Ship classes in their "CMDB CI Class Models" application: link to Store.

These tables are extended from a "Transport Type" class which is extended from cmdb_ci as seen below.

find_real_file.png

Hope this helps.

EDIT: I just checked the default form view for the Vehicles class and.... well... there's some work to be done. But at least the tables are already there OOB.

find_real_file.png

Cheers,

--Mikko

AlanK
Tera Contributor

Mikko, this will definitely be a help, I missed this completely in the store. Thanks for this