A method and system for business process configuration generation and controlled execution

Abstract

The application provides a business process configuration generation and controlled execution method and system, relates to the technical field of business process management and data processing, and comprises the following steps: acquiring business service configuration data and generating a business node list, determining associated compiled capabilities and dependency levels of the business nodes according to a runtime capability directory, and generating a business service process template package; performing consistency verification based on the reference relationship of each list; a business execution terminal determines candidate executable business nodes according to node entry conditions, user context and business object states, and generates an ordered business service execution plan in combination with the runtime capability directory; in response to a business action trigger, an associated pre-compiled business processor is called, the business object state is updated according to the execution result, and subsequent executable business nodes are determined. The application can improve the consistency between the business process configuration and the actual execution conditions of the terminal, and reduce process execution errors caused by configuration exceptions.

Description

Technical Field

[0001] This invention relates to the field of business process management and data processing technology, and in particular to a method and system for configurable generation and controlled execution of business processes. Background Technology

[0002] As online service platforms increasingly evolve towards multi-business scenario and multi-project reuse, the same application typically needs to provide different business processes based on the service content, user roles, data status, and business stages of different projects. To reduce the workload of repetitive development for different projects, existing systems usually use a configuration-based approach to describe service projects, business nodes, data content, and interactive actions, with the terminal completing the corresponding business processing based on the configuration results. As the types of business and configuration content increase, the relationships between factors such as data, permissions, status, actions, and terminal versions involved in the business process also increase, and different configuration contents may be maintained separately by different personnel or at different stages.

[0003] Existing configurable business processes often lack unified consistency constraints between generation, deployment, and terminal execution. Some configuration errors are only exposed when the terminal actually loads or executes the corresponding business node. For example, mismatches between data referenced by a business node and actual input, business actions not meeting current permission or state conditions, or unavailability of functions on which the configuration depends in the current terminal version can all cause the business process to fail to continue as expected. Inconsistencies are more likely to occur between configuration content and actual terminal execution conditions, especially when business processes are continuously updated and terminal versions coexist. Therefore, improving the consistency between configurable business processes and actual terminal execution conditions, and identifying configuration anomalies affecting process execution before the process is put into operation, are problems that existing technologies need to address. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, the technical problem to be solved by this invention is to propose a method and system for configurable generation and controlled execution of business processes, employing the following technical solution: On one hand, the present invention provides a method for configurable generation and controlled execution of business processes, including: S1: The business process generation end obtains business service configuration data, merges configuration items belonging to the same business node according to the stable business node identifier, and generates a list of business nodes that record the node order and node entry conditions. S2: The business process generation end obtains the runtime capability catalog corresponding to the business execution terminal, determines the compiled capabilities and dependency levels associated with each business node based on the business node list and the runtime capability catalog, generates a data binding list, action list, status list and capability dependency list, and encapsulates them with the business node list into a business service process template package. S3: The business process generation end establishes a reference graph based on the reference relationships of each list in the business service process template package, performs reference integrity, data pattern compatibility, action execution conditions and runtime version compatibility checks, and stops publishing when there is a blocking-level error. S4: The business execution terminal obtains the verified business service process template package, user context and business object status, and determines the candidate executable business nodes based on the node entry conditions, user context and business object status in the business node list; S5: The business execution terminal generates an ordered business service execution plan, matching the capability identifiers of candidate executable business nodes with the runtime capability catalog; when a capability is unavailable, the execution process is rolled back or the node is skipped according to the dependency level; when a capability is available, the association between the corresponding business node and its action intent and the pre-compiled business processor is written into the above execution plan. S6: Respond to the business action trigger in the above execution plan, determine the pre-compiled business processor according to the above association, verify the parameters, user permissions and business object status, and call the above processor after passing the verification. Update the business object status according to the execution result, and determine the subsequent executable business nodes based on the updated business object status and node entry conditions.

[0005] As a further improvement, in step S2, the aforementioned business service process template package also includes a state transition list, in which the state transition records include the source business state, the action intent identifier, and the target business state.

[0006] In step S3, a business state transition graph is established using business states as state nodes and state transition records as directed edges. The action intent corresponding to each state transition record is then verified against the registered action processing capabilities based on the action list and runtime capability catalog. If no correspondence is established, the state transition record is determined to be an invalid transition, and a blocking-level error is generated.

[0007] As a further improvement, in step S3, the action record in the above action list also includes parameter mode, permission conditions and business status conditions.

[0008] For state transition records that are not determined to be invalid transitions, a combined verification is performed based on the above parameter mode, permission conditions, and business status conditions. The state transition records that pass the combined verification are used to construct an executable state transition diagram.

[0009] When a business state has an entry path, is not configured as a process end state, and has no subsequent executable state transition, the business state is determined as an abnormal termination state and a blocking-level error is generated.

[0010] As a further improvement, in step S3, the business node record in the aforementioned business node list also includes a payment dependency identifier.

[0011] For service items with payment dependency identifiers, determine whether there exists a first reachable path from the order created state to the payment completed state, and a second reachable path from the payment completed state to the service executable state in the above executable state transition graph.

[0012] A blocking-level error occurs when any reachable path does not exist.

[0013] As a further improvement, in step S2, the action record in the above action list includes an action intent identifier, parameter mode, permission conditions, and processor capability identifier, and the processor capability identifier corresponds to the action processing capability registered in the runtime capability catalog.

[0014] In step S5, the aforementioned processor capability identifier is used as a matching key to associate the action intent with the pre-compiled service processor in the service execution terminal.

[0015] As a further improvement, in step S6, the action parameters are verified according to the parameter mode, the permission conditions are verified according to the user context, and the action execution conditions are verified according to the business object status.

[0016] When the action intent is a payment action, the pre-compiled shared payment processor is determined based on the processor capability identifier. The shared payment processor then obtains the payment parameters based on the order data and invokes the payment capability. Based on the payment execution result, the payment status and order status are updated.

[0017] As a further improvement, in step S2, the above-mentioned capability dependency level includes required capabilities and optional capabilities. In step S2, the capability dependency level includes required capabilities and optional capabilities. The capability dependency list also records the minimum runtime version and fallback capability corresponding to each capability. The business service process template package also records the previous compatible version and standard template identifier.

