A multi-environment workflow batch security update method and device

Abstract

This disclosure belongs to the field of workflow management technology in multiple environments. This disclosure provides a method and apparatus for batch secure updates of workflows in multiple environments. The method includes: a batch secure maintenance step: performing a unified structural modification on multiple deployed workflow JSON files in the source environment; and a secure deployment step: synchronizing the workflow JSON files to be deployed to the target environment.

Description

Technical Field

[0001] This disclosure belongs to the field of workflow management technology in multiple environments, and particularly relates to a method and apparatus for batch secure updates of workflows in multiple environments. Background Technology

[0002] With the widespread adoption of low-code workflow orchestration technology, enterprise business processes are generally deployed in the engine in the form of visual workflows, typically maintaining multiple independent environments such as testing and production. After developers complete a batch of workflow iterations and debugging in the source environment, they need to synchronize them to the target environment in batches. However, existing technologies have consistently failed to balance efficiency, reliability, and accuracy in this scenario.

[0003] When faced with batch updates of dozens of workflows, manual modification is inefficient and prone to omissions and errors. While text replacement tools improve efficiency, they cannot detect JSON structure rules, easily violating specific syntax elements of the workflow JSON. Once an error occurs, the entire batch is corrupted, and the impact of the failure is far greater than that of a single update. More importantly, the batch-modified files lack systematic verification methods, and key quality dimensions cannot be automatically detected, allowing defective files to directly enter subsequent stages.

[0004] Meanwhile, workflow IDs are generated independently in different environments, with no inherent correspondence, leading to a double deficiency in identity recognition and verification during cross-environment matching and deployment. Manually maintaining ID mapping tables is extremely inefficient; automated solutions rely on fuzzy matching such as names or filenames, but names can be duplicated and filenames can be arbitrarily modified, resulting in a high risk of identity mismatch and often causing incorrect overwriting of existing workflows. Existing solutions also lack pre-deployment difference verification, failing to distinguish between expected differences introduced by batch modifications and unexpected structural damage. Mismatches or damage cannot be detected in advance, leading to business failures after direct deployment.

[0005] The aforementioned defects amplify each other: unreliable outputs from the batch modification process directly enter the matching and deployment process, which lacks effective verification methods, creating a chain of risks such as structural damage, identity mismatch, and fault propagation. Enterprises are forced to repeatedly weigh efficiency, reliability, and accuracy, and batch cross-environment updates can never meet actual production needs. Summary of the Invention

[0006] This disclosure provides a method and apparatus for batch secure updates of multi-environment workflows, which can effectively solve the above-mentioned problems.

[0007] This disclosure is implemented as follows: Firstly, this disclosure provides a method for batch secure updates of multi-environment workflows, the method comprising: Batch security maintenance steps: Perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: Export the workflow JSON file from the source environment to the local file system; The use of a structured JSON parsing tool is mandatory to perform structured parsing and modification of workflow JSON files on the local file system, and direct manipulation by text replacement tools is prohibited. After modification, perform multi-dimensional consistency verification and output a compliant JSON file of the workflow to be deployed; Secure deployment steps: Synchronize the JSON file of the workflow to be deployed to the target environment, and execute the following steps in sequence: Copying phase: The JSON file of the workflow to be deployed is parsed using a structured JSON parsing tool. The environment-related fields are traversed, and the source environment parameters are replaced with the parameters corresponding to the target environment to obtain the JSON definition file of the workflow to be uploaded. Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment. The workflow JSON definition file to be uploaded is then compared with the existing workflow JSON data of the corresponding identity pulled from the target environment to identify differences. The three-level matching algorithm is executed in sequence: the first level is based on the path information of the Webhook node in the workflow to perform business semantic primary key matching; the second level is based on the pre-persistent source environment ID-target environment ID mapping file to perform secondary matching; and the third level determines that there is no corresponding relationship. Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

[0008] Secondly, this disclosure provides a multi-environment workflow batch security update device, the device comprising: The batch security maintenance module is used to perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: Export the workflow JSON file from the source environment to the local file system; The use of a structured JSON parsing tool is mandatory to perform structured parsing and modification of workflow JSON files on the local file system, and direct manipulation by text replacement tools is prohibited. After modification, perform multi-dimensional consistency verification and output a compliant JSON file of the workflow to be deployed; The secure deployment module is used to synchronize the JSON file of the workflow to be deployed to the target environment, and executes it sequentially: Copying phase: The JSON file of the workflow to be deployed is parsed using a structured JSON parsing tool. The environment-related fields are traversed, and the source environment parameters are replaced with the parameters corresponding to the target environment to obtain the JSON definition file of the workflow to be uploaded. Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment. The workflow JSON definition file to be uploaded is then compared with the existing workflow JSON data of the corresponding identity pulled from the target environment to identify differences. The three-level matching algorithm is executed in sequence: the first level is based on the path information of the Webhook node in the workflow to perform business semantic primary key matching; the second level is based on the pre-persistent source environment ID-target environment ID mapping file to perform secondary matching; and the third level determines that there is no corresponding relationship. Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

