Method and apparatus for hot updating of business logic executed by a workflow

Abstract

This invention provides a method and apparatus for hot updating business logic in workflow execution, relating to the technical field of workflow engines. It standardizes and defines business logic scripts and stores multiple versions in a database. Cluster node script synchronization is achieved based on a distributed messaging mechanism. Hot replacement of script instances is achieved through incremental compilation triggered by content fingerprint verification and a dual-track class loading architecture. Pre-execution verification and canary rules control the scope of script effectiveness. Finally, sandbox permissions are dynamically adjusted based on the process context, and the execution of scripts drives workflow flow. This enables millisecond-level, non-downtime hot updates of business rules, balancing high performance, high security, and high availability.

Description

Technical Field

[0001] This invention relates to the technical field of workflow engines, and in particular to a hot update method and apparatus for executing business logic in a workflow. Background Technology

[0002] In existing technologies, workflow engines primarily employ two implementation methods for business logic changes: one is the hard-coded release mode, where business rules are embedded in the project code of a compiled language. Rule modifications require a complete CI / CD process, resulting in long rule activation cycles and frequent releases that can lead to system instability. The other is the configuration parameterization mode, which only allows adjusting numerical thresholds through configuration files or databases, without modifying the business calculation logic and process structure, making it difficult to adapt to sudden business rule changes. Furthermore, existing dynamic script execution solutions suffer from poor interpreted execution performance, frequent dynamic loading leading to memory overflows, and a lack of security isolation and exception fallback mechanisms for dynamic code execution, failing to meet the stability and security requirements of high-concurrency business systems. Summary of the Invention

[0003] The purpose of this invention is to provide a hot update method and apparatus for workflow execution business logic, so as to alleviate the technical problems in the prior art that require downtime for workflow engine business logic changes, can only adjust numerical parameters and cannot modify the core execution logic, and that dynamic code execution has high performance loss, high risk of memory leaks, poor security isolation and no fallback for anomalies.

[0004] In a first aspect, the present invention provides a hot update method for workflow execution business logic, comprising: Obtain the standard-compliant business logic script and the identification parameter corresponding to each business logic script, and store each version of the business logic script in the database based on the identification parameter; Monitor changes to the business logic scripts in the database, broadcast change notifications to service nodes within the cluster, and control the service nodes to synchronize the latest script data of the business logic scripts. If the latest script data has content changes, a pre-execution verification will be performed to determine the script instances whose update scope is effective. When the workflow reaches the target node of the script instance, a sandbox environment is determined based on the process context representing the current business data and encapsulated as a read-only data structure. The read-only data structure is then injected into the matching script instance, and the workflow is driven to flow based on the execution result of the matching script instance in the sandbox environment.

[0005] In an optional implementation, the step of performing a pre-execution verification to determine the script instances whose update scope is effective when the latest script data has undergone content changes includes: The content fingerprint of the latest script data is compared with the content fingerprint of the old version of the script data cached locally. When the content fingerprints are inconsistent, the latest script data is pre-executed and verified using preset historical offline service traffic. If the verification passes, the latest script data will be compiled into bytecode and instantiated using a dual-track class loading architecture that separates shared and private classes; The newly instantiated script execution instance is updated to the local cache, and the scope of the newly instantiated script execution instance is controlled.

[0006] In an optional implementation, the step of compiling the latest script data into bytecode and instantiating it using a dual-track class loading architecture that separates shared and private classes includes: The common shared utility classes that the latest script data depends on and do not change with the version are divided into shared classes, which are loaded uniformly through the global shared class loader and reused for a long time. The business logic class of the latest script data itself, which changes with version iteration, is divided into a private class and loaded through an independent subclass loader exclusive to the private class of the latest script in the current version. After the latest script data version replacement is completed, all strong references to the independent subclass loader exclusive to the old version's private class and the corresponding private class bytecode object are disconnected, so that the virtual machine garbage collector can identify and reclaim the metaspace memory resources occupied by the old version.

[0007] In an optional implementation, the step of controlling the scope of the latest script execution instance includes: Pre-configure traffic grayscale rules for the latest script execution instance, and match the traffic grayscale rules based on the traffic tags of the workflow context; Traffic that successfully matches is controlled to invoke the latest script execution instance, while traffic that fails to match is controlled to invoke a stable version script instance. The system monitors the execution anomaly rate of the latest script execution instance in real time. If the rate exceeds a preset threshold, it automatically terminates the gray-scale rollout and switches to full traffic to call the stable version of the script for execution.

[0008] In an optional implementation, the step of pre-executing the latest script data using preset historical offline service traffic includes: The latest script data is pre-executed using preset historical offline service traffic; Compare the deviation values ​​between the pre-execution results and the historical business baseline; If the deviation value is within a preset allowable range, the latest script data of the current version will be enabled; If the deviation value exceeds the preset allowable range, the latest script data will be blocked from going online and an abnormal alarm will be pushed.

[0009] In an optional implementation, when the workflow reaches the target node of the script instance, the steps of determining a sandbox environment based on the process context representing the current business data and encapsulating it into a read-only data structure, injecting the read-only data structure into the matching script instance, and driving the workflow flow based on the execution result of the matching script instance in the sandbox environment include: When the workflow reaches the target node corresponding to the dynamic business logic script in the script instance, the current business data of the workflow is obtained and encapsulated as a process context; Based on the unique identifier of the target node, retrieve the matching script instance pre-bound to the target node from the local cache; Identify the risk level of the process context and dynamically adjust the interface call and data read / write permissions of the dedicated sandbox environment for the script execution of the target node; The process context is encapsulated as a read-only data structure and injected into the matching script instance in the dedicated sandbox environment. The script is then executed in the dedicated sandbox environment, and the workflow is driven to the next node based on the execution result returned by the script.

[0010] In an optional implementation, the step of identifying the risk level of the process context and dynamically adjusting the interface call and data read / write permissions of the dedicated sandbox environment for the script execution of the target node includes: When the workflow reaches the target node, business risk labels and transaction characteristics are first extracted from the process context to identify the risk level of the current process. The risk level is matched with the corresponding preset hierarchical permission rules, and the interface call and data read / write permissions of the target node's exclusive sandbox environment for the script instance are dynamically adjusted. If the current process is a high-risk scenario, then tighten the system interface call and sensitive data read / write permissions of the script instance; If the current process is a low-risk scenario, then the necessary business extension interfaces and data reading permissions of the script instance are granted.

