Multi-protocol adaptation service processing method and system

Abstract

The present application discloses a multi-protocol adapted business processing method and system, wherein the server-side method includes: receiving a business processing request sent by a client that has deployed a first system, the business processing request carrying business data to be sent; when the data format of the business data to be sent is not a preset default data format, converting the data format of the business data to be sent into a preset default data format according to a stored multi-protocol adapter to obtain first business data; identifying a second system to which the business data to be sent needs to flow; when the data request format of the second system is not a preset default data format, converting the data format of the first business data into a data request format according to a multi-protocol adapter to obtain second business data; and pushing the second business data to the client that has deployed the second system. Therefore, by adopting the embodiment of the present application, the development work of point-to-point docking can be avoided, while meeting business scenarios with high real-time requirements.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a multi-protocol adapted service processing method and system. Background Art

[0002] With the diversification of business and the acceleration of digital transformation, enterprises need to integrate multiple different types of application systems to process business. Because these systems use different protocols and data formats—for example, financial systems use the WebService protocol, IoT systems rely on MQTT message queues, and production systems only expose RESTful APIs—data flow between these systems is difficult. To achieve efficient business process management, these systems require efficient data interaction and information sharing.

[0003] In related technologies, enterprises typically use a point-to-point integration approach to implement data exchange between different systems. However, point-to-point connections require separate maintenance. Changes to the interface or protocol of one system require readjustment and retesting of all related connections, placing a heavy burden on the enterprise's IT department. Furthermore, point-to-point integration often relies on a polling mechanism for message push, making it difficult to meet the demands of business scenarios with high real-time requirements. Summary of the Invention

[0004] The embodiments of this application provide a multi-protocol adaptive service processing method and system. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is provided below. This summary is not intended to be a comprehensive review, identify key or important components, or delineate the scope of protection for these embodiments. Its sole purpose is to present some concepts in a simplified form, serving as a prelude to the detailed description that follows.

[0005] In a first aspect, an embodiment of the present application provides a multi-protocol adaptation service processing method, which is applied to a server, and the method includes:

[0006] receiving a business processing request sent by a client that has deployed the first system, where the business processing request is used to request a client that has deployed the second system to perform business process collaborative processing, and the business processing request carries business data to be sent;

[0007] If the data format of the service data to be sent is not a preset default data format, converting the data format of the service data to be sent into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-device service node to obtain the first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format;

[0008] A second system for identifying a desired flow direction of the business data to be sent;

[0009] In a case where the data request format of the second system is not a preset default data format, converting the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data;

[0010] The second business data is pushed to the client where the second system is deployed via the HTTP protocol.

[0011] Optionally, the method further includes:

[0012] receiving a business processing result sent by a client that has deployed the second system;

[0013] Converting the data format of the business processing result into the data request format of the first system according to the multi-protocol adapter to obtain the final business processing result of the business processing request;

[0014] The final business processing result is sent to the client where the first system is deployed.

[0015] Optionally, the method further includes:

[0016] Monitor the service status of the preset master service node through the preset health detection mechanism;

[0017] In the event of a node failure in the service state, traffic is switched to the pre-device service node through the Kubernetes cluster.

[0018] Optionally, feature templates are pre-set for different data protocols;

[0019] Converting the data format of the service data to be sent into a preset default data format to obtain first service data includes:

[0020] Extract the fixed fields of the message header of the business data to be sent;

[0021] Establish a pattern fingerprint based on the fixed fields in the message header;

[0022] Perform pattern matching on the pattern fingerprint and the feature templates set for different data protocols to obtain matching results;

[0023] When the matching result indicates a successful match, obtaining a target feature template that successfully matches the pattern fingerprint;

[0024] Determine the target data protocol corresponding to the target feature template;

[0025] Obtaining a target data bidirectional conversion script between the data format of the target data protocol and the preset default data format from the data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format included in the multi-protocol adapter;

[0026] The data format of the to-be-sent business data is converted into a preset default data format through a target data bidirectional conversion script to obtain first business data.

[0027] Optionally, a pattern fingerprint is created based on fixed fields in the message header, including:

[0028] Convert the fixed fields in the message header into a hexadecimal string to obtain the original byte code;

[0029] Encode the text field in the fixed field of the message header to obtain a semantic hash code;

[0030] Encode the field length value of the fixed field in the message header to obtain a structural feature code;

[0031] Combine the original byte encoding, semantic hash encoding, and structural feature encoding to obtain the field feature triple;

[0032] The field feature triplet is used as the original parameter of the compression algorithm, and the compression algorithm is executed to compress the field feature triplet to generate a 256-bit fixed-length pattern fingerprint.

[0033] Optionally, the method further includes:

[0034] If the matching result indicates a match failure, the nested structure of the payload of the service data to be sent is analyzed to determine the discreteness of the JSON key-value pairs and the periodicity characteristics of the device data as structural entropy features;

[0035] According to the pre-trained lightweight classification model, the structural entropy features are classified to obtain the classification results;

[0036] Perform fuzzy matching between the classification results and the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed field in the message header;

[0037] Creating a field value conversion script between each field in the data format of the original protocol and each field in the preset default data format, and obtaining a data bidirectional conversion script between the data format of the original protocol and the preset default data format;

[0038] A data bidirectional conversion script between the data format of the original protocol and the preset default data format is stored in the multi-protocol adapter.

[0039] Optionally, the structural entropy features are classified to obtain classification results, including:

[0040] Quantify the structural entropy characteristics to obtain the discrete value of JSON key-value pairs and the periodicity intensity of device data time series;

[0041] Scale the discreteness value and the periodicity intensity of the device data time series to a standardized range that the model can handle, and obtain the standardized feature vector;

[0042] The normalized feature vector is input into the pre-trained lightweight classification model, and the predicted probability distribution corresponding to each original protocol corresponding to the structural entropy feature is output;

[0043] From the predicted probability distribution, obtain the protocol label corresponding to the highest probability;

[0044] The protocol label corresponding to the highest probability is taken as the classification result.

[0045] Optionally, generate a pre-trained lightweight classification model by following these steps:

[0046] extracting a protocol conversion log from a multi-protocol adapter log, wherein the protocol conversion log includes a dispersion value, a periodicity intensity, and a protocol type label;

[0047] Construct the initial training set based on the protocol conversion log;

