Connection errors with the 2019_1 API

[shaicoleman]

I've configured Netsuite with a wsdl_domain:

        api_version   '2019_1'
        wsdl_domain   '1234567.suitetalk.api.netsuite.com'

However, it seems to be connecting to webservices.netsuite.com:80 instead.

DEBUG -- : HTTPI /peer GET request to 1234567.suitetalk.api.netsuite.com (net_http)
 INFO -- : SOAP request: http://webservices.netsuite.com/services/NetSuitePort_2019_1
 INFO -- : SOAPAction: "get", Content-Type: text/xml;charset=UTF-8, Content-Length: 1129
DEBUG -- : <?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:platformMsgs="urn:messages_2019_1.platform.webservices.netsuite.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:platformCore="urn:core_2019_1.platform.webservices.netsuite.com">
  <env:Header>
    <platformMsgs:tokenPassport>
      <platformCore:account>***FILTERED***</platformCore:account>
      <platformCore:consumerKey>***FILTERED***</platformCore:consumerKey>
      <platformCore:token>***FILTERED***</platformCore:token>
      <platformCore:nonce>***FILTERED***</platformCore:nonce>
      <platformCore:timestamp>1559923804</platformCore:timestamp>
      <platformCore:signature algorithm="HMAC-SHA256">***FILTERED***
</platformCore:signature>
    </platformMsgs:tokenPassport>
  </env:Header>
  <env:Body>
    <platformMsgs:get>
      <platformMsgs:baseRef xsi:type="platformCore:RecordRef" internalId="123456" type="file"/>
    </platformMsgs:get>
  </env:Body>
</env:Envelope>

DEBUG -- : HTTPI /peer POST request to webservices.netsuite.com (net_http)
Netsuite::Client::Error (Failed to open TCP connection to webservices.netsuite.com:80 (No route to host - connect(2) for "webservices.netsuite.com" port 80))

[billgathen]

I saw the same issue when I tried to upgrade to 2019_1 and account-specific URLs (from 2017_2 and the generic webservices.netsuite.com URL) after receiving an email from NetSuite that the non-account-specific proxy servers will be shut down 2019-06-18.

My requests do succeed with the account-specific URL and version 2018_2 (the SOAP request targets our assigned server, not the generic webservices.netsuite.com), so I'm hoping that will survive the transition.

[shaicoleman]

I'm pretty sure 2018_2 will stop working , as it's currently making requests to webservices.netsuite.com

@iloveitaly , could you please take a look at this?

[billgathen]

I'm seeing the locale-specific server webservices.na2.netsuite.com in my 2018_2 SOAP requests. When I use 2019_1, it switches back to webservices.netsuite.com.

D, [2019-06-14T11:32:24.392126 #94435] DEBUG -- : HTTPI /peer GET request to ***FILTERED***.suitetalk.api.netsuite.com (httpclient)
I, [2019-06-14T11:32:24.913425 #94435]  INFO -- : SOAP request: https://webservices.na2.netsuite.com/services/NetSuitePort_2018_2
I, [2019-06-14T11:32:24.913519 #94435]  INFO -- : SOAPAction: "get", Content-Type: text/xml;charset=UTF-8, Content-Length: 1341
D, [2019-06-14T11:32:24.914200 #94435] DEBUG -- : <?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:platformMsgs="urn:messages_2018_2.platform.webservices.netsuite.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:platformCore="urn:core_2018_2.platform.webservices.netsuite.com">
  <env:Header>
    <platformMsgs:tokenPassport>
      <platformCore:account>***FILTERED***</platformCore:account>
      <platformCore:consumerKey>***FILTERED***</platformCore:consumerKey>
      <platformCore:token>***FILTERED***</platformCore:token>
      <platformCore:nonce>9KKMMXBkqipebvU4ltDg</platformCore:nonce>
      <platformCore:timestamp>1560526344</platformCore:timestamp>
      <platformCore:signature algorithm="HMAC-SHA256">z4IL8jKTWJ0CBpBDK8sygauhAyvo5fF/fB+UwDrAuC4=
</platformCore:signature>
    </platformMsgs:tokenPassport>
    <platformMsgs:preferences>
      <platformMsgs:ApplicationInfo>
        <platformMsgs:applicationId>***FILTERED***</platformMsgs:applicationId>
      </platformMsgs:ApplicationInfo>
    </platformMsgs:preferences>
  </env:Header>
  <env:Body>
    <platformMsgs:get>
      <platformMsgs:baseRef xsi:type="platformCore:RecordRef" internalId="***FILTERED***" type="salesOrder"/>
    </platformMsgs:get>
  </env:Body>
</env:Envelope>

D, [2019-06-14T11:32:24.914439 #94435] DEBUG -- : HTTPI /peer POST request to webservices.na2.netsuite.com (httpclient)
I, [2019-06-14T11:32:27.717369 #94435]  INFO -- : SOAP response (status 200)
...response body follows...

[tusharr]

Hi. Is there any update on this issue? How can I set the domain for all netsuite requests?

[iloveitaly]

@tusharr I don't have time to investigate right now, but you can use NetSuite::Configuration.wsdl to set the full WSDL URL directly in the meantime.

[shaicoleman]

Setting the wsdl directly doesn't seem to fix the issue:

        api_version     '2019_1'
        wsdl_domain     "#{ACCOUNT_ID.to_s.downcase.dasherize}.suitetalk.api.netsuite.com" # https://rest.netsuite.com/rest/datacenterurls?account=ACCOUNT_ID
        wsdl            "https://#{account.to_s.downcase.dasherize}.suitetalk.api.netsuite.com/wsdl/v2019_1_0/netsuite.wsdl"

Still does a request to https://webservices.netsuite.com/services/NetSuitePort_2019_1

[shaicoleman]

It seems that the above URL is in the WSDL itself.

The workaround is that I download a copy of the WSDL (e.g. https://webservices.netsuite.com/wsdl/v2019_1_0/netsuite.wsdl ), and patch it on runtime

wsdl = File.read("#{Rails.root}/vendor/netsuite/v2019_1_0.wsdl") \
           .gsub('https://webservices.netsuite.com/services/',
                 "https://#{@account_id.to_s.downcase.dasherize}.suitetalk.api.netsuite.com/services/")

Then add the following lines in the configure block

        api_version     '2019_1'
        wsdl            wsdl

[iloveitaly]

This is all good stuff! The connection configuration is way overdue for an update. Someone want to start a PR for it?

[q3aiml]

Heads up that I opened up a PR that I believe addresses this: #439. If you take a look or give it a try let me know. I also provided a way to patch the fix in and give it a try without updating the gem.

(h/t to @shaicoleman as the PR accomplishes similar to the fix he shared but in a different location)

[iloveitaly]

Hoping to look at this within the next week or two! Time available to work on this has been limited :(

[iloveitaly]

This issue is fixed with #473 (comment)