Microsoft 365 Business Central

For about a year now, we have been talking about “Tenerife”. Despite going to great lengths to calm down the partner channel, the name and what it stood for has caused massive misunderstandings and great anxiety. Hopefully that anxiety will come to an end because today the new name has been announced: Microsoft Dynamics 365 Business Central (click here for the announcement and click here for the overview page). A catchy, easy-to-pronounce, 14 syllable name, and it is scheduled to be released on April 2, 2018.

I just wanted to put this out there, and I don’t have a ton of things to say right now, but watch this space for much more stuff to come. This week is Directions Asia in Bangkok, and there will be plenty of information coming out of that event. With the release of the new product there will be some new requirements for partners to get their IP into AppSource, and I will have plenty of things to share about that. Microsoft is working incredibly hard on getting all the information out there, including new material in the learning portal (the link that I had wasn’t working when I wrote this, so I owe you that one) and a ton of new and updated content in the new technical documentation site called ‘docs’.

I am in a very fortunate position to be involved in the very early stages of Business Central, I’ve had the pleasure to be working with the new product for a while now. I have to say I was skeptical of the Web Client and having everything in the cloud, but as I’ve gotten used to how it all works, and how the new ecosystem is forcing to improve our internal processes, I can’t help but be happy about the way that my industry is taking me into a more professional approach to my business. No longer do we get away with flying by the seat of our pants, and do whatever we can get out there in a short term, quick and dirty way. We must adapt and get ALL of our ducks in a row. Our approach to design, architecture, coding, marketing, delivery, automated testing, EVERYTHING must be in top shape in order to be successful in the new age.

This is the time where you have to adapt, or be disrupted. For me personally, it scares the heck out of me, but I also welcome the challenge. I am looking forward to what is to come next, I hope you are too.

Install from .vsix

This is a quick blog about installing the AL language for Visual Studio Code from a .vsix file.

When you create a developer preview Azure VM for AL development, you get a landing page to access this VM. The script that creates this VM will put all the components on the VM that you need to do your development, including the correct version of the AL Language extension for VS Code.

If you want to do your development locally, you will need to put the right version of the AL Language extension on your local installation of VS Code. Lucky for you, there is a link on the landing page for your VM that will download the installation package into your downloads folder. The file has the extension .vsix, which is what VS Code needs.

All you need to do is press Ctrl+Shift+P and type ‘vsix’ in the command palette, and VS Code will suggest ‘Extensions: Install from vsix…’. When you select this, you need to browse to the file, and hit the ‘Install’ button. If you already have another version of the AL Language installed, you’ll need to disable that, so that there is no confusion about which one VSCode uses.

Keep Your Data When Developing

One of the most frequent questions I get in our workshops is how can I keep my test data when I am developing in AL. For this, Microsoft has given us a new property that you can set in launch.json, read on to learn the details :).

Up until now, every time you hit F5 in AL to test your app, you have to start from scratch to enter some test data, of put together some data creation code in an install codeunit to populate your tables automatically. The reason is that the default behavior of the AL Language extension was to completely recreate and rebuild the app, every time you hit F5. This means that behind the scenes, your current installed version is completely destroyed, and then VSCode recreates the .app file and publishes/installs the app for you. As a consequence all the test data goes kerblammo, and you are stuck having to enter all the test data again. Not a big deal if it’s a setting or two, but if you added some fields to an existing table that you need some values in, and you need some data in your custom tables, it can get very tedious very quickly.

Microsoft has given us a new property called ‘schemaUpdateMode’ that goes into launch.json. If you leave this property out, the default behavior stays the same, so it recreates the app every time you hit F5. You can of course also add the property and set it to “Recreate” just to make sure. If you want to keep your data though, you can set it to “Synchronize”, which will keep your data intact.

Be aware that if you increase your app version, you will also need to use Powershell to Synch and run the data upgrade.

I Made It