[0009] Thirdly, this disclosure provides an electronic device, including: Memory, the memory storing execution instructions; and A processor that executes execution instructions stored in the memory, causing the processor to perform the method described in the first aspect.

[0010] Fourthly, this disclosure provides a readable storage medium storing executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect.

[0011] Compared with the prior art, the beneficial effects of this disclosure are: This disclosure provides a method and apparatus for secure batch updates of workflows in multiple environments. By forcibly using a structured JSON parsing tool to modify batch workflow files, it replaces traditional batch text replacement tools, thus preventing JSON structure corruption caused by batch modifications at the source. The modified files with compliant structure are used as deployment input, and a three-level progressive matching based on the business semantic primary key and the pre-stored ID mapping is used to achieve automatic identification of workflow identities across environments, eliminating the need for manual maintenance of the corresponding relationships. Before deployment, a field-by-field deep comparison and verification is performed to distinguish between expected parameter replacements and unexpected structural changes, intercepting the risk of mismatch.

[0012] The structured batch modification and secure deployment steps described above involve three sequentially linked stages: copying, verification, and uploading. The copying stage replaces environmental parameters; the verification stage incorporates a three-level progressive identity matching and field-by-field deep comparison; and the uploading stage performs update or creation operations based on the confirmed identity. The output of the preceding stages directly serves as the input for the subsequent stages, forming a technical closed loop of input quality control, accurate identity recognition, and early anomaly interception. This reduces the probability of business failures caused by batch updates and meets the actual needs of batch iteration workflows in various enterprise environments. Attached Figure Description

[0013] Figure 1 This is a flowchart of the multi-environment workflow batch security update method S100 provided in the embodiments of this disclosure.

[0014] Figure 2 This is a schematic diagram of the architecture of the multi-environment workflow batch security update system provided in the embodiments of this disclosure.

[0015] Figure 3 This is a schematic diagram of the structure of the multi-environment workflow batch security update device 1000 provided in the embodiments of this disclosure. Detailed Implementation

[0016] The present disclosure will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0017] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] Unless otherwise stated, the exemplary implementations / embodiments shown are to be understood as providing exemplary features of various details that provide ways in which the technical concepts of this disclosure can be implemented in practice. Therefore, unless otherwise stated, the features of various implementations / embodiments may be additionally combined, separated, interchanged and / or rearranged without departing from the technical concepts of this disclosure.

[0019] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure. The singular forms “a,” “the,” and “the” used in the embodiments of this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0020] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0021] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0022] The terms "first" and "second" used herein are merely to distinguish similar objects and do not represent a specific ordering of the objects. Understandably, the specific order or sequence of "first" and "second" can be interchanged where permitted. It should be understood that the objects distinguished by "first" and "second" can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein.

[0023] Example 1 Please refer to Figure 1 This disclosure provides a method S100 for batch secure updates of multi-environment workflows. Method S100 can be applied to a multi-environment workflow management system, which maintains at least two independent workflow runtime environments (e.g., a test environment and a production environment). Each environment has an independent workflow engine instance, API key, and workflow storage. The system uses a standardized JSON data model as the unified representation format for workflows, supporting the entire process of workflow export, modification, verification, transmission, and import.

[0024] Specifically, method S100 includes: S102, Batch Security Maintenance Steps: Perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: S1021, Export the workflow JSON file from the source environment to the local file system; S1022, Force the use of a structured JSON parsing tool to perform structured parsing and modification of the workflow JSON file on the local file system, and prohibit the direct operation of the text replacement tool; S1023, after modification, performs multi-dimensional consistency verification and outputs a compliant JSON file of the workflow to be deployed; S104, Secure Deployment Steps: Synchronize the JSON file of the workflow to be deployed to the target environment, and execute the following steps sequentially: S1041, Copying stage: The structured JSON parsing tool is used to perform structured parsing on the JSON file of the workflow to be deployed, traversing the environment-related fields, replacing the source environment parameters with the parameters corresponding to the target environment, and obtaining the JSON definition file of the workflow to be uploaded; S1042, Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment, and a deep consistency comparison is performed between the workflow JSON definition file to be uploaded and the existing workflow JSON data of the corresponding identity pulled from the target environment to locate the differences. The three-level matching algorithm is executed in sequence: the first level performs business semantic primary key matching based on the path information of Webhook nodes in the workflow; the second level performs secondary matching based on the pre-persistently stored source environment ID-target environment ID mapping file; and the third level determines that there is no corresponding relationship. S1043, Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

[0025] In some embodiments, the method further includes: A multi-environment configuration dictionary is pre-generated. The multi-environment configuration dictionary stores the environment configuration information corresponding to the local development environment, test environment, and production environment. The environment configuration information of each environment includes the workflow engine instance address, API authentication information, and read-only flag. The system parses the user's input commands, extracts environment selection parameters, determines the target environment based on a semantic keyword matching algorithm, and loads the environment configuration information corresponding to the target environment from the multi-environment configuration dictionary. If the environment selection parameters are not extracted, the local development environment is determined as the target environment by default.

