SpringBoot extension method, system, device and medium based on process engine

Abstract

This invention discloses a Spring Boot extension method, system, device, and medium based on a process engine, relating to the field of Java development technology. This invention obtains the business method information marked with annotations in the Spring container and the node call expressions of the process definition, parses and constructs the method registration set and node call set; after completing the association and matching, it performs parameter consistency verification and generates a matching analysis report; if the verification fails, it terminates the loading of the Spring container application context; if the verification succeeds, it generates dynamic construction instructions for the service execution component, binds them with the Spring declarative transaction manager and request context propagation mechanism, and then mounts them to the process engine runtime environment for integration. This invention achieves full pre-verification of process configuration at startup, reduces the coupling between business code and process orchestration, avoids runtime exceptions from the root, and improves system stability and development efficiency.

Description

Technical Field

[0001] This invention relates to the field of Java development technology, and more specifically, to Spring Boot extension methods, systems, devices, and media based on a process engine. Background Technology

[0002] With the continuous development of enterprise-level Java development technologies, Spring Boot has become the mainstream framework for backend business system development. Workflow engines, as core tools for business process orchestration, are widely used in various business scenarios requiring process-oriented control. Deep integration between the two is a core requirement for enterprise-level system development. Currently, mainstream workflow engines all provide basic integration solutions with Spring Boot, allowing core components of the workflow engine to be incorporated into the lifecycle management of the Spring container. By invoking business methods of beans within the Spring container through expressions, the linkage between process execution and business logic can be achieved, meeting basic process-oriented business development needs.

[0003] However, in practical use, it still has some drawbacks. For example, the existing integration solution only parses the node call expression and looks up the target Bean and corresponding method in the Spring container through reflection when the process instance runs to the corresponding service node. Configuration defects in the process definition cannot be detected in the startup phase before application deployment and can only be exposed when online business is triggered. This can easily lead to irreversible problems such as interruption of the executing process instance and disorder of business data, seriously affecting the stability of the business system. The existing solution has weak support for mapping process variables and business method parameters. It can only realize simple expression value retrieval and cannot natively adapt to complex scenarios such as composite objects, nested attributes, and multi-variable aggregation and filling. Developers need to write a lot of redundant code for parameter adaptation and data transformation in the business code, which not only greatly increases the development workload, but also leads to strong coupling between the core business logic and the process engine adaptation logic, which violates the core design goal of decoupling process orchestration and business. Meanwhile, the existing solution lacks sufficient integration with the core capabilities of the Spring ecosystem. When process nodes call business methods, they cannot fully inherit Spring's declarative transaction management mechanism, which easily leads to issues such as transactions not taking effect and exceptions not being able to be rolled back. The asynchronous execution thread of the process engine can also cause the request context to be lost, failing to meet the core requirements of enterprise-level systems such as access control, end-to-end auditing, and multi-tenant isolation. In addition, each execution of a process node requires repeated operations such as expression parsing and reflection calls, which generates a lot of repetitive performance overhead in high-concurrency, high-frequency process execution scenarios, reducing system throughput and response efficiency, and making it difficult to adapt to the high-concurrency operation requirements of core business. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides a Spring Boot extension method, system, device, and medium based on a process engine. The following solutions address the problems of frequent runtime exceptions, high development and adaptation costs, insufficient integration, significant performance loss, and high coupling in the existing integration solutions mentioned in the background.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a Spring Boot extension method based on a process engine, comprising: S1: Obtain information about business methods annotated with custom delegates in the Spring container, and read the service node call expressions in the pre-defined process source files in the project resource directory; S2: Parse the business method information, extract the method identifier, parameter type and variable mapping relationship, and construct a method registration set; Parse the service node call expression, extract the node identifier and call target, and construct the node call set; S3: Associate and match the calling target of the node call set with the method identifier of the method registration set. For nodes that are successfully matched, based on the data output definition and variable mapping relationship of its predecessor node, perform semantic mapping on the output data of the predecessor node according to the mapping relationship, generate the target data structure and deduce the expected parameter type sequence. Perform consistency analysis between the expected parameter type sequence and the actual parameter type sequence of the corresponding method in the successfully matched method registration set, and generate a matching analysis report including missing identifiers, structural inconsistencies, and type incompatibilities. S4: Read the matching analysis report. When at least one of the following is recorded: missing item, inconsistent structure item, or incompatible type item, trigger the Spring container startup initialization failure handling and terminate the application context loading. When there are no records for any item, the construction instructions for dynamically constructing the service execution component at runtime are generated based on the correspondence between the method identifier and the process node identifier in the method registration set. S5: Execute the construction instructions to generate the process engine service execution component, bind it with the Spring declarative transaction manager and request context propagation mechanism, and then mount it to the process engine runtime environment to complete the extended integration.

