How to create a service project in Dataphin-Dataphin(Dataphin)-阿里云帮助中心

A service project is the basic organizational unit in DataService Studio and serves as the primary boundary for multi-user isolation and access control. You need a service project before you can use DataService Studio.

Permissions

Super administrators and system administrators can create and manage service projects and their members.
Project administrators can manage the projects and members that are assigned to them.

Create a service project

In the top menu bar of the Dataphin home page, choose Service > Service Management.
In the navigation pane on the left, click Project Management. On the Project Management page, click the +Create Service Project button in the upper-right corner.

In the Service Project Settings dialog box, configure the parameters.

Parameter	Description
Service Project Name	Enter a name for the service project. The name must meet the following requirements: It can contain Chinese characters, letters, digits, underscores (_), and hyphens (-). It must start with a Chinese character or a letter. It cannot exceed 32 characters in length.
Description	Enter a description for the service project. The description cannot exceed 128 characters in length.
API Release Control	When an API is published, five types of changes can affect normal calls to the API and its associated composite APIs: adding required request parameters, removing request parameters, removing response parameters, changing the data type of request parameters, and changing the call type. After an API is granted to an application or referenced by a composite API, a new version is compared with the online version before publishing. If any of these changes exist, you can configure a release control mechanism based on the project and API usage scenario. You can choose to block or allow publishing for the following two scenarios. API Is Authorized To Applications: The default is Block Publishing, which can be changed to Allow Publishing. API Is Referenced By Composite APIs: The default is Block Publishing, which can be changed to Allow Publishing. The following list describes the applicable scope of each release control combination. When API Is Authorized To Applications and API Is Referenced By Composite APIs are set to Block Publishing, new versions cannot be published if the API is attached to an application or referenced by a composite API. This ensures that downstream applications and composite APIs can be called as normal. This setting is suitable for important APIs with wide usage and significant impact, where publishing changes would seriously affect downstream systems. When API Is Authorized To Applications is set to Allow Publishing, and API Is Referenced By Composite APIs is set to Block Publishing, new versions cannot be published if the API is referenced by a composite API. This ensures that composite APIs can be called as normal. The developers must notify the owners of affected applications offline. This setting is suitable for scenarios where application owners can be promptly notified to adjust application call configurations after API changes are published. This ensures that applications can call the API as normal. Note If an API is referenced by other composite APIs and their owners cannot be notified to make corrections in time, publishing API changes is not allowed. This prevents the composite APIs from failing due to changes in the child API. When API Is Authorized To Applications is set to Block Publishing, and API Is Referenced By Composite APIs is set to Allow Publishing, new versions cannot be published if the API is attached to an application. This ensures that downstream applications can be called as normal. The developers must notify the owners of affected composite APIs offline. This setting is suitable for scenarios where you only need to ensure that downstream applications can call the API as normal. Note If an API is referenced by other composite APIs, the developers must inform the owners of those composite APIs to make corrections in time. This ensures that the composite APIs can be called as normal. When API Is Authorized To Applications and API Is Referenced By Composite APIs are set to Allow Publishing, new versions can be published. The developers must notify the owners of affected composite APIs and downstream applications. This setting is suitable for APIs with a small impact and few downstream users, where the business is not affected even if publishing changes causes the API to fail. The definition of release control criteria has changed. Users of versions earlier than 4.4 can refer to the following diagram to view the corresponding criteria.

Click Submit to create the service project.

Manage service projects

The Project Management page lets you add project members, create service project groups, and edit or delete service projects.

Operation	Description
Edit	Modify the project name, description, and API release control settings. Changes to API release control affect the release policy for new API versions.
Member Management	Add or remove members for the project and assign roles to them. For more information, see Add members and assign roles.
Group Management	Set up service units and API groups to organize the project. For more information, see Create service project groups.
Delete	Before you can delete the project, delete all dependent APIs, service units from the project.

What to do next

To have Resource Access Management (RAM) users assist with development, add them to the service project as members from the Dataphin member list and assign roles to them. For more information, see Add members and assign roles.