[0026] In some implementations, the configuration parameters of the multi-environment configuration dictionary are loaded from external configuration files (such as environment variable files, JSON files, or YAML files), achieving separation of configuration and code. At runtime, the configuration information of the specified environment is loaded through an environment initialization function, and the target environment for the current operation is switched.

[0027] The configuration information for each environment includes: the workflow engine instance address (base_url), the API authentication key (api_key), the local workflow file storage directory (export_dir), and the read-only flag (readonly). For example, as shown in Table 1: Table 1 Multi-environment configuration information

[0028] By configuring a read-only flag independently for each environment, hierarchical permission control is achieved, allowing "read-write access in development and testing environments and read-only access in production environments".

[0029] In some implementations, the method further includes: receiving and parsing user-inputted operation instructions to determine the source and target environments for this batch update.

[0030] For example, the system receives a user's input command: "Batch update the workflow from the test environment to the production environment," and parses the environment selection parameters. The system's built-in semantic keyword matching engine determines the source environment as the test environment based on keywords such as "test environment / test," and the target environment as the production environment based on keywords such as "production environment / prod." If the user does not specify a source or target environment, or if the command does not involve cross-environment migration, the local development environment is used as the operating environment by default (following the principle of least privilege). After parsing, the system loads the complete configuration information of the corresponding environment (including API address, authentication key, storage directory, and read-only flag) from the multi-environment configuration dictionary. Through the built-in semantic keyword matching engine, users do not need to remember complex parameters such as API addresses and authentication keys for each environment; they can specify the operating environment simply by using natural language (such as "test environment" or "production environment"), and the system automatically completes environment identification and configuration loading.

[0031] In some implementations, before executing a write operation command to the target environment, the read-only flag of the target environment is queried. If the read-only flag is true, the write operation command is intercepted and its execution terminated at the API client script layer. Before executing any write operation command (such as create, update, delete, activate, or deactivate) to the target environment (especially the production environment), the system first queries the read-only flag of the target environment. If the read-only flag is true, hard-coded interception is implemented at the API client script layer. Existing technologies typically rely on role and permission configuration on the workflow engine server, which carries the risk of configuration errors or bypassing. This disclosure implements hard-coded interception at the API client script layer through a read-only flag and a command whitelist: the write operation is terminated before the HTTP request is sent, eliminating the possibility of accidental operations reaching the production environment instance at the network level. This mechanism does not rely on any external configuration, cannot be bypassed, and has higher security.

[0032] In some implementations, the target environment is configured with an allowed command whitelist, which is stored using a hash set. The allowed command whitelist includes the following read operation commands: list, get, export, download-all, executions, and tags. Requests to the target environment are only allowed if the command to be executed belongs to the allowed command whitelist. The system predefines an allowed command whitelist, which is stored using a hash set and contains only read operation commands. If the command to be executed does not belong to the whitelist, the write operation command is intercepted and its execution is terminated, thereby ensuring that any HTTP request for a write operation is never sent to the workflow engine instance in the production environment. The allowed command whitelist is stored using a hash set, and the command matching time complexity is O(1), which does not affect performance even in high-frequency read operation scenarios, ensuring a balance between security mechanisms and execution efficiency.

[0033] Based on the aforementioned environment preparation and permission verification, method S100 proceeds to the specific process of batch security maintenance and deployment. In some embodiments, the source environment is a test environment, and the target environment is a production environment. For ease of description, the following steps are illustrated using the test environment as the source environment and the production environment as the target environment as an example. However, the method disclosed herein is also applicable to batch updates between any two environments (such as from a development environment to a test environment), and is not limited thereto.

[0034] Step S102 is executed on the source environment side, aiming to make unified structural modifications to multiple deployed workflows and ensure the security of the modification process and the structural compliance of the modified files. Compared with manual modification one by one, this step significantly improves modification efficiency while ensuring the consistency of all workflow parameter modifications, solving the problem of "efficiency and reliability cannot be balanced" in batch modification.

[0035] Step S1021 persists the workflow from the source environment to the local file system as a JSON file, providing an operable file copy for subsequent batch modifications using structured JSON parsing tools (such as the Python json module). This operation itself only involves read-only API calls and will not affect the running instance in the source environment, ensuring the security of the source data. Simultaneously, the introduction of the local file system makes the modification process independent of network dependencies, supporting offline batch processing. If modifications are made directly in the production environment's memory, the risks of text replacement tools cannot be avoided. In a specific implementation scenario, the test environment deploys workflows for producing text, image, and video content for local businesses in multiple industries such as catering, beauty, and retail. When it is necessary to uniformly modify the Large Language Model (LLM) calling method in all workflows or add a common compliance verification node, maintenance personnel initiate an export request to the test environment via the API interface, batch downloading all relevant workflow JSON files to a pre-configured export directory locally, such as . / workflows / test_env / .

