Offline computing task submission instructions - Dataphin

Upon completing the development and submission of an offline computing task, the Dataphin system automatically analyzes the data lineage of tables and fields within the task, verifies the task object's change type and content, and conducts a preliminary check to ensure the task meets submission requirements, thereby reducing the likelihood of erroneous submissions.

Data lineage parsing instructions

Data lineage parsing instructions The system analyzes the data lineage in the development environment upon task submission and in the production environment upon task publication. The number of data lineage entries parsed is capped at 100,000 entries. Entries beyond this limit will not be recorded and will not appear in the asset catalog.

Submission details instructions

During the submission of an offline computing task, you can review the submission details, pre-check results, and enter remarks in the Submitting Log dialog box.

Submission content
The submission content includes the task object's name, type, change type, and details of the change. Information on the change encompasses basic information, computing code, runtime parameters, schedule configuration, schedule dependencies, runtime configuration, resource configuration.

Pre-check

The following pre-checks are performed during task submission. If any check item is incorrectly configured, the system will not support submission.

Check item	Description
Schedule dependencies	Dataphin optimizes business data output by systematically executing each process node according to the configured schedule dependencies. For more information, see Configure offline task schedule dependencies and .
Runtime parameters	Runtime parameter configuration is essential for assigning values to variables within the code of a computing task, facilitating node scheduling. These parameter variables are designed to be automatically substituted with their respective values. For additional details, refer to Parameter configuration and node parameter usage and .
Cross-node parameters	Pass-through parameters to direct descendant nodes of the current object node. For more information, see Parameter configuration and use of node parameters.

Submission remarks
Allows for the inclusion of remarks with the task submission, limited to 128 characters.

Check item instructions

After submitting an offline computing task, you can view the check items and their results in the Submitting Log dialog box.

Check item	Description
Configuration check	Checks include pre-check, code length, number of referenced resources, and offline code template version. Pre-check: Verifies completion of all required properties. Code length: Ensures the code does not exceed 100,000 characters; otherwise, submission is not supported. Number of referenced resources: Checks if the number of resources referenced is within the limit of 100 resources. Offline code template version: Checks for changes in the offline code template version.
Parameter configuration	All variables in the code are parsed and listed, including parameter name, type, and current value. Checks if local variables have been assigned values.
Syntax check	For SQL tasks, verifies the correctness of SQL syntax. Submissions with errors are not supported.
Object check	For SQL tasks, checks if all referenced objects are submitted and published to the production environment. Lists all referenced objects in the code, including name, type, and check result. Object name: The format is `[catalog].[object name]`. Project space name variable: If `catalog` is a variable `${catalog}`, then `catalog` refers to the production space name. Hard coding: Directly written space names in the code are taken as is. If omitted, the system defaults to `${catalog}`. Omitting catalog: Defaults to the `${catalog}` variable when omitted. Object type: Checked types include physical tables, fields, and logical tables. Check result: Indicates success or failure. Success: All objects are submitted and published to the production environment. Note If the catalog is hard-coded, the system will verify the existence of objects only within the specified environment. Failure: Objects not submitted or published, or fields not existing in the checked objects, will result in failure. Note The check will fail if it encounters fields absent in the objects under scrutiny.
Permission check	All objects in the code are parsed to display whether the user has the necessary operation permissions, including object name, type, check result, and permission request operation. Object name: The format is `[catalog].[object name]`. Project space name variable: If `catalog` is a variable `${catalog}`, then `catalog` refers to the production space name. Hard coding: Directly written space names in the code are taken as is. If omitted, the system defaults to `${catalog}`. Omitting catalog: Defaults to the `${catalog}` variable when omitted. Object type: Checked types include physical tables, global objects, and logical tables. Check result: Indicates success or failure. Success: The user has read/write permissions for the checked objects. Note When the object is a table, it is necessary to have permissions for all referenced fields. Failure: The user lacks read/write permissions for the checked objects. Permission request: Should the check object encounter a failure, you may single click to initiate a permission request. For detailed instructions, see Request permissions or .
Specification check	For SQL tasks, the system performs a scan based on predefined specifications and presents the results for each check. For more information, see Coding specifications and .
Code review	The system automatically checks for configurations that require a code review within the task. If such configurations are present, as in the case of referencing a global variable with code review requirements, a code review will be mandated. For more information, see View built-in approval templates or .
Dependency check	The system evaluates the task's dependency and output configurations. Dependency configuration: Verifies the existence of dependency node objects configured for the task in the development environment. Output configuration: Checks for duplicate task output names within the current tenant.
Operation execution	This check confirms the task submission has been executed. During this phase, the submission cannot be revoked.