Dataset submission-阿里云帮助中心

When you configure and submit a dataset, Dataphin checks the objects and permissions it references to ensure it meets submission requirements and to reduce submission errors. This topic describes the submission and publishing instructions for offline, real-time, and API datasets.

Limitations

Datasets can currently be created only in Basic projects. A Basic project has only a production environment, so submitting a dataset is equivalent to publishing it to the production environment. No separate publishing operation is required.

Offline and real-time dataset submission

After you configure the dataset, click Submit. The system automatically performs the following checks. You can view the results in the Submit Log dialog box.

Check	Description
object check	Checks whether the data source, file storage path, and the target table for metadata storage exist. If any of these do not exist, the submission fails.
permission check	Checks whether you have execution permissions for the selected data source. If you do not have the required permissions, the submission fails.

API dataset submission

You must configure and then submit an API dataset. The dataset can provide HTTP API services only after its bound online workflow is published.

Check	Description
object check	Checks whether the API dataset name is unique within the project, whether the selected Data Service project, API group, and referenced data source exist and are accessible, and whether an API dataset with the same name but a different source already exists in the target environment.
permission check	Checks whether the current project has read and write permissions for the referenced OSS or Amazon S3 data source. Checks whether the current project has been granted the Online Workflow Integration role by the target Data Service project. This check is skipped if the target is the preset Unstructured Online Service project. For any failed checks, you can click Request Permission to navigate to the corresponding page and apply for the required permissions.
API publishing control	In a Basic project, submitting a dataset is equivalent to publishing it to the production environment. When you submit the dataset, a check for breaking changes is performed. This check runs only if an online version of the API already exists and the current submission is an incremental update. The system detects if the new version introduces any breaking changes compared to the online version. Breaking changes include adding a required request parameter, removing a request parameter, removing a response parameter, changing the data type of a request parameter, or changing the invocation type. If a breaking change is detected and the API has been granted to an application or is referenced by a composite API, the system determines whether to block the submission based on the API publishing control configuration of the target Data Service project. The details of the changes and their impact are also displayed. If the target is the preset Unstructured Online Service project, the submission is allowed by default. Service project administrators can edit the API publishing control configuration for the target service project in Data Service > Service Management > Project Management.

After a successful submission, the system automatically generates an API ID and the gateway registers a route for this version in the production environment. The status of the API dataset changes from draft to published. At this point, the binding status of this version is UNBOUND. You can call this version only after submitting the online workflow that binds to it. The latest published version with a BOUND status becomes the online version. After you publish the bound online workflow, the system updates the online version identifier for this version.

Each version of an API dataset has its own binding status. Only versions with a BOUND status can be called. The binding statuses include:

UNBOUND: The version has been submitted and its route is registered with the gateway, but no online workflow binds to its backend service. Calling this version returns a 503 error.
BOUND: Once an online workflow is submitted and its backend service is registered with the gateway, you can call this version normally.

Referenced workflows

In the Referenced Workflow section on the dataset tab, you can view information about the online workflow that is bound to the current version. This information includes the workflow name (click to navigate to the workflow canvas configuration page), status, binding status, owner, description, and last published time. An API dataset version has a one-to-one binding with an online workflow, so only one record is displayed for each version.