CN114092248A - Transaction flow processing method and device - Google Patents

Transaction flow processing method and device Download PDF

Info

Publication number
CN114092248A
CN114092248A CN202111407257.5A CN202111407257A CN114092248A CN 114092248 A CN114092248 A CN 114092248A CN 202111407257 A CN202111407257 A CN 202111407257A CN 114092248 A CN114092248 A CN 114092248A
Authority
CN
China
Prior art keywords
transaction
module
processing module
data
original
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111407257.5A
Other languages
Chinese (zh)
Inventor
许国鹏
陈定邦
赖洁仪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bank of China Ltd
Original Assignee
Bank of China Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bank of China Ltd filed Critical Bank of China Ltd
Priority to CN202111407257.5A priority Critical patent/CN114092248A/en
Publication of CN114092248A publication Critical patent/CN114092248A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching

Abstract

The invention discloses a transaction flow processing method and device, which can be applied to the field of mobile interconnection. The method comprises the following steps: reading original transaction data of the transaction to be processed from the transaction request queue and determining the transaction type of the transaction to be processed, wherein the transaction type is obtained by the transaction request processing module or the network management transaction processing module in an identification way; the transaction processing core of the transaction processing system is at least divided into: the system comprises a transaction request processing module, a transaction matching processing module, a transaction reply module, a storage and forwarding module and a network management transaction processing module; aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the processing speed and the processing efficiency of the transactions are improved, and the time for responding to the transactions is reduced.

Description

