A service logic orchestration method and system

Abstract

The application discloses a service logic arrangement method and system, and relates to the technical field of service logic arrangement of industrial software.The method comprises the following steps: in response to a service request, initializing an execution context and establishing a transaction compensation mechanism; obtaining definition information containing service nodes and resource operation attributes; constructing a directed acyclic graph based on data dependency between nodes and determining an execution time sequence; dividing the nodes into transaction batches according to the resource operation attributes; executing the nodes and temporarily storing the data to be persisted in the execution context; at the convergence point of the directed acyclic graph, submitting database transactions in batches according to the transaction batches; and after the completion of the database transaction submission or rollback, triggering a resource recycling process uniformly by the arrangement engine.The application reduces the number of database transaction submissions through node clustering based on resource operation attributes and transaction merging at the convergence point, and ensures the data consistency and the reliability of resource release by triggering the resource recycling uniformly after the completion of the transaction.

Description

Technical Field

[0001] This application relates to the field of business logic orchestration technology for industrial software, specifically to a business logic orchestration method and system. Background Technology

[0002] As the complexity of industrial software and distributed systems increases, business logic orchestration technology is widely used to handle complex processes involving multiple interconnected nodes. Existing business orchestration solutions are typically implemented based on workflow engines or microservice architectures.

[0003] However, existing technologies have the following drawbacks when dealing with scenarios requiring high concurrency and strong consistency: First, transaction granularity control is coarse. Existing technologies typically adopt a "one business node corresponds to one database transaction" model. When the business process contains a large number of fine-grained nodes, frequent database commit operations will occur, leading to a surge in the number of database log flushes, consuming a large amount of I / O resources and database connections, and seriously affecting system throughput.

[0004] Second, resource reclamation and transaction state are out of sync. In existing technologies, distributed locks, caches, and other resources are typically released immediately after the business node code finishes execution (e.g., in a try-finally block). However, at this time, the database transaction may not have been finally committed. If a system exception or concurrency conflict occurs after resource release but before transaction commit, other transactions may intervene and modify data because the lock has been released, leading to a loss of data consistency. Furthermore, if developers forget to manually release the lock, resource leaks are highly likely.

[0005] Third, there is a lack of automatic optimization based on data attributes. Existing orchestration engines typically determine the execution order based solely on business process dependencies, lacking awareness of node data operation attributes (such as read / write types and involved data tables). This makes it impossible to automatically merge conflict-free nodes for execution, hindering further optimization of transaction boundaries.

[0006] Therefore, there is an urgent need for a business logic orchestration method that can optimize the frequency of transaction commits and ensure consistency between resource reclamation and transaction state. Summary of the Invention

[0007] This application provides a business logic orchestration method and system to solve the problems of low system performance caused by frequent database transaction commits in the prior art, and data consistency risks caused by the timing of node resource release being earlier than the transaction write-in.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a business logic orchestration method, comprising: responding to a business request, initializing an execution context associated with the business request, and establishing a transaction compensation mechanism; obtaining business logic definition information, the business logic definition information including multiple business nodes and resource operation attributes of each business node; constructing a directed acyclic graph based on the data dependency relationships between the multiple business nodes, and determining the execution sequence of the nodes; dividing the multiple business nodes into at least one transaction batch according to the resource operation attributes, wherein business nodes with compatible resource operation attributes are classified into the same transaction batch; executing the business nodes according to the execution sequence, and temporarily storing the data to be persisted generated by each node in the execution context; submitting database transactions in batches according to the transaction batches at the convergence point of the directed acyclic graph; and after the database transactions are submitted or rolled back, the orchestration engine uniformly triggers a resource reclamation process to execute a preset resource cleanup operation.

[0009] Secondly, the present invention also provides a business logic orchestration system, comprising: a transaction coordination module, used to respond to a business request, initialize an execution context associated with the business request, and establish a transaction compensation mechanism; an orchestration construction module, used to obtain business logic definition information, construct a directed acyclic graph based on the data dependency relationships between the multiple business nodes, and determine the execution sequence of the nodes; a transaction merging module, used to divide the multiple business nodes into at least one transaction batch according to the resource operation attributes, and submit database transactions in batches according to the transaction batches at the merging point of the directed acyclic graph; a node execution module, used to execute the business nodes according to the execution sequence, and temporarily store the data to be persisted generated by each node to the execution context; and a resource reclamation module, used to trigger a resource reclamation process uniformly by the orchestration engine after the database transaction is committed or rolled back, and execute preset resource cleanup operations.

[0010] Thirdly, the present invention also provides an electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to execute the business logic orchestration method.

[0011] The beneficial effects of the technical solutions provided in this application include: By dividing multiple business nodes into transaction batches based on resource operation attributes and submitting database transactions in batches at the convergence point of the directed acyclic graph, the number of database commits and log flushing frequency are significantly reduced, database lock contention is reduced, and system throughput is improved.

