Business processing method and device for online transaction scene and electronic equipment

Abstract

The invention provides a business processing method and device for an online transaction scene and electronic equipment. Comprising the following steps: acquiring business data, defining a logic arrangement keyword based on an online transaction execution language, arranging the business data according to the logic arrangement keyword to obtain DSL arrangement data, constructing a grammar verification analyzer, and performing grammar verification processing on the DSL arrangement data by adopting the grammar verification analyzer to obtain the DSL arrangement data. An abstract syntax tree is constructed based on the verified DSL arrangement data, the abstract syntax tree comprises root nodes and leaf nodes, the root nodes represent arrangement rules and scheduling logic, and the leaf nodes represent actually called atomic transactions in the service data; and traversing each node in the abstract syntax tree by adopting an execution engine, and calling a node processor corresponding to each node to process the service data. The problem that an existing rule arrangement engine is poor in business reliability when being applied to banking businesses is solved.

Description

Technical Field

[0001] The present application relates to the technical field of business processing in online transaction scenarios, and more specifically, to a business processing method, device, computer-readable storage medium, and electronic device for online transaction scenarios. Background Art

[0002] Generally, rule / process engines can reduce business development complexity, improve development efficiency, enhance business maintainability, and meet the needs of rapid iteration. Currently, there are a variety of open source rule orchestration engine software, such as Drools, URule, Aviator, Activiti, and Liteflow.

[0003] However, after investigation and research, we found that existing rule engines support a limited range of rule types. Banking operations are complex, including parallel invocation, selective invocation, conditional invocation, repeated invocation, conditional invocation, and nested sub-transaction invocation. Furthermore, existing rule engines, such as LiteFlow, lack support for parallel invocation. In practice, not only do we need to implement parallel asynchronous invocation of atomic transactions, but we also require a variety of invocation strategies, such as execute all, execute any transaction, wait for execution, and ignore the result and continue execution.

[0004] In cluster and distributed system scenarios, existing engine technology solutions cannot provide reliable business consistency assurance capabilities. For example, Liteflow's consistency assurance capabilities are relatively weak because Liteflow implements transaction management based on memory. This results in the loss of transaction records when system anomalies cause server downtime, and the system cannot trace all transactions generated during the system anomaly, resulting in poor business reliability. Summary of the Invention

[0005] The main purpose of this application is to provide a business processing method, device, computer-readable storage medium and electronic device for an online transaction scenario, so as to at least solve the problem of poor business reliability in the application of existing rule orchestration engines to banking business.

[0006] To achieve the above objectives, according to one aspect of the present application, a business processing method for an online transaction scenario is provided, comprising: acquiring business data, defining logical orchestration keywords based on an online transaction execution language, orchestrating the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword; constructing a syntax verification parser, using the syntax verification parser to perform syntax verification on the DSL orchestration data, and constructing an abstract syntax tree based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, the root node representing orchestration rules and scheduling logic, and the leaf nodes representing atomic transactions actually invoked in the business data; and traversing each node in the abstract syntax tree using an execution engine, invoking a node processor corresponding to each node to process the business data.

[0007] Optionally, after constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: performing a rule initialization operation on the abstract syntax tree, wherein the rule initialization includes transaction attribute initialization, node attribute initialization, and grayscale policy initialization.

[0008] Optionally, the syntax verification parser is used to perform syntax verification processing on the DSL orchestration data, including: using the syntax verification parser to perform basic field verification on the DSL orchestration data, wherein the basic field verification includes at least one of transaction storage policy detection, plug-in list detection, and transaction type detection; using the syntax verification parser to perform value range verification on the DSL orchestration data, wherein the value range verification includes service node, parallel node, for loop node value detection, and timeout detection; using the syntax verification parser to perform process expression verification on the DSL orchestration data, wherein the process expression verification includes non-empty verification, bracket matching verification, and syntax verification.

[0009] Optionally, an execution engine is used to traverse each node in the abstract syntax tree, and a node processor corresponding to each node is called to process the business data, including: when the execution engine is used to traverse the root node in the abstract syntax tree for the first time, a node processor factory is used to determine a first node processor corresponding to the root node; the first node processor is used to determine the scheduling relationship of the next node according to the orchestration rule of the root node and the scheduling logic; when the next node is the leaf node, a second node processor corresponding to the leaf node is determined, and the second node processor is used to process the business data.

[0010] Optionally, after constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: configuring a processing timeout policy for each node in the abstract syntax tree to obtain a timeout configuration rule for each node in the abstract syntax tree, wherein the timeout configuration rule includes at least one of timeout success, timeout success and retry, timeout failure and no rollback, and timeout failure and retry.

[0011] Optionally, in the process of calling the node processor corresponding to each of the nodes to process the business data, the method also includes: obtaining the processing time of the node processor corresponding to each of the nodes; when the processing time is greater than the set time, determining that the node processor processing has timed out, and controlling the node processor to perform timeout processing on the business data according to the timeout configuration rule.

[0012] Optionally, the node processor includes: at least one of: a parallel node processor, a serial node processor, a For node processor, an IF node processor, a Switch node processor, a transaction node processor, a sub-transaction node processor, and a conditional loop node processor, wherein the For node processor is a node processor that executes sub-nodes in a loop, the IF node processor is a node processor that determines to call a target sub-node based on a SpEL expression, the Switch node processor is a node processor that determines to execute a target sub-node based on the character value of the SpEL expression, the sub-transaction node processor is a node processor for executing nested sub-transactions, and the conditional loop node processor is a node processor that determines whether to execute a loop based on the output or input of the previous node.

[0013] According to another aspect of the present application, a business processing device for an online transaction scenario is provided, comprising: an orchestration processing unit, configured to obtain business data, define logical orchestration keywords based on an online transaction execution language, and orchestrate the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword; a construction unit, configured to construct a syntax verification parser, perform syntax verification processing on the DSL orchestration data using the syntax verification parser, and construct an abstract syntax tree based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, wherein the root node represents orchestration rules and scheduling logic, and the leaf nodes represent atomic transactions actually invoked in the business data; and a calling unit, configured to use an execution engine to traverse each node in the abstract syntax tree and call a node processor corresponding to each node to process the business data.

[0014] According to another aspect of the present application, a computer-readable storage medium is provided, which includes a stored program, wherein when the program is run, the device where the computer-readable storage medium is located is controlled to execute any one of the business processing methods for the online transaction scenario.

