Monthly Archives: November 2014

Implementation Pattern #1 | Classes, Methods and Properies

So last week in this post I promissed you to publish the implementation patterns that help you structure your application to achieve repeatable and upgradable solutions that are easy to understand and maintain.

Not a big reader? You can watch the video of this blog post!

This is the first pattern and one of the most fundamental elements to understand before proceeding with the other patterns.

We will talk about ising classes, methods and properties in C/AL, a functional language.

Classes, Methods and Properties are elements of C#, an object oriented programming language. However there are certain elements that we can take from that language and map them to Dynamics NAV and make our daily lives easier.

This week I wrote two other posts in a series about Dynamics NAV and C# that discuss the same concept from another side. If you haven’t done so I recommend reading them first.

Dynamics NAV in C# | Part 2 | Classes (Updated)

Dynamics NAV in C# | Part 2 | Classes (Continued)

And here are the two other posts about C# and Dynamics NAV:

Dynamics NAV in C# | Part 1 | The Differences

Dynamics NAV is moving to C#, get ready to follow!

Let’s talk about the Pattern

The problem we are trying to solve with this pattern is the loose connection between tables in dynamics NAV and what you can do with it in other objects such as codeunits.

If we look at an example, we have the customer table, and a function in Codeunit 365 Format Address.

2014-11-29_20-25-52

If we want to format an address in a report, as a developer I need to know that there is something like Codeunit 365, declare it as a variable and call the right function. There is nothing in Dynamics NAV that helps me find that function.

Another example, the sales header. With this I can call the post Codeunit or the Release Codeunit.

2014-11-29_20-29-07

However, when I look at the sales order page, we see again that the codeunits are called as variables.

What would this look like in C#?

Let’s compare this to object oriented programming, C# and classes.

2014-11-29_20-29-52

In C# the customer table would be a class and the fields would be properties that have a getter and a setter. The class has a method FormatAddress, and this calls out to a generic class.

Our Sales Header and Sales Invoice would also be classes. Probably in pure C# you would increase the object orientation with inheritance, but let’s leave this a simple example.

2014-11-29_20-31-08

With a Sales Header I would be able to use the Method Post and with the Sales Invoice I could call the FormatAddress again.

Let’s do this in Dynamics NAV!

So what if we do this in Dynamics NAV.

2014-11-29_20-32-25

We would create a function on the Customer Table called FormatAddress, and then on our report.

2014-11-29_20-33-17

We don’t have to know the Codeunit anymore, but browsing through the Symbol Menu, the equivalent of Intellisense in the C/AL editor, I would see that a function FormatAddress exists and I just use it from my report.

2014-11-29_20-33-54

The Table is the class, the Function is the Method and a Codeunit is a Class.

The same would work for the Sales Header.

2014-11-29_20-34-40

This would have functions release and post. And on the page I can just call the functions.

Advantages

This pattern has a number of advantages. First of all there is a clear intention of the programmer. Everything you can do with a record in the table is clearly specified on the object.

2014-11-29_20-36-10

It reduces the learning curve for new developers, since by just looking at the functions in the symbol menu we can learn what we can do with the records in the table.

We can actually use the symbol menu. Using this pattern would make creating a Codeunit as a variable on pages and reports wrong. If you see a Codeunit on one of these objects, it is an indication that this pattern is not implemented.

When working on methods, developers have less chance of overlap changing the same object. This makes merging easier when the branches come together.

And it actually allows us to do versioning of business logic. This concept will be explained in another video or blog post.

Downsides

There are some downsides too. If you create a Codeunit for each function, you get a lot of objects making managing the application less easy. Also having more than a hundred functions on a table does not exactly clarify the intention either.

2014-11-29_20-36-49

Lastly if you call a table function from a page, the Go To Definition does not work which is highly annoying.

2014-11-29_20-36-59

To avoid too many codeunits in your application, you might use the rule that if a function is less than 5 or 10 lines of code, you can write the code in the function. We’ll touch on that too when we will talk about natural language programming.

Advertisements

Dynamics NAV in C# | Part 2 | Classes (Continued)

Disclaimer (Repeated): If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

In my last blogpost I talked about interpreting the table object in NAV as a C# class, how to use C# properties as fields and how to use C# methods as function that then map to another C# class which represents a codeunit.