[0012] By delaying the resource reclamation process until after the database transaction is committed or rolled back, and having it triggered uniformly by the orchestration engine, the risk of inconsistency caused by "data not yet written to the database but locks already released" is avoided, ensuring the reliability of resource release under abnormal paths.

[0013] By automatically constructing directed acyclic graphs based on input-output contracts and using the engine to enforce transaction boundaries and resource lifecycles, the amount of code developers need to manually handle transactions and resource releases is reduced, thus lowering the probability of errors.

[0014] By clustering resource operation attributes, transaction boundaries are automatically optimized, creating a closed loop between problem, solution, and effect. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating an embodiment of the business logic orchestration method of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0018] Example 1 This embodiment provides a business logic orchestration method that runs at the business logic layer of an industrial internet platform, and is particularly suitable for distributed systems such as mold MES, financial transactions, or multi-node collaborative systems. Figure 1 As shown, this method is implemented based on a three-layer nested responsibility chain architecture of "transaction coordination - business orchestration - node execution", and specifically includes the following steps: Step S101: In response to a business request, initialize the execution context associated with the business request and establish a transaction compensation mechanism. Specifically, when the orchestration engine receives an externally initiated business request (e.g., a work order creation request), it first obtains the current thread handling the request and initializes the thread-local storage space (e.g., ThreadLocal in Java) bound to the current thread as the execution context. This execution context is used to store temporary data, transaction states, and resource handles throughout the entire business process lifecycle, ensuring data isolation and transmission security within the thread. Simultaneously, the engine establishes a transaction compensation mechanism based on the Saga pattern. The engine creates a global transaction state machine to record the forward execution state sequence of the current business unit. If an exception occurs in a subsequent process, the engine will trigger compensation operations on the executed business nodes in reverse order according to this state machine, ensuring eventual consistency of distributed transactions across business units.

[0019] Step S102: Obtain business logic definition information, which includes multiple business nodes and resource operation attributes of each business node. The orchestration engine loads the logic definition file (e.g., JSON or XML format) corresponding to the current business request from the orchestration description repository (e.g., database or configuration center). Each business node not only contains a reference to the execution logic class but also explicitly declares its own resource operation attributes. The resource operation attributes include at least: Database operation type (dbOpType): Indicates whether the node is a read-only (READ_ONLY), write (WRITE), or mixed operation.

[0020] TargetTables: Identifies the database table names, shard keys, or cache keys involved in the operation of this node.

