Bill message processing method and device, electronic equipment and storage medium
By acquiring the metadata of the bill of exchange messages and constructing a topology graph, the dependencies between the bill of exchange messages are identified and processed hierarchically, solving the problem of improper processing of the order of bill of exchange messages in existing technologies, and realizing efficient and accurate bill of exchange processing in a distributed system.
Patent Information
- Application Number
- CN202511665569.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-13
- Publication Date
- 2026-02-10
AI Technical Summary
In distributed bill of exchange systems, existing technologies rely on a single queue or timestamp mechanism to ensure the sequential processing of bill of exchange messages. This cannot effectively guarantee the message order, resulting in a high failure rate and limiting the system's parallel processing capabilities.
By acquiring the metadata of the bill of exchange messages, identifying the dependencies between messages, constructing a topology graph based on these relationships, processing the bill of exchange messages hierarchically, and using a distributed server to adopt different processing strategies for messages at different levels to ensure that messages are processed in the correct order.
It enables efficient sequential processing of bill of exchange messages in a distributed environment, improves the success rate of processing, balances the system's processing efficiency, and ensures the accuracy of bill of exchange transactions and the security of accounting.
Smart Images

Figure CN121504608A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial technology or other related technical fields. Specifically, it relates to a method and apparatus for processing bill of exchange messages, an electronic device, and a storage medium. Background Technology
[0002] With the rise of electronic financial transactions, the new generation of bill of exchange systems has become an indispensable part of modern business activities. This system not only simplifies the processes of bill issuance, acceptance, endorsement, and discounting, but also improves transaction efficiency and transparency. However, the surge in electronic bill transactions, especially the widespread adoption of the new generation of electronic bill systems, has posed unprecedented challenges to the accuracy and security of bill processing systems.
[0003] In high-concurrency trading environments, financial institutions have widely adopted distributed system architectures to improve processing speed and system responsiveness. This architecture allows multiple servers to interact with the bill exchange simultaneously to process a large number of bill messages in parallel. While distributed architecture can significantly improve processing efficiency, it also introduces new problems: message order disruption.
[0004] In a bill of exchange system, the circulation of bills involves multiple stages, and the messages at each stage carry specific business logic and information. For example, an endorsement operation depends on the completion of a previous endorsement or acceptance operation; otherwise, it will lead to abnormal bill status or even accounting errors. Therefore, ensuring that messages are executed in the correct business sequence in a distributed environment is crucial for maintaining the accuracy of bill transactions and the security of funds.
[0005] In related technologies, most distributed bill of exchange message processing typically relies on a single queue or timestamp mechanism to ensure message order. However, this is prone to failure in multi-server environments, especially under high concurrency and network latency. Furthermore, a single sequential processing mechanism significantly limits the system's parallel processing capabilities, thereby affecting overall processing efficiency.
[0006] There is currently no effective solution to the above problems. Summary of the Invention
[0007] This invention provides a method, apparatus, electronic device, and storage medium for processing bill of exchange messages, to at least solve the technical problem in related technologies that rely on a single queue or timestamp mechanism to sequence messages, which cannot effectively guarantee message order and has a high failure rate.
[0008] According to one aspect of the present invention, a method for processing bill of exchange messages is provided, comprising: acquiring a bill of exchange message and metadata corresponding to the bill of exchange message; identifying dependencies between the bill of exchange messages based on the metadata; classifying the bill of exchange messages based on the dependencies to obtain first-level bill of exchange messages, second-level bill of exchange messages, and third-level bill of exchange messages, wherein the first-level bill of exchange messages represent bill of exchange messages without dependencies, the second-level bill of exchange messages represent bill of exchange messages with single business dependencies, and the third-level bill of exchange messages represent bill of exchange messages with multiple business dependencies; for the second-level bill of exchange messages and the third-level bill of exchange messages, constructing a topology graph based on the dependencies between the bill of exchange messages, and constructing a message processing task based on the topology graph of the second-level bill of exchange messages, the topology graph of the third-level bill of exchange messages, and the first-level bill of exchange messages, and processing the bill of exchange messages based on the message processing task.
[0009] Furthermore, the steps of obtaining the bill of exchange message and the corresponding metadata include: retrieving the bill of exchange message from the Shanghai Commercial Paper Exchange message queue based on multiple pre-deployed servers; and obtaining the metadata of the bill of exchange message, wherein the metadata includes at least: message service type, real-time bill identifier, and initial bill identifier.
[0010] Furthermore, the step of identifying the dependencies between the bill messages based on the metadata includes: identifying bill messages with no dependencies and bill messages with dependencies based on the message service type; for bill messages with dependencies, identifying the dependencies between any bill message and other bill messages based on the real-time bill identifier and the initial bill identifier of the bill message.
[0011] Furthermore, for the second-level bill of exchange messages and the third-level bill of exchange messages, the step of constructing a topology graph based on the dependencies between messages includes: for the second-level bill of exchange messages, determining the transaction business corresponding to the second-level bill of exchange messages; obtaining all second-level bill of exchange messages corresponding to the transaction business; constructing a single-business topology graph with each second-level bill of exchange message as a node and the dependencies between the second-level bill of exchange messages as edges; for the third-level bill of exchange messages, determining the business interval to which the third-level bill of exchange messages belong; within each business interval, constructing a directed topology graph of each business interval with the third-level bill of exchange messages as nodes and the dependencies between the third-level bill of exchange messages as edges, and associating the directed topology graphs of each business interval to generate a multi-business topology graph.
[0012] Furthermore, for the third-level bill of exchange message, the step of determining the business range to which the third-level bill of exchange message belongs includes: defining isolation anchor points between each transaction business based on preset anchor point definition rules; determining the business type involved in the third-level bill of exchange message according to the isolation anchor points and the message business type of the third-level bill of exchange message; and saving the third-level bill of exchange message to the corresponding business range according to the business type.
[0013] Furthermore, the step of constructing a message processing task based on the topology diagram of the second-level bill of exchange message, the topology diagram of the third-level bill of exchange message, and the first-level bill of exchange message includes: performing topological sorting on the second-level bill of exchange message based on the single-service topology diagram of the second-level bill of exchange message, constructing a single-service message processing task based on the sorting result, and updating the status of the single-service message processing task to the ready state; performing topological sorting on the third-level bill of exchange message based on the multi-service topology diagram of the third-level bill of exchange message, constructing a multi-service message processing task based on the sorting result, and updating the multi-service message processing task to the ready state; directly constructing a message processing task for the first-level bill of exchange message, and updating the message processing task to the ready state.
[0014] Furthermore, the step of processing the bill of exchange message based on the message processing task includes: monitoring the tasks in the ready state through a distributed server to obtain monitoring results; for the message processing tasks in the ready state in the monitoring results, processing each message processing task in parallel through multiple distributed servers; for the single-service message processing tasks in the ready state in the monitoring results, processing the second-level bill of exchange messages within the single-service message processing task sequentially through the distributed server; and for the multi-service message processing tasks in the ready state in the monitoring results, processing the third-level bill of exchange messages within the multi-service message processing task sequentially through the distributed server.
[0015] According to another aspect of the present invention, a bill of exchange message processing apparatus is also provided, comprising: an acquisition unit, configured to acquire a bill of exchange message and metadata corresponding to the bill of exchange message; an identification unit, configured to identify the dependency relationships between the bill of exchange messages based on the metadata; a classification unit, configured to classify the bill of exchange messages based on the dependency relationships to obtain a first-level bill of exchange message, a second-level bill of exchange message, and a third-level bill of exchange message, wherein the first-level bill of exchange message represents a bill of exchange message without dependency relationships, the second-level bill of exchange message represents a bill of exchange message with a single business dependency relationship, and the third-level bill of exchange message represents a bill of exchange message with multiple business dependencies; and a construction unit, configured to construct a topology graph for the second-level bill of exchange message and the third-level bill of exchange message based on the dependency relationships between the bill of exchange messages, and construct a message processing task based on the topology graph of the second-level bill of exchange message, the topology graph of the third-level bill of exchange message, and the first-level bill of exchange message, and process the bill of exchange message based on the message processing task.
[0016] Furthermore, the acquisition unit includes: a first capture module, used to capture the bill message from the Shanghai Commercial Paper Exchange message queue based on multiple pre-deployed servers; and a first acquisition module, used to acquire the metadata of the bill message, wherein the metadata includes at least: message service type, real-time bill identifier, and initial bill identifier.
[0017] Furthermore, the identification unit includes: a first identification module, used to identify bill messages with no dependency relationship and bill messages with dependency relationship based on the message service type; and a second identification module, used to identify the dependency relationship between any bill message and other bill messages based on the real-time bill identifier and the initial bill identifier of the bill message for bill messages with dependency relationship.
[0018] Further, the construction unit includes: a first determining module, used to determine the transaction business corresponding to the second-level bill message for the second-level bill message; a second obtaining module, used to obtain all second-level bill messages corresponding to the transaction business; a first construction module, used to construct a single-business topology graph with each second-level bill message as a node and the dependencies between the second-level bill messages as edges; a second determining module, used to determine the business interval to which the third-level bill message belongs for the third-level bill message; and a first generating module, used to construct a directed topology graph of each business interval with the third-level bill message as a node and the dependencies between the third-level bill messages as edges, and associate the directed topology graphs of each business interval to generate a multi-business topology graph.
[0019] Furthermore, the second determining module includes: a first defining submodule, used to define isolation anchor points between each transaction business based on preset anchor point definition rules; and a first determining submodule, used to determine the business type involved in the third-level bill message according to the isolation anchor points and the message business type of the third-level bill message, and save the third-level bill message to the corresponding business range according to the business type.
[0020] Further, the construction unit includes: a first sorting module, configured to perform topological sorting on the second-level bill messages based on the single-service topology diagram of the second-level bill messages, and construct a single-service message processing task based on the sorting result, and update the status of the single-service message processing task to a ready state; a second sorting module, configured to perform topological sorting on the third-level bill messages based on the multi-service topology diagram of the third-level bill messages, and construct a multi-service message processing task based on the sorting result, and update the multi-service message processing task to a ready state; and a second construction module, configured to directly construct a message processing task for the first-level bill messages, and update the message processing task to a ready state.
[0021] Furthermore, the construction unit also includes: a first monitoring module, used to monitor tasks in the ready state through a distributed server and obtain monitoring results; a first processing module, used to process each message processing task in the ready state in the monitoring results in parallel through multiple distributed servers; a second processing module, used to process the second-level bill messages within the single-service message processing task in the ready state in the monitoring results sequentially through the distributed server; and a third processing module, used to process the third-level bill messages within the multi-service message processing task in the ready state in the monitoring results sequentially through the distributed server.
[0022] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform any of the above-described methods for processing bill of exchange messages.
[0023] According to another aspect of the present invention, an electronic device is also provided, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described methods for processing bill of exchange messages.
[0024] In this application, the following steps are taken: obtaining the bill of exchange messages and their corresponding metadata, identifying the dependencies between the bill of exchange messages based on the metadata, classifying the bill of exchange messages based on the dependencies to obtain first-level, second-level, and third-level bill of exchange messages. First-level bill of exchange messages represent those without dependencies, second-level bill of exchange messages represent those with single-business dependencies, and third-level bill of exchange messages represent those with multiple-business dependencies. Finally, for second-level and third-level bill of exchange messages, a topology graph is constructed based on the dependencies between the bill of exchange messages. A message processing task is then constructed based on the topology graphs of the second-level and third-level bill of exchange messages and the first-level bill of exchange messages. The bill of exchange messages are then processed based on the message processing task.
[0025] In this application, dependencies between messages are identified based on metadata, and messages are classified. Different processing strategies are adopted for messages at different levels. For messages without dependencies, parallel processing is performed using distributed servers to ensure processing efficiency. For messages with dependencies, a directed acyclic graph is constructed to perform topological sorting of messages and determine the message processing order, thereby achieving sequential processing of messages and improving the success rate of sequential processing. Even in a distributed server environment, messages can be processed in a timely manner. This solves the technical problem in related technologies that rely on a single queue or timestamp mechanism to sort messages, which cannot effectively guarantee message order and has a high failure rate. Attached Figure Description
[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:
[0027] Figure 1 A hardware structure block diagram of a mobile terminal for executing a bill of exchange message processing method according to an embodiment of this application is shown.
[0028] Figure 2 This is a flowchart of an optional bill of exchange message processing method according to an embodiment of the present invention;
[0029] Figure 3 This is a schematic diagram of an optional bill of exchange message processing flow according to an embodiment of the present invention;
[0030] Figure 4 This is a schematic diagram of an optional bill of exchange message processing apparatus according to an embodiment of the present invention; Detailed Implementation
[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0033] It should be noted that the bill of exchange message processing method and apparatus in this application can be used in the financial technology field when messages are processed sequentially by constructing a topology graph, and can also be used in any field other than the financial technology field when messages are processed sequentially by constructing a topology graph. This application does not limit the application field of the bill of exchange message processing method and apparatus.
[0034] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this application are 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 such data all comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.
[0035] It should be noted that in this application, when collecting and analyzing customer information, users are provided with corresponding operation entry points to choose whether to agree to or reject the automated decision-making results; if the user chooses to reject, the process will proceed to the expert decision-making process.
[0036] The following embodiments of the present invention can be applied to various bill of exchange message processing systems / applications / devices. The present invention utilizes multiple servers simultaneously to capture unordered messages from the exchange's message queue. First, it constructs a directed acyclic graph (DAG) from these messages, where nodes represent messages and directed edges represent order constraints between messages (i.e., message A must be executed before message B). Then, topological sorting is used to determine the execution order of the messages, thereby transforming multiple unordered messages into multiple tasks with sequential dependencies (each task is a sequence of ordered messages). Distributed servers then process the messages sequentially according to the topological order. This ensures strictly ordered message execution, guaranteeing the accuracy of bill of exchange transactions and the security of accounting, while balancing system processing efficiency, avoiding message delays and backlogs, and significantly improving the accuracy and security of system operation.
[0037] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.
[0038] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a bill of exchange message processing method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0039] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the bill of exchange message processing method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-described networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the above-described networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0040] Example 1
[0041] According to an embodiment of the present invention, an embodiment of a method for processing bill of exchange messages is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0042] Figure 2 This is a flowchart of an optional bill of exchange message processing method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps:
[0043] Step S201: Obtain the bill of exchange message and the corresponding metadata.
[0044] It should be noted that a bill of exchange message refers to the data format used by participating parties (such as financial institutions and enterprises) to exchange information through an electronic bill system during a bill of exchange transaction. These messages contain various transaction information related to the bill of exchange, such as detailed data and instructions regarding issuance, acceptance, endorsement, discounting, rediscounting, repurchase, further discounting, pledging, guarantee, and recourse. For example, when a company applies to a financial institution for a bill of exchange, the financial institution sends an issuance message through the system; when the acceptor agrees to accept the bill, an acceptance message is sent; when the bill of exchange is transferred between different holders, an endorsement message is generated and transmitted, recording information for each transfer. Through the processing of this series of messages, the bill of exchange transaction is completed, and the relevant business and accounting status is updated.
[0045] In step S201 above, multiple front-end servers (which are interface components that interact with the Shanghai Stock Exchange for data exchange) are deployed to achieve message capture and metadata collection. Each front-end server can connect to the Shanghai Stock Exchange independently, thereby capturing messages in parallel and improving the speed and efficiency of message acquisition.
[0046] After the front-end server captures the message, it immediately parses the message content and extracts the metadata. Metadata is data that describes the characteristics and attributes of the bill message, including but not limited to the message's business type, real-time bill identifier (i.e., the unique identifier of the current bill, which may change after endorsement or other operations), and initial bill identifier (the unique identifier assigned when the bill is first created and remains unchanged). The extraction of metadata is the foundation for subsequent identification of message dependencies and classification processing.
[0047] Furthermore, the steps for obtaining the bill of exchange message and the corresponding metadata include: retrieving the bill of exchange message from the Shanghai Commercial Paper Exchange message queue based on multiple pre-deployed servers; and obtaining the metadata of the bill of exchange message, wherein the metadata includes at least: message business type, real-time bill identifier, and initial bill identifier.
[0048] Specifically, when capturing and parsing bill of exchange messages, multiple front-end servers are first pre-deployed within the financial institution's IT infrastructure. These servers collectively undertake the responsibility of communicating with the Shanghai Commercial Paper Exchange (SCPE), capturing bill of exchange messages in parallel from the SCPE's message queue. A message queue is a middleware technology used for temporarily storing and transmitting messages. After message capture, the front-end servers parse the messages and extract their metadata. Metadata is key information describing message attributes and business characteristics, mainly including message business type, real-time bill identifier, and initial bill identifier. The message business type specifies the specific business activity involved in the message, such as issuance, acceptance, and endorsement, which is crucial for identifying dependencies between messages. The real-time bill identifier is the current unique identifier of the bill associated with the message and may change as the bill circulates (e.g., endorsement), used to track the bill's immediate status. The initial bill identifier is a unique identifier assigned when the bill is created and does not change with the bill's status, used to ensure traceability throughout the bill's lifecycle.
[0049] In this embodiment, the parallel fetching mechanism of multiple servers fully utilizes existing IT resources, significantly improving the message acquisition speed and adapting to the high-frequency, high-volume transaction needs of the bill of exchange system. The accurate extraction of metadata provides a solid data foundation for subsequent message dependency identification and classification.
[0050] Step S202: Identify the dependencies between bill messages based on metadata.
[0051] In step S202 above, after parsing the metadata, the dependencies between bills are identified based on the key information in the metadata. The dependencies include the dependencies between different messages under the same business and the dependencies between messages between different businesses. The dependencies between messages are the basis for the sequential processing of messages, providing a key logical basis for subsequent topology construction and task scheduling.
[0052] Furthermore, the steps for identifying dependencies between bill messages based on metadata include: identifying bill messages with no dependencies and bill messages with dependencies based on the message business type; for bill messages with dependencies, identifying the dependencies between any bill message and other bill messages based on the real-time bill identifier and the initial bill identifier of the bill message.
[0053] Specifically, when identifying dependencies between messages, the message business type is first extracted from the metadata. Some business types indicate that the message is an independent event and can be processed without waiting for other messages, such as participant information modification; these messages are classified as messages without dependencies. However, business types involving the circulation of negotiable instruments, such as issuance, acceptance, and endorsement, indicate that the message may depend on the completion of other messages and are marked as messages with dependencies. For messages with dependencies, the real-time negotiable instrument identifier and the initial negotiable instrument identifier are further analyzed to determine the specific dependencies between messages. By comparing these two identifiers, the system can determine whether the messages are associated with different stages of the same negotiable instrument, thereby deciding whether it is necessary to include them in the same sequential dependency chain.
[0054] Step S203: Classify the bill of exchange messages based on the dependency relationship to obtain first-level bill of exchange messages, second-level bill of exchange messages and third-level bill of exchange messages.
[0055] In step S203 above, after obtaining the dependencies between messages, the bill messages are further divided according to the dependencies. For bill messages without dependencies, they are classified as first-level bill messages (L0), which can be processed in parallel by multiple servers to improve message processing efficiency. For bill messages with dependencies, they are divided into first-level bill messages (L1) and second-level bill messages (L2) according to whether there are dependencies between services.
[0056] Therefore, all messages are divided into Level 1, Level 2, and Level 3 draft messages. Level 1 draft messages represent those without dependencies, while Level 2 draft messages represent those with single-business dependencies. A single-business dependency means that the dependency between draft messages is limited to the same type of business activity. This means that the execution order of messages depends on the inherent rules of the business process and does not involve other different types of business. For example, in endorsement business, multiple endorsement processes of a draft exemplify a single-business dependency. For instance, the first endorsement message (message A) must be executed before the second endorsement message (message B) because each endorsement needs to be based on the result of the previous endorsement, but both endorsements belong to the single business type of endorsement. In this case, the relationship between messages can be represented by a simple topological graph, where nodes only involve endorsement business messages, and edges represent sequential dependencies between messages.
[0057] Level 3 bill of exchange messages represent bill of exchange messages with multiple business dependencies. These dependencies involve the interdependencies between two or more different types of business transactions. This dependency is not limited to the same business process but spans different business processes, forming a more complex dependency network. For example, in the series of bill of exchange transactions from issuance to acceptance, discounting, and rediscounting, the issuance message (message C) must be executed first, followed by the acceptance message (message D); only after acceptance is completed can the discounting and rediscounting related messages (messages E and F) be processed. Here, there is a sequential dependency between multiple business types (issuance, acceptance, discounting, and rediscounting), forming a multi-business dependency. In this case, the message dependencies need to be represented by a more complex topology graph. This graph not only includes the messages of the various business types mentioned above and their dependencies, but may also include isolation anchors to distinguish different business types, ensuring that the topology graph within each business process is correctly constructed and that these different business topologies are correctly linked to form a holistic view reflecting the dependencies between multiple business processes.
[0058] Step S204: For the second-level and third-level bill of exchange messages, construct a topology graph based on the dependencies between the bill of exchange messages, and construct a message processing task based on the topology graph of the second-level and third-level bill of exchange messages and the first-level bill of exchange messages, and process the bill of exchange messages based on the message processing task.
[0059] In step S204 above, after classifying the messages, different processing methods are adopted for different types of bill messages, thereby achieving sequential processing of dependent messages and ensuring the accuracy and effectiveness of business processing. For bill messages with single business dependencies, the system constructs a topology graph for a single business type. Nodes in the graph represent messages, and edges represent dependencies between messages, ensuring that message A must be executed before message B. For messages with multiple business dependencies, the system constructs a topology graph for multiple business types. In this type of graph, in addition to message nodes and dependency edges, it also includes isolation anchors between various businesses to define the processing range of different business messages. Subsequently, a topology graph is constructed based on the messages and their dependencies. The topology graph is the basis for topology sorting. The tasks that have completed topology sorting are updated in status, and distributed server listeners monitor all ready tasks. When a ready L1 or L2 level task is detected, the server will start processing all messages in the task according to the execution order determined in the topology graph. Different servers can process different tasks in parallel, improving message processing efficiency while ensuring sequential execution.
[0060] Furthermore, for second-level and third-level bill messages, the steps for constructing a topology graph based on the dependencies between messages include: for second-level bill messages, determining the transaction business corresponding to the second-level bill message; obtaining all second-level bill messages corresponding to the transaction business; constructing a single-business topology graph with each second-level bill message as a node and the dependencies between second-level bill messages as edges; for third-level bill messages, determining the business area to which the third-level bill message belongs; within each business area, constructing a directed topology graph of each business area with third-level bill messages as nodes and the dependencies between third-level bill messages as edges, and associating the directed topology graphs of each business area to generate a multi-business topology graph.
[0061] Specifically, by constructing a topology graph, the processing order of bill of exchange messages can be understood more intuitively. First, the system needs to identify the specific transaction involved in the L1-level bill of exchange message, such as acceptance or endorsement. Next, the system will obtain all L1-level bill of exchange messages related to that transaction, ensuring that the subsequently constructed topology graph includes all necessary messages. Using the obtained L1-level messages as nodes and the dependencies between messages as edges, a directed acyclic topology graph for each business type is constructed according to the directions of these dependencies. Thus, the order of message execution is determined through topological sorting, ensuring the orderly processing of messages in a distributed environment.
[0062] Secondly, for L2-level messages, the system needs to define the business area to which the L2-level message belongs. This is usually determined based on isolation anchors, which are specific identifiers or rule points used in bill of exchange message processing to define the processing flow of different business types of messages. When processing third-level bill of exchange messages with multiple business dependencies, isolation anchors help the system identify and distinguish which messages belong to the same business process and which messages cross different business boundaries. For each business area, the system must collect all related L2-level bill of exchange messages. Within each business area, a directed topology graph is constructed based on the dependency direction, using L2 messages as nodes and the dependencies between messages as edges. The topology graphs of all business areas are then associated to form a multi-business topology graph. This step ensures that when processing messages involving multiple business types, the mutual influence between different business processes can be considered, ensuring the orderliness of the overall business process and the security of accounting.
[0063] Furthermore, for Level 3 bill messages, the steps for determining the business range to which the Level 3 bill message belongs include: defining isolation anchors between each transaction based on preset anchor definition rules; determining the business types involved in the Level 3 bill message according to the isolation anchors and the message business type of the Level 3 bill message; and saving the Level 3 bill message to the corresponding business range according to the business type.
[0064] Specifically, for Level 3 bill of exchange messages, business anchors are the basis for determining the execution order of various transactions. The system uses a pre-defined set of anchor definition rules to determine the boundary points between transaction transactions. These rules are usually related to the nature and requirements of the bill of exchange business, such as based on specific business types or changes in bill status. Anchor definition rules are predefined. First, a thorough analysis of the bill of exchange business process is needed to understand the relationships and dependencies between different business types, such as the order of acceptance and endorsement, endorsement and discounting. Identifying which business types or messages require the completion of other messages as a prerequisite, these potential dependencies indicate the location of anchors. A set of anchor definition rules is defined based on business characteristics and system requirements. This may be based on message type, business stage, specific bill status change points, etc. According to the anchor definition rules, messages that can clearly identify business boundaries or status changes can be found and set as isolation anchors. For example, the initial acceptance message of a bill of exchange can serve as the anchor point for subsequent endorsement transactions, ensuring that all endorsement messages are processed sequentially after the initial acceptance.
[0065] Subsequently, the business type involved in each message is identified, and based on the identified business type, the Level 3 draft messages are saved to the corresponding business interval. Business intervals are defined by the aforementioned isolation anchor points, ensuring that messages of the same business type are stored centrally, while messages of different business types are isolated, forming their respective business intervals. The Level 3 draft messages saved to the business intervals are then further constructed into a multi-business topology graph, where nodes represent messages, edges represent dependencies between messages, and reflect the sequential nature of the business process.
[0066] Furthermore, the steps for constructing message processing tasks based on the topology diagrams of the second-level and third-level draft messages and the first-level draft messages include: performing topological sorting on the second-level draft messages based on the single-service topology diagram of the second-level draft messages, constructing a single-service message processing task based on the sorting result, and updating the status of the single-service message processing task to the ready state; performing topological sorting on the third-level draft messages based on the multi-service topology diagram of the third-level draft messages, constructing a multi-service message processing task based on the sorting result, and updating the multi-service message processing task to the ready state; and directly constructing message processing tasks for the first-level draft messages and updating the message processing tasks to the ready state.
[0067] Specifically, based on the single-service topology diagram of the second-level bill of exchange messages, messages within the same service are topologically sorted. This sorting process determines the execution order between messages, ensuring that all messages are executed according to the predetermined business logic order; that is, all preceding messages have been processed before subsequent messages begin processing. Based on the topology sorting result, the system constructs corresponding single-service message processing tasks, which will contain a sequentially arranged list of messages. Once the single-service message processing task is constructed, the system updates its status to "ready," indicating that the task is ready for execution.
[0068] Similarly, based on the multi-service topology diagram of the Level 3 bill of exchange messages, topology sorting is performed to determine the execution order of messages within each service segment, as well as the order in which messages are processed in different service segments. According to the sorting results, the system constructs multi-service message processing tasks for the Level 3 bill of exchange messages. These tasks take into account the dependencies between different service types to ensure that all messages are executed in the correct order. The constructed multi-service message processing tasks are then updated to the ready state.
[0069] Since first-level bill messages have no business dependencies, message processing tasks can be directly constructed without the need for complex topology graph construction and sorting processes. Once constructed, the system directly updates the status of these message processing tasks to the ready state, preparing them for execution.
[0070] Furthermore, the steps for processing bill messages based on message processing tasks include: monitoring tasks in the ready state through a distributed server to obtain monitoring results; for message processing tasks in the ready state in the monitoring results, processing each message processing task in parallel through multiple distributed servers; for single-service message processing tasks in the ready state in the monitoring results, processing the second-level bill messages within the single-service message processing task sequentially through a distributed server; and for multi-service message processing tasks in the ready state in the monitoring results, processing the third-level bill messages within the multi-service message processing task sequentially through a distributed server.
[0071] Specifically, the distributed server starts a dedicated listener to continuously monitor the status of message processing tasks within the mDAGMM. mDAGMM, short for Multilevel Directed Acyclic Graph Message Manager, is responsible for storing and managing message processing tasks at all levels. The listener periodically checks the status of tasks in the mDAGMM to identify which tasks have been updated to the ready state. A ready state indicates that all message dependencies have been correctly processed and the task is ready for execution. When the listener detects ready message processing tasks, each distributed server selects and acquires one or more tasks for processing based on its own load. The servers process the acquired ready message processing tasks in parallel, maximizing processing efficiency without sacrificing system accuracy and security. Simultaneously, for messages within a task, the servers process them sequentially according to the execution order, ensuring that all messages are executed strictly according to business logic.
[0072] Through the above steps, the bill of exchange messages and their corresponding metadata are obtained. Dependencies between the bill of exchange messages are identified based on the metadata. Then, the bill of exchange messages are classified according to these dependencies, resulting in first-level, second-level, and third-level bill of exchange messages. First-level bill of exchange messages represent those without dependencies, second-level messages represent those with single-business dependencies, and third-level messages represent those with multiple-business dependencies. Finally, for second-level and third-level bill of exchange messages, a topology graph is constructed based on the dependencies between them. Message processing tasks are then built based on the topology graphs of the second-level and third-level messages, along with the first-level messages, and the bill of exchange messages are processed using these tasks.
[0073] In this embodiment, multiple servers process ready tasks in parallel, accelerating system execution, especially for tasks without business dependencies, enabling rapid processing. For reporting tasks with business dependencies, execution strictly follows the topological order of the second and third level bill messages, ensuring the correctness and continuity of all business processes. By monitoring and processing ready tasks through distributed servers, the system can automatically allocate tasks, achieving dynamic and balanced use of computing resources and avoiding overload of a single server.
[0074] In this embodiment, dependencies between messages are identified based on metadata, and messages are classified. Different processing strategies are adopted for messages at different levels. For messages without dependencies, parallel processing is performed using distributed servers to ensure processing efficiency. For messages with dependencies, a directed acyclic graph is constructed to perform topological sorting of messages and determine the message processing order, thereby achieving sequential processing of messages and improving the success rate of sequential processing. Even in a distributed server environment, messages can be processed in a timely manner. This solves the technical problem in related technologies that rely on a single queue or timestamp mechanism to sort messages, which cannot effectively guarantee message order and has a high failure rate.
[0075] The following describes in detail another optional implementation method.
[0076] Figure 3 This is a schematic diagram of an optional bill of exchange message processing flow according to an embodiment of the present invention, such as... Figure 3 As shown, the processing flow of a bill of exchange message includes:
[0077] Step 1, Begin;
[0078] Step 2: Multiple servers simultaneously retrieve messages from the Shanghai Stock Exchange's message queue to obtain the packets;
[0079] Step 3: Discover the dependencies between messages;
[0080] Step 4: Identify the message level based on the dependency relationship. For L0 level messages (corresponding to the first level message mentioned above), proceed to step 5. For L1 level messages (corresponding to the second level message mentioned above), proceed to step 6. For L2 level messages (corresponding to the third level message mentioned above), proceed to step 7.
[0081] Step 5: L0 level messages have no dependencies and require no processing. They are directly processed in parallel by calling the background message processing server.
[0082] Based on the identified L0 level messages, such as public control messages like participant information modification and stock exchange status update, there are no preceding message dependencies and no subsequent business will depend on these messages. Therefore, the preceding layer directly calls the backend message processing system for business processing.
[0083] Step 6: L1 level messages. Construct a directed acyclic graph based on the message sequence. After obtaining all messages of the current service and completing the topology sorting, update the task to the ready state.
[0084] Based on the identified L1 level messages, the messages are saved to mDAGMM, and a new L1 level task of a single service type is created. When receiving subsequent exchange messages for this service, the execution topology graph of the messages in this task is constructed according to the message sequence. After all service messages for this service have been obtained and the topology sorting is completed, this task is updated to the ready state.
[0085] Step 7: L2 level message, define the isolation anchor point between services, construct the directed acyclic graph of intervals within each service, form a multi-interval topology order, and update the task to the ready state;
[0086] Based on the identified L2-level messages, the messages are stored in mDAGMM, and a multi-service-type L2-level task is created, defining isolation anchors between each service to achieve multi-level sorting of service types. When receiving subsequent messages from the stock exchange, the service type is determined based on the message type and isolation anchor, and the message is stored in its corresponding service interval. This process is repeated until all messages are stored in their corresponding service intervals. Finally, a directed acyclic graph is constructed within each service interval, resulting in a multi-interval directed acyclic graph for the entire task, which is then updated to the ready state.
[0087] Step 8: Execute the messages sequentially according to the topological order within the ready-to-go task;
[0088] The distributed server starts a listener to monitor the ready tasks in mDAGMM. Once a ready task is detected, the current server begins executing all messages in that task in a topology-ordered manner. Different servers execute ready tasks that do not have mutual dependencies simultaneously.
[0089] Step nine, end.
[0090] This invention utilizes multiple servers simultaneously to retrieve unordered messages from the Shanghai Stock Exchange's message queue. First, these messages are constructed into a directed acyclic graph (DAG), where nodes represent messages and directed edges represent order constraints between messages (i.e., message A must be executed before message B). Then, topological sorting is used to determine the execution order of the messages, transforming multiple unordered messages into multiple tasks with sequential dependencies (each task is a sequence of ordered messages). Distributed servers then process these messages sequentially according to the topological order. This ensures strictly ordered message execution, guaranteeing the accuracy of bill transactions and the security of accounting, while balancing system processing efficiency, avoiding message delays and backlogs, and significantly improving the accuracy and security of system operation.
[0091] The following is a detailed description with reference to another embodiment.
[0092] Example 2
[0093] The bill of exchange message processing device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in the above embodiment one. The specific implementation method and beneficial effects can be referred to the foregoing method embodiment, and will not be repeated here.
[0094] Figure 4 This is a schematic diagram of an optional bill of exchange message processing apparatus according to an embodiment of the present invention, such as... Figure 4 As shown, the processing device for the bill of exchange message includes: an acquisition unit 41, an identification unit 42, a classification unit 43, and a construction unit 44, wherein,
[0095] Acquisition unit 41 is used to acquire the bill of exchange message and the metadata corresponding to the bill of exchange message;
[0096] Identification unit 42 is used to identify the dependencies between bill messages based on metadata;
[0097] Classification unit 43 is used to classify bill messages based on dependencies to obtain first-level bill messages, second-level bill messages and third-level bill messages. The first-level bill message represents a bill message without dependencies, the second-level bill message represents a bill message with a single business dependency, and the third-level bill message represents a bill message with multiple business dependencies.
[0098] The construction unit 44 is used to construct a topology graph for the second-level and third-level bill messages based on the dependencies between the bill messages, and to construct a message processing task based on the topology graph of the second-level bill message, the topology graph of the third-level bill message, and the first-level bill message, and to process the bill messages based on the message processing task.
[0099] The aforementioned bill of exchange message processing device acquires the bill of exchange message and its corresponding metadata through the acquisition unit 41; identifies the dependencies between bill of exchange messages based on the metadata through the identification unit 42; classifies the bill of exchange messages based on the dependencies through the classification unit 43 to obtain first-level bill of exchange messages, second-level bill of exchange messages, and third-level bill of exchange messages, wherein the first-level bill of exchange messages represent bill of exchange messages without dependencies, the second-level bill of exchange messages represent bill of exchange messages with single business dependencies, and the third-level bill of exchange messages represent bill of exchange messages with multiple business dependencies; and constructs a topology graph for the second-level and third-level bill of exchange messages based on the dependencies between the bill of exchange messages through the construction unit 44, and constructs message processing tasks based on the topology graphs of the second-level and third-level bill of exchange messages and the first-level bill of exchange messages, and processes the bill of exchange messages based on the message processing tasks.
[0100] In this embodiment, dependencies between messages are identified based on metadata, and messages are classified. Different processing strategies are adopted for messages at different levels. For messages without dependencies, parallel processing is performed using distributed servers to ensure processing efficiency. For messages with dependencies, a directed acyclic graph is constructed to perform topological sorting of messages and determine the message processing order, thereby achieving sequential processing of messages and improving the success rate of sequential processing. Even in a distributed server environment, messages can be processed in a timely manner. This solves the technical problem in related technologies that rely on a single queue or timestamp mechanism to sort messages, which cannot effectively guarantee message order and has a high failure rate.
[0101] Furthermore, the acquisition unit includes: a first capture module, used to capture bill messages from the Shanghai Commercial Paper Exchange message queue based on multiple pre-deployed servers; and a first acquisition module, used to acquire the metadata of the bill messages, wherein the metadata includes at least: message business type, real-time bill identifier, and initial bill identifier.
[0102] Furthermore, the identification unit includes: a first identification module, used to identify bill messages with no dependency relationship and bill messages with dependency relationship based on the message service type; and a second identification module, used to identify the dependency relationship between any bill message and other bill messages based on the real-time bill identifier and initial bill identifier of the bill message for bill messages with dependency relationship.
[0103] Furthermore, the construction unit includes: a first determining module, used to determine the transaction business corresponding to the second-level bill message; a second obtaining module, used to obtain all second-level bill messages corresponding to the transaction business; a first construction module, used to construct a single-business topology graph with each second-level bill message as a node and the dependencies between second-level bill messages as edges; a second determining module, used to determine the business interval to which the third-level bill message belongs; and a first generating module, used to construct a directed topology graph of each business interval with third-level bill messages as nodes and the dependencies between third-level bill messages as edges, and to associate the directed topology graphs of each business interval to generate a multi-business topology graph.
[0104] Furthermore, the second determining module includes: a first defining submodule, used to define isolation anchor points between each transaction business based on preset anchor point definition rules; and a first determining submodule, used to determine the business types involved in the third-level bill of exchange message according to the isolation anchor points and the message business type of the third-level bill of exchange message, and save the third-level bill of exchange message to the corresponding business range according to the business type.
[0105] Furthermore, the construction unit includes: a first sorting module, used to perform topological sorting on the second-level bill messages based on the single-service topology diagram of the second-level bill messages, and to construct a single-service message processing task based on the sorting result, and update the status of the single-service message processing task to the ready state; a second sorting module, used to perform topological sorting on the third-level bill messages based on the multi-service topology diagram of the third-level bill messages, and to construct a multi-service message processing task based on the sorting result, and update the multi-service message processing task to the ready state; and a second construction module, used to directly construct message processing tasks for the first-level bill messages, and update the message processing tasks to the ready state.
[0106] Furthermore, the building unit also includes: a first monitoring module, used to monitor tasks in the ready state through a distributed server and obtain monitoring results; a first processing module, used to process message processing tasks in the ready state in the monitoring results in parallel through multiple distributed servers; a second processing module, used to process second-level bill messages within single-service message processing tasks in the ready state in the monitoring results sequentially through a distributed server; and a third processing module, used to process third-level bill messages within multi-service message processing tasks in the ready state in the monitoring results sequentially through a distributed server.
[0107] The aforementioned bill of exchange message processing device may further include a processor and a memory. The aforementioned acquisition unit 31, identification unit 32, classification unit 33, construction unit 34, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.
[0108] The processor described above contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and message processing is achieved by adjusting kernel parameters.
[0109] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.
[0110] This invention provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device where the computer-readable storage medium is located to execute a method for processing bill of exchange messages.
[0111] According to another aspect of the present invention, a processor is also provided, which is used to run a program, wherein the program executes a method for processing bill of exchange messages during runtime.
[0112] This invention provides an apparatus, including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps: acquiring bill of exchange messages and corresponding metadata; identifying dependencies between bill of exchange messages based on the metadata; classifying the bill of exchange messages based on the dependencies to obtain first-level, second-level, and third-level bill of exchange messages, wherein first-level bill of exchange messages represent bill of exchange messages without dependencies, second-level bill of exchange messages represent bill of exchange messages with single-business dependencies, and third-level bill of exchange messages represent bill of exchange messages with multiple-business dependencies; for second-level and third-level bill of exchange messages, constructing a topology graph based on the dependencies between the bill of exchange messages, and constructing a message processing task based on the topology graph of the second-level and third-level bill of exchange messages and the first-level bill of exchange messages; and processing the bill of exchange messages based on the message processing task.
[0113] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.
[0114] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps: obtaining bill of exchange messages and corresponding metadata; identifying dependencies between bill of exchange messages based on the metadata; classifying the bill of exchange messages based on the dependencies to obtain first-level bill of exchange messages, second-level bill of exchange messages, and third-level bill of exchange messages, wherein first-level bill of exchange messages represent bill of exchange messages without dependencies, second-level bill of exchange messages represent bill of exchange messages with single business dependencies, and third-level bill of exchange messages represent bill of exchange messages with multiple business dependencies; for second-level and third-level bill of exchange messages, constructing a topology graph based on the dependencies between the bill of exchange messages, and constructing a message processing task based on the topology graph of the second-level and third-level bill of exchange messages and the first-level bill of exchange messages, and processing the bill of exchange messages based on the message processing task.
[0115] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.
[0116] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0117] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0118] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0119] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0120] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0121] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0122] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0123] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0124] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0125] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for processing bill of exchange messages, characterized in that, include: Obtain the bill of exchange message and the corresponding metadata of the bill of exchange message; The dependencies between the bill of exchange messages are identified based on the metadata. Based on the dependencies, the bill messages are classified to obtain first-level bill messages, second-level bill messages, and third-level bill messages. The first-level bill messages represent bill messages without dependencies, the second-level bill messages represent bill messages with single business dependencies, and the third-level bill messages represent bill messages with multiple business dependencies. For the second-level bill of exchange message and the third-level bill of exchange message, a topology graph is constructed based on the dependency relationship between the bill of exchange messages. A message processing task is constructed based on the topology graph of the second-level bill of exchange message, the topology graph of the third-level bill of exchange message, and the first-level bill of exchange message. The bill of exchange message is processed based on the message processing task.
2. The method according to claim 1, characterized in that, The steps for obtaining the bill of exchange message and the corresponding metadata include: The bill messages are retrieved from the Shanghai Commercial Paper Exchange message queue using multiple pre-deployed servers; Obtain the metadata of the bill of exchange message, wherein the metadata includes at least: message business type, real-time bill identifier, and initial bill identifier.
3. The method according to claim 2, characterized in that, The steps for identifying dependencies between the bill of exchange messages based on the metadata include: Based on the message service type, identify bill of exchange messages with no dependency relationship and bill of exchange messages with dependency relationship; For bill messages with dependencies, the dependencies between any bill message and other bill messages are identified based on the real-time bill identifier and the initial bill identifier of the bill message.
4. The method according to claim 2, characterized in that, For the second-level and third-level bill of exchange messages, the steps for constructing a topology graph based on the dependencies between messages include: For the second-level bill of exchange message, determine the transaction corresponding to the second-level bill of exchange message; Retrieve all second-level draft messages corresponding to this transaction; A single business topology graph is constructed using each second-level bill message as a node and the dependencies between second-level bill messages as edges. For the third-level bill of exchange message, determine the business segment to which the third-level bill of exchange message belongs; Within each of the aforementioned business segments, a directed topology graph is constructed using the third-level bill message as a node and the dependencies between the third-level bill messages as edges. The directed topology graphs of each business segment are then associated to generate a multi-business topology graph.
5. The method according to claim 4, characterized in that, For the third-level bill of exchange message, the steps to determine the business segment to which the third-level bill of exchange message belongs include: Define isolation anchor points between various transaction businesses based on preset anchor point definition rules; The business type involved in the third-level bill of exchange message is determined based on the isolation anchor point and the message business type of the third-level bill of exchange message, and the third-level bill of exchange message is saved to the corresponding business range according to the business type.
6. The method according to claim 4, characterized in that, The steps for constructing a message processing task based on the topology diagram of the second-level bill of exchange message, the topology diagram of the third-level bill of exchange message, and the first-level bill of exchange message include: Based on the single-service topology diagram of the second-level bill of exchange message, the second-level bill of exchange message is sorted in topology, and a single-service message processing task is constructed based on the sorting result. The status of the single-service message processing task is then updated to the ready state. Based on the multi-service topology diagram of the third-level bill of exchange message, the third-level bill of exchange message is sorted in topology, and a multi-service message processing task is constructed based on the sorting result, and the multi-service message processing task is updated to the ready state. For the first-level bill of exchange message, directly construct a message processing task and update the message processing task to the ready state.
7. The method according to claim 6, characterized in that, The steps for processing the bill of exchange message based on the message processing task include: The monitoring results are obtained by monitoring tasks in the ready state through a distributed server; For the message processing tasks that are in the ready state in the monitoring results, each message processing task is processed in parallel by multiple distributed servers; For the single-service message processing task that is in the ready state in the monitoring results, the second-level bill of exchange messages within the single-service message processing task are processed sequentially by the distributed server. For the multi-service message processing task that is in the ready state in the monitoring results, the third-level bill of exchange messages within the multi-service message processing task are processed sequentially by the distributed server.
8. A device for processing bill of exchange messages, characterized in that, include: The acquisition unit is used to acquire the bill of exchange message and the metadata corresponding to the bill of exchange message; The identification unit is used to identify the dependencies between the bill of exchange messages based on the metadata; A classification unit is used to classify the bill of exchange messages based on the dependency relationship to obtain a first-level bill of exchange message, a second-level bill of exchange message, and a third-level bill of exchange message. The first-level bill of exchange message represents a bill of exchange message with no dependency relationship, the second-level bill of exchange message represents a bill of exchange message with a single business dependency relationship, and the third-level bill of exchange message represents a bill of exchange message with multiple business dependencies. The construction unit is used to construct a topology graph for the second-level bill of exchange message and the third-level bill of exchange message based on the dependency relationship between the bill of exchange messages, and to construct a message processing task based on the topology graph of the second-level bill of exchange message, the topology graph of the third-level bill of exchange message and the first-level bill of exchange message, and to process the bill of exchange message based on the message processing task.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the bill of exchange message processing method according to any one of claims 1 to 7.
10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the bill of exchange message processing method according to any one of claims 1 to 7.