For a while I wasn’t sure if I should write about this. I’m still not sure if it’s a good idea to share something this personal. Take a look at that picture, it is me playing golf with a friend in Tucson, AZ on Saturday July 23, 2016. I just striped a perfect drive right down the center of the fairway (all of 225 yards of it, I’m not very long). After this round of golf we’d meet up with our wives for lunch, we’d go see the new Star Wars movie, and we’d spend the rest of the day having a good time all around. Little did I know that my life is about to take a decidedly dark turn.

As the evening progressed, I gradually started feeling worse and worse. My heart started racing, and pain was starting to grow in my chest, neck and arms. On our way back to our hotel, I could not get my heart under control, and I started to panic. My wife decided that something was very wrong and she took me to the ER. To make a very long story short: I was having a heart attack.

If not for my wife, I would have gone back to my hotel room to lay down and wait for it to pass. I would have maybe fallen asleep and never woken up again. If not for her quick thinking, and the fact that we were 4 minutes away from the ER, I would not be writing this now. Over the next couple of days, I received a few stents to unblock my coronary arteries and I was sent home with a prescription for a bunch of medications.

Pretty much immediately after coming back home I went to a VERY dark place. I’ve turned into an extremely emotional person, and my mood can swing on a dime. Out of nowhere, with no discernible rhyme or reason, I’d just start sobbing uncontrollably. I’d talk to someone about what had happened, and I would have to excuse myself to not break down. I’ve discovered that I have wonderful friends who have supported me, which in itself is something that makes me emotional just thinking about it. Accepting that I have a heart disease is one of the most difficult things I’ve had to do in my life.

Now that I am writing about it, I feel like writing the whole story down, but I also realize that it’s probably too much for a single post. What I do want to put down here is that I was SO lucky to get away with this. It has turned my whole world upside down, and I’ve made some big changes in my life. If nothing else, it has helped me be in the present more than dwelling on the past or fretting about the future. I’ve learned not to give a f*ck, well maybe much less of one because I’m still the same person who cares too damn much about pretty much everything.

I’ve been thinking about writing posts about health and wellness, because many of us in our industry are on a decidedly unhealthy life style. I see so many people who I know could be next. I talk about the changes that I’ve made to anyone who wants to hear about it, and because it’s considered to be rude to confront someone’s eating habits directly to them (also a lesson learned this year) I feel like maybe sharing this here could be a good thing. Let me know in the comments what you think about it.

The oppressive terror that I’ve felt for the better part of this past year has subsided, and replaced with a more manageable sense of doom. The way this is going I may end up actually overcoming my fear altogether, which probably has its upside and also its downside. It would be nice not to be afraid, but if I’m not afraid I don’t know if I’ll be able to maintain my healthy lifestyle.

So, on the 1st year anniversary of my heart attack, I just want to say I am super happy that I made it! A whole year! On to the next half of my life!

Registered for NAV Techdays 2017

It’s that time of the year. The official announcement came in on Twitter that registration is open for NAV Techdays 2017, which is again held in Antwerp of course. The official two day conference is 16 and 17 November, but I consider the pre-conference workshops to be part of the event, so a full 4 days of deep technical knowledge sharing.

The session schedule has not been published, but we do know the pre-conference content, go take a look at the Sessions page to check out what is available to you. The familiar sessions will cover PowerShell by Waldo, JavaScript by Vjeko, automated testing by Luc van Vugt, SQL Server performance by Jörg, and of course the 2 day design patterns class by Mark. The new topics include how to SaaSify your software architecture, how to use Visual Studio Code (it is very important to learn about this one) and how to develop extensions with it by Arend-Jan. Another exciting one is the SCM workshop by Sören, he will show you how to make it work directly in VSCode.

Only a few regular sessions have been announced (some fantastic content by our friends at Microsoft), but I have a feeling that we will see a super deep dive into all things related to Dynamics 365. I cannot wait to go to Antwerp, and I hope to see you there.

Localize Objects with PowerShell and VSCode

In this article I will explain how you can use PowerShell to extract the right objects and merge those objects, and how to use Visual Studio Code to resolve most of the conflicts in the merged objects.

In a previous article, I explained how you can use PowerShell to create the environments. The script in this article actually use the variables that are assigned in the other one. What I should really do is create a configuration file and load that from both scripts. I wanted to share what I have so far though, without a handy configuration file but hopefully helpful nonetheless.

