NAV Directions 2014 in San Diego

Have you signed up yet?

Well if not, you really need to get it done.

Directions is the one big event every year that is exclusively dedicated to Microsoft Dynamics NAV on the North American continent and everybody should make sure to be there.

Maybe you are a smaller partner, bigger or some were in between and you really don’t see why you should invest in this event, but this year it is more important than ever. Like I wrote recently in my “Do or Die with Microsoft Dynamics NAV” blog post, things are changing and they are changing fast. If you don’t change I doubt you will have a chance to make it in the coming years.

The competition is hard out there with major players that will eat your segment for breakfast and that at a price point where you cannot compete unless you change and now.

Looking at the great many sessions this year it is clear that there is a lot of focus on this from Microsoft & the community. Very much energy has gone into putting sessions together that help explain what we need to do to be successful in the future with cloud, multi-tenant and a very different looking ERP market.

Sign up today and start your change…

http://navdirections.com/

DO or DIE with Microsoft Dynamics NAV

Do I have your attention now… or should I have called it “An Inconvenient Truth

Dynamics NAV greatest strength is its amazing ability to easily be modified & customized to individual needs, but it is also the greatest weakness. Said in other words: “With Great power comes great responsibility”

You might be thinking by now: “What is this guy talking about?

Well far too often (and I have fallen victim myself from times to times) we make changes to NAV because we can. It is easy and what the customer is asking for, but we forget to qualify if this is the right thing to do!

Henry Ford once said that, if he’d asked his customers what they wanted, they’d have asked for a faster horse.

In our Dynamics NAV world this is especially true. We as partners needs to be the leaders and figure out what the customers really need instead of what they are asking for, but currently far too few of us do that.

This all comes down to a few things: Product Management… Source Code Management… Product Life Cycle… Agile development…

Product Management is among other the ability to filter through customer demands or requirement. The ability to understand the market you are working in & the ability to ask the right questions to get to the root of the problem or requirement.

What is it the customer REALLY is looking for…? What is his fundamental need?

Sadly Product Management is far too often overlooked and many even don’t have this as a job function in their organization.

You might ask: Why?

Well the classic way in the NAV world has been to locate a customer, sign a deal and develop a solution that fit his needs. The consultant and programmer (often one and the same person) was on the front line and gave the customer what he needed. It was easy. It was quick and it generated revenue. End of story. In short it is much easier to give the customer what he thinks he needs instead of figuring it out.

I guess this story is still true in many cases, but this world is dying and if you don’t want to die with it, you need to change gear. Change the way we think about everything.

If you think you can compete with somebody that delivers one solution, but can deploy it 200 times, 500 times or a 1000 times you are sadly mistaken. They can afford to put much more into the product in the form of functionality, testing, upgrading than you will ever be able to in the “one of” individually customized installation.

Source Code Management is another area far too many try to avoid. Many have told me through the years that this is just overhead and brings no value to the product. Nothing could be further from the truth.

That ability to know WHAT you are doing (The source code changes) and WHY you are doing it is true product management. It is true Product Life Cycle management because you now develop your product in a direction with a clear goal and understanding of why and what it takes to make your vertical a success.

How to get it done?

The next question is how to get it done. Well it is all about selecting the right tools.

Team Foundation Server from Microsoft is my preferred tool, because it is doing all of this in an integrated way. Source Code is stored and linked directly to tasks. Bugs & Product Backlog Items are managed, prioritized and linked to Features.

This is also completely integrated to Visual Studio which already should be your developers preferred tool of choice for anything in the non NAV world of programming.

If you don’t want to install it you can use the cloud version that you find athttp://www.visualstudio.com/ Yes you need to pay for it if you go above a certain number of users or if you want to access all the features, but cloud services are the way of the future, so get over it.

Best in class development practices is another fundamental way we need to change the way we think. The Partner Ready Software guys have been working on this for years. There is a new initiative on the community side about Microsoft Dynamics Design Patterns, but it also comes down to your team of developers. Do we give them time to research the best ways to do development? Do we encourage code review? Do we put time aside to refactor code?

