Dynamics NAV 2009 contains a new subsystem for dealing with Web Services. This feature has been well received by partners and customers alike. Partners have expressed interest in having web services available for earlier versions of Dynamics NAV. This feedback resulted in a technology talk at Directions2007 in Florida, where the topic was what could be done to day. The conclusion of the talk was that everything we where intending to deliver was already possible today, yes some code is needed but strictly from function/feature perspective all of it is possible, and it is not even all that ugly. Dynamics NAV 2009 will provide out-of-the-box programmatic web service access to the application and will therefore remove the need for this additional technology plumbing described here.
I have to say that the response to my talk has been tremendous. After the response to my talk on Web Services in NAV 5.0 and previous versions I decided to write this blog post and make the source files available.
This post is about how to bridge the gap between the need for web services now and the current platform, it will help you understand how you can provide Web Services directly from Dynamics NAV today, in a “simple” and flexible way, already today.
To work with the samples in this post you will need: Visual Studio 2005, Dynamics NAV 5.0 and .Net 3.0 installed on your system. This sample should work on Dynamics NAV 4.0 to but has not been tested on that version.
The system we will build contains 4 different components/moving parts: Web Service Listener, Event Dispatcher, Codeunit Eventhandler and XMLPort for stream handling.
Any client that understands how to communicate with Web Services; like InfoPath, Visual Studio, SharePoint or any custom application written by you.
Is the physical communication port that the WCF listens to.
Defines the data contracts and service contracts for the Web Service, it also implements the concrete service and opens for listening in the WCF subsystem, it then delegates the requests to the COM Event Dispatcher component.
This component provides the hookups for Dynamics NAV, both to activate the service and to register event sinks. It defines 2 IDispatch interfaces the IServiceEvents and the IWebServiceListner, as well as the concrete implementation of the IWebServiceListner in the WebServiceListner class that provides the actual code for hooking up the WCF Web Service to Dynamics NAV.
We are using the CLR runtime for writing our Web Service component and our COM plugin. Some of this blog entry is about interop between Dynamics NAV and .NET through COM.
Is responsible for starting up the WCF Web Service through the COM interface, it then registered for events coming from the WCF Web Service Component. The events routed to XMLPort for processing.
It deals with the actual business logic and data coming from or going to the Web Service.
The implementation is in 2 programming languages: C# and C/AL.
Please take a look at the provided code sample, for the rest of the information contained in the posting. It can be found here: http://code.msdn.microsoft.com/nav/Release/ProjectReleases.aspx?ReleaseId=896
I have included comments in the code that should explain what is going on, if you feel something is missing, first look at the documentation for the WCF or post a comment to this post and I will try to answer it.
To deploy the sample you will first have to download it, unpack it.
Then open it up with Visual Studio and compile.
Then import the codeunit.txt and xmlport.txt into your NAV installation and compile those objects, starting with the XMLPort
To run the service simply open the Object Designer in NAV, find the Codeunit that you just imported and press run.
There is no dependency on IIS or other external components. No further deployment steps should be needed.
In the Visual studio solution is a ConsoleTestApp project. After you have followed the steps above you can run that project, it will test if your install was successful, as well as provide sample on how to use the web service.
In this sample I’m using XMLPort to handle the XML stream that is provided.
You can take many different approaches to this, and still reuse large please of the code provided in the sample.
To use the XMLPort as handler you will have to set the encoding property to UTF-8. This is due to a null termination bug in stream handler in NAV.
With this approach you can already today, incorporate web services in your projects in straightforward way.
The appropriate usage is whenever you need to give external application access to Dynamics NAV data or business process.
For any questions or comments please feel free to ask them in the comment section of this blog post. I will answer questions to best of my ability on this post in the comments section as well.
One last thing: This is a sample code. It has not been tested, you should thoroughly test this code before usage.
Best regards,Kris Rafnsson
Great article demonstrating a minimal framework for exposing NAV business logic. Seems a little more elegant than MSMQ & easier to deploy.
I got this to work on NAV50, but when I try it on NAV50SP1 I receive this error: "The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))". This error is reported by the Console App when any method is called on Customer_Service.
It seems to me to be related to Stream/IStream/NAV InStream/NAV OutStream compatibilty or something. Is the InStream/OutStream different in NAV50SP1?
Thanks for any help,
"To use the XMLPort as handler you will have to set the encoding property to UTF-8. This is due to a null termination bug in stream handler in NAV. "
Has this been fixed in NAV5.0 SP1? I have earlier had issues about importing streams into BLOB's from .NET, but i need to try and test this on SP1.
Great post about the Webservice. Keep up the good work.
I can't get it to work on 5.0SP1 either but 5.0 works.
Ikke-afviklet undtagelse: System.Web.Services.Protocols.SoapHeadeHeaderException: Serveren kunne ikke behandle anmodningen på grund af en intern fejl. (the server could not execute the request because of an internal error).
entMessage message, WebResponse response, Stream responseStream, Boolean asyncCa
ved System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String method
Name, Object parameters)
ved ConsoleTestApp.localhost.Customer_Service.Read() i C:\Users\kfc\Desktop\S
ample - WebServicesinNAV5\ConsoleTestApp\Web References\localhost\Reference.cs:l
ved ConsoleTestApp.Program.PrintAllCustomers() i C:\Users\kfc\Desktop\Sample
- WebServicesinNAV5\ConsoleTestApp\Program.cs:linje 21
ved ConsoleTestApp.Program.Main(String args) i C:\Users\kfc\Desktop\Sample
- WebServicesinNAV5\ConsoleTestApp\Program.cs:linje 12
I will look into the issue regarding 5.0 SP1 sometime next week.
This approach should work on Dynamics NAV 4.0 as well.
When I import the dataport, i get the error
"There is a syntax error in the import on line 33 in position 2 : REQUESTPAGE.
A'}'(ListEnd) is expected here.
Ravinder. I just removed the Code-Part REQUESTPAGE including PROPERTIES and CONTROLS and was able to import then without Problem.
Kris. Tnx for the Posting. Works fine here on 5.0-CH.
To make it work with all Nav versions, you have to change 2 lines in Stream.Write method:
Thanks for a great example!
I have a couple of questions:
1) Are there any problems if multiple clients makes calls at the same time? Are there any queue handling?
2) Error handling in NAV. If there's an error in NAV, can I get that error back to the client?
I just tried this on another computer with Windows Server 2003 and Dynamics NAV 5.0SP1.
The compuiter has .net 2.0, 3.0 and 3.5. I registered the dll like so:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>RegAsm.exe c:\NAVWebServiceDemo\bin\Debug\NAVWebServiceDemo.dll /tlb:c:\navwebservicedemo\bin\debug\NAVWebServiceDemo.tlb
Yet, when I try to start the codeunit I get this error:
It was not possible to create an instance of the OLE-object... etc.
However, I can compile the codeunit with no problem.
I noticed that the Input and Output functions is of type IUNKNOWN inside NAV.
The code should serialize calls to NAV.
However for large number of requests you should do something different.
Errors should be propagated when you run this on the NAS.
Try to run the RegAsm with /verbose flag set and see if you can get better info over the registration.
I'm afraid it doesn't give a lot of helpful information.
VWebServiceDemo\bin\Debug\NAVWebServiceDemo.dll /tlb c:\_Shared\NAVWebService\NAVWebServiceDemo\bin\Debug\NAVWebServiceDemo.tlb /verbose
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.1433
Copyright (C) Microsoft Corporation 1998-2004. All rights reserved.
Types registered successfully
Type 'N' exported.
Assembly exported to 'c:\_Shared\NAVWebService\NAVWebServiceDemo\bin\Debug\NAVWebServiceDemo.tlb', and the type library was registered successfully
Just found the solution.
When registering with RegAsm you need to use the /codebase parameter.
This should only be used for signed assemblies, so I'll have to reregister it in a bit.
Hi, i'm not so familar with Visual Studio, so please tell me step by step how to compile the VS Files and register it for use with NAV. I have installed Visual C# Express 2008 and MS .NET Framework SDK 2.0 on my PC. Thank in advance for your help. Best regards Marcel
I have not had the time to look at you fix to my code you did. However this fix makes sense. And thank you for it. As the complains for SP1 compatibility don’t show up any more I assume it is what it takes to get this working with SP1.
Make sure that you do the changes that Andrzej suggested. I have not tried myself with express version of Visual Studio, but if it compiles without errors and warnings, it should run.
That means that you should be able to load the project file.
Import the objects
Compile the NAV objects
Has anybody tested it on 4.0.3 ?