The NetSuite platform allows customizations via 3rd party code. This is a review of what development for NetSuite is all about.
As an example, let’s look at the API to get the contents of a remote URL: nlapiRequestURL. This API connects to the url passed in as parameter and returns an object containing details of the response. For SuiteScripts, this API is available in client and server scripts, which is kind of cool because cross site scripting limitations mean you can’t do this kind of thing on the client side directly. So what NetSuite does is pass it through the server (behind the scenes) when it’s called from the client side. It’s one less thing for developers to worry about, it’s just that the request will take longer.
NetSuite has these four main types of scripts: Client, User Event, Scheduled, Suitelet. There are more types but these 4 will highlight all the possibilities of the platform.
User Event scripts run on the server side, in response to records being opened or saved. The script runs on the server side. In particular the “Before Save” handler is useful as you can use it to make further modifications to records when they are updated.
Scheduled scripts can be run on the server at scheduled intervals. Apart from the obvious use case, to run certain checks on a daily basis, these types of scripts are also used to deal with script governance. A script is only allowed to take a certain amount of time and resources. So if your script has been running for too long, you can write code to handle this elegantly by rescheduling itself immediately. This doesn’t mean it executes over several days: when a script invokes a scheduled script it is run almost immediately again, this just seems to be the way NetSuite manages the server load.
Suitelets are also server side scripts and behave like web apps. This script type allows you to build up custom pages and forms, and handle GET/POST requests from them. NetSuite has a library which lets you build up a NetSuite-style form in your Suitelet, but you can also create custom HTML output.
All script types enforce governance, which means you can only use a limited number of resources per script execution. This is to prevent scripts running on the NetSuite servers from taking too long or putting too much of a load on the server. For client scripts there are also governance limits, which apply to the APIs which interact with the server side.
When you want to develop an app for NetSuite, you can get a free development environment. The environment seems to be fully functional and it comes with accounts for two developers. When you are ready to release your code you can create a bundle using SuiteBundler. You can control where to deploy your bundle or you can even make it publicly available.
So, on one hand developing in NetSuite is quite powerful. There is really not much that cannot be done. But like many things in NetSuite, this comes at the trade-off of ease of use. In terms of the development framework, this means it doesn’t have some of the features that mature platforms nowadays offer out of the box, such as:
- No source code version and release management. This is sorely missing from NetSuite. To make a change to your code, you upload a new version of a file to the file library. When you collaborate with other developers this can cause problems. You need to implement your own deployment strategy while your app is under development.
- No ability to store application values. Something like the registry on Windows. There is no ability to store for example simple name/value pairs. The only way to store persistent data is by creating records.
If as a developer you are choosing a platform to develop for, NetSuite is not an obvious choice. Be prepared to read a lot and spend a lot of time developing things from scratch. But if you are being asked to create an app for a customer who already uses NetSuite, what the client asks for is almost certainly possible, because there are almost no limits to what can be customized. But with power comes great responsibility.