[0011] In an optional implementation, the step of obtaining a standard-compliant business logic script and an identifier parameter corresponding to each business logic script, and storing each version of the business logic script in a database based on the identifier parameter, includes: A standardized business execution interface specification is predefined, and static security verification is performed on business logic scripts that conform to the business execution interface specification. Obtain the identification parameters corresponding to the verified business logic script; wherein, the identification parameters include a unique identifier, a version identifier, and a content fingerprint calculated based on the script content of the business logic script; The script content is associated with the identifier parameter in string form, and the modified business logic script, the corresponding version identifier, and the content fingerprint are stored in the database according to the unique identifier.

[0012] In an optional implementation, the steps of monitoring change events of the business logic script in the database, broadcasting change notifications to service nodes within the cluster, and controlling the service nodes to synchronize the latest script data of the business logic script include: The system monitors for new additions or version updates of the business logic scripts in the database and broadcasts change notifications to service nodes within the cluster via a distributed message bus. Based on the change notification, the service node is controlled to pull the latest script data of the updated business logic script in real time. At a preset time point, a background daemon thread is triggered to periodically compare the version identifiers of the business logic scripts in the database and the local cache. When the version identifiers are inconsistent, the service node is controlled to actively pull the latest script data and content fingerprint of the updated business logic scripts in the database. Simultaneously update the business logic script and corresponding identifier parameters stored in the local cache.

[0013] In a second aspect, the present invention provides a hot update apparatus for workflow execution business logic, comprising: The storage module obtains a standard-compliant business logic script and an identifier parameter corresponding to each business logic script, and stores each version of the business logic script in the database based on the identifier parameter. The synchronization module listens for change events of the business logic scripts in the database, broadcasts change notifications to service nodes in the cluster, and controls the service nodes to synchronize the latest script data of the business logic scripts. The determination module performs a pre-execution verification when the latest script data has content changes, and determines the script instances whose update scope is effective. The driving module determines the sandbox environment based on the process context representing the current business data when the workflow reaches the target node of the script instance, encapsulates it into a read-only data structure, injects the read-only data structure into the matching script instance, and drives the workflow to flow based on the execution result of the matching script instance in the sandbox environment.

[0014] This invention provides a method and apparatus for hot updating workflow execution business logic. First, by standardizing script definitions and storing multiple versions, it breaks the strong coupling between business logic and core system code, solving the root cause pain point of requiring system downtime for version releases in hard-coded modes. Second, through distributed event listening and a dual synchronization mechanism, it solves the problem of inconsistent script versions across multiple nodes in a cluster environment, ensuring full cluster synchronization of rule changes. Then, through content change verification, pre-execution verification, and effective scope control, it achieves incremental script updates and risk-controlled deployment, avoiding unnecessary resource consumption and the risk of full-scale business failures. Finally, through sandbox dynamic management and script execution based on process context, it achieves secure isolation between dynamic scripts and the core engine. While ensuring flexible hot updates of business rules, it also considers system security and stability, fully realizing the core objective of the invention: real-time replacement and activation of complex business logic in workflow nodes without restarting the service or re-issuing a new version.

[0015] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0018] Figure 1 A flowchart of a hot update method for executing business logic in a workflow, provided in an embodiment of the present invention; Figure 2 A functional module diagram of a hot update device for executing business logic in a workflow, provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions 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, 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.

