Workflow control method based on hierarchical constraints, execution method, device, medium and program product

Abstract

The application provides a workflow control method and execution method based on hierarchical constraints, equipment, medium and program product, the method acquires a plurality of business execution units in a workflow layer for constituting a business process, and is hierarchically configured as a process unit, a component unit and a task unit, a hierarchical constraint relationship is established, so that the process unit can be called by a page control layer, and the component unit is called only inside the workflow layer. After the page control layer initiates a business processing request, the request parameters are mapped into process input parameters based on the parameter alias in the input parameter mapping structure and transmitted into the process unit; the process unit schedules the component unit and the task unit for execution according to the hierarchical constraint relationship, each execution unit executes corresponding business operations according to the transaction type and the upper call environment, and maps the execution result into the page return parameter based on the parameter alias in the output parameter mapping structure. The application improves the controllability of the workflow call boundary, the accuracy of parameter transmission and the stability of process execution.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a workflow control method, execution method, device, medium and program product based on hierarchical constraints. Background Technology

[0002] As the business complexity of enterprise application systems continues to increase, business processes typically require the orchestration of multiple execution units through workflows, with parameter passing, transaction control, and data manipulation occurring between the page control layer, process layer, and data access layer. For such business process processing systems, the clarity of the call boundaries between workflow execution units and the standardization of parameter passing relationships between the page control layer and the process layer directly impact the stability of business process execution and the accuracy of data processing.

[0003] However, in existing technologies, workflow processing units typically lack clear calling constraints. Different business processing units may be arbitrarily nested or directly called by inappropriate callers based on process configurations, leading to complex internal calling relationships and unclear execution boundaries. When there are continuous calls, conditional jumps, or reused calls between multiple processing units in a business process, the uncertainty of these calling relationships can easily make execution paths difficult to control, thus affecting system execution stability and the reusability of processing units. Simultaneously, parameter passing between the page control layer and the process layer often lacks standardized control. When page request parameters, process processing parameters, and return parameters generated during execution flow between different processing stages, value errors, overwriting errors, or abnormal return results can easily occur, leading to data anomalies or process logic errors. In scenarios involving transaction control and data operations in business processes, unclear calling relationships and non-standardized parameter passing further increase the difficulty of data consistency control during execution. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this application provides a workflow control method, execution method, device, medium, and program product based on hierarchical constraints, which at least solves the problems of unclear workflow calling relationships and error-prone cross-layer parameter transmission in existing technologies, leading to insufficient reliability of business process execution.

[0005] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0006] In a first aspect, some embodiments of this application provide a workflow control method based on hierarchical constraints, including:

[0007] The system acquires multiple business execution units from the workflow layer that constitute a business process, and configures these units hierarchically according to preset boundary constraint rules to construct a multi-level execution unit. The multi-level execution unit includes process units, component units, and task units. The task unit is the smallest indivisible and non-nested execution unit. The component unit is formed by combining at least one task unit and / or at least one defined component unit, and is configured as a private execution unit that is only invoked within the workflow layer. The process unit is formed by combining at least one task unit and / or at least one component unit, and is configured as a public execution unit that can be invoked by the page control layer, representing a complete business processing unit.

[0008] Establish hierarchical constraints between the process unit, the component unit, and the task unit; wherein, the hierarchical constraints include: the process unit does not nest other process units, and the component unit is not directly called by the page control layer;

[0009] Establish an input parameter mapping structure and an output parameter mapping structure between the page control layer and the workflow layer; wherein, the input parameter mapping structure and the output parameter mapping structure both include parameter name, parameter type, default value and parameter alias, and complete the parameter mapping between the page control layer and the workflow layer based on the parameter alias.

[0010] Secondly, some embodiments of this application provide a workflow execution method based on hierarchical constraints, including:

[0011] In response to a business processing request initiated by the page control layer, the request parameters in the business processing request are mapped to process input parameters in the workflow layer based on parameter aliases in the input parameter mapping structure pre-established between the page control layer and the workflow layer, and the process input parameters are passed to the process unit corresponding to the business processing request.

[0012] According to the preset hierarchical constraints, the process unit schedules the execution of its internal component units and task units;

[0013] During the execution of the process unit, the component unit, or the task unit, the transaction type corresponding to the current execution unit and the transaction status of the superior calling environment are obtained, and the corresponding business operation is determined to be performed by the current execution unit based on the transaction type and the transaction status, so as to obtain the unit execution result of the current execution unit;

[0014] Based on the execution path of the process unit, the execution results of the unit are transmitted or summarized to determine the execution result of the process unit;

[0015] Based on the parameter aliases in the output parameter mapping structure pre-established between the workflow layer and the page control layer, the execution result of the process unit is mapped to the page return parameter returned to the page control layer.

[0016] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0017] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform either the hierarchical constraint-based workflow control method described above, or the hierarchical constraint-based workflow execution method described above.

[0018] Fourthly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, wherein the computer program and / or instructions, when executed by a processor, implement the workflow control method based on hierarchical constraints as described above, or implement the workflow execution method based on hierarchical constraints as described above.

[0019] Fifthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the workflow control method based on hierarchical constraints as described above, or implement the workflow execution method based on hierarchical constraints as described above.

[0020] Compared with existing technologies, the solution provided in this application, by hierarchically configuring multiple business execution units constituting a business process into process units, component units, and task units in the workflow layer, and configuring component units as private execution units that can only be called within the workflow layer, and configuring process units as public execution units that can be called by the page control layer, gives business execution units of different granularities clear hierarchical boundaries and calling boundaries. This avoids arbitrary nesting of workflow units or inappropriate external calls, thereby improving the stability of the workflow structure and the reusability of business execution units. Simultaneously, by establishing input parameter mapping structures and output parameter mapping structures between the page control layer and the workflow layer, and completing parameter mapping between the page control layer and the workflow layer based on parameter aliases, the request parameters in the business processing request can be transformed through the input parameter mapping structure. The workflow layer inputs parameters to the corresponding workflow units, and the execution results of these units are converted into page return parameters via an output parameter mapping structure before being returned to the page control layer. This avoids parameter mismatches, incorrect values, and return anomalies caused by direct parameter passing between the page control layer and the workflow layer, improving the accuracy and controllability of cross-layer parameter transmission. Furthermore, during workflow execution, business processing requests initiated by the page control layer can enter the corresponding workflow units through the input parameter mapping structure. The workflow units then schedule their internal component units and task units for execution based on hierarchical constraints. During the execution of each unit, the corresponding transaction execution environment is determined based on the transaction type of the current execution unit and the transaction status of the superior calling environment, enabling workflow units, component units, and task units to execute business operations according to their independently configured transaction types. This decentralizes transaction control granularity from the overall workflow down to each level of execution unit, improving the fineness of transaction execution and data consistency control capabilities in complex business processes. Therefore, the embodiments of this application can form unified constraints and controls in terms of workflow structure, call boundaries, parameter passing, transaction execution and result return, reducing the risk of execution anomalies caused by chaotic process calls and non-standard parameter passing, and improving the operational stability, data processing reliability and maintenance efficiency of the business process processing system. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a workflow control method based on hierarchical constraints provided in an embodiment of this application;

[0023] Figure 2 A schematic diagram of the parameter mapping structure between the page control layer and the workflow layer provided in an embodiment of this application;

