Tag Archives: NAV Architecture, Patterns & Code

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.

Advertisements

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

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

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

Design Patterns YouTube Playlist | 30 Videos

With the recovery of a lost video at Microsoft, the Design Patterns YouTube PlayList has 30 Videos now.

23 of these videos are part of the How Do I series and co-sponsored by Microsoft. 7 videos are created by me.

You can find the PlayList on my YouTube channel: Here is the link:

https://www.youtube.com/user/brummelds

Until a year ago I was unfamiliar with YouTube and video making but it is surprisingly easy to do and sends out a very clear message.

The playlist includes an hour long introduction to the concept of Design Patterns

Workshops (Advertisement)

If you want to learn more about how Design Patterns can help you improve development of Dynamics NAV in your company we have started a series of workshops together with regional MCT’s.

The first region we host is North America. On March 19th and 20th we do Atlanta with Mike Doster and on March 23rd and 24th we do Toronto with Floyd Chan.

Next up will be Europe with probably Belgium, The Netherlands, UK and Austria. I am still looking for an MCT in the UK to work together with.

Quiz: Can you see the difference between these two images?

ThinkNAVAttlantaThinkNAVToronto

[PRS] Design Patterns that should be [made] obsolete [by Microsoft]

Yes, this blog has a double title. Every now and then you need to do a little self reflection. Two weeks ago I was in talking with my fellow PRS member Soren Klemmensen and we discussed the fact that in the list of object oriented Design Patterns that we brought to Dynamics NAV there are a few that could be built in or better integrated if Microsoft would help us a little.

Ok, if you read this and think, what does this guy mean, then I should tell you some background first, otherwise just skip this part.

For the last 4 or 5 years ago we have been working on the Design Patterns project. Next to documenting the existing patterns with Microsoft we also tried to look at some best practices to better code in Dynamics NAV. They are also design patterns, categoriesed as implementation patterns, meaning the way you structure code.

Examples of these patterns are:

  • Class, Method, Property (aka Agents/Actions)
  • Natural Language Programming
  • Encapsulation
  • Facade
  • Hooks
  • Interfaces
  • Surrogate Keys

You can learn more about these patterns on my YouTube channel.

While most of these patterns have nice names now, we actually changed them quite a number of times. Natural Language Programming was once called Readable Code and Encapsulation was called Atomic Coding. The Class, Method Property has two names as well. Reason for this is that we learned during the project that most of these concepts are well known in computer science and object oriented programming. We were reinventing wheels.

Dynamics NAV has a realtively basic development environment that does not allow us to do things that Visual Studio and C# or other languages do. On the other hand it has lots of things that C# does not have that we can take advantage of.

This can come in handy when trying to make a couple of these PRS design patterns obsolete, smarter or built in the environment. One of the reasons we can do this is becuase C/AL and C/SIDE are very metadata driven.

So what patterns can be made obsolete

Class Method Property (aka Agents/Actions)

This pattern teaches us to make all functions that you can perform on a table a member of the table and if complex enough put inside their own codeunit.

The reason why we thought of that is actually a bug in the symbol menu. The symbol menu does not understand code outside the contect of the variable you define. For example: if you define a variable of the type Sales Header, it does not show that we have a codeunit that takes this record as a parameter and posts it.

If that would be the case, we would probably have to rethink this pattern. I have implemented this pattern at one of my solutions where we have a table that is more or less the core of an application. This table now had douzens and douzens of functions. I can honestly say that this does not improve usabilty more than loosely coupling the codeunits to tables.

It would be easier if NAV reads the metadata and helps with the symbol menu. That would save a lot of functions on the table that are then obsolete and actually a hassle to maintain.

Facade

This was the example I thought about yesterday when I did an introduction to design patterns workshop for NAVUG USA. I was talking about encapsulation and override. Most languages allow programmers to override functions in a class. NAV does not.

With PRS we found Facade as a solution for that, but it is actually wrong to suggest to implement a facade for each function you create on the table. Think about it. You would dramatically make your code more complex than required.