Transaction flow processing method and device
Technical Field
The invention relates to the technical field of data processing, in particular to a transaction flow processing method and device.
Background
Banks generally use transaction processing systems (such as a financial intercommunication system) to process online transactions, but currently used transaction processing systems do not distinguish transactions when processing transactions, and the function implementation of the transaction processing systems is complicated, which all result in slower transaction processing speed, thus resulting in lower processing efficiency and longer transaction response time.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method and an apparatus for processing a transaction flow, so as to solve the problems of a conventional transaction processing system that the processing speed is relatively slow, the processing efficiency is relatively low, and the response time is relatively long when processing a transaction.
In order to achieve the above purpose, the embodiments of the present invention provide the following technical solutions:
the first aspect of the embodiment of the invention discloses a processing method of a transaction flow, which comprises the following steps:
reading original transaction data of a to-be-processed transaction from a transaction request queue and determining a transaction type of the to-be-processed transaction, wherein the transaction type is as follows: financial transactions, notification transactions or local transactions identified by the transaction request processing module, or network management transactions identified by the network management transaction processing module; the transaction processing core of the transaction processing system is divided into at least: the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module and the network management transaction processing module;
when the transaction type is the financial transaction, calling the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow;
when the transaction type is the notification transaction, calling the transaction request processing module, the storage and forwarding module and the transaction reply module to process the original transaction data according to a second preset processing flow;
when the transaction type is the local transaction, calling the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow;
and when the transaction type is a network management transaction, calling the network management transaction processing module to process the original transaction data according to a fourth preset processing flow.
Preferably, when the transaction type is the financial transaction, the step of calling the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow includes:
when the transaction type is the financial transaction, calling the transaction request processing module to split the original transaction data into N sub-transactions, and sequentially routing the sub-transactions to a target downstream system to enable the target downstream system to process the original transaction data to obtain transaction return data;
calling the transaction matching processing module to obtain the transaction return data, updating the original transaction data according to the transaction return data, and recording the transaction running water corresponding to the original transaction data;
and calling the transaction reply module, performing data integration processing and special transaction logic processing on the updated original transaction data, and feeding back the processed updated original transaction data to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
Preferably, the invoking the transaction request processing module to split the original transaction data into N sub-transactions and sequentially route the sub-transactions to a target downstream system, so that the target downstream system processes the original transaction data to obtain transaction return data includes:
calling the transaction request processing module, splitting the original transaction data into N sub-transactions according to a transaction configuration table and a routing configuration table, and determining routing information of each sub-transaction;
and calling the transaction request processing module, and routing the sub-transactions to a target downstream system in sequence according to the routing information so that the target downstream system processes the original transaction data to obtain transaction return data.
Preferably, the method further comprises:
and calling the transaction request processing module to store the original transaction data to a specified database table.
Preferably, the transaction processing core is further divided into a timeout processing module; the method further comprises the following steps:
calling the overtime processing module to scan the specified database table according to a preset period, and determining orthogonal easy data to be flushed, wherein the orthogonal easy data to be flushed is overtime transaction data which needs to be flushed;
calling the storage and forwarding module, and sending the orthogonal and easy data to be flushed to a downstream system corresponding to the storage and forwarding module for processing to obtain a corresponding first response result;
and calling the transaction matching processing module to obtain the first response result and updating the transaction flow according to the first response result.
Preferably, when the transaction type is the notification transaction, according to a second preset processing flow, the step of calling the transaction request processing module, the store-and-forward module, and the transaction reply module to process the original transaction data includes:
when the transaction type is the notification transaction, calling the transaction request processing module, performing transaction splitting and routing configuration on the original transaction data, and recording transaction running water corresponding to the original transaction data;
calling the transaction request processing module, storing the original transaction data subjected to transaction splitting into a storage forwarding table, updating the original transaction data according to routing information obtained by routing configuration, and storing the updated original transaction data into a reply queue;
calling the storage and forwarding module to scan the storage and forwarding table, determining transaction data to be forwarded, and sending the transaction data to be forwarded to a downstream system corresponding to the transaction data to be forwarded for processing to obtain a corresponding second response result;
and calling the transaction matching processing module to obtain the second response result and updating the transaction flow according to the second response result.
Preferably, when the transaction type is the local transaction, according to a third preset processing flow, invoking the transaction request processing module and the transaction reply module to process the original transaction data, including:
when the transaction type is the local transaction, calling the transaction request processing module, and updating the field of the original transaction data by using a preset local transaction processing function;
and calling the transaction reply module to feed back the original transaction data subjected to field updating to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
Preferably, when the transaction type is a network management transaction, according to a fourth preset processing flow, invoking the network management transaction processing module to process the original transaction data, including:
when the transaction type is network management transaction and the transaction to be processed is used for requesting key exchange, calling the network management transaction processing module to check and update a key value carried in the original transaction data, and feeding back the key value subjected to check and update to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
Preferably, the transaction processing core is further divided into a main control module;
before the reading of the raw transaction data of the pending transaction from the transaction request queue and the determination of the transaction type of the pending transaction, the method further includes:
and calling the main control module, and starting the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module, the network management transaction processing module and the timeout processing module.
The second aspect of the embodiment of the present invention discloses a processing apparatus for a transaction flow, the apparatus comprising:
the processing unit is used for reading original transaction data of the transaction to be processed from the transaction request queue and determining the transaction type of the transaction to be processed, wherein the transaction type is as follows: financial transactions, notification transactions or local transactions identified by the transaction request processing module, or network management transactions identified by the network management transaction processing module; the transaction processing core of the transaction processing system is divided into at least: the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module and the network management transaction processing module;
the first calling unit is used for calling the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow when the transaction type is the financial transaction;
the second calling unit is used for calling the transaction request processing module, the storage and forwarding module and the transaction reply module to process the original transaction data according to a second preset processing flow when the transaction type is the notification transaction;
the third calling unit is used for calling the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow when the transaction type is the local transaction;
and the fourth calling unit is used for calling the network management transaction processing module to process the original transaction data according to a fourth preset processing flow when the transaction type is a network management transaction.
Based on the above method and apparatus for processing a transaction flow provided by the embodiments of the present invention, the method includes: reading original transaction data of the transaction to be processed from the transaction request queue and determining the transaction type of the transaction to be processed, wherein the transaction type is obtained by the transaction request processing module or the network management transaction processing module in an identification way; the transaction processing core of the transaction processing system is at least divided into: the system comprises a transaction request processing module, a transaction matching processing module, a transaction reply module, a storage and forwarding module and a network management transaction processing module; when the transaction type is the financial transaction, calling a transaction request processing module, a transaction matching processing module and a transaction reply module to process original transaction data according to a first preset processing flow; when the transaction type is the notification transaction, calling a transaction request processing module, a storage and forwarding module and a transaction reply module to process the original transaction data according to a second preset processing flow; when the transaction type is local transaction, calling a transaction request processing module and a transaction reply module to process original transaction data according to a third preset processing flow; and when the transaction type is network management transaction, calling a network management transaction processing module to process the original transaction data according to a fourth preset processing flow. In the scheme, a transaction processing core of the transaction processing system is divided into a plurality of modules, and transaction types needing to be processed are distinguished. Aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the transaction processing speed and efficiency are improved, and the transaction response time is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a block diagram of a transaction processing system according to an embodiment of the present invention;
fig. 2 is a flowchart of a processing method of a transaction flow according to an embodiment of the present invention;
FIG. 3 is a flow chart of processing financial transactions provided by embodiments of the present invention;
FIG. 4 is a flow chart of processing timeout transactions provided by embodiments of the present invention;
FIG. 5 is a flow diagram for processing a notification transaction provided by an embodiment of the invention;
FIG. 6 is a flow chart of processing local transactions provided by an embodiment of the present invention;
fig. 7 is a block diagram of a processing device of a transaction flow according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
As can be seen from the background art, when a transaction processing system processes a transaction, the transaction is not distinguished, and the function of the transaction processing system is complex and complicated to implement, which all result in a slow transaction processing speed, resulting in a low transaction processing efficiency and a long transaction response time.
Therefore, embodiments of the present invention provide a method and an apparatus for processing a transaction flow, which divide a transaction processing core of a transaction processing system into a plurality of modules and distinguish transaction types to be processed. Aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the transaction processing speed and efficiency are improved, and the transaction response time is reduced.
It should be noted that the transaction flow processing method and device provided by the invention can be used in the field of mobile internet. The above description is only an example, and does not limit the application field of the transaction flow processing method and apparatus provided by the present invention.
It can be understood that the transaction flow processing method and apparatus disclosed in the embodiments of the present invention can be applied to a transaction processing system, for example: a financial intercommunication system (also referred to as a WES system); in order to better understand the contents of the following embodiments of the present invention, the architecture of the transaction processing system is first illustrated by fig. 1, and it should be noted that fig. 1 is only used for illustration.
Referring to fig. 1, there is shown a schematic diagram of an architecture of a transaction processing system provided in an embodiment of the present invention, where the transaction processing system may be a financial intercommunication system; as shown in fig. 1, the financial intercommunication system at least comprises an upstream gateway, a batch module, a transaction processing core, a management module, an encryption machine and a downstream gateway; the transaction processing core is divided into: a transaction request processing module, a transaction matching processing module, a transaction reply module, a store-and-forward module, a network management transaction processing module (composed of a network management transaction receiving module and a network management transmitting module), a main control module (i.e. SWITCH main control in fig. 1) and an overtime processing module.
It can be understood that the financial intercommunication system interacts with the upstream system through the upstream gateway and interacts with the downstream system through the downstream gateway; for the transaction sent by the upstream system in the form of a message, transaction data of the transaction is defined as a data structure body such as JNDATA, and the transaction data is stored in a message queue such as an MQ queue so as to transmit information among modules of the financial intercommunication system, namely JNDATA (namely the transaction data) is written into the message queue, and each module reads the JNDATA from the message queue and performs corresponding processing when required.
It can be understood that in the upstream system, ATMP is an ATM front-end system, IST is a bank card exchange system, BL is a counter front-end system, MCIS-o (abs) is an internet banking system, IPS is an interface platform, and MCIS is a multi-channel access system; in the downstream system, AMLMAS is an anti-money laundering monitoring and analyzing system. GW is a WES gateway module, configured to receive a request message (i.e., a transaction request) from an upstream system and parse the message; GS and SG refer to MQ queues inside the WES system.
The main control module is mainly responsible for starting each module in the transaction processing core according to the configuration file and ensuring that each module in the transaction processing core can be automatically restarted after abnormal operation exits; the transaction request processing module is mainly responsible for processing financial transactions, notification transactions and local transactions, and the transaction request processing module is used for performing transaction splitting and routing on received transactions and adopting different transaction processing modes according to different transaction types; the transaction matching processing module is mainly used for processing the transaction response data returned by the downstream gateway, matching the original transaction and splitting and routing the sub-transaction; a transaction reply module, which adjusts the data content and format of the reply data before sending the reply data (data obtained by processing transaction) to the upstream gateway, and replies the reply data to the source system (namely the upstream system sending transaction) according to different upstream system names; the overtime processing module is responsible for processing overtime transactions; the forwarding storage module is responsible for timing forwarding of the notification transaction; and the network management transaction processing module is used for carrying out key exchange with an upstream system (or an external system) in sequence when receiving the transaction with the transaction type being network management transaction.
It should be noted that, the modules in the transaction processing core operate in an asynchronous operation mode, which can prevent the transaction processing system from operating slowly due to frequent calling of the modules, thereby improving the transaction processing efficiency.
The above description is only a brief introduction to the functions of the modules divided by the transaction processing core, and the functions of the modules divided by the transaction processing core are explained in detail by the contents of the embodiments below.
It should be noted that, when the upstream gateway receives a transaction request message sent by any upstream system, the transaction request message is parsed into JSNDATA, and the JSNDATA is stored in the MQ queue. The main flow of the WES system processing the transaction is as process A1-A5.
A1, analyzing the transaction request message (equivalent to the transaction to be processed) into the original transaction data with JSONATA structure.
A2, WES system processes corresponding transaction processing logic according to transaction type, and updates JSNDATA of the transaction to be processed.
A3, packaging the data from JSDATA data and sending the packaged data to the downstream system.
A4, after receiving the message returned by the downstream system, analyzing the message to obtain response data, matching the response data to the transaction to be processed, and updating the JNDATA of the transaction to be processed by using the response data.
And A5, updating the JSONDATA in A4 by the WES system, packaging the JSONDATA data and returning the packaged data to an upstream system (a source side of the transaction to be processed), and finishing the processing of the transaction to be processed (namely finishing the transaction).
Referring to fig. 2, a flow chart of a processing method of a transaction flow provided by an embodiment of the present invention is shown, the processing method includes:
step S201: raw transaction data for the pending transaction is read from the transaction request queue and a transaction type for the pending transaction is determined.
The transaction types are: financial type transactions, notification transactions or local transactions identified by the transaction request processing module, or network management type transactions identified by the network management transaction processing module.
It should be noted that the financial transaction is a transaction involving account change, such as a transfer transaction initiated by an ATM; the notification transaction is a notification transaction sent to a downstream system, such as a consumption result notification transaction; a local transaction is a transaction that completes processing only within the transaction processing system (i.e., does not need to be sent to downstream systems). If the quota is judged; the network management type transaction is a transaction such as connection detection or key exchange between an upstream system and a downstream system.
The transaction processing core of the transaction processing system is divided into at least: the system comprises a transaction request processing module, a transaction matching processing module, a transaction reply module, a storage and forwarding module, a network management transaction processing module, a main control module and an overtime processing module.
In the process of implementing step S201, the upstream gateway of the transaction processing system stores the original transaction data (data structure is JSNDATA) of the transaction to be processed into a transaction request queue (e.g., a WES _ REQ queue of the WES system).
Calling a transaction request processing module to read the original transaction data from the transaction request queue, identifying the transaction type of the transaction to be processed by analyzing the transaction code of the original transaction data, executing step S202 if the transaction type is identified to be a financial transaction, executing step S203 if the transaction type is identified to be a notification transaction, and executing step S204 if the transaction type is identified to be a local transaction. It can be understood that the network management transaction processing module is also invoked to read the original transaction data from the transaction request queue, and identify the transaction type of the transaction to be processed by parsing the transaction code of the original transaction data, and if the transaction type is identified as the network management type transaction, step S205 is executed.
In some embodiments, after the transaction request processing module is invoked to identify the transaction type of the to-be-processed transaction as a financial transaction, a notification transaction or a local transaction, a unique serial number corresponding to the to-be-processed transaction is generated through the transaction request processing module, and the serial number is stored in the original transaction data.
It can be understood that after the transaction type of the transaction to be processed is identified by the transaction request processing module or the network management transaction processing module, each module in the transaction processing core is invoked to process the original transaction data of the transaction to be processed, which is detailed in the following steps.
Preferably, before executing step S201, the main control module is called, and the transaction request processing module, the transaction matching processing module, the transaction reply module, the store-and-forward module, the network management transaction processing module, and the timeout processing module are started according to the configuration file.
Step S202: and when the transaction type is financial transaction, calling a transaction request processing module, a transaction matching processing module and a transaction reply module to process the original transaction data according to a first preset processing flow.
In the process of implementing step S201 specifically, the transaction request processing module is invoked to split the original transaction data into N (1 or more) sub-transactions, and route the sub-transactions to the target downstream system (the downstream system corresponding to the sub-transactions) in sequence, so that the target downstream system processes the original transaction data to obtain the transaction return data.
In some embodiments, the specific implementation of sequentially routing the sub-transactions to the target downstream system according to the routing information is: and updating the original transaction data and writing the original transaction data into a downstream request queue according to the routing information of the sub-transaction, and reading the original transaction data from the downstream request queue and sending the original transaction data to a target downstream system by a downstream gateway for relevant processing to obtain transaction return data.
It should be noted that, after the sub-transaction is routed to the target downstream system, the transaction request processing module is called to perform quota judgment on the transaction to be processed.
And calling a transaction matching processing module to obtain transaction return data, updating original transaction data according to the transaction return data, and recording transaction running water corresponding to the original transaction data. Specifically, the target downstream system stores the transaction return data into a downstream return queue through a downstream gateway, and calls a transaction matching processing module to read the transaction return data from the downstream return queue; according to the above contents, a serial number is generated for the transaction to be processed, the transaction matching processing module is called to match the original transaction data of the transaction to be processed according to the serial number, the transaction serial corresponding to the original transaction data is recorded in the database serial number, and meanwhile, the quota control table can be updated according to the requirement. It can be understood that if subsequent sub-transactions are not processed, the transaction matching processing module can be called to perform transaction splitting and routing on the subsequent sub-transactions, the split sub-transactions are sequentially sent to a target downstream system through a downstream gateway, and the above process is repeated until the to-be-processed transaction is processed.
After the transaction to be processed is finished, a transaction reply module is called, data integration processing and special transaction logic processing (different transactions have different special transaction logic processing) are carried out on the updated original transaction data, the processed updated original transaction data are fed back to a target upstream system, and the target upstream system is a system for sending the transaction to be processed. Specifically, the updated original transaction data is written into a transaction return queue by the calling transaction matching processing module, the updated original transaction data is read from the transaction return queue by the calling transaction reply module and is subjected to data integration processing and special transaction logic processing, the processed updated original transaction data is written into an upstream gateway queue, and the processed updated original transaction data is fed back to a target upstream system by the upstream gateway in a packaging mode.
To better explain the above process of processing financial transactions, the process is illustrated by the flowchart of processing financial transactions shown in fig. 3, and it should be noted that fig. 3 is only used for illustration.
As shown in fig. 3, the IST is a target upstream system, the upstream gateway stores original transaction data of a transaction to be processed sent by the IST in the WES _ REQ (i.e., a transaction request queue), when the FIN (a transaction request processing module) reads the original transaction data and determines that the transaction type is a financial transaction according to a transaction code, the FIN splits the original transaction data into 1 or more sub-transactions, updates the original transaction data according to routing information of the sub-transactions and writes the updated original transaction data into the HOST _ IPS (downstream request queue), and the downstream gateway reads the original transaction data from the downstream request queue and sends the updated original transaction data to the IPS (target downstream system) for related processing to obtain transaction return data, wherein the IPS returns the transaction return data to the WES _ RSP.
It is understood that the FIN stores the original transaction data into the OVR transaction table (i.e. the designated database table mentioned below), so that the timeout processing module determines whether the transaction corresponding to the data in the OVR transaction table is timed out, and performs corresponding timeout processing.
MAT (transaction matching processing module) obtains transaction return data from WES-RSP, updates original transaction data according to the transaction return data, records transaction flow corresponding to the original transaction data into a database flow meter, and can update a quota control table according to requirements. The MAT writes the updated original transaction data into WES _ HANDLE. The TID (transaction reply module) reads the updated original transaction data from WES _ HANDLE, performs data integration processing and special transaction logic processing on the updated original transaction data, writes the processed updated original transaction data into UPXX _ IST (upstream gateway queue), and feeds the processed updated original transaction data back to IST in a packet mode by the upstream gateway.
Preferably, the transaction request processing module is invoked to store the original transaction data in the specified database table (i.e. in the OVR transaction table in fig. 3), so that the timeout processing module determines whether the transaction corresponding to the data in the specified database table is timeout or not, and performs corresponding timeout processing.
The specific process of the overtime processing module for judging the overtime transaction and carrying out overtime processing is as follows:
calling an overtime processing module to scan an appointed database table according to a preset period, and determining orthogonal easy data to be flushed, wherein the orthogonal easy data to be flushed is overtime and transaction data which needs to be flushed; specifically, the overtime processing module is called to scan the specified database table according to the preset period, determine whether overtime transaction data (corresponding to overtime transactions) exist, and judge whether the transaction data needs to be aligned according to whether the overtime transaction data carries an alignment mark.
It should be noted that when the transaction data is written into a specified database table (such as the OVR transaction table in fig. 3), it needs to be determined whether the transaction data needs to be flushed according to the transaction type corresponding to the transaction data, and if the transaction data needs to be flushed (e.g., the transaction data related to the account debit needs to be flushed when the time is out), an flushing flag is carried in an OVR table field of the transaction data.
Calling a storage and forwarding module, and sending the orthogonal and easy data to be flushed to a downstream system corresponding to the storage and forwarding module for processing to obtain a corresponding first response result; specifically, an overtime processing module is called to store orthogonal easy data to be flushed into a storage forwarding table, and then the storage forwarding table is called to scan the storage forwarding table at regular time to acquire the orthogonal easy data to be flushed; and calling a storage and forwarding module to send the orthogonal and easy data to be flushed to a downstream gateway request queue, and sending the orthogonal and easy data to be flushed in the downstream gateway request queue to a downstream system corresponding to the downstream gateway in a packet mode by the downstream gateway for processing to obtain a corresponding first response result.
Calling a transaction matching processing module to obtain a first response result and updating the transaction flow according to the first response result; specifically, the downstream gateway disassembles the first response result and sends the first response result to the transaction response queue, calls the transaction matching processing module to obtain the first response result from the transaction response queue, matches the first response result with the original transaction data of the transaction to be processed, updates the transaction flow of the original transaction data according to the first response result, and can update the quota control table according to actual demands.
It should be noted that if there are subsequent sub-transactions, the transaction matching processing module may be invoked to perform transaction splitting and routing on the subsequent sub-transactions, and the split sub-transactions are sequentially sent to the corresponding downstream system through the downstream gateway, and after the processing of the to-be-processed transaction is completed, the records in the storage forwarding table are deleted.
To better explain the above-mentioned timeout transaction process, the timeout transaction processing flowchart shown in fig. 4 is used for illustration, and it should be noted that fig. 4 is used for illustration only.
As shown in fig. 4, the OVR (timeout processing module) scans an OVR transaction table (designated database table) according to a preset period, determines orthogonal easy data to be flushed, and stores the orthogonal easy data to be flushed in a storage forwarding table. The STR (store and forward module) regularly scans a store and forward table, sends orthogonal and easy data to be flushed to downstream gateway request queues (HOST _ IPS and HOST _ ABS) according to a target downstream system corresponding to the orthogonal and easy data to be flushed, and sends the orthogonal and easy data to be flushed to downstream systems such as ABS and IPS through a downstream gateway. And the downstream gateway receives the first response result fed back by the downstream system, disassembles the first response result and then sends the disassembled first response result to the WES _ RSP (transaction response queue). And calling a transaction matching processing module to obtain a first response result from the WES _ RSP, matching the first response result with the original transaction data of the transaction to be processed, updating a transaction flow (namely updating a flow meter) of the original transaction data according to the first response result, and updating the quota control table according to actual requirements.
Step S203: and when the transaction type is the notification transaction, calling the transaction request processing module, the storage and forwarding module and the transaction reply module to process the original transaction data according to a second preset processing flow.
In the process of implementing step S203 specifically, when the transaction type is notification transaction, a transaction request processing module is called to read original transaction data of the transaction to be processed from the transaction request queue, perform transaction splitting and routing configuration on the original transaction data, and record transaction flow corresponding to the original transaction data.
Calling a transaction request processing module, storing original transaction data subjected to transaction splitting into a storage forwarding table, updating the original transaction data according to routing information obtained by routing configuration, and storing the updated original transaction data into a reply queue; specifically, the routing information is updated into the original transaction data (data structure JSNDATA).
Calling a store-and-forward module to scan a store-and-forward table, determining transaction data to be forwarded, and sending the transaction data to be forwarded to a downstream system corresponding to the transaction data to be forwarded for processing to obtain a corresponding second response result; specifically, the method is described. And for the transaction data to be forwarded, storing the transaction data to be forwarded to a downstream gateway request queue, sending the transaction data to be forwarded to a downstream system corresponding to the downstream gateway by the downstream gateway for processing to obtain a corresponding second response result, and sending the second response result to the transaction response queue by the downstream gateway after the downstream gateway receives the second response result returned by the downstream system.
Calling a transaction matching processing module to obtain a second response result and updating the transaction running water corresponding to the original transaction data according to the second response result; specifically, the transaction matching processing module is called to obtain the second response result from the transaction response queue and match the second response result with the original transaction data, and the transaction flow corresponding to the original transaction data is updated, so that the quota control table can be selected and updated according to actual requirements.
It should be noted that if there are subsequent sub-transactions, the transaction matching processing module may be invoked to perform transaction splitting and routing on the subsequent sub-transactions, and the split sub-transactions are sequentially sent to the corresponding downstream system through the downstream gateway, and after the processing of the to-be-processed transaction is completed, the records in the storage forwarding table are deleted.
To better explain the above timeout transaction process, the above flowchart of processing the notification transaction is illustrated in fig. 5, and it should be noted that fig. 5 is only for illustration.
As shown in fig. 5, the IST is a target upstream system, the upstream gateway stores original transaction data of a to-be-processed transaction sent by the IST in the WES _ REQ (i.e., a transaction request queue), the FIN (a transaction request processing module) reads the original transaction data and determines that the transaction type is a notification transaction according to a transaction code, the FIN performs transaction splitting and routing configuration on the original transaction data, records transaction flow corresponding to the original transaction data, stores the original transaction data subjected to transaction splitting into a storage forwarding table, updates the original transaction data according to routing information obtained by the routing configuration, and stores the updated original transaction data into the WES _ hash (i.e., a reply queue). STR (store and forward module) scans the store and forward table at regular time, determines the transaction data to be forwarded, stores the transaction data to be forwarded to a downstream gateway request queue (such as HOST _ IPS and HOST _ ABS in fig. 5), the downstream gateway sends the transaction data to be forwarded to a downstream system corresponding to the downstream gateway in a packet mode to process the transaction data to obtain a corresponding second response result, and after receiving the second response result returned by the downstream system, the downstream gateway disassembles the second response result and sends the second response result to a transaction response queue (WES _ RSP). And the MAT (transaction matching processing module) acquires a second response result from the WES-RSP, updates the transaction flow corresponding to the original transaction data according to the second response result, and can selectively update the quota control table according to actual requirements.
Step S204: and when the transaction type is local transaction, calling a transaction request processing module and a transaction reply module to process the original transaction data according to a third preset processing flow.
In the process of implementing the step S204 specifically, when the transaction type is a local transaction, a transaction request processing module is called, and field updating is performed on the original transaction data by using a preset local transaction processing function; specifically, calling a transaction request processing module to read local transaction control table information, and performing field updating on original transaction data with a data format of JSDATA by using a preset local transaction processing function; and storing the original transaction data subjected to the field updating in a reply queue.
Calling a transaction reply module to feed back the original transaction data subjected to field updating to a target upstream system; specifically, the transaction reply module is called to read original transaction data subjected to field updating from the reply queue, the original transaction data is subjected to transaction internal logic processing and then is stored in the return queue, and the original transaction data in the return queue is fed back to the target upstream system by the upstream gateway.
To better explain the above process of the timeout transaction, the process of processing the local transaction is illustrated by the flowchart shown in fig. 6, and it should be noted that fig. 6 is only used for illustration.
When the transaction type is local transaction, acquiring original transaction data from WES _ REQ by a FIN (transaction request processing module), reading a local transaction control table by the FIN, and updating the field of the original transaction data by using a local transaction processing function; the original transaction data after field update is saved in a WES _ HANDLE (reply queue). The TID (transaction reply module) reads the original transaction data with updated field from the WES _ HANDLE, performs internal logic processing on the original transaction data, and then stores the processed data in the UPXX _ IST (return queue), and the upstream gateway feeds back the original transaction data in the UPXX _ IST to the IST (i.e., the target upstream system in this example).
Step S205: and when the transaction type is network management transaction, calling a network management transaction processing module to process the original transaction data according to a fourth preset processing flow.
It should be noted that the network management type transaction generally includes: network TEST (ECHO-TEST, ECT), key exchange request (KEQ), Key Exchange (KEX), check-in and check-out, etc. The transaction processing system (e.g., WES system) engages a key when connected to both the upstream system and the downstream system, the key is used to cryptographically protect the personal data involved in the transaction, and the transaction is allowed to proceed normally when the key of the transaction processing system and the upstream system (or the downstream system) are verified to be consistent. When the Key is exchanged, the PIN _ Key and the MAC _ Key are exchanged at the same time.
In the process of implementing step S205 specifically, when the transaction type is a network management type transaction and when the transaction to be processed is used to request to exchange the key, that is, when the transaction to be processed is used to request to exchange the key, a network management transaction processing module is invoked to check and update the key value carried in the original transaction data, and the key value after being checked and updated is fed back to the target upstream system, which is a system that sends the transaction to be processed.
It can be understood that the network management transaction processing module is composed of a network management transaction receiving module and a network management sending module, and in a specific implementation, the network management transaction receiving module is invoked to read original transaction data from a transaction request queue (i.e., the WES _ REQ in the above examples of fig. 3 to 6); the method comprises the steps that a network management sending module is called to check and update a key value carried in original transaction data, and the key value after check and update is written into a transaction return queue; and feeding back the key value which is subjected to checksum updating in the transaction return queue to the target upstream system by the upstream gateway.
In the embodiment of the invention, the transaction processing core of the transaction processing system is divided into a plurality of modules, and the types of transactions needing to be processed are distinguished. Aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the transaction processing speed and efficiency are improved, and the transaction response time is reduced.
Corresponding to the method for processing a transaction flow provided by the embodiment of the present invention, referring to fig. 7, an embodiment of the present invention further provides a block diagram of a processing apparatus for a transaction flow, where the processing apparatus includes: a processing unit 701, a first calling unit 702, a second calling unit 703, a third calling unit 704 and a fourth calling unit 705;
a processing unit 701, configured to read original transaction data of a to-be-processed transaction from the transaction request queue and determine a transaction type of the to-be-processed transaction, where the transaction type is: financial transactions, notification transactions or local transactions identified by the transaction request processing module, or network management transactions identified by the network management transaction processing module; the transaction processing core of the transaction processing system is divided into at least: the system comprises a transaction request processing module, a transaction matching processing module, a transaction reply module, a storage and forwarding module and the network management transaction processing module.
The first invoking unit 702 is configured to, when the transaction type is a financial transaction, invoke the transaction request processing module, the transaction matching processing module, and the transaction replying module to process the original transaction data according to a first preset processing flow.
In a specific implementation, the first invoking unit 702 is specifically configured to: when the transaction type is financial transaction, calling a transaction request processing module to divide original transaction data into N sub-transactions, and sequentially routing the sub-transactions to a target downstream system to enable the target downstream system to process the original transaction data to obtain transaction return data; calling a transaction matching processing module to obtain transaction return data, updating original transaction data according to the transaction return data, and recording transaction running water corresponding to the original transaction data; and calling a transaction reply module, performing data integration processing and special transaction logic processing on the updated original transaction data, and feeding back the processed updated original transaction data to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
In a specific implementation, the original transaction data is divided into N sub-transactions, and the sub-transactions are sequentially routed to the first call unit 702 of the target downstream system, which is specifically configured to: calling a transaction request processing module, splitting original transaction data into N sub-transactions according to a transaction configuration table and a routing configuration table, and determining routing information of each sub-transaction; and calling a transaction request processing module, and routing the sub-transactions to a target downstream system in sequence according to the routing information so that the target downstream system processes the original transaction data to obtain transaction return data.
Preferably, the first invoking unit 702 is further configured to: and calling a transaction request processing module to store the original transaction data to a specified database table.
The second invoking unit 703 is configured to invoke the transaction request processing module, the store-and-forward module, and the transaction reply module to process the original transaction data according to a second preset processing flow when the transaction type is the notification transaction.
In a specific implementation, the second calling unit 703 is specifically configured to: when the transaction type is the notification transaction, a transaction request processing module is called, transaction splitting and routing configuration are carried out on original transaction data, and transaction running water corresponding to the original transaction data is recorded; calling a transaction request processing module, storing original transaction data subjected to transaction splitting into a storage forwarding table, updating the original transaction data according to routing information obtained by routing configuration, and storing the updated original transaction data into a reply queue; calling a store-and-forward module to scan a store-and-forward table, determining transaction data to be forwarded, and sending the transaction data to be forwarded to a downstream system corresponding to the transaction data to be forwarded for processing to obtain a corresponding second response result; and calling the transaction matching processing module to obtain a second response result and updating the transaction flow according to the second response result.
The third invoking unit 704 is configured to invoke the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow when the transaction type is a local transaction.
In a specific implementation, the third invoking unit 704 is specifically configured to: when the transaction type is local transaction, calling a transaction request processing module, and updating the field of the original transaction data by using a preset local transaction processing function; and calling a transaction reply module to feed back the original transaction data subjected to the field updating to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
The fourth invoking unit 705 is configured to invoke the network management transaction processing module to process the original transaction data according to a fourth preset processing flow when the transaction type is the network management transaction type.
In a specific implementation, the fourth invoking unit 705 is specifically configured to: when the transaction type is network management transaction and the transaction to be processed is used for requesting key exchange, a network management transaction processing module is called to check and update a key value carried in original transaction data, the key value subjected to check and update is fed back to a target upstream system, and the target upstream system is a system for sending the transaction to be processed.
In the embodiment of the invention, the transaction processing core of the transaction processing system is divided into a plurality of modules, and the types of transactions needing to be processed are distinguished. Aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the transaction processing speed and efficiency are improved, and the transaction response time is reduced.
Preferably, in conjunction with the content shown in fig. 7, the transaction processing core further divides the timeout processing module, and the processing device further includes:
the fifth calling unit is used for calling the overtime processing module to scan the specified database table according to the preset period and determine orthogonal easy data to be flushed, wherein the orthogonal easy data to be flushed is overtime and transaction data which needs to be flushed; calling a storage and forwarding module, and sending the orthogonal and easy data to be flushed to a downstream system corresponding to the storage and forwarding module for processing to obtain a corresponding first response result; and calling a transaction matching processing module to obtain a first response result and updating the transaction flow according to the first response result.
Preferably, in conjunction with the content shown in fig. 7, the transaction processing core further divides the main control module, and the processing apparatus further includes:
the starting unit is used for calling the main control module, and starting the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module, the network management transaction processing module and the overtime processing module.
In summary, embodiments of the present invention provide a method and an apparatus for processing a transaction flow, which divide a transaction processing core of a transaction processing system into a plurality of modules and distinguish transaction types to be processed. Aiming at transactions of different transaction types, a module of a transaction processing core is called according to a corresponding preset processing flow to process the transactions, so that the decoupling of the function realization of a transaction processing system is realized, the transaction processing speed and efficiency are improved, and the transaction response time is reduced.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments, which are substantially similar to the method embodiments, are described in a relatively simple manner, and reference may be made to some descriptions of the method embodiments for relevant points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Those of skill would further appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the components and steps of the various examples have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A method for processing a transaction flow, the method comprising:
reading original transaction data of a to-be-processed transaction from a transaction request queue and determining a transaction type of the to-be-processed transaction, wherein the transaction type is as follows: financial transactions, notification transactions or local transactions identified by the transaction request processing module, or network management transactions identified by the network management transaction processing module; the transaction processing core of the transaction processing system is divided into at least: the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module and the network management transaction processing module;
when the transaction type is the financial transaction, calling the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow;
when the transaction type is the notification transaction, calling the transaction request processing module, the storage and forwarding module and the transaction reply module to process the original transaction data according to a second preset processing flow;
when the transaction type is the local transaction, calling the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow;
and when the transaction type is a network management transaction, calling the network management transaction processing module to process the original transaction data according to a fourth preset processing flow.
2. The method according to claim 1, wherein when the transaction type is the financial transaction, invoking the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow, comprising:
when the transaction type is the financial transaction, calling the transaction request processing module to split the original transaction data into N sub-transactions, and sequentially routing the sub-transactions to a target downstream system to enable the target downstream system to process the original transaction data to obtain transaction return data;
calling the transaction matching processing module to obtain the transaction return data, updating the original transaction data according to the transaction return data, and recording transaction running water corresponding to the original transaction data;
and calling the transaction reply module, performing data integration processing and special transaction logic processing on the updated original transaction data, and feeding back the processed updated original transaction data to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
3. The method of claim 2, wherein the invoking the transaction request processing module splits the original transaction data into N sub-transactions and sequentially routes the sub-transactions to a target downstream system, such that the target downstream system processes the original transaction data to obtain transaction return data, comprising:
calling the transaction request processing module, splitting the original transaction data into N sub-transactions according to a transaction configuration table and a routing configuration table, and determining routing information of each sub-transaction;
and calling the transaction request processing module, and routing the sub-transactions to a target downstream system in sequence according to the routing information so that the target downstream system processes the original transaction data to obtain transaction return data.
4. The method of claim 2, further comprising:
and calling the transaction request processing module to store the original transaction data to a specified database table.
5. The method of claim 4, wherein the transaction processing core further divides a timeout processing module; the method further comprises the following steps:
calling the overtime processing module to scan the specified database table according to a preset period, and determining orthogonal easy data to be flushed, wherein the orthogonal easy data to be flushed is overtime transaction data which needs to be flushed;
calling the storage and forwarding module, and sending the orthogonal and easy data to be flushed to a downstream system corresponding to the storage and forwarding module for processing to obtain a corresponding first response result;
and calling the transaction matching processing module to obtain the first response result and updating the transaction flow according to the first response result.
6. The method according to claim 1, wherein when the transaction type is the notification transaction, according to a second preset processing flow, invoking the transaction request processing module, the store-and-forward module, and the transaction reply module to process the original transaction data, including:
when the transaction type is the notification transaction, calling the transaction request processing module, performing transaction splitting and routing configuration on the original transaction data, and recording transaction running water corresponding to the original transaction data;
calling the transaction request processing module, storing the original transaction data subjected to transaction splitting into a storage forwarding table, updating the original transaction data according to routing information obtained by routing configuration, and storing the updated original transaction data into a reply queue;
the storage forwarding module is called to scan the storage forwarding table, transaction data to be forwarded are determined, and the transaction data to be forwarded are sent to a downstream system corresponding to the transaction data to be forwarded to be processed to obtain a corresponding second response result;
and calling the transaction matching processing module to obtain the second response result and updating the transaction flow according to the second response result.
7. The method according to claim 1, wherein when the transaction type is the local transaction, invoking the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow, comprising:
when the transaction type is the local transaction, calling the transaction request processing module, and updating the field of the original transaction data by using a preset local transaction processing function;
and calling the transaction reply module to feed back the original transaction data subjected to field updating to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
8. The method according to claim 1, wherein when the transaction type is a network management type transaction, invoking the network management transaction processing module to process the original transaction data according to a fourth preset processing flow, comprising:
when the transaction type is network management transaction and the transaction to be processed is used for requesting key exchange, calling the network management transaction processing module to check and update a key value carried in the original transaction data, and feeding back the key value subjected to check and update to a target upstream system, wherein the target upstream system is a system for sending the transaction to be processed.
9. The method of claim 5, wherein the transaction processing core further divides a master control module;
before the reading of the raw transaction data of the pending transaction from the transaction request queue and the determination of the transaction type of the pending transaction, the method further includes:
and calling the main control module, and starting the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module, the network management transaction processing module and the timeout processing module.
10. An apparatus for processing a transaction flow, the apparatus comprising:
the processing unit is used for reading original transaction data of the transaction to be processed from the transaction request queue and determining the transaction type of the transaction to be processed, wherein the transaction type is as follows: financial transactions, notification transactions or local transactions identified by the transaction request processing module, or network management transactions identified by the network management transaction processing module; the transaction processing core of the transaction processing system is at least divided into: the transaction request processing module, the transaction matching processing module, the transaction reply module, the storage and forwarding module and the network management transaction processing module;
the first calling unit is used for calling the transaction request processing module, the transaction matching processing module and the transaction reply module to process the original transaction data according to a first preset processing flow when the transaction type is the financial transaction;
the second calling unit is used for calling the transaction request processing module, the storage and forwarding module and the transaction reply module to process the original transaction data according to a second preset processing flow when the transaction type is the notification transaction;
the third calling unit is used for calling the transaction request processing module and the transaction reply module to process the original transaction data according to a third preset processing flow when the transaction type is the local transaction;
and the fourth calling unit is used for calling the network management transaction processing module to process the original transaction data according to a fourth preset processing flow when the transaction type is a network management transaction.
CN202111407257.5A 2021-11-24 2021-11-24 Transaction flow processing method and device Pending CN114092248A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111407257.5A CN114092248A (en) 2021-11-24 2021-11-24 Transaction flow processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111407257.5A CN114092248A (en) 2021-11-24 2021-11-24 Transaction flow processing method and device

