The Portal among other ways presents the migration results as Events and provides collaboration functionality enabling the users to keep track of the state of Events, including (new, fixed, accepted, recurring etc.). It also enables users to comment on Events and provides the ability for a user to appoint responsibilities to other team members.
For the Business Object the Event presents:
- How many Business Objects of this type that has been migrated successfully and how many were rejected during the migration.
- An aggregation of the Event that occurred for this type of Business Object.
Events enable the user to search or drill down to any specific Business Object to view:
- The Events that occurred for this business object
- Links to any related Business Objects (ancestor and/ or descendants)
- The data that were produced for each step in the migration process.
- The data extracted from the source system
- The intermediate result produced by the export engine
- The intermediate result produced by the transformation engine
- The result is produced by the target engine
Looking at the Events panel you have a list of all Events fired in the lifetime of the project. The message for each Event is presented with the space holders for parameters, the actual parameter values have not been merged into the message.
The list contains the following columns:
|Business object||The Business Object on which the Event is created, e.g., Account.|
The Event Code as created in hopp by migration team.
Alternate this could be the Step where the event was created (i.e., as “system event”) and the migration team has not created an Event Code for this.
|Count||Number of times this event has occurred.|
|Items||Number of objects that have been affected by this event. |
An event can be given several times for the same object (i.e., 1 client can have the same event multiple times) hence the number of Items can be smaller than the number in the Count column.
|Severity||The Severity of the Event.|
|Reject Root||The entire object (I.e. a specific account/client) has been rejected|
|Reject Child||A sub-object (i.e. an address of a client) has been rejected|
The business object will be migrated, but something is not right e.g. there is no translation for NamePrefix so a default is used.
The business object will be migrated, but something is not right
e.g. on a client Address a state is listed that is not valid in Sonata, so the state-field will not be migrated – but it is not mandatory, so no need to reject the address.
|State||The current state of the event.|
|New||Default state of an event, until a user changes the state or there are no more objects with this event.|
|Resolved||Some action has been taken and this Event should not occur in the next iteration.|
|Regression||This event has been marked Resolved but there are still objects with this event.|
|Accepted||A user has accepted that this event occurs – no further action is needed.|
|Active||A user has set this state and is actively working on this event.|
There are no more objects with this event.
|User||Shows the user responsible for this event (i.e., the user to which this event has been assigned). If no user has been assigned yet, the field is blank.|
|Area||Indicates if this should be handled Source, Migration, or Target team. |
(Icon column) 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 Event text.||Description of what caused this event.|
By clicking the Business Object name Account you go to the intermediate Event list displaying the actual parameter values.
Even though the number of occurrences can be quite daunting, the intermediate list shows that the problem is in fact limited to a just few missing InterestTypes.
Clicking a line in the Intermediate list takes you to the list of items that fired the Event with this value for the message placeholders. This is also the list you will get from the Items menu item.
|Item Id||The internal Id of the Business Object instance in the migration database. Click to proceed to the detail view|
The migration result for each item is
|Source Key||The key identifying the item in the Source System. This is the given by the Discriminator defined on the Business Object in the Source Map (here the values for BankId, ClientId and AccountNumber)|
|Migration Key||The key in the migration. This is the value of the Target Interface Fields that were marked as Key in the Studio Target Map (here BankId and AccountNumber)|
|The same Key information as is visible in the list|
|Information of the jobs in the Director that ran the Export and Import of this item|
|The commit ids of the Source- and Target Maps tells you on which basis the item was processed. You can locate these commits in Studio to see the exact state of the maps that were used.|
A yellow warning means that the user had one or more items in Studio checked out locally when the engine was generated
|Any parent items on which this item is dependent as defined by relationships in the Target Map|
|Any child items which depend on this item|
|All the Events that were fired when this item was migrated|
|Tabs to show the actual item data that were processed for this item, see below|
|The data that was extracted from the Staging database to serve as the foundation for the migration of the item.|
|The data that was produced by the Source Engine and sent on to the Target Engine through the Business Object interface|
|The result produced by the Target Engine, ready for delivery to the Target System(s)|
Was this article helpful?
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
We appreciate your effort and will try to fix the article