Facade is a great pattern! It exists in object oriented world and it should be implemented by design if the architect expects functional requirements to override the function. The typycal example is weighing bridges where every customer has their own hardware and has a custom interface. This is what facade does great.

C/AL should allow programmers to override any other function at design when required without the orriginal architect anticipating every move. Other programming languages allow that.

Surrogate Keys

This is the newest member of the PRS design patterns and as most other patterns it started its life with another name. Unique Record Identifier.

In dynamics NAV most tables are connected through the primairy key, for example comments. Comment tables have complex primary keys to be able to connect them to each table in NAV.

The idea is to add a single unique key to each table in NAV so we can connect to other tables using a single unique key. Think about the possibilities to add factboxes using this to each table in NAV without thinking.

C/SIDE can add this automatically for us.

Conclusion

Some design patterns can be improved with what I think are relatively small changes to C/Side. We should always self reflect and realise that some things we do are actually workarounds.

Implementation Pattern #2 | Natural Language Programming

If you want to read the first article about Implementation Patterns, here is the link.

If you prefer a video, it is on YouTube. The blog starts at 2:20 after a general introduction.

Natural Language Programming

I hear what you are thinking. A scientific concept like this, in C/AL. Yes, in C/AL.

Scientific Approach

If we look at Natural Language Programming as a concept there is first of all the scientific approach. Programming computers in natural English, or any other language, preferably via speech recognition. However, there is a lesser science fiction approach to the concept.

Multi Level Coding

This is multi level coding. Splitting the nerdy code, from the readable code.

Natural Language Programming has actually been implemented in some way in SQL and COBOL, it’s not new and we’ll try to apply it do Dynamics NAV.

If we look at SQL server syntax, you can see that readability is implemented in the language.

2014-12-08_20-49-14

With Dynamics NAV we don’t have that, we have SETRANGE and SETFILTER and FIND. Also with SQL code get hard to read once you start adding business logic.

The approach we would like to you take when we talk about Natural Language Programming in Dynamics NAV, is to write two layers of code Readable Code and Nerdy Code. These layers should be separated.

2014-12-08_20-50-27

Traditionally, if code is to nerdy and hard to understand the programmer will add comments. And if one programmer cannot understand the others code, the feedback will be, he forgot to put comments in the code!

2014-12-08_20-51-02

This is untrue, comments are evil and should always be avoided.

Let’s look at an example.

The development task we will give our programmer is to create a script for a very popular customer who always buys the same item. A side board.

Instead of coding away, our developer starts thinking what steps need to be implemented.

2014-12-08_20-51-47

So this is the code we end up writing.

2014-12-08_20-52-26

Although this is very understandable code, it does nothing. We need an extra layer, the nerdy layer.

2014-12-08_20-53-11

The nerdy layer contains the actual C/AL code that does the heavy lifting.

But wait! This is not all, there is a bonus. This makes debugging accessible for consultants and end users.

Even though general rules mostly say debugging is for developers, if all hens is on deck, everyone will start debugging.

2014-12-08_20-54-09

And when Natural Language programming is implemented, this will have the same two layered approach and we can step over all the code that does not contain errors.

So where do you start with implementing this.

There are two approaches.

The first is to start writing the functions and then write the code. This is the preferred way.

The second option is to start with the classic approach and then break it down and create smaller pieces.

Remember that when loops are required, you need to create a very logical function name since you cannot see the functions inside the loop from the initial workflow. To support this pattern the function names can now be 132 characters.

There are two enhancements to the C/AL code editor that would improve using this pattern.

The first is to select a few lines of code and create a function from a right mouse click. (Thanks to Soren Klemmensen for the idea)

2014-12-08_20-55-32

The second would be to see from the editor that a function has details or subfunctions.

2014-12-08_20-56-44

As a reference video I would encourage watching How Do I Implement the C/AL Coding Guidelines which will be published in December 2014.

Remember, write readable code, and nerdy code and separate them. This will enhance readability of your code and improve maintainability.