Code Generation

Code generation is the idea that you can write a program that takes a specification as an input and generates code files as an output.

Motivation

Maybe you have thousands of lines of code to write that are almost identical or follows a specific pattern. It’s boring and possibly prone to human errors.

The auto-generated code is picture perfect. Of course presuming that the specification is correct. If you should find an error, simply correcting it in the tool and running it again will solve the error everywhere.

Introduction and History

As we shall see below, I have used code generation for upgrading a very old Navision version and to upgrade and localize the Euro Conversion tool.

Then I will give some examples from outside the Business Central/Navision world.

Invitation to collaborate

If you have a project where generating AL code or C/AL code could be the solution, I can maybe help. Don’t hesitate to reach out to me. See the Contact page.

Navision Upgrade

I had a customer with an old Navision version. The customer wanted to get historical data into separate historical tables in the new version to be able to consult them after the upgrade or move them into their corresponding tables. The customer had between 10 and 15 companies with about 60 tables to be migrated each.

Solution

The solution was a combination of manually written objects and auto-generated objects.

Manually written objects

  • A code generator Codeunit. As input, it got a list of the tables to be migrated.

  • A set of objects to be run before and after the upgrade. The details are outside the scope of this article.

The output files from the code generation

  • One file with Dataport objects for each table to be imported in the old version.

  • One file with a single Codeunit calling all the Dataports to export all data to text files.

  • One file with XMLports for each table to be imported in the old version.

  • One file with historic tables to be imported in the new version.

  • One file with a single Codeunit calling all XMLports to import the data.

Conclusion

Because the scope kept evolving, it was easy to extend the number of tables to be migrated and simply run the tool again and again until it was ready.

Euro Conversion French Version

When we had to make the first French version of the Euro Conversion tool, I suggested to my manager that we outsource the task to a partner since it was a once in a lifetime job. That was a mistake.

I had studied the Euro Conversion tool and seen that it consisted of two kinds of objects.

  • Specific functionality to calculate the conversion. Functions to ensure correct rounding and consistency.

  • A set of almost identical functions to convert each table with amount and currency fields. There was a specific pattern.

So when I was asked to do the upgrade of the French Euro Conversion tool, I decided to try out my idea that the second part could be auto-generated.

To ensure that my generated code was correct, I would start by generating the code for the current version before making the new version and compare my code with the code made by the partner. To my great surprise, there was a huge gap. I found dead code and errors in the code we had received from the partner. My generated code was perfect so I decided to replace all the previous French code with the auto-generated code.

Euro Conversion Slovenia

In 2006 I was given the responsibility for making the Euro Conversion tool for Slovenia. They were converting to the Euro on January 1st, 2007.

The Euro Conversion tool had, of course, not been maintained and had to be updated completely. The core functionality was, of course, fine, but each conversion of a table had to be reviewed and new one had to be written.

Given my results with the French upgrade, I decided to push the idea a bit further. I created a tool to automatically analyze all the tables and suggest a specification. That is, the specification for the auto-generation.

Again I decided to first generate the current version to ensure that I would get exactly the same result. Of course I didn’t and I could prove that I found all bugs in the standard version.

Microsoft decided to only release the Euro Conversion tool for the two supported versions in Slovenia, so that was what I auto-generated.

OpenAPI Specification

The OpenAPI specification format is maybe a bit less known in the Dynamics community, but really interesting from a code and documentation generation point of view.

If you want to expose an API to the world, you would write the specification in a json or yaml file.

You can find an example here. finnpedersenkazes/taskmanager-api

Take a look in the documentation folder. There you will find the swagger.json and swagger.yaml files, the postman collection file and the corresponding documentation.

From the specification you can auto generate server code, client code and documentation in html or markdown formats.

For more information on generators, take a look at this website: https://openapi-generator.tech/

Unfortunately, there is no generator for AL code.

Ruby on Rails App Generator

Ruby on Rails has built in generators. It is called scaffolding. The above API was built with a single scaffolding command line.

To push the idea further, I have written an App Generator in Ruby, which generates an entire app. It takes the specification of the app as input and returns all the app specific files plus the instructions to make the app.

When is Code Generation the right solution?

Once you have identified that code generation would be the optimal way to write the code, you should talk with your manager and colleagues. Get their approval and buy-in before you start.

My experience is that you might get some resistance. Either because they don’t understand the concept or they don’t agree on the cost/benefit.