[0048] Obtain the business system labels associated with the protocols of the initial training set;

[0049] Business scenario weighting is performed on the initial training set and business system labels to obtain a business scenario weighted feature vector set;

[0050] The feature vector set weighted for business scenarios is grouped by protocol type, and the mean and standard deviation of each feature group are calculated. Z-score normalization is also performed within the group to obtain the normalized feature vectors of the protocol cluster group.

[0051] Create a lightweight classification model that can output multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. The two nodes in the input layer correspond to discreteness and periodicity intensity, and the output layer includes a softmax probability distribution.

[0052] Input the normalized feature vector of the protocol cluster group into the lightweight classification model for model training and output the model loss value;

[0053] When the model loss value reaches the minimum, a pre-trained lightweight classification model is generated.

[0054] In a second aspect, an embodiment of the present application provides a multi-protocol adaptation service processing method, which is applied to a client, and the method includes:

[0055] receiving second business data sent by the server; the second business data is obtained by the server converting the data format of the business data to be sent sent by the client deploying the first system according to the multi-protocol adapter; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and a preset default data format;

[0056] generating a business process collaborative processing request based on the second business data;

[0057] Store business process collaborative processing requests in a preset distributed message queue, asynchronously process business process collaborative processing requests, and obtain business processing results; the preset distributed message queue is a Kafka queue designed with a distributed architecture;

[0058] Send business processing results to the server.

[0059] In a third aspect, an embodiment of the present application provides a multi-protocol adapted service processing system, the system comprising:

[0060] A receiving module, configured to receive a business processing request sent by a client that has deployed the first system, wherein the business processing request is used to request a client that has deployed the second system to perform business process collaborative processing, and the business processing request carries business data to be sent;

[0061] A first conversion module is configured to, when the data format of the service data to be sent is not a preset default data format, convert the data format of the service data to be sent into the preset default data format according to a multi-protocol adapter stored in a preset main service node or a pre-device service node, thereby obtaining first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format;

[0062] an identification module, configured to identify a second system to which the service data to be sent needs to flow;

[0063] a second conversion module configured to convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data when the data request format of the second system is not a preset default data format;

[0064] The push module is used to push the second business data to the client where the second system is deployed through the HTTP protocol.

[0065] The technical solutions provided by the embodiments of the present application may have the following beneficial effects:

[0066] In an embodiment of the present application, on the one hand, a multi-protocol adapter includes scripts for bidirectional data conversion between the data formats of different data protocols and a preset default data format. This multi-protocol adapter acts as an intermediate layer, uniformly handling protocol conversions. When a new system is connected, only the adapter script needs to be configured, without rewriting any code in the system. This significantly reduces development workload, avoids point-to-point docking development work, and meets business scenarios with high real-time requirements. On the other hand, by dynamically identifying protocols using a pre-trained lightweight classification model, the model can adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functionality of the multi-protocol adapter.

[0067] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0069] Figure 1 This is a flowchart of a multi-protocol adaptation service processing method provided by an embodiment of the present application;

[0070] Figure 2 This is a schematic diagram of a scenario of interaction between a client and a server provided in an embodiment of the present application;

[0071] Figure 3 This is a flowchart of another multi-protocol adaptation service processing method provided by an embodiment of the present application;

[0072] Figure 4 This is a flow chart of a lightweight classification model training method provided in an embodiment of the present application;

[0073] Figure 5 This is a schematic diagram of the model architecture of a lightweight classification model provided in an embodiment of the present application;

[0074] Figure 6 This is a structural diagram of a multi-protocol adaptation service processing system provided by this application;

[0075] Figure 7 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0076] The following description and the drawings sufficiently illustrate specific embodiments of the application to enable those skilled in the art to practice them.

[0077] It should be clear that the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0078] When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of systems and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0079] In the description of this application, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances. In addition, in the description of this application, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship.

[0080] Currently, enterprises usually use point-to-point integration to achieve data interaction between different systems.

[0081] The inventors realized that point-to-point connections require separate maintenance. When the interface or protocol of one system changes, all related connections need to be readjusted and retested, placing a heavy burden on the company's IT department. Furthermore, point-to-point integration approaches often rely on polling mechanisms for message push, making them difficult to meet the demands of real-time business scenarios.

[0082] In order to solve the above problems, the present application provides a multi-protocol adaptation business processing method and system to solve the problems existing in the above-mentioned related technical problems. In an embodiment of the present application, on the one hand, the multi-protocol adapter includes a data bidirectional conversion script between the data format of different data protocols and the preset default data format. The multi-protocol adapter serves as an intermediate layer to uniformly handle protocol conversion. When a new system is connected, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload and avoids the development work of point-to-point docking. At the same time, it can meet business scenarios with high real-time requirements. On the other hand, the protocol is dynamically identified by a pre-trained lightweight classification model, and the model can adaptively identify the new protocol. It can automatically generate and store new data conversion scripts, and can continuously enrich and optimize the functions of the multi-protocol adapter. The following uses an exemplary embodiment for detailed description.

[0083] The following will be combined with the Figure 1 -Attached Figure 5 This article details the multi-protocol adaptive service processing method provided in the embodiments of this application. This method can be implemented using a computer program and run on a multi-protocol adaptive service processing system based on the von Neumann architecture. This computer program can be integrated into an application or run as a standalone tool application.

[0084] See Figure 1 , provides a flowchart of a multi-protocol adaptation service processing method for an embodiment of the present application, which is applied to the server. Figure 1 As shown, the method of the embodiment of the present application may include the following steps:

[0085] S101, receiving a business processing request sent by a client that has deployed a first system, where the business processing request is used to request a client that has deployed a second system to perform business process collaborative processing, and the business processing request carries business data to be sent;

[0086] The first system is the source system initiating the business request (e.g., a finance system using the WebService protocol). The second system is the target system that needs to collaborate on the business (e.g., a production system using a RESTful API). The business processing request contains a communication message containing business data and operational instructions (e.g., a payment request or work order issuance). The business data to be sent is the actual business information to be transmitted in the request (e.g., order details in JSON format).

