Getting Started with SDF

Published April 9, 2023

This article will be a general guide on how to get started with NetSuite SuiteCloud Development Framework, aka SDF.
Here is the list of tools I will be using in this article:

While these are the tools I use, they're not the only options. For example, WebStorm has a NetSuite SDF plugin that works well. The tools I use are primarily a personal preference. They're also a low-cost way to get up and running with SDF. Git Bash is great, but CMD will work just as well on a Windows machine.

NetSuite SDF Prerequisites

Before setting up the CLI, we must ensure some features are enabled in NetSuite beforehand. NetSuite has a great guide you can use as well. The key options to enable are; Web Services (SuiteTalk), SuiteCloud Development Framework, Token-Based Authentication, Ouath2 Authentication, Client SuiteScript, and Server SuiteScript. You need to enable TBA Token-Based Authentication; without TBA, the CLI's Browser-based and Token-Based authentication methods will not work.

Install node.js

First things first, let's make sure we have NodeJS installed. If you already have NodeJS and npm configured, jump to the SuiteCloud installation.
You can install NodeJS from nodejs.org. I am going with Windows version 18.14.0 LTS as of this article. Make sure to install npm during the installation.

Install Oracle JDK 17

Next, we must install version 17 of the Oracle Java SE Development Kit. As of this article, it is version 17.0.6. At this time SuiteCloud CLI for node.js only supports version 17. I do not believe it works with version 20 yet. You can find the download install variant for your OS from Oracle's Java Download Page.

Install SuiteCloud CLI for node.js

Open up your terminal of choice that supports npm. I will use Git Bash for Windows as a terminal window in VS Code. Installing SuiteCloud CLI for node.js is very easy with npm. Just run the following command.
npm install -g @oracle/suitecloud-cli
I add the "-acceptSuiteCloudSDKLicense" flag in the video below so the license doesn't appear in the recording.

Creating a Project with SDF

In your terminal, CD to the directory you want to create the SDF project. Since I am using VS Code, I will open it to the directory and then leverage the Terminal Window for all the following CLI commands. Before doing anything more, we will create a blank SDF project with suitecloud project:create -i. Using project:create will create a new SDF Project directory structure. I like using the -i flag to run in interactive mode. It lets the terminal run through in steps to create the project.

  • Select the project type, Account Customization Project or SuiteApp. ACP is for customizing your NetSuite account, whereas SuiteApp is for creating and deploying a SuiteApp through the NetSuite SuiteApp Marketplace. We'll choose ACP.
  • Now, we name the project. "Hello World" in the example. Note that this name will show in the manifest.xml file. This project name will also show as the project name in the Deployment Audit Log in NetSuite.
  • Last, we can choose to install the Jest testing framework. For this example, I will select No to keep it simple. I will delve deeper into the Jest testing framework in a future article.

Setting up the Account

After creating the project, you want to ensure you are in the correct directory in your terminal. In our example, that is "Hello World", so make sure to CD into that. ~Documents/GitHub/GettingStartedSDF/Hello World.
Once the terminal directory is correct, we can set up the SDF account for this project. The command for this is suitecloud account:setup -i. The account:setup command lets us navigate to which NetSuite account instance we want this project associated with. If this is your first time, there will be no stored authentications; we must set up a new authentication.
NetSuite will ask you what authentication method to use. In this example, we will keep it simple and use Browser-based authentication. I like to have a browser already logged into NetSuite available for this in the background.
Next, it will ask you to name this new authentication id. I use myTestInstance for this example. I have seen a common naming convention InstanceTypeRoleUsed, IE: "myProductionAdmin", "mySB1Admin", etc. Finally, it will pop you over to a new browser tab and ask which NetSuite instance to Allow access to. Click Allow, and this will finish the Authentication flow and store the access token on your local machine. You can use the newly stored token in any future SDF projects you wish to set up.
The general idea of the stored authentication accounts is to switch between your various NetSuite accounts (Production, Sandbox, Developer) and deploy SuiteScript code and NetSuite objects to the account you currently have set active in the project. To see the current authentication id that the project will use, look for a project.json file in your SDF project after you use the account:setup command. Our example will be ~Documents/GitHub/GettingStartedSDF/Hello World/project.json.

Upload a SuiteScript file

Uploading a SuiteScript file to the target account is the command I use more than any other CLI command. This command will upload the specified SuiteScript file(s) into the target account. My general flow is to write code changes, use file:upload, then check in NetSuite. Then, rinse, wash, and repeat until I finish the code changes.
In the video, I will show off the interactive method of the file:upload command. It lets you choose one or many files to upload to the NetSuite instance.

Import an Object to your SDF Project

While you can create your own XML objects and then deploy them to the NetSuite instance with object:update or project:deploy, I prefer to create the Object in the sandbox and then either download the XML from the UI and drop it into my SDF Objects directory or use object:import command that will download it from the NetSuite instance. For this example, I will show the suitecloud object:import -i command. Please note that I have already created the Suitelet Script Record and Deployment ahead of time.

The object:import command helps import many objects into your SDF project. If you are working on a single Object, it is easier to use the "Download XML" option from the Object in Netsuite, then copy the XML file into the Project Objects directory. In our example, it would be ~Documents/GitHub/GettingStartedSDF/Hello World/src/Objects/customscript_acv_helloworld.xml

Download XML

Validate the SDF Project

Before deploying your SDF project to a NetSuite instance, an important step to run is the project:validate command. This command will validate the project locally and show any warnings and errors. Unfortunately, as you will see in the following video, I forgot to run the project:adddependencies command. The project:validate will show that our manifest.xml file does not have the required dependencies. We will add those in the next section.

Add dependencies to the SDF Project

Based on the failed validation in the last step, we needed to add dependencies to our manifest.xml file for this project. The command for this is suitecloud project:adddependencies. It will look at the NetSuite instance, determine what parts of the manifest dependencies are missing, and add them to the manifest.xml file.

Deploy the SDF Project

The final step, deploy the project to the account. Generally, this step is for deploying the SDF project to a different account than where you are building the project. For example, a typical flow I take is to build the project in a Sandbox or Developer account. Then when the Git feature branch is approved and merged into the main branch, I will deploy the SDF project to the Production instance. I only have one instance to play with in our example, so we will deploy it into the same instance we built the project with.

Summarizing SDF

For myself, SDF has drastically decreased the time of my development cycle. In the early days of my development in NetSuite, I recall manually navigating to the SuiteScript file in the NetSuite File Cabinet, clicking edit on the file, copy-pasting my code into the pop-up, and saving it. It was a painstaking process, and development could have been smoother and more pleasant.
My intro to SDF was with WebStorm and the early plugin they have for SDF. It was a game-changer for me. However, it wasn't much later that I heard about the SDF with Node.js, and I jumped on board with that immediately.
As this was a "Getting Started" article, I didn't delve into all of the features of the Node CLI; for that, I refer to the SuiteCloud CLI for Node.js Reference page.
In future articles, I will show how to leverage SDF with a CI/CD tool to automate tests and deployments.