Publications (1)

Publication Number Publication Date
CN114092248A true CN114092248A (en) 2022-02-25

Family

ID=80304334

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111407257.5A Pending CN114092248A (en) 2021-11-24 2021-11-24 Transaction flow processing method and device

Country Status (1)

Country Link
CN (1) CN114092248A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114584629A (en) * 2022-05-07 2022-06-03 中国光大银行股份有限公司 Transaction message processing method and device
CN115134411A (en) * 2022-06-27 2022-09-30 中国银行股份有限公司 System processing method and device based on message queue

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114584629A (en) * 2022-05-07 2022-06-03 中国光大银行股份有限公司 Transaction message processing method and device
CN115134411A (en) * 2022-06-27 2022-09-30 中国银行股份有限公司 System processing method and device based on message queue

Similar Documents

Publication Publication Date Title
CN114092248A (en) Transaction flow processing method and device
CN112000730B (en) Tracing information writing and tracing information verification method and system based on block chain
CN107135188B (en) Method, device and system for realizing services of financial information exchange (FIX) protocol
EP3816912B1 (en) Blockchain-based transaction processing method and apparatus, and electronic device
EP0090016A1 (en) Apparatus for routing data amoung low order units and a high order host computer system
CN115859343A (en) Transaction data processing method and device and readable storage medium
CN108959465B (en) Method and device for storing and reading service data and server
CN114328348A (en) FPGA acceleration board card and market data processing method thereof
CN113626218A (en) Data processing method, data processing device, storage medium and computer equipment
CN112258184B (en) Method, apparatus, electronic device and readable storage medium for freezing blockchain network
CN113691618A (en) Message notification method, device, message center and storage medium
CN106130740B (en) Digital certificate synchronous method, digital signature server and digital certificate synchronization system
CN111381985B (en) Heterogeneous system data calling method, device, equipment and storage medium
CN114006927B (en) Service message processing method and processing device thereof, electronic equipment and storage medium
CN114793246A (en) Method and device for processing transaction message
JP2020166554A (en) Customer data maintenance system, method, and program
CN114942957A (en) Method and device for forwarding transaction message
CN111199393B (en) Account entering method, device and equipment for single information transaction
CN114490781B (en) Block chain data processing method and device
JP7347779B2 (en) Transfer management system, transfer management method and program
CN110032569B (en) Method, device, equipment and system for checking changed data
CN111222872A (en) User piece-entering method, device and system based on payment channel
CN111638954A (en) Virtual resource allocation method and device and electronic equipment
CN117235163A (en) Service processing method, device, equipment and storage medium
CN115470174A (en) Route generation method and device, many-core system and computer readable medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination