Transaction processing method and device

Abstract

The embodiment of the present invention provides a transaction processing method and device, which relates to the field of data processing technology, including: receiving a first transaction request of a user sent by a transaction platform, selecting a first thread from a thread pool; calling the first thread to determine a first rule from a rule set defined based on a rule engine, converting the first transaction request into a second transaction request in a first format based on the first rule, selecting a target transaction processing node according to the load information of each transaction processing node, and forwarding the second transaction request to the target transaction processing node; after monitoring the transaction feedback sent by the target transaction processing node, re-calling the first thread to generate a first transaction state based on the transaction feedback, determining a second rule from the rule set, converting the first transaction state into a second transaction state in a second format supported by the transaction platform based on the second rule, and sending the second transaction state to the transaction platform. The solution provided by the embodiment of the present invention can be used to achieve docking with various transaction platforms.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a transaction processing method and device. Background Art

[0002] Currently, more and more users hope to manage their own funds through securities trading. Therefore, users often submit their transaction requests to the order management system through various trading platforms, and then the order management system helps users complete the transaction according to the user's transaction request.

[0003] Since there are many types of trading platforms on the market, the order management system needs to be connected with various trading platforms. In order to ensure that the order management system can smoothly connect with various trading platforms and successfully complete the user's transaction request, it is necessary to provide a transaction processing solution that can support connection with various types of trading platforms. Summary of the invention

[0004] The purpose of the embodiment of the present invention is to provide a transaction processing method and device to achieve docking with various transaction platforms. The specific technical solution is as follows:

[0005] In a first aspect, an embodiment of the present invention provides a transaction processing method, the method comprising:

[0006] Receive a first transaction request from a user sent by the transaction platform, and select a first thread from a thread pool for processing the first transaction request;

[0007] The first thread is called to determine a first rule that matches the trading platform and is used to convert the format of the trading request from a rule set defined based on a rule engine, convert the first trading request into a second trading request in a first format based on the first rule, and select a target trading processing node for processing the second trading request according to load information of each trading processing node, and forward the second trading request to the target trading processing node, wherein the first format is: a unified format supported by all rules in the rule set;

[0008] After monitoring the transaction feedback sent by the target transaction processing node, the first thread is re-invoked to generate a first transaction state based on the transaction feedback, a second rule that matches the transaction platform and is used to convert the format of the transaction state is determined from the rule set, the first transaction state is converted into a second transaction state in a second format supported by the transaction platform based on the second rule, and the second transaction state is sent to the transaction platform.

[0009] In one embodiment of the present invention, the method further comprises:

[0010] Monitoring update instructions for rules in the rule set;

[0011] If a target update instruction in the form of a command line is monitored, the rules to be updated indicated by the target update instruction are updated in the memory according to the target update instruction;

[0012] The updated rules to be updated are written back to the rule set.

[0013] In one embodiment of the present invention, the target update instruction is used to implement at least one of the following functions:

[0014] Updating the enabled state of the rule to be updated;

[0015] Updating the execution priority of the rule to be updated;

[0016] Adding the rule to be updated to the rule set;

[0017] Deleting the rule to be updated from the rule set;

[0018] Modify the rule to be updated.

[0019] In one embodiment of the present invention, the method further comprises:

[0020] receiving a cancellation instruction of the user for the first transaction request sent by the transaction platform;

[0021] determining whether the second transaction request has been sent to the target transaction processing node;

[0022] If not, instructing the first thread to refuse to send the second transaction request to the target transaction processing node;

[0023] If yes, the first thread is instructed to forward the cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

[0024] In one embodiment of the present invention, the method further comprises:

[0025] receiving a modification instruction of the user to the first transaction request sent by the transaction platform;

[0026] determining whether the second transaction request has been sent to the target transaction processing node;

[0027] If not, instructing the first thread to refuse to send the second transaction request to the target transaction processing node, and modifying the second transaction request according to the modification instruction, and sending the modified second transaction request to the target transaction processing node;

[0028] If yes, instruct the first thread to send a cancellation instruction for the first transaction request to the transaction processing node, receive cancellation feedback for the first transaction request sent by the target transaction processing node, and send a modification instruction updated based on the cancellation feedback to the target transaction processing node, so that the target transaction processing node performs the transaction according to the updated modification instruction.

[0029] In a second aspect, an embodiment of the present invention provides a transaction processing device, the device comprising:

[0030] A transaction request receiving module, configured to receive a first transaction request from a user sent by a transaction platform, and select a first thread from a thread pool for processing the first transaction request;

[0031] a transaction request conversion module, configured to call the first thread to determine a first rule that matches the transaction platform and is used to convert the format of the transaction request from a rule set defined based on a rule engine, convert the transaction request into a second transaction request in a first format based on the first rule, select a target transaction processing node for processing the second transaction request according to load information of each transaction processing node, and forward the second transaction request to the target transaction processing node, wherein the first format is: a unified format supported by all rules in the rule set;

[0032] A transaction status sending module is used to, after listening to the transaction feedback sent by the target transaction processing node, re-call the first thread to generate a first transaction status based on the transaction feedback, determine from the rule set a second rule that matches the transaction platform and is used to convert the format of the transaction status, convert the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and send the second transaction status to the transaction platform.

[0033] In one embodiment of the present invention, the device further comprises:

[0034] An update instruction monitoring module, used for monitoring update instructions for rules in the rule set;

[0035] A rule updating module, configured to update the to-be-updated rule indicated by the target update instruction in the memory according to the target update instruction if a target update instruction in the form of a command line is monitored;

[0036] The update rule writing back module is used to write the updated rules to be updated back to the rule set.

[0037] In one embodiment of the present invention, the target update instruction is used to implement at least one of the following functions:

[0038] Updating the enabled state of the rule to be updated;

[0039] Updating the execution priority of the rule to be updated;

[0040] Adding the rule to be updated to the rule set;

[0041] Deleting the rule to be updated from the rule set;

[0042] Modify the rule to be updated.

[0043] In one embodiment of the present invention, the device further comprises:

[0044] a cancellation instruction receiving module, configured to receive a cancellation instruction of the user for the first transaction request sent by the transaction platform;

[0045] A transaction request judgment module, used to judge whether the second transaction request has been sent to the target transaction processing node, and if so, trigger the rejection sending module; if not, trigger the cancellation instruction forwarding module;

[0046] A first sending rejection module, configured to instruct the first thread to refuse to send the second transaction request to the target transaction processing node;

[0047] The cancellation instruction sending module is used to instruct the first thread to forward the cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

[0048] In one embodiment of the present invention, the device further comprises:

[0049] A modification instruction receiving module, used for receiving a modification instruction of the user to the first transaction request sent by the transaction platform;

[0050] a transaction request determination module, configured to determine whether the second transaction request has been sent to the target transaction processing node, and if not, trigger the second rejection sending module; and if yes, trigger the modification instruction sending module;