We can continue doing what we have done in the last many years and gaining another 100,000 customers worldwide over the next 25 years for NAV or we can change gears and add another 100,000 customers every year. I know what ship I want to sail on.

 

It is DO or DIE time folks

Get and Set-NAVApplicationObjectProperty with PowerShell in Cumulative Update 9 for Microsoft Dynamics NAV 2013 R2

Time to look at the Get and Set Commandlets introduced with Cumulative Update 9 for Microsoft Dynamics NAV 2013 R2

These 2 new commandlets can be used to get and set the Object Properties from in objects exported to text files from Dynamics NAV 2013 and higher.

Let’s look at them in detail.

Get-NAVApplicationObjectFile

The Syntax:

Get-NAVApplicationObjectProperty [-Source] <String> [-Confirm] [-WhatIf] [<CommonParameters>]

-Source: The <String> after the Source points to the source file from which you are reading the NAV Object file you want to split into multiple Object files

An example could be C:\temp\AllObjects.txt

-Confirm If set you will get a prompt before the command is run.
-WhatIf Interesting one. If set this shows you what would happen if the cmdlet was run, but it is actually not running it.
-CommonParameters The CommonParameters are things that are not specific to this cmdlet.

A great resource for the CommonParameters can be found here:

http://technet.microsoft.com/en-us/library/hh847884.aspx

Example:

Get-NAVApplicationObjectProperty -SourceC:\temp\NA2013R2CU9\COD2.TXT

This will give you an output of the Object Properties of the file or files identified. In itself this is not too interesting unless you can use it for something, but more about that in a later blog post.

Alternative you can also here use the “*” to filter your input.

Get-NAVApplicationObjectProperty -SourceC:\temp\NA2013R2CU9\COD*.TXT

In this case the output will be all of the Object properties of the Codeunits in the folder.

The commandlet also works on a text file with multiple objects as seen in the commandlet here:

Get-NAVApplicationObjectProperty -Source C:\temp\AllObjects.TXT

Set-NAVApplicationObjectFile

The Syntax:

Set-NAVApplicationObjectProperty [-Target] <String> [-DateTimeProperty <String>] [-ModifiedProperty <SetModifiedPropertyAction>] [-PassThru] [-VersionListProperty <String>] [-Confirm] [-WhatIf] [<CommonParameters>]

-Target: The <String> after the Destination points to the folder where we want the individual object files written to.

An example could be: c:\temp\Destination\

-DateTimeProperty: The <String> after the DateTimeProperty identifies the values the Date and Time should be set to in the object properties.
-ModifiedProperty The <SetModifiedPropertyAction> after the ModifiedProperty identifies the value you would like the Modified property to be set to. Only “Yes” or “No” is allowed.
-PassThru The PassThru is another SwitchParameter that instructs the command to return file info for all the files created. Default it will only return a list of files if this SwitchParameter is not set.

 

The file info includes information such as Mode, Date, Time, Length (File Size in Bytes).

-VersionListProperty The <String> after VersionListProperty is used to update the Object properties identified by the Target.
-Confirm If set you will get a prompt before the command is run.
-WhatIf Interesting one. If set this shows you what would happen if the cmdlet was run, but it is actually not running it.
-CommonParameters The CommonParameters are things that are not specific to this cmdlet.

A great resource for the CommonParameters can be found here:

http://technet.microsoft.com/en-us/library/hh847884.aspx

Examples:

Set-NAVApplicationObjectProperty -TargetC:\temp\NA2013R2CU9\COD1.TXT -VersionListProperty “MyVertical1.1”-ModifiedProperty No -DateTimeProperty (Get-Date -Year 2017 -Month 1 -Day 1 -Hour 0 -Minute 0 -Format g)

This will set the set the VersionList to MyVertical1.1, Clear the modified flag and set the date to January 1st, 2017 at midnight. You can write dates in many ways, but this one is pretty safe no matter what your regional setting might be in regards to Date and Time.

