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.
My last topic was resident control add-ins. In my video and written blog I’ve explained what they are and how you can quickly have them up and running. However, there was one particular thing I said I generally don’t like – single-instance codeunits. So my second blog on this topic focuses precisely on that: how to make your control add-in available to your AL code from everywhere, without having to rely on a single-instance codeunit.
A few days ago I’ve announced that there will be a new series of webinars. The last webinar was a success. Apart from a few people complaining that I talked fast, and that there was too much content, I got pretty good comments. People felt quite happy with the content and that the value they received was worth the money they invested.
One thing I’ve learned was that you want to learn more about various branching models and strategies. One thing is talking about Git from the technical angle – that’s what the last webinar was about; this time I am focusing on the strategy, how to make Git work inside your organization and how to organize your repository and workflow.
One of the most common questions I get asked about Control Add-ins is whether you can make a control add-in be always present and able to respond to your calls from AL. In other words: can you have a resident control add-in that you can invoke from anywhere in your AL code.
I’ve done a lot about control add-ins. However, I’ve never done resident control add-ins for real; all I know about them is pure theory and then some playing I did at various points of time. Still, this is an interesting topic that I wanted to address some way or other.
So, yesterday I did a live session about it.
If you missed my From JavaScript to AL and back: SkipIfBusy live session on January 8, or if you simply prefer to read rather than watch, then this post is for you. As promised, I’ll follow up in writing on all my video blogs, so here we go.
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.
Happy New Year everyone, with a little delay. I was busy in the first two weeks of this year preparing and delivering the “Leveraging Git” webinar. It turned out to be quite a success, but it also prevented me from doing my live session last Friday.
But this short break doesn’t mean I am not going to get busy with my blog and live blog again. This is what’s coming up.