Why do we need Interface Codeunits

And what is an interface Codeunit?

A Codeunit that you can execute with CODEUNIT.RUN to perform a given task is, from my point of view, an interface Codeunit.

An interface Codeunit has a parameter that we put in the

This parameter is always a table object.

We have multiple examples of this already in the application.  Codeunits 12 and 80 are some.  There the parameter is a mixed set of data and settings.  Some of the table fields are business data being pushed into the business logic.  Other fields are settings used to control the business logic.

Table 36, Sales Header, is used as the parameter for Codeunit 80.  Fields like No., Bill-to Customer No., Posting Date and so on are business data.  Fields like Ship, Invoice, Print Posted Documents are settings used to control the business logic but have no meaning as business data.

Every table is then a potential parameter for an interface Codeunit.  Our extension can easily create a table that we use as a parameter table.  Record does not need to be inserted into the table to be passed to the Codeunit.

Let’s look at another scenario.  We know that there is an Interface Codeunit  with the name “My Interface Codeunit” but it is belongs to an Extensions that may and may not be installed in the database.

Here we use the virtual table “CodeUnit Metadata” to look for the Interface Codeunit before execution.

This is all simple and strait forward.  Things that we have been doing for a number of years.

Using TempBlob table as a parameter also gives us flexibility to define more complex interface for the Codeunit.  Tempblob table can store complex data in Json or Xml format and pass that to the Codeunit.

Let’s take an example.  We have an extension that extends the discount calculation for Customers and Items.  We would like to ask this extensions for the discount a given customer will have for a given Item.  Questions like that we can represent in a Json file.

And the question can be coded like this.

The Interface Codeunit could be something like

With a Page that contains a single Text variable (Json) we can turn this into a web service.

That we can use from C# with a code like

This is just scratching the surface of what we can do.  To copy a record to and from Json is easy to do with these functions.

And even if I am showing all this in C/AL there should be no problem in using the new AL in Visual Studio Code to get the same results.

Don’t worry about DotNet version in C/AL

When using DotNet data type in NAV C/AL we normally lookup a sub type to use.  When we do the result can be something like

Then, what will happen when moving this code from NAV 2016 to NAV 2017 and NAV 2018.  The Newtonsoft.Json version is not the same and we will get a compile error!

Just remove the version information from the sub type information.

And NAV will find the matching Newtonsoft.Json library you have installed and use it.

This should work for all our DotNet variables.

Using AdvaniaGIT – Docker Containers

There is a new kid in town.  His name is Docker.

Microsoft is saying:

We are currently investigating how we can use Docker for deploying NAV. For test purposes we have created a Docker Container Image with the NAV Developer Preview, which you can try out.

Docker Containers is a technology where you, instead of virtualizing the entire machine, only virtualize the services and share resources from the host computer. Read more about it here: https://www.docker.com/what-docker

Read more about how to get started with Docker here: https://docs.docker.com/docker-for-windows/install/

So what does this mean?

We can install NAV environments as container both in Azure and on premise.  We can have multiple NAV versions to work with without having to install, so there is no conflict.  We can also get access to container images that are still in preview.

Note what Microsoft says, they are investigating.  The NAV Container Image service is not public yet.  You need authentication to get access.  This project has a place on GitHub.  To get access please contact Microsoft or send me a line and I will point you in the right direction.

The easiest way to get started is to try the NAV Developer Preview template on Azure,  http://aka.ms/navdeveloperpreview.  This will give you a full development environment for NAV Extension2.0 using VS Code.

It should be straight forward to install AdvaniaGIT on top of the NAV Developer Preview and start from there.  We can also start from Azure template called “Windows Server 2016 Datacenter – with Containers”.

The local option is to install Docker on our Windows laptop.  If you would like to use Docker on your laptop you need to change one setting after installation.  You need to switch to Windows containers.  Your laptop will most likely restart during installation and configuration of Docker so make sure to have your work saved.

If you are planning to run a Docker-Only environment you don’t need to install NAV.  Still there are prerequisite components that you must install.  These components can be found on the NAV DVD folder “Prerequisite Components”.  From the “Microsoft SQL Server” folder install sqlncli64.msi and ReportBuilder3.msi.  From the “Microsoft Visual C++ 2013” folder install vcredist_x64.exe.  From the “Microsoft Visual Studio 2010 Tools for Office Redist” install vstor_redist.exe.  From the “Microsoft Report Viewer” folder install both SQLSysClrTypes.msi and ReportViewer.msi.  You should now be ready for the next step.

So, let’s get started

In your C:\AdvaniaGIT\Data folder open DockerSettings.json

That’s all.  Your are now ready to use Docker with AdvaniaGIT.  Make sure to always have the latest version of AdvaniaGIT installed.

