Device management method, electronic device, and readable storage medium

Abstract

This application discloses a device management method, an electronic device, and a readable storage medium, belonging to the field of computer technology. The method includes: in response to receiving a first message sent by a client, using a web process to convert first data carried in the first message into a target command, wherein the first data is in JSON format and the target command is in object format; in response to the completion of execution of the target command, using the web process to convert a first execution result corresponding to the target command into second data, wherein the first execution result is in the object format and the second data is in JSON format; and returning a second message carrying the second data to the client.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a device management method, electronic device, and readable storage medium. Background Technology

[0002] Optical Transport Network (OTN) equipment is used in optical communication networks, primarily for transmitting high-speed, high-capacity, and reliable data. It typically consists of optical access equipment, optical distribution equipment, and optical transmission equipment, supporting various protocols and data formats such as SDH, Ethernet, and Fibre Channel. OTN equipment is commonly used in carriers, data centers, and enterprises to meet the demands of high-speed data transmission. Based on network scale, it can be categorized as large, medium, and small. In most cases, communication between OTN equipment and the proprietary network management system relies on private commands. However, in some small-scale network environments, to reduce operating costs, network operators often do not purchase a network management system. Without a network management system, it is difficult to efficiently manage OTN equipment. Summary of the Invention

[0003] This application provides a device management method, an electronic device, and a readable storage medium, which can solve the problem of difficulty in efficiently managing OTN devices in the absence of a network management system.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, a device management method is provided, applied to a device. The method includes: in response to receiving a first message sent by a client, using a web process to convert first data carried in the first message into a target command, wherein the first data is in JSON format and the target command is in object format; in response to the completion of the execution of the target command, using the web process to convert a first execution result corresponding to the target command into second data, wherein the first execution result is in the object format and the second data is in JSON format; and returning a second message carrying the second data to the client.

[0005] Secondly, a device management method is provided, applied to a client. The method includes: sending a first message to a device, wherein the first message carries first data in JSON format; and receiving a second message returned by the device based on the first message, wherein the second message carries second data, the second data being obtained by the device using a web process to convert the format of an execution result corresponding to a target command, the target command being obtained by the device using the web process to convert the format of the first data, the second data being in JSON format, the target command being in object format, and the execution result being in object format.

[0006] Thirdly, an electronic device is provided, including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method as described in the first aspect, or implementing the steps of the method as described in the second aspect.

[0007] Fourthly, a readable storage medium is provided, wherein at least one computer program is stored therein, which, when loaded and executed by a processor, implements the steps of the method described in the first aspect, or implements the steps of the method described in the second aspect.

[0008] Fifthly, a computer program product is provided, the computer program product comprising at least one computer program that, when loaded and executed by a processor, implements the steps of the method described in the first aspect, or implements the steps of the method described in the second aspect.

[0009] In this embodiment, in response to receiving a first message from the client, a web process converts the first data carried in the first message into a target command. The first data is in JSON format, and the target command is in object format. Then, in response to the completion of the target command execution, the web process converts the first execution result corresponding to the target command into second data. The first execution result is in object format, and the second data is in JSON format. Finally, a second message carrying the second data is returned to the client. This method, by converting only the JSON-formatted first data carried in the first message sent by the client into an internal command, achieves internal command reuse, transforming external management operations into independent internal management operations. This avoids complex management configurations on the client side. Furthermore, after obtaining the first execution result in object format, the device converts it into second data in JSON format. This allows the client to directly obtain the response result without complex parsing, again avoiding complex management configurations on the client side and reducing maintenance costs. This achieves convenient and efficient management of OTN devices. Moreover, even if new commands are added to the device, there is no need to modify the JSON conversion rules, and convenient and efficient management of OTN devices can still be achieved.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0012] Figure 1 This application shows a schematic flowchart of a device management method provided in an exemplary embodiment. Figure 2 This illustration shows an interaction diagram between a client and a device provided in an exemplary embodiment of this application; Figure 3 This illustration shows another interaction diagram between the client and the device provided in an exemplary embodiment of this application; Figure 4 This illustration shows a message interaction diagram corresponding to a query operation provided by an exemplary embodiment of this application; Figure 5 This illustration shows a message interaction diagram corresponding to a configuration operation provided by an exemplary embodiment of this application; Figure 6 This illustration shows a message interaction diagram corresponding to a configuration operation provided by an exemplary embodiment of this application; Figure 7This illustration shows a message interaction diagram corresponding to a query operation provided by an exemplary embodiment of this application; Figure 8 This illustration shows an interactive diagram of a device management method provided in an exemplary embodiment of this application; Figure 9 This illustration shows an interactive diagram of a device management method provided in an exemplary embodiment of this application; Figure 10 This application illustrates a login process diagram provided by an exemplary embodiment. Figure 11 This application illustrates another login process provided by an exemplary embodiment. Figure 12 This illustration shows a logout process provided by an exemplary embodiment of this application; Figure 13 This illustration shows another flowchart of a device management method provided in an exemplary embodiment of this application; Figure 14 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0014] Figure 1 This illustration shows a flowchart of a device management method provided in an exemplary embodiment of this application. The method can be executed by a device, which includes an OTN device, and the method may include the following steps: S110: In response to receiving the first message sent by the client, the first data carried in the first message is converted into a target command using the WEB process.

