This is the third of a multi part series on Nav 2016 events and workflows. This post will be a introduction to creating your own event publishers.
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
When creating your own publishers there are two types you can make. Business and Integration. There is no function difference to between the two. Only what they imply to the user is different. A business event is very similar to an API. Something that you let third parties use. This means that the definition of the event should almost never change. These events should also follow a before/after pattern if the process suits it. This way there is constancy between your events and the ones that Microsoft provides. You can always change the implementation behind the event whenever you want, but the definition should stay the same as much as possible.
Integration events are custom events that don’t have the same binding contract that business events have. These are more to be used just in your own solutions and not necessarily for outside users to use. Other people can use your events, but by stating its a integration event lets them know that this event can change many times in future versions.
Again, both types are implemented the same way, except for one settings. But the intend behind them is slightly different. If you want to read up a bit more on the differences look at the MSDN.
So now that we know what type of events we can create, lets try making one. Most of your events should either be in a new codeunit, or in an object that they relate to. For this example we are going to make an event that will happen after the Posting Date gets set in the Purch.-Post codeunit. First we need to make the event publisher. This is done by making a new function. Lets call it, OnAfterSetPostingDate. These name clearly describes when this event will happen. Once you make the function, open up the properties.
We set the EventType to Integration because we might change the definition of this event later. If we are sure that this event definition will not change, then we could consider setting the type to business. if you want subscribers outside of this object to subscribe make sure you set Local to No. You can add any parameters you see necessary, For this event lets add the Purchase Header record as a parameter. What we just made is only the event publisher. You can now subscribe to this event from any codeunit. Next we need to raise or fire our event.
Now that we have our event publisher set up. We need to fire the event. To do so, we simply place a function call to the function we just made. For our event, lets call it at the end of the SetPostingDate function:
Its that easy. Now any subscribers to our event will run every time after SetPostingDate is ran.
Next we will turn our attention to workflows. – 03/21/2016