WO2024078366A1

WO2024078366A1 - Data management method, server, client and system

Info

Publication number: WO2024078366A1
Application number: PCT/CN2023/122848
Authority: WO
Inventors: 冯冲; 马秋方
Original assignee: 华为技术有限公司
Priority date: 2022-10-11
Filing date: 2023-09-28
Publication date: 2024-04-18
Also published as: CN117880075A

Abstract

The present application belongs to the technical field of communications. Disclosed are a data management method, a server, a client and a system. The method comprises: a server receiving a first data request, wherein the first data request carries an object identifier; and the server managing a first data set on the basis of the object identifier. A first data request sent by a client to a server carries an object identifier, the object identifier indicates a first data set, and the first data set is a custom data set which is created for a first task; therefore, after the first data request is received, the server can manage, on the basis of the object identifier, the first data set corresponding to the first task. That is, the client instructs, according to a task requirement, the server to create a custom data set, wherein one task corresponds to one custom data set, and custom data sets are independent of each other and do not affect each other.

Description

Data management method, server, client and system

This application claims priority to Chinese patent application No. 202211241732.0 filed on October 11, 2022, entitled “A method and device for data processing”, and claims priority to Chinese patent application No. 202211516827.9 filed on November 29, 2022, entitled “Data management method, server, client and system”. The entire contents of the above patent applications are incorporated into this application by reference.

Technical Field

The present application relates to the field of communication technology, and in particular to a data management method, a server, a client, and a system.

Background technique

The network configuration protocol (NETCONF) is a mechanism for managing the server side. Administrators can use this mechanism to manage the server side through the client. Configuration management includes adding, modifying, and deleting server side configuration data.

NETCONF defines that the server side includes a running data set and a candidate data set. After the client establishes a session connection with the server side, when the client executes multiple tasks at the same time, each of the multiple tasks will perform configuration management on the server side and update the configuration data to the candidate data set. In this way, when the configuration data corresponding to a task is submitted to the running data set, the configuration data corresponding to other tasks will also be passively submitted to the running data set. Similarly, when the configuration data corresponding to the task is rolled back, that is, when the configuration data corresponding to the task is restored to the state before the modification, the configuration data corresponding to other tasks will also be cleared.

Summary of the invention

The present application provides a data management method, a server, a client, and a system, which can enable the server to manage only the first data set corresponding to the first task, and not the data sets corresponding to other tasks. The technical solution is as follows:

In a first aspect, a data management method is provided, the method comprising:

The server receives a first data request, which carries an object identifier indicating a first data set. The first data set is a custom data set created for the first task. The custom data set is used to store data used by the client to manage the server. The server manages the first data set based on the object identifier.

Since the first data request sent by the client to the server carries an object identifier, the object identifier indicates the first data set and the first data set is a custom data set created for the first task, so after receiving the first data request, the server can manage the first data set corresponding to the first task based on the object identifier. That is, the client instructs the server to create a custom data set according to the task requirements, one task corresponds to one custom data set, and each custom data set is independent of each other and does not affect each other. In this way, when the client executes a task, it only needs to send a data request carrying the corresponding object identifier to the server, so that the server can manage the data set corresponding to the task based on the object identifier carried by the data request, and will not manage the data sets corresponding to other tasks.

The object identifier is an identifier of the first data set, or the object identifier is an identifier of the first task.

Based on the above description, the management of the first data set by the server includes any one of the operations of creating the first data set, editing the data in the first data set, submitting the first data set, or deleting the first data set. In the case where the information indicated by the first data request is different, the server manages the first data set in different ways based on the object identifier, which will be described in the following four cases.

In the first case, the first data request instructs the server to create a first data set, and the first data request also carries the type of the first data set. At this time, the server determines whether the first data set meets the data set creation condition based on the object identifier. If the first data set meets the data set creation condition, the server creates the first data set based on the object identifier and the type of the first data set. If the first data set does not meet the data set creation condition, the server sends a data set creation failure message to the client.

For example, the data set creation condition includes: the data set created by the server does not include the first data set.

After receiving the first data request sent by the client, the server queries whether the first data set exists in the created data sets based on the object identifier carried in the first data request. If the first data set exists in the created data sets, it indicates that the server has currently created The first dataset is created. At this time, the server sends a dataset creation failure message to the client. If the first dataset does not exist in the created datasets, it indicates that the server has not currently created the first dataset. At this time, the server creates a dataset whose identifier is the object identifier and whose type is the type of the first dataset, and sends a dataset creation success message to the client.

For example, the dataset creation condition includes: the total number of datasets created by the server is less than the maximum number of datasets. The maximum number of datasets is set in advance, for example, the maximum number of datasets is 15. Moreover, the maximum number of datasets can be adjusted according to different requirements.

After receiving the first data request sent by the client, the server determines the total number of datasets currently created. When the total number of datasets currently created is less than the maximum number of datasets, it indicates that the total number of datasets created by the server has not reached the maximum number of datasets that the server can support, that is, the server can continue to create datasets. At this time, the server creates a dataset whose identifier is the object identifier and whose type is the type of the first dataset, and sends a dataset creation success message to the client. When the total number of datasets currently created is not less than the maximum number of datasets, it indicates that the total number of datasets created by the server has reached the maximum number of datasets that the server can support, that is, the server cannot continue to create datasets. At this time, the server sends a dataset creation failure message to the client.

For example, the dataset creation condition includes: the datasets created by the server do not include the first dataset, and the total number of datasets created by the server is less than the maximum number of datasets. The detailed implementation process is referred to the above related description, which will not be repeated here.

For example, the first data request also carries the lifetime of the first data set. In this way, after the server creates the first data set based on the object identifier and the type of the first data set, it can also set the lifetime of the first data set to the lifetime carried by the first data request, so that the first data set can be deleted when the lifetime of the first data set is detected to have expired. Of course, in actual applications, there may also be a situation where the first data request does not carry the lifetime of the first data set. At this time, the server directly sets the lifetime of the first data set to the default lifetime. Among them, the default lifetime is set in advance, for example, the default lifetime is 1 day. Moreover, the default lifetime can also be adjusted according to different requirements.

