In part 1 of this series, we took a quick look at NAV Events, discussed their potential to allow for customized NAV application behavior without requiring source code customization, and shared some thoughts about why you should care. In this part of the series, we are going to dig into NAV Events in a bit more technical detail.
Recall that NAV Events are just C/AL functions where the function's "signature" includes some new properties. There are event publishers (function where Event property is set to Publisher) and event subscribers (function where Event property is set to Subscriber) with events "raised" in C/AL simply by calling the publisher function.
What else should we know about NAV Events?
There are 3 Event types: Trigger, Business, and Integration.
Trigger events are created and “raised” automatically by table and page objects when particular things happen in an object. Table Trigger Events have considerable similarity to traditional table "triggers" like OnInsert, OnModify... The following screen clip shows Trigger Events associated with NAV's Customer table:
The list of various Trigger Events available to you from one table to the next is the same. If you create a new custom table, it too will automatically expose a set of Trigger Events! Same goes for page objects.
Business Events carry a "promise" from the developer who created them not to change following creation and across product releases. Integration Events carry no such promise. Realistically it’s poor programming practice to define and then frequently change or remove an Event's signature (regardless of type); therefore, most (if not all) user defined events you'll find throughout NAV source code thus far (including those provided by Microsoft) have Type = Integration.
Here's a screen clip showing an event Microsoft recently added to the Sales-Post Codeunit (and that event's type):
Microsoft has and will continue adding user defined events to the application in locations they know have been traditional "hot spots" for customization or areas they anticipate will be. The screen clip above is an example of a traditional "hot spot". In the past, it was not unusual to add custom code (like my clip below) early in the sales posting process.
Today, we can create the same custom experience by subscribing to the Codeunit's OnBeforePostSalesDoc event publisher without modifying Codeunit 80 (and complicating a future upgrade). Here's what the new way would look like:
Avoiding source code modification via NAV Events can require a different approach to modification and challenges us to think differently. You may need to write a little extra code in an effort to avoid customization of the base object source code. Here's an example of a common "old way" mod (transfer the value of a custom Item table field to a custom Sales Line field ) and that same mod accomplished differently without base object customization thanks to a Trigger Event!
Old way:
New Way:
Worth noting: the "old way" was very simple and required a single line of code (ignoring my bad habit of extensive use of verbose code comments...)… but potentially required developer time/review/cost at each upgrade / cumulative update application. The "new way" required me to write a couple additional lines of code and even clone a small amount of code from Sales Line."No." OnValidate (traditional) trigger... but I did not touch Sales Line source code to accomplish the "new way" and as a result, upgraded/updated versions of the base table object can be applied to the environment almost at will going forward with little to no risk to or from my modification.
Q: "We're not on NAV 2016 or 2017. What good is any of this to me?"
A: You're on your way to understanding the preferred way of customizing NAV application functionality going forward. That is the primary benefit for you! Prior to NAV 2016, there was no way to avoid some amount of source code modification when custom functionality was required. That said, there are development patterns that can be followed to minimize a mod's "foot print" on NAV source code and It is frequently possible to apply those patterns and development practices in a way that mimics NAV 2016/2017 events! It is also possible to review and refactor old modifications in a relatively low risk / non-intrusive way preparing past customizations for easier future conversion to an "event enabled" version of NAV!