You can even use the “devpreview” build of NAV TENERIFE to do vNext development both in C/AL and AL.

Stay tuned, the AdvaniaGIT journey will continue…

Using AdvaniaGIT – How to configure licenses

When NAV environments are built a development license is uploaded to the development database.

Make sure to save your development licenses in your AdvaniaGIT license folder.

There are two ways to configure which license is used.  First with the “licenseFile” property of GITSettings.json in your AdvaniaGIT data folder.

Just specify the file name in the license folder.

The license configured in GITSettings.json will be used as default for all builds.  However, as mentioned earlier, every settings in GITSettings.json can be overwritten by the settings in each branch.

The settings file in each branch is named according to the “setupPath” parameter in GITSettings.json.  If we take a look at the setup.json file for my G/L Source Names solution.

Here I need to use another license file.  The one used when I applied for the object range for my extension.

Licenses are not to be stored in SQL backups used by AdvaniaGIT.  When using AdvaniaGIT to create SQL backups the license is removed before creating the backup and reinstalled afterwards.

The first function that is executed after SQL database restore is a database upgrade with the development environment.  This must be done to make sure that the database fits the service version being used.  For this database upgrade function to be successful, first either make sure that the database does not contain expired license, and make sure that you have a valid license in the master database.

There are a few ways of doing this.  First, there is an option when installing NAV to upload the license.

Secondly, in the development environment you can upload a license, going through Tools and License Information.

But make sure that the database your development environment is connected to does not have the “Save license in database” set like here, going through File, Database and Alter.

The third option is to use the server administrative shell.

Hope this helps.  More to come soon.  Stay tuned…

Using AdvaniaGIT – Bring your solution into SCM

Most of us are not just starting working with NAV.  But again not all of us have been able to apply Source Control Management (SCM) to our daily work.

In the previous posts we have installed and prepared our development environment and we are now ready to start working on our solution in the SCM way.

Our first step is to create a branch for our solution.

Now we should look at the options we have to import our solution into our branch.  We can have our solution in different formats.

All these file formats can be imported into our solution branch with the tools that AdvaniaGIT delivers.  Let’s start with the SQL backup, 2016-DAA_WineApp.bak.  AdvaniaGIT will search for backups using these patterns.

In this example the values are:

The module first searches the local drive (default = C:\AdvaniaGIT\Backup) and then the ftp server if one is defined in GITSettings.json.

When AdvaniaGIT creates a database backup it is named according to the first pattern, in this case 2016-WineSolution.bak and saved in the default backup location.

The rest of the file types require that the solution branch has already been built like shown in the first video.

Here we restore from bacpac.  Bacpac format is for example used by AzureSQL.

The Navdata format was created by the NAV development team.  To be able to import from a Navdata file we require an Navdata export with the application included.

Perhaps the most common way is to have a FOB export.

Text exported objects can be imported directly into out GIT branch.

And finally we can update the solution branch from delta files.

Out next task will be to do some development in our solution and commit the changes we make to our GIT server.  Stay tuned…

Using AdvaniaGIT – Create a localization branch

In our previous post we completed the installation of GIT, SourceTree, NAV and the AdvaniaGIT modules.  We also created a GIT repository in Bitbucket.  We selected to use BitBucket just because I already had a user configured there.  I also have a user configured in Visual Studio Online where I store many of my NAV solutions in a private GIT repository.  Public projects I put on GitHub.  As I stated before we must make sure not to push any of the NAV standard code to public repositories.

Advania has internal GIT servers where we host our solutions.

The choice is yours.  I don’t have any favorite GIT server solution.

In Advania we have created a branch structure.  We create repositories for each NAV version.  The master branch is always the W1 release.  Each commit to the W1 branch contains a CU update.  We always store all objects in every branch.  In solution branches we also store deltas and reverse deltas.

We can access any of the CU’s code from the GIT repository and we can see every code change made from one CU to the next.

We branch out master to each localization.  Each localization has the same rule as the master branch.  Every CU is available and every code change is traceable.

All the GIT servers have a nice web interface.  There we can easily see all commits, all code and all changes.  This is a list of commits for the master branch.

This is a list of code changes in NAV 2017 CU8.

Let’s go ahead and create our first localization branch.  In the following video I use the AdvaniaGIT functions to download and extract information from the latest CU.  I don’t have a function that will download all updates for a given version.

Our next step will be creating a solution branch based of our localization.  Stay tuned…

Installing AdvaniaGIT – Video Help

We need to add DotNet 3.5 to the standard Windows installation to be able to do NAV report design in our development environment.  The following video will show you how.  We also need to make changes to PowerShell execution policy.  The scripts and functions in AdvaniaGIT have not yet been signed.  Therefore we need to allow for execution of unsigned scripts.

