Restrictions

Instance edition

Huawei Cloud Astro Zero offers three instance editions: free, standard, and professional.

• Free: provides development and runtime environments for no-code applications. No runtime environment for low-code applications.
• Standard: applies to no-code application development. No coding experience is needed.
• Professional: provides a development environment and a tenant-shared runtime environment, ideal for professional developers.

Users (portal users included)

• Free: 10. The user quota cannot be increased.
• Standard: 30 by default. The user quota can be increased.
• Professional: 30 by default. The user quota can be increased.

Changing Huawei Cloud Astro Zero instance specifications or type

• You are advised to change instances during off-peak hours. Otherwise, the change may fail.
• Free instances cannot be upgraded.
• Standard instances can be upgraded to professional.
• Standard or professional instances can be downgraded to free. Data remains, but runtime access is unavailable.

Supported region

CN North-Beijing4

Quantity

A tenant can create one namespace, which cannot be modified or deleted once created.

Namespace name

• Max. characters: 15.
• Start with a letter and use only letters, digits, and underscores (_). Avoid two underscores (_) in a row or ending with an underscore (_).

Application type

Huawei Cloud Astro Zero supports four types of applications: standard, add-on, BO, and native service.

For details, see Creating Applications.

Application name

• Max. characters: 31, including the prefix namespace.
• Start with a letter and use only letters, digits, and underscores (_). Do not end with an underscore (_).

Script naming

• The script is named in lower camel case, for example, createDeviceInstance.
• The structure is named in upper camel case, for example, QueryPaymentResult.
• Fields in the structure are named in lower camel case, for example, customerName.
• Classes, enumerated values, and APIs are named in upper camel case.
• Functions are named in lower camel case.
• Attributes or variables are named in lower camel case.

Comments in scripts

• Unnecessary code cannot exist in the form of comments.
• Do not add comments for code description. Script comments should be as concise as possible.
• It is recommended that comments be in English.
• Comments are not required for input and output parameters.

For details, see Script Development Rules and Restrictions.

References in scripts

• Avoid unnecessary references to standard libraries or objects in scripts.
• Only the used objects are referenced, and import * is not required.
• @action.method is a mandatory method annotation and is written above the method.
• To facilitate script calling on pages, only the required objects are exported at the end of a script.
• Common object definitions can be placed in some common scripts (such as pc_XXX.ts and cm_XXX.ts) by category. Other required scripts can be directly referenced.

Script definition

• The type, label, description, required, and isCollection fields must be defined. The fields with default values are optional.
• If the field is of the set type, define it as [].

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

• When @action.object is used, clearly define the object in the script and do not reference the object of other scripts.
• If the structure is nested, the granularity decreases from bottom to top.

For details, see Script Development Rules and Restrictions.

SQL statements in scripts

• You are not advised concatenating SQL statements to avoid injection risks.
• For complex multi-table queries, use either sql.exec() or sql.excute(). excute() returns more field sets and success operations.
• For single-table queries and add, delete, and modify SQL operations, use the Orm API method.
• Avoid calling methods or performing database operations in a loop. Instead, use in to query results in the collection.
• When optimizing SQL statements, use fields with indexes.
• When performing batch database operations, use the encapsulated batch APIs whenever possible.
• Use like for match query, and < and > for date comparison.
• Replace in with exists and replace not in with not exists.
• Avoid using is null or is not null in an index column. Otherwise, the index becomes invalid.

Script calling

• Scripts in BOs cannot be called by application scripts.

  For example, the script of the device management application cannot call any script in the device BO.

• Cross-BO script calling is not allowed.

  For example, a script in the employee BO cannot call any script in the device BO.

Flow naming

• Use lower camel case without underscores (_).
• Use verb-object structure, e.g., notifyOrderCompletion. Incorrect: OrderCompletionNotification.
• Avoid abbreviations unless they are proper nouns, e.g., invokeCRM. Incorrect: paymentCbk.
• Names should be simple, clear, and reflect business meaning, not just internal implementation, e.g., createPayment. Incorrect: InsertAndUpdatePayData.
• Max. 64 characters. Start with a letter and use only letters, digits, and underscores (_). Do not end with an underscore (_).

Variable naming

• The names of input and output variables must adhere to the API design document.
• For internal variables, element names follow the CamelCase naming style.
• For a single variable, names contain the object name (e.g., Level1Catalog and Level2Catalog). For a set of variables, names contain the set name (e.g., Level1CatalogList or Level2CatalogArray).
• Array variable subscript names must adhere to specified requirements. When using letters like I, J, and K for variable names, clearly define their meanings and avoid repetition.

Diagram element naming

Use verb-noun phrases. Capitalize the first letter of each word and separate words with spaces. Diagram element names should be concise, contain no more than five words, and clearly describe the element's main function, e.g., Valid Input or Call Device Service.

Connection line naming

In flow diagrams, all element connection lines except Decision connection line use predefined fixed names.

Decision connection line name must be in English, with the first letter of each word capitalized, and should contain a maximum of three words. Use verb-noun phrases to concisely and accurately describe the condition's judgment logic.

Diagram element orchestration

To maintain a neat flow canvas layout and ease subsequent reviews, flow diagram element arrangement follows these principles:

• Before configuring a flow, specify the steps and sub-flows, and orchestrate diagram elements properly.
• Service logic is displayed top-to-bottom and left-to-right, ensuring clarity. Same-task steps are arranged horizontally, while different tasks are arranged vertically. Use horizontal and vertical indentation for hierarchical structure.
• Default in the Decision diagram element indicates the main flow, which is similar to the If Error Else MainProcess structure. The exception handling is marked first.
• Ensure consistent spacing between diagram elements on the same panel.
• Avoid intersecting connection lines.
• In scenarios involving complex parent-child object structures (e.g., creating an order and related objects), arrange the creation and query of the parent object and key sub-objects as a reusable sub-flow for multiple flows.
• Common service functions, like obtaining the offer instances, can be arranged in sub-flows or implemented via scripts for sharing across multiple flows.
• When orchestrating each flow, first configure the input parameter verification step using a Decision diagram element, prioritizing exception scenarios in branches. Other steps using the Decision diagram element must also consider the exception scenarios.
• Avoid loop-within-loop.
• Sub-flows must not be the final step; all end exits should be in the outermost flow. Sub-flows must always return output parameters.

Parameter definition

• Flow input and output parameters must be verified according to the design document.
• Each field in input and output parameters must be clearly defined. If a structure is present, define each field within it. Empty structures are not allowed, except for structures reserved for custom extensions.
• In flows, parameters exposed to and entered by users must be placed in the flow's input parameters. Flows cannot contain parameters that can be used by users but are not included in the input or output parameters.

Calling

• BO flows cannot be called by application flows.
• BO scripts cannot be called by application flows.
• Cross-BO flow and script calls are not allowed.

  For example, a flow of the personnel BO cannot call the flow and scripts in the space BO.

Application installation package

• Asset packages are for testing, deployment, and production. They can be installed in development, runtime, and sandbox environments. Note that developers cannot install their own developed asset packages.
• Installation packages are for initial deployments and significant updates.
• Patch packages are for minor fixes and updates.
• Source packages are mainly used to migrate assets between different environments of the same account for continuous development as in the source environment (similar to the tenant's code repository) or back up the account's code for restoration.