A service project is the foundational organizational unit within a data service, serving as the primary boundary for multi-user isolation and access control. Utilizing a service project is essential for leveraging data services. This topic describes the process for creating and managing service projects.
Prerequisites
You can only create a service project once the gateway configuration is complete. For gateway configuration instructions, see Data service settings.
Limits
Only super administrators are authorized to create service projects.
Create a new service project
On the Dataphin home page, select Service > Management from the top menu bar.
Click Project Management in the left-side navigation pane. On the Project Management page, click the + New Service Project button in the upper-right corner.
In the Service Project Settings dialog box, enter the required parameters.
Parameter
Description
Service Project Name
Enter the name of the service project. The name must meet the following requirements:
Contains Chinese characters, letters, numbers, underscores (_), and hyphens (-).
Starts with a Chinese character or a letter.
Cannot exceed 32 characters.
Description
Provide a brief description of the service project. The description cannot exceed 128 characters.
API Release Control
During the process of releasing an API for online use, there are five change scenarios (adding required request parameters, removing request parameters, removing return parameters, changing the data type of request parameters, and changing the invocation type) that can affect the normal invocation of the API and associated composite APIs. Therefore, when an API is authorized to an application or referenced by a composite API, and a new version of the API is released online, it will be compared with the online version. If any of the above changes exist, you can flexibly configure the release control mechanism for APIs under different projects based on the API usage scenarios. Below are the specific control items for release control, where you can choose to block or allow the release for these two situations.
API Authorized To Application: The default is Block Release, but it can be changed to Allow Release.
API Referenced By Composite API: The default is Block Release, but it can be changed to Allow Release.
The scope of application for different release control mechanisms is described as follows.
When API Authorized to Application and API Referenced by Composite API are set to Block Release, the API cannot be released online when it is bound to an application or referenced by a composite API, ensuring the normal invocation of downstream applications and composite APIs. This is suitable for important APIs with a wide usage range and significant impact. If changes are released online, they can severely affect downstream, and interception is possible.
When API Authorized to Application is set to Allow Release, API Referenced by Composite API is set to Block Release, the API cannot be released online when referenced by a composite API, ensuring the normal invocation of the composite API. The affected application is notified offline by the developer to the corresponding owner. This is suitable for situations where the API change is released online, and the application owner can be promptly notified to adjust the application invocation configuration, ensuring the normal invocation of the API.
NoteIf the API is referenced by other composite APIs and the owner of the composite API cannot be notified in time to correct the composite API, to avoid issues where changes to the factor API prevent the composite API from being invoked normally, the API change is not allowed to be released online.
When API Authorized to Application is set to Block Release, API Referenced by Composite API is set to Allow Release, the API cannot be released online when bound to an application, ensuring the normal invocation of downstream applications. The affected composite API is notified offline by the developer to the composite API owner. This is suitable for ensuring only the normal invocation of downstream applications.
NoteIf the API is referenced by other composite APIs, the developer informs the corresponding composite API owner to promptly correct the composite API to ensure its normal invocation.
When API Authorized to Application and API Referenced by Composite API are set to Allow Release, new versions can be released online. The affected composite API and downstream applications are notified by the developer to the corresponding owner. This is suitable for APIs with a small impact range and less downstream usage, where even if changes are released online causing the API to be unable to be invoked normally, it does not affect the business.
The definition of release control changes, users before version 4.4 can refer to the following diagram to view the corresponding definitions.
Click Submit to finalize the creation of the service project.
Manage service projects
On the Project Management page, you can add project members, create service project groups, edit or delete service projects, among other management tasks.
Operation | Description |
Edit | Support modifying the project's name, description, and API release control information. Changes to API release control will affect the release policy of new version APIs. |
Member Management | Support adding or deleting members for the project and setting roles for them. For more information, see Add members and set roles. |
Group Management | Support setting service units, applications, and API groups for the project to facilitate project management. For more information, see Create service project groups. |
Delete | You must delete the APIs, applications, service units, and resource groups that the project depends on before you can delete the project. |
What to do next
If you need RAM users to assist with development, you can add RAM users from the Dataphin member list as members of the service project and set roles for them. For specific operations, see Add members and set roles.