1. SuiteCloud Platform
  2. SuiteScript
  3. SuiteScript 2.x
  4. SuiteScript 2.x API Introduction
  5. SuiteScript 2.x Script Basics

SuiteScript 2.x Script Basics

Some components are common to all SuiteScript 2.x scripts. This topic covers a few of them and includes the following sections:

Note:

If you haven’t already, review SuiteScript 2.x Hello World, and pay special attention to the Key Concepts section.

Modular Architecture

SuiteScript 2.x is modular, meaning all its APIs are organized into standard modules. When your script loads a standard module, it can use any of that module’s APIs.

Every SuiteScript 2.x entry point and custom module script needs to be set up to create a module. This doesn’t apply to scripts meant only for on-demand debugging in the NetSuite Debugger or a browser console. For example, an entry point script has to create a module that the NetSuite application can use. In the same way, a custom module script also needs to create a module that other scripts can load and use. In both cases, the module should be set up to return an object, which is usually a function.

You create a module using the globally available define Object. You can use the define function to create and load modules in your script (see SuiteScript 2.x Hello World).

The define function can take one to three arguments, but most examples in this help center use two:

  • The first argument is a list of dependencies, like standard SuiteScript 2.x Modules. These modules load when the script runs.

  • The second argument is a callback function. This function needs a return statement that identifies at least one standard or custom entry point. The entry point should be linked to an object that’s returned when it’s called—usually, that object is a function.

If you want to learn more about SuiteScript 2.x’s modular architecture, check out the Asynchronous Module Definition (AMD) Specification, which SuiteScript 2.x uses. But you don’t need to know AMD in depth to use SuiteScript 2.x.

Note:

Some samples in this help center use the require Function instead of the define function. Samples that use require are meant for on-demand debugging, either in the NetSuite Debugger or a browser console. If you want to use a script for anything other than on-demand debugging, it needs to use the define Object.

Objects as Arguments

In SuiteScript 2.x, the arguments you pass to methods are usually objects. For two examples of why this matters, check out the following sections:

Using Objects When Calling Standard Methods

Many SuiteScript 2.x methods need you to provide one or more pieces of information, all wrapped up in a single object. This object has one or more properties, which can be required or optional. You need to set a value for each required property, as well as any optional ones you use in your script.

When you set a value on a record, you use the Record.setValue(options) method. With this method, you need to provide two things: the ID of the field and the value you want to set. To do that, you create an object with a fieldId property and a value property, then pass that object to the method. For example:

              var myObject =  {
    fieldId: 'Hello!',
    value: 'Hello, World!'
}; 

myRecord.setValue(myObject);

Another way to pass an object is to define it right inside the method call. For example:

              myRecord.setValue({
    fieldId: 'Hello!',
    value: 'Hello, World!'
});

In the documentation for standard SuiteScript 2.x methods, each method’s argument is usually called options. But in your script, you can name the object whatever you want. For an example, see SuiteScript 2.x User Event Script Tutorial.

Note:

In SuiteScript 2.x, you can’t add inline comments inside an object. You might not see a specific error, but your script won’t work right if you include comments inside an object.

Context Objects for Standard and Custom Entry Points

Every SuiteScript 2.x script—whether it’s an entry point script or a custom module script—needs to use an entry point. Each entry point should match up with an object you define in the script, which is usually a function. When it is, it’s called an entry point function.

Most of the time, an entry point function gets access to an object provided by the system. This object lets your script access data and take actions based on the context where the script is running, which is why it’s often called a context object.

Depending on what your script needs to do, this object can be a key part of your script. You can name it whatever you like, but most examples here call it context.

Note:

For more about entry points, see the Key Concepts section of SuiteScript 2.x Hello World.

Context Objects in Entry Point Scripts

Every standard script type has entry points specific to that type. Most of these entry points can access a context object that gives you data or methods. The properties of this object depend on the entry point you’re using. For details about the context object for each entry point, check the documentation for that entry point.

For an example of how context objects work in a user event script, see SuiteScript 2.x User Event Script Tutorial.

Context Objects in Custom Module Scripts

Similar to entry point scripts, a custom module script’s entry point function can also get a context object. But in this case, the object isn’t provided by NetSuite—it comes from the SuiteScript that calls the module.

If you want a custom entry point function to get an object, the calling SuiteScript needs to be set up for that. The calling script has to create the object, set any needed properties, and pass it to the custom module script, which can then use it.

For an example, see SuiteScript 2.x Custom Module Tutorial.

Note:

To see how these components show up in scripts, check out SuiteScript 2.x Anatomy of a Script and SuiteScript 2.x Anatomy of a Custom Module Script.

Related Topics

General Notices