[0018] In step S5, if a required capability is unavailable, the previous compatible version compatible with the current runtime version is selected; if no compatible version exists, the standard template is used. If an optional capability is unavailable, a fallback capability is used or the corresponding business node is skipped.

[0019] Another aspect of the present invention provides a business process configurable generation and controlled execution system, including a business process generation terminal, a process server terminal, a business data server terminal, and a business execution terminal.

[0020] The aforementioned business process generation module includes a configuration merging module, a process template generation module, and a cross-list verification module, which are connected sequentially. The aforementioned process server includes a process template version storage module and a project template association module.

[0021] The aforementioned business execution terminal includes a template package client, an execution plan generation module, an action intent distribution module, a rollback control module, and a runtime capability directory storage unit, which stores the runtime capability directory.

[0022] The aforementioned business process generation terminal is connected to the process server terminal, and the aforementioned process server terminal and business data server terminal are respectively connected to the business execution terminal.

[0023] The execution plan generation module is connected to the template package client, the runtime capability directory storage unit, and the action intent distribution module, respectively. The rollback control module is connected to the template package client, the execution plan generation module, and the runtime capability directory storage unit, respectively.

[0024] Further improvements include the software building module, the runtime capability catalog generation module, and the capability catalog synchronization module.

[0025] The runtime capability catalog generation module reads the registration information of the pre-compiled business processors, data adapters, and state processors registered in the software building module and generates a runtime capability catalog corresponding to the runtime version.

[0026] The capability catalog synchronization module provides the runtime capability catalog corresponding to the target runtime version to the business process generation end and synchronizes it to the runtime capability catalog storage unit of the business execution terminal.

[0027] As a further improvement, the above-mentioned process template version storage module saves the business service process template package in an immutable version and records the compatible runtime scope and the previous compatible version.

[0028] The aforementioned business execution terminal also includes a local verification cache connected to the template package client.

[0029] When the integrity verification of the current business service process template package fails, the aforementioned rollback control module calls the business service process template package that has passed the integrity verification in the local verification cache. When the necessary capabilities are incompatible, it controls the template package client to obtain the corresponding compatible version of the business service process template package.

[0030] Compared with the prior art, the beneficial effects of the present invention are: Firstly, this invention generates a list of business nodes based on business service configuration data and determines the compiled capabilities associated with each business node by combining this list with the runtime capability directory corresponding to the business execution terminal. The business node list and related lists are then encapsulated into a business service process template package. Before release, cross-list consistency verification is performed, and an ordered business service execution plan is generated on the terminal side based on node entry conditions, business object status, and runtime capability matching results. This establishes a correspondence between the business process configuration and the actual execution capabilities of the terminal during both the release and runtime phases, reducing process anomalies caused by inconsistencies between configuration content and terminal execution conditions.

[0031] Secondly, a business state transition diagram is established through state transition records, and the action processing capabilities and execution conditions corresponding to the state transitions are verified to form an executable state transition diagram. For service projects with payment dependencies, the reachability between the order creation state and the payment completion state, as well as between the payment completion state and the service executable state, is further verified. This can identify process configurations that lack effective execution capabilities, terminate abnormally, or have missing necessary business state connections before the process is released.

[0032] Third, by using processor capability identifiers, the intention of an action is associated with the pre-compiled business processor in the business execution terminal. When a business action is triggered, it is verified in combination with parameters, user permissions, and business object status. This ensures that the actions in the business process configuration can only be executed through the existing processing capabilities of the terminal, thereby reducing the execution risk caused by the mismatch between the action configuration and the terminal execution logic, permission conditions, or business status. Attached Figure Description

[0033] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of the steps of the method of the present invention.

[0035] Figure 2 This is a schematic diagram of the framework structure of the system of the present invention.

[0036] Figure 3 This is a schematic diagram of the structure for generating and synchronizing the runtime capability catalog of this invention.

[0037] Figure label: 100 - Business process generation terminal; 200 - Process server terminal; 300 - Business data server terminal; 400 - Business execution terminal; 500 - Software building module; 110 - Configuration merging module; 120 - Process template generation module; 130 - Cross-list verification module; 210 - Process template version storage module; 220 - Project template association module; 410 - Template Package Client; 420 - Execution Plan Generation Module; 430 - Action Intent Distribution Module; 440 - Rollback control module; 450 - Runtime capability catalog storage unit; 460 - Local verification cache; 510 - Runtime capability catalog generation module; 520 - Capability catalog synchronization module. Detailed Implementation

[0038] To facilitate understanding by those skilled in the art, the structure of the present invention will now be described in further detail with reference to the accompanying drawings: like Figure 1 As shown, a method for configurable generation and controlled execution of business processes includes steps S1 to S6. Combined with... Figure 2 and Figure 3 The business process generation terminal 100 is responsible for merging business service configuration data, generating business service process template packages, and performing pre-release verification. The process server terminal 200 is responsible for storing business service process template packages and template versions and associating them with projects. The business data server terminal 300 provides business data, user permissions, and business object status to the business execution terminal 400. The business execution terminal 400 generates an ordered business service execution plan based on the business service process template package, runtime capability catalog, and current running data, and calls the already compiled business processing capabilities within the terminal according to the execution plan.

[0039] In step S1, the business process generation terminal 100 obtains business service configuration data, merges configuration items belonging to the same business node according to the stable business node identifier, and generates a business node list that records the node order and node entry conditions.

[0040] Business service configuration data describes the service items, business nodes, business data, user permissions, and status conditions involved in the target business process. In one specific embodiment, business service configuration data includes project service configuration, business interaction configuration, user role and permission configuration, business status configuration, and business field configuration. Project service configuration records the types of services that can be provided in the project and the attributes of the service items; business interaction configuration records the sequential relationship between different business nodes, business actions, and input conditions; user role and permission configuration records the business access permissions corresponding to user roles; business status configuration records service status, order status, and payment status; and business field configuration records the data fields and field types used in the business processing.

[0041] In one specific embodiment, business service configuration data originates from page structure files, style files, interaction delivery files, page screenshots, and resource files. The business process generation end 100 extracts content reflecting business processing relationships from this data and converts it into unified business configuration records. For example, the service entry area on the page corresponds to a service entry business node, click behaviors in the interaction delivery file correspond to action intentions, existing data slots are converted into stable business field keys, and page state configurations are converted into state records related to business execution. It should be noted that display configurations such as page color, font, spacing, and image position are saved as interface presentation parameters and managed separately from the entry conditions of business nodes and the execution conditions of business actions.

