RDLC? That’s easy. Everyone can do it…

I typically don’t post about RDLC. That’s why we have Clausl, our top notch expert on the subject.

But lately I have the feeling I want to get something out. Even five years after the introduction of RDLC to the Dynamics NAV ecosystem, I still hear very experienced developers complain about how complex RDLC is. And I always say I disagree. But here is why.

True, my first RDLC document report took me two days. It was right after the product was released, 2009RTM and there was close to no documentation about GetData, SetData and what have you. Clausl was still working at Microsoft, but just started to blog.

Since then I’ve made dozens of reports and we have a much better set of guidelines on how to build reports. Also the newer versions of Visual Studio have a better design experience. I can make a document report in a few minutes now, as fast or faster than in the classic designer and better looking for sure.

Since last year I also have some end users starting with RDLC. Both guys are no experienced developers and have no experience in the classic reports. I just briefly explained then how Visual Studio worked and helped them with the basic data set. One project is NAV2013 and the other NAV2009R2.

I was amazed to see how quickly they started to be productive and I’ll show you a screenshot of one of the reports that were made. It was amazing.

This was emphasized when my brother, a functional consultant with technical interest, started doing RDLC too. Also not limited with knowledge of the classic designer. He too was very enthusiastic and made the most fantastic enhancements.

Here is one of the reports made, in NAV2009R2 with Visual Studio 2008:

2014-12-02_20-07-04

And here is how it looks in combination with the Anveo Portal

2014-12-02_20-11-22

This report was created in two days, by a non developer.

RDLC? It’s easy! Its better! You can do it too!

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

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.

Dynamics NAV & GIT

In this post I introduced Visual Studio Online as a tool to do source control for Dynamics NAV.

Another option is to use GIT. Visual Studio also conects to GIT and many developers love it.

It looks a lot less sexy than VSO but it is extremely powerfull and command line based. Try it out, it is fun.

Kamil Sazec, a good friend and NAV MVP has publised a script on codeplex for using GIT and NAV.

Here is what he says on his blog:

PowerShell–Strong tool for MS Dynamics NAV Developers

After long time, I have found some time to write this article.

Last few months was full of “Crete” testing including the PowerShell scripts to merge NAV Objects. And I must say, I have started to love PowerShell. Things, you needed to do manually or you needed to use some “hack” to do automatically (like using ROT), you can do now using PowerShell. And I started to create some scripts for things, I just needed actually do. You can find the scripts on the NAVScripts codeplex project, which is open for you and if you want, you can contribute. I want to have this project to store different scripts “made by NAV developers for NAV developers”.

Actually you can find these scripts there:

Merge-NAVGIT

this script takes two branches in GIT repository and merge the objects in them. You can solve the conflicts in kdiff3 or araxis merge (or any other tool if you want). This way you can “work around” standard GIT merge mechanism. I have merged the Rollup Update 9 to our Addon database in just 5 minutes! Merge of the updated addon to our customer customized database – another 3 minutes of work! In this way, you get the nice “train station plan” (my internal naming) like this:

image

Compile-NAVTxt2Fob

another script, which you can use after you merge the objects. This script is doing these steps for you automatically:

  1. Create new NAV database from .BAK file (e.g. from Cronus demo db backup)
  2. Create new NST instance for this database
  3. Import NAV license to the server (to have enough permissions to create objects etc.)
  4. Import selected .FOB file to the database (e.g. FOB with latest Rollup Update to update the database objects)
  5. Import selected .txt files to the database one by one (to see where is problem)
  6. Compile the objects imported in step 5 one by one (you can see the problems)
  7. Run NAV client for manual check of possible problems (could be skipped, could send email to you when ready for manual check)
  8. Export all objects to .FOB file
  9. Remove NST
  10. Drop database

As you can see, result should be FOB file with compiled objects ready for import to target database. It is something like “Automatic build process”. You can easily add part to run automatic testing…

 

Other functions

In the scripts there are many functions you can use for own scripts. You can export/import/compile objects to e.g. update the files in repository, update you database from the repository, merge version lists etc.

 

I hope that you will find these scripts usefull and you will be able to extend them as you will need. All is available from the codeplex here:

https://navscripts.codeplex.com

You can even fork/clone the GIT repository and contribute… Mrkající veselý obličej

Conclusion

Every NAV developer should learn powershell, because it could save big chunk of time for us. And with the accent to the up-to-date customers, we will need to press the upgrade cost down. And you cannot do that without automating the upgrade process. Correctly written scripts are good tool to do your work. They will never replace you, because still there are exceptions which needs some human brain to solve, but it is not 100% of the process now, but e.g. 10%.

Merge of our new version of addon to some customer database was 1-2 days in some cases. Now, with the script support, it is just 2-3 hours, in which the 1.5-2.5 hours are automatized and only 0.5 hour is “conflict solving”.

You can find many sources for beginning with powershell, but one for all: https://www.youtube.com/watch?v=MnWKPdkGFSU

Visual Studio Online | Welcome Cloud Development

It was not until recently that I was introduced to the term ALM. Application Lifecycle management. No idea when this Three Letter Abbreviation was invented but the problem it describes are much older, and familiar to a lot of Dynamics NAV developers.

About three years ago I wrote this article, that caused quite some stirr in the NAV Channel, unintended, but typical for our community I think.

So what is the problem definition.

Keeping track of Development History. Why did What happen and When.

After writing the article I dropped the subject. We started the Partner Ready Software initiative and ALM is/was not part of our initial primairy focus. When presenting our vision on Dynamics NAV development I use these slides:

2014-04-06_21-29-58
What we tried…
2014-04-06_21-30-22
What we need…

And from a pure software quality concept this is true.

But that does not take away the fact that ALM is quite cool too. And a recent development caught my attention that might be of interest to all Dynamics Partners, but especially the smaller ones or the ones who still do customer based development.

Until recently TFS had to be installed on premisse and it is “something to maintain” for IT guys.

When Waldo and I were in Redmond (WA) last year for MVP Summit I went to a session about ALM where Visual Studio Online was presented, as Luc van Vugt also mentions in one of his posts.

On first thoughts you might think this allows you to code C# in the cloud, and yes, you can do that if you want. But a better naming would be TFS Online since it allows a Team Foundation Server to run in the Cloud for free without any hassle or cost. How cool is that!

This is definately something that brings ALM back into my area’s of interest and I have already spent some time exploring it.

You can setup different projects in the tool and it allows you to define work items and sprints to work scrum. You can define team members and do planning and even do visual kanban planning. Really super cool!

The first downside I found is that it is still required to use an on site tool to check in and check out objects. You can use Team Exporer which is free.

PowerShell

But TFS also allows you to use PowerShell to check in and check out objects which means it can be integrated with existing Dynamics NAV PowerShell scripts. This would be very interesting to NAV Partners and we won’t need all these third party tools to integrate.

2014-04-07_19-39-54

GIT & Microsft Dynamics NAV

Another concept that I stumbled on while exploring VSO is GIT. I am not quite sure yet how to combine these two concepts in NAV but the way I look at it is that GIT helps while doing development and work is still unfinished, and when you check in objects in TFS they are ready to be tested.

TFS is integrated with GIT and I am going to spend some time investigating what the options are and how they can work together.