[0015] The first data is in JSON format, and the target command is in object format. In other words, after receiving the first message carrying the first data from the client, the device uses its internal web process to convert the JSON-formatted first data into an executable internal command corresponding to the device, i.e., a target command in object format. It is understood that the client in this embodiment can interact with the device without being limited by the operating device itself. Specifically, the user enters the device's IP address on the client's login page through a browser, connects to the device, and then sends a message corresponding to the relevant operation to the device. Upon receiving the message, the device uses its web process to parse the message and converts the parsed JSON-formatted first data into a target command in object format. This allows users to access the corresponding device through a browser on different operating systems or devices. The device converts the received first data into an internal command, improving command execution efficiency and reducing maintenance costs.

[0016] For example, suppose the first piece of data in JSON format is:

[0017] After conversion, the target command for the object format can be:

[0018] In this context, 0001 represents attribute number 1, corresponding to "attr_id": 1; the first 0002 represents the attribute type, corresponding to "type": "uint16"; the second 0002 represents the attribute length, corresponding to "len": 2; and 01 represents the attribute value, corresponding to "value": 1.

[0019] In an exemplary embodiment, converting the first data in JSON format into a target command in object format may include: obtaining an object identifier and a list of attributes included in the first data, and writing the object identifier and the list of attributes into specified bytes of the target command format, where the object identifier refers to the identifier of the command corresponding to the device, for example, the object identifier of query command 68865 is 68865. For example, taking query command 68865 as an example, the first data is shown in Table 1, and the attributes of query command 68865 are shown in Table 2. Table 1

[0020] Table 2

[0021] After conversion, the query command 68865 in object format can be:

[0022] Wherein, 00010d01 represents command 68865; 0001 represents attribute identifier: 1, i.e. attribute number 1; 0002 represents the attribute type of attribute number 1; 0002 represents the attribute length of attribute number 1; 01 represents the attribute value of attribute number 1; 0002 represents attribute identifier: 2, i.e. attribute number 2; 0006 represents the attribute type of attribute number 2; 001f represents the attribute length of attribute number 2; and 0012 represents the attribute value of attribute number 2.

[0023] In the above S110, by converting the first data in the first message into an internal command, i.e. a target command, the device does not need to start a new execution process and can directly execute the target command in the current environment, which can improve command execution efficiency, simplify the command calling process, and thus achieve efficient reuse of commands.

[0024] S120: In response to the completion of the target command execution, the first execution result corresponding to the target command is converted into second data using the WEB process.

[0025] The first execution result is in the format of the object, and the second data is in the format of JSON.

[0026] S130: Return a second message carrying the second data to the client.

[0027] Regarding S120 and S130 above, it can be understood that after the device executes the target command, it converts the first execution result in object format into second data in JSON format. This ensures that both the client and device use the same format for communication, avoiding complex format parsing and guaranteeing data transmission consistency. For example, taking response command 68866 as an example, Table 3 shows the attribute description of response command 68866: Table 3

[0028] It should be noted that in the previous example, query command 68865 was a request command, while command 68866 in this example is a response command.

[0029] Assume the first execution result is:

[0030] The converted JSON format of the second data is shown in Table 4.

[0031] Table 4

[0032] In this embodiment, in response to receiving a first message from the client, a web process converts the first data carried in the first message into a target command. The first data is in JSON format, and the target command is in object format. Then, in response to the completion of the target command execution, the web process converts the first execution result corresponding to the target command into second data. The first execution result is in object format, and the second data is in JSON format. Finally, a second message carrying the second data is returned to the client. This method, by converting only the JSON-formatted first data carried in the first message sent by the client into an internal command, achieves internal command reuse, transforming external management operations into independent internal management operations. This avoids complex management configurations on the client side. Furthermore, after obtaining the first execution result in object format, the device converts it into second data in JSON format. This allows the client to directly obtain the response result without complex parsing, again avoiding complex management configurations on the client side and reducing maintenance costs. This achieves convenient and efficient management of OTN devices. Moreover, even if new commands are added to the device, there is no need to modify the JSON conversion rules, and convenient and efficient management of OTN devices can still be achieved.

[0033] In one exemplary embodiment, receiving the first message sent by the client includes: receiving the first message through a target process, wherein both the target process and the first message correspond to a target transport protocol. That is, regarding the first message sent by the client, the device can receive it through the target process and then forward it to the WEB process for format conversion.

[0034] In this embodiment, the target transmission protocol can be Simple Network Management Protocol (SNMP), Simple Network Management Protocol (SNMP), Simple Mail Transfer Protocol (SMTP), or other transmission protocols. The target process can be a process corresponding to other communication protocols such as HTTP, SNMP, or SMTP. For example, assuming the target process is an HTTP process, such as… Figure 2The diagram illustrates an interaction between a client and a device. The client sends a request to the device. The device's HTTP process receives the request and forwards it to the device's web process. The web process parses the request to obtain first data in JSON format, converts it into a target command in object format, and sends it to the business entity. The business entity executes the target command to obtain a first execution result in object format, which is returned to the web process. The web process receives the first execution result, converts it into second data in JSON format, and sends it to the HTTP process. The HTTP process sends the second data as a response to the client. The client receives the response, retrieves the data, and displays it. In other words, communication between the client and the web process is implemented based on the HTTP process.