[0024] Figure 3 This is a flowchart illustrating a workflow execution method based on hierarchical constraints provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] Some embodiments of this application relate to a workflow control method based on hierarchical constraints. This method can be applied to software systems that need to organize multiple business execution units through workflow, such as order processing systems, supply chain management systems, financial reimbursement systems, inventory management systems, or other business process orchestration systems. The aforementioned systems may include a page control layer and a workflow layer. The page control layer can receive user operations or external business requests and initiate business processing requests to the workflow layer. The workflow layer can host multiple business execution units constituting a business process and organize, invoke, and control each business execution unit according to the configuration relationship of the business process. (See also...) Figure 1 As shown, the method may include the following steps:

[0028] Step A1: Obtain multiple business execution units in the workflow layer that constitute the business process, and configure these multiple business execution units hierarchically according to preset boundary constraint rules to construct a multi-level execution unit. The multi-level execution unit includes process units, component units, and task units. The task unit is the smallest indivisible and non-nested execution unit. The component unit is formed by combining at least one task unit and / or at least one defined component unit, and is configured as a private execution unit that can only be called within the workflow layer. The process unit is formed by combining at least one task unit and / or at least one defined component unit, and is configured as a public execution unit that can be called by the page control layer, and is used to represent a complete business processing unit.

[0029] Specifically, a business process can be a processing flow used to achieve a complete business objective, and multiple business execution units can be configurable execution objects of different granularities that constitute this business process. For example, in an order processing scenario, the business process can be a "create order" process, which is used to complete the entire process of receiving a new order request from the page control layer, performing necessary business validations, and saving order information. The multiple business execution units constituting this business process can include a credit check execution unit, an inventory check execution unit, an order saving execution unit, a user information query execution unit, a product inventory query execution unit, and a conditional judgment execution unit, etc.

[0030] In some embodiments, the preset boundary constraint rules may include execution granularity constraints, composition relationship constraints, and invocation attribute constraints. Execution granularity constraints determine whether a business execution unit is the smallest indivisible and non-nested execution unit; composition relationship constraints determine whether a business execution unit is formed by combining other task units or defined component units; and invocation attribute constraints determine whether a business execution unit is allowed to be invoked by the page control layer, or whether it is only allowed to be invoked within the workflow layer. Based on the above boundary constraint rules, multiple business execution units in the workflow layer can be configured hierarchically to construct a multi-level execution unit including process units, component units, and task units.

[0031] If a business execution unit is used to perform basic business operations such as saving data, querying data, and making conditional judgments, and this business execution unit does not contain other business execution units, then it can be configured as a task unit based on execution granularity constraints. As the smallest execution granularity in the business process, the task unit is not nested below process units, component units, or other task units, thereby ensuring clear boundaries for underlying business operations.

[0032] If a business execution unit is formed by combining at least one task unit, or at least one defined component unit, or a combination of at least one task unit and at least one defined component unit, and this business execution unit is only for internal calls within the workflow layer and not used as an entry point for direct calls from the page control layer, then this business execution unit can be configured as a component unit based on composition relationship constraints and call attribute constraints. A defined component unit refers to a component unit whose internal composition relationship has been configured and which has been determined to be called only within the workflow layer; it can be reused by other component units or process units. Component units are used to encapsulate reusable intermediate business logic within the workflow layer, such as internal processing logic like credit checks, inventory checks, and inventory holding. They can be called by process units or other component units, but are not directly exposed to the page control layer.

[0033] If a business execution unit is formed by combining at least one task unit and / or at least one defined component unit, and this business execution unit is used to carry out a complete business processing procedure and can serve as the entry point for the page control layer to initiate business processing requests, then this business execution unit can be configured as a process unit based on composition relationship constraints and call attribute constraints. A process unit is used to represent a complete business processing unit, such as a new order process, an approval process, or a reimbursement process. It can serve as a public entry point for the page control layer to enter the workflow layer, and during execution, it schedules its internal component units and task units to complete the corresponding business processing.

[0034] For example, in the business process of creating a new order, the new order can be configured as a process unit as the entry point for a complete business process, and can be invoked by the page control layer. During execution, this process unit can call the credit check component unit, the inventory check component unit, and the order save task unit. The credit check component unit can include a user credit information query task unit, a prepayment user judgment task unit, and a credit occupancy check component unit; the inventory check component unit can include a product inventory query task unit and an inventory occupancy component unit; and the order save task unit can be used to perform basic operations such as saving order data. Thus, the process unit, as a public execution unit that can be invoked by the page control layer, is used to carry out the complete business process; the component unit, as a private execution unit invoked internally by the workflow layer, is used to encapsulate intermediate business logic such as credit checks and inventory checks; and the task unit, as the smallest indivisible and non-nested execution unit, is used to perform basic business operations such as querying, judging, and saving. Through the above hierarchical configuration, the external call entry point of the complete business process can be kept clear, and the internal business logic and basic business operations can be encapsulated and reused at different granularities. This avoids the direct call of component units by the page control layer and the continued nesting of task units with other execution units, thereby improving the stability and maintainability of the business process structure.

[0035] Step A2: Establish hierarchical constraints between process units, component units, and task units; among which, the hierarchical constraints include: process units should not nest other process units, and component units should not be directly called by the page control layer.

[0036] Specifically, after constructing process units, component units, and task units, hierarchical constraints can be further established between these three types of execution units. These hierarchical constraints constrain the inclusion, calling, and external callable scope of process units, component units, and task units within the workflow layer. Specifically, process units, as public execution units that can be called by the page control layer, can serve as external entry points for business processes; component units, as private execution units that are only called within the workflow layer, can be called internally by process units or other component units, but are not allowed to be directly called by the page control layer; and task units, as the smallest indivisible and non-nested execution unit, are no longer used as containers for other execution units. Thus, a hierarchical calling system can be formed within the workflow layer, with process units as external entry points, component units as internal reuse structures, and task units as the basic execution structure.

[0037] In some embodiments, hierarchical constraints may include preventing process units from nesting other process units. That is, a process unit can schedule its internal component units and task units to complete a full business process, but it should not configure or call another process unit as its subordinate execution object. This constraint avoids nesting between complete business processes, which can lead to confusing call entry points, unclear execution boundaries, and difficulty in maintaining process paths. For example, in the "Create Order" business process, "Create Order" can be a process unit that can call the "Credit Check" component unit, the "Inventory Check" component unit, and the "Save Order" task unit. However, it should not nest another complete "Create Order" process unit or other complete process units within the "Create Order" process unit. If nesting of other process units is detected within a process unit during the configuration or execution phase, an exception message can be generated, and the process configuration can be refused to be saved or the process unit can be refused to be executed.

[0038] Hierarchical constraints can also include preventing component units from being directly called by the page control layer. While component units can be formed by combining task units and predefined component units, and can encapsulate internal business logic such as credit checks, inventory checks, and inventory holding, their scope of invocation is limited to the workflow layer. When the page control layer initiates a business processing request, it should call the process unit that represents the complete business processing unit, and cannot directly call the component unit. Taking the new order scenario as an example, the page control layer can initiate a "New Order" request and call the corresponding process unit, but it cannot bypass the "New Order" process unit and directly call the "Credit Check" or "Inventory Check" component units. This ensures that external requests always enter through the complete business process entry point, preventing internal component logic from being directly called externally and disrupting the integrity and execution order of the business process.