Many using source code control of some kind clear the object properties before putting the code in to the source control system including myself. Here is an example of how you can clear your object properties from one or more objects.

Set-NAVApplicationObjectProperty -TargetC:\temp\NA2013R2CU9\COD2.TXT -VersionListProperty “” -ModifiedProperty No -DateTimeProperty (”)

This commandlet will clear all Object Properties in the objects identified by the Target. (A special thanks to Bas Graaf for the clue to clearing the DateTimeProperty).

 

Split and Join Application Object with PowerShell in Cumulative Update 9 for Microsoft Dynamics NAV 2013

Yesterday I wrote about the new Merging abilities in Cumulative Update 9.

Today I want to take a little time and dive into the 2 first cmdlets: Split-NAVApplicationObjectFile and Join-NAVApplicationObjectFile.

Split-NAVApplicationObjectFile

This cmdlet let you split a text file with NAV objects into individual files. One file for each object.

Let’s first look at the syntax

Split-NAVApplicationObjectFile [-Source] <String> [[-Destination] <String>] [-Force] [-PassThru] [-PreserveFormatting] [-Confirm] [-WhatIf] [<CommonParameters>]
-Source: The <String> after the Source points to the source file from which you are reading the NAV Object file you want to split into multiple Object files

An example could be C:\temp\AllObjects.txt

-Destination: The <String> after the Destination points to the folder where we want the individual object files written to.

An example could be: c:\temp\Destination\

-Force This is a SwitchParameter that instructs the command to overwrite any existing files in the Destination folder. Generally I would recommend you don’t turn this one on, but make sure you destination folder is empty before using cmdlet.
-PassThru The PassThru is another SwitchParameter that instructs the command to return file info for all the files created. Default it will only return a list of files if this SwitchParameter is not set.

 

The file info includes information such as Mode, Date, Time, Length (File Size in Bytes).

-PreserveFormating This is an interesting one. Because the tool knows the object model of Dynamics NAV it reads the object and recreates it based on the object model when it writes it back to the system. This could cause minor changes to happen.

 

If you want to avoid that you need to set this SwitchParameter which secures the output is exactly the same as the original.

-Confirm If set you will get a prompt before the command is run.
-WhatIf Interesting one. If set this shows you what would happen if the cmdlet was run, but it is actually not running it.
-CommonParameters The CommonParameters are things that are not specific to this cmdlet. I will touch on that later.

Examples:

Split-NAVApplicationObjectFile -Source C:\temp\AllObjects.txt -Destination C:\temp\Destination\

This does a plain Split of the object into individual files.

Split-NAVApplicationObjectFile -Source C:\temp\AllObjects.txt -Destination C:\temp\Destination\ -PassThru

By adding the PassThru the cmdlet will return file info on all the files it created.

 

Join- NAVApplicationObjectFile

This cmdlet let you join a set of application objects stored in individual text files into one text file.

What is the syntax:

Join-NAVApplicationObjectFile [-Source] <String> [-Destination] <String> [-Force] [-Confirm] [-WhatIf] [<CommonParameters>]

 

-Source: The <String> after the Source points to the source folder from which you are reading the individual NAV Object files you want to join into a single object file.

An example could be C:\temp\source\ or you can filter it like this C:\temp\source\COD*.TXT

-Destination: The <String> after the Destination points to the file you want created containing all the objects you have selected to join.

An example could be:c:\temp\Destination\AllObjects.txt

-Force This is a SwitchParameter that instructs the command to overwrite any existing file in the Destination file position. Generally I would recommend you don’t turn this one on, but make sure you destination file has been deleted before using cmdlet, however this if far less dangerous then in the case of the split where you risk having objects files from different solutions mixed in the destination folder.
-Confirm If set you will get a prompt before the command is run.
-WhatIf Interesting one. If set this shows you what would happen if the cmdlet was run, but it is actually not running it.
-CommonParameters The CommonParameters are things that are not specific to this cmdlet. I will touch on that later.

Examples:

