With the latest release of Microsoft Dynamics NAV (2016), Microsoft have introduced, for us “techies”, one feature that stands out from the rest… Events. Don’t worry if you don’t class yourself in the group of “techies”, I’ll try to keep this post in the realms of normality!
Extra! Extra! Read All About It!
The official description of what an event is, goes something like this… “an event is an action or occurrence recognised by software that may be handled by the software.” That make sense? No? Ok, let’s try again… Within a piece of software there’s some code that is shouting out to the rest of the application. It’s trying it’s best to be heard, but if no one is listening it just carries on with its normal course of action. This is called a “publisher” – think of it as the chap at the local railway station, sat behind his sign, trying to sell his newspapers.
On the other side of this, we have a piece of code that is listening for a published event. This is called a “subscriber” – or the person that buys the paper every day from the seller.
When the subscriber hears what a publisher has to say, it takes over for a little while, does its own thing and then returns back to where the publisher left off.
Events in Dynamics NAV
In my opinion, Microsoft have been very generous in their implementation of events within Microsoft Dynamics NAV. Not because of the number of different events they have created, but in the way they have created them.
There are some standard events that are automatically published by the application such as record inserts, deletes, modifications, and field validation. There are also events published from pages such as opening the page, closing the page and reading the records.
On top of these standard events, Microsoft have allowed userdefinable events that we as developers can create and publish within our own vertical applications and bespoke customer solutions.
But What Does That Mean For Me As A User of Dynamics NAV?
When solutions and bespoke modifications are developed within Dynamics NAV they are generally done in the core application in order to add to or tweak the existing functionality. This impacts the standard object base of the application, meaning that when it comes to upgrading, the tweaks have to be transferred from the old version of the application to the code set of the new version. These software changes are referred to as the “footprint”.
It goes without saying, that the more changes made to the standard application, the bigger the footprint, and therefore the longer (and more costly) an upgrade process will be.
The aim of events is to reduce the footprint of the software changes, which in turn means less upgrade time and allow the possibility of more frequent updates to the latest version of NAV.
How Do They Work?
Let’s do a little example so you can see how this works in practice. One of the main software changes that I come across time and again is a request from the end user to have the date that a record was added to the database, along with the user that has added it. Traditionally, this would be a couple of fields added to the table and then some code placed within the standard code of NAV to populate the fields.
We can’t get away from adding the fields to the table, but using events we can remove the need for adding code to that table, thus minimising our footprint as much as possibe. Upgrade tools easily handle the addition of new fields into a table structure, so this part of the modification is not so much a problem.
Let’s implement this on the customer record. Firstly we need to design the customer table, and then create the two new fields that we want to populate.
The fields are added to the table structure in the standard way.
Here you can see I’ve added them in the customer 50000 range, and also highlighted within the Description field that they are for SCR001.
* Other ways of documenting your code are available!
Now that we have our fields in place, we can create our code to populate them. Instead of putting the code inside the table, we’ll create a new codeunit to be our event handler.
Within the codeunit, we create a new function and assign it to listen for published events on the customer table. Here at Evo-Soft, we have come up with our own naming convensions for our event handling functions, but it doesn’t matter what you call them. The event we subscribe to is the OnBeforeInsert() event – this happens before the record is inserted, so is perfect for what we want to do.
Once the properties have been set, we can then add our required code to populate the fields.
As you can see, NAV has put some standard parameters into our function to allow us to utilise the record that is being inserted, and also to allow us to determine if the RunTrigger was called – I’m not going to cover this in this article.
The codeunit is then saved in the customer object range, and is immediately listening to the customer record, waiting for the OnBeforeInsert() event to trigger. As soon as that event fires, our codeunit will then take over, populate our fields and then return control back to the OnInsert() of the table for normal processing to continue.
Although it’s only a simple example above, it shows how bespoke functionality can be introduced into a Dynamics NAV implementation without huge software development. Upgrading the above solution simply means merging the new fields into the customer table, and importing a .fob set of our custom event handling codeunits – simple, quick and cost effective!
Events are a great addition to the Dynamics NAV application, and when used appropriately can massively reduce the footprint of modifications to the standard object set. Sure, they require a new way of thinking and development, but overall it is definitely worth it in order to make future upgrades easier, quicker and cheaper for the end user.
Are they the future of NAV development? Yes, I think they are!
Written by Neil Halliday.