Apps, API's, Portals, Extensions and AddOns for Dynamics NAV
So today I wanted to create a simple text variable with 3 dimensions in my extension. Normally no big deal but how on earth do I define dimensions in my variables?
It turns out they are now called Arrays. So that is an improvement but the documentation is worthless. And again, nothing to be found on the old Google. So after a frustrating time of figuring stuff out here it is:
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.
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:
But can I use it in VS Code? Well, it turn out that you can:
So, for me the Active Session table works perfectly. It does not show you the database server though.
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
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):
And adds in on the Posted Sales Shipments page (142):
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:
Now for example add a button on the Posted Sales Shipments Page that calls the Codeunit:
And there you go:
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?
And again a call from page 142:
And::: (drum-roll please)
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:
So, there it is. I added the BoxNo field to the report and when printing this is the result:
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.
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
