NAV Events: the strange behaviour that I hate… the

Events in Microsoft Dynamics NAV (and in Dynamics 365 Business Central) are one of the best features of the platform ever. With events, you can now extend your business logic without modifying the original objects and events are the core for the new Extension model that we’ll use for Dynamics 365 Business Central.

However, there’s a little strange behaviour regarding events that personally I don’t like and that sometimes can be the cause of many problems in a business process. I want to show here what I mean with a quick example.

In my NAV environment I’ve created a simple table 50000 called Event Test with the following fields:

EventProblem_01.jpg

In this table, I’ve defined a Business event called MyEvent:

EventProblem_02.jpg

The event has this signature:

EventProblem_03.jpg

It receives in input a Code field and a Date field. The event is triggered in the table OnInsert trigger:

EventProblem_04.jpg

After that, I’ve created a codeunit (id = 50001) for handling this event. Here, I have a function called HandleEvent that is a Subscriber of my previously defined event:

EventProblem_05.jpg

The HandleEvent function code here only shows a message with some details:

EventProblem_06.jpg

Now I run my table and I insert a record. My business event is triggered correctly:

EventProblem_07

Now, the business requirements are changed and someone a day changes the Event signature on my table 50000. Now the MyEvent is defined as follows:

EventProblem_08.jpg

and in the table’s OnInsert the event it’s triggered as follows:

EventProblem_09.jpg

Save and compile the table, then try to compile the previously defined codeunit 50001. Magically, it compiles, no errors are triggered.

Now, execute the table 50000 and try to insert a record: the record is correctly inserted but the business event is not triggered:

EventProblem_10.jpg

This behaviour is quite strange, because 99% of the times no errors are triggeres, while I’ve found that sometimes an error at runtime is triggered that alerts you about the event change.

Obviously, this is a stupid example, but imagine a business process where this event passes values to a function used for modify data in NAV (if the event is triggered, data are modified otherwise no). If the event is changed and then it’s not triggered because in C/AL noone has modifyed the subscriber, my business process could give a wrong result.

Someone could say that there’s a “non written rule” that says that Business Events should never change signature across product releases, but this occours for Business and for Integration events.

Ok, NAV provides the Event Subscription view (from Development Environment, on the Tools menu, choose Debugger, and then choose Event Subscriptions) where you can find all Subscribers attached to a published event and if parameters mismatch occours (remember to ALWAYS check this view!), but this is not enough because in a distributed development environment many times you forgot to check here.

Why, during compilation of objects, a compile error cannot be triggered? If in my example Codeunit 50001 will not compile, I’ll discover immediately the event signature change and I could act accordingly by modifying my event subscriber.

In my personal opinion, there’s a loosely binding for events now and this could be improved (ok AL checks for this, but why no also in C/AL?)

Hey NAV Team, any ideas? 🙂

UPDATE: official response from Microsoft: This is actually checked by the new compiler. We have no plans of fixing it in C/SIDE.

3 Comments

  1. It is not ideal, I agree with you. But you have the ‘Event Subscriptions’ view with the last field ‘Error Information’ stating ‘ErrorParameterMismatch’ if the parameter of the subscriber is incorrect. Better than nothing 🙂

    Like

    1. Yes, you’ve that view but when you’ve a project where many distributed developers work and someone changes a Business event without notifying others, this could be dangerous without a compilation error. The NAV Yeam should start thinking on this…

      Like

  2. It’s by design — they’re unlikely to change logic on the classic development environment.

    Incidentally AL does enforce this. It should only be a warning however, as there are scenarios where you want lose coupling.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.