Events and Flags

An important element in hopp is the notion of Events. In another article, we introduced Rules and how they 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.

This video below walk through Events.