This blog post is primarily directed towards partners who wants to do AL code customization in Microsoft Dynamics 365 2019 release wave 2. Even though the tools can be used for extension development as well, typically people working on extensions already have organized their files.
A question I got recently was, how can I visualize or create a dataset that can show/fetch information on a timeline? For example, I have a time-sheet and want to visualize the hours employees worked at certain projects, per day, week, month, year, and so on.
In this example I will create an order intake report. For the simple reason that for this report you can use the standard demo data in Business Central, and for time-sheets you first need to go threw a setup and then create the demo data.
Like any other code, AL code can be flawed and break during refactoring. To prevent manual testing, each time you make the smallest change in code, it is necessary to write Dynamics 365 Business Central AL automated tests. Dynamics 365 Business Central AL automated tests are pivotal to ensure that your code works correctly after refactoring or addition of new functionality.
Some time ago, after explaining my most used VSCode Extensions for AL Development for (about) the 829th time – I decided to make my life a bit easier. I already came across the concept of creating a VSCode Extension that act like packages that automatically install other extensions. An “Extension Pack”, if you will ;-).
There is a recent change that I had to introduce in the CRS AL Language Extension – you know, that tiny little VSCode Extension that quite a lot of you seem to be using ;-). +89000 downloads/+21500 installs – that’s crazy! It’s one of my biggest projects I ever did for the community :-).
One of the biggest headaches right now, is the missing feature for move data from a C/AL table to an extension table without having to do export and import, RapidStart Packages or other funky operations. The idea behind my method is to avoid too much data copying and instead rely on a Rube Goldberg’sk series of SQL rename operations.