We start off with the 4 environments that were created in our last article: ORIGINAL, MODIFIED, TARGET, and RESULT. The first two environments contain the standard W1 and the ISV product. Target and RESULT are identical at this point, and they both contain the standard NA localization. All environments are in the same build number (NAV 2017 CU2 in this case). Because I have a developer license that has insert rights in the ISV number range, my strategy is to merge the product modifications into the NA database. If you do not have those insert rights, then a better strategy would be to merge the NA localization into the product environment instead. Microsoft has recently added insert capabilities for the standard object ranges to regular developer licenses, for this particular purpose. As I was working through the conflict objects of this assignment, I was thinking that this may even be the best default strategy anyway.

Due to a limited amount of time, and a limited amount of PowerShell skill, I decided to approach this task pragmatically:

  • Manually move the ISV specific objects to the RESULT environment
  • Use PowerShell to export all the objects
  • Manually eliminate the unmodified objects
    • NOTE: as I learned later, Waldo’s PowerShell modules actually have logic to remove these after the merge, so this can be scripted as well
  • Use PowerShell to merge the objects
  • Use Visual Studio Code (AKA VSCode) to resolve the conflicts as much as possible
  • Use PowerShell to join the objects
  • Use C/SIDE to resolve any remaining conflicts

The conflict resolution is something that has to be done manually. Everything else can be scripted in PowerShell. During this process I’ve asked Waldo for some help, and he explained that most of what I am doing here is already part of the merge sample scripts. In the Cloud Ready Software PowerShell module, there is a folder called “PSScripts”, and in that folder you will find a large number of scripts that you can use as an example to get started on your task. As you gain experience in using PowerShell, you will recognize a lot of useful features in those scripts, and you can modify them to your specific needs.

Alright, on to the details. The first part is to use PowerShell to extract the objects into their own folders. I also added commands to create the folder structure itself:

At this point, you will have an “Objects” folder in your working folder, with full object files for ORIGINAL, MODIFIED, and TARGET. Those object files have then been split into individual object files in the ORIGINAL, MODIFIED, and TARGET folders. Before using PowerShell to merge those objects, I used a text compare tool (I like Scooter Software’s Beyond Compare) to eliminate unmodified objects. Remember, I only want to work on the modified objects, so I don’t have to worry about getting confused by objects that were not changed for the ISV product.

Now that we only have modified objects in all three object folders, we’ll use the merge Cmdlet to do the actual merging of the objects.

If you notice, the output of the “Merge-NAVApplicationObject” Cmdlet is loaded into the variable “$MergeResult”. This object is then piped into the “Merge-NAVApplicationObjectProperty” Cmdlet. The first Cmdlet is a standard NAV PowerShell Cmdlet, and the second one comes with the Cloud Ready Software modules. The standard merge Cmdlet does not merge the Version List property, it simply takes the Version List from one of the three environments. We can have a discussion about whether the Version List is even important anymore, especially if you use Source Code Management. The reality is that most NAV developers depend on proper tags in the Version List, so it is useful to merge those as well. All you need to do is specify the prefixes that you want to merge (In my case NAVW1 and NAVNA) and it will find the highest value for those prefixes. All other prefixes will be simply copied into the RESULT objects.

At this point, we have all merged files in the RESULT folder. This includes the objects that were merged successfully, but also the objects that the merge Cmdlet could not resolve, for instance when code was added at the same position in MODIFIED and in TARGET. Since we are going to have to learn how to use VSCode, I decided to use that to resolve the conflicts.

With VSCode installed, you can open the RESULT folder and see the content of this folder inside the file browser at the left hand side. In the upper right hand corner is a button that you can use to split the screen into two (and even three) editor windows. This is very useful for resolving merge conflicts, because you can open the conflict file in one side, and the object file in the other side. You are editing the actual object file here, so you may want to take a backup copy of the folder before you get started.

