Example: Using Non-Specific Chronology

Another way for downstream developers to affect the sequence of handlers is with the use of non- specific chronology. Non-specific chronology allows developers to indicate that a particular handler must always execute either first or last.

This is done by selecting either the First or Last option from the Chronology drop-down field, as in this example.

Infor creates an event with no handler

The Infor development team adds code to generate a new application event (AppEvent) before a certain transaction posting is performed.

The transaction data is passed into and received from the application event, so that any downstream subscribers can test and modify the values before the posting is performed if they want. An event failure is trapped and aborts the posting, displaying the error message returned by the event. Infor adds no event handlers for the event at this time.

Then, the product is released. The application event is now published and available to downstream developers who install this product.

An end-customer creates a handler

An end-customer installs the software and decides to create a handler (EC1) to validate that the posting data is within a certain range. If an out-of-range condition is detected, the handler fails the event and aborts the posting.

At this point, the sequence is this:

Because no upstream handlers exist yet and the end-customer is the furthest downstream developer, a specific chronology cannot be specified at this time.

A business partner creates an add-on product

In the meantime, an Infor business partner creates an add-on product that stores custom parameters that can be used to adjust the transaction data before posting. They add their own handler (BP1) to input, adjust, and output the data.

In the Chronology field, they select First to indicate that handler BP1 must run before:

Any existing, downstream handlers with no specified chronology that might already exist for this published event
Note: A specific chronology (Before, After, Instead) takes precedence over a non- specific one (First and Last).
Any future upstream or peer handlers

With this add-on product, at the business partner level, the sequence is now this:

The end-customer installs the business partner’s add-on product

Now the end-customer purchases and installs the add-on from the Infor business partner and uses the App Metadata Sync or App Metadata Transport utility to synchronize the metadata from the business partner with their own.

Because the business partner specified that their handler should always run first, the sequence is now this:

The end-customer rearranges the sequence

After installing the business partner’s add-on product, the end-customer decides that their handler must run before the business partner’s handler. So the end-customer uses the Keep With and Chronology fields to associate handler EC1 with the business partner’s handler (BP1) and to execute Before it.

After saving the event handler EC1, the sequence is this:

This is possible because a specific chronology designation takes precedence over a non-specific chronology.

The end-customer decides to add another handler

After this, the end-customer adds a new handler (EC2) to save the final, adjusted transaction data into a data warehouse. They use the Keep With and Chronology fields to associate the new handler with the business parther’s handler, specifying that the new one execute After the business partner’s (BP1).

After saving the new event handler, the sequence is this:

Another business partner adds a handler

Independently of all this, a second Infor business partner installs the standard Infor software and decides to add another event handler for their add-on product. This event handler (AV1) posts additional information to the journal based on the transaction data that was specified.

Because this handler runs after all transaction data has been processed, the business partner specifies in the Chronology field that event handler AV1 must execute Last.

At this point, the flow looks similar to the first business partner’s add-on flow:

However, the effect of designating this handler to run Last is different.

The end-customer adds the second business partner’s handler

Finally, the end-customer purchases and installs the second business partner’s add-on product. After using the App Metadata Sync or App Metadata Transport utility to synchronize the new metadata with the existing metadata, the flow now proceeds as follows:

Note: Even without the Last designation, in this case, handler AV1 executes last because the handler BP1 is designated to execute First, and the other two handlers are both attached to BP1.