[0051] a second rejection sending module, configured to instruct the first thread to refuse to send the second transaction request to the target transaction processing node, and to modify the second transaction request according to the modification instruction, and to send the modified second transaction request to the target transaction processing node;

[0052] A modification instruction sending module is used to instruct the first thread to send a cancellation instruction for the first transaction request to the transaction processing node, receive cancellation feedback for the first transaction request sent by the target transaction processing node, and send a modification instruction updated based on the cancellation feedback to the target transaction processing node, so that the target transaction processing node performs the transaction according to the updated modification instruction.

[0053] In a third aspect, an embodiment of the present invention provides an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0054] Memory, used to store computer programs;

[0055] The processor is used to implement the transaction processing method described in the first aspect when executing the program stored in the memory.

[0056] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the transaction processing method described in the first aspect is implemented.

[0057] In a fifth aspect, an embodiment of the present invention provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the transaction processing method described in the first aspect above.

[0058] It can be seen from the above that when the solution provided by the embodiment of the present invention is applied to perform transaction processing, the first process adopts the first rule to convert the first transaction request sent by the transaction platform into a second transaction request in a unified format, so that the second transaction request is sent to the target transaction processing node, so that the target transaction processing node can process the second transaction request according to the processing logic for the same format. This not only ensures that the transaction processing node can execute the transaction smoothly, but also makes the processing logic supported by the transaction processing node single, which can effectively prevent the transaction processing node from being complex and diverse.

[0059] In addition, after receiving the first transaction status fed back by the target transaction processing node, the second rule is used to convert the first transaction status into a second transaction status in a data format supported by the transaction platform, so that the transaction platform can successfully identify the second transaction status.

[0060] Furthermore, since the first rule is a rule that matches the trading platform, different first rules can be used to convert the format of the transaction request for different trading platforms, but the final converted format is the above-mentioned unified format. Therefore, the solution provided by the embodiment of the present invention is used for transaction processing, which can achieve docking with various trading platforms.

[0061] Of course, it is not necessary to achieve all of the advantages described above at the same time to implement any product or method of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0063] Figure 1 A schematic diagram of a flow chart of a first transaction processing method provided by an embodiment of the present invention;

[0064] Figure 2 A schematic diagram of a flow chart of a second transaction processing method provided by an embodiment of the present invention;

[0065] Figure 3 A schematic diagram of a flow chart of a third transaction processing method provided by an embodiment of the present invention;

[0066] Figure 4 A structural block diagram of an order management processing system provided by an embodiment of the present invention;

[0067] Figure 5 A schematic diagram of the structure of a first transaction processing device provided by an embodiment of the present invention;

[0068] Figure 6 A schematic diagram of the structure of a second transaction processing device provided by an embodiment of the present invention;

[0069] Figure 7 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0070] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field based on this application belong to the scope of protection of the present invention.

[0071] First, some concepts involved in the solutions provided in the embodiments of the present invention are explained.

[0072] User: The subject who issues a transaction request and entrusts the transaction request to the trading platform.

[0073] Trading platform: The entity that receives user transaction requests and sends them to the order management system.

[0074] Order management system: processes the transaction requests received from users and forwards them to the transaction processing nodes to help users complete transactions.

[0075] Transaction processing node: forms a transaction order based on the transaction request and submits the transaction order to the stock exchange for trading. Stock exchange: the trading institution where the transaction is actually carried out, such as the Shanghai Stock Exchange, Shenzhen Stock Exchange, etc.

[0076] The application scenarios of the embodiments of the present invention are described below.

[0077] The application scenario of the embodiment of the present invention is a scenario where an order management system is connected to various trading platforms.

[0078] Users can submit their transaction requests to the order management system through various trading platforms, and then the order management system helps users complete transactions according to their transaction requests. However, different trading platforms may support different data formats when sending transaction requests, so different trading platforms may send different data formats of transaction requests to the order management system. In view of the above situation, an embodiment of the present invention provides a transaction processing method to achieve the connection between the order management system and various trading platforms.

[0079] The following is a description of the implementation of the solution provided by the embodiment of the present invention:

[0080] The execution subject of the solution provided by the embodiment of the present invention may be an electronic device installed with an order management system. Specifically, the execution subject of the solution provided by the embodiment of the present invention may be a main thread created by the above electronic device.

[0081] In order to clearly illustrate the solution provided by the embodiment of the present invention, the solution provided by the embodiment of the present invention is described below in a manner of interaction between a main thread and other threads.

[0082] The transaction processing method provided by the embodiment of the present invention is described in detail below.

[0083] See also Figure 1 , Figure 1 This is a flow chart of a first transaction processing method provided by an embodiment of the present invention. The method includes the following steps S101 to S108.

[0084] Step S101: the main thread receives a first transaction request from a user sent by a transaction platform, and selects a first thread for processing the first transaction request from a thread pool.

[0085] The first transaction request may include information such as the transaction object, transaction amount, transaction time period, etc.

[0086] Specifically, after receiving the first transaction request, the main thread may add the first transaction request to the task queue, and select a thread in an idle state as the first thread for processing the first transaction request in the task queue by polling each thread in the pre-created thread pool. Of course, a thread that meets a preset thread selection condition may also be selected according to the busyness of each thread as the first thread. For example, the thread selection condition may be to select a thread with the smallest busyness, or to select a thread with a busyness less than a preset busyness threshold, etc.

[0087] It should be noted that the above-mentioned order management system can run on a single electronic device or in a distributed system including multiple electronic devices. The threads in the above-mentioned thread pool and the above-mentioned main thread can be threads created by the same device or threads created by different devices.

[0088] Step S102: the main thread calls the first thread.

[0089] After selecting the first thread from the thread pool, the main thread calls the first thread, so that the first thread can start processing the first transaction request.

[0090] After the main thread successfully calls the first thread, in order to facilitate calling the first thread again later, the main thread may record the corresponding relationship between the first interaction request and the first thread.

[0091] Step S103: The first thread determines a first rule that matches the trading platform and is used to convert the format of the trading request from a rule set defined based on the rule engine.

[0092] A rule engine is a component that can be embedded in an application and can separate business decisions from application code, thus decoupling business logic from code. For example, the rule engine can be a Drools rule engine, an EasyRules rule engine, an OpenL Tablets rule engine, etc.

[0093] The above rule set may include a variety of rules pre-defined by the rule engine. The following are some examples of rules that may be included in the rule set:

[0094] Request rejection rule: used to reject trading requests that meet certain conditions. For example, reject the trading request of user A, reject the trading request of non-stock type, reject the trading request of S exchange, etc.

[0095] Adjustment request rules: used to adjust the user's transaction request. For example, if the transaction start time indicated in the user's transaction request is not in the normal transaction time period, the transaction start time period is adjusted to be in the normal transaction time period.