The above content takes the example that the server sets the lifetime of the first data set to a fixed time length, and the time starts from the successful creation of the first data set, and the first data set is deleted when the time length is reached. For example, the server can also set a temporary tag for the first data set, and the temporary tag instructs the server to delete the first data set when submitting the first data set to the corresponding data set.

Optionally, when the client sends a first data request to the server to instruct the server to create a first data set, the first data request can also carry the identifier of the client. In this way, after the server creates the first data set, it can also create a correspondence between the client identifier, the object identifier, and the type of the data set based on the identifier of the client, the object identifier, and the type of the first data set. In this way, the various types of data sets created by each client instructing the server can be recorded through the correspondence.

The type of the first data set is used to indicate whether the type of the first data set is a candidate data set type or a dynamic data set type. Of course, in practical applications, the type of the first data set can also be other types, which is not limited in the embodiments of the present application.

In the second case, the first data request indicates that the first data set is to be deleted, and the first data request also carries the identifier of the client. At this time, the server determines whether the first data set meets the data set deletion condition based on the object identifier and the identifier of the client. If the first data set meets the data set deletion condition, the server deletes the first data set based on the object identifier. If the first data set does not meet the data set deletion condition, the server sends a data set deletion failure message to the client.

For example, the data set deletion condition includes: the first data set is created by the client instructing the server. Alternatively, the first data set is not created by the client instructing the server, but the client has management authority. Of course, in actual applications, the data set deletion condition may also include other conditions, which are not limited in the embodiments of the present application.

That is, clients without management rights only have the right to delete custom datasets that they instruct the server to create, but not the right to delete custom datasets that other clients instruct the server to create, thus avoiding passive deletion of custom datasets that other clients instruct the server to create. Clients with management rights can delete custom datasets that all clients instruct the server to create, thereby reducing resource usage.

Because the maximum number of datasets that the server can support is not unlimited, when the total number of datasets created on the server reaches the maximum number of datasets that the server can support, a client with management permissions can forcibly delete datasets whose lifetime has expired.

It should be noted that, in actual applications, the client may actively delete the first data set that it instructs the server to create. That is, after the client completes the first task and the first data set corresponding to the first task is no longer used, the client sends a first data request to the server, and the first data request instructs the server to delete the first data set.

In the third case, the first data request indicates to edit the data in the first data set, and the first data request also carries the first data to be edited, and the editing operation includes any one of adding, modifying, and deleting. At this time, the server performs the editing operation on the first data in the first data set based on the object identifier.

Based on the above description, the object identifier is the identifier of the first data set, or the object identifier is the identifier of the first task. In different cases, the server performs the editing operation on the first data set based on the object identifier in different ways, which will be described below respectively.

(1) The object identifier is the identifier of the first data set. After receiving the first data request sent by the client, the server performs an editing operation on the first data set based on the identifier of the first data set and the first data to be edited.

Optionally, the first data request may also indicate a query for data in the first data set. That is, when the client needs to query the data on the server, the client sends a first data request to the server, and the first data request carries the identifier of the first data set and query information. After receiving the first data request sent by the client, the server determines the first data set from the created data sets based on the identifier of the first data set, and then queries the relevant data in the first data set based on the query information, and sends a data query response to the client.

(2) The object identifier is the identifier of the first task. After receiving the first data request sent by the client, the server determines whether the first data set corresponding to the first task exists in the created data set based on the identifier of the first task. If the first data set exists, the server directly performs an editing operation on the first data set based on the identifier of the first task and the first data to be edited.

Optionally, the first data request also carries the type of the first data set, so that when the first data set does not exist and the total number of created data sets is less than the maximum number of data sets, the server first creates the first data set based on the identifier of the first task and the type of the first data set. Then, the server performs the editing operation on the first data set.

That is, when the server receives a first data request and the first data set does not exist in the created data sets, it creates the corresponding first data set for the first task in real time through implicit creation, so that the server performs editing operations on the first data set based on the first data to be edited.

It should be noted that after the server creates the first data set for the first task in real time according to the above method, it can also set a temporary tag for the first data set, which instructs the server to delete the first data set when submitting the first data set to the corresponding data set.

Of course, in actual applications, there may be a situation where the first data set does not exist in the data sets created by the server, but the total number of created data sets is not less than the maximum number of data sets. In this case, the server sends a data editing operation failure message to the client.

Optionally, the first data request may also indicate a query for data in the first data set. That is, when the client needs to query the data on the server, the client sends a first data request to the server, and the first data request carries the identifier of the first task and the query information. After receiving the first data request sent by the client, the server determines whether the first data set corresponding to the first task exists in the created data set based on the identifier of the first task. In the case where the first data set exists, the server directly determines the first data set from the created data set based on the identifier of the first task, and then queries the relevant data in the first data set based on the query information, and sends a data query response to the client. In the case where the first data set does not exist, the server queries the relevant data from the corresponding data set based on the type of the first data set, and sends a data query response to the client, and does not create the first data set based on the identifier of the first task and the type of the first data set.

In the fourth case, the first data request indicates that the server is to be configured. After receiving the first data request sent by the client, the server determines the type of the first data set based on the object identifier carried in the first data request. When the type of the first data set is a candidate data set type, the server submits the data stored in the first data set to the running data set based on the object identifier. When the type of the first data set is a dynamic data set type, the server submits the data stored in the first data set to the operating data set based on the object identifier.

In a second aspect, a data management method is provided, the method comprising:

The client sends a first data request, which carries an object identifier. The object identifier indicates a first data set. The first data set is a custom data set created for a first task. The custom data set is used to store data used by the client to manage a server. The first data request instructs the server to manage the first data set based on the object identifier.

Optionally, the first data request indicates to perform an editing operation on the data in the first data set, and the first data request also carries the first data to be edited, and the editing operation includes any one of adding, modifying, and deleting.

Optionally, the first data request indicates configuration of the server side, and the type of the first data set is a candidate data set type or a dynamic data set type.

Optionally, the first data request indicates deletion of the first data set, and the first data request also carries an identifier of the client.

Optionally, the first data request instructs the server to create a first data set, and the first data request also carries the type of the first data set.

