Suppose you have a database containing following changes:
- W1 objects, with event publishers, no event subscription codeunits
- BE objects, possibly containing subscription codeunits dealing with events published by standard NAV objects (if NAV would ship localisations using events). Example : '11800 Sales Post Hook BE' codeunit
- Third party add-on, containing subscription codeunits dealing with events published by standard NAV objects. Example : '55.000.000 Sales Post Hook Add-On 1' codeunit
In the above scenario, the event subscriptions from the BE version and the third party add-on would be part of separate codeunits, thus no guarantee on the order execution of the subscriptions, although they should normally not interfere.
Let's say we're creating our own add-on on top of this database. Logically, we should group our event subscriptions in our own proper codeunits, example : '2.550.000 Sales Post Hook Add-On 2' codeunit
In the very end, this database will be used for customer implementations, containing additional customizations. Now the question: in case customizations are to be made using event subscriptions, is it 'best practice' to integrate these changes in NEW / separate codeunits (example: '50.000 Sales Post Hook Customer') (to keep the footprint to 'standard' / other objects small and ease merges of future add-on versions) or could we integrate these changes in the same objects from our add-on. (to minimize the number of extra codeunits needed to purchase by the customer) ('2.550.000 Sales Post Hook Add-On 2' )?
- W1 objects, with event publishers, no event subscription codeunits
- BE objects, possibly containing subscription codeunits dealing with events published by standard NAV objects (if NAV would ship localisations using events). Example : '11800 Sales Post Hook BE' codeunit
- Third party add-on, containing subscription codeunits dealing with events published by standard NAV objects. Example : '55.000.000 Sales Post Hook Add-On 1' codeunit
In the above scenario, the event subscriptions from the BE version and the third party add-on would be part of separate codeunits, thus no guarantee on the order execution of the subscriptions, although they should normally not interfere.
Let's say we're creating our own add-on on top of this database. Logically, we should group our event subscriptions in our own proper codeunits, example : '2.550.000 Sales Post Hook Add-On 2' codeunit
In the very end, this database will be used for customer implementations, containing additional customizations. Now the question: in case customizations are to be made using event subscriptions, is it 'best practice' to integrate these changes in NEW / separate codeunits (example: '50.000 Sales Post Hook Customer') (to keep the footprint to 'standard' / other objects small and ease merges of future add-on versions) or could we integrate these changes in the same objects from our add-on. (to minimize the number of extra codeunits needed to purchase by the customer) ('2.550.000 Sales Post Hook Add-On 2' )?