[0039] In some embodiments, the hierarchical constraint relationship described above can be achieved through a combination of configuration validation and runtime validation. Configuration validation can be performed during the process definition, process saving, or process loading phases to determine whether the lower-level execution object of a process unit contains other process units, and whether the component unit is configured as a direct calling object of the page control layer. Runtime validation can be performed when the page control layer initiates a business processing request or when the workflow layer schedules an execution unit, to determine whether the current call conforms to the hierarchical constraint relationship. If it is detected that a process unit nests other process units, or that the page control layer directly calls a component unit, the system can throw an exception, reject the corresponding configuration, or reject the corresponding execution.

[0040] Step A3: Establish the input parameter mapping structure and output parameter mapping structure between the page control layer and the workflow layer; wherein, the input parameter mapping structure and the output parameter mapping structure both include parameter name, parameter type, default value and parameter alias, and complete the parameter mapping between the page control layer and the workflow layer based on the parameter alias.

[0041] Specifically, after constructing multi-level execution units in the workflow layer and establishing hierarchical constraints, an input parameter mapping structure and an output parameter mapping structure can be further established between the page control layer and the workflow layer. Since the request parameter names in the page control layer, the process input parameter names in the workflow layer, and the parameter names used within different execution units may not be entirely consistent, directly passing parameters between the page control layer and the workflow layer can easily lead to parameter mismatches, parameter overriding, or abnormal return results. Therefore, this embodiment of the application uses an input parameter mapping structure and an output parameter mapping structure to provide structured constraints on parameter passing between the page control layer and the workflow layer.

[0042] In some embodiments, the input parameter mapping structure can be used to constrain the process of the page control layer passing parameters to the workflow layer, and the output parameter mapping structure can be used to constrain the process of the workflow layer returning parameters to the page control layer. Both the input and output parameter mapping structures can include a parameter name, a parameter type, a default value, and a parameter alias. The parameter name can represent the name of the parameter at the source level or in the current configuration; the parameter type can represent the data type of the parameter; the default value can provide a default parameter content when no valid parameter value is obtained; and the parameter alias can establish a mapping relationship between parameters in the page control layer and the workflow layer. Therefore, parameter passing between the page control layer and the workflow layer no longer relies on direct name passing, but instead establishes a clear correspondence through parameter aliases.

[0043] Reference Figure 2As shown, in some embodiments, the page control layer and the workflow layer can pass parameters through input parameter mapping structures and output parameter mapping structures. The page control layer can include request parameters, such as user_id and order_id; the workflow layer can include process input parameters corresponding to the request parameters, such as uid and oid. The input parameter mapping structure can establish a correspondence between the page control layer's request parameters and the workflow layer's process input parameters based on parameter aliases. For example, user_id in the page control layer can be mapped to uid in the workflow layer, and order_id in the page control layer can be mapped to oid in the workflow layer. Thus, even if the parameter names used by the page control layer and the workflow layer are different, a correspondence can be established through parameter aliases, enabling the workflow layer to execute business processes based on the mapped process input parameters. The output parameter mapping structure can be used to map the execution result parameters generated by the workflow layer to page return parameters that the page control layer can receive. In other words, when the workflow layer returns the execution result to the page control layer, it does not directly rely on the parameter name inside the workflow layer for the return. Instead, it determines the return parameter name used by the page control layer when receiving the execution result through the parameter alias in the output parameter mapping structure.

[0044] In some embodiments, the input parameter mapping structure and the output parameter mapping structure can be defined using a structured configuration approach. For example, for a task unit used to perform data saving operations, its task unit name, execution address, transaction type, input parameter mapping structure, and output parameter mapping structure can be defined using the following configuration snippet:

[0045] <jobunit>

[0046] <jobunitname> saveit2< / jobunitname>

[0047] <unittype> Normal< / unittype>

[0048] <jobuniturl> savedata< / jobuniturl>

[0049] <txtype> TX_REQUIRED< / txtype>

[0050] <create>

[0051] <param>

[0052] <paramname> schema< / paramname>

[0053] <paramtype> String< / paramtype>

[0054] <paramalias> schema< / paramalias>

[0055]

[0056] <param>

[0057] <paramname> objstosubmit< / paramname>

[0058] <paramtype> Vector< / paramtype>

[0059] <paramalias> collection< / paramalias>

[0060]

[0061] <param>

[0062] <paramname> EAIName< / paramname>

[0063] <paramtype> String< / paramtype>

[0064] <paramalias> EAIName< / paramalias>

[0065]

[0066] < / create>

[0067] <return>

[0068] <param>

[0069] <paramname> errorcode< / paramname>

[0070] <paramtype> Vector< / paramtype>

[0071] <paramalias> newerrorcode< / paramalias>

[0072]

[0073] < / return>

[0074] <conditionforward>

[0075] <conditionforwardname / >

[0076] <next> the forward< / next>

[0077] < / conditionforward>

[0078] <visinfo> -10905,8200:3932276,6< / visinfo>

[0079] < / jobunit>

[0080] In the example above, JobUnitName represents the task unit name, JobUnitUrl represents the execution address corresponding to the task unit, and TxType represents the transaction type corresponding to the task unit. Create can be used as an input parameter mapping structure to define the parameters passed to the task unit by the caller in the workflow layer when the task unit is invoked; Return can be used as an output parameter mapping structure to define the parameters returned to the caller in the workflow layer after the task unit completes execution. In each parameter item, ParamName represents the parameter name in the caller's execution environment, ParamType represents the parameter type, and ParamAlias ​​represents the parameter alias corresponding to the parameter when used within the called task unit or returned to the caller.

[0081] For example, in the `Create` structure, the parameter name `objstosubmit` has a parameter type of `Vector`, and its alias is `collection`. This means that the parameter flowing through the caller's execution environment in the workflow layer can be `objstosubmit`, while within the called task unit, it can be used through the alias `collection`. Thus, the parameter is not passed directly, but a mapping relationship is established between the caller's parameter and the parameters within the called task unit through parameter aliases. In the `Return` structure, the parameter name `errorcode` has an alias of `newerrorcode`, indicating that the result parameter generated after the task unit's execution can be returned to the caller in the workflow layer through the alias `newerrorcode`, and further returned to the page control layer according to the output parameter mapping structure between the page control layer and the workflow layer. Through this method, a structured parameter mapping can be achieved between the page control layer and the workflow layer, as well as during calls within the workflow layer, avoiding parameter mismatches, parameter overwriting, or return exceptions caused by direct parameter passing.

[0082] In a preferred embodiment, step A3, which involves mapping parameters between the page control layer and the workflow layer based on parameter aliases, specifically includes:

[0083] Step A3101: When the page control layer passes parameters to the workflow layer, the request parameters of the page control layer are mapped to the process input parameters of the workflow layer according to the parameter aliases in the input parameter mapping structure.

[0084] Specifically, after the page control layer initiates a business processing request, it can obtain the request parameters from the request and match them with the parameter items in the input parameter mapping structure. If there is a parameter alias corresponding to the request parameter in the input parameter mapping structure, a workflow input parameter that the workflow layer can recognize can be generated based on the parameter alias, and the workflow input parameter can be passed to the corresponding workflow unit. For example, in the example above, ParamName is objstosubmit and ParamAlias ​​is collection, indicating that the parameter passed by the caller in the page control layer or workflow layer can be mapped to an input parameter that can be used within the called task unit through the alias collection. Thus, even if the request parameter and the parameter name used internally in the workflow layer are different, a mapping relationship between the two can be established through the parameter alias.