[0015] According to another aspect of the present application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs include a business processing method for executing any one of the online transaction scenarios.

[0016] Applying the technical solution of the present application, business data is acquired, and logical orchestration keywords are defined based on an online transaction execution language. The business data is orchestrated and processed according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword. A syntax verification parser is constructed and used to perform syntax verification on the DSL orchestration data. An abstract syntax tree is constructed based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, wherein the root node represents orchestration rules and scheduling logic, and the leaf nodes represent atomic transactions actually called in the business data. An execution engine is used to traverse each node in the abstract syntax tree and call a node processor corresponding to each node to process the business data. By defining logical orchestration keywords based on the online transaction execution language, the engine's basic syntax architecture is constructed, allowing for flexible orchestration and dynamic updating of business logic. By introducing a syntax validation parser, rule files can be verified, parsed, and initialized to ensure their grammatical correctness and the rationality of transaction attributes before execution. Transactions and services are abstracted into nodes by constructing an executable abstract syntax tree (AST), and a multi-tree data structure is formed through connections between nodes, simplifying rule management and expansion. Furthermore, an interpreter executor is designed. As a multi-threaded parallel execution engine, it can intelligently schedule the execution of transaction nodes based on different node types and parallel strategies, achieving efficient transaction processing capabilities. This enables this embodiment to meet the banking industry's requirements for high performance and high reliability, while providing a rich variety of transaction features and business consistency guarantees. This solves the problem of poor business reliability in existing rule orchestration engines used in banking business. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings that constitute part of this application are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation on this application. In the drawings:

[0018] Figure 1 A hardware structure block diagram of a mobile terminal for executing a business processing method for an online transaction scenario provided in an embodiment of the present application is shown;

[0019] Figure 2 A schematic diagram illustrating a process flow of a business processing method for an online transaction scenario provided according to an embodiment of the present application is shown;

[0020] Figure 3 A schematic diagram of the process of constructing an abstract syntax tree and syntax checking according to an embodiment of the present application is shown;

[0021] Figure 4 A schematic diagram of rules corresponding to a grammar example provided according to an embodiment of the present application is shown;

[0022] Figure 5 A schematic diagram showing an abstract syntax tree corresponding to a syntax example provided according to an embodiment of the present application is shown;

[0023] Figure 6 shows a UML class diagram of a node processor provided according to an embodiment of the present application;

[0024] Figure 7 A schematic diagram of a process flow executed by an execution engine according to an embodiment of the present application is shown;

[0025] Figure 8 A structural block diagram of a business processing device for an online transaction scenario provided according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0027] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings 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 without making creative efforts should fall within the scope of protection of this application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] For ease of description, some nouns or terms involved in the embodiments of the present application are explained below:

[0030] DSL: The full name is Domain Specific Language, which is a computer programming language that focuses on a certain field. For example, regular expressions, json, sql, and XML are all DSL languages ​​in a fixed field.

[0031] OTEL: Online Transaction Execute Language, the English abbreviation of the online transaction engine custom DSL language, that is, online transaction execution language.

[0032] AST: Abstract Syntax Tree, an abstract expression of a certain grammatical structure, a tree structure.

[0033] SpEL: Spring Expression Language, Spring Expression Language, SpEL is one of the core technologies of Spring, which supports querying and manipulating objects at runtime.

[0034] As introduced in the background technology, the existing rule orchestration engine applied to banking business has poor business reliability. To solve the problem of poor business reliability in the existing rule orchestration engine applied to banking business, the embodiments of the present application provide a business processing method, device, computer-readable storage medium and electronic device for an online transaction scenario.

[0035] The technical solutions in the embodiments of the present invention will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present invention.

[0036] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1This is a hardware structure block diagram of a mobile terminal for a business processing method in an online transaction scenario according to an embodiment of the present invention. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data, wherein the mobile terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the mobile terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0037] Memory 104 can be used to store computer programs, such as software programs and modules of application software, such as the computer program corresponding to the business processing method for the online transaction scenario in the embodiments of the present invention. Processor 102 executes the computer programs stored in memory 104 to execute various functional applications and data processing, thereby implementing the aforementioned method. Memory 104 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located from processor 102, which can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. Transmission device 106 is used to receive or transmit data via a network. Specific examples of such networks may include a wireless network provided by the mobile terminal's telecommunications provider. In one example, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0038] In this embodiment, a business processing method for an online transaction scenario running on a mobile terminal, a computer terminal or a similar computing device is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0039] Figure 2 This is a flow chart of a business processing method for an online transaction scenario according to an embodiment of the present application. Figure 2 As shown, the method includes the following steps:

[0040] Step S201: Acquire business data, define logical orchestration keywords based on an online transaction execution language, and orchestrate the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword.

[0041] Specifically, the online transaction execution language (OTEL) used is similar to common programming languages ​​and DSL languages. The keywords in OTEL are the cornerstone of the online transaction engine. They determine the basic data structure of the engine, define the transaction context, and play a key role in rule construction, rule verification, rule parsing, rule interpretation and execution, and exception handling.

[0042] In the online trading engine, the defined keywords include: condition keyword IF, serial keyword THEN, parallel keyword PARALLEL, conditional loop keyword WHILE, number of loop keyword FOR, selection keyword SWITCH..CASE, and sub-trading keyword SUBTRADE.

[0043] The parallel keyword includes multiple parallel strategies, including ALL, ANY, CONTINUE, and DIRECT. This diverse parallel strategy design can meet the diverse parallel transaction requirements of banking services. For example, the DIRECT strategy can be selected in certain scenarios with high real-time requirements, while the ALL strategy can be selected in scenarios with high transaction result accuracy requirements. These are features that existing rule engines do not have or do not fully support.

[0044] ALL: All transactions must be executed successfully;

[0045] ANY: As long as at least one transaction is successfully executed;

[0046] CONTINUE: Regardless of whether the transaction is successful or not, continue to execute forward;

[0047] DIRECT: After initiating a transaction, continue execution without waiting for the execution result.

[0048] Step S202: Construct a syntax verification parser, use the syntax verification parser to perform syntax verification on the DSL orchestration data, and construct an abstract syntax tree based on the verified DSL orchestration data. The abstract syntax tree includes a root node and leaf nodes. The root node represents the orchestration rules and scheduling logic, and the leaf nodes represent the atomic transactions actually called in the business data.

