Message processing method, device, apparatus, medium and program product

Abstract

This application provides a message processing method, apparatus, device, medium, and program product, applied in the fields of big data and distributed technologies. The method includes: in response to a change in message standard from a first standard to a second standard, configuring a proxy entry point with the same protocol and address as an external interface, wherein the external interface is based on the first standard; receiving raw messages conforming to the first standard through the proxy entry point, performing format adaptation and standardization processing on the raw messages to generate standard messages; mapping the standard messages to target messages conforming to the second standard based on predefined mapping rules; routing the target messages from a first link to a second link for processing, wherein the first link is a processing link configured with processing logic of the first standard, and the second link is a processing link configured with processing logic of the second standard; when the processing result of the second link meets the rollback condition, switching the target messages back to the first link, whereby the first link reprocesses them based on the first standard.

Description

Technical Field

[0001] This application relates to the financial field, specifically to the fields of big data and distributed technology, and more specifically to a message processing method, apparatus, device, medium, and program product. Background Technology

[0002] In fields such as finance, payment, and enterprise information system integration, message standards frequently undergo structural changes due to regulatory policy updates, industry rule upgrades, or expansion of business fields. However, existing message upgrade technologies have the following technical drawbacks: First, backend business systems require large-scale modifications to their parsing, assembly, and verification logic, resulting in significant changes and high risks. Second, frontend channels and third-party systems heavily rely on the old message structure, leading to high coupling between frontend and backend modifications, where a change in one part affects the entire system. Third, many automated testing, reconciliation, and batch processing scripts developed based on the old message structure become invalid after the standard upgrade, requiring a complete rewrite and incurring extremely high regression costs. Fourth, upgrades typically involve a full switch and a one-size-fits-all deployment, posing significant risks to production continuity and failing to meet the requirements for 24 / 7 uninterrupted operation. Fifth, multiple upgrades require repeated modifications, lacking a unified reusable architecture and resulting in high long-term maintenance costs. Summary of the Invention

[0003] In view of the above problems, this application provides a message processing method, apparatus, device, medium and program product.

[0004] According to a first aspect of this application, a message processing method is provided, comprising: in response to a change in message standard from a first standard to a second standard, configuring a proxy entry point having the same protocol and address as an external interface, wherein the external interface is based on the first standard; receiving an original message conforming to the first standard through the proxy entry point, and performing format adaptation and standardization processing on the original message to generate a standard message; mapping the standard message to a target message conforming to the second standard based on predefined mapping rules; routing the target message from a first link to a second link for processing based on a grayscale strategy, wherein the first link is a processing link configured with processing logic of the first standard, and the second link is a processing link configured with processing logic of the second standard; and when the processing result of the second link meets a preset rollback condition, switching the target message to the first link, and having the first link reprocess it based on the first standard.

[0005] According to an embodiment of this application, the method further includes: when the processing result of the second link does not meet the rollback condition, returning the processing result to the caller through the proxy entry; wherein the processing result is one of the following: a first processing result generated by the second link that conforms to the second standard; or a second processing result that conforms to the first standard obtained by re-encapsulating the first processing result according to the first standard through the proxy entry.

[0006] According to an embodiment of this application, a target packet is routed from a first link to a second link for processing based on a grayscale strategy, including: determining whether the target packet meets the grayscale conditions according to the grayscale strategy; when the grayscale conditions are met, routing the target packet from the first link to the second link; and when the grayscale conditions are not met, maintaining the processing of the target packet on the first link.

[0007] According to an embodiment of this application, the original message is subjected to format adaptation and standardization processing to generate a standard message, including: identifying the script type of the original message; adapting the original message to a format according to the message characteristics corresponding to the script type; and standardizing the adapted original message to generate a standard message.

[0008] According to an embodiment of this application, the adapted original message is standardized to generate a standard message, including: reading the original message segment by segment based on a preset segment boundary, parsing the read segment to obtain the parsing result of each segment; and asynchronously reassembling the parsing results of each segment to generate a standard message.

[0009] According to an embodiment of this application, a standard message is mapped to a target message conforming to a second standard based on a predefined mapping rule, including: parsing the mapping rule to generate an abstract syntax tree corresponding to the mapping rule; and performing a conversion operation on the standard message based on the abstract syntax tree to obtain the target message.

[0010] According to an embodiment of this application, before routing the target packet from the first link to the second link for processing based on a grayscale strategy, the method further includes: performing compliance verification on the target packet; and generating an error message and terminating subsequent processing of the target packet when the verification fails.

[0011] A second aspect of this application provides a message processing apparatus, comprising: a configuration module, configured to configure a proxy entry with the same protocol and address as an external interface in response to a change in message standard from a first standard to a second standard, wherein the external interface is based on the first standard; a processing module, configured to receive raw messages conforming to the first standard through the proxy entry, and perform format adaptation and standardization processing on the raw messages to generate standard messages; a mapping module, configured to map the standard messages to target messages conforming to the second standard based on predefined mapping rules; a routing module, configured to route the target messages from a first link to a second link for processing based on a grayscale strategy, wherein the first link is a processing link configured with processing logic of the first standard, and the second link is a processing link configured with processing logic of the second standard; and a switching module, configured to switch the target messages to the first link when the processing result of the second link meets a preset rollback condition, and have the first link reprocess the messages based on the first standard.