Join-NAVApplicationObjectFile -Source C:\temp\Source\ -Destination C:\temp\All.txt

This will just join the files with the default settings. One interesting think here is that the default setting here is to show the file info while you need to request that with the PassThru SwitchParameter when splitting. There is no possibility to turn that off.

Join-NAVApplicationObjectFile -Source C:\temp\Source\ -Destination C:\temp\All.txt -Force -Verbose

Here we have added Force to ensure we overwrite any existing destination file and we have also added a common parameter called Verbose which outputs information about what is happening as the process is running.

Join-NAVApplicationObjectFile -Source C:\temp\Source\TAB*.TXT -Destination C:\temp\All.txt -Force -Verbose

Here we have added filtering to the Source so we are only reading the Tables from the Source folder.

Common Parameters

I promised to return to Common Parameters and explain, but then I found a great article on technet explaining them all.

http://technet.microsoft.com/en-us/library/hh847884.aspx

This is a great read and I would encourage you all to check it out if you are interested in PowerShell.

Merging Application Objects with PowerShell in Cumulative Update 9 for Microsoft Dynamics NAV 2013 R2

Did you all see the newest addition to the Dynamics NAV family?

With the release of Cumulative Update 9 for Dynamics NAV 2013 R2 an entire new set of tools came out. These tools are all about merging of your objects. As many of you know I am a big advocate for Team Foundation Server for both Source Code Control and management of Product Development, so my first thought is: “How does this fit into my current setup?

The answer is simple: “The tools fit just perfect.

For those of you that remember far enough back in time many, attempts have been made to merge NAV efficiently by Microsoft/Navision. Back in time we had NDT (Navision Development Tool) yes it was not a success to say the least. Many have used tools like WinMerge, Araxis, and many others for doing pure text based merges. This is also what is standard in Team Foundation Server/Visual Studio. None where a huge success because none of them understand the Dynamics NAV object model or syntax, but they still made it work. Then of course we haveMergeTool which without a doubt has been the most successful tool of them all.

Microsoft is back…

With this new set of tools Microsoft is back in the game of creating tools to help the Microsoft Dynamics NAV partner channel creating outstanding and upgradable products. The biggest difference between all pasts and current attempt is that this tool understands the Dynamics NAV object model and syntax which opens up a range of possibilities we never could have dream of in the past.

So how does it work and how good is it?

Let’s look at what is included in and how it works.

File naming

First we need to understand what basis the tools works on. Yes the tools work on text based version of the object of course. No fob files here. Any type of merge needs a certain amount of human interaction and as binary (such as fob files) is pretty hard to read (yes that was a little bit of sarcasm) the better option is text based files.

The file naming from all output from these tools is pretty simple. The first 3 letters in the Object Type in upper case than the number followed by “.TXT” in uppercase. In other words Codeunit 1 is COD1.TXT, Table 15 is TAB15.TXT, Page 5050 is PAG5050.TXT and so on. If you don’t use this naming conversion today you should consider making a change unless you want to develop & run some renaming scripts in all future.

We can discuss the naming to death and I am sure people will complain, but just get on board. This is just a standard going forward and why should we not all follow the same standard?

Split & Join

The first 2 PowerShell cmdlets I am going to look at are Split-NAVApplicationObjectFile and Join-NAVApplicationObjectFile. Yes you properly guessed it. The 2 cmdlets are meant to split a text file export of NAV object into individual files or Join them back together.

Why is this important and a logic thing to do?

Well if you are doing any kind of Source Code Management you will need to have the individual objects on their own, so you can see the difference from check-in to check-in and between versions. This is just what Source Code Control systems do.

If you don’t, but want to know more about Source Code Management I would suggest you watch my 3 videos that introduce the cloud version of Team Foundation Server to any NAV developer. You can find them here:http://www.youtube.com/user/SorenKlemmensen/videos

When you split a file I always recommend that you strip it of the object properties as they have no value as part of a merge or a source code control system. These tools give you complete control of this which is a great improvement for developers.

Compare, Update & Merge