[0085] Step A3102: When the workflow layer returns parameters to the page control layer, the execution result parameters of the workflow layer are mapped to the page return parameters of the page control layer according to the parameter aliases in the output parameter mapping structure.

[0086] Specifically, after a process unit, component unit, or task unit completes execution, it generates an execution result parameter. Based on the parameter alias corresponding to this execution result parameter in the output parameter mapping structure, the page return parameter used by the page control layer to receive the execution result can be determined. For example, in the above example, ParamName is errorcode and ParamAlias ​​is newerrorcode, indicating that the result parameter errorcode generated after the task unit execution can be returned to the caller in the workflow layer through the alias newerrorcode, and further passed back as a page return parameter recognizable by the page control layer. Therefore, even if the name of the execution result parameter generated internally in the workflow layer differs from the name of the return parameter received by the page control layer, a correspondence can be established between them through the parameter alias in the output parameter mapping structure. This ensures that the parameter naming within the workflow layer and the return parameter naming in the page control layer are independent, avoiding mismatches in return results due to inconsistent parameter names.

[0087] Specifically, when passing parameters between the page control layer and the workflow layer, if it is detected that the parameter to be passed has not established a mapping relationship based on the parameter alias in the input parameter mapping structure or the output parameter mapping structure, the parameter to be passed between the page control layer and the workflow layer will be rejected.

[0088] In some embodiments, when the page control layer and the workflow layer pass parameters, a mapping validation can be performed on the parameters to be passed. If the parameter to be passed has already established a mapping relationship based on the parameter alias in the input parameter mapping structure or the output parameter mapping structure, then the parameter to be passed is allowed to be passed according to the corresponding input parameter mapping structure or the output parameter mapping structure; if it is detected that the parameter to be passed has not established a mapping relationship based on the parameter alias, then the parameter to be passed is rejected from being passed between the page control layer and the workflow layer. This avoids the page control layer and the workflow layer from directly passing parameters by bypassing the input parameter mapping structure or the output parameter mapping structure, so that both the request parameter input and the execution result return are constrained by the parameter alias mapping, thereby improving the accuracy and controllability of cross-layer parameter passing.

[0089] In a preferred embodiment, the method further includes:

[0090] Configure transaction types for process units, component units, and task units respectively; among which, transaction types include: the first transaction type that uses the parent transaction, the second transaction type that uses the parent transaction when the parent transaction exists and creates a new transaction when the parent transaction does not exist, the third transaction type that always creates an independent transaction, the fourth transaction type that does not use the parent transaction, the fifth transaction type that controls transactions manually, and the sixth transaction type that prohibits the use of transactions.

[0091] Specifically, each process unit, component unit, and task unit in the workflow layer can be configured with a transaction type. In other words, transaction types are not uniformly set only at the level of the entire business process, but can be configured down to different levels of execution units. This allows process units, component units, and task units to configure corresponding transaction control strategies based on their business processing characteristics, data consistency requirements, and invocation relationships. For example, a process unit can configure transaction types for the entire business process, a component unit can configure transaction types for its internal reusable business logic, and a task unit can configure transaction types for basic business operations such as saving data, querying data, and conditional judgments. Therefore, within the same business process, different execution units can have different transaction control methods, thereby improving the granularity of transaction control.

[0092] In some embodiments, the transaction type may include a first to a sixth transaction type. The first transaction type may indicate the use of a parent transaction; that is, when the current execution unit is called by a parent execution unit, the current execution unit uses the parent transaction that already exists in the parent calling environment. The second transaction type may indicate that the current execution unit must execute in a transactional environment; when a parent transaction already exists in the parent calling environment, the current execution unit uses that parent transaction; when no parent transaction exists in the parent calling environment, a new transaction is created for the current execution unit. The third transaction type may indicate that an independent transaction is always created; that is, regardless of whether a parent transaction already exists in the parent calling environment, an independent transaction is created for the current execution unit, allowing the current execution unit to execute in a transactional environment independent of the parent transaction. The fourth transaction type may indicate that a parent transaction is not used; that is, the current execution unit does not join the parent transaction in the parent calling environment, but executes in an environment without using a parent transaction. The fifth transaction type may indicate that transactions are manually controlled; that is, the current execution unit can control whether the transaction is committed or rolled back. The sixth transaction type can indicate that transactions are prohibited, meaning that the current execution unit executes in a transaction-free environment, and no existing transaction or new transaction is allocated to the current execution unit.

[0093] For example, in the business process of creating a new order, the new order process unit can be configured as a second transaction type, so that the complete business process uses the parent transaction when a parent transaction exists and creates a new transaction when no parent transaction exists; the save order task unit, since it involves writing order data, can be configured as a second or third transaction type to ensure that the save operation is in a clear transaction environment; some query task units can be configured as a first or fourth transaction type to control whether they need to participate in the parent transaction; for certain read-only or external call operations that are not allowed to be executed in a transaction environment, they can be configured as a sixth transaction type.

[0094] By configuring transaction types separately for process units, component units, and task units, this embodiment avoids the problem of overly coarse transaction granularity caused by uniformly setting transactions only at the complete process level in existing methods. This allows transaction control to cover different execution granularities, including the complete business process, internal business components, and the smallest task operations. Therefore, during subsequent workflow execution, the transaction execution environment corresponding to the current execution unit can be determined by combining the transaction type of the current execution unit and the transaction status of the superior calling environment. This enables differentiated transaction control for execution units at different levels, improving data consistency and transaction management flexibility during business process execution.

[0095] Some embodiments of this application also relate to a workflow execution method based on hierarchical constraints, see reference Figure 3 As shown, the method may include the following steps:

[0096] Step B1: In response to the business processing request initiated by the page control layer, based on the parameter aliases in the pre-established input parameter mapping structure between the page control layer and the workflow layer, the request parameters in the business processing request are mapped to the process input parameters in the workflow layer, and the process input parameters are passed to the process unit corresponding to the business processing request.

[0097] In some embodiments, the page control layer can generate a business processing request in response to user actions, external system calls, or front-end page submissions. This business processing request can carry one or more request parameters, which characterize the business data required by the page control layer when initiating business processing to the workflow layer. For example, in a new order scenario, the new order request initiated by the page control layer can carry request parameters such as user identifier, order identifier, product information, order details, and a set of submitted objects. Since the request parameter names in the page control layer may not be consistent with the process input parameter names in the workflow layer, parameter aliases can be used to map the request parameters in the business processing request before passing the business processing request to the workflow layer, based on a pre-established input parameter mapping structure between the page control layer and the workflow layer.

[0098] Specifically, the input parameter mapping structure can include parameter name, parameter type, default value, and parameter alias. Upon receiving a business processing request initiated by the page control layer, the request parameters in the request can be read, and the request parameter to be mapped can be determined based on the parameter name in the input parameter mapping structure. Subsequently, based on the parameter alias corresponding to the request parameter, the request parameter in the page control layer is mapped to the process input parameter in the workflow layer. If the business processing request does not carry a certain request parameter, and the input parameter mapping structure has a default value configured for that request parameter, the corresponding process input parameter can be generated based on that default value. If the data type of the request parameter is inconsistent with the parameter type configured in the input parameter mapping structure, the request parameter can be type-validated according to preset validation rules, or the request parameter can be rejected from being passed to the workflow layer.