[0012] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0013] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0014] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0015] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 This diagram illustrates an application scenario of the message processing method according to an embodiment of this application.

[0017] Figure 2 A flowchart illustrating a message processing method according to an embodiment of this application is shown schematically.

[0018] Figure 3 This illustration schematically shows a flowchart of the process of routing a target packet from a first link to a second link according to an embodiment of this application;

[0019] Figure 4 This schematically illustrates a structural block diagram of a message processing apparatus according to embodiments of this application; and

[0020] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a message processing method according to an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0023] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0024] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0025] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0026] In financial transaction systems, business scenarios such as cross-border clearing, payment settlement, interbank transactions, batch reconciliation, clearing organization interaction, and regulatory reporting all rely on standardized messages for data exchange. However, driven by factors such as updated regulatory policies, upgraded clearing organization rules, unified data standards, and expanded business fields, message standards frequently undergo structural changes. These changes manifest as the addition or removal of fields, adjustments to their positions, changes in length, changes in encoding formats, conversions in data types, reconstruction of verification rules, adjustments to nesting levels, additions or removals of repeated segments, and changes to required or optional attributes. These changes directly affect the underlying logic of message parsing, assembly, and verification, posing a continuous challenge to the stable operation of core transaction links.

[0027] Currently, message standard upgrades generally face the following technical drawbacks. First, the comprehensive changes to message format, fields, structure, and verification rules force backend business systems to undergo large-scale modifications to their parsing, assembly, and verification logic. These modifications are extensive, high-risk, and difficult to validate, easily leading to production failures. Second, frontend channels, counter systems, open interfaces, and third-party integration systems all heavily rely on the old message structure. Interface input parameters, output parameters, field mappings, and return code rules all need to be redeveloped, resulting in extremely high coupling between frontend and backend modifications—a change in one part affects the whole system. Third, automated test scripts, reconciliation scripts, end-of-day batch processing scripts, and data extraction scripts are all developed based on the old message structure. Once the message standard is upgraded, all of these become invalid, requiring a complete rewrite and full regression testing, severely impacting production efficiency and testing quality. Fourth, existing upgrade methods mostly adopt a full switchover and one-size-fits-all deployment model, lacking a gray-scale mechanism, dual-track operation capability, and a unified adaptation layer. Once an anomaly occurs, it is impossible to quickly roll back, resulting in extremely high production continuity risks and making it difficult to meet the stringent requirements of financial institutions for the 24 / 7 uninterrupted operation of core systems. Fifth, message standards require repeated modifications when upgraded multiple times, lacking a unified and reusable architectural support, leading to persistently high long-term maintenance costs.

[0028] In addition, the currently available message processing technologies are mostly limited to traditional methods such as single-point format conversion, hard-coded mapping, interface pass-through, or static configuration. They do not yet possess key capabilities such as zero modification of business systems, zero modification of scripts, dual-track operation, gray-scale routing, and one-click rollback, resulting in significant technological gaps.

[0029] In view of this, embodiments of this application provide a message processing method, apparatus, device, medium, and program product that can be applied to message transformation scenarios with high security, high continuity, and strong regulatory compliance requirements, such as cross-border clearing, payment settlement, interbank messages, batch reconciliation, clearing organization interaction, and regulatory reporting, to achieve seamless switching between old and new message standards, dual-track parallel operation, and one-click rollback.

[0030] Figure 1 The diagram illustrates an application scenario of the message processing method according to an embodiment of this application.

[0031] like Figure 1As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, an external caller may use the first terminal device 101 and the second terminal device 102 to interact with the server 105 and / or the database 103 through the network 104 to send messages or receive processing results.

[0032] The first terminal device 101 and the second terminal device 102 can be various systems that call message processing services, including but not limited to: front-end channel systems, counter systems, open interfaces, third-party docking systems, automated test script execution environments, reconciliation script execution environments, end-of-day batch processing script execution environments, data extraction script execution environments, etc. These external systems can interact with the server 105 by relying on the message structure that conforms to the first standard (old standard).

[0033] Server 105 can be a server that provides message processing services, such as a business server that performs protocol stripping, structured parsing, standard mapping, canary routing, and rollback processing on received raw messages. The server can analyze, transform, and forward received messages, and feed the processing results back to external systems. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and basic cloud computing services such as big data.

[0034] Database 103 is a professional storage system for storing and managing data. It can store and manage various types of data related to message processing, such as predefined mapping rules (used to map standard messages to target messages conforming to a second standard), gray-scale policy configurations (such as traffic ratio routing, caller identifier routing, etc.), rollback condition configurations, and script compatibility adaptation rules (field position mapping, message structure simulation, output format fixing, etc.). It supports structured, semi-structured, or unstructured data storage and has management capabilities such as data creation, deletion, modification, querying, backup, and recovery. In this application scenario, database 103 can be connected to server 105 via a communication link. Server 104 can retrieve the required data from database 103 for processing according to requests from external systems. It can also synchronously store new data generated by the operations of the first terminal device 101 and the second terminal device 102 into database 103, thereby achieving data persistence and efficient retrieval.

