Dynamic expansion service node management method based on Camuda process engine

Abstract

The invention discloses a method for managing service nodes capable of being dynamically expanded based on a Camuda process engine, which belongs to the technical field of electric digital data processing and comprises the following steps of: uniformly configuring service process nodes into a pointing proxy delegation class; querying an external mapping table based on the execution context to obtain a business logic unit identifier; obtaining metadata from a logic registration center according to the identifier, and dynamically loading and instantiating a business logic implementation class through a sandbox class loader; driving service logic execution through a security context object of a white list only exposure method; and recording a full-link audit log. According to the method, structural decoupling of process definition and service logic is realized, so that the process definition does not need to be modified during service change, and dynamic replacement and gray release are supported; through sandbox isolation and security agent, isolated operation of dynamic codes and security and stability of an engine are ensured; and in combination with an audit tracking and fusing mechanism, the observability, the reliability and the operation and maintenance efficiency of the system are improved.

Description

Technical Field

[0001] This invention relates to the technical field of electronic digital data processing, and more particularly to a dynamically scalable business node management method based on the Camunda process engine. Background Technology

[0002] In the ongoing advancement of enterprise-level business process automation and digital transformation, lightweight open-source workflow engines, represented by Camunda, are widely used in multiple key industry sectors such as finance, manufacturing, and government due to their excellent embeddability. Workflow engines can abstract complex business rules into visual process models and drive business nodes to flow according to preset logic through standardized execution mechanisms, thereby achieving standardized, traceable, and efficient collaboration of business processes.

[0003] In the process engine, business logic is typically injected into specific activity nodes within the process definition as Java delegate classes. The engine dynamically invokes these delegates at runtime to perform core operations such as data validation, external system interaction, or state changes. Developers must strictly adhere to the interface specifications provided by Camunda when writing business implementation classes and explicitly specify the fully qualified name of the implementation class through attributes in the corresponding BPMN 2.0 XML definition file. This approach offers significant advantages in early application scenarios: it ensures strong consistency between the process execution path and business logic, simplifies the development and debugging process, and provides compile-time security based on Java's static type system. Correspondingly, once the process definition is deployed, it is solidified by the engine as an immutable version entity. All process instances launched based on this version are strictly bound to the process structure and node implementation at the time of deployment throughout their lifecycle, thus ensuring the deterministic execution and transaction integrity of long-cycle business processes.

[0004] However, with the increasing demand for business agility, the hard-coded binding mechanism has exposed its inherent limitations. Any modification to the business logic of a single node requires recompiling, packaging, and deploying the entire process definition. Because Camunda adopts an immutable strategy for deployed process definitions, new versions cannot be automatically applied to running older process instances. This makes it difficult to seamlessly cover all instances with defect fixes or feature upgrades, leading to the introduction of a large amount of conditional compatibility logic and increasing the complexity and risk of operations and maintenance. Summary of the Invention

[0005] This invention overcomes the shortcomings of existing technologies and provides a dynamically scalable business node management method based on the Camunda process engine.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a dynamically scalable business node management method based on the Camunda process engine, comprising:

[0007] S1. Configure the business nodes in the business process so that they point to a unified proxy class during execution, serving as the entry point for all dynamically extended logic.

[0008] S2. When the proxy class is called by the process engine, based on the process definition identifier, version, and node identifier in the current execution context, the mapping table in the external storage is queried to obtain the identifier of the business logic unit that should be executed. The mapping table is independent of the process definition storage and is used to establish the binding relationship between process nodes and specific business logic identifiers under specific versions and tenants. The enabling and disabling of the mapping is controlled by the status field.

[0009] S3. Based on the business logic unit identifier, obtain the logic unit metadata from the logic registry center, and use the dependent resources declared in the logic unit metadata to dynamically load and instantiate the target business logic implementation class through the sandbox class loader.

[0010] S4. Pass the encapsulated security context object to the standardized execution interface of the instantiated object to drive the execution of business logic; the security context object proxies and encapsulates the native engine context, exposing only whitelisted methods;

[0011] S5. Record audit logs containing full-process tracking identifiers before and after the execution of business logic.

[0012] In a preferred embodiment of the present invention, querying the external mapping table to obtain the business logic unit identifier specifically includes:

[0013] Parse and extract the process definition key, process definition version, activity node identifier, and tenant identifier from the execution context;

[0014] Using the process definition key, process definition version, activity node identifier, and tenant identifier as query conditions, query the records in the external mapping table that are active.

[0015] The process definition version field in the external mapping table supports storing specific version numbers or node identifiers;

[0016] When querying, prioritize matching records with identical process definition versions. If no such record is found, match records whose process definition version is the node identifier.

[0017] In a preferred embodiment of the present invention, before dynamically loading and instantiating the target business logic implementation class through a sandbox class loader based on the logical unit metadata, the method further includes:

[0018] The metadata of the logical unit is subjected to security verification, and the security verification includes at least the following:

[0019] Verify whether the current time is within the effective time window of the metadata declaration;

[0020] The digital signature in the metadata is verified using a pre-set public key to verify the integrity and origin of the logical unit JAR package;