[0099] For example, when initiating a new order request in the page control layer, the request parameters may include the user identifier `user_id` and the order identifier `order_id`. The input parameter mapping structure can configure parameter alias mappings between `user_id` and `uid`, and between `order_id` and `oid`. Based on this input parameter mapping structure, the user identifier `user_id` in the page control layer can be mapped to the process input parameter `uid` in the workflow layer, and the order identifier `order_id` in the page control layer can be mapped to the process input parameter `oid` in the workflow layer. Therefore, even if the page control layer and the workflow layer use different parameter naming methods, a correspondence can be established between them through the parameter aliases in the input parameter mapping structure, allowing the workflow layer to continue executing the business process based on the mapped process input parameters.

[0100] In some embodiments, a process unit corresponding to a business processing request can be determined based on the business processing request. A process unit can be a public execution unit in the workflow layer that can be invoked by the page control layer, representing a complete business processing unit. For example, when the page control layer initiates a new order request, it can match the business processing request to the new order process unit in the workflow layer. After mapping the request parameters to process input parameters, the process input parameters can be passed to the new order process unit, enabling the process unit to schedule the execution of its internal component units and task units based on process input parameters such as uid and oid.

[0101] By employing the above method, before a business processing request enters the workflow layer, the request parameters of the page control layer are first mapped and transformed based on the parameter aliases in the input parameter mapping structure, and then the transformed process input parameters are passed to the corresponding process unit. This avoids issues such as inconsistent parameter names, parameter mismatches, or parameter overriding caused by directly passing parameters between the page control layer and the workflow layer.

[0102] Step B2: Based on the preset hierarchical constraints, the process unit schedules the execution of its internal component units and task units.

[0103] In some embodiments, after the process input parameters are passed to the process unit corresponding to the business processing request, the process unit can schedule the execution of its internal component units and task units according to a preset hierarchical constraint relationship. The process unit, as a public execution unit that can be called by the page control layer, can be used to carry out the complete business processing; the component unit, as a private execution unit that is only called within the workflow layer, can be used to encapsulate the intermediate business logic within the process unit; and the task unit, as the smallest indivisible and non-nested execution unit, can be used to execute specific basic business operations.

[0104] Hierarchical constraints can be used to constrain the inclusion and calling relationships between process units, component units, and task units. Specifically, a process unit does not nest other process units, and its internal execution objects can include component units and task units; component units are not directly called by the page control layer, but can be called by process units or other component units within the workflow layer; a task unit is the smallest execution unit and does not nest other execution units. Based on these hierarchical constraints, when scheduling execution, a process unit can first determine the execution path corresponding to the current business processing request, and then sequentially or conditionally call its internal component units and task units according to that execution path to complete the corresponding business processing. Therefore, during the execution of a process unit, the page control layer does not directly call component units or task units, but first calls the process unit, and then the process unit schedules the component units and task units according to its internally configured execution path and hierarchical constraints.

[0105] For example, in the new order business process, after the new order request initiated by the page control layer is passed to the new order process unit, the new order process unit can schedule the credit check component unit, inventory check component unit, and order save task unit to execute according to the preset execution path. Specifically, the credit check component unit can further call the user credit information query task unit, prepayment user judgment task unit, and credit occupancy check component unit within the workflow layer; the inventory check component unit can further call the product inventory query task unit and inventory occupancy component unit; and the order save task unit can be used to perform order data save operations. All of the above scheduling processes occur within the workflow layer; the page control layer only calls the new order process unit and does not directly call the credit check component unit or the inventory check component unit.

[0106] In some embodiments, a process unit can determine the execution order of component units and task units based on the sequential relationship, conditional branch relationship, or subsequent node relationship in the execution path. For example, after a task unit completes execution, the process unit can determine the next node to be executed based on the conditional flow configuration corresponding to that task unit; if the preset conditions are met, the corresponding component unit or task unit is scheduled to continue execution; if the preset conditions are not met, the process jumps to another execution node or terminates the current process. Thus, the process unit can perform orderly scheduling of internal component units and task units without disrupting hierarchical constraints.

[0107] By using the above method, business processing requests can always use the process unit as the external entry point of the workflow layer, and the process unit can schedule the execution of internal component units and task units according to the preset hierarchical constraints. This avoids the page control layer directly calling private component units, avoids nesting between complete process units, and ensures that internal business logic and basic business operations are organized and executed according to a clear hierarchical structure.

[0108] Step B3: During the execution of a process unit, component unit, or task unit, obtain the transaction type corresponding to the current execution unit and the transaction status of the superior calling environment, and determine the corresponding business operation to be performed by the current execution unit based on the transaction type and transaction status, and obtain the unit execution result of the current execution unit.

[0109] In some embodiments, process units, component units, and task units can all be pre-configured with corresponding transaction types. Transaction types can be used to represent the transaction control strategy adopted by the corresponding execution unit when it is invoked. Since there are hierarchical calling relationships between process units, component units, and task units, different execution units may be in different parent calling environments during execution. For example, a process unit can call a component unit, and a component unit can further call other component units or task units. Therefore, before the current execution unit executes its corresponding business operation, the transaction execution environment corresponding to the current execution unit can be determined by combining the transaction type configured in the current execution unit itself and the transaction state of the parent calling environment that called the current execution unit.

[0110] In a preferred embodiment, step B3 specifically includes:

[0111] Step B301: When any execution unit in a process unit, component unit, or task unit is invoked, the invoked execution unit is determined as the current execution unit.

[0112] Specifically, the current execution unit can be a process unit invoked after a request from the page control layer, a component unit or task unit scheduled during the execution of the process unit, or another component unit or task unit further invoked by the component unit within the workflow layer. For example, in the new order business process, the new order process unit can be initially identified as the current execution unit; when the new order process unit invokes the credit check component unit, the credit check component unit can be identified as the current execution unit; when the credit check component unit further invokes the user credit information query task unit, that user credit information query task unit can be identified as the current execution unit.

[0113] Step B302: Obtain the transaction type of the current execution unit and the transaction status of the parent calling environment of the current execution unit.

[0114] Transaction types can include using a parent transaction, using a parent transaction if one exists and creating a new transaction if no parent transaction exists, always creating a new independent transaction, not using a parent transaction, manually controlling transactions, and prohibiting the use of transactions. The transaction state of the parent calling environment can be used to indicate whether a parent transaction already exists in the parent execution environment that calls the current execution unit. For example, when a process unit calls a component unit, the execution environment of the process unit can be used as the parent calling environment of that component unit; when a component unit calls a task unit, the execution environment of that component unit can be used as the parent calling environment of that task unit. Therefore, whether the current execution unit reuses a parent transaction, creates a new transaction, breaks away from a parent transaction, or executes in a transaction-free environment can all be determined based on the pre-configured transaction type of the current execution unit and the transaction state of the parent calling environment.

[0115] Step B303: Determine the transaction execution environment corresponding to the current execution unit based on the transaction type and transaction status.

[0116] In a preferred embodiment, step B303 specifically includes:

[0117] When the transaction type indicates the use of a parent transaction, the parent transaction in the calling environment is determined as the transaction execution environment corresponding to the current execution unit. In other words, the current execution unit does not create a new transaction independently, but instead joins the transaction of the parent execution unit that called it, ensuring that the business operations of the current execution unit and the business operations of the parent execution unit are within the same transaction control scope. This transaction type is suitable for scenarios where the processing results of the current execution unit need to be consistently committed or rolled back with those of the parent execution unit. For example, when a process unit calls a component unit to perform internal validation or data processing, the component unit can reuse the parent transaction of the process unit, thereby ensuring data consistency between the upper and lower execution units.