[0035] In addition, in this embodiment, the transmission protocol corresponding to the first message must be the same as the transmission protocol corresponding to the target process to ensure that the target process can correctly receive the first message and to avoid complex protocol parsing.

[0036] In another exemplary embodiment, returning a second message carrying the second data to the client includes: encapsulating the second data into a second message using the target process, wherein the second message corresponds to the target transport protocol; and returning the second message to the client. For illustrative purposes, continue to refer to... Figure 2 The web process on the device forwards the second data to the HTTP process, which then encapsulates the message and sends it to the client.

[0037] In this embodiment, the device communicates with the client using the target process, which can accurately receive messages from the sender and accurately send messages to the sender, thus ensuring the security of data transmission.

[0038] In another exemplary embodiment, such as Figure 3 As shown, the client sends a request to the device. The device's web process receives the request, parses it to obtain the first data in JSON format, converts the first data into a target command in object format, and sends it to the business entity. The business entity executes the target command to obtain the first execution result in object format, and returns it to the web process. After receiving the first execution result, the web process converts it into the second data in JSON format and sends it as the response result to the client. The client receives the response result, retrieves the data, and displays it. In other words, the device can directly use the web process to receive the first message and perform format conversion; that is, a persistent connection is established between the client and the web process, without the need for communication through a third party.

[0039] In an exemplary embodiment, converting the first data carried in the first message into a target command using a web process may include the following steps: S112: Determine the target format.

[0040] For example, the target format can be XML format, CLI command format, or Qx port command format, etc.

[0041] In one exemplary embodiment, step S112 may include: obtaining a processing interface corresponding to the first data from a Uniform Resource Locator (URL) contained in the first message; in response to the processing interface being an interface for processing YANG model data, determining that the data structure of the first data is a YANG (Yet Another NextGeneration) model structure based on the NETCONF (Network Configuration Protocol) protocol, wherein the data format corresponding to the YANG model structure based on the NETCONF protocol is XML format; and determining that the target format is the XML format.

[0042] For example, suppose the first message contains the URL: https: / / deviceIP / yangconfig.cgi, where deviceIP represents the address of the device and yangconfig.cgi represents the processing interface, indicating that this interface is used to process YAN model data. If the processing interface is for processing YANG model data, then the data structure of the first data sent by the client can be a YANG model structure based on the NETCONF protocol. YANG is a modular language that uses XML tree format to represent data structures, defining the configuration, status information, and interaction structure of network devices. NETCONF (Network Configuration Protocol) is a network management protocol that defines how to send and receive configuration data over the network and how to make operation requests; NETCONF uses XML format to encode data.

[0043] In this embodiment, NETCONF is the protocol layer and YANG is the data model layer. By utilizing the YANG data model to provide standardized descriptions of device configuration, status, fault information, etc., NETCONF can be used to manage OTN devices, thereby achieving more flexible, secure, and scalable device management. Therefore, in this embodiment, after determining that the processing interface is an interface for processing YANG model data, it is determined that the data structure of the first data can be a YANG model structure based on the NETCONF protocol.

[0044] It's important to note that the data structure and format are different. JSON format is used to represent the data transmission format, while the YANG language defines the data structure and constraints. This means that the JSON data sent by the client is organized according to the data model defined by the YANG language. It also indicates that the current environment requires parsing the YANG model structure based on the NETCONF protocol. NETCONF uses XML format to encode data, and YANG model data is represented in XML tree format. Therefore, the target format can be determined to be XML.

[0045] Optionally, in this embodiment of the application, the processing interface may be an interface of type .cgi.

[0046] S114: The first data is converted into third data using the WEB process, wherein the format of the third data is the target format.

[0047] For example, suppose the first data in JSON format could be:

[0048] After conversion, the third data in XML format can be:

[0049] S116: Convert the third data in the target format into the target command in the object format.

[0050] In one exemplary embodiment, S116 may include: in response to the target format being XML format, using a NETCONF process to convert the third data in XML format into the target command in object format. It is understood that since the data corresponding to the NETCONF protocol uses XML as the encoding and decoding format to describe device configuration information, status information, and operation requests, in this embodiment, after the WEB process converts the first data in JSON format into the third data in XML format, the NETCONF process on the device side can be used to convert the third data in XML format into the target command in object format. For example, suppose the third data in XML format is:

[0051] After conversion, the target command for the object format can be:

[0052] In the above Figure 1 In the illustrated embodiment, a web process can directly convert the first data in JSON format into a target command in object format. In this embodiment, the web process can first convert the first data in JSON format into third data, and then convert the third data into a target command in object format. That is, the device can flexibly choose the conversion method based on its own configuration and environment. For example, when there are no environmental requirements, the web process can directly convert the first data in JSON format into a target command in object format; when there are environmental requirements, the web process can first convert the first data in JSON format into third data corresponding to the environmental requirements, and then convert the third data into a target command in object format.

[0053] In an exemplary embodiment, the step of converting the first execution result corresponding to the target command into second data using the WEB process includes: converting the first execution result into fourth data using the NETCONF process, wherein the fourth data is in XML format; and converting the fourth data into the second data using the WEB process.

