Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOAP request missing header? ("Operation not Supported on this Platform" error attempting to make a request to a Web Service) #2530

Closed
sameera opened this issue Jan 30, 2018 · 8 comments
Assignees
Labels
tooling

Comments

@sameera
Copy link

@sameera sameera commented Jan 30, 2018

I have referenced
https://webservices.netsuite.com/wsdl/v2017_1_0/netsuite.wsdl
with WCF WS Reference Provider connected service. GeneratedCodeAttribute reads:
("dotnet-svcutil", "1.0.0.0")

When attempting to run the solution, I'm getting the following error:

Operation is not supported on this platform.
   at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannelProxy.TaskCreator.<>c__DisplayClass1_0.<CreateGenericTask>b__0(IAsyncResult asyncResult)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

Sample code to repro:

            var client = new NetSuitePortTypeClient();
            var data = await client.getServerTimeAsync(
                new Passport {
                    email = "my@company.com",
                    password = "mypassword",
                    account = "NSACCOUNTNO"
                }, 
                null, 
                new ApplicationInfo { applicationId = config.ApplicationId },
                null
            );

None of the Passport fields should matter because the call doesn't actually happen and fails before any HTTP calls is made.

On a related note:
I had previously used WCF Connected Service to reference and successfully use an older version of this WSDL back in 2017 - June(ish). And the method signatures generated by dotnet-svcutil 0.5.0.0 (which is what was there at that time), and the new signatures are significantly different.

The WSDL definese several header level properties (passport, applicationId). In 0.5, these was required to be set at Endpoint level using IClientMessageInspectors. In v1.0, these have moved to the method signature itself.
e.g.
getServerTimeAsync(SuiteTalk.Passport passport, SuiteTalk.TokenPassport tokenPassport, SuiteTalk.ApplicationInfo applicationInfo, SuiteTalk.PartnerInfo partnerInfo) // v1.0..

Neither the MessageInspector approach nor setting the values at method level, is working for me now.

@mlacouture
Copy link
Member

@mlacouture mlacouture commented Jan 30, 2018

Thank you @sameera, we'll look into this issue as soon as we have a chance.

@mlacouture mlacouture self-assigned this Jan 30, 2018
@mlacouture mlacouture added the tooling label Jan 30, 2018
@mlacouture mlacouture added this to the S132 milestone Jan 30, 2018
@sameera
Copy link
Author

@sameera sameera commented Mar 6, 2018

I've managed to get the NetSuite WS API to work with Connected Services by doing a combination of things (steps that were required before the new method signatures required the header fields to be sent in method params). While I've not spent time pinpointing the issue, my guess is that these new signatures don't work with the NetSuite's WSDL.

Anyhow, I have created a wrapper library for the NetSuite WSDL, abstracting most of the Connected Service nuances and simplifying the APIs to those that look like Service References that VS 2012 and earlier used to build for the NetSuite API.

Library code can be found at https://github.com/pro-celigo/lib-netsuite-servicemgr
under Apache 2.0 license.
You can also get it via nuget:
https://www.nuget.org/packages/Celigo.ServiceManager.NetSuite/

@mlacouture
Copy link
Member

@mlacouture mlacouture commented Mar 16, 2018

Hi @sameera
I tried to reproduce this problem but w/o a NetSuite app id I can't make much progress. If you have details about what operation is not supported (maybe by attaching a debugger and sending us a callstack) that would be very useful.
thanks,

@mlacouture mlacouture modified the milestones: S132, S133 Mar 19, 2018
@sameera
Copy link
Author

@sameera sameera commented Mar 29, 2018

@mlacouture Sorry for the late reply. I tested the same code above and and I'm no longer getting the "Operation is not supported" error.
However, the SOAP request that the above code makes is missing the SOAP header tag.

Here's the SOAP request it made:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <getServerTime xmlns="urn:messages_2017_2.platform.webservices.netsuite.com"/>
  </s:Body>
</s:Envelope>

The Passport and application ID (passed to the original code in the parameter) is what we'd expect to be set in the headers.

As I've mentioned earlier, I've resolved this (and am not using the same method signatures) by extending MessageHeader and adding that to EndPointBehaviors collection. So, this issue could potentially be closed.

@mlacouture
Copy link
Member

@mlacouture mlacouture commented Mar 29, 2018

Thank you @sameera, is the new issue you are experiencing the same as 2569?

@sameera
Copy link
Author

@sameera sameera commented Mar 30, 2018

@mlacouture I don't think so. My code was always on .net core 2.0 and I think 2569 is about missing scaffolding for the header. In this case, all the code seems to be in place; just that the headers set via method params don't get set.

BTW, you can repro this without an Application ID and even a real NetSuite account. If the valid soap xml was generated, that would have been enough for verification. Following is the valid SOAP message generated by using the workaround:

<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <passport xmlns="urn:messages_2017_2.platform.webservices.netsuite.com">
      <email xmlns="urn:core_2017_2.platform.webservices.netsuite.com">my@company.com</email>
      <password xmlns="urn:core_2017_2.platform.webservices.netsuite.com">mypassword</password>
      <account xmlns="urn:core_2017_2.platform.webservices.netsuite.com">NSACCOUNTNO</account>
    </passport>
    <applicationInfo xmlns="urn:messages_2017_2.platform.webservices.netsuite.com">
      <applicationId>TEST_APP_ID</applicationId>
    </applicationInfo>
  </s:Header>
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <getServerTime xmlns="urn:messages_2017_2.platform.webservices.netsuite.com"/>
  </s:Body>
</s:Envelope>

@mlacouture mlacouture modified the milestones: S133, S134 Apr 6, 2018
@jedsmallwood
Copy link

@jedsmallwood jedsmallwood commented Apr 10, 2018

I can say I am interested in a solution here. I need to support multiple versions of the NetSuite API and I'd prefer not to have to maintain wrapper code on top of generated code. Just looking at how different this generated code is when using VS 2017 Preview 2 I am probably going to need to rethink all of my interactions with the API.

@mlacouture mlacouture modified the milestones: S134, S136 May 14, 2018
@Lxiamail Lxiamail modified the milestones: S136, S138 Jul 5, 2018
@mlacouture mlacouture modified the milestones: S138, S139 Jul 9, 2018
@mlacouture mlacouture changed the title "Operation not Supported on this Platform" error attempting to make a request to a Web Service SOAP request missing header? ("Operation not Supported on this Platform" error attempting to make a request to a Web Service) Jul 31, 2018
@mlacouture mlacouture modified the milestones: S139, S140, Future Aug 24, 2018
@Lxiamail
Copy link
Member

@Lxiamail Lxiamail commented Mar 4, 2019

Thank you for the feedback, but our team was unable to prioritize it at this time as they are working on problems with broader customer impact. Please comment below if you have additional data or details that will help us appropriately reprioritize this issue.

@Lxiamail Lxiamail closed this as completed Mar 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tooling
Projects
None yet
Development

No branches or pull requests

4 participants