[0118] When the transaction type indicates that the parent transaction should be used if one exists, and a new transaction should be created if no parent transaction exists, the transaction execution environment for the current execution unit is determined if the transaction status indicates that a parent transaction exists. If the transaction status indicates that no parent transaction exists, a new transaction execution environment is created for the current execution unit. In this way, the transaction type ensures that the current execution unit always executes within a transaction environment. It prioritizes reusing the parent transaction when one exists, avoiding duplicate transaction creation; and creates a new transaction only when no parent transaction exists, thus meeting the transaction control requirements of the current execution unit.

[0119] When the transaction type indicates that a new independent transaction is always created, a transaction execution environment independent of the parent calling environment is created for the current execution unit. In other words, regardless of whether a parent transaction exists in the parent calling environment, the current execution unit does not reuse the parent transaction, but instead executes the corresponding business operations as an independent transaction. This transaction type is suitable for scenarios where the current execution unit needs to have independent commit or rollback boundaries. For example, certain log recording, status updates, or independent data saving operations can be configured as independent transactions so that their execution results are not completely affected by the commit or rollback of the parent transaction.

[0120] When the transaction type indicates that a parent transaction is not used, the current execution unit is detached from the parent transaction in the calling environment and executes in a transaction execution environment that does not use a parent transaction. The key point of this transaction type is that the current execution unit does not join the existing parent transaction in the calling environment, thus isolating the current execution unit from the parent transaction. This does not necessarily mean that the current execution unit is completely prohibited from transactions, but rather that the current execution unit executes without depending on the parent transaction. It is suitable for scenarios where the processing logic of the current execution unit does not need to participate in the parent transaction control, or needs to avoid being affected by the parent transaction rollback.

[0121] When the transaction type indicates manual transaction control, the current execution unit executes in a transaction execution environment where it controls transaction commit or rollback. Specifically, the current execution unit can trigger transaction commit or rollback based on its own business logic, execution results, or abnormal states, rather than having the transaction boundaries automatically determined by the superior calling environment. This transaction type is suitable for scenarios where the current execution unit has relatively complex transaction control logic, such as when the current execution unit needs to decide whether to commit based on the execution results of multiple sub-operations, or when it needs to perform rollback processing according to its own rules when an exception occurs.

[0122] When the transaction type indicates that transactions are prohibited, the current execution unit is controlled to execute in a non-transactional environment, and no existing transaction or new transaction is assigned to the current execution unit. In other words, the current execution unit neither joins the parent transaction in the calling environment nor creates a new transaction. This transaction type is suitable for business operations that do not require transaction control or are not allowed to be in a transactional environment, such as certain read-only queries, non-transactional external interface calls, or processing operations that should not be subject to database transaction control. This transaction type can prevent the current execution unit from mistakenly joining the parent transaction or incurring unnecessary transaction overhead.

[0123] By employing the above methods, the appropriate transaction execution environment can be adapted for each process unit, component unit, or task unit based on the pre-configured transaction type of the current execution unit and the transaction status of the superior calling environment. Therefore, transaction control is no longer limited to the entire business process level but can be extended to different execution granularities such as process units, component units, and task units, thereby improving the flexibility and granularity of transaction control in complex business processes.

[0124] Step B304: Execute the business operation corresponding to the current execution unit in the transaction execution environment to obtain the unit execution result of the current execution unit.

[0125] Specifically, the execution result of a unit can include data results, status results, error codes, return parameters, or control information for subsequent process flow generated after the current execution unit performs a business operation. For example, after the order saving task unit performs an order data saving operation in the corresponding transaction execution environment, it can generate a saving result or an error code; after the user credit information query task unit performs a query operation in the corresponding transaction execution environment, it can generate user credit data; the credit check component unit can form a credit check result based on the execution results of its internal task units or component units. Thus, each process unit, component unit, or task unit can perform business operations in an appropriate transaction execution environment according to its configured transaction type and the transaction status of the superior calling environment, thereby achieving fine-grained transaction control of different levels of execution units and improving data consistency and execution stability during the execution of complex business processes.

[0126] Through steps B301 to B304, when a process unit, component unit, or task unit is invoked, a transaction execution environment matching the current execution unit is determined based on the transaction type of the current execution unit and the transaction status of the superior calling environment. Business operations are then executed within this transaction execution environment. Therefore, this embodiment enables unit-level transaction adaptation control during workflow execution, allowing transaction control to be devolved from the granularity of the entire business process down to different levels of execution units. This improves the granularity, execution flexibility, and data consistency assurance capabilities of transaction control in complex business processes.

[0127] In a preferred embodiment, during the execution of a corresponding business operation by the current execution unit, if the business operation involves data operations, the data operations are performed through a composite logical table built upon the physical table mapping model. The physical table mapping model describes the underlying data structures in the database, such as physical tables, physical fields, and field attributes. The composite logical table, built upon the physical table mapping model, is used to convert data access requests during workflow execution into access instructions for the underlying physical database. The composite logical table may include field configurations, table join configurations, custom query configurations, cascading delete configurations, and field view configurations. Through this composite logical table, the current execution unit does not need to configure separate, distributed data access logic when performing business operations; instead, it can complete data operations such as field mapping, multi-table joins, conditional queries, cascading deletes, and field return control based on the same logical data model.

[0128] Based on field configuration and field view configuration, the business scenario identifier corresponding to the current execution unit is obtained. The corresponding field return range is determined from the field view configuration according to the business scenario identifier. Then, physical field mapping and field attribute validation are performed on the target fields within the field return range according to the field configuration to construct a logical data view corresponding to the current execution unit.

[0129] Specifically, the business scenario identifier corresponding to the current execution unit can be obtained. This identifier can represent the data operation scenario in which the current execution unit operates, such as a query scenario, a save scenario, a list display scenario, a details display scenario, or a validation scenario. Based on this business scenario identifier, the field return range corresponding to the current business scenario is determined from the field view configuration. For example, in a list display scenario, the field return range may only include fields such as order identifier, user identifier, order status, and creation time; in a details display scenario, the field return range may further include fields such as order details, product information, and receipt information. Subsequently, according to the field configuration, physical field mapping and field attribute validation are performed on the target fields within the field return range. Physical field mapping is used to determine the correspondence between logical fields and physical table fields; field attribute validation is used to validate attributes such as the data type of the target field, whether nullables are allowed, default values, field length, or field access permissions. Through the above processing, a logical data view corresponding to the current execution unit can be constructed, enabling the current execution unit to perform data operations within the field range that conforms to the current business scenario.

[0130] Based on table join configuration and cascading delete configuration, when the data operation is a data change operation, the join relationship between multiple physical tables involved in the data change operation is determined according to the table join configuration, and the set of related data to be processed is determined based on the join relationship; the deletion dependency relationship and deletion order between each related data in the related data set are determined according to the cascading delete configuration; cascading delete processing is performed on the related data set according to the deletion dependency relationship and deletion order, or if the cascading delete processing does not meet the preset execution conditions, rollback processing is performed on the processed related data.