[0035] It should be noted that the message processing method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-102. Accordingly, the message processing device provided in this application embodiment can generally be disposed in server 105 and / or terminal devices 101-102.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0037] It should be noted that the message processing method and apparatus of this application can be used in the field of software engineering automation testing in the financial technology field, and can also be used in any field other than the financial technology field. The application field of the message processing method and apparatus of this application is not limited.

[0038] The following will be based on Figure 1 The described scene, through Figure 2 and Figure 3 The message processing method according to the embodiments of this application will be described in detail.

[0039] Figure 2 A flowchart illustrating a message processing method according to an embodiment of this application is shown schematically.

[0040] like Figure 2 As shown, the message processing method 200 according to the embodiments of this application may include steps S210 to S250.

[0041] In step S210, in response to the message standard being changed from the first standard to the second standard, a proxy entry with the same protocol and address as the external interface is configured, wherein the external interface is based on the first standard.

[0042] A message standard refers to a set of specifications for messages at the data organization level, including but not limited to one or more of the following: message format, field definition, field order, field length, field type, delimiter, encoding format, message structure framework, and verification rules. Changes to message standards can be adjustments to any one or a combination of the above specifications.

[0043] The proxy entry point serves as a unified access layer for all channels, systems, and scripts, and is the core mechanism for achieving zero modification, zero code change, and zero configuration adjustment of front-end business systems. Through technologies such as dynamic proxies, bytecode enhancement, script semantic parsing, and protocol encapsulation, it ensures that external callers, internal business systems, automated scripts, and batch processing scripts are completely unaware of message standard upgrades, without requiring any modification to interface definitions, call logic, dependency reading, or script code.

[0044] In some exemplary embodiments, a virtual access point, completely identical to the old interface at the protocol and network layers, can be constructed as a proxy entry point based on the interface definition of the original old message standard (i.e., the first standard). This is based on the communication protocol and network address of the original old interface, using dynamic bytecode enhancement technology and an interface mirroring generation mechanism. This entry point can provide unified access capabilities for multiple protocols without changing the original access path, request method, message header fields, input parameter positions, output parameter structure, status code, error code, timeout policy, and encryption rules. In other words, the old interface is still provided externally, and external callers can only access and perceive the old interface; the new interface is only used internally within the system. The proxy entry point can shield all differences between the old and new message standards and the underlying conversion logic, allowing front-end channels, counter systems, open platforms, third-party institutions, and automated scripts to directly access the system without adjusting any configuration or call paths, thereby achieving true access layer transparency.

[0045] In step S220, the original message conforming to the first standard is received through the proxy entry, and the original message is processed for format adaptation and standardization to generate a standard message.

[0046] The original messages can originate from various business channels or calling systems. For example, the original messages can come from front-end counter systems, electronic channels such as online banking or mobile banking, open platforms or application programming interfaces (APIs), third-party partner systems, automated test scripts, end-of-day batch reconciliation scripts, data extraction or processing scripts, and even clearing organization or regulatory agency systems. The proxy entry point does not restrict the source of the messages and provides unified compatibility access capabilities for various channels and scripts.

[0047] Upon receiving the raw message, the proxy entry point does not directly forward it to the backend business logic. Instead, it first sends it to an internal standardized processing stage. This stage performs operations such as format adaptation, protocol stripping, and content extraction on raw messages that follow different communication protocols and have different formats, converting them into standard messages that the system can recognize and manipulate internally. For example, fixed-length messages and delimited messages carried by different protocols can be uniformly encapsulated into internal abstract objects with the same data structure.

[0048] In other embodiments, the proxy entry point can also receive messages conforming to a second standard. For example, during the transition period of message standard upgrades, some front-end systems or third-party organizations that have completed adaptation may already support directly sending messages conforming to the second standard. For such messages, the proxy entry point can identify their standard version and process them according to a preset strategy. Specifically, if the message already conforms to the second standard, format adaptation and standardization processing can be bypassed, or only necessary protocol stripping can be performed before directly sending it to the second link for processing. Through the above-mentioned bidirectional compatible access mechanism, caller systems at different stages of transformation can be served simultaneously, further improving the flexibility and smoothness of message standard upgrades.

[0049] In step S230, based on predefined mapping rules, the standard message is mapped to a target message that conforms to the second standard.

[0050] After obtaining the standard message, a bidirectional automatic conversion from the first standard to the second standard can be performed according to predefined mapping rules. The mapping rules can be established based on the structured definition of the message standard's metadata. The metadata can uniformly describe structured attributes such as message version, business type, transaction code, protocol type, field name, data type, length limit, hierarchical path, nesting relationship, repetition count, required or optional attributes, enumerated value range, encoding format, and padding rules, thereby ensuring compatibility with multiple message types.

[0051] In step S240, based on the grayscale strategy, the target packet is routed from the first link to the second link for processing, wherein the first link is a processing link configured with the first standard processing logic, and the second link is a processing link configured with the second standard processing logic.

[0052] Based on a pre-defined canary deployment strategy, generated target packets can be routed in a refined manner, rather than being switched entirely to the second processing link. The canary deployment strategy supports multi-dimensional traffic segmentation, such as combined routing based on transaction codes, institution IDs, channel types, currencies, amount ranges, customer IDs, date and time, serial number ranges, and regional dimensions. It also supports smooth switching of traffic according to a preset proportion. Canary deployment rules take effect in real time without requiring a service restart, thus achieving secure, controllable, and gradual standard upgrades.

