Business Central Under the Hood episode 6: We Have Too Many Events!

Overview

The episode traces extensibility from code customization, through the introduction of events, to the current event volume. Version 25 has about 22,500 events, and over 90% of them were requested by partners through GitHub. Cloud telemetry shows about 3,400 unused events and 53% used in fewer than 100 environments. Some objects, such as the sales posting codeunit, hold over 600 events, which makes bug fixes and refactoring risky.

The second half covers the response. Newer and refactored areas use interfaces and extensible enums, and refactoring has produced about 10 times fewer events. The System Application and the Business Foundation layer (introduced in version 24) are built as modules. Namespaces, an obsolescence scheme with a 12 to 18 month uptake period, preprocessor symbols, a clean schema symbol, and an SQL schema cleanup every fifth release are described. Replaceable components and selective module installation are future ideas.

Key points

• Version 25 has about 22,500 events. Growth has been linear since version 15, and over 90% of events were partner-requested through GitHub.
• Cloud usage telemetry shows about 3,400 unused events, 5,600 used by a single environment, and 53% (about 11,000) used in fewer than 100 environments.
• Events are concentrated in a few objects. The sales posting codeunit has around 600 events, and density can reach one event per five lines of code, which makes bug fixes and refactoring risky.
• Handled events work like code customization, which events were meant to avoid. Extensible enums with interfaces give a clearer and more controlled contract; refactored areas show about 10 times fewer events.
• Removing unused events is discussed as a possibility, not a done decision. Partners would be told in advance.
• Obsolete code is kept for 12 to 18 months so partners get recompile warnings. Preprocessor symbols and automated removal support a zero debt principle.
• A clean schema preprocessor symbol is being introduced. The SQL schema will be cleaned every fifth release, starting with version 26, and fields obsoleted in one release are not deleted in the next.

Features

AL objects mentioned

As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.

• codeunit “Sales Posting” at 11:44
• codeunit “Purchase Posting” at 11:44
• other “Journal Posting” at 6:14
• table “Dimensions” at 28:50
• other “Number Series” at 28:29
• other “Audit Codes” at 28:50

Not found in BC28-30: codeunit “Sales Posting”, codeunit “Purchase Posting”, table “Dimensions”.

Quotes

• 2:30 “code customization was a very successful model because it was very flexible but it had a a big downside”
• 2:50 “whenever we changed the code and we shipped a new version or you wanted to you had to code customize across different localizations then”
• 4:12 “the merge model the the merging code and the old code customization is not really fitted for the cloud right”
• 7:14 “I’d say over 90% is partner requested so we had this yeah so we had this basically Community Driven approach”
• 8:14 “right now in version 25 I think we have 22,500 events mhm um and in the in the first few years the the uh”
• 9:06 “we have about 3,400 events that are not used at all in the class nobody nobody we could remove them nobody would notice”
• 9:46 “53% of events so that’s 11,000 something events I think my math is right uh are used in less than 100 environments”
• 12:44 “when we want to make even something as simple as a bug fix right around where these events are or you want to refactor”
• 14:46 “3 000 plus events that are not used in the cloud”
• 16:07 “uh quite a lot of code where the events are just U glorified code customization right”
• 26:36 “the system app is just a physical packaging all just more convenient right to ship them together and version it potentially we could uh”
• 27:49 “business foundation is meant to be the the foundational layer so the rule there is it”
• 30:01 “when we build these modules we actually we rewrite most of the code um so we we”
• 34:38 “we introduced Nam spaces yeah so we uh even though we still have the folder structure we added name spaces to the objects as”
• 36:40 “when we introduced the system application at same time we introduced an obso scheme MH so uh in the past a new version would”
• 37:00 “we obsolete code um we give Partners I think 12 to 18 months to to uptake so they get warnings so if they recompile”
• 39:32 “we operate on a zero debt principle so if you if you want to change some code today you have to make sure that”
• 40:13 “every fifth release we’re going to clean up the SQL schema”
• 40:28 “if we removed the a field in in this release we don’t want to delete it the next release right so we we need”
• 41:29 “Partners will know several releases ahead of time like hey you know this field that they stopped using it’s actually going away in a”
• 41:59 “smaller apps that are that have one purpose because they’re easier to understand they’re easier to use we document them so that you know”
• 43:55 “if they don’t need a Char module inventory module or Supply Chain management you know pick pick your combination you would only install the”

Disclaimers in the video

• 14:46 coming-later: we could choose to remove those um so we can tell Partners R we are going to remove some events you know it’s coming
• 29:00 coming-later: work there would be so that maybe if let’s assume that’s our next step right so what so you would be the work would be pulling everything that has to do with Dimensions
• 32:39 coming-later: we’re still looking into how we can make that non-breaking and again this is all good
• 42:20 not-in-this-release: we’re not there yet so we could have their own HR module for example
• 43:35 coming-later: maybe there’s a future where we could um not install all these modules uh more lean apps

Presenters (as heard): G, Unknown Speaker 1, Unknown Speaker 2, MH.