The Portal provides invaluable support for analyzing and handling the Events that were fired during the migration.
The Portal remembers results and Events from iteration to iteration and provides delta indicators to signal the overall progress of the migration. The workflow functionality supports the sign-off of all the Events, that were fired. By the go-live point, the status on all events should be either that the Event is not fired anymore (status Done), or that the user assigned as responsible for the Event has given it a status Accepted.
In this and the following exercises you will have a look at the different tabs in the Portal. Especially, you will see how you can drill down to a single Business Object and see:
- All the Events that were fired for this Business Object
- Links to all Business Objects on which this Business Object depends
- Links to all Business Objects dependent on this Business Object
- The Source Data that was extracted from the Staging Tables for this Business Object
- The Export Result for this Business Export
- The Target Result for this Business Object
Generally in the lists there is a delta indicator next to each count. The delta indicator compares the current count to the number stored in the current baseline.
The indicators are:
|The current count is equal to baseline (unchanged)|
|The current count is less than baseline. Green if this is good, for instance if the count of rejected Business Objects has decreased. Red if bad, for instance if the count of Business Objects that were imported successfully has decreased|
|The current count is greater than baseline. Green if this is good, for instance if the count of Business Objects that were imported successfully has increased. Red if bad, for instance if the count of rejected Business Objects has increased|
User Interface depending on User authorization
As mentioned in the last exercise, you can see the All level in the Partition dropdown because you in migFx are authorized as a Migration Team member.
Partition users, from the business(es) being migrated, will not have this global authorization and will only be authorized to see data for their respective Partitions.
In several places, the Portal user interface differs depending on whether you are a Team Member or a Partition User. Below, the User Interface is primarily described as you see it as a Team Member.
Differences for Partition Users are described where relevant and marked like this.
A given Event can be processed at two different levels. Either the processing of the Event takes place in the migration team or it is delegated to users in the respective Partitions.
|Team||The Event is processed by the migration team|
|Delegate||The processing of the Event is delegated to users in the respective Partitions.|
When editing the details of a given Event, you - or a Partition User if the Level is Delegate - can change the State of the Event to one of these possible States:
|None||No State has been set||New Events are created with this State|
|Resolved||Some action has been taken and this Event should not occur in the next iteration|
|Regression||The State was set to Resolved, but the Event occurred anyway in the last iteration||This State is set automatically by the Director on Publish|
|Active||The Event is currently being worked on|
|Accepted||It is accepted that this Event occurs and it will not prevent a final sign-off on the migration|
These are the States that can be set manually on an Event. When the Event is shown in the Events list, this State in combination with the baseline comparison is translated to a List State, see below.
Let's go through the menu items one by one.
Shows the statistics for each root Business Object in the latest migration iteration.
As elsewhere, the Partition Box allows you to see the statistics aggregated for the entire migration or for each partition. The list can be exported to an Excel spreadsheet.
The label of each column should make it clear what the column signifies.
Shows the values that were in effect for the Runtime Parameters during the latest iteration. The Runtime Parameters are the Constants from the Studio that were marked as Runtime.
The Events tab shows an aggregated list of Events. The aggregated counts reflect your selection in the Partition Box. You must select both a Partition (or All) and a Track before the list shows anything.
You will find that this list is extensively used and is the major entry point once you start to analyze specific events. The columns are
|Business Object||The Business Object that fired the Event|
|Event||The Event code from Studio.|
|Count||The number of Events that occurred in the last iteration. The count changes with the selected Partition. Clicking the count drills down in the aggregation for the Event. See following exercises.|
|Items||The number of Items that is affected by the Event. Given that the same Event may be fired more than once for the same Item, the Item count may - but does not have to be - lesser than the Event count.|
|Severity||The Severity of the Event.|
|State||The state of the Event processing. See below for more about this State.|
|Anchor||The person in the migration team keeping track of the processing of the Event. The exact meaning depends on whether the Level is Team or Delegate:|
|Area||This is the Receiver from Studio. Studio Receivers are Source, Migration and Target.|
|Level/Derived||Indicates if the processing of the Event takes in the migration team or is delegated to users in the respective Partitions and if the Event is derived (caused by) another Event|
|Message||This is the Events message text with spaceholders in the Language chosen under the Settings tab. Clicking the Message takes you to the Event detail, where you can comment, change User State and delegate the Event.|
|Comments||if there are any Comments on the Event, an image will appear in this column. Hovering over the image will display the comments.|
The List State
The State shown in the Events list is not the User State set on the Event, but rather the User State in combination with with the baseline comparison. The translation assists in getting a better view of the actual state of the Event in relation to the final sign-off on the migration. In addition, if the Level is Delegate, the list state has special meaning for Team users as the Event may be processed by several Partition Users.
|List State||User States and Comments|
|Done||This list state means that the Event did not occur in the last iteration, regardless of the User State set for the Event.|
The Translation tab shows the Valuesets from Studio that were marked as Translation. The Portal displays the Valuesets depending on what has been selected in the Partition dropdown.
Shows a list of the Valuesets:
Remember, the All Partition level is only available if you have the necessary authorization.
From here, you can
- up and download the entire content of a Valueset (for all partitions)
- lock Valuesets, so users cannot edit
Shows initially a list of the Valuesets together with a matrix over the validation results (if any) for the rows in each Valueset:
migFx comes with a utility function that can export the rows for all Translation Valuesets to a file and afterwards to import a file containing validation results for each row.
For instance, if a Translation Valueset deals with the translation of code values in the Source System to code values in the Target System, the utility can be used to validate that the code values for the Target System do actually exist.
- Export the Valuset rows to file using the migFx Utility
- Hand this file to proprietary functionality to validate the rows against the Target System and write a file containing the validation results
- Import this file using the migFx Utility
By clicking on a Valueset, you can edit the contents of the Valueset:
Shows a searchable list of the all instances for a given Business Object
What happened here?
The purpose of this exercise has been to introduce the panels in the Portal relevant to these training exercises. Along the way the notions of Level, User State and List State were explained. These all provide support for a workflow around the processing and sign-off on the Events in the Portal.
In the following exercises you will drill down on a specific Event to see more and more detail and you will see how Event details can be edited to process a given Event.