Daily Archives: June 19, 2013

Top 10 things I miss in .NET Interoperability in NAV 2013

  • Post comments:25 Comments
  • Reading time:21 mins read

If you ask me what the top addition to the NAV technology stack over the past few years is – it’s .NET interoperability. A lot of folks, maybe you as well, would disagree, and say it’s Web services. They are important. But if you are a NAV developer, Web services don’t make your life any easier. You are programming for Web services when your requirements tell you so, but that’s it. You don’t experience those moments of truth, when it dawns on you, when you go eureka, slap your forehead and say: now this is something I solve with Web services! Not quite.

But with .NET interoperability, it’s a different story. If you know how to harness its power, there is no single project you’ll ever want to go without using .NET. It opens the door to the most powerful development framework for Windows, and it makes many impossible things possible, in pure C/AL.

There are two kinds of things in this world. Those that .NET Interoperability can do, and those it can’t. Microsoft has been steadily improving it since the initial release in 2009 R2. However, there is still much to be desired. Those small things that you cut in C# in seconds, and twist your brain inside out for hours before you realize you can’t do it in C/AL. Some of them may be in a backlog somewhere in Vedbæk, but I don’t know that, so I decided to compile a list of top 10 things I believe C/SIDE should support, and it doesn’t.

(more…)

Continue ReadingTop 10 things I miss in .NET Interoperability in NAV 2013

I had a dream: decoupled NAV

  • Post comments:4 Comments
  • Reading time:18 mins read

You know about PRS (Partner Ready Software), don’t you? It’s the initiative started by Mark Brummel, Eric Wauters (Waldo), and Gary Winter (not necessarily in this order), and then they decided to expand their team by one more member. I am not quite sure if this was a good move, but the time will tell. It always does.

The main goal of the initiative is to enable you to customize NAV in a repeatable way. Repeatability is kind of a buzzword, but PRS doesn’t just buzz the word. PRS believes repeatability is the key. Today maybe you don’t care about repeatability. In two years, or latest five, you’ll want to go back and rethink your angle. PRS wants you to rethink now.

One way of getting repeatable customizations is through patterns. There are patterns, all over NAV, that repeat, time after time, over and again. Agosto dopo agosto dopo agosto dopo agosto as Jovanotti would put it. Pun intended. When a pattern repeats itself, it’s repetition, not repeatability. There is a big difference between them, big as a house. To get repeatable, is to get rid of repetition. Instead of having essentially the same piece of code all over the place with a hint of Goldberg Variations, how about having it only once, in a single place?

Like, having one place where you assign a number from a number series to any master record, document, journal, you name it. Instead of at least—let me guess—120 different places in about as many objects. Then, if you want to customize one small aspect of it, you just touch that one single place. You can then repeat the same customization for hundreds of customers, not only surviving the version upgrade, but making it (the upgrade) an essential, non-disruptive, piece-of-cakeish part of your service offering. That’s the repeatability that PRS is all about.

But—there is always a but—the way NAV is today, we are a long way from this kind of repeatability. A long and painful way away.

That’s why I had a dream. I know it’s only a dream because to make NAV do what I am about to share here would be to downright rearchitect it from the core. But I’ll share it nonetheless. Keep reading.

(more…)

Continue ReadingI had a dream: decoupled NAV