Category Archives: NAV Architecture, Patterns & Code

Design Patterns are common solutions best practices to solve problems. This is a well known concept in computer programming and can therefore be applied to Microsoft Dynamics NAV as well.

NAV2016 CU1 | The AltSearchField field property does not work as documented

Whenever I teach a class I always talk about boat anchors and my favorite one is the AltSearchField property.

Luc van Vugt describes it on his blog:

http://dynamicsuser.net/blogs/vanvugt/archive/2014/11/13/let-s-clean-up-nav-3-altsearchfield.aspx

It is one of these features that we inherrited in the Windows version from the Dos version, but it never worked in RTC or other modern clients. This is why I was surprised to see this in the list of fixes for CU1 of NAV2016:

376291 The AltSearchField field property does not work as documented.

After investigation it looks like Microsoft removed the property from the options in the Development Environment.

AltSearchField1

So this is a boat anchor that is now fixed. However…

If you export the G/L Account table to txt it is still there.

AltSearchField2

So it is actually a hidden property.

Thank you Microsoft for starting cleaning up NAV!

I have to start looking for a new favorite boat anchor.

Using Argument Tables | Introducing Overloading in Dynamics NAV

Last year I did some videos about organizing code in Microsoft Dynamics NAV which I put on my YouTube channel. I wanted to do more, but got occupied by writing a book about learning dynamics NAV patterns and organizing a global set of classes around this subject.

Let’s continue where we left off and discuss the possibilities and challenges of implementing the arguments table.

Let’s go into it.

At the end of this blog you will be familiar with the Arguments table pattern, why we need it in Dynamics NAV and what are possible negative side effects.

Problem Definition

Within our C/AL programming language and programming in general we have some challenges.

Using to many arguments in a function

When creating functions we sometimes need a lot of parameters to give the information we require. Sometimes these parameters are optional, only required in some scenarios. This makes calling them quite hard. The code becomes less easy to read, sometimes spread across multiple lines.

Arguments

Hard to change signatures

When refactoring code it is hard to change signatures of functions when they are called in many places of the system. Think about the Functions that create reservations for example. When changing the signature of these function you might end up changing and endless chain of codeunits.

Arguments2

No Function Overloading in C/AL

Our beloved language does not support overloading. What is that? I had to look it up too the first time. Overloading means creating functions with the same name and meaning that take different parameters effectively allowing you to be more flexible in your code.

For example creating a new DateTime in DotNet can be done in 12 different ways with different parameters effectively giving the same result, a DateTime.

Arguments6

Duplicating Option Definitions

Lastly, when calling functions that take an option field as parameter we have to duplicate the option value in order to make the code easy to read. And option values are hard to maintain anyway.

Solution

These challenges can be solved by grouping commonly used arguments in a single table and use that table as the parameter of a function. This is effectively using a table as a class.

Let’s look at some examples of candidates in our product

The legacy code of Dynamics NAV is full of examples, but let’s discuss two that you are bound to hit if you start working with the product, even if you don’t deep dive.

FindSalesPrice

This function in codeunit 7000 is called to calculate a sales price for an Item. It uses 10 parameters.

FormatAddr

This function in codeunit 365 is called to format an address in the system

Changing the signature

Imaging adding a field to this function, or change a datatype. The amount of code affected is pretty big and if you need to parameter only for one specific case you end up changing a lot of code for no purpose.

Compiler

Fortunately the compiler finds all instances where the function call is incomplete, but that does not mean we should use that to change all of them.

Let’s also make sure we understand that the sheer fact that NAV legacy code has these functions it is ok to do so. It does not match the basic principles of clean code.

The Argument Table

So the solution is to create a single table that holds the contract for the function. This would be similar to creating a class in DotNet and using that class as parameter.

When we add new fields to the table, we effectively do not change the signature of the function hence this acts as overloading allowing optional parameters to change the behavior of the code.

Arguments3

Examples in Standard Dynamics NAV

What if I told you that this one of the oldest patterns in Microsoft Dynamics NAV, dating all the way back to good old Navision Software. Would you believe me? I guess not, but it is true.

