300x198xiStock_000018196272Small-300x198.jpg.pagespeed.ic.KQ25RkOYrU

SuiteScript 2.0 with 2015.2

Version 2015 Release 2 introduces the beta version of SuiteScript 2.0, a complete re-factor of the SuiteScript model.The introduction of SuiteScript 2.0 does not change how SuiteScript 1.0 scripts are written. There is only one SuiteScript 2.0 enhancement that impacts SuiteScript 1.0 – the enhancement to the Script record creation process.

Advantages to SuiteScript 2.0

  • Modular Architecture
  • Modern JavaScript Syntax and Behaviour
  • New and Improved API Functionality
  • Asynchronous Client Side Processing (Promises)
  • New Batch Processing Framework (Map/Reduce Script Type)

Modular Architecture

SuiteScript 2.0 is built on modularity. With it, you have access to a complete set of new APIs, contained within modules. These modules are organized based on behaviour. SuiteScript 2.0 also enables you to create your own custom modules. You can use these custom modules to organize helper functions (as a replacement for SuiteScript 1.0 libraries). Additionally, you can add custom modules to SuiteApps and expose those modules to third parties.

Dependency Management and Improved Performance

SuiteScript 2.0 gives you built-in dependency management. It also gives you improved performance. With SuiteScript 2.0, you define the dependencies that must load prior to module execution. This means that you are required to load only those modules that are needed. Because you are not loading all available dependencies at one time (as you do in SuiteScript 1.0), your script loads faster. Plus, when possible, required dependencies are loaded asynchronously in client-side scripts.

Modern JavaScript Syntax and Behaviour

The underlying design principle of this new version of SuiteScript is that SuiteScript 2.0 is JavaScript. SuiteScript 2.0 scripts are clean and intuitive.

SuiteScript 2.0 is modelled to look and behave like modern JavaScript. To facilitate that objective, SuiteScript 2.0 methods and objects are not prefixed with nlapi and nlobj.

This change also reflects the modular organization of SuiteScript 2.0. SuiteScript 1.0 methods and objects respectively belong to the nlapi and nlobj namespaces. SuiteScript 2.0 methods and objects are encapsulated within various modules.

Properties and Enumerations

SuiteScript 2.0 adopts the usage of properties and enumerations. Most SuiteScript 1.0 getter and setter methods are replaced with properties. Enumerations encapsulate common constants (for example, standard record types).

Updated Sublist Indexing

The standard practice in the development world is to start indexing at 0. This behaviour is observed in the majority of programming languages. To bring SuiteScript into alignment with modern JavaScript, sublist indexing within SuiteScript 2.0 begins at 0.

Consistent Behaviour

  • All SuiteScript 2.0 methods take a plain JavaScript object as an input. Within the SuiteScript 2.0 API, all method inputs are named options. For example, the record.load signature is listed as record.load(options).
  • All SuiteScript 2.0 Booleans take a value of true or false. All other Boolean values (for example: T or F) throw an error.
  • Parameter types in SuiteScript 2.0 are strictly adhered to. You must pass in valid parameter types, as listed in the SuiteScript 2.0 help. SuiteScript 2.0 does not convert invalid parameter values to valid values.

New and Improved API Functionality

SuiteScript 2.0 includes the following new functionality.

Expanded Support for HTTP Content Type Headers

SuiteScript 2.0 adds support for most HTTP content types.

New Encryption/Encoding Functionality

SuiteScript 2.0 adds enhanced encryption, decryption, encoding, and hashing functionality.

Asynchronous Client Side Processing (Promises)

With SuiteScript, synchronous processing is especially important in client remote object scripts. These are client scripts that make a call to the NetSuite server to create, load, edit, submit, or delete an object. You can use nested callback functions to increase performance and efficiency, but this method is confusing when dealing with complex operations. The end result is often code that is difficult to read.

In SuiteScript 2.0, all client scripts now support the use of promises. With promises, developers can write asynchronous code that is intuitive and efficient. SuiteScript 2.0 provides promise APIs for select modules (see SuiteScript 2.0 Promise APIs). In addition, you can create custom promises in all modules that support client scripting.

