How to Seamlessly Integrate Data Into NetSuite
Discover effective strategies for integrating data into NetSuite. Explore various options, considerations, and best practices for seamless integration.
Join the DZone community and get the full member experience.
Join For FreeWhen integrating data into NetSuite, there are important decisions to make regarding the source of data, technical options, automation requirements, and the scope of professional services. This article explores the considerations involved in integrating data into NetSuite and highlights different options for achieving seamless integration.
This article is an excerpt from my recent book, NetSuite for Consultants, Second Edition.
Managing Data Coming Into Netsuite
When we talk about integrating data into NetSuite, there are several things to decide on as we initially plan the work:
- Will NetSuite pull the data from another system, or will the other system push it into NetSuite?
- What are the technical options for accomplishing this integration?
- Does the integration need to be automated, or can a user perform a CSV import to bring the data into NetSuite instead?
- What actions are needed on the NetSuite side? (In other words, will we be creating, modifying, or deleting records?)
- Who will create the integration that performs these actions?
In some cases, these things are easy to map out — the other system has a connector already, and we just install and configure it in NetSuite, and we’re done. In other cases, though, this can be tricky. When we need to build some custom integration in NetSuite, the first topic that comes up is usually one regarding the scope of our professional services contract.
It’s common in integrations like this for the scope to be called out in our initial Statement of Work, for instance, but many times it isn’t. We might need to negotiate with the client to add services work (at some new cost) to the contract before building something new. But this depends on your delivery business model — how the initial contract was set up. If you’re working on an open-ended time and materials contract already, you can get approval for the work and then go for it.
Getting two systems to talk to each other can occasionally be time-consuming and difficult. As I mentioned previously when we integrate another system’s data into NetSuite, the two separate databases might not have a lot in common, and that usually means we need to find a way to both transform the data before it’s transferred and also create custom records or fields in which to store it, in the destination system (NetSuite or another application). Once, I worked with a client who wanted to bring their legal caseload data into NetSuite to make it available on the invoices they send their customers. We had to integrate that data from the system their legal users worked in, store it in a custom record, and also tie each of those to an existing Invoice in the system to support their need for a link between the two records.
In some cases, when data comes into NetSuite, we might want to create a custom record type for this purpose, allowing us to define a place where all of the data will reside within NetSuite without adding a lot of unusual fields to a native record type. Then, we can leave the data there and include it in reports or whatever we need, or we can incorporate some of those fields into native records as needed. For instance, if a business uses a third-party system to track most of its day-to-day services operations work, they might want to import that data into a custom record called something like Daily Services. Then, that data can be synced to Invoice lines or just reported on to make it useful within the ERP system.
We always want to find out how frequently data will need to be brought into NetSuite. When the frequency is low, such as once per month, we will suggest that a user performs a CSV import rather than create automation. This saves on development, and users can usually learn this approach in just a single training session. When the frequency warrants it, though, we have a few other options where some type of automation running in NetSuite needs to import data for users. We’ll look at this in the next few sections.
Option 1: SuiteScripts
The most common option in these situations is to create a SuiteScript of the User Event or Map/ Reduce type. Depending on the need, we can create a script that runs in real-time (if the triggering event happens in NetSuite) or on a predefined schedule. Either way, these scripts can be made to reach out to an external system, such as a web service or a secure file transfer server, gather the intended data, and integrate it into NetSuite wherever it belongs.
Option 2: SuiteTalk SOAP
When the owners of an external system are OK with pushing their data into NetSuite — that is, they can develop the integration themselves — then we talk about the two SuiteTalk web services options that are currently supported. SuiteTalk SOAP is the more mature option, having been available for many years. It’s based on an older XML-formatted technology, but it’s fully featured and is used by many, many integrations already. The SOAP standard is used by all sorts of applications (not just within NetSuite), so many developers will find it easy enough to begin importing or exporting data with NetSuite using easily accessed and configured development tools. NetSuite publishes a sort of data dictionary called the Web Services Description for SuiteTalk SOAP that gets updated twice a year, along with the rest of the product.
Option 3: SuiteTalk REST
SuiteTalk REST is a newer option, and as of 2023, it’s a generally available feature, but not every record type is fully supported yet. Some records are generally available (that is, GA), such as customers and Sales Orders, which means NetSuite fully supports their use with the REST API; the API’s details won’t change without an announcement in advance. But some record types are still in what NetSuite calls Beta status. Those records are still subject to change as the API has not been finalized for them. That makes it hard to build production-ready integrations upon them.
I can’t make any firm predictions about this, but I expect that most of the commonly used record types will be given the GA status before too long, so I’m expecting more and more integrations to be built on the REST API over time. For instance, in NetSuite 2023.1, the following record types have become fully supported:
- Customer Payment
- Deposit
- Description Item
- Fulfillment Request
- Item Group item type
- Non-Inventory item type
- Vendor Return Authorizations
Each new NetSuite biannual release usually adds one or more new records to the “GA” list as well. REST is a standard that most web developers will be familiar with since it’s become the most popular communication method among modern web applications and services.
With either the SOAP or REST option, though, someone outside NetSuite has to develop and test an integration from an external server. This is usually a challenge since those people probably won’t have NetSuite experience or even access to an account other than the clients. You can help them with this by providing them with answers to questions about NetSuite and the APIs, ensuring they complete their tasks on time.
Option 4: SuiteScript RESTlet
When another party is OK with developing an integration, but the data they want to send cannot come into NetSuite through SuiteTalk (which is somewhat rare), then we can create another type of script known as a RESTlet. These scripts are like mini web services running in NetSuite. They listen, as we say, for another system or service to call them, with either data in the request or a request for us to send them NetSuite data and respond accordingly. We develop them to use a custom API (of sorts) with the external party. In the case of data coming into NetSuite, the other party might be an external e-commerce web store that wants to send data to NetSuite, and then we might create a RESTlet that receives those requests and creates Sales Orders in NetSuite using the data. We usually choose this option when the third party already has an API specification, and they need NetSuite to work with that, versus adapting their system to the NetSuite APIs.
Conclusion
Integrating data into NetSuite requires careful planning, consideration of technical options, and understanding of the scope of professional services. Whether it's utilizing SuiteScripts, SuiteTalk SOAP, SuiteTalk REST, or SuiteScript RESTlet, each option offers unique advantages. By choosing the right approach and understanding the specific integration requirements, businesses can achieve seamless data integration, enhance operational efficiency, and unlock the full potential of NetSuite's capabilities. Remember, a well-executed integration can streamline processes and provide valuable insights, empowering businesses to make informed decisions and drive growth.
Opinions expressed by DZone contributors are their own.
Comments