Optionally, the first data request also carries the lifetime of the first data set.

In a third aspect, a data management device is provided, wherein the data management device has the function of implementing the data management method in the first aspect. The data management device includes at least one module, and the at least one module is used to implement the data management method provided in the first aspect.

That is, a data management device is provided, which is applied to a server side and includes:

A receiving module, configured to receive a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for a first task, and the custom data set is used to store data used by a client to manage a server;

The management module is used to manage the first data set based on the object identifier.

Optionally, the object identifier is an identifier of the first data set, or the object identifier is an identifier of the first task.

Optionally, the first data request indicates to perform an editing operation on the data in the first data set, and the first data request further carries the first data to be edited, and the editing operation includes any one of adding, modifying, and deleting;

The management module is specifically used for:

Based on the object identifier, an editing operation on the first data set is performed on the first data set.

The management module is specifically used for:

In a case where it is determined based on the object identifier that the first data set exists, an editing operation on the first data is performed on the first data set based on the object identifier.

Optionally, the first data request further carries the type of the first data set, and the management module is specifically configured to:

If it is determined based on the object identifier that the first data set does not exist and the total number of data sets created on the server is less than the maximum number of data sets, create the first data set based on the object identifier and the type of the first data set;

An editing operation on the first data is performed on the first data set.

Optionally, the first data request indicates configuration of the server side, and the type of the first data set is a candidate data set type;

The management module is specifically used for:

Based on the object identifier, the data stored in the first data set is submitted to the running data set.

Optionally, the first data request indicates configuration of the server side, and the type of the first data set is a dynamic data set type;

The management module is specifically used for:

Based on the object identifier, the data stored in the first data set is submitted to the operation data set.

Optionally, the first data request indicates to delete the first data set, and the first data request also carries an identifier of the client;

The management module is specifically used for:

When it is determined that the first data set meets the data set deletion condition based on the object identifier and the identifier of the client, the first data set is deleted based on the object identifier.

Optionally, the data set deletion condition includes: the first data set is created by the server side at the instruction of the client; or the first data set is not created by the server side at the instruction of the client, but the client has management authority.

Optionally, the first data request instructs the server to create a first data set, and the first data request also carries a type of the first data set;

The management module is specifically used for:

When the first data set meets the data set creation condition, the first data set is created based on the object identifier and the type of the first data set.

Optionally, the data set creation condition includes: the data set created on the server side does not include the first data set.

Optionally, the data set creation condition further includes: the total number of created data sets is less than the maximum number of data sets.

Optionally, the first data request further carries a lifetime of the first data set; and the apparatus further comprises:

The first setting module is used to set the lifetime of the first data set to the lifetime carried in the first data request.

Optionally, the device further comprises:

The second setting module is used to set the lifetime of the first data set to a default lifetime.

Optionally, the device further comprises:

The deleting module is used to delete the first data set when it is detected that the lifetime of the first data set expires.

Optionally, the client performs configuration management on the server through a network configuration management protocol, where the network configuration management protocol includes but is not limited to the network configuration protocol NETCONF, the expressive state transfer configuration protocol RESTCONF, and the constraint application protocol management interface CORECONF.

In a fourth aspect, a data management device is provided, wherein the data management device has the function of implementing the data management method in the second aspect. The data management device includes at least one module, and the at least one module is used to implement the data management method provided in the second aspect.

That is, a data management device is provided, which is applied to a client and includes:

A sending module is used to send a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for a first task, the custom data set is used to store data used by the client to manage the server, and the first data request instructs the server to manage the first data set based on the object identifier.

Optionally, the first data request indicates to delete the first data set, and the first data request also carries an identifier of the client.

In a fifth aspect, a server is provided, the server comprising a memory and a processor, the memory being used to store a computer program for executing the data management method provided in the first aspect. The processor is configured to execute the computer program stored in the memory to implement the data management method described in the first aspect.

Optionally, the server side may further include a communication bus, and the communication bus is used to establish a connection between the processor and the memory.

In a sixth aspect, a client is provided, the client comprising a memory and a processor, the memory being used to store a computer program for executing the data management method provided in the second aspect. The processor is configured to execute the computer program stored in the memory to implement the data management method described in the second aspect.

Optionally, the client may further include a communication bus, and the communication bus is used to establish a connection between the processor and the memory.

In a seventh aspect, a data management system is provided, the data management system comprising a server and a client. The server is used to implement the steps of the data management method provided in the first aspect, and the client is used to implement the steps of the data management method provided in the second aspect.

In an eighth aspect, a computer-readable storage medium is provided, wherein the storage medium stores instructions, and when the instructions are executed on a computer, the computer executes the steps of the data management method described in the first aspect or the second aspect.

In a ninth aspect, a computer program product comprising instructions is provided, and when the instructions are executed on a computer, the computer is caused to execute the steps of the data management method described in the first aspect or the second aspect. In other words, a computer program is provided, and when the computer program is executed on a computer, the computer is caused to execute the steps of the data management method described in the first aspect or the second aspect.

The technical effects obtained in the above-mentioned second to ninth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a business scenario provided in an embodiment of the present application;

FIG2 is a schematic diagram of another business scenario provided in an embodiment of the present application;

FIG3 is a schematic diagram of the architecture of a data management system provided in an embodiment of the present application;

FIG4 is a flow chart of a data management method provided in an embodiment of the present application;

FIG5 is a schematic diagram of a data management process provided in an embodiment of the present application;

FIG6 is a schematic diagram of the structure of a data management device provided in an embodiment of the present application;

FIG7 is a schematic diagram of the structure of another data management device provided in an embodiment of the present application;

FIG8 is a schematic diagram of the structure of a communication device provided in an embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

To facilitate understanding, some nouns and terms involved in the embodiments of the present application are first explained.

YANG (yet another next generation): a data modeling language for NETCONF.

YANG model: A data model built using the YANG data modeling language is called a YANG model. YANG models can be maintained by clients and servers. YANG models express server-side data in the form of data nodes. Data instantiated using the YANG model can be stored in the encoding format of the extensible markup language XML (Extensible Markup Language).

