So, you've been asked to create a NetSuite SuiteApp...
Around 12 months ago, I began work on creating a SuiteApp for NetSuite (having had no previous NetSuite experience). While we are no strangers to creating integrations with 3rd party platforms here at Workiro, I was surprised to discover how powerful the SuiteCloud platform and SuiteCloud Development Framework were. It is much more akin to a SaaS platform, allowing you to create a complete application in a modern scripting language in an IDE, deploy that to an account via a CLI, and package up as an application in an app store!
It was quickly clear that the SuiteApp and SuiteCloud platforms were going to become a vital part of our strategic success, and therefore implementing a professional development process which would enable our team to build, test, deploy and ship our SuiteApp as quickly as possible, was vital.
This article details some of the tools and practices we have used, that have enabled us to create a process that we are familiar with as SaaS developers.
They break down to the following four suggestions -
The great thing about SDF is that you are able to store your project locally and write the code on your machine. Any objects your project creates are stored as XML definitions, and as such can be stored in version control.
As a business, and coming from a web development background, we were already very familiar with this idea. We use git and were used to the typical “GitHub-flow” branching strategy. But while this strategy is great for a continuously updating project such as a web app, it’s not so great a fit for when you’d like to release (and support) a specific version of your software, such as a SuiteApp. So my first suggestion would be to read up on, and adopt, “Gitflow” branching strategy before doing anything else.
I began by following the SuiteScript “Hello World” guide (very helpful, I would advise!) which demonstrates how to deploy your first SuiteScript using SDF. NetSuite’s JavaScript API allows you to create and compose scripts based on the AMD module format. The most recent version (2.1 at time of writing) introduces some of the, now commonplace, features of JavaScript such as `const` and `let` keywords and arrow functions etc.
But having written a complex React-based web app using TypeScript, I was keen to work out whether it would be possible to bring the many benefits to our SuiteApp - these included static typing, access to ES2019 features, and great tooling support.
The thing is, using an external API can be tricky with TypeScript unless someone provides the types.
Fortunately, “Head in the Cloud” development company has gone to the trouble of defining the types for the SuiteScript API - see here. Once installed and configured (given you are using a TypeScript-aware IDE) you’ll benefit from syntax highlighting, error detection, embedded API docs, type-checking, and autocomplete for all of the SuiteScript 2.x modules and types. You can find the clearly defined installation instructions here.
Although there is a plugin for JetBrains WebStorm, I would suggest using VS Code and the terminal (using the CLI). This seems to be an industry-wide preference of forgoing clunky “plugins” in favour of lightweight command-line tools.
The additional benefit is that once you’ve understood the process of deploying your new project via the CLI, you’ll be nearer to being able to automate the process via a CI/CD pipeline (blog post on this here!).
Getting the dependancies installed on your machine (Node and JDK 14 etc) to use CLI is simple enough, however when your team mate then downloads the latest version of Node rather than the version that is required, the problems begin. Then there’s the build machine so that you can automate building and deployment. This all creates unnecessary work for your team mates and DevOps team.
Docker makes it possible to standardise the way in which software is run (think, the operating system and other bits of software or settings that are required) by defining a container so that it can run anywhere.
Containerization is the next logical step toward reducing version conflicts and saving time. Containers package all binaries and their dependencies into one executable image. This means, if you need to use a more recent version of Node on your host machine, you can have a container running Node 16 LTS without any conflicts.
I found this article from ERP and distributed systems expert, Brendan Boyd, very helpful - “Using containers for the your netsuite dev workflow”.
I hope this helps!
You can read more about how to automate your CI/CD process in my second blog post of this series here.
Work with documents, get any work done, and communicate in a way that truly matters.