[0036] In existing technologies, developers often use text replacement tools such as sed and awk to directly modify JSON files in batches. However, JSON files exported by workflow engines contain a large number of special syntax elements, such as the expression ={{$json.field}}, cross-node references in $('node name').item.json, Chinese characters, and multi-level nested quotation marks. Modifying these files using text replacement tools can easily corrupt the JSON structure or cause encoding errors. To address this issue, step S1022 mandates the use of a structured JSON parsing tool (such as a JSON parsing library built into various programming languages). This type of tool completely parses the JSON file into a structured object in memory (such as a dictionary, list, etc.), and all modification operations are performed in this structured environment—for example, traversing the node list, updating specified fields, inserting new nodes, etc. After modification, the structured object is serialized back to JSON format and written to a file. This process automatically handles special character escaping and maintains UTF-8 encoding (especially ensuring that Chinese characters are not converted to Unicode escape sequences), thereby preventing JSON structure corruption and encoding errors at the source.

[0037] After batch modifications, to ensure that all workflow modifications meet expectations and have consistent internal structures, in step S1023, the system automatically performs multi-dimensional consistency verification. In some implementations, the multi-dimensional consistency verification includes at least the following dimensions: Consistency of node expression referencing: Check whether all expressions consistently use explicit reference syntax (such as $('node name').item.json.field) instead of implicit reference (such as $json.field) to ensure the clarity and reliability of data references in complex workflows.

[0038] HTTP Node Header Passing Consistency: Check whether all HTTP Request nodes pass their request headers in the standard JSON object format ({"key":"value"}) rather than a list of key-value pairs to ensure the consistency and correctness of parameter passing.

[0039] Webhook path uniqueness: Scan all Webhook nodes in the workflow, extract their parameter.path field values ​​(e.g., / api / content / generate), and check for duplicate paths in the current environment (test environment). Duplicate paths can cause routing conflicts, and this check can detect and prevent such problems in advance.

[0040] Completeness of settings configuration fields: Check whether the settings object of each workflow contains all core fields, such as: verifying that the errorWorkflow field is specified and points to a valid error handling workflow, verifying that the executionOrder field is a compatible version (such as 'v1'), and verifying that the callerPolicy field is not empty and meets the policy requirements, thereby ensuring the integrity and reliability of the workflow execution logic.

[0041] Only workflow JSON files that pass all the above consistency verifications will be marked as "pending deployment" and proceed to the next step of the security deployment process. If verification fails, the system will output a detailed error report, locating the specific workflow file and field, and requiring maintenance personnel to make corrections.

[0042] Step S104 is responsible for securely and reliably synchronizing the JSON file of the workflow to be deployed, which has passed the verification in step S102, from the source environment to the target environment. This step sequentially executes three stages: copying S1041, verifying S1042, and uploading S1043.

[0043] In the replication phase S1041, the system again uses a structured JSON parsing tool to parse each workflow JSON file to be deployed, traversing the environment-related fields and automatically replacing the parameter values ​​specific to the source environment with the parameter values ​​corresponding to the target environment. In some implementations, the environment-related fields include the settings.errorWorkflow field and the service address parameters of the HTTP / API node. The environment-related fields mainly include two categories: (1) Workflow-level error handling configuration. That is, the settings.errorWorkflow field, which is used to specify the global error handling workflow ID to be called when an error occurs in the current workflow. The system first reads the configuration information of the target environment, obtains its global error handling workflow ID, and then replaces the errorWorkflow field value in the workflow JSON to be deployed from the ID of the source environment (such as the test environment) to the corresponding ID of the target environment (such as the production environment). For the error handling workflow itself, this replacement step is skipped to avoid self-referencing. (2) Node-level service address parameters. Typically, the `parameters.url` field of an HTTP Request node, the callback address configuration of a Webhook node, and the connection string of a MySQL node may all contain environment-bound address information (e.g., `https: / / test.api.com / endpoint` needs to be replaced with `https: / / prod.api.com / endpoint`). The system uses a structured lookup and replace approach for intelligent adaptation based on predefined field mapping rules (e.g., specifying the fields to be replaced and their replacement logic using regular expressions or JSON path expressions). In addition, the workflow may contain other environment-bound parameters, such as hard-coded database connection strings and object bucket names in the Code node. For these parameters, the system can also adapt them based on predefined mapping rules. After completing the above parameter replacements, a JSON definition file for the workflow to be uploaded with correct environment parameters is obtained, which can be directly uploaded to the target environment. In some implementations, the `errorWorkflow` ID replacement further includes: skipping the replacement step for the error handler workflow itself to avoid self-referencing; and automatically supplementing the `errorWorkflow` field for non-error handler workflows that lack it, pointing to the error handler workflow ID of the target environment. In addition, the deployment pipeline automatically maintains the correctness of the errorWorkflow field when replicating across environments, ensuring that the business workflow in each environment points to the error handling workflow instance in that environment.

[0044] The verification phase S1042 is crucial for ensuring deployment correctness and comprises two sub-steps: identity matching and deep difference comparison. First, the system employs a three-level matching algorithm to determine the corresponding identity of the workflow to be uploaded in the target environment. In some implementations, the first level, business semantic primary key matching based on the Webhook path, includes: traversing the node list of the JSON definition file of the workflow to be uploaded and extracting the path identifier field value of the Webhook nodes; searching for workflows containing the same path parameter field value among existing workflows in the target environment; if a matching existing workflow is found, it is determined that the workflow to be uploaded and the existing workflow are the same business workflow, and the correspondence between the workflow to be uploaded and the existing workflow is established. The system extracts the parameter.path field value of all Webhook nodes in the definition of the workflow to be uploaded. Then, it pulls all existing workflows from the target environment (production environment) and constructs an index of {webhook_path:workflow_id}. If the Webhook path of the workflow to be uploaded (e.g., / api / content / generate_for_beauty) matches exactly with the path of an existing workflow in the production environment, then they are considered to be the same business workflow, and the match is successful. This is the highest priority matching strategy because the Webhook path is the business entry point and has uniqueness and stability.