All codeunits that are used to post Journals are effectively argument functions. We use the Journal Line as an argument table to call into the posting routine. Imagine the effect if posting routines had all these fields as parameters.

Arguments4

When we call one of these codeunits nested inside another transaction we never actually insert the journal line in the database. We merely use the record variable as a placeholder in memory for the data.

Side effects

Although in my personal opinion the arguments is one of the greatest patterns to write clean code, there are some side effects

First off we need to write code to populate the arguments table. This requires us to write extra code we don’t need if we just call a function with let’s say 10 parameters. It does make the code cleaner and makes it intention easier to understand.

Also, the fact that the compiler does not catch adding a field to the table as a signature change can be a downside. Who has not abused this feature as “where used”. We would really need where used in order to perform a risk analysis when adding arguments.

Last but not least, one of the basic principles of events will be broken. The new events in NAV2016 have a built in warning system if a parameter that I inherit no longer exists. This mechanism does not understand if I delete a field of an arguments table. The extensions have the same challenge.

Example

Let’s look at an example. In NAV2015 the development team decided to implement email as an arguments table. This is table 9500 Email Item.

This table has all fields we need to send emails, as well as functions to send the email. The validation logic of the fields can be used to perform checks on the values. How nice and clean is that.

Arguments5

The arguments table is used in Codeunit 260 Document Mailing. Here you can see the coding that is required to use an arguments table.

A new, nice and clean way of writing C/AL code.

Naming Recommendations

When using arguments tables, I recommend adding the keyword “arguments” to the name of the table. This makes it one of the only, if not the only plural table name in Dynamics NAV.

Licensing Considerations

In essence Argument tables can be outside of a customer’s license file since we never insert data in the SQL Server database. However, when you want to use functions as methods of the arguments table it needs to be licensed. Reason for this is simple. The licensing engine is not aware that you want to run code that is tied to a temporary table, you might for example call code in a Production Order when running Business Essentials licensing. To make this work, Microsoft first needs to add a table type “temporary” to the properties

Want to know more?

I will create a video on this too soon. The Arguments Table is also part of my new book.

Learning Dynamics NAV Patterns

NAV2016 | Getting started with Extensions (NAV Apps)

After returning home from NAVUG where I tried to inspire people to develop software in a less intrusive way I found out that some of you might not start working with the new extension model because the DLL does not load.

What are Extensions?

Extensions are packages of Delta files that you can run as an “App” inside NAV. They are compiled on top of your NAV code. In other words, you can customise NAV without doing raw source code modifications.

I’ll post a video on YouTube about this as soon as all the conferences are over

Who is this for?

People have different opinions about this, but my own is that ISVs should start using this first to ship their horizontal solutions as extensions. In future we might also be able to ship vertical solutions or localisations.

Can I customise an extension?

No! This is one major change compared to shipping raw sourcecode modifications. You cannot make changes except personalisation. The Delta files (which are text files) are scrambled so you cannot change them either.

So why would I do this?

To make upgrades easier. With Liberty Grove Software (the partner I work for) we do the integration for some ISVs, and their interface is typically not to be changes. Another example is Anveo which is also designed not to be modified by partners, except for one module which could work as events.

Events? Are you making this more complex now?

Eventing is another new model that we have in NAV2016 which is stolen from .NET. We can now subscribe to triggers in the product. This, in combination with Extensions might be a new model to develop modifications in our product.

So how do I get started?

This was the intention of the blog. The DLL you need to create your own extension as described in my previous blog is (apparently) might not load.

Thanks to Erik Hougaard for trying to figure this out:

Erik Hougaard (@eHougaard) says:

  • For those how cannot find the commands, use this to register the missing DLL from the RTC folder:

    Import-Module .\Microsoft.Dynamics.Nav.Apps.Tools.dll

    Then it should works (It did that on my machine).

More soon

I will post more about this since I think we should all start experimenting with this and give our feedback to Microsoft.

Meanwhile, please start reading MSDN:

https://msdn.microsoft.com/en-us/library/mt574414%28v=nav.90%29.aspx

