约束与限制

实例版本

AstroZero目前支持的实例版本有：免费版、标准版、专业版和专享版。

• 免费版：仅提供开发环境和开发零代码应用的运行环境，不提供低代码应用的运行环境。
• 标准版：适用于开发零代码应用，开发者不需要有任何代码开发经验。
• 专业版：适用于专业开发者，提供了开发环境和多租户共享的运行环境。
• 专享版：需要先提交工单申请开通专享版，才可以正常购买。专享版提供了开发环境和物理隔离的运行环境，即运行环境实例发放到租户虚拟私有云中。
• 申请AstroZero免费试用或购买AstroZero商用实例时，会同步创建一个Astro工作流免费基础版实例。

用户数

• 免费版：10个（包括业务用户），不支持扩展用户。
• 标准版：默认为30个（包括业务用户），支持扩展用户。
• 专业版：默认为30个（包括业务用户），支持扩展用户。
• 专享版：提供了500个、2000个和5000个用户数（包括业务用户）供选择。

变更AstroZero实例规格/类型

• 建议在业务低峰期变更实例，业务高峰期变更实例可能会失败。
• 免费版实例不支持升级规格。
• 标准版可以升级到专业版。
• 标准版、专业版无法升级到专享版，只能单独购买。
• 标准版、专业版可以直接回退到免费版，回退后不会删除数据，但是不支持访问运行环境。

命名空间个数

一个租户只能创建一个命名空间，且创建后不支持修改和删除。

命名空间名称

• 长度不能超过15个字符。
• 必须以英文字母开头，只能由英文字母、数字或单下划线组成，不能包含两条连续的下划线，且不允许以下划线结尾。

应用类型

在AstroZero中，支持创建标准应用、扩展应用、BO和原生服务四种类型的应用。

更多信息，请参见使用AstroZero创建应用概述。

应用名称

• 长度不能超过31个字符，包括前缀命名空间的长度。
• 必须以英文字母开头，只能由英文字母、数字或单下划线组成，且不允许以下划线结尾。

脚本命名

• 脚本采用小驼峰命名，例如createDeviceInstance。
• 结构体（struct）采用大驼峰命名，例如QueryPaymentResult。
• 结构体内的字段采用小驼峰命名，例如customerName 。
• 类、枚举值和接口采用大驼峰命名。
• 函数采用小驼峰命名。
• 属性或变量采用小驼峰命名。

脚本中注释

• 无用的代码不能以注释形式存在。
• 能用代码说明的尽量不要添加注释，脚本注释尽可能简洁。
• 建议注释统一用英文。
• 出入参不必写注释说明。

更多信息，请参见AstroZero脚本开发规则及约束限制。

脚本中引用

• 脚本中不要包含没用到的标准库或对象的引用。
• 只引用使用到的对象，而不用import *。
• @action.method属于必须的方法注解，写在方法上面。
• 为方便页面直接调用脚本，仅在脚本最后统一导出需要的对象，而不是导出所有对象。如果不需要，可以不用导出。
• 可以把公共的对象Object定义，按分类放在一些公共的脚本里（例如pc_XXX.ts、cm_XXX.ts），其他需要的脚本直接引用即可。

脚本定义

• 每个字段的定义，均需要定义type、label、description、required和isCollection，有默认值的非必填。
• 当字段为集合类型时，需要定义成“[]”。

  @action.param({
      type: "Attribute",
      label: "Attribute",
      description: "attributeList",
      required:false
      isCollection: true
  })
  attributeList: Attribute[];

• @action.object时，需要在脚本中详细定义清楚Object，不要引用其他脚本的Object。
• 如果是嵌套结构体，则从下到上粒度依次变小。

更多信息，请参见AstroZero脚本开发规则及约束限制。

脚本中SQL

• 不推荐用拼接SQL方法，避免注入风险。
• 多表复杂查询建议用“sql.exec()”或“sql.excute()”方法，“excute()”方法比“exec()”多返回字段集和操作成功数。
• 对于单表查询和增删改SQL，推荐使用Orm接口方法。
• 避免在循环中调用方法和操作数据库，可以用“in”来查询在集合中的结果。
• 对sql进行优化时，尽量使用有索引的字段，避免使用没有索引的字段。
• 批量操作数据库时，尽量使用已封装好的批量操作接口。
• 匹配查询推荐用like，日期比较推荐用“<”、“>”。
• 使用exists替代in，使用not exists替代not in。
• 避免在索引列上使用is null和is not null，会造成索引失效。