[0045] Level 2: Matching based on a persistent ID mapping file. If the first-level match fails (e.g., due to a new workflow or a change in the Webhook path), the system queries a pre-persistent JSON mapping file. This file records the mapping between source environment workflow IDs and target environment workflow IDs in historical deployments. The system searches this mapping file to attempt to find a production environment workflow ID that matches the original ID of the workflow to be uploaded. For example, the system maintains a JSON mapping file of {source environment workflow_id: target environment workflow_id}. When the first-level match fails, it queries this mapping file; if a matching relationship exists, the match is considered successful.

[0046] Level 3: No matching found. If the first two levels fail to match, the system determines that there is no existing workflow in the target environment that corresponds to the workflow to be uploaded, meaning that the workflow is a completely new workflow.

[0047] The three-level progressive matching algorithm first performs a primary matching based on the business semantic primary key (Webhook path), and then performs a secondary matching based on the pre-stored ID mapping. It eliminates the need for manual maintenance of ID correspondences, significantly improving efficiency compared to manual matching and greatly reducing the probability of mismatches compared to single fuzzy matching. It solves the problem of "inability to balance automation and accuracy" in multi-environment workflow matching.

[0048] After determining the corresponding identity (whether by matching or by determining that it is a new one), the system performs a deep consistency comparison between the JSON definition file of the workflow to be uploaded and the existing workflow JSON data of the corresponding identity pulled from the target environment (for new workflows, the existing data is empty). In some implementations, the deep consistency comparison is a field-by-field comparison, and the detection content includes: field value differences, field type differences, field missing, array length differences, and the difference location is located by using the workflow engine schema path expression. The comparison uses a recursive depth-first traversal algorithm to compare the two JSON objects field by field. The algorithm will record all differences, including: (1) value differences: such as the value of nodes[0].parameters.url changing from http: / / test.api.com to http: / / prod.api.com. Such expected differences introduced by the replication phase will be identified and marked. (2) structural differences: such as the node nodes[2] not existing in the target environment's existing workflow, but existing in the file to be uploaded, which indicates an expected change of a new node. (3) Unexpected damage: For example, if the value of a field should be an array, but it becomes a dictionary in the file to be uploaded, this structural damage caused by improper modification will be accurately located and reported as an error. The difference location is accurately located using the workflow engine schema path expression (such as settings.errorWorkflow, nodes[3].parameters.url). Through deep difference comparison, the system can clearly show the specific changes that the deployment will bring and intercept any unexpected structural damage before deployment. The embodiments of this disclosure adopt a field-by-field deep traversal comparison algorithm and output the workflow engine schema path expression to accurately locate the difference location, so that maintenance personnel can quickly identify the expected changes and unexpected structural damage introduced by batch modification, significantly improving the efficiency of anomaly investigation before deployment and deployment security.

[0049] This phase adopts a "match identity first, then compare differences" workflow design. A three-level matching algorithm quickly identifies the unique workflow identity in the target environment, and then performs a deep difference comparison on this unique identity. Compared with the method of directly traversing and comparing all unmatched identities, the number of comparisons is reduced from O(N) to O(1), significantly improving deployment efficiency. At the same time, even if an identity matching error occurs, the subsequent deep comparison can detect unexpected differences and intercept the deployment, forming a double security guarantee.

[0050] It is important to note that the first-level Webhook path matching in this stage shares the same Webhook path uniqueness verification mechanism as the Webhook path uniqueness verification in the aforementioned batch security maintenance step S1023. Specifically, the path uniqueness verification in S1023 ensures that there are no duplicate or conflicting Webhook paths in all workflows within the source environment, thus guaranteeing that the workflow set output in the batch modification stage is structurally compliant at the business semantic level. Meanwhile, the path primary key matching in this stage, based on the same path index, accurately identifies the corresponding workflow identity in the target environment. Both are connected by the same index, achieving mutual verification and constraint between batch modification quality and deployment matching accuracy—if the batch modification stage misses path conflict checks, primary key matching will fail in the deployment stage, thus blocking the deployment process; conversely, if the matching logic in the deployment stage deviates, it will be detected because it cannot align with the constraints of the source environment verification stage. This design prevents defects in a single step from propagating to the production environment. In summary, in method S100, the batch security maintenance step and the security deployment step share the processing mechanism based on the structured JSON parsing tool, and the Webhook path primary key matching in the three-level matching algorithm and the Webhook path uniqueness verification in the multi-dimensional consistency verification are based on the same Webhook path index, thus forming a closed loop of full-chain security processing for the specific syntax structure of workflow JSON.