[0087] In some embodiments of the present application, the first system client sends a business processing request to the server, and the server listens to the business processing request from the first system through the HTTP / HTTPS port, separates the business data and metadata from the message carried by the business processing request, that is, locates the data payload (JSON in the HTTP request body, label in the SOAP message), strips off the protocol encapsulation (such as removing the HTTP header, MQTT Fixed Header), obtains pure business data (such as {"orderId": "123", "amount": 100.00}), and obtains the business data to be sent.

[0088] Furthermore, the business data to be sent is checked to see if it conforms to a preset default format (e.g., JSON). For example, the business data to be sent is parsed using the preset default data format, and the parsing result is captured (e.g., an error is reported when attempting to parse XML data into JSON), and the Boolean flag isDefaultFormat (True / False) is obtained.

[0089] Furthermore, when the Boolean flag is True, it is determined that the data format of the service data to be sent is the preset default data format. When the Boolean flag is False, it is determined that the data format of the service data to be sent is not the preset default data format.

[0090] S102: If the data format of the service data to be sent is not a preset default data format, converting the data format of the service data to be sent into the preset default data format according to a multi-protocol adapter stored in a preset main service node or a pre-device service node to obtain first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format;

[0091] The default data format is the intermediate data format (e.g., JSON) used uniformly within the system. The primary service node is the primary service instance currently responsible for protocol conversion. The backup service node is a standby service instance in hot standby mode, ready to take over if the primary node fails. The multi-protocol adapter contains a component library that implements the logic for converting various protocols into and from the default format. The bidirectional data conversion script is an executable program for both forward (protocol to default) and reverse (default to protocol) conversions.

[0092] In some embodiments of the present application, when the data format of the service data to be sent is a preset default data format, step S103 is executed.

[0093] In other embodiments of the present application, when the data format of the business data to be sent is not the preset default data format, the service status of the preset main service node is monitored through a preset health detection mechanism, and when the service status is normal, the multi-protocol adapter stored in the main service node is obtained.

[0094] Alternatively, in the event of a node failure in the service state, traffic is switched to the pre-device service node through the Kubernetes cluster, and the multi-protocol adapter stored in the standby service node is obtained.

[0095] In the embodiment of the present application, the high availability and stability of the service are ensured through the health detection mechanism and the traffic switching mechanism of the Kubernetes cluster, and the impact of node failure on the business is reduced.

[0096] Among them, feature templates are pre-set for different data protocols.

[0097] Specifically, the specific process of converting the data format of the business data to be sent into a preset default data format to obtain the first business data includes: extracting the fixed fields of the message header of the business data to be sent; establishing a pattern fingerprint based on the fixed fields of the message header; performing pattern matching on the pattern fingerprint with the feature templates set for different data protocols to obtain a matching result; when the matching result indicates a successful match, obtaining a target feature template that successfully matches the pattern fingerprint; determining the target data protocol corresponding to the target feature template; obtaining a target data bidirectional conversion script between the data format of the target data protocol and the preset default data format from the data bidirectional conversion scripts between the data formats of different data protocols included in the multi-protocol adapter and the preset default data format; converting the data format of the business data to be sent into the preset default data format through the target data bidirectional conversion script to obtain the first business data.

[0098] For example, extract the fixed fields of the message header of the business data to be sent. The fixed fields of the message header include fields such as the protocol version number, message type, and data length. Assume that the received message header is: Protocol Version: 1.0, Message Type: 0x01, Data Length: 128. Convert these fields into a pattern fingerprint. The resulting pattern fingerprint is a fixed-length string, such as: Mode Fingerprint: "0x312e30|0x01|hash(128)". Match the generated pattern fingerprint with the preset feature template. The feature template is pre-set for different data protocols, such as: Modbus: "0x312e30|0x01|hash(128)", OPC UA: "0x322e30|0x02|hash(256)", and custom protocol: "0x332e30|0x03|hash(64)". It can be seen that the pattern fingerprint successfully matches the Modbus feature template. After a successful match, the target feature template that matches the pattern fingerprint is obtained, namely the Modbus template. The target data protocol corresponding to this template is determined to be Modbus. The data bidirectional conversion script between the Modbus protocol and the preset default data format (JSON) is obtained from the multi-protocol adapter. The conversion script is as follows:

[0099] function modbusToJson(data) {

[0100] return {

[0101] "device_id": data.deviceId,

[0102] "sensor_value": data.value,

[0103] "timestamp": data.timestamp

[0104] };

[0105] }.

[0106] Use the above conversion script to convert the Modbus format data sent by the client that deployed the first system into JSON format. Assume that the original Modbus data is:

[0107] {

[0108] "deviceId": 101,

[0109] "value": 25.5,

[0110] "timestamp": 1678000000

[0111] }.

[0112] The first business data in JSON format after conversion is:

[0113] {

[0114] "device_id": 101,

[0115] "sensor_value": 25.5,

[0116] "timestamp": 1678000000

[0117] }.

[0118] In the embodiments of the present application, by extracting fixed fields from the message header and establishing a pattern fingerprint, and then performing pattern matching in combination with a preset feature template, the data protocol used by the business data to be sent can be quickly and accurately identified. The corresponding bidirectional data conversion script is then obtained to convert the data format into a preset default format. This process not only improves the automation and efficiency of data processing, but also enhances the flexibility and scalability of the system, making it easy to handle data exchange requirements across multiple protocols and reducing the complexity and cost of system integration.

[0119] In some embodiments of the present application, the specific process of establishing a pattern fingerprint based on the fixed field of the message header includes: converting the fixed field of the message header into a hexadecimal string to obtain the original byte code; encoding the text type field in the fixed field of the message header to obtain a semantic hash code; encoding the field length value of the fixed field of the message header to obtain a structural feature code; combining the original byte code, the semantic hash code and the structural feature code to obtain a field feature triple; using the field feature triple as the original parameter of the compression algorithm, and executing the compression algorithm to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint.

[0120] For example, the fixed fields in the message header are protocol version number: 1.0, message type: 0x01, and data length: 128. Protocol version number: 1.0 is converted to the hexadecimal string "31 2e 30", message type: 0x01 is already in hexadecimal and remains unchanged as "01", and data length: 128 is converted to hexadecimal as "80". After combining, the original byte code is "31 2e 30 0180", which is the original byte code.

[0121] For example, the protocol version number: 1.0 is encoded using a hash algorithm (such as SHA-256), and the first 8 bits are taken as the semantic hash code: "a94a8fe5" to obtain the semantic hash code.

