- My View
I have a couple of questions concerning CI status and syncing them to their corresponding Asset.
First of all, which field to us on CI, the general opinion seems to bet that you should use the install_status field on ci’s although I can’t really get a definitive answer on this.
Next question is concerning custom states on subclasses. For instance, we’ve introduced custom states to cmdb_ci_computer to match our computer lifecycle. Mappings in the ‘Asset-CI install status mapping’ module only works for states defined on cmdb level so i can’t map the new cmdb_ci_computer values to asset values.
If I were to add the custom states on cmdb level they would be available on all descendant classes and I still can’t map them to the desired asset states because there for most there already is a mapping with direction ‘both’. The already existing mapping I can’t edit (not without altering the ACL anyway) because they are out of the box.
So, I’m wondering how this is all supposed to work, which fields to use and how to deal with custom states on cmdb classes? How is everyone else doing this? The option as I see them:
- create an extra status field to hold the custom states, map them to existing install_status values which in turn map to asset states
- create custom states on cmdb level, also create them on asset level and map those to each other.
None of these seem like great options to me.
Hopefully you can offer some suggestions.
look at 'alm_asset_ci_state_mapping' & 'alm_hardware_state_mapping' tables for state mapping between CI to Asset tables.
I guess system should take care of syncing the states once you enter the new states in these mapping tables.
Thanks for you reply. The problem with these tables is that they look to the 'cmdb' and 'cmdb_ci_hardware' tables respectively so I would have to introduce my custom states on those levels while they are specific to computers.
Even if I introduce them on lets say cmdb_ci_hardware level I still can't map them to existing Asset states because the out of the box mappings are in place and blocking the creation of new mappings to existing Asset states. Out of the box I can't edit these mappings unless I customise the ACL on that table.
Its not that it can't be done I'm just wondering how these situations should be handled from an OOTB perspective and how others are handeling them.
This is one approach on it: http://www.servicenowelite.com/blog/2013/12/20/how-to-sync-assets
I'm not too happy about customizing the AssetAndCISynchronizer script include though.
It would be nice to hear your take on it bsweetser - how would you approach this?
Morten and mjl1983,
I would avoid any approach that modifies that script include. That post was from prior to the time when we had these mapping tables to simplify this.
mjl1983, out of curiosity, what are your new status values that you are looking to add?
My recommendation is to use the install_status, as it covers more types of CIs than the hardware status.
Normally, I would recommend putting the custom options on the top level you want it to be available, but in this case you will need to use the higher level classes. You could hide the values on the higher classes with a client script. This will make them available to you in the mappings, but prevent them from being displayed as options in the classes above computer.
I do have a concern with the mapping, though, if you do this: If you map to your custom options from the Asset State, you have the potential to set an invalid status on your CI. Can you please describe some more specifics of your use case here?
Ben Sweetser, Principal Business Process Consultant