Scripting Best Practices

The following sections offer a series of best practices which you can apply to your scripting. These best practices are meant to help you succeed with scripting, and create scripts which:

• Can be verified and tracked as working correctly

• Can recover from errors

• Don’t need continuous maintenance

Following these practices can maximize your investment in scripting.

Development

• Confirm that your development and production accounts have the necessary switches enabled. You must have the “Enable user script support for Web Service API methods” feature to use the NSOA.wsapi functions. See Scripting Switches.

  Note:

  By default, scheduled triggers are disabled on sandboxes.

• Test your scripts in a sandbox account before deploying them to a production account. See Testing Form Scripts.

• Use platform role permissions to control access to critical features of the Scripting Center and Scripting Studio. See Platform Role Permissions.

• Always check for errors and handle errors appropriately. See Error Handling.

• Consider mobile users when designing scripted solutions. Scripts triggered by “On submit”, “Before save”, or “After save” are not supported for mobile devices. See Scripting and OpenAir Mobile.

• If you are using NetSuite Connector to import Project records from NetSuite, review NetSuite Connector configuration options. Depending on the integration configuration, form scripts triggered by the “Before save” or “After save” events may run for each imported project record. See Scripting and NetSuite Integration.

• Remember that some NSOA functions have no effect for certain script events. For example, NSOA.form.error has no effect on the “After save” form event. See NSOA Functions.

• Use NSOA.form.setValue instead of a wsapi call when possible. See NSOA.form.setValue(field, value).

• Use NSOA.form.confirmation / warning / error messages to give user feedback. See NSOA.form.confirmation(message), NSOA.form.warning(message), and NSOA.form.error(field, message).

• Write scripts which fail safely and are re-entrant to avoid data corruption.

Writing Scripts in JavaScript

• Use comments to explain the script. See JavaScript Overview.

• Use indentation and white space to make your code easy to read. See JavaScript Overview.

• Use meaningful names for variables and functions. See Variables.

• Be consistent in the way you name variables and functions. Use camel case. See Variables.

• Be careful with quotation marks. Quotation marks are used in pairs around strings and that both quotation marks must be of the same style (either single or double). See String.

• Be careful with equal signs. You should not use a single equal sign for comparisons. See Comparison Operators.

• Declare variables explicitly using the var keyword. See Variables.

• Be careful not to create endless loops. Your loops should always have an exit condition. See Loops.

• Rather than creating a long “if .. else” chain, use the “switch” statement. See Conditional Statements.

• Use “try and catch” blocks to handle errors. See Error Handling.

SOAP / WSAPI

• Always check that any SOAP API call was successful before using the results. See Handling SOAP Errors.

• Where possible, batch a series of objects together into a single SOAP API call rather than making a separate call for each object. See Making SOAP Calls.

• The updated and created fields are maintained automatically by OpenAir. You can read these values, but they cannot be modified. See Making SOAP Calls.

• You cannot delete an entity (database record) which has dependent records. You must first delete all the dependent records. See Deleting data.

• You must specify a limit attribute to read data. Make this limit as small as possible if you will only access the first record (for example, set the limit attribute to 1). See Attribute and Reading data.

• Don’t forget to specify the ‘update_custom’ attribute to update a custom field. See Updating Custom Fields.

Logs

• Use log messages to verify your script is executing as expected and to help you to troubleshoot scripts which behave unexpectedly. Logs.

• Set the log severity to “Warning” or “Error” to save space and improve system performance. See Log Severity.

• Set the log severity of a deployed script to "Debug" or "Trace" to track down errors which only occur for a deployed script. See Log Severity.

• Use the “delete log entries” maintenance task to delete log entries which are no longer needed. Use this maintenance task when your system is not busy and be careful not to delete log entries which you may need. See Delete Log Entries.

• Always keep at least the last 30 days of logs. See Delete Log Entries.

Data Access

• Make sure your script can run correctly for any user that may trigger the script. Form scripts are executed within the context of the user who is signed in. See NSOA.wsapi.disableFilterSet( [ flag] ).

• When setting “Select user to execute a script deployment”, create a dedicated user with the minimum necessary permissions dedicated to this purpose. See Platform Role Permissions.

Governance

• Make sure that none of the execution paths through your script will exceed the allowed units limit. See Scripting Governance.

• Don’t try to do too much in a script (especially in a form script). Make sure your script can finish well within the allowed time limits. Your script needs to be able to run successfully even when the server is under load. See Scripting Governance.

• Always try to reduce the number of units your scripts consume. Notice that NSOA.record functions consume zero units, but NSOA.wsapi functions consume 10 units for each call. See NSOA Functions.

Maintainable Scripts

• Access custom fields using the __c notation (note the two underscore characters). The old approach to read custom fields using custom_ with the internally assigned custom field number appended is still supported but NOT recommended. In addition, scripts using the custom_ notation may not be portable between environments, for example, from sandbox to production. See Reading Custom Fields.

• Reference custom fields used by the script. This will prevent changes to custom fields from unintentionally breaking a script. See Updating Custom Fields.

• Reference parameters used by the script. Referencing a parameter prevents the parameter from being deleted or changed in a way which will affect the script. See Creating Parameters.

• Use library scripts to package the complexity of a scripted solution into calling scripts and supporting functions. This will result in scripts which are easier to build and maintain. You can build libraries of proven functions to reduce the cost of future development and maintenance. See Creating Library Scripts.

• Use script parameters to create scripts which can be configured without needing to change the script. See Creating Parameters.

• Use script terminology to allow scripts to immediately reflect any terminology changes made by the administrator. See Accessing Terminology.

• Use platform solutions to package all the elements of a script into a single file. See Creating Solutions.