[0042] A stable business node identifier is used to identify the same business node during configuration generation, template release, and terminal execution. The stable business node identifier remains unchanged even when the node's display name, display location, or interface style changes. In one specific embodiment, the service entry node is denoted as `service.entry`, the service details node as `service.detail`, the order creation node as `order.create`, the payment processing node as `payment.process`, and the service activation node as `service.activate`. The above naming is merely an example of identification in a specific implementation; the stable business node identifier can also adopt a numerical code, hierarchical encoding, or other identification form that can uniquely identify the business node.

[0043] The business process generation terminal 100 merges configuration items from different sources according to stable business node identifiers. In one specific embodiment, a composite key is formed by the process identifier and the stable business node identifier, with each composite key corresponding to one business node record. The business node record includes the stable business node identifier, node order, and node entry conditions, and may also include business type, dependent business objects, associated actions, and display attributes.

[0044] The node order represents the arrangement order when there are multiple candidate business nodes in the same business phase. In one specific embodiment, the node order is recorded using integers, with a numerical interval reserved between adjacent nodes so that it is not necessary to modify all node numbers when adding a new business node.

[0045] Node entry conditions represent the business conditions that a business node must meet to enter the candidate executable state. In one specific embodiment, node entry conditions include business object status conditions, user permission conditions, prerequisite node completion conditions, and necessary business field conditions. For example, an order creation node requires the current user to be logged in, the service item to be selected, and the service status to be in the "allow order" state; a payment processing node requires the order to be created and the order status to be in the "pending payment" state; and a service activation node requires the payment status to be "payment completed."

[0046] When configuration items for the same business node originate from multiple data sources, the business process generation terminal 100 can merge them based on the confirmation status and priority of the data sources. In one specific embodiment, the data source confirmation status includes draft, approved, and finalized, with priority given to data with a higher degree of confirmation; if the confirmation status is the same, the content to be used is determined according to the priority recorded in the data source. When the confirmation status and priority are the same and there is still a conflict for the same configuration item, the conflict is recorded as a blocking-level error.

[0047] In step S2, the business process generation terminal 100 obtains the runtime capability directory corresponding to the business execution terminal 400, determines the compiled capabilities and dependency levels associated with each business node based on the business node list and the runtime capability directory, generates a data binding list, action list, status list and capability dependency list, and encapsulates them together with the business node list into a business service process template package.

[0048] The runtime capability directory describes the processing capabilities that have been compiled and can be actually invoked in the business execution terminal 400. For example... Figure 3 As shown, in one specific embodiment, the software building module 500 registers the registration information and runtime versions of the pre-compiled business processor, data adapter, and state processor during the application building process. The runtime capability catalog generation module 510 reads the above registration information and generates a runtime capability catalog corresponding to the runtime version. The capability catalog synchronization module 520 provides the runtime capability catalog to the business process generation terminal 100 and synchronizes it to the runtime capability catalog storage unit 450 in the business execution terminal 400.

[0049] In one specific embodiment, each runtime capability records a capability identifier, capability type, minimum runtime version, input data pattern identifier, set of allowed action intents, security level, and fallback capability identifier. The capability identifier uniquely identifies a compiled capability; the capability type distinguishes between service processors, data adapters, and state processors; the input data pattern identifier describes the data structures the capability is allowed to receive; the set of allowed action intents records the types of actions the capability is allowed to process; the minimum runtime version indicates the lowest software version that the capability can be invoked; and the fallback capability identifier indicates another compiled capability that can be used as a replacement when the current capability is unavailable.

[0050] In one specific embodiment, the runtime capability catalog uses capability_id to record capability identifiers, carrier_type to record capability types, input_schema_id to record input data patterns, allowed_intent_ids to record the set of allowed action intents, min_runtime_version to record the minimum runtime version, security_level to record the security level, and fallback_capability_id to record fallback capability identifiers.

[0051] For example, `action.open.service.v2` represents the action processing capability for opening a service, `action.payment.shared.v1` represents the shared payment processing capability, and `project.service.primary.v1` represents the project service data adaptation capability. The above names are a naming convention used in specific embodiments.

[0052] The business process generation end iterates through the list of business nodes 100 times, and searches for the corresponding capabilities in the runtime capability directory based on the actions and data required by each business node. For example, if the service.entry business node has the open.service action, it searches the runtime capability directory for capabilities that allow the open.service action; if the order creation node requires service.id and user.id, it determines whether the business fields meet the input requirements based on the input data pattern of the corresponding business processing capability.

[0053] The business process generation terminal 100 determines the dependency level of the capabilities associated with a business node based on the dependency level field recorded in the business service configuration data or the preset mapping relationship between business node categories and dependency levels. In this embodiment, the capability dependency level includes required capabilities and optional capabilities. In one specific embodiment, the processing capabilities corresponding to order creation, payment processing, and service activation are set as required capabilities, while the capabilities corresponding to auxiliary recommendations, statistical displays, and non-critical auxiliary functions are set as optional capabilities.

[0054] A data binding list is used to record the correspondence between business fields and business nodes, data sources, and data adaptation capabilities. In one specific embodiment, the records in the data binding list include stable business field keys, data types, data adapter identifiers, data paths, default values, and null value handling methods.

[0055] Stable business field keys serve as unified field identifiers between the business service process template package and project business data. For example, service.primary.id represents the primary service project number, service.primary.title represents the service project name, order.id represents the order number, order.status represents the order status, and payment.status represents the payment status. When different projects use different field names, the data adapter is responsible for converting project fields into corresponding stable business field keys.

[0056] In one specific embodiment, project business data, template default values, and common default values ​​determine the final input value according to a preset priority. After obtaining the project business data, the business execution terminal 400 first performs data type verification. If the data type of the project business data is inconsistent with the capability input mode, a conversion is performed through a data adapter; if the converted data still does not meet the input mode, a template default value that meets the data type requirements is adopted. The business execution terminal 400 forms the input data for the pre-compiled business processor according to the stable business field keys registered in the data binding list.

[0057] An action list describes the business actions that a business node can trigger. In one specific embodiment, the action record includes an action intent identifier, parameter pattern, parameter source, permission conditions, and processor capability identifier.

