A distributed twin data interaction method, system, and storage medium

Abstract

The application relates to a distributed twin data interaction method, system and storage medium, the method is applied to a distributed twin data interaction system, the system comprises a front end, a twin data middleware and a back end, and the method comprises the following steps: S1, the front end sends a data request to the twin data middleware; S2, the twin data middleware resets an address in the received data request to a standard address and performs address matching, if the matching is successful, the method proceeds to step S3, otherwise, the front end is returned with exception information; S3, the twin data middleware encrypts and forwards the data request to the back end after authentication verification, and the back end returns corresponding data according to the data request; and S4, the twin data middleware returns the returned data to the front end after performing exception judgment and standardization processing. The method solves the problems of complex data format, great connection difficulty, high troubleshooting cost and low interaction security during the twin data interaction between the front end and the back end.

Description

Technical Field

[0001] This invention relates to the field of distributed data interaction, and more particularly to a distributed twin data interaction method, system, and storage medium. Background Technology

[0002] Data visualization / digital twin products utilize graphics, image processing, computer vision, user interfaces, modeling, and the display of 3D, surface, attribute, and animation to visually interpret data, completing a mapping of the real world in virtual space. Compared to traditional reports, they offer innovative and groundbreaking breakthroughs in the richness of data representation (two-dimensional, three-dimensional, combined with spatial geographic information), methods (color, height, size), and enhanced visual effects. They better present "data," mapping the business landscape behind the data and helping target users understand the status of their own business from a data perspective.

[0003] Data visualization / digital twin products, as front-end applications for data display, are the convergence point for numerous data sets. The real-time data they present has several characteristics: diversity (e.g., sensor data, production data, event alarms, etc.), multi-dimensionality (historical, real-time, and future), and diverse business systems (new and old systems, multiple data vendors, and multiple language versions).

[0004] The specific issues are as follows:

[0005] 1. The project faces a variety of data formats provided by various data vendors, which makes integration difficult, communication costs high, and development efficiency low; during the operation and maintenance phase, troubleshooting problems is costly once they occur.

[0006] 2. When faced with API authentication, the identity information stored in the front-end system is easily obtained by others, creating a security risk.

[0007] 3. If the front-end system obtains data directly from the data vendor, data anomalies caused by system problems of the data vendor will directly affect the front-end application, lacking a fault tolerance mechanism.

[0008] 4. The front-end system obtains data directly from the data vendor, and there is a lack of access logs in the data access chain.

[0009] 5. After acquiring the data, it needs to be filtered / cleaned / decrypted / merged. If mature technical tools or solutions are required, it is difficult for the front-end application to integrate these capabilities into the process.

[0010] The purpose of this invention is to design a distributed twin data interaction method, system, and storage medium to address the problems existing in the prior art. Summary of the Invention

[0011] To address the problems existing in the prior art, the present invention provides a distributed twin data interaction method, system, and storage medium, which can effectively solve the problems existing in the prior art.

[0012] This invention provides a distributed twin data interaction method. The method is based on a distributed twin data interaction system, which includes a front-end, a twin data middleware, and a back-end. The method includes the following steps:

[0013] S1 The front end sends a data request to the twin data middleware;

[0014] The twin data middleware described in S2 resets the address in the received data request to the standard address and performs address matching. If the matching is successful, it proceeds to step S3; otherwise, it returns an error message to the front end.

[0015] The twin data middleware described in S3 authenticates and verifies the data request, then encrypts and forwards it to the backend. The backend then returns the corresponding data based on the data request.

[0016] The twin data middleware described in S4 performs anomaly detection and standardization on the returned data before returning it to the front end.

[0017] Specifically, step S2 includes:

[0018] S201 resets the address in the data request of the front end to the port service address of the twin data middleware;

[0019] S202 identifies the corresponding business system address based on the address in the data request and performs business system routing address matching.

[0020] The authentication and verification steps specifically include:

[0021] S301 determines whether identity authentication is required based on the data request. If identity authentication is required, proceed to step 302; otherwise, forward the request directly to the backend.

[0022] S302 checks whether the corresponding identity information is cached. If it is cached, proceed to step S303; otherwise, proceed to step S304.

[0023] S303 retrieves the corresponding identity information and forwards it to the backend;