[0096] Order splitting rules: used to split the master order of a transaction request that meets certain conditions. The master order is an order formed according to the transaction volume indicated by the transaction request. For example, if the transaction quantity indicated by the user's transaction request is greater than the preset quantity, the master order indicated by the transaction request will be split into several sub-orders according to the transaction volume.

[0097] In some cases, if the transaction volume of the above-mentioned transaction master order is large, submitting the transaction master order to the stock exchange for trading will have a greater impact on the trading market. Therefore, the order splitting rule can split the transaction master order into each transaction sub-order with a smaller transaction volume, so that each transaction sub-order can be submitted to the stock exchange for trading during the transaction process, effectively reducing the market impact. Of course, the above rules are only partial examples, and the embodiment of the present invention does not limit the number of rules contained in the rule set and / or the function of the rules.

[0098] In addition, the above rule set may also include rules for converting the format of a transaction request and rules for converting a transaction status.

[0099] The first transaction request may be in a data format defined by the FIX (Financial Information eXchange Protocol) protocol. However, various transaction intermediary systems often have different modifications and / or extensions to the data format defined by the FIX protocol. Therefore, for different trading platforms, the first transaction request may have a variety of different data formats. Therefore, it is necessary to select different rules in a rule set to convert the data format of the first transaction request sent by different trading platforms.

[0100] Specifically, the first transaction request may carry a transaction platform identifier, so that a rule for converting the format of the transaction request may be selected from the rules in the rule set that have a corresponding relationship with the transaction platform identifier as the first rule.

[0101] Step S104: the first thread converts the first transaction request into a second transaction request in a first format based on the first rule.

[0102] The first format mentioned above is a unified format supported by all rules in the rule set.

[0103] Specifically, the first thread may adopt the first rule to modify the data format of the first transaction request according to the first format, so as to obtain a second transaction request that satisfies the first format after the modification is completed.

[0104] For example, the data format of the first transaction request is a data format defined based on the FIX protocol, which is composed of a tag and a value corresponding to the tag. The first thread adopts the first rule to modify, add, delete, etc. the tag and / or the value corresponding to the tag contained in the first transaction request, so that the first transaction request can be converted into a second transaction request in the first format.

[0105] In this way, the data format of the first transaction request sent by each trading platform can be converted into a unified format supported by each rule in the rule set through the first rule. In this way, even if the formats of the first transaction requests from different trading platforms are different, they are converted into the same format, so that the data processed in the subsequent processing flow are oriented to the same data format. In this way, the subsequent processing flow only needs to set up the processing flow for one data format, and there is no need to set up the processing flow for multiple data formats, thereby simplifying the development workload of the processing flow and reducing the complexity of the order management system to a certain extent.

[0106] Step S105: the first thread selects a target transaction processing node for processing the second transaction request according to the load information of each transaction processing node, and forwards the second transaction request to the target transaction processing node.

[0107] Specifically, the first thread can adopt a load balancing strategy based on normal distribution based on the load information of each transaction processing node to ensure that transaction processing nodes that are in an idle state or have a light load are preferentially selected as target transaction processing nodes, and avoid selecting transaction processing nodes that are in a busy state or are processing downtime as target transaction processing nodes.

[0108] In one embodiment of the present invention, the correspondence between transaction processing nodes and transaction requests for different types of transaction objects such as stocks, funds, futures, etc. can be pre-set, and then based on the load information of each transaction processing node, the target processing node can be selected from the transaction processing nodes that have a corresponding relationship with the transaction object indicated by the second transaction request.

[0109] After receiving the second transaction request, the transaction processing node selects a transaction timing and a transaction volume corresponding to the transaction timing according to a certain strategy based on the information carried in the second transaction request to form a transaction order, and submits the transaction order to the stock exchange for trading.

[0110] Step S106: After the main thread monitors the transaction feedback sent by the target transaction processing node, it calls the first thread again.

[0111] After the main thread monitors the transaction feedback sent by the target transaction processing node, it can call the first thread again to process the transaction feedback according to the correspondence between the first interaction request and the first thread recorded above.

[0112] After the target transaction processing node submits the transaction order to the stock exchange for trading, it will periodically send transaction feedback for the first transaction request to the order management system.

[0113] Specifically, the above transaction feedback can be in the following different forms:

[0114] In the first case, the rules in the rule set do not split the transaction master order. In this case, the transaction feedback may be the executed transaction volume of the transaction master order, etc.

[0115] In the second case, the rules in the rule set split the transaction parent order into multiple transaction child orders. In this case, the above transaction feedback can be the executed transaction volume of each transaction child order, etc.

[0116] After the first thread sends the second transaction request to the target processing node, the first thread can continue to process other tasks in the task queue, and the main thread starts to listen to the transaction feedback sent by the transaction processing node, and after listening to the above transaction feedback, calls the first thread again, so that the first thread processes the above transaction feedback, so as to ensure that the transaction feedback is processed in the order of submission of the first transaction request, thereby ensuring that the second transaction status can be sent to the trading platform in an orderly manner based on the transaction feedback.

[0117] Among them, when the main thread calls the first thread after listening to the transaction feedback, there are the following two situations.

[0118] In the first case, when the main thread calls the first thread after listening to the transaction feedback, the first thread is in an idle state. At this time, the main thread can call the first thread to make the first thread process the above transaction feedback.

[0119] In the second case, when the main thread calls the first thread after listening to the transaction feedback, the first thread is in a busy state. For example, the first thread is processing other tasks in the task queue. At this time, the main thread waits for the first thread to complete the processing and then calls the first thread, so that the first thread processes the above transaction feedback.

[0120] Step S107: the first thread generates a first transaction state based on the transaction feedback, and determines a second rule from the rule set that matches the transaction platform and is used to convert the format of the transaction state.

[0121] The above-mentioned first transaction status may include the transaction status of the transaction master order corresponding to the first transaction request, for example: the transaction volume contained in the transaction master order, the executed transaction volume of the transaction master order, the transaction platform identifier of the first transaction request corresponding to the transaction master order, etc.

[0122] The above-mentioned first transaction status may also include the transaction status of the transaction sub-order corresponding to the first transaction request, for example: the transaction volume contained in the transaction sub-order, the executed transaction volume of the transaction sub-order, the transaction platform identifier of the first transaction request corresponding to the transaction sub-order, etc.

[0123] Specifically, according to the difference in transaction feedback received by the first thread, the first thread may generate the first transaction state based on the transaction feedback in the following manner.

[0124] In one implementation, the transaction feedback received by the first thread includes the executed transaction volume of the transaction master order. In this case, the first thread may use the transaction volume included in the transaction master order, the executed transaction volume of the transaction master order, and the transaction platform identifier of the first transaction request corresponding to the transaction master order as the first transaction status.