Now what you must understand is that the conflict files only contains the pieces that the merge Cmdlet could not figure out. In a total of 860 objects, with 6956 individual changes, it was able to merge 96.4% of those changes. An object that may have 4 conflicts can also have a ton of other changes that the merge Cmdlet merged successfully. All YOU have to do is focus on the ones that need manual attention. For instance, codeunits 80 and 90 had a TON of modifications, but it only needed help with 3 of them.

I had a total of 115 conflict files, and I could completely resolve 112 of them in VSCode. I made a note of the few that remained, and decided to import those unchanged into C/SIDE, so I can finish those off in the proper IDE.

The last PowerShell command that I used is to create a single object file, which can then be imported into C/SIDE. Then I finished the last few remaining object files, and was able to compile all objects from there.

I’ve done many of these merges completely manually. To say that I was skeptical that PowerShell would do a good job is putting it mildly. I flat out did not trust the merge Cmdlet, surely they could not do as good a job as I could do. I was wrong. I checked a bunch of objects to see if I could find any mistakes and I could not find any. Not only did the merge Cmdlet do a fine job at merging the objects, it did so in about 5 minutes flat.

You can download the scripts here.

Instead of having to manually merge almost 900 objects, all I had to do was focus on the conflicts. Usually, a vertical merge like this would take me anywhere from 2 to 4 weeks, and I was able to finish this one in less than two days. Figuring out the PowerShell scripts took me much longer, but I will be able to use those for the next merge task.

Create NAV Environment with PowerShell

If you kind of know about PowerShell, and you want to use it more, but you don’t really know where to start, then you should read on. I am going to explain to you how you can use PowerShell to create the environments that you need to localize a product.

One of the things that always seem to fall on my plate at my job is to take an ISV product and merge that into the North American localization. I call it ‘localizing a product’. It is not, because localizing a product is much more than simply merging the objects, but it’s what you have to do first. I’ve done a bunch of these manually, and I kind of enjoy the almost mindless nature of the task of working my way through hundreds of objects (sometimes even thousands, I once ‘localized’ a product that had more objects than standard NAV itself).

This time around, I wanted to use PowerShell to automate as much as I could. Lucky for me, I attended Waldo’s “PowerShell Black Belt” workshop at NAV Techdays (read my review of this fantastic event here) and I should have all the tools to get this started.

The first thing you need is to install Waldo’s PowerShell modules, I will be using those for just about everything. I could figure out how to script all of this stuff myself, but why would I if Waldo already did that for us, and he is sharing his scripts. For instructions read Waldo’s blog here.

This post focuses on creating the environments themselves, and for this task you really need just a few things:

  • A SQL backup for the product in the W1 version of NAV, and make sure that you know exactly which build this was developed in. For instance, the product that I am working with was provided as a SQL Backup, and it was developed in NAV 2017 CU2.
  • The DVD’s for standard W1 and NA for the same NAV build.
  • A Development license that has insert rights for the product’s number range. If you only have a regular developer license, or if the ISV refuses to provide you with a license (this happens more often than not) then you will have to merge NA into the product database. This works exactly the same, you just have to figure out which environments are your ORIGINAL, MODIFIED and TARGET.

Use the NA DVD that you just downloaded and install the NA Version with a demo database. I like to give the database a meaningful name, so I called it ‘NAV2017NACU2’. This is all the manual installing that we will do, everything else is PowerShell baby! Actually, you could even use Waldo’s PowerShell modules to do the install as well. You could even write a script that downloads the DVD for you as well, all using Waldo’s PowerShell modules.

If you understand the mechanics of localizing a solution, you will know that we need 4 databases in total: standard W1, Product database in W1, standard NA, and a copy of the standard NA database that will become the product database. In this case, standard W1 is ORIGINAL; product W1 is MODIFIED; standard NA is TARGET and product NA is RESULT. This will become important when we do the merge, which will be another blog post.

Now the goal is to have a re-usable script, so we’ll use variables instead of having to re-type values multiple times, as you can see in the picture.

Remember, I installed standard NA. I created the working folder and placed the three backup files into the ‘Backups’ folder. I like to keep things together, but I can imagine having a network location for the standard backup files. The nice thing about using these variables is you can set them however you need them :). My database server is called KERPLUNK, which is just a regular unnamed instance on my VM called KERPLUNK. You could also use a demo installation and then you’d have to set it to ‘KERPLUNK\NAVDEMO’. I will use the 4 names for the database names as well as the service tier names.

