Developing Integration Content

Before creating a new integration, you must understand what the integration's requirements are:

• Should the integration copy data into the RTSM? Should the data be tracked by history? Is the source unreliable?

  If you answer yes to these questions, then Population is needed.

• Should the integration federate data on the fly for views and TQL queries? Is the accuracy of changes to data critical? Is the amount of data too large to copy to the RTSM, but the requested amount of data is usually small?

  If you answer yes to these questions, then Federation is needed.

• Should the integration push data to remote data sources?

  If you answer yes to these questions, then Data Push is needed.

• Is the length of any CI's ID greater than 60 characters?

  If you answer yes to this question, then decrease the ID length for all concerning CIs, so that their IDs do not exceed the maximum length of 60 characters.

Note Federation and Population flows may be configured for the same integration, for maximum flexibility.

For details about the different types of integrations, see Integration Studio.

Five different options are available for creating integration adapters:

1. Jython Adapter:

   • The classic discovery pattern

   • Written in Jython

   • Used for population

   For details, see Developing Jython Adapters.

2. Java Adapter:

   • An adapter that implements one of the adapter interfaces in the Federation SDK Framework.

   • May be used for one or more of Federation, Population, or Data Push (depending on the required implementation).

   • Written from scratch in Java, which allows writing code that will connect to any possible source or target.

   • Suitable for jobs that connect to a single data source or target.

   For details, see Developing Java Adapters.

3. Generic DB Adapter:

   • An abstract adapter based on the Java Adapter that uses the Federation SDK Framework.

   • Allows creation of adapters that connect to external data repositories.

   • Supports both Federation and Population (with a Java plug-in implemented for changes support).

   • Relatively easy to define, as it is based mainly on XML and property configuration files.

   • Main configuration is based on an orm.xml file that maps between OMi classes and database columns.

   • Suitable for jobs that connect to a single data source.

   For details, see Developing Generic Database Adapters.

4. Generic Push Adapter:

   • An abstract adapter based on the Java Adapter (the Federation SDK Framework) and the Jython Adapter.

   • Allows creation of adapters that push data to remote targets.

   • Relatively easy to define, as you need only to define the mapping between OMi classes and XML, and a Jython script that pushes the data to the target.

   • Suitable for jobs that connect to a single data target.

   • Used for Data Push.

   For details, see Developing Push Adapters.

5. Enhanced Generic Push Adapter:

   • All the above features of the Generic Push Adapter

   • A root-element-based adapter

   • Maps a UCMDB tree data structure to a target tree data structure

   For details, see Achieving Data Push using the Generic Adapter.

The following table displays the capabilities of each adapter:

Flow/Adapter	Jython Adapter	Java Adapter	Generic DB Adapter	Generic Push Adapter	Enhanced Generic Push Adapter
Population	Yes	Yes	Yes	No	No
Federation	No	Yes	Yes	No	No
Data Push	No	Yes	No	Yes	Yes