[0125] In another implementation, the transaction feedback received by the first thread includes the executed transaction volume of each transaction sub-order. In this case, the first thread may first determine the transaction volume and the executed transaction volume corresponding to each transaction sub-order, and then summarize the transaction volume and the executed transaction volume corresponding to each transaction sub-order to obtain the transaction volume corresponding to the transaction master order, the executed transaction volume of the transaction master order, and the transaction platform identifier of the first transaction request corresponding to the transaction master order as the above-mentioned first transaction status.

[0126] Specifically, since the transaction status may carry a transaction platform identifier, a rule for converting the format of the transaction status may be selected from the rules in the rule set that have a corresponding relationship with the transaction platform identifier as the second rule.

[0127] Step S108: The first thread converts the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and sends the second transaction status to the transaction platform.

[0128] Specifically, the first thread may adopt the second rule to modify the data format of the first transaction status according to the second format, so as to obtain the second transaction status in the second format supported by the transaction platform after modification.

[0129] For example, the data format of the first transaction state is a data format defined based on the FIX protocol, which is composed of a tag and a value corresponding to the tag. The first thread can modify, add, delete, and / or perform other operations on the tag and / or the value corresponding to the tag contained in the first transaction state by adopting the second rule, so that the first transaction state can be converted into a second transaction state in a second format.

[0130] In this way, the first transaction status can be converted into a second transaction status in a second format supported by the transaction platform through the second rule, so that after the second transaction status is sent to the transaction platform, the transaction platform can successfully identify the second transaction status in the second format.

[0131] It can be seen from the above that when the solution provided by the embodiment of the present invention is applied to perform transaction processing, the first process adopts the first rule to convert the first transaction request sent by the transaction platform into a second transaction request in a unified format, so that the second transaction request is sent to the target transaction processing node, so that the target transaction processing node can process the second transaction request according to the processing logic for the same format. This not only ensures that the transaction processing node can execute the transaction smoothly, but also makes the processing logic supported by the transaction processing node single, which can effectively prevent the transaction processing node from being complex and diverse.

[0132] In addition, after receiving the first transaction status fed back by the target transaction processing node, the second rule is used to convert the first transaction status into a second transaction status in a data format supported by the transaction platform, so that the transaction platform can successfully identify the second transaction status.

[0133] Furthermore, since the first rule is a rule that matches the trading platform, different first rules can be used to convert the format of the transaction request for different trading platforms, but the final converted format is the above-mentioned unified format. Therefore, the solution provided by the embodiment of the present invention is used for transaction processing, which can achieve docking with various trading platforms.

[0134] As can be seen from the above description, in addition to the rules for converting the data formats of transaction requests and transaction statuses, the rule set may also include other rules for implementing specific functions.

[0135] In some cases, with the iterative upgrade of the order management system, changes in user needs, etc., it is necessary to update the rules in the rule set to meet the needs of iterative upgrades of the order management system and / or changing user needs.

[0136] In view of the above situation, in one embodiment of the present invention, the main thread can listen for update instructions for rules in a rule set. If a target update instruction in the form of a command line is listened to, the rules to be updated indicated by the target update instruction are updated in the memory according to the target update instruction, and the updated rules to be updated are written back to the rule set.

[0137] Specifically, the method of updating the to-be-updated rule indicated by the target update instruction in the memory according to the target update instruction can be described in the following manner.

[0138] In one implementation, the rules to be updated in the rule set indicated by the target update instruction may be first loaded into the memory, and then the rules to be updated may be updated based on the target update instruction, and the updated rules to be updated may be written back to the rule set. For example, the target update instruction is an instruction to modify the rules. In this case, the rules to be updated indicated by the target update instruction may be first loaded into the memory, and then the rules to be updated indicated by the target update instruction may be modified, and the modified rules to be updated may be written back to the rule set.

[0139] In another implementation, new rules can be generated in the memory based on the information carried in the target modification instruction, and the newly generated rules to be updated can be written back to the rule set. For example, the target update instruction is an instruction to add rules. In this case, the rules to be updated indicated by the target update instruction can be generated in the memory based on the command parameters and other information carried by the target modification instruction, and the generated rules to be updated can be written back to the rule set.

[0140] From the above, it can be seen that the solution provided in this embodiment supports the recognition of target modification instructions in the form of command lines, that is, it supports sending target modification instructions to the order management system in the form of command lines, so that the modification of the rules to be updated indicated by the target modification instructions can be completed in the memory without restarting the order management system.

[0141] In this way, the rules in the rule set can be modified in real time without restarting the order management system, ensuring that the rules can be updated in real time according to user needs, meeting the real-time needs of users, improving the user experience of using the order management system to process transactions, and increasing the stickiness of users using the order management system to process transactions.

[0142] In one embodiment of the present invention, the target update instruction is used to implement at least one of the following functions:

[0143] 1. Update the activation status of the above-mentioned rule to be updated. That is, adjust whether the rule to be updated is enabled. If the rule to be updated is enabled, the rule to be updated will process the first transaction request; if the rule to be updated is not enabled, the rule to be updated will not process the first transaction request.

[0144] 2. Update the execution priority of the above-mentioned rules to be updated. By updating the priority of the rules, the processing order of the rules for the first transaction request can be changed.

[0145] 3. Add the above rules to be updated in the rule set. That is, add new rules to the rule set.

[0146] 4. Delete the above rules to be updated from the rule set, that is, delete the existing rules in the rule set.

[0147] 5. Modify the above rules to be updated, that is, modify the content of the existing rules in the rule set.

[0148] Of course, the functions implemented by the above target update instruction are only some examples, and the embodiment of the present invention does not limit the way in which the target update instruction updates the rules in the rule set. For example, the target update instruction can also update the effective time of the rule, whether the rule is executed cyclically, etc.

[0149] Since the solution provided by the embodiment of the present invention supports multiple rule modification methods, the target instructions can be used to update the above-mentioned rules to be updated in multiple ways according to the needs of different users. For example, for user A, the target instruction can be used to start rule R1 and stop starting rule R2; for user B, the target instruction can be used to start rules R1 and rule R2, and stop starting rule R3; for user C with new functional requirements, the target instruction can be used to add a new rule R4, etc.

[0150] In this way, personalized rule sets can be formulated for different users to meet the personalized needs of different users, improving the user experience of using the order management system to process transactions and increasing the user's stickiness in using the order management system to process transactions.

[0151] exist Figure 1 Based on the embodiment shown, in some cases, after the user entrusts the first transaction request to the trading platform, there may be a demand to cancel the first transaction request. At this time, the order management system can also send a cancellation instruction to the target transaction processing node to make the target transaction processing node stop the transaction for the first transaction request. In view of the above situation, the embodiment of the present invention provides a second transaction processing method.

[0152] See also Figure 2 , Figure 2 This is a flow chart of a second transaction processing method provided by an embodiment of the present invention. The method includes the following steps S201 to S212.

