On Harleys, mad gods and Dynamics NAV

I could have named this blog post Living with extensions in a hybrid Dynamics NAV database. The title I went with is far cooler though. And since I write this stuff mostly for my own enjoyment you get stuck with the cool title.

You see, a little over a year ago I traded in my trusty old bike for a Harley Davidson. It is an awesome bike. Riding it feels like having the mad god of Milwaukee steel shred the fabric of reality and smash you face first through the black hole thus created. I love it and until I can buy the flying steam train out of Back to the Future it is my preferred mode of transport.

It did create a bit of a problem though. I had wrenched on my old bike for years. I knew it inside out, and my thirty year old metric spanners worked perfectly well on it.

Harley Davidson though does not do metric though. Metric tools lack something undefined. They are perhaps too refined for something as cool as a Harley. So I had to get a whole new set of inch sized tools. And that is not the only difference. There is a whole different planet of aftermarket parts for Harleys. I had to find out where to get the stuff I needed to do a simple oil change. It was infuriating.

But I guess that is change. More than a year later I still can’t guess if I need a 1/2 or 9/16th inch wrench but mostly I am happy on planet Harley.

And that brings us back to Dynamics NAV. Or Business Central or whatever you want to call it. Our environment has changed. We have had a major change in the way we work and we are still trying to make sense of it. Sometimes it feels as if the not so mad god of Danish sensibility has left us to an uncertain world of extensions, API’s and all sorts of other things that we can’t make head or tail of.

Where I work (a Dynamics NAV end user) we decided to upgrade to Dynamics NAV 2018 and start working with extensions. And, as I learned to live with Imperial wrenches I am also learning to live with AL and Visual Studio Code. Mostly I like it. Not as much as C# but definitely more than C/AL. The biggest problems we experience are due to the fact that we are in an in between period. We are forever generating symbols because we still need to develop in C/Side. We are creating events in custom code in standard objects because we need to move on and develop new things. I still have doubts about how easy the upgrades will be when Microsoft decides to change the events we use. But upgrading will be easier, no doubt about that.

So basically what I want to say with this blog is this. Cheer up. Change is hard. It is inevitable but it sucks. It creates great opportunities and even bigger pains in the backside. But from where I stand we are going to a good place.

With extensions you can do everything you should do. The rest you should leave alone even in C/Side.

How does that good place look? Dynamics NAV (or Business Central if you must) systems with as little modification as we can get away with. Just customized enough to give our customers or employers a competitive edge. Connected to great server based web applications through API’s. Using machine learning to help our users make sense of the masses of data we create. And think of Azure functions. Great ways of decentralizing business logic and ensuring similar execution across several platforms.

So the future looks good. As long as we develop ourselves to be something more than Navision developers. Change is hard. But, as 15 months of riding a Harley Davidson taught me, change is also good.

And so I hoist my glass to the mad god of change. May we live in interesting times.

Before you move on there is one thing I want to point out. I am independent. I have zero desire to ever become a MVP. It is a great award and I am grateful to all MVP’s for sharing their knowledge but it is not for me. There is no advertising here because I value my independence much more than the €4 per month WordPress charges me for removing the ads. The only reason I write this is because I enjoy writing it. If anyone disagrees with my opinions then that is fine. This is my view.

Absorb what is useful. Discard what is not. Add what is uniquely your own. Bruce Lee

 

Why I named my company after Papa Smurf.

I have written a fair amount of blog posts so far but I realized today I had been remiss in explaining the name I chose for my business. Red and Bundle, what is that all about people ask me.

When I tell them I named my business after Papa Smurf their bewilderment only grows. To explain all this I have to take you back in time with me. To a place where life was not very different than it is now. But I was younger. About eight or nine years old in fact.

We were visiting my grandparents and my granddad let us watch the Smurfs. The particular episode was called The time capsule. It had druids and magic in it so naturally I thought it was excellent. In the period when everything looked bleak the smurfs had to solve a riddle.

“A twig by itself is too weak; it’s twigs in a bundle you seek.”

And for some reason that single line stuck with me in the back of my head for thirty years. A bit like a time capsule.

Explaining the riddle to the smurfs Papa Smurf said it is about working together. One Smurf alone cannot possibly win this.

To me that is the epitome of a great leader. To recognize that you cannot do this alone, to recognize that the people you work with have their own skills and contributions to make. And to help those people to become the best versions of themselves. To realize that Brainy, Hefty, Handy, and even Clumsy are geniuses in their own right. And to coach and guide people so the sum becomes greater than the parts.

So that is the role I decided I want to fulfill. To work with my clients to make the best of the people, software, and organizations I work with. Red and Bundle means that while we as IT specialists sometimes seem to be practicing magic we cannot save the world all by ourselves. If we want to overcome obstacles we have to work together.

Papa Smurf knows all this. He knows that each and every Smurf has their own nature and their own genius. Even if they drive him bonkers every episode. Because without them he would just be a lonely old Smurf.

Image found here.

Get server and database information in AL

Today I wanted to get some basic information about my NAV2018 service and database name in my extension. A quick Google found a lot of useful stuff about this but nothing that was easy enough for me. I really did not want to go messing about with xml or dotNET. This is basic stuff right? There has to be a simple way. And then my eye was drawn to my system indicator, what I want is right there on the screen.

So I started having a look in table 79, Company Information, and there was the gem I needed:

ActiveSessions