[0021] Step S103: Construct a directed acyclic graph (DAG) based on the data dependencies between the multiple business nodes and determine the execution order of the nodes. The engine scans the input contract and output contract of each business node. If the output data structure of node A matches the input requirements of node B, a dependency edge is established from node A to node B. Based on all dependency edges, the engine uses a topological sorting algorithm (e.g., Kahn's algorithm) to construct the DAG. During the sorting process, the engine marks nodes without dependencies as parallel execution nodes and nodes with dependencies as serial execution nodes. Simultaneously, the algorithm detects circular dependencies in the graph; if a cycle is detected, an exception is thrown and the process terminates, thus avoiding deadlock risks early in the compilation or runtime phase.

[0022] Step S104: dividing the plurality of service nodes into at least one transaction batch according to the resource operation attribute. The engine traverses all nodes in the DAG, and performs automatic clustering according to the resource operation attribute declared in step S102. Specific division strategies include: Nodes whose operation type is identified as read-only are classified into a read-only batch, and this batch does not need to open a database write transaction.

[0023] Nodes whose operation type is identified as write and whose involved data resource scopes (such as table names) have no intersection are merged into the same write batch.

[0024] Assess the data resource conflict risk between service nodes according to the database operation attribute; split service nodes with conflict risk into different write batches, and merge service nodes without conflict risk into the same write batch. Through this step, the original N service nodes are divided into K transaction batches (K<N), realizing the optimization of transaction boundaries.

[0025] Step S105: execute the service nodes according to the execution sequence, and temporarily store the to-be-persisted data generated by each node into the execution context. The engine schedules the executor to call the business logic code of each service node according to the sequence determined in step S103. The key point is that the data that needs to be persisted generated during the node execution process (such as SQL change records, entity object changes) does not immediately call the database driver to submit to the database, but is captured through an interceptor or AOP aspect, and written into the temporary storage area (Temp Store) of the execution context initialized in step S101. At this stage, the nodes may have applied for distributed locks or loaded cache data, but these resources remain held and have not been released.

[0026] Step S106: at the convergence point of the directed acyclic graph, submit database transactions in batches according to the transaction batches. When all branches of the DAG are executed and reach the Join Point, the engine collects all temporarily stored to-be-persisted data in the execution context. The engine sequentially opens database transactions (for example, Connection.setAutoCommit(false)) according to the order of the transaction batches divided in step S104, and batch writes the data in the batch to the database and submits (Connection.commit()). During this process, the engine performs version number optimistic lock verification and field conflict detection. If a version conflict is detected, the current batch is aborted, the transaction is marked as failed, and the transaction compensation mechanism established in step S101 is triggered to perform rollback.

[0027] Step S107: After a database transaction is committed or rolled back, the orchestration engine triggers a unified resource cleanup process to execute preset resource cleanup operations. This step is crucial for ensuring data consistency. Regardless of whether the transaction commit in step S106 succeeds or fails and is rolled back, the orchestration engine only triggers the post-processor chain after the database transaction state is finally determined. The engine traverses the post-processor registry of executed nodes and executes resource cleanup operations in reverse order of registration. Specific operations include, but are not limited to: Release the distributed lock (such as a Redis lock) held by the node.

[0028] The local or distributed cache loaded by the failed node.

[0029] Write to the audit log and operation record.

[0030] This mechanism cleans up temporary data in the execution context to prevent memory leaks. It ensures that resource holding covers the entire transaction lifecycle, avoiding the risk of "locks being released but data not being stored."

[0031] Through the above steps, this embodiment optimizes the traditional "node-level transaction" into a "batch-level transaction". In a typical scenario with 50 nodes, the number of database commits can be reduced from 50 to about 17, and the time consumption is reduced by about 42%. At the same time, by uniformly managing the timing of resource reclamation through the engine, the reliability of resource release under abnormal paths is ensured, and the lock leakage rate is reduced to 0 (no leakage was observed during the test).

[0032] Example 2 This embodiment, based on Embodiment 1, provides a specific implementation architecture for a business logic orchestration system. Implemented in Java, this embodiment employs a three-layer nested responsibility chain architecture: a transaction coordination chain, a business orchestration chain, and a node execution chain. The system mainly includes an orchestration engine core, a context manager, a collection of node executors, and a post-processor registry.

[0033] The transaction coordination chain, located at the top layer, is responsible for the lifecycle management of the global transaction context. It is implemented as a transaction coordinator class, providing interfaces for starting and committing global transactions. This chain does not directly handle business logic but maintains the global transaction state machine and triggers the Saga compensation mechanism when any business unit fails. The business orchestration chain, located in the middle layer, is responsible for constructing the directed acyclic graph (DAG) and dividing transaction batches. It is implemented as an orchestration engine class, including a DAG construction module, a node clustering module, and a transaction merging module. This chain parses the orchestration description file and calculates transaction batches based on the resource operation attributes declared by the nodes. The node execution chain, located at the bottom layer, is responsible for executing atomic business logic. It is implemented as a node executor interface, and all business nodes must implement the execution methods of this interface.

[0034] In this embodiment, business nodes are declared through configuration description files (such as JSON, XML, or database configuration). The following example uses a material reservation node to demonstrate its JSON declaration structure: { "id":"materialReserve", "dbOpType":"WRITE", "targetTables":["mat_reserve","mat_stock"], "inputContract":{"bomList":"List <bomitem>"}, "outputContract":{"reserveResult":"ReserveResult"}, "postProcessors":["ReleaseLockPostProcessor","AuditLogPostProcessor"] } The dbOpType and targetTables fields are used by the orchestration engine's clustering algorithm, while the inputContract and outputContract fields are used by the DAG automatic construction algorithm for dependency inference.

[0035] Regarding the construction of the execution topology, this embodiment specifically implements it as a directed acyclic graph (DAG). Each business node is defined as a business node object, declaring its input contract and output contract. During compilation or initialization, the system scans the contract declarations of each business node. When the input field name and type of the second node match the output field of the first node, a dependency edge from the first node to the second node is added to the DAG. Subsequently, the Kahn algorithm is used to perform topological sorting and cycle detection on the DAG. If the number of nodes in the sorted result is less than the total number of declared nodes, a circular dependency is determined, the system refuses to load the orchestration description, and throws an exception.

[0036] Regarding the specific logic of node clustering and transaction merging, the orchestration engine maintains a transaction batch manager, which divides nodes based on their declared dbOpType and targetTables attributes. The specific clustering strategy is as follows: all nodes with dbOpType set to READ_ONLY are grouped into the first read-only transaction batch, with the isolation level set to Read Committed; for nodes with dbOpType set to WRITE, if two nodes have no overlap in their targetTables, they are merged into the same write batch; if they involve the same database table but have no row lock conflict risk, they are merged into the same batch; if they involve the same database table and have a hotspot conflict risk, they are split into different batches to avoid row lock contention; for nodes with dbOpType set to MIXED, they are treated as a separate transaction batch, with the isolation level set to Repeatable Read.

[0037] At the convergence point of the directed acyclic graph (DAG), the orchestration engine collects the temporarily stored data to be persisted in the execution context and performs optimistic version number verification. If a version conflict is detected, the current batch is aborted and the Saga compensation chain is triggered. Specifically, the transaction commit trigger condition is the detection of reaching the convergence point of the DAG, i.e., the moment when all termination nodes with an out-degree of 0 have completed execution. When triggering the commit, the system performs field conflict detection: if two nodes are found to have different write values ​​to the same field in the same row, they are handled according to a predefined conflict resolution strategy, such as write-after-over or rejection with an error. Subsequently, transactions are started sequentially according to the clustering order, database operations are executed in batches, and transactions are committed.

[0038] Regarding the mandatory resource reclamation mechanism, this embodiment implements it through a post-processor sub-chain. Each business node can register one or more processors that implement the post-processor interface. Crucially, the orchestration engine does not trigger the post-processor immediately after node execution, but rather triggers the post-processor sub-chain uniformly after the database transaction is committed or rolled back. The triggering logic does not depend on the try-finally block in the node's business code; instead, it is uniformly scheduled by the engine and executed in reverse order of registration. The advantage of this design is that even if resource release logic is omitted in the business node code, the orchestration engine can still provide fallback reclamation. Specifically, the audit log writing operation performed by the post-processor includes writing the node execution time, operation type, operation result, and the scope of the database table involved in the operation into the audit log for compliance review and fault location.

[0039] Furthermore, the transaction compensation mechanism in this embodiment specifically adopts the Saga pattern.

[0040] When an exception occurs during business execution, the transaction coordination chain first determines whether there is a previously committed preceding business unit: If there is no committed unit (i.e., the abnormal node and the preceding node are in the same transaction batch): the orchestration engine will abort the current batch commit and trigger the database transaction rollback. No business compensation operation is required, and data consistency is guaranteed by the atomicity of the database.

[0041] If there are committed units (i.e., the abnormal node and the preceding node are in different transaction batches): the transaction coordination chain triggers the compensation operation of the committed business units and executes them in reverse order.

[0042] This method is particularly suitable for scenarios with strong consistency across multiple nodes. In this embodiment, the three-layer architecture interacts through the following nested collaboration mechanism: the transaction coordination chain creates a global transaction context and schedules business units; the business orchestration chain receives a global context reference and schedules business processing nodes according to the DAG topology; after the node execution chain completes atomic operations, it aggregates the output data to the business orchestration chain context; when all termination nodes with an out-degree of 0 in the DAG have completed execution, the orchestration engine triggers a transaction batch merging process, dividing the data into K transaction batches based on the clustering results, and committing them sequentially in the order of read-only batches, write batches, and mixed batches (if there are independent external interaction nodes, they can be divided into independent batches). After all business units are successfully completed, the transaction coordination chain performs a global commit; if any business unit fails, if there is a committed preceding unit, the compensation chain is triggered to perform compensation operations in reverse order, and regardless of whether compensation is triggered, the post-processor sub-chains of all executed nodes of the current business unit are traversed to ensure that system resources are completely reclaimed under any execution path.

[0043] This embodiment supports plug-in extensions and runtime hot reloading. Adding a new business node only requires implementing the standard business node interface and declaring its location and attributes in the orchestration description file; no modification to the core engine code is needed. The system-provided class loader supports dynamically loading new node class instances at runtime, thereby enabling hot updates of business logic. It should be noted that the implementation of the above execution context is not limited to the Java thread model; it can also be a coroutine context, a request scope container, or other storage mechanisms that can guarantee request isolation. The above configuration description file is not limited to JSON format; it can also be YAML, XML, or database table configuration. The above post-processor mechanism can also be embedded in the node base class or implemented through annotations. Any implementation that achieves node clustering based on data operation attributes and a mandatory resource reclamation mechanism is considered an equivalent implementation of this application.

[0044] In a preferred embodiment of the present invention, an intelligent merging strategy is employed: even if multiple nodes involve the same database table, if no row lock conflict risk is assessed (e.g., based on primary key range analysis), they are merged into the same batch to minimize the number of transaction commits. In another optional embodiment of the present invention, a conservative splitting strategy is employed: as long as multiple nodes involve the same database table, it is considered that there is a potential conflict risk, and they are split into different batches to reduce the risk of data conflict.

[0045] Example 3 This embodiment provides a business logic orchestration system, which can be used to execute the business logic orchestration method described in Embodiment 1 or Embodiment 2. The system mainly includes a transaction coordination module, an orchestration construction module, a node execution module, a transaction merging module, and a resource reclamation module. The modules interact with each other through an internal bus, message queue, or inter-process communication mechanism to jointly complete the orchestration and execution of business logic.

[0046] The transaction coordination module is primarily used to respond to business requests, initialize the execution context associated with the business request, and establish a transaction compensation mechanism. In a specific implementation, this module can be located at the top level of the system, responsible for managing the global transaction state. For example, this module can maintain a transaction state machine to track whether the current request is in progress, committed, or rolled back. When an abnormal interruption of the business process is detected, this module is responsible for triggering compensation operations in reverse order to ensure eventual data consistency. In a preferred architecture of this system, this module is also used to chain interceptor sub-chains at the entry point of the business request, complete pre-processing tasks such as tenant identity resolution and permission verification, and bind the initialized execution context to the current processing thread or coroutine.

[0047] The orchestration and construction module is primarily used to acquire business logic definition information containing multiple business nodes, construct an execution topology based on the data dependencies between these business nodes, and determine the execution sequence of the nodes. This module can integrate a DAG builder and a topology sorter. During system initialization, this module scans the input-output contracts of each business node and automatically establishes dependency edges between nodes. During runtime, this module calculates the execution order of nodes based on dependencies and marks nodes without dependencies as executable in parallel. The completed topology and execution sequence information are sent to the node execution module and transaction merging module as the basis for execution scheduling and batch partitioning.

[0048] The node execution module is primarily used to execute the business nodes sequentially or in parallel according to the execution sequence, and temporarily store the generated data to be persisted in the execution context. This module communicates with the underlying database or external services, and is responsible for calling atomic operation processors to complete specific business logic. During execution, this module does not immediately commit the database transaction, but instead temporarily stores the change records in the memory context to prepare for subsequent batch commits.

[0049] The transaction merging module is primarily used to divide multiple business nodes into at least one transaction batch based on the resource operation attributes, and to batch commit database transactions according to the transaction batches when the transaction commit trigger condition is detected. This module communicates with the database connection pool and is responsible for managing the initiation and commit of transactions. Specifically, this module maintains a batch manager, which merges the operation requests of multiple nodes into fewer transaction batches based on the operation type declared by the nodes and the data table information involved. When it receives the convergence signal from the orchestration building module, indicating that the DAG convergence point has been reached, this module collects the data to be persisted from the execution context, performs optimistic locking verification, and sends commit instructions to the database in batches.

[0050] The resource reclamation module is used to trigger a unified resource reclamation process by the orchestration engine after a database transaction is committed or rolled back, executing preset resource cleanup operations. This module is independent of the specific logic of the business nodes and is uniformly scheduled by the orchestration engine. Specifically, this module maintains a post-processor registry, storing the resource cleanup callback functions registered by each node. When the database transaction state is finally determined, this module iterates through the callback functions in reverse order of registration and executes them, releasing distributed locks, cached resources, etc.

[0051] It should be noted that the system architecture described in this embodiment is only a logical functional division. In actual hardware deployment, the above modules can be integrated into the same server process or distributed across different microservice nodes. For example, the transaction coordination module can be deployed at the gateway layer, while the orchestration and construction module and the transaction merging module can be deployed at the business logic layer. Furthermore, the above modules can be implemented through software programs, dedicated hardware acceleration cards, or a combination of software and hardware. The system described in this embodiment can be hosted on an electronic device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the computer program to implement the method described in Embodiment 1.

[0052] Example 4 This embodiment, based on embodiments one through three, specifically illustrates the practical application of the business logic orchestration method in an industrial internet platform. The method in this embodiment is particularly suitable for complex business scenarios requiring strong consistency and linkage among multiple nodes, such as the work order creation process in a mold manufacturing MES system, and the multi-recipe switching process in the injection molding industry.

[0053] In the work order creation scenario of a mold manufacturing MES system, a complete work order creation business unit involves the collaboration of multiple business nodes, such as BOM expansion, material reservation, and quality inspection task generation. In traditional solutions, these nodes often commit transactions independently. If the material reservation node has already committed its transaction independently, but the quality inspection task generation node subsequently rolls back due to an anomaly, the system will fall into a data inconsistency state where the material has been reserved but there is no corresponding quality inspection task. This intermediate state is difficult to detect and repair automatically in traditional solutions. Using the technical solution of this embodiment, the orchestration engine first initializes the execution context and establishes a Saga transaction compensation mechanism. Subsequently, based on the resource operation attributes declared by each node, the BOM expansion node (read-only) is divided into read-only transaction batches; the material reservation node (writing to the material table) and the quality inspection task generation node (writing to the quality inspection table), although involving different data tables, are assessed to have no row lock conflict risk and are therefore merged into the same write transaction batch. Combined with the read-only batches, the final actual division is into 2 transaction batches (K=2). During node execution, the data to be persisted is temporarily stored in the execution context and not immediately committed. When all nodes have completed their execution and reached the DAG convergence point, the orchestration engine commits the database transactions in batches. Crucially, the distributed locks and cached resources held during this process are not released when the node code finishes execution, but rather released by the orchestration engine through a unified triggering of the post-processor chain after the database transaction has been committed or rolled back.

[0054] Exception handling mechanisms fall into two categories: One is an in-batch anomaly (transaction not committed). If a node within the same transaction batch (such as a quality inspection task generation node) fails to execute, the orchestration engine will directly abort the commit of the batch transaction because the batch data is still temporarily stored in the execution context and has not been persisted. The database does not need to perform a rollback operation, and the material reservation data will naturally not generate persistent records.

[0055] Secondly, there's the cross-batch exception (transaction already committed). If the current node fails while the preceding transaction batch (such as the batch containing material reservations) has already been committed to the database, the transaction coordination chain will trigger a Saga compensation operation. This operation performs reverse compensation (such as calling the inventory release interface or writing write records) for the already persisted preceding business units, ensuring eventual consistency of distributed transactions across business units. Furthermore, regardless of the situation, the post-processor sub-chain will be triggered, responsible for releasing memory locks, clearing caches, and other non-persistent resources.

[0056] The following example, using the work order creation process of a mold manufacturing company's MES system, demonstrates the specific application of this method. This process involves multi-node linkage of five business processing nodes, and the attribute declarations of each node are shown in Table 1.

[0057] Table 1. Schematic diagram of business node attribute declaration

[0058] The orchestration engine processing flow is as follows: The DAG is automatically constructed, and the contract declaration is scanned to infer four dependency edges: "BOM expansion → material reservation", "process route selection → work order writing", "material reservation → work order writing", and "work order writing → quality inspection task generation". "BOM expansion" and "process route selection" have no dependency relationship and are automatically identified as parallel nodes.

[0059] The execution nodes were clustered, with READ_ONLY nodes grouped into read-only batches; WRITE nodes, although involving different target tables, were assessed as having no row lock conflict risk and were merged into the same write transaction batch. Ultimately, it was divided into 2 transaction batches, with 5 business nodes generating only 2 database commit operations, while the traditional model required 5.

[0060] To ensure transaction consistency, if a node generating a quality inspection task throws an exception during execution, the merging process at the rendezvous point detects the anomaly in the data to be persisted at that node, aborting the current write batch and triggering a transaction rollback. Since the material reservation data within the same batch has not yet been persisted, no business data compensation operation is required; database transaction rollback guarantees data consistency. After the transaction rollback is complete, the orchestration engine uniformly triggers the post-processor sub-chain to release system resources, such as releasing distributed locks and clearing caches. If there are committed preceding business batches, the transaction coordination chain will trigger compensation operations in Saga mode, rolling back persisted business data (such as releasing deducted inventory). This mechanism ensures that uncommitted business data is not persisted to the database, and system resources are reliably reclaimed.

[0061] In the context of multiple formulation switching scenarios in the injection molding industry: Formula parameters and quality inspection standards must be atomically synchronized. If the formula parameters have been updated but the quality inspection standard update fails, the quality inspection basis of the produced products will be incorrect. This embodiment uses node clustering based on data operation attributes to divide the formula parameter update nodes and quality inspection standard update nodes into transaction batches according to the range of data tables involved. If there is no risk of lock conflict between the two, they can be merged into the same write batch for batch submission, reducing the frequency of database interactions. At the same time, through the post-processor sub-chain mechanism, it is ensured that temporary caches and lock resources generated during the switching process are cleaned up uniformly after the transaction status is determined. Regardless of whether the node execution result is successful, failed, or degraded, the orchestration engine forcibly triggers resource cleanup operations, avoiding the problem of dirty reads caused by the omission of cache release logic in the business code.

[0062] This scenario involves the linkage of 4 service nodes, including a formula verification node, a formula parameter writing node, a device parameter issuing node, and a quality inspection standard updating node. Among them, the formula verification node is classified into a read-only batch; the formula parameter writing node and the quality inspection standard updating node are combined into a write batch; the device parameter issuing node is independent as a hybrid batch due to involvement in external device interaction. Finally, 3 transaction batches are divided, with a total of 4 nodes, and the number of commit times is reduced from 4 in the traditional mode to 3. More critically, the formula parameter writing and the quality inspection standard updating are atomically committed within the same transaction batch, which completely eliminates the data inconsistency risk that the formula parameters are updated but the quality inspection standards are not synchronized. The post-processor sub-chain of the device parameter issuing node executes the device state rollback operation under any execution path, ensuring that the device will not be in a hanging state during parameter issuing.

[0063] In addition, the technical solution of this embodiment can also be extended and applied to cross-border payment and clearing scenarios in the financial transaction field, as well as order fulfillment scenarios in the e-commerce field. In the financial scenario, the transaction batch merging mechanism can be used to reduce the database lock waiting time when deducting money from multiple accounts; in the e-commerce scenario, the post-processor unified triggering mechanism can be used to ensure cache consistency and message notification reliability after operations such as inventory deduction and point change. It should be noted that the above application scenarios are only exemplary descriptions, and all scenarios involving database transaction optimization and resource consistency management in multi-node service orchestration fall within the protection scope of the present invention. This embodiment supports defining node positions and connection relationships through orchestration description files in JSON or YAML formats. Adding a new service node only requires implementing a unified interface and declaring it in the description file, without modifying the code of existing nodes, and supports dynamic loading and unloading of orchestration definitions at runtime to achieve dynamic service expansion.

[0064] Embodiment Five This embodiment performs performance testing and effect verification on the service logic orchestration methods and systems provided in Embodiment 1 to Embodiment 4, so as to quantitatively evaluate the technical effects of the present invention in reducing the number of database transaction commits, lowering system time consumption, eliminating resource leaks, and ensuring data consistency.

[0065] The test environment is based on an industrial internet platform simulation cluster, the hardware configuration is a 4-core 8G application server, the database adopts MySQL 8.0, and the middleware adopts Redis as the distributed lock and cache service. The test concurrency is set to 50 threads, and each scenario is repeated 1000 times to obtain the average value. The comparison solutions include the conventional independent transaction solution, the conventional Saga solution, the conventional TCC solution, and the single global transaction 2PC solution. The solution of this embodiment adopts a node clustering and convergence point transaction batch merging mechanism based on resource operation attributes, and uniformly triggers resource recycling after the database transaction commit or rollback is completed.

[0066] The test scenario selected was the process reporting workflow of a mold MES system. This workflow involves the collaboration of multiple business systems, including work order scheduling, material distribution, quality inspection, and process reporting. In traditional solutions, problems frequently arise such as quality inspection nodes being triggered before materials arrive and equipment status not being verified when reporting a process. By adopting the three-layer chain of responsibility orchestration method provided in this embodiment, the transaction coordination chain ensures that business units execute in the correct dependency order, and the business orchestration chain ensures that nodes execute according to the declared topology. After implementation, the error rate of reporting records decreased from approximately 5% in the traditional solution to below 0.1%, and manual correction workload was reduced by 95%. In terms of scalability, adding a cost accounting function requires only about 200 lines of code and declaring node attributes, taking 2 days; while the conventional solution requires modifying multiple components, taking more than 2 weeks and involving approximately 2000 lines of code. This solution reduces the amount of change code by approximately 90%.

[0067] In terms of performance metrics, the comparison data between this scheme and the conventional independent transaction scheme are shown in Table 3.

[0068] Table 3 Performance Comparison Test Table of Different Solutions

[0069] As shown in Table 3, in terms of transaction commit count, in the traditional solution, N business nodes independently start and commit transactions, resulting in 100 database commit operations across 100 nodes. This embodiment divides nodes into transaction batches based on resource operation attributes and commits them in batches at the DAG convergence point. In a typical test scenario, this reduces 100 commits to 34, decreasing database interaction frequency by approximately 66%. This directly leads to a significant decrease in average latency; the average time for the system to process the same business request decreases from 1820ms to 891ms, a performance improvement of approximately 51%. The main reason for this is the reduction in database log flushing times and lock contention waiting time.

[0070] To further illustrate the technical advantages of this solution, it is compared and analyzed with three common distributed transaction processing modes. While the conventional Saga solution possesses cross-unit compensation capabilities, each node still commits independently, resulting in a similar number of commits and processing time as the conventional independent transaction solution. The conventional TCC solution, due to its Try / Confirm two-phase commit, doubles the number of commits and incurs high development costs. The single global transaction 2PC solution holds locks for read operations at repeatable read or higher isolation levels, with lock waiting times approximately 4 to 6 times longer than this solution, and the failure of any node leads to a global rollback, undoing completed read-only operations. This solution, while retaining the cross-unit coordination capabilities of Saga, compresses intra-unit commits to approximately N / 3 through resource operation attribute clustering, and eliminates the need for global locks. In high-concurrency scenarios, throughput is increased by approximately 40%, and in abnormal rollback scenarios, average rollback time is reduced by approximately 60%.

[0071] Regarding the reliability of resource reclamation, after introducing the post-processor sub-chain, the distributed lock leakage rate decreased from approximately 2% to 0 (no leakage was observed during testing), business anomaly tickets caused by dirty cache decreased from an average of approximately 15 per month to 0, and the audit log integrity rate increased from 94% to 100%. Crucially, this embodiment achieves resource reclamation through the post-processor sub-chain, which is uniformly triggered by the orchestration engine after the node execution chain is completed. The triggering timing is as follows: regardless of whether the node execution result is success, failure, or degradation, the orchestration engine only triggers the post-processor sub-chain of that node after the database transaction is committed or rolled back, executing sequentially in reverse order of registration. Since the triggering of post-processing is guaranteed by the orchestration engine rather than the node code, node developers do not need to write resource reclamation code in the business logic, eliminating the possibility of missing post-processing at the architectural level and avoiding the risk of data inconsistency caused by resource release preceding transaction write-in.

[0072] In summary, this embodiment verifies the effectiveness of the proposed method in resolving technical issues such as execution timing disorder, difficulty in guaranteeing data consistency, and resource leakage through specific test data. This solution achieves optimized commit counts within units, elimination of intermediate states, and resource reclamation of abnormal paths through a three-layer collaborative approach: Saga cross-unit coordination, resource operation attribute clustering and confluence point merging within unit transactions optimization, and post-processor reverse-order resource reclamation layer guarantee. This is done without forcing each node to implement three sets of interfaces or introducing global locks. Those skilled in the art will understand that this method can also be applied to other fields requiring strong consistency processing across multiple nodes, such as financial clearing and e-commerce fulfillment.

[0073] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0074] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0075] In the description of the embodiments in this application, terms such as "exemplary," "for example," or "for instance" are used to indicate that they are examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being better or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a specific manner.

