Integration Brief

From OpenNMS

This is the beginning of a brief description of the Import Integration Service

Importer: The Service Provider's Discovery and Capsd replacement

The Integration Importer service in OpenNMS replaces 2 core services in OpenNMS: Discovery and Capsd.

Discovery is a ping sweeper that is configured to perform scheduled ping sweeps. When a network entity replies to the ping, the Discovery service publishes an event (uei.opennms.org/internal/discovery/newSuspect). The Capsd services listens for this event an performance 2 phases of "Capability discovery". First, the device is scanned for services to be monitored, then, if the device supports SNMP, detailed characteristics are discovered that aid monitoring and peformance reporting.

When using the Integration Importer, the Discovery and Capsd services are disabled in the OpenNMS configuration /etc/opennms/services-configuration.xml file. I instead of ping sweeps by the Discovery service, OpenNMS is told about nodes and interfaces in an XML export from a provisioning system.

OpenNMS marshals this file in to Java objects. Each Java object is processed by OpenNMS code based on the [Visitor] design pattern. Each marshaled Node object, is visited over its attributes and its interfaces, services, and categories and their respective attributes creating appropriate concrete operations (add, update, or insert). All database operations created for each individual node are processed in a single transaction. This insures the integrity of the data for the entire node (no partial nodes or orphaned interfaces, etc.). If any single operation throws and exception, the entire transaction is aborted and logged as an ERROR to the importer.log file.

In order for the Importer to replace the Discovery and Capsd services, it must work in concert with the other core services in OpenNMS. The requires that all significant changes made to OpenNMS are published just as they would have been by Discovery and Capsd. Each operation created in the visitor pattern returns a list of Events that are added to a collection of events for each node. These events are then published upon the successful completion of the transaction. Again, the transactional nature of the import operations insures the integrity of the system.

Critical in determining if a marshaled object is and add, change, or delete operation, is the "foreign-id" attribute assigned to the node element. This foreign ID is the node ID from the a provisioning system and is stored in the "assetNumber" column the OpenNMS asset table. The asset table has a one-to-one relationship with the OpenNMS node table. The assetNumber is prefixed with the text "imported: " to differentiate between nodes added to the system by the Importer integration verses other OpenNMS integration strategies (i.e. XML-RPC). Nodes with assetNumbers that do no begin with this prefix, do not concern the OpenNMS Importer service.

I hope that this adds some clarity to the Importer service. Please discuss this article in the talk section and I will updated it ASAP.

--David.hustace 06:15, 14 March 2006 (CET)