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

Updates sandbox url to new address #383

Closed
wants to merge 1 commit into from

Conversation

j-mutter
Copy link

@j-mutter j-mutter commented Jan 26, 2018

Updates the sandbox WSDL url to the new address.

I manually checked this with api_versions of both 2017_1 and 2015_1

Closes #382

@iloveitaly

@tatecarr
Copy link
Contributor

tatecarr commented Feb 9, 2018

@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 wsdl_domain_sandbox similar to being able to set wsdl_domain if you're on na2 etc. in production.

Thoughts @j-mutter & @iloveitaly ?

@jwebbstevens
Copy link

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

Copy link

@jrusso1020 jrusso1020 left a 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"

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

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.

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?

Copy link
Member

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.

@iloveitaly iloveitaly force-pushed the master branch 2 times, most recently from 7185ffc to df796ee Compare May 28, 2019 15:55
@iloveitaly
Copy link
Member

The best way to determine the correct wsdl url / endpoint for a given account ID (sandbox or production) is to use NetSuite::Utilities.data_center_url('account_id'). The readme has been updated to include more details about setting this up properly.

@iloveitaly iloveitaly closed this May 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Netsuite have changed how sandbox urls work
6 participants