[0020] In existing technologies, workflow engines primarily rely on two implementation paradigms for dynamically adjusting business logic: The first is the hard-coded release mode, where business rules are statically embedded into project code built using compiled languages ​​(such as Java and C#). This approach requires any rule change to undergo a complete Continuous Integration / Continuous Delivery (CI / CD) process—including code modification, compilation and building, automated testing, canary releases, and full deployment—resulting in lengthy rule activation cycles and frequent version iterations that can introduce uncontrollable system disturbances, significantly weakening service continuity and operational stability. The second is the parameter-configurable mode, which only supports adjusting numerical thresholds (such as timeout, retry count, and weight coefficients) through external configuration files or relational databases. However, it cannot access core computational logic (such as conditional branch decisions, data transformation functions, and state transition rules) and process topology (such as node addition / deletion, execution order restructuring, and parallel / serial mode switching), thus making it difficult to respond to sudden, structural, and semantic-level business rule evolution needs.

[0021] Furthermore, some current systems attempt to introduce dynamic scripting mechanisms (such as runtime interpreted execution based on Groovy, JavaScript, or Python), but such solutions still face multiple technical bottlenecks in engineering practice: (1) The inherent performance overhead of the interpretation execution mechanism is relatively large, which can easily become a system bottleneck in high-throughput scenarios; (2) Frequent hot loading of scripts and dynamic registration of class loaders can easily lead to continuous growth of metaspace or heap memory, thereby inducing the risk of memory overflow (OutOfMemoryError); (3) The lack of fine-grained security sandbox isolation mechanisms (such as permission control, resource quotas, and call stack depth limits), as well as the lack of complete exception capture, circuit breaker degradation and traceable execution rollback capabilities, result in potential security risks and reliability defects in the dynamic code execution process. In summary, the existing technology is still unable to achieve synergistic unity in the four dimensions of logical flexibility, high performance, high reliability and security governance, and cannot meet the core requirements of modern enterprise-level business systems with high concurrency, strong consistency and strict compliance for workflow engines.

[0022] Based on this, the present invention provides a method and apparatus for hot updating workflow execution business logic, which realizes millisecond-level hot updating of workflow business logic without downtime, while taking into account high performance, memory safety, execution security and business continuity in high-concurrency scenarios.

[0023] To facilitate understanding of this embodiment, a hot update method for workflow execution business logic disclosed in this embodiment of the invention will be described in detail first.

[0024] Figure 1 A flowchart of a hot update method for executing business logic in a workflow is provided in an embodiment of the present invention.

[0025] Reference Figure 1 The method includes the following steps: Step S102: Obtain the standard-compliant business logic script and the identification parameter corresponding to each business logic script, and store each version of the business logic script in the database based on the identification parameter; This step predefines standardized business execution interface specifications. After completing static security verification of the script, it generates three core parameters: a unique identifier, a version identifier, and a content fingerprint. A multi-version concurrency control mechanism is used to store the script as a string without overwriting old version records. This breaks the strong coupling between business logic and the system's core code, realizing an architecture shift where logic is data. It solves the root pain point of hard-coded mode, which requires modifying core code and going through release processes. At the same time, it provides a data foundation for subsequent version management and exception rollback.

[0026] In some embodiments, step S102 may be implemented by the following steps: Step 1.1: Predefine standardized business execution interface specifications, and perform static security checks on business logic scripts that conform to the business execution interface specifications; This step predefines a unified business execution interface specification. All scripts must follow this specification to implement the corresponding methods to ensure that they can be correctly called by the host system. At the same time, before storing the scripts, static analysis of the Abstract Syntax Tree (AST) is used to intercept syntax errors and high-risk operations, so as to achieve standardized integration between the scripts and the workflow engine. In addition, the first round of security verification is completed before storage to intercept dirty code with syntax errors and high-risk operations, so as to avoid polluting the database.

[0027] Step 2.2: Obtain the identifier parameters corresponding to the business logic script that has passed the verification; The identification parameters include a unique identifier, a version identifier, and a content fingerprint calculated based on the script content of the business logic script. This step generates three core identifier parameters for the verified script: a globally unique identifier for the script, an auto-incrementing version identifier, and a content fingerprint calculated based on the script content hash. These parameters provide a unique identifier for the entire lifecycle management of the script. The version identifier is used for multi-version management and consistency verification, while the content fingerprint is used for script change identification and incremental compilation judgment.

[0028] Step 3.3: Associate the script content with the identifier parameter in string form, and store the modified business logic script, the corresponding version identifier and content fingerprint in the database with unique identifiers.

[0029] This step associates and binds the script content with three types of identifier parameters in string form, and stores it in the database using a multi-version concurrency control mechanism. Each time the script is modified, a new independent record with the new version identifier is added without overwriting the original version data, so as to realize the full life cycle management of the script with multiple versions. This provides complete data support for subsequent version rollback, canary release, and A / B testing, while completely breaking the strong coupling between business logic and system code.

[0030] For example, firstly, the system predefines standardized business execution interface specifications, clarifying the execution methods, input parameters, and output parameter standards that the script must implement. Business personnel write business logic scripts that conform to the interface specifications through a visual editor. After the script is written, the editor backend calls the parser to generate the script's abstract syntax tree, completes static security verification, and intercepts basic issues such as syntax errors and undefined variables, as well as high-risk operations such as system exit, reflection modification of system classes, and file I / O operations.

[0031] Then, the system generates three types of core identifier parameters for the business logic scripts that pass the static security verification, including a globally unique identifier for the script, a version identifier that increments automatically with each version iteration, and a content fingerprint calculated using a hash algorithm based on the complete content of the script.

[0032] In addition, the system associates and binds the complete content of the script as a string with the generated unique identifier, version identifier, and content fingerprint. It uses a multi-version concurrency control mechanism to store the script in a relational database. Each time the script is modified, a new independent record with the new version identifier is added, without overwriting the original historical version record, thus realizing full version retention and management of the script.

[0033] Step S104: Listen for change events of business logic scripts in the database, broadcast change notifications to service nodes in the cluster, and control service nodes to synchronize the latest script data of business logic scripts; This step listens for script addition / update events in the database via a distributed message bus and broadcasts change notifications to all nodes in the cluster. It employs a dual mechanism combining event push and scheduled fetching to control service nodes to synchronize the latest script data and identifier parameters. This solves the problem of inconsistent script versions across multiple nodes in a distributed cluster environment. It ensures millisecond-level synchronization of rule changes and uses scheduled fetching as a fallback to prevent message loss due to network jitter, thus ensuring rule consistency across the entire cluster.

[0034] In practical applications, step S104 can be achieved through the following steps, including: Step 2.1: Listen for new or updated business logic scripts in the database and broadcast change notifications to service nodes in the cluster via the distributed message bus; This step uses database triggers or event listeners to continuously monitor for new and updated script records in the database. When a change is detected, a notification containing the script ID and the latest version number is broadcast to all service nodes in the cluster via a distributed message bus such as RedisPub / Sub. This enables millisecond-level detection and cluster-wide broadcast of script change events, ensuring that all nodes in the cluster can detect script changes immediately, thus providing a foundation for the rapid implementation of rules.

[0035] Step 2.2: Based on the change notification, control the service node to pull the latest script data of the updated business logic script in real time; In this step, the service nodes within the cluster continuously subscribe to change notifications from the distributed message bus. Upon receiving a notification, they immediately trigger an update process, retrieving the latest content and identifier parameters of the corresponding script from the database. This enables real-time synchronization of script changes, ensuring that rule modifications can be quickly synchronized to all nodes in the cluster, achieving effect within seconds.

[0036] Step 2.3: At a preset time point, trigger the background daemon thread to periodically compare the version identifiers of the business logic scripts in the database and the local cache. When the version identifiers are inconsistent, control the service node to actively pull the latest script data and content fingerprint of the updated business logic script in the database. This step starts a daemon thread in the background of the service node. At preset time intervals, it compares the latest version number of the script in the database with the version number in the local cache. If the local version is found to be outdated, it actively pulls the latest script data and content fingerprint. As a backup solution for the real-time push mechanism, it solves the problem of inconsistent node versions caused by network jitter and message loss, ensuring eventual consistency of script versions across the entire cluster.

[0037] Step 2.4: Simultaneously update the business logic scripts and corresponding identifier parameters stored in the local cache.

[0038] This step, after the service node retrieves the latest script data, uses read-write locks to control concurrent read-write conflicts. The write lock is held only for a fleeting moment (microseconds) when replacing the cache reference, completing the atomic update of the script content and identifier parameters in the local cache. This avoids cache data inconsistency issues caused by concurrent reads and writes, while minimizing the impact of lock contention on business throughput and ensuring system performance in high-concurrency scenarios.

[0039] For example, step S104 can also be implemented by the following steps, specifically: First, the system continuously monitors for new records and version update events of business logic scripts in the database through a database event listening mechanism. When a script change is detected, the system immediately broadcasts a change notification containing the script's unique identifier and the latest version number to all running service nodes in the cluster via a distributed message bus.

[0040] Then, all service nodes in the cluster continuously subscribe to change notifications from the distributed message bus. Upon receiving a change notification, they immediately trigger the script update process, retrieving the latest content of the corresponding script and its associated identifier parameters from the database.

[0041] In addition, a persistent daemon thread will be started in the background of the service node. At preset time intervals, it will batch compare the latest version identifier of all scripts in the database with the version identifier of the corresponding script in the local cache. If it is found that the version in the local cache is behind the latest version in the database, it will actively pull the latest updated script content and content fingerprint from the database as a backup guarantee for the real-time push mechanism.

[0042] Furthermore, after the service node retrieves the latest script data and identifier parameters, it controls concurrent read and write conflicts through read-write locks. The write lock is held only for a microsecond-level instant when replacing the local cache reference, completing the atomic update of the script content and corresponding identifier parameters in the local cache, thus avoiding data inconsistency issues caused by concurrent read and write.

[0043] Step S106: Perform a pre-execution verification when the latest script data has content changes to determine the script instances whose update scope is effective; This step uses content fingerprint comparison to determine whether the script has undergone a real change. Only the changed scripts are pre-executed and verified using historical offline business traffic. After the verification is passed, compilation and instantiation are completed. The effective scope of the script instance is determined based on traffic gray-scale rules, which can avoid the waste of CPU resources caused by invalid compilation. At the same time, scripts with business logic errors are intercepted before going live. The risk of new rules is mitigated through gray-scale rules, which solves the pain point that the full deployment of new scripts can easily cause full business failures.

[0044] In some embodiments, step S106 may be implemented by the following steps: Step 3.1: Compare the content fingerprint of the latest script data with the content fingerprint of the old version of the script data cached locally; This step calculates the fingerprint of the latest script content based on the MD5 / SHA hash algorithm, compares it with the fingerprint of the old version of the script cached locally, and determines whether the script has undergone real logical changes. It accurately identifies real script changes, avoids invalid compilation triggered by non-logical modifications such as comments and spaces, significantly reduces the unnecessary consumption of CPU resources, and provides a basis for judgment for incremental compilation.

[0045] Step 3.2: When the content fingerprint is inconsistent, the latest script data is pre-executed and verified using preset historical offline business traffic; This step is triggered only when fingerprints are inconsistent or the script has changed. It uses historical real-world business traffic from the production environment as test cases to pre-execute the latest script offline, simulating the execution effects of real-world business scenarios. By performing business logic validation on the script before deployment, it fills the gap in existing technologies that can only perform syntax validation and cannot identify business logic deviations, thus preventing scripts with logical errors from being deployed and avoiding business failures.

[0046] When the content fingerprint is inconsistent, i.e. the script has changed, step 3.2 can also be achieved through the following steps: Step 4.1: Pre-execute the latest script data using preset historical offline service traffic; This step retrieves real historical business traffic from the production environment within a preset time period as standardized test cases, inputs them in batches into the latest script, completes full pre-execution, and records the execution result of each traffic instance. It simulates the script's real production execution scenario in an offline environment, covering all business boundary conditions, avoiding execution anomalies in boundary scenarios after deployment, and ensuring business stability after script deployment.

[0047] Step 4.2: Compare the deviation values ​​between the pre-execution results and the historical business baseline; This step compares the results of the script pre-execution with the historical execution results (business baseline) of the same traffic in a stable version of the script, calculates the deviation value between the two, and determines whether the script's business logic meets expectations. It accurately identifies deviations in the script's business logic, such as misjudgments or omissions in risk control rules, filling the gap in existing technologies that can only perform syntax compliance checks but cannot verify the correctness of business logic.

[0048] Step 4.3: If the deviation value is within the preset allowable range, set the latest script data of the current version to take effect; This step determines that the script's business logic meets expectations when the deviation between the pre-execution result and the business baseline is within the preset allowable range. The script version is then marked as ready to be implemented, allowing it to enter the subsequent compilation and deployment process. This ensures that only scripts with expected business logic can enter the deployment stage, preventing production failures caused by scripts with incorrect business logic from being deployed from the source.

[0049] Step 4.4: If the deviation value exceeds the preset allowable range, intercept the latest script data from going online and push an anomaly alarm.

[0050] When the deviation between the pre-execution result and the business baseline exceeds the allowable range, this step determines that there is a defect in the script's business logic, directly blocks the deployment process of this version of the script, and pushes an exception alarm containing deviation details to the administrator. This can achieve proactive interception of business logic defects, avoid business losses caused by the deployment of erroneous rules, and improve the efficiency of rule iteration by notifying the administrator through alarms.

[0051] For example, step 3.2 can also be implemented through the following steps: First, the system retrieves real historical offline business traffic from the production environment within a preset time period as standardized test cases, inputs the test cases in batches into the latest script data, completes full offline pre-execution, and records the script execution result corresponding to each test traffic. Then, the system compares the pre-execution result of the latest script with the historical execution result (i.e., the preset business baseline) of the same batch of test traffic in the current stable version script, calculates the deviation value of the two execution results, and statistically analyzes the overall deviation rate. In addition, when the deviation value obtained from the comparison is within the preset business allowable range, the system determines that the business logic of this version of the script meets expectations, sets the latest script data of the current version to an effective state, and allows it to enter the subsequent compilation and deployment process. Further, when the deviation value obtained from the comparison exceeds the preset business allowable range, the system determines that this version of the script has a business logic defect, directly intercepts the deployment process of the script, and pushes an alarm notification containing deviation details and abnormal test cases to the administrator, reminding the administrator to complete the script correction.

[0052] Step 3.3: If the verification passes, the latest script data will be compiled into bytecode and instantiated using a dual-track class loading architecture that separates shared and private classes; This step compiles scripts that pass pre-execution verification using a dual-track class loading architecture. It separates the script's dependent general utility classes and business logic classes, loading them separately through different class loaders to ultimately generate an executable script instance. The script is then compiled into JVM bytecode, making its execution performance close to native Java code, thus addressing the pain point of poor performance in interpreted script execution. Simultaneously, the dual-track class loading architecture balances isolation and memory utilization.

[0053] For example, step 3.3 can be implemented by the following steps to instantiate the latest script data: Step 5.1: Divide the common shared utility classes that the latest script data depends on and that do not change with the version into shared classes, load them uniformly through the global shared class loader and reuse them for a long time; Here, the script content can be broken down into shared classes. Common utility classes, such as JSON parsing and date calculations, which do not change with version, are grouped into shared classes. These shared classes are loaded only once by a globally unique shared class loader, allowing all script versions to reuse them. This avoids the repeated loading of common utility classes across different script versions, significantly reducing the unnecessary use of metaspace memory and resolving the memory resource waste caused by frequent loading of multiple script versions.

[0054] Step 5.2: Divide the business logic classes of the latest script data itself, which change with version iterations, into private classes, and load them through the independent subclass loader dedicated to the private class of the latest script in the current version; Here, the core business logic classes that change with version in the script can be divided into private classes. A dedicated independent subclass loader can be created for each version of the private class to achieve complete isolation of script class loading in different versions. This will enable execution isolation of scripts in different versions, provide an architectural foundation for subsequent hot replacement of versions and recycling of old version resources, and avoid class loading conflicts between scripts in different versions.

[0055] Step 5.3: After the latest script data version replacement is completed, disconnect all strong references to the independent subclass loader exclusive to the old version's private class and the corresponding private class bytecode object, so that the virtual machine garbage collector can identify and reclaim the metaspace memory resources occupied by the old version.

[0056] Specifically, after the new version of the script takes full effect and the version replacement is completed, it actively disconnects all strong references of the JVM to the old version's independent subclass loader and private class bytecode objects, enabling the GC to identify and reclaim the corresponding memory resources. This addresses the long-standing industry pain points of metaspace memory leaks and memory overflows in the field of dynamic class loading, ensuring that frequent hot updates of scripts will not lead to a continuous increase in system memory usage.

[0057] As an optional implementation, the system can first perform class splitting on the latest script data that has passed pre-execution verification. Common utility classes that the script depends on and do not change with version iterations are classified as shared classes. These classes are loaded uniformly by a globally unique shared class loader and remain resident in memory long-term after loading. All versions of the script can reuse these classes without repeated loading. Next, the system classifies the core business logic classes of the script itself, which change with version iterations, as private classes. These classes are the core content that needs to be replaced with each hot update. The system creates a dedicated independent subclass loader for the private classes of the current version of the script. This dedicated loader completes the compilation and loading of the private classes, achieving loading isolation between different versions of the script. Furthermore, after the new version of the script has fully taken effect and the version replacement process is complete, the system actively disconnects all strong references from the JVM to the dedicated independent subclass loader of the old version's private classes and the corresponding private class bytecode objects. This allows the JVM's garbage collector to identify these no-reference resources and automatically reclaim the metaspace memory occupied by the old version, preventing memory leaks.

[0058] Step 3.4: Update the local cache with the latest instantiated script execution instance to control the scope of the latest script execution instance.

[0059] This step stores the compiled script instance in a local memory cache, using the unique identifier of the node to which the script is bound as the cache key. At the same time, based on preset traffic canary rules, the effective range of the script instance in business traffic is controlled to achieve millisecond-level invocation of the script instance, avoiding repeated compilation for each execution. Meanwhile, the canary rules are used to control the release of new scripts, minimizing the risk of new scripts going live.

[0060] For example, step 3.4 can be configured to apply the scope of the latest script execution instance through the following steps: Step 6.1: Pre-configure traffic canary rules for the latest script execution instance, and match traffic canary rules based on traffic tags in the workflow context; This step pre-configures the gray-scale rollout rules for the new version of the script. Based on traffic tags such as region, amount, and user level in the process context, it sets matching rules to clarify which traffic can trigger the new version of the script, so as to achieve fine-grained rollout control of the new version of the script, avoid the full rollout of the new script, control potential risks within a limited traffic range, and adapt to the zero-fault tolerance requirements of financial risk control scenarios.

[0061] Step 6.2: Control the traffic that successfully matches to call the latest script execution instance, and control the traffic that fails to match to call the stable version script instance; During workflow execution, this step involves matching the traffic tags in the current process context with the grayscale rules. For successfully matched traffic, the new version of the script instance is invoked, while for other traffic, the previous stable version of the script instance is invoked. This achieves parallel execution of the new and old versions of the script and traffic isolation. This not only verifies the business effectiveness of the new version of the script but also does not affect the normal operation of all business processes, providing technical support for A / B testing.

[0062] Step 6.3: Monitor the execution anomaly rate of the latest script execution instance in real time. If the rate exceeds the preset threshold, automatically terminate the gray-scale rollout and switch to full traffic to call the stable version of the script for execution.

[0063] This step monitors the execution timeout and error reports of the new version script in real time, calculates the exception rate, and automatically terminates the gray-scale rollout when the exception rate exceeds the preset safety threshold, switching all traffic back to the stable version script. This achieves automatic fallback for exceptions during the launch of the new version script. Even if the new version script has undetected defects, traffic can be switched back instantly to prevent the scope of business failures from expanding and to ensure the continuity of core business.

[0064] As an optional implementation, after the new version script instance is stored in the local cache, the system pre-configures traffic gray-scale rules for the latest script execution instance. These rules specify the range of traffic tags that can trigger the new version script, including matching conditions based on dimensions such as business region, transaction amount, user level, and channel source. Then, when the workflow reaches the corresponding target node, the system first extracts the traffic tags from the current process context and matches them with the preset gray-scale rules. For successfully matched traffic, it controls the invocation of the latest version script execution instance; for traffic that fails to match, it still controls the invocation of the previous stable version script execution instance. Furthermore, the system monitors the running status of the latest script execution instance in real time, continuously collecting indicators such as execution timeouts, uncaught anomalies, and business logic deviations, and calculates the script execution anomaly rate in real time. When the anomaly rate exceeds a preset safety threshold, the current gray-scale rollout process is automatically terminated, instantly switching all business traffic back to the stable version script execution, achieving automatic fallback for abnormal scenarios.

[0065] In practical applications, step S106, which involves pre-executing and verifying the latest script data and generating a script instance after passing the verification, includes the following steps: First, after the service node retrieves the latest script data, it calculates the content fingerprint of the latest script content based on a hash algorithm and compares it with the content fingerprint of the old version of the same script in the local cache to determine whether the script has undergone real logical changes. Then, when the comparison finds that the content fingerprint is inconsistent and the script has undergone real changes, the system retrieves the preset historical offline business traffic from the production environment as test cases and performs a full pre-execution of the latest script to completely simulate the execution process of the script in a real business scenario. In addition, when the deviation between the pre-execution result and the historical business baseline is within the preset allowable range and the verification passes, the system adopts a dual-track class loading architecture that separates shared and private classes to compile the latest script into a JVM-recognizable bytecode file and instantiate it to generate an executable script instance. Further, the system updates the instantiated latest script execution instance to the local memory cache with the unique identifier of the target node bound to the script as the key, and controls the effective scope of the latest script instance in business traffic based on pre-configured traffic gray-scale rules to achieve controllable risk deployment of the new script.

[0066] Step S108: When the workflow reaches the target node of the script instance, the sandbox environment is determined based on the process context representing the current business data and encapsulated as a read-only data structure. The read-only data structure is injected into the matching script instance, and the workflow is driven to flow based on the execution result of the matching script instance in the sandbox environment.

[0067] This step dynamically adjusts the sandbox execution permissions based on the risk level of the process context when the workflow reaches the target node of the pre-bound script. The process context is encapsulated as a read-only structure and a matching script instance is injected. After the script is executed in the sandbox, the process flow is driven by the return result. This can achieve complete isolation between dynamic scripts and the core workflow engine, preventing scripts from tampering with core business data from the root. At the same time, dynamic permission adjustment takes into account both security and business flexibility, ensuring that even if the script has defects, it will not bring down the entire business system.

[0068] In some embodiments, step S108 may also be implemented through the following steps: Step 7.1: When the workflow reaches the target node corresponding to the dynamic business logic script in the script instance, obtain the current business data of the workflow and encapsulate it into a process context; This step automatically collects all business data in the current process, such as form data, user information, historical execution records, and transaction characteristics, when the workflow reaches the target node that is pre-bound with dynamic business logic scripts. This data is then encapsulated into a standardized process context object, providing complete business data support for the execution of dynamic scripts. At the same time, the standardized encapsulation ensures that different versions of scripts can correctly read business data, achieving standardized integration between scripts and the workflow engine.

[0069] Step 7.2: Based on the unique identifier of the target node, retrieve the matching script instance pre-bound to the target node from the local cache; This step uses the unique identifier of the target node as the key to retrieve all available script instances pre-bound to that node from the local memory cache. Then, it combines the version activation rules to determine the currently matching effective version script instance. This ensures the accurate binding of workflow nodes and script instances, avoids script call errors, and enables millisecond-level script instance calls through local caching, ensuring response performance in high-concurrency scenarios.

[0070] Step 7.3: Identify the risk level of the process context and dynamically adjust the interface call and data read / write permissions of the dedicated sandbox environment for the script execution of the target node; This step extracts business risk tags and transaction characteristics from the process context, identifies the risk level of the current process, matches preset hierarchical permission rules, and dynamically adjusts the interface call and data read / write permissions of the script in the dedicated sandbox environment of this node. This solves the contradiction between the existing fixed permission sandbox permissions being too strict to execute business and too loose permissions posing security risks, thus balancing the flexibility of script execution with the security of the production environment.

[0071] In some embodiments, step 7.3 further includes the following steps: Step 8.1: When the workflow reaches the target node, first extract the business risk label and transaction characteristics from the process context to identify the risk level of the current process; This step extracts risk tags and transaction characteristics such as transaction amount, region, user credit rating, and historical violation records from the process context when the workflow reaches the target node. Based on the preset risk model, it identifies the risk level of the current process, achieves accurate identification of business risks, and provides a basis for judgment for the dynamic adjustment of sandbox permissions in the future, ensuring that permission adjustments are accurately matched with the business risk level.

[0072] Step 8.2: Match the risk level with the corresponding preset hierarchical permission rules, and dynamically adjust the target node's exclusive sandbox environment's interface call and data read / write permissions for script instances; This step, based on the identified risk level, matches pre-configured hierarchical permission rules and dynamically adjusts the sandbox environment's permissions for script system interface calls, external service calls, and sensitive data read / write, achieving real-time dynamic adaptation of permissions. This breaks the limitations of existing fixed-permission sandboxes and enables dynamic adaptation of sandbox permissions to business risks, ensuring system security in high-risk scenarios while meeting the business flexibility needs of low-risk scenarios.

[0073] Step 8.3: If the current process is a high-risk scenario, tighten the system interface call and sensitive data read / write permissions of the script instance; When this step identifies the current process as high-risk, it automatically disables the script's system-level interface calls, external service calls, and sensitive data modification permissions, granting only basic business data read permissions. This maximizes the restriction of script operation permissions in high-risk scenarios, fundamentally reducing the risk of security incidents and business losses caused by malicious or defective scripts.

[0074] Step 8.4: If the current process is a low-risk scenario, then grant the necessary business extension interfaces and data reading permissions to the script instance.

[0075] When this step identifies the current process as low-risk, and under the premise of security and controllability, it grants access to the script's business extension interface calls and read / write permissions for non-sensitive data to meet the execution needs of complex business logic. This ensures the script's business flexibility in low-risk scenarios, supports complex business logic extensions, and prevents normal business logic from failing to execute due to permission restrictions.

[0076] As an optional implementation, step 7.3 can be achieved through the following steps: First, when the workflow engine reaches the target node, it extracts business risk tags and transaction characteristics from the encapsulated process context, including information on transaction amount, transaction region, user credit rating, historical violation records, and channel source. Based on a preset risk grading model, it identifies the risk level of the current business process. Then, the system matches the identified risk level with pre-configured hierarchical permission rules and dynamically adjusts the target node's dedicated sandbox environment based on the matching results, granting the current script instance's interface call permissions and data read / write permissions. Furthermore, if the current business process is identified as a high-risk scenario, the system automatically tightens the script instance's permissions, disabling high-risk permissions such as system-level interface calls, external service calls, and sensitive data modification, only granting the script basic business data read permissions to minimize security risks. Further, if the current business process is identified as a low-risk scenario, the system, under the premise of security and controllability, grants the script instance necessary business extension interfaces and non-sensitive data read permissions to meet the execution needs of complex business logic, balancing security and business flexibility.

[0077] Step 7.4: Encapsulate the process context into a read-only data structure, inject it into the matching script instance in the dedicated sandbox environment, execute the script in the dedicated sandbox environment, and drive the workflow to the next node based on the execution result returned by the script.

[0078] This step defensively replicates the original data of the process context, encapsulates it into an unmodifiable read-only data structure, and injects it into a script instance in a dedicated sandbox environment. After the script completes execution in the sandbox, it returns the result. The workflow engine drives the process flow based on the result, preventing scripts from maliciously tampering with core business data from the root. At the same time, the sandbox environment achieves complete isolation between the script and the core engine. Even if the script has problems such as infinite loops or illegal calls, it will not affect the normal operation of the core workflow engine.

[0079] For example, step S108 can also be implemented through the following steps: First, when the workflow engine runs to a target node that is pre-statically bound to a dynamic business logic script, it automatically collects business data from the entire workflow chain, including form data, user information, historical approval records, transaction characteristics, risk tags, etc., and encapsulates them into a standardized process context object. Then, the system uses the unique identifier of the target node as the retrieval key to retrieve all available script instances pre-bound to the target node from the local memory cache, and determines the currently effective version script instance that matches the current business traffic by combining the preset version activation rules. In addition, the system extracts business risk tags and transaction characteristics from the process context, identifies the risk level of the current business process, matches the pre-configured hierarchical permission rules, and dynamically adjusts the interface call and data read / write permissions of the target node's dedicated sandbox environment, tightening permissions in high-risk scenarios and opening necessary extended permissions in low-risk scenarios. Furthermore, the system defensively replicates the original business data of the process context, encapsulates it into an unmodifiable read-only data structure, and injects it into a matching script instance in a dedicated sandbox environment. The script completes the execution of business logic and returns the execution result in the dedicated sandbox environment with controlled permissions. Finally, the workflow engine drives the workflow to the next corresponding node based on the execution result returned by the script.

[0080] In a preferred embodiment of practical application, firstly, the system predefines standardized business execution interface specifications. Business personnel write business logic scripts that conform to the interface specifications using a visual editor. The editor backend performs static security checks on the script using an abstract syntax tree, intercepting syntax errors and high-risk operations. It then generates a unique identifier, an incrementing version identifier, and a content fingerprint calculated based on the script content for each script. A multi-version concurrency control mechanism is used to store the script content as a string associated with all identifier parameters in the database. Each modification creates a new independent version record without overwriting existing data. Next, the system continuously monitors for script additions and version updates in the database. When a change is detected, a change notification is broadcast to all service nodes in the cluster via a distributed message bus. Service nodes trigger script synchronization by listening for change notifications in real time. Simultaneously, a background daemon thread periodically compares the version identifiers in the database and the local cache. If the versions are inconsistent, it actively retrieves the latest script data, achieving dual-protection cluster synchronization. Furthermore, after the service node retrieves the latest script data, it first compares the content fingerprints of the old and new scripts. Only when the fingerprints are inconsistent or the script has undergone actual changes, a pre-execution verification of the script is performed using preset historical offline business traffic. The deviation between the pre-execution result and the historical business baseline is compared. If the verification passes, the script is compiled into bytecode and instantiated. At the same time, traffic canary rules are configured for the script instance to determine its business scope. Further, when the workflow engine runs to the target node that is pre-bound to the corresponding script, it first obtains the full business data of the current workflow and encapsulates it into a process context. Based on the business risk label of the process context, the risk level is identified, and the execution permissions of the node's dedicated sandbox environment are dynamically adjusted. At the same time, the process context is encapsulated into an unmodifiable read-only data structure and injected into the matching currently effective version of the script instance. After the script completes execution in the dedicated sandbox environment, it returns the execution result to the workflow engine. Finally, the engine drives the workflow to the next node based on the execution result.

[0081] In some embodiments, such as Figure 2 As shown, this embodiment of the invention provides a hot update device for workflow execution business logic, comprising: The storage module obtains a standard-compliant business logic script and an identifier parameter corresponding to each business logic script, and stores each version of the business logic script in the database based on the identifier parameter. The synchronization module listens for change events of the business logic scripts in the database, broadcasts change notifications to service nodes in the cluster, and controls the service nodes to synchronize the latest script data of the business logic scripts. The determination module performs a pre-execution verification when the latest script data has content changes, and determines the script instances whose update scope is effective. The driving module determines the sandbox environment based on the process context representing the current business data when the workflow reaches the target node of the script instance, encapsulates it into a read-only data structure, injects the read-only data structure into the matching script instance, and drives the workflow to flow based on the execution result of the matching script instance in the sandbox environment.

[0082] This invention discloses a hot update method for workflow execution business logic, aiming to solve the problems of existing workflow business logic changes requiring system downtime for version releases, insufficient flexibility, and high risks associated with dynamic execution. This invention standardizes and defines business logic scripts, storing multiple versions in a database. It achieves script synchronization across cluster nodes based on a distributed messaging mechanism, implements hot replacement of script instances through content fingerprint verification-triggered incremental compilation and a dual-track class loading architecture, controls the script's effective scope using pre-execution verification and canary rules, and finally dynamically adjusts sandbox permissions based on the process context to drive workflow flow. This invention enables millisecond-level, non-downtime hot updates of business rules, balancing high performance, high security, and high availability.

[0083] The present invention provides an embodiment of an electronic device. In this embodiment, the electronic device may be, but is not limited to, a personal computer (PC), a laptop computer, a monitoring device, a server, or other computer device with analysis and processing capabilities.

[0084] As an exemplary embodiment, see [reference]. Figure 3 The electronic device 110 includes a communication interface 111, a processor 112, a memory 113, and a bus 114. The processor 112, the communication interface 111, and the memory 113 are connected via the bus 114. The memory 113 is used to store a computer program that supports the processor 112 in executing the above-described method. The processor 112 is configured to execute the program stored in the memory 113.

[0085] The machine-readable storage medium mentioned in this article can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0086] Non-volatile media can be non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar non-volatile storage media, or combinations thereof.