[0053] It should be noted that the first and second links are completely isolated in terms of resources, threads, statistics, and status, and do not interfere with each other. The first link is configured with the processing logic corresponding to the first standard, i.e., the parsing, verification, routing, and business processing flow designed based on the message format and business rules of the first standard; the second link is configured with the processing logic corresponding to the second standard, i.e., the parsing, verification, routing, and business processing flow designed based on the message format and business rules of the second standard. Both links can operate simultaneously. Gray-scale traffic enters the second link and completes full-link processing according to the new standard, while non-gray-scale traffic remains on the first link and completes full-link processing according to the old standard. This provides operations and decision-making personnel with a stable data comparison and observation window, thus achieving a dual-track upgrade.

[0054] In step S250, when the processing result of the second link meets the preset rollback conditions, the target message is switched to the first link and reprocessed by the first link based on the first standard.

[0055] During dual-track operation, the system can monitor the operational status of the second link in real time. Monitoring metrics include, but are not limited to, conversion power, transaction success rate, abnormal packet ratio, response time, and error rate. When any metric exceeds a preset threshold, i.e., the rollback condition is met, the system can automatically trigger the gray-scale circuit breaker and full rollback mechanism, instantly switching all or part of the gray-scale traffic back to the first link. The rollback process only requires switching routing rules and metadata version pointers; it does not require restarting the service, releasing a new version, or affecting business operations. Traffic can be instantly restored to the first link, which then reprocesses the target packets based on the first standard, thereby significantly reducing deployment risks.

[0056] When the processing result of the second link meets the preset rollback conditions, the target packet can be reverse-mapped back to a format conforming to the first standard using mapping rules, and then the reverse-mapped packet can be switched to the first link for reprocessing based on the first standard. Alternatively, the first link can, upon receiving the target packet, invoke its internal mapping and conversion capabilities to perform reverse adaptation before processing.

[0057] In other exemplary embodiments, strict access control can be implemented for operations such as grayscale adjustments, rollbacks, metadata publication, and rule modifications. Specifically, a fine-grained access control model can be adopted to assign differentiated operation permissions to different users or roles. All operations can be recorded, including the operator, operation time, internet protocol address from which the operation originated, operation content, and operation result, forming an immutable operation log to meet the internal control and audit requirements of the financial system and ensure operational security and traceability.

[0058] For example, a bank's core transaction system needs to upgrade its message standard from the first standard to the second standard. First, the system dynamically builds a completely consistent proxy entry point on the existing old standard interface address, maintaining the old interface's communication protocol, access path, and input / output parameter structure externally. Callers such as the counter system, online banking, and third-party payment institutions continue to send transaction request messages conforming to the old standard in the original way. After receiving the messages, the proxy entry point performs protocol stripping and unified encapsulation on various raw messages, generating internally standardized message abstract objects. Then, based on field mapping rules, the system converts the standard messages into target messages conforming to the second standard, completing operations such as field reorganization, type conversion, and nested structure adjustment. Next, based on a canary strategy, 10% of cross-border payment transaction traffic is routed to the second link configured with the new standard processing logic, based on the institution number and transaction type. The remaining traffic remains on the first link of the old standard. The two links operate in parallel with complete isolation in terms of resources, threads, and states. During dual-track operation, the system monitors the transaction success rate and response time of the second link in real time. When the transaction success rate of the second link is found to be lower than the preset threshold, the circuit breaker mechanism is automatically triggered, and the gray-scale traffic is switched back to the first link for reprocessing according to the old standard to ensure that cross-border payment business is not interrupted. At the same time, an alarm is generated to notify the operation and maintenance personnel to investigate the problem of the new standard link.

[0059] Understandably, by building a unified proxy entry point, the access layer becomes transparent, allowing external callers to upgrade message standards without modifying any interface definitions or calling logic. Simultaneously, through format adaptation and standardization, messages of different protocols and formats are uniformly converted into internal standard messages, shielding the differences in underlying protocols. Automatic circuit breaking and one-click rollback mechanisms instantly restore traffic to the old link for reprocessing when the new standard link fails, fundamentally ensuring business continuity and production stability. Furthermore, the unified adaptation layer architecture allows for one-time deployment to adapt to all future message standard upgrades without repeated modifications, significantly reducing long-term maintenance costs and project risks. The entire process is loosely coupled and pluggable, supporting horizontal scaling and multi-business line reuse, making it widely applicable to bank-wide message standardization transformation scenarios in financial institutions.

[0060] Based on the above embodiments, in this embodiment, the original message is format adapted and standardized to generate a standard message, including: identifying the script type of the original message; adapting the original message to the format according to the message characteristics corresponding to the script type; and standardizing the adapted original message to generate a standard message.

[0061] The script types in the raw messages can include automated test scripts, reconciliation scripts, end-of-day batch processing scripts, data extraction scripts, etc. Since different types of scripts have different dependencies on characteristics such as message field names, offsets, delimiters, message lengths, and field order, accurately identifying the script type can provide a basis for subsequent format adaptation.