The 3 next cmdlets to look at are Compare-NAVApplicationObject, Update-NAVApplicationObject and Merge-NAVApplicationObject.

Compare-NAVApplicationObject looks at 2 sets of application objects and creates a set of delta files of the differences. One file per object that has differences. It can be very interesting to look at and will in many cases give you a good idea of the workload it will take to do the upgrade.

Update-NAVApplicationObject takes the set of delta files created by Compare-NAVApplicationObject and applies it to another version of objects. So basically it updates a new set of files with the changes found by the Compare-NAVApplicationObjects

Merge-NAVApplicationObject does the Compare and update in one command.

Both Update and Merge creates a set of files with merged objects. Any Conflicts are identified in conflict files with extension “.CONFLICT” which makes them easy to find and view in file explorer. It also gives us a wide range of options for getting the issues fixed by a distributed group of developers as these conflicts can be checked in to source control and assigned to individuals for resolution if that is what it calls for.

All of the commands above can take object input from a folder full of individual object or from a single file containing multiple objects. The tools don’t care but will always deliver the result in a folder as individual objects.

Get and Set Object Properties

The last 2 cmdlets are Get-NAVApplicationObejctProperty and Set-NAVApplicationObjectProperty and yes they are meant to get and set the individual objects Properties such as VersionList, Modified, Date and Time.

I always recommend that you don’t have or track the Object Properties in your source code control system. If you are building a product the only time you need to know the VersionList is if you run a build (and that can be discussed) or if you create a new version for release. In your daily work the developers don’t care and don’t need to know Date, Time, Modified and VersionList. They are just distractions that give them false differences when they compare and look for changes in the source code control system such as Team Foundation Server. The only thing the developers need to know is what version of the Source Code they are currently working on which in the world of Team Foundation Server means what ChangeSet are they currently on.

Conclusions

I have tested the tools and they are very fast. Full merges take minutes instead of hours. The conflicts are few and far between. The tools really have a great logic as to what needs to go where. What is more impressive is that many of the issues that typically killed you when you did merges before are now made easy. Dealing with Control ID issues. Who has not been pulling his hair trying to get that resolved and the files imported? Issues like splitting the object into individual files, which is a must if you want to do source code control, is now a standard tool in PowerShell and not a 3rd party tool, like the vb script I have shared on my blog ,which again is just one of many others.

If you are serious about development and Source Code Control this tool is a huge step forward not only for the partners that are creating repeatable software, but for the entire partner channel.

You can read much more about the tools on the Microsoft Dynamics NAV Team Blog.

Cumulative Updates for Microsoft Dynamics NAV – July 2014

The July Release of Cumulative updates are out

Cumulative Update 9 Released for Microsoft Dynamics NAV 2013 R2

You can get it from KB​2977473

You can find an overview of the Platform Hotfixes here and Application Hotfixes here.

Cumulative Update 16 for Microsoft Dynamics NAV 2013

You can get it from KB2977472​

You can find an overview of the Platform Hotfixes here and Application Hotfixes here.

Microsoft Patnersource Access required.

Indenting multiple lines of code

A feature we have had in the development environment for a while now is the ability to indent multiple lines of code at once instead of one line at a time.

Generally it is recommended we try and keep your functions small and well structured (under 20 lines of code where possible), but this is still extremely handy when you are writing or restructuring code. Indenting 20 lines takes about 80 key strokes if you do them one at a time and only indent those 2 spaces.

From time to time I notice that some developers are unaware of the feature, so here is a little short blog on how it works.

If you have a few lines of code you would like to indent you can mark them by holding the <shift> down and pushing <Arrow up> or <Arrow down>

Now if you click TAB the codes indents in increments of 2 spaces from the left edge.

And you can click SHIFT + TAB to move the code to the left. Left is done 1 space at a time.

Enjoy.

 

Importing and Exporting NAVData via PowerShell

In my last post I talked about the new export and import features included in Cumulative Update 8 for Microsoft Dynamics NAV 2013 R2, but I did not touch much on the 3 new PowerShell commands that comes with them.