[0131] Specifically, when the data operation is a data modification operation, such as deletion, update, or status change, the relationships between multiple physical tables involved in the data modification operation can be determined based on the table join configuration, and the set of related data to be processed can be determined based on these relationships. For example, in an order processing scenario, there may be business relationships between the order master table, order detail table, inventory occupancy table, and payment record table. When a data modification operation involves an order record in the order master table, the order detail data, inventory occupancy data, or payment record data associated with that order record can be determined based on the table join configuration. Furthermore, the deletion dependencies and deletion order between the related data in the set of related data can be determined based on the cascading delete configuration. For example, the order detail data can be processed first, then the inventory occupancy data, and finally the order master table data, or the specific processing order can be determined according to the dependencies defined in the cascading delete configuration. Cascading deletion can be performed on related data sets according to the deletion dependencies and deletion order. If the cascading deletion does not meet the preset execution conditions, such as deletion failure, foreign key constraint conflict, permission verification failure, or abnormal processing of some related data, the already processed related data can be rolled back to avoid some data being deleted while other related data is still retained, thereby improving the consistency of multi-table data processing.

[0132] Based on the custom query configuration, the process parameters obtained from the current execution unit are obtained, and the parameter placeholders and dynamic query conditions corresponding to the process parameters are determined according to the custom query configuration. The process parameters are type-validated and bound to obtain the bound query parameters. The query parameters are applied to the logical data view or relationship to generate the database access instructions corresponding to the data operation.

[0133] Specifically, during the execution of the current execution unit, process parameters can be obtained. These parameters can come from process input parameters passed from the page control layer or from the execution result of the previous execution unit. For example, in a new order scenario, process parameters may include user identifier, order identifier, product identifier, order status, query conditions, or business scenario identifier. Parameter placeholders and dynamic query conditions corresponding to the process parameters can be determined based on the custom query configuration. Parameter placeholders can indicate the position of parameters to be bound in the database access command, and dynamic query conditions can be used to generate different query conditions based on the process parameters. Subsequently, type validation and parameter binding can be performed on the process parameters to obtain the bound query parameters. Type validation is used to determine whether the data type of the process parameter matches the parameter type in the custom query configuration, and parameter binding is used to bind the process parameter to the corresponding parameter placeholder, avoiding errors in query conditions caused by directly concatenating parameters. Afterward, the query parameters can be applied to the relationships determined by the aforementioned logical data view or table association configuration to generate database access commands corresponding to data operations. For example, in query operations, the range of fields to be returned can be determined based on the logical data view, and the physical tables involved can be determined based on the relationships, and then the corresponding query instructions can be generated by combining the bound query parameters; in change operations, corresponding delete, update or status change instructions can be generated based on the relationships and cascading delete configurations.

[0134] Through the above approach, this embodiment enables the current execution unit to uniformly complete field mapping, field view control, multi-table join processing, cascading delete processing, and custom query processing when data operations are involved, using a combined logical table. Since the combined logical table is built upon the physical table mapping model and simultaneously incorporates field configuration, table join configuration, custom query configuration, cascading delete configuration, and field view configuration, it avoids different execution units writing their own fragmented data access logic. This reduces the configuration complexity of multi-table joins, dynamic queries, cascading deletes, and multi-scenario field returns, and improves the consistency, maintainability, and scalability of data operations during workflow execution.

[0135] Step B4: Based on the execution path of the process unit, transmit or summarize the execution results of the unit to determine the execution result of the process unit.

[0136] Specifically, after a process unit schedules the execution of its internal component units and task units, each component unit or task unit can generate its corresponding unit execution result. The unit execution result may include business processing data, status identifiers, error codes, return parameters, conditional judgment results, or control information used to indicate subsequent process flows. The process unit can transmit or summarize the execution results of each unit according to a pre-configured execution path, thereby determining the execution result of that process unit.

[0137] In some embodiments, the execution path of a process unit can be used to represent the execution order, calling relationship, conditional jump relationship, and result transmission relationship among the execution units within the process unit. For example, a process unit can first schedule the credit check component unit to execute, and determine whether to continue scheduling the inventory check component unit based on the credit check result returned by the credit check component unit; after the inventory check component unit completes its execution, the process unit can determine whether to schedule the save order task unit based on the inventory check result. If the credit check result or the inventory check result does not meet the preset conditions, the process unit can end the current process or return an abnormal result based on the conditional jump relationship in the execution path; if all check results meet the preset conditions, the process unit can continue to schedule the save order task unit, and form the execution result of the process unit based on the save result of the save order task unit.

[0138] In some embodiments, after a current execution unit completes its execution, the process unit can determine subsequent execution nodes based on the execution result of that current execution unit. For example, if the status flag returned by the current execution unit indicates successful execution, the process unit can pass the return parameters from the execution result to the next component unit or task unit in the execution path; if the status flag returned by the current execution unit indicates execution failure, the process unit can generate an error result or enter an exception handling node based on the exception flow relationship configured in the execution path. Therefore, the unit execution result can not only serve as input data for subsequent execution units but also as the basis for the process unit to determine subsequent execution paths.

[0139] Step B4 ensures that the results generated by execution units at different levels flow in an orderly manner according to the preset execution path, ultimately forming a complete business process execution result. This facilitates the subsequent mapping of the execution result into page return parameters that the page control layer can receive through the output parameter mapping structure.

[0140] Step B5: Based on the parameter aliases in the pre-established output parameter mapping structure between the workflow layer and the page control layer, map the execution result of the process unit to the page return parameters returned to the page control layer.

[0141] In some embodiments, after determining the execution result of a process unit based on its execution path, the execution result of the process unit can be returned to the page control layer based on a pre-established output parameter mapping structure between the workflow layer and the page control layer. The output parameter mapping structure can be used to constrain the process by which the workflow layer returns parameters to the page control layer, and it can include parameter names, parameter types, default values, and parameter aliases.

[0142] The execution results of a workflow unit can include business processing status, business processing data, error codes, exception information, prompts, or other result parameters that need to be returned to the page control layer. Based on the output parameter mapping structure, the parameter aliases corresponding to each execution result parameter in the workflow unit's execution results can be determined, and these aliases can be used to map the execution result parameters in the workflow layer to page return parameters that the page control layer can receive. Therefore, the names of the execution result parameters within the workflow layer do not need to be consistent with the names of the return parameters received by the page control layer; the two can establish a correspondence through the parameter aliases in the output parameter mapping structure, thus avoiding mismatches in return results due to inconsistent parameter names.

[0143] In some embodiments, before mapping the execution result of a process unit to page return parameters, the execution result parameters to be returned can be validated according to the output parameter mapping structure. If an execution result parameter has already been mapped based on a parameter alias in the output parameter mapping structure, then the execution result parameter is allowed to be returned to the page control layer according to the corresponding parameter alias; if an execution result parameter has not been mapped based on a parameter alias in the output parameter mapping structure, then the execution result parameter can be rejected from being returned directly, or a corresponding page return parameter can be generated based on a preset default value. In this way, the workflow layer can be prevented from bypassing the output parameter mapping structure to return parameters directly to the page control layer, thereby improving the standardization and controllability of the result return process.

[0144] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0145] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0146] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a workflow control method based on hierarchical constraints and / or a workflow execution method based on hierarchical constraints as provided in any one or more of the above embodiments. Figure 4An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0147] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0148] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0149] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0150] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a workflow control method and / or a workflow execution method based on hierarchical constraints provided in any one or more of the above embodiments. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The computer-readable medium carries one or more computer-readable instructions.

