If you are starting the journey to business central in the cloud, and need to upgrade from NAV 2017 or older, this post will help you. I have been a C/AL developer for close to three decades and here I will document how I moved a one thousand object application from C/AL to AL and was one of the first approved apps on Appsource.
In this post we will discuss table objects, and I will document the what and how. Typical modifications on tables is to add code to the built in triggers. The most common triggers are Field OnValidate, OnInsert, OnModify and OnDelete.
Before I go deeper, a little context. When I started this process, we were part of the TAP program. TAP gave us early insight into what Microsoft was developing for what would become Dynamics Business Central. Because of this early preview, we became aware that our ability to modify code directly as we had done for decades was about to end, yet our code needed to exist in both the C/AL form and continue to transform to be ready for the eventual move to AL. In addition we need to support NAV2015 to 2017 with the same code base, so some of our decisions reflect that requirement. To achieve this, I started the first phase of transformation, which was all in C/AL.
The first set of changes made, was to move all our code from triggers to functions. For tables, we used the template shown on the right, even on new tables of our own.
Each trigger has a single line of code that calls a function. If you need to put code on a field, simply add a fourth function ValidateField and call this function from the field trigger. Within the ValidateField function you can use a case statement to control what gets validated. Here is a snippet of the code...
case parmFieldNo of
FIELDNO("No."): begin
//validation code goes here
end;
end;Now this doesn't get you directly to AL, but you need to move your code in stages (in my opinion) and put it in production, so when the time comes for the final conversion to AL you minimize business logic changes. If your code is the same, when you get bugs reported by your users, you can be confident that it is not the business logic, that the problem must be elsewhere.
The one change I would make to this method is to use a separate codeunit for each table instead of functions inside tables. This will get you one step closer to AL. When you are ready to move your code to AL, replace the call to your functions with a subscription to the event associated with each trigger. If you are on NAV2017, you can start the transformation to events.
Comments