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.
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:
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?
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?
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:
And most importantly put you in a good position to select the most suitable Netsuite integration option for your use case.
With that said, let’s review some of the options Netsuite provides for getting data inside the ERP.
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:
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.
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.
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.key points:
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.
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.key points:
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.
Here’s a table summarising the main features for each of the above integration options
|HTTP Method||GET, POST, PUT, PATCH, DELETE||POST||GET, POST, PUT, DELETE|
|Record Operations||CRUD, Search||CRUD, Search||any operation supported by SuiteScript|
|Platform||Agnostic||Favours Java/.NET through available tooling||SuiteScript|
|Authentication||TBA, OAuth1/2.0||TBA, User||TBA, OAuth1/2.0, User|
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:
It helps to check which Netsuite release each of the above methods is compatible with as it varies substantially.
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:
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.
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!