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…

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.

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.

Our next task will be on creating a branch for our localization and our solution.  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…

REST Web Services using Json and requiring authentication

But first…

Registration for NAV TechDays 2017 have been opened.  I will do a workshop on web services and json.  I will be using both C/AL and AL with VS Code in this workshop.

Make sure to register for the conference and if possible go to one or two of the workshops.

Now to the topic.  Yesterday I started to develop an integration solution for bokun.io.  Their API is RESTful and uses Json file formats.  It also requires authentication.

In a project like this I usually start by using the OCR Service Setup from standard NAV.  Create a Setup table and a page.

Looking at the API documentation we can see that we need to use HmacSHA1 with both Access Key and Secret Key to authenticate.  In other project I used HmacSHA256 with the Access Key for the Azure API.

First part of the authentication is the time stamp created in UTC.  I find it easy to use the DateTime DotNet variable to solve this.  There are two different formatting I needed to use.

REST service normally just use GET or POST http methods.  The authentication is usually in the request headers.  This is an example from bokun.is

The GetSignature function is

The Secret Key string and the Signature is converted to a byte array.  The Crypto class is constructed with the Secret Key Byte Array and used to compute hash for the Signature Byte Array. That hash is also a byte array that must be converted to a base64 string.  This will give you the HmacSHA1 signature to use in the request header.

My Azure project is using HmacSHA256 but the code is similar.

Azure displays the Access Keys in base64 format while bokun.is has a normal string.

A little further down the line I choose not to use XML Ports, like I did here, but still convert Json to Xml or Xml to Json.

I use the functions from Codeunit “XML DOM Management” to handle the Xml.  This code should give you the general idea.

 

 

Building Assisted Setup for Dynamics 365 for Financials

I had my Assisted Setup wizard up and running on NAV 2017.  Everything looked fine but when the extension was being validated nothing worked.

So, there is a difference between NAV 2017 and Dynamics 365 for Financials.

Remember the session on Design Patterns in NAV 2017 on NAV TechDays 2016?  Microsoft showed what they where planning in regards to assisted setup and manual setup.  This has been implemented in Dynamics 365 for Financials but has not been released for NAV 2017.

One of the feedback Microsoft got from us MVPs was about the Assisted Setup not using the discovery pattern (you will know what I am talking about after watching the session above).  The Assisted Setup table (1803) in NAV 2017 is the one used to register all assisted setup pages.  The problem was that a record for an extension in this table was not removed during uninstall.

Now we have a new table, Aggregated Assisted Setup (1808) that is a temporary table using the discovery pattern.  We also have a new discovery pattern for the Manual Setup with another new table, Business Setup (1875).  You can download these new tables from here (NewD365SetupTables) or wait for them to be released in one of the upcoming NAV 2017 Cu releases.

Here you can also download the guidelines for the new setup pattern (AssistedSetupGuidelines).  My code looks like this.

The Icon file that I created is 240x240px with foreground (RGB 55 55 55) and background (RGB 250 250 235).

More to come, stay tuned…

My first Dynamics 365 Extension – Approved for publishing

Yes!  I have passed all validation steps and Microsoft will publish my app soon.

These are my marketing validation results.

Marketing Validation_Objects4NAV – GL Source Names, 3.2.2017

Remember to look for this image in AppSource and try out my Extension.

As I promised, all the source code is now available on GitHub.

https://github.com/gunnargestsson/nav2017/tree/GLSourceNames

This concludes my blog series on “My first Dynamics 365 Extension”.  Stay tuned for more information on how to design and publish your extension.  I will have more to share in the coming weeks and months.

 

My first Dynamics 365 Extension – Mistakes I made

There are a few things to look out for – things not that obvious.

Look at the extension settings in my Source Control.

the “appName” must match the name in Azure Publishing.

The “appPublisher” must match the publisher short name.

The “appVersion” must be in this format and identical to the version of you app in Azure Publishing.

Also make sure to only select Canada and US even if your app can support more.  Also make sure to only select English as the language.  There can only be two industries and sub-categories.

There must be a web site for the extension.  The “appHelp” Url needs to land in a place where it is easy for the user to find help.

We would recommend to make the videos more prominent on the top of the side. The help link is intended to provide online customer help.”

Now, when you follow the help link you will see a video that will show the benefits of installing this Extension.

Also make sure to have a proper page for privacy, terms and conditions and the publisher website.

All videos must be Dynamics 365 only, both in speech and image.  Never mention Dynamics NAV nor NAV.  Using the Dynamics 365 shell or the upcoming Dynamics 365 for Financials testing environment to make your screenshots and videos.

The documentation must include a user story for the testing team to follow.  The testing team must be able to follow a guided path to test the Extension with new releases of Dynamics 365.  The user story should also show the gains by installing the extension.

Then there is the Lead Management.

There is a document describing how to do this.  You can download it from here, but this is a static document and will not be updated by Microsoft.  AppSource Publishing Guide for Dynamics CRM Solutions.

I am using Azure Table.  Sample final connection string:

{“connectionString”:”DefaultEndpointsProtocol=https;AccountName=spzademoaccount;AccountKey=Ld4mIh4DVrsFEaSw21HKbqn05bl5hLVKcw0fJ4DIsa6RuvwlSMZJzQZM312IHersOIMof4DEouEmc0jw==”}

After correcting all my issues I have restarted the request approval to push to production process…

 

Updates to my Object Renumbering Tool

Back in the end of 2014 I published a renumbering tool for NAV objects.  Using DotNet I was able to increase the renumbering speed for text object files dramatically.

Since then I have been asked if I could upgrade it to work with IDs and Field Numbers.

Now I have.

What’s more, it is also on GitHub.

The Process functions are the following;

  • Read Object Lines – Creates renumbering lines base on the objects in the selected object file.
  • Suggest IDs – Suggest new object numbers in the range from 50.000 based on the available objects in the current license.
  • Read from Excel – Reads object renumbering lines from Excel Sheet created with the Write to Excel process.
  • Write to Excel – Writes current renumbering lines to a new Excel Sheet to me managed within Excel and reread into the renumbering lines.
  • Renumber Using Lines – Prompts for a file to read and for a new file to save with renumbered objects based on the rules in the renumbering lines.
  • Renumber Using Controls – Prompts for a file to read and for a new file to save with renumbered objects based on the rules in the control IDs setup.

I have done some fixes to the renumbering function and have added support for the EventSubscriber.

Go to GitHub to download Page and Table 50000, try this out and submit improvements.

When I am processing an object file I have it open in my text editor.  When I see something to renumber I update the control ranges and execute the renumbering process, reading and writing to the same object file.  My editor will reload the file and I can see the results immediately.

 

NAV Http Web Request

In my post about Json and Rest web services I showed how to use the standard Codeunit no. 1297 for web service communication.

Today I was asked to do this in NAV 2015.  I must admit, I forgot that this Codeunit was not available in NAV 2015.

So I made one.

This one has identical functionality to the one delivered with NAV 2016.  To catch and handle the errors I use the NAV Web Request Add-in that I created and published here on my blog.

Now I can easily move that Json code down to NAV 2015.

Download here –> COD1297-NAV2015