脚本调用

• 不允许在应用的脚本中，调用BO中的脚本。

  例如， 设备管理应用的脚本，不可调用设备BO内的任何脚本。

• 不允许跨BO，调用脚本。

  例如，人员BO中的脚本，不允许调用设备BO内的任何脚本。

服务编排命名

• 驼峰命名，首字母小写，不要携带下划线。
• 动宾结构，例如，notifyOrderCompletion，错误样例OrderCompletionNotification。
• 尽量不用缩写，除非是专有名词，例如，invokeCRM，错误样例paymentCbk。
• 应简单明了，表示业务意义，而不是内部实现。例如createPayment，错误样例InsertAndUpdatePayData。
• 长度不能超过64个字符，名称必须以英文字母开头，只能由英文字母、数字或单下划线组成，且不能以下划线结尾。

变量命名

• 输入变量和输出变量：命名遵循接口设计文档的要求。
• 内部变量：元素命名遵循驼峰命名原则。
• 变量为单数时，命名包含对象名称（如Level1Catalog、Level2Catalog），变量为复数时命名包含集合名称（如Level1CatalogList或者Level2CatalogArray）。
• 数组型变量的下标命名要符合规范，当使用I、J、K等字母来命名时，需要明确变量含义，勿重复使用。

图元命名

采用动词和名词短语的形式，每个单词首字母大写，单词之间有空格。名称一般不要超过五个单词，短语尽可能简明，描述该图元的主要作用，例如Valid Input、Call Device Service。

连接线命名

在服务编排的图元中，除了Decision连接线外，其他图元的连接线采用系统的固定命名。

Decision连接线名称使用英文，采用单词首字母大写，一般不要超过三个单词。采用动词和名词短语的形式，尽可能简明、准确的描述该条件的判断逻辑。

图元编排

为了服务编排画布排版美观以及方便后续的服务编排检视，服务编排的图元编排遵循以下原则：

• 在配置服务编排前，需明确具体步骤和子流程的分解，合理编排图元。
• 业务逻辑采用自上而下、从左往右的页面布局方式，业务逻辑展示清晰，同一任务多个步骤，横向排列，不同任务之间竖向排列。利用横向和竖向，做到层次缩进。
• Decision图元里的Default改为表示主流程，类似于If Error Else MainProcess这种结构，把异常处理优先标出。
• 在同一个版面中，图元之间的间隔大小相同。
• 尽量避免连接线相互交叉。
• 创建或查询较复杂的父子对象结构场景（如创建订单和相关对象），应将父对象和典型子对象的创建和查询编排到子流程中，供多个流程共享。
• 对于服务编排中常用到的业务功能（如获取Offer实例），可以考虑编排到子流程或用脚本实现，供多个流程共享。
• 编排每个服务编排时，首先都应该设置入参校验步骤，图元类型为“Decision”，分支优先考虑异常场景。服务编排流程中，其他的“Decision”图元也要首先考虑异常场景。
• 避免使用循环套循环。
• 不允许在子流程中结束，所有结束出口应在最外层服务编排中体现。子流程中，应始终返回出参。

参数定义

• 服务编排的入参和出参，需要根据设计文档做必填参数校验。
• 出入参数需要定义清楚每个字段。如果存在结构体，结构体中也应定义清楚每个字段。除了本身是预留的定制扩展的结构体之外，不允许有空结构的结构体。
• 服务编排中，暴露给用户由用户输入的参数，必须放到服务编排的“入参”中。服务编排中，不能存在用户能够使用但不在“入参”及“出参”的参数。

调用约束

• 不允许在应用项目的服务编排中，调用BO的内部服务编排。
• 不允许在应用项目的服务编排中，编排调用BO的脚本。
• 不允许跨BO调用脚本和内部服务编排。

  例如，人员BO的服务编排不允许调用空间BO的内部服务编排和脚本。

应用安装包

• 资产包：资产包一般用于测试、部署或正式运行，支持在开发环境（不能安装开发者自己开发的资产包）、沙箱环境以及运行环境中安装使用。
• 安装包：适用于初次和大的变更打包。
• 补丁包：适用于问题修复类打包变更。
• 源码包：主要用于同一账号内，在不同环境之间的资产迁移，以源环境的状态继续开发（类似自己代码仓库），或者用于备份账号自己的代码，以便在需要恢复时使用。