From Administrative PowerShell run

This you can also see in this video.

Install SQL Server 2016 Developer Edition.  AdvaniaGIT will work with SQL Express as well.

Install GIT, SourceTree and AdvaniaGIT module.  Make sure to have your NAV development license at hand.

There is an alternate ending to the above video.  If you have already installed NAV on your Windows machine you will need to perform the environment preparation as well.  This is demoed in the update video below.  Under normal circumstances doing Fetch and Pull will be enough to update the AdvaniaGIT module installation.  If you have manually updated or installed NAV make sure to execute the update steps shown here.

Now you machine should be ready for NAV installation.  By cloning my 2016 demo repository and using the custom actions in SourceTree you will be able to download and install NAV easily.  Our method have been to always use the latest CU from Microsoft.  The update and installation functions in AdvaniaGIT will read CU information from Microsoft and update/install the latest version.  Installation requires both the application setup and also it needs to extract the database backup and database object export from the version.  The backup and the object export are saved in your AdvaniaGIT folder.  If you have enabled the connection to a FTP server these files will also be uploaded to that server.

Here is how to install NAV 2016.

And the video from NAV 2017 is almost identical.  Using my 2017 demo repository.

Now your Windows machine should no be ready to start NAV development with Source Control Management.

Soon to come are more videos and demos on how to use SCM for your organization.  Stay tuned…

Introducing AdvaniaGIT – SCM for Dynamics NAV

Almost two years ago we in Advania decided to start using GIT as Source Control Management (SCM).  We brought Kamil up to Iceland and we kicked off.  In Sorens session on NAVTechDays last year we demoed SourceTree as the GIT client for NAV SCM.

Everything we in Advania are doing with SCM is available on GitHub.  It is our hope that we can get as many users and companies to use and contribute to this solution.

Over the next coming days and weeks I will be writing here about this tool.  I will also be using the GitHub Wiki for some of the information.

Installing AdvaniaGIT will create a folder structure on your local drive. You can select any of the local drive installed. We suggest that the AdvaniaGIT\Workspace folder should be excluded from Windows Defender and that also goes for any GIT folder used.

Refer to the README.md file inside every subfolder for more details about each subfolder usage.

Inside the Data subfolder we store the module settings in JSON files.

  • BranchSettings.json is automatically managed by the module and used to link GIT branches to local NAV environments.
  • BuildSettings.json contains incremented values that will be used when building new environments.
  • GITSettings.json contains machine settings for the module.
  • NAVVersions.json contains information about locally installed NAV.
  • RemoteSettings.json contains settings for the Remote Management module. Not used by GIT in any way.
  • TenantSettings.json contains settings for each tenant running on a remote server that is managed using the Remote Management module. Not used by GIT in any way.

In the GIT repository folder we require a setup.json file. When the scripts are executed settings from the GIT branch (setup.json) and settings from the machine (GITSettings.json) are merged to a single settings object. If same settings exist in both files the one in the GIT branch will be used.

Installing the module will add custom actions to SourceTree and a command file (StartPowerShell.cmd) to your Windows directory. SourceTree will execute this command file with parameters telling the module what to do. The command file will execute Scripts\Start-CustomAction.ps1 with the same parameters. All custom actions within the Scripts\CustomActions subfolder can be executed.

For teams we suggest using a FTP server for backups and CRONUS text files.

My next blog post will be on the installation and update of AdvaniaGIT.  Stay tuned…

Working with optional NAV table fields

Now that we have entered the Extension era we must take into account that some extensions may or may not be installed at the time of code execution.

You might even have two Extensions that you would like to share data.

Let’s give an example.

In Iceland we add a new field to the Customer table (18).  That field is named “Registration No.” and is being used for a 10 digit number that is unique for the individual or the company we add as a customer to your system.

My Example Extension can support Icelandic Registration No. if it exists.

Using Codeunit 701, “Data Type Management”, Record Reference and Field Reference we can form the following code.

Let’s walk through this code…

GetRecordRef will populate the record reference (RecRef) for the given table and return TRUE if successful.
FindFieldByName will populate the field reference (FltRef) for the given record reference and field name and return TRUE if successful.

Call this function with a code like this.

We could create a more generic function.

This function can be used in more generic ways, like

See where I am going with this?

So the other way around…

And using this with

More generic versions can be something like this.

To use these functions we first need to copy our record to a variant variable and then back to the record after the function completes.

Or

I have requested Microsoft to add more generic functions to Codeunit 701, “Data Type Management”.  I trust that they will deliver as usual.

That NAV Codeunit is one of my favorite ones delivered by Microsoft.