Exercise 1.7 - Create Events - and the tale of Flags and Events

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 Hopp 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 Hopp to report everything that occurred. When you get to the Portal application in later exercises, you will see that - basically - the Portal 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 Hopp 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 Portal, 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
• Disposition defines the consequence if this Event is fired:
  • Full discard: The entire Business Object will be discarded and no Target data produced
  • Partial discard: Only relevant on a child Business Object. Will discard the current Child Business Object and descendants but let the rest of the Business Object through
  • Retain: No consequence
• Impact signifies how important this event is to the migration. Impact can have these values - with these suggested meanings
  • Critical: This is a critical problem that must be fixed before the migration goes live
  • Advisory: This is a problem that may be resolved in the Target System after go-live
  • Information: This is a purely informational event and does not signify any problem
• 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 Disposition, Impact and/or Receiver in that specific context 
• It has a Text that will ultimately be shown in the Portal
  • 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 add some text to help with the resolution of the event, should it occur in the migration
  • User Guidance will show up in the Portal and you can use it to assist your testers
  • Internal Description is only visible in Studio itself. Use it to provide assistance to your team members that you not want your testers to see

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 Disposition as Full Discard (default)
• Leave Impact as Critical (default)
• Leave 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 Disposition as Full Discard (default)
• Leave Impact as Critical (default)
• Leave 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 Disposition, that defines the consequences of an Event, the Impact that says something about how serious this event is for the migration, and finally 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.