A service project is the basic organizational unit in DataService Studio and the primary boundary for multi-user isolation and access control. You must use service projects to work with DataService Studio. This topic describes how to create and manage service projects.
Prerequisites
You must configure a gateway before you can create a service project. For more information, see DataService Studio settings.
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 brief description of 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 the normal calls to the API and its associated composite APIs. These changes are adding required request parameters, removing request parameters, removing response parameters, changing the data type of request parameters, and changing the call type. Therefore, after an API is granted to an application or referenced by a composite API, a new version of the API is compared with the online version before it is published. If any of the preceding changes exist, you can configure a release control mechanism for the API 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 different release control mechanisms.
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.
NoteIf 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.
NoteIf 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
On the Project Management page, you can 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 information. Changes to API release control affect the release policy of 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 for the project to facilitate project management. For more information, see Create service project groups. |
Delete | Before you can delete the project, you must delete all dependent APIs, service units from the project. |
What to do next
If you need Resource Access Management (RAM) users to 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.