Once you start PowerShell from the menu item installed with the application Type “help Export-NAVData” to get the syntax for the new command Export-NAVData.

So the first question is why there are 4 syntaxes and not just one. Well first you can make the export through the Microsoft Dynamics Server Instance or directly by connecting to the SQL database. Secondly you can be running Multi-tenant or not.

Single Tenant Multi Tenant
Directly to Microsoft SQL Server Database Use Syntax 1 Use Syntax 2
Through Microsoft Dynamics NAV Server Use Syntax 3 Use Syntax 4

 

So why would you need to go directly to SQL you might ask? I mean if you do it from the windows client or via the 2 new commands in C/SIDE you are obviously doing this through the NAV Server and not going directly to the SQL Server. Well one clear case where this could or would be handy would be cases where a tenant in a multi-tenant environment no longer can be mounted because of some issue.

This way you can regain access and figure out what the issues are and get the tenant back online.

Let’s try it out.

Here I am executing a command to export from the database called W12013R2 on my SQL server called SOREN01. I am exporting all companies to a file my.navdata on the temp folder on my C drive.

A process indicator looking like this will be shown while the export is running.

Now you can include the Application, Application Data and Global Data, by adding the optional parameters IncludeApplication, IncludeApplicationData & IncludeGlobalData as seen here

If you have a navdata file and you want to see what is in it you can use the 2ndnew command called Get-NAVDataFile.

Now exporting would not make sense without an import and there we have the last of the 3 new commands Import-NAVData. Let’s try to import this navdata file we just created into an empty database.

First I created a new database on my server called NewDatabase. Secondly I execute the import with the following syntax to rebuild my database from the navdata file.

In my case it asks me if I really want to overwrite and I said yes.

All I need to do now is setup a NAV Server instance and I am good to access my new database.

PowerShell rocks.

 

The FBK Replacement has arrived

I thought I would draw some attention to Cumulative Update 8 for Dynamics NAV 2013R2 and a new feature added. The update includes a replacement for fbk files also known as the old Backup/Restore Functionality many have been missing.

First of all calling it a Backup/Restore functionality is a little much. It is not meant to be used to take backups or do restores. Backup and Restores should be done via SQL ONLY. A place where this would be great to use would be cases where you have a bug and you need to quickly grab the data to reproduce and/or debug at a later point.

Taking a copy of your data and or your objects don’t guarantee that you can restore them in a live environment is one thing and the other is that SQL is far better to ensure you never lose your entire database.

So how does it work?

In the menu in General under Departments => Administration => IT Administration you will find 2 new options “Import From Data File” and “Export To a Data File”.

Selecting the Export we get a page that hopefully feels very much like the options we use to have.

I am not going to explain the fields here as I am sure you all know them and if not check out the online help.

Once filled out just push OK and the common dialog pops up.

Notice the new extension “*.navdata”. This is a new file format, so no going back or using the old files.

The import looks pretty much the same and again no big surprises here.

So what is new? First of all 2 new Pages where added 9900 Import Data and 9901 Export Data, but also 2 new commands that you can find used in the these 2 Pages.

EXPORTDATA and IMPORTDATA. These command now gives you access to import and export navdata files via code.

While I was writing this I just noticed that a blog post was posted on the Microsoft Dynamics NAV Team Blog this morning with a lot of great details on this including the fact that this can be executed via PowerShell of course. Please read “Importing and Exporting Data in Microsoft Dynamics NAV 2013 R2 CU 8” with all the details.

 

 

Cumulative Updates for Microsoft Dynamics NAV – June 2014

The June release of Cummulative updates are out.

Cumulative Update 8 Released for Microsoft Dynamics NAV 2013 R2.

You can find an overview of the Platform Hotfixes here and Application Hotfixeshere.

Cumulative Update 15 for Microsoft Dynamics NAV 2013.

You can find an overview of the Platform Hotfixes here and Application Hotfixeshere.

Microsoft Partnersource access required.