Unified container-based heterogeneous system communication interaction processing method and system

Abstract

The application discloses a kind of based on uniform container's heterogeneous system communication interaction processing method and system, it is related to computer network communication and software architecture technical field.The method takes uniform data processing container as whole link only data carrier, container includes message header field, service data body, security context and routing metadata;Container is created when in-bound flow starts, continuously loads and updates data in each processing link, until the end of out-bound flow or service layer is consumed and destroys;When inbound, external request is routed to service layer after being converted into internal standard format by protocol analysis, decryption, format conversion;When outbound, internal standard message is sent to target external system after format conversion, encryption, and response is returned to service layer after reverse analysis.The application is through uniform data container throughout whole link, eliminates the invasion of heterogeneous system difference to business logic, reduces the coupling degree and maintenance cost of communication integration between systems.

Description

Technical Field

[0001] This invention relates to the field of computer network communication and software architecture technology, specifically to a method and system for heterogeneous system communication and interaction processing based on a unified container. Background Technology

[0002] As enterprises deepen their digital transformation, the need for business collaboration between internal core systems and external heterogeneous systems is growing. Current system integration practices typically involve developing independent adaptation modules for each third-party channel or using an enterprise service bus for unified routing. However, these methods still have many technical shortcomings when facing large-scale multi-system integration scenarios.

[0003] Chinese patent application CN121585356A discloses an end-to-end quantum key data security protection system and method for power grid operations. It generates and manages quantum keys through a quantum key distribution and key management module. At a controlled injection station, the quantum key and metadata are signed and encrypted to generate an offline injection package, which is then loaded into a terminal device via a secure medium. Field-level data encryption and decryption operations are performed on the terminal or gateway according to an encryption rule base. A transparent gateway is also set up for protocol adaptation and access control. This solution focuses on solving the problems of offline distribution, secure injection, and terminal encryption / decryption of quantum keys in power grid scenarios. Its core lies in leveraging the high entropy characteristics of quantum keys to enhance key security and achieving traceable management of the key's entire lifecycle through hardware binding and an audit chain.

[0004] However, existing solutions primarily focus on key security protection, neglecting the core integration issues of communication protocol adaptation and message format conversion between heterogeneous systems. In power grid business scenarios, communication interactions are typically based on relatively standardized power regulations, with limited heterogeneity between systems. However, in enterprise-level multi-system integration scenarios, different third-party systems employ varying communication protocols, message formats, and data exchange standards. Existing solutions require writing dedicated parsing, conversion, and assembly code within the business system for each type of difference, resulting in a high degree of coupling between adaptation logic and business logic. Once a third-party interface changes, the modifications are scattered across multiple business modules, drastically increasing maintenance costs.

[0005] Furthermore, existing communication processing workflows typically modularize functions such as protocol adaptation, message format conversion, encryption / decryption verification, and business routing, but these modules are deployed independently, lacking a unified data carrier and process standard. The same message undergoes multiple serialization and deserialization operations during its flow, increasing processing latency and reducing code reusability due to inconsistent data formats at each stage. Simultaneously, processing workflows for different channels are often implemented independently by different development teams, easily leading to inconsistent results for the same type of operation across different channels due to differences in implementation details, potentially causing data loss or decryption failure in extreme cases. Moreover, the lack of a unified end-to-end tracking identifier makes it difficult to monitor the message flow status in complex links. Once an anomaly occurs, problem localization often requires troubleshooting across multiple systems segment by segment, resulting in extremely low debugging efficiency.

[0006] In summary, existing technologies urgently need a standardized and unified technical solution that can encapsulate protocol adaptation, format conversion, encryption / decryption mechanisms, and routing strategies to shield underlying heterogeneous differences and achieve zero intrusion of the communication interaction layer into the business layer. Summary of the Invention

[0007] To overcome the technical problems of high coupling of adaptation code, scattered processing logic, and difficulty in ensuring process consistency in the existing heterogeneous system interface, the present invention provides a heterogeneous system communication and interaction processing method and system based on a unified container.

[0008] This invention provides a heterogeneous system communication and interaction processing method based on a unified container. The method uses a unified data processing container as the unique data carrier throughout the entire link. The container includes at least a message header field, a business data body, a security context, and routing metadata. The message header field carries a unified transaction identifier and routing addressing information throughout the entire link. The business data body carries standardized and transformed business data using a unified data structure. The security context uniformly manages encryption and decryption strategies and states. The routing metadata drives dynamic mapping queries and message queue routing decisions. The container is created when the inbound process starts and continuously loads and updates data in each processing stage, including message format conversion, security encryption and decryption, dynamic routing, and protocol adaptation, until the outbound process ends or the data is destroyed after consumption by the business layer. All processing modules uniformly perform read and write operations around the container.

[0009] The method includes an inbound interaction processing flow and an outbound interaction processing flow: (a) Inbound Interaction Processing Flow An external heterogeneous system initiates an interface call request carrying the original request message. The access application determines the source protocol type based on the protocol of the upstream requesting system and the target protocol type based on the downstream target system. It performs multi-dimensional protocol identification based on port characteristics, message header and payload structure. Then, it creates the unified data processing container instance, assigns a globally unique tracking identifier, and initializes the message header field and the routing metadata. The original request message is loaded into the container's original data buffer. The globally unique tracking identifier is used throughout the entire lifecycle of inbound, routing, business processing and outbound processes.

[0010] The original request message loaded in the container's original data buffer is parsed according to the protocol. The message is unpacked and the fields are split according to the agreed communication protocol. The request header, business parameters, extended fields and link tracing information are extracted. All the parsed data is stored in the business data body. The context in the business data body runs through the entire call lifecycle and can be shared and read by subsequent processing stages.

[0011] Based on the target system security configuration recorded in the routing metadata, the corresponding decryption policy is invoked to perform security decryption processing on the data in the business data body. The encryption algorithm identifier, key alias and digital signature context contained in the current link security configuration are read, and decryption, signature verification and de-identification operations are performed. The decrypted data is then filled back into the business data body and the security processing log is stored in the log field of the container.

[0012] The intermediate data in the business data body is converted into internal standard format data, which is JSON format. After the conversion is completed, the internal standard format data is backfilled into the container, so that the container can carry fully standardized internal unified messages.

[0013] The dynamic mapping table is queried based on the transaction code and product code in the routing metadata to resolve the target system address, interface address, communication protocol, timeout policy, and retry policy. The dynamic mapping table includes at least a transaction code mapping table and a product code mapping table. The transaction code mapping table is used to configure the mapping relationship between external transaction codes, internal transaction codes, and service paths. The product code mapping table is used to configure the mapping relationship between product codes and message sender names. The mapping table is stored in the form of a configuration file and supports dynamic loading. When the mapping relationship changes in real time, the next request thread uses the latest data after the current thread finishes processing, writes the queried routing result into the routing metadata of the container, and sends the loaded container to the internal business layer for processing through a message queue.

[0014] The system retrieves the response data returned by the internal business layer and loads it into the container. It performs security encryption processing according to the encryption policy configured according to the source channel, restores the internal standard format data in the business data body to the original third-party format, and completes protocol encapsulation according to the source protocol type. It extracts the restored response message from the container and sends it back to the external heterogeneous system through the original link. It destroys the container and archives the full-link log.

[0015] The secure decryption and secure encryption processes follow the principle of one-time encryption and decryption. In a complete interaction process, the container performs a decryption operation only once at the inbound boundary and an encryption operation only once at the outbound boundary. The business data body remains in plaintext during internal insecure processing.

[0016] (II) Outbound Interaction Processing Flow The application receives an internal standard message initiated by the internal business layer, creates a unified data processing container instance, and stores the internal standard message in the business data body. The context in the business data body is shared and read throughout the entire call lifecycle.

[0017] Based on the target protocol type recorded in the routing metadata, the internal standard messages in the business data body are converted into the protocol and message formats required by the target external system. The protocol formats include HTTP / HTTPS, WebSocket, and custom TCP protocols, and the message formats include XML, JSON, and fixed-length or delimited messages. The conversion results are temporarily stored in the business data body.

[0018] Based on the target system security configuration recorded in the routing metadata, the corresponding encryption policy is invoked to perform security encryption processing on the data in the business data body. The encryption algorithm identifier, key alias and digital signature context contained in the current link security configuration are read, and request data encryption, sensitive field desensitization and message signing operations are performed. The encrypted data is then filled back into the business data body and the security processing log is stored in the log field of the container.

[0019] The encrypted final message is extracted from the business data body and sent to the target external system. The original response message, exception status code and error information returned by the target external system are received and stored in the container. The response message is subjected to reverse security parsing and format conversion, including decryption, format back translation and unified exception encapsulation. The restored standardized response data is updated to the business data body.

[0020] The standardized response data within the container is sent back to the internal business layer, the container is destroyed, and the end-to-end logs are archived.

[0021] The method also includes a processing flow for interacting with the Enterprise Service Bus (ESB): receiving a request message sent by the channel end via the ESB, creating a container instance and storing the original ESB message in the business data body, extracting the service number from the message header field of the container, extracting the version number field from the business data body, combining the service number and the version number to determine a unique interface identifier for accessing the business gateway and storing it in the routing metadata, querying the data mapping table based on the interface identifier to determine a standard interface common process or a special interface common process, writing the process identifier into the container, and having the format conversion engine convert the ESB format message in the business data body into the unified access format of the target business system based on the process identifier, concatenating the backend URL and sending it to the business gateway. During the conversion process, the container always maintains bidirectional traceability between the original message and the converted message. After receiving the response from the business gateway, the response data is stored in the container, reverse-converted into an ESB format message, and returned to the channel end via the ESB.

[0022] The method also includes a file interaction processing flow: creating or reusing the container in a common sub-flow, assembling the request parameters required for file upload or download in the business data body of the container, the request parameters including the local file path, Minio storage path and target FTP / SFTP parameters, calling the token acquisition service to store the acquired upload or download token in the security context, the file transfer engine performing file upload to Minio or download from Minio to local operation according to the request parameters loaded in the container and the token, and the operation result being written back to the business data body and transferred to the next processing stage along with the container. The file interaction supports batch transfer of multiple files.

[0023] The present invention also provides a heterogeneous system communication and interaction processing system based on a unified container, the system comprising: The container management module is used to create, maintain, and destroy unified data processing container instances. Each container contains at least a message header field, a business data body, a security context, and routing metadata. The message header field carries a unified transaction identifier and routing addressing information across the entire link. The business data body carries standardized business data using a unified data structure. The security context uniformly manages encryption and decryption policies and states. The routing metadata drives dynamic mapping queries and message queue routing decisions. The container management module configures a state machine for each container. The state machine dynamically adapts to the state transition path according to the processing direction. The states include at least the created state, loading state, transformation state, encryption or decryption state, routing state, completed state, and destroyed state. Each processing module determines the allowed operation types based on the current state of the container.