[0076] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0077] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0078] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0079] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.< / bomitem>

Claims

1. A business logic orchestration method, characterized in that, include: In response to a business request, initialize the execution context associated with the business request and establish a transaction compensation mechanism; Obtain business logic definition information, which includes multiple business nodes and resource operation attributes of each business node; A directed acyclic graph is constructed based on the data dependencies between the multiple business nodes, and the execution sequence of the nodes is determined. Based on the resource operation attributes, multiple business nodes are divided into at least one transaction batch, wherein nodes with compatible resource operation attributes are classified into the same transaction batch. The business nodes are executed according to the execution sequence, and the data to be persisted generated by each node is temporarily stored in the execution context. At the convergence point of the directed acyclic graph, database transactions are submitted in batches according to the transaction batch. After a database transaction is committed or rolled back, the orchestration engine triggers a unified resource reclamation process to execute preset resource cleanup operations.

2. The method according to claim 1, characterized in that, The construction of a directed acyclic graph based on data dependencies between multiple business nodes includes: Dependency edges are established based on the matching relationship between the input and output contracts of business nodes; The dependent edges are sorted using a topological sorting algorithm. Nodes with no dependencies are marked as executable in parallel, while nodes with dependencies are marked as executable in a forced serial manner.

3. The method according to claim 1, characterized in that, The resource operation attributes include an operation type identifier and the scope of data resources involved; the step of dividing multiple business nodes into at least one transaction batch based on the resource operation attributes includes: Nodes whose operation type is marked as read-only are grouped into read-only batches; Nodes whose operation type is identified as write and whose data resource ranges do not overlap are merged into the same write batch; The total number of transaction batches after division is less than the total number of business nodes.