But can I use it in VS Code? Well, it turn out that you can:

ActiveSession-AL

So, for me the Active Session table works perfectly. It does not show you the database server though.

ActiveSession

Many thanks to the people who wrote about this before me:

https://www.kauffmann.nl/2015/04/07/read-server-settings-from-cal-code/
https://community.dynamics.com/nav/f/34/p/141286/831849#831849
http://www.dynamics.is/?p=541

Three ways to use extension data in C/Side

So, I get it now. We need to develop in extensions. Nothing but extensions. We need to tell our employers to forget about new requirements for half a year and ignore bugs while we developers lock ourselves in the basement and rework our existing code to an extension. Right?

Well, locking developers in a basement will probably appeal to a fair number of managers. Not developing new requirements or fixing bugs for said amount of time will definitely not. Like it or not, many of us face working with hybrid systems.

Where I work we now have extensions in a heavily modified C/Side code base. So when my Colleague phoned me a while back to ask me how in hell he could get a field from our extension onto a C/Side report I had to put my thinking cap on.

So far I came up with three workable methods of getting extension data into C/Side.

For demo purposes I created a simple extension that adds a Box Number field to the Posted Sales Shipment Header (110):

TEX50100

And adds in on the Posted Sales Shipments page (142):

PEX50100

So, I now have a Box No. field on my Posted Sales Shipments. How do I use it in C/Side?

Method 1

Create an eventpublisher in a C/Side Codeunit or Report and subscribe to it in the extension:

COD50208

COD50100

Now for example add a button on the Posted Sales Shipments Page that calls the Codeunit:

PAG142

And there you go:

MsgBoxFromEvent

Big downside here of course is that you have to generate symbols. Which is a right royal pain in the backside. So, without symbols and events?

Method 2.

Thanks to some old colleagues I have a pretty good working knowledge of RecordRefs and FieldRefs. So, can I use those?

COD50208-FieldRef

And again a call from page 142:

PAG142-FieldRef

And::: (drum-roll please)

MsgBoxFromFieldRef

So, well, that was, well, easy. Of course you would need to add a few checks to see if the field exists. Just in case someone uninstalls your extension.

Method 3.

Have I mentioned it gets easier? Well, I have been working with the great people at ForNAV for a while now. Since they use the fields web service to determine the Dynamics NAV data set perhaps the ForNAV designer can see the extension field without mucking about in hyperspace C/Side. So I converted report 208 to ForNAV and opened the designer:

BoxNoInForNAV

So, there it is. I added the BoxNo field to the report and when printing this is the result:

REP50208-ForNAVResult

Final notes

Thanks for reading this far. If you have anything to add or know of a better way please let me know. Of course all the objects and the extension are found on GitHub. All objects are provided without warranty. Try them at your own risk.

Full disclosure, ForNAV do pay me to do webinars and other stuff. I love the product because it is awesome. That is why I write about it. Try it, you will not be disappointed.

Confession day, I messed up our extension

Those of you that know me will know that I started working on extensions pretty soon after we upgraded to Dynamics NAV 2018. That has led to a recent go-live of our first two extensions. One is a smaller one, the second is pretty sizeable and has to do with paperless order picking and automatically printing packing slips and address stickers from our new packing machine.

Now during the development phase I messed up. And as I believe in owning my mistakes I will share this with you all.

What nobody told us when we started development is that once your extension is in production fields in tables and table-extensions cannot be changed. At least, not without uninstalling the extension and deleting all data in the entire extension. And deleting all the data in this extension is not going to make our  warehouse manager very happy. At all.

And yes, I do know about upgrade codeunits and yes, I do know I can create a new field and make the old one obsolete. Only, there was no data in this table yet. So there was nothing to upgrade. I just wanted to change the order of my fields.

So, what happened? After the go-live of the first version I started development on the interfacing between the PLC of our packing machine and Dynamics NAV. A fun job for which I required a new table. Now during development this table was somehow taken into production after a bug fix. A simple mistake that can happen. But what happened then is that I changed the fields in the table. Not a problem in Dev and Test as there is no data. But when I wanted to go to production all hell broke loose. Fortunately for me it was a simple table and with some minor changes we went live anyway. But those fields I wanted to change will bother me forever now.

So, lessons learned. First, beware of what goes to production. It is easy to build the wrong version of an extension.

Second, create small extensions with dependencies. Plan and design well.

Third, don’t break API. Wait, what? API? I just changed a table. Well, in our brave new world a table is an API as other developers can subscribe to events in your extension. And the first rule of creating API’s is that you do not break them. Ever.

And that raises a pretty serious question. We are all happily subscribing to events in Standard Dynamics NAV. Or DYN365BC or whatever the marketing demons want to call it these days. What if Microsoft breaks their own API? We all know how easy it is to change a codeunit right? Bye bye easy upgrade.

Food for thought.

In the meantime, feel free to make fun of me. But please learn from my errors.

Some further reading:

https://github.com/Microsoft/AL/issues/1499
https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
Photo by chuttersnap on Unsplash

Options and the agony of choice

Choice is agony. How do you discard a whole world of possibility and settle for a single option?

The other hard thing about options is how to program the buggers in AL… After finding precisely zero results on Google (I’m sure there is something to be found, I just lack the patience to find it) I decided to share my findings here.

To add a field of type option

Options field

And to use an option as a variable:

Options var

So there you go, the agony of choice now lies with your users. Where it should be.