[0051] During the upload phase S1043, the system performs corresponding operations based on the identity correspondence determined during the verification phase.

[0052] 1. Update Operation: If a match is successfully found at the first or second level, indicating that the workflow to be uploaded corresponds to an existing workflow in the target environment, the system sends an update request to the target environment's API (e.g., using the HTTP PUT method), overwriting the JSON definition of the workflow to be uploaded as the new version. 2. Creation Operation: If no matching is found at the third level, the system sends a creation request to the target environment's API to create a new workflow. Upon successful creation, the system automatically writes the mapping between the source environment workflow ID and the newly generated workflow ID in the target environment (e.g., {source environment workflow_id: newly created target environment workflow_id}) into the aforementioned persistent ID mapping file for future deployments.

[0053] Before deployment, a deep consistency comparison is performed to locate differences. Then, based on the matching results, either update or create an application is selected. This avoids blind full coverage, further improving security from the deployment process level and reducing the risk of business failures caused by batch updates.

[0054] The method S100 provided in this embodiment replaces traditional batch text replacement with forced structured JSON parsing modification, and combines a two-step collaborative mechanism of "three-level progressive matching" and "deep consistency verification before deployment" to simultaneously take into account the efficiency of batch updates, the structural reliability of the modification process, and the accuracy of cross-environment identity matching, thus realizing a complete technical closed loop from secure batch modification to automated and reliable deployment.

[0055] The method S100 provided in this embodiment solves the complete problems of "how to modify correctly" and "how to deploy correctly" in large-scale workflow management scenarios through the progressive collaboration of two core steps: a secure batch maintenance pipeline and a three-level matching deployment algorithm. Specifically, the secure batch maintenance pipeline (corresponding to step S102) uses a forced structured JSON parsing tool to replace traditional batch text replacement, fundamentally avoiding JSON structure corruption and encoding errors, and is supplemented by multi-dimensional consistency verification to ensure that each workflow file after batch modification is structurally compliant and semantically correct before entering the deployment stage. This pipeline solves the reliability problem in the workflow development / maintenance stage. The three-level matching deployment algorithm (corresponding to S104) takes over the compliant files output in the previous step and accurately identifies the corresponding identity of each workflow to be deployed in the target environment through a progressive strategy of "Webhook path primary key matching → persistent ID mapping file matching → automatic creation"; combined with the automatic adaptation of environment parameters in the replication stage and the deep difference comparison in the verification stage, it realizes secure, accurate, and traceable batch deployment from the source environment to the target environment. This algorithm solves the identity recognition and environment adaptation problems in the workflow deployment / deployment phase. Two core steps are interconnected and mutually dependent: the secure batch maintenance pipeline provides high-quality file input for the deployment stage, preventing errors from propagating to the production environment; the three-level matching deployment algorithm relies on the structural integrity and path uniqueness verification results of the preceding outputs to efficiently complete identity matching and environment parameter adaptation. Together, they form a complete technical closed loop from "batch modification" to "secure deployment," effectively solving a series of chain problems in existing technologies, such as low efficiency, structural vulnerability, identity mismatch, and fault propagation, during batch cross-environment workflow updates.

[0056] To support the method S100, in some embodiments, such as Figure 2As shown, the system of this embodiment adopts a layered architecture, which consists of the following layers from top to bottom: interaction understanding layer, workflow design engine layer, multi-environment management layer, API abstraction layer, and security control layer. The layers communicate with each other through standardized data interfaces, and the data format between layers is uniformly JSON. The responsibilities of each layer are as follows: (1) Interaction understanding layer: receives the user's natural language business requirement description, extracts key semantic elements such as triggering method, data processing flow, and external service integration, and outputs structured requirement description objects to the lower layer. (2) Workflow design engine layer: contains two core components, a node template knowledge base and a workflow pattern library, and is responsible for mapping structured requirements to complete workflow JSON definition files. (3) Multi-environment management layer: maintains the configuration information of three independent environments: local development, testing, and production, and realizes automatic environment routing and deployment pipeline management. (4) API abstraction layer: encapsulates all HTTP communication with the workflow engine instance, provides a unified request / response processing interface, and shields the address and authentication differences of different environments. (5) Security control layer: spanning all levels, implementing security mechanisms such as script-level read-only interception, command whitelist filtering, and settings field filtering. Specifically, the core layers related to the technical solutions of this disclosure are the multi-environment management layer, the API abstraction layer, and the security control layer.

[0057] This disclosure adopts a standardized JSON data model as a unified data structure for workflow representation, storage, transmission, and cross-environment deployment. This data model ensures the consistency and integrity of the structure during batch modifications and cross-environment deployments. As shown in Table 2, the WorkflowDefinition contains the following core fields: Table 2 Core Fields of Workflow Definition

[0058] As shown in Table 3, each node contains the following fields: Table 3 Node Data Structure

[0059] The ConnectionMap uses a directed graph adjacency list structure, with the source node name as the key and the output port mapping as the value. Each output port contains a list of target nodes and supports the following topology modes: (1) Serial link: single target nodes are executed sequentially; (2) Conditional branch: multiple output ports of IF / Switch nodes are connected to different branches respectively; (3) Parallel fan-out: multiple target nodes are connected to the same output port; (4) Loop: the output of the processing node is connected back to the batch splitting node to form a directed loop.

