Example: Performing Upgrades

At some point in the future, Infor will make changes to the existing events and handlers, and these changes will be included in an upgrade. This poses a few problems and questions. The upgrade process must:

  • Update any changed Infor handlers and insert new ones while maintaining custom handlers belonging to business partners and end-customers.

  • Keep custom handlers in the correct sequence with Infor’s handlers (especially for overrides) beyond the point where Infor inserts a new handler.

Continuing the specific chronology example…

After the end-customer has installed the Infor software and the business partner add-on product and added its own custom handlers, Infor introduces a new version in which one of the original base handlers (S2) has been modified and a new one, S4, has been added between S2 and S3. The new base flow in the upgrade is illustrated in this diagram:

Frame Event Performing Upgrades
Note: When this version is released, there are numbers that are displayed in the Handler Sequence field of the Event Handlers form.

This table shows the numbers that are in displayed in the Handler Sequence field:

Handler ID Handler Sequence Number
S1 1
S2 2
S3 4
S4 3
Note: Previously, the third event handler in the flow (S3) now appears as 4 in the Handler Sequence field. When the Infor developer saves the new handler, the system automatically assigns the correct Handler Sequence number, without changing the underlying Handler ID number.

The end-customer now installs the new Infor upgrade and uses the App Metadata Sync or App Metadata Transport utility to import and synchronize the updated metadata for this application event. After the integration is complete, the new end-customer sequence is this:

Frame Event Updated Metadata
Note: 
  • Infor handler S2 has been updated. In this case, the update does not run, because of the end- customer handler C1, which replaces it. But the changes are there (stored as handler metadata) and available if the end-customer should ever decide to delete handler C1.

  • The synchronization process inserts the new Infor handler between end-customer handlers C1 and C2. The end-customer handler C1 is attached to Infor handler S2. The end-customer handlers C2 and C3 are attached to Infor handler S3. The new Infor handler has been inserted between S2 and S3.

Continuing the non-specific chronology example…

At the end of the Using Non-Specific Chronology example, after the end-customer has installed the Infor software and both business partner add-on products, Infor introduces a new version in which a new handler to validate data formats has been added and designated to run First. The new base flow in the upgrade is illustrated in this diagram:

App Event Non-Specific Chronology
Note: This new upgrade causes the application event to be generated and check data formats whenever the appropriate transaction is posted. This is different, because before the Infor base version of this application event did nothing.

Now the end-customer installs the Infor upgrade and uses the App Metadata Sync or App Metadata Transport utility to import and synchronize the new handler metadata with the existing metadata for this application event. Because the business partner handler BP1 is marked to execute First, that handler and all handlers attached to EC1 and EC2 are placed at the beginning. Because the business partner handler AV1 is marked to execute Last, that handler is placed at the end. Because the Infor handler SL1 is not marked to execute in any particular order, it is inserted between EC2 (which is attached to BP1) and AV1.

After the integration is complete, the new handler sequence is as follows:

App Event New Handler Sequence