[0087] It is understood that the specific operation methods of each functional module in this embodiment can be referred to the detailed description of the corresponding steps in the above method embodiment, and will not be repeated here.

[0088] The computer-readable storage medium provided in the embodiments of the present invention stores a computer program. When the computer program code is executed, it can implement the method described in any of the above embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0090] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms installation, connection, and linking should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0091] In the description of this invention, it should be noted that the terms center, up, down, left, right, vertical, horizontal, inner, and outer, indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms first, second, and third are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0092] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A hot update method for workflow execution business logic, characterized in that, include: Obtain the standard-compliant business logic script and the identification parameter corresponding to each business logic script, and store each version of the business logic script in the database based on the identification parameter; Monitor changes to the business logic scripts in the database, broadcast change notifications to service nodes within the cluster, and control the service nodes to synchronize the latest script data of the business logic scripts. If the latest script data has content changes, a pre-execution verification will be performed to determine the script instances whose update scope is effective. When the workflow reaches the target node of the script instance, a sandbox environment is determined based on the process context representing the current business data and encapsulated as a read-only data structure. The read-only data structure is then injected into the matching script instance, and the workflow is driven to flow based on the execution result of the matching script instance in the sandbox environment.

2. The method according to claim 1, characterized in that, The steps for performing pre-execution verification to determine the script instances whose update scope is affected when the latest script data has undergone content changes include: The content fingerprint of the latest script data is compared with the content fingerprint of the old version of the script data cached locally. When the content fingerprints are inconsistent, the latest script data is pre-executed and verified using preset historical offline service traffic. If the verification passes, the latest script data will be compiled into bytecode and instantiated using a dual-track class loading architecture that separates shared and private classes; The newly instantiated script execution instance is updated to the local cache, and the scope of the newly instantiated script execution instance is controlled.

