20 Jun First benefits of upgrades with events
From Dynamics NAV 2016, Microsoft provided a new possibility of carrying out the development of our applications. This is what we call events. The main idea is not to change the standard objects of NAV, only separating our code in personalised items for the customer. Furthermore, this type of development is what enabled the development of extensions from NAV 2017.
The first thing to be clear about is what types of events exist. I’m not going to enter into detail in this regard, since the internet is full of articles about this issue, but basically the idea is that there are two types of events: integration and subscription. The first are created by Microsoft in certain key points of the standard NAV code (or by partners in the Addons), and these are the ones we refer to when adding desired personalisations, through subscription events.
It seems good in theory, but is it like that? Is it worth changing the programming logic to this characteristic or, on the contrary, is it a big headache which brings more problems than benefits to your development team? In this blog, i’m going to talk about my impressions and the benefits we have found during the first two years focusing our developments towards this path.
So, initially we didn’t see much future in it, since it was practically impossible to carry out any development using just events without modifying the standard code at all. We always ran into a function without a desired integration event (above all in the purchase/sales records or journal codeunits). It was good for managing Addons with little relation to the standard code. In these cases, it gave us the possibility of adding the desired integration events, to later on link them to any change of the customer, using subscription events for these personalisations. This way, we had an totally clean Addon and without differences in the different customers, and it facilitated the management and updating of patches (it would become as if our Addon was the standard code of NAV that we don’t want to change).
But all of the negative points up until then changed radically from the release of Dynamics NAV 2018. In this new version there is a big increase in integration events available in standard code. For example, in the code unit of the general journal record, the events went from 4 to 13, or in the sales register, from 4 to more than 30. It is certain that there are various points that are missed, but the possibilities are much wider and the range keeps growing, in just the first 5 Cumulative Updates of this version, Microsoft has published a minimum of 17 new events in standard code (and we hope this number won’t stop growing).
First impressions
Thanks to these new possibilities, at Grup de Serveis Triangle we have undertaken to carry out NAV 2018 developments and the migrations of this version, trying to make the most of the available events, and within 6 months of being implemented, we have arrived at various conclusions:
- With development based on events, the update of standard patches, Cumulative Updates or changes of version are more efficient since not changing so many standard objects means that most can be imported directly without having to do merges, and in those that do need it, the differences are minimal. This translated into less development time and a lower cost of this type of projects for the customer.
- Better understanding of the code and the restructuring of certain codeunits. While it is true that, in the first developments, it can be difficult for the developers to find the suitable event to link our subscriber to (whether it’s because the event is in a table rather than the codeunit, or because the standard code has been restructured), when you stop to study carefully which functionality you are looking to obtain in the development, you find that there is a specific one for what you are doing (some clear examples could be the OnAfterCheckSalesDoc and OnAfterTestSalesLine to test the headings and the lines respectively, in the process of the sales record). This provides an initial understanding of the idea of the code restructuring which has been produced in the main codeunits. It also provides an improved efficiency and reduction in errors, because you are sure that what you want to develop you are really doing at the correct point, for example, if you are carrying out a test of the sales record, it is good to use the events created for it (as I have previously mentioned), not to do it at any point in the registration process, although at a functional level, not at an error level.
- On the other hand, the only negative aspect that I could mention would be, for certain programmers not involved in the initial development, the difficulty of finding the created subscriber event. But, to minimise this problem, there are the parameters and development guides of each Partner, specifying and documenting how and where the new subscriber events are going to be created related to each functionality.
So, since the improvements bring benefits to the development team as well as the customer, at Grup de Serveis Triangle, we believe it is positive to carry out this type of developments and, if Microsoft continues to provide new integration events in their code, in the future all of the C/AL programming will be restructured towards this objective.