Client/server (C/S) architecture: network management equipment, management equipment or controller is the client, and network equipment (such as routers, switches, bridges and other network element devices) is the server. In the embodiment of the present application, the client and the server communicate based on the network configuration management protocol. The network configuration management protocol includes but is not limited to NETCONF, representational state transfer configuration protocol (RESCONF), and constrained application protocol management interface (CORECONF).

Candidate data set: A configuration data set used by the server to store configuration data that has been configured but not yet effective.

Running data set: A configuration data set used by the server to store the configured and effective configuration data.

Dynamic data set: A data set used to store dynamic data on the server side, such as routing information and forwarding tables.

Operational data set: A data set used to store operational data on the server side, including configuration data, routing information, forwarding tables, status information, various statistical data, and other derived data that are effective on the task.

Secondly, the business scenarios involved in the embodiments of the present application are introduced.

The data management method provided in the embodiment of the present application can be applied to a variety of scenarios, for example, a scenario in which multiple tasks of the client are performed in parallel, that is, a client performs multiple tasks at the same time. As shown in Figure 1, client 1 performs tasks 1, 2, and 3 at the same time. Task 1 involves business A and business B, task 2 involves business B and business C, and task 3 involves business C and business D. Client 1 creates custom data set 1 for task 1, custom data set 2 for task 2, and custom data set 3 for task 3 through the method provided in the embodiment of the present application. Then, client 1 sends three data requests to the server respectively to manage the three custom data sets respectively.

For another example, a scenario where a server accesses multiple clients, each of which performs a task. As shown in FIG2 , client 1, client 2, and client 3 all establish a session connection with the server. Among them, client 1 and client 2 currently need to manage the data on the server, and client 3 currently needs to query the data on the server. That is, the task of client 1 is used to manage the data on the server, the task of client 2 is also used to manage the data on the server, and the task of client 3 is used to query the data on the server, so client 1 and client 2 instruct the server to create custom data sets corresponding to their respective tasks through the method provided in the embodiment of the present application, so as to obtain custom data set 1 and custom data set 2. In this way, different data management tasks from different clients correspond to different custom data sets, so that the server can subsequently manage the data sets corresponding to the corresponding data management tasks based on the identifiers of each custom data set or the identifiers of each task. In addition, since the task of client 3 is used to query the data on the server, client 3 does not need to request the server to create a custom data set corresponding to the data query task, that is, each client can create a custom data set corresponding to each task according to demand.

Finally, the system architecture involved in the embodiments of the present application is introduced.

Please refer to Figure 3, which is a schematic diagram of the architecture of a data management system provided in an embodiment of the present application, and the system is a C/S architecture. That is, the system includes multiple clients 301 (two clients are schematically illustrated in Figure 3) and a server 302. Each of the multiple clients is connected to the server 302 by wire or wireless means for communication. As shown in Figure 3, each client 301 communicates with the server 302 through an Internet protocol (IP) network.

The client 301 is used to send a first data request to the server 302, and the first data request carries an object identifier. The object identifier is the first The server 302 is used to receive the first data request sent by the client 301, and manage the first data set based on the object identifier carried by the first data request. The management of the first data set by the server 302 includes any one of the operations of creating the first data set, editing the data in the first data set, submitting the first data set, or deleting the first data set.

The client 301 can be installed and deployed on any computer device, such as a server, desktop computer, laptop computer, mobile phone, etc., and can also be installed and deployed on the computing and storage resources of a cloud platform. The server 302 can be a network device such as a router, switch, gateway, firewall, etc.

Those skilled in the art should understand that the above-mentioned client 301 and server 302 are only examples, and other existing or future clients or servers that are applicable to the embodiments of the present application should also be included in the protection scope of the embodiments of the present application and are included here by reference.

It should be noted that the business scenarios and system architectures described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person of ordinary skill in the art can appreciate that with the emergence of new business scenarios and the evolution of system architectures, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

Fig. 4 is a flow chart of a data management method provided in an embodiment of the present application. Referring to Fig. 4, the method includes the following steps.

Step 401: the client sends a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for a first task, and the custom data set is used to store data used by the client to manage the server.

In some embodiments, the object identifier is an identifier of the first data set. After the client establishes a session connection with the server, when the client needs to manage the data on the server, the client sends a first data request to the server. Since the first data request carries the identifier of the custom data set that the client instructs the server to create for the first task, the server can manage only the custom data set corresponding to the first task of the client based on the identifier of the first data set, thereby avoiding the server from managing tasks of other clients or custom data sets corresponding to other tasks of the client at the same time.

In some other embodiments, the object identifier is an identifier of the first task. After the client establishes a session connection with the server, when the client needs to manage the data on the server through the first task, the client sends a first data request to the server. Since the first data request carries the identifier of the first task, the server can manage only the custom data set corresponding to the first task of the client based on the identifier of the first task, thereby avoiding the server from managing tasks of other clients or custom data sets corresponding to other tasks of the client at the same time.

Of course, in practical applications, the object identifier may also be other identifiers, as long as the object identifier can indicate the first data set, and the embodiment of the present application does not limit this.

That is, in the embodiment of the present application, each client instructs the server to create a custom data set according to the task requirements, one task corresponds to one custom data set, and any client instructs the server to manage the custom data set corresponding to any task of the client, thereby solving the problem of data conflicts caused by multiple clients or multiple tasks sharing one data set. In addition, each client creates a custom data set according to the task requirements. Only when a certain client needs to manage the data on the server side, the client instructs the server to create one or more custom data sets according to the number of tasks to be executed. It is not that each client instructs the server to create a custom data set after establishing a session connection with the server. In this way, it is possible to solve the problem of resource waste caused by each client that establishes a session connection with the server instructing the server to create a custom data set.

Step 402: The server receives the first data request and manages the first data set based on the object identifier.

In some embodiments, the data set creation condition includes: the data sets created on the server side do not include the first data set.

