1. SuiteCloud Platform
  2. SuiteScript
  3. SuiteScript 2.x
  4. Transitioning from SuiteScript 1.0 to SuiteScript 2.x
  5. Overview of the Differences Between SuiteScript 1.0 and SuiteScript 2.x

Overview of the Differences Between SuiteScript 1.0 and SuiteScript 2.x

In general, SuiteScript 2.x provides support for all functionality in SuiteScript 1.0. However, there is not always a direct mapping between functions and objects in SuiteScript 1.0 and modules and methods available in SuiteScript 2.x. And some functionality provided by SuiteScript 1.0 can now be done using JavaScript.

Because SuiteScript 2.x is a modular language, there are several general differences between how scripts are written in SuiteScript 2.x and how they are written in SuiteScript 1.0. These differences include:

There are also more specific differences concerning arguments and parameters, such as:

For more information about these differences and other specific differences, see Differences in Similar SuiteScript 1.0 and SuiteScript 2.x Capabilities.

Also note that some SuiteScript 1.0 functions and objects are not directly mapped to a SuiteScript 2.x module. For a list of these functions and objects, see SuiteScript 1.0 APIs Not Directly Mapped to a SuiteScript 2.x Module.

Script Structure, Entry Points, Entry Point Functions

Each SuiteScript 2.x script type includes one or more entry points that are exclusive to that script type. An entry point represents the juncture at which the system grants control of the NetSuite application to the script. When you include an entry point in your script, you tell the system that it should execute a function defined within the script. This function is called an entry point function. With many script types, the available entry points are analogous to the types of events that trigger your script. For example, the entry points in a client script represent events that can occur during a browser session, such as pageInit and fieldChanged. In comparison, the scheduled script type has only one entry point, execute, which represents the point at which a schedule executes the script or a user manually executes the script.

For more information about the required structure for SuiteScript 2.x scripts, see SuiteScript 2.x Anatomy of a Script.

For more information about entry points and entry point functions, see SuiteScript 2.x Entry Point Script Creation and Deployment.

For more information about entry points for each specific script type, see SuiteScript 2.x Script Types.

Context Objects

Every SuiteScript 2.x script, whether it be an entry point script or a custom module, must use an entry point. Each entry point must also correspond to an object (usually a function) defined within the script. 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 a system-provided object that lets 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.

For more information about context objects, see Context Objects Passed to Standard and Custom Entry Points.

JSDoc

SuiteScript 2.x supports the use of JSDoc tags and comment blocks. In fact, two SuiteScript JSDoc tags are required for SuiteScript 2.x scripts: @NApiVersion and @ScriptType . You can use JSDoc to document your scripts by inserting JSDoc comment blocks and tags within your script.

For more information, see SuiteScript 2.x JSDoc Validation.

Reserved Words

Like most programming languages, SuiteScript includes a list of reserved words. You cannot use reserved words as variable names, labels, or function names in languages based on the ECMAScript specification, such as JavaScript. SuiteScript is based on the ECMAScript specification, so you also cannot use ECMAScript reserved words as variable names or function names in your SuiteScript scripts. If you use a reserved word as a variable name or function name, you may encounter a syntax error when your script runs.

There are also additional reserved parameter names when using SuiteScript Suitelets. For more information about these reserved parameter names, see Reserved Parameter Names in Suitelet URLs.

Note:

SuiteScript 2.x provides global objects including log Object and util Object. If you are using the words ‘log’ or ‘util’ as variable names in your SuiteScript 1.0 scripts and you have both SuiteScript 1.0 and SuiteScript 2.0 scripts running on the same record you will receive an error. Both the ‘log’ and ‘util’ words are reserved in SuiteScript 2.x. You will need to update your SuiteScript 1.0 scripts that use ‘log’ or ‘util’ as variables names.

For more information about SuiteScript reserved words, see SuiteScript Reserved Words.

Enumerated Values

Although JavaScript does not include an enumeration type, in the SuiteScript 2.x documentation we use the term 'enumeration' (or enum) to describe a plain JavaScript object with a flat, map-like structure. Within this object, each key points to a read-only string value.

Enumerations typically take the form of a constant with an associated value. For example, the N/runtime Module includes the runtime.Permission enum that includes permission values of FULL, EDIT, CREATE, VIEW, and NONE. Or, the N/error Module includes the error.Type enum that includes values for possible errors that may be generated from the execution of a script.

Some enumeration values are static and some are dynamic. Static values are available to all SuiteScript 2.x scripts regardless of the type of account or which features are enabled. Dynamic values are determined based on the specific account type and enabled features. In most cases, the help center documentation indicates that some values are dynamic and may not be available to all scripts in all accounts.

Modules

All SuiteScript 2.x APIs are organized into a set of modules. Each module’s name reflects its functionality. For example, the N/record Module lets you interact with NetSuite records and the N/https Module module lets you make HTTPS requests to external web services. Most SuiteScript 2.x modules must be explicitly loaded by a script before the script can access that module’s methods, properties, and enums. You load each module you want to use by specifying it as an argument to the define function. Some SuiteScript modules are also globally available and do not need to be explicitly loaded.

For more information about the modular architecture of SuiteScript 2.x, see Modular Architecture.

For more information about the define function, see define Object.

For more information about globally available objects, see SuiteScript 2.x Global Objects.

Arguments and Parameters

There are several differences between how arguments or parameters are used in SuiteScript 1.0 and how they are used in SuiteScript 2.x. Some of these differences are:

  • In SuiteScript 2.x, method parameters are specified as objects of key: value pairs. In SuiteScript 1.0, arguments are passed to API methods as individual variables or values. In SuiteScript 2.x, they are typically passed as objects. Standard methods expect all parameters to be passed in the form of a single object, that has one or many properties (key: values pairs).

  • Some argument or parameter names are slightly different in SuiteScript 1.0 than in SuiteScript 2.x for the same comparable API method.

  • Some arguments or parameters to functions in SuiteScript 1.0 are now properties in SuiteScript 2.x modules.

  • Some SuiteScript 2.x module methods have additional parameters than their SuiteScript 1.0 function or object counterparts.

The SuiteScript 1.0 to SuiteScript 2.x API Map help topic provides links to each SuiteScript 1.0 API and each corresponding SuiteScript 2.x module, method, or property. You can use this map to compare arguments and parameters between similar functions. The map also includes notes that point out SuiteScript 1.0 functions that are now module properties in SuiteScript 2.x.

Scripting Subrecords

Scripting subrecords in SuiteScript 2.x is fundamentally different from scripting subrecords in SuiteScript 1.0. For example, in SuiteScript 2.x:

  • You can use a single method to create or load a subrecord.

  • Subrecords do not have to be explicitly saved; they are saved when you save the parent record.

  • You must use subrecord methods to work with the address subrecord; addresses are now implemented using subrecords rather than individual fields on a record.

For more information about scripting subrecords in SuiteScript 2.x, see the help topics SuiteScript 2.x Scripting Subrecords and Subrecord Scripting in SuiteScript 2.x Compared With 1.0.

Related Topics

General Notices