4. The method according to claim 1, characterized in that, The step of batch committing database transactions at the convergence point of the directed acyclic graph, according to the transaction batch, includes: Collect the data to be persisted in the execution context at the convergence point; Perform optimistic locking verification of version number and field conflict detection. If a version conflict is detected, abort the current batch and trigger a compensation rollback. Batch commit database transactions in sequence.

5. The method according to claim 1, characterized in that, The resource reclamation process, uniformly triggered by the orchestration engine, includes: The orchestration engine checks the commit status of transaction batches, and triggers the post-processor chain after confirming that all transaction batches have been successfully committed or rolled back. The post-processor chain executes at least one of the following operations in reverse order of registration: distributed lock release, cache invalidation, audit log writing, and execution context temporary data cleanup.

6. The method according to claim 1, characterized in that, The establishment of the transaction compensation mechanism includes: The Saga pattern is used to manage the lifecycle of distributed transactions across business units; the business unit corresponds to one or more business nodes in the business orchestration chain. In the normal process, business units are executed in forward order. If any business unit fails, compensation operations for the already executed business units are triggered in reverse order.

7. The method according to claim 1, characterized in that, The initialization of the execution context associated with the business request includes: Obtain the current thread that is processing the business request, and initialize the thread-local storage space bound to the current thread as the execution context; A pre-verification interceptor sub-chain is connected at the entry point of the business request. The interceptor sub-chain sequentially performs at least one of the following operations: tenant identity resolution, permission verification, request parameter desensitization, and request log embedding.

8. The method according to any one of claims 1 to 7, characterized in that, The method is applicable to industrial control scenarios, financial transaction scenarios, or e-commerce fulfillment scenarios that require strong consistency and linkage among multiple nodes.

9. A business logic orchestration system, characterized in that, include: The transaction coordination module is used to respond to a business request, initialize the execution context associated with the business request, and establish a transaction compensation mechanism. The orchestration and construction module is used to obtain business logic definition information, construct a directed acyclic graph based on the data dependencies between the multiple business nodes, and determine the execution sequence of the nodes; The business logic definition information includes multiple business nodes and the resource operation attributes of each business node. The transaction merging module is used to divide multiple business nodes into at least one transaction batch according to the resource operation attributes, and to submit database transactions in batches according to the transaction batches at the merging point of the directed acyclic graph. The node execution module is used to execute the business nodes according to the execution sequence and temporarily store the data to be persisted generated by each node into the execution context. The resource reclamation module is used to trigger a unified resource reclamation process by the orchestration engine after a database transaction is committed or rolled back. Regardless of the execution result of the business node, the preset resource cleanup operation is performed.

10. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor is configured to invoke the instructions stored in the memory to perform the method according to any one of claims 1 to 8.

Images