August 2017 – Gunnar's Blog

August 22, 2017

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.

    $FilePatterns = @(
        "$($SetupParameters.navRelease)-$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.navVersion)/$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.projectName).bak",
        "$($SetupParameters.navRelease)-$($SetupParameters.navSolution).bak"
        "$($SetupParameters.navRelease)/$($SetupParameters.navVersion)/$($SetupParameters.navSolution).bak",
        "$($SetupParameters.navRelease)/$($SetupParameters.navSolution).bak")

In this example the values are:

    $FilePatterns = @(
        "2016-WineSolution.bak",
        "2016/9.0.46045.0/WineSolution.bak",
        "2016/WineSolution.bak",
        "2016-NA.bak"
        "2016/9.0.46045.0/NA.bak",
        "2016/NA.bak")

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…

August 21, 2017

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…

August 18, 2017June 6, 2018

Using AdvaniaGIT – Create your first private GIT repository

We have a predefined folder structure in our GIT repository. Each repository can have multiple branches. The first branch and the parent to all the rest is “master”. In our structure we always store released W1 objects in the master branch.

The GIT sub folder structure is defined in GITSettings.json.

“setupPath”: “setup.json”,
“objectsPath”: “Objects”,
“deltasPath”: “Deltas”,
“reverseDeltasPath”: “ReverseDeltas”,
“extensionPath”: “Extension1”,
“imagesPath”: “Images”,
“screenshotsPath”: “ScreenShots”,
“permissionSetsPath”: “PermissionSets”,
“addinsPath”: “Addins”,
“languagePath”: “Languages”,
“tableDataPath”: “TableDatas”,
“customReportLayoutsPath”: “CustomReportLayouts”,
“webServicesPath”: “WebServices”,
“binaryPath”: “Binaries”,

We store all the NAV objects in the “Objects” folder. All NAV objects is everything needed to build a solution from our GIT branch.

The basic rules are

Each branch needs a unique id, a GUID. You can find a new guid with any of the online guid generators. The branchId parameter is stored in each branch setup file.
Public repositories must not contain exported Microsoft objects. These repositories must have the storeAllObjects parameter set to false. These branches are based on standard objects in the Source folder and the Deltas in the repository.
Keep your common parameters in Data\GITSettings.json and your branch specific parameters in Setup.json

List of available setup parameters can be found on the AdvaniaGIT wiki. The Wiki is a work in progress.

As we go through each of the Custom Actions we will talk about these parameters and how they are used.

Here is a demo video on me creating a private repository for NAV 2017 solutions.

The AdvaniaGIT module links each branch to an installed NAV environment. This link is stored in Data\BranchSettings.json and is automatically maintained when environments are built and removed.

NAV Environment and NAV Databases have name rules. Prefix is NAVDEV then the main release then an automatically increment number. Example could be “NAV2017DEV0000008”. The last increment number is stored in Data\BuildSettings.json and is updated on every environment build.

All installed NAV versions must be defined in Data\NAVVersions.json. Make sure to have the correct web client port to have your web client working correctly. This is an example of my NAV versions.

{
  "Releases": 
	[
		{"mainVersion": "90", "navRelease": "2016", "webClientPort": "8090", "helpServer": "nav90help.advania.is", "helpServerPort": "80"},
		{"mainVersion": "100","navRelease": "2017", "webClientPort": "8080", "helpServer": "nav100help.advania.is", "helpServerPort": "80"}
	]
}

This summer I got the change to work with Microsoft on vNext. Microsoft gave me access to a GIT repository with their base application. The GIT repository contained a ReadMe file and a folder called BaseApp with all the objects. I just added a setup.json file to repository and was able to use SourceTree and the custom actions for all the development. Here is the setup.json file I added.

{
  "branchId": "1901c80b-711a-4564-aec6-ac7684e578cb",
  "navVersion": "10.0.17001.0",
  "navSolution": "W1",
  "projectName": "W1",
  "storeAllObjects": "true",
  "objectProperties": "false",
  "objectsPath": "BaseApp"
}

Our next task will be on creating a branch for our localization and our solution. Stay tuned…

August 17, 2017

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

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

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…

August 16, 2017

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…

August 15, 2017

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.

LOCAL PROCEDURE GetCustomerRegistrationNo@10(Customer@1000 : Record 18) RegistrationNo : Text;
VAR
  DataTypeMgt@1001 : Codeunit 701;
  RecRef@1002 : RecordRef;
  FldRef@1003 : FieldRef;
BEGIN
  IF NOT DataTypeMgt.GetRecordRef(Customer,RecRef) THEN EXIT('');
  IF NOT DataTypeMgt.FindFieldByName(RecRef,FldRef,'Registration No.') THEN EXIT('');
  RegistrationNo := FldRef.VALUE;
END;

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.

Customer.GET('MYCUSTOMER');
RegistrationNo := GetCustomerRegistrationNo(Customer);

We could create a more generic function.

LOCAL PROCEDURE GetFieldValueAsText@103(RecVariant@1000 : Variant;FieldName@1004 : Text) FieldValue : Text;
VAR
  DataTypeMgt@1001 : Codeunit 701;
  RecRef@1002 : RecordRef;
  FldRef@1003 : FieldRef;
BEGIN
  IF NOT DataTypeMgt.GetRecordRef(RecVariant,RecRef) THEN EXIT('');
  IF NOT DataTypeMgt.FindFieldByName(RecRef,FldRef,'Registration No.') THEN EXIT('');
  FieldValue := FldRef.VALUE;
