Exercise 5.1 - Portal State and Publish

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 
• Management

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

Baselines

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.

Partitions

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