The Portal State is the section of the Portal that presents the results of the migration to all stakeholders. For instance:
- The Migration Team
- Users from the business involved in the migration
In addition to the static presentation of the migration results the Portal State also allows users to edit certain aspects
- Status, Responsible User and Comments on Events to support the Event resolution workflow
- Data content for Translation Valuesets
The Portal State presents the results that were stored when the latest migration iteration executed the Export and the Import. In order to improve responsiveness, you will in this exercise submit a Publish job to store aggregated results and statistics in optimization tables in the Migration database.
This job will also synchronize the Project database with new Events to participate in the workflow.
Publish to Portal State
The first thing to do is to submit a job in Portal Operations to publish the results of your latest migration iteration to the Portal State.
The Publish job does not provide new information, it will just sum and aggregate the Business Object instances and Events in the migration result to help the Portal to be as responsive as possible.
- In Portal Operations, select Administration/Manage in the navigation menu
- Check the Portal Operations radio button Publish
- Click the Submit using the Action Context Menu
- Select the Portal tab, move all Business Objects to the Selected box
- Click the Confirm button to submit the Publish job
- Follow the job progress in the Job list
A bit further on you will see that the Portal Operations shows delta indicators to signal whether counts (of Events or Instances) increase, remain level or decrease. These delta indicators compare the current counts to a baseline.
You may have noticed the Baselines button next to the Portal Operations Publish radio button in Administration/Manage. You can click this button to manage baselines, including creating a new baseline, setting a baseline as the current baseline and deleting a baseline.
Hopp is able to migrate multiple separate businesses in the same project. In fact, the Workshop project you are working on is migrating two separate banks from one multi-tenant system to another. In Hopp, we say the migration is separated into Partitions.
Hopp has user authorization in place here. For instance, in the Portal, you can view the results for all partitions only because you are authorized as a migration team member.
Hopp can also selectively authorize users to see results for only one Partition and not any other Partitions. So in the case of the Workshop project, users in one bank can only see the results for this bank, not results for other banks included in the migration.
When you were in the Target Map right at the beginning of these exercises you created the Interface Fields for the Card root Business Object, one of Interface Fields (BankId) acts as a partition field. It is the actual value of this Interface Field for each Business Object that determines which Partition the Business Object belongs to.
The Portal State
By clicking the State menu item in the Navigation Menu, you will collapse the Operations submenu and expand the State submenu:
- Statistic: Displays statistics for the migrated Business Objects
- Parameters: Shows a list of the actual values of the parameters in place for this migration iteration (The values of the Constants from the Source and Target Maps that were marked as Run Parameters)
- Test: Part of the Scope & Test module and not active for the Workshop project
- Events: An aggregated list of the Events that occurred during the migration
- Translation: Edit and manage the Translation Valuesets
- Objects: List and search in specific instances of Business Objects
- Items: Part of the Issue management module - lists issues in the migration project
Partitions and Tracks
Once a menu item is selected, you will in many cases need to select a Partition and potentially a Track:
|Partitions||The Partition box contains the actual partition values that exist in the migration project. You can only see the All level because you are authorized to do so|
|Tracks||The Runtime executes the migration in what is called a Track and a project can have as many active Tracks as you want. This enables you to separate different aspects of the migration.|
For instance, in a banking migration, it is quite normal to separate the migration of historic transactions (huge volume, little complexity) in a separate track and keep the golden track for the complicated stuff unpolluted in another track.
In your training setup, the Workshop project only has 1 track: Training