C/Side Integration Utilities

Version: 1.4.21.318 Alpha

Contributors:  Kamil Sacek, Jan Pieter de Boer
Status: In development
Description: A set of .Net classes that act as a wrapper for communicating with running instances of Microsoft Dynamics Nav.  This is accomplished via the COM running object table.  The purpose of this wrapper is to simplify the workings of communicating with the running object table instances, so that anyone fluent in .Net programming can easily interact with running Dynamics Nav clients.  Thanks to Kamil Sacek, Soren Nielsen and Abhishek Pareek.  Without the foundations laid by these people, I would never have written this.

This library still has one minor known bug and I'm sure some other unknown ones so just keep that in mind.  I have added a good deal of locking to this project in an attempt to make it thread safe but it is still not 100% thread safe so keep this in mind.  Given the single threaded nature of the Dynamics Nav client there is really little point to using this in a multi-threaded manner.  In the event that the client is busy (such as displaying a modal dialog) the locking code will wait till the client becomes responsive to lock and then carry on operation.  This means that if you do not wish your code to wait forever, you should check the IsBusy property of the client in advance and handle this result accordingly before calling any methods or properties on the client instance.

IMPORTANT:  When using this library it is very important you call Client.CleanUp() when you are done working with the Client instances or you should explicitly call Dispose() for each instance you work with.  This is because the .Net garbage collector is quite aggressive when it comes to disposing of COM instances, and it will dispose of some resources the Client instances still have references to, before the client can properly dispose of them.  The result of this can be instability in any Dynamics Nav client instance you have bound to.  This is all due to the event subscriptions, so if you creating client instances without binding the client events, you will not have to worry about this.  The primary outstanding known bug is also event subscription related.

NOTE: If you are building a project on a x64 operating system and having problems, you must set the target platform of your application to x86 for this to work.  Due to the fact that the Nav interfaces this wrapper makes use of are compiled in 32 bit only, my project also had to be targeted for 32 bit.  This also means any applications that use it must likewise target 32 bit.  This doesn't mean it won't run on 64 bit just fine though :)

Download the latest release from my Repository on Github

Update on Thursday, April 4, 2013 at 4:06PM by Thaddeus

I am now hosting this project in a Mercurial repository that is open to everyone.  This is the preferred way to get the latest source release going forward.  I will still publish a compiled package of the latest build for those that just want the binaries, but if you want the source, you should download it from the Mercurial repository.

Comments

[Gerd]

Hello Thad,
that´s a cool piece of work and ty for sharing it as open source! Kudos!
You know if somebody also is concentrating on a .NET API to interact with the new NAV Server (2nd tier)?
ATB
Gerd

[Thaddeus]

Well the new Nav server converts all the C/AL code to C# and compiles it into an assembly so technically it should be quite easy reference that assembly (Although I'm sure the Nav folks don't like people to do that). It's less of an issue though because it has become so easy to communicate with the Nav server since the addition of web services. I guess it all comes down to why you wish to interact with the server. If it is for the purposes of designing objects, the classic client will remain the designer for quite a while, so I'd just use this library (or one like it). If it is for the purposes of manipulating data, then I would craft web services targeted to your needs. I myself will not be focusing on the new server any time soon since my primary focus on is object design at the moment.

[Gerd]

Being able to interact (officially - by means of an API) with the new middle-tier NAV server would enable us to build new sorts of NAV clients. Of course webservice communication does provide for this too, but a more "native" protocol - without all the overhead of webservice/SOAP communication - should be somewhat more efficient. Though I´m not out for new mobile clients I´d be interested in a scaleable and failover enabled alternative for the currently available classic application server. Maybe I´m lacking some information here but although everybody seems to be facinated by the RTC what about NAS: Is there a new component around or announced that will replace classic NAS? One could create a replacement for this component if there would be an API for the new NAV middle-tier server, no? I think this is a very interesting topic to watch out for in the future.

[Thaddeus]

Hmm, that is true, you could theoretically build a new NAS in that fashion. My suspicion is that they won't replace the NAS anytime soon as it is "Good Enough". There are a number of changes I would like to see made to the current NAS server. As far as cutting out the overhead of SOAP goes, ....well I suspect the role tailored client is using SOAP to communicate with the new server though I haven't sniffed any traffic yet to look into it. I still have a bit of catching up to do on the role-tailored client/server. I think it would be just as easy to build a NAS replacement using web services for communication. Given that the code for each NAS is already specialized I don't see much difference between building a web service as opposed to embedding it in codeunit 1. Then you could write a simple windows service program in .Net that communicates using the web service. I plan to delve more into web services integration once I get some other projects wrapped up at my work.

[Soren Nielsen]

With the current NAS, which i think works like a regular classic client, there are some issues, as you cant run RTC reports in it. Also the code executed will not be on service tier, so the new .NET datatypes will probably not be available for NAS here with the release of R2.

[Thaddeus]

Those are very good points. More reasons why I think I would just go the route of creating a service in .Net that talks to some web services created in Navision. Not to mention, you can do lots of cool things not possible in NAS, like much better logging using something like Log4Net or other logging framework, rather than ugly event log messages that all have the same event ID.