[0153] Step S201: the main thread receives a first transaction request from a user sent by a transaction platform, and selects a first thread from a thread pool for processing the first transaction request.

[0154] Step S202: the main thread calls the first thread.

[0155] Step S203: The first thread determines a first rule that matches the trading platform and is used to convert the format of the trading request from a rule set defined based on the rule engine.

[0156] Step S204: the first thread converts the first transaction request into a second transaction request in a first format based on the first rule.

[0157] Step S205: the first thread selects a target transaction processing node for processing the second transaction request according to the load information of each transaction processing node, and forwards the second transaction request to the target transaction processing node.

[0158] Step S206: After the main thread monitors the transaction feedback sent by the target transaction processing node, it calls the first thread again.

[0159] Step S207: the first thread generates a first transaction state based on the transaction feedback, and determines a second rule from the rule set that matches the transaction platform and is used to convert the format of the transaction state.

[0160] Step S208: The first thread converts the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and sends the second transaction status to the transaction platform.

[0161] The above steps S201 to S208 are the same as the above Figure 1 Steps S101-S108 in the illustrated embodiment are the same and will not be described in detail here.

[0162] Step S209: the main thread receives a cancellation instruction for the first transaction request from the user sent by the transaction platform.

[0163] The cancellation instruction is an instruction issued by the user to cancel the transaction indicated by the first transaction request.

[0164] Step S210: The main thread determines whether the second transaction request has been sent to the target transaction processing node. If not, step S211 is executed; if yes, step S212 is executed.

[0165] Step S211: the main thread instructs the first thread to refuse to send the second transaction request to the target transaction processing node.

[0166] If the second transaction request has not been sent to the target transaction processing node, it means that the target transaction processing node has not formed a transaction order for the second transaction request and has not submitted the transaction order to the stock exchange for trading.

[0167] In this case, the main thread may instruct the first thread to refuse to send the second transaction request to the target transaction processing node, so as to ensure that the target transaction processing node will not perform a transaction for the second transaction request.

[0168] Specifically, the first thread may refuse to send the second transaction request to the target transaction processing node in the following manner.

[0169] In one implementation, the first thread may cancel the task of sending the second transaction request to the target transaction processing node, so that there will be no task for the second transaction request in the task queue of the first thread, and the second transaction request will not be sent to the target transaction node. As a result, the target transaction processing node will not receive the second transaction request and will not perform a transaction for the second transaction request.

[0170] In another implementation, the first thread may set the second transaction request as an invalid request, so that after detecting that the second transaction request is an invalid request, the first thread will not send the second transaction request to the target transaction processing node, and the target transaction processing node will not receive the second transaction request.

[0171] Since the second transaction request is obtained by modifying the data format of the first transaction request, the transaction for the second transaction request is not performed, that is, the transaction for the first transaction request is cancelled.

[0172] Step S212: the main thread instructs the first thread to forward a cancel instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

[0173] If the second transaction request has been sent to the target transaction processing node, it means that the target transaction processing node has formed a transaction order for the first transaction request and submitted the transaction order to the exchange for transaction.

[0174] In this case, the main thread can instruct the first thread to forward a cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request according to the cancellation instruction, and cancels the transaction order corresponding to the second transaction request that has not yet been executed, so as to cancel the unexecuted transaction for the first transaction request to the greatest extent.

[0175] This can meet the user's needs to cancel transactions, and can promptly cancel the transaction for the first transaction request based on the user's needs to cancel transactions, thereby improving the security and risk control capabilities of the order management system, thereby improving the user's experience of using the order management system to process transactions, and increasing the user's stickiness in using the order management system to process transactions.

[0176] exist Figure 1 Based on the embodiment shown, in some cases, after the user entrusts the first transaction request to the trading platform, there may be a need to modify the first transaction request. At this time, the order management system can also send a modification instruction to the target transaction processing node to make the target transaction processing node modify the transaction for the first transaction request. In view of the above situation, the embodiment of the present invention provides a third transaction processing method.

[0177] See also Figure 3 , Figure 3 The present invention provides a flowchart of a third transaction processing method according to an embodiment of the present invention. The method includes the following steps S301 to S312.

[0178] Step S301: the main thread receives a first transaction request from a user sent by a transaction platform, and selects a first thread for processing the first transaction request from a thread pool.

[0179] Step S302: the main thread calls the first thread.

[0180] Step S303: The first thread determines a first rule that matches the trading platform and is used to convert the format of the trading request from a rule set defined based on the rule engine.

[0181] Step S304: the first thread converts the first transaction request into a second transaction request in a first format based on the first rule.

[0182] Step S305: the first thread selects a target transaction processing node for processing the second transaction request according to the load information of each transaction processing node, and forwards the second transaction request to the target transaction processing node.

[0183] Step S306: After the main thread monitors the transaction feedback sent by the target transaction processing node, it calls the first thread again.

[0184] Step S307: the first thread generates a first transaction state based on the transaction feedback, and determines a second rule from the rule set that matches the transaction platform and is used to convert the format of the transaction state.

[0185] Step S308: The first thread converts the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and sends the second transaction status to the transaction platform.

[0186] The above steps S301 to S308 are the same as the above Figure 2 Steps S201-S208 in the illustrated embodiment are the same and will not be described in detail here.

[0187] Step S309: the main thread receives a modification instruction for the first transaction request from the user sent by the transaction platform.

[0188] The modification instruction is an instruction issued by the user to modify the transaction indicated by the first transaction request. The modification instruction represents the user's new transaction requirements, and may include the identifier of the first transaction request to be modified, as well as the transaction target, transaction volume, transaction time period, etc. re-indicated by the user.

[0189] Among them, the modification operation indicated by the above modification instruction can be to maintain the transaction target indicated by the first transaction request and only modify the transaction volume, transaction time period, etc. indicated by the first transaction request, or it can be to modify both the transaction target indicated by the first transaction request and the transaction volume, transaction time period, etc. indicated by the first transaction request.

[0190] Step S310: The main thread determines whether the second transaction request has been sent to the target transaction processing node. If not, step S311 is executed; if yes, step S312 is executed.

[0191] Step S311: the main thread instructs the first thread to refuse to send the second transaction request to the target transaction processing node, and modifies the second transaction request according to the modification instruction, and sends the modified second transaction request to the target transaction processing node.

[0192] If the second transaction request has not been sent to the target transaction processing node, it means that the target transaction processing node has not formed a transaction order for the second transaction request and has not submitted the transaction order to the stock exchange for trading.

[0193] In this case, it indicates that the user's first transaction request has not been processed, so the main thread can instruct the first thread to refuse to send the second transaction request to the target transaction processing node to ensure that the target transaction processing node will not conduct a transaction for the current second transaction request, that is, will not conduct a transaction for the current first transaction request.