[0060] For the SettingsObject configured at the workflow level, a field whitelist filtering mechanism is used to ensure cross-version compatibility. As shown in Table 4, only the following three core fields are retained, and the remaining non-core fields are filtered during cross-environment transmission and batch updates: Table 4 Whitelist of settings field

[0061] This whitelist filtering mechanism employs a two-level filtering algorithm: when creating or updating a workflow, the input JSON is first filtered at the top level, retaining only the five core fields: name, nodes, connections, settings, and staticData. Then, a second-level filtering is performed on the fields within settings, retaining only the three predefined core fields mentioned above. This filtering mechanism avoids interference from redundant fields caused by workflow engine version iterations, ensuring compatibility of workflow structures across different version environments after batch structured modifications, and improving the success rate of batch updates.

[0062] The system has a built-in node template knowledge base, which serves as the basic data source for workflow creation. It stores complete JSON structure templates for more than 15 node types. The knowledge base divides nodes into four categories according to function: trigger nodes, data processing nodes, HTTP / API nodes, and utility nodes. Each node template contains a complete parameter structure definition. The parameters support five data types: string, number, boolean, array, and object. Dynamic parameters are filled by the built-in expression engine.

[0063] The system has a built-in expression syntax engine for dynamic data binding between workflow nodes. All expressions use ={{}} as delimiters and support multiple syntax types such as current item field reference, cross-node data reference, execution context retrieval, runtime count, and time functions. It also supports JavaScript method chain calls to meet the real-time evaluation requirements of various dynamic parameters.

[0064] To address the large language model invocation requirements in content production scenarios, this disclosure defines a standardized LLM invocation parameter set, which unifies and standardizes core fields such as system prompts, user prompts, response formats, model parameters, and temperature parameters. This set can be automatically assembled into request messages that conform to the LLM API specification, simplifying the development process of large language model workflows in low-code scenarios.

[0065] Example 2 This disclosure provides a multi-environment workflow batch security update device 1000.

[0066] The update device 1000 may include corresponding modules that execute one or more steps in the flowchart of the multi-environment workflow batch security update method described above. Therefore, each or more steps in the flowchart can be executed by a corresponding module, and the update device 1000 may include one or more of these modules. A module may be one or more hardware modules specifically configured to execute a corresponding step, or implemented by a processor configured to execute a corresponding step, or stored in a readable storage medium for implementation by a processor, or implemented through some combination thereof.

[0067] Specifically, such as Figure 3 As shown, the updating device 1000 includes: Batch security maintenance module 1002 is used to perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: Export the workflow JSON file from the source environment to the local file system; The use of a structured JSON parsing tool is mandatory to perform structured parsing and modification of workflow JSON files on the local file system, and direct manipulation by text replacement tools is prohibited. After modification, perform multi-dimensional consistency verification and output a compliant JSON file of the workflow to be deployed; The security deployment module 1004 is used to synchronize the JSON file of the workflow to be deployed to the target environment, and executes it sequentially: Copying phase: The JSON file of the workflow to be deployed is parsed using a structured JSON parsing tool. The environment-related fields are traversed, and the source environment parameters are replaced with the parameters corresponding to the target environment to obtain the JSON definition file of the workflow to be uploaded. Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment. The workflow JSON definition file to be uploaded is then compared with the existing workflow JSON data of the corresponding identity pulled from the target environment to identify differences. The three-level matching algorithm is executed in sequence: the first level is based on the path information of the Webhook node in the workflow to perform business semantic primary key matching; the second level is based on the pre-persistent source environment ID-target environment ID mapping file to perform secondary matching; and the third level determines that there is no corresponding relationship. Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

[0068] This disclosure also provides an electronic device, including: a memory storing execution instructions; and a processor or other hardware module executing the execution instructions stored in the memory, causing the processor or other hardware module to execute the above-described multi-environment workflow batch security update method.

[0069] This disclosure also provides a readable storage medium storing execution instructions, which, when executed by a processor, are used to implement the above-described multi-environment workflow batch secure update method.

[0070] The hardware structure of the update device 1000, implemented using a processor-based hardware approach, can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0071] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component Architecture (EISA) bus, etc. Bus 1100 can be divided into address bus, data bus, control bus, etc. For ease of representation, only one connection line is used in this diagram, but this does not indicate that there is only one bus or one type of bus.

[0072] Any process or method description in the flowcharts or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain. The processor performs the various methods and processes described above. For example, the method embodiments of this disclosure may be implemented as software programs tangibly contained in a machine-readable medium, such as memory. In some embodiments, part or all of the software program may be loaded and / or installed via memory and / or a communication interface. When the software program is loaded into memory and executed by the processor, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the processor may be configured to perform one of the methods described above by any other suitable means (e.g., by means of firmware).

[0073] The logic and / or steps represented in the flowchart or otherwise described herein may be specifically implemented in any readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-based system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0074] For the purposes of this specification, a "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use in or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM). Furthermore, a readable storage medium can even be paper or other suitable media on which a program can be printed, since a program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in memory.

