Avoid deleted Cis while synchronize Cis between 2 uCMDB

Idea ID 1647650

Avoid deleted Cis while synchronize Cis between 2 uCMDB

It is needed to synchronize all important Cis between 2 UCMDB to have all of them in one main UCMDB. It is also needed to synchronise the data with a “UCMDB Push”, including the deletion of Cis, and is needed to discover and synchronise everything every day. Since the data is huge, cannot do full push all the time, so it is needed to do delta sync.



1- UCMDB doesn’t look what the target UCMDB have when he wants to sync. The sender UCMDB just keep a baseline of what he thought was previously transferred, so it’s already not really robust at first. And if you modify a TQL, then the baseline change, so it’s creating more problems to know what needs to be deleted or not in the target system.

2- The new specific problem that we saw, is that a CI will be deleted in the target system as soon as it’s not in a TQL anymore, even if the CI still exist, only because a relationship is not there anymore.


Let’s take the next 2 little TQL (See attachments). The relationship is 1-N, to avoid pushing everything everywhere all the time. So on day 1, a computer has a tcp port and installed software, so it’s in both TQL and send the data correctly to the other UCMDB. On day 2, this computer doesn’t have tcp ports anymore but still have the software. Since it’s not in the first TQL anymore, the server would be deleted in the destination UCMDB, ouch.

Possible solution :

A) Merge both TQL in 1 TQL. But since in reality I have many tql and some a lot more complex, it would be really big to include everything with optional Cis in the same TQL. And in this case, if a node have 0 ports and 0 software at a given time, it would delete the node anyway execpt if I include my soluation #B. And it would be long to test to confirm that there’s no error.

B) In each TQL, do 0-N relationship instead of 1-N everywhere. That way, all the servers would be push in both TQL, even if they have no port or no software at a given time. In theory, it would work, but it would make my TQL containing a lot more CI. In a simple example like that it would not be too big to include all nodes in both, but since I have many tql, and some are more complex, it would create a really big load to try to put 0-N relationship on everything. Some tql would move from few thousands Cis to few millions Cis, and many would be duplicate from other TQL. And I would have to include my solution #A at the same time to avoid duplicate data as much as possible. And it would be long to test to confirm that there’s no error.

C) Was tried to “hide” some object in my tql, to only push the main CI in a TQL and the relationship, but it failed because the node or other related Cis were often mandatory.

D) Could stop to include the deletion in the push job. The problem is that there would be no way to clean up the data in the destination UCMDB.  Could not have aging unabled, cause aging doesn’t support multi ucmdb. I say this because the delta push doesn’t sync data when there was only a touch to it. So if a CI doesn’t change, in the first system, it would become old in the target system without any way to know if it should really be deleted or not. And even if you could include the delta sync to sync when there’s only a touch since we discover everything every day, it means or delta sync would become a full sync, and it would be too big.

Tags (2)
Honored Contributor.
Honored Contributor.

Hi, If a solution will be implemented to delete a CI only when it was actually deleted in the sending CMDB [not just from the TQL], will it resolve it?

Super Contributor.
Super Contributor.

Hello everyone, there is only one way to keep two UCMDB synchronized - Implement CI Type deletion capability management on integration job level instead of adapter level. I already have such ER - https://softwaresupport.softwaregrp.com/group/softwaresupport/search-result/-/facetsearch/document/KM03014048

Workaround how to be now - copy CMDB Adapter with different name , for example - CustomCMDB10.xAdapter. Use first adapter to delete only CIs and second one to delete only relations.


PS Also keep in mind that the workaround works fine only for push integration type with disabled "Auto Complete Reconciliation". My advice is never to use "Auto Complete Reconciliation" because it brings more problems than good.

Honored Contributor.
Honored Contributor.
Status changed to: Waiting for Votes

Thank you! The idea has received an initial review to ensure adherence to our idea submission and community guidelines. We ask the community to help prioritize the idea with comments and community support (votes/kudos).

Trusted Contributor.
Trusted Contributor.

Hi guys,

if I'm getting it right the core of the sync-deletion problem is the missing overarching lifecycle concept "aging".

Refering to "I say this because the delta push doesn’t sync data when there was only a touch to it. So if a CI doesn’t change, in the first system, it would become old in the target system without any way to know if it should really be deleted or not." - Wouldn't controlled transfer of the "IS CANDIDATE FOR DELETION" etc. from uCMDB1 to uCMDB2 keep it from being deleted when my following proposal would be implemented:

IMHO if adapter or integration level deletion would work on lifecycle control attributes like






instead of just one "DELETION ALLOWED" flag there would be much finer control available for synching.

One could do all sorts of creative lifecycle management then, even with multi-integration setups or chained uCMDB integrations.

Let me know if I'm totally wrong here or if it makes sense to you 🙂




The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.