The rest of the script is surprisingly simple to put together, here it is:

The reason why I start with the ‘Copy-NAVEnvironment’ step is because this script turns on port sharing for both server instances, so I don’t have to take care of that step myself. This is one of Waldo’s script that looks at the first server instance and creates a new one just like it. It creates a SQL Backup from the service instance, restores that into a new database, and finally it creates a new server instance for that new database, and it enables port sharing by default. The ‘New-NAVEnvironment’ is also one of Waldo’s scripts, and it does all the heavy lifting of restoring the database, creating the service tier and setting up port sharing. The full script took maybe 2-3 minutes to run for me, not bad for something that used to take all morning.

This same script could also be used to create your environments for developing extensions. For that you only need a standard database for ORIGINAL and a development database for MODIFIED, both of which will then be used to create the DELTA files for the extension package. If you look at the screenshot of my environment you’ll see an APPDEV and an APPTEST database. Both of these were originally created as copies of the standard database, also using PowerShell.

I’m planning to also put this into a video but I actually have this work to deliver so I’ll focus on that first. Up next is getting the objects out and comparing them to create a set of merged objects. Stay tuned!

Update 4/22/2017: added link to the new article about localizing the objects, and you can download the scripts here.

NAV codebase for Dynamics 365

Something that was kind of a big deal happened this week. During the keynote at Directions ASIA in Bangkok, Marko Perisic (General Manager, Microsoft Dynamics SMB) announced that Dynamics 365 for Financials and Dynamics NAV will operate on the same codebase.

There are two reasons why this is a big deal. First it falls right in line with Microsoft’s “AND strategy” when it comes to cloud ERP and on premise ERP. BOTH are essential to Microsoft, and BOTH will have a place in their product line. Second, and this is where NAV is kind of unique, it will allow Dynamics 365 for Financials to be “Full NAV” in the cloud. Let that sink in: Microsoft is committing to having full Dynamics NAV functionality in Dynamics 365. Whether you implement in the cloud or on premise, your ERP will operate on the same codebase. As far as I can tell, there are not many ERP products that provide this. I have a feeling that it is a trend that many will follow though.

The Dynamics 365 codebase has always been the same as NAV, but only parts of its functionality was exposed. The assumption was that the Dynamics 365 codebase could potentially diverge from the on prem version of the product, although how that would happen was not always very clear. Now that there is a firm commitment to keeping a single codebase, the next step is that Dynamics 365 will at some point provide “Full NAV” capabilities, which was in fact also part of the same keynote.

The nuts and bolts are still in progress. Dynamics 365 is updated constantly and NAV only gets monthly cumulative updates and annual version updates. There is also a lot of movement in how add-ons and customizations will be implemented, although the magic word there is “Extensions”.

For Microsoft to come out and announce the equal codebase though….. that is a Very Big Deal.

Get Started with Dynamics 365 Apps

Dynamics 365 for Financials has been out for a while, and by now you have probably learned about how the functionality can be extended rather than modified. Instead of modifying the application objects directly, development is done using “extensions”, which are published as an “App” in AppSource.

What is unclear to a lot of partners is how this works exactly. What do you need to know? What do you need to do? Where do you get the help that you need? Microsoft has put together a few resources to get you started and to get you the help that you need.

You may need a partner source login and/or an Azure account to be able to access these pages. These links won’t answer all your questions, but you should find enough information to get started. Good luck!

Webinar – Dynamics NAV Dev Tools Preview

This morning I was part of a panel to host a webinar to show the development tools preview. It was my pleasure to provide the demo part and show the attendees a taste of what is to come in the new development tools for Dynamics NAV. The demo part was just about 25 minutes, and then we opened up the floor for questions. We had some good questions, and it was a lot of fun to be able to share that with everyone.

The webinar was recorded and uploaded to YouTube, and you can watch it here. Oh, my name is not Erik Ernst, not sure how that happened 🙂