END;

This function can be used in more generic ways, like

Customer.GET('MYCUSTOMER');
RegistrationNo := GetFieldValueAsText(Customer,'Registration No');

Vendor.GET('MYVENDOR');
RegistrationNo := GetFieldValueAsText(Vendor,'Registration No');

See where I am going with this?

So the other way around…

LOCAL PROCEDURE SetCustomerRegistrationNo@21(VAR Customer@1000 : Record 18;RegistrationNo@1004 : Text) : Boolean;
VAR
  DataTypeMgt@1001 : Codeunit 701;
  RecRef@1002 : RecordRef;
  FldRef@1003 : FieldRef;
BEGIN
  IF NOT DataTypeMgt.GetRecordRef(Customer,RecRef) THEN EXIT(FALSE);
  IF NOT DataTypeMgt.FindFieldByName(RecRef,FldRef,'Registration No.') THEN EXIT(FALSE);
  FldRef.VALUE := RegistrationNo;
  RecRef.SETTABLE(Customer);
  EXIT(TRUE);
END;

And using this with

Customer.GET('MYCUSTOMER');
SetCustomerRegistrationNo(Customer,'1234567890');

More generic versions can be something like this.

PROCEDURE PopulateOptionalField@25(VAR RecordVariant@1000 : Variant;FieldName@1001 : Text;FieldValue@1002 : Variant) : Boolean;
VAR
  RecRef@1004 : RecordRef;
  FldRef@1003 : FieldRef;
BEGIN
  IF NOT GetRecordRef(RecordVariant,RecRef) THEN EXIT;
  IF NOT FindFieldByName(RecRef,FldRef,FieldName) THEN EXIT;
  FldRef.VALUE := FieldValue;
  RecRef.SETTABLE(RecordVariant);
  EXIT(TRUE);
END;

PROCEDURE ValidateOptionalField@26(VAR RecordVariant@1000 : Variant;FieldName@1001 : Text;FieldValue@1002 : Variant) : Boolean;
VAR
  RecRef@1004 : RecordRef;
  FldRef@1003 : FieldRef;
BEGIN
  IF NOT GetRecordRef(RecordVariant,RecRef) THEN EXIT;
  IF NOT FindFieldByName(RecRef,FldRef,FieldName) THEN EXIT;
  FldRef.VALIDATE(FieldValue);
  RecRef.SETTABLE(RecordVariant);
  EXIT(TRUE);
END;

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.

RecordVariant := Customer;
PopulateOptionalField(RecordVariant,'Registration No.','1102713369');
Customer := RecordVariant;

RecordVariant := Customer;
ValidateOptionalField(RecordVariant,'Registration No.','1102713369');
Customer := RecordVariant;

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.

August 14, 2017May 15, 2018

My first Dynamics 365 Extension – Offer ‘G/L Source Names’ is live

So, back from summer vacation and time to blog…

Early this month I got this email:

Offer ‘G/L Source Names’ is live

Congratulations! Your offer ‘G/L Source Names’ has been successfully published and is available publicly.

Next Steps

Below are the published link(s) for this offer. Please use these to verify and validate end to end experience.

Microsoft AppSource

If you need to update your offer click here.

Reply all to this email in case you need any help.

Thank you,
Microsoft AppSource team

If you follow these links you should see that the publishing portal for Dynamics 365 AppSource has been changed.

My App was automatically migrated from Azure MarketPlace to Cloud Partner Portal. Got this email from Microsoft:

Greetings,

Azure Marketplace will be migrating your VM offers to the Cloud Partner Portal – the new and improved portal for publishing your single VM offers and getting valuable insights about your Azure Marketplace business, on Monday, 17^th July 2017.

What should you expect during migration?

Migration will be done by Azure marketplace team and there is no action needed from you. Post-migration, you will start managing your single VM offers in the new Cloud Partner Portal.

During the migration, you will be unable to make updates to your offers via the publishing portal. Migration will be completed on the same day.

Will my offer be available on Azure Marketplace during migration?

Yes, migration will not affect your Azure Marketplace listing.

Refer to migration documentation here for FAQs.

You can log in to the Cloud Partner Portal at https://cloudpartner.azure.com. Documentation about the Cloud Partner Portal and publishing single VM offers can be found here.

General questions on the new CPP itself, reach out to cpp-public-preview@microsoft.com and we will follow up with you! If you have specific D365 questions, reach out to d365val@microsoft.com

Regards,
Azure Marketplace Team

And that is not all. I also got this email from Microsoft:

Hello,

The Dynamics 365 for Financials Extension Team wants to inform you of some important information. As of August 1^st, 2017, we will begin accepting version 2.0 extensions for validation. Version 2.0 extensions is a much improved experience and represent our future direction for extensions. We will continue to accept v1 extensions until October 1. Please plan accordingly.

If you have a v1 app that is currently in process of validation, or if you have one that is currently published in App Source, you can begin (at your convenience) to convert your v1 app to v2. Refer to the site here for information on how to convert your app. We will work with you as well for the conversion so please direct any questions to d365val@microsoft.com.

https://aka.ms/BeDeveloperforApps and https://aka.ms/GetStartedWithApps has all the information to date around Extensions v2.0. If there is anything you cannot find there, you can always contact the email with any further questions.

Best Regards

D365 Extension Validation Team

This blog series will be continued where I will be converting this App to Extension v2.0 using VSCode. Stay tuned…