[0049] Specifically, a personalized multi-tree data structure (abstract syntax tree) is constructed based on node objects. Leaf nodes represent the atomic transactions actually invoked in the business data, while non-leaf nodes are keyword node objects (representing orchestration rules and scheduling logic). This mechanism reduces the complexity and processing overhead of transaction rules, improves the speed and accuracy of rule parsing, and enhances the organization and management of transaction rules.

[0050] Step S203: Using an execution engine to traverse each node in the abstract syntax tree, and calling a node processor corresponding to each node to process the business data.

[0051] Specifically, after the execution engine obtains the abstract syntax tree, it will first find the root node, and then adopt the factory pattern to use the node processor factory to find the corresponding node processor. The node processor determines the scheduling relationship of the next layer based on the internal orchestration rules and built-in scheduling logic. If it is a leaf node, the node processor (this processor is a service node processor, which is specifically used for actual service calls) will call the atomic transaction through the atomic transaction agent; if it is a non-leaf node, the processor of this layer will recursively call the node object of the next layer until all nodes are deeply traversed.

[0052] The node processor factory is one of the core components of the execution engine, responsible for creating corresponding processor instances based on different node types. In the online engine device implemented based on the custom DSL language, each keyword (such as THEN, IF, PARALLEL, etc.) corresponds to a specific node type, and each node type has its own specific function and execution logic. The node processor factory dynamically creates corresponding node processors such as ThenProcessor, IfProcessor, ParallelProcessor, etc. by identifying the type of node in the AST (abstract syntax tree), ensuring that the execution engine can correctly parse and execute the business logic contained in each type of node.

[0053] Specifically, the node processor factory follows the factory design pattern, which is an object-oriented design pattern used to encapsulate the process of object instantiation. When the execution engine starts to execute a rule, it first starts traversing from the AST root node. The node processor factory creates and returns the corresponding node processor based on the type of node traversed. For example, when encountering the THEN keyword, the factory will create a ThenProcessor to process serial nodes; when encountering the PARALLEL keyword, it will create a ParallelProcessor to process parallel nodes. In this way, the execution engine does not need to care about the specific node type and execution logic. It only needs to call the process() method of the node processor to start the execution process of the node. The node processor is responsible for parsing and executing the sub-nodes within its scope of responsibility.

[0054] This embodiment applies steps S201, S202, and S203 above, defining logical orchestration keywords based on the online transaction execution language to form the engine's basic syntax architecture, allowing for flexible orchestration and dynamic updating of business logic. By introducing a syntax validation parser, rule files can be verified, parsed, and initialized to ensure syntactic correctness and the rationality of transaction attributes before execution. Transactions and services are abstracted into nodes by constructing an executable abstract syntax tree (AST), and a multi-tree data structure is formed through connections between nodes, simplifying rule management and expansion. Furthermore, an interpreter executor is designed as a multi-threaded parallel execution engine that can intelligently schedule the execution of transaction nodes based on different node types and parallel strategies, achieving efficient transaction processing capabilities. This embodiment meets the banking industry's requirements for high performance and high reliability, while providing a rich and diverse range of transaction features and ensuring business consistency. This addresses the problem of poor business reliability in existing rule orchestration engines used in banking applications.

[0055] During the specific implementation process, after constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: performing a rule initialization operation on the abstract syntax tree, wherein the rule initialization includes transaction attribute initialization, node attribute initialization, and grayscale strategy initialization.

[0056] Among them, transaction attribute initialization: transaction attributes refer to some default attribute configurations at the rule level, such as transaction attributes, transaction mode, timeout period, persistence engine type, etc.

[0057] Node attribute initialization: Node attributes are the attributes of the nodes that make up the entire transaction rule, such as loop nodes, parallel nodes, service nodes, etc. Each node contains some default attribute values ​​for use by the execution engine.

[0058] Grayscale policy initialization: Each rule has a corresponding grayscale policy. The grayscale policy is mainly used to determine which strategy to use for grayscale release when updating rules, such as by user, by system, by channel, etc. The default is by user.

[0059] This method rule initialization is a critical step in ensuring all necessary parameters and policies are correctly set before transaction processing. For example, transaction attribute initialization involves setting transaction isolation levels, rollback boundaries, and other factors, ensuring transaction consistency and integrity. Node attribute initialization assigns specific execution policies to each node, such as the number of retries and timeouts. This helps optimize resource utilization and improve overall system throughput. Grayscale policy initialization is designed to support a smooth transition between old and new versions, allowing for the gradual deployment of new business rules without impacting the majority of users, thereby reducing risk.

[0060] Specifically, the syntax verification parser is used to perform syntax verification processing on the DSL orchestration data, including: using the syntax verification parser to perform basic field verification on the DSL orchestration data, wherein the basic field verification includes at least one of transaction storage policy detection, plug-in list detection, and transaction type detection; using the syntax verification parser to perform value range verification on the DSL orchestration data, wherein the value range verification includes service node, parallel node, for loop node value detection, and timeout detection; using the syntax verification parser to perform process expression verification on the DSL orchestration data, wherein the process expression verification includes non-empty verification, bracket matching verification, and syntax verification.

[0061] This method's syntax validation parser ensures the correctness and integrity of business logic by rigorously checking the basic fields, value ranges, and process expressions of DSL orchestration data. For example, transaction storage policy detection prevents data consistency issues, plugin list verification ensures that all necessary functional modules are correctly loaded, and transaction type detection prevents the execution of illegal transactions. Value range validation and process expression validation further ensure the logical coherence and grammatical compliance of business processes, reducing potential runtime errors.

[0062] In addition to the aforementioned validation, the syntax validation parser can also include checks on variable naming conventions and validation of the validity of function calls. These additional validation measures can further enhance the robustness and maintainability of the system. For example, by checking that variable names conform to predefined standards, name conflicts can be avoided and code readability improved. Verifying the validity of function calls ensures that all calls are within the expected scope, preventing undefined behavior.

[0063] More specifically, an execution engine is used to traverse each node in the above-mentioned abstract syntax tree, and a node processor corresponding to each of the above-mentioned nodes is called to process the above-mentioned business data, including: when the above-mentioned execution engine is used to traverse the root node in the above-mentioned abstract syntax tree for the first time, a node processor factory is used to determine the first node processor corresponding to the above-mentioned root node; the above-mentioned first node processor is used to determine the scheduling relationship of the next node according to the above-mentioned orchestration rule of the above-mentioned root node and the above-mentioned scheduling logic; when the above-mentioned next node is the above-mentioned leaf node, the second node processor corresponding to the above-mentioned leaf node is determined, and the above-mentioned second node processor is used to process the above-mentioned business data.