[0151] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0152] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0153] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0154] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. 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, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0155] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0156] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0157] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0158] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0159] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. Terms such as "first," "second," etc., are used only to distinguish descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0160] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A workflow control method based on hierarchical constraints, characterized in that, include: The process acquires multiple business execution units from the workflow layer that constitute a business process, and configures these units hierarchically according to preset boundary constraint rules to construct a multi-level execution unit. The multi-level execution unit includes process units, component units, and task units. The task unit is the smallest indivisible and non-nested execution unit. The component unit is formed by combining at least one task unit and / or at least one defined component unit, and is configured as a private execution unit that is invoked only within the workflow layer. The process unit is formed by combining at least one task unit and / or at least one defined component unit, and is configured as a public execution unit that can be invoked by the page control layer, representing a complete business processing unit. Establish hierarchical constraints between the process unit, the component unit, and the task unit; wherein, the hierarchical constraints include: the process unit does not nest other process units, and the component unit is not directly called by the page control layer; Establish an input parameter mapping structure and an output parameter mapping structure between the page control layer and the workflow layer; wherein, the input parameter mapping structure and the output parameter mapping structure both include parameter name, parameter type, default value and parameter alias, and complete the parameter mapping between the page control layer and the workflow layer based on the parameter alias.

2. The workflow control method based on hierarchical constraints according to claim 1, characterized in that, The step of completing the parameter mapping between the page control layer and the workflow layer based on the parameter alias includes: When the page control layer passes parameters to the workflow layer, the request parameters of the page control layer are mapped to the process input parameters of the workflow layer according to the parameter aliases in the input parameter mapping structure. When the workflow layer returns parameters to the page control layer, the execution result parameters of the workflow layer are mapped to the page return parameters of the page control layer according to the parameter aliases in the output parameter mapping structure. Specifically, when the page control layer and the workflow layer exchange parameters, if it is detected that the parameter to be exchanged has not established a mapping relationship based on the parameter alias in the input parameter mapping structure or the output parameter mapping structure, the parameter to be exchanged is rejected from being exchanged between the page control layer and the workflow layer.

3. The workflow control method based on hierarchical constraints according to claim 1, characterized in that, The method further includes: Configure transaction types for the process unit, the component unit, and the task unit respectively; wherein, the transaction types include: a first transaction type that uses a parent transaction, a second transaction type that uses a parent transaction when a parent transaction exists and creates a new transaction when a parent transaction does not exist, a third transaction type that always creates an independent transaction, a fourth transaction type that does not use a parent transaction, a fifth transaction type that controls transactions manually, and a sixth transaction type that prohibits the use of transactions.

4. A workflow execution method based on hierarchical constraints, characterized in that, include: In response to a business processing request initiated by the page control layer, the request parameters in the business processing request are mapped to process input parameters in the workflow layer based on parameter aliases in the input parameter mapping structure pre-established between the page control layer and the workflow layer, and the process input parameters are passed to the process unit corresponding to the business processing request. According to the preset hierarchical constraints, the process unit schedules the execution of its internal component units and task units; During the execution of the process unit, the component unit, or the task unit, the transaction type corresponding to the current execution unit and the transaction status of the superior calling environment are obtained, and the corresponding business operation is determined to be performed by the current execution unit based on the transaction type and the transaction status, so as to obtain the unit execution result of the current execution unit; Based on the execution path of the process unit, the execution results of the unit are transmitted or summarized to determine the execution result of the process unit; Based on the parameter aliases in the output parameter mapping structure pre-established between the workflow layer and the page control layer, the execution result of the process unit is mapped to the page return parameter returned to the page control layer.

5. The workflow execution method based on hierarchical constraints according to claim 4, characterized in that, The step of obtaining the transaction type corresponding to the current execution unit and the transaction status of the superior calling environment during the execution of the process unit, the component unit, or the task unit, and determining the corresponding business operation to be performed by the current execution unit based on the transaction type and the transaction status, and obtaining the unit execution result of the current execution unit, includes: When any execution unit in the process unit, the component unit, or the task unit is invoked, the invoked execution unit is determined as the current execution unit; Obtain the transaction type of the current execution unit and the transaction status of the calling environment of the current execution unit; Based on the transaction type and the transaction status, determine the transaction execution environment corresponding to the current execution unit; The business operation corresponding to the current execution unit is executed in the transaction execution environment to obtain the unit execution result of the current execution unit.

6. The workflow execution method based on hierarchical constraints according to claim 5, characterized in that, The step of determining the transaction execution environment corresponding to the current execution unit based on the transaction type and the transaction state includes: When the transaction type indicates the use of a parent transaction, the parent transaction in the parent calling environment is determined as the transaction execution environment corresponding to the current execution unit; When the transaction type indicates that a parent transaction is used when a parent transaction exists and a new transaction is created when no parent transaction exists, if the transaction status indicates that a parent transaction exists, then the parent transaction is determined as the transaction execution environment corresponding to the current execution unit; if the transaction status indicates that no parent transaction exists, then a new transaction execution environment is created for the current execution unit. When the transaction type indicates that a new independent transaction is always created, a transaction execution environment independent of the parent calling environment is created for the current execution unit; When the transaction type indicates that the parent transaction is not used, the current execution unit is removed from the parent transaction in the parent calling environment and executed in a transaction execution environment that does not use the parent transaction; When the transaction type indicates manual control of the transaction, the current execution unit executes in a transaction execution environment where it controls the transaction commit or rollback. When the transaction type indicates that transactions are prohibited, the current execution unit is controlled to execute in a transaction-free environment, and no existing transactions or new transactions are allocated to the current execution unit.

7. The workflow execution method based on hierarchical constraints according to claim 4, characterized in that, During the execution of the corresponding business operation by the current execution unit, if the business operation involves data operation, the data operation is executed through a combined logical table built on the physical table mapping model; wherein, the combined logical table includes field configuration, table association configuration, custom query configuration, cascading delete configuration, and field view configuration; Based on the field configuration and the field view configuration, the business scenario identifier corresponding to the current execution unit is obtained. The corresponding field return range is determined from the field view configuration according to the business scenario identifier. The target fields within the field return range are physically mapped and field attribute validated according to the field configuration to construct a logical data view corresponding to the current execution unit. Based on the table association configuration and the cascading delete configuration, when the data operation is a data change operation, the association relationships between multiple physical tables involved in the data change operation are determined according to the table association configuration, and the set of associated data to be processed is determined based on the association relationships; the deletion dependencies and deletion order between each associated data in the associated data set are determined according to the cascading delete configuration; cascading delete processing is performed on the associated data set according to the deletion dependencies and the deletion order, or if the cascading delete processing does not meet the preset execution conditions, rollback processing is performed on the processed associated data; Based on the custom query configuration, the process parameters obtained from the current execution unit are obtained, and the parameter placeholders and dynamic query conditions corresponding to the process parameters are determined according to the custom query configuration; the process parameters are type-validated and parameter-bound to obtain the bound query parameters; the query parameters are applied to the logical data view or the association relationship to generate the database access instruction corresponding to the data operation.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the workflow control method based on hierarchical constraints as described in any one of claims 1-3, or to perform the workflow execution method based on hierarchical constraints as described in any one of claims 4-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the workflow control method based on hierarchical constraints as described in any one of claims 1-3, or the workflow execution method based on hierarchical constraints as described in any one of claims 4-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the workflow control method based on hierarchical constraints as described in any one of claims 1-3, or the workflow execution method based on hierarchical constraints as described in any one of claims 4-7.

Images