This is the first of a multi part series on Nav 2016 events and workflows. This post will be a quick overview of what are events and why they are a big deal.
First part : What are events and the advantages they provide.
Third Part: Creating event subscribers
Fourth Part : What are workflows and how to make a workflow step
Fifth part: Making a workflow response
Seventh Part: Assigning workflow step predecessors
Eighth Part: Putting it all together
What are events?
Events are a way for an application to say “Hey! this thing just happened, (or is about to happen) does anyone care!”. If any other part of the application does care, it now has the opportunity to execute some code. Events have two parts. The first part is the publisher, the part of the system that will let the rest know that something just happened. The other part is the subscriber, the part of the system that waits for the publisher to say something. A real world example is your mail box. You are a subscriber to your mail box. When ever the post-man puts mail in the box and raises the little red flag on the side you are notified that you now got mail. You can always unsubscribe to your mail box by ignoring the red flag and going about your day. With events you can have multiple subscribers to a publisher. In our mail box example, maybe an other family member will subscribe to the little red flag and go get the mail every time the flag is up. Maybe your partner is only interested in the magazines that come in the mail, and leaves you with all the bills. When the post-man puts up the flag, your partner handles their subscription to the system and goes and get the magazines and ignores the rest. You handle your subscription and retrieve the bills. If there is anything in the mail box that no one cares about it, it will be left there, such as flyers and spam.
So how do we relate this to Nav? Nav has built in a lot of publishers already (the mail-box). Some of these include when a new record is created, modified or deleted, or before/after a page action got pressed. You can subscribe to any of these publishers in your code. So lets say you subscribed a function to an event that happens just after any new customer records are create. From now on that function will run after every single time a new customer record is made. It doesn’t matter what codeunit/table/page made the record, your subscriber will always get notified and be able to do its thing. You can even make your own events if you are unable to use any of the built in ones.
Why use events in Nav?
Events should be used when ever possible for a variety of reasons. The big one is that it will minimize the impact of existing code. Right now, you probably have many modifications to the existing tables, pages, and codeunits within Nav. When ever you try and do an upgrade or merge someone else’s code into your database, you will have a lot of conflicts and issues. This is because your modifications are in the same place as the new ones you are trying to merge in. What events now allow you to do, is write almost all your modifications somewhere else. Yet still work in almost the same way. Some modifications can’t be turned into events, but the large majority can be as they are usually ran after or before existing processes happen. With most of your modifications separated out from the base code, its turns upgrading from a two week process to an afternoon process. Microsoft is now releasing updates every single month, and full new versions of Nav every year. So if you want to stay up-to-date you need to make your upgrade process easy and quick. Another advantage of events, is that they can easily be turned into workflow steps and responses. Workflows, which we will go into later, are a easy way for the user to configure they system without getting a developer involved.