The example code allowed us to create a Customer using Number Series and Format the Address.

Let’s take this one step further to really explain how this mapping is done, and how to use some of these OOP concepts back in our beloved Dynamics NAV C/AL

Sales Header

Let’s create a new class to create a Sales Header. The goal is to post the document as a Sales Invoice, we will reuse the Customer and FormatAddress classes.

2014-11-29_11-28-21

There are a couple of things I’d like to discuss in this example. It might not be the official way to do it in C#, but the idea is to be able to pass a customer class to the sales header and populate the name and the address. I also want the Order Date to be the Posting Date unless the order date is set to a different value. For the latter I probably need to add some more code like Jason shared on part I of this post.

So let’s see what happens if we create a new Sales Header like this:

2014-11-29_11-55-08In the example above we first create the customer like in the first post, then we create a new sales header and “Validate” the Customer. This populates the Name and the Address. Then we set the Posting Date, which sets the Order Date. We write the values to the console to see that it works.

Posting

Let’s repeat using a codeunit as a method and post the Sales Header to a Sales Invoice. To do this, we need the SalesPost  class that we make a method on the SalesHeader class. Like this:

2014-11-29_11-59-09

If you would have to fully design this in C#, you would probably use inheritence and try to reuse more elements, but we are trying to map C/AL to C# using the methodology we are used to in C/AL.

So we create a new C# class SalesInvoice which is a subset of the Sales Header, like table 36 and 112 in Dynamics NAV. In the SalesPost class we convert a SalesHeader into a SalesInvoice.

I’ve explored if something like TRANSFERFIELDS exist in C# and found a class on GitHub but decided not to use it for simplicity reasons.

If we use this in our example it would look something like the following:

2014-11-29_12-05-44

So we “Post” the Sales Header to a Sales Invoice and print the Customer Name to prove it works.

Let’s take it one step further…

To complete the class lesson, let’s reuse the FormatAddress on the Sales Invoice, like we would do in Dynamics NAV. In the first part of this post you’ve already seen that I had a function in my FormatAddress class that takes the Sales Invoice as a parameter.

Let’s use this, and again, we would make FormatAddress a method on the Sales Invoice class.

2014-11-29_12-09-10

You probably get the point now so let’s see what this does:

2014-11-29_12-12-39

So to briefly recap, we create a customer class and populate the address. We “Validate” that into the Sales Header and “Post” it into the Sales Invoice. Then we Format the Address.

Conclusion

The idea of this post is to explain C# from a C/AL perspective using names you recognise. A table is a class, A codeunit is a method and A field is a property.

There are probably very smart things you can do in C# to acomplish the same in a more object oriented approach. Personally I like the NAV model since it’s self explaining and simple.

This is what makes NAV rock!

Next episode: Plymorphism in Dynamics NAV. (I hope :).)

Dynamics NAV in C# | Part 2 | Classes (Updated)

Disclaimer: If you are a skilled C# developer, I apologize for any mistakes I made, they we unintentional. 🙂

UPDATE (29/nov/2014): Based on the feedback from Jason Down I changed the C# code to get the number from the number series class.

Ok, there we go. No more conferences so time to do some actual blogging.

This is part 2 of my NAV in C# series. If you have not done so, please read part 1.

In this episode we will talk about classes.

In C# a class is very powerfull. It’s a datatype that you can form yourself giving it properties and methods. And since C# is object oriented, you can inherit from classes etc.

But let’s not get into these details. The blog series is intended to explain C# from a Dynamics NAV perspective.

So how do we map a class to Dynamics NAV.

Actually you could see a table or a codeunit as a class.

A Table is a Class

Let’s start with that. Let’s have a look at the customer table in NAV. It has a bunch of fields

2014-11-27_21-38-07

So how would something like that look like in C#:

2014-11-27_21-41-27

Each field is a property. You can see that it is a property because it has the { get; set; } syntax

If you would like to code against it you would declare a new customer like this

Customer Cust = new Customer();

Cust.Name = “Mark Brummel”;

Cust.Address = “Somewhere”;

This would create a new instance of the class and populate the name

Number Series

But we have number series in NAV.  So let’s make that

A Codeunit as a class