3. The method according to claim 2, characterized in that, The steps of compiling the latest script data into bytecode and instantiating it using a dual-track class loading architecture that separates shared and private classes include: The common shared utility classes that the latest script data depends on and do not change with the version are divided into shared classes, which are loaded uniformly through the global shared class loader and reused for a long time. The business logic class of the latest script data itself, which changes with version iteration, is divided into a private class and loaded through an independent subclass loader exclusive to the private class of the latest script in the current version. After the latest script data version replacement is completed, all strong references to the independent subclass loader exclusive to the old version's private class and the corresponding private class bytecode object are disconnected, so that the virtual machine garbage collector can identify and reclaim the metaspace memory resources occupied by the old version.

4. The method according to claim 2, characterized in that, The steps for controlling the scope of the latest script execution instance include: Pre-configure traffic grayscale rules for the latest script execution instance, and match the traffic grayscale rules based on the traffic tags of the workflow context; Traffic that successfully matches is controlled to invoke the latest script execution instance, while traffic that fails to match is controlled to invoke a stable version script instance. The system monitors the execution anomaly rate of the latest script execution instance in real time. If the rate exceeds a preset threshold, it automatically terminates the gray-scale rollout and switches to full traffic to call the stable version of the script for execution.

5. The method according to claim 2, characterized in that, The step of pre-executing and verifying the latest script data using preset historical offline service traffic includes: The latest script data is pre-executed using preset historical offline service traffic; Compare the deviation values ​​between the pre-execution results and the historical business baseline; If the deviation value is within a preset allowable range, the latest script data of the current version will be enabled; If the deviation value exceeds the preset allowable range, the latest script data will be blocked from going online and an abnormal alarm will be pushed.