[0194] Since the customer has modified the first transaction request, in order to ensure that the target transaction processing node can accurately process the modified first transaction request, in this case, the first process can modify the second transaction request according to the modification instruction, and then send the modified second transaction request to the target transaction processing node, for example, modify the second transaction request according to the transaction target, transaction volume, transaction time period and other information indicated by the modification instruction, so that the target transaction processing node can trade according to the modified second transaction request. Since the second transaction request is obtained after the format of the first transaction request is modified, the target transaction processing node can trade according to the modified second transaction request by trading according to the modified first transaction request.

[0195] The method of refusing to send the second transaction request to the target transaction processing node may refer to the aforementioned step S211, which will not be described in detail here.

[0196] Step S312: the main thread instructs the first thread to send a cancellation instruction for the first transaction request to the target transaction processing node, receives cancellation feedback for the first transaction request sent by the target transaction processing node, and sends a modification instruction updated based on the cancellation feedback to the target transaction processing node, so that the target transaction processing node performs the transaction according to the updated modification instruction.

[0197] If the second transaction request has been sent to the target transaction processing node, it means that the target transaction processing node has formed a transaction order for the first transaction request and submitted the transaction order to the exchange for transaction.

[0198] In this case, the main thread can instruct the first thread to send a cancel instruction for the first transaction request to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request and cancels the transaction order corresponding to the second transaction request that has not yet been executed.

[0199] In addition, a cancellation feedback for the first transaction request sent by the receiving transaction processing node is sent, and a modification instruction updated based on the cancellation feedback is sent to the target transaction processing node, so that the target transaction processing node modifies the transaction for the second transaction request according to the updated modification instruction. Since the second transaction request is obtained by modifying the data format of the first transaction request, modifying the transaction for the second transaction request is equivalent to modifying the transaction for the first transaction request.

[0200] Specifically, the number of successfully canceled trading orders for the second trading request may be determined based on the cancellation feedback, and then the trading volume indicated in the modification instruction may be updated to the difference between the above trading volume and the number of successfully canceled trading orders.

[0201] For example, the second transaction request indicates that 1000 shares are traded for transaction target a, and the modification instruction indicates that 1500 shares are traded for transaction target b. Based on the cancellation feedback, it is determined that the number of transaction orders for transaction target a that have been successfully canceled is 500 shares. Then the transaction volume indicated in the modification instruction can be updated to 1500-500=1000 shares. In this way, after the order is modified, the actual transaction volume executed is the same as the transaction volume indicated in the modification instruction.

[0202] This can meet the user's needs to modify transactions, and can promptly modify the transaction for the first transaction request according to the user's needs to modify the transaction, thereby improving the security and risk control capabilities of the order management system, thereby improving the user's experience of using the order management system to process transactions, and increasing the user's stickiness in using the order management system to process transactions.

[0203] The transaction processing process provided by the embodiment of the present invention is described below from the perspective of the order management system.

[0204] In one embodiment of the present invention, an order management system is provided, which interacts with a trading platform, a transaction processing node, and a monitoring client. Figure 4 , Figure 4 Provides a structural diagram of an order management system. Figure 4 It can be seen that the order management system is connected to the upstream trading platform, the downstream transaction processing node and the monitoring client.

[0205] First, the above-mentioned monitoring client is described.

[0206] Depend on Figure 4 It can be seen that the monitoring client can establish a remote connection with the server communication framework in the order management system through the monitoring client communication framework, so as to communicate with the order management system. In this way, the monitoring client can input the target modification instructions for the rules in the rule set from the command line of the device where the order management system is located through the remote connection, thereby modifying the rules in the above rule set, and realizing the remote modification of the rules in the rule set. Among them, the rules in the rule set are defined based on the rule engine.

[0207] It can be seen that in this way, not only can the rules in the rule set be modified through the device where the order management system is located, but the rules in the rule set can also be modified remotely through the monitoring client, which improves the flexibility when modifying the rules in the rule set.

[0208] In one embodiment of the present invention, the monitoring client can remotely query the order management system for each rule in the rule set and query the transaction status of the transaction order through DOS commands.

[0209] Next, the data recovery module in the order management system is explained.

[0210] In order to prevent the server where the order management system is located from crashing, the data recovery module can save the data status in the order management system. If the server where the order management system is located crashes, the data recovery module can restore the data based on the saved data status.

[0211] During the process of data recovery by the data recovery module, the order management system does not process the transaction request temporarily, but caches the transaction request. After the data recovery module successfully recovers the data, the transaction request in the cache is processed again.

[0212] This ensures that there will be no data loss even if the server crashes, ensuring normal transaction processing.

[0213] The following takes the data format of the transaction request sent by the trading platform as the data format specified by the FIX protocol as an example, and introduces steps A to J. Figure 4The order management system shown processes a transaction.

[0214] Step A: The FIX upstream receiving engine in the order management system receives information from the trading platform.

[0215] The above information may be a first transaction request.

[0216] Specifically, the order management system first monitors the information sent by the trading platform through a monitor, and the FIX upstream receiving engine receives the monitored information and sends the received information to the OM (Order Management) queue.

[0217] Step B: The OM queue in the order management system selects a first thread from the thread pool for processing the transaction request indicated by the above information.

[0218] Step C: The order management system calls the first thread in the thread pool to process the information using the rules defined by the rule engine, wherein the above rules include the above first rule, and the first thread uses the first rule to convert the data format of the above information into a unified format supported by other rules in the rule set.

[0219] The first thread may also use the order checking rules included in the above rule set to split the transaction master order corresponding to the transaction request indicated by the above information into a plurality of transaction sub-orders.

[0220] Step D: After the first thread processes the information according to the execution priority of the rule, the intelligent routing module selects the target transaction processing node according to the load information of the transaction processing node.

[0221] The way in which the intelligent routing module selects the target transaction processing node according to the load information of the transaction processing node can refer to the way of selecting the target transaction processing node described in the above embodiment, which will not be repeated here. In this way, the target processing node that is idle or lightly loaded can be preferentially selected to process the above information, thereby improving the processing efficiency of the above information.

[0222] Step E: The first thread uses the downstream FIX sending engine to send the information processed by the above rules to the target transaction processing node.

[0223] The target processing node may form a transaction order based on the received information and submit the transaction order to the stock exchange for trading.

[0224] Step F: The listener in the order management system listens to the ExecutionReprot (execution report) sent by the target transaction processing node.

[0225] The above ExecutionReprot may be the first transaction feedback introduced above.

[0226] Step G: The order management system re-calls the first thread for processing the information.

[0227] Once the order management system monitors the ExecutionReprot sent by the target transaction processing node, it will re-call the first thread that performs the aforementioned processing and sends information to the target node, and through the business logic distribution module, enable the first thread to complete the update of the transaction status of subsequent transaction sub-orders and transaction parent orders.