[0062] For the identified script type, the original message format can be adapted based on its corresponding message characteristics. Specifically, a script semantic seamless adaptation engine can perform deep adaptation on features such as fixed field names, fixed offsets, fixed delimiters, fixed message lengths, and fixed field orders that the script depends on. This engine can use techniques such as field position shadow mapping, old message structure simulation, and output format solidification to ensure that the field values, formats, delimiters, padding methods, and filling rules read by the script are completely consistent with those before the upgrade, thus eliminating the need to modify the script source code or redevelop or rewrite the script.

[0063] After format adaptation is completed, the adapted raw messages can be standardized to generate standard messages. Standardization can convert raw messages of different formats into message formats that conform to the new standard, thereby providing a unified input for subsequent request forwarding and protocol encapsulation.

[0064] Understandably, by identifying script types and adapting formats based on message characteristics, the problem of batch script failures caused by changes in message structure can be effectively solved, significantly reducing regression costs and production risks.

[0065] Based on the above embodiments, in this embodiment, the adapted original message is standardized to generate a standard message, including: reading the original message segment by segment based on the preset message segment boundaries, parsing the read message segments to obtain the parsing results of each message segment; and asynchronously reassembling the parsing results of each message segment to generate a standard message.

[0066] The adapted original message can be read segment by segment based on preset segment boundaries. These preset segment boundaries can be configured according to message format characteristics, such as dividing the message by fixed length, delimiters, or specific markers. This segment-by-segment reading method effectively avoids loading the entire message into memory at once, thus reducing memory usage risks.

[0067] In some exemplary embodiments, standardization processing may include protocol stripping and structured parsing of the read message segments. Specifically, for each message segment read, protocol stripping is first performed to remove communication protocol header information such as Transmission Control Protocol (TCP), Internet Protocol (IP), and Hypertext Transfer Protocol (HTTP) to extract the clean service payload data. Then, the stripped service message segment can be structuredly parsed to extract specific field information according to a predefined message format (such as fixed-length format, delimiter format, or markup language format). The entire parsing process does not require waiting for the entire message to be read; it can be processed segment by segment using a streaming parsing method to finally obtain the parsing results of each message segment.

[0068] After each segment is parsed, the parsing results can be asynchronously reassembled to generate a standard message. Asynchronous reassembly means that the merging process of the parsing results is independent of the parsing process. Merging can be performed after all segments have been parsed, or it can be done while parsing. Through asynchronous reassembly, the system can assemble the parsing results from different segments into a complete standard message according to the original order or business logic, ultimately converting it into a unified message abstraction object within the system.

[0069] Understandably, by reading segment by segment and reassembling asynchronously, the system can complete the standardized processing of messages without loading the entire message. This not only provides a unified message abstraction object for the system but also effectively avoids memory overflow and performance loss.

[0070] Based on the above embodiments, in this embodiment, a standard message is mapped to a target message that conforms to a second standard based on a predefined mapping rule, including: parsing the mapping rule to generate an abstract syntax tree corresponding to the mapping rule; and performing a conversion operation on the standard message based on the abstract syntax tree to obtain the target message.

[0071] In some exemplary embodiments, the mapping relationship between new and old fields can be configured through a visual interface. The mapping types can include one-to-one mapping, one-to-many splitting, many-to-one aggregation, constant filling, conditional assignment, format conversion, encoding conversion, field desensitization, combined field splitting, and automatic filling of default values. After configuration, the above mapping rules can be converted into an abstract syntax tree structure for structured storage and then downloaded to the bidirectional mapping execution engine.

[0072] Abstract Syntax Trees (ABSTs) are a data organization form that represents mapping logic in a tree structure. Each node represents a mapping operation (such as field reading, type conversion, conditional judgment, etc.), and leaf nodes represent specific fields or constant values. Through ABSTs, the system can decompose complex mapping rules into executable basic operation units, thereby achieving the separation of conversion logic from business code.

[0073] Based on abstract syntax trees (ASTs), the bidirectional mapping execution engine can perform transformation operations on standard messages to obtain target messages. Specifically, the engine can load the AST corresponding to the mapping rules and use the AST executor to complete the automatic conversion from the first standard to the second standard (or from the second standard to the first standard). The engine supports the following transformation capabilities, including but not limited to: field position adjustment (changing the order of fields in the message); nested structure reconstruction (converting a flattened field structure into a nested object structure, or flattening a nested structure); repeating segment alignment (handling the mapping of array or loop fields between different standards); data type conversion (converting string types to numeric or date types); encoding conversion (converting between different character encodings); length padding or truncation (padding characters on the left or right or truncating excess parts when the field length does not meet the target standard requirements); enumeration mapping (mapping enumeration values ​​in the old standard to corresponding enumeration values ​​in the new standard); conditional logic judgment (determining the mapping method of the target field based on the value of a certain field in the original message); and default value filling (filling the target field with a preset default value when the corresponding field in the original message is missing or invalid).

[0074] In some exemplary embodiments, the system can also implement multi-version parallel management, creating an independent and complete metadata storage instance for each message standard version, and realizing full lifecycle management of version creation, editing, pre-verification, publication, freezing, canary activation, full activation, expiration and invalidation, and version rollback. Simultaneously, a lock-free dual-caching hot-switching mechanism can be adopted to allow metadata changes to be asynchronously loaded into the backup cache for pre-verification, pre-compilation, and rule preheating. After successful verification, the cache pointer is atomically switched, making the new rules take effect instantly without affecting business traffic, interrupting transactions, or causing system anomalies.

