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:

  1. How many Business Objects of this type that has been migrated successfully and how many were rejected during the migration.
  2. 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:

  1. The Events that occurred for this business object
  2. Links to any related Business Objects (ancestor and/ or descendants)
  3. The data that were produced for each step in the migration process
  4. The data extracted from the source system
  5. The intermediate result produced by the export engine
  6. The intermediate result produced by the transformation engine
  7. 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 objectThe 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.


ImpactThe Impact (Critical, Advisory, Information) assigned the the Event whent it was created in Studio.
CountNumber of times this Event has occurred.
ObjectsNumber 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.
DispositionThe 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.

MessageDescription 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 IdThe 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 KeyThe 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 KeyThe 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.


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



Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article