[0006] The Spring Boot extension system based on the process engine includes an information acquisition module, a parsing and building module, an association and verification module, an instruction generation module, and a component mounting module. Information Acquisition Module: Used to acquire information about business methods annotated with custom delegates in the Spring container, and to read service node call expressions from the pre-defined process definition source files in the project resource directory; Parsing and building module: used to parse the business method information to build a method registration set, and to parse the service node invocation expression to build a node invocation set; Association verification module: used to associate and match the calling target with the method identifier, deduce the expected parameter type sequence for successfully matched nodes, perform consistency calculation with the actual parameter type sequence, and generate a matching analysis report; Instruction generation module: Used to read the matching analysis report. When any type of exception item is recorded, it triggers the Spring container startup initialization failure handling. When there are no records, it generates the construction instructions for dynamically constructing the service execution component at runtime. Component mounting module: Used to execute the construction instructions to generate service execution components, and then mount them to the process engine runtime environment after binding with Spring declarative transaction manager and request context propagation mechanism.

[0007] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the Spring Boot extension method based on a process engine as described in any one of claims 1 to 7.

[0008] A computer storage medium storing a computer program that, when executed by a processor, implements the Spring Boot extension method based on a process engine as described in any one of claims 1 to 7.

[0009] The technical effects and advantages of this invention are as follows: 1. This invention moves the verification step of process node call configuration to the Spring Boot application startup stage, and completes multi-dimensional compliance verification of all process service nodes and business methods before the application provides services to the outside world. In the case of configuration defects, the application context loading is directly terminated. This avoids the problems of business interruption and data anomaly caused by configuration errors being exposed only when the process is running, and greatly improves the operation stability and availability of the business system. 2. This invention designs standardized, multi-priority variable mapping rules that are compatible with various mapping configuration modes. It natively supports automatic semantic mapping and data filling of process context variables to business method input parameters in complex scenarios. Developers do not need to write additional parameter adaptation and data conversion code. At the same time, the annotation-based marking method does not require business code to adapt to the interface specifications of the process engine. It achieves complete decoupling between core business logic and process orchestration logic, greatly reduces development adaptation costs, and improves code maintainability and business iteration flexibility. 3. This invention uses dynamic proxy and aspect-oriented programming techniques to deeply bind dynamically generated service execution components with Spring's declarative transaction manager, ensuring that the entire process of executing business logic in process nodes is under Spring transaction control, thus guaranteeing the atomicity of business operations and data consistency. At the same time, through the built-in request context propagation mechanism, it solves the problem of context loss caused by asynchronous execution threads of the process engine, and can completely transmit all request context information. It is natively compatible with the core requirements of enterprise-level systems such as permission control, full-link auditing, and multi-tenant isolation, thus making up for the functional shortcomings of existing integration solutions. 4. This invention performs pre-compilation processing of expression parsing, method matching, and data conversion logic during the application startup phase, dynamically generating service execution components that conform to the standard interface specifications of the process engine. This allows the process instance to directly call the pre-generated components to execute business logic at runtime, eliminating the need for repeated operations such as expression parsing, target business class lookup, and method reflection invocation. This completely eliminates the overhead of redundant calculations at runtime and improves the throughput and response efficiency of the system in high-concurrency and high-frequency process execution scenarios. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the overall method flow of the present invention; Figure 2 This is a schematic diagram of the process for obtaining a matching analysis report according to the present invention; Figure 3 This is a flowchart illustrating the process of generating dynamic construction instructions according to the present invention; Figure 4 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] As attached Figures 1 to 3 The Spring Boot extension methods based on the process engine shown include: S1: Obtain information about business methods annotated with custom delegates in the Spring container, and read the service node call expressions in the pre-defined process source files in the project resource directory; It should be noted that the specific process for obtaining information about business methods annotated with custom delegates in the Spring container is as follows: A custom delegate annotation is pre-defined to identify business methods that can be called by the process engine. The scope of this annotation is clearly defined as the business class managed by the Spring container or the business methods within that class. Two core configuration rules are also defined for the annotation: First, it supports configuring the mapping relationship between business method input parameters and process context variables, clarifying the conversion and matching rules between process variables and method input parameters; second, it supports custom calling identifiers for business classes in the process engine. Without custom configuration, the default is to use the native registered name of the business class in the Spring container as the calling identifier. This annotation uses runtime-recognizable retention rules to ensure it can be correctly read and parsed during application runtime.

[0013] Based on the lifecycle management mechanism of the Spring container, the timing of the business method scanning action is set as follows: during the startup process of the Spring Boot application, after the Spring container has completed the instantiation, dependency injection and initialization of all singleton business classes, and before the application context has been finally refreshed. This execution timing can ensure that during the scanning, all business classes managed by the Spring container have been instantiated and can be fully identified and read without omissions or inaccessibility.

[0014] It iterates through all initialized singleton business classes within the Spring container and filters target business methods that can be called by the process engine according to preset rules: If the business class has a custom delegate annotation at the class level, all public instance methods in that business class that meet the calling requirements are included in the scope of target methods to be processed; if the business class does not have a custom delegate annotation at the class level, only public instance methods in that business class that have a custom delegate annotation at the method level are filtered and included in the scope of target methods to be processed; among them, public instance methods that meet the calling requirements refer to instance methods that are non-static, non-abstract, non-private, and can be called normally by the Spring container.

