Red and Bundle

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):

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.

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

And to use an option as a variable:

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

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

The cat, the blowfly, and the Japanese archer

The other day I was witness to something awesome. A blowfly had just entered my room and I was feeling mildly annoyed. From out of nowhere my cat came, jumped and snatched the fly from the air. My sense of awe at this feat of poetry in motion was only slightly marred by the crunching sound of said blowfly in the jaws of my cute and adorable apex predator.

It brought to mind a lecture by Alan Watts that I had been listening to a while earlier. In it he mentioned that the objective of the Zen archer is to release the arrow without thinking. The big hangup here of course is how do you purposely do something not on purpose. How do you think about not thinking?

It is like being told to be spontaneous, the ghastly results of which can be viewed on national television with jarring regularity. Anyway, for a blog supposedly about programming and other worldly ventures things have started getting far too woo-woo.

So lets bring this back to programming. Serious stuff where thinking is the norm. When we are stuck we programmers think our way out of it. Or we use Google but that is just asking their AI to think about our problem. Voracious application of our intellect will solve all our problems for us. And when we get really stuck we use the scientific method to think ourselves out of any hole.

So when stuck on a particularly difficult piece of code this is what I try. I think, I Google and I try to concentrate. And the result is a headache, time wasted and no result. I want to think up something new, I need an idea!

So let’s explore this. Alan Watts tells us that thinking hard is like straining to see an object in the distance. You frantically pull at muscles around the eyes, squinting like a madman. And it has no effect whatsoever, the eyes work best when you don’t try. Just look, your eyes will work fine. So how does it work? How do we get ideas, solve problems?

“The ultimate test is always your serenity. If you don’t have this when you start and maintain it while you’re working you’re likely to build your personal problems right into the machine itself.” Robert Pirsig.

Whether it is programming, fixing a motorcycle, or releasing an arrow, the secret is not thinking about it. And you can’t do that just like you can’t lift yourself up by your bootstraps. And if you can’t do it you might as well stop trying. And then magic happens. You give up and all of a sudden, at the weirdest time, lightning strikes. You jump from your bath running naked through the streets shouting eureka.

So cheer up. Have a coffee, have a bath. There are methods for getting out of your own way and doing more creative work. But they only work if you don’t try them.

Meanwhile my cat is lying in the sun looking smug. When she lies she lies. When she walks she walks. And when there is a blowfly she crunches.

Thanks for reading this far. If you liked this you might want to explore these sources. They helped me and were the inspiration for this blog post.

For more on Alan Watts you might try listening to this
Try reading Zen and the Art of Motorcycle Maintenance by Robert Pirsig
For some tips on getting out of your own way try listening to Josh Waitskin on the Tim Ferriss podcast
And, of course, Eureka!
Photo by Zoltan Tasi on Unsplash