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

Certain components are common to all SuiteScript 2.x scripts. This topic describes some of these components. It includes the following sections:

Note:

If you have not already done so, review SuiteScript 2.x Hello World, paying particular attention to the Key Concepts section.

Modular Architecture

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

Each SuiteScript 2.x entry point and custom module script must be structured so that it creates a module with the exception of scripts intended solely for on–demand debugging in the NetSuite Debugger or a browser console.

For example, an entry point script must create a module that can be used by the NetSuite application. A custom module script must create a module that can be loaded and used by other scripts. In both cases, the module must be designed to return an object, which is usually a function.

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

The define function can take between one and three arguments. However, a common technique, and the one used in most samples throughout this help center, is to provide two arguments, as follows:

  • The first argument is a list of any dependencies, such as standard SuiteScript 2.x Modules. These modules are loaded when the script executes.

  • The second argument is a callback function. The callback function must include a return statement that identifies at least one standard or custom entry point. The entry point must be associated with an object that is returned when the entry point is invoked. In most use cases, this object is a function.

If you want to understand more about the modular architecture of SuiteScript 2.x, consider reviewing the Asynchronous Module Definition (AMD) Specification, which SuiteScript 2.x uses. However, you do not have to be deeply familiar with AMD before you can use SuiteScript 2.x.

Note:

Some samples that appear in this help center use the require Function instead of the define function. Samples that use require are intended for on-demand debugging, either in the NetSuite Debugger or in a browser console. If a script is to be used for anything other than on-demand debugging, it must use the define Object.

Objects as Arguments

In SuiteScript 2.x, the arguments passed to methods are typically objects. For two examples of how this characteristic is significant, see the following sections:

Objects as Arguments for Standard Methods

Many SuiteScript 2.x methods require you to provide one or more pieces of information. The pieces of information are enclosed in the form of a single object. This object contains one or more properties that may be required or optional. You must set the property value for each required property and any optional properties used in your script.

For example, when you set a value on a record, you use the Record.setValue(options) method. With this method, you must submit two pieces of information: the ID of the field, and the value that you want to set for that field. To pass this information to the method, you must create an object with a fieldId property and a value property. Then you pass this object to the method. For example:

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

myRecord.setValue(myObject);

Another way of passing in an object is to define it within 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 typically referenced as an object titled options. However, in your script, you can give the object any name. For an example, see SuiteScript 2.x User Event Script Tutorial.

Note:

In SuiteScript 2.x, inline comments are not allowed within an object. You may not see a specific error, however, your script will not function properly if you include inline comments within an object.

Context Objects Passed to Standard and Custom Entry Points

Every SuiteScript 2.x script — every entry point script and every custom module script — must use an entry point. Further, each entry point must correspond with an object defined within the script. This object is usually a function. When the object is a function, it is referred to as an entry point function.

In most cases, an entry point function has access to an object provided by the system. Typically, this object can let your script access data and take actions specific to the context in which the script is executing. For that reason, this object is often referred to as a context object.

Depending on what your script needs to do, this object can be a critical part of your script. You can give this object any name you want, but most examples in this help center call these objects context.

Note:

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

Context Objects in Entry Point Scripts

Every standard script type includes entry points specific to that type. Most of these standard entry points have access to a context object that provides access to data or methods. The properties of this object vary depending on the entry point being used. For details about the context object available to each entry point, refer to the documentation for that entry point.

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

Context Objects in Custom Module Scripts

Similar to an entry point script, in a custom module script, an entry point function can receive a context object. However, in the case of a custom module, the object is not provided by the NetSuite application. The object is provided by the SuiteScript that is calling the module.

If you want a custom entry point function to receive an object, then the SuiteScript that calls the function must be written in a way that supports that behavior: The calling script must create the object, set whatever properties are needed, and pass the object to the custom module script. The custom module can then use the object.

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

Note:

To see an example of how the components described in this topic appear in scripts, review SuiteScript 2.x Anatomy of a Script and SuiteScript 2.x Anatomy of a Custom Module Script.

Related Topics

General Notices