[0024] The access processing module receives raw request messages initiated by external heterogeneous systems. Based on port characteristics, message headers, and payload structures, it performs multi-dimensional protocol identification to determine the source and target protocol types. Through the container management module, it creates a container instance, assigns a globally unique tracking identifier, initializes the message header fields and routing metadata, loads the raw request message into the container's raw data buffer, performs protocol parsing, message unpacking, and field splitting on the raw request message to extract the request header, business parameters, and extended fields, and stores them in the business data body. After calling the security processing module to perform security decryption, it sends the standardized and converted data to the internal business layer via a message queue. After obtaining the response data returned by the internal business layer, it calls the security processing module to perform security encryption and the format conversion module to perform message format restoration. Finally, it transmits the restored response message back to the external heterogeneous system through the original link.

[0025] The outgoing processing module is used to receive internal standard messages initiated by the internal business layer, create a container instance through the container management module and store the internal standard messages in the business data body, call the format conversion module to convert the internal standard messages into the protocol and message formats required by the target external system, call the security processing module to perform security encryption, extract the encrypted final message from the business data body and send it to the target external system, receive the response message returned by the target external system, call the security processing module to perform reverse security parsing and call the format conversion module to perform format back translation, update the restored standardized response data to the business data body and send it back to the internal business layer.

[0026] The routing decision module maintains a dynamic mapping table, which includes at least a transaction code mapping table and a product code mapping table. The transaction code mapping table configures the mapping relationship between external transaction codes, internal transaction codes, and service paths. The product code mapping table configures the mapping relationship between product codes and message sender names. The mapping tables are stored in the form of configuration files and support dynamic loading. When the mapping relationship changes in real time, the next request thread uses the latest data after the current thread finishes processing. The routing decision module queries the dynamic mapping table based on the transaction codes and product codes recorded in the container to parse the target system address, interface address, communication protocol, timeout policy, and retry policy, and writes the routing results into the routing metadata of the container.

[0027] The security processing module is used to read the encryption algorithm identifier, key alias, and digital signature context contained in the current link security configuration based on the target system security configuration recorded in the container, call the corresponding encryption or decryption strategy to encrypt or decrypt the data in the business data body, perform decryption, signature verification, desensitization or request data encryption, sensitive field desensitization, and message signing operations, fill the processing results back into the business data body, and store the security processing log in the log field of the container; the security processing module performs decryption operation in the inbound direction and encryption operation in the outbound direction, and performs decryption or encryption only once for the same data in a complete interaction process.

[0028] The format conversion module is used to convert intermediate data in the business data body into internal standard format data or protocol and message formats required by the target system. The internal standard format is JSON format, the protocol formats include HTTP / HTTPS, WebSocket and custom TCP protocols, and the message formats include XML, JSON and fixed-length or delimited messages. The conversion results are temporarily stored in the business data body.

[0029] The ESB interaction module receives request messages sent by the channel end via ESB, creates a container instance through the container management module, stores the original ESB message in the business data body, extracts the service number from the message header field of the container and the version number from the business data body, combines the service number and the version number to determine a unique interface identifier for accessing the business gateway and stores it in the routing metadata, queries the data mapping table based on the interface identifier to determine the common process of the standard interface or the common process of the special interface, writes the process identifier into the container, controls the format conversion module to convert the ESB format message into the unified access format of the target business system according to the process identifier, concatenates the backend URL and sends it to the business gateway, receives the response from the business gateway, stores the response data in the container and controls the format conversion module to reverse convert it into an ESB format message, and returns it to the channel end via ESB.

[0030] The file interaction module is used to create or reuse containers through the container management module in common sub-processes. It assembles the request parameters required for file upload or download in the business data body of the container. The request parameters include the local file path, Minio storage path, and target FTP / SFTP parameters. It calls the token acquisition service to store the acquired upload or download token in the security context. It controls the file transfer engine to perform file upload to Minio or download from Minio to local machine according to the request parameters loaded in the container and the token. The operation result is written back to the business data body and flows with the container to the next processing stage. The file interaction supports batch transfer of multiple files.

[0031] Compared with the prior art, the present invention has the following advantages: 1. Unified data processing container Existing technologies employ distributed, independent components, with data exchanged between modules through predefined interfaces, lacking a unified data carrier throughout the entire process. In this approach, keys undergo multiple serialization and deserialization processes during inter-module transfers, resulting in inconsistent data formats and low code reusability. This invention addresses this by using a unified data processing container. This container integrates message headers, business data bodies, security contexts, and routing metadata into a single object. Created upon inbound process startup, this container continuously loads and updates data during protocol adaptation, format conversion, encryption / decryption, and routing stages, until the outbound process ends or the data is consumed by the business layer and destroyed. Instead of directly manipulating the original messages, processing modules operate uniformly around this container, eliminating the intrusion of heterogeneous system differences into business logic at the architectural level.

[0032] 2. Two-way standardized interaction process Existing technologies primarily focus on encryption and decryption applications after the key is distributed unidirectionally from the central terminal to the terminal. This invention defines inbound as a conversion process of "external message → container loading → internal standard format," and outbound as a reverse restoration process of "container data → target protocol format → external message," forming a bidirectional closed-loop standard processing paradigm. During inbound, the external private protocol is parsed and converted into the internal JSON standard format, then asynchronously and decoupledly sent to the business layer via a message queue. During outbound, the internal standard message is formatted and securely encrypted before being restored to the original third-party format. All steps operate around the same container instance, reducing process complexity.

[0033] 3. Container state machine driven process control In existing technologies, each module executes its own function independently, and there is a lack of a unified state management mechanism between the key injection, loading, encryption, and re-encryption stages. The same data may be processed repeatedly by different modules during the flow, posing a risk of state inconsistency. This invention configures a complete state machine for the container, dynamically adapting the state transition path according to the processing direction (inbound / outbound). The state includes at least the following states: created, loading, transforming, decrypting / encrypting, routing, completed, and destroyed. Each processing module determines the allowed operation type based on the container's current state, ensuring that each step is executed serially and orderly, avoiding data inconsistency problems caused by concurrent access or abnormal processes.

[0034] 4. Dynamic mapping table configuration routing In existing technologies, routing strategies and protocol mappings need to be pre-configured within each module. Adding new services or changing interfaces requires modifications to multiple configurations and even code. This invention establishes transaction code mapping tables and product code mapping tables, both stored in configuration files and supporting dynamic loading. When the mapping relationship changes in real time, the next request thread uses the latest data after the current thread finishes processing. The system extracts transaction codes and product codes from the container's routing metadata, queries the mapping tables, obtains the corresponding service path, message sender name, or external transaction code, and drives subsequent routing decisions. Adding third-party channels or internal services only requires configuring the mapping relationship without modifying the container's data structure and processing flow.

[0035] 5. Unified security context Existing technologies employ independent encryption / decryption modules on the terminal, with key management, encryption, and authentication functions distributed across different modules. Encryption operations may be executed multiple times on different nodes. This invention encapsulates encryption / decryption operations within the security context of a container, strictly adhering to the "one-time encryption / decryption" principle. Decryption is performed only once at the container boundary upon inbound traffic, and encryption is performed only once at the container boundary upon outbound traffic. The container's business data remains in plaintext during internal insecure processing. This design fundamentally avoids the risk of business logic directly processing sensitive encrypted data, while also reducing performance overhead caused by repeated encryption / decryption.

[0036] 6. End-to-end traceability of global tracking identifiers Existing technologies lack a unified business tracking identifier that runs throughout the entire process. When business anomalies occur, it is necessary to investigate each segment across multiple audit logs, resulting in low efficiency in problem localization. The container of this invention is assigned a globally unique tracking identifier upon creation. This identifier runs through the entire lifecycle of inbound, routing, business processing, and outbound processes. The tracking identifier is always carried in the message header field as the container flows through each stage, making the complete chain of each transaction recordable, traceable, and auditable. When an anomaly occurs, the faulty link can be quickly located through the container logs.

[0037] 7. Unified Container Extension for File Interaction Existing technologies focus on the encrypted encapsulation of structured data. This invention designs file interaction as an extension capability of the container. In file interaction scenarios, the container additionally loads file metadata (including file path, bucket identifier, file list, and transmission protocol parameters) into the business data body. File transmission and message interaction share the same set of tracking identifiers and routing decision mechanisms, expanding the service scope of the communication interaction platform while maintaining management consistency.

[0038] The aforementioned technical features are not independent additions, but rather form an organically collaborative overall technical solution based on a unified data processing container. As the sole data carrier across the entire chain, the container standardizes protocol adaptation, format conversion, security encryption / decryption, routing decisions, and file interaction all around the same container object. Each processing module achieves orderly collaboration through the container's state machine, avoiding the logical fragmentation caused by inconsistent data formats and states between modules in traditional solutions. Simultaneously, the global tracking identifier's pervasive mechanism is deeply integrated with the container's lifecycle management, making end-to-end traceability an inherent attribute of the container rather than an additional feature. The configurable routing of the dynamic mapping table seamlessly integrates with the container's routing metadata, allowing new channels to be added without modifying the container's processing flow. These interdependent and synergistic technical features collectively achieve zero intrusion from the communication layer to the business layer, significantly improving the system's scalability, maintainability, and traceability. Attached Figure Description

[0039] Figure 1 This is an overview diagram of the overall architecture and four interactive processes of the method of this invention; Figure 2 This is a schematic diagram of the inbound interaction processing flow of the present invention; Figure 3 This is a schematic diagram of the outbound interaction processing flow of the present invention; Figure 4 This is a schematic diagram of the interaction process between the present invention and the ESB (Enterprise Service Bus). Figure 5 This is a schematic diagram of the document interaction processing flow of this invention; Figure 6 This is a diagram of the modular architecture of the system of the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0041] Definitions: The inbound interaction processing flow refers to the complete processing process executed by the communication platform from the receipt of the request to the return of the response when an external heterogeneous system initiates a communication interaction with the internal core system. This process starts with the request entering the internal system from the outside and ends with the response returning from the internal system to the outside.

[0042] Outbound interaction processing flow refers to the complete processing procedure executed by the communication platform from request receipt to response return when an internal core system initiates communication interaction with an external heterogeneous system. This process begins with the request being sent from inside to outside and ends with the response returning from outside to inside. Inbound and outbound interaction processing flows are two independent processing directions, and there is no sequential execution relationship between them. In actual operation, they can be executed one at a time or concurrently depending on the business initiator.

[0043] The unified data processing container refers to the logical object constructed in this invention, which serves as the sole data carrier across the entire data chain. It encapsulates message header fields, business data bodies, security context, and routing metadata. It is created when the inbound or outbound interaction processing flow begins and continuously loads and updates data during each processing stage, including protocol parsing, protocol adaptation, message format conversion, security encryption / decryption, and dynamic routing, until the interaction flow ends or the data is destroyed after consumption by the business layer. Each processing module does not directly manipulate the original message but instead performs read and write operations uniformly around the container.

[0044] The globally unique identifier generation service refers to the functional service unit deployed in this invention for generating globally unique and non-repeating identifiers. This service unit generates identifiers that are not repeated globally based on a preset identifier generation algorithm, which are used to uniquely identify each transaction processed by the communication platform. The term "globally unique tracking identifier" refers to a tracking number generated and assigned globally by the globally unique identifier generation service. This tracking number is written into the container's message header field when the container is created and accompanies the container throughout its entire lifecycle from creation to destruction. It runs through all stages of the inbound and outbound interaction processing flows, including protocol parsing, format conversion, security encryption and decryption, dynamic routing, and message queue transmission, to achieve unique identification, tracking, and auditing of each transaction across the entire link.

