-
-
Notifications
You must be signed in to change notification settings - Fork 270
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
Updates sandbox url to new address #383
Conversation
ffe1cfb
to
bd27bb9
Compare
bd27bb9
to
a39e9f1
Compare
@j-mutter Should we use a flag to allow both the new approach and old approach to sandbox endpoints? Maybe default to sandbox being the new endpoint style, but the flag will force old style still? Thinking some people could want to update their gem version, but still have the old sandbox. At this point there doesn't appear to be a hard cutover to the new style, so there could be a period where people want the latest gem but need to access both sandbox endpoints. Then just have an update requirement for the next version of the gem to set that flag if you still need the old SB endpoint. Or perhaps we update the gem to use the new style. But we could add a similar config variable to allow for Thoughts @j-mutter & @iloveitaly ? |
@tatecarr The hard cutover is essentially tied to when a user refreshes Sandbox. NetSuite started process in January of 2018. Such a refresh forces the update to use the new domain centered access instead of the old webservices.sandbox model. It would be best to set the current standard since that's the standard that NetSuite is already on. If a user is using an old version say pre 2017.2 its really on them to maintain. Trying to be data center agnostic is also the way to go if at all possible. It's a chicken/egg problem but since users in my experience don't keep up with the latest in releases in general its good to kind of force them to do so even if it breaks things because the user is using an outdate version. I like the newer version because its essentially pushing users towards data center agnosticism and essentially forcing the adoption of TBA which is better for everyone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For all of these changes I think you should replace system
with webservices
(just remove .sandbox
from the initial code). This gem is for the SuiteTalk api which uses webservices
in the domain if I'm not mistaken @j-mutter
@@ -69,7 +69,7 @@ NetSuite.configure do | |||
api_version '2012_1' | |||
|
|||
# optionally specify full wsdl URL (to switch to sandbox, for example) | |||
wsdl "https://webservices.sandbox.netsuite.com/wsdl/v#{api_version}_0/netsuite.wsdl" | |||
wsdl "https://system.netsuite.com/wsdl/v#{api_version}_0/netsuite.wsdl" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be "https://webservices.netsuite.com/wsdl/v#{api_version}_0/netsuite.wsdl"
? In order to get this working correctly for our current setup we had to use the former url not the system
one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. You may have to add in the Data Center (ie. na1, na2) if users aren't going to use data center agnostic rules.
From NetSuite Help Docs:
The format of an account-specific domain name is: ..netsuite.com. For example, if your account ID is 123456, your account-specific domains would be:
123456.suitetalk.api.netsuite.com
123456.restlets.api.netsuite.com
123456.shop.netsuite.com
As of 2017.2, account-specific domains are supported for SuiteTalk (web services), RESTlets, and External Catalog (WSDK) shopping sites. These account-specific domains are unique to your account because they contain your account ID as part of the domain name. These domains do not change when your account is moved to a different data center.
Format of a Data Center-Specific NetSuite URL
For web services, rest, and External Catalog (WSDK) site URLs, consider using account-specific URLs rather than data center-specific URLs. See URLs for Account-Specific Domains.
Data center-specific NetSuite URLs are strings made up of the following parameters: ...netsuite.com.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ignorant question: How do you find your account id?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cooncesean Navigate to the SuiteTalk preferences via “Setup > Integration > Web Services Preferences” to find this ID.
7185ffc
to
df796ee
Compare
The best way to determine the correct wsdl url / endpoint for a given account ID (sandbox or production) is to use |
Updates the sandbox WSDL url to the new address.
I manually checked this with
api_version
s of both2017_1
and2015_1
Closes #382
@iloveitaly