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 the Hopp Runtime 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 were completely forgotten and the new result stored instead.
The Runtime still saves the new result as before, but it now also saves 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 deltas on by one in order to step back in time and thus be able to 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. All versions are represented by the Runtime Job that created the version:
The compare button is used to compare 2 versions of the Business Object.
| |||||||
Modifying job only | Check to 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 | |||||||
Job | Shows the number of the job that created the version | ||||||
Time | Shows 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
| ||||||
Events | Contains a blue dot if the version changed the Events for the Business Object | ||||||
Dependencies | Contains a blue dot if the version changed the Dependencies for the Business Object Note that the history only tracks the dependencies from this Business Object to others (parent) | ||||||
Source | Contains a blue dot if the version changed the Source data for the Business Object | ||||||
Interface | Contains a blue dot if the version changed the Interface data for the Business Object | ||||||
Target | Contains a blue dot if the version changed the Target data for the Business Object | ||||||
Baseline | Shows 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.
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 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 oldest 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 optrion. This option will show a dialog to select how the history should be cleared:
Up to date | Will clear all history older than the specified date and time |
Up to baseline | Will clear all history before the selected Portal baseline |
Clear all | Clears 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 Keep object history to false:
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article