Netsuite Integration Guide

Netsuite provides you with a fair amount of possibilities for enabling the flow of data in and out of the ERP. Each method has its own strengths, and is best suited towards certain use cases. This Netsuite integration guide aims to give an overview of the available options, highlight the benefits of using one method over the other, and hopefully help the reader gain a better understanding of when to use what.

As your Netsuite setup starts to grow, so too will the amount of integrations. It is our belief that in order to run your business at maximum efficiency it makes sense to meet the demands for exchanging data with external systems, by distributing the load across the entire suite of Netsuite integration services.

Netsuite Integration Requirements

We’re advocates of over-analysing requirements when thinking about integrations. By that we mean really thinking deeply about the problem we’re trying to solve. That’s not to say that you should be considering even the tiniest of details at the earliest stages of planning, it’s equally important to remain agile, however when designing a solution it’s paramount to really think about an integration with Netsuite in terms of a few key parameters.

Here are 3 questions you could ask upfront before settling on any option:

1. how big?

Will the data be pacakged in one large payload including several data points? If so, should processing be sequential or could it be processed in parallel? Is it a single resource that’s being sent? Does it exceed X amount of rows? Is the size of the payload fixed, or could it vary in size? Should the integration be designed for scale? Are there restrictions in terms of content type? Does the data need pre/post processing? Does it need aggregating? Is it a one-to-one translation?

2. how often?

What is the frequency of data exchange between the two systems, ie how often will data be sent/received? Is it hourly/daily/weekly/monthly/during business hours/outside peak hours/at undefined intervals? Is it a recurring task, or one time migration?

3. how fast?

Is the time it takes to complete the transaction crucial? Should processing be completed in real-time, or could it be deferred? Will other systems await the completion, or could it be set and forgotten?

Answering the above questions early on will help:

• to clarify technical requirements
• establish implementation boundaries
• determine what is needed and what is not
• separate must-haves from nice-to-haves

And most importantly put you in a good position to select the most suitable Netsuite integration option for your use case.

Netsuite Web Services

With that said, let’s review some of the options Netsuite provides for getting data inside the ERP.

1. CSV Import
2. Restlet
3. SuiteTalk - SOAP,REST

CSV Import

Netsuite ships with a CSV importer capable of importing up to 25000 records of virtually any Netsuite type. The import process could be triggered programmatically using the N/task module, making it highly automatable.

Performance is generally quite good. Netsuite does provide the possibility to use different queues for running multiple imports at the same time. Moreover with SuiteCloud plus licenses you could even leverage multi-threading resulting in optimal performance, on condition that the ordering of record creation is not important.

Keep in mind the input data needs to translate directly to some Netsuite record type, meaning it should arrive in the format specified in the field mapping set up via the Netsuite UI.

Post-processing is possible through:

• enabling user events / workflows to run (though keep in mind this could slow down the import process considerably)
• running some form of transformation logic once import is complete (import status could be retrieved by querying the task). One common approach to avoid running post-import logic in the user events is to use a scheduled script or map/reduce to pick up and process imported records or even simply, to create placeholder custom records and schedule these to be processed asynchronously once CSV import has completed independently.

Leveraging this mode of importing data wherever possible could free up the rest of your account’s integrations capacity (concurrency governance, SuiteCloud processors) for other business processes with a differing set of requirements.

SuiteTalk Web Services

Netsuite offers two industry standard web service options to facilitate integrating with the ERP. Either approach will give you the ability to read and maintain virtually all Netsuite record types from the outside at scale. The first is SOAP, and more recently they’ve introduced a RESTful api.

Before mentioning a few points on each Netsuite implementation, here are some structural differences between the two.

The main difference between the two paradigms lies primarily in the extent to which consuming clients are coupled with the server. In SOAP, there is a strict contract between client and server, everything the client can do is defined upfront, and messages tend to be quite verbose. This provides for a very robust and predictable experience, at the cost of inconvenient maintenance, since even slight changes in functionality require updates to any consumers. SOAP is more of a web service protocol.

REST is a lot less rigid, and more of a design philosophy than a protocol. It piggy backs off of the use of standard HTTP methods, leveraging each to manipulate resources. Client and server are a lot less tightly coupled, and updates to the server don’t generally require an overhaul of the client implementations. REST messages are lighter than SOAP ones, and not restricted to XML as a format. Another key aspect of a truly RESTful api is that it should provide hypermedia links to the client, enabling it to navigate the entirety of the api, much like a browser does a website.

SOAP

Most commonly used in Enterprise systems, SOAP web services tend to be robust and secure at the cost of being rather cumbersome to maintain. SOAP web services are explicitly described using a Web Service Definition Language (WSDL), messages are sent in XML and come with a fair amount of overhead, resulting in slightly slower network traffic than REST web services.