[0054] Understandably, after using the WEB process to convert the third data in JSON format into a target command in object format, the NETCONF process can be used to convert the first execution result in object format into fourth data in XML format, and then send the fourth data to the WEB process, which then converts the fourth data in XML format into second data in JSON format. In another exemplary embodiment, after using the NETCONF process to convert the third data in XML format into a target command in object format, the NETCONF process can similarly be used to convert the first execution result in object format into fourth data in XML format, and then send the fourth data to the WEB process, which then converts the fourth data in XML format into second data in JSON format.

[0055] In the embodiments of this application, the conversion method of the first data in JSON format to the target command in object format and the conversion method of the first execution result in object format to the second data in JSON format can be the same or different.

[0056] In an exemplary embodiment of this application, the type of processing interface contained in the URL can be used to determine whether the current request has environmental requirements. For example, if the processing interface contained in the URL of the first message request is config.cgi, it indicates that the setting or query operation corresponding to the first message has no environmental requirements, and the WEB process can directly convert the first data in JSON format into a target command in object format. If the processing interface contained in the URL of the first message request is yangconfig.cgi, it indicates that the setting or query operation corresponding to the first message has environmental requirements, requiring the WEB process to convert the first data in JSON format into third data in XML format, and then the NETCONF process to convert the third data in XML format into a target command in object format. The following illustrative examples illustrate query operations via the config.cgi interface, configuration operations via the config.cgi interface, setting operations via the yangconfig.cgi interface, and query operations via the yangconfig.cgi interface.

[0057] (1) Perform query operations through the config.cgi interface Assuming the request payload carries an object identifier of 68865, with attributes 1 and 2 and their values, the device receives the payload, converts the JSON content into the internal object command format 68865, responds with the command 68866, and then converts 68866 into a JSON response. Figure 4 The diagram shown illustrates the message interaction corresponding to a query operation, which may include the following steps: S410: When a user clicks to query, the client sends the URL of config.cgi. The request method can be POST, and the request payload is a JSON message containing the operation type (get), request identifier, and data object. The data object includes an object id and a list of attributes. Each attribute in the attribute list contains an attribute id, attribute type, attribute length, and attribute value.

[0058] S420: After receiving the message, the web process on the device side parses the payload JSON message, reads the data object content, parses out the object ID and attribute list, and converts them into an internal command format. For example, it puts the object ID and attribute list content into specified bytes of the internal command format. Then, it assembles the object ID command and sends it to the message distribution process.

[0059] S430: The message distribution process on the device side forwards the command to the business entity on the device side. After the business entity executes the command, it sends a response command to the message distribution process, which then forwards the response command to the WEB process.

[0060] S440: After receiving the object response command, the web process parses out the object ID and attribute information, then formats it into a JSON message. The message contains the operation type (GET), request identifier, and data object. The data object contains the data ID and data row, and the data row contains the attribute ID, attribute type, attribute length, and attribute value. Finally, it sends a Response message to the client.

[0061] S450: After receiving the Response message, the client parses the JSON message and extracts the attribute values ​​for display or caching.

[0062] S460: If the command execution fails, a 302 error message will be returned.

[0063] (2) Configure via the config.cgi interface Taking the existing laser setting command object 32358 on the device side as an example, its attribute format is shown in Table 5 below.

[0064] Table 5

[0065] Suppose the object in the request payload is represented as 32358, with attribute number 66 and attribute number 2 and their values. After receiving the payload, the device converts the JSON format into its internal object command format for distribution. Figure 5 The diagram shown illustrates the message interaction corresponding to a setup operation, which may include the following steps: S510: When the user clicks on settings, the client sends the URL of config.cgi. The request method can be POST, and the request payload is a JSON message containing the operation type (set), request identifier, and data object. The data object includes an object id and a list of attributes. Each attribute in the attribute list contains an attribute id, attribute type, attribute length, and attribute value.

[0066] For example, Table 6 shows a description of the URL, and Table 7 shows a description of the request payload.

[0067] Table 6

[0068] Table 7

[0069] S520: After receiving the message, the WEB process parses the Payload JSON message, reads the data object content, parses out the object ID and attribute list, and converts them into an internal command format. For example, it puts the object ID and attribute list content into specified bytes of the internal command format. Then, it assembles the object ID command and sends it to the message dispatch process.

[0070] S530: The message distribution process forwards the command to the business entity. After the business entity executes the command, it sends a response command to the message distribution process, which then forwards the command to the WEB process.

[0071] S540: After receiving the object response command, the web process parses the response result, error code, and error description, then formats it into a JSON message. The message includes the operation type (SET), request identifier, result, error code, and description. The result field is divided into success and failure, the error code is the command execution error code, and the description is information about the error scenario. Then, it is sent back to the client as a Response message.

[0072] S550: After receiving the Response message, the client parses the JSON message, retrieves the response result, and displays a success message.

[0073] S560: If the command execution fails, a 302 error message will be returned.

[0074] For example, as shown in Table 8, this is a description of the Response.

[0075] Table 8