[0064] This method's execution engine traverses the abstract syntax tree and calls the corresponding node handler based on the node type, automating the execution of business processes. The node handler factory is responsible for creating and managing various handler types, ensuring that the correct handler instance is retrieved for each call. This design pattern adheres to the principles of object-oriented programming and improves code reusability and scalability. Through the collaborative work of the first and second node handlers, the system intelligently schedules and executes transaction processes, reducing human intervention and improving processing speed and accuracy.

[0065] Furthermore, after constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: configuring a processing timeout strategy for each node in the abstract syntax tree to obtain a timeout configuration rule for each node in the abstract syntax tree, wherein the timeout configuration rule includes at least one of timeout success, timeout success and retry, timeout failure and no rollback, and timeout failure and retry.

[0066] Timeout Success: Under this strategy, even if the execution of a service node exceeds the scheduled time, as long as it is eventually completed successfully, the engine will consider the execution of the service node to be successful. This is suitable for scenarios that do not have strict real-time requirements but want to avoid interrupting subsequent processes due to timeouts.

[0067] Successful retry after timeout: In addition to accepting a successful result after a timeout, the engine will also attempt to re-execute the service node when it first times out. This increases the likelihood of the service node succeeding and is suitable for situations where network fluctuations or short delays may affect the execution of the service node.

[0068] Timeout failure without retry: Once a service node's execution exceeds the specified time, it is immediately considered a failure and no retries are performed. This is a more stringent policy, suitable for business scenarios with high requirements for real-time responsiveness or when retries may introduce additional risks.

[0069] Retry on timeout failure: Even if the execution of a service node exceeds the preset timeout period, the engine will automatically retry the service in the hope that the service can be successfully executed in the subsequent attempt. This strategy is particularly suitable for scenarios where timeouts are often encountered due to external factors (such as temporary unavailability of remote services).

[0070] This method's timeout policy configuration is a crucial tool for ensuring transactions complete within a reasonable timeframe. By defining timeout configuration rules, the system can take appropriate action when a node processing timeout is detected, such as directly marking the transaction as successful to avoid long wait times, attempting to re-execute after a timeout to improve the success rate, or logging a failure without triggering a rollback mechanism to preserve the validity of partial transaction results. The introduction of this policy significantly enhances system robustness and user experience, particularly in high-concurrency environments, effectively managing and controlling transaction execution times, avoiding unnecessary resource waste and system congestion.

[0071] Timeout policy configurations can also include customizable timeout thresholds and notification mechanisms. These configuration options can be flexibly adjusted based on specific business needs. For example, for certain critical transactions, a lower timeout threshold can be set to ensure their completion priority; for non-critical transactions, timeout limits can be appropriately relaxed to improve overall system throughput. Furthermore, the post-timeout notification mechanism promptly informs relevant personnel of transaction status, allowing for remedial measures to be taken, enhancing system transparency and controllability.

[0072] Furthermore, in the process of calling the node processor corresponding to each of the above-mentioned nodes to process the above-mentioned business data, the above-mentioned method also includes: obtaining the processing time of the above-mentioned node processor corresponding to each of the above-mentioned nodes; when the above-mentioned processing time is greater than the set time, determining that the above-mentioned node processor processing has timed out, and controlling the above-mentioned node processor to perform timeout processing on the above-mentioned business data according to the above-mentioned timeout configuration rules.

[0073] By monitoring the processing time of node processors, this method enables the system to detect and respond to timeouts in real time. When processing time exceeds a preset threshold, the system automatically triggers a timeout handling mechanism and takes appropriate action based on configured timeout rules. This mechanism not only effectively prevents transactions from being suspended for extended periods, which can impact system performance, but also ensures transaction accuracy and user satisfaction in unusual situations.

[0074] Furthermore, processing time monitoring can be combined with a dynamic adjustment mechanism, allowing timeout thresholds to be adjusted in real time based on system load and resource availability. For example, during periods of low system load, the timeout threshold can be appropriately increased to allow for more complex transaction flows; during periods of high load, the threshold should be lowered to ensure rapid transaction response. Furthermore, by introducing machine learning algorithms, the system can predict the average processing time of node processors based on historical data, allowing for more precise timeout threshold settings and further optimizing transaction processing.

[0075] Specifically, the above-mentioned node processor includes: at least one of a parallel node processor, a serial node processor, a For node processor, an IF node processor, a Switch node processor, a transaction node processor, a sub-transaction node processor, and a conditional loop node processor, wherein the above-mentioned For node processor is a node processor for loop execution processing sub-nodes, the above-mentioned IF node processor is a node processor for deciding to call a target sub-node according to a SpEL expression, the above-mentioned Switch node processor is a node processor for deciding to execute a target sub-node according to the character value of the above-mentioned SpEL expression, the above-mentioned sub-transaction node processor is a node processor for executing nested sub-transactions, and the above-mentioned conditional loop node processor is a node processor for deciding whether to execute a loop according to the output or input of the previous node.

[0076] The diverse design of this method's node processors enables the system to handle a variety of complex business logic. For example, parallel node processors can execute multiple transaction steps simultaneously, significantly reducing total processing time; serial node processors ensure sequential execution of transactions, meeting the strict process requirements of certain businesses. IF node processors and Switch node processors implement dynamic branching of business processes through conditional judgments, improving the level of intelligent processing. Sub-transaction node processors and conditional loop node processors support nested transactions and loop logic, enhancing the system's flexibility and adaptability.

[0077] In addition, node processors can also include exception handling node processors and logging node processors. These processors can be used to handle exceptions during transactions and record detailed transaction logs, respectively, thereby improving the system's fault tolerance and audit capabilities. For example, the exception handling node processor can immediately take remedial measures upon detecting any anomalies, such as rolling back transactions and sending alerts, to ensure stable system operation; while the logging node processor can record the execution status of each transaction step in detail, providing valuable data support for subsequent troubleshooting and business analysis.