[0045] The structure and generation method of the globally unique tracking identifier are as follows. The globally unique tracking identifier is a 45-digit hexadecimal string, composed of two parts concatenated in sequence. The first part is the application system number, occupying 11 hexadecimal digits. This system number is assigned by the business system according to general rules. The second part is a custom unique identifier, occupying 34 hexadecimal digits. This identifier consists of two substitute identifiers (default is 00) and a 32-digit custom identifier, where the 32-digit custom identifier is composed of alphanumeric characters after removing the hyphens from the UUID. After receiving the generation request, the globally unique identifier generation service uses the serial number generation module to concatenate the system number and the custom unique identifier into a 45-digit hexadecimal string and returns this string.

[0046] A dynamic mapping table refers to a collection of mapping relationship data stored in the form of a configuration file and supporting dynamic loading. It is used to query the corresponding service path, message sender name, or common process type based on the transaction code, product code, or interface identifier. Dynamic mapping tables include transaction code mapping tables, product code mapping tables, and ESB interface routing mapping tables. The term "one-time encryption / decryption principle" means that in the complete interaction process of this invention, the container performs a decryption operation only once on the original request message at the inbound boundary and an encryption operation only once on the internal standard message at the outbound boundary. The container's business data body remains in plaintext during internal insecure processing, avoiding repeated encryption / decryption at multiple intermediate nodes.

[0047] Example 1 like Figure 1 As shown, this embodiment provides a heterogeneous system communication and interaction processing method based on a unified container, using a unified data processing container as the unique data carrier across the entire link.

[0048] The data structure of the unified data processing container includes message header fields, business data body, security context, and routing metadata.

[0049] The message header field carries a unified transaction identifier and routing addressing information across the entire chain, including service number, service serial number, request serial number, global serial number, call path number, original requester organization code, requester service time, product code, transaction code, channel code, original channel code, legal entity bank number, interface version, access point information, attention information, submission key, sub-channel code, IP address, MAC address, longitude, latitude, device ID, SIM card number, device type, device model, operator number, operator name, and organization name. The global serial number is generated when the container is created and persists throughout the entire lifecycle of inbound and outbound interaction processes, serving as the core identifier for end-to-end tracing. The global serial number's structure and generation method are the same as the globally unique tracing identifier, also a 45-digit hexadecimal string, sequentially concatenated from a system number and a custom unique identifier. The transaction code and product code, as core fields of routing metadata, drive dynamic mapping queries.

[0050] The business data body uses a unified data structure to carry standardized business data. In the inbound interaction processing flow, the original request message is converted into internal standard data in JSON format and stored in the business data body after protocol parsing and secure decryption. In the outbound interaction processing flow, the internal standard message is extracted from the business data body after format conversion and secure encryption, and then sent to the target system.

[0051] The security context uniformly manages encryption and decryption policies and states, including encryption algorithm identifiers, key aliases, encryption state identifiers, and digital signatures, and is used to invoke the corresponding security policies when performing encryption and decryption operations at the container boundary.

[0052] Routing metadata drives dynamic mapping queries and message queue routing decisions, including source protocol type, target protocol type, transaction code, product code, and JMS destination.

[0053] The container is created when the inbound interaction processing flow starts. It continuously loads and updates data in each processing stage, including protocol parsing, protocol adaptation, message format conversion, security encryption / decryption, and dynamic routing, until the outbound response is completed or the data is consumed by the business layer and then destroyed. All processing modules uniformly revolve around the container for read and write operations.

[0054] The method includes an inbound interaction processing flow and an outbound interaction processing flow. The inbound and outbound interaction processing flows are two independent processing directions and do not have a sequential execution relationship. In actual business operation, they are executed separately or concurrently depending on the initiator of the communication.

[0055] like Figure 2 As shown, the inbound interaction processing flow includes the following steps: Step A1: The external heterogeneous system initiates an interface call request carrying the original request message to the communication platform. The access application of the communication platform listens on multiple ports, and different ports are associated with different communication protocol types. The access application performs multi-dimensional protocol identification based on the characteristics of the port receiving the request, the protocol identifier field in the message header, and the structural characteristics of the message payload to determine the source protocol type, and determines the target protocol type based on the target system identifier field in the request message.

[0056] Subsequently, the access application performs the allocation operation of the globally unique tracking identifier. The access application calls the identifier retrieval method of the globally unique identifier generation service through the service interface. This method uses a synchronous blocking call approach, where the calling thread waits until the service returns the identifier. Upon receiving the identifier generation request, the globally unique identifier generation service uses the serial number generation module to concatenate the system number and the custom unique identifier into a 45-digit hexadecimal string, which is then returned to the access application as the globally unique tracking identifier. Upon receiving the return value, the access application creates a unified data processing container instance and calls the container's header field setting method to write the 45-digit hexadecimal string into the globally unique tracking identifier field of the header. Simultaneously, the container management module synchronously writes this identifier into the identifier index cache of the container context manager. The identifier index cache uses an in-memory hash table structure, with the globally unique tracking identifier as the key and the container instance reference as the value, to support fast retrieval of container instances by tracking identifier.

[0057] The access application simultaneously initializes the service serial number, requester service time, and channel code fields in the message header, and initializes the source protocol type and target protocol type fields in the routing metadata. The access application loads the complete original request message into the container's raw data buffer and sets the container state to "loading" in the container state machine. A globally unique tracking identifier is used throughout the entire lifecycle of both inbound and outbound interaction processing flows. During container initialization, the container management module verifies whether the globally unique tracking identifier field in the message header has been assigned a value. If it has not been assigned a value, the container initialization is refused and an exception is thrown.

[0058] In a specific interbank agency business scenario, an external third-party custody system initiates a TCP request to port 13003 of the platform. The request message is in fixed-length format and contains a query instruction for the networked bank account balance with transaction code 102A0004. The access application identifies the source protocol type as TCP based on port 13003 and determines the target protocol type as JMS (ActiveMQ) based on the product code identifier field in the request message. The access application calls the globally unique identifier generation service to obtain a globally unique tracking identifier, creates a container instance, writes the globally unique tracking identifier into the message header field, and loads the original fixed-length request message into the container's raw data buffer.

[0059] Step A2: The application performs protocol parsing on the original request message loaded in the container's raw data buffer. The protocol parsing process, based on the source protocol type identified in Step A1, calls the protocol parser corresponding to that protocol type. The protocol parser completes the message unpacking operation according to the agreed communication protocol specifications, sequentially extracting the message header, message body, and message trailer. For the message header, the protocol parser extracts the transaction code, product code, interface version, and organization code fields. For the message body, the protocol parser performs field splitting according to the message format definition, extracting business parameter fields, extended fields, and link tracing information fields. For the message trailer, the protocol parser extracts the checksum or end marker. The protocol parser stores all parsed data into the business data body according to the data structure definition of the business data body. The context in the business data body persists throughout the entire call lifecycle and can be shared and read by subsequent processing stages. After completing protocol parsing, the container state machine transitions the container state from the loading state to the decryption state.

[0060] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the protocol parser unpacks the message according to the TCP protocol, sequentially parsing out the transaction code "102A0004", product code "9990102003", and interface version "V1.0" from the fixed-length message header, and the brokerage number "3299888122", online bank card number "621785******0001", and contracted currency "01" from the message body. The protocol parser writes the transaction code "24603" into the transaction code field of the routing metadata, and writes the brokerage number "3299888122", online bank card number "621785******0001", and contracted currency "01" into the business data body. After parsing is complete, the container state transitions to the decryption state.

[0061] In step A3, after the security processing module detects that the container state has transitioned to the decryption state, it reads the target system security configuration identifier recorded in the container's routing metadata. Based on this security configuration identifier, the security processing module loads the corresponding decryption policy from the security policy library. The decryption policy includes the encryption algorithm identifier, key alias, and digital signature verification rules. The security processing module reads the business data to be decrypted from the business data body and calls the decryption engine to perform the decryption operation. The decryption engine first determines the type of symmetric or asymmetric encryption algorithm used based on the encryption algorithm identifier, then obtains the corresponding decryption key from the key management system based on the key alias, and uses this key to perform field-by-field decryption of the encrypted fields in the business data body. After decryption, the decryption engine verifies the digital signature of the message according to the digital signature verification rules. After successful verification, it performs desensitization processing on sensitive fields. The security processing module fills the plaintext data after decryption, verification, and desensitization back into the corresponding field positions of the business data body and stores the security processing log in the container's log field. The security processing log includes the decryption time, the key alias used, the decrypted field name, and the verification result. After completing the security decryption process, the container state machine will transition the container state from the decryption state to the transition state.

[0062] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the external third-party custody system encrypts the messages using SM4. The security processing module loads the SM4 decryption policy from the security policy library based on the security configuration identifier, obtains the decryption key from the key management system based on the key tag "1050115436", decrypts the business message, fills the decrypted message fields back into the business data body, performs SM2 signature verification on the message's digital signature, and records the result in the log field after successful verification. After decryption is complete, the container state transitions to the transition state.

[0063] In step A4, after the format conversion module detects that the container state has transitioned to the transitioning state, it reads the intermediate state data stored in the business data body. The format conversion module constructs a data mapping relationship according to the internal standard format specification. This data mapping relationship defines the corresponding conversion rules between each field of the intermediate state data and each field of the internal JSON format. The format conversion module iterates through each field of the intermediate state data according to this data mapping relationship, mapping the field name and field value to the field key and field value in the internal JSON format, respectively. For fields that are not present in the intermediate state data but are required in the internal JSON format, the format conversion module fills in the default values ​​according to the field default value rules. The format conversion module then fills back the converted, complete internal JSON format data into the container's business data body, overwriting the original intermediate state data. At this point, the container carries fully standardized internal unified messages. After completing the format conversion, the container state machine transitions the container state from the transitioning state to the routing state.

[0064] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the format conversion module converts the fixed-length balance query message into an internal JSON format. The module constructs a data mapping relationship, mapping the fixed-length field `req_txProcCd` to the JSON field "txProcCd", `req_praaccNo` to the JSON field "praaccNo", and `req_mrctTyp` to the JSON field "mrctTyp". The module generates complete JSON data, including {"txProcCd":"3299888122","praaccNo":"621785******0001","mrctTyp":"01"}, and populates this JSON data back into the business data body. After the conversion is complete, the container state migrates to the routing state.

[0065] In step A5, after the routing decision module detects that the container state has transitioned to the routing state, it reads the transaction code and product code fields from the container's routing metadata. The routing decision module first performs an exact match query in the transaction code mapping table using the transaction code as the query key. The transaction code mapping table is stored in the communication platform's configuration center as a configuration file. Each record in the configuration file contains an external transaction code field, an internal transaction code field, and a service path field. When the query is successful, the routing decision module extracts the internal transaction code and service path from the matched record and writes them into the container's routing metadata. When the query fails, the routing decision module determines that the mapping has failed, triggering an exception handling process. This process constructs an exception response message according to the communication protocol specifications of the third-party system, stores the exception response message in the container, skips subsequent steps, and directly proceeds to the response feedback operation in step A9, while simultaneously recording an exception log.