[0076] (3) Configure via the yangconfig.cgi interface In an exemplary embodiment of this application, the yangconfig.cgi interface can be defined to implement the conversion function between JSON and NETCONF messages, realizing the conversion from JSON to NETCONF messages. In the conversion between JSON and NETCONF messages and objects, the conversion between NETCONF messages and objects is actually implemented by multiplexing the device's NETCONF channel. For example... Figure 6 The diagram shown illustrates the message interaction corresponding to a setup operation, which may include the following steps: S610: When the user clicks on settings, the client sends the URL of yangconfig.cgi. The request method is POST, and the request payload is a JSON message containing the operation type (set) and setting data (data). The setting data includes the yang model name, yang node, and the set node value.

[0077] For example, as shown in Table 9, this URL is described.

[0078] Table 9

[0079] S620: After receiving the message, the WEB process parses the Payload JSON message, reads the operation type and setting data, converts it into a NETCONF message, and forwards it to the NETCONF process. The NETCONF process then converts the NETCONF message into an object command format and forwards it to the message dispatch process.

[0080] S630: The message distribution process forwards the command to the business entity. After the business entity executes the command, it sends the response result to the message distribution process. The message distribution process then forwards the result to the NETCONF process, which in turn forwards it to the WEB process.

[0081] S640: After receiving the NETCONF message response, the web process parses the response and formats it into a JSON message. The message contains result fields, indicating either success or failure. Then, it sends this response to the client as a Response message.

[0082] S650: After receiving the Response message, the client parses the JSON message, retrieves the response result, and displays a success message.

[0083] S660: If the command execution fails, a 302 error message will be returned.

[0084] For example, as shown in Table 10, there are examples of response and NETCONF message response results.

[0085] Table 10

[0086] (4) Perform query operations through the yangconfig.cgi interface. like Figure 7 The diagram shown illustrates the message interaction corresponding to a setup operation, which may include the following steps: S710: When a user clicks to query, the client sends the URL of yangconfig.cgi with the POST request method. The request payload is a JSON message containing the operation type (get) and the node field (node). The node field contains the yang model name, the yang node, and the value of the node being queried.

[0087] For example, as shown in Table 11, this URL is described.

[0088] Table 11

[0089] S720: After receiving the message, the WEB process parses the Payload JSON message, reads the operation type and setting data, converts it into a NETCONF message, and forwards it to the NETCONF process. The NETCONF process then converts the NETCONF message into an object command format and forwards it to the message dispatch process.

[0090] S730: The message distribution process forwards the command to the business entity. After the business entity executes the command, it sends the response result to the message distribution process. The message distribution process then forwards the result to the NETCONF process, which in turn forwards it to the WEB process.

[0091] S740: After receiving the NETCONF message response, the web process parses the response and formats it into a JSON message. The message contains a result field (result) and query data (data). The result field is categorized as success or failure, and the query data includes the yang node and its attributes. Then, it sends the response to the client as a Response message.

[0092] S750: After receiving the Response message, the client parses the JSON message, extracts the response message, and then displays or caches it.

[0093] S760: If the command execution fails, a 302 error message will be returned.

[0094] For example, as shown in Table 12, are examples of response and NETCONF message response results.

[0095] Table 12

[0096] In one exemplary embodiment, before the target command is executed, the method further includes: invoking a business entity corresponding to the target command to execute the target command.

[0097] It is understood that after obtaining a target command, the business entity corresponding to the target command is invoked to execute the command. In another exemplary embodiment, before invoking the business entity corresponding to the target command to execute the target command, the method may further include: obtaining a command identifier corresponding to the target command, and determining the business entity corresponding to the command identifier based on a message registry.

[0098] Furthermore, in another exemplary embodiment, the step of invoking the business entity corresponding to the target command to execute the target command includes: in response to the requirement of participating in execution based on the target board, constructing a board command based on the target command; and executing the board command through the target board.

[0099] It is understandable that, during the execution of the target command by the business entity, if the execution of the target command requires interaction with the target board, the business entity will construct a board command and then send it to the target board, which will then execute the board command and wait for the target board's response.

[0100] Furthermore, in yet another exemplary embodiment, before converting the first execution result corresponding to the target command into second data using the WEB process, the method further includes: obtaining the second execution result corresponding to the target board; and generating the first execution result using the business entity based on the second execution result.

[0101] It is understandable that the first execution result generated by the business entity is based on the execution result of the target board. During the command execution process, the second execution result of the target board is obtained first, and then the execution continues based on the second execution result of the target board to obtain the first execution result. Alternatively, the second execution result can be used as the first execution result.

[0102] To further illustrate the foregoing embodiments, such as Figure 8 As shown in the illustration, this application also provides an interactive diagram of another device management method, which may include the following steps: S810: The client sends an HTTP message.

[0103] For example, taking a query operation as an example, when a user clicks to query, the client sends the URL of config.cgi. This URL includes the device's IP address, the request method is POST, the request payload is an HTTPS message, which includes the operation type (get), the request identifier, and the data object. The data object includes an object id and a list of attributes. Each attribute in the attribute list includes an attribute id, an attribute type, an attribute length, and an attribute value.

[0104] S820: The device's web process parses HTTPS messages, converts JSON content into object format, and sends it to the message distribution process.

[0105] Understandably, after receiving the message, the web process on the device side parses the payload JSON message, reads the data object content, extracts the object ID and attribute list, and converts them into an internal command format. For example, it puts the object ID and attribute list content into specified bytes of the internal command format. After assembling the object ID command, it sends it to the message dispatch process.