[0078] In addition, this embodiment also includes a dynamic parameter mapping and injection mechanism. In order to improve transaction flexibility and reduce the workload of business developers, a dynamic parameter mapping and injection mechanism is designed. This mechanism allows the engine to automatically match and map request parameters with the input parameters required for the transaction during transaction execution, and can even pass and convert parameters between multiple service nodes. For example, when processing a complex request containing multiple parallel transactions, the engine can identify the dependencies between parallel transactions and automatically map the result parameters of the previous transaction to the input of the next transaction without manually writing additional parameter mapping logic. This feature is particularly important when the parallel strategy is CONTINUE or DIRECT, because under these strategies, even if some transactions fail, other transactions will continue to execute. At this time, dynamic parameter mapping and injection can ensure correct parameter passing and avoid further transaction failures due to parameter errors.

[0079] The application of dynamic parameter mapping and injection significantly simplifies the writing of business logic and improves the flexibility and maintainability of transaction configuration. In actual deployment cases, banking developers have reported that this mechanism makes adjusting and expanding transaction logic extremely convenient, especially when handling complex transaction paths and parallel transactions. Developers no longer need to worry about the underlying parameter matching details, focusing solely on the business logic itself, significantly improving development efficiency and system scalability. Furthermore, by reducing errors associated with manual parameter mapping, system stability has been enhanced.

[0080] This embodiment also includes an intelligent exception management and rollback mechanism. This mechanism allows the engine to automatically perform a rollback operation or take other remedial measures according to a preset strategy when a transaction fails, such as retrying or jumping to an alternative transaction path. Specifically, when the execution engine encounters an abnormal situation when processing a certain transaction node, such as a network failure, data access error, etc., if the node is marked as rollable in the AST, the engine will automatically trigger a rollback operation, undoing all changes to the node and subsequent nodes that may be affected, ensuring data consistency and security. In addition, by analyzing the cause of the exception, the engine can intelligently determine whether the transaction needs to be retried, avoiding unnecessary waste of resources.

[0081] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the business processing method for the online transaction scenario of the present application will be described in detail below with reference to specific embodiments.

[0082] This embodiment relates to a business processing method for a specific online transaction scenario. Similar to popular DSL languages ​​such as XML, SQL, and GraphQL, the customized online transaction execution language OTEL in this embodiment is mainly composed of three modules: keywords, syntax validation parser, and syntax interpretation executor. Among them, keywords define the basic syntax architecture and domain model of OTEL; the syntax validation parser is responsible for syntax loading, validation, and parsing during class storage and class loading; the syntax interpretation executor is similar to the execution engine of the JVM virtual machine, which interprets and executes OTEL and provides comprehensive online transaction-related functions.

[0083] 1. Keywords:

[0084] The keywords in this embodiment are similar to those in common programming languages ​​and DSL languages. Keywords in OTEL are the cornerstone of the online trading engine. They determine the basic data structure of the engine, define the context of the transaction, and play a key role in rule construction, rule verification, rule parsing, rule interpretation and execution, and exception handling.

[0085] In the online trading engine, the defined keywords include: IF, THEN, PARALLEL, WHILE, FOR, SWITCH, and SUBTRADE.

[0086] Adhering to the object-oriented concept, every keyword and every atomic transaction will eventually be encapsulated into a node in the engine, that is, everything in the engine is a node object. This makes it easy to construct and parse the engine language.

[0087] 1) IF, indicating conditions, all capitalized;

[0088] IF(node ​​1, node 2): If the result of the IF expression is true, execute node 1; otherwise, execute node 2. (Note that the node here is not necessarily a specific transaction, but can also be a node encapsulated by other keywords, such as THEN and PARALLEL.) IF requires a judgment condition SpringEL expression. The condition variable can be a request message parameter or an output parameter of a transaction.

[0089] Example:

[0090]

[0091] 2) THEN, indicating serial, all capital letters;

[0092] THEN (node ​​1, node 2), transactions at nodes 1 and 2 are executed serially. If a transaction node is abnormal, the exception handling logic is automatically executed, such as rollback or forward submission.

[0093] 3) PARALLEL, which means parallel, all capital letters;

[0094] PARALLEL(node ​​1, node 2): Node 1 and 2 transactions are executed in parallel, isolated by thread pools, and support multiple parallel strategies, namely ANY, ALL, CONTINUE, and DIRECT.

[0095] ALL: All transactions must be executed successfully;

[0096] ANY: As long as at least one transaction is successfully executed;

[0097] CONTINUE: Regardless of whether the transaction is successful or not, continue to execute forward;

[0098] DIRECT: After initiating a transaction, continue execution without waiting for the execution result;

[0099] Example of parallel node property configuration:

[0100]

[0101] 4) FOR, indicating the number of cycles, all in uppercase;

[0102] FOR(node ​​1) specifies the number of times transaction node 1 is executed in a loop. The execution parameters can be changed according to the index. You can also configure an expression to implement BREAK, that is, to jump out of the loop.

[0103] 5) WHILE, indicating a conditional loop, all in uppercase;

[0104] WHILE (node ​​1) implements conditional looping through conditional expressions. You need to configure the loop condition when using it.

[0105] 6) SWITCH..CASE, select, all capital letters;

[0106] SWITCH(EL).CASE(node ​​1), CASE(node ​​2), select the execution node through the expression.

[0107] 7) SUBTRADE, sub-trading;

[0108] Indicates nested combination transactions. By nesting sub-transactions, the workload of business configuration can be reduced in some scenarios.

[0109] OTEL syntax example:

[0110]

[0111] 2. Syntax validation parser:

[0112] The syntax validation parser loads the compiled JSON data into memory, verifies the metadata, converts and parses it, and initializes the transaction attributes, ultimately constructing a multi-tree object that can be interpreted and executed by the execution engine. The flowchart of the abstract syntax tree construction and syntax validation process is shown in the following figure. Figure 3 As shown, specifically including the following:

[0113] 1) Metadata verification:

[0114] Metadata verification mainly verifies the validity of rule syntax and transaction attribute fields to ensure that there are no incorrect syntax and illegal initialization values ​​in the rules. Metadata verification includes basic field verification, value range verification, and process expression verification.

[0115] Basic field validation includes transaction storage strategy detection, plugin list detection, and transaction type detection;

[0116] Transaction storage policy detection: used to detect whether the transaction storage policy is configured correctly and ensure that the configured storage policy is supported by the engine.