[0066] The routing decision module then performs an exact match query in the product code mapping table using the product code as the query key. The product code mapping table is stored as a configuration file in the communication platform's configuration center. Each line of the configuration file contains a product code field and a message sender name field. When the query is successful, the routing decision module extracts the message sender name from the matched record and writes it as the JMS destination into the container's routing metadata. When the query fails, the routing decision module determines that the mapping has failed and triggers an exception handling process. Based on the queried target system address, interface address, communication protocol, timeout policy, and retry policy, the routing decision module constructs a complete routing decision result and writes it into the container's routing metadata. The mapping table supports dynamic loading. When the mapping configuration file changes, the configuration center reloads the configuration file after detecting the file change. The currently processing thread continues to use the mapping data before the change to complete the processing. After the current thread finishes processing, the next request thread uses the newly loaded mapping data. After completing the routing decision, the container state machine transitions the container state from the routing state to the completed state.

[0067] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the routing decision module searches the transaction code mapping table using transaction code "102A0004" as the query key. The matched record is the internal transaction code "0210" and the service path " / osl / ibap / cib / scrtspnsracctquery / cibscrtspnsracctquery.biz". The internal transaction code "0210" and the service path " / osl / ibap / cib / scrtspnsracctquery / cibscrtspnsracctquery.biz" are written into the routing metadata. The routing decision module then searches the product code mapping table using product code "LOAN" as the query key. The matched record is the message sender name "P02003_IN_sender", and this name is written into the routing metadata as the JMS destination. The routing decision result includes the message sending queue name and queue size information. The routing decision result is then written into the routing metadata. After completing the routing decision, the container state transitions to the completed state.

[0068] In step A6, the communication platform, based on the JMS destination recorded in the container's routing metadata, sends the loaded container to the internal business layer for processing via a JMS message queue. The internal business layer reads standardized request data in internal JSON format from the container's business data body and executes business logic processing. After completing the business processing, the internal business layer generates response data, organizes the response data according to the internal JSON format, loads it into the original container's business data body, and returns the container to the communication platform's access application via the JMS message queue.

[0069] The application extracts internal standard format data from the business data body, constructs a JMS message based on the routing metadata (the message body is plain JSON data, and the message header carries a globally unique tracking identifier), and sends the message to the business layer. After sending, the container instance is immediately destroyed and the logs are archived.

[0070] After the business layer has finished processing, it replies with a message via JMS (carrying the same globally unique tracking identifier).

[0071] The communication platform (access application) listens to the JMS reply queue. After receiving a reply message, it creates a new container instance (or reuses the original identifier), loads the reply data into the business data body, and then continues to execute steps A7, A8, and A9.

[0072] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the communication platform sends the container to the interbank business service application based on the JMS destination "SSP_OUT_SERVER". Upon receiving the container, the interbank business service application reads the JSON request data from the business data body, executes the brokerage balance query business logic, and queries the database to retrieve the account balance "128500.00". The interbank business service application organizes the response data according to its internal JSON format, generating JSON data including {"txProcCd":"3299888122","praaccNo":"621785******0001","mrctTyp":"01"}, loads it into the original container's business data body, and returns the container to the communication platform's access application via the JMS message queue.

[0073] In step A7, after the security processing module detects that the container state has transitioned to the encryption state, it reads the source channel security configuration identifier recorded in the container's routing metadata. Based on this security configuration identifier, the security processing module loads the corresponding encryption policy from the security policy library. The encryption policy includes an encryption algorithm identifier, key alias, digital signature generation rules, and sensitive field desensitization rules. The security processing module reads the internal JSON-formatted response data from the business data body and calls the encryption engine to perform encryption operations. The encryption engine first identifies the names of fields in the response data that need to be desensitized according to the sensitive field desensitization rules and performs desensitization processing on these fields. The encryption engine determines the encryption algorithm type based on the encryption algorithm identifier, obtains the encryption key based on the key alias, and performs field-by-field encryption on the fields in the response data that need encryption. The encryption engine calculates a digital signature for the encrypted message according to the digital signature generation rules and appends the signature to the message. The security processing module refills the data after encryption, desensitization, and signing operations into the business data body and stores the security processing log in the container's log field. After completing the security encryption processing, the container state machine transitions the container state from the encryption state to the transition state.

[0074] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the external third-party custody system requires digital signatures for the entire response message. The security processing module loads the SM4 encryption policy, obtains the encryption key based on the key alias "1050115436", and performs SM4 encryption on the business data body. The encryption engine calculates an SM2 digital signature on the encrypted response data and appends the signature to the message. The security processing module fills back the encrypted field values ​​and digital signature into the business data body and records the encryption time, key alias, and encrypted field names in the log field. After encryption is completed, the container state transitions to the transition state.

[0075] In step A8, after the format conversion module detects that the container state has transitioned to the "in transition" state, it reads the encrypted response data stored in the business data body. Based on the source protocol type determined in step A1, the format conversion module calls the corresponding reverse format converter. The reverse format converter constructs a reverse data mapping relationship based on the format definition of the original request message, restoring each field of the internal JSON format response data to the fields of the third-party original format response message, including restoring JSON key-value pairs to XML tag pair format, fixed-length field format, or delimiter format. Following the structure of the original request message, the format conversion module assembles the message header, message body, and message trailer sequentially to generate a complete original format response message. The format conversion module stores the restored response message in the container's original data buffer. After completing the format conversion, the container state machine transitions the container state from the "in transition" state to the "completed" state.

[0076] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the format conversion module converts the internal JSON format response data into a fixed-length format. The reverse format converter constructs a reverse data mapping relationship based on the fixed-length message definition, mapping the JSON field "response_data.txAmt" to the fixed-length field txAmt. Following the structure of the original request message, the format conversion module sequentially assembles lkbkId (network bank number), packTyp (packing type), encryptKey (signature key), mac (signature), and packBody (encrypted business body message). The format conversion module stores the restored fixed-length response message into the container's original data buffer. After the conversion is complete, the container state transitions to the completed state.

[0077] Step A9: The access application extracts the restored response message from the container's original data buffer. Based on the source protocol type determined in Step A1, it calls the corresponding protocol encapsulator. The protocol encapsulator encapsulates the response message according to the message encapsulation specifications required by the source protocol type, including adding a protocol header, calculating a checksum, and adding a protocol trailer. The encapsulated response message is then sent back to the external heterogeneous system via the original link. After the response message is successfully sent back, the access application destroys the container and archives the end-to-end logs stored in the container's log field to the log storage center. The inbound interaction processing flow ends.