Download Example

UPDATE: Download the files and script from the new Mibuso

NAV2016 | My first extension (UPDATED) | NAVUG Summit

UPDATE: Download the files and script from the new Mibuso

This blog is written from Reno Nevada where the folks from the NAVUG content committee asked me to talk about how to integrate add-ons with NAV. This session was intented to inspire people to think about alternative approaches to the traditional raw source code modification.

Part of the session was about Web Services and the new Eventing framework. I also wanted to show how the new extensions allow you to enhance NAV without customisations. Hence I had to figure out how this works.

Step 1 – Create the Delta

The first step is to have Delta files that are within the limitations of the extension framework. These are New tables, Pages and Codeunits and adding fields to tables and pages.

Reports, XMLPorts and Query objects are not supported.

Delta

Once we have the delta files we need aditional PowerShell

Step 2 – Manifest

The extension needs an XML file that tells us what the version of our extension is, the name and the publisher.

The easiest way to have that is to create it with PowerShell

Manifest

The XML looks like this

Manifest2

Step 3 – Create NAVX File

NAVx

That is how easy it is to create an extension.

Step 4 – Publish the Extension

Now we need a new clean database to use it in. So in PowerShell we move to a new service tier.

Publish

This makes the extension available in our database, but it is not activated

Step 5 – Install

The last step is to install the extension.

Install

Done!

Now the extension is available in our database.

You can hopefully download this example from the new Mibuso website soon.

Here are the commands for copy/paste

New-NAVAppManifest -Name “NAVUG Summit” -Publisher “Mark Brummel” -Version “1.0.0.0” |

New-NAVAppManifestFile -Path “C:\Users\marq\Documents\DynamicsExt90\Manifest.xml”

Get-NAVAppManifest -Path “C:\Users\marq\Documents\DynamicsExt90\Manifest.xml” |

New-NAVAppPackage -Path “C:\Users\marq\Documents\DynamicsExt90\NAVUG.navx”

-SourcePath “C:\Users\marq\Documents\DynamicsExt90\Delta\”

Publish-NAVApp -ServerInstance Clean2016 -Path “C:\Users\marq\Documents\DynamicsExt90\NAVUG.navx”

Install-NAVApp -ServerInstance Clean2016 -Name “NAVUG Summit” –Version 1.0.0.0

UPDATE

The orriginal post was created with NAV 2016 RTM. Microsoft has now made an upgrade codeunit mandatory. Read here.

ANNOUNCING: New Book | Learning Dynamics NAV Patterns

Since Packt Publishing put it on their website, I might as well reveal a secret project I’ve been working on for the last couple of months, almost a year.

My new book Learning Dynamics NAV Patterns is about to be released. I am in the final stages of processing reviews.

Learning Dynamics NAV Patterns

You can order the book here.

The book is a written version of the Master Class for Application Architecture and Patterns I am currently teaching accross the globe and contains a lot of information about the Dynamics NAV DNA in a structured, easy to follow way. Things that have been in the product, some 30 years, some only one or two releases.

It also contains coding best practices, anti-patterns and refactoring methodologies and finaly a real world example of how to apply patterns while architecting a solution, working with Delta files and using Visual Studio Online to host your IP in the cloud.

The book is a more abstract and technical version of my first book Microsoft Dynamics NAV 2013 Application Design. All the things I learned from being part of the Design Patterns project and Partner Ready Software have been applied to this hands on bundled work. I would like to thank all other members from the teams for their inspiration during the meetings and brainstorm sessions and I hope they enjoy the way the efforts are combined and for everyone to grab although the book is my view and solely my opinion on the matter. The book would have also been worse without the reviewers. One in particular who shall remain anonimous had a big impact on the final version.

I’ve also read countless articles about clean code, object orriented programming and design patterns. I can’t mention them all but I would like to thank everyone for sharing their views and vision with the world.

Please (pre) order the book and enjoy.

Mark Brummel

cropped-navskills1.png

Toronto Master Class Application Architecture & Design Patterns