[0015] For each selected target business method, three types of core metadata are extracted: The first type is a unique method identifier, which is composed of the business class's call identifier and the business method name. This identifier can uniquely lock the corresponding business method execution entry point within the Spring container. The second type is method parameter sequence information. According to the order of the input parameters declared in the business method, the type information and sorting position of each input parameter are extracted to form an ordered parameter type sequence for subsequent parameter type consistency verification. The third type is the mapping relationship between parameters and process variables. The parsing of this mapping relationship follows the following priority rules: First priority: Key-value pair configuration explicitly declared through the mapping attribute in the custom delegate annotation (supports locating nested values ​​in process variables using JSON path expressions); Second priority: If no explicit configuration is used, the dot-separated naming convention is followed, automatically mapping process variables (such as order.amount) to nested attribute paths of method parameter objects (such as the amount field of the order object); Third priority: If none of the above rules are met, the default mapping rule based on method parameter names is used, that is, a one-to-one correspondence is established between method parameter names and process context variable names; This priority design ensures the determinism and scalability of the mapping rules.

[0016] All extracted business method information is standardized and encapsulated, and stored in a thread-safe storage structure that supports concurrent read and write operations, using the method identifier as the retrieval index.

[0017] Ultimately, what is obtained is information about all business methods annotated with custom delegates within the Spring container. This information specifically includes: a unique identifier for the business method that can be invoked by the workflow engine, the invocation identifier of the Spring Bean to which the method belongs, the method name, the sequence of method parameter types arranged in declaration order, and the mapping relationship between method input parameters and workflow context variables. It should be further explained that the process of reading the service node call expression from the pre-defined process definition source file in the project resource directory is as follows: In the classpath resource directory of the Spring Boot project, set a fixed default directory for process definition source files. At the same time, it supports customizing the directory path and file matching rules through the project's core configuration file. It is clear that the process definition source files must conform to the international standard format commonly used by workflow engines, and standardize the naming rules and format suffixes of files to ensure that all process definition source files can be correctly recognized, read and parsed by workflow engines and structured parsing tools.

[0018] After the Spring container completes the instantiation and initialization of all singleton beans, and before the application context publishes the final refresh event (i.e., before the ContextRefreshedEvent event is triggered), according to the preset directory path and matching rules, all process definition source files that meet the format requirements in the directory are loaded. File validity checks are performed synchronously: invalid files with empty content, error files with non-standard format, and redundant files with duplicate process unique identifiers are filtered out. At the same time, the unique identifier, storage path, and basic process topology information of each valid process definition source file are recorded to ensure that the loaded files are all valid process definition files that can be executed normally by the workflow engine.

[0019] For each valid process definition source file, a full document structure parsing is performed. All service-related nodes of executable business logic within the file are traversed, and the call expression used to specify the entry point of the business logic call is extracted from each node. The extracted raw expressions are standardized and cleaned to remove invalid content such as formatting characters, fixed input parameter identifiers, and redundant spaces, and the target business class call identifier and the name of the business method to be called are accurately extracted from the expression. Among them, the service-related nodes include three core executable nodes in the process definition: service task nodes, execution listener nodes, and task listener nodes.

[0020] The cleaned call expression is bound and encapsulated with the unique identifier of the process it belongs to, the unique identifier of the node it belongs to, and the node's position information in the process topology to form standardized node call metadata. All node call metadata are aggregated to form a node call metadata set, which is stored in a thread-safe global storage structure that supports concurrent read and write operations.

[0021] What is ultimately obtained is the call expression information of service nodes in all valid process definition source files within the project. This information specifically includes: the unique identifier of the process definition to which the call expression belongs, the unique identifier of the service node, the node type, the node's position information in the process topology, the target call Bean identifier after expression parsing, and the name of the business method to be called.

[0022] S2: Parse the business method information, extract the method identifier, parameter type and variable mapping relationship, and construct the method registration set; parse the service node call expression, extract the node identifier and call target, and construct the node call set; It should be noted that the process of parsing the business method information, extracting the method identifier, parameter types, and variable mapping relationships, and constructing the method registration set is as follows: First, all business method information is validated line by line to filter invalid data, ensuring that the baseline data for subsequent parsing is compliant and usable. The validation rules include: 1) validating the completeness and uniqueness of method identifiers, removing invalid information such as empty method identifiers, missing Bean call identifiers, and missing method names; 2) validating the completeness of parameter type sequences, removing invalid information such as missing input parameter type information or disordered sorting; and 3) validating the compliance of variable mapping relationships, removing invalid information such as a single method parameter corresponding to multiple process variables or incomplete mapping key-value pairs. For business method information that fails validation, the reason for the exception is recorded simultaneously, and it is excluded from the scope of subsequent parsing.

