Overriding Handlers

As demonstrated briefly in Using Specific Chronology example, downstream event handler creators can create handlers that replace an upstream handler. This is done primarily with the use of the Instead option in the Chronology field on the Event Handlers form. This option allows multiple overriding handlers to coexist. In other words, this option is considered a non-exclusive override.

There is also a second option for situations where a handler’s creator might want to override all other handlers, regardless of who owns them or when they were added to the sequence. This is done using the Exclusively (instead) option in the second Keep With field. This option is considered an exclusive override.

Non-exclusive overrides

In this example, the Infor application development team creates an application event and adds an event handler, SL1.

The application is released with this event metadata included as part of the standard product.

An Infor business partner installs the software with this event metadata. However, they decide that they want to replace the standard Infor event handler with one of their own. So they create handler BP1 and select Instead in the Chronology field on the Event Handlers form. After saving their handler, the sequence is as follows:

Notice that this effectively bypasses and deactivates the original Infor event handler, SL1. The business partner then releases the add-on product with this new event handler in place.

In the meantime, a second Infor business partner does the same thing. For the sake of the example, the second business partner’s handler is labeled AV1.

Now suppose that a customer purchases and installs the standard Infor product. At this point, the sequence is the same as what both business partners received originally:

When the event is generated, the Infor event handler executes.

Then, the customer purchases and installs the add-on product from the first business partner. At this point, the sequence is the same as the first business partner’s. The App Metadata Sync or App Metadata Transport utility recognizes the override of BP1 and automatically deactivates the Infor handler SL1.

But then, the customer also purchases and installs the second business partner’s add-on product. The App Metadata Sync or App Metadata Transport utility recognizes the new override of AV1 and allows both overrides to coexist. When the application event is generated, both handlers BP1 and AV1 execute. The sequence now looks similar to this:

Note: In this case, there is no reliable way to know the precise order in which event handlers BP1 and AV1 executes, since they coexist at the same level in the sequence and execute independently of one another.

Exclusive overrides

To continue the example, suppose that the Infor application development team now adds another event handler, SL2, for the same application event. When Infor releases the upgrade, the sequence for this application event now looks similar to this:

The first business partner installs the upgrade using the App Metadata Sync or App Metadata Transport utility. Once again, they decide they want to override the new Infor handler with one of their own. So they create a new handler, BP2, and assign it to run Instead of SL2. When they release the new version of their add-on product, the sequence for this event now similar to this:

Note: This sequence is typical non-exclusive override behavior.

The second business partner does the same thing as the first, with one exception: They specify that the new handler, AV2, is to execute Exclusively Instead, regardless of any other handlers that might exist at that point in the sequence. When they release their new version, the sequence for this event looks very similar to that of the first business partner:

However, the outcome is quite different.

Suppose the customer now installs the Infor software upgrade and tries to install the upgrades for both business partners as well. All goes well until the customer tries to install the new version of the second business partner’s add-on product. When the customer tries to synchronize the event metadata from the second business partner, the App Metadata Sync or App Metadata Transport utility generates an error, because the handler AV2 is set to execute exclusively, which puts it in conflict with the first business partner’s handler BP2. The two cannot coexist.

To resolve the conflict, the customer must uninstall one of the business partner handlers and contact them for guidance.

In practice, this must be a very rare occurrence.

Disabling the ability to override

Owners of higher-level handlers can designate that their handlers cannot be overridden. Downstream developers cannot use a Chronology setting of Instead or Exclusive Instead with such a handler.

To designate an event handler as not subject to being overridden, on the Event Handlers form, use the Overrideable check box. When this check box is cleared, no lower-level handlers can override that handler. In this case, the Instead and Exclusive Instead options are disabled for any other handlers (downstream) that use the Keep With field to associate those handlers with this handler.