[0117] Plugin list detection: Plugins are an extensible function in this DSL language. This detection mainly verifies whether the plugins defined in the rules are supported by the engine.

[0118] Transaction type detection: The engine currently only supports transaction and query transactions, so it is necessary to detect whether the transaction type defined in the rule is correct.

[0119] Value range verification includes: service node, parallel node, for loop node value detection, and timeout detection;

[0120] Service node, parallel node, and for loop node value detection: Different types of nodes in the DSL syntax will have threshold limits. For example, a loop node cannot loop infinitely, and the default maximum loop is 10 times.

[0121] Timeout: The engine requires that the maximum timeout of the rule configuration cannot exceed 10 minutes, so it is necessary to detect whether the configured timeout exceeds the limit.

[0122] Process expression verification includes: non-empty check, bracket matching check and syntax check:

[0123] Non-empty check: To check whether the SpringEL expression in the rule is empty, the SpEL expression is part of the DSL syntax.

[0124] Bracket matching check: Brackets are an important part of DSL syntax, similar to curly braces in Java, so we check whether they are missing.

[0125] Syntax check: Similar to Java syntax check, it checks whether the grammar is written correctly.

[0126] 2) Abstract syntax tree (AST) construction, including constructing the root node, recursively building nodes layer by layer, and traversing to the end of the leaf node.

[0127] 3) Rule initialization:

[0128] Transaction attribute initialization: Transaction attributes refer to some default attribute configurations at the rule level, such as transaction attributes, transaction mode, timeout period, persistence engine type, etc.

[0129] Node attribute initialization: Node attributes are the attributes of the nodes that make up the entire transaction rule, such as loop nodes, parallel nodes, service nodes, etc. Each node contains some default attribute values ​​for use by the execution engine.

[0130] Grayscale policy initialization: Each rule has a corresponding grayscale policy. The grayscale policy is mainly used to determine which strategy to use for grayscale release when updating rules, such as by user, by system, by channel, etc. The default is by user.

[0131] Rule example:

[0132] grammar:

[0133] THEN(node1,node2,IF(THEN(node3,node4),THEN(PARALLEL(node5,node6),node7);

[0134] The rule diagram corresponding to the grammar example is as follows Figure 4 As shown, the schematic diagram of the abstract syntax tree corresponding to the grammar example is as follows Figure 5 shown.

[0135] 3. Syntax interpretation and execution, also known as the execution engine, is responsible for interpreting and executing the structured objects generated by the syntax validation parser. Its execution characteristics and rules are as follows:

[0136] 1) Any orchestration rule has a root node;

[0137] 2) Near depth-first traversal;

[0138] 3) Each node is an engine object and inherits the same ancestor parent class (base class), that is, it has common basic attribute characteristics;

[0139] 4) The service node (the atomic transaction that is actually called) is a leaf node in the syntax tree;

[0140] 5) Each type of node processor only focuses on the processing of sub-nodes within the current node range and determines the scheduling relationship of the next layer.

[0141] The execution process of the execution engine: Figure 7 As shown, after the thread context is built, the execution engine obtains the abstract syntax tree (rule object), first finds the root node, and then uses the factory mode to use the node processor factory to find the corresponding node processor (the processor corresponds to Figure 6 Each actual processor in the Processor UML class diagram) determines the scheduling relationship of the next layer based on its internal orchestration rules and built-in scheduling logic. If it is a leaf node, the node processor (this processor is a service node processor, specifically used for actual service calls) will call the atomic transaction through the atomic transaction agent; if it is a non-leaf node, the layer processor will recursively call the node object of the next layer until all nodes are deeply traversed.

[0142] Among them, the node processor specifically includes a parallel node processor, an IF node processor, a Switch node processor, a sub-transaction node processor, a For node processor, a serial processor, and a conditional loop processor.

[0143] Parallel node processor: It calls child nodes asynchronously through the thread pool and decides whether to block and wait for the result of the child node to be returned and whether to handle exceptions based on the parallel strategy;

[0144] IF node processor: It is necessary to decide which child node to call based on the SpEL expression. There are only two child nodes, and one of them must be executed.

[0145] Switch node processor: It determines which Case child node to execute based on the character value of the SpEL expression. If no case is found, the execution engine will decide whether to continue execution or throw an exception based on the configured strategy.

[0146] Sub-transaction node processor: For nodes with nested sub-transactions, the processor will determine the propagation mechanism of the nested transaction based on the configuration strategy to decide whether to start or join an existing transaction.

[0147] For node processor: The most important thing about the loop processor is that it can loop through child nodes and effectively identify Break expressions, ending the loop of child nodes when the conditions are met.

[0148] Serial processor: The logic of the serial processor is relatively simple, and it only needs to be traversed and executed in sequence.

[0149] Conditional loop processor: A conditional loop is different from a For loop in that it can determine whether to execute child nodes within the loop based on the previous output or requested input.

[0150] This embodiment also includes a timeout policy design. When calling an actual service node, a timeout handling policy can be configured in the rule. The matching rules of the timeout handling policy include the following:

[0151] Timeout Success: Under this strategy, even if the execution of a service node exceeds the scheduled time, as long as it is eventually completed successfully, the engine will consider the execution of the service node to be successful. This is suitable for scenarios that do not have strict real-time requirements but want to avoid interrupting subsequent processes due to timeouts.

[0152] Successful retry after timeout: In addition to accepting a successful result after a timeout, the engine will also attempt to re-execute the service node when it first times out. This increases the likelihood of the service node succeeding and is suitable for situations where network fluctuations or short delays may affect the execution of the service node.

[0153] Timeout failure without retry: Once a service node's execution exceeds the specified time, it is immediately considered a failure and no retries are performed. This is a more stringent policy, suitable for business scenarios with high requirements for real-time responsiveness or when retries may introduce additional risks.

[0154] Retry on timeout failure: Even if the execution of a service node exceeds the preset timeout period, the engine will automatically retry the service in the hope that the service can be successfully executed in the subsequent attempt. This strategy is particularly suitable for scenarios where timeouts are often encountered due to external factors (such as temporary unavailability of remote services).

[0155] The embodiments of the present application achieve the following technical effects:

[0156] 1) Proprietary DSL language architecture and keyword design. OTEL syntax creates keywords that can be used in various online trading scenarios, including IF, THEN, PARALLEL, WHILE, SWITCH, SUBTRADE, and more. Keywords determine the engine's basic data structure and transaction context, and the syntax supports flexible keyword assembly, arrangement, and hot updates. OTEL provides highly flexible rule-building capabilities, unlike the simple rule types of existing rule engines.

