Leveraging Dynamics NAV Events: Why you should consider it and what you need to know

As stated above, Events are a way for developers to run customized behavior in response to specific actions. Based on the .NET framework, events consist of three different elements:

• Event: The declaration of the occurrence or change in the application
• Publisher: The object that contains the function that declares the event
• Subscriber: A function that listens for and handles a published event.

For more information on these three elements, check out Microsoft’s “Introducing Dynamics NAV Events” page.

Event subscribers determine what actions to take in response to an event that has been raised. An event subscriber is a function that subscribes to, or listens for, a specific event that is declared by an event publisher function. The event subscriber includes code that defines the business logic to handle the event. When the published event is raised, the event subscriber is called and its code is run.

There are different types of events.

• Business Events: A typical business event reflects changes in “state” with regards to a process. This makes them very well suited for workflow. An example of a business event would be when a sales order has been posted in NAV.
• Database Trigger Events: Trigger events are automatically raised by the system when it performs database operations on a table object, such as deleting, inserting, modifying, and renaming a record, as defined in a table. Trigger events are closely associated with the table triggers for database operations: OnDelete, OnInsert, OnModify, OnRename, and OnValidate (for fields).
• Page Trigger Events: Page Trigger events are raised automatically by the system when it performs certain operations in a page object. Page trigger events are closely associated

There are several reasons why you should consider using Dynamics NAV events. Firstly, they decouple your code from Microsoft’s code. More specifically, your code is connected to Microsoft’s through an event but the two are not dependent on each other because they sit in completely different containers. This makes upgrades both faster and easier (and therefore cheaper), as you don’t have to worry about breaking anything.

The use of events also makes maintaining your code much easier. Consider a scenario where you have two modifications that run an action after a sales posting. In the past, making modifications to one meant adding code to the other function and doing a bunch of testing to ensure you hadn’t broken anything. With the introduction of events, you don’t have to worry about this. Because the two modifications are self-contained, you only need to work on one code. This greatly reduces the risk of rollouts.

Another benefit can be found in the fact that by separating your code from Microsoft’s, events make it far easier to view your own code. You can avoid mix-ups, easily viewing all the code that pertains to your operation. And the easier your code is to read, the easier it is to find bugs.

In sum, events are a key tool for organizations looking to reduce risk and cost. By enabling easier upgrades, easier maintenance and the improved ability to find bugs, issues will occur far less often. And when they do, it will be easier to identify and resolve them.

While the use of events in NAV has several benefits, there are two important factors to take into account before diving in headfirst. Firstly, when dependencies exist between two subscribers, it’s not possible to control the order in which the events are triggered. For example, if you have an AfterSalesPost function with Subscriber 1 and Subscriber 2, you cannot be sure of which one will fire first. Usually, the codeunits first in numerical order, but this isn’t guaranteed. So, if it’s important that the events fire in a specific order, you may need to handle this differently.

Secondly, you need to be careful when using global variables. In older versions you could use the global variables without worry. In NAV 2016 it’s important to understand whether or not the variable has been touched by someone else. If it has, you cannot guarantee the state of it and will need to re-query the information, leading to a potential performance hit.