I would have a question related to data loading in uCMDB. If this is not the right forum, please redirect me. I would like to interface a large repository providing java interfaces (like an external inventory). Likely to be a large number of CI types and a large volume of data (several 100K to several millions) to replicate.
I read the docs on federation and DDM. I understand a federation adapter can do replication, but it is not clear what are the exact differences vs using DDM scripts for doing that and what are the advantages/drawbacks of each.
P.S. This thread has been moved from Application Perf Mgmt (BAC / BSM) Support and News Forum to CMS and Discovery Support and News Forum. -HP Forum Moderator
Well the first question you have to ask yourself is do you really need the information replicated within uCMDB. Sometimes this information can also be federated. And with the latter i mean that the information is not replicated to uCMDB but will only be retrieved if someone requested for it e.g. running a view, running a report etc.
The uCMDB has the following options: - real federation. This is by using the federation adapter to configure it to know where to find the information when requested. Data is not replicated but only the structure of data has to be configured and to what CIs it relates within uCMDB. Very powerful feature because it is old days thinking to have one monolithic CMDB storing all CIs. This functions is especially useful if the datasource contains data that is often changing or only needed sometimes. - replication using federation adapter. If you want to replicate a source then the best place is to define a federation adapter for replication. In here you can define the name of the source, some credentials, the CI-types you want to replicate and the schedule. This adapter is visible within the federation part of the uCMDB. The federation adapter is running from the central server. - DDM pattern. These are best used for the real discovery work going out to several systems requesting information. So the DDM is good for the auto discovery work. But a DDM pattern can also be used for doing a source replication (no federation). If you define an pattern it will be visible within discovery manager. DDM patterns are running from DDM probes. You could for instance introduce one probe next to the source you want to replicate.
There is not much difference between federation adapter and DDM pattern if used for replication. There is a though a difference between federation and replication. And that has to do with the uCMDB functions enrichments and change tracking which for now are not possible with real federation.
But it is also a matter what you like to do. Some people handy with writing a DDM pattern prefer that way where people having knowledge about the federation adapter prefer it that way.
KPIs is something for BAC right not for uCMDB only.
Real federated CIs can be replication with SM this will work. But if you are looking for updates on changes on CIs to SM then that will not work. Because in real federation you don't know what is changed. So only replication will work.
And for the current version of uCMDB (8x) you indeed cannot have multiple real federation after each other. Assuming you use the OOTB real federation of incidents.
Looking at your response it looks like you're talking about hosts, and i think this can be best replicated to uCMDB. Host is one of the important CI-Types within uCMDB. It is used almost in every query or view and if you want to replicate to SM you definitely want to replicate on changes. This can only be done on replicated CIs where uCMDB can track if a CI is changed or not. Don't forget to replicate the unique id of the source CIs, this makes the reconciliation of the data much more easier.