[0122] For example, the field length value of the fixed field in the message header is encoded to obtain the structural feature code: the protocol version number length: 3 (character length of 1.0), the message type length: 1 (byte length of 0x01), the data length length: 1 (byte length of 128), and a certain encoding method (such as simple numerical encoding): "03 01 01" is used to obtain the structural feature code.

[0123] For example, the above three codes are combined into a field feature triple ("31 2e 30 01 80", "a94a8fe5", "03 01 01").

[0124] For example, use a compression algorithm (such as SHA-256) to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint:

[0125] SHA-256("31 2e 30 01 80" + "a94a8fe5" + "03 01 01") = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855".

[0126] In an embodiment of the present application, by combining and compressing multiple features of fixed fields in the message header (raw byte encoding, semantic hash encoding, and structural feature encoding) into a fixed-length pattern fingerprint, the characteristics of the data message can be efficiently and accurately represented. This method not only quickly identifies and distinguishes data messages of different protocols, but also significantly reduces the complexity of data storage and processing. At the same time, the fixed-length pattern fingerprint facilitates subsequent pattern matching and classification processing, improving the overall performance and scalability of the system, and is suitable for rapid protocol identification and adaptation in large-scale data processing and complex protocol environments.

[0127] In other embodiments of the present application, when the matching result indicates a matching failure, the nested structure of the payload of the business data to be sent is analyzed to determine the discreteness of the JSON key-value pairs and the periodic characteristics of the device data as structural entropy features; the structural entropy features are classified according to a pre-trained lightweight classification model to obtain a classification result; the classification result is fuzzy matched with the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed field of the message header; a field value conversion script is created between each field in the data format of the original protocol and each field in the preset default data format to obtain a data bidirectional conversion script between the data format of the original protocol and the preset default data format; and the data bidirectional conversion script between the data format of the original protocol and the preset default data format is stored in multiple protocol adapters.

[0128] For example, the payload of the service data to be sent is as follows:

[0129] {

[0130] "device_id": "sensor_001",

[0131] "timestamp": 1678000000,

[0132] "readings": [

[0133] {"value": 25.5, "unit": "Celsius"},

[0134] {"value": 60.0, "unit": "Humidity"}

[0135] ],

[0136] "status": {

[0137] "code": 200,

[0138] "message": "OK"

[0139] }

[0140] }.

[0141] The dispersion is calculated by analyzing the distribution of key-value pairs in the JSON object in the payload of the service data to be sent. For example, the number and distribution of keys at different levels can be counted. The root level has three keys (device_id, timestamp, readings, and status). The readings array contains two objects, each with two keys (value and unit). The status object has two keys (code and message). The distribution of these keys can be calculated. For example, if the keys at the root level are evenly distributed, while the objects in the readings array have a consistent structure, this distribution can be used to quantify the dispersion.

[0142] Use a sliding window technique to analyze periodicity. The timestamp field represents the timestamp of data collection. By calculating the difference between adjacent timestamps, you can detect periodicity in data collection. For example, if the differences between timestamps are roughly the same, it indicates that the data collection has periodic characteristics.

[0143] This application pre-trains a lightweight classification model that can classify data packets based on structural entropy features (discreteness and periodicity). The model takes the discreteness and periodicity features calculated above as input and outputs a classification result. For example, the model might classify the data packet as a "sensor data packet."

[0144] Perform a fuzzy match between the classification results and the fields in the pre-set original protocol library. Assume the original protocol library contains multiple protocols, each with its own characteristic fields. Through fuzzy matching, find the original protocol that most closely resembles the datagram structure. For example, the matching result may indicate that the datagram conforms to the characteristics of the "Modbus TCP" protocol.

[0145] Create a field value conversion script based on the matched original protocol (Modbus TCP) and the preset default data format (assuming JSON format). For example, the script may be as follows:

[0146] function modbusToJson(data) {

[0147] return {

[0148] "device_id": data.device_id,

[0149] "timestamp": data.timestamp,

[0150] "sensor_readings": data.readings.map(reading =>({

[0151] "value": reading.value,

[0152] "unit": reading.unit

[0153] })),

[0154] "status_code": data.status.code,

[0155] "status_message": data.status.message

[0156] };

[0157] }.

[0158] The conversion script created above is stored in the multi-protocol adapter so that it can be directly used when processing similar data packets later.

[0159] In the embodiments of the present application, even if pattern matching fails, the data type can be determined by analyzing its structural characteristics (such as the discreteness of JSON key-value pairs and the periodicity of device data) and classified using a lightweight classification model. Fuzzy matching is then used to identify the corresponding original protocol and create a corresponding data conversion script. This approach not only improves the system's fault tolerance but also enhances its adaptability and scalability. It can effectively handle unknown or non-standard data formats, ensuring smooth data conversion and transmission between different protocols, and improving the overall stability and reliability of the system.

[0160] In some embodiments of the present application, the structural entropy features are classified, and the specific process of obtaining the classification results includes: quantifying the structural entropy features to obtain the discrete value of the JSON key-value pair and the periodic strength of the device data time series; scaling the discrete value and the periodic strength of the device data time series to a standardized range that the model can handle to obtain a standardized feature vector; inputting the standardized feature vector into a pre-trained lightweight classification model, and outputting the predicted probability distribution corresponding to each original protocol corresponding to the structural entropy feature; obtaining the protocol label corresponding to the highest probability from the predicted probability distribution; and taking the protocol label corresponding to the highest probability as the classification result.

[0161] S103, identifying the second system to which the service data to be sent needs to flow;

[0162] In the business process, the second system is the target system that receives and processes the business data to be sent. It corresponds to the "first system" that sends the data and performs business collaborative processing.

[0163] In an embodiment of the present application, the second system that is to identify the required flow direction of the business data to be sent can ensure that the data is sent to the correct processing node, thereby achieving efficient collaboration between different systems.

[0164] S104, when the data request format of the second system is not a preset default data format, converting the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data;

[0165] In some embodiments of the present application, when the data request format of the second system is a preset default data format, it indicates that the data format of the data protocol used by the second system for business collaboration with the first system is the preset default data format. At this time, the first business data can be directly pushed to the client where the second system is deployed through the HTTP protocol.