[0021] Based on bytecode security scanning, the implementation classes in the logical unit JAR package are detected to prevent code containing preset dangerous operations from being loaded.

[0022] In a preferred embodiment of the present invention, the step of dynamically loading and instantiating the target business logic implementation class through a sandbox class loader specifically includes:

[0023] Based on the list of dependent resources in the metadata of the logical unit, a dedicated sandbox class loader instance is created; the sandbox class loader is configured to load classes only from specified resource locations and is granted a preset minimum set of execution permissions;

[0024] The business implementation class specified in the metadata is loaded through the sandbox class loader;

[0025] An object instance is created by invoking the constructor of the business implementation class using reflection, and then converted into a predefined standardized execution interface type.

[0026] In a preferred embodiment of the present invention, the security context object encapsulates the native engine context object using a proxy pattern, specifically including:

[0027] The security context object holds a reference to the original execution context object;

[0028] The method for exposing the security context object is a whitelist-filtered subset, which includes only one or more of the following: obtaining process variables, setting process variables, obtaining process instance identifiers, obtaining activity node identifiers, obtaining tenant identifiers, and obtaining business keys.

[0029] Method calls to the security context object are intercepted and inspected, and the call is delegated to the original execution context object only if the calling method is within the whitelist.

[0030] In a preferred embodiment of the present invention, before the driver runs the business logic, it further includes:

[0031] The standardized adapter interface implementation managed by the system is injected into the security context object or passed as a parameter;

[0032] All access operations to external resources in the business logic implementation code must be completed through the methods provided by the standardized adapter interface.

[0033] In a preferred embodiment of the present invention, an audit log containing a full-process tracking identifier is recorded, specifically including:

[0034] After obtaining the business logic unit identifier, a globally unique execution trace identifier is generated;

[0035] Record the execution start audit log, the contents of which shall include at least the execution trace identifier, process instance identifier, process definition key and version, activity node identifier, tenant identifier, logical unit identifier, and timestamp;

[0036] After the business logic is completed, an execution end audit log is recorded, which includes at least the execution tracking identifier, end timestamp, execution time, and execution result status.

[0037] In a preferred embodiment of the present invention, a circuit breaker mechanism is further included:

[0038] Maintain a failure counter with the logical unit identifier as the key;

[0039] When the number of execution failures of a certain logical unit exceeds a threshold within a preset time window, an instruction is automatically sent to the data source managing the external mapping table to update the status of all records in the mapping table that point to the identifier of the logical unit and are active to disabled or isolated.

[0040] In a preferred embodiment of the present invention, a multi-level caching strategy is also included:

[0041] The system implements a multi-level cache, including thread-local cache, application-process heap cache, and distributed cache, to cache one or more of the mapping relationships queried from the external mapping table and the logical unit metadata obtained from the logical registry center.

[0042] When the records in the external mapping table or the metadata of the logical unit are updated, a cache invalidation event is published to clear the relevant cached items.

[0043] In a preferred embodiment of the present invention, the sandbox class loader is created based on the tenant identifier, so that the business logic implementation classes of different tenants run in mutually isolated class loading spaces.

[0044] This invention addresses the shortcomings of the prior art and has the following beneficial effects:

[0045] (1) This invention maintains the dynamic binding relationship between nodes and logical units by uniformly configuring business nodes in the process model to point to the proxy class and establishing an independently stored external mapping table. This enables the structural decoupling of process definition and business implementation, keeps the topology of the process model highly stable, and changes in business logic, gray releases, or A / B tests do not require modification or redeployment of the BPMN file. Only updating the external mapping table configuration is required for the changes to take effect. In contrast to the prior art where the class name of the service task is hard-coded in the process definition XML, which requires any change in business logic to go through the complete process definition version release process, this invention realizes the independent evolution of business logic and process structure. This further enables complex business processes to cope with rapidly changing business needs in a modular and configurable manner, greatly improving the agility of business response.

[0046] (2) This invention designs a dynamic loading security chain consisting of a sandbox class loader, bytecode security scanning, and logical unit metadata verification. It then combines this with a proxy security context object that exposes only whitelisted methods to drive business logic execution, creating a runtime-isolated and permission-controlled security sandbox for each dynamically loaded business code. Compared to existing dynamic delegation mechanisms that execute arbitrary code directly in the engine context, this invention not only eliminates dependency conflicts through class loading isolation but also prevents unauthorized read / write or jump operations on the core state of the process engine through strict access control, further ensuring the stability of the process engine and the consistency of process data.

[0047] (3) This invention deeply integrates observability and reliability assurance into the dynamically expanding core execution chain by injecting audit logs containing global tracing identifiers into critical execution nodes and constructing an automatic circuit breaker mechanism based on failure counting. Each business logic executed through dynamic mapping has complete end-to-end tracing capabilities and automatic fault isolation capabilities. Compared with traditional dynamic loading frameworks that often only focus on loading itself and lack production-level operation and maintenance support, this invention enables operation and maintenance personnel to clearly monitor and automatically circuit break when specific logical units fail frequently, preventing the problem from spreading. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a flowchart of a preferred embodiment of the present invention;