[0075] In other embodiments, message-level lock-free parallel conversion technology can be employed to convert multiple messages simultaneously without waiting for lock release, thus significantly improving conversion efficiency in batch message and high-concurrency transaction scenarios. Simultaneously, local rule caching technology can be used to store frequently used mapping rules, verification rules, etc., in a high-speed cache, avoiding repeated loading and reducing input / output overhead. Furthermore, the system can employ structural fingerprint reuse technology to generate a unique structural fingerprint for recurring message structures. When a message with the same fingerprint is encountered again, the previous conversion path and mapping result can be directly reused, avoiding repeated traversal of the abstract syntax tree, thereby significantly reducing the consumption of the central processing unit and memory.

[0076] It is understandable that by generating an abstract syntax tree and performing mapping transformations based on the abstract syntax tree, it is possible to achieve universal adaptation to any changes in message structure, rather than single-point conversion of fixed formats and fixed fields.

[0077] In the embodiments of this application, before routing the target packet from the first link to the second link for processing based on the grayscale strategy, the method further includes: performing compliance verification on the target packet; and generating error information and terminating subsequent processing of the target packet when the verification fails.

[0078] Compliance validation can include various validation types. Specifically, format validation can be used to check whether the overall structure of the target message conforms to the format requirements of the second standard, such as whether the message header is correct, whether the field separators are as expected, and whether the nesting level is complete. Length validation can be used to check whether the length of each field in the message meets the length limits of the second standard, including exact matching of fixed-length fields and maximum and minimum length constraints for variable-length fields. Value range validation can be used to check whether the value of a field is within a predefined enumerated value range, such as whether the transaction type code is a legal value defined in the standard. Association validation can be used to check whether the logical dependency relationship between multiple fields is valid, such as whether another field must exist or must take a specific value when one field takes a specific value. Business rule validation can be used to check whether the message conforms to business-level constraints, such as whether the transaction amount is within the allowed range, and whether the loan / debit flag is consistent with the positive or negative sign of the amount. Field dependency validation can be used to check the existence dependency relationship between fields, such as whether another field must appear simultaneously when one field appears.

[0079] In some exemplary embodiments, the system can load the aforementioned validation rules from the metadata device. The metadata device can uniformly store the format specifications, length limits, value range definitions, association rules, business rules, and field dependency rules corresponding to the second standard.

[0080] When validation fails, an error message can be generated and subsequent processing of the target message can be terminated. The error message can include a standardized exception code and error description to identify the specific type of validation failure, the location of the failed field, and the reason for the failure. By terminating subsequent processing, non-compliant exception messages can be prevented from entering the backend core system, thereby improving data accuracy and system security.

[0081] In some exemplary embodiments, a dynamic validation model can also be introduced to automatically optimize the validation rule set by monitoring anomalies (such as missing fields, format errors, etc.) during the conversion process in real time. Specifically, the anomaly handling process can be modeled as a decision optimization process, using the anomaly resolution rate and processing latency as reward signals, enabling the validation rules to evolve autonomously with business changes, adaptively adjusting validation thresholds and rule weights, and reducing the cost of manual intervention.

[0082] After the compliance verification is completed and passed, the routing operation based on the gray-scale policy can continue to be executed, and the target packet can be routed from the first link to the second link for processing.

[0083] Understandably, by performing full compliance checks on target packets before routing, and promptly terminating processing and generating error messages when checks fail, it is possible to effectively prevent abnormal packets from entering the backend core system, thereby ensuring the accuracy of business data and the security of system operation.

[0084] Figure 3 The illustration shows a flowchart of routing a target message from a first link to a second link according to an embodiment of this application.

[0085] like Figure 3 As shown, based on the above embodiments, in this embodiment, the method 300 for routing target packets from the first link to the second link for processing based on a grayscale strategy may include steps S310 to S330.

[0086] In step S310, it is determined whether the target message meets the grayscale conditions according to the grayscale strategy.

[0087] In step S320, when the grayscale condition is met, the target packet is routed from the first link to the second link.

[0088] In step S330, when the grayscale condition is not met, the target message is maintained for processing on the first link.

[0089] The canary deployment strategy supports multi-dimensional traffic segmentation. Specifically, the system can perform combined routing based on dimensions such as transaction code, institution ID, channel type, currency, amount range, customer ID, Internet Protocol address range, date and time, serial number range, and region to determine whether a target packet meets the canary deployment conditions. For example, packets from a specific institution or channel with transaction amounts within a preset range can be identified as meeting the canary deployment conditions and routed to the second link. Furthermore, the system supports proportional canary deployment switching, such as gradually switching 1%, 5%, 10%, 50%, up to 100% of traffic to the second link. Canary deployment rules take effect in real time without requiring service restarts, thus enabling secure, controllable, and gradual standard upgrades.

