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

[sameera]

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]

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

[sameera]

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]

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,

[sameera]

@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]

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

[sameera]

@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>

[jedsmallwood]

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.

[Lxiamail]

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.