[0050] Figure 2 This is a timing diagram of step S3, dynamic loading, in a preferred embodiment of the present invention.

[0051] Figure 3 This is a timing diagram of the safe execution of step S4 in a preferred embodiment of the present invention;

[0052] Figure 4 This is a timing diagram for the observability guarantee of step S5 in a preferred embodiment of the present invention. Detailed Implementation

[0053] 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.

[0054] Application Overview:

[0055] This invention targets enterprise-level application systems built on the Camunda process engine, in scenarios where business nodes require high-frequency, independent, uninterrupted updates and canary releases. Existing technologies hard-bind the logical implementation of process nodes with the process definition at compile time through fully qualified class names, confusing the nodes that serve as topological location identifiers in the process model with the business logic implementation that serves as the carrier of specific behaviors, and directly anchoring the two at the physical code level. This forces the version management of business processes to be deeply coupled with the version evolution of business functions, and any change in node logic is equivalent to a redefinition of the process structure.

[0056] The fundamental reason why existing technologies struggle to dynamically scale business nodes lies in the fact that the Camunda engine ensures long-lived transactions through static binding and immutable process definition versions. While simply employing conventional techniques like reflection to dynamically load class names or external configuration mappings superficially decouples class names, it fails to address deeper underlying contradictions. This simple decoupling disrupts Camunda's native version management semantics, making it impossible to accurately track the specific business logic version executed by a particular process instance, thus introducing uncertainty risks. Directly replacing class implementations can lead to inconsistencies in behavior between old and new instances, especially when logic involves state changes, easily causing data inconsistencies or process interruptions. Therefore, simply layering conventional techniques not only fails to resolve the core contradictions but may also create more severe system vulnerabilities and operational pitfalls by circumventing the engine's core mechanisms.

[0057] Therefore, this invention proposes a dynamically scalable business node management method based on the Camunda process engine. By constructing a decoupling layer consisting of proxy delegation, runtime mapping, and a logic registry center between the process engine execution link and the specific business logic implementation, it solves the contradiction in the traditional model where the logic cannot be independently hot-updated due to the hard binding between the business node implementation and the process definition version, and the process instance is difficult to track. Combined with a sandboxed dynamic class loading mechanism and tenant isolation, it enables secure dynamic replacement and canary release of business node logic.

[0058] Exemplary method:

[0059] like Figure 1 As shown, a dynamically scalable business node management method based on the Camunda process engine includes the following steps:

[0060] S1. Configure the business nodes in the business process so that they point to a unified proxy class during execution, serving as the entry point for all dynamically extended logic.

[0061] S2. When the proxy class is called by the process engine, based on the process definition identifier, version, and node identifier in the current execution context, the mapping table in the external storage is queried to obtain the identifier of the business logic unit that should be executed. The mapping table is independent of the process definition storage and is used to establish the binding relationship between process nodes and specific business logic identifiers under specific versions and tenants. The enabling and disabling of the mapping is controlled by the status field.

[0062] S3. Based on the business logic unit identifier, obtain the logic unit metadata from the logic registry center, and use the dependent resources declared in the logic unit metadata to dynamically load and instantiate the target business logic implementation class through the sandbox class loader.

[0063] S4. Pass the encapsulated security context object to the standardized execution interface of the instantiated object to drive the execution of business logic; the security context object proxies and encapsulates the native engine context, exposing only whitelisted methods;

[0064] S5. Record audit logs containing full-process tracking identifiers before and after the execution of business logic.

[0065] In practical implementation, in order to achieve structural decoupling between business node logic and process definition, this method first performs the node configuration step.

[0066] Step S1 transforms the business nodes in the business process that need to support dynamic expansion from the traditional direct binding to specific implementation classes to pointing to a unified proxy entry point dedicated to logic distribution. Step S1 lays the architectural foundation for subsequent runtime mapping and dynamic loading.

[0067] In step S1, the business process of the present invention refers to an XML format file constructed in accordance with the business process model and annotation standards, which is used to describe the topology, node type and flow path of the business process in the Camunda engine.

[0068] Among them, a ServiceTask node is a model element representing an automated business activity to be executed; an activityId is a unique identifier for each activity node in the business process model, used to locate the current node position when the process instance is executed; and a UserTask node is a task node model element that requires human intervention to complete.

[0069] During the execution of a process instance, the node execution module drives the actual execution of the node based on the binding relationship between activityId and code. For ServiceTask, it is automatically triggered and executed synchronously by the engine; for UserTask, it is triggered and completed by external events.

[0070] This method also applies to UserTask. For UserTask, the dynamically bound business logic is usually applied to lifecycle listeners such as task creation, assignment, and completion.

[0071] The proxy class introduced in step S1 is a specific Java class that has been pre-developed and deployed and implements the process engine delegation interface. In this invention, its role is not to carry specific business logic, but to serve as a unified call entry point and dispatcher for all dynamically extended business logic.