[0075] It should be understood that various parts of this disclosure can be implemented in hardware, software, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0076] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0077] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a readable storage medium. The storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0078] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A multi-environment workflow bulk security update method, characterized in that, The method includes: Batch security maintenance steps: Perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: Export the workflow JSON file from the source environment to the local file system; The use of a structured JSON parsing tool is mandatory to perform structured parsing and modification of workflow JSON files on the local file system, and direct manipulation by text replacement tools is prohibited. After modification, perform multi-dimensional consistency verification and output a compliant JSON file of the workflow to be deployed; Secure deployment steps: Synchronize the JSON file of the workflow to be deployed to the target environment, and execute the following steps in sequence: Copying phase: The JSON file of the workflow to be deployed is parsed using a structured JSON parsing tool. The environment-related fields are traversed, and the source environment parameters are replaced with the parameters corresponding to the target environment to obtain the JSON definition file of the workflow to be uploaded. Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment. The workflow JSON definition file to be uploaded is then compared with the existing workflow JSON data of the corresponding identity pulled from the target environment to identify differences. The three-level matching algorithm is executed in sequence: the first level is based on the path information of the Webhook node in the workflow to perform business semantic primary key matching; the second level is based on the pre-persistent source environment ID-target environment ID mapping file to perform secondary matching; and the third level determines that there is no corresponding relationship. Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

2. The method of claim 1, wherein, The method further includes: A multi-environment configuration dictionary is pre-generated. The multi-environment configuration dictionary stores the environment configuration information corresponding to the local development environment, test environment, and production environment. The environment configuration information of each environment includes the workflow engine instance address, API authentication information, and read-only flag. The system parses the user's input commands, extracts environment selection parameters, determines the target environment based on a semantic keyword matching algorithm, and loads the environment configuration information corresponding to the target environment from the multi-environment configuration dictionary. If the environment selection parameters are not extracted, the local development environment is determined as the target environment by default.

3. The method of claim 2, wherein, Before executing a write operation command to the target environment, the read-only flag of the target environment is queried; if the read-only flag is true, the write operation command is intercepted and its execution is terminated at the API client script layer.

4. The method of claim 3, wherein, The target environment is configured with an allowed command whitelist, which is stored using a hash set. The allowed command whitelist includes the following read operation commands: list, get, export, download-all, executions, and tags. Requests to the target environment are allowed only if the command to be executed belongs to the allowed command whitelist.

5. The method of claim 1, wherein, The multi-dimensional consistency verification includes the uniformity of node expression referencing methods, the uniformity of HTTP node header input methods, the uniqueness verification of Webhook paths, and the integrity of settings configuration fields.

6. The method of claim 1, wherein, The first-level business semantic primary key matching based on Webhook paths includes: Iterate through the list of nodes in the JSON definition file of the workflow to be uploaded, and extract the path identifier field value of the Webhook node; Search for workflows in the existing workflows of the target environment that contain the same path parameter field values; If a matching existing workflow is found, it is determined that the workflow to be uploaded and the existing workflow are the same business workflow, and the correspondence between the workflow to be uploaded and the existing workflow is established.

7. The method of claim 1, wherein, The source environment is a test environment, and the target environment is a production environment.

8. A multi-environment workflow bulk security update apparatus, comprising: The device includes: The batch security maintenance module is used to perform uniform structural modifications on multiple deployed workflow JSON files in the source environment, including: Export the workflow JSON file from the source environment to the local file system; The use of a structured JSON parsing tool is mandatory to perform structured parsing and modification of workflow JSON files on the local file system, and direct manipulation by text replacement tools is prohibited. After modification, perform multi-dimensional consistency verification and output a compliant JSON file of the workflow to be deployed; The secure deployment module is used to synchronize the JSON file of the workflow to be deployed to the target environment, and executes it sequentially: Copying phase: The JSON file of the workflow to be deployed is parsed using a structured JSON parsing tool. The environment-related fields are traversed, and the source environment parameters are replaced with the parameters corresponding to the target environment to obtain the JSON definition file of the workflow to be uploaded. Verification Phase: A three-level matching algorithm is used to determine the corresponding workflow identity of the workflow JSON definition file to be uploaded in the target environment. The workflow JSON definition file to be uploaded is then compared with the existing workflow JSON data of the corresponding identity pulled from the target environment to identify differences. The three-level matching algorithm is executed in sequence: the first level is based on the path information of the Webhook node in the workflow to perform business semantic primary key matching; the second level is based on the pre-persistent source environment ID-target environment ID mapping file to perform secondary matching; and the third level determines that there is no corresponding relationship. Upload phase: Perform update or creation operations based on the identity correspondence determined in the verification phase; if the verification phase determines that there is no correspondence, perform creation operations and persist the mapping relationship.

9. An electronic device, comprising: include: The memory stores execution instructions; as well as A processor that executes execution instructions stored in the memory, causing the processor to perform the method according to any one of claims 1-7.

10. A readable storage medium, characterized by, The readable storage medium stores execution instructions, which, when executed by a processor, are used to implement the method described in any one of claims 1-7.

Images