First of all I want to clarify that I have learned from this pattern from the big NAV specialist Waldo. All credit go to him.
So, in this post I want to get myself acquainted with this way of developing. It allows you to save a lot of time in the upgrading process and version changes. The name of this method is “Hooks Pattern”.
This system or methodology enables, when doing the merge (either manual or automatic) to decrease by a lot (over 50%) the invested time in merging the objects from the old version with the newer one keeping the customizations in them.
At the office we have found multiple times with versions of a product based on the international NAV version (W1) and having to create the local version (ES in my case).
You might have found yourself in a similar situation. You’ll then know that the easiest part is upgrading the objects in the add-on range (specific).
The tricky part comes when we have to merge the standard application objects. You know them, the codeunit 12, codeunit 80 and 90, the document tables, etc.
And this is where the Hooks Patterns comes to save the day!
This system promotes the creation of codeunits related to standard objects. This way and minimizing the code in the standard object we can upgrade more easily.
As far as naming goes, there is a way of naming the Hooks codeunits.
This could be:
For example, the Hook codeunit for the codeunit Sales-Post would be named “Sales-Post Hook“.
How to use this “Hook Pattern”?
1. Create the Hook codeunit if it does not already exist.
2. Create inside this codeunit a function for each major event of the function that will be “hooked”. For instance, in the case of the releasing sales documents codeunit (144), a majoreven could be “OnBeforeReleaseSalesDoc” (before releasing the actual sales document).
3. Making sure that the first parameter of the Hook codeunit is a variable of the type “Record” used as reference (the first parameter checkmark activated).
4. Declaring inside the main codeunit a global variable that will be the reference to this new codeunit we just created and call each major event from the new codeunit from within the standard codeunit in the proper places.
5. Write all the code we need in the new codeunit.
At the end we should end up with codeunits with as many function inside as major events we have inside the original codeunits.
This method has a lot of upsides but also some negative aspects. Among the few negative aspects I’d like to mention that the developer requires the “Go to definition” feature, and that is only available in the latest NAV versions to date. If we try to do that in a NAV5.0 we will see we cannot.
Also this creates the need to consume codeunits that were previously not being consumed for this purpose.
Personally I use the idea behind it but I try to keep those new functions inside the same object. That way the standard code touched is still minimal but I don’t give up the perks of the method.
For further information you can go to the official NAV blog in the MSDN.