[0072] In practice, before designing or deploying the process model, the process definition file is configured and modified. For each business activity node in the process that is expected to require independent changes, replacements, or canary releases, especially for business activity nodes involving business rules, the specific business implementation class is no longer directly written into its class attributes. Instead, the attribute values ​​of all such nodes are uniformly set to the fully qualified name of a pre-agreed proxy class. From the perspective of the process, the responsibility for the execution of these nodes' behaviors is delegated to this unified proxy class. At the same time, it must be ensured that each service task node has a globally unique and stable activity identifier attribute value. The activity identifier is the key index for accurately associating nodes with specific business logic at runtime in subsequent steps.

[0073] As a fundamental component of the framework of this invention, the proxy class needs to be pre-packaged and deployed to a classpath that can be loaded by the Camunda engine at runtime.

[0074] After completing the configuration steps, the first-level physical decoupling between the process structure definition and the business behavior implementation is achieved. The process definition file only contains topology information and a declaration pointing to a unified proxy, and no longer has compile-time or deployment-time binding relationships with any frequently changing specific business code. This makes the process definition itself stable, and its version iteration can be driven only by structural changes, separated from the version evolution trajectory of business logic. This invention avoids binding any volatile elements at the process definition level by uniformly pointing nodes to a fixed, neutral proxy entry point.

[0075] After configuring the business nodes to point to the unified delegate class in the process definition, when the process instance runs to that node, the process engine will call the execution method of that delegate class. At this point, the system needs to dynamically and deterministically address the specific business logic to be executed from the execution context that only knows the node location and process version information.

[0076] Step S2 is the addressing process, which connects the static process definition with the dynamic business logic.

[0077] The proxy class of this invention is the unified entry class configured in S1, which has implemented the standard proxy interface of the process engine.

[0078] When the process engine triggers its execution method, it passes in an execution context object, which encapsulates the real-time status information of the current process instance.

[0079] Several key location information items were extracted from the current execution context:

[0080] The process definition key is a globally unique business identifier specified when deploying a process definition;

[0081] The process definition version is an integer version number that the process engine automatically assigns or specifies for each deployed process definition, used to distinguish different revisions of the same process model;

[0082] The activity node identifier, activityId, is the unique identifier of the currently executing service task node in the process model.

[0083] The tenantId identifier, in a multi-tenant Camunda engine environment, is used to identify the tenant space to which the current process instance belongs.

[0084] The Activity Logic Mapping Table of this invention is a relational data table that is deployed independently of the process engine and stored in external persistent storage. It is used to maintain dynamic association rules from the process definition dimension, node dimension to business logic identifier dimension.

[0085] The specific steps of step S2 include:

[0086] Once the execution method of the proxy class is activated, it parses and extracts the aforementioned process definition key, process definition version, activity node identifier, and tenant identifier from the passed-in execution context object. The extracted four-tuple constitutes the complete coordinates for this logical addressing.

[0087] Based on these coordinates, the proxy class initiates an exact query to the external mapping table.

[0088] The mapping table contains the following fields: process definition key field, process definition version field, active node identifier field, tenant identifier field, logical unit identifier field, and status field. The query condition is to find records that exactly match the input coordinates and are active. The process definition version field is flexible; it can store either a specific version number or a special node identifier value (code).

[0089] The query logic follows the principle of precision first: first, it matches records where the process definition key, process definition version, active node identifier, and tenant identifier are all equal and the status is active; if not found, it attempts to match records where the process definition version field is the node identifier code, as a fallback solution for cases where the mapping of a specific version is missing.

[0090] This query will ultimately yield a definite logical unit identifier that is active in the current context. The logical unit identifier is a system-defined, globally unique string that serves as an abstract code for the specific business logic implementation within this system, completely replacing the fully qualified class name used directly in traditional patterns.

[0091] Step S2 constructs an externalized, configurable addressing mapping layer. This layer, driven by data, translates the static node location information in the process model into corresponding dynamic business logic identifiers at the moment of process execution. The mapping table serves as a configuration center; its records can be added, deleted, modified, and queried by operations personnel during system runtime without affecting the process definition file or restarting the application. The query parsing logic is embedded in the proxy class, ensuring accurate logical addressing based on real-time configuration for each node execution.

[0092] Step S2 enables dynamic and configurable business logic addressing. The behavior of process nodes is no longer determined by the class names hard-coded in the BPMN file, but by the real-time configuration of the external mapping table. This allows changes to the business logic of a certain node, canary releases, or A / B testing to be transformed into modifications to the status of a record in the mapping table or switching between old and new records.

[0093] like Figure 2 As shown, after obtaining the logical unit identifier through S2, step S3 needs to safely, reliably and isolatedly transform this identifier into an executable specific business logic code object, so as to realize the dynamic discovery, verification, loading and instantiation of the business logic implementation class without compromising the stability of the main application.

[0094] The logical unit identifier of this invention is the result of S2 querying the mapping table, and is a unique string key representing a specific business function version.

[0095] The logical registry is an independent core service component used to uniformly register and manage all dynamically loadable business logic units throughout their entire lifecycle. It persistently stores the metadata of each logical unit, which is structured information describing all the key attributes of a logical unit.

