Extentions

hopp is a 100% generic solution designed to enable the functionality of hopp in various different proprietary installations. hopp exposes a set of public interfaces, making it possible to implement different extensions specific to a given installation context.

Let's start out with some very central extensions that also explain how hopp lives in relation to the source system and the target systems involved. It's not hopp that will extract data from the source system. Instead, hopp expects the data from the source system to be delivered in a set of files, and then hopp will load these files through a load extension. Now, hopp out of the box comes with quite a few implementations of these extensions to read various file formats, but you can implement your own extension to read yet other file formats.

Likewise, it is not hopp that will be inserting data into your target system. Instead, hopp provides an unload interface that it will call to deliver the result of the migration. Now, hopp comes with a default implementation of this unload interface that will simply unload the business objects into a set of XML files. But you can implement your own extension to do otherwise, and then it's functionality surrounding the target system that is responsible for the final insert into the target system.

As you have seen in earlier sketches, Studio is very dependent on information about the metadata in the source system and the target system. Studio will call an extension to load this metadata out of the box. We deliver an extension that will read the metadata from an Excel file. But you can implement your own extension, for instance, to read the metadata from the target system. Additionally, you can also implement an extension to read data metadata from the source system.

In previous sketches, we saw value sets, including dynamic value sets. In this case, hopp calls out through an interface to retrieve the data for the value set from an extension. We provide an implementation here that will read the data from an Excel spreadsheet. However, you can implement your own extension to fetch the data from another source. It's very common to write extensions that retrieve data from the target system to be used for validation purposes during the migration process.

If you want, you can implement an audit extension, and then hopp will provide the business object to you for every iteration. The extension can then select the data from the business object that it wants to deliver as audit data. hopp is in charge of housekeeping, so if you iterate the same business object again, hopp will purge the old audit data and store the new audit data. At the end of the iteration, the same extension can receive all the audit data from hopp, and you can send the data to other functionality of your own choice. For instance, you can compare the audit data from the migration with other expectations for reconciliation purposes.

Another extension point is the reject processing. In some instances, it's all very well and good that hopp rejects a business object, but something might have to be done in that case. A typical use case is when a bank is migrating, and an account with a significant balance is rejected. What will happen to the money? If you implement a reject extension, hopp will provide you with information on all the rejected business objects, and then you can process it accordingly. For example, you could place the money of the rejected account into an internal account in the receiving bank.

Finally, it's possible to write your own jobs to be executed in the hopp job scheduling framework. You can write jobs to be executed, and you can also write and implement panels that will be shown in the hopp UI, allowing you to parameterize and submit your own jobs.

This video provides similar content to the article above.