[0024] S304 forwards the data request to the backend and obtains and stores the corresponding identity information.

[0025] Step S3 further includes:

[0026] If the data request requires calling several backend interfaces, then the several backend interfaces are merged into one interface call chain and then forwarded to the backend.

[0027] After obtaining the data returned by all the backend interfaces through the interface call chain, the data is then returned to the frontend in a unified manner.

[0028] Specifically, step S4 includes:

[0029] S401 performs anomaly detection on the data returned by the backend. If the data is abnormal, proceed to step S402; otherwise, proceed to step S403.

[0030] S402 performs data anomaly classification processing based on data anomalies and feeds the feedback to the data request front-end;

[0031] S403 decrypts the data returned by the backend and then forwards it to the data requesting frontend.

[0032] Step S4 further includes:

[0033] Determine whether the data returned by the backend needs to be archived. If yes, archive and store it; otherwise, return it directly to the frontend.

[0034] Step S4 further includes:

[0035] The data returned by the backend is decoded, decrypted, and then standardized before being returned to the frontend.

[0036] Another aspect of the present invention provides a distributed twin data interaction system, comprising: a front-end, a twin data middleware, and a back-end; the twin data middleware includes:

[0037] The address routing and distribution module is used to reset the received data requests from the front end to standard addresses and perform address matching;

[0038] The identity and permission verification module is used to authenticate and verify data requests.

[0039] The data encryption processing module is used to encrypt and forward data requests to the backend.

[0040] The data standard processing module is used to perform standard processing on the data after anomaly detection and decryption before returning it to the front end.

[0041] The distributed twin data interaction system further includes the twin data middleware as follows:

[0042] The data caching module is used to store the corresponding identity information;

[0043] An exception information processing module is used to perform exception judgment on the data requests from the front end and the corresponding data returned by the back end;

[0044] The data log storage module is used to determine whether the data returned by the backend needs to be archived and stored.

[0045] The content information decryption module is used to decrypt the data returned by the backend.

[0046] Another aspect of the present invention provides a distributed twin data interaction storage medium, comprising: a computer program stored on the storage medium, wherein when the computer program is executed by a processor, a distributed twin data interaction method as described above is executed.

[0047] Therefore, the present invention provides the following effects and / or advantages:

[0048] First, by setting up a twin data middleware, various data provided by different data vendors in the backend can be managed through a unified interface. This allows for standardized processing of the data returned from the backend, reducing the difficulty of integration and communication costs, as well as reducing the dependence of different modules and the fan-in and fan-out between software modules.

[0049] Secondly, by using a twin data middleware to perform unified authentication and verification of front-end data and store identity information, it avoids security issues such as identity information leakage caused by direct authentication at the front end. Simultaneously, it can encrypt data forwarded to the backend, ensuring the security of data transmission.

[0050] Third, a twin data middleware is used to uniformly decrypt and transcode the data returned by the backend, preventing the frontend from leaking the decryption algorithm after the backend directly sends the data. Anomaly detection for backend-returned data has also been added, enhancing fault tolerance mechanisms.

[0051] Fourth, data access and archiving through the twin data middleware provides strong evidence for data security and greatly simplifies operation and maintenance troubleshooting. Code can be uniformly managed and hosted, significantly reducing development and debugging costs. Self-developed or third-party plugins can be quickly integrated into the twin data middleware for functional expansion. Applications can be quickly replicated in similar projects, improving development efficiency by 50% and reducing product operation and maintenance costs by 30%.

[0052] It should be understood that the above summary and the following detailed description of the invention are exemplary and explanatory, and are intended to provide further explanation of the invention as claimed. Attached Figure Description

[0053] Figure 1 This is a flowchart of the method steps of the present invention.

[0054] Figure 2 This is a schematic diagram of the overall method flow of the present invention.

[0055] Figure 3 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0056] To facilitate understanding by those skilled in the art, the structure of the present invention will now be described in further detail with reference to the accompanying drawings. It should be understood that, unless otherwise specified, the order of the steps mentioned in this embodiment can be adjusted according to actual needs, and they can even be executed simultaneously or partially simultaneously.

[0057] Please refer to Figure 1 and Figure 2 This invention provides a distributed twin data interaction method. The method is based on a distributed twin data interaction system, which includes a front-end, twin data middleware, and a back-end. The method includes the following steps:

[0058] S1 The front end sends a data request to the twin data middleware;

[0059] In this step, all data requests sent from the front end are uniformly sent to the twin data middleware for unified processing. Simultaneously, the data interface services (backend data) from various data vendors are uniformly managed and configured within the twin data middleware. This can be achieved through the following code:

[0060]

[0061]

[0062] It should be noted that in this step, the front-end refers to the user making operation requests on a webpage through a browser or other means, and communicating with the twin data middleware through the H5Gateway service gateway. The specific physical carrier can be a mobile phone, computer, etc., and there are no restrictions here. The twin data middleware performs protocol parsing and conversion of the front-end data requests through HTTP and WebSocket services, and can also call its internal multimedia decoding service to transcode and parse the data requests from the front-end.

[0063] The twin data middleware described in S2 resets the address in the received data request to the standard address and performs address matching. If the matching is successful, it proceeds to step S3; otherwise, it returns an error message to the front end.

[0064] Step S2 specifically includes:

[0065] S201 resets the address in the data request of the front end to the port service address of the twin data middleware;

[0066] In this step, the reset address needs to retain not only the port service address of the twin data middleware but also the corresponding business system address so that the twin data middleware can perform address matching based on the business system address. Simultaneously, resetting the address facilitates the standardization of frontend data requests into requests to the twin data middleware, promoting standardized data storage and simplifying logging and troubleshooting. The reset address structure is defined as: http: / / twin data middleware address:port / business system identifier / business module identifier. This can be implemented using the following code:

[0067]

[0068]

[0069]

[0070] Examples of resetting some data request addresses are shown in Table 1.

[0071]

[0072]

[0073] Table 1

[0074] S202 identifies the corresponding business system address based on the address in the data request and performs business system routing address matching.

[0075] In this step, when the twin data middleware receives a request from the front-end application, it identifies the requested business system from the request address parameters and performs business system routing address matching. If the routing address matches successfully, it proceeds to the corresponding business system module; otherwise, it returns exception handling information. Uniform routing and distribution are handled by the twin data middleware, reducing end-to-end communication and improving communication efficiency. This can be implemented using the following code:

[0076]

[0077]

[0078]

[0079]

[0080] The twin data middleware described in S3 authenticates and verifies the data request, then encrypts and forwards it to the backend. The backend then returns the corresponding data based on the data request.

[0081] The authentication and verification steps specifically include:

[0082] S301 determines whether identity authentication is required based on the data request. If identity authentication is required, proceed to step 302; otherwise, forward the request directly to the backend.

[0083] S302 checks whether the corresponding identity information is cached. If it is cached, proceed to step S303; otherwise, proceed to step S304.

[0084] S303 retrieves the corresponding identity information and forwards it to the backend;

[0085] S304 forwards the data request to the backend and obtains and stores the corresponding identity information.

[0086] In this step, after entering the corresponding business system module, it identifies whether the backend interface corresponding to the current request requires authentication. If authentication is required, it checks if the identity information is cached in the local cache of the twin data middleware; if so, it retrieves it from the agreed-upon location (e.g., Request Header) and sends it to the backend service interface. If not, it retrieves the identity information from the backend again, caches it in the local cache of the twin data middleware, and sends the request to the backend service interface. If authentication is not required, it sends the request directly to the backend. Authentication and identity information storage are uniformly handled by the twin data middleware, avoiding direct authentication on the frontend. Due to the insecurity of frontend data, this prevents unauthorized access to identity information. This can be implemented using the following code:

[0087]

[0088]

[0089]

[0090] Step S3 further includes:

[0091] If the data request requires calling several backend interfaces, then the several backend interfaces are merged into one interface call chain and then forwarded to the backend.

[0092] After obtaining the data returned by all the backend interfaces through the interface call chain, the data is then returned to the frontend in a unified manner.

[0093] In this step, if the result required by the current frontend request comes from the merging of data from multiple backend interfaces, the corresponding backend interfaces are merged into a single backend interface call chain. This application utilizes JavaScript's Promise capability, ensuring that all backend interfaces are processed and return the corresponding data before providing a response to the frontend application. This allows the frontend to obtain all the necessary data at once, eliminating the need for synchronous data return for each port request. Asynchronous data interaction across multiple ports is achieved through a twin data middleware. This can be implemented using the following code:

[0094]

[0095]

[0096]

[0097] It should be noted that the backend in this application consists of multiple servers, including basic server functions (which are not limited here), such as task scheduling, service registration, data access, and system log services. The servers in this application communicate with the twin data middleware through the RabbitMQ message middleware, and the data storage can be either a relational database or a non-relational database.

[0098] The twin data middleware described in S4 performs anomaly detection and standardization on the returned data before returning it to the front end.

[0099] Step S4 specifically includes:

[0100] S401 performs anomaly detection on the data returned by the backend. If the data is abnormal, proceed to step S402; otherwise, proceed to step S403.

[0101] S402 performs data anomaly classification processing based on data anomalies and feeds the feedback to the data request front-end;

[0102] S403 decrypts the data returned by the backend and then forwards it to the data requesting frontend.

[0103] In this step, when the backend returns data, the twin data middleware checks whether the returned backend port address matches the address required by the frontend. If an anomaly is found, it captures the exception and displays it to the frontend for timely troubleshooting. If no anomaly is found, the data returned by the backend is decrypted and returned to the frontend. To ensure data transmission security, the data returned by the backend is encrypted; therefore, the twin data middleware is used directly to decrypt and return it to the frontend, avoiding information leakage security issues caused by frontend decryption.

[0104] In this step, the data returned from the backend can be further processed before being returned to the frontend application. For example, consider the conversion of shipping port geographic coordinate data (WGS84 spatial data to GCJ02). Specifically, to ensure the security and confidentiality of shipping port geographic coordinate data, backend data storage and transmission typically involve encrypting and converting geographic information. The frontend needs to perform this data conversion to obtain the specific shipping port geographic coordinate data. Therefore, setting up a data conversion function on the twin data middleware can improve the security of data transmitted from the backend to the twin data middleware, while also increasing data interaction efficiency. This eliminates the need for each backend port to decrypt and resend data manually; the twin data middleware handles all the processing. This can be implemented using the following code:

[0105]

[0106]

[0107] The transformation of geographic coordinate data for some shipping ports is shown in Table 2.

[0108]

[0109]

[0110] Step S4 further includes:

[0111] Determine whether the data returned by the backend needs to be archived. If yes, archive and store it; otherwise, return it directly to the frontend.

[0112] In this step, if the front-end webpage logging switch is enabled, the front-end request data and back-end response data for that entry will be archived and retained. The twin data middleware, based on logging requirements, preserves the complete front-end data request process and back-end response process. In case of a failure, the entire data interaction process can be viewed at any time through the logs, facilitating troubleshooting.

[0113] Step S4 further includes:

[0114] The data returned by the backend is standardized and then returned to the frontend.

[0115] In this step, the data returned from the backend is uniformly filtered and cleaned to remove interfering information. The twin data middleware is then standardized before being returned to the frontend.

[0116] Step S4 further includes:

[0117] After standardizing the data, specific data can be returned to the backend, such as unencrypted data, unencrypted cached data, and decrypted symmetric encrypted data, which can be mirrored, stored, and updated. Each twin data interaction can be stored and updated, making it convenient for the frontend to send the same data request. The twin data middleware only needs to determine the business system requesting the request to send the corresponding content, without having to forward it to the corresponding backend again. This allows for a rapid response to frontend data requests, improving the efficiency of the twin middleware and reducing the number of backend communications.

[0118] Please refer to Figure 3 Another aspect of the present invention provides a distributed twin data interaction system, comprising: a front-end, a twin data middleware, and a back-end; the twin data middleware includes:

[0119] The address routing and distribution module is used to reset the received data requests from the front end to standard addresses and perform address matching;

[0120] The identity and permission verification module is used to authenticate and verify data requests.

[0121] The data encryption processing module is used to encrypt and forward data requests to the backend.

[0122] The data standard processing module is used to perform standard processing on the data after anomaly detection and decryption before returning it to the front end.

[0123] The distributed twin data interaction system further includes the twin data middleware as follows:

[0124] The data caching module is used to store the corresponding identity information;

[0125] An exception information processing module is used to perform exception judgment on the data requests from the front end and the corresponding data returned by the back end;