[0023] For each business method information that passes the validity check, precise field-by-field parsing is performed to fully extract the three core types of content required to construct the method registration set: First, method identifier parsing; the method identifier is completely extracted from the business method information. This identifier is composed of the business class's call identifier and the business method name; the original format of the identifier is preserved throughout the parsing process; Second, parameter type sequence parsing: From the business method information, strictly follow the order of the input parameters declared in the business method to completely extract the type information and sorting position of each input parameter, forming an ordered parameter type sequence; during the parsing process, strictly lock the original declaration order of the input parameters, do not adjust the parameter arrangement position, and ensure that the parsed parameter type sequence completely matches the actual input parameter declaration of the business method; Third, variable mapping relationship parsing: From the business method information, the corresponding variable mapping relationship between the method input parameters and the process context variables is completely extracted; for the mapping relationship explicitly configured in the custom delegate annotation, the original key-value pair configuration is completely preserved during parsing; for the mapping relationship generated by the default naming convention without explicit configuration, the rule of "one-to-one correspondence between method input parameter name and process context variable name" is strictly followed during parsing to ensure that the parsed mapping relationship is completely consistent with the actual configuration of the business method.

[0024] The parsed method identifiers, parameter type sequences, and variable mapping relationships are standardized and encapsulated. Using the method identifier as the unique retrieval index, the parameter type sequences and variable mapping relationships obtained from parsing the same business method information are used as the associated binding content under this index, forming a single method registration entry. All single method registration entries are summarized to construct a complete structured method registration set. Since this method registration set is only used for runtime read-only retrieval after the Spring container starts, in order to improve access efficiency and strengthen data immutability, it is encapsulated into an immutable collection that supports fast retrieval with O(1) time complexity (such as using java.util.Collections.unmodifiableMap) and injected into the process engine runtime environment.

[0025] It should be further explained that the specific process of parsing the service node call expression, extracting the node identifier and call target, and constructing the node call set is as follows: All service node call expression information is validated line by line to filter invalid data and ensure that the process-side data in subsequent parsing stages is compliant and usable. The validation rules include: first, validating the completeness of node attribution information and removing invalid information such as missing process definition unique identifiers or missing service node unique identifiers; second, validating the validity of call expressions and removing invalid information such as empty target call Bean identifiers or empty business method names after parsing; and third, validating the completeness of node topology information and removing invalid information such as missing node position information in the process topology. For service node call expression information that fails validation, the reason for the exception is recorded synchronously and excluded from the scope of subsequent parsing.

[0026] For each service node call expression that passes the validity check, perform precise field-by-field parsing to fully extract the two core types of content required to construct the node call set: First, node identifier parsing: Extract the process definition unique identifier and the service node unique identifier from the service node call expression information, and combine the two to form the node identifier; the original format of the two identifiers is preserved throughout the parsing process to ensure that the node identifier has global uniqueness within the entire process definition, and can accurately locate the unique service node in the unique process; Second, target parsing: From the service node call expression information, extract and split the two core contents of the call target, namely the target call Bean identifier and the name of the business method to be called; during the parsing process, retain the original format of the Bean identifier to ensure that it is completely consistent with the Bean call identifier format in the business method information, and at the same time retain the original content of the name of the business method to be called to ensure that the call target and the method name in the business method information can be accurately matched.

[0027] The parsed node identifiers and call targets are standardized and associated, and the node identifiers are used as unique retrieval indexes. The call targets obtained from parsing the same expression information, along with the corresponding node types and the node's position information in the process topology, are used as the associated binding content under this index to form a single node call entry. All single node call entries are aggregated to build a complete structured node call set. The node call set is stored in a thread-safe storage structure that supports high-concurrency read and write and full fast traversal. It can fully traverse all node call entries, complete the association matching between call targets and method identifiers, and quickly locate the corresponding full node information through the node identifier.

[0028] S3: Associate and match the calling targets of the node call set with the method identifiers of the method registration set. For nodes that match successfully, based on the data output definition and variable mapping relationship of their predecessor nodes, perform semantic mapping on the output data of the predecessor nodes according to the mapping relationship to generate the target data structure and derive the expected parameter type sequence. Perform consistency analysis between the expected parameter type sequence and the actual parameter type sequence of the corresponding method in the matched method registration set to generate a matching analysis report including missing identifier items, structural inconsistencies, and type incompatibilities. It should be noted that the process of associating and matching the call targets of the node call set with the method identifiers of the method registration set is as follows: Iterate through all single node call entries in the node call set. For each node call entry, extract its associated call target. Combine the target call Bean identifier in the call target with the name of the business method to be called to form a query key for retrieval. The query key is constructed according to the following rules: the target call Bean identifier is the core prefix, and the name of the business method to be called is the core suffix. The two are combined to form a complete and unique retrieval key. The method identifier is composed of the call identifier of the business class and the business method name, ensuring that the format and content of the retrieval matching are completely consistent.

[0029] Based on the query key, a precise search and match is performed in the method registry: If no method identifier exactly matches the query key in the method registry, the service node corresponding to the node call entry is determined to be a missing identifier, and the node identifier, call target, and exception reason ("The business method called by the process node has no matching callable entry in the Spring container, and no corresponding method identifier was found") of the node are recorded synchronously; If a method identifier exactly matches the query key in the method registry, the node call entry is determined to be a successful match with the method registry entry, and a one-to-one association and binding relationship is established between the node identifier and the corresponding method identifier, forming a successfully matched node correspondence.