[0157] 2) The execution engine proposes and designs a rich set of multi-threaded parallel call execution strategies, including ALL, ANY, CONTINUE, and DIRECT. This diverse parallel strategy design can meet the diverse parallel transaction requirements of banking services. For example, the DIRECT strategy can be selected in certain scenarios with high real-time requirements, while the ALL strategy can be selected in scenarios with high transaction result accuracy requirements. These are features that existing rule engines do not have or do not fully support.

[0158] 3) We propose an "everything is a node object" solution and construct a customized multi-tree data structure based on node objects, where service nodes are defined as leaf nodes and non-leaf nodes are keyword nodes. We also design an execution strategy that approximates depth-first traversal, implemented using a custom processor factory. This mechanism reduces the complexity and processing overhead of trading rules, improves the speed and accuracy of rule parsing, and enhances the organization and management of trading rules.

[0159] The embodiments of the present application also provide a business processing device for an online transaction scenario. It should be noted that the business processing device for an online transaction scenario in the embodiments of the present application can be used to execute the business processing method for an online transaction scenario provided in the embodiments of the present application. The device is used to implement the above-mentioned embodiments and preferred implementation methods, and the details that have been described will not be repeated here. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0160] The following introduces the business processing device for the online transaction scenario provided by the embodiment of the present application.

[0161] Figure 8 Schematic diagram of a business processing device for an online transaction scenario according to an embodiment of the present application. Figure 8 As shown, the device includes:

[0162] The orchestration processing unit 81 is configured to obtain business data, define logical orchestration keywords based on an online transaction execution language, and orchestrate the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword;

[0163] A construction unit 82 is configured to construct a syntax verification parser, perform syntax verification on the DSL orchestration data using the syntax verification parser, and construct an abstract syntax tree based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, the root node representing the orchestration rules and scheduling logic, and the leaf nodes representing the atomic transactions actually invoked in the business data;

[0164] The calling unit 83 is configured to use an execution engine to traverse each node in the abstract syntax tree and call a node processor corresponding to each node to process the business data.

[0165] In this embodiment, the orchestration processing unit is configured to obtain business data, define logical orchestration keywords based on an online transaction execution language, and orchestrate the business data according to the logical orchestration keywords to obtain DSL orchestration data. The logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword. The construction unit is configured to construct a syntax verification parser, use the syntax verification parser to perform syntax verification on the DSL orchestration data, and construct an abstract syntax tree based on the verified DSL orchestration data. The abstract syntax tree includes a root node and leaf nodes. The root node represents the orchestration rules and scheduling logic, and the leaf nodes represent the atomic transactions actually invoked in the business data. The calling unit is configured to use an execution engine to traverse each node in the abstract syntax tree and call the node processor corresponding to each node to process the business data. By defining logical orchestration keywords based on the online transaction execution language, the engine's basic syntax architecture is constructed, allowing for flexible orchestration and dynamic updating of business logic. By introducing a syntax validation parser, rule files can be verified, parsed, and initialized to ensure their grammatical correctness and the rationality of transaction attributes before execution. Transactions and services are abstracted into nodes by constructing an executable abstract syntax tree (AST), and a multi-tree data structure is formed through connections between nodes, simplifying rule management and expansion. Furthermore, an interpreter executor is designed. As a multi-threaded parallel execution engine, it can intelligently schedule the execution of transaction nodes based on different node types and parallel strategies, achieving efficient transaction processing capabilities. This enables this embodiment to meet the banking industry's requirements for high performance and high reliability, while providing a rich variety of transaction features and business consistency guarantees. This solves the problem of poor business reliability in existing rule orchestration engines used in banking business.

[0166] As an optional solution, the apparatus further includes an initialization operation unit for performing a rule initialization operation on the abstract syntax tree after constructing the abstract syntax tree based on the verified DSL orchestration data, wherein the rule initialization includes transaction attribute initialization, node attribute initialization, and grayscale strategy initialization.

[0167] In an optional solution, the construction unit includes a basic field verification module, a value range verification module, and a process expression verification module; the basic field verification module is used to use the above-mentioned syntax verification parser to perform basic field verification on the above-mentioned DSL orchestration data, wherein the basic field verification includes at least one of transaction storage policy detection, plug-in list detection, and transaction type detection; the value range verification module is used to use the above-mentioned syntax verification parser to perform value range verification on the above-mentioned DSL orchestration data, wherein the value range verification includes service node, parallel node, for loop node value detection, and timeout detection; the process expression verification module is used to use the above-mentioned syntax verification parser to perform process expression verification on the above-mentioned DSL orchestration data, wherein the process expression verification includes non-empty check, bracket matching check, and syntax check.

[0168] An optional solution, the calling unit includes a first determination module, a second determination module and a third determination module, the first determination module is used to use the node processor factory to determine the first node processor corresponding to the above-mentioned root node when the above-mentioned execution engine is used to traverse the root node in the above-mentioned abstract syntax tree for the first time; the second determination module is used to use the above-mentioned first node processor to determine the scheduling relationship of the next node according to the above-mentioned orchestration rules of the above-mentioned root node and the above-mentioned scheduling logic; the third determination module is used to determine the second node processor corresponding to the above-mentioned leaf node when the above-mentioned next node is the above-mentioned leaf node, and use the above-mentioned second node processor to process the above-mentioned business data.

[0169] In an optional solution, the apparatus further includes a configuration unit for, after constructing an abstract syntax tree based on the verified DSL orchestration data, configuring a processing timeout strategy for each node in the abstract syntax tree to obtain a timeout configuration rule for each node in the abstract syntax tree, wherein the timeout configuration rule includes at least one of timeout success, timeout success and retry, timeout failure and no rollback, and timeout failure and retry.

[0170] An optional solution, the device also includes an acquisition unit and a determination unit, the acquisition unit is used to obtain the processing time of the node processor corresponding to each of the above nodes in the process of calling the node processor corresponding to each of the above nodes to process the above business data; the determination unit is used to determine that the processing of the above node processor has timed out when the above processing time is greater than the set time, and control the above node processor to perform timeout processing on the above business data according to the above timeout configuration rules.