[0078] In the aforementioned interbank agency business scenario (taking Industrial Bank's interbank business as an example), the access application extracts a fixed-length response message from the original data buffer, calls the TCP protocol encapsulator to encapsulate the response message according to the TCP protocol specification, and sends the encapsulated fixed-length response message back to the external third-party storage system through the original TCP connection. After the fixed-length response message is successfully sent back, the access application destroys the container instance and archives the end-to-end log containing a globally unique tracking identifier to the log storage center.

[0079] In the inbound interaction processing flow, the security decryption process in step A3 and the security encryption process in step A7 strictly adhere to the one-time encryption / decryption principle. In a complete interaction flow, the security processing module performs a decryption operation only once on the original request message at the inbound boundary step A3, and an encryption operation only once on the response data at the outbound boundary step A7. The business data body remains in plaintext throughout its internal flow from steps A4 to A6; the security processing module does not repeatedly encrypt or decrypt the business data body.

[0080] like Figure 3 As shown, the outbound interaction processing flow includes the following steps: In step B1, the internal business layer initiates a request to send an internal standard message to the communication platform. After receiving the internal standard message, the outgoing application of the communication platform performs an allocation operation for a globally unique tracking identifier. The outgoing application calls the identifier acquisition method of the globally unique identifier generation service through the service interface. The globally unique identifier generation service generates a 45-digit hexadecimal string as the globally unique tracking identifier in the same way as in step A1 and returns it to the outgoing application. The outgoing application creates a unified data processing container instance, writes the globally unique tracking identifier into the message header field, and initializes the service serial number, requester service time fields, and target protocol type field in the routing metadata in the message header field. The outgoing application stores the complete internal standard message into the container's business data body. The context in the business data body persists throughout the entire call lifecycle and can be shared and read by subsequent processing stages. After data loading is complete, the container state machine sets the container state to the loading state.

[0081] In a specific public fund collection scenario, the internal business layer of a bank initiates a public fund deposit notification to the public fund center. The internal business layer generates a deposit notification message in an internal JSON format, which includes {"bizType":"DEPOSIT","fundAccount":"GJJ20260101001","idNumber":"110101******1234","name":"Zhang*","amount":"5000.00","depositMonth":"202601"}. After receiving the internal JSON message, the egress application invokes the globally unique identifier generation service to obtain a globally unique tracking identifier, creates a container instance, writes the identifier into the message header field, initializes the target protocol type in the routing metadata as "custom TCP delimiter protocol", and stores the complete internal JSON message in the service data body. After loading is completed, the container status is set to the loading status.

[0082] Step B2: after the format conversion module monitors that the container status is the loading status, it reads the internal standard message stored in the service data body. The format conversion module invokes the forward format converter corresponding to the target protocol type according to the target protocol type recorded in the routing metadata. The forward format converter constructs a forward data mapping relationship according to the message format definition required by the target external system, and converts each field of the internal standard message in the internal JSON format into each field of the message format required by the target external system. When the target external system requires an XML format, the forward format converter maps JSON key-value pairs to XML tag pairs, and generates an XML document conforming to the XML Schema definition of the target system. When the target external system requires a fixed-length message format, the forward format converter performs padding or truncation on each field value according to the field length definition, and splices to generate a fixed-length message byte sequence. When the target external system requires a delimiter message format, the forward format converter assembles each field value into a message string separated by delimiters according to the delimiter definition. The conversion result is temporarily stored in the service data body, overwriting the original internal standard message. After the format conversion is completed, the container state machine migrates the container status from the loading status to the converting status.

[0083] In the aforementioned provident fund collection scenario, the provident fund center requires the use of the vertical line delimiter format. The format conversion module invokes the delimiter format converter according to the target protocol type "custom TCP delimiter protocol". The delimiter format converter constructs a forward data mapping relationship, maps the JSON field "bizType" to the service type field "01", maps "fundAccount" to the provident fund account field "GJJ20260101001", maps "idNumber" to the ID number field "110101******1234", maps "name" to the name field "Zhang*", maps "amount" to the amount field "5000.00", and maps "depositMonth" to the deposit month field "202601". According to the definition of vertical line delimiter, the delimiter format converter assembles each field value into a delimiter message string "01|GJJ20260101001|110101******1234|Zhang*|5000.00|202601" and stores it in the service data body, overwriting the original internal JSON message. After the conversion is completed, the container status migrates to the converting state.

[0084] Step B3: after the security processing module monitors that the container status has migrated to the converting state, it reads the target system security configuration identifier recorded in the routing metadata of the container. The security processing module loads the corresponding encryption policy from the security policy library according to the security configuration identifier. The encryption policy includes an encryption algorithm identifier, a key alias, a digital signature generation rule and a sensitive field desensitization rule. The security processing module reads the converted target format message data from the service data body and invokes the encryption engine to perform encryption operations. The encryption engine first identifies the fields that need desensitization in the message according to the sensitive field desensitization rule, and performs desensitization processing on these fields. The encryption engine determines the type of encryption algorithm according to the encryption algorithm identifier, obtains the encryption key according to the key alias, and performs field-by-field encryption on the fields that need to be encrypted in the message. The encryption engine calculates the digital signature for the encrypted message according to the digital signature generation rule and attaches the signature to the message. The security processing module backfills the data after encryption, desensitization and signature operations into the service data body, and stores the security processing logs in the log domain of the container. After the security encryption processing is completed, the container state machine migrates the container status from the converting state to the routing state.

[0085] In the aforementioned housing provident fund collection scenario, the housing provident fund center requires SM4 encryption of the ID number field and SM2 digital signature of the entire message. The security processing module loads the SM4 encryption policy, obtains the encryption key based on the key alias "SM4_KEY_GJJ", and performs SM4 encryption on the ID number "110101******1234" in the business data body, obtaining a ciphertext byte sequence. The security processing module uses the SM2 private key to calculate a digital signature on the encrypted complete message and appends the signature to the end of the message. The security processing module then rewrites the encrypted ID number ciphertext and SM2 signature back into the business data body, recording the encryption time and key alias in the log field. After encryption is complete, the container state is migrated to the routing state.

[0086] In step B4, after the routing decision module detects that the container state has transitioned to the routing state, it reads the product code field and the internal transaction code field from the container's routing metadata. First, using the product code as the query key, the routing decision module performs an exact match query in the product code mapping table to obtain the corresponding JMS message sender name, and writes this name as the routing target into the routing metadata. Then, using the internal transaction code as the query key, the routing decision module performs an exact match query in the transaction code mapping table to obtain the corresponding external transaction code, and writes the external transaction code into the routing metadata. The routing decision module constructs a complete routing decision result based on the queried target system address, interface address, communication protocol, timeout policy, and retry policy. When a mapping query fails, an exception handling process is triggered. This process constructs an exception response according to the target system's communication protocol specifications, records the exception log, and terminates the current outbound interaction process. After completing the routing decision, the container state machine transitions the container state from the routing state to the completed state.

[0087] In the aforementioned housing provident fund collection scenario, the routing decision module queries the product code mapping table using the product code "GJJ" as the lookup key to obtain the JMS message sender name "JMS_GJJ_SENDER". The routing decision module then queries the transaction code mapping table using the internal transaction code "DEPOSIT" as the lookup key to obtain the external transaction code "GJJ_DEP". Based on the retrieved target system address "10.10.10.100:9090", communication protocol "TCP", timeout policy "60000 milliseconds", and retry policy "retry 2 times", the routing decision module constructs a complete routing decision result and writes it to the routing metadata. After completing the routing decision, the container state transitions to the completed state.

[0088] In step B5, the outgoing application sends the encrypted final message to the target external system through the corresponding protocol channel, based on the target system address and communication protocol recorded in the container's routing metadata. The outgoing application starts a timeout timer to wait for a response from the target external system. The outgoing application receives the raw response message, exception status code, and error information returned by the target external system, storing the received raw response message in the container's raw data buffer and the exception status code and error information in the routing metadata's log field. The container state machine transitions the container state from the completed state to the decrypting state.

[0089] In the aforementioned housing provident fund collection scenario, the outgoing application sends an encrypted delimited message "01|GJJ20260101001|SM4 encrypted ID number|Zhang*|5000.00|202601|SM2 signature" to the housing provident fund center server via a TCP protocol channel using the target system address "10.10.10.100:9090", and starts a 60000-millisecond timeout timer. After processing the payment notification, the housing provident fund center server returns a response message: "00|GJJ20260101001|Payment successful|20260101143000", where "00" is the success status code. The outgoing application receives this response message, stores it in the container's raw data buffer, and stores the status code "00" in the routing metadata log field. The container state then transitions to the decryption state.

[0090] In step B6, after the security processing module detects that the container state has transitioned to the decryption state, it reads the target system security configuration identifier recorded in the container's routing metadata, loads the corresponding decryption policy from the security policy library, performs decryption operations on the encrypted fields in the original response message, performs signature verification operations on the digital signature, and fills the decrypted and verified data back into the business data body. After completing the security decryption process, the container state machine transitions the container state from the decryption state to the transition state.

[0091] In step B7, after the format conversion module detects that the container state has transitioned to the transitioning state, it reads the decrypted response data stored in the business data body and calls the reverse format converter to convert the response message in the target external system format into standardized response data in the internal JSON format. The format conversion module then fills the converted standardized response data back into the business data body. After the format conversion is complete, the container state machine transitions the container state from the transitioning state to the completed state.

[0092] In the aforementioned housing provident fund collection scenario, the format conversion module calls the reverse delimiter format converter to split the delimiter response message "00|GJJ20260101001|Deposit Successful|20260101143000" using vertical delimiters. Following the reverse data mapping relationship, it maps each field value to a JSON field, generating JSON data including {"status":"00","fundAccount":"GJJ20260101001","message":"Deposit Successful","time":"20260101143000"}, which is then populated back into the business data body. After the conversion is complete, the container state transitions to the "Completed" state.

[0093] Step B8: The outbound application extracts standardized response data from the business data body and sends it back to the internal business layer via the internal communication interface. After the standardized response data is successfully sent back, the outbound application destroys the container and archives the end-to-end logs stored in the container's log domain to the log storage center. The outbound interaction processing flow ends.

[0094] In the aforementioned housing provident fund collection scenario, the outgoing application extracts standardized response data in JSON format from the business data body and sends it back to the internal business layer that initiated the contribution notification via an internal HTTP interface. After the standardized response data is successfully sent back, the outgoing application destroys the container instance and archives the end-to-end logs containing a globally unique tracking identifier to the log storage center.

[0095] In this embodiment, the query-driven and configuration-based loading of the dynamic mapping table enables the addition of new third-party channels or internal businesses by configuring the mapping relationship without modifying the container's data structure and processing flow.

[0096] The inbound and outbound interactive processing flows use different numbering systems for their steps to clarify that they are independent processing directions and have no sequential execution relationship.

[0097] This embodiment also provides a processing flow for interacting with the ESB (Enterprise Service Bus). This processing flow is independent of the above-mentioned inbound and outbound interaction processing flows and is executed when a request is initiated by the channel through the ESB.

[0098] like Figure 4 As shown, the ESB interaction process includes the following steps: Step C1: The communication platform receives the request message sent by the channel end via ESB. The access application of the communication platform creates a container instance, stores the original ESB message in the container's business data body, and initializes the service serial number field in the message header field and assigns a globally unique tracking identifier to the message header field.

[0099] In a specific social security card management scenario, the social security channel sends a social security card loss reporting request message via ESB. The access application creates a container instance, assigns a globally unique tracking identifier, and stores the original ESB message in the business data body.

[0100] In step C2, the access application extracts the service number field from the container's message header and the version number field from the business data body. The access application concatenates the service number and version number according to a preset combination rule, and the combined result serves as the unique interface identifier for accessing the business gateway. The access application stores this unique interface identifier in the container's routing metadata.

[0101] In the social security card management scenario described above, the access application extracts the service number "SOCIAL_CARD" from the message header field and the version number "V2.0" from the business data body. They then concatenate these into "SOCIAL_CARD_V2.0" according to the combination rules as a unique interface identifier and store it in the routing metadata.

[0102] In step C3, the access application queries the data mapping table based on the unique interface identifier in the routing metadata. The data mapping table is stored in a configuration file. Each line of the configuration file contains an interface identifier field and a process type field. The process type field has two possible values: standard interface common process and special interface common process. The special interface common process is used to handle complex packets with loop nodes. When the query is successful, the access application extracts the process type identifier from the matched record and writes it into the container's routing metadata. When the query fails, the access application triggers an exception handling process.

[0103] In the social security card management scenario described above, the access application queries the data mapping table using "SOCIAL_CARD_V2.0" as the query key. If the matched record corresponds to the standard interface public process, the standard interface public process identifier is written into the routing metadata.

[0104] In step C4, the format conversion module reads the process type identifier from the container's routing metadata. When the process type identifier is a standard interface common process, the format conversion module calls the standard interface format converter. The standard interface format converter calls the corresponding ESB interface through a preset configuration item, which configures the latter half of the business interface URL corresponding to the ESB interface. The format conversion module converts the ESB format message into a unified access format message for the target business system, concatenates the complete backend URL, and sends it to the business gateway via an HTTP client. When the process type identifier is a special interface common process, the format conversion module calls the special interface format converter. During the conversion process, the special interface format converter identifies and processes the loop nodes in the ESB message, independently performs field mapping and format conversion for each iteration of the loop node, assembles all iteration results to generate a unified access format message, concatenates the backend URL, and sends it to the business gateway. During the format conversion process, the container always maintains bidirectional traceability between the original ESB message and the converted unified access format message. That is, the container's business data body stores both the original ESB message and the converted message, and the two are associated through field mapping relationships.

[0105] In the aforementioned social security card management scenario, the format conversion module reads the standard interface public process identifier from the routing metadata and calls the standard interface format converter. The standard interface format converter calls the corresponding social security card loss reporting ESB interface through pre-configured items, which specify the latter half of the business interface URL corresponding to the ESB interface as " / social / card / loss". The format conversion module converts the ESB-formatted social security card loss reporting message into a unified access format JSON message for the target business system, concatenates the complete backend URL "http: / / business-gateway / social / card / loss", and sends it to the business gateway via an HTTP client.

[0106] Step C5: The access application receives the response data returned by the business gateway and stores the response data into the business data body of the container. The format conversion module performs a reverse conversion of the business gateway response data into an ESB format message, and stores the reverse-converted ESB format message into the container's raw data buffer. The access application extracts the ESB format response message from the raw data buffer and returns it to the channel end via ESB. The container is destroyed, and the end-to-end logs are archived.

[0107] This embodiment also provides a file interaction processing flow, which is independent of the above-mentioned inbound interaction processing flow, outbound interaction processing flow and ESB interaction processing flow, and is invoked and executed when a file transfer operation is required.

[0108] like Figure 5 As shown, the file interaction processing flow includes the following steps: Step D1: In the common sub-process for file interaction, the container management service is invoked to create a container instance. If a container instance already exists in the current context, it is reused instead of being created again. The common sub-process for file interaction assembles the request parameters required for file upload or download in the container's business data body. The request parameters vary depending on the file operation type. For file upload operations, the request parameters include the local file path, Minio storage path, target FTP or SFTP server address, target FTP or SFTP username and password, target FTP or SFTP path, and file encoding. For file download operations, the request parameters include the source FTP or SFTP server address, source FTP or SFTP username and password, source FTP or SFTP path, file list, Minio storage path, and file encoding. The common sub-process for file interaction also writes file metadata into the business data body. The file metadata includes the filename, file size, file creation time, and file MD5 checksum for each file in the file list.

[0109] In a specific scenario involving the transfer of social security card production data files, the bank's internal card production system needs to transfer batch card production data files to an external server of the social security department. The common sub-process for file interaction creates a container instance and assembles file upload request parameters within the business data body, including the local file path " / data / card / batch_20260101.csv", the Minio storage path "minio: / / bucket-card / card / batch_20260101.csv", the social security department's SFTP server address "sftp: / / 10.10.10.101:22", the username "card_user", the password "encrypted_password", the target path " / incoming / card / ", and the file encoding "UTF-8". The file metadata includes the filename "batch_20260101.csv", the file size "2048576 bytes", the file creation time "2026-01-01 10:00:00", and the file MD5 checksum "a1b2c3d4e5f6".

[0110] In step D2, the file interaction public sub-process invokes the token acquisition service. Based on the target FTP or SFTP server address and username recorded in the business data body, the token acquisition service requests an upload or download token corresponding to the target server from the token management platform. After verifying the requested permissions, the token management platform generates a time-limited access token and returns it to the file interaction public sub-process. The file interaction public sub-process then stores the acquired access token in the container's security context.

[0111] In the aforementioned scenario of transferring social security card production data files, the common sub-process for file interaction invokes the token acquisition service. Based on the SFTP server address "sftp: / / 10.10.10.101:22" and the username "card_user", it requests an SFTP access token from the token management platform. After verifying the requested permissions, the token management platform generates an access token "SFTP_TOKEN_202601011000" with a 30-minute validity period and returns it to the common sub-process for file interaction. The common sub-process for file interaction then stores the access token "SFTP_TOKEN_202601011000" in the security context.

[0112] Step D3: The common sub-process for file interaction calls the file transfer engine to perform file transfer operations. The file transfer engine first reads the access token stored in the container's security context and uses this token to initiate authentication with the target FTP or SFTP server. After successful authentication, the file transfer engine reads the local file path, Minio storage path, target server path, and transfer file encoding stored in the business data body. For file upload operations, the file transfer engine first reads the file to be uploaded from the local file path, encodes the file according to the transfer file encoding, and then transfers it to the specified path on the target server via FTP or SFTP protocol. For operations involving Minio storage, the file transfer engine uploads the local file to Minio object storage before performing FTP or SFTP transfer, and writes the Minio storage path back to the business data body after the Minio upload is complete. For file download operations, the file transfer engine first downloads the file from the specified path on the target server via FTP or SFTP protocol, decodes the downloaded file according to the transfer file encoding, saves it to the local file path, uploads the file to Minio object storage, and writes the Minio storage path back to the business data body. The file transfer engine supports batch transfer of multiple files, performing the above transfer operation sequentially for each file in the file list.

[0113] The file transfer engine records the transfer status of each file in real time during the transfer process. The transfer status includes the transfer start time, transfer end time, number of bytes transferred, transfer success rate, and error information. The file transfer engine summarizes the transfer status of all files and writes it to the file transfer result field of the business data body. After completing all file transfer operations, the file transfer engine writes the operation results back to the business data body, and the container carries the complete file transfer results to the next processing stage.

[0114] In the aforementioned scenario of transferring social security card production data files, the file transfer engine reads the access token "SFTP_TOKEN_202601011000" from the security context and uses this token to initiate authentication with the social security department's SFTP server. Upon successful authentication, an SFTP connection is established. The file transfer engine reads the local file path " / data / card / batch_20260101.csv", the Minio storage path "minio: / / bucket-card / card / batch_20260101.csv", the target server path " / incoming / card / ", and the file encoding "UTF-8" stored in the business data body. The file transfer engine first converts the local file " / data / card / batch_20260101.csv" into a byte stream using UTF-8 encoding, and then transfers it to the social security department's SFTP server directory " / incoming / card / " via the SFTP protocol. After the file transfer is complete, the file transfer engine uploads the local file to the Minio object storage, and the Minio storage path "minio: / / bucket-card / card / batch_20260101.csv" is written back to the business data body. The file transfer engine records the transfer status, including the transfer start time "2026-01-01 10:00:00", the transfer end time "2026-01-01 10:00:30", the number of bytes transferred "2048576", the transfer success rate "100%", and the error message "none". The file transfer engine summarizes the transfer status and writes it to the file transfer result field of the business data body. The container carries the complete file transfer result to the next processing stage.

[0115] The file interaction processing flow supports the following file operation types: put operation (retrieving files from Minio and transferring them to a third party via FTP or SFTP), get operation (retrieving files from a third-party FTP or SFTP and storing them in Minio), MinioPut operation (uploading local files to Minio object storage), MinioGet operation (downloading files from Minio to local storage), ftpPut operation (transferring local files to a third party via FTP or SFTP), ftpGet operation (retrieving files from a third-party FTP or SFTP and storing them locally), and JMS_IN operation (supporting other applications on this node to call the above operations via JMS).

[0116] During a PUT operation, the container's business data body needs to include the following fields: transfer method, third-party username, third-party password, third-party address, third-party port, file encoding, Minio file list, recipient path, and number of files. The transfer method field can be either SFTP or FTP-PASV. When the file transfer engine executes a PUT operation, it selects the corresponding transfer protocol based on the transfer method field, reads files one by one from the location specified in the Minio file list, transfers the files to the specified directory on the third-party server according to the recipient path, and writes the transfer status of each file back to the business data body after the transfer is complete.

[0117] During a GET operation, the container's business data body needs to include the following fields: transfer method, bucket type, proxy type, Minio upload file path, peer path, third-party username, third-party password, third-party address, third-party port, and transfer file encoding. The bucket type field can be either a temporary bucket or a business-wide bucket. When the file transfer engine executes a GET operation, it selects the corresponding transfer protocol based on the transfer method field, reads files one by one from the peer path on the third-party server, decodes and converts them according to the transfer file encoding, determines the Minio storage bucket based on the bucket type field, and stores the files in Minio according to the Minio upload file path. The response includes the number of files loaded into the container and a list of Minio files.

[0118] In the MinioPut operation, the container's business data body needs to load fields including the local file path, bucket type, and Minio upload file path. The bucket type field can be a temporary bucket, a business common bucket, or an external communication platform bucket. When the file transfer engine executes the MinioPut operation, it determines the Minio storage bucket based on the bucket type field, reads the file from the local file path, uploads the file to Minio according to the Minio upload file path, and the container loads the Minio file storage path, the Minio file list, and the number of files in the response.

[0119] In the MinioGet operation, the fields that the container's business data body needs to load include the number of files and the list of Minio files. When the file transfer engine executes the MinioGet operation, it reads the corresponding file from Minio based on the file identifier in the Minio file list, saves it to the local file path, and the container loads the number of files, the local file path, and the list of local file names in the response.

[0120] During an ftpPut operation, the container's business data body needs to include fields such as transfer method, proxy type, third-party username, third-party password, third-party address, third-party port, destination path, local file path, and file encoding. When the file transfer engine executes an ftpPut operation, it selects either SFTP or FTP-PASV protocol based on the transfer method field, determines whether to access the target FTP or SFTP server through a proxy server based on the proxy type field, reads the file from the local file path, performs encoding conversion according to the file encoding, and then transfers it to the destination path of the third-party server. The response includes the number of files loaded by the container and a list of local filenames.

[0121] In an ftpGet operation, the container's business data body needs to include fields such as transfer method, proxy type, third-party username, third-party password, third-party address, third-party port, peer path, file encoding, and connection timeout. When the file transfer engine executes an ftpGet operation, it selects the corresponding transfer protocol based on the transfer method field, determines whether to access the target server through a proxy server based on the proxy type field, reads the file from the peer path of the third-party server, decodes and converts it according to the file encoding, and saves it to the local file path. The response includes the number of files loaded by the container, the local file path, and a list of local file names.

[0122] In the JMS_IN operation, the container's business data body needs to load the following fields: response adapter name and service identifier. The service identifier field can be set to put, get, MinioPut, MinioGet, ftpPut, or ftpGet. The JMS_IN operation is used to support other applications on this node to call the above file operation functions via JMS. When another application initiates a JMS_IN call, the common sub-process for file interaction routes the corresponding file operation execution logic based on the value of the service identifier field, and the other fields are loaded according to the request specification of the called service.

[0123] Example 2 like Figure 6 As shown, this embodiment provides a heterogeneous system communication and interaction processing system based on a unified container. The system includes a container management module, an access processing module, an outgoing processing module, a routing decision module, a security processing module, a format conversion module, an ESB interaction module, and a file interaction module. Each of these modules is a software functional module deployed on the communication platform server. Data transfer and state synchronization between modules are achieved through container instances provided by the container management module.

[0124] This embodiment focuses on illustrating the overall system architecture and the logical relationships between its modules. The system architecture adopts a layered design, including an access layer, container management layer, security layer, format conversion layer, routing layer, and output layer. The access processing module and outgoing processing module are located in the access layer, responsible for communication connections with external systems and internal business layers. The container management module is located in the container management layer, serving as the core hub of the entire system architecture, responsible for the full lifecycle management of containers, and providing services for creating, reading, updating, and destroying container instances for all other modules. The security processing module is located in the security layer, responsible for performing encryption / decryption, de-identification, and signature verification operations. The format conversion module is located in the format conversion layer, responsible for bidirectional conversion of message formats. The routing decision module is located in the routing layer, responsible for performing dynamic mapping queries and routing decisions. The ESB interaction module and file interaction module are located in the output layer, responsible for handling interaction requirements in specific scenarios.

[0125] The logical relationships between the modules are described in detail below: The container management module, as the core hub of the system architecture, has direct logical connections with all other modules. It provides container creation and initialization interfaces to the access processing module, which calls the container creation interface to create container instances when receiving external requests. It also provides container creation and loading interfaces to the outgoing processing module, which calls the container creation interface to create container instances when receiving requests from the internal business layer. Furthermore, it provides container status reading and data update interfaces to the security processing module. Before performing encryption / decryption operations, the security processing module uses the container status reading interface to confirm whether the container's current status allows encryption / decryption. After encryption / decryption, it uses the container data update interface to update the processing result back to the container. Finally, it provides container status reading and data update interfaces to the format conversion module. Before performing format conversion, the format conversion module uses the container status reading interface to confirm whether the container's current status allows format conversion. After format conversion, it uses the container data update interface to update the conversion result back to the container. The container management module provides the routing decision module with container status read and container data update interfaces. Before executing a routing decision, the routing decision module uses the container status read interface to confirm whether the container's current state allows the routing decision operation. After the routing decision is completed, it uses the container data update interface to write the routing result into the container's routing metadata. The container management module provides the ESB interaction module and file interaction module with container reuse and container destruction interfaces. At the beginning of the interaction process, the ESB interaction module and file interaction module obtain or create container instances using the container reuse interface, and at the end of the interaction process, they destroy container instances using the container destruction interface.

[0126] The access processing module, security processing module, format conversion module, and routing decision module have a sequential logical relationship. After completing protocol parsing, the access processing module transitions the container state to the decryption state and sends a state change notification to the security processing module. Upon receiving this state change, the security processing module begins security decryption. After decryption, the security processing module transitions the container state to the conversion state and sends a state change notification to the format conversion module. Upon receiving this state change, the format conversion module begins format conversion. After format conversion, the format conversion module transitions the container state to the routing state and sends a state change notification to the routing decision module. Upon receiving this state change, the routing decision module begins routing decision processing. After completing routing decisions, the routing decision module transitions the container state to the completed state and sends a routing completion notification to the access processing module. Upon receiving this state change, the access processing module begins message queue sending. Upon receiving a response from the internal business layer, the access processing module transitions the container state to the encryption state and sends a state change notification to the security processing module. The security processing module then begins encryption of the response data. After completing encryption, the security processing module transitions the container state to the conversion state, and the format conversion module begins to perform response message restoration processing.

[0127] The outgoing processing module, format conversion module, security processing module, and routing decision module have a sequential logical relationship. After loading the internal standard message, the outgoing processing module transitions the container state to the loading state and sends a state change notification to the format conversion module, which then begins format conversion. After completing format conversion, the format conversion module transitions the container state to the conversion state and sends a state change notification to the security processing module, which then begins security encryption. After encryption, the security processing module transitions the container state to the routing state and sends a state change notification to the routing decision module, which then begins routing decision processing. After completing routing decision processing, the routing decision module transitions the container state to the completed state and sends a routing completion notification to the outgoing processing module, which then begins message transmission. Upon receiving a response from the target external system, the outgoing processing module transitions the container state to the decryption state and sends a state change notification to the security processing module, which then begins response decryption. After decryption, the security processing module transitions the container state to the conversion state, and the format conversion module begins response format conversion.

[0128] There is a logical data dependency between the routing decision module and the container management module. When executing a routing decision, the routing decision module reads the transaction code and product code fields from the container's routing metadata and uses these two fields as query keys to perform a query in the dynamic mapping table. The routing decision module writes the queried routing results into the container's routing metadata, and the container management module is responsible for persisting the updated routing metadata to the container instance.

[0129] There is a logical data dependency between the security processing module and the container management module. When performing encryption and decryption operations, the security processing module reads the encryption algorithm identifier, key alias, encryption state identifier, and digital signature from the container's security context, and loads the corresponding encryption and decryption policy based on these security configurations. The security processing module then populates the encryption and decryption operation results back into the container's business data body and security context, and the container management module is responsible for persisting the updated data to the container instance.

[0130] There is a logical data dependency between the format conversion module and the container management module. When performing format conversion, the format conversion module reads the data to be converted from the business data body stored in the container management module, populates the converted data back into the business data body through the container management module, and the container management module is responsible for persisting the updated data to the container instance.

[0131] There is a logical relationship between the ESB interaction module, the container management module, and the format conversion module. The ESB interaction module obtains or creates container instances through the container management module and controls the format conversion module to perform bidirectional conversion between ESB format messages and unified access format messages. During the conversion process, the container always maintains bidirectional traceability between the original ESB message and the converted message.

[0132] The file interaction module has a logical relationship with the container management module and the security processing module. The file interaction module obtains or creates container instances through the container management module, assembles file transfer request parameters in the container's business data body, calls the security processing module to store the obtained access token in the container's security context, and the file transfer engine performs file transfer operations based on the request parameters and token loaded in the container. The operation results are written back to the business data body through the container management module.

[0133] The access processing module and the outgoing processing module are mutually exclusive and independent. The access processing module is responsible for handling communication from the outside to the inside, while the outgoing processing module is responsible for handling communication from the inside to the outside. The two modules operate independently and there is no direct connection between them in terms of data transmission or state synchronization.

[0134] The system's various modules achieve data sharing and state synchronization through container instances provided by the container management module. All modules do not directly manipulate the original messages or business data, but instead uniformly perform read and write operations around the container, thereby achieving standardization and reusability of the communication layer processing logic.

[0135] Example 3 This embodiment uses a commercial bank as an application scenario in the financial industry to illustrate the specific implementation process of the technical solution of the present invention in online search and control business. The complete execution process of the inbound interaction processing flow in this embodiment has been fully described in steps A1 to A9 of Embodiment 1 using the online search and control scenario as an example, and will not be repeated here. This embodiment further explains the file interaction scenario involved in the online search and control business.

[0136] In commercial banks' online asset tracing and control operations, in addition to initiating account inquiry and freezing requests, judicial authorities may also require banks to provide batch account transaction records. In such batch file exchange scenarios, after the bank's internal system generates the transaction records from its core database, it needs to transmit the files to the file server designated by the judicial authorities via a communication platform.

[0137] In the file interaction processing flow, after the bank's internal document generation system generates the transaction log file, it initiates a file upload request to the communication platform. The common sub-process for file interaction creates a container instance and assembles the file upload request parameters in the container's business data body, including the local file path, Minio storage path, judicial authority SFTP server address, username, password, target path, and file encoding. The common sub-process for file interaction calls the token acquisition service to obtain an SFTP access token and stores it in the security context. The file transfer engine reads the access token from the security context, initiates authentication with the judicial authority SFTP server, and after successful authentication, reads the local file, converts it according to the file encoding, and transfers it to the target directory of the judicial authority SFTP server via the SFTP protocol. After the file transfer is complete, the file transfer engine uploads the local file to the Minio object storage, and the Minio storage path is written back to the business data body. The file transfer engine records the complete transfer status, including the number of bytes transferred, the success rate, and error information. It summarizes the transfer status and writes it to the file transfer result field of the business data body. The container returns the complete file transfer result to the bank's internal document generation system.

[0138] The above file interaction process and inbound interaction processing flow share the same globally unique tracking identifier generation mechanism. File transfer operations and message interaction operations achieve full-process traceability management through globally unique tracking identifiers.

[0139] Example 4 This embodiment uses social security card management as an application scenario to illustrate the specific implementation process of the technical solution of the present invention in its interface with external systems of the human resources and social security department. The complete execution process of the ESB interaction processing flow in this embodiment has been fully described in steps C1 to C5 of Embodiment 1 using the social security card management scenario as an example. This embodiment further explains the outbound interaction processing flow in the social security card management business.

[0140] Social security card management involves data synchronization and business collaboration between the bank's internal core system and the human resources and social security department's external system. After completing the processing of social security card issuance, loss reporting, replacement, or cancellation, the bank's internal business layer needs to notify the human resources and social security department's external system of the processing results.

[0141] In the outbound interaction processing flow, after the bank's internal business layer completes the social security card loss reporting process, it generates an internal JSON format loss report notification message. Upon receiving this notification message, the outbound application creates a container instance, assigns a globally unique tracking identifier, and stores the complete internal JSON message in the business data body. The format conversion module converts the internal JSON message into the WebSocket protocol and fixed-length message format required by the external system of the human resources and social security department, based on the target protocol type recorded in the routing metadata. The security processing module performs encryption and signing operations according to the security configuration of the human resources and social security department. The routing decision module determines the target system address and communication protocol by querying the dynamic mapping table based on the product code and transaction code. Based on the routing decision result, the outbound application sends the encrypted final message to the external system of the human resources and social security department via the WebSocket protocol channel. After receiving the response message returned by the external system of the human resources and social security department, the outbound application performs reverse security parsing and format conversion, and sends the restored standardized response data back to the internal business layer.

[0142] When external systems of the human resources and social security department simultaneously initiate inbound requests, the access processing module independently executes the inbound interaction processing flow, running concurrently with the outbound interaction processing flow. The two flows each use independent container instances and do not interfere with each other.

[0143] Example 5 This embodiment uses the housing provident fund collection and withdrawal business as an application scenario to illustrate the specific implementation process of the technical solution of the present invention in the interface with the external system of the housing provident fund management center. The complete execution process of the outbound interaction processing flow in this embodiment has been fully described in steps B1 to B8 of Embodiment 1 using the housing provident fund collection scenario as an example. This embodiment further explains the inbound interaction processing flow and the dynamic mapping table exception handling scenario in the housing provident fund business.

[0144] When an external system of the Housing Provident Fund Center initiates a housing provident fund withdrawal request to a bank, the inbound interaction processing flow is executed. The Housing Provident Fund Center system sends a withdrawal request message in delimited message format via a custom TCP protocol. The access application identifies the source protocol type as the custom TCP protocol based on port characteristics and determines the target protocol type as JMS based on the target system identifier. The access application creates a container instance, assigns a globally unique tracking identifier, and loads the original delimited message into the container's raw data buffer. The protocol parser unpacks the message according to the custom TCP protocol, splits the fields according to the vertical delimiter parsing rules, and extracts business parameters such as transaction code, housing provident fund account number, ID number, name, and withdrawal amount. All parsed data is stored in the business data body. The security processing module performs SM4 decryption and SM2 signature verification operations according to the Housing Provident Fund Center's security configuration. The format conversion module converts the delimited message data into the internal JSON format. The routing decision module performs a query in the transaction code mapping table using the transaction code as the query key. If the corresponding internal transaction code record does not exist in the mapping table, the routing decision module determines that the mapping has failed and triggers the exception handling process. The exception handling process constructs a delimited format exception response message according to the communication protocol specifications of the Housing Provident Fund Center. The exception response message contains error codes and error information. The exception response message is stored in a container, skipping subsequent steps and directly proceeding to the response feedback operation. Simultaneously, mapping failure exceptions are recorded in the exception log. The access application retrieves the exception response message from the raw data buffer and sends it back to the Housing Provident Fund Center system via a custom TCP protocol. The container is then destroyed, and the entire log is archived.

[0145] Example 6 This embodiment uses bill payment services as an application scenario to illustrate the concurrent processing capability and overall system architecture operation mechanism of the technical solution of the present invention when connecting to multiple third-party payment channels.

[0146] The bill payment service involves batch transaction processing between the bank's internal core system and external systems of multiple third-party payment channels, such as water, electricity, gas, and telecommunications. Different third-party payment channels use different communication protocols and message formats: water channels use HTTP protocol and JSON format, electricity channels use HTTPS protocol and XML format, gas channels use WebSocket protocol and fixed-length message format, and telecommunications channels use a custom TCP protocol and delimited message format.

[0147] In multi-channel concurrent request scenarios, the communication platform's access processing module listens to multiple ports simultaneously, each associated with a different communication protocol type. When multiple channels initiate requests concurrently, the access processing module creates an independent container instance for each request. Each container instance has a unique globally unique tracking identifier, an independent state machine, and an independent lifecycle. State transitions within each container are independent; a state transition in one container will not trigger state changes in other containers. The access processing module allocates an independent processing thread for each request through a multi-threaded concurrent processing mechanism. Each thread independently executes protocol parsing, security decryption, format conversion, and routing decision operations. Each container's business data body independently stores the message data for its respective channel, without interference.

[0148] During the format conversion phase, each container's format conversion module calls the corresponding format converter based on the source protocol type recorded in its container's routing metadata. Each format converter operates independently, and the conversion results are stored in the business data body of its respective container.

[0149] During the routing decision-making phase, each container's routing decision module reads the transaction code and product code recorded in its respective container's routing metadata and performs a query in a unified dynamic mapping table. The routing decision results of each container are written into its respective container's routing metadata. Each container then sends its routing decision results to the corresponding internal business processing application via its own JMS message sender.

[0150] In the outbound interaction processing flow, when the internal business layer simultaneously sends payment result notifications to multiple payment channels, the outbound processing module creates an independent container instance for each target channel. Each container instance independently performs format conversion, security encryption, and routing decision operations. The format conversion module of each container calls the corresponding forward format converter based on the target protocol type recorded in its respective container's routing metadata, converting it to the protocol and message formats required by each channel. The security processing module of each container executes the corresponding encryption policy based on the security configuration of its respective channel. Each container independently completes message sending, response reception, and reverse parsing.

[0151] In file-based communication scenarios, the bulk payment files involved in bill payment services need to be transferred from within the bank to designated servers outside each payment channel. The file-based communication module creates an independent container instance for each channel. Within each container's business data body, the corresponding channel's file transfer parameters are assembled. Each container independently calls a token acquisition service to obtain the corresponding transfer token. The file transfer engine executes multi-channel file upload or download operations in parallel based on the parameters and tokens loaded in each container. Each container independently records the operation results and transfer status. File transfer tasks across different channels share the same globally unique tracking identifier generation mechanism and routing decision mechanism, but the lifecycle and state transitions of each container are independent.

[0152] In the above process, the container management module acts as the core hub of the system, managing the creation, state maintenance, and destruction of all container instances. Each processing module uses the container instances provided by the container management module for data transfer and state synchronization. No module directly manipulates the original messages or business data, achieving standardization and reusability of the communication layer processing logic. When adding a new payment channel, only new protocol identification rules need to be configured in the access processing module and new mapping relationships need to be configured in the dynamic mapping table of the routing decision module, without modifying the container's data structure and processing flow, or the code logic of other existing modules.

[0153] Example 7 This embodiment uses interbank agency business as an application scenario to illustrate the specific implementation process of the technical solution of the present invention in interfacing with other banking systems.

[0154] Interbank agency business involves business interactions such as agency clearing, agency settlement, and agency inquiry between our core system and multiple other banks' interbank systems. Different interbank systems use different communication protocols and message formats. Some interbank systems use HTTPS protocol and XML format, some use WebSocket protocol and JSON format, and some use custom TCP protocol and fixed-length message format.

[0155] In the inbound interaction processing flow, each industry system initiates proxy service requests through its own communication protocol. The protocol identification unit of the access processing module performs multi-dimensional protocol identification based on port characteristics, message headers, and payload structures, automatically distinguishing protocol types from different sources. The access processing module creates an independent container instance for each request and assigns a unique globally unique tracking identifier. In the format conversion stage, the format conversion module of each container calls the corresponding protocol parser and format converter according to the source protocol type recorded in the routing metadata of each container, uniformly converting the original message format of each channel into the internal JSON format. In the security decryption stage, the security processing module loads the corresponding decryption policy according to the security configuration of each industry system recorded in the routing metadata of each container, and performs decryption, signature verification, and de-identification operations for request messages containing encrypted fields. In the routing decision stage, the routing decision module queries the dynamic mapping table according to the transaction code and product code of each container, and routes each request to the corresponding internal proxy service processing application.

[0156] In the outbound interaction processing flow, the internal business layer initiates proxy business requests or notifications in a unified internal JSON format. The outbound processing module creates an independent container instance for each target peer system. Each container independently performs format conversion, security encryption, and routing decision operations. The format conversion module of each container converts the internal JSON message into the protocol format and message format required by each peer system. The security processing module performs the corresponding encryption and signing operations. The outbound processing module independently sends messages, receives responses, and performs reverse parsing through the protocol channels of each container.

[0157] In this embodiment, a globally unique tracking identifier is used throughout the entire chain from request initiation by each interbank system to completion of internal business processing and response feedback. When an anomaly occurs in an interbank agency transaction, the globally unique tracking identifier is used to quickly locate the faulty link in the full-chain log. The dynamic mapping table configures the mapping relationship between the transaction codes of each interbank system and the bank's internal transaction codes. When the interface specification of an interbank system is upgraded, only the mapping table configuration corresponding to that interbank system needs to be updated, without affecting the normal interaction of other interbank systems.

[0158] The scope of protection of this invention is not limited to the specific embodiments described above. Those skilled in the art can make various corresponding changes and modifications based on this invention without departing from its essential spirit and scope, but all such changes and modifications should fall within the protection scope of the appended claims. The above embodiments are only used to illustrate the technical solutions of this invention and are not intended to limit it. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the protection scope of this invention.

Claims

1. A method for heterogeneous system communication and interaction processing based on a unified container, characterized in that, A unified data processing container serves as the sole data carrier across the entire link. The container contains at least a message header field, a business data body, a security context, and routing metadata. The message header field carries the unified transaction identifier and routing addressing information across the entire link. The business data body carries the standardized and transformed business data. The security context manages encryption and decryption policies and states. The routing metadata drives dynamic mapping queries and message queue routing decisions. The methods include inbound interaction processing and outbound interaction processing: Inbound interaction processing involves: identifying the source and target protocol types of external requests and creating container instances, assigning globally unique tracking identifiers and initializing message header fields and routing metadata, and loading the original request message into the container; Perform protocol parsing on the original request message and store the parsed data into the business data body; Decryption is performed according to the target system's security configuration, and the decrypted data is then populated back into the business data body; the data in the business data body is converted into an internal standard format and populated back into the container; The dynamic mapping table is queried based on the transaction code and product code to parse the routing information, the routing results are written into the routing metadata, and the container is sent to the internal business layer through a message queue. Obtain the response data returned by the business layer, perform encryption processing and message format restoration, send the restored response message back to the external system, and destroy the container; Outbound interaction processing is as follows: receiving internal standard messages initiated by the internal business layer and creating container instances, storing the internal standard messages in the business data body; converting the internal standard messages into the protocol and message formats required by the target external system according to the target protocol type; Encryption is performed according to the target system's security configuration; the encrypted final message is extracted and sent to the target external system; after receiving the response message, reverse security parsing and format conversion are performed; the restored standardized response data is sent back to the internal business layer; and the container is destroyed.

2. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, According to claim 1, the heterogeneous system communication interaction processing method based on a unified container is characterized in that, in a complete interaction process, a decryption operation is performed only once at the beginning of the inbound interaction processing process and an encryption operation is performed only once at the beginning of the outbound interaction processing process, and the business data body always remains in plaintext during the internal insecure processing stage. The inbound interaction processing flow refers to the complete processing process executed by the communication platform when an external heterogeneous system initiates a communication interaction with the internal core system, from receiving a self-request to sending a response. The outbound interaction processing flow refers to the complete processing process executed by the communication platform when an internal core system initiates a communication interaction with an external heterogeneous system, from receiving a self-request to sending a response.

3. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, The container is configured with a state machine. The state machine adapts the state transition path according to the processing direction. The state includes at least the created state, the loading state, the transitioning state, the encryption or decryption state, the routing state, the completed state, and the destroyed state.

4. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, The dynamic mapping table is stored in the form of a configuration file and supports dynamic loading. When the mapping relationship changes, the next request thread will use the latest data after the current thread has finished processing.

5. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, The globally unique tracking identifier is used throughout the entire lifecycle. The globally unique tracking identifier is a hexadecimal string, which is composed of two parts: an 11-digit application system number and a 34-digit custom unique identifier.

6. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, It also includes processing for interaction with the Enterprise Service Bus (ESB): receiving request messages sent by the channel end through the ESB, creating a container instance and storing the original ESB message in the business data body, extracting the service number from the message header field and the version number from the business data body, combining the service number and version number to determine the unique interface identifier for accessing the business gateway, querying the data mapping table based on the interface identifier to determine the process type, converting the ESB format message into the unified access format of the target business system according to the process type and sending it to the business gateway, and after receiving the response, reversing it to convert it into an ESB format message and returning it to the channel end.

7. The heterogeneous system communication and interaction processing method based on a unified container according to claim 1, characterized in that, It also includes file interaction processing: creating or reusing containers in the common sub-process of file interaction; the common sub-process of file interaction is used to assemble the request parameters required for file upload or download in the business data body of the container, call the token acquisition service to store the acquired token in the security context, call the file transfer engine to perform file transfer operation according to the request parameters and the token, and write the operation result back to the business data body and flow with the container to the next processing stage; The file transfer request parameters are assembled in the business data body. The request parameters include the local file path, the Minio storage path, and the target FTP / SFTP parameters. The token acquisition service is invoked to store the acquired upload or download token into the security context. The file transfer engine performs operations to upload files to Minio or download them to local storage based on the request parameters and token loaded in the container. The operation results are then written back to the business data body and transferred to the next processing stage along with the container. The file interaction supports batch transfer of multiple files.

8. A heterogeneous system communication and interaction processing system based on a unified container, characterized in that, include: The container management module is used to create, maintain, and destroy unified data processing container instances. A container must contain at least a message header field, a business data body, a security context, and routing metadata. The access processing module is used to receive raw request messages initiated by external heterogeneous systems, create container instances through the container management module and assign globally unique tracking identifiers, load the raw request messages into the container, perform protocol parsing on the raw request messages and store them in the business data body, call the security processing module to perform decryption, send the standardized and converted data to the internal business layer, obtain the response data, call the security processing module to perform encryption and call the format conversion module to perform message format restoration, and send the restored response message back to the external system. The outgoing processing module is used to receive internal standard messages initiated by the internal business layer, create container instances through the container management module and store the internal standard messages in the business data body, call the format conversion module to convert the internal standard messages into the protocol and message formats required by the target external system, call the security processing module to perform encryption and extract the final message and send it to the target external system, and after receiving the response message, call the security processing module to perform reverse security parsing and call the format conversion module to perform format back translation, and send the restored response data back to the internal business layer. The routing decision module is used to maintain a dynamic mapping table. It queries the dynamic mapping table based on the transaction code and product code recorded in the container to parse the routing information and writes the routing results into the container's routing metadata. The security processing module is used to encrypt or decrypt data in the business data body by invoking the corresponding encryption or decryption policy according to the security configuration recorded in the container. The format conversion module is used to convert data in the business data body into internal standard format data or the protocol and message formats required by the target system.

9. The heterogeneous system communication and interaction processing system based on a unified container according to claim 8, characterized in that, Also includes: The ESB interaction module is used to receive request messages sent by the channel end via ESB, create a container instance through the container management module and store the original ESB message in the business data body, extract the service number from the message header field and the version number field from the business data body to determine the unique interface identifier for accessing the business gateway, query the data mapping table based on the unique interface identifier to determine the process type, control the format conversion module to convert the ESB format message into the unified access format of the target business system according to the process type and send it to the business gateway, and control the format conversion module to reverse convert it into an ESB format message and return it to the channel end after receiving the response.

10. The heterogeneous system communication and interaction processing system based on a unified container according to claim 8, characterized in that, Also includes: The file interaction module is used to create or reuse the container through the container management module in the common sub-process of file interaction; The file interaction public sub-process is used to assemble the request parameters required for file upload or download in the business data body of the container, call the token acquisition service to store the acquired token in the security context, call the file transfer engine to perform file transfer operation according to the request parameters and the token, and write the operation result back to the business data body and transfer it to the next processing stage with the container. The system assembles the request parameters required for file upload or download in the business data body. The request parameters include the local file path, Minio storage path, and target FTP / SFTP parameters. The system calls the token acquisition service to store the acquired upload or download token in the security context. The system controls the file transfer engine to perform file upload to Minio or download from Minio to the local machine according to the request parameters and token loaded in the container. The operation results are written back to the business data body and transferred to the next processing stage along with the container. The file interaction supports batch transfer of multiple files.

Images