[0030] The final results are divided into two categories: the first category is a set of missing identifiers, which includes the node identifiers, call targets, and exception reasons of all service nodes that did not match the corresponding business methods; the second category is a set of matching node correspondences, which includes the association and binding relationships between the node identifiers and the corresponding method identifiers of all successfully matched service nodes.

[0031] It should be further explained that for a successfully matched node, based on the data output definition and variable mapping relationship of its predecessor node, the output data of the predecessor node is semantically mapped according to the aforementioned mapping relationship to generate the target data structure and derive the expected parameter type sequence. The specific process is as follows: For each association and binding relationship in the set of successfully matched node correspondences, first extract the position information of the service node in the process topology from the service node call expression information based on the node identifier, and then locate all the direct predecessor nodes of the service node by combining the topology structure of the process definition source file. If the number of direct predecessor nodes is greater than one, the only valid data source is determined according to the process engine specification: the input parameter data mapping source explicitly configured for the service node in the process definition is preferred. If no explicit configuration is specified, check for naming conflicts in the output variables of each predecessor node. If a conflict exists, record it as a structural inconsistency exception and prompt the developer to eliminate ambiguity through process variable scope isolation or explicit mapping. If there is no conflict, merge the output variables of all predecessor nodes as usable data sources. Based on the determined valid data source, obtain the data output definition, which clarifies the variable names, variable data structures, and variable data types output to the process context after the predecessor node has completed execution.

[0032] Then, based on the method identifier in the association and binding relationship, extract the variable mapping relationship corresponding to the method identifier from the method registration set to clarify the one-to-one correspondence between each input of the business method and the process context variable.

[0033] Based on variable mapping relationships, the variable data output by the predecessor node to the process context is mapped to the corresponding input parameter positions of the business method according to the following rules: If the input parameter of the business method is a single basic type or simple object type, the complete data of the corresponding process variable is directly mapped to the input parameter position; if the input parameter of the business method is a composite data transmission object type, the parameterless constructor of the input parameter type is called first through reflection to create an object instance; if the type does not provide a parameterless constructor or is an interface type, it checks whether a factory bean reference is configured in the custom delegate annotation, and uses the factory bean to generate the required instance at runtime; after obtaining the object instance, according to the variable mapping relationship, the multiple variable data scattered in the process context are aggregated and filled into the corresponding attribute fields of the instance; the mapping relationship supports the naming convention of dot-separated names, for example, the process variable order.amount is automatically mapped to the amount field of the order attribute of the composite object; it also supports explicit configuration through JSON path expressions in the custom delegate annotation; after filling according to this rule, a target data structure that meets the requirements of the business method input parameter structure is formed.

[0034] Based on the generated target data structure, the actual data type corresponding to each input parameter position in the target data structure is extracted according to the declaration order of the business method input parameters, forming an ordered sequence of expected parameter types. The length of the expected parameter type sequence and the parameter sorting position correspond completely with the actual input parameter declaration of the business method.

[0035] Finally, the target data structure and expected parameter type sequence corresponding to the successfully matched node are obtained. The target data structure clarifies the complete transformation result from process context variables to business method input parameters, and the expected parameter type sequence clarifies the order and type requirements of the parameter types that should be passed to the business method when the process engine runs.

[0036] It should be further explained that a consistency analysis is performed between the expected parameter type sequence and the actual parameter type sequence of the corresponding method in the successfully matched method registration set, generating a matching analysis report. The specific process is as follows: For each association and binding relationship in the set of relationships corresponding to successfully matched nodes, the actual parameter type sequence corresponding to the method identifier is extracted from the method registration set according to the method identifier. The actual parameter type sequence is then compared with the expected parameter type sequence derived above, strictly following the declaration order of the business method input parameters, and a position-by-position consistency comparison analysis is performed.

[0037] Consistency comparison analysis includes three types of judgment logic: The first type is structural consistency judgment. If the nesting level of the data structure or the organization of attributes at a certain position in the expected parameter type sequence cannot correspond to the structural requirements of the corresponding position in the actual parameter type sequence, including but not limited to the expected input of a single composite object but the actual parameter is declared as a collection type, the expected input of a required attribute field has no corresponding definition in the actual parameter object, and the expected input of a number of parameters does not match the actual parameter declaration number, then the node is determined to be a structural inconsistency item, and the node identifier, method identifier, inconsistent parameter position, and specific abnormal reason are recorded synchronously. The second category is type compatibility determination: this is based on the safe assignment rules of the Java type system. The expected parameter type generated from the process variables is considered the source type, and the parameter type declared in the business method is considered the target type. If the target type is the same as the source type, or the target type is the parent class / interface of the source type (i.e., it satisfies the condition `target type.isAssignableFrom(source type)`), then it is considered type compatible. Conversely, if the expected parameter type cannot be safely converted to the declared parameter type using standard type conversion rules—for example, expected to be `java.lang.String` but declared as `java.lang.Integer`, or expected to be the parent class `java.lang.Object` but declared as the subclass `com.example.User` with no factory method to support the conversion—then the node is determined to be a type incompatible item, and the node identifier, method identifier, incompatible parameter location, and specific exception reason are recorded synchronously. The third category is for items with missing identifiers. The set of items with missing identifiers obtained from the previous matching process can be used directly without repeated verification.

