History on migrated Business Objects

Modified on Wed, 27 Nov at 2:31 PM

This is a detailed topic in our support portal in the Using Hopp series and assumes that you have some prior knowledge or experience using Hopp. 


Introduced in Hopp version 2.4.


A powerful capability of Hopp is the ability to remember previous versions of migrated Business Objects. This allows users to step back in time and inspect a Business Object as it looked after being migrated in any previous job. This includes Events, Dependencies, Source-, Interface- and Target data for the Business Object.


Any 2 versions can easily be compared to see exactly what has changed between iterations. 


This feature is unique to Hopp and provides unmatched insights to the team in change of the migration.


The techie take

In earlier versions, when a given Business Object was migrated, any previous result for the Business Object was completely forgotten and the new result stored instead.


Now, the Runtime still saves the new result as before, but it also records a delta that can be applied to the new result to reconstruct the previous result. It is this functionality that renders it possible for the Portal user to see previous versions of the migration result for the Business Object.


The Portal will simply retrieve the current migration result, and then apply recorded deltas one by one in order to step back in time and present the migration result from any previous point in time. 


At the same time, the Runtime remains efficient as it is still only dealing with the current results when actually running the migration.


Viewing the object history

A new tab has been added to the dialog showing the migration details for a Business Object:


This tab shows the version history for the Business Object, with the current version first on top of the list. The versions are represented by the Runtime Job that created the version:



The compare button is used to compare 2 versions of the Business Object.
  • If just one version is selected in the list, then this version will be compared to the current version

  • If 2 versions are selected in the list (with Ctrl-click) these 2 versions will be compared


Modifying jobs onlyA check here will filter the list to only display versions for jobs that modified the Business Object

The indicator points to the version of the Business Object that is currently being viewed

JobShows the number of the job that created the version

TimeShows the time the job created the version as well as the status of the Business Object for this version

Also contains the context menu for the version
ViewOpens a dialog to view the details of the version
Compare to currentCompares this version to the current version


EventsContains a blue dot if the version modified the Events for the Business Object

DependenciesContains a blue dot if the version modified the Dependencies for the Business Object

SourceContains a blue dot if the version modified the Source data for the Business Object

InterfaceContains a blue dot if the version modified the Interface data for the Business Object

TargetContains a blue dot if the version modified the Target data for the Business Object

BaselineShows the Baselines saved in the Portal, correctly placed in the timeline represented by the versions

Viewing a previous version

Selecting the View option from the context menu will open a new dialog with the details of the same Business Object as it was at that point in time



The dialog header will clearly indicate that a historic version of the Business Object is being viewed



The information in the dialog is similar to the current version, only the dialog is now showing the information for the Business Object as it was for that historic version. This includes the information for the Export and Import jobs as well as for the latest Studio Commits - and of course the Events, Dependencies, Source-, Interface- and Target data.


The only difference when viewing a historic version is that child Dependencies cannot be shown:

This is because, for a given Business Object, the Runtime will only store references to its parents. Any historic child dependencies are part of the history of the children and cannot be represented on the parent in any meaningful way.


Comparing versions

Comparing 2 versions by clicking the Compare button will open the Comparison Dialog:


The Comparison dialog in general shows the older version on the left hand side and the newer version on the right hand side. 


The top part of the dialog shows the job and Studio commit information for the 2 versions. The bottom part of the dialog contains the 3 tabs that will show a side-by-side comparison of the Source-, Interface- and Target data for the 2 versions.


Clearing version history

The version history is from the Manage panel in the Portal operations: 

If the Runtime is clearing the Track for use by a new Track by using the Reset track option, the version history is cleared as well. None of the other options for Runtime touches the history.


Instead, history can be cleared more precisely by using the Object History -> Clear option. This option will show a dialog to select how the history should be cleared:


Up to dateWill clear all history older than the specified date and time

Up to baselineWill clear all history before the selected Portal baseline

Clear allClears all history


Opt out of version history

Given that only deltas are stored - and that these deltas are compressed - the hit in storage size and additional overhead when running the migration is minimal and not expected be of any issue in almost all scenarios. 


Nevertheless, it is possible to completely opt out of storing deltas by setting the Runtime Option Record object history to false:


Note that when the option is changed from false to true, the Runtime will start recording the change history from that point in time. 


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article