[0058] Action intent identifiers are used to indicate the type of business behavior. For example, `open.service` indicates entering a service, `open.resource` indicates opening a resource, `start.chat` indicates establishing a session, `submit.form` indicates submitting a form, `request.login` indicates requesting login, and `pay.order` indicates order payment. Parameter patterns describe the input parameters and parameter types required by the business processor; parameter source records whether the parameters come from business data, runtime context, or user input; permission conditions record the user permissions required to execute the action; and processor capability identifiers point to the action processing capabilities registered in the runtime capability directory.

[0059] In one specific embodiment, the action intent identifier of the service entry node is open.service, the processor capability identifier is action.open.service.v2, the parameter mode is service_ref.v1, the parameter source is service.primary.id, and the permission condition is project_service_read.

[0060] A status list is used to record the business states and status handling requirements involved in the operation of a business process. In one specific embodiment, business states include: order not created, order created, payment pending, payment processing, payment completed, service available, service in progress, and service completed. The status list can also record the status handling capabilities corresponding to operational states such as no permission, service unavailable, and data anomalies.

[0061] The capability dependency list records the capability identifier, dependency level, minimum runtime version, and fallback capability referenced by business nodes. When a business service process template package needs to adapt to multiple runtime versions, it can also record the compatible runtime range, the previous compatible version, and the standard template identifier.

[0062] In one specific embodiment, the template metadata includes template_id, template_version, compatible_runtime_range, previous_compatible_version, and standard_template_id. template_id represents the template identifier, template_version represents the current template version, compatible_runtime_range represents the runtime version range for which compatibility checks have been completed, previous_compatible_version points to an existing template version suitable for a lower runtime version, and standard_template_id points to a standard business service process template.

[0063] The business process generation module 100 encapsulates the business node list, data binding list, action list, status list, and capability dependency list into a business service process template package. Each list establishes a reference relationship through stable business node identifiers, stable business field keys, and capability identifiers.

[0064] For example, the `service.entry` business node references the `open.service` action intent, the `open.service` action record references the `action.open.service.v2` processor capability, and the action parameters reference the `service.primary.id` stable business field key. Through these reference relationships, a definite correspondence is formed between business nodes, business actions, business data, and terminal processing capabilities.

[0065] In one specific embodiment, the business service process template package further includes a state transition list. The state transition records in the state transition list include the source business state, the action intent identifier, and the target business state.

[0066] For example, the "order created" status transitions to the "payment processing" status via the `pay.order` action; the "payment processing" status transitions to the "payment completed" status upon successful payment of the payment result; and the "payment completed" status transitions to the "service ready" status via the `activate.service` action. State transition records use business state identifiers consistent with the state list.

[0067] In step S3, the business process generation terminal 100 establishes a reference graph based on the reference relationships of each list in the business service process template package, performs checks on reference integrity, data pattern compatibility, action execution conditions, and runtime version compatibility, and stops publishing when a blocking-level error exists.

[0068] The reference graph uses configuration records in each list as graph nodes, and reference relationships formed by stable business node identifiers, stable business field keys, and capability identifiers as graph edges. In one specific embodiment, a business node record is associated with an action record through a stable business node identifier, and with a data binding record through a stable business field key. An action record is associated with a capability item in the runtime capability catalog through a processor capability identifier.

[0069] Referential integrity checks are used to verify that each reference in the business service process template package has a corresponding target. For example, when the service.entry business node references service.primary.id, the corresponding business field record must exist in the data binding manifest; when the action manifest references action.open.service.v2, the capability identifier must exist in the runtime capability directory. A blocking-level error occurs when a reference target is missing.

[0070] Data schema compatibility validation checks whether the data provided in the data binding manifest conforms to the input data schema required for association capabilities. For example, if a business processor requires service.id to be a string type, the corresponding data binding record should provide a data source or data adapter that can produce a string type result. Required fields must have a clearly defined data source, default value, or other data processing method that satisfies the input schema.

[0071] Action execution condition validation is used to check the configuration relationship between action intent, parameter mode, permission conditions, and business status. In one specific embodiment, the validation content includes whether the action intent belongs to the set of actions allowed by the processor, whether the field referenced by the parameter mode exists, whether the permission identifier referenced by the permission condition has been registered, and whether the business status condition references a valid status in the status list.

[0072] Runtime version compatibility verification checks whether the compiled capabilities referenced by the business nodes exist in the capability directory corresponding to the target runtime version, and whether the current runtime version meets the minimum runtime version required for the capability. For required capabilities, it also checks whether a previous compatible version or standard template is configured; for optional capabilities, it also checks whether a fallback capability or node skipping method is configured.

[0073] In one specific embodiment, cross-manifest validation results are categorized into blocking, warning, and alert levels. Blocking-level errors affect the actual execution of the business service process; template publishing is halted when a blocking-level error occurs. Warning-level errors are processed again after confirmation information is recorded, while alert-level errors are written to the publishing record.

[0074] For a business service process template package that includes a state transition list, step S3 also includes business state transition relationship verification. The business process generation end 100 establishes a business state transition graph using business states as state nodes and state transition records as directed edges.

[0075] Each directed edge carries an action intent identifier. The business process generation end 100 obtains the processor capability identifier corresponding to the action intent based on the action list and queries the corresponding compiled action processing capability in the runtime capability directory. When the action intent does not correspond to a registered action processing capability, the state transition record is determined to be an invalid transition and a blocking level error is generated.

[0076] The action record in the action list also includes parameter mode, permission conditions, and business status conditions. For status transition records that are not determined to be invalid transitions, the business process generation end 100 performs a combined verification based on the parameter mode, permission conditions, and business status conditions.

[0077] Parameter pattern validation is used to determine whether the parameters required for an action have a registered data source and whether they meet the data type requirements; permission condition validation is used to determine whether the permission identifier referenced by the state transition exists in the permission configuration; business state condition validation is used to determine whether the source business state and the target business state have been registered, and whether the action intent is allowed to be executed under the source business state.

[0078] An executable state transition diagram is constructed by combining and verifying the state transition records.

[0079] The business process generation end checks the business states in the executable state transition diagram. When a business state has an entry path, is not registered as a process end state, and has no subsequent executable state transition, the business state is determined to be an abnormal termination state and a blocking level error is generated.

