- Traffic Health Now Evaluates More NetSuite Services
- Data Center-Specific Domains Targeted for Deprecation in 2020.2
- Change in Outbound Email Filtering
Traffic Health Now Evaluates More NetSuite Services
Data center-specific domains are targeted for deprecation. As of 2020.2, you must use account-specific
domains or dynamic methods to discover the correct domain to use for SOAP web services, RESTlets, external Suitelets, and external forms. The Traffic Health tool is available in NetSuite to help you find the use of data center-specific URLs by the aforementioned services. As of 2020.2, enhancements to Traffic Health include:
- Traffic Health now evaluates the NetSuite UI, Commerce sites, inbound email, and the File Cabinet to
identify traffic that is using data center-specific URLs in your account.
- NetSuite UI: Lists instances of data center-specific versions of the system.netsuite.com domain in your account. Examples of this type of traffic include: ▬ A link to a saved search. ▬ Something published outside of NetSuite, like browsers. ▬ A previously received email. ▬ A text document.
- Commerce: Lists requests to the data center-specific shopping or checkout domains, such as
shopping.netsuite.com or checkout.netsuite.com. You should update your external websites
with the account-specific Commerce domains to ensure processing of shopping and checkout
requests. For example,
.shop.netsuite.com or .secure.netsuite.com. - Inbound Email: Lists instances of email received by NetSuite on a data center-specific
netsuite.com domain. For example, case capture email (
@cases.netsuite.com) where the may include a data center-specific case capture address. - File Cabinet: Lists files using data center-specific URLs that were accessed during the reporting period. You should review and update each file listed so that the URL includes your account-specific domain.
- Traffic Health reports now include a new Response Code column. To access Traffic Health, administrators and other users with the Set Up Company permission can go to Setup > Company > Company Management > Traffic Health. For more information, see the help topic Traffic Health. Data Center-Specific Domains Targeted for Deprecation in 2020.2 As announced in the 2020.1 release notes and in several notifications to customers, some of the data center-specific domains are targeted for deprecation in 2020.2 production accounts. Your SOAP web services integrations, RESTlets, external Suitelets, and external forms should be using account-specific domains. Using account-specific domains removes dependencies on the data center where your account is hosted. Before the 2020.2 release, you must update your integrations, RESTlets, external Suitelets, and external forms in your production account that are still using data center-specific domains. Integrations and external Suitelets must either use account-specific domains or use a dynamic method for discovering the domain. NetSuite gives you the tools needed to identify the data center-specific URLs in your account, and to verify that the updates you make are successful. For information about locating data center-specific URLs in your production accountee, see the help topic Traffic Health.
Data Center-Specific Domains Being Deprecated in 2020.2
SOAP Web Services Data Center- RESTlet Data Center-Specific External Forms and External
Specific Domains Domains Suitelet Domains
- webservices.na1.netsuite.com ■ rest.na1.netsuite.com ■ forms.na1.netsuite.com
SOAP Web Services Data Center- RESTlet Data Center-Specific External Forms and External
Specific Domains Domains Suitelet Domains
- webservices..na2.netsuite.com ■ rest.na2.netsuite.com ■ forms.na2.netsuite.com
- webservices.na3.netsuite.com ■ rest.na3.netsuite.com ■ forms.na3.netsuite.com
- webservices.eu2.netsuite.com ■ rest.eu2.netsuite.com ■ forms.eu2.netsuite.com In NetSuite 2020.2:
- Requests sent to data center-specific webservices and rest domains will receive an HTTP status code 410 Gone.
- A temporary redirect service will be in effect for external Suitelets that use the GET method.
- For external forms, HTTP GET requests to data center-specific forms domains will be redirected to your account-specific domain URL. HTTP POST or PUT requests to these domains will no longer be processed in 2020.2. The effect of not processing these requests is that the submission of the external form will not succeed and any data on the form will be lost. Important: You should use account-specific domains no matter which HTTP methods are used by your external forms. The temporary redirects currently in effect for the GET method may be deprecated in a future release. In cases where an application accesses more than one NetSuite account, you can use dynamic discovery methods to obtain the correct URLs. For information about the available discovery methods, see the help topic Dynamic Discovery of URLs for SOAP Web Services and RESTlet Clients.
All NetSuite account types can still access the following domains for dynamic discovery purposes:
- webservices.netsuite.com: To dynamically discover the URL for SuiteTalk SOAP web services requests.
- rest.netsuite.com: To dynamically discover URLs for NetSuite services in RESTlets or the URL for SuiteTalk REST web services.
Change in Outbound Email Filtering
When outgoing email is sent from NetSuite, the system always verifies that no recipients of the email are listed in the Bounced Email Address list. Now, the system also verifies that the domains of the email addresses have existing records in DNS (an MX or A record). If an email address domain does not have an existing record in DNS, the message for that recipient is listed in the Sent Email List as Not Sent with the delivery status Skipped. The skipped message is logged with the reason code Not Sent: No MX or A for domain. You can view this information in the Sent Email List. You can also view the information in the Undelivered Email Saved Search. In past releases, email messages sent to a domain that did not have a proper DNS record would have been added to the Bounced Email Address list as a hard bounce.
Verifying the Recipients Domain
For email messages sent to a recipient (or multiple recipients) the system does the following:
- Verifies whether a DNS MX record exists for the recipient’s domain.
- If an MX record for the domain exists, the email is sent to the recipient.
- If no MX record exists, the system verifies whether a DNS A record exists for the recipient’s domain. If an A record for the domain exists, the email is sent to the recipient.
- If neither an MX or A record for the domain exists, the system does not send the email message. In
this case:
- The system logs the email message as Not Sent.
- The system logs the recipient as Skipped, with the reason Not sent: No MX or A for domain. For more information, see the help topics Using the Sent Email List, Using the Sent Email List, and Viewing the Bounced Email Address List.