Events

Modified on Mon, 18 Mar at 3:43 PM

The Portal 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 assign responsibilities for its resolution to specific 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 current Events created during the last job interation. 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.
Event	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.
Impact	The Impact (Critical, Advisory, Information) assigned the the Event whent it was created in Studio.
Count	Number of times this Event has occurred.
Objects	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 Objects can be smaller than the number in the Count column.
Disposition	The Disposition indicate the concequenses of the Event occuring on the business object. The concequence can be either Full discard, Partial discard, Retain. Full Discard: The entire object (I.e. a specific account/client) has been rejected Partial Discard: A sub-object (i.e. an address of a client) has been rejected Retain: The business object will be migrated, but something is not right.
State	The current State of the Event. The State can have the value of: 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. Done: There are no more objects with this Event.
Anchor	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	Description of what caused this Event.

By clicking the Business Object name e.g Account you go to the intermediate Event list displaying the actual parameter values.

Even though the number of occurrences can be quite large, the intermediate list shows that the problem is this excample 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.

The columns in Item list are:

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:

	Failed in Export (Source Engine)
	Exported
	Failed in Import (Target Engine)
	Imported

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).

Detail View

Clicking the Item Id in the Item list proceeds to the detail view. Here all information for one specific Business Object instance is displayed in a consolidated view:

The same Key information as is visible in the list
Information of the jobs in the Runtime that ran the Export and Import of this item
The Studio 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 child items which depend on this item as defined by relationships in the Target Map
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

Use rhese dropdown filters to narrow list if its is too long:

Object Data

Use the tabs to get to a consolidated view of relevant data for this specific item by selecting the Source, Inyerface or Target Tab. .

Here the Portal presents you with all the data that were in use for the entire hierarchy defined in Studio for this Business Object.

This view is data lineage taken to a new level and indeed something that is very usefull for testing and validation.

The screenshots above shows the data hierarchies for an Account Business object.

Navigate to a Card item in the Portal and you will easily recognize the hierarchies you have been working on in the Source- and Target Maps.

Source	The data that was extracted from the Staging database to serve as the foundation for the migration of the item.
Interface	The data that was produced by the Source Engine and sent on to the Target Engine through the Business Object interface
Target	The result produced by the Target Engine, ready for delivery to the Target System(s)