[0228] Step H: The first thread updates the transaction status of the transaction sub-order according to the ExecutionReprot through the sub-order processing module.

[0229] The transaction status of the above-mentioned transaction sub-order can refer to the transaction status described in the previous embodiment, which will not be repeated here.

[0230] The first thread can update the transaction status of each transaction sub-order through the sub-order processing module, so that the subsequent parent order processing module can summarize the transaction status of each transaction sub-order.

[0231] Step I: The first thread summarizes the transaction sub-order status updated by each sub-order processing module through the parent order processing module to update the transaction status of the transaction parent order.

[0232] The transaction status of the above-mentioned transaction master order can refer to the description in the above-mentioned embodiment.

[0233] Step J: The first thread returns the status information of the transaction master order to the trading platform through the FIX upstream sending engine.

[0234] The first thread may also use the second rule in the rule set to convert the above status information into a transaction status in a format supported by the transaction platform, so as to ensure that the transaction platform can successfully identify the above transaction status.

[0235] It can be seen from the above that when the solution provided by the embodiment of the present invention is applied to perform transaction processing, the first process adopts the first rule to convert the first transaction request sent by the transaction platform into a second transaction request in a unified format, so that the second transaction request is sent to the target transaction processing node, so that the target transaction processing node can process the second transaction request according to the processing logic for the same format. This not only ensures that the transaction processing node can execute the transaction smoothly, but also makes the processing logic supported by the transaction processing node single, which can effectively prevent the transaction processing node from being complex and diverse.

[0236] In addition, after receiving the first transaction status fed back by the target transaction processing node, the second rule is used to convert the first transaction status into a second transaction status in a data format supported by the transaction platform, so that the transaction platform can successfully identify the second transaction status.

[0237] Furthermore, since the first rule is a rule that matches the trading platform, different first rules can be used to convert the format of the transaction request for different trading platforms, but the final converted format is the above-mentioned unified format. Therefore, the solution provided by the embodiment of the present invention is used for transaction processing, which can achieve docking with various trading platforms.

[0238] Corresponding to the above-mentioned transaction processing method, an embodiment of the present invention also provides a transaction processing device.

[0239] See also Figure 5 , is a first transaction processing device provided by an embodiment of the present invention, the device comprises the following modules 501-503:

[0240] The transaction request receiving module 501 is used to receive a first transaction request from a user sent by a transaction platform, and select a first thread from a thread pool for processing the first transaction request;

[0241] The transaction request conversion module 502 is used to call the first thread to determine a first rule that matches the transaction platform and is used to convert the format of the transaction request from a rule set defined based on a rule engine, convert the transaction request into a second transaction request in a first format based on the first rule, select a target transaction processing node for processing the second transaction request according to the load information of each transaction processing node, and forward the second transaction request to the target transaction processing node, wherein the first format is: a unified format supported by all rules in the rule set;

[0242] The transaction status sending module 503 is used to, after listening to the transaction feedback sent by the target transaction processing node, re-call the first thread to generate a first transaction status based on the transaction feedback, determine from the rule set a second rule that matches the transaction platform and is used to convert the format of the transaction status, convert the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and send the second transaction status to the transaction platform.

[0243] It can be seen from the above that when the solution provided by the embodiment of the present invention is applied to perform transaction processing, the first process adopts the first rule to convert the first transaction request sent by the transaction platform into a second transaction request in a unified format, so that the second transaction request is sent to the target transaction processing node, so that the target transaction processing node can process the second transaction request according to the processing logic for the same format. This not only ensures that the transaction processing node can execute the transaction smoothly, but also makes the processing logic supported by the transaction processing node single, which can effectively prevent the transaction processing node from being complex and diverse.

[0244] In addition, after receiving the first transaction status fed back by the target transaction processing node, the second rule is used to convert the first transaction status into a second transaction status in a data format supported by the transaction platform, so that the transaction platform can successfully identify the second transaction status.

[0245] Furthermore, since the first rule is a rule that matches the trading platform, different first rules can be used to convert the format of the transaction request for different trading platforms, but the final converted format is the above-mentioned unified format. Therefore, the solution provided by the embodiment of the present invention is used for transaction processing, which can achieve docking with various trading platforms.

[0246] In one embodiment of the present invention, the device further comprises:

[0247] a cancellation instruction receiving module, configured to receive a cancellation instruction of the user for the first transaction request sent by the transaction platform;

[0248] a transaction request determination module, configured to determine whether the second transaction request has been sent to the target transaction processing node, and if not, trigger the first rejection sending module; and if yes, trigger the cancellation instruction sending module;

[0249] A first sending rejection module, configured to instruct the first thread to refuse to send the second transaction request to the target transaction processing node;

[0250] The cancellation instruction sending module is used to instruct the first thread to forward the cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

[0251] This can meet the user's needs to cancel transactions, and can promptly cancel the transaction for the first transaction request based on the user's needs to cancel transactions, thereby improving the security and risk control capabilities of the order management system, thereby improving the user's experience of using the order management system to process transactions, and increasing the user's stickiness in using the order management system to process transactions.

[0252] In one embodiment of the present invention, the device further comprises:

[0253] A modification instruction receiving module, configured to receive a modification instruction of the user to the first transaction request sent by the transaction platform;

[0254] a transaction request determination module, configured to determine whether the second transaction request has been sent to the target transaction processing node, and if not, trigger the second rejection sending module; and if yes, trigger the modification instruction sending module;

[0255] a second rejection sending module, configured to instruct the first thread to refuse to send the second transaction request to the target transaction processing node, and to modify the second transaction request according to the modification instruction, and to send the modified second transaction request to the target transaction processing node;

[0256] A modification instruction sending module is used to instruct the first thread to send a cancellation instruction for the first transaction request to the target transaction processing node, receive cancellation feedback for the first transaction request sent by the target transaction processing node, and send a modification instruction updated based on the cancellation feedback to the target transaction processing node, so that the target transaction processing node performs the transaction according to the updated modification instruction.

[0257] This can meet the user's needs to modify transactions, and can promptly modify the transaction for the first transaction request according to the user's needs to modify the transaction, thereby improving the security and risk control capabilities of the order management system, thereby improving the user's experience of using the order management system to process transactions, and increasing the user's stickiness in using the order management system to process transactions.

[0258] See also Figure 6 , Figure 6 The second transaction processing device provided by the embodiment of the present invention includes the following modules 601 to 606:

[0259] A transaction request receiving module 601 is used to receive a first transaction request from a user sent by a transaction platform, and select a first thread from a thread pool for processing the first transaction request;

[0260] The transaction request conversion module 602 is used to call the first thread to determine a first rule that matches the transaction platform and is used to convert the format of the transaction request from a rule set defined based on a rule engine, convert the transaction request into a second transaction request in a first format based on the first rule, and select a target transaction processing node for processing the second transaction request according to the load information of each transaction processing node, and forward the second transaction request to the target transaction processing node, wherein the first format is: a unified format supported by all rules in the rule set;

