AL

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 Conditional directives

Conditional directives

  • Reading time:2 mins read

One of the new features of the AL compiler that arrived with 2020 Wave 2 is Precompiler directives. This is nothing spectacular, programming languages had these kinds of things since the dawn of programming languages, and now we have them too.

The biggest thing, though, is that on their surface, just like so many other features (cough! interfaces, cough, cough, interfaces) you can’t really grasp their full power just by reading the documentation available.

Continue ReadingConditional directives

A couple of ideas for HttpClient

  • Reading time:11 mins read

When invoking any REST web services, a lot of AL code mostly looks like this:

procedure CallRESTFoo()
var
    Client: HttpClient;
    Response: HttpResponseMessage;
    Body: Text;
    Json: JsonObject;
begin
    Client.Get('https://foo.bar/', Response);
    Response.Content.ReadAs(Body);
    Json.ReadFrom(Body);
    // Process JSON body of the response...
end;

Of course, there are more things there, like headers or perhaps calling HTTP POST (or another method) instead of GET, but when you strip it down to the bones, the chunk above is what remains.

Today’s post is a follow up for my HttpClient Patterns live session on http://vjeko.live/ and as I promised, I am providing the text-only version for those who prefer reading to watching.

Continue ReadingA couple of ideas for HttpClient
Read more about the article Fun with Interfaces

Fun with Interfaces

  • Reading time:1 min read

Today I’ve streamed the Fun with Interfaces video blog at https://www.youtube.com/watch?v=QSMHL32c5mg and the recording is now published online.

This was the first session I ever delivered about interfaces, and I actually planned delivering this a lot earlier (I made a suggestion to run this at Directions ASIA before corona crisis hit), but never had a chance. I now polished the demos a bit and delivered it as-is (no slides, really, so – no theory, just practice).

I will have more to say on interfaces, definitely. Stuff like dependency injection, inversion of control, testability, etc. is all very interesting to discuss and very useful in our daily life with AL.

My today’s session not only shows what you can do with interfaces, but also what you cannot, and why. Maybe, who knows, at some point we get some improvements to address some of pain points from my video.

Thanks to everyone who joined me today, and I am looking forward to see all you next week in “Making InvokeExtensibilityMethod work” session.

Continue ReadingFun with Interfaces

How to replace DotNet in AL

  • Reading time:7 mins read

A lot of us still have a ton of C/AL code sitting around in existing databases that sooner or later will have to be moved into AL. A lot of us also have a ton of AL code using DotNet that we want to be able to run in Microsoft’s cloud (that is: not on-prem). And I guess most of us don’t want to maintain a DotNet-less and DotNet-ful versions of our code.

Sooner or later, you’ll want all of DotNet out of your AL. Even if you are a seasoned .NET developer, you’ll want all DotNet out of AL.

Anyway, when you need to replace DotNet, what options do you have? Let’s take a look at all possible paths.

Continue ReadingHow to replace DotNet in AL

Top 5 things I miss in AL

  • Reading time:9 mins read

The community often criticizes Microsoft for adding new platform features only when Microsoft needed them. Well, it has been a bit too harsh – Microsoft did add improvements in other situations, too. But still, if you compare it to other Microsoft’s languages like TypeScript or C#, the AL language isn’t really advancing.

Looking back at C/AL, the AL language has really brought a lot of improvements. We have native JSON types, HTTP API, interfaces, overloads, and a lot more. But still, the overall change of the AL language was minor improvement, rather than a real evolution that transition to VS Code could have allowed.

Here’s the list of top five things I’d absolutely love to see in AL. And I have strong reasons to believe that all of them would be fairly easy to implement for Microsoft. Let’s get started.

Continue ReadingTop 5 things I miss in AL

How about Rollback in AL?

  • Reading time:6 mins read

I’ve never truly understood why we could explicitly commit a transaction, but we could only implicitly roll one back. There is a universe of difference between throwing an error (and ending the call stack), and rolling back (and continuing execution).

There was always a way to roll back and go on, sure. Wrap the entire thing in a if Codeunit.Run() block, throw an error as the last thing inside that codeunit, and there you go. Problem solved. Well, not quite.

Continue ReadingHow about Rollback in AL?

Tip: Text constants in AL

  • Reading time:3 mins read

Long time no see, but that’s how it gets every now and then, I guess… Anyway, I am still alive, still kicking, just don’t get to blog as much as I’d hope for, it’s work, and life and universe and everything.

So, I am back with not a typical “Vjeko” post, just a simple AL opinion piece. A tip, without a trick.

One of the problems we’ve all suffered from in the old days of C/AL (who remembers that still, anyway) was inability to define real text constants. One thing we all avoided was using hardcoded Text literals, like this:

It was not only about the sheer scariness of using Text literals in C/AL, stuff that if left unchecked could cause process issues, something nobody in the ERP world (especially those on the business end of it) likes. Arguably, the worst thing about this kind of code was total lack of reusability. If you had to reuse the literal, you would have to write it again:

Yeah, the mismatch (or typo, whatever you prefer) is intentional to prove my point. You could mistype it, or somebody may decide to change it and then forget to change it in all places, or… stuff happens, you know. It was no good.

There were no constants, and it sucked.

Yeah, yeah, there *were* TextConst constants, but that’s not it. The moment you did this:

… somebody could come in and “fix” it like this:

And there was no way for you to prevent them. There goes your discoverable extension, things break up and your users start yelling your way.

Back in those pre-historic days, I’ve seen people work around this problem like this:

The “constant” is coded in one place, other place call the wrapper function, and world goes on. That was the way to do it in C/AL, truly.

Fast forward back to present. I’ve got myself in the middle of refactoring a chunk of code migrated from C/AL to AL a while ago. It’s full of “pluggable” things that identify themselves to various discoverers, and it’s full of “constants” coded with this function-that-returns-a-hardcoded-literal pattern.

While this worked miracles in C/AL, in AL we actually have a far better way to handle this. Labels. Yeah, fells like I am discovering hot water or sliced bread or something, but please, for the record, don’t do this:

Instead, do this:

If you set the Locked property to true, you are making sure nobody inadvertently translates it, and you keep it a bit cleaner. This is especially true if you have multiple constants – listing them in your var block will be much cleaner than creating a function a piece.

Here endeth the lesson. No rocket science, just an easy one to document my train of thoughts for posterity. Everyone is entitled to my opinion, after all 😁

Continue ReadingTip: Text constants in AL