On March 23 and 24, the first Master Class for Microsoft Dynamics NAV Application Architecture and Design Patterns was held in Toronto.

Thirteen students attended. This what they had to say:

“I think this should be a mandatory class… developers who have the knowledge of design patterns and common coding practices inherently develop stronger, cleaner code.” ~ Michael Hollinger, Harbor Wholesale Foods

“An awesome course that covers the best practices of NAV development and application architecture.” ~ Sukeev Kailayapathy, Second Foundation

The workshop will be scheduled twice per year in Toronto (or on demand if enough students register). Your teacher will be Floyd Chan.

Toronto - Class of 2014; design patterns; master class; Dynamics NAV
Toronto – Class of 2015

The workshop is scheduled for the following locations this year.

When Where Who
May The Netherlands Luc van Vugt, Mark Brummel
May Belgium Steven Renders, Mark Brummel
June Iceland Gunnar Gestsson, Mark Brummel
June Japan (Closed Partner Training)
June Romania (Closed Partner Training)
October United States (NAVUG, Reno) Mark Brummel
October Online NAVUG Academy Mike Doster
November Online NAVUG Academy Mike Doster

Master Class – Application Architecture & Design Patterns

During the workshop, we will reveal all the secrets that are hidden in the Dynamics NAV Source Code. You will get answers to questions like…

  • How is Dynamics NAV Architected and how do the modules communicate
  • What are Design Patterns and Anti Patterns and how do they apply to Dynamics NAV
  • How can I avoid conflicts during my object merge
  • What impact do monthly rollups have to my roadmap and release strategy
  • Can the new Delta Files help me get more organized
  • Why does Dynamics NAV have so much Code Cloning
  • Are the coding standard documented and how can apply them
  • Can I implement Object Oriented concepts such as MVVM, overloading and reflection
  • How do I organize my object structure
  • Best Practices such as Encapsulation and Natural Language Programming
  • Be familiar with over 30 most used Design Patterns in Dynamics NAV
  • What does a perfect UI look like to be repeatable in the cloud
  • Understand the impact of Meta Data on Software Design
  • What is the difference between Reservation Entries, G/L Entries and Interaction Log Entries

Course Outline

The course has four, iterative blocks that explain the elements for good software architecture using Design Patterns – Repeatable User Interface, Coding Guidelines, Architectural Principles and Exercises.

Introduction

  • Introduction to Application Architecture
  • Rollup update & Upgrade Strategies
  • Design Patterns & Anti Patterns
  • Meta Data Driven Software Development

Object Architecture

  • Define Object Hierarchy
  • Enhance the use of the Symbol Menu
  • Interfaces
  • Function Libraries
  • Natural Language Programming
  • Encapsulation
  • Arguments & Overloading
  • Façade & Hooks

Coding Guidelines

  • Design
  • Internationalization
  • Localizability
  • Readability
  • Data Dictionary
  • Hungarian Notation
  • User Interface
Design Patterns

  • Singleton, Multi Level Setup & Rules Pattern
  • Master Data, Entity State & Compound
  • Documents, Copy, Posting & Archiving
  • Test Near, Test Far, Do It, Clean Up

Code Cloning

  • Fundamentals
  • Transaction Mirroring
  • Forking, Templating, Customize & Exact Match

Modern UI for Repeatable Software

  • Instructions in the User Interface
  • Transaction Data Update
  • Hiding Fields & Fast tabs
  • Totals on Sub Pages
  • Create Data from Templates

Model View View Model

  • Working with Temporary Tables
  • MVVM Pages
  • Reports based on data in memory
  • Query data on Pages

We’re back to be found | Dynamics NAV Community

Oh my, I was almost ready to blog about it. We were completely lost!

“What do you mean?”, I hear you say.

Dynamics NAV is, as far as I know, the only product on the community website with a Wiki and with one of the last updates, we were gone missing.

Fortunately we are back and on a really nice place.

Wiki

Thanks Bogdana and Dustin for this nice spot.

Remember, the wiki is a community project. If you want to contribute, don’t hesitate to sign up!

http://community.dynamics.com/nav/w/designpatterns/default.aspx