A promise is a JavaScript object that represents the eventual result of an asynchronous process. After this object is created, it serves as a placeholder for the future success or failure of the operation. During the period of time that the promise object is waiting, the remaining segments of the script can execute.

A promise holds one of the following values:

  • fulfilled – The operation is successful.
  • rejected – The operation failed.
  • pending – The operation is still in progress and has not yet been fulfilled or rejected.

When it is first created, a promise holds the value pending. After the associated process is complete (from success or failure), the value changes to fulfilled or rejected. A success or failure callback function attached to the promise is called when the process is complete. Note that a promise can only succeed or fail one time. When the value of the promise updates to fulfilled or rejected, it cannot change.

SuiteScript 2.0 Promise APIs

To make promises more accessible, SuiteScript 2.0 provides client-side promise APIs for the following modules:

  • email
  • error
  • http
  • https
  • record
  • search
  • transaction

The available promise APIs are named so that they correspond with their synchronous counterparts. The distinction is that the promise APIs have names that are suffixed with .promise. For example, the search.create(options) API has a promise version named search.create.promise(options).

New Batch Processing Framework (Map/Reduce Script Type)

Map/reduce is a programming model that enables large amounts of data to be efficiently batch processed. The initial task of parsing the data is broken up into several categories of smaller tasks. In general (not specific to SuiteScript), the basic flow of map/reduce is as follows:

  • Take in a large data set (INPUT).
  • Parse the data into key: value pairs (MAP).
  • Group values based on keys.
  • Evaluate the data in each group (REDUCE).
  • Output the results (OUTPUT).

SuiteScript 2.0 introduces a new script type based on the map/reduce model. Map/reduce scripts provide a structured framework for batch processing scripts. In addition to batch processing, SuiteCloud Plus users can also use map/reduce scripts to process records in parallel across multiple work queues. This script type replaces the parallel processing functionality utilized in SuiteScript 1.0 scheduled scripts. Users manually select the number of work queues to utilize from the script deployment record.

Note: The map/reduce script type automatically tracks governance usage and yielding.

Map/Reduce is a new server-side script type that batch processes large data sets. It goes through at least three of five possible stages when a script is executed.

Important: A map/reduce script is not required to go through both the Map and Reduce stages. One of these stages can be skipped, but the script must go through one of them.

The stages are processed in the following order.

  • Get Input Data – Takes in the original data set. This stage is always processed first and is required. When the data is processed across multiple queues, this stage runs sequentially.
  • Map – Parses data into key: value pairs. If this stage is skipped, the Reduce stage is required. When the data is processed across multiple queues, this stage runs in parallel.
  • Shuffle – Groups values based on keys. This stage is automatically processed after the Map stage is processed. When the data is processed across multiple queues, this stage runs sequentially.
  • Reduce – Evaluates the data in each group. If this stage is skipped, the Map stage is required. When the data is processed across multiple queues, this stage runs in parallel.
  • Summarize – Summarizes the metadata of the task. This stage is optional and is not technically a part of the map/reduce process. When the data is processed across multiple queues, this stage runs sequentially.

With the map/reduce script type, SuiteScript 2.0 also introduces a new map/reduce API. The map/reduce API includes four entry point functions that control the script’s flow into the stages listed above.

  • getInputData() – Starts the map/reduce process. Takes the script into the Get Input Data stage and returns an array. This entry point function is required.
  • map() – Takes the script into the Map and Shuffle stages and returns key: value pairs. Note that the Shuffle stage is automatically processed after the Map stage is processed. If this entry point function is skipped, reduce() is required.
  • reduce() – Takes the script into the Reduce stage and then outputs the result. If this entry point function is skipped, map() is required.
  • summarize() – Takes the script into the Summarize stage. This entry point function is optional.

The script record for map/reduce scripts is similar to the script record for scheduled scripts.

Deployment is also handled in the same manner. Both script types have three options for deployment: by schedule, from the Save and Execute option on the deployment record, or through the task module.