[0090] When a target packet meets the grayscale criteria, it can be routed from the first link to the second link for processing. When a target packet does not meet the grayscale criteria, it can remain processed on the first link. Through this mechanism, grayscale traffic can enter the second link to complete full-link processing according to the new standard, while non-grayscale traffic can remain on the first link to complete full-link processing according to the old standard. The two links are completely independent in terms of resource isolation, thread isolation, statistical isolation, and state isolation, and do not interfere with each other. This achieves a dual-track upgrade, allowing for real-time monitoring of the stability of the new standard link and providing stable data support for production deployment decisions.

[0091] Understandably, through a multi-dimensional gray-scale strategy and a dual-track parallel operation mechanism, the system can achieve safe, controllable, and gradual traffic switching during the message standard upgrade process.

[0092] In embodiments of this application, the method further includes: when the processing result of the second link does not meet the rollback condition, returning the processing result to the caller through the proxy entry; wherein the processing result is one of the following: a first processing result generated by the second link that conforms to the second standard; or a second processing result that conforms to the first standard obtained by re-encapsulating the first processing result according to the first standard through the proxy entry.

[0093] Once the target message is routed to the second link and processed according to the second standard, the second link can produce a first processing result that conforms to the second standard. At this point, the system can decide which format of processing result to return based on the actual needs of the caller.

[0094] For callers that have completed the adaptation and can directly process the second standard messages, the first processing result generated by the second link and conforming to the second standard can be directly returned to the caller without additional format conversion.

[0095] For callers that have not yet completed adaptation and can still only process messages according to the first standard (such as existing automated scripts, batch scripts, or front-end systems that have not yet been upgraded), the system can repackage the first processing result through a proxy entry point, converting it into a second processing result that conforms to the first standard. The repackaging process may include, but is not limited to: header concatenation (reconstructing the response header according to the protocol format of the first standard); field padding (left or right padding according to the field length requirements of the first standard); length calculation (recalculating the length of each field and the overall message and filling it into the corresponding positions); checksum generation (regenerating the checksum according to the checksum algorithm of the first standard); encoding format conversion (converting the encoding format of the response content from the encoding required by the second standard to the encoding required by the first standard); and encryption rule restoration (encrypting the response content according to the encryption rules of the first standard). Through the above repackaging operations, the response message format returned to the caller can be completely consistent with that before the upgrade, thus achieving seamless output to the outside world.

[0096] In some exemplary embodiments, compatibility checks can also be performed on the old standard response messages returned to the caller to ensure that the front-end channel and script can read them correctly. Compatibility checks may include format checks, field integrity checks, encoding checks, etc., to ensure that the repackaged response messages fully comply with the specifications of the first standard.

[0097] Understandably, after the second link is successfully processed, the system can flexibly choose to return the original new standard response or the repackaged old standard response based on the caller's level of adaptation. This not only supports upgraded callers to directly connect to the new standard, but also ensures the seamless operation of existing scripts and front-end systems that have not been upgraded, thereby achieving external compatibility and a smooth transition during the message standard upgrade process.

[0098] Based on the above message processing method, this application also provides a message processing apparatus. The following will be combined with... Figure 4 The device is described in detail.

[0099] Figure 4 A schematic block diagram of a message processing apparatus according to an embodiment of this application is shown.

[0100] like Figure 4 As shown, the message processing device 400 in this embodiment includes a configuration module 410, a processing module 420, a mapping module 430, a routing module 440, and a switching module 450.

[0101] The configuration module 410 is used to configure a proxy entry point with the same protocol and address as the external interface in response to a change in the message standard from the first standard to the second standard, wherein the external interface is based on the first standard. In one embodiment, the configuration module 410 can be used to perform step S210 described above, which will not be repeated here.

[0102] The processing module 420 is used to receive raw messages conforming to the first standard through the proxy entry point, and to perform format adaptation and standardization processing on the raw messages to generate standard messages. In one embodiment, the processing module 420 can be used to execute the step S220 described above, which will not be repeated here.

[0103] The mapping module 430 is used to map standard packets to target packets conforming to a second standard based on predefined mapping rules. In one embodiment, the mapping module 430 can be used to perform step S230 described above, which will not be repeated here.

[0104] The routing module 440 is used to route target packets from the first link to the second link for processing based on a gray-scale strategy. The first link is a processing link configured with a first standard processing logic, and the second link is a processing link configured with a second standard processing logic. In one embodiment, the routing module 440 can be used to execute step S240 described above, which will not be repeated here.

[0105] The switching module 450 is used to switch the target packet to the first link when the processing result of the second link meets the preset rollback conditions, so that the first link can reprocess it based on the first standard. In one embodiment, the switching module 450 can be used to execute the step S250 described above, which will not be repeated here.

[0106] According to an embodiment of this application, the switching module 450 can also be used to: return the processing result to the caller through the proxy entry when the processing result of the second link does not meet the rollback condition; wherein the processing result is one of the following: a first processing result generated by the second link that conforms to the second standard; or a second processing result that conforms to the first standard obtained by re-encapsulating the first processing result according to the first standard through the proxy entry.

[0107] According to an embodiment of this application, the routing module 440 can be specifically used to: determine whether the target packet meets the grayscale conditions according to the grayscale policy; when the grayscale conditions are met, route the target packet from the first link to the second link; and when the grayscale conditions are not met, maintain the processing of the target packet on the first link.

