对于只有正式账号,没有沙盒账号的环境而言,不太需要在设计的时候考虑接口与沙盒环境的兼容性。而对于一部分有多个沙盒账号的环境而言,沙盒的兼容性尤为重要,否则刷沙盒可能造成外部系统的混乱。

Suitelet做endpoint

用suitelet作为接口确实有一些hacky(因为suitelet原生是不带验证的,一旦url被滥用可能非常尴尬),但是确实有开发者会使用它。

在外部系统调用suitelet的时候需要考虑的东西不会太多,主要是账号的后缀-sb需要正确,它意味着正确的系统环境;而h参数一样决定了访问是否成功。

对于suitelet类型的脚本每次刷新之后系统会更新h这个参数,因此你的url每次刷新都需要改变。

Restlet类型的脚本

Restlet脚本在沙盒兼容性上考虑的最少。

外部系统调用restlet的时候需要考虑到账号的-sb参数以及realm(针对OAuth1.0)

对于restlet类型脚本,每次刷新之后需要考虑重新创建Integration以确保获得正确的token和secret

其他脚本

其他脚本包括了所有可能通过http、https请求向外部发送请求数据的脚本,包括但不限于MapReduce, Scheduled, UserEvent等服务器端的脚本,实现的目的包括推送、更改、获取数据等等。

在设计上,有两种思路:

  • 在推送数据时包含环境信息,供外部系统判断
  • 在判断是否推送的时候考虑环境信息,实现“正式环境推送、沙盒不推送”或“正式环境推送外部正式环境,沙盒环境推送外部沙盒环境”

以上都需要用到N/runtime

var accountId = runtime.accountId;
var environment = runtime.envType;  // PRODUCTION, SANDBOX, etc.

如果应用了以上的设计思路,那么正式环境和沙盒环境可以实现脚本互相通用,刷新了沙盒环境也无需顾虑。如果没有采取以上的设计思路,则需要在沙盒环境刷新之后尽快调整脚本的部署,尤其是定时类型的脚本,比如MapReduce和Scheduled。

Last modified: 19/12/2023

Author

Comments

Write a Reply or Comment

Your email address will not be published.