Bi-directional updates of Legacy status fields and new Life Cycle stage and status

[Ed Laar]

Hi community,

There is some confusion on the bi-directional updates the Legacy CMDB status fields and the new Life Cycle stage and status fields.
In a CSDM video is stated that bi-directional updates work with some exceptions. There is also an article on this community where the explanation including exceptions is done.

To prevent from surprises: Does anyone have operational, day2day experience with this bi-directional updates? As far as we have tested all works fine but I want to be sure about this before enabling this in production.

In our scenario there is a one to one mapping between the legacy and new fields. 

Looking forward to your responses,

Best regards,

Ed

[Lyle Taylor]

The bidirectional mapping works but has caused us some issues that we have had to work around. Our issues are due to two main problems with the mapping functionality:

1. You can only map a legacy field value to a single new Life Cycle Stage/Status value, and there are many more new Life Cycle Stage/Status values than legacy values (for the OOB legacy fields we care about). We are doing bidirectional mapping between either Install status or Operational status (which one depends on the class), and we had not customized the values of those fields. We care about those fields, because discovery will maintain them in certain situations, so we want those fields and the new fields to stay in sync.
2. The business rule that does the forward mapping (legacy field -> life cycle fields) fires upon any change to the CI - not just when the field being mapped forward changes.

Note that if the legacy field you care about has legacy values corresponding to every new life cycle value (that is, every new life cycle value can be reverse mapped to a legacy value), this issue will not affect you.

This affected us in a couple different ways. The first issue means that if a user selects a new life cycle value that does not have a reverse mapping for it (because there aren't enough legacy values to reverse map to), the legacy field value does not change, and effectively becomes out of sync with the new fields.

For example, on a server, Install status only has 2 values that correspond to a server that is deployed and in use or retired: Installed and Retired - Installed corresponds to Operational, and Retired corresponds to End of Life.  However, Life Cycle Stage Status has 3 values for the Operational stage, and many more for the End of Life stage. By default Installed forward maps to Operational/In Use, and Retired forward maps to End of Life/Retired.

The issue occurs when, for example, you move an Operational/In Use server to, say, End of Life/Pending Disposal. That server is clearly retired based on the new field values, but because there is no reverse mapping that tells the system that Install status should now be set to Retired instead of Installed, it stays set to Installed and becomes out of sync.

This is where the second issue comes in. So, the legacy and new fields are out of sync, and the business rule that performs the forward mapping (from the legacy to the new fields) fires on update, but without qualification, so it runs on all updates. When it runs, it compares the legacy field with the new fields, and if they're out of sync according to the mapping definitions, it forward maps the legacy field to the new fields. So, in the example above, our retired server gets updated so that Life Cycle Stage and Life Cycle Stage Status match the value in the Install status field (Installed), and sets it back to Operational/In Use.

This specific scenario bit us on a large number of servers, and has affected us with other classes as well. There is a work around, but it also has its issues in this specific scenario.

The workaround is to define custom legacy values for each of the additional new values that you want to use. So, for our server case, that means adding a new custom value to Install status that we can map to End of Life/Pending Disposal. This "fixes" the out of sync issue but introduces a new issue. OOB, when a retired server (Install status = Retired) is discovered, it will set Install status back to Installed. We want this to happen. However, now that we have to set Install status to a custom value for our retired server, the code that sets a discovered server that was Retired back to Installed no longer works. So, we've traded one issue for another in implementing the workaround.