[0080] For example, if an order can move from the "order created" state to the "payment processing" state, but there are no subsequent state transitions that meet the capability, parameter, and state conditions in the "payment processing" state, then the business process cannot continue after reaching the "payment processing" state. This configuration is identified as an abnormal termination state during the release phase.

[0081] The business node records in the business node list may also include payment dependency identifiers. Payment dependency identifiers indicate that the corresponding service item needs to complete the payment status transition before it can enter the service executable state.

[0082] For service items with payment dependency identifiers, the business process generation terminal 100 checks whether there exists a first reachable path from the order created state to the payment completed state, and a second reachable path from the payment completed state to the service executable state in the executable state graph. If neither reachable path exists, a blocking-level error is generated.

[0083] In one specific embodiment, reachability paths are determined using a breadth-first traversal. Business states are stored in an adjacency list, with each source business state corresponding to a set of target business states reachable through valid state transitions. When performing the first reachability path determination, the "order created" state is added to the queue to be accessed, and the reachable target states are expanded sequentially, with each expanded state recorded. When the "payment completed" state is reached, it is determined that the first reachable path exists. Subsequently, the queue to be accessed and the accessed set are reinitialized, using the "payment completed" state as a starting point to determine whether the service is ready to execute.

[0084] In another specific embodiment, depth-first traversal can also be used to perform the above reachability determination. When there is a loop state formed by retries, cancellations, or re-payments in the state transition relationship, the business states that have been expanded in the same path search are recorded to avoid the continuous repeated expansion of the same state.

[0085] After completing the cross-list consistency verification, in one specific embodiment, the business service process template package is further standardized, serialized, and processed for integrity. Each list is deterministically sorted according to list name, stable business node identifier, node order, and field name, with unified character encoding, numeric representation, and null value representation, and then serialized according to the preset list order.

[0086] In one specific embodiment, after normalized serialization, the SHA-256 algorithm is used to calculate the template packet digest. Template versions are stored using an immutable versioning method, with each template version corresponding to fixed template content. A new template version is generated when the template content changes.

[0087] The business process generation terminal 100 sends the validated business service process template package to the process server 200. The process server 200 saves the business service process template package, the template version, and the association between the project and the template, and returns the corresponding template version or a compatible template version according to the runtime version of the business execution terminal 400.

[0088] In step S4, the business execution terminal 400 obtains the verified business service process template package, user context, and business object status, and determines candidate executable business nodes based on the node entry conditions, user context, and business object status in the business node list.

[0089] User context represents the identity and authorization information of the current user when participating in a business process. In one specific embodiment, user context includes user identifier, login status, subject type, affiliated business subject, role, and permission set.

[0090] The business object status represents the actual state of the current business processing object. In one specific embodiment, the business object status includes service status, order status, payment status, and completed business nodes. The business execution terminal 400 obtains the business object status from the business data server 300.

[0091] The business execution terminal 400 traverses the list of business nodes, reads the entry conditions of each business node, and makes a judgment based on the current user context and the state of the business object.

[0092] For example, the service details node requires that a service item has been selected; the order creation node requires that the user is logged in, has service purchase permissions, and the service status is "available for ordering"; the payment processing node requires that the order status is "order created" or "pending payment"; and the service activation node requires that the payment status is "payment completed." Business nodes that meet the node entry conditions are identified as candidate executable business nodes.

[0093] In one specific embodiment, the node entry conditions are recorded using structured conditions, which include at least the condition type, comparison object, comparison relationship, and condition value. For example, `payment.status` equal to `paid` indicates that the payment status has been completed, and `permission` containing `project_service_read` indicates that the user has access to the corresponding service.

[0094] When multiple entry conditions exist simultaneously, the business node record can also be configured with logical relationships between the conditions. In one specific embodiment, when all the necessary conditions of the same business node are met, the business node enters the candidate executable business node set.

[0095] Candidate executable service nodes represent nodes whose service status and user conditions have been met. Whether the terminal actually has the ability to execute is determined in step S5.

[0096] In step S5, the service execution terminal 400 generates an ordered service execution plan and matches the capability identifiers of candidate executable service nodes with the runtime capability catalog. If a capability is unavailable, the execution process is rolled back or the node is skipped according to the dependency level; if a capability is available, the association between the corresponding service node, the action intent, and the pre-compiled service processor is written into the execution plan.

[0097] For each candidate executable business node, the business execution terminal 400 obtains the associated capability identifier, searches for the corresponding capability item in the runtime capability directory, and determines whether the current runtime version meets the minimum runtime version of the capability.

[0098] When the capability exists and the version conditions are met, the candidate business node is written into the ordered business service execution plan.

[0099] In one specific embodiment, each execution plan item includes a stable business node identifier, node order, capability identifier, input business data, action intent identifier, processor capability identifier, capability dependency level, and rollback strategy. Multiple execution plan items are arranged according to the node order in the business node list.

[0100] The processor capability identifier in the action list serves as a matching key to establish the association between the action intent and the pre-compiled service processor of the terminal. For example, if the processor capability identifier in the open.service action record is action.open.service.v2, after the service execution terminal 400 finds this processing capability in the runtime capability directory, it will associate open.service with the already compiled action.open.service.v2 processor and write this association into the corresponding execution plan item.

[0101] The ability dependency level includes required abilities and optional abilities.

[0102] When the required capability associated with a candidate executable business node does not exist in the runtime capability catalog, or when the runtime version of the current business execution terminal 400 is lower than the minimum runtime version of the required capability, a template compatible with the current runtime version is found based on the previous compatible version recorded in the business service process template package.

[0103] In one specific embodiment, if the current service execution terminal runtime version is 2.4.0, and a certain required capability in the target template requires a minimum runtime version of 2.5.0, then the rollback control module 440 obtains a service process template suitable for version 2.4.0 based on the previous compatible version. If no suitable previous compatible version exists, a standard template is used to identify the corresponding standard service process template. The standard service process template is a service process template that has already undergone compatibility verification for the basic runtime versions supported by the system.

[0104] When a candidate executable business node is associated with an optional capability, the execution plan is searched first based on the fallback capability identifier to find a fallback capability that can be executed in the current runtime version. If an available fallback capability exists, it is written into the execution plan. If no fallback capability is registered or the fallback capability is still unavailable, the business node corresponding to that optional capability is skipped, and the remaining business nodes that meet the conditions are written into the execution plan.

