Example: Using Specific Chronology

The primary way for a lower-level handler creator to resequence existing handlers from higher-level owners is to use what is known as specific chronology. The handler’s creator can attach the new handler to an existing handler and specify the order in which the two handlers are to execute with respect to each other.

The mechanism used to do this process are the Keep With and Chronology fields on the Event Handlers form. These fields allow you to specify whether your handler must run before, after, or in place of the handler it is associated with, as in this example.

For more information, see the help on the Keep With and Chronology fields.

Infor creates a framework event with three handlers

The Infor framework team creates FrameEvent application event and three event handlers that execute in order when the event is generated.


Handler ID	Display as handler sequence
S1	1
S2	2
S3	3

This application event and handlers are all included with the application software when it ships. Note that, if a lower-level developer wants to add or modify handlers, these rules apply:

Lower-level handler creators cannot change the sequence of higher-level handlers.
Any handlers that the lower-level creators use and affect the sequence in specific ways must be associated with a particular, already-existing handler, using the Keep With and Chronology fields.

A business partner creates an additional handler

An Infor business partner decides to add a handler that executes after the first framework handler. The business partner creates the event handler and uses the Keep With and Chronology fields to keep their handler with ID 1 (S1) and to execute After that handler.

The sequence is now:


Handler ID	Display as handler sequence
S1	1
A1	2
S2	3
S3	4

Note: When the new event handler is saved, the system automatically assigns new numbers, so that you can tell which handler executes in what order.

The business partner uses the App Metadata Sync or App Metadata Transport utility to export the new metadata, along with the existing metadata, to a file that can be imported by the end-customer. Then, the business partner sells the add-on product to the end-customer. The add-on product includes this file, along with any product code the business partner has developed.

The end-customer creates three more handlers

When the end-customer receives the add-on software from the third-party business partner, in addition to whatever other software installation procedures the customer must perform, the customer must also use the App Metadata Sync or App Metadata Transport utility to import the event metadata from the business partner.

The end-customer now decides to use a different handler in place of the second framework handler. The customer also requires two custom handlers to run just before the third framework handler. To accomplish this, the customer:

Creates a handler and uses the Keep With field to assign this handler to ID 2 (S2). In the Chronology field, the customer selects Instead.
Creates a second handler and uses the Keep With field to assign this handler to ID 3 (S3). In the Chronology field, the customer selects Before.
Creates a third handler and uses the Keep With field to also assign this handler to ID 3 (S3). In the Chronology field, again the customer selects Before.

After saving their new handlers with the existing handlers, the sequence is now:


Handler ID	Display as handler sequence
S1	1
A1	2
C1	3
C2	4
C3	5
S3	6

Note:

When the customer saves the new handlers, the system automatically assigns and displays the correct Handler Sequence number on the Event Handlers form. However, the underlying Handler IDs remain unchanged.
Event handler S2 is now inactive and does not execute at all. S2 is in the system, but the system ignores S2 in favor of the new customer handler.
The custom handlers C2 and C3 execute in that order unless you use the Up / Down buttons on the Event Handler Sequence form to alter the default order.