Nav 2013 R2 - Web Service & DotNet Variable

u382514

I realize in previous versions that using a DotNet variable as a parameter in a function that is opened as a web service just didn't work. I'm assuming it had something to do with the fact that a DotNet variable is actually wrapped in a NavDotNet type and the web service portion couldn't handle serializing that or didn't want to bother with the reflection piece of it.

Now with 2013 R2 it looks like we have the same issue again. The strange thing is that I'm getting a much different error than previous versions. I'm getting an unauthorized error as if it couldn't log in to the service. Of course as soon as I change the parameter to something other than DotNet it works just fine.

Has any genius out there figured out a way to directly add a DotNet variable as a parameter and pass through the web service that they can shed some light on? Note that the DotNet class in question is built specifically with web services in mind and is actually being used/serialized in a WCF service already.

Serializing complex objects is fairly trivial in web services so it seems the Nav guys would've added that functionality by now.

Thanks as always,

SiSt

As far as I know it is still not possible. You have to serialize the value before, pass it as text and deserialize it in NAV. I think I've seen the error you described also in 2009. If you use a data type that was not supported and try to receive the metadata of the service.

Can you give us an idea what you're trying to do? You can access other webservices using WCF from inside NAV (Example: http://msdn.microsoft.com/en-us/library/hh169399(v=nav.71).aspx). Maybe it is possible to have a simple web service in NAV that you call, when the data is ready and it will pull the .NET objects from another service instead of getting it directly?

u382514

Hello SiSt,

Thanks for responding!

I am currently using the serialize -> pass as text -> deserialize in nav approach. Since the WSDL isn't going to show the details of what makes up the appropriate request of the object being passed it is hard for outside vendors to know how to format a request and send it through without me writing up a bunch of documentation and doing change requests along the way, etc. I basically wanted the ability to use a DotNet parameter so the WSDL would be created with the complex data definition and basically be self documenting.

So what I am currently doing to combat that is that I have a web service method call that just returns the XSD of the classes that are used to serialize/deserialize in the other method requests. So the vendor can call that method, grab the XSD for the definition of the classes (can even use something like XSD.exe to recreate the class for use in their .NET app) and then they can serialize and push through the method. On NAV's side it is deserializing back into the expected object (Errors if it is not correct) and processes. This way I can update my .NET Class and register on the server without having to change NAV code and is somewhat self documenting with a way for outside vendors to know what the expected format is supposed to be for requests and responses. NAV will always attempt to deserialize into the correct object and gracefully provide an error if an unexpected request was given for a method.

Also with this method I can have strongly typed objects and not deal with the pushing and pulling into an XML Document. I don't find XMLPorts flexible enough to define the data in web services so I opted not to use those. Also that's one less object I'm taking up in NAV.

Someday I hope they add the ability to use serializable DOTNET variables in NAV parameters for web services.

SiSt

I think in that case I would create a simple proxy service using .Net and serialize the objects in the proxy before passing them to nav. As an additional value it would be much more flexible in terms of user management and and ensuring security policies. But I understand the wish for a better integration of the .Net technology in NAV.