Splitting or grouping event subscriptions in add-on / custom codeunits?

Navitrans_fvet
Member Posts: 9
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' )?
0
Answers
-
if I understand your question correctly then it depends upon requirement.
if you create new subscription codeunit then again we don't know the order of execution.
if it is dependent upon the addon codeunit then you need to continue using same codeunit or create a publisher in that codeunit and use in new subscribing codeunit0 -
It sounds like the customizations you are referring to are for specific customers in which case the event subscriptions should be done in separate codeunits (50,000 range).0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions