Best practices

Read more about the article AL Object ID Ninja

AL Object ID Ninja

  • Reading time:9 mins read

One of the biggest obstacles to AL team development (is there any other kind?) is object IDs. IDs are supposed to be easy: just pick the next free one and off you go. AL Language even helps by suggesting the next available one through IntelliSense. But you are most likely not the only developer on your team. As soon as you add another developer to equation, and both of you use the built-in AL IntelliSense auto-suggest feature, you are inevitably heading towards object ID collision. The more developers there are, the more active your repository is, the more likely the collision.

Obviously, without some kind of a back-end that coordinates object ID assignment – preferably in real time – is absolutely necessary. And teams have come up with various solutions to this problem. They include:

  • “Who cares!”: the most heroic one, no object ID collision will ruin your day. Bring it on – you say! I’ll handle you – you say! These teams spend a lot of time resolving collisions post-factum.
  • Object “reservations”: you create an empty object of the desired type, push just that, create a PR that does nothing by that, and launch into the Hail Mary mode until your PR gets merged. The slower your validation pipeline is, the more likely it is that more than one developer will be saying their Hail Marys at the same time, and guess what – Mary will help one of them.
  • “Hey, folks”: you yell to announce to everyone that you are about to take an object ID. Or, in more advanced teams, you run a Teams team (uh, did I mention “team?”). This approach is not too robust, but generally yields better results than the above two.
  • Excel: the ways this tool gets used, geez. It’s a spreadsheet calculator, for Pete’s sake, but people have been using it for everything ranging from shopping lists to, well, object ID assignment sheets.
  • “When you have a hammer, every problem you see is a…” BC! The ways this tool gets used, too! Well, heck, yeah, isn’t it so freaking obvious that people will just create a BC app and deploy it internally so that everyone can use it. BC has nearly all facilities you need (that none of the above approaches does): primary key validation and concurrency. This is a very advanced stage in the evolution of object ID collision management solutions.
  • Automation. Yeah, baby! Now that there is a BC back end, and BC has APIs, let’s build an API that gives you next number, and then let’s do some front-end that fetches that from the back end, and then let’s somehow embed into VS Code. There is at least one tool that I know of, that does exactly this. And good that I didn’t know of it that Saturday morning nine days ago, because I would have zero motivation to take this evolution one big step further.

This is where AL Object ID Ninja joins the show! It’s zero-configuration, crazy-fast, mind-bogglingly simple solution for no-collision object ID assignment in AL. If you haven’t already (and if you are using Waldo’s AL Extension Pack, chances are you already have) go fetch yourself a copy.

Continue ReadingAL Object ID Ninja
Read more about the article Code annotations in AL – Please, don’t!

Code annotations in AL – Please, don’t!

  • Reading time:10 mins read

One of good practices of writing C/AL Code for Microsoft Dynamics NAV since the dawn of civilization was annotating (commenting) code changes. If you are not sure what I mean by that, this is what I am talking about:

While standards varied about > vs +, or < vs -, or what the annotations should include, there was absolute consensus that annotating changes is an absolute must.

And it was a must. It was such an important rule that everyone followed it without questions asked. In my career, I’ve seen one or two situations of somebody changing or deleting a line of code without leaving any comment, and I’ve seen quite a lot of code, believe you me. It was that important.

It was that important in fact that it was one of the first things developers learned when they signed up for the job, and it was one of the rules they all followed from their first day.

Continue ReadingCode annotations in AL – Please, don’t!

C# Injection: Don’t trust FOB

  • Reading time:3 mins read

FOBs, those pesky little files that we all take for granted, import into our databases, and live happily ever after. After you read this post, you’ll handle FOB files very, very carefully.

Why is that? Well, if you haven’t already, then read this post first: From C/AL to executable: how NAV runs your C/AL code

Good, now that we are on the same page, let me explain why you must never, ever, ever trust a FOB file.

Continue ReadingC# Injection: Don’t trust FOB
Read more about the article Module Binder Pattern proposal
Zlata Praha, by Roman Boed

Module Binder Pattern proposal

  • Reading time:17 mins read

Whoa! This has been quite an event, the Directions EMEA 2016 in Prague. There has never been this many people (1.700+) and it was quite a pleasure connecting again with old friends, and meeting new friends. Also, it has been quite a pleasure listening to many good sessions, and an even bigger pleasure delivering four of them.

And this is why I am blogging now – to follow up on my promise during my Polymorphic Event Patterns for C/AL. I promised you that I’d post my pattern proposal online, and here I am doing it.

Let’s get started.

Continue ReadingModule Binder Pattern proposal

Gentlemen’s agreement pattern, or handling the “Handled” pattern

  • Reading time:11 mins read

I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.

It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.

Let’s take a look.

Continue ReadingGentlemen’s agreement pattern, or handling the “Handled” pattern

TempBlob Façade: a pattern proposition

  • Reading time:7 mins read

Achieving some kind of polymorphism in C/AL has always been a problem. The fact that true polymorphism with pure C/AL is outright impossible has not stopped the more stubborn of us to at least give it a try. That’s how some cool patterns emerged.

The façade pattern has been evangelized by Gary Winter so eagerly that he couldn’t find time to formally describe it. The other pattern that comes close is the variant façade pattern. It was formally described at the patterns Wiki page, but – to the best of my knowledge – was first figured out by Arend-Jan Kauffmann.

These two patterns can go a long way. No, they are not coming anywhere near true polymorphism, but will achieve some cool loose binding when you need it.

In my practice, I took a step further, and I think it’s about time I share it. Let’s see if it works for you as well as it did for me.

Continue ReadingTempBlob Façade: a pattern proposition

Decoupling dependencies in C/AL

  • Reading time:11 mins read

Directions US 2016 (yes, 2016, sorry y’all who got the 2017 link in your mailbox) was quite an event. As Directions always is, a lot of people, enthusiastic about this market we strive to thrive in, and about the product we love no matter the limitations we often face when we aim for better, more scalable architectures.

If anything, it reminded me of a long to-do list I have had around for this blog for a while, and I decided to start cleaning it up. The topic of my main session this year was loose coupling of dependencies (I called it polymorphism, because that’s what I’d ultimately like to see possible in C/AL) and I presented two patterns I came up with during my past few years.

Before I present them here on my blog, I wanted to put them in a broader context: loose coupling. So, this is what this post is all about: explaining what loose coupling is, how to achieve it in C/AL, and why you will not want to live without it ever again.

Continue ReadingDecoupling dependencies in C/AL

OnAfter table event subscriber patterns and antipatterns

  • Reading time:6 mins read

The purpose of events is to simplify business logic customization while not impeding upgradeability and general extensibility. However, there is one particular class of events that may cause troubles: OnAfter* table events. There are four of them: OnAfterInsert, OnAfterModify, OnAfterDelete, and OnAfterRename.

If you need them, you must be careful.

Continue ReadingOnAfter table event subscriber patterns and antipatterns

A few thoughts around assembly naming and versioning for NAV

  • Reading time:5 mins read

Are you developing .NET assemblies intended to be used from C/AL? If so, then you must have realized that keeping proper track of them and managing them on the server (or client, in case you still do that) is not a simple affair.

Assemblies in .NET are identified through their fully qualified name, and that’s how NAV tells one assembly from another, as well. Fully qualified name contains the assembly name, version, public key token, and culture information. A good practice in .NET development is that when you update assembly’s functionality, you also version that assembly up, essentially resulting in a completely new assembly, which doesn’t have the same fully qualified name as the older version did.

However, this kind of change is a breaking change. In .NET, it’s not all that breaking – you simply reference the new version and this applies to whole project. Or whole solution, depending on how you configure the MSBuild behavior.

But in NAV, it’s a completely different story. Versioning an assembly up is a very breaking change. In NAV, we cannot simply replace a reference once, and then have it apply to the whole database. Unfortunately, we have to update a reference on every single variable, and if you ever had to do it, chances are you don’t keep any happy memories about this experience.

That’s why NAV developers, when working in .NET, prefer not versioning up. And that’s wrong.

Continue ReadingA few thoughts around assembly naming and versioning for NAV

Activity Log or Activity Lock pattern?

  • Reading time:5 mins read

Today at NAV TechDays 2015 in Antwerp, I attended a presentation by Nikola Kukrika, Ciprian Iordache, and Gary Winter, at which Ciprian presented a new design pattern based on a new feature in NAV 2016: Activity Log.

In a nutshell, this new feature, and thus the design pattern, aim at helping trace issues and facilitate troubleshooting by leaving information in the database about what was done, by whom, if it failed, and if it did, why.

All pretty and nice, but – as Ciprian pointed out – there is a bad aspect about it: when an error happens, and everything is rolled back – the activity entry is rolled back together with everything else. Nikola later explained how this could be solved through writing into temporary tables, but this either requires redesign by Microsoft or special coding techniques by you.

However, there is a bigger caveat than this. Non-persisting data in case of errors is a problem, but the bigger problem lies elsewhere. Let me explain that bigger problem here, and then give a silver-bullet solution to solve it all.

Continue ReadingActivity Log or Activity Lock pattern?