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, RTSM CIs for input.

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

From Run-time Service Model 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 HPE Software Support.

To integrate another product to Run-time Service Model, 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	HPE ED
Read in a csv or xml file produced by an export	HPE ServiceCenter
Access a product's API	BMC Atrium/Remedy