[0106] Prior to S820, it may also include: S815: HTTPS messages are received using the HTTP process on the device side, and the HTTP process forwards the HTTPS messages to the WEB process.

[0107] S830: The device-side message distribution process determines the business entity to execute the command and sends the command to the business entity.

[0108] Understandably, after receiving a command from the WEB process, the message distribution process dispatches the command to the corresponding business entity according to the message registry.

[0109] S840: The device-side business entity executes the command.

[0110] After receiving a command dispatched by the message distribution process, the business entity performs the corresponding operation based on the nature of the command: The first type: Independent command execution. That is, if the command does not require interaction with the board, the business entity will execute the command independently and complete the response.

[0111] The second method involves interaction with a single-board unit. In other words, if a command requires interaction with a single-board unit, the business entity converts its internal command into a single-board command, sends it to the single-board unit for execution, and waits for the unit's response. Upon receiving the execution result from the single-board unit, the business entity converts it back into an internal command and completes the response.

[0112] S850: The business entity sends a response command containing the result of the command execution to the message distribution process.

[0113] S860: The message distribution process on the device side sends the response command to the WEB process.

[0114] S870: The device's web process converts the response command into a JSON message and sends this JSON message as a Response message to the client. Finally, the client receives the Response message, parses the JSON message, and extracts the attribute values ​​for display or caching.

[0115] In other words, after the WEB process receives the object response command, it parses out the object ID and attribute information, and then formats it into a JSON message. The message contains the operation type (GET), request identifier, and data object. The data object contains the data ID and data row. The data row contains the attribute ID, attribute type, attribute length, and attribute value.

[0116] The process of sending this JSON message as a Response message to the client can include: S871: Use the HTTP process to send the JSON message as a Response message to the client.

[0117] In another exemplary embodiment, such as Figure 9 As shown in the illustration, this application also provides an interactive diagram of another device management method, which may include the following steps: S910: The client sends an HTTP message.

[0118] For example, taking a query operation as an example, when a user clicks to query, the client sends the URL of config.cgi. This URL includes the device's IP address, the request method is POST, the request payload is an HTTPS message, which includes the operation type (get), the request identifier, and the data object. The data object includes an object id and a list of attributes. Each attribute in the attribute list includes an attribute id, an attribute type, an attribute length, and an attribute value.

[0119] S920: The device's web process parses HTTPS messages, converts JSON content into XML format, and sends it to the NETCONF process.

[0120] Understandably, after receiving the message, the web process on the device side parses the payload json message and converts it into XML format.

[0121] Prior to the S920, it may also include: S915: HTTPS messages are received using the HTTP process on the device side, and the HTTP process forwards the HTTPS messages to the WEB process.

[0122] S930: The NETCONF process converts XML-formatted content into object format and sends it to the message dispatch process.

[0123] S940: The message distribution process determines the business entity to execute the command and sends the command to the business entity.

[0124] Understandably, after receiving a command from the NETCONF process, the message distribution process dispatches the command to the corresponding business entity according to the message registry.

[0125] S950: The device-side business entity executes the command.

[0126] After receiving a command dispatched by the message distribution process, the business entity performs the corresponding operation based on the nature of the command: The first type: Independent command execution. That is, if the command does not require interaction with the board, the business entity will execute the command independently and complete the response.

[0127] The second method involves interaction with a single-board unit. In other words, if a command requires interaction with a single-board unit, the business entity converts its internal command into a single-board command, sends it to the single-board unit for execution, and waits for the unit's response. Upon receiving the execution result from the single-board unit, the business entity converts it back into an internal command and completes the response.

[0128] S960: The business entity on the device side sends a response command containing the command execution result to the message distribution process.

[0129] S970: The message dispatch process sends the response command to the NETCONF process.

[0130] S980: The NETCONF process converts the response command into XML format data and sends it to the WEB process.

[0131] S990: The web process converts the XML data into a JSON message and sends this JSON message as a Response message to the client. Finally, the client receives the Response message, parses the JSON message, and extracts the attribute values ​​for display or caching.

[0132] In other words, after the WEB process receives the object response command, it parses out the object ID and attribute information, and then formats it into a JSON message. The message contains the operation type (GET), request identifier, and data object. The data object contains the data ID and data row. The data row contains the attribute ID, attribute type, attribute length, and attribute value.

[0133] The process of sending this JSON message as a Response message to the client can include: S991: Use the HTTP process to send the JSON message as a Response message to the client.

[0134] In an exemplary embodiment, before responding to receiving the first message sent by the client, the method further includes: in response to receiving a login request sent by the client, authenticating the client based on the login information carried in the login request; and returning first response data to the client based on the authentication result. It is understood that in this embodiment, the user directly accesses the device through a browser to perform management operations on the device. Therefore, before the client interacts with the device, the device also needs to authenticate the client to ensure the security of the operating environment.

[0135] For example, taking a client's login request as a GET request, such as... Figure 10 The diagram shown is a login process provided in an embodiment of this application, which may include the following steps: S1010: Users can access the login interface by entering the device's IP address (e.g., https: / / device IP) through the client, and then enter the username, password, and verification code to log in.