Based on the above description, the object identifier is the identifier of the first data set, or the object identifier is the identifier of the first task. In the case where the object identifier is the identifier of the first data set, the server end queries whether the first data set exists from the created data set based on the object identifier, including: the server end queries whether there is a data set whose data set identifier is the same as the identifier of the first data set from the created data set based on the identifier of the first data set. If there is a data set whose data set identifier is the same as the identifier of the first data set in the created data set, it indicates that the first data set exists in the created data set. If there is no data set whose data set identifier is the same as the identifier of the first data set in the created data set, it indicates that the first data set does not exist in the created data set. In the case where the object identifier is the identifier of the first task, since the server end has created the corresponding custom data set for each task according to the instructions of the client, the corresponding relationship between the task identifier and the data set is also stored. Therefore, after receiving the first data request sent by the client, the server end determines whether there is a first data set corresponding to the identifier of the first task in the created data set based on the identifier of the first task carried in the first data request from the corresponding relationship between the stored task identifier and the data set.

In some other embodiments, the data set creation condition includes: the total number of data sets created by the server is less than the maximum number of data sets. The maximum number of data sets is set in advance, for example, the maximum number of data sets is 15. Moreover, the maximum number of data sets can also be adjusted according to different requirements.

In some other embodiments, the data set creation condition includes: the data sets already created on the server side do not include the first data set, and the total number of data sets already created on the server side is less than the maximum number of data sets.

After receiving the first data request sent by the client, the server queries whether the first data set exists in the created data sets based on the object identifier carried in the first data request. If the first data set exists in the created data sets, it indicates that the server has currently created the first data set. At this time, the server sends a data set creation failure message to the client.

If the first dataset does not exist in the created datasets, it indicates that the server has not currently created the first dataset. Then, the server determines the total number of datasets currently created. When the total number of datasets currently created is less than the maximum number of datasets, it indicates that the total number of datasets created by the server has not reached the maximum number of datasets that the server can support, that is, the server can continue to create datasets. At this time, the server creates a dataset whose identifier is the object identifier and whose type is the type of the first dataset, and sends a dataset creation success message to the client. When the total number of datasets currently created is not less than the maximum number of datasets, it indicates that the total number of datasets created by the server has reached the maximum number of datasets that the server can support, that is, the server cannot continue to create datasets. At this time, the server sends a dataset creation failure message to the client.

It should be noted that, when the dataset creation condition includes: the datasets created by the server end do not include the first dataset, and the total number of datasets created by the server end is less than the maximum number of datasets, the server end first queries whether the created datasets include the first dataset according to the above steps, and then determines whether the total number of currently created datasets is less than the maximum number of datasets. This is only an example. In actual applications, the server end may also first determine whether the total number of currently created datasets is less than the maximum number of datasets, and then query whether the created datasets include the first dataset. This embodiment of the present application does not limit this. Of course, in actual applications, the dataset creation condition may also include other conditions, which are not limited in this embodiment of the present application.

Based on the above description, when the server fails to create the first data set, the server will send a data set creation failure message to the client. Optionally, the creation failure message may also include the reason for the failure to create the data set.

In some embodiments, the first data request also carries the lifetime of the first data set. In this way, after the server creates the first data set based on the object identifier and the type of the first data set, it can also set the lifetime of the first data set to the lifetime carried by the first data request, so that when the lifetime of the first data set is detected to have expired, the first data set can be deleted. Of course, in actual applications, there may also be a situation where the first data request does not carry the lifetime of the first data set. In this case, the server directly sets the lifetime of the first data set to the default lifetime. The default lifetime is set in advance, for example, the default lifetime is 1 day. Moreover, the default lifetime can be adjusted according to different needs.

The above content takes the example of setting the life span of the first data set to a fixed time length on the server side, starting from the successful creation of the first data set, and deleting the first data set when the time length is reached. In other embodiments, the server side may also set a temporary tag for the first data set, and the temporary tag instructs the server side to delete the first data set when submitting the first data set to the corresponding data set.

For example, the server receives the first data request sent by the client as follows:

Among them, <rpc message-id="1"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> represents the message header defined in the XML encoding format, that is, the server-side data instantiated using the YANG model is stored in the XML encoding format. <create-datastore> represents the operation of creating a data set. The parameters in <create-datastore> include <name>, <type>, and <lifetime>. The <name> parameter carries the identifier of the first data set "my-datastore", the <type> parameter carries the type of the first data set "candidate data set type", and the <lifetime> parameter carries the lifetime of the first data set "1day".

It should be noted that the use of the time period "1day" in the first data request mentioned above to indicate the lifetime of the first data set is only an example. In other embodiments, the lifetime of the first data set can also be indicated in other ways. For example, the lifetime of the first data set is indicated by a time node. For example, the <lifetime> parameter carries the lifetime of the first data set "11.23.2022", indicating that the lifetime of the first data set expires on November 23, 2022.

When the first dataset meets the dataset creation condition, after the server creates the first dataset based on the object identifier and the type of the first dataset, the dataset creation success message sent by the server to the client is as follows:

In the case where the first dataset fails to be created because the server has already created the first dataset, the dataset creation failure message sent by the server to the client is as follows:

The parameters in <rpc-error> include <error-type>, <error-tag>, <error-severity>, and <error-message>. The content in the <error-type> parameter indicates that the type of the failure to create the first data set is "application", that is, the failure to create the first data set is due to an error in the application layer. The content in the <error-tag> parameter indicates that the tag of the failure to create the first dataset is "data-exists", that is, the server has already created the first dataset. The content in the <error-severity> parameter indicates that the severity of the failure to create the first dataset is "error". The content in the <error-message> parameter indicates that the message of the failure to create the first dataset is "The datastore to be created exists", that is, the first dataset failed to be created because the server has already created the first dataset.

In the case where the creation of the first dataset fails because the total number of datasets currently created by the server is not less than the maximum number of datasets, the dataset creation failure message sent by the server to the client is as follows:

The parameters in <rpc-error> include <error-type>, <error-tag>, <error-severity>, and <error-message>. The content in the <error-type> parameter indicates that the type of failure to create the first dataset is "protocol", that is, the failure to create the first dataset is due to an error in the protocol layer. The content in the <error-tag> parameter indicates that the tag of the failure to create the first dataset is "resource-denied", that is, the current resources on the server are insufficient. The content in the <error-severity> parameter indicates that the severity of the failure to create the first dataset is "error". The content in the <error-message> parameter indicates that the message of the failure to create the first dataset is "Reach the max number of customized datastore", that is, the failure to create the first dataset is due to the total number of datasets currently created on the server reaching the maximum number of datasets that the server can support.