[0108] According to an embodiment of this application, the processing module 420 can be specifically used to: identify the script type of the original message; adapt the format of the original message according to the message characteristics corresponding to the script type; and standardize the adapted original message to generate a standard message.

[0109] According to an embodiment of this application, the processing module 420 can be specifically used to: read the original message segment by segment based on a preset message segment boundary, parse the read message segments to obtain the parsing results of each message segment; and asynchronously reassemble the parsing results of each message segment to generate a standard message.

[0110] According to an embodiment of this application, the mapping module 430 can be specifically used to: parse the mapping rules, generate an abstract syntax tree corresponding to the mapping rules; and perform a conversion operation on the standard message based on the abstract syntax tree to obtain the target message.

[0111] According to an embodiment of this application, the routing module 440 can also be used to: perform compliance verification on the target packet; and when the verification fails, generate an error message and terminate the subsequent processing of the target packet.

[0112] According to embodiments of this application, any multiple modules among the configuration module 410, processing module 420, mapping module 430, routing module 440, and switching module 450 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the configuration module 410, processing module 420, mapping module 430, routing module 440, and switching module 450 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the configuration module 410, processing module 420, mapping module 430, routing module 440, and switching module 450 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0113] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a message processing method according to an embodiment of this application.

[0114] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory 502 or a program loaded from a storage portion 508 into a random access memory 503. The processor 501 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0115] Random access memory 503 stores various programs and data required for the operation of electronic device 500. Processor 501, read-only memory 502, and random access memory 503 are interconnected via bus 504. Processor 501 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 502 and / or random access memory 503. It should be noted that programs may also be stored in one or more memories other than read-only memory 502 and random access memory 503. Processor 501 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0116] According to embodiments of this application, the electronic device 500 may further include an input / output interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card, such as a local area network card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0117] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0118] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 502, and / or random access memory 503, and / or one or more memories other than read-only memory 502 and random access memory 503 described above.

[0119] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0120] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0121] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0122] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method of processing a packet, the method comprising: include: In response to the change of message standard from the first standard to the second standard, a proxy entry with the same protocol and address as the external interface is configured, wherein the external interface is based on the first standard; The proxy entry receives raw messages conforming to the first standard, performs format adaptation and standardization processing on the raw messages, and generates standard messages. Based on predefined mapping rules, the standard message is mapped to a target message that conforms to the second standard; Based on a gray-scale strategy, the target packet is routed from the first link to the second link for processing, wherein the first link is a processing link configured with the first standard processing logic, and the second link is a processing link configured with the second standard processing logic; and When the processing result of the second link meets the preset rollback conditions, the target message is switched to the first link, and the first link reprocesses it based on the first standard.

2. The method of claim 1, wherein, The method further includes: When the processing result of the second link does not meet the rollback condition, the processing result is returned to the caller through the proxy entry point; The processing result is one of the following: The second link generates a first processing result that conforms to the second standard; or The second processing result, which conforms to the first standard, is obtained by repackaging the first processing result through the proxy entry according to the first standard.

3. The method of claim 1, wherein, The gray-scale strategy-based routing of the target packet from the first link to the second link for processing includes: Based on the grayscale strategy, determine whether the target message meets the grayscale conditions; When the grayscale condition is met, the target packet is routed from the first link to the second link; and When the grayscale condition is not met, the target message is maintained in the first link for processing.

4. The method of claim 1, wherein, The step of performing format adaptation and standardization processing on the original message to generate a standard message includes: Identify the script type of the original message; Based on the message characteristics corresponding to the script type, the original message is format-adapted; and The adapted original message is standardized to generate a standard message.

5. The method of claim 4, wherein, The standardization process for the adapted original message to generate a standard message includes: The original message is read segment by segment based on preset segment boundaries, and the read segments are parsed to obtain the parsing results of each segment; and The parsing results of each segment are asynchronously reassembled to generate the standard message.

6. The method of claim 1, 4 or 5, wherein, The mapping of the standard message to a target message conforming to the second standard based on predefined mapping rules includes: Parse the mapping rules to generate an abstract syntax tree corresponding to the mapping rules; and Based on the abstract syntax tree, a transformation operation is performed on the standard message to obtain the target message.

7. The method according to claim 1 or 3, characterized in that, Before routing the target packet from the first link to the second link for processing based on the grayscale strategy, the process further includes: Perform compliance verification on the target message; and If the verification fails, an error message is generated and subsequent processing of the target message is terminated.

8. A packet processing device, characterized by, include: A configuration module is used to configure a proxy entry with the same protocol and address as the external interface in response to a change in the message standard from a first standard to a second standard, wherein the external interface is based on the first standard; The processing module is used to receive raw messages conforming to the first standard through the proxy entry, and to perform format adaptation and standardization processing on the raw messages to generate standard messages. The mapping module is used to map the standard message into a target message that conforms to the second standard based on predefined mapping rules; A routing module is used to route the target packet from a first link to a second link for processing based on a gray-scale strategy, wherein the first link is a processing link configured with the first standard processing logic, and the second link is a processing link configured with the second standard processing logic; and The switching module is used to switch the target packet to the first link when the processing result of the second link meets the preset rollback conditions, so that the first link can reprocess it based on the first standard.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer readable storage medium having stored thereon a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product comprising computer programs or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images