Data Flow Management and Integration

DFM adapters are capable of integration with other products. Consider the following definitions:

• DFM collects specific content from many targets.

• Integration collects multiple types of content from one system.

Note that these definitions do not distinguish between the methods of collection. Neither does DFM. The process of developing a new adapter is the same process for developing new integration. You do the same research, make the same choices for new vs. existing adapters, write the adapters the same way, and so on. Only a few things change:

• The final adapter's scheduling. Integration adapters may run more frequently than discovery, but it depends on the use cases.

• Input CIs:

  • Integration: non-CI trigger to run with no input: a file name or source is passed through the adapter parameter.

  • Discovery: uses regular, CMDB CIs for input.

For integration projects, you should almost always reuse an existing adapter. The direction of the integration (from Universal CMDB to another product, or from another product to Universal CMDB) may affect your approach to development. There are field packages available for you to copy for your own uses, using proven techniques.

From Universal CMDB to another project:

• Create a TQL that produces the CIs and relations to be exported.

• Use a generic wrapper adapter to execute the TQL and write the results to an XML file for the external product to read.

  Note For examples of field packages, contact Micro Focus Software Support.

To integrate another product to Universal CMDB, depending on how the other product exposes its data, the integration adapter acts differently:

Integration Type	Reference Example to Be Reused
Access the product's database directly	Microsoft SCCM
Read in a csv or xml file produced by an export	Troux
Access a product's API	BMC Atrium/Remedy