Problem calling webservice with a URL (SOAP/HTTP)

JohnPJohnP Member Posts: 56
edited 2014-08-21 in NAV Three Tier
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.

Comments

  • faludigaborfaludigabor Member Posts: 4
    Hi John,

    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.
    regards,
    Gabor [MVP]
    Navblog
  • JuhlJuhl Member Posts: 724
    You could make a asp.net webservice running on IIS, and make that webservice call the NAV webservice, when the bank hits it.
    In .NET you can make everything the way you want it.

    But trying to change standard NAV is a dead end.
    Follow me on my blog juhl.blog
  • JohnPJohnP Member Posts: 56
    Thanks for replying guys.

    @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
Sign In or Register to comment.