Dealing with Obsolete Handlers
If you are an Infor or business partner developer, you must not delete handler metadata that has been exported and made available to other downstream metadata developers. This is because those developers might have their own metadata associated with your metadata, by means of the Keep With feature, before your next release.
If your exported metadata removes a handler that is referenced by their handler'sKeep With field, a broken link occurs during import. This forces the App Metadata Sync or App Metadata Transport utility to relegate the downstream developer’s handler to free floating status. This status means its sequence is less controllable. This is especially true if you or an upstream developer, whose handlers are referenced by your handlers' Keep With field, later resequence your handlers.
Therefore, when a handler is no longer needed, on the Event Handlers form, you must mark the handler as obsolete, by selecting the check box. This effectively and permanently deactivates the handler but leaves it in the sequence, so that associations with it do not get destroyed.
For example, consider this sequence of handlers:
After initially releasing this version of the metadata, Infor decides not to use the handler S1 anymore. Because a business partner has associated handler A1 with this handler, if Infor simply deletes handler S1, a broken link occurs the next time the business partner or a customer who uses the business partner’s add-on product tries to install the upgraded metadata. Handler A1 is relegated to a free floating status (as in this diagram), and unexpected consequences can result after subsequent resequencing or synchronizing operations.
So, rather than delete handlerS1, Infor marks it as Obsolete before the next release. Then, when the update is installed, the reference to handler S1 is not broken, though the system ignores it when handling this application event, as in this diagram:
