User Scripting Overview

User scripting is one component of the OpenAir platform, allowing you to customize OpenAir to better meet the unique needs of your business. OpenAir supports Form Scripts, Scheduled Scripts, Library Scripts, and Script Parameters.

User scripts are written in the industry standard JavaScript language. OpenAir is compliant with ECMAScript 5.

To ensure the security and stability of OpenAir, constraints and checks are placed on user scripting, see Scripting Governance. User scripting is prevented from accessing DOM methods, the file system, and sockets. Access to OpenAir is made available through NSOA Functions.

Scripts are stored in a Dedicated Scripting Workspace used exclusively for scripting and can only be altered through the Scripting Center. Scripts can be edited from the integrated Scripting Studio or by an external editor. To use the Scripting Center or Scripting Studio you need to be signed in as an administrator.

Before you begin writing scripts, you should review Scripting Best Practices.

Tip:

For a quick reference, see the User Scripting Reference Card.

Scripting Switches

There are four switches used to control scripting:

• Enable user scripts to be executed by forms — enables the Scripting Center with the Forms tab and enables you to create Form Scripts. This switch also enables the Script deployment detail report section with the Form script deployment logs report, see Reporting.

• Enable scheduled script deployments — enables the Scripting Center with the Scheduled tab and enables you to create Scheduled Scripts. This switch also enables the Script deployment detail report section with the Scheduled script deployment logs report, see Reporting.

• Enable user script support for https methods — enables you to access NSOA.https functions and call external APIs. See Outbound Calling.

• Enable user script support for Web Service API methods — enables you to access the SOAP API (Web Services) through the NSOA.wsapi functions. SOAP API.

Note:

Contact OpenAir Customer Support to enable these features.

There is one role used to control access to scripting reports:

• There is a View the script deployment log report role permission to enable non-administrators to view script deployment log reports, see Reporting.

Form Scripts

Form scripts are triggered to run by Events. When you create a form script it must be associated with a specific form.

Deploying a form script consists of specifying:

• Event — The event to trigger the script to run, see Events.

• Entrance function — The function defined in the script (attached to the form) you want called, see Entrance Function.

See Creating Form Scripts.

Note:

Form scripts are executed within the context of the user who is signed in, see NSOA.wsapi.disableFilterSet( [ flag] )

Important:

Form scripts may be triggered by an event associated with user interaction — when a user clicks Save, for example.

Form scripts can also be triggered by an event associated with a process utilizing the form software logic — when importing project records from NetSuite using OpenAir NetSuite Connector, for example, depending on the integration configuration. For more information, see Scripting and NetSuite Integration.

Scheduled Scripts

Scheduled scripts are created in a similar same way to form scripts and follow the same scripting workflow. The main differences are that scheduled scripts are not associated with a form, have higher Scripting Governance limits, and are executed according to a schedule defined when they are deployed.

Scripts are executed one at a time from a single first in first out (FIFO) queue.

See Creating Scheduled Scripts.

Tip:

Two or more scripts with the same schedules times that need to run in a specific order should be merged into a single script, that is merge into one script with one Entrance Function calling each of the three functions in the desired order.

Note:

Scheduled scripts are executed within the context of a user. You need to specify the user under which the script is to be executed when you deploy the script.

Tip:

By default scheduled triggers are disabled on sandboxes. If you need to test scheduled triggers in your sandbox account, create a support case in SuiteAnswers and request the run_schedule_script trigger to be enabled for your sandbox account.

Library Scripts

Library scripts are created in a similar same way to form and scheduled scripts and follow the same scripting workflow.

Library scripts allow you to package the complexity of a scripted solution into calling scripts and supporting functions resulting in scripts that are easier to build and maintain. You can build libraries of proven functions to reduce the cost of development and maintenance. Libraries are seamlessly integrated into the Scripting Studio to boost developer productivity.

See Creating Library Scripts.

Script Parameters

Script parameters allow developers to create scripts that can be configured without needing to change the script. Parameters are created and set in the same way as custom fields.

See Creating Parameters.

Script Terminology

Administrators can customize the terminology used in OpenAir to meet the unique needs of their company. For example, one company may use the word project to describe work to be accomplished. Another company may call it a case, job, or assignment. See Interface: Terminology in Administrator Guide Chapter 6 "Administration - Global Settings" for more information about customizing terminology in OpenAir.

The terminology set for an account can be directly accessed and used in scripts to create results that meet the unique needs of the company.

Scripts can be written to immediately reflect any terminology changes made by an administrator without the need to adjust the scripts in any way.

See Accessing Terminology.

Platform Solutions

You can create scripts and store them with all their dependent libraries and parameters in a single solution (XML) file. You can then apply the solution directly to another account. Solutions are stored in XML files to facilitate reading, transfering, archiving, and comparing them.

Tip:

All of the examples described in Real World Use Cases are provided as solutions, see Creating Solutions.

Business Intelligence Connector

The Business Intelligence Connector feature lets you publish OpenAir reports and list views to the OpenAir OData service. Reports can be published with different scope of use. All published reports are accessible with user scripting. You can publish reports for use with user scripting exclusively.

You can access the reports and list views published using the Business Intelligence Connector feature with the following functions:

• For reports: NSOA.report.data(reportId,optionalParameters) and NSOA.report.list().

• For list views: NSOA.listview.data(listviewId) and NSOA.listview.list()

These functions give you access to the same information available when you use Business Intelligence tools to access your OpenAir OData feed.

You can use published list views like custom queries and read the latest list view data in your OpenAir form and scheduled scripts.

Note:

The Business Intelligence Connector feature must be enabled for your account to use NSOA.listview and NSOA.report functions. The Business Intelligence Connector feature is a licensed add-on. To enable this feature, contact your OpenAir account manager.

For more information about publishing list views and reports to the OpenAir OData service, see Business Intelligence Connector.