AL Object ID Ninja

Zero-configuration, dead-simple, lightning fast, no-collision object ID assignment for multi-user repositories

  • No collisions, ever: Real-time, conflict-free ID assignment that always gives every developer a guaranteed unique object ID.
  • Lightning-fast: Get your conflict-free object IDs instantly, with IntelliSense integration.
  • Zero-configuration: No setup, no onboarding, no settings — you work exactly like before, and it silently keeps your IDs clean.
Learn more

From the blog

Cross-Call State Sharing in Web Services

imageWeb services in NAV have an interesting feature: they are stateless. For a system which is pretty stateful otherwise, this feature can be outright annoying. You must get used to it, and then make sure you never ever write code as if there was any state preserved on the other end.

The reason for this is simple – there is no actual protocol that you use to communicate with NAV through SOAP. Calls are ad-hoc, essentially atomic, each one can accomplish a great deal of things in a single go, and it makes programming a whole lot simpler. The price you pay is the state. Once you close the connection, the session ends and the transaction commits (or rolls back). Next call starts from scratch.

If you need to preserve any state between the calls, whatever that state might be, you are toast. NAV simply doesn’t support it out of the box. A common misconception is that single-instance codeunits help. They don’t. The single instance is always single per session, and since each call is an isolated session, it means that each single instance codeunit dies at the end of the call.

Pretty annoying, isn’t it?

Well, it is, and it isn’t. I won’t argue about validity of situations where you need to preserve state across multiple web services calls – I am going to show you how to do it when you need it.

And what I’m going to show you works in both NAV 2009 R2 and 2013.

Some tips and hints about temporary tables

MP900433071[1]Temporary tables in NAV are a great thing, and are frequently used, but there are some misconceptions about them. I see developers do the same mistakes time after time and again. In this post I’ll address some common misconceptions and give some tips and hints that you can use in practice.

There may be a lot of basics for you here, in which case just skip to the end: there I give you a nice tip about how to prevent accidental changes to physical tables when you expect that a table is temporary, and in fact it is not.

Web Services Black Belt: consuming NAV web services using pure C/AL

MP900406779[1]Have you ever needed to connect to the Web services of one NAV instance from another one? If so, I bet that the approach was something like this: you created a .NET class where you defined a Web or Service reference to the target instance, and then you consumed that .NET class using .NET Framework interoperability. It was kind of clumsy, inflexible, but it worked.

How cool would it be if you could do something like this:


WITH WebService DO BEGIN
  CONNECT('http://localhost:7047/DynamicsNAV70/WS/CRONUS%20International%20Ltd/Page/Customer');

  INIT;
  SETVALUE('Name','Test Customer');
  SETVALUE('Blocked',Cust.Blocked::Ship);
  SETVALUE('Credit_Limit_LCY',10000);
  CREATE;

  MESSAGE('I just created Customer No. %1 in another NAV instance.',GETVALUE('No'));
END;

Read all...