In some embodiments, the data set deletion condition includes: the first data set is created by the client instructing the server. Alternatively, the first data set is not created by the client instructing the server, but the client has management authority. Of course, in actual applications, the data set deletion condition may also include other conditions, which are not limited in the embodiments of the present application.

Based on the above description, the server stores the correspondence between the client identifier, the object identifier and the data set type. Therefore, the data set deletion condition includes: when the first data set is created by the server at the instruction of the client, after the server receives the first data request sent by the client, based on the object identifier and the client identifier carried in the first data request, from the stored correspondence between the client identifier, the object identifier and the data set type, it determines whether the first data set is created by the server at the instruction of the client. In the case that the first data set is created by the server at the instruction of the client, the server directly deletes the first data set. In the case that the first data set is not created by the server at the instruction of the client, the server sends a data set deletion failure message to the client.

Optionally, when the data set deletion condition includes: the first data set is not created by the client instructing the server, but the client has management authority, if the first data set is not created by the client instructing the server, the server can also determine whether the client has management authority based on the identifier of the client. If the client has management authority, the server deletes the first data set. If the client does not have management authority, the server sends a data set deletion failure message to the client.

That is, a client without management privileges can only delete the custom datasets that it instructs the server to create, but cannot delete other datasets. The client instructs the server to create a custom dataset, thereby preventing other clients from instructing the server to create a custom dataset passively deleted. Clients with management permissions can delete all custom datasets created by clients instructing the server to create a custom dataset, thereby reducing resource usage.

Among them, <delete-datastore> represents the operation of deleting a data set, and the parameters in <delete-datastore> include <name1> and <name2>. The <name1> parameter carries the identifier "my-datastore" of the first data set, and the <name2> parameter carries the identifier "my-ID" of the client.

Since the maximum number of datasets supported by the server is not unlimited, when the total number of datasets created on the server reaches the maximum number of datasets supported by the server, the client with management authority can forcibly delete the datasets whose lifetime has expired. At this time, the first data request sent by the client with management authority received by the server is as follows:

Among them, <destroy-datastore> represents the operation of forcibly deleting a dataset by a client with management permissions. The parameters in <destroy-datastore> include <name>, and the <name> parameter carries the identifier "my-datastore" of the forcibly deleted dataset.

That is, when the client needs to edit the data in the first data set, the client sends a first data request to the server, where the first data request carries the object identifier and the first data to be edited.

Among them, <edit-data> represents the editing operation on the data in the data set, and the parameters in <edit-data> include <target> and <data>. The <target> parameter carries the identifier of the first data set "my-datastore", and the <data> parameter carries the first data to be edited. The first data to be edited includes the namespace of the first data set indicated by the <top xmlns="http://example.com/schema/1.2/config"> parameter, the interface information indicated by the <interface> parameter, the interface name <name> is "Ethernet0/0", and the maximum transmission unit number <mtu> of the router is "1500".

In the message header <rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"app-id="test"> defined in the XML encoding format, app-id="test" represents the identifier of the first task, <edit-data> represents the editing operation on the data in the data set, and the parameters in <edit-data> include <target> and <data>. <target> The parameter carries the type of the first data set "candidate data set type", and the <data> parameter carries the first data to be edited. The first data to be edited includes the namespace of the first data set indicated by the <top xmlns="http://example.com/schema/1.2/config"> parameter, the interface information indicated by the <interface> parameter, the interface name <name> is "Ethernet0/0", and the maximum transmission unit number <mtu> of the router is "1500".

Wherein, when the first data set does not exist, the server side queries the relevant data from the corresponding data set based on the type of the first data set to implement the process including: when the type of the first data set is a candidate data set type, the server side queries the relevant data from the running data set according to the filter type carried by the first data request. When the type of the first data set is a dynamic data set type, the server side queries the relevant data from the operation data set according to the filter type carried by the first data request.

Among them, <get-data> represents a query operation on the data in the data set, and the parameters in <get-data> include <target> and <filter type="subtree">. The <target> parameter carries the type of the first data set as "candidate data set type", and the <filter type="subtree"> parameter carries the filter type as "subtree". The query information includes the namespace of the first data set indicated by the <top xmlns="http://example.com/schema/1.2/config"> parameter, and the user list indicated by the <users> parameter.

For example, the data query response sent by the server to the client is as follows:

Among them, <data> represents the data obtained by the query, and the parameters in <data> include the namespace of the first data set indicated by the <top xmlns="http://example.com/schema/1.2/config"> parameter and the user list indicated by the <users> parameter. The parameters in <users> include <name>, <type>, <full-name>, and <company-info>. The <name> parameter indicates that the user's name is "root", the <type> parameter indicates that the user's type is "superuser", the <full-name> parameter indicates that the user's full name is "Charlie Root", and the <company-info> parameter indicates that the user's company information includes "dept1" and "id1".

Based on the above description, the server stores the correspondence between the client identifier, the object identifier and the data set type. Therefore, after receiving the first data request, the server can obtain the type of the first data set from the stored correspondence between the client identifier, the object identifier and the data set type based on the object identifier.

Since the first data set is a custom data set that the client instructs the server to create for the first task, when the client executes the first task, the server only needs to submit the first data set corresponding to the first task to the corresponding data set based on the type of the first data set, and will not passively submit custom data sets corresponding to other tasks to the corresponding data set.

For example, when the object identifier is the identifier of the first data set, the server receives the first data request sent by the client as follows:

<commit> represents the operation of submitting a data set, and the parameters in <commit> include <datastore>. The <datastore> parameter carries the identifier of the first data set "my-datastore".

For example, when the object identifier is the identifier of the first task, the server receives the first data request sent by the client as follows:

Among them, app-id="test" in the message header <rpc message-id="101"xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"app-id="test"> defined in the XML encoding format represents the identifier of the first task, and <commit> represents the operation of submitting the data set.