[0261] The transaction status sending module 603 is used to, after listening to the transaction feedback sent by the target transaction processing node, re-call the first thread to generate a first transaction status based on the transaction feedback, determine from the rule set a second rule that matches the transaction platform and is used to convert the format of the transaction status, convert the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and send the second transaction status to the transaction platform.

[0262] An update instruction monitoring module 604, used to monitor update instructions for rules in the rule set;

[0263] The rule updating module 605 is used to update the to-be-updated rule indicated by the target updating instruction in the memory according to the target updating instruction if a target updating instruction in the form of a command line is monitored;

[0264] The update rule writing back module 606 is used to write the updated rules to be updated back to the rule set.

[0265] In this way, the rules in the rule set can be modified in real time without restarting the order management system to reload, ensuring that the rules can be updated in real time according to the needs of users, meeting the real-time needs of customers, improving the user experience of using the order management system to process transactions, and increasing the stickiness of users using the order management system to process transactions. In one embodiment of the present invention, the target update instruction is used to implement at least one of the following functions:

[0266] Updating the enabled state of the rule to be updated;

[0267] Updating the execution priority of the rule to be updated;

[0268] Adding the rule to be updated to the rule set;

[0269] Deleting the rule to be updated from the rule set;

[0270] Modify the rule to be updated.

[0271] In this way, the above-mentioned rules to be updated can be updated in a variety of ways using target instructions according to the needs of different users, so that personalized rule sets can be formulated for different users to meet the personalized needs of different users, thereby improving the user experience of using the order management system to process transactions and increasing the stickiness of users using the order management system to process transactions.

[0272] The embodiment of the present invention further provides an electronic device, such as Figure 7As shown, it includes a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0273] Memory 703, used for storing computer programs;

[0274] The processor 701 is used to implement the transaction processing method provided in the embodiment of the present invention when executing the program stored in the memory 703.

[0275] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0276] The communication interface is used for communication between the above electronic device and other devices.

[0277] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0278] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0279] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the transaction processing method provided in the embodiment of the present invention is implemented.

[0280] In another embodiment of the present invention, a computer program product including instructions is provided, which, when executed on a computer, enables the computer to execute the transaction processing method provided in the embodiment of the present invention.

[0281] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0282] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0283] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, electronic device, storage medium and computer program product embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0284] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A transaction processing method, characterized in that: The method comprises: Receive a first transaction request from a user sent by the transaction platform, and select a first thread from a thread pool for processing the first transaction request; The first thread is called to determine a first rule that matches the trading platform and is used to convert the format of the trading request from a rule set defined based on a rule engine, convert the first trading request into a second trading request in a first format based on the first rule, and select a target trading processing node for processing the second trading request according to load information of each trading processing node, and forward the second trading request to the target trading processing node, wherein the first format is: a unified format supported by all rules in the rule set; After monitoring the transaction feedback sent by the target transaction processing node, re-call the first thread to generate a first transaction state based on the transaction feedback, determine a second rule from the rule set that matches the transaction platform and is used to convert the format of the transaction state, convert the first transaction state into a second transaction state in a second format supported by the transaction platform based on the second rule, and send the second transaction state to the transaction platform; The method further comprises: Listening for update instructions for rules in the rule set; if a target update instruction in the form of a command line is listened, updating the to-be-updated rules indicated by the target update instruction in the memory according to the target update instruction; and writing the updated to-be-updated rules back to the rule set; The target update instruction is used to implement at least one of the following functions: Update the enabled state of the rule to be updated; update the execution priority of the rule to be updated; add the rule to be updated to the rule set; delete the rule to be updated from the rule set; modify the rule to be updated; The method further comprises: Receive a cancellation instruction for the first transaction request from the user sent by the transaction platform; determine whether the second transaction request has been sent to a target transaction processing node; if not, instruct the first thread to refuse to send the second transaction request to the target transaction processing node; if yes, instruct the first thread to forward the cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

2. The method according to claim 1, characterized in that: The method further comprises: receiving a modification instruction of the user to the first transaction request sent by the transaction platform; determining whether the second transaction request has been sent to the target transaction processing node; If not, instructing the first thread to refuse to send the second transaction request to the target transaction processing node, and modifying the second transaction request according to the modification instruction, and sending the modified second transaction request to the target transaction processing node; If yes, instruct the first thread to send a cancellation instruction for the first transaction request to the target transaction processing node, receive cancellation feedback for the first transaction request sent by the target transaction processing node, and send a modification instruction updated based on the cancellation feedback to the target transaction processing node, so that the target transaction processing node performs the transaction according to the updated modification instruction.

3. A transaction processing device, characterized in that: The device comprises: A transaction request receiving module, configured to receive a first transaction request from a user sent by a transaction platform, and select a first thread from a thread pool for processing the first transaction request; a transaction request conversion module, configured to call the first thread to determine a first rule that matches the transaction platform and is used to convert the format of the transaction request from a rule set defined based on a rule engine, convert the transaction request into a second transaction request in a first format based on the first rule, select a target transaction processing node for processing the second transaction request according to load information of each transaction processing node, and forward the second transaction request to the target transaction processing node, wherein the first format is: a unified format supported by all rules in the rule set; a transaction status sending module, configured to, after monitoring the transaction feedback sent by the target transaction processing node, re-call the first thread to generate a first transaction status based on the transaction feedback, determine from the rule set a second rule that matches the transaction platform and is used to convert the format of the transaction status, convert the first transaction status into a second transaction status in a second format supported by the transaction platform based on the second rule, and send the second transaction status to the transaction platform; The device also includes: An update instruction monitoring module, used for monitoring update instructions for rules in the rule set; a rule update module, used for updating the rules to be updated indicated by the target update instruction in the memory according to the target update instruction if a target update instruction in the form of a command line is monitored; an update rule write-back module, used for writing the updated rules to be updated back to the rule set; The target update instruction is used to implement at least one of the following functions: Update the enabled state of the rule to be updated; update the execution priority of the rule to be updated; add the rule to be updated to the rule set; delete the rule to be updated from the rule set; modify the rule to be updated; The device also includes: a cancellation instruction receiving module, used for receiving a cancellation instruction of the user for the first transaction request sent by the transaction platform; a transaction request judgment module, used for judging whether the second transaction request has been sent to the target transaction processing node, and if so, triggering a rejection sending module, and if not, triggering a cancellation instruction forwarding module; a first rejection sending module, used for instructing the first thread to refuse to send the second transaction request to the target transaction processing node; a cancellation instruction sending module, used for instructing the first thread to forward the cancellation instruction to the target transaction processing node, so that the target transaction processing node stops the transaction for the second transaction request.

4. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1-2 when executing a program stored in a memory.

5. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1-2 are implemented.

Images