[0096] Each logical unit must be packaged into a separate JAR archive file, which includes not only the compiled business implementation class, but also all its declared dependency libraries.

[0097] The sandbox class loader is a special class loader used in this method to achieve runtime isolation. It creates an independent class loading space for each or each group of logical units, preventing class and dependency conflicts.

[0098] In step S3, after obtaining a valid logical unit identifier, the proxy class sends a request to the logical registry center to obtain the corresponding complete logical unit metadata.

[0099] The metadata includes the following fields:

[0100] The fully qualified name of the business implementation class, used to indicate the specific class to be loaded;

[0101] Semantic version number, used to identify the functional version of this business logic;

[0102] The tenant identifier is used for tenant-level isolation; the effective time window defines the time range during which this logical unit is allowed to be executed.

[0103] The dependency resource list is a list of one or more Uniform Resource Locators (URLs) that point to the JAR package resources that the logical unit depends on.

[0104] Digital signatures are used to verify the integrity of logical unit JAR packages and the identity of the publisher;

[0105] In addition, it may also contain other descriptive attributes such as class file hash values ​​and developer information.

[0106] Upon receiving the metadata, the proxy class does not load it immediately. Instead, it performs security checks, including: verifying whether the current system time is within the effective time window of the metadata declaration to ensure that expired or ineffective logic is not executed; and using a pre-set public key certificate to verify the digital signature in the metadata to confirm that the JAR package of the logical unit has not been tampered with since it was packaged and that its source is trustworthy.

[0107] After passing the basic verification, a deeper bytecode security scan is required, which is accomplished through a bytecode manipulation and analysis framework.

[0108] The system retrieves the main JAR package of the logical unit from the location specified in the dependency resource list and scans the implementation classes within it; it detects and prevents code containing potentially dangerous operations from being loaded and executed.

[0109] Dangerous operations include, but are not limited to: attempting to call the system exit method to terminate the virtual machine; attempting to modify or bypass the security policy of the security manager; attempting to access internal application interfaces or perform low-level memory operations using unsafe operation classes; declaring native methods in an attempt to load uncontrolled dynamic link libraries; and attempting to illegally obtain access permissions to private fields or methods through reflection.

[0110] At the same time, the scanning process will also perform simple taint analysis to check whether string constants or obvious variable assignments contain sensitive keywords that have not been masked, in order to prevent business logic from accidentally leaking confidential information such as passwords and tokens.

[0111] Once all security checks have passed successfully, the actual dynamic class loading phase begins.

[0112] The proxy class creates a new, dedicated sandbox class loader instance based on the list of dependent resources in the metadata; the loader is designed to load classes only from JAR files pointed to by the list of Uniform Resource Locators specified during its initialization.

[0113] The key feature of the loaded class is that it overrides the default permission acquisition method and constructs a minimal security policy that only includes the necessary running permissions.

[0114] For example, the loaded class is granted the minimum permissions required to run, such as the permission to access members declared within its own package and the permission to suppress access checks when making reflection calls, but high-risk permissions that may endanger host security or affect the stability of the main application, such as accessing the file system, initiating network connections, and reading system properties, are explicitly denied.

[0115] Through the sandbox class loader, the proxy class calls its loading class method, passing in the fully qualified name of the business implementation class specified in the metadata, thereby loading the target class into the Java Virtual Machine.

[0116] Since each logical unit or each tenant may use an independent sandbox class loader, even if different logical units depend on different versions of the same third-party library, they will be loaded into their own independent class namespaces, completely isolated from each other, fundamentally eliminating runtime errors such as class definitions not found or methods not found caused by dependency version conflicts.

[0117] After the class is successfully loaded, the proxy class calls the class's parameterless public constructor through the reflection application programming interface to create a specific business logic object instance. Then, this instance is forcibly cast to a predefined standardized execution interface type. The interface is the contract between this framework and all dynamic business logic implementations, and contains only one execution method. The type casting operation ensures that business logic can be called in a unified and type-safe manner in the future, and also constrains the business implementation class to follow the framework specifications.

[0118] In step S3, the inputs are identifiers representing business intent and metadata of external configuration, and the output is a compliant object that has undergone multiple security checks and runs in an isolated sandbox. The entire process is designed to be pluggable. Step S3 realizes the dynamic loading and secure isolation of business logic. The deployment and update of business functions no longer require restarting the main application or process engine. Simply publish the new logic unit JAR package to the resource repository and complete the metadata registration in the logic registry center, and it can be discovered and used by the running system.

[0119] Because of the sandbox isolation mechanism, code defects or malicious operations within a logical unit are strictly controlled within its own loader, preventing them from interfering with the normal operation of the main application or other logical units, thus greatly improving the overall fault tolerance and security of the system. The dependency isolation mechanism solves the common dependency geography problem encountered by enterprise applications when integrating business components from multiple teams and vendors, allowing different components to use their own required and potentially incompatible versions of third-party libraries.

[0120] like Figure 3As shown, after dynamically loading and instantiating the business logic object through step S3, step S4 needs to drive the object to execute business logic in a safe and controllable manner, while ensuring that its operation process is isolated from the core state of the underlying process engine, so as to avoid any potential risks to the stability of the engine and the consistency of process data.

