In an earlier exercise concerning Relationships you have already encountered Flags and Events. In this exercise you will create 3 Events that you are going to need in the following exercises.


However, before you launch yourself into that there's a little tale to tell about Flags and Events. These 2 buddies are very central to migFx in several respects:

  • They separate (decouple) the fact that something happened (a Flag is raised) and what to do about it in a specific context (fire an Event if a Flag is raised)
  • They provide a completely uniform and standardized mechanism for migFx to report everything that occurred. When you get to the Tracker web application in later exercises, you will see that - basically - the Tracker just shows the Events that were fired during the migration. 


The mechanism of raising af Flag and reacting with an Event is the way of migFx to report what takes place and is used in many different places. For instance:

  • A Rule can raise a Flag (or indeed many Flags). The Rule can be used multiple times in different contexts. It's when the Rule is used you decide how to act if the Rule raises a specific Flag. 
    • You can choose to simply ignore it 
    • or you can assign an Event that ultimately will show up in the Tracker, if this Flag is raised right there
  • As you have seen, when you create a Relationship, you get 2 Flags for free: Found and Not found
  • Similarly, when you create a Lookup Rule (more on this later) you will also get 2 free Flags: Found and Not found
  • The same is the case when you get to the Source map later on. A SourceObject will raise a Not found or a Found Flag depending on whether it is found in the Source System or not 


An Event consists of these parts:

  • It has a number. When you create a new Event, Studio will assign the next vacant number to the Event. Of course if you and a team mate create and Event simultaneously, you may get the same number - one of you would have to change it
  • Severity defines the consequence if this Event is fired:
    • Reject Root: The entire Business Object will be rejected and no Target data produced
    • Reject Child: Only relevant on a child Business Object. Will reject the current Child Business Object but let the rest of the Business Object through.
    • Error, Warning and Information have no consequence in the migration, but can be used to signal different levels of problems that may be expected in the Target System.
  • Receiver suggests who initially should assigned the responsibility to trace and fix the Event
    • Source: Users of the Source System, typically some need for data cleansing or likewise
    • Migration: The migration team handles the Event
    • Target: Users of the Target System, typically some missing code values or similar in the Target System
  • Note that these are defaults - when the Event is connected to a Flag it is possible to override Severity and/or Receiver in that specific context 
  • It has a Text that will ultimately be shown in the Tracker
    • The Text can have placeholders in the form of {0}, {1}, {2} and so on. The placeholders will be replaced by the value of the Parameters of the Event
    • If the project supports multiple languages, you can supply the text for each language
  • It has Parameters to be substituted for the placeholders described above
  • Finally you can connect some generic Text to the Event if desired. For instance something like: 'The Business Object must be manually corrected in the Target System after migration'.


This video explains Events as well:


Events


Before you start, a little tip: You can open a list of all the existing Events by locating and double-clicking the Events folder node in the Project Explorer treeview. The tasks that follow assume you will create the new Events by clicking the New button in this list. Of course you can just as well create an Event by right-clicking the Events folder node in Project Explorer and select New from the context menu.


Anyways, let's create the Events. In spite of the long tale above it is actually fairly simple to create the Events themselves 


Create Event to handle an unknown CardType on a Card

  • Verify that there is no Event available that covers your need (anyway, that's what you would do in a real life scenario)
  • Click on the New button
  • Leave Severity as Reject Root (default) and Receiver as Migration (default)
  • Text (English): Card Type ({0}) is unknown
  • Add Parameters 
    • CardType, format char 50
  • Save (ctrl-s)



Create Event to handle an unknown CardStatus on a Card

  • Verify that there is no Event available that covers your need (have you got it by now?)
  • Click on the New button
  • Leave Severity as Reject Root (default) and Receiver as Migration (default)
  • Text: Card Status ({0}) is unknown
  • Add Parameters
    • CardStatus, format char 10
  • Save (ctrl-s)




What happened here?


Hopefully you got the principle of Flags and Events: A Flag is raised as a signal, and an Event is the action taken in a given context:

  • Flag: Something happened
  • Event: What to do about it

There was also the Severity, that defines the consequences of an Event and the Receiver to hand the responsibility for the Event to someone.


Finally you created 2 new Events that you are going to need in following exercises.