• Mature, stable platform.
• CRUD and search functionality
• Messages are sent exclusively over HTTP POST
• XML schema embedded in the messages themselves dictate the structure
• Usually slower than Restlet or REST web services due to additional transaction overhead
• Changes to the WSDL require SOAP clients to be updated
• Certain tasks require multiple requests to complete
• Favours .NET and Java developers as client proxy classes could be quickly generated in both contexts using the provided Netsuite WSDL
• Allows both synchronous and asynchronous processing of data.

Functionality achievable through a SOAP web service will closely resemble that of an authenticated user browser session. If it could be done via the Netsuite UI, it generally could also be achieved via SOAP. This goes for authentication, permissions, field availability and actions etc. This also applies to system feature settings. Functionality that is disabled through the account settings would not be accessible through SOAP web services.

REST

As at the time of writing, this feature is partly still in Beta

Netsuite also provides a RESTful api for working with data inside the ERP. Communication happens over HTTP using standard methods, with JSON being the media type. Clients could interface with Netsuite records with having little to no knowledge of the api since it follows HATEOAS design. HATEOAS enables an interaction flow between client and server which is analogous to the way a web browser navigates the different pages of a website by providing hyperlinks to the client.

• CRUD and query functionality
• Ships with a metadata catalogue which is the complete Netsuite record schema, which could be used to discover every aspect of the api
• Responses contain hypermedia links to navigate the api
• Content type is JSON
• A little more lightweight than SOAP web services
• Looser client/server coupling means less maintenance than SOAP
• No bulk insertion of records - one request per resource
• Allows both synchronous and asynchronous processing of data.

Restlet

The darling of all Netsuite integration options, a Restlet acts as a gateway into the ERP, exposing publicly accessible endpoints, listening for HTTP requests, running custom code and returning data to the client. Restlets have the added benefit of running some kind of business logic upon receiving requests, which makes them a powerful tool for completing what would normally be a multi-request operation using SuiteTalk, in one Restlet request.

The true power of Restlets lies in the fact that any other SuiteScript could be triggered upon receiving a request, be it a Scheduled Script or a Map/Reduce, making it possible to safely process large amounts of data (in parallel) with the right design.

Restlets must be written and maintained using SuiteScript, which could be limiting/expensive for companies not having access to SuiteScript developers.

• Mature, stable api
• Flexible alternative to SuiteTalk web services
• Communication over HTTP with methods (GET, POST, PUT, DELETE)
• Supports JSON/XML/TEXT content types
• Restlet could do much more with just one request
• Restlet development means needing SuiteScript knowhow, and in-house maintenance of the scripts which is sometimes more expensive over time. With web services maintenance is pretty much offloaded to Netsuite
• Synchronous transaction (though any kind of post-processing achievable using other script types could be triggered by the Restlet)

Here’s a table summarising the main features for each of the above integration options

Authentication

Netsuite offers various ways for external web services to authenticate their way to protected resources. Each integration type comes with it’s own available methods.

Here’s a summary of what’s possible for each.

Restlet and REST:

• Token-based authentication. Tokens are provisioned (Netsuite provides various methods of doing so to cater for all kinds of use cases) and stored. Requests are signed using OAuth 1.0 headers.
• OAuth 2.0 eliminates the need for storing credentials and signing requests. OAuth 2.0 ships with a flow for acquiring an access token, and then requests are authorised by passing the access token in the HTTP Authorization header.
• User Credentials (Restlet only) - pass an NLAuth Authorization header which is built using user credentials. This method is not allowed for Restlets created after the 2021.1 release.

SOAP

• Request-Level Credentials. Include credentials in the SOAP header of each request. Could be done using User Credentials or Token-Based authentication
• Login/SSO Login - session based authentication through user credentials or inbound SSO. In either case, a login class is created containing a method for initiating a new SOAP session in Netsuite. Credentials are passed to the method in the form of a passport object.

It helps to check which Netsuite release each of the above methods is compatible with as it varies substantially.

Concurrency Governance

Please refer to Netsuite’s official documentation for concurrency governance.

Netsuite imposes limits on the amount of incoming concurrent requests for integrations built on SuiteTalk or Restlet. A concurrent request could be thought of as a request which arrives whilst a previous request is still being served.

The account limit is based on:

• your Netsuite service tier
• your SuiteCloud plus licenses
• the account type

These limits will certainly dictate some of the design choices you make when building integrations. It’s sometimes necessary to involve a mechanism for throttling incoming requests depending on your use case.

Involving a middleware to act as a gateway to Netsuite has potential benefits in terms of managing the influx of requests, respecting concurrency governance, error handling and tracing. It could also be viable for teams with not that much SuiteScript experience, to integrate solely using SuiteTalk.

That’s it.

We hope that having read our short Netsuite api guide you have gained a better understanding of the available options for your integration with Netsuite.

We’d be happy to answer any of your integration related queries. Please use the contact form on our homepage or email us on info AT suitehearts DOT net

Just one thing to keep in mind, nothing beats RTFM, so fact-check, verify, and don’t take our word for it!