[0126] The data log storage module is used to determine whether the data returned by the backend needs to be archived and stored.

[0127] The content information decryption module is used to decrypt the data returned by the backend.

[0128] Another aspect of the present invention provides a distributed twin data interaction storage medium, comprising: a computer program stored on the storage medium, wherein when the computer program is executed by a processor, the distributed twin data interaction method is executed.

[0129] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0130] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0131] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0132] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0133] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0134] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0135] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0136] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0137] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms should not be construed as necessarily referring to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

Claims

1. A distributed twin data interaction method, characterized in that, The method is based on a distributed twin data interaction system, which includes a front-end, twin data middleware, and a back-end. The method includes the following steps: S1 The front end sends a data request to the twin data middleware; The twin data middleware described in S2 resets the address in the received data request to the standard address and performs address matching. If the matching is successful, it proceeds to step S3; otherwise, it returns an error message to the front end. The twin data middleware described in S3 authenticates and verifies the data request, then encrypts and forwards it to the backend. The backend then returns the corresponding data based on the data request. The twin data middleware in step S4 performs anomaly detection and standardization on the returned data before returning it to the front end; step S2 includes: S201 resets the address in the data request of the front end to the port service address of the twin data middleware; S202 identifies the corresponding business system address based on the address in the data request and performs business system routing address matching; Step S4 specifically includes: S401 performs anomaly detection on the data returned by the backend. If the data is abnormal, proceed to step S402; otherwise, proceed to step S403. S402 performs data anomaly classification processing based on data anomalies and feeds back to the front end of the data request; S403 decrypts the data returned by the backend and then forwards it to the frontend that requested the data.

2. The distributed twin data interaction method as described in claim 1, characterized in that, The authentication and verification steps specifically include: S301 determines whether identity authentication is required based on the data request. If identity authentication is required, proceed to step 302; otherwise, forward the request directly to the backend. S302 checks whether the corresponding identity information is cached. If it is cached, proceed to step S303; otherwise, proceed to step S304. S303 retrieves the corresponding identity information and forwards it to the backend; S304 forwards the data request to the backend and obtains and stores the corresponding identity information.

3. The distributed twin data interaction method as described in claim 1, characterized in that, Step S3 further includes: If the data request requires calling several backend interfaces, then the several backend interfaces are merged into one interface call chain and then forwarded to the backend. After obtaining the data returned by all the backend interfaces through the interface call chain, the data is then returned to the frontend in a unified manner.

4. The distributed twin data interaction method as described in claim 1, characterized in that, Step S4 includes: Determine whether the data returned by the backend needs to be archived. If yes, archive and store it; otherwise, return it directly to the frontend.

5. A distributed twin data interaction method as described in claim 1, characterized in that, Step S4 further includes: The data returned by the backend is standardized and then returned to the frontend.

6. A distributed twin data interaction system, characterized in that, A distributed twin data interaction method as described in any one of claims 1-5 can be implemented, comprising: a front-end, a twin data middleware, and a back-end; the twin data middleware includes: The address routing and distribution module is used to reset the received front-end data request to a standard address and perform address matching; specifically, it is used to reset the address in the front-end data request to the port service address of the twin data middleware; and to identify the corresponding business system address based on the address in the data request and perform business system routing address matching. The identity and permission verification module is used to authenticate and verify data requests. The data encryption processing module is used to encrypt and forward data requests to the backend. The data standard processing module is used to perform standard processing on the data after anomaly detection and decryption before returning it to the front end; the twin data middleware includes: The data caching module is used to store the corresponding identity information; An exception information processing module is used to make exception judgments on the data requests from the front end and the corresponding data returned by the back end. Making exception judgments on the data returned by the back end includes: if the data is abnormal, performing data exception classification processing according to the data exception and feeding it back to the front end that made the data request; otherwise, decrypting the data returned by the back end and then forwarding it to the front end that made the data request. The data log storage module is used to determine whether the data returned by the backend needs to be archived and stored. The content information decryption module is used to decrypt the data returned by the backend.

7. A distributed twin data interaction storage medium, characterized in that, include: The storage medium stores a computer program, which, when executed by a processor, performs a distributed twin data interaction method as described in any one of claims 1-5.

Images