6. The method according to claim 1, characterized in that, When the workflow reaches the target node of the script instance, the steps of determining the sandbox environment based on the process context representing the current business data and encapsulating it into a read-only data structure, injecting the read-only data structure into the matching script instance, and driving the workflow flow based on the execution result of the matching script instance in the sandbox environment include: When the workflow reaches the target node corresponding to the dynamic business logic script in the script instance, the current business data of the workflow is obtained and encapsulated as a process context; Based on the unique identifier of the target node, retrieve the matching script instance pre-bound to the target node from the local cache; Identify the risk level of the process context and dynamically adjust the interface call and data read / write permissions of the dedicated sandbox environment for the script execution of the target node; The process context is encapsulated as a read-only data structure and injected into the matching script instance in the dedicated sandbox environment. The script is then executed in the dedicated sandbox environment, and the workflow is driven to the next node based on the execution result returned by the script.

7. The method according to claim 1, characterized in that, The steps of identifying the risk level of the process context and dynamically adjusting the interface call and data read / write permissions of the dedicated sandbox environment for script execution of the target node include: When the workflow reaches the target node, business risk labels and transaction characteristics are first extracted from the process context to identify the risk level of the current process. The risk level is matched with the corresponding preset hierarchical permission rules, and the interface call and data read / write permissions of the target node's exclusive sandbox environment for the script instance are dynamically adjusted. If the current process is a high-risk scenario, then tighten the system interface call and sensitive data read / write permissions of the script instance; If the current process is a low-risk scenario, then the necessary business extension interfaces and data reading permissions of the script instance are granted.

