DEV Community

Cover image for Changing our Integration with Netsuite

Posted on

Changing our Integration with Netsuite

So Netsuite decided they will be implementing 2FA for logins. This makes things rather difficult for me as our integration was using basic username/password Authorization header calls. Essentially, in Netsuite, you can't use username/password for web service calls anymore.

They have varying methods of authentication they allow for in order to utilize their services. They have a SOAP service and then they provide a RESTful type of method that allows you to write your own script and assign the callback functions to verbs. It's actually quite flexible and powerful with the various actions one can do. I recommend looking into RESTlets in Netsuite's documentation if you're unfamiliar.

This brings me to Netsuite's authentication methods. You can use username and password, Session ID (virtually unusable...but capable) and OAuth 1.0 for integration into their web services platform.

Many of our partners used the username and password authentication due to the simplicity of setup. Obviously, this can create problems when passwords expire or a client wants to eliminate access but our scheduled jobs continue to try to access Netsuite from inside our platform until you can't. Netsuite is sunsetting the username/password capability soon.

So with all that said, I have decided I'll work from the inside out. I am going to rewrite my integration from within Netsuite using a variety of Suitescript events and calling out to our own RESTful API which will accept the data.

This may cause some problems for debugging or troubleshooting any possible errors but we also have an endpoint we will write errors to that will essentially duplicate the execution log of a script. With the exception of invalid license keys to our API, we should be able to generally troubleshoot most issues.

I will use UserEventScripts to attach actions of records to trigger Map/Reduce scripts to loop through unimported records and throttle the calls on our end using our own governance methods tweaking it based on customer commitments ($$$).

I will also use a public Suitelet webhook that will do nothing more than wake up, obtaining updated info by retrieving info via our RESTful api and then going back to sleep. Clean.

Using a combination of RESTlets, Suitelets, and javascript, I will beat permission issues related to users who don't have access to needed records, slower data transfer times and clunky popups that call unfamiliar UIs possibly confusing user experience. Rounding out a good, fast, and usable solution all without needing to use OAuth.

Top comments (0)