Skip to main content

Flags and Events Discussion

An important element in Hopp is the notion of Events. We have previously described how Rules have a signature with a name and parameters, and perform processing, potentially raising flags and returning a value.

Let's now focus on these Flags, which are closely linked to Events. An Event is essentially a text or a placeholder enclosed in curly braces, followed by a number, another curly brace, and additional text to describe the Event.

For instance, we can define a non-existent Event and include as many placeholders as needed, each assigned a number. Moreover, we have the option to provide text in multiple languages. For each placeholder, we must assign a parameter to the Event. As always with Parameters, we need to provide a name and a data type.

Suppose we are currently mapping the target fields of a target object, and we want to invoke a rule to assign a value to one of the target fields. In Studio, we select the rule and specify that we want the return value to be assigned to the target field. This action prompts the rule's parameters to appear, expecting us to provide the parameter values within this Studio context.

Additionally, the Flags that the rule may raise will be displayed. Now, we must decide how to respond to each Flag. One possible reaction is to simply ignore it, meaning we take no action and continue. Another reaction could be to connect and trigger a user event. If we choose this option, it will prompt us to provide a value for the event's parameter. Thus, within this context, we must select the value to be merged into the text when the migration executes.

Alternatively, we can choose a system event. This means that Hopp will generate the event text for us, using the rule's name and parameter values. Finally, we must determine the severity.

Several severities are available, and it's important to note that some of them may result in the rejection of the current Business Object being migrated. By using the rule within a specific context and reacting to the Flags, we ensure an effective decoupling between the event occurrence and our desired actions.

So, how does this process work when the migration executes? Well, when the engine reaches the point of assigning a value to the target field, it calls the rule. At this stage, it provides the specified parameter values and assigns the rule's return value to the target field.

Furthermore, if the rule raises a Flag, the engine takes two actions. First, it reacts accordingly. For instance, if the severity indicates rejecting the Business Object, the engine rejects it. Second, it requests the director to store the event and its parameter values.

It's worth noting that Portal Operations is responsible for housekeeping. Therefore, when iterating the same Business Object at a later time, Portal Operations will remove previous events and store the new ones. Once we're satisfied with the iteration, we ask Operations to publish the events to the Portal.

Ultimately, this enables the Portal to present the events to users. In fact, presenting events is the primary function of the Portal, as they provide descriptions of iteration results and serve as a valuable source of information.

Summary​

Flags and Events 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. The Portal just shows the Events fired during the migration.

The mechanism of raising a Flag and reacting with an Event is the way for 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.

  • A Relationship contains two Flags: Found and Not found.

  • Similarly, a Lookup Rule (more on this later) contains two Flags: Found and Not found.

  • In the Source Map, a Source Object will raise a Not found or a Found Flag depending on whether it is found in the Source System or not.