Let’s make a class that can return number series.

2014-11-27_21-46-58

This is a very simple class with a method that returns a number. It should be smarter but I hope it explains the idea

Return the number in the customer

So what if we want to assign this number to the customer? In C/AL we would have triggers. In this example we would use the getter, and store the value in a variable. This latter would off-course be done in the SQL Table in NAV itsself.

2014-11-29_11-10-04.

In the property we return the value of the number series. See how easy that is?

Now if we create a sample application that would create a customer we would have this

2014-11-27_21-51-24

So we have a new customer with a number, that we do not declare in the class, it is automatically added, like in Dynamics NAV

What about address formatting

So we print the address, but what if I want to do that like in NAV? Then we need a new codeunit class, and we would add a method to the class, like this:

2014-11-27_21-54-02

This class takes a customer as a parameter and calls into a generic function to move the address to an array. It also has a function for the Sales Invoice, a class we will use in the next blog post.

A Codeunit is a Method

In C# we would add the adressformating as a method that we can do with a class. This way we don’t have to call the addressformatting class in our programm.

Like this:

2014-11-27_21-56-00

And the keyword this stands for what we would cal Rec in Dynamics NAV.

This is what it does in the program:

2014-11-27_21-58-07

A Table is a Class, A Codeunit is a Method (and a class)

So a table definition (not the actual SQL table) would be a class and a codeunit too, and added to the table class.

This actually would work nice in NAV too, if we would declare things like FormatAddress on the table, we would never have to use Codeunits as a variable anymore.

Next time…

I will explain how to create a sales order in C# and how to post it to a sales invoice.

Hang on, stay tuned.

2014 Conference season is over, NAVTechDays rocks | What’s up next ?

With NAVTechDays 2014 last week, the conference season for Microsoft Dynamics NAV is officially over.

From the perspective of a presenter, NAVTechDays is just amazing. At a cinema with a screen the size of a small house and hundreds of attendees is an experience that’s next to nothing.

I’ve already wrote some articles about what I did in Antwerp. Just in case you haven’t read them yet, you can find them here, here and here. I also recorded a video.

I had to promise Arend Jan Kauffmann that my next blog post would actually contain useful information, so hopefully it did.

Why Do You Attend All These Conferences…

…and what does Microsoft pay you? That is a question a lot of people ask me. Traveling to 6 events across the globe in 10 weeks has some serious impact on your life.

First of all, let me release you from one dream; Microsoft does not pay anything.It just does not work that way. Even if you are an MVP you are on your own. And just because you are an MVP, doesn’t make you a good presenter or a good teacher either.

For me the reason to do it, is to meet a lot of people and to get a chance to evangelise a wonderful product. The only selfish act is that paying my mortgage depends on the continuous existence of the product, so I might as well help keeping it so.

So what’s next?

I am inspired to do a lot of blogging and some videos. First of all I want to continue with my C# series that I started. I have learned a lot of C# during my trips. Even last week during Vjeko’s Mere Mortals session I got some inspiration to write an article.

From a Design Patterns perspective we are getting ready to a complete package of Architectural, Design and Implementation patterns. We have a good list of patterns on the wiki and almost 30 videos.

Together with the object-oriented methodology we presented during the writing repeatable software session we have a complete package what deserves more attention. You can expect that coming.

What about Partner Ready Software?

When we started PRS in 2011, the intention was to brand a thinktank and community initiative. With the design patterns project maturing one could argue about the value of such a concept.

Truth is we don’t know yet what will happen. There are a few options that we are currently discussing that have different futures for the brand. I’ll keep you updated as things get more clear.

So now…

…back to work all of you, you already wasted enough time reading this…

🙂

An introduction to Repeatable and Upgradable Software Design

Partner Ready Software | Be Repeatable and Upgradable

By Mark Brummel

Not a big reader? Watch the video of this blog post here.

Introduction
Partner Ready Software is a community initiative founded by Gary Winter, Mark Brummel and Eric Wauters. The current team is completed by Vjeko Babic and Soren Klemmensen.

2014-11-23_14-15-49

When Dynamics NAV was introduced, about 25 years ago, the original authors of the software have implemented design patterns. However they were never documented and only existed implicitly in the software. The people who were trained in these early years got these patterns explained by the trainers who were closely related to the original authors of the software.