Next, taking Figure 5 as an example, the data management process provided by the embodiment of the present application is fully described. In Figure 5, the client instructs the server to create a first data set, and the first data set is a custom data set created for the first task performed by the client. After the server creates the first data set, the client edits the data in the first data set. After the client completes editing the data in the first data set, the client instructs the server to submit the data stored in the first data set to the corresponding data set to perform the first task. When the first data set is no longer in use, the client instructs the server to delete the first data set.

The above content is based on the example of each client instructing the server to create a custom data set according to the task requirements. The server manages the first data set through the identifier of the first data set carried in the first data request. Alternatively, the server manages the data set corresponding to the first task through the identifier of the first task carried in the first data request.

Optionally, the server also stores a shared data set, which is independent of each custom data set. Each client can also instruct the server to manage the shared data set by sending a first data request to the server. In this case, the first data request does not carry an object identifier. That is, if the first data request sent by any client to the server carries an object identifier, it indicates that the client instructs the server to manage a specific custom data set. If the first data request sent by any client to the server does not carry an object identifier, it indicates that the client instructs the server to manage the shared data set.

In the embodiment of the present application, since the first data request sent by the client to the server carries an object identifier, the object identifier indicates the first data set and the first data set is a custom data set that the client instructs the server to create for the first task, after receiving the first data request, the server can manage the first data set corresponding to the first task based on the object identifier. That is, the client instructs the server to create a custom data set according to the task requirements, one task corresponds to one custom data set, and each custom data set is independent of each other and does not affect each other. In this way, when the client performs a task, it only needs to send a data request carrying the corresponding object identifier to the server, so that the server manages the data set corresponding to the task based on the object identifier carried by the data request, and does not manage the data sets corresponding to other tasks. Moreover, each client instructs the server to create a custom data set according to the task requirements. Only when a client needs to manage the data on the server, the client instructs the server to create one or more custom data sets according to the number of tasks to be executed, and it is not that each client instructs the server to create a custom data set after establishing a session connection with the server. In this way, it can solve the problem of resource waste caused by each client that establishes a session connection with the server instructing the server to create a custom data set. In addition, by each client actively deleting the datasets that it instructed the server to create, or by a client with management authority forcibly deleting the datasets whose lifetime has expired, resource usage can be reduced and system resources can be saved.

FIG6 is a schematic diagram of the structure of a data management device provided in an embodiment of the present application, and the data management device can be implemented by software, hardware or a combination of both to become part or all of a communication device, and the communication device can be the server end shown in FIG3 , and the device is applied to the server end. Referring to FIG6 , the device includes: a receiving module 601 and a management module 602.

The receiving module 601 is used to receive a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for the first task, and the custom data set is used to store data used by the client to manage the server. The detailed implementation process refers to the corresponding content in the above embodiments, which will not be repeated here.

The management module 602 is used to manage the first data set based on the object identifier. The detailed implementation process refers to the corresponding content in the above embodiments, which will not be repeated here.

The management module 602 is specifically used for:

Optionally, the first data request further carries the type of the first data set, and the management module 602 is specifically configured to:

An editing operation on the first data is performed on the first data set.

The management module 602 is specifically used for:

Optionally, the device further comprises:

It should be noted that: the data management device provided in the above embodiment only uses the division of the above functional modules as an example to illustrate when performing data management. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the data management device provided in the above embodiment and the data management method embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

FIG7 is a schematic diagram of the structure of another data management device provided in an embodiment of the present application, the data management device can be implemented by software, hardware or a combination of both to become part or all of a communication device, the communication device can be any client shown in FIG3 , and the device is applied to the client. Referring to FIG7 , the device includes a sending module 701.

The sending module 701 is used to send a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for the first task, the custom data set is used to store data used by the client to manage the server, and the first data request instructs the server to manage the first data set based on the object identifier. The detailed implementation process refers to the corresponding content in the above embodiments, which will not be repeated here.

Optionally, the first data request indicates to edit the data in the first data set, and the first data request also carries the first Data,editing operations include adding, modifying, and deleting.

Please refer to Figure 8, which is a schematic diagram of the structure of a communication device according to an embodiment of the present application. Optionally, the communication device is any client or server shown in Figure 3, and the communication device includes at least one processor 801, a communication bus 802, a memory 803 and at least one communication interface 804.

The processor 801 may be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or may be one or more integrated circuits for implementing the solution of the present application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

The communication bus 802 is used to transmit information between the above components. The communication bus 802 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

The memory 803 may be a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), an optical disc (including a compact disc read-only memory (CD-ROM), a compressed optical disc, a laser disc, a digital versatile disc, a Blu-ray disc, etc.), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 803 may exist independently and be connected to the processor 801 via the communication bus 802. The memory 803 may also be integrated with the processor 801.

The communication interface 804 uses any transceiver-like device to communicate with other devices or communication networks. The communication interface 804 includes a wired communication interface and may also include a wireless communication interface. Among them, the wired communication interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface can be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof, etc.

In a specific implementation, as an embodiment, the processor 801 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 8 .

In a specific implementation, as an embodiment, the communication device may include multiple processors, such as processor 801 and processor 805 shown in Figure 8. Each of these processors may be a single-core processor or a multi-core processor. The processor here may refer to one or more devices, circuits, and/or processing cores for processing data (such as computer program instructions).

In a specific implementation, as an embodiment, the communication device may further include an output device 806 and an input device 807. The output device 806 communicates with the processor 801 and may display information in a variety of ways. For example, the output device 806 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 807 communicates with the processor 801 and may receive user input in a variety of ways. For example, the input device 807 may be a mouse, a keyboard, a touch screen device, or a sensor device.

In some embodiments, the memory 803 is used to store the program code 810 for executing the solution of the present application, and the processor 801 can execute the program code 810 stored in the memory 803. The program code 810 may include one or more software modules, and the communication device can implement the data management method provided in the embodiment of FIG. 4 above through the processor 801 and the program code 810 in the memory 803.

