Support Differential Synchronization

For the Push adapter to support differential synchronization, the DiscoveryMain function must return an object implementing the DataPushResults interface, which contains the mappings between the IDs that the Jython script receives from the XML and the IDs that the Jython script creates on the remote machine. The latter IDs are of the type ExternalId.

The ExternalIdUtil.restoreExternal command, which receives the ID of the CI in the CMDB as a parameter, restores the external ID from the ID of the CI in the CMDB. This command can be used, for example, while performing differential synchronization, and a link is received where one of its ends is not in the bulk (it was already synchronized).

If the DiscoveryMain method in the Jython script on which the Push adapter is based returns an empty ObjectStateHolderVector instance, the adapter will not support differential synchronization. This means that even when a differential synchronization job is run, in actuality, a full synchronization is being performed. Therefore, no data can be updated or removed on the remote system, since all data is added to the RTSM during each synchronization.

Important: If you are implementing differential synchronization on an existing adapter that was created in version 9.00 or 9.01, you must use the push-adapter.zip file from version 9.02 or later to recreate your adapter package. For details, see Build an Adapter Package.

This task enables the Push adapter to perform differential synchronization.

The Jython script returns the DataPushResults object which contains two Java maps - one for object ID mappings (keys and values are ExternalCiId type objects) and one for link IDs (keys and values are ExternalRelationId type objects).

  • Add the following from statements to your Jython script:

    from com.hp.ucmdb.federationspi.data.query.types import ExternalIdFactory

    from com.hp.ucmdb.adapters.push import DataPushResults

    from com.hp.ucmdb.adapters.push import DataPushResultsFactory

    from com.mercury.topaz.cmdb.server.fcmdb.spi.data.query.types import ExternalIdUtil

  • Use the DataPushResultsFactory factory class to obtain the DataPushResults object from the DiscoveryMain function.

    # Create the UpdateResult object

    updateResult = DataPushResultsFactory.createDataPushResults(objectMappings, linkMappings);

  • Use the following commands to create Java maps for the DataPushResults object:

    #Prepare the maps to store the mappings if IDs

    objectMappings = HashMap()

    linkMappings = HashMap()

  • Use the ExternalIdFactory class to create the following ExternalId IDs:

    • ExternalId for objects or links originating in a CMDB (for example, all of the CIs in an add operation are from the CMDB):

      externaCIlId = ExternalIdFactory.createExternalCmdbCiId(ciType, ciIDAsString)

      externalRelationId = ExternalIdFactory.createExternalCmdbRelationId(linkType, end1ExternalCIId, end2ExternalCIId, linkIDAsString)

    • ExternalId for objects or links not originating in a CMDB (usually, every update and remove operation contains such objects):

      myIDField = TypesFactory.createProperty("systemID", "1")

      myExternalId = ExternalIdFactory.createExternalCiId(type, myIDField)

      Note If the Jython script updated existing information and the ID of the object (or link) changes, you must return a mapping between the previous external ID and the new one.

  • Use the restoreCmdbCiIDString or restoreCmdbRelationIDString methods from the ExternalIdFactory class to retrieve the UCMDB ID string from an External ID of an object or link that originated in UCMDB.

  • Use the restoreExternalCiId and restoreExternalRelationId methods from the ExternalIdUtil class to restore the ExternalId object from the mamId attribute value of the XML of the update or remove operations.

    Note ExternalId objects are actually an array of properties. This means that you can use an ExternalId object to store any information you may need that will identify the data on the remote system.