2014-11-23_14-22-42

During the years, these patterns were forgotten by both Microsoft and the partner ecosystem. In order to attempt to document this knowledge, Mark Brummel, one of the founders of Partner Ready Software wrote a book about Application Design for Microsoft Dynamics NAV in 2010. This book contains a…

View original post 965 more words

NAVTechDays 2014 | How to Write Repeatable Software

Yesterday, on the first day of NAVTechDays the Partner Ready Software Team presented the latest and greatest on how we think you should write repeatable software.

The session was done by Soren Klemmensen, Gary Winter, Vjeko Babic and Mark Brummel (me).

I started of with a short introduction into te concept of Design Patterns and the history of our project.

B24yZd8CYAAcCSg

After that Gary took over and presented part of the methodology. He talked about defining your agents, them as a class and add what they do as methods.

I hear you thinking, Dynamics NAV does not have class objects and methods. Well, we think it does. If you think of a table as a class, and everything you can do with the records in a table as a method, you can transfer some of the object oriented concepts to Dynamics NAV. This helps you get structure in your software making it easier to understand for everyone and maintain in the future.

The second subject would be something I like to refer to as natural language programming. This is a methodology of writing self explaining code. It is possible in NAV although there are some minor drawbacks that we get with the C/AL editor.

Watch my blog, I will explain Natural Language Programming soon.

Lastly Gary talked about implementing Facades. This is a concept where you separate the method implementation from the class. Again a concept we took from object oriented programming.

This can be done in Dynamics NAV as well, and I will hopefully blog about that soon as well.

Surrogate Keys

Then Soren took over and he talked about surrogate keys. To avoid this blog post getting too long, I will refer to the pattern he published about it so you can read about it yourself. It is a very neat concept of creating repeatable components in Dynamics NAV with a low footprint in the application.

http://blogs.msdn.com/b/nav/archive/2014/07/09/nav-design-pattern-implementation-of-surrogate-keys-using-the-autoincrement-pattern.aspx

Out of the Box

After Soren presented, I wanted to share two concepts that were introduced in NAV2015 but not emphasised by Microsoft in the way I thought they could be used. Also, these two deserve seperate blog post.

Shipping Delta’s

The new delta object that is introduced in NAV2015 is an excelent candidate to ship software instead of using FOB files. There are some drawbacks that I will blog about later.

2014-11-21_07-53-49

Conversion inside your FOB

If you ship software to customers in a FOB, sometimes you need data conversion. Traditionally you would do that in a report or codeunit that you ship seperately. Now with the new upgrade codeunits you can also ship that and it will be automatically executed if you import the FOB. That opens a whole new world on how we ship software and makes our lives easier.

Again, a follow up blogpost is needed here.

Design Patterns in .NET

Vjeko showed us how you can use design patterns in .NET in correlation with Dynamics NAV. He explained how to implement the service locator pattern.

Roadmap

Lastly we presented a “roadmap”. This we got into the product and things we would like to get.

B2515vOIgAEAv2z

GIT/TFS

We focussed on a vision on how to get TFS integration into the product.

Our suggestion is to implement that into the client via PowerShell.

2014-11-21_07-56-12

That’s it

Hopefully the session video will be available soon.

You can download the presentation here.

NAVTechDays 2014 | Development Best Practices for Creating Partner Ready Software

This year for NAVTechDays we did our second workshop for Development Best Practices for Creating Partner Ready Software. This is a one day workshop about design patterns in Dynamics NAV and how they can be applied.

I’ve been asked by the attendees to share the slides, and so I will.

Before lunch we first spent time explaining what Design Patterns are and how they fit into the Dynamics NAV ecosystem. After this the attendees did an excercise of writing a patterns themselves and presenting their pattern to the group.

After lunch we deep dive into what we call the Partner Ready Software Design Patterns. They help you structure your code in Dynamics NAV the way you would do it in object oriented languages.

On this link you will find the PowerPoint slides and the fob file with excercises.

I would like to thank Soren Klemmensen for his help during the workshop.

If you would like the introduction to Design Patterns, please contact me. I will be happy to do an online session and explain how they can be implemented.

WP_20141119_001