[0121] Step S4 constructs a controlled runtime environment that enables dynamically loaded business logic to access the necessary process context and complete calculations within strictly defined boundaries.

[0122] The security context object is a core proxy object constructed by the framework of this invention. It encapsulates a reference to the execution context object of the original process engine, but exposes a set of strictly limited and security-checked methods to the outside world through the proxy pattern.

[0123] The standardized execution interface is a unified contract interface that all dynamic business logic implementation classes must implement. It typically defines only one execution method, with the security context object as the only parameter.

[0124] The adapter interface is a set of standardized interfaces provided by the framework of this invention for accessing external resources, such as calling HTTP services, database operations, or message queues. The specific implementation is uniformly managed by the framework to ensure the observability, flexibility, and security of resource access.

[0125] In step S4, after the proxy class obtains the business logic object instance that has been transformed into a standard interface type, it will not directly pass the original, powerful process engine execution context object to the business logic instance. This is because it would grant the business logic code excessive privileges, allowing it to perform arbitrary operations through the rich application interfaces provided by the engine, such as arbitrarily jumping to process nodes, tampering with core instance data, or accessing the engine's internal state, thus posing a serious security and stability risk.

[0126] The proxy class creates a new security context object instance; the security context object internally has a weak or protected reference to the original execution context object, but all its externally exposed methods are proxy methods.

[0127] The security context object follows the principle of least privilege, providing only a subset of methods that have been strictly whitelisted. This subset of methods contains only the most basic operations necessary for the execution of business logic, such as: retrieving process variable values ​​by variable names; setting process variables by variable names and values; retrieving the unique identifier of the current process instance; retrieving the identifier of the currently executing active node; retrieving the current tenant identifier; and retrieving the business key.

[0128] All other methods that exist in the original execution context object, especially those that can change the process topology, control flow jumps, manage process transactions, or access the engine's internal configuration, are hidden or explicitly prohibited by the security context object.

[0129] In terms of implementation, this can be accomplished through dynamic proxy or static proxy patterns. In the proxy logic, each method call is intercepted and checked. Only when the method signature is within the predefined whitelist is the call delegated to the original object for execution; otherwise, a security exception is thrown or the call is ignored.

[0130] Before calling the execution method of the business logic instance, the proxy class will also inject the standardized adapter interface implementation managed by the system into the security context object, or pass it as one of the parameters to the business logic.

[0131] All calls to external systems, databases, caches, message brokers, or third-party services in the business logic code are not allowed to use the native client library directly, but must be completed through the methods provided by this adapter interface.

[0132] For example, if business logic requires calling a remote HTTP interface, you cannot directly instantiate an HTTP client; instead, you should call a method like adapter.callHttpService(String serviceName, Object request).

[0133] The framework's adapter implementation integrates capabilities such as connection pool management, timeout control, automatic retries, circuit breaking and degradation, unified monitoring, and logging. This not only unifies resource access patterns and improves system observability, but more importantly, it decouples business logic from specific external technical implementation details. Furthermore, the framework can implement global security policies through the adapter layer, further constraining the behavioral boundaries of dynamic code.

[0134] After completing the above preparations, the delegate class formally calls the execution method of the business logic instance, passing the security context object as a parameter. The business logic implementation code, within its method body, interacts with the workflow engine in a restricted manner through the security context object; for example, it reads the form data passed from the previous step, performs calculations, and writes the approval result into workflow variables.

[0135] Meanwhile, through the adapter interface provided by the security context object, external services can be securely invoked to obtain risk control scores or send notification messages. The entire execution process is strictly confined within the framework's pre-defined security sandbox.

[0136] Step S4 constructs a two-layer isolated secure execution sandbox; the first layer of isolation is engine access isolation implemented through security context objects, which separates dynamic business logic from sensitive engine kernel operations, leaving only a few data channels; the second layer of isolation is external resource access isolation implemented through adapter interfaces, which separates business logic from the complex external environment. All external interactions must pass through the framework's unified and hardened gateway, achieving deep security control and behavioral consistency in the business logic execution process.

[0137] After successfully driving the business logic to execute within the security sandbox via step S4, the final challenge is to ensure the entire dynamic scaling process has production-grade observability, reliability, and performance. Step S5 addresses these challenges by building a monitoring, assurance, and optimization system covering the entire execution lifecycle.

[0138] Step S5 must not only clearly record who executed what logic, when, and where, and the result, but also automatically circuit breakers to isolate risks when exceptions occur, and ensure that the performance overhead of dynamic addressing and loading is controllable through an efficient caching mechanism. This makes the entire dynamic expansion mechanism highly flexible while also being stable, auditable, and high-performance.

[0139] The audit log of this invention is a structured event information recorded by the system in a uniform format, which is intended to fully describe the end-to-end process of a business node execution.

[0140] Implementing a circuit breaker mechanism is an automated fault protection strategy. When a logical unit fails continuously within a short period of time and reaches a threshold, the system automatically disables it temporarily to prevent the fault from spreading.

