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 discarded 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 discarded 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 Portal 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 in terms how many were discarded and how many actually made it through the migration.
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 statistic for each root Business Object in terms of the impact of events that were fired.
Use the Events/Objects radio buttons to switch the counts between how many events were fired or how many Business Objects instances were affected by the events (1 instance may fire multiple events)
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.|
|Impact||The Impact of the Event|
|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.|
|Disposition||The Disposition 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:|
|Team||The Anchor is responsible for the Event processing|
|Delegate||The Anchor ensures that the Event is processed by the users in the respective Partitions|
For Partition users, this column is labelled User and will show
- the Team Anchor if Level is Team
- the responsible Partition User if level is 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|
|The processing of the Event is delegated to users in the respective Partitions|
|Event is derived from (or caused by) another Event|
|Message||This is the Events message text with space holders 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 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|
|None||The Event occurs in the last iteration and the User State has not been set.|
The default Level and Team Anchor for new Events can be set in the Portal Operations.
|Resolved||The User State has manually been set to Resolved. If the events occur on the next iteration, the Portal Operations will automatically change the User State to Regression.|
|If the Level is Delegate and all Partition Users have either Accepted or Resolved the Event, any Team user will see the List State Resolved.|
|Accepted||Occurrences of the Event are acceptable and will not hold back a final sign-off on the migration.|
|In Progress||Resolution of the Event is in progress.|
|Regression||Is automatically set by the Portal on Publish, if the User State was set to Resolved and the Event nevertheless occurred in the last iteration.|
|The Waiting list state only occurs for Team users and only if the Level is Delegate. Waiting means that the team is waiting for the Partition Users to resolve the Event.|
|Done||This list state means that the Event did not occur in the last iteration, regardless of the User State set for the Event.|
|However, if the Level is Delegate, any Team user will see the list state Resolved or Waiting regardless of the actual count for the Event and it is up to the Partition Users to resolve 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 afterward 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 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.