Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Problem calling webservice with a URL (SOAP/HTTP)
JohnP
Member Posts: 56
I have to setup a web service in NAV 2013 R2 that can be used by a third party system to push notifications to NAV. Since the third party is a large bank, there is no flexibility a their end to change things. The first problem was that they only support basic authentication so because you can't mix credential types on a single NAV server, I had to setup a separate NAV server using NAVuserpassword credential types and then implement SSL because it insisted on having that.
Having got past all that, I now tried sending a message from their test page using SOAP.
I put in the URL in the usual format: [url=http://serverip:port/instance/WS/companyname/codeunit/servicename]http://serverip:port/instance/WS/compan ... ervicename[/url] and let it go.
(Yes, the company name is escaped correctly!)
Now, their code is looking for a method called "sendNotification" so I had setup a codeunit with a function called the same thing. However, the test failed and it turns out that the WSDL that is exposed by NAV shows the method as "SendNotification" - note the difference with the upper & lower case "S" at the beginning.
So, since the WSDL is automatically generated, is there anything that can be done in NAV to deal with this? I've tried extending the URL above so it reads "servicename:methodname" and "servicename/methodname" but that doesn't work. I know it is desperate but I'm grasping at anything right now.
As an alternative to SOAP, they can consume the web service with HTTP POST. But I can't work out how to make NAV provide that kind of thing. The examples I can find on the web are all using a URL that ends in something like ".asmx" or whatever which we don't have in NAV. The bottom line is that their setup page allows me to enter a URL, chose whether to use SOAP or HTTP POST and an option to include a SOAP header so there is very limited room for manouvre.
Maybe I am missing something in my old age but I don't know where to go with this now. ](*,)
Thanks in advance for any ideas you might have.
Cheers
John P.
Having got past all that, I now tried sending a message from their test page using SOAP.
I put in the URL in the usual format: [url=http://serverip:port/instance/WS/companyname/codeunit/servicename]http://serverip:port/instance/WS/compan ... ervicename[/url] and let it go.
(Yes, the company name is escaped correctly!)
Now, their code is looking for a method called "sendNotification" so I had setup a codeunit with a function called the same thing. However, the test failed and it turns out that the WSDL that is exposed by NAV shows the method as "SendNotification" - note the difference with the upper & lower case "S" at the beginning.
So, since the WSDL is automatically generated, is there anything that can be done in NAV to deal with this? I've tried extending the URL above so it reads "servicename:methodname" and "servicename/methodname" but that doesn't work. I know it is desperate but I'm grasping at anything right now.
As an alternative to SOAP, they can consume the web service with HTTP POST. But I can't work out how to make NAV provide that kind of thing. The examples I can find on the web are all using a URL that ends in something like ".asmx" or whatever which we don't have in NAV. The bottom line is that their setup page allows me to enter a URL, chose whether to use SOAP or HTTP POST and an option to include a SOAP header so there is very limited room for manouvre.
Maybe I am missing something in my old age but I don't know where to go with this now. ](*,)
Thanks in advance for any ideas you might have.
Cheers
John P.
0
Comments
That is the way NAV generates the WSDL for you , so I am affraid the bank will have to change their code to match the WSDL generated.
shouldn't be that big deal
g.
Gabor [MVP]
Navblog
In .NET you can make everything the way you want it.
But trying to change standard NAV is a dead end.
@Juhl: Yes, I too was getting to the conclusion that I'll have to have something to proxy the request. It is a pain in the **** because it is something else to develop, deploy and maintain but it does have an upside in that I can make it use Windows authentication rather than having to have a separate NAV server that provides basic authentication.
@faludigabor: The response from the bank was that I should take it up with Microsoft. I pointed out that the chances of getting MS to change was about as likely as getting the bank to change so we're stuck between a couple of multi-national giants - they said they appreciated the predicament but that is still my problem. Great.
Cheers
John