[0141] Multi-level caching strategies are hierarchical data caching solutions designed to address performance bottlenecks that may be caused by frequent queries to external data sources.

[0142] The implementation of step S5 runs through the entire execution chain of the proxy class. It is not an independent subsequent step, but a kind of integrated guarantee layer.

[0143] After successfully obtaining the logical unit identifier in step S2 and before loading begins in step S3.

[0144] At this point, the system will generate a globally unique execution trace identifier, which is a hash of the process instance identifier, the current node identifier, and the timestamp, ensuring that this specific node execution can be uniquely identified throughout the distributed system.

[0145] After generating the execution trace identifier, the system immediately records an execution start audit log to solidify the initial execution context and serve as the starting point for audit trails. The log includes at least the following fields: execution trace identifier, process instance identifier, process definition key and version, activity node identifier, tenant identifier, logical unit identifier and version obtained from the query, current timestamp, and execution thread information.

[0146] After the business logic is completed in step S4, whether it returns successfully or throws an exception, the system will immediately record an execution completion audit log.

[0147] For successful execution, the log includes: execution trace identifier, end timestamp, total execution time, and possible result summary.

[0148] For abnormal situations, the log should record the type of the exception, the exception message after de-identification, the exception stack trace fingerprint, and mark the execution result as a failure.

[0149] These two corresponding logs, linked by execution tracking identifiers, constitute a complete digital archive of a business node execution.

[0150] All audit logs are written in real time to local media such as log files or standard output, and simultaneously sent to a centralized log aggregation platform in an asynchronous, non-blocking manner for subsequent real-time monitoring, historical queries, and big data analysis.

[0151] The triggering and operation of the circuit breaker mechanism depends on the aforementioned exception logs.

[0152] The system maintains a sliding time window counter with the logical unit identifier combined with the tenant identifier as the key; whenever the execution of a logical unit is recorded as a failure, the value of its corresponding counter is incremented.

[0153] If the number of failures of a certain logic unit exceeds the set threshold within a preset time window, the circuit breaker mechanism will automatically take effect.

[0154] When the circuit breaker mechanism takes effect, it sends a command to the external data source managing the mapping table, temporarily updating the status of all records in the mapping table that point to the problematic logical unit identifier and are currently active to disabled or isolated. Simultaneously, the system sends a notification to operations and maintenance personnel through the integrated alarm channel, indicating which logical unit has been circuit-broken and the reason for the circuit breaker failure.

[0155] Circuit breaking is designed to effectively prevent the risk of a large number of process instances being blocked or failing due to a bug in a logical unit or a failure of a dependent service. It achieves automatic fault isolation and ensures the overall availability of the system.

[0156] To support the frequent query and load operations in S2 and S3 without introducing unacceptable performance latency, this invention implements a multi-level caching strategy.

[0157] The multi-level caching strategy consists of three layers:

[0158] The first level is thread-local caching, which uses thread-local variables to cache the results of the mapping query that has just been completed or the metadata of the parsed logical unit within the lifecycle of the currently executing thread, avoiding the duplicate overhead when retrying or calling the same node in the same thread.

[0159] The second level is the local heap cache within the application process, using structures such as concurrent hash tables. It defines the cache mapping relationship with process-defined key:version:node identifier:tenant identifier, and sets an appropriate lifespan.

[0160] The third level is distributed caching. For example, a Redis cluster is used to cache relatively stable but frequently queried data, such as metadata of logical units, which is shared by all application instances within the cluster.

[0161] All levels of cache are configured with a write-once invalidation policy: when a mapping table record is modified or the metadata in the logical registry is updated, the system will actively publish or broadcast a cache invalidation event. All nodes that listen to the event will immediately clear the relevant cache entries, thereby improving performance while ensuring consistency between cached data and persistent storage.

[0162] Step S5 does not handle the business process itself, but rather provides the infrastructure to safeguard the dynamic scalability of the business process. It relies on the integration of multiple fundamental components such as a logging framework, circuit breaker pattern, caching library, and message middleware, seamlessly embedding them into the core execution chain through framework code. This makes observability and reliability no longer ex-post features, but inherent capabilities built into the architecture. This invention, by systematically embedding audit logs at the framework layer, extends observability to every critical stage of dynamic execution and achieves precise correlation between business execution and engine logs through a unique execution trace identifier, thereby achieving true end-to-end tracing.

[0163] In this invention, process definitions are designed and deployed based on business needs. All service task nodes requiring dynamic expansion are uniformly configured as proxy classes. Developed business functions are registered to a logic registry center as compliant logical units. An active mapping relationship is established in the mapping table for the specified process definition version, node, and tenant, using a visual console or management interface. When a process instance reaches a relevant node, the engine calls the proxy class, which automatically performs a series of actions: extracting coordinates from the context, querying the mapping table, obtaining and securely verifying metadata, dynamically loading the logical unit using a sandbox class loader, driving its execution through a security context object, and simultaneously completing end-to-end audit logging, circuit breaker checks, and cache management. In this way, business personnel can achieve instant updates, canary releases, or multi-tenant customization of specific business node logic without modifying the process definition, restarting the application, or interfering with existing instances, simply by updating the mapping relationship or releasing new logical units. This ensures the core stability of the process engine and data consistency while achieving agile iteration and security governance of business functions.