[0105] In one specific embodiment, the runtime version of the service execution terminal 400 is 2.4.0, the resource preview capability resource.preview.v2 requires a minimum runtime version of 2.5.0, and resource.preview.v1 is recorded in the capability dependency list as a fallback capability. The service execution terminal 400 selects resource.preview.v1 during the capability matching process, while the capability configurations of the other service nodes remain unchanged.

[0106] In step S6, in response to the triggering of business actions in the ordered business service execution plan, the business execution terminal 400 determines the pre-compiled business processor according to the association recorded in the execution plan, verifies the parameters, user permissions and business object status, calls the corresponding business processor after passing the verification, updates the business object status according to the execution result, and determines the subsequent executable business nodes based on the updated business object status and node entry conditions.

[0107] Parameter validation is performed according to the parameter patterns in the action list. In one specific embodiment, the parameter pattern records the parameter name, data type, whether it is required, and allowed data sources. The business execution terminal 400 checks whether the parameters obtained for the currently executed item meet the above requirements.

[0108] For example, the `open.service` action requires the `service.id` parameter to be a string and is a required field. The business execution terminal returns a 400 error and retrieves the service number from the stable business field key `service.primary.id`. If the data type and required conditions meet the parameter pattern, the permission verification process continues.

[0109] User permission verification is performed based on the current user context and the permission conditions in the action list. For example, the open.service action requires project_service_read permission, and the business execution terminal 400 searches for the permission identifier in the current user permission set.

[0110] Business object status validation is used to determine whether the current business object is in a state where the action can be performed. For example, the `pay.order` action requires that an order has been created and the payment status is incomplete; the `activate.service` action requires that the payment status is complete.

[0111] Once the above conditions are met, the business execution terminal 400 calls the pre-compiled business processor associated in the execution plan.

[0112] In one specific embodiment, when a user clicks the main service entry point, the service execution terminal 400 reads the action intent `open.service` and the processor capability identifier `action.open.service.v2`, verifies `service.primary.id` according to the parameter pattern, verifies the `project_service_read` permission according to the user context, and determines whether the service is accessible based on the current service status. If the verification passes, the `action.open.service.v2` processor is invoked.

[0113] When the action intent is a payment action, the shared payment processor in the business execution terminal 400 is determined based on the processor capability identifier.

[0114] In one specific embodiment, the shared payment processor obtains the order number, order amount, and service number, retrieves the payment parameters corresponding to the current order through the business data server 300, and then invokes the payment capabilities integrated into the business execution terminal 400. The payment capabilities return a result indicating payment success, payment failure, or payment cancellation.

[0115] When payment is successful, the payment status is updated to "Payment Completed" and the order status is updated to "Paid". When payment fails or is canceled, the business object status is updated according to the corresponding business configuration to either "Allow Payment Again" or "Payment Failed".

[0116] After the business object status is updated, the business execution terminal 400 makes another judgment based on the node entry conditions in the business node list. For example, the service.activate node requires payment.status to be completed. After successful payment, the node meets the entry conditions and is determined to be a subsequent executable business node.

[0117] For other business actions, the status of the corresponding business object is also updated according to the result returned by the processor. For example, after the order creation processor executes successfully, the order status is updated to "order created"; after the form submission processor executes successfully, the form status is updated to "submitted"; and after the service confirmation processor executes successfully, the service status is updated to "service available".

[0118] In one specific embodiment, the updated business object status is written to the business data server 300. When the business execution terminal 400 re-enters the same business process, it obtains the latest status from the business data server 300 and determines the currently executable business node based on the node entry conditions.

[0119] like Figure 2 As shown, a business process configurable generation and controlled execution system includes a business process generation terminal 100, a process server terminal 200, a business data server terminal 300, and a business execution terminal 400.

[0120] The business process generation module 100 includes a configuration merging module 110, a process template generation module 120, and a cross-list verification module 130. The configuration merging module 110 is connected to the process template generation module 120, and the process template generation module 120 is connected to the cross-list verification module 130.

[0121] The configuration merging module 110 receives business service configuration data, merges configuration items based on stable business node identifiers, and generates a business node list. The process template generation module 120 generates a data binding list, action list, status list, and capability dependency list based on the business node list and runtime capability directory, and encapsulates them into a business service process template package. The cross-list verification module 130 establishes a reference graph based on the reference relationships between the lists and performs pre-release verification.

[0122] The process server 200 includes a process template version storage module 210 and a project template association module 220. The process template version storage module 210 stores the validated business service process template packages and template version information. The project template association module 220 records the correspondence between project identifiers, template identifiers, and template versions.

[0123] In one specific embodiment, the process template version storage module 210 uses an immutable versioning method to store template packages, with each version corresponding to fixed content. When the template content changes, a new version is generated, and the compatible_runtime_range and previous_compatible_version are recorded.

[0124] The business data server 300 is connected to the execution plan generation module 420 in the business execution terminal 400, and provides the execution plan generation module 420 with project business data, user permissions and business object status.

[0125] The service execution terminal 400 stores a runtime capability catalog and includes a template package client 410, an execution plan generation module 420, an action intent distribution module 430, and a rollback control module 440. In one specific embodiment, the service execution terminal 400 further includes a runtime capability catalog storage unit 450 and a local verification cache 460.

[0126] The template package client 410 obtains the business service process template package corresponding to the current project from the process server 200 and provides the template package to the execution plan generation module 420.

[0127] In one specific embodiment, the template package client 410 recalculates the template digest according to the normalized serialization rules consistent with those of the publishing end, and compares it with the digest carried in the template package. If the digests match, the business service process template package that has passed the integrity verification is written to the local verification cache 460.

[0128] The execution plan generation module 420 reads the template package, the runtime capability directory, and the business data provided by the business data server 300, and generates an ordered business service execution plan based on the node entry conditions and capability matching results.

[0129] The action intent distribution module 430 queries the runtime capability directory storage unit 450 based on the processor capability identifier in the execution plan, determines the pre-compiled service processor associated with the processor capability identifier, and distributes the service action to the corresponding pre-compiled service processor.

[0130] The rollback control module 440 handles template version rollback, optional capability rollback, and business node skipping. When the integrity verification of the business service process template package fails, the rollback control module 440 retrieves the business service process template package that has passed the integrity verification from the local verification cache 460. When a required capability is incompatible with the current runtime version, the rollback control module 440 determines the compatible template version that needs to be loaded based on the previous compatible version and controls the template package client 410 to retrieve the corresponding business service process template package from the process server 200.

