NAV2009 SOAP Service - XMLports and namespace
iansilvers
Member Posts: 38
I have a codeunit in NAV2009, exposed as a web service, which contains a number of functions to handle SOAP messages from an external application. Each function corresponds to a different XML message which are handled by XML ports.
This works fine under testing until the XML supplied by the external application included namespaces in the elements of the XML message. I have seen other posts on the forum talking about stripping out the namespace before passing it to the XMLport, but how can I get the inbound XML message before it is passed to the XMLport?
Any suggestions ?
PROCEDURE StockBalanceMessage@1000000000(VAR stockBalances@1000000000 : XMLport 50001) OK : Boolean;
BEGIN
OK := stockBalances.IMPORT;
COMMIT;
END;
This works fine under testing until the XML supplied by the external application included namespaces in the elements of the XML message. I have seen other posts on the forum talking about stripping out the namespace before passing it to the XMLport, but how can I get the inbound XML message before it is passed to the XMLport?
Any suggestions ?
0
Comments
-
As far as I know you can't. But you can set the parameter to BigText pre-process the text before passing it to the XML port.0
-
I thought of trying that, but the authors of the external application are not willing to go down that route. They want to pickup the WDSL from NAV and build the message accordingly.0
-
You do not need to do that. Stripping out the namespace is needed only when you are not the one who makes the rules. Because in your case you are the MASTER and you create the rule of which namespace should be used (by setting the property on the XMLPort), you do not need to handle this. The caller is responsible to send data with correct namespaces...0
-
kine wrote:You do not need to do that. Stripping out the namespace is needed only when you are not the one who makes the rules. Because in your case you are the MASTER and you create the rule of which namespace should be used (by setting the property on the XMLPort), you do not need to handle this. The caller is responsible to send data with correct namespaces...
Thanks for the reply, but the supplier is picking up the WSDL as exposed by NAV, and formatting their messages according to this. NAV then objects when it finds the namespace prefixed to the elements.
We also have the added problem where the supplier thinks they are the more important member of the partnership, and want to shift the resolution of the problem to NAV, this means we would need to be able to access the raw message as it is supplied, and strip out the namespace - something which it appears is not possible.0 -
Than you cannot use the "standard" way. You can use the BigText parameter to take the raw data and decode them as you wish. But than you do not have nice WSDL which will describe the format of the message inside and you need to create own documentation of the expected message.
You know, WSDL is sometimes named as "Contract", and if someone takes it, and do not follow it, he cannot use the webservice... in this case another way must be created, own webservice for such a partner, or some Proxy, translating the calls to the standard calls following the contract. It should be easy to create such a proxy if you know c# or something else from .NET world.0 -
kine wrote:Than you cannot use the "standard" way. You can use the BigText parameter to take the raw data and decode them as you wish. But than you do not have nice WSDL which will describe the format of the message inside and you need to create own documentation of the expected message.
You know, WSDL is sometimes named as "Contract", and if someone takes it, and do not follow it, he cannot use the webservice... in this case another way must be created, own webservice for such a partner, or some Proxy, translating the calls to the standard calls following the contract. It should be easy to create such a proxy if you know c# or something else from .NET world.
Thanks Kine. I appreciate the replies. I am struggling to get the supplier to accept what he is being told, so might need to consider other options, such as you suggest. But this adds to the NAV workload, when the problem really lies at the supplier.0 -
You could also build a soap proxy using .net or a similar language that transforms the data to a format that can be processed by NAV and provide WSDLs etc. to the other parties. But that would also be some effort and someone would have to monitor it.0
-
SiSt wrote:You could also build a soap proxy using .net or a similar language that transforms the data to a format that can be processed by NAV and provide WSDLs etc. to the other parties. But that would also be some effort and someone would have to monitor it.
Thanks SiSt. I am awaiting a response from the other party, but this is the route I am thinking I might need to take. I have not tried this approach before. Do you have any examples that I could take a look at?0 -
I'm sorry, I do not have code that I can share. You can use the Service References in .NET to talk to NAV, there are a lot of examples out there and use the WCF to host the new SOAP service. You will probably also want to build a windows service and so on. Feel free to write me if you want a detailed list of the steps that I think are neccessary.0
-
Thanks again for the reply SiSt.
I am quite comfortable with the writing the requests into NAV, but have never created any web services in C#, and was just looking for a quick starting point.0 -
It is easy to create WCF service. There is template in Visual Studio for it. What will be available from outside is just about using correct attributes on the interface and methods (see ServiceContract and OperationContract attributes). http://msdn.microsoft.com/en-us/library ... 6(v=vs.110).aspx0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 323 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
