Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    Jason Owens
    How to add a service reference in VisualStudio after 1.4?Answered
    Topic posted December 13, 2017 by Jason OwensBlue Ribbon: 750+ Points, last edited December 13, 2017 
    250 Views, 9 Comments
    Title:
    How to add a service reference in VisualStudio after 1.4?
    Content:

    I'm having issues getting a new C# project connected to the SOAP WebService.

    The developer documentation hasn't changed:

    http://documentation.custhelp.com/euf/assets/devdocs/cloud17d/Connect_Web_Services_for_SOAP/Default.htm

     

    But when I enter the correct (according to documentation) address in VisualStudio I get an error attempting to find services.

     

    Navigating to the URL in a browser results in a page telling me:

    The service was accessed in a non-supported manner. Please use standardized URL to access the service: https://<sitename>/services/soap/connect/<service>.
    

     

    My old projects are also now unable to refresh the service (i assume after an upgrade).

    As I can view the WSDL when I append "v1.3" i assume this changed in 1.4, is the correct address format for 1.4 documented somewhere that I'm missing? Or does anyone know how to get this to work in VisualStudio after being upgraded to 1.4?

    Version:
    May 2017

    Best Comment

    Owen Sood-Giddings

    Starting in v1_4, your service reference URL is now:

     

    https://*your URL*/services/soap/connect/soap?wsdl=typed

    Comment

     

    • Owen Sood-Giddings

      Starting in v1_4, your service reference URL is now:

       

      https://*your URL*/services/soap/connect/soap?wsdl=typed

    • Jason Owens
      Owen Sood-Giddings said:

      Starting in v1_4, your service reference URL is now:

       

      https://*your URL*/services/soap/connect/soap?wsdl=typed

      View original

      That works! Thanks!

      After knowing the format, i was able to find it in the documentation in the 'August 2017 Connect Web Services Release Notes'.

      If someone from Oracle happens across this thread, it probably wouldn't hurt to update the "Getting Started - .NET" part of the developer guide to reflect the newest information.

    • Bastiaan van der Kooij

      I am curious to see how this develops for other customers. When the actual old url does not work anymore there will be a ton of customizations that will fail.

      Can someone explain why this decision was made, since I cannot come up with a valid reason to disable the old URL?

    • Suresh Thirukoti

      I second Baastian's concern......Already I saw some concerns from folks in customizations bucket so I think Oracle Dev Team should give clarity

      ~Suresh

    • Jason Owens

      The sample code provided in the Developer Guide (marked 17D) also fail to include the now required 'APIAccessRequestHeader', which means the samples won't work as-is, and the documentation also fails to mention APIAccessRequestHeader at all, as noted in this other thread .





      This definitely needs fixed, it's incredibly frustrating as a developer when documentation and sample code is wrong or doesn't work.



       



       

    • Owen Sood-Giddings

      Hi Jason,

      I'm sorry, I should've remembered to bring that up as another difference.  For anyone who's wondering what Jason is referencing, there is a new parameter that needs to be passed into SOAP API calls.  Ex:

              QueryCSV(ClientInfoHeader ClientInfoHeader, APIAccessRequestHeader APIAccessRequestHeader, string Query, int PageSize, string Delimiter, bool ReturnRawResult, bool DisableMTOM, out CSVTableSet CSVTableSet, out byte[] FileData) 

      You can get away with passing null, for what it's worth.

      I actually work with Oracle, and I very much apologize for the inconvenience.  I will make sure that this gets in front of the right people so the documentation gets updated.

       

    • Bastiaan van der Kooij

      hey Owen,

      can you explain why was chosen to remove the old URL and change the definition in such a way that old code will break?

      Bastiaan

    • Owen Sood-Giddings

      Hi Bastiaan,

      I asked around about this and it sounds like the intention behind the URL change was to bring the format of it into line with other web services (REST, Knowledge Foundation, Chat API, etc.).  Those all share the same general URL format while the SOAP endpoint was an outlier.  I understand that this is a pain in the short term but hopefully in the long run it'll make it easier to remember what the endpoints are because they are all standardized!

      I can verify from our own experience that existing addins continue to work fine (as the WSDL file is incorporated into the build already).  It's only at the point when you open up and rebuild the addin that the the new function definitions or URL become a factor.

      I've also confirmed that our documentation team is actively working on getting the SOAP documentation and code samples updated, and I've been told that those changes will be available soon.

      Let me know if there's anything else I can do to help!

    • Jason Owens

      Owen Sood-Giddings said:

       

      I've also confirmed that our documentation team is actively working on getting the SOAP documentation and code samples updated, and I've been told that those changes will be available soon.

      Let me know if there's anything else I can do to help!


      View original


      I appreciate the updates in this thread, related to documentation, i mentioned in this thread that it looks like object properties are being removed that were never marked as depreciated or removed, are the docs going to be updated to reflect the properties removed without warning, or is the removal of these a bug that needs a ticket opened?