Extensions

Hopp approaches data migrations in a generic manner capable of being used with any source system(s) and any target system(s).

However, Hopp software will always be used in a specific project/installation context and must be able to function in this context. To bridge the gap, Hopp comes with several extension points to ease the development of context-specific extensions.

Most obvious are the extensions to load the data from the source system to be migrated and the extensions to offload the resulting target data for delivery to the target system.

From the perspective of the generic framework, the migration starts when source data has been loaded into the generated source tables of the export database. Similarly, the migration ends when the resulting target data has been created and stored using the Portal.

However, from the global perspective of the migration project, this is hardly the entire path. Source data must somehow arrive in the generated tables in the export database and the resulting target data somehow be delivered from Runtime to the target system.

Two important extension interfaces of the framework are the Load Extension Interface and the Offload Extension Interface as illustrated below.

As a principle, tasks of implementing these extensions are part of deploying Hopp in a given context. However, some extensions are mandatory, and some are optional. For all mandatory extensions, the framework does come with default extension implementations, allowing rapid initial deployment as well as opening rich possibilities for deeper, proprietary integration.

Extension points

Below is a list of the most common extension points, as well as their default implementations and examples of proprietary implementations.

Load Source Data	Populates the generated source data tables in the export database. Default implementation Load from different file formats, such as: Delimited Excel worksheet Fixed length Db2 textual unload Etc. Proprietary implementation sample Direct database-to-database insert or bulk load (if direct access to the source system database is possible).
Offload Target Data	The framework holds the created target data for each business object as an XML element. This XML element contains the child Business Object hierarchy – each Business Object in the hierarchy contains all target data for this object. This extension interface receives these XML documents in order to further process the target data in the implementation context. Default implementation Offload to XML files — one XML file for each root Business Object. Each file contains a copy of all the XML elements for the instances of the business object. Proprietary implementation sample If the target data structures represent rows to be inserted in a target database, it is straightforward to implement an offload extension that shreds the target data XML to one file per target table.
Import data structures	This extension interface imports data structures into Studio to use in the Source Map or the Target Map. Default implementation Studio comes with a default extension to import source and target data structures from an Excel spreadsheet. Proprietary implementation sample Functionality to read the data structure directly from the table schema in supported database management systems.
Populate value sets	This extension interface is used to populate value sets with data. Default implementation Read data content from Excel spreadsheets. Proprietary implementation sample Functionality to read value-set content directly from the target system.
Audit	This extension interface – if present – is called by Runtime for each Business Object during migration. The interface allows the extension implementation to hand back audit data for Runtime to store. Another part of the extension interface is called by the Runtime to hand over the collected audit data. Default implementation None. Proprietary implementation sample Commonly, audit data is used to reconcile migration results with an expected result from some other data source.
Reject	This extension interface – if present – is called by the Runtime for each root business object rejected during migration. Default implementation None. Proprietary implementation sample Commonly implemented to perform actions for rejected Business Objects. For instance, if a bank account is rejected, the balance may still need to be placed on a technical account in the receiving bank.

There are other specialized extension interfaces outside the scope and detail of this page.