[0166] In other embodiments of the present application, when the data request format of the second system is the preset default data format, it means that the data format of the data protocol used by the second system for business collaboration with the first system is not the preset default data format. At this time, it is necessary to convert the data format of the first business data into the data request format according to the multi-protocol adapter to obtain the second business data.

[0167] It should be noted that the conversion process is the same as the logic of converting the data format of the to-be-sent business data into the preset default data format in step S102, which will not be described here in detail. For details, please refer to the specific implementation logic in step S102.

[0168] S105: Push the second business data to the client where the second system is deployed through the HTTP protocol.

[0169] HTTP (Hypertext Transfer Protocol) is an application-layer communication protocol used for data exchange between clients and servers. Secondary service data refers to processed and converted data ready for transmission to a secondary system. This data has been adapted to the data format required by the secondary system.

[0170] In some embodiments of the present application, the converted XML data (second business data) is sent to the client of the second system using the HTTP protocol. After receiving the HTTP request, the client of the second system parses the XML data, performs business collaboration, obtains business processing results, and finally feeds the business processing results back to the server.

[0171] Furthermore, the server receives the business processing results sent by the client deployed with the second system; converts the data format of the business processing results into the data request format of the first system according to the multi-protocol adapter to obtain the final business processing results of the business processing request; and sends the final business processing results to the client deployed with the first system.

[0172] For example, a business person creates a new purchase order on a client where the first system is deployed, triggering the approval process. Protocol adaptation is first performed: the integration engine receives data through the WebService protocol adapter and automatically parses fields (such as order number, amount, and supplier). Data standardization then occurs: the format is converted to the platform's unified JSON Schema, extracting key fields (such as order_id, amount, and supplier). Rule engine matching: Based on preset approval rules (such as multi-level approval required for amounts > 100,000), the process engine is called to generate an approval node (Finance Department → Purchasing Director → General Manager). The JSON data is converted into the second system's RESTful API request format corresponding to the approval node (such as POST / approval), and pushed to the client where the second system is deployed via the HTTP protocol.

[0173] For example Figure 2 As shown, Figure 2 This is a scenario diagram of the interaction between a client and a server provided by the present application, in which a client deployed with a first system sends a business processing request to a server; the server receives the business processing request sent by the client deployed with the first system, and the business processing request is used to request a client deployed with a second system to perform collaborative processing of a business process, and the business processing request carries business data to be sent; when the data format of the business data to be sent is not a preset default data format, the server converts the data format of the business data to be sent into a preset default data format according to a multi-protocol adapter stored in a preset main service node or a pre-device service node, and obtains first business data, and the multi-protocol adapter includes a data bidirectional conversion script between data formats of different data protocols and a preset default data format; the server identifies the second system to which the business data to be sent needs to flow; when the data request format of the second system is not a preset default data format, the server converts the data format of the first business data into a data request format according to the multi-protocol adapter, and obtains second business data; the server pushes the second business data to the client deployed with the second system via the HTTP protocol.

[0174] In an embodiment of the present application, on the one hand, a multi-protocol adapter includes scripts for bidirectional data conversion between the data formats of different data protocols and a preset default data format. This multi-protocol adapter acts as an intermediate layer, uniformly handling protocol conversions. When a new system is connected, only the adapter script needs to be configured, without rewriting any code in the system. This significantly reduces development workload, avoids point-to-point docking development work, and meets business scenarios with high real-time requirements. On the other hand, by dynamically identifying protocols using a pre-trained lightweight classification model, the model can adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functionality of the multi-protocol adapter.

[0175] See Figure 3 , provides a flowchart of a multi-protocol adaptation service processing method for the embodiment of the present application, which is applied to the client. Figure 3 As shown, the method of the embodiment of the present application may include the following steps:

[0176] S201, receiving second business data sent by a server; the second business data is obtained by the server converting the data format of the business data to be sent sent by a client that deploys the first system according to a multi-protocol adapter; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and a preset default data format;

[0177] S202, generating a business process collaborative processing request based on the second business data;

[0178] S203, storing the business process collaborative processing request in a preset distributed message queue, asynchronously processing the business process collaborative processing request, and obtaining a business processing result; the preset distributed message queue is a Kafka queue designed with a distributed architecture;

[0179] S204: Send the business processing result to the server.

[0180] In some embodiments, business process collaborative processing requests are asynchronously processed through Kafka queues to obtain business processing results. Partitioning strategies ensure that high-priority orders (such as urgent purchases) are processed first. Status writeback: After the second system returns the approval result (approved / rejected), the engine converts the result format and writes it back to the server, updating the transaction status in the Redis cluster.

[0181] In this embodiment, the second system's message processing layer adopts a distributed architecture design, building a high-concurrency, low-latency message queue based on Apache Kafka. This allows for asynchronous processing of millions of messages per second, effectively addressing the massive data reporting scenarios of IoT devices. Partitioning strategies and dynamic load balancing algorithms ensure stable message processing latency at the millisecond level.

[0182] In an embodiment of the present application, on the one hand, a multi-protocol adapter includes scripts for bidirectional data conversion between the data formats of different data protocols and a preset default data format. This multi-protocol adapter acts as an intermediate layer, uniformly handling protocol conversions. When a new system is connected, only the adapter script needs to be configured, without rewriting any code in the system. This significantly reduces development workload, avoids point-to-point docking development work, and meets business scenarios with high real-time requirements. On the other hand, by dynamically identifying protocols using a pre-trained lightweight classification model, the model can adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functionality of the multi-protocol adapter.

[0183] See Figure 4 , provides a flow chart of a lightweight classification model training method for the embodiment of the present application. Figure 4 As shown, the method of the embodiment of the present application may include the following steps:

[0184] S301, extracting a protocol conversion log from a multi-protocol adapter log, where the protocol conversion log includes a dispersion value, a periodicity strength, and a protocol type tag;

[0185] In some embodiments of the present application, when processing data, the multi-protocol adapter records detailed information about each protocol conversion in a multi-protocol adapter log file. These logs include discrete values, periodic strengths, and protocol type labels. When training a model, protocol conversion logs are extracted from the multi-protocol adapter logs. The protocol conversion logs include discrete values, periodic strengths, and protocol type labels. The log contents may include:

[0186] 2024-12-16 10:00:00, Discreteness: 0.85, Periodicity: 0.92, Protocol: Modbus;

