#NAVdevTips 10: AL – no, you can’t. But do I need?

Last two days I spent on very productive workshops where we were trying to find out if some things are possible or not when developing extensions 2.0 and AL code. Before I will give you some examples I want to explain why I am writing about this.

This post has two reasons. First to show you that some things are not possible to do in AL (when writing Extension) or at least they need some workarounds (for now) – means if you would talk with your customers or internally remember about it that you can have some problems in this areas. Second, which is even more important, is to think if we really need such functions doing the extensions in AL.

Some update [26th April] and before you will read the rest of blog

Reading the next topics in this blog think of extension as something not build for one customer but as a solution which is published later on App Source. There is an option to use below functions mentioned in the article writing code in AL but for specific customer.

To do that you need to set in app.json:

And in this place I would like to thank my colleague Martin, who point this and found the solution here https://github.com/Microsoft/AL/issues/1080 .

Managing the Files

There is few things in this area which normally you would do very quick but in AL and extensions you are not allowed to do.

Table File

You cannot use the virtual table File as in below example in C/AL. This table was very useful when you wanted  for example to list the files in the folder.

If you will try to create the record in Visual Studio Code then you will get errors when building the solution.

File variable

It is possible in AL declare the File as variable and you will not get any error when doing so. The problem will start when you would like to use it with any of methods available. You cannot open, read or create In/Out Streams.

File Management Codeunit

Function in it were very useful when doing any operations with files. You could list the files, check if file or dictionary exist or upload/download files from server.

Now most of functions are not available for development of Extensions. In the list below I tried to catch all which are not used anymore.

What you can use is very limited. Below you can find functions which are available from File Management Codeunit. Probably some you could use in your solutions (for example Browse the Directories and import file to BLOB and then process it).

DotNet support

Some of blogs already wrote about this topic and there are some workarounds presented by others. The status for now is that it is not possible to use DotNet variables in AL. Also you cannot use DotNet functions in Web Client in 2018. As I wrote some time in the past there is a light in the tunnel. Now when you try use DotNet then you get error as below which says that we can expect something.

Linking to External Tables

To be honest I do not remember when I used this functionality however there was the option in NAV to open the SQL table or view from the same database or external database directly in NAV. For that the Linked Object property was used.

In AL when you try to use the same properties for the table you will get the error that table already exists in Database.

And if you would like to use TableType – External SQL or CRM then it is apparently not supported at all.

Connecting to objects in range 50000

If someone already created the object in the range 50000 using C/SIDE it is not possible to get to it from AL language when developing the extensions.

So what that we can’t use those things?

For me the first two things are one of most used functionalities in real life. When developing any of interface it is quite important to have flexibility working with files and importing files for example from FTP. But do I really need it in developing extensions?

To answer that questions first let’s think for why are we doing extensions? For me extension is not something which is customer specific functionality. It is business oriented functionality. Which for me means something which we can implement without additional modifications to many customers to meet the business needs.

This means I do not need in extensions connecting to external tables – because I do not know which SQL tables/views customer would have. I also do not need to use objects in range 50000 – as they should be created either after my extension is installed either my extensions should not depends on customer specific functionalities.

You can say “Well, but working with files (importing, exporting) is something which a lot of customers do. This is business oriented for sure”. And I fully agree.

But then we should ask ourselves another question. For which environments Business Central is built? At least for now it is cloud version and available mostly via Web Browser. Therefore such  customers are not those who really need to store and process many files at one time or connect to other systems. If so they would rather go for on-premise versions. And this is were I would agree – for on-premise developing interfaces is a must (or not? but this is thought is for other discussion). we will see what Microsoft will offer us in autumn.