SuiteScript 2.x Script Types
SuiteScript 2.x offers several script types each with their own entry points as described in the following table.
Script Type |
Description |
Where They Execute |
---|---|---|
Bundle installation scripts are specialized server scripts that perform processes in target accounts as part of a bundle installation, update, or uninstallation. These processes include setup, configuration, and data management tasks that would otherwise have to be completed by account administrators. Entry points:
|
On the server |
|
Client scripts are scripts that are executed by predefined event triggers in the client browser. They run on individual forms, can be deployed globally, and are applied to entity and transaction record types. They can validate user-entered data and auto-populate fields or sublists at various form events. Global client scripts enable centralized management of scripts that can be applied to an entire record type. Entry points:
|
On the client’s browser |
|
The map/reduce script type is designed for scripts that need to handle large amounts of data. They provide a structured framework for processing a large number of records or a large amount of data and are best suited for situations where the data can be divided into small, independent parts. Entry points:
|
On the server |
|
Mass update scripts allows you to programmatically perform custom mass updates to update fields that are not available through general mass updates. These scripts can run complex calculations across many records. Entry points:
|
On the server |
|
Portlet scripts are used to create custom dashboard portlets. For example, you can use the portlet script type to create a portlet that is populated on-the-fly with company messages based on data within the system. Entry points:
|
On the server, but rendered on the client’s browser |
|
RESTlets can be used to define custom RESTful integrations to NetSuite. You can make a RESTlet available for other applications to call, either from an external application or from within NetSuite. When an application or another script calls a RESTlet, the RESTlet script executes and, in some cases, returns a value to the calling application. Entry points:
|
On the server |
|
Scheduled scripts are server scripts that are executed (processed) with SuiteCloud Processors. You can deploy scheduled scripts so they are submitted for processing at a future time, or at future times on a recurring basis. You can also submit scheduled scripts on demand from the deployment record or from another script with the N/task Module. Entry points:
|
On the server |
|
Suitelets allow you to build custom NetSuite pages and backend logic. They are server scripts that operate in a request-response model, and are invoked by HTTP GET or POST requests to system generated URLs. Suitelets enable the creation of dynamic web content and build NetSuite-looking pages, and they can be used to implement custom front and backends. Entry points:
|
On the server |
|
User event scripts are executed when you perform certain actions on records, such as create, load, update, copy, delete, or submit. These scripts customize the workflow and association between your NetSuite entry forms. These scripts can also be used for additional processing before records are entered or for validating entries based on other data in the system. Entry points:
|
On the server |
|
Workflow action scripts allow you to create custom Workflow Actions that are defined on a record in a workflow. Entry points:
|
On the server |
|
SDF installation scripts are used to perform tasks during deployment of a SuiteApp from SuiteCloud Development Framework (SDF) to your target account. They are automatically executed when a SuiteApp project is deployed. Entry points:
|
On SuiteApp project deployment |
Best Practices
-
Always thoroughly test your code before using it on your live NetSuite data.
-
Type all record, field, sublist, tab, and subtab IDs in lowercase in your SuiteScript code.
-
Prefix all custom script IDs and deployment IDs with an underscore (_).
-
Do not hard-code any passwords in scripts. The password and password2 fields are supported for scripting.
-
If the same code is used across multiple forms, ensure that you test any changes in the code for each form that the code is associated with.
-
Include proper error handling sequences in your script wherever data may be inconsistent, not available, or invalid for certain functions. For example, if your script requires a field value to validate another, ensure that the field value is available.
-
Organize your code into reusable chunks. Many functions can be used in a variety of forms. Any reusable functions should be stored in a common library file and then called into specific event functions for the required forms as needed.
-
Place all custom code and markup, including third party libraries, in your own namespace.
Important:Custom code must not be used to access the NetSuite DOM. Developers must use SuiteScript APIs to access NetSuite UI components.
-
Use the built in Library functions whenever possible for reading/writing Date/Currency fields and for querying XML documents
-
During script development, break your scripts into components, load them individually, and then test each one — inactivating all but the one you are testing when multiple components are tied to a single user event.
-
When working with script type events, your function name should correspond with the event. For example, a pageInit event can be named PageInit or formAPageInit.
-
Since name values can change, ensure that you use static ID values in your API calls where applicable.
-
Although you can use any desired naming conventions for functions within your code, you should use custom namespaces or unique prefixes for all your function names.
-
Thoroughly comment your code. This practice helps with debugging and development and assists NetSuite Customer Support in locating problems if necessary. However, not the inline comments are not allowed within an object.
-
You must use the runtime.getCurrentScript() function in the runtime module to reference script parameters. For example, use the following code to obtain the value of a script parameter named custscript_case_field:
define(['N/runtime'], function(runtime) { function pageInit(context) { var strField = runtime.getCurrentScript().getParameter('SCRIPT', 'custscript_case_field'); ... });
-
Make sure that your script does not take a long time to execute. A script may execute for a long time if any or all of the following occur:
-
The script performs a large number of record operations without going over the usage limit.
-
The script causes a large number of user event scripts or workflows to execute.
-
The script performs database searches or updates that collectively take a long time to finish
Each server script type or application has a time limit for execution. This limit is not fixed and depends on the script type or application. If a single execution of a server script or application takes longer than the time limit for that script type or application, a
SSS_TIME_LIMIT_EXCEEDED
error is thrown. This error can also be thrown from a script that is executed by another script (for example, from a user event script that is executed by a scheduled script). -
You can use SuiteScript Analysis to learn about when the script was installed and how it performed in the past. For more information, see Analyzing Scripts.
Related Topics
- SuiteScript 2.x
- SuiteScript 2.x API Introduction
- SuiteScript 2.1
- SuiteScript 2.x Analytic APIs
- SuiteScript 2.x Record Actions and Macros
- SuiteScript 2.x JSDoc Validation
- SuiteScript 2.x Entry Point Script Creation and Deployment
- SuiteScript 2.x Custom Modules
- SuiteScript 2.x Scripting Records and Subrecords
- SuiteScript 2.x Custom Pages
- Transitioning from SuiteScript 1.0 to SuiteScript 2.x