[0187] 2024-12-16 10:01:00, Discreteness: 0.78, Periodicity: 0.88, Protocol:OPC UA;

[0188] S302, constructing an initial training set based on the protocol conversion log;

[0189] In some embodiments of the present application, each sample in the initial training set includes a discreteness value, a periodicity strength, and a protocol type label. For example: [

[0191] {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus"},

[0192] {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA"}

[0193] ].

[0194] S303, obtaining a business system label associated with the protocol of the initial training set;

[0195] In some embodiments of the present application, each protocol type is associated with a specific business system. For example, the Modbus protocol is commonly used in industrial automation systems, and OPC UA is used for enterprise-level industrial communications. These business system labels are added to the training set, for example: [

[0197] {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus", "business_system": "Industrial Automation"},

[0198] {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA", "business_system": "Enterprise Communication"}

[0199] ].

[0200] S304, performing business scenario weighting on the initial training set and the business system labels to obtain a business scenario weighted feature vector set;

[0201] In some embodiments of the present application, a weight is assigned to each sample based on the importance of the business scenario. For example, an industrial automation system may be more important than an enterprise-level communication system, so it is assigned a higher weight, such as: [

[0203] {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus", "business_system": "Industrial Automation", "weight": 1.5},

[0204] {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA", "business_system": "Enterprise Communication", "weight": 1.0}

[0205] ].

[0206] S305 , grouping the service scenario weighted feature vector set by protocol type, calculating the feature mean and standard deviation of each group, and performing Z-score normalization within the group to obtain a normalized feature vector for the protocol cluster group;

[0207] In some embodiments of the present application, the protocols are grouped by protocol type, the mean and standard deviation of each group are calculated, and the feature vectors are normalized by Z-score. For example, for the Modbus protocol group, for example:

[0208] Mean Discreteness: 0.85, Mean Periodicity: 0.92;

[0209] Std Discreteness: 0.05, Std Periodicity: 0.03.

[0210] The normalized eigenvector is: [

[0212] {"discreteness": 1.0, "periodicity": 1.0, "protocol": "Modbus"}

[0213] ].

[0214] S306: Creating a lightweight classification model capable of outputting a multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. The two nodes of the input layer correspond to discreteness and periodicity intensity, and the output layer includes a Softmax probability distribution.

[0215] For example Figure 5 As shown in Figure 1, the lightweight classification model includes an input layer with 2 nodes (corresponding to discreteness and periodicity intensity), and the output layer uses the Softmax function to output the probability distribution of multiple protocols.

[0216] S307, inputting the normalized feature vector of the protocol cluster group into the lightweight classification model for model training, and outputting the model loss value;

[0217] S308: When the model loss value reaches the minimum, a pre-trained lightweight classification model is generated.

[0218] In some embodiments of the present application, when the model loss value has not reached the minimum, the step of inputting the normalized feature vector of the protocol cluster group into the lightweight classification model for model training is continued until the model loss value reaches the minimum.

[0219] In an embodiment of the present application, a pre-trained lightweight classification model is used to dynamically identify protocols, thereby enabling the model to adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functions of the multi-protocol adapter.

[0220] The following are system embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the system embodiments of the present application, please refer to the method embodiments of the present application.

[0221] See Figure 6 , which shows a schematic diagram of the structure of a multi-protocol adaptive service processing system provided by an exemplary embodiment of the present application. The multi-protocol adaptive service processing system can be implemented as all or part of an electronic device through software, hardware, or a combination of both. The system 1 includes a receiving module 10, a first conversion module 20, an identification module 30, a second conversion module 40, and a push module 50.

[0222] A receiving module 10 is configured to receive a business processing request sent by a client that has deployed the first system. The business processing request is used to request a client that has deployed the second system to perform business process collaborative processing. The business processing request carries business data to be sent.

[0223] A first conversion module 20 is configured to convert the data format of the service data to be sent into the preset default data format according to a multi-protocol adapter stored in a preset main service node or pre-device service node, when the data format of the service data to be sent is not a preset default data format, to obtain first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format;

[0224] An identification module 30 is used to identify the second system to which the service data to be sent needs to flow;

[0225] The second conversion module 40 is configured to convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain the second service data when the data request format of the second system is not the preset default data format;

[0226] The push module 50 is configured to push the second business data to the client where the second system is deployed via the HTTP protocol.

[0227] It should be noted that the multi-protocol adaptive business processing system provided in the above embodiment only uses the division of the above-mentioned functional modules as an example when executing the multi-protocol adaptive business processing method. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the multi-protocol adaptive business processing system provided in the above embodiment and the multi-protocol adaptive business processing method embodiment are of the same concept. The implementation process is detailed in the method embodiment and will not be repeated here.

[0228] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0229] In an embodiment of the present application, on the one hand, a multi-protocol adapter includes scripts for bidirectional data conversion between the data formats of different data protocols and a preset default data format. This multi-protocol adapter acts as an intermediate layer, uniformly handling protocol conversions. When a new system is connected, only the adapter script needs to be configured, without rewriting any code in the system. This significantly reduces development workload, avoids point-to-point docking development work, and meets business scenarios with high real-time requirements. On the other hand, by dynamically identifying protocols using a pre-trained lightweight classification model, the model can adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functionality of the multi-protocol adapter.

[0230] The present application also provides a computer-readable medium having program instructions stored thereon, which, when executed by a processor, implements the multi-protocol adaptation service processing method provided by the above-mentioned various method embodiments.

[0231] The present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the multi-protocol adapted service processing methods of the above-mentioned various method embodiments.

[0232] See Figure 7 , is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 7 As shown, the electronic device 1000 may include: at least one processor 1001 , at least one network interface 1004 , a user interface 1003 , a memory 1005 , and at least one communication bus 1002 .

[0233] The communication bus 1002 is used to implement the connection and communication between these components.

[0234] The user interface 1003 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 1003 may also include a standard wired interface and a wireless interface.

[0235] The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0236] The processor 1001 may include one or more processing cores. The processor 1001 utilizes various interfaces and circuits to connect various components within the electronic device 1000. It executes instructions, programs, code sets, or instruction sets stored in the memory 1005, and accesses data stored in the memory 1005 to perform various functions and process data within the electronic device 1000. Optionally, the processor 1001 may be implemented in hardware using at least one of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 1001 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing content displayed on the display; and the modem handles wireless communications. It is understood that the modem may also be implemented independently of the processor 1001 and implemented on a separate chip.

[0237] Among them, the memory 1005 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 1005 includes a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 1005 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 1005 may also be optionally at least one storage system located away from the aforementioned processor 1001. As Figure 7As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a multi-protocol adapted business processing application.

[0238] exist Figure 7 In the electronic device 1000 shown, the user interface 1003 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 1001 can be used to call the multi-protocol adapted business processing application stored in the memory 1005 and specifically perform the following operations:

[0239] receiving a business processing request sent by a client that has deployed the first system, where the business processing request is used to request a client that has deployed the second system to perform business process collaborative processing, and the business processing request carries business data to be sent;

[0240] If the data format of the service data to be sent is not a preset default data format, converting the data format of the service data to be sent into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-device service node to obtain the first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format;

[0241] A second system for identifying a desired flow direction of the business data to be sent;

[0242] In a case where the data request format of the second system is not a preset default data format, converting the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data;

[0243] The second business data is pushed to the client where the second system is deployed via the HTTP protocol.

[0244] In one embodiment, the processor 1001 further performs the following operations:

[0245] receiving a business processing result sent by a client that has deployed the second system;

[0246] Converting the data format of the business processing result into the data request format of the first system according to the multi-protocol adapter to obtain the final business processing result of the business processing request;

[0247] The final business processing result is sent to the client where the first system is deployed.

[0248] In one embodiment, the processor 1001 further performs the following operations:

[0249] Monitor the service status of the preset master service node through the preset health detection mechanism;

[0250] In the event of a node failure in the service state, traffic is switched to the pre-device service node through the Kubernetes cluster.

[0251] In one embodiment, when the processor 1001 converts the data format of the to-be-sent service data into a preset default data format to obtain the first service data, it specifically performs the following operations:

[0252] Extract the fixed fields of the message header of the business data to be sent;

[0253] Establish a pattern fingerprint based on the fixed fields in the message header;

[0254] Perform pattern matching on the pattern fingerprint and the feature templates set for different data protocols to obtain matching results;

[0255] When the matching result indicates a successful match, obtaining a target feature template that successfully matches the pattern fingerprint;

[0256] Determine the target data protocol corresponding to the target feature template;

[0257] Obtaining a target data bidirectional conversion script between the data format of the target data protocol and the preset default data format from the data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format included in the multi-protocol adapter;

[0258] The data format of the to-be-sent business data is converted into a preset default data format through a target data bidirectional conversion script to obtain first business data.

[0259] In one embodiment, when the processor 1001 establishes a pattern fingerprint based on a fixed field in a message header, it specifically performs the following operations:

[0260] Convert the fixed fields in the message header into a hexadecimal string to obtain the original byte code;

[0261] Encode the text field in the fixed field of the message header to obtain a semantic hash code;

[0262] Encode the field length value of the fixed field in the message header to obtain a structural feature code;

[0263] Combine the original byte encoding, semantic hash encoding, and structural feature encoding to obtain the field feature triple;

[0264] The field feature triplet is used as the original parameter of the compression algorithm, and the compression algorithm is executed to compress the field feature triplet to generate a 256-bit fixed-length pattern fingerprint.

[0265] In one embodiment, the processor 1001 further performs the following operations:

[0266] If the matching result indicates a match failure, the nested structure of the payload of the service data to be sent is analyzed to determine the discreteness of the JSON key-value pairs and the periodicity characteristics of the device data as structural entropy features;

[0267] According to the pre-trained lightweight classification model, the structural entropy features are classified to obtain the classification results;

[0268] Perform fuzzy matching between the classification results and the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed field in the message header;

[0269] Creating a field value conversion script between each field in the data format of the original protocol and each field in the preset default data format, and obtaining a data bidirectional conversion script between the data format of the original protocol and the preset default data format;

[0270] A data bidirectional conversion script between the data format of the original protocol and the preset default data format is stored in the multi-protocol adapter.

[0271] In one embodiment, when the processor 1001 classifies the structural entropy features and obtains the classification result, it specifically performs the following operations:

[0272] Quantify the structural entropy characteristics to obtain the discrete value of JSON key-value pairs and the periodicity intensity of device data time series;

[0273] Scale the discreteness value and the periodicity intensity of the device data time series to a standardized range that the model can handle, and obtain the standardized feature vector;

[0274] The normalized feature vector is input into the pre-trained lightweight classification model, and the predicted probability distribution corresponding to each original protocol corresponding to the structural entropy feature is output;

[0275] From the predicted probability distribution, obtain the protocol label corresponding to the highest probability;

[0276] The protocol label corresponding to the highest probability is taken as the classification result.

[0277] In one embodiment, when executing the generation of a pre-trained lightweight classification model, the processor 1001 specifically performs the following operations:

[0278] extracting a protocol conversion log from a multi-protocol adapter log, wherein the protocol conversion log includes a dispersion value, a periodicity intensity, and a protocol type label;

[0279] Construct the initial training set based on the protocol conversion log;

[0280] Obtain the business system labels associated with the protocols of the initial training set;

[0281] Business scenario weighting is performed on the initial training set and business system labels to obtain a business scenario weighted feature vector set;

[0282] The feature vector set weighted for business scenarios is grouped by protocol type, and the mean and standard deviation of each feature group are calculated. Z-score normalization is also performed within the group to obtain the normalized feature vectors of the protocol cluster group.

[0283] Create a lightweight classification model that can output multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. The two nodes in the input layer correspond to discreteness and periodicity intensity, and the output layer includes a softmax probability distribution.

[0284] Input the normalized feature vector of the protocol cluster group into the lightweight classification model for model training and output the model loss value;

[0285] When the model loss value reaches the minimum, a pre-trained lightweight classification model is generated.

[0286] In an embodiment of the present application, on the one hand, a multi-protocol adapter includes scripts for bidirectional data conversion between the data formats of different data protocols and a preset default data format. This multi-protocol adapter acts as an intermediate layer, uniformly handling protocol conversions. When a new system is connected, only the adapter script needs to be configured, without rewriting any code in the system. This significantly reduces development workload, avoids point-to-point docking development work, and meets business scenarios with high real-time requirements. On the other hand, by dynamically identifying protocols using a pre-trained lightweight classification model, the model can adaptively identify new protocols, automatically generate and store new data conversion scripts, and continuously enrich and optimize the functionality of the multi-protocol adapter.

[0287] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program for multi-protocol adaptive service processing can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium for the program for multi-protocol adaptive service processing can be a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0288] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A multi-protocol adaptation service processing method, characterized in that: Applied to the server, the method includes: receiving a business processing request sent by a client that has deployed the first system, the business processing request being used to request a client that has deployed the second system to perform business process collaborative processing, the business processing request carrying business data to be sent; When the data format of the service data to be sent is not a preset default data format, the data format of the service data to be sent is converted into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-device service node to obtain the first service data; the multi-protocol adapter includes a data bidirectional conversion script between data formats of different data protocols and the preset default data format; wherein, The different data protocols are pre-set with feature templates; Converting the data format of the to-be-sent service data into a preset default data format to obtain the first service data includes: Extracting a fixed field from a message header of the service data to be sent; Establishing a pattern fingerprint according to the fixed field of the message header; Performing pattern matching on the pattern fingerprint and the feature templates set for the different data protocols to obtain a matching result; If the matching result indicates a successful match, obtaining a target feature template that successfully matches the pattern fingerprint; Determining a target data protocol corresponding to the target feature template; Obtaining a target data bidirectional conversion script between the data format of the target data protocol and the preset default data format from data bidirectional conversion scripts between data formats of different data protocols and the preset default data format included in the multi-protocol adapter; The target data bidirectional conversion script is used to convert the data format of the service data to be sent into a preset default data format to obtain the first service data; wherein, The method further comprises: If the matching result indicates a matching failure, analyzing the payload nesting structure of the service data to be sent to determine the discreteness of the JSON key-value pairs and the periodicity characteristics of the device data as structural entropy features; Classifying the structural entropy features according to a pre-trained lightweight classification model to obtain a classification result; Performing fuzzy matching on the classification result and the fields of each original protocol in a preset original protocol library to find the original protocol that matches the fixed field of the message header; Creating a field value conversion script between each field in the data format of the original protocol and each field in the preset default data format, and obtaining a data bidirectional conversion script between the data format of the original protocol and the preset default data format; Storing a data bidirectional conversion script between the data format of the original protocol and a preset default data format in the multi-protocol adapter; a second system for identifying a desired flow direction of the service data to be sent; In a case where the data request format of the second system is not a preset default data format, converting the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data; The second business data is pushed to the client where the second system is deployed via the HTTP protocol.

2. The method according to claim 1, characterized in that The method further comprises: receiving a business processing result sent by a client that has deployed the second system; converting the data format of the business processing result into the data request format of the first system according to the multi-protocol adapter to obtain the final business processing result of the business processing request; The final business processing result is sent to the client where the first system is deployed.

3. The method according to claim 1, characterized in that The method further comprises: Monitor the service status of the preset main service node through a preset health detection mechanism; In the event of a node downtime in the service state, traffic is switched to the pre-device service node through the Kubernetes cluster.

4. The method according to claim 1, wherein The step of establishing a pattern fingerprint according to the fixed field in the message header includes: Convert the fixed field of the message header into a hexadecimal string to obtain the original byte code; Encoding the text field in the fixed field of the message header to obtain a semantic hash code; Encoding the field length value of the fixed field in the message header to obtain a structural feature code; Combining the original byte code, the semantic hash code, and the structural feature code to obtain a field feature triple; The field feature triplet is used as an original parameter of a compression algorithm, and the compression algorithm is executed to compress the field feature triplet to generate a pattern fingerprint of a fixed length of 256 bits.

5. The method according to claim 1, wherein The classifying the structural entropy features to obtain a classification result includes: Quantifying the structural entropy characteristics to obtain the discreteness value of the JSON key-value pair and the periodicity intensity of the device data time series; Scaling the discreteness value and the periodicity intensity of the device data time series to a standardized range that can be processed by the model to obtain a standardized feature vector; Inputting the standardized feature vector into a pre-trained lightweight classification model, and outputting a predicted probability distribution corresponding to each original protocol corresponding to the structural entropy feature; Obtaining the protocol label corresponding to the highest probability from the predicted probability distribution; The protocol label corresponding to the highest probability is taken as the classification result.

6. The method according to claim 5, characterized in that Follow these steps to generate a pre-trained lightweight classification model, including: extracting a protocol conversion log from a multi-protocol adapter log, wherein the protocol conversion log includes a dispersion value, a periodicity intensity, and a protocol type label; Convert the logs according to the protocol to construct an initial training set; Obtaining a business system label associated with the protocol of the initial training set; Performing business scenario weighting on the initial training set and the business system label to obtain a business scenario weighted feature vector set; The weighted feature vector set for the business scenario is grouped by protocol type, and the mean and standard deviation of each feature group are calculated, and Z-score normalization is performed within the group to obtain the normalized feature vector of the protocol cluster group; Creating a lightweight classification model capable of outputting a multi-protocol probability distribution, the lightweight classification model comprising an input layer and an output layer, wherein two nodes of the input layer correspond to discreteness and periodicity intensity, and the output layer comprises a softmax probability distribution; Inputting the normalized feature vector of the protocol cluster group into the lightweight classification model for model training, and outputting a model loss value; When the model loss value reaches the minimum, a pre-trained lightweight classification model is generated.

7. A multi-protocol adaptive service processing system implemented using the method according to any one of claims 1 to 6, characterized in that: The system comprises: A receiving module, configured to receive a business processing request sent by a client that has deployed the first system, wherein the business processing request is used to request a client that has deployed the second system to perform business process collaborative processing, and the business processing request carries business data to be sent; A first conversion module is configured to, when the data format of the service data to be sent is not a preset default data format, convert the data format of the service data to be sent into the preset default data format according to a multi-protocol adapter stored in a preset main service node or a pre-device service node, to obtain first service data; the multi-protocol adapter includes a script for bidirectional data conversion between data formats of different data protocols and the preset default data format; an identification module, configured to identify a second system to which the service data to be sent needs to flow; a second conversion module configured to convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data when the data request format of the second system is not a preset default data format; A push module is used to push the second business data to the client where the second system is deployed through the HTTP protocol.

Images