November 2014 – Marije Brummel Blog | Business Central, Azure and more…

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.

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.

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.

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.

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.

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

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.

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

The same would work for the Sales Header.

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.

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.

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

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.

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.

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:

In 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:

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:

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.

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

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

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

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 = “Marije 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.

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.

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

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:

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:

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

This is what it does in the program:

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

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 Marije Brummel (me).

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

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.

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.

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.

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.

Recap | Asian Partner Summit 2014 | Bali

Doing six events in 10 weeks, this is probably the most special one from a venue perspective.

Last year I’ve heard from a number of people quite good feedback of that year’s Asian Partner Conference. So I decided to check it out myself. As an excuse I figured I might as well promote my new book. I calculated that I have to sell at least 250-300 copies to break even. 😉

Since I am not a Partner, the way I managed to squeeze myself in was via the MergeTool sponsoring. Their sponsor package included an extra ticket and I offered helping them out.

Having been in Redmond for a week, traveling 15 timezones in 48 hours and spending 27 hours in planes, I was not really feeling well ariving. Fortunately that got better after a good nights sleep.

Which was good since I offered Microsoft since I was there, I might as wel help them out too doing a presentation. So I did.

What is this about

The conference is actually a combination of two events, a business part with more general marketing sessions and a technical and functional track with sessions for consultants and developers as well as hands on labs.

The latter proved to be quite a challenge.

Reading the emails from the sponsoring I already read the recommendation to not relay on the internet for your presentations but to use screenshots or installed software only. And that was a good recommendation.

Even though the internet in the rooms (and the hotel had more than 1000 rooms) was very good, the internet at the venue just crashed as soon as more people connected.

And with the handson labs based on Azure, this was a problem. Because of that, the schedule got changed.

RapidStart Upgrade

I presented about a part of NAV2015 that I love most and am very familiar with. RapidStart Upgrade. I’ve been doing upgrades for more than 10 years and as many other technical people I must have done 1000nds of code merges.

The entire Wednesday afternoon the floor was mine, and since there was no internet, I talked about RapidStart for 2,5 hours. This you can easily do since there is so much cool stuff to talk about. It drasically changes the way we will be doing upgrades in the new platform.

During the talk, the hotel brought in 4G routers and the attendees did some handson after the presentation, but it was still slow.

Design Patterns

The next day, thursday it was so slow, and we had no internet that I decided to try and go home earlier.

Fortunately I did not do that since I first got asked to talk about design patterns for an hour, and then the internet started working so we could do handson. I decided to stay and help with the RapidStart handson.

The Community

In Asia is quite nice. People are friendly and asked many questions during the handson. People from Australia and New Zealand where a bit louder than the Asian people.

MergeTool

I must say I am really impressed by the work Per and Susanne have done in the last years. They have a widely used product with a huge fanbase and a lot of interest from partners. Per and Susanne, thanks for inviting me.

The Venue

Although I am not a typical sun bather, Bali is just amazing. I took a tour around the island and it is beautifull.

NAV Events Fall 2014 | 2nd half

As I am writing this the second half of the 2014 NAV event season has started. We had Directions USA & EMEA and NAVUG SUMMIT.

Whilst I am writing this post from my hotel room at MVP Summit in Seattle, most NAV people are in Barcelona for Convergence EMEA. I had to make the choice between Redmond and Convergence, I choose Redmond to educate myself more on .Net, Visual Studio and development methodology and see how that reflects to Dynamics NAV.

Next week we have the Asia Partner Summit in Bali. I will be there doing a presentation and hands on lab for Rapidstart Upgrade and Rapidstart Code, helping out Freddy Kristiansen. Although I am looking forward to the event, I am not looking forward to spending 27 hours in airplanes in 2 days.

The last, and probably best, event of the season is NAVTechDays in Antwerp, although NAVUG Summit was really cool too.

Our Development Methodology workshop is SOLD OUT, but you can still register for the event and attend our session where we will deep dive into the complete PRS methodology which is “ready” now. We are proud to present four years of work, and we’ll probably think of new things allong the way. We at least have some fresh new idea’s to share with you.

So hope to see you at one of the events.

Goodbye from Redmond, WA.