[0131] During runtime capability matching, the execution plan generation module 420 sends the processing results of capability unavailability or runtime version incompatibility to the rollback control module 440. The rollback control module 440 determines the corresponding rollback method based on the capability information in the runtime capability catalog storage unit 450, and returns the rollback capability selection or node skip result to the execution plan generation module 420. When template version rollback is required, the rollback control module 440 controls the template package client 410 to obtain the corresponding compatible template version. After the template package client 410 completes the template package integrity verification, it writes the verified template package to the local verification cache 460.

[0132] like Figure 3 As shown, the system also includes a software building module 500, a runtime capability catalog generation module 510, and a capability catalog synchronization module 520.

[0133] The software building module 500 records the registration information of pre-compiled service processors, data adapters, and state processors, as well as their current runtime versions. In one specific embodiment, the service processor registration information includes processor capability identifiers, permitted action intentions, input data patterns, and security levels; the data adapter registration information includes adapter identifiers, input data types, and output data types; and the state processor registration information includes the types of states it can process.

[0134] The runtime capability catalog generation module 510 reads the registration information registered in the software building module 500 and generates the corresponding runtime capability catalog according to the runtime version.

[0135] In one specific embodiment, runtime versions 2.4.0 and 2.5.0 generate corresponding runtime capability directories. The pre-compiled service processors newly added in version 2.5.0 are only recorded in the runtime capability directory corresponding to version 2.5.0.

[0136] The capability catalog synchronization module 520 obtains the corresponding runtime capability catalog based on the runtime version of the target business execution terminal, provides the runtime capability catalog to the business process generation terminal 100, and synchronizes it to the runtime capability catalog storage unit 450 in the business execution terminal 400.

[0137] The business process generation terminal 100 uses the capability catalog corresponding to the target runtime version to determine the compiled capabilities that the business nodes can reference, and the business execution terminal 400 uses the capability catalog of the corresponding version to complete runtime capability matching and action processor determination.

[0138] In implementation scenarios with multiple business execution terminal versions, the runtime capability catalog generation module 510 stores the capability catalog corresponding to each runtime version. The business process generation terminal 100 performs compatibility verification according to the runtime versions supported by the target project and records the compatible runtime range in the template metadata.

[0139] In one specific embodiment, the business execution terminal 400 uses a WeChat mini-program. During the software build phase, pre-compiled business processors, data adapters, and state processors are released along with the mini-program code, and the runtime capability catalog is generated from the capability information already registered during the build process.

[0140] In another specific embodiment, the service execution terminal 400 uses an application compiled based on uni-app. The runtime capability catalog is still generated according to the processing capabilities already registered in the current build version.

[0141] In other specific embodiments, the business execution terminal 400 may also adopt an enterprise application container, a super application sub-application, or an in-vehicle lightweight application. Each runtime environment generates a corresponding runtime capability catalog according to its own software construction results.

[0142] In a specific business scenario, the target business is consulting services. Business service configuration data includes consultant information, service items, user permissions, order configuration, and payment configuration. The business node list includes service entry nodes, service detail nodes, order creation nodes, payment processing nodes, and service activation nodes.

[0143] The service entry node references the stable business fields `service.primary.id` and `service.primary.title`, with the action intent being `open.service` and the processor capability identifier being `action.open.service.v2`. The order creation node requires the user to be logged in and have selected a service. The payment processing node requires the order status to be "order created". The service activation node requires the payment status to be "payment completed".

[0144] The business process generation end 100 obtains the capability directory of the target runtime version, confirms that the pre-compiled business processor, order creation processing capability and shared payment processing capability corresponding to open.service have been registered, and then generates a business service process template package.

[0145] The cross-list verification module 130 checks whether service.primary.id has a data binding record, whether open.service corresponds to the registered action processing capability, whether the order status and payment status have been registered, and establishes a business status transition diagram.

[0146] In service projects with payment dependency identifiers, the executable state transition graph needs to have a first reachable path from the order created state to the payment completed state, and a second reachable path from the payment completed state to the service executable state. After both paths pass validation, the business service process template package enters the release process.

[0147] After obtaining the template package, the business execution terminal 400 first determines candidate executable business nodes based on the current user context and business object status. If the user has not yet created an order, the service entry node and service details node meet the node entry conditions.

[0148] After the user completes the service selection, the order creation action is triggered. The pre-compiled order processor executes successfully and updates the order status to "order created". The payment processing node then meets the node entry conditions.

[0149] After a user triggers a payment action, the shared payment processor obtains the payment parameters and invokes the terminal's payment capabilities. Upon successful payment, the payment status is updated to "Payment Completed." The service activation node meets the node entry conditions and enters the subsequent ordered business service execution plan.

[0150] In another specific embodiment, the runtime version of the service execution terminal 400 is lower than the minimum runtime version required by a certain optional capability. The execution plan generation module 420 reads the fallback capability of that capability from the capability dependency list and generates an execution plan using the fallback capability that meets the current runtime version. If the fallback capability does not exist, the corresponding optional service node is skipped.

[0151] In cases of incompatibility of essential capabilities, the rollback control module 440 determines a compatible template version applicable to the current runtime version based on the previous compatible version in the template metadata, and controls the template package client 410 to obtain the corresponding business service process template package from the process server 200; if no compatible template version exists, the business service process template corresponding to the standard template identifier is obtained. In this embodiment, after the template package client obtains a compatible version or standard template and completes integrity verification, it uses the obtained business service process template package as the current template, and the execution plan generation module regenerates an ordered business service execution plan based on the current template.

[0152] In one specific embodiment, the business service process template package is stored in JSON format. The business node list, data binding list, action list, status list, capability dependency list, and state transition list are each stored as independent data objects, and references are established through stable business node identifiers, stable business field keys, and capability identifiers.

[0153] In another specific embodiment, the business service process template package is stored using CBOR, Protocol Buffers, or database records. When the data storage format changes, the stable reference relationships between the various lists remain consistent.

