CMDB: Dynamic CI Group data sync

[ritika2k23]

Hi All,

Can you help me understand what happens if a same CI is part of 2 different Dynamic CI Groups, then how the values (mainly the support group, change group, approval group, managed by group) are going to sync between the Dynamic CI Groups and the CI? Kindly suggest me on this. Thank You!

Regards,

Ritika

[Fabian Kunzke · Accepted solution]

Hey Ritika,

Great question!

Generally speaking you should always try to prevent a CI from being in two sepearate dynamic CI groups. From a CSDM definition standpoint that can not happen (as dynamic CI groups should only be used as a horizontal grouping service). There is one exception: If you are using dynamic CI groups as Application Services, this shouldn't apply (side note: technically it will still cause the originally stated issue of CIs being in 2 dynamic ci groups).

To sperate these two cases for the end-user, we need to make sure, that we use different relationship-types. The type used for the data sync between a service offering and the dynamic ci group should always be "Contains::Contained by". NOTE: there are also "old" documentations using a different type: "Manages::Managed by" as described here. It is unclear if the relationship type actually impacts the data sync. Update: Looking at the code, the "svc_ci_assoc" is used for most parts. THis ignores the relationship type.

You cannot actually create two dynamic CI groups for the same CMDB group, but - of course - you can have two dynamic ci groups with overlapping queries. IMPORTANT: You should always try to prevent this!

Now, what happens during the sync is (simplified), that the list of technical service offering is gone through. Next, if a TSO is connected to a dynamic ci group, related CIs are updated based on the TSO. If the schedule job gets to the next TSO, the same process starts. IF you have an overlapping dynamic ci group query, the scheduled job will get to the same CI and update it again.

In short: You won't have control about the order of action here. So it probably will end up flip-flopping back and forth between the synced TSOs. If your dynamic CI groups are related to the same TSO, then this won't matter.

tl:dr: Prevent overlapping dynamic CI groups. There are some situations where you may have to still do it. In that case make sure, that the TSO definitions are not overlapping (assign all to the same TSO). If either won't work, deactivate the TSO sync globally (although that would kind of defeat the purpose of it).

You can always use reporting to find CIs where the synched groups change back and forth. This way you will get a good indication where you have to adjust the queries.

Regards

Fabian