[0164] Based on the preferred embodiments of the present invention described above, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A dynamically scalable business node management method based on the Camunda process engine, characterized in that, include: S1. Configure the business nodes in the business process so that they point to a unified proxy class during execution, serving as the entry point for all dynamically extended logic. S2. When the proxy class is called by the process engine, based on the process definition identifier, version, and node identifier in the current execution context, the mapping table in the external storage is queried to obtain the identifier of the business logic unit that should be executed. The mapping table is independent of the process definition storage and is used to establish the binding relationship between process nodes and specific business logic identifiers under specific versions and tenants. The enabling and disabling of the mapping is controlled by the status field. S3. Based on the business logic unit identifier, obtain the logic unit metadata from the logic registry center, and use the dependent resources declared in the logic unit metadata to dynamically load and instantiate the target business logic implementation class through the sandbox class loader. S4. Pass the encapsulated security context object to the standardized execution interface of the instantiated object to drive the execution of business logic; the security context object proxies and encapsulates the native engine context, exposing only whitelisted methods; S5. Record audit logs containing full-process tracking identifiers before and after the execution of business logic.

2. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: Querying the external mapping table to obtain the business logic unit identifier specifically includes: Parse and extract the process definition key, process definition version, activity node identifier, and tenant identifier from the execution context; Using the process definition key, process definition version, activity node identifier, and tenant identifier as query conditions, query the records in the external mapping table that are active. The process definition version field in the external mapping table supports storing specific version numbers or node identifiers; When querying, prioritize matching records with identical process definition versions. If no such record is found, match records whose process definition version is the node identifier.

3. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: Before dynamically loading and instantiating the target business logic implementation class based on the logical unit metadata using the sandbox class loader, the following steps are also included: The metadata of the logical unit is subjected to security verification, and the security verification includes at least the following: Verify whether the current time is within the effective time window of the metadata declaration; The digital signature in the metadata is verified using a pre-set public key to verify the integrity and origin of the logical unit JAR package; Based on bytecode security scanning, the implementation classes in the logical unit JAR package are detected to prevent code containing preset dangerous operations from being loaded.

4. The dynamically scalable business node management method based on the Camunda process engine according to claim 3, characterized in that: The dynamic loading and instantiation of the target business logic implementation class through the sandbox class loader specifically includes: Based on the list of dependent resources in the metadata of the logical unit, a dedicated sandbox class loader instance is created; the sandbox class loader is configured to load classes only from specified resource locations and is granted a preset minimum set of execution permissions; The business implementation class specified in the metadata is loaded through the sandbox class loader; An object instance is created by invoking the constructor of the business implementation class using reflection, and then converted into a predefined standardized execution interface type.

5. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: The security context object encapsulates the native engine context object using a proxy pattern, specifically including: The security context object holds a reference to the original execution context object; The method for exposing the security context object is a whitelist-filtered subset, which includes only one or more of the following: obtaining process variables, setting process variables, obtaining process instance identifiers, obtaining activity node identifiers, obtaining tenant identifiers, and obtaining business keys. Method calls to the security context object are intercepted and inspected, and the call is delegated to the original execution context object only if the calling method is within the whitelist.

6. The dynamically scalable business node management method based on the Camunda process engine according to claim 5, characterized in that: Before the driver runs the business logic, it also includes: The standardized adapter interface implementation managed by the system is injected into the security context object or passed as a parameter; All access operations to external resources in the business logic implementation code must be completed through the methods provided by the standardized adapter interface.

7. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: The audit log records include full-process tracking identifiers, specifically: After obtaining the business logic unit identifier, a globally unique execution trace identifier is generated; Record the execution start audit log, the contents of which shall include at least the execution trace identifier, process instance identifier, process definition key and version, activity node identifier, tenant identifier, logical unit identifier, and timestamp; After the business logic is completed, an execution end audit log is recorded, which includes at least the execution tracking identifier, end timestamp, execution time, and execution result status.

8. The dynamically scalable business node management method based on the Camunda process engine according to claim 7, characterized in that: This also includes implementing a circuit breaker mechanism: Maintain a failure counter with the logical unit identifier as the key; When the number of execution failures of a certain logical unit exceeds a threshold within a preset time window, an instruction is automatically sent to the data source managing the external mapping table to update the status of all records in the mapping table that point to the identifier of the logical unit and are active to disabled or isolated.

9. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: It also includes multi-level caching strategies: The system implements a multi-level cache, including thread-local cache, application-process heap cache, and distributed cache, to cache one or more of the mapping relationships queried from the external mapping table and the logical unit metadata obtained from the logical registry center. When the records in the external mapping table or the metadata of the logical unit are updated, a cache invalidation event is published to clear the relevant cached items.

10. The dynamically scalable business node management method based on the Camunda process engine according to claim 1, characterized in that: The sandbox class loader is created based on the tenant identifier, so that the business logic implementation classes of different tenants run in mutually isolated class loading spaces.

Images