SSP Applications (SuiteScript 1.0 Compared with SuiteScript 2.0)

SSP applications can be written in both SuiteScript 1.0 and SuiteScript 2.0 but the two versions of SuiteScript cannot be combined in a single SSP application. Each SSP application can contain scripts written in either SuiteScript 1.0 or SuiteScript 2.0. The version of SuiteScript affects how the SSP applications are created, installed, and deployed.

The main differences between SSP applications written in SuiteScript 1.0 and SuiteScript 2.0 are:

• Different syntax is used in SuiteScript 2.0 and SuiteScript 1.0– SuiteScript 2.0 scripts used in SSP applications must begin with the following declaration:

  <%@ NApiVersion="2.x"%>

  This declaration ensures that the script automatically uses the latest minor version of SuiteScript 2.0. No declaration is required in SuiteScript 1.0 scripts. For more information and examples, see Sample SSP Application Code (SuiteScript 2.0).

• Explicit deployment required for SuiteScript 2.0 SSP applications– to be accessible on a website or domain, a SuiteScript 2.0 SSP application must be explicitly deployed to it. Deployment to a website means that it is accessible from all domains associated with the website. Deployment to a domain means it is accessible only on that domain. For more information, see Deploy and Undeploy SSP Applications.

• Single SuiteScript 2.0 SSP application permitted per path – if you have more than one SSP application with the same URL root, you cannot deploy them to the same domain or website.

• Touch points are not supported for SuiteScript 2.0 SSP applications– instead of touch points, SuiteScript 2.0 SSP applications use a default SSP file as a single entry point into the SSP application.

  At present there are no NetSuite SSP applications that contain a default application file; however, you can develop and use your own.

  The ability to select a default SSP file for a domain or website will be available in a future release. In 2018.2, SSP applications that use SuiteScript 2.0 can be used for:

  • Backend processing, for example, logging.

  • Services on the website, accessible using a direct link to the URL root at which it is deployed.

  For more information, see Select Default SSP File.

General Notices