[0154] Through the above implementation method, the business process generation terminal 100 forms a business node list based on the business service configuration data, and generates a business service process template package based on the runtime capability catalog corresponding to the target business execution terminal 400; before release, the business service process template package completes cross-list reference, data mode, action execution conditions, runtime version, and business state transition relationship verification; during the running phase, the business execution terminal 400 further combines the current user, business object status, and actual runtime capabilities to generate an ordered business service execution plan, and executes the corresponding business actions through a pre-compiled business processor, and updates the business object status and subsequent executable nodes based on the execution results.

[0155] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A method for configurable generation and controlled execution of business processes, characterized in that, include: S1: The business process generation end obtains business service configuration data, merges configuration items belonging to the same business node according to the stable business node identifier, and generates a list of business nodes that record the node order and node entry conditions. S2: The business process generation end obtains the runtime capability catalog corresponding to the business execution terminal, determines the compiled capabilities and dependency levels associated with each business node based on the business node list and the runtime capability catalog, generates a data binding list, action list, status list and capability dependency list, and encapsulates them with the business node list into a business service process template package. S3: The business process generation end establishes a reference graph based on the reference relationships of each list in the business service process template package, performs reference integrity, data pattern compatibility, action execution conditions and runtime version compatibility checks, and stops publishing when there is a blocking-level error. S4: The business execution terminal obtains the verified business service process template package, user context and business object status, and determines the candidate executable business nodes based on the node entry conditions, user context and business object status in the business node list; S5: The business execution terminal generates an ordered business service execution plan, matching the capability identifiers of candidate executable business nodes with the runtime capability catalog; when a capability is unavailable, the execution process is rolled back or the node is skipped according to the dependency level; when a capability is available, the association between the corresponding business node and its action intent and the pre-compiled business processor is written into the execution plan. S6: In response to the business action trigger in the execution plan, determine the pre-compiled business processor according to the association, verify the parameters, user permissions and business object status, and call the processor after passing the verification. Update the business object status according to the execution result, and determine the subsequent executable business nodes based on the updated business object status and node entry conditions.

2. The method for configurable generation and controlled execution of business processes according to claim 1, characterized in that, In step S2, the business service process template package also includes a state transition list, and the state transition records in the state transition list include the source business state, the action intent identifier, and the target business state; In step S3, a business state transition graph is established with the business state as the state node and the state transition record as the directed edge. The action intent corresponding to each state transition record is verified according to the action list and runtime capability catalog to see if it corresponds to the registered action processing capability. If no corresponding relationship is established, the state transition record is determined to be an invalid transition and a blocking level error is generated.

3. The method for configurable generation and controlled execution of business processes according to claim 2, characterized in that, In step S3, the action records in the action list also include parameter modes, permission conditions, and business status conditions; For state transition records that are not determined to be invalid transitions, a combined verification is performed based on the parameter mode, permission conditions, and business status conditions. The state transition records that pass the combined verification are used to form an executable state transition diagram. When a business state has an entry path, is not configured as a process end state, and has no subsequent executable state transition, the business state is determined as an abnormal termination state and a blocking-level error is generated.

4. The method for configurable generation and controlled execution of business processes according to claim 3, characterized in that, In step S3, the business node records in the business node list also include payment dependency identifiers; For service items with payment dependency identifiers, determine whether there is a first reachable path from the order created state to the payment completed state, and a second reachable path from the payment completed state to the service executable state in the executable state of the executable state. A blocking-level error occurs when any reachable path does not exist.

5. The method for configurable generation and controlled execution of business processes according to claim 1, characterized in that, In step S2, the action record in the action list includes an action intent identifier, parameter mode, permission conditions, and processor capability identifier, wherein the processor capability identifier corresponds to the action processing capability registered in the runtime capability catalog. In step S5, the processor capability identifier is used as a matching key to associate the action intent with the pre-compiled service processor in the service execution terminal.

6. The method for configurable generation and controlled execution of business processes according to claim 5, characterized in that, In step S6, the action parameters are verified according to the parameter pattern, the permission conditions are verified according to the user context, and the action execution conditions are verified according to the business object status. When the action intent is a payment action, the pre-compiled shared payment processor is determined based on the processor capability identifier. The shared payment processor obtains payment parameters based on the order data and calls the payment capability. The payment status and order status are updated based on the payment execution result.

7. The method for configurable generation and controlled execution of business processes according to claim 1, characterized in that, In step S2, the capability dependency level includes required capabilities and optional capabilities. The capability dependency list also records the minimum runtime version and fallback capability corresponding to each capability. The business service process template package also records the previous compatible version and standard template identifier. In step S5, if the required capability is unavailable, the previous compatible version that is compatible with the current runtime version is selected; if no compatible version exists, the standard template is used. When optional capabilities are unavailable, fallback capabilities or skip the corresponding business nodes can be used.

8. A business process configurable generation and controlled execution system, characterized in that, It includes the business process generation end, the process server end, the business data server end, and the business execution terminal; The business process generation end includes a configuration merging module, a process template generation module, and a cross-list verification module connected in sequence; the process server includes a process template version storage module and a project template association module. The business execution terminal includes a template package client, an execution plan generation module, an action intent distribution module, a rollback control module, and a runtime capability directory storage unit, which stores the runtime capability directory. The business process generation terminal is connected to the process server terminal, and the process server terminal and the business data server terminal are respectively connected to the business execution terminal. The execution plan generation module is connected to the template package client, the runtime capability directory storage unit, and the action intent distribution module, respectively. The rollback control module is connected to the template package client, the execution plan generation module, and the runtime capability directory storage unit, respectively.

9. The business process configurable generation and controlled execution system according to claim 8, characterized in that, It also includes a software building module, a runtime capability catalog generation module, and a capability catalog synchronization module; The runtime capability catalog generation module reads the registration information of the pre-compiled business processors, data adapters and state processors registered in the software building module, and generates a runtime capability catalog corresponding to the runtime version; The capability catalog synchronization module provides the runtime capability catalog corresponding to the target runtime version to the business process generation end and synchronizes it to the runtime capability catalog storage unit of the business execution terminal.

10. The business process configuration generation and controlled execution system according to claim 8, characterized in that, The process template version storage module saves the business service process template package in an immutable version and records the compatible runtime range and the previous compatible version. The business execution terminal also includes a local verification cache connected to the template package client; When the integrity verification of the current business service process template package fails, the rollback control module calls the business service process template package that has passed the integrity verification in the local verification cache. When the necessary capabilities are incompatible, the module controls the template package client to obtain the corresponding compatible version of the business service process template package.

Images