SuiteScript 1.0 vs 2.0 for SSP Applications

The ability to create SuiteScript (SSP) applications in either SuiteScript 1.0 or 2.0 is critical for developers in the NetSuite ecosystem. However, it is important to note that both versions cannot be combined within a single SSP application. Each application must strictly adhere to one version, which significantly affects how they are created, deployed, and operated.

Key Differences Between SuiteScript 1.0 and 2.0

1. Syntax Variation
   SuiteScript 2.0 applications require scripts to begin with the declaration:
   <%@ NApiVersion="2.x"%>
   This ensures that the script uses the most recent minor version of SuiteScript 2.0. In contrast, no such declaration is necessary for SuiteScript 1.0 applications.

2. Deployment Requirements
   SuiteScript 2.0 applications must be explicitly deployed to a website or specific domain to be accessible. This is different from SuiteScript 1.0 applications, which become available by default. Developers need to consider if they want an application accessible across all domains associated with a website or limited to a single domain.

3. Deployment Limitations
   Only one SuiteScript 2.0 SSP application is permitted per URL root per domain. Therefore, if there's an existing application at a specific URL, it must be undeployed before another can be deployed to the same path.

4. Touch Points
   SuiteScript 2.0 applications do not support touch points. Instead, they utilize a default SSP file as an entry point. While this means fewer entry options, it simplifies the architecture required for these applications. Currently, customizable default SSP files need to be implemented, but future updates may allow broader configuration options.

Future Features

In upcoming releases, it is anticipated that selection of default SSP files for specific domains or websites will improve, allowing for seamless backend processing, live website services, and more accessible functionality linked directly to the application roots.

Conclusion

Given these differences, developers must carefully evaluate which SuiteScript version to utilize based on their specific SSP application requirements. Understanding the implications of each choice will lead to more robust applications tailored to user needs.

Key Takeaways

• Choose SuiteScript 1.0 or 2.0 based on your SSP application needs.
• Deployment is explicit in SuiteScript 2.0, requiring an understanding of domain settings.
• Only one SuiteScript 2.0 application can share a URL root, requiring management of deployments.
• Touch points are absent in SuiteScript 2.0, with a default SSP file needed for entry.
• Future updates may enhance SSP application configurations and deployment options.