[0171] An optional solution, the node processor includes: at least one of a parallel node processor, a serial node processor, a For node processor, an IF node processor, a Switch node processor, a transaction node processor, a sub-transaction node processor, and a conditional loop node processor, wherein the For node processor is a node processor that executes sub-nodes in a loop, the IF node processor is a node processor that determines to call a target sub-node based on a SpEL expression, the Switch node processor is a node processor that determines to execute a target sub-node based on a character value of the SpEL expression, the sub-transaction node processor is a node processor for executing nested sub-transactions, and the conditional loop node processor is a node processor that determines whether to execute a loop based on the output or input of the previous node.

[0172] The business processing device for the online transaction scenario includes a processor and memory. The orchestration processing unit, construction unit, and calling unit are all stored as program units in the memory. The processor executes the program units stored in the memory to implement the corresponding functions. The modules are all located in the same processor; alternatively, the modules can be located in different processors in any combination.

[0173] The processor contains a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be configured, and kernel parameters can be adjusted to address the poor reliability of existing rule-based orchestration engines used in banking applications.

[0174] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0175] An embodiment of the present invention provides a computer-readable storage medium, which includes a stored program. When the program is executed, the device where the computer-readable storage medium is located is controlled to execute the business processing method for the online transaction scenario.

[0176] An embodiment of the present invention provides a processor, which is used to run a program, wherein the program executes the business processing method for the online transaction scenario when running.

[0177] An embodiment of the present invention provides an electronic device comprising a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements at least the steps of the business processing method for the online transaction scenario described above. The device herein may be a server, a PC, a PAD, a mobile phone, or the like.

[0178] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program for initializing steps of a business processing method having at least the above-mentioned online transaction scenario.

[0179] Obviously, those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, can be centralized on a single computing device, or can be distributed across a network of multiple computing devices. They can be implemented using program code executable by the computing device, and thus, can be stored in a storage device and executed by the computing device. In some cases, the steps shown or described herein can be performed in a different order than that shown, or can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0180] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0181] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0182] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0183] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0184] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0185] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0186] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0187] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0188] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A business processing method for an online transaction scenario, characterized in that: include: Acquiring business data, defining logical orchestration keywords based on an online transaction execution language, and orchestrating the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword; Building a syntax verification parser, using the syntax verification parser to perform syntax verification processing on the DSL orchestration data, and building an abstract syntax tree based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, the root node represents the orchestration rules and scheduling logic, and the leaf nodes represent the atomic transactions actually called in the business data; An execution engine is used to traverse each node in the abstract syntax tree, and a node processor corresponding to each node is called to process the business data.

2. The method according to claim 1, characterized in that After constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: A rule initialization operation is performed on the abstract syntax tree, wherein the rule initialization includes transaction attribute initialization, node attribute initialization, and grayscale strategy initialization.

3. The method according to claim 1, characterized in that The syntax verification parser is used to perform syntax verification processing on the DSL formatted data, including: Using the syntax validation parser to perform basic field validation on the DSL orchestration data, wherein the basic field validation includes at least one of transaction storage policy detection, plug-in list detection, and transaction type detection; The syntax verification parser is used to perform value interval verification on the DSL arrangement data, wherein the value interval verification includes service node, parallel node, for loop node value detection, and timeout detection; The syntax verification parser is used to perform process expression verification on the DSL orchestration data, wherein the process expression verification includes non-empty verification, bracket matching verification and syntax verification.

4. The method according to claim 1, wherein Using an execution engine to traverse each node in the abstract syntax tree and calling a node processor corresponding to each node to process the business data includes: In a case where the execution engine is used to traverse the root node in the abstract syntax tree for the first time, determining a first node processor corresponding to the root node by using a node processor factory; Determine, by the first node processor, a scheduling relationship of a next node according to the orchestration rule of the root node and the scheduling logic; In the case that the next node is the leaf node, a second node processor corresponding to the leaf node is determined, and the second node processor is used to process the service data.

5. The method according to claim 1, wherein After constructing an abstract syntax tree based on the verified DSL orchestration data, the method further includes: The processing timeout strategy of each node in the abstract syntax tree is configured to obtain the timeout configuration rule of each node in the abstract syntax tree, wherein the timeout configuration rule includes at least one of timeout success, timeout success and retry, timeout failure and no rollback, and timeout failure and retry.

6. The method according to claim 5, characterized in that In the process of calling the node processor corresponding to each of the nodes to process the service data, the method further includes: Obtaining the processing time of the node processor corresponding to each of the nodes; When the processing time is longer than the set time, it is determined that the node processor has timed out, and the node processor is controlled to perform timeout processing on the service data according to the timeout configuration rule.

7. The method according to claim 1, characterized in that The node processor includes: At least one of a parallel node processor, a serial node processor, a For node processor, an IF node processor, a Switch node processor, a transaction node processor, a sub-transaction node processor, and a conditional loop node processor, Among them, the For node processor is a node processor that executes sub-nodes in a loop, the IF node processor is a node processor that determines to call the target sub-node based on the SpEL expression, the Switch node processor is a node processor that determines to execute the target sub-node based on the character value of the SpEL expression, the sub-transaction node processor is a node processor for executing nested sub-transactions, and the conditional loop node processor is a node processor that determines whether to execute a loop based on the output or input of the previous node.

8. A business processing device for an online transaction scenario, characterized in that: include: an orchestration processing unit, configured to obtain business data, define logical orchestration keywords based on an online transaction execution language, and orchestrate the business data according to the logical orchestration keywords to obtain DSL orchestration data, wherein the logical orchestration keywords include at least one of a conditional keyword, a serial keyword, a parallel keyword, a number of loop keywords, a conditional loop keyword, a selection keyword, and a sub-transaction keyword; a construction unit, configured to construct a syntax verification parser, perform syntax verification processing on the DSL orchestration data using the syntax verification parser, and construct an abstract syntax tree based on the verified DSL orchestration data, wherein the abstract syntax tree includes a root node and leaf nodes, the root node representing the orchestration rules and scheduling logic, and the leaf nodes representing the atomic transactions actually called in the business data; The calling unit is used to use an execution engine to traverse each node in the abstract syntax tree and call a node processor corresponding to each node to process the business data.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the business processing method for the online transaction scenario according to any one of claims 1 to 7.

10. An electronic device, characterized in that: include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs include a business processing method for executing the online transaction scenario described in any one of claims 1 to 7.

Images