8. The method according to claim 1, characterized in that, The steps of obtaining standard-compliant business logic scripts and corresponding identifier parameters for each business logic script, and storing each version of the business logic script in the database based on the identifier parameters, include: A standardized business execution interface specification is predefined, and static security verification is performed on business logic scripts that conform to the business execution interface specification. Obtain the identification parameters corresponding to the verified business logic script; wherein, the identification parameters include a unique identifier, a version identifier, and a content fingerprint calculated based on the script content of the business logic script; The script content is associated with the identifier parameter in string form, and the modified business logic script, the corresponding version identifier, and the content fingerprint are stored in the database according to the unique identifier.

9. The method according to claim 1, characterized in that, The steps of monitoring change events of the business logic script in the database, broadcasting change notifications to service nodes in the cluster, and controlling service nodes to synchronize the latest script data of the business logic script include: The system monitors for new additions or version updates of the business logic scripts in the database and broadcasts change notifications to service nodes within the cluster via a distributed message bus. Based on the change notification, the service node is controlled to pull the latest script data of the updated business logic script in real time. At a preset time point, a background daemon thread is triggered to periodically compare the version identifiers of the business logic scripts in the database and the local cache. When the version identifiers are inconsistent, the service node is controlled to actively pull the latest script data and content fingerprint of the updated business logic scripts in the database. Simultaneously update the business logic script and corresponding identifier parameters stored in the local cache.

10. A hot-update device for workflow execution business logic, characterized in that, include: The storage module obtains a standard-compliant business logic script and an identifier parameter corresponding to each business logic script, and stores each version of the business logic script in the database based on the identifier parameter. The synchronization module listens for change events of the business logic scripts in the database, broadcasts change notifications to service nodes in the cluster, and controls the service nodes to synchronize the latest script data of the business logic scripts. The determination module performs a pre-execution verification when the latest script data has content changes, and determines the script instances whose update scope is effective. The driving module determines the sandbox environment based on the process context representing the current business data when the workflow reaches the target node of the script instance, encapsulates it into a read-only data structure, injects the read-only data structure into the matching script instance, and drives the workflow to flow based on the execution result of the matching script instance in the sandbox environment.

Images