In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (for example: coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (for example: infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiment of the present application may be a non-volatile storage medium, in other words, a non-transient storage medium.

That is, the embodiment of the present application further provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a computer, the computer executes the steps of the above-mentioned data management method.

The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps of the above data management method. In other words, a computer program is provided, which, when executed on a computer, enables the computer to execute the steps of the above data management method.

It should be understood that the "multiple" mentioned herein refers to two or more. In the description of the embodiments of the present application, unless otherwise specified, "/" means or, for example, A/B can mean A or B; "and/or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit them to be necessarily different.

It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the first data request involved in the embodiments of this application is obtained with full authorization.

The above-mentioned embodiments are provided for the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

A data management method, characterized in that the method comprises:

The server receives a first data request, the first data request carries an object identifier, the object identifier indicates a first data set, the first data set is a custom data set created for a first task, and the custom data set is used to store data used by the client to manage the server;

The server manages the first data set based on the object identifier.
The method as claimed in claim 1 is characterized in that the object identifier is an identifier of the first data set, or the object identifier is an identifier of the first task.
The method according to claim 1, wherein the first data request indicates an edit operation to be performed on the data in the first data set, the first data request further carries the first data to be edited, and the edit operation includes any one of adding, modifying, and deleting;

The server manages the first data set based on the object identifier, including:

The server performs an editing operation on the first data set based on the object identifier.
The method according to claim 1, wherein the first data request indicates an edit operation to be performed on the data in the first data set, the first data request further carries the first data to be edited, and the edit operation includes any one of adding, modifying, and deleting;

The server manages the first data set based on the object identifier, including:

In a case where it is determined based on the object identifier that the first data set exists, the server performs an editing operation on the first data set based on the object identifier.
The method according to claim 4, wherein the first data request further carries a type of the first data set, and the method further comprises:

When it is determined based on the object identifier that the first data set does not exist and the total number of data sets created by the server is less than the maximum number of data sets, the server creates the first data set based on the object identifier and the type of the first data set;

The server performs an editing operation on the first data set.
The method according to claim 1, wherein the first data request indicates configuration of the server side, and the type of the first data set is a candidate data set type;

The server manages the first data set based on the object identifier, including:

The server submits the data stored in the first data set to the running data set based on the object identifier.
The method according to claim 1, wherein the first data request indicates configuration of the server side, and the type of the first data set is a dynamic data set type;

The server manages the first data set based on the object identifier, including:

The server submits the data stored in the first data set to the operation data set based on the object identifier.
The method according to claim 1, wherein the first data request indicates deletion of the first data set, and the first data request also carries an identifier of the client;

The server manages the first data set based on the object identifier, including:

When it is determined that the first data set meets a data set deletion condition based on the object identifier and the identifier of the client, the server deletes the first data set based on the object identifier.
The method of claim 8, wherein the data set deletion condition comprises: the first data set is created by the server at the instruction of the client; or the first data set is not created by the server at the instruction of the client, but the client The client has administrative privileges.
The method according to claim 1, wherein the first data request instructs the server to create the first data set, and the first data request also carries a type of the first data set;

The server manages the first data set based on the object identifier, including:

In the case that the first data set meets the data set creation condition, the server creates the first data set based on the object identifier and the type of the first data set.
The method according to claim 10, characterized in that the data set creation condition includes: the data sets already created on the server side do not include the first data set.
The method according to claim 11, characterized in that the data set creation condition further includes: the total number of the created data sets is less than the maximum number of data sets.
The method according to any one of claims 10 to 12, characterized in that the first data request also carries the lifetime of the first data set;

After the server creates the first data set based on the object identifier and the type of the first data set, the method further includes:

The server sets the lifetime of the first data set to the lifetime carried in the first data request.
The method according to any one of claims 10 to 12, characterized in that after the server creates the first data set based on the object identifier and the type of the first data set, the method further comprises:

The server sets the lifetime of the first data set to a default lifetime.
The method according to claim 13 or 14, characterized in that the method further comprises:

When the server detects that the lifetime of the first data set expires, the server deletes the first data set.
The method according to any one of claims 1-15 is characterized in that the client performs configuration management on the server through a network configuration management protocol, and the network configuration management protocol includes but is not limited to the network configuration protocol NETCONF, the expressive state transfer configuration protocol RESTCONF, and the constraint application protocol management interface CORECONF.
A data management method, characterized in that the method comprises:

The client sends a first data request, which carries an object identifier. The object identifier indicates a first data set. The first data set is a custom data set created for a first task. The custom data set is used to store data used by the client to manage a server. The first data request instructs the server to manage the first data set based on the object identifier.
The method as claimed in claim 17 is characterized in that the object identifier is an identifier of the first data set, or the object identifier is an identifier of the first task.
The method as claimed in claim 17 is characterized in that the first data request indicates an editing operation on the data in the first data set, and the first data request also carries the first data to be edited, and the editing operation includes any one of adding, modifying, and deleting.
The method as claimed in claim 17 is characterized in that the first data request indicates configuration of the server side, and the type of the first data set is a candidate data set type or a dynamic data set type.
The method as claimed in claim 17 is characterized in that the first data request indicates deletion of the first data set, and the first data request also carries an identifier of the client.
The method as claimed in claim 17 is characterized in that the first data request instructs the server to create the first data set, and the first data request also carries the type of the first data set.
The method as claimed in claim 22 is characterized in that the first data request also carries the lifetime of the first data set.
The method according to any one of claims 17-23 is characterized in that the client performs configuration management on the server through a network configuration management protocol, and the network configuration management protocol includes but is not limited to the network configuration protocol NETCONF, the expressive state transfer configuration protocol RESTCONF, and the constraint application protocol management interface CORECONF.
A server side, characterized in that the server side includes a memory and a processor;

The memory is used to store computer programs;

The processor is used to execute the computer program to implement the steps of any method described in claims 1-16.
A client, characterized in that the client comprises a memory and a processor;

The memory is used to store computer programs;

The processor is used to execute the computer program to implement the steps of any method described in claims 17-24.
A data management system, characterized in that the data management system comprises a server and a client;

The server side is used to implement the steps of any method described in claims 1-16;

The client is used to implement the steps of any method described in claims 17-24.