Blog

If it does what the documentation says it does, I can only say: “Build this man a statue!” Awesome job.

— Waldemar Brakowski (@wbrakowski365) September 11, 2021

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.

In the course of publishing this extension to Visual Studio Code, I’ve written a lot of documentation in the form of .md files, and I don’t really want to repeat any of that stuff. So, to present the AL Object ID Ninja, I’ll turn this post into a FAQ.

What does AL Object ID Ninja do?

It assigns object IDs.

Duh! Doesn’t AL already do it?

No, duh! It kind of does, but it works only if you work alone. If you work in a team, then AL will cause object ID collisions.

What are object ID collisions?

They are situations when two developers, working at the same time in their local environments, create a new object of the same type and assign the next available object ID. Since AL Language on one machine doesn’t see what’s happening on another machine, both developers will get the same ID assigned. Everything will work fine in their local repo. But then for one of them (or both of them if there was a third developer who did the same!) the build will break when both developers attempt to merge their code into master.

And how exactly does AL Object ID Ninja help?

AL Object ID Ninja uses a lightweight serverless back end built on Azure Function and Azure BLOB storage to keep track of object IDs assigned in each app. Every time you assign the next object ID, AL Object ID Ninja will jump to the back end and fetch the next number for you. If two developers do it at the same time, they will both get different IDs.

Sounds cool, but is it complicated to use?

No, absolutely not! Check this out:

AL Object ID Ninja works through IntelliSense. It puts its suggestions on top of the IntelliSense auto-suggest list, just above Microsoft’s suggestion coming from AL Language. You can see the difference by checking the icon – AL Object ID Ninja shows a different icon that AL – that makes it easier to spot it in the list.

Is it reliable?

Yes. AL Object ID Ninja guarantees that nobody will ever get a colliding object ID as long as everyone in your team is using AL Object ID Ninja.

How can you be sure there won’t be a collision?

Because it’s built right into it since the beginning. This is how requesting an object ID works in AL Object ID Ninja:

1. When you start IntelliSense, AL Object ID Ninja calls the back end with GET method to “peek” the next available number. Let’s say the next number is 50108. Then it shows 50108 in the auto-suggest list.
2. If you close the IntelliSense drop-down list without accepting the suggestion, nothing happens. The ID stays available.
3. If you accept the auto-suggestion made by AL Object ID Ninja, then Visual Studio Code first inserts the selected item into the code. But then AL Object ID Ninja calls the back end with POST method to both retrieve the next available number and commit it to the back-end storage. It’s transactional, concurrent, uses optimistic ETag approach and there is no theoretical way two users are able to get the same number out of this. Azure BLOB storage service guarantees this for you.
4. If the number fetched with GET (in step 1) is different than one fetched with POST, AL Object ID Ninja will correct the entry and replace the number fetched through GET with the one fetched through POST (in step 3). If the number fetched in step 1 was 50108, and while your IntelliSense drop-down box was open two other developers were faster and already assigned numbers 50108 and 50109, then step 3 will fetch number 50110 and will replace it in the code.

No collisions. Ever.

Wow, this is so cool, is it complicated to set it up?

There is no set up. Seriously. You just install the extension in Visual Studio Code and start using it. Full stop.

The only thing you have to do before you can start assigning new numbers is run one initial sync. AL Object ID Ninja will do this for you automatically when you first use it:

If there is no setup, how does it know which number belongs to which app?

Every time you request a new object, three essential pieces of information are sent: a unique identifier of your app, range that your app uses, and object type that you are requesting an ID for. Since two apps cannot send the same unique identifier, the back end “knows” which number to assign.

Is it safe, I mean me sending my app id to a public endpoint?

Yes, it’s safe. And no, you are not sending your app id. AL Object ID Ninja is not sending your app id. It only ever sends the SHA256 hash of your app id to identify your app. There is no way anyone can identify your app id by reading this hash. Your app id is safe.

Is it fast? I mean, fast enough?

It is fast. And it’s more than fast enough. I mean, if ~150 milliseconds to fetch the next ID is not fast enough for you, then no, it’s probably not fast enough.

And how about that initial synchronization? My repository is huge, how long will that take?

For most repositories, syncing the IDs will take not much longer than fetching the next ID. I’ve tested a repository of ~3000 objects in it, and it takes on average ~500 milliseconds to read all objects, and sync them up with the back end.

It’s fast. AL Object ID Ninja was built to be fast, performance was one of the most important criteria. Whatever it does or will do in the future – you can rely on its swiftness.

And what if one developer in my team doesn’t want to use it?

Well, then you are on your own. Back to Excel sheets, or yelling, or whatever works better for you.

Either everyone in your team uses it, or it makes no sense for anyone to use it. You can’t have it both ways. For the object IDs to be reliably assigned and be guaranteed to never collide, everyone who assigns them must use the same source.

I don’t believe any of this. I mean, this fast, this reliable, it must be some sort of a scam!

Well, then you have your opinion, and I am here to confuse you with facts. Sorry for that. But “facts are stubborn things” and you can easily check all of these claims in the source. AL Object ID Ninja is open source. If I lie in my blog, my code doesn’t lie for sure.

Where do I learn more?

There are some readmes:

• AL Object ID Ninja landing page on Visual Studio Code Marketplace
• Welcome to AL Object ID Ninja readme on GitHub
• Synchronization of IDs readme on GitHub
• Authorization of apps readme on GitHub

And of course, if you want to learn more about how it works and how it was built, join me for the AL Object ID Ninja overview on my Vjeko.live YouTube channel this Friday:

Good luck and let me know what you think of it, and how I can make it even better!