[0038] The above three types of anomalies are summarized and organized to generate a structured matching analysis report. Each anomaly record in the report fully includes: anomaly type, unique identifier of the process definition, unique identifier of the service node, node location information in the process topology, identifier of the method to be called, and a detailed description of the anomaly cause.

[0039] S4: Read the matching analysis report. When at least one of the following items is recorded: missing identifier, inconsistent structure, or incompatible type, trigger the Spring container startup initialization failure handling and terminate the application context loading. When none of the items are recorded, generate the runtime dynamic construction instructions for the service execution component based on the correspondence between the method identifiers in the method registration set and the process node identifiers. It should be noted that when reading the matching analysis report, if at least one of the following is recorded: a missing item, a structural inconsistency item, or a type incompatibility item, the Spring container startup initialization failure handling is triggered, terminating the application context loading. The specific process is as follows: In the middle and late stages of the Spring container context refresh phase, the complete matching analysis report is read, and each of the three types of exceptions in the report is checked: the first type checks whether there are records in the set of missing items; the second type checks whether there are records in the set of structurally inconsistent items; and the third type checks whether there are records in the set of type-incompatible items.

[0040] If at least one record exists in any of the following categories—missing identifier, inconsistent structure, or incompatible type—a blocking error is determined to exist in the integration of the current process definition and business code, triggering the Spring container startup initialization failure handling mechanism: An uncaught runtime exception is immediately thrown, and the exception information fully outputs the detailed content of the matching analysis report, including the exception type of all exception records, the unique identifier of the process definition to which it belongs, the unique identifier of the service node, the node's position information in the process topology, the identifier of the method to be called, and a detailed description of the exception cause; simultaneously, the matching analysis report is synchronously written to the application startup log, facilitating developers to quickly locate and correct the problem; throwing this exception will directly terminate the subsequent loading steps of the Spring application context, causing the entire Spring Boot application to fail to start, ensuring that defective process configurations are not deployed to the runtime environment.

[0041] It should be further explained that when there are no records for any item, the construction instructions for dynamically constructing the service execution component at runtime are generated based on the correspondence between the method identifiers and process node identifiers in the method registration set. The specific process is as follows: If there are no records for any of the three types of anomalies in the matching analysis report—missing identifiers, inconsistent structures, and incompatible types—then it is determined that all service node call expressions in the current process definition file and the business methods in the Spring container have passed the verification in terms of identifier matching, structural consistency, and type compatibility.

[0042] At this point, the set of relationships corresponding to successfully matched nodes is traversed, and for each association and binding relationship, the corresponding node identifier and method identifier are extracted; based on the method identifier, the parameter type sequence and variable mapping relationship corresponding to the method identifier are extracted from the method registration set; combined with the service node type corresponding to the node identifier and the node's position information in the process topology, the construction instructions for the runtime dynamic construction service execution component for that service node are generated.

[0043] The constructor instruction contains the following core elements: First, the metadata of dynamic components, including the component's unique identifier, the identifier of the process definition to which it belongs, and the identifier of the corresponding service node; Second, the SpringBean reference information that needs to be injected, including the call identifier of the target bean and the identifier of the method to be called; Thirdly, data transformation rule information, including the variable mapping relationship between method inputs and process variables, and parameter type sequence; Fourthly, there are requirements for transaction and context binding, including binding rules with Spring's declarative transaction manager and binding rules with the request context propagation mechanism.

[0044] S5: Execute the construction instructions to generate the process engine service execution component, bind it with the Spring declarative transaction manager and request context propagation mechanism, and then mount it to the process engine runtime environment to complete the extended integration.

[0045] It should be noted that the specific process of executing the construction instructions to generate the process engine service execution component is as follows: Before the Spring container starts up or during the workflow engine initialization phase, the structured constructor instruction set is read, each constructor instruction in the set is traversed, and based on the dynamic component meta-information in the instruction, a service execution component instance that conforms to the workflow engine service task execution interface specification is directly constructed in memory using dynamic proxy technology or bytecode generation technology.

[0046] During the construction process, a reference binding to the target business bean is established within the component based on the SpringBean reference information in the construction instructions. Based on the data transformation rule information in the construction instructions, data transformation and filling logic based on variable mapping relationships and parameter type sequences is built into the component. This logic can automatically convert the process context data passed in by the process engine into the target data structure expected by the business method at runtime, and fill it into the corresponding input parameter positions in the order of parameter type sequence.

[0047] The generated service execution component instance fully complies with the standard execution interface requirements of the workflow engine externally, and internally encapsulates complete business Bean call logic and data transformation logic.