[0136] S1020: The client sends a login message: URL+GET+Payload, where the Payload contains the username, password, encryption type, language, and main page.

[0137] S1030: The device receives GET +login.cgi, retrieves cookies, and checks if the cookie contains a sessionID. If it does and is valid, the login is successful. The page returned after successful login may include one of the following: (1) If the root directory is requested, the client is required to be redirected to the main page.

[0138] (2) If a page file is requested, the file is read directly and returned. If the file does not exist, 404 NOTFOUND is returned.

[0139] S1040: If there is no sessionID or the sessionID in the cookie is invalid, the client is required to be redirected to the login page login.html.

[0140] S1050: If the client receives a 302, it will continue to send a message to redirect to the main page.

[0141] S1060: After receiving the request, the device returns the main page file, which is then received by the client and displayed on the main page.

[0142] For example, taking a client's login request as a POST request, such as... Figure 11 The diagram shown is a login process provided in an embodiment of this application, which may include the following steps: S1110: Users access the login interface by entering the device's IP address (e.g., https: / / deviceIP) through the client. They then enter their username, password, and verification code to log in.

[0143] S1120: The client sends a login message: URL+POST+Payload. The payload contains the username, password, encryption type, language, and main page.

[0144] S1130: If the device receives POST +login.cgi, it does not retrieve cookies, but directly extracts the username and password, and then performs user authentication. If authentication fails, the device returns a 401 error code; if authentication succeeds, it generates a session and cookies, returns a 302 error, and requests the client to be redirected to the main page.

[0145] Additionally, if the device receives a POST request with a value other than login.cgi, it needs to check the cookies, where the sessionID must be valid; otherwise, the client should be redirected to login.html.

[0146] S1140: If the client receives a 302, it continues to send a message to redirect to the main page.

[0147] S1150: After receiving the request, the device returns the main page file, which the client then receives and displays.

[0148] Optionally, the request fields corresponding to the login request are shown in Table 13, and the response fields corresponding to the login request are shown in Table 14.

[0149] Table 13

[0150] Table 14

[0151] In one exemplary embodiment, the method further includes: in response to receiving a logout request sent by the client, performing a logout operation based on the logout request; and returning second response data to the client based on the execution result corresponding to the logout operation.

[0152] Understandably, users should ensure that all changes have been saved and all sensitive information has been properly handled after completing all necessary operations. To protect user account security, users can actively click the "Logout" button on the client when ending the session. This implementation ensures that the user session is securely terminated, preventing unauthorized access. Users can log out by clicking the "Logout" button on the interface. The system will automatically clear all data in the current session, including temporary files and cached information.

[0153] Optionally, this logout request can be implemented via the ogout.cgi interface. For example, as shown... Figure 12 The diagram shown is a logout process provided in an embodiment of this application, which may include the following steps: S1210: When a user clicks "Logout" on the client, the client sends the URL of login.cgi with the POST request method.

[0154] S1220: After receiving the logout.cgi message, the device closes the session and clears cookies. The device returns a 302 error and redirects to the login page.

[0155] S1230: After receiving the redirection request, the client retrieves and displays the login page.

[0156] Optionally, the request fields corresponding to the logout request are shown in Table 15.

[0157] Table 15

[0158] Figure 13 This invention illustrates a flowchart of a device management method provided in an exemplary embodiment of the present application. The method can be executed by a client and may include the following steps: S1310: Send the first message to the device.

[0159] The first message carries first data, which is in JSON format.

[0160] For information about the client, please refer to [link / reference]. Figures 1-12 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0161] S1320: Receive the second message returned by the device based on the first message.

[0162] The second message carries second data, which is obtained by the device using a WEB process to convert the execution result corresponding to the target command. The target command is obtained by the device using the WEB process to convert the first data. The second data is in JSON format, the target command is in object format, and the execution result is in object format.

[0163] In this embodiment, a first message carrying first data in JSON format is sent to the device. Then, a second message carrying second data is received from the device based on the first message. This second data is obtained by the device using a web process to convert the execution result corresponding to the target command. The target command is obtained by the device using a web process to convert the first data. The second data is in JSON format, the target command is in object format, and the execution result is in object format. Thus, the client only sends a first message carrying JSON content. The device then converts the JSON-formatted first data in the first message into an internal command, enabling the reuse of internal commands. This converts external management operations into independent internal management operations, avoiding complex management configurations on the client side. Furthermore, after obtaining the first execution result in object format, the device converts it back into JSON-formatted second data. This allows the client to directly obtain the response result without complex parsing, again avoiding complex management configurations on the client side and reducing maintenance costs. This achieves convenient and efficient management of OTN devices. Furthermore, even if new commands are added to the device, there is no need to modify the JSON conversion rules, and convenient and efficient management of OTN devices can still be achieved. In addition, this can reduce reliance on professional network administrators, making the management of OTN devices more decentralized, reducing the need for professional skills, and thus reducing overall operation and maintenance costs.

[0164] In one exemplary embodiment, before sending the first message to the device, the method further includes: acquiring the first data; determining a processing interface corresponding to the data structure of the first data; determining a requested URL based on the IP address of the device and the processing interface; and generating the first message based on the first data and the URL.

[0165] In one exemplary embodiment, determining the processing interface corresponding to the data structure of the first data may include: in response to the first data's data structure being a YANG model structure based on the NETCONF protocol, determining the processing interface as an interface for processing YANG model data. For details regarding the URL, processing interface, YANG model structure, and NETCONF protocol, please refer to... Figures 1-12 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0166] It is understandable that by determining the processing interface corresponding to the data structure of the first data and requesting that processing interface to process the first data, it can be ensured that the first data can be processed correctly.

[0167] In an exemplary embodiment, before sending the first message to the device, the method further includes: sending a login request to the device, wherein the login request carries login information and is used to request the device to authenticate the client based on the login information; and receiving first response data returned by the device based on the authentication result.

[0168] For details regarding login, please refer to [link / reference]. Figures 1-12 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0169] In one exemplary embodiment, the method further includes: sending a logout request to the device, wherein the logout request is used to request the device to perform a logout operation; and receiving second response data returned by the device based on the execution result of the logout operation.

[0170] For details regarding the logout, please refer to [link / reference]. Figures 1-12 The relevant descriptions in the illustrated embodiments will not be repeated here.

[0171] like Figure 14 As shown in the figure, this application embodiment also provides an electronic device 1400, including a processor 1410 and a memory 1420. The memory 1420 stores a program or instructions that can run on the processor 1410. When the program or instructions are executed by the processor 1410, they implement the various processes of the above-described device management method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0172] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described device management method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0173] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0174] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device management method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0175] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0176] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described device management method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0177] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0178] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0179] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. A device management method characterized by, Applied to the device side, including: In response to receiving a first message sent by the client, the first data carried in the first message is converted into a target command using a web process, wherein the first data is in JSON format and the target command is in object format; In response to the completion of the target command execution, the first execution result corresponding to the target command is converted into second data using the WEB process, wherein the format of the first execution result is the object format and the format of the second data is JSON format; A second message carrying the second data is returned to the client.

2. The method according to claim 1, characterized in that, The first message received from the client includes: The first message is received by a target process, wherein both the target process and the first message correspond to a target transmission protocol.

3. The method according to claim 2, characterized in that, The step of returning a second message carrying the second data to the client includes: The second data is encapsulated into the second message using the target process, wherein the second message corresponds to the target transmission protocol; The second message is returned to the client.

4. The method according to claim 1, characterized in that, The step of using a web process to convert the first data carried in the first message into a target command includes: Determine the target format; The first data is converted into third data using the web process, wherein the format of the third data is the target format; The third data in the target format is converted into the target command in the object format.

5. The method according to claim 4, characterized in that, The determination of the target format includes: Obtain the processing interface corresponding to the first data from the Uniform Resource Locator (URL) contained in the first message; In response to the fact that the processing interface is an interface for processing YANG model data, the data structure of the first data is determined to be a YANG model structure based on the NETCONF protocol, wherein the data format corresponding to the YANG model structure based on the NETCONF protocol is XML format; The target format is determined to be the XML format.

6. The method according to claim 4, characterized in that, The step of converting the third data in the target format into the target command in the object format includes: In response to the target format being XML, the NETCONF process is used to convert the third data in the XML format into the target command in the object format.

7. The method according to claim 1, characterized in that, The step of using the web process to convert the first execution result corresponding to the target command into second data includes: The first execution result is converted into fourth data using the NETCONF process, wherein the fourth data is in XML format; The fourth data is converted into the second data using the web process.

8. The method according to claim 1, characterized in that, Before the response to the completion of the target command execution, the method further includes: The business entity corresponding to the target command is invoked to execute the target command.

9. The method according to claim 8, characterized in that, The step of invoking the business entity corresponding to the target command to execute the target command includes: In response to the requirement of participating in execution based on the target board, a board command is constructed based on the target command; The board command is executed through the target board.

10. The method according to claim 9, characterized in that, Before converting the first execution result corresponding to the target command into second data using the web process, the method further includes: Obtain the second execution result corresponding to the target board; Based on the second execution result, the first execution result is generated using the business entity.

11. A method for managing equipment, characterized in that, Applied to the client side, including: Send a first message to the device, wherein the first message carries first data, and the first data is in JSON format; The device receives a second message returned by the device based on the first message, wherein the second message carries second data, the second data is obtained by the device using a WEB process to convert the execution result corresponding to the target command in a specific format, the target command is obtained by the device using the WEB process to convert the first data in a specific format, the format of the second data is JSON format, the format of the target command is object format, and the format of the execution result is object format.

12. The method according to claim 11, characterized in that, Before sending the first message to the device, the method further includes: Obtain the first data; Determine the processing interface corresponding to the data structure of the first data; The requested URL is determined based on the IP address of the device and the processing interface. The first message is generated based on the first data and the URL.

13. The method according to claim 12, characterized in that, The process interface for determining the data structure corresponding to the first data includes: In response to the fact that the data structure of the first data is a YANG model structure based on the NETCONF protocol, the processing interface is determined to be an interface for processing YANG model data.

14. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the device management method as described in any one of claims 1-13.

15. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device management method as described in any one of claims 1-13.

16. A computer program product, characterized in that, The computer program product includes program instructions that, when executed by a computer, cause the computer to perform the steps of the device management method as described in any one of claims 1-13.

Images