[0048] It should be further explained that after binding it with Spring's declarative transaction manager and request context propagation mechanism, it is mounted to the process engine runtime environment to complete the extended integration. The specific process is as follows: For each service execution component instance generated, perform two binding operations: The first step is binding with Spring's declarative transaction manager. Specifically, when generating the bytecode of the service execution component, it implements a specific business delegation interface. Spring's ProxyFactory then uses this interface as a point of entry to create an AOP proxy object, dynamically registering the corresponding BeanDefinition to the current Spring container. Because the proxy object wraps the original component instance, its business logic call entry point will be fully processed through the Spring transaction interceptor chain. This ensures that during the execution of business logic at process nodes, all transactional operations, such as database operations and message queue operations, are within a unified Spring transaction context, guaranteeing data consistency and operational atomicity. The second aspect is binding with the request context propagation mechanism. The request context passing logic is built into the service execution component instance to ensure that even in the asynchronous execution thread of the process engine, the security authentication information, session identifier, locale and other context data related to the original request can be correctly obtained, avoiding the context loss problem caused by thread switching.

[0049] After completing the two binding operations, the service execution component instance is registered in the runtime configuration cache of the process engine, and a one-to-one association mapping is established with the corresponding process definition identifier and service node identifier in the construction instruction. At this point, in the subsequent process instance execution process, the process engine will directly call these mounted dynamic service execution components without having to parse the original text call expression and perform reflection lookup, thus achieving smooth integration and stable operation of the extended module.

[0050] As attached Figure 4The Spring Boot extension system based on the process engine shown includes an information acquisition module, a parsing and building module, an association and verification module, an instruction generation module, and a component mounting module. Information Acquisition Module: Used during the startup phase of a Spring Boot application to acquire information about business methods annotated with custom delegates in the Spring container, and to read service node call expressions from pre-defined process source files in the project resource directory; The parsing and construction module is used to parse the business method information, extract the method identifier, parameter type and variable mapping relationship to construct the method registration set, and parse the service node call expression to extract the node identifier and call target to construct the node call set. Association verification module: It is used to associate and match the calling target of the node call set with the method identifier of the method registration set, deduce the expected parameter type sequence for the successfully matched node, perform consistency calculation with the actual parameter type sequence, and generate a matching analysis report containing missing identifier items, structural inconsistencies, and type incompatibilities. Instruction generation module: used to read the matching analysis report, trigger Spring container startup initialization failure handling when any type of exception item has a record, and generate runtime dynamic construction instructions for service execution components when no exception item has a record; Component mounting module: Used to execute the construction instructions to generate the process engine service execution component, bind it with Spring declarative transaction manager and request context propagation mechanism, and mount it to the process engine runtime environment to complete the extension integration.

[0051] An electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor; It should be specifically noted that the electronic device includes at least one processor, at least one memory communicatively connected to the processor, and a communication bus; wherein, the processor and the memory communicate and interact with each other through the communication bus; the memory stores a computer program that can be executed by the processor, and when the processor calls the computer program, it can execute all the steps of the aforementioned SpringBoot extension method based on the process engine; It should be further explained that the electronic device also includes an input device and an output device. The input device is connected to the processor and is used to receive user-inputted custom parameters such as the process definition directory path, custom delegate annotation configuration, type conversion rules, and verification trigger timing. The output device is connected to the processor and is used to display visualized data such as matching analysis reports, application startup verification results, process node integration status, and anomaly location information. The electronic device can be an application server deployed with Spring Boot applications, a local development terminal of an enterprise-level development environment, a business service node of a microservice cluster, a cloud server cluster, or an embedded service terminal. This embodiment does not limit the specific form of the electronic device, as long as it can complete the process engine extension operation described in this embodiment.

[0052] A computer storage medium storing a computer program, wherein when executed by a processor, the computer program implements all the steps of the aforementioned SpringBoot extension method based on a process engine. It should be specifically noted that the computer-readable storage medium is a non-transitory storage medium with a physical storage carrier; when the computer program is executed by the processor, it can fully implement the entire process of the aforementioned Spring Boot extension method based on the process engine.

[0053] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A Spring Boot extension method based on a process engine, characterized in that: include: S1: Obtain information about business methods annotated with custom delegates in the Spring container, and read the service node call expressions in the pre-defined process source files in the project resource directory; S2: Parse the business method information, extract the method identifier, parameter type and variable mapping relationship, and construct a method registration set; Parse the service node call expression, extract the node identifier and call target, and construct the node call set; S3: Associate and match the calling target of the node call set with the method identifier of the method registration set. For nodes that are successfully matched, based on the data output definition and variable mapping relationship of its predecessor node, perform semantic mapping on the output data of the predecessor node according to the mapping relationship, generate the target data structure and deduce the expected parameter type sequence. Perform consistency analysis between the expected parameter type sequence and the actual parameter type sequence of the corresponding method in the successfully matched method registration set, and generate a matching analysis report including missing identifiers, structural inconsistencies, and type incompatibilities. S4: Read the matching analysis report. When at least one of the following is recorded: missing item, inconsistent structure item, or incompatible type item, trigger the Spring container startup initialization failure handling and terminate the application context loading. When there are no records for any item, the construction instructions for dynamically constructing the service execution component at runtime are generated based on the correspondence between the method identifier and the process node identifier in the method registration set. S5: Execute the construction instructions to generate the process engine service execution component, bind it with the Spring declarative transaction manager and request context propagation mechanism, and then mount it to the process engine runtime environment to complete the extended integration.

2. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The method for obtaining business method information and service node call expressions in S1 is as follows: Business method information: A custom delegate annotation is pre-defined, with its scope limited to business classes or business methods managed by the Spring container; the business method scanning timing is set to the Spring Boot application startup process, after the Spring container has completed the instantiation, dependency injection, and initialization of all singleton business classes, and before the application context has been finally refreshed; it iterates through the singleton business classes that have been initialized within the Spring container, filters the target business methods annotated with the custom delegate annotation according to preset rules, and extracts the unique method identifier, parameter type sequence arranged in declaration order, and variable mapping relationship of the target business methods to complete the acquisition of business method information; Service node invocation expression: Set a pre-defined directory for process definition source files in the classpath resource directory of the Spring Boot project; at the same execution time as the business method scan, load the process definition source files that meet the format requirements in the directory and complete the validity verification; The system performs structured parsing on valid files, traverses service task nodes, execution listener nodes, and task listener nodes within the file, extracts and standardizes the call expressions within the nodes, extracts the target business class call identifier and the name of the business method to be called, and binds and encapsulates them with node ownership information and topology location information to complete the acquisition of service node call expression information.

3. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The method registration set and node call set in S2 are constructed in the following way: Method registration set: The validity of business method information is validated. For business method information that passes the validity validation, the parameter type sequence and variable mapping relationship are associated and encapsulated using the method identifier as the index, and the method registration set is constructed by summarizing them. Node call set: The binding information of the service node call expression is validated. For the information that passes the validation, the node identifier, which is composed of the process definition unique identifier and the node unique identifier, is used as the storage index. The node identifier is associated with the call target containing the target business class call identifier and the name of the business method to be called and encapsulated into a node call entry. The node call set is then built by summarizing the information.

4. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The association matching method is as follows: traverse all node call entries in the node call set, extract the call target of each entry, and combine the target business class call identifier with the name of the business method to be called to form the search query key; Based on the query key, a search and matching process is performed in the method registration set. Nodes without matching method identifiers are identified as missing identifiers and their relevant information is recorded synchronously. For nodes that are successfully matched, a one-to-one correspondence between the node identifier and the method identifier is established.

5. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The expected parameter type sequence is obtained as follows: For a successfully matched node, all its direct predecessor nodes are located based on the process topology, and the valid data source is determined according to preset rules and the predecessor node data output definition is obtained; the variable mapping relationship of the method corresponding to the node is extracted, and the predecessor node output data is mapped to the corresponding input parameter position of the business method based on the mapping relationship to generate a target data structure that meets the requirements of the business method input parameter structure; according to the declaration order of the business method input parameters, the actual type of the data corresponding to each input parameter position in the target data structure is extracted to form an ordered expected parameter type sequence.

6. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The matching analysis report is obtained as follows: For nodes that are successfully matched, their expected parameter type sequence and the actual parameter type sequence of the corresponding method are compared and analyzed position by position according to the order of the input parameters of the business method; according to the preset rules, structural inconsistencies and type incompatibilities are determined and recorded respectively, and the missing items are marked by continuing the recording results of the association matching step; the three types of abnormal items are summarized to generate a matching analysis report.

7. The Spring Boot extension method based on a process engine according to claim 1, characterized in that: The method for generating the construction instruction is as follows: when there are no records for any of the three types of anomalies in the matching analysis report, traverse all successfully matched node associations, extract the corresponding node identifier, method identifier, parameter type sequence, variable mapping relationship, node type and topology location information, and generate the service execution component construction instruction for the corresponding service node. The construction instruction includes dynamic component meta-information, target business class reference information, data conversion rule information, and transaction and context binding requirements.

8. A Spring Boot extension system based on a process engine, characterized by: It includes an information acquisition module, a parsing and construction module, an association verification module, an instruction generation module, and a component mounting module; Information Acquisition Module: Used to acquire information about business methods annotated with custom delegates in the Spring container, and to read service node call expressions from the pre-defined process definition source files in the project resource directory; Parsing and building module: used to parse the business method information to build a method registration set, and to parse the service node invocation expression to build a node invocation set; Association verification module: used to associate and match the calling target with the method identifier, deduce the expected parameter type sequence for successfully matched nodes, perform consistency calculation with the actual parameter type sequence, and generate a matching analysis report; Instruction generation module: Used to read the matching analysis report. When any type of exception item is recorded, it triggers the Spring container startup initialization failure handling. When there are no records, it generates the construction instructions for dynamically constructing the service execution component at runtime. Component mounting module: Used to execute the construction instructions to generate service execution components, and then mount them to the process engine runtime environment after binding with Spring declarative transaction manager and request context propagation mechanism.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the Spring Boot extension method based on the process engine as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the Spring Boot extension method based on the process engine as described in any one of claims 1 to 7.

Images