Methods, systems, and media for dynamic orchestration, strategy binding, and canary execution of business processes in industrial logistics

Abstract

This invention discloses a method, system, and medium for dynamic orchestration, strategy binding, and canary execution of business processes in industrial logistics, belonging to the field of industrial internet and intelligent manufacturing technology. It includes the following steps: constructing a logistics process model; bidirectional binding of process nodes and business strategies; canary release and isolated execution of process versions; context-aware dynamic routing execution; and end-to-end execution tracking and visualization analysis. Through technologies such as visualized process orchestration, dynamic strategy binding, canary release, and context awareness, it solves the technical problems of rigid business processes, difficult changes, and downtime required for version updates in traditional warehousing systems, achieving flexible configuration and efficient execution of industrial logistics business processes.

Description

Technical Field

[0001] This invention relates to a method, system, and medium for dynamic orchestration, strategy binding, and canary execution of business processes for industrial logistics, belonging to the field of industrial internet and intelligent manufacturing technology. Background Technology

[0002] With the development of intelligent manufacturing, modern warehousing and logistics systems face challenges such as complex and ever-changing business processes, high real-time requirements, and difficulties in equipment coordination. Traditional warehouse management systems mainly adopt the following technical solutions for business process management: 1. Hard-coded implementation: The business process logic is written directly in the code, and the process branches are controlled by if-else or switch-case statements.

[0003] 2. Configurable rule engine: Use rule engines such as Drools to manage business rules, but process control still needs to be implemented in code.

[0004] 3. General workflow engine: Introduces general workflow engines such as Activiti and Flowable, but lacks optimization for industrial logistics scenarios.

[0005] Existing technologies also include some optimization solutions for warehouse management or process deployment, such as: Chinese patent application CN121414265A, entitled "A Warehouse Management System and Management Method for Logistics Supply Chain," discloses a logistics warehouse management solution. It achieves information-based management of warehouse operations by building an integrated system including inbound management, inventory management, and outbound management modules. Its process logic is implemented through pre-defined module interfaces, supporting basic warehouse operation scheduling. However, its warehouse management process still adopts a fixed module coupling design. Business process changes require modification of module interface code, making rapid adjustments impossible through visual orchestration, resulting in long response cycles. Furthermore, it lacks real-time operational status awareness; process branch decisions are based on static configuration, unable to adjust execution paths according to dynamic data such as AGV status and warehouse space occupancy, leading to weak anomaly response capabilities.

[0006] Chinese patent application CN121070427A, entitled "A Method, Apparatus, Device, Media, and Program Product for Continuous Deployment Based on Gray-Scale Scale," discloses a general software gray-scale release scheme. This scheme achieves smooth software version switching through a version gray-scale strategy, reducing the risk of version updates, and is primarily applied to the deployment phase of general software systems. However, this gray-scale release scheme is designed for general software scenarios and does not consider the special requirements of industrial logistics scenarios where process instances are bound to production equipment and need to run continuously 24 / 7. It cannot achieve multi-version isolated execution of process definitions, nor does it support refined gray-scale strategies based on tenants, business types, or other dimensions, making it difficult to directly apply to process version updates in industrial warehouse management systems.

[0007] Based on the shortcomings of the aforementioned traditional technical solutions and published patents, the existing technologies as a whole suffer from the following common technical problems: The response time for business changes is long. With hard-coded methods, if a process needs adjustment (such as adding a quality inspection step before warehousing), it requires code modification, recompilation, testing, and deployment, with the entire cycle typically taking 2-5 days. This severely restricts business agility for modern manufacturing industries that need to respond quickly to market changes.

[0008] 4. The process control and business logic are heavily coupled. In traditional implementations, process transition logic and specific business operations (such as calling AGV interfaces and querying inventory) are mixed in the same method, resulting in poor code readability and high maintenance costs. When business logic is adjusted, the process control code is easily modified by mistake, causing system failures.

[0009] Version updates require system downtime for maintenance. When updating process definitions, general workflow engines typically need to stop all currently executing process instances, or allow both old and new versions to coexist without fine-grained control over which instances use the new version. This is unacceptable in industrial scenarios with continuous 24 / 7 production.

[0010] Lack of real-time operational condition awareness. Existing systems typically make process branch decisions based on static configuration or snapshot data at startup, failing to dynamically adjust paths according to real-time operational conditions during execution (such as sudden AGV failures or temporary occupancy of storage spaces), resulting in rigid process execution and weak anomaly handling capabilities.

[0011] The process execution is not traceable. Traditional systems lack fine-grained records of the process execution, making it difficult to pinpoint which step went wrong when anomalies occur, and also making it impossible to calculate the average execution time of each node to optimize bottlenecks. Summary of the Invention

[0012] The purpose of this invention is to propose a method, system, and medium for dynamic orchestration, strategy binding, and canary execution of business processes in industrial logistics. By using technologies such as visualized process orchestration, dynamic strategy binding, canary release, and context awareness, this invention solves the technical problems of rigid business processes, difficult changes, and downtime required for version updates in traditional warehousing systems, thereby achieving flexible configuration and efficient execution of industrial logistics business processes.

[0013] On the one hand, this invention provides a method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics, including the following steps: S1: Logistics process model construction: Extend the standard process modeling meta-model, define the set of process nodes in industrial logistics scenarios, and generate standardized process definition files through visual orchestration tools.

[0014] S2: Two-way binding between process nodes and business policies: Establishes a mapping relationship between process nodes and policy rules, supports multiple binding modes, performs policy validity verification in the process definition stage, and triggers the corresponding policy in the process execution stage.

[0015] S3: Process Version Gray Release and Isolated Execution: Implements multi-version management for process definitions, supports various gray release strategies, and enables isolated operation and version rollback of new and old version process instances.

[0016] S4: Context-aware dynamic routing execution: Construct a process context set containing static parameters and dynamic operating condition data, and make dynamic routing decisions based on real-time context data at process routing nodes.

[0017] S5: End-to-end execution tracing and visualization analysis: Collects execution data of the entire lifecycle of process nodes to enable visualization playback and performance analysis of the execution process.

[0018] Furthermore, the extended standard process modeling meta-model in step S1 is a BPMN 2.0 meta-model, and the defined set of process nodes for the industrial logistics scenario includes AGV task nodes, inventory operation nodes, strategy triggering nodes, manual confirmation nodes, and conditional exclusive gateways; the visual orchestration tool is a visual drag-and-drop editor, and the generated standardized process definition file is an XML format file conforming to the BPMN 2.0 standard.

[0019] Furthermore, the AGV task node integrates a state machine, with states including pending, issued, executing, picking, picking completed, unloading, unloading completed, completed, failed, and canceled. During execution, it automatically calls the RCS interface to issue the task and starts an asynchronous listening thread to periodically query the task status until the final state is reached. The inventory operation node encapsulates interfaces for locking, unlocking, deducting, and adding inventory, and dynamically reads the storage location ID and storage location code attributes from process variables. The strategy trigger node is used to trigger an external strategy engine to decouple business rules from process definitions, including two modes: pre-binding and post-binding. The manual confirmation node is used for exception handling or confirmation of key steps, and is bound to mobile or web forms. The conditional exclusive gateway supports conditional expressions that reference dynamic variables.

[0020] Furthermore, the binding modes in step S2 include pre-binding and post-binding: pre-binding triggers the strategy before the node executes, and the strategy execution result is used as the node input parameter; post-binding triggers the strategy after the node executes successfully, and is used to execute subsequent linkage services.

[0021] Furthermore, the policy validity verification is performed during the process definition saving phase. The policy code of all policy triggering nodes is parsed, and the policy engine health check interface is called to verify the policy validity. If the policy does not exist or is disabled, the process saving is prevented and an error is prompted. If the policy execution throws an exception during the process execution phase, the process direction is determined according to the exception handling policy configured for the node, including terminating the process, skipping the current node, retrying the policy execution, or switching to the exception handling subprocess.

[0022] Furthermore, the canary release strategy in step S3 includes canary release based on tenant ID, canary release based on business type, and canary release based on random ratio: canary release based on tenant ID specifies that the tenant uses the new version of the process, while other tenants use the old version; canary release based on business type only uses the new version for process instances of the specified business type; canary release based on random ratio sets the canary release ratio, and newly initiated process instances use the new version according to the corresponding probability.

[0023] Furthermore, the multi-version management of the process definition is as follows: each time a process definition is released, a version number in the format Major.Minor.Build is automatically generated. The process engine stores multiple versions of the process definition, and only marks one version as the default version. When a new process instance starts, an execution instance is created based on the current default version. The old version process instance that is currently running is not affected by the release of the new version. Version rollback is achieved by updating the default version marker, and the rollback operation takes less than 100ms.

[0024] Furthermore, the process context set in step S4 includes static variables and dynamic variables: static variables are fixed parameters passed in when the process starts, including material type, task type, and tenant ID; dynamic variables are operating condition data collected in real time during runtime, including AGV real-time coordinates, warehouse occupancy rate, equipment online status, and battery power.

[0025] Furthermore, the dynamic routing execution uses the SPI mechanism to collect runtime condition data in parallel and implements local LRU caching for dynamic variables with an expiration time of 30 seconds. The configuration expression of the condition gateway supports referencing dynamic variables. After the engine parses the expression, it calculates a Boolean value based on real-time data to determine the flow branch direction. If the acquisition of dynamic variables times out or fails, the preset default value is used or the exception handling subprocess is entered.

[0026] On the other hand, this invention provides a visualized business process dynamic orchestration, strategy binding, and canary execution system for industrial logistics. Based on the above method, it is implemented using a four-layer architecture, including: The basic support layer provides underlying technical capabilities, including the Flowable process engine kernel, Redis caching and distributed lock components, Elasticsearch log storage components, and MySQL persistent database; The engine extension layer, based on the Flowable kernel, includes five core extension components: logistics node parser, policy binding interceptor, gray-scale routing filter, context variable injector, and end-to-end tracing aspect. The core functional layer comprises five functional modules: including: The logistics process modeling module is used to extend the standard process modeling metamodel, define the set of process nodes in industrial logistics scenarios, and generate standardized process definition files through visual orchestration tools. The process and strategy binding module is used to establish the mapping relationship between process nodes and business strategies. It supports multiple binding modes, performs strategy validity verification during the process definition stage, and triggers the corresponding strategy during the process execution stage. The canary release and isolated execution module is used to implement multi-version management of process definitions, supports various canary release strategies, and realizes the isolated operation of new and old version process instances and version rollback; The context-aware routing execution module is used to construct a process context set containing static parameters and dynamic operating condition data, and to make dynamic routing decisions based on real-time context data at the process routing node; The end-to-end tracing and visualization analysis module is used to collect execution data throughout the entire lifecycle of process nodes, enabling visualized playback and performance analysis of the execution process. The application layer includes two interactive entry points: a visual designer and a monitoring and tracking platform, providing operation interfaces for process designers and operation and maintenance managers, respectively.

[0027] On the other hand, the present invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the described method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics.

[0028] Compared with existing technologies, the present invention's method, system, and medium for dynamic orchestration, strategy binding, and canary execution of business processes for industrial logistics exhibit the following beneficial effects in terms of technical performance and practical application: 1. Improved Efficiency for Business Changes. Through a visual process designer, business personnel can directly drag and drop nodes to adjust processes without writing code. The response time for process changes has been reduced from 2-5 days to less than 30 minutes. In a certain home appliance manufacturing company, over 120 process adjustments were made throughout the year, with an average configuration time of only 20 minutes per adjustment.

[0029] 2. Significantly improved code maintainability. The process control logic is completely decoupled from the business logic. Process definitions are stored in XML format, and business logic is encapsulated in a separate Service class. The number of lines of code is reduced by 40%, cyclomatic complexity is reduced by 60%, and the onboarding time for new employees is shortened from 2 weeks to 3 days.

[0030] 3. Achieve zero-downtime version updates. Through a canary release mechanism, new and old version process instances are executed in isolation, and version switching requires no downtime. In a certain automobile manufacturing company, more than 50 process version updates have been completed without a single production interruption, and the version rollback time is less than 100ms.

[0031] 4. Improved intelligence in process execution. Through a context-aware mechanism, the process can dynamically adjust its path based on real-time operating conditions. For example, when the AGV's battery level is detected to be below 20%, a charging step is automatically initiated; when the warehouse area is congested, an alternative path is automatically selected. Actual operation data shows that the process execution success rate has increased from 92% to 99.5%.

[0032] 5. Improved problem localization efficiency. Through end-to-end tracing and visual playback, operations and maintenance personnel can quickly locate faulty nodes. The average troubleshooting time has been reduced from 2 hours to 20 minutes. Simultaneously, based on bottleneck analysis of execution data, 15 high-frequency processes have been optimized, reducing their average execution time by 35%. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall process of the method of the present invention; Figure 2 This is a diagram showing the types of logistics nodes in the implementation of this invention; Figure 3 This is a diagram illustrating the bidirectional binding relationship between process nodes and policy rules in an embodiment of the present invention. Figure 4 This is a diagram illustrating the canary release mechanism for the process version in an embodiment of the invention. Figure 5 This is a timing diagram of the execution of context-aware dynamic routing in an embodiment of the present invention; Figure 6 This is a schematic diagram of the full-link execution tracing and visualization playback interface in an embodiment of the present invention; Figure 7 This is a flowchart illustrating an application example in an embodiment of the present invention; Figure 8 This is a diagram showing the overall architecture of the system in the implementation of this invention. Detailed Implementation

[0034] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0035] Example 1: like Figure 1 As shown, the method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics described in this invention includes the following steps: S1: Logistics process model construction: Business personnel can select industrial logistics nodes (AGV task nodes, inventory operation nodes, etc.) through a visual drag-and-drop editor to form business processes. The editor, implemented using the Vue.js framework, supports node drag-and-drop, automatic connection snapping, and a property configuration panel. Node property configuration supports parameterized input, and all configuration items undergo format validation. After arrangement, the system automatically generates a process definition file in XML format conforming to the BPMN 2.0 standard. The file contains complete information such as node ID, node name, connection relationships, and property configurations. It supports import / export and version snapshot storage, with the version number automatically generated in Major.Minor.Build format. This enables non-technical personnel to quickly configure business processes.

[0036] S2: Two-way binding between process nodes and policy rules: Configure pre- or post-binding strategies for process nodes. Strategy codes are selected from the strategy engine's strategy library, supporting fuzzy search and categorized filtering. After the binding relationship is configured, the system automatically calls the strategy engine's health check interface to verify the existence, availability, and parameter matching of the strategy. If the verification fails, process saving is prevented and a specific error message is provided. Successfully verified binding relationships are stored in a strategy binding table in a relational database, associated with the process ID and node ID, supporting batch querying and modification. This achieves decoupling between process control logic and business logic.

[0037] S3: Canary release of process version: Multi-version management is implemented for process definitions, automatically generating a new version number with each release, supporting the storage of up to 100 historical versions. A canary release strategy is configured during release, supporting combinations of three strategies: tenant ID, business type, and random proportion. Strategy rules are stored in JSON format, allowing for dynamic modification without system restart. After the canary release rules are configured, the default version tag is updated to the new version, and newly initiated process instances are matched to the corresponding process version according to the canary release rules. This achieves smooth switching between process versions.

[0038] S4: Context-aware dynamic routing execution: When the process engine starts a process instance, it first initializes static context variables, then collects runtime condition data in parallel through SPI extension points, and implements a local LRU cache for dynamic variables with a default expiration time of 30 seconds. At the process routing node, the engine parses the context variables referenced by SpEL expressions, calculates Boolean values ​​based on real-time data to determine the process branch direction. If variable retrieval times out or fails, it uses preset default values ​​or enters an exception handling subprocess. When a node executes, it triggers the bound strategy, passing the context variables as input parameters. This implements dynamic routing based on real-time conditions.

[0039] S5: End-to-end tracing and visual playback: The process engine uses AOP aspects to intercept the entire lifecycle events of node execution, collecting data such as node ID, node name, start time, end time, input parameters, output results, exception information, and operator ID. The collection latency is less than 10ms, ensuring no impact on normal process execution. The collected data is asynchronously written to Elasticsearch, with indexes created daily, supporting terabyte-level data storage. Users can view the execution chain diagram and execution sequence diagram through a visual interface, and statistically analyze metrics such as average execution time and success rate for each node. The system automatically identifies process bottlenecks and provides optimization suggestions, achieving traceability and optimization of the execution process.

[0040] Specifically, the class structure of the industrial logistics scenario process node set defined by the extended standard BPMN 2.0 metamodel in this invention is as follows: Figure 2As shown, the specific implementation details of each node are as follows: (1) Base Node Class: All industrial logistics process nodes inherit from the FlowNode base class defined in the standard BPMN 2.0 specification. The base class encapsulates three types of general attributes and two types of core abstract methods, providing a unified execution specification for all subclasses: The general attributes include three fields: globally unique identifier (id), node display name (name), and node type (type). The id is generated in 32-bit UUID format, globally unique and cannot be repeated, and serves as the unique index of the node. The name supports mixed Chinese and English input, with a maximum length limit of 100 characters, and is used for node display in the visual designer. The type is an enumeration type, with values ​​including AGV_TASK (AGV task node), STOCK_OPERATION (inventory operation node), POLICY_TRIGGER (strategy trigger node), MANUAL_CONFIRM (manual confirmation node), and EXCLUSIVE_GATEWAY (conditional exclusive gateway). The engine uses this field to identify the node type and call the corresponding execution logic.

[0041] The base class defines an abstract method that is enforced to execute(): the execute() method encapsulates the core logic of the node's forward execution. The process engine automatically calls this method when scheduling nodes, and the execution result will determine the subsequent direction of the process.

[0042] (2) AGV Task Node: Inherited from BPMNNode, it is specifically used to encapsulate the execution logic of AGV material transfer tasks and is the core node for realizing automated equipment scheduling in industrial logistics scenarios: Exclusive Attributes: Task Type (taskType): String type, identifies the business type of the AGV task, which can be configured as common AGV operation types such as unloading, loading, moving, and charging; Priority: An integer that identifies the scheduling priority of a task. The value range is usually 0-9. The larger the number, the higher the priority. The RCS system prioritizes scheduling high-priority tasks. Timeout: Integer type, in seconds, defines the maximum execution time of the task. If the task is not completed within this time, it is considered to have timed out and the exception handling logic is triggered.

[0043] Exclusive method: DispatchToRCS(): This function encapsulates the interface call logic with the AGV scheduling system (RCS), automatically assembles task parameters, sends the task request to the RCS, and obtains the unique task ID returned by the RCS. Monitor Status (monitorStatus()): Encapsulates the asynchronous listening logic for task status. It obtains the real-time status of tasks by periodically calling the RCS query interface, driving the internal state machine flow of the node.

[0044] The `execute()` method executes as follows: After the node starts, it first reads dynamic parameters such as the currently available AGV ID and task priority from the process context variables, calls the `dispatchToRCS()` method to send a task request to the RCS system, and obtains the unique task ID returned by RCS. Then, it starts an independent asynchronous listening thread, calls the `monitorStatus()` method to query the RCS for the real-time status of the task every 100ms, and drives the built-in state machine to flow forward in the order of "pending dispatch → dispatched → executing → picking → picking completed → unloading → unloading completed → completed". If the status changes to failure or cancellation, and the current number of retries has not exceeded the `retryCount` configuration value, the task is automatically re-dispatched. If the number of retries exceeds the limit and the task still fails, an execution exception is thrown, triggering the process rollback logic.

[0045] (3) StockOpNode: Inherited from BPMNNode, it is specifically used to encapsulate the change operation logic of warehouse inventory, realizing automatic interaction between the process engine and the WMS warehouse management system. Exclusive Attributes: Stock ID (stockId): Long integer, a unique code that identifies the target stock location to be operated on. It supports dynamic reading of variables from the process context to adapt to the operation requirements of different stock locations. Material ID (materialId): A string type that uniquely identifies the material to be operated on and is used to verify the correctness of inventory operations; Operation Quantity: Integer type, defines the quantity of materials for this inventory operation. It supports configuring fixed values ​​or referencing process context variables to achieve dynamic quantity operations.

[0046] Exclusive method: Lock Stock(): Encapsulates the inventory locking logic, using a distributed lock to lock the corresponding inventory in the target storage location, avoiding overselling of inventory caused by concurrent operations; Update Inventory (updateInventory()): Encapsulates the actual inventory change logic, calls the WMS system interface to perform operations such as locking, unlocking, deducting, and adding inventory, and synchronizes the execution results to the process context.

[0047] (4) StrategyTriggerNode: Inherited from BPMNNode, it is specifically designed to decouple process logic from business rules, supporting the separation of volatile business rules from fixed process structures: Exclusive Attributes: Strategy Code: A string type that serves as a unique identifier for business rules in the external strategy engine, used to locate the specific strategy to be executed; BindingType: String type, defines when the strategy is triggered. It can be configured as pre-binding or post-binding. Pre-binding triggers the strategy before the associated business node is executed, while post-binding triggers the strategy after the associated business node is successfully executed.

[0048] Exclusive method: TriggerStrategy(): Encapsulates the interface call logic with the external strategy engine, passes the current process context variable as input parameter to the strategy engine, and executes the corresponding business rules; HandleResult(): Encapsulates the parsing logic for the strategy execution result, stores the output parameters returned by the strategy in the process context for subsequent nodes to call, and triggers exception handling logic if the strategy execution fails.

[0049] (5) ManualConfirmNode: Inherited from BPMNNode, it is specifically used to encapsulate the review and confirmation operations that require manual intervention in industrial logistics scenarios, realizing the combination of automated processes and manual intervention: Exclusive Attributes: Form Key: A string type, a unique identifier for the business form to be filled out, used to associate the corresponding confirmation form template; Approval Role: A string that defines the user role code that has the authority to process this confirmation task. It supports pushing tasks to be done by role group without binding to a specific user.

[0050] Exclusive method: Wait for Approval (waitForApproval()): Encapsulates the full lifecycle management logic of pending tasks, including pushing task notifications to specified roles, listening for user submission results, and handling timeouts and unapproved tasks. The form data submitted by the user will be automatically stored in the process context for use by subsequent nodes.

[0051] The two-way binding mechanism between process nodes and business strategies in this invention is as follows: Figure 3 As shown, it is divided into two parts: design-state binding and runtime triggering. The specific implementation details are as follows: The design-state binding mechanism comprises three core components: a strategy configuration module, a binding relationship verification module, and a binding relationship storage module. The strategy configuration module provides a visual configuration interface, allowing users to select binding strategies for process nodes, configure binding modes (pre- / post-), ​​execution order, exception handling rules, and other parameters. It supports binding multiple strategies to a single node, executing them sequentially according to the configured order. The binding relationship verification module executes automatically when the user saves the process definition. It first parses the strategy code of all strategy trigger nodes, then calls the strategy engine's health check interface to verify the existence, availability, and matching of input and output parameters of the strategies. If a strategy does not exist, is disabled, or its parameters do not match, the process saving is prevented, and a specific error message is given, ensuring the binding relationship is legal and valid. Verified binding relationships are stored in a strategy binding table in a relational database, associated with information such as process ID, node ID, strategy ID, binding mode, execution order, and exception handling rules. Batch querying and modification are supported.

[0052] Pre-binding mechanism: Pre-binding triggers the strategy before node execution, and the strategy execution result serves as the node's input parameter. The specific implementation steps are as follows: 1. Before a node is executed, the strategy code, matching conditions, and execution parameters of the strategy trigger node are parsed.

[0053] 2. Call the corresponding strategy engine based on the strategy code.

[0054] 3. Pass the matching conditions and execution parameters to the strategy engine.

[0055] 4. The strategy engine queries the corresponding business rules based on the matching conditions, executes the rule logic, and returns the execution results.

[0056] 5. Inject the strategy execution results into process variables as input parameters for nodes.

[0057] 6. The node uses these parameters to perform subsequent operations.

[0058] Post-binding mechanism: Post-binding triggers a strategy after a node executes successfully, used to execute subsequent linked business logic. The specific implementation steps are as follows: 1. After a node executes successfully, the strategy code, matching conditions, and execution parameters of the strategy trigger node are parsed.

[0059] 2. Pass the execution result of the node as an input parameter to the strategy engine.

[0060] 3. The strategy engine queries the corresponding business rules based on the matching conditions, executes the rule logic, and returns the execution results.

[0061] 4. Execute subsequent linked business based on the strategy execution results, such as synchronizing inventory, sending messages, creating new tasks, etc.

[0062] Exception handling mechanism: The policy triggering node supports configuring exception handling policies, including: TERMINATE: Terminates the execution of the current process instance and logs any exception information.

[0063] SKIP (Skip the current node): Skip the execution of the current policy-triggered node and continue executing subsequent nodes.

[0064] RETRY (Retry Policy Execution): Re-execute the policy according to the configured number of retries and retry interval. If the number of retries is exhausted and the attempt still fails, proceed to the exception handling sub-process.

[0065] SUBPROCESS (Transfer to Exception Handling Sub-process): Transfers to a dedicated exception handling sub-process, where exception handling logic is executed, such as logging the exception, sending a notification, and performing compensation operations.

[0066] The two-way binding mechanism between process nodes and policy rules further includes: This invention establishes a mapping table between process nodes and business strategy rules, and designs a complete binding verification mechanism. The implementation of this mechanism is described in detail below.

[0067] Mapping table design: Establish a mapping table between process nodes and business strategy rules. The table structure includes id (primary key), process_def_key (process definition key), process_def_version (process version number), node_id (node ​​ID), strategy_code (strategy code), and binding_type (binding type, 1 for pre-requirement / 2 for post-requirement).

[0068] Table 1 Mapping Relationship Table

[0069] This table structure supports different versions of the same process using different strategy binding configurations, achieving versioned strategy management. The `process_def_key` and `process_def_version` fields uniquely identify a process definition version; the `node_id` and `strategy_code` fields uniquely identify the binding relationship between a node and a strategy.

[0070] Binding verification mechanism: During the process definition saving phase, the policy code of all policy trigger nodes is parsed, and the health check interface of the policy engine is called to verify the validity of the policy code. If the policy is disabled or does not exist, the process saving is prevented and an error is displayed.

[0071] During the process execution phase, if the strategy bound to the strategy trigger node throws an exception during execution, the process direction is determined according to the exception handling strategy configured for the node: terminate the process, skip the current node, retry strategy execution, or switch to the exception handling subprocess.

[0072] The process version canary release and isolated execution mechanism of this invention is as follows: Figure 4 As shown, it includes four core components: version management, canary deployment routing, isolated execution, and version rollback. The specific implementation details are as follows: (1) Version Management: Each time a process definition is released, the system automatically generates a version number in the format Major.Minor.Build. Major is the primary version number, incrementing when a major architectural change occurs in the process; Minor is the secondary version number, incrementing when new features are added or process logic is adjusted; and Build is the revision number, automatically incrementing with each release. The process engine supports storing up to 100 historical versions of the process definition. Each version includes a complete process XML file, strategy binding relationships, version release time, publisher, and other information. Only one version is marked as the default version. The version list supports querying, comparison, and exporting operations, allowing users to view the differences between any two versions.

[0073] (2) Gray-scale routing: Supports three gray-scale strategies: tenant ID, business type, and random ratio, which can be used in combination. The tenant ID-based gray-scale strategy specifies a list of tenant IDs, and only process instances belonging to these tenants use the new version of the process, while other tenants use the old version. The business type-based gray-scale strategy specifies a list of business types, and only process instances of the corresponding business type use the new version. The random ratio-based gray-scale strategy sets a gray-scale ratio of 0-100%, and newly initiated process instances randomly use the new version according to the corresponding probability. Gray-scale rules are stored in JSON format, support dynamic modification without restarting the system, and take effect immediately after modification. When a new process instance starts, the gray-scale routing engine matches according to the configured gray-scale rules and assigns the corresponding process version to the instance.

[0074] (3) Isolation of Execution Phases: Different versions of process instances use independent execution contexts and scheduling queues, ensuring no interference between them. The process engine maintains an independent thread pool and task queue for each version of the process definition, avoiding resource contention between instances of different versions. Running older version process instances are unaffected by new version releases and continue to execute according to the original process definition until completion, ensuring business continuity. When a node executes, it reads configuration information and policy binding relationships from the corresponding version of the process definition to ensure that the execution logic is consistent with the version.

[0075] Version rollback process: When a problem occurs while running a new version, users can perform a rollback operation through the version management interface. The system only needs to update the default version flag; no service restart is required, and the rollback operation takes less than 100ms. After the rollback, newly initiated process instances will use the rolled-back default version. Newly running version instances can choose to continue execution or be forcibly terminated and rolled back to the old version. The rollback operation supports audit logging, recording information such as rollback time, operator, and rollback reason, facilitating problem tracing.

[0076] The context-aware dynamic routing architecture of this invention is as follows: Figure 5 As shown, the specific implementation details are as follows: (1) Definition of dynamic variables: Defines the set of dynamic variables that can be used in the process, including: Static variables: Material type, Task type, Tenant ID (passed in when the process starts); Dynamic variables: AGV real-time coordinates, warehouse occupancy rate, equipment online status, battery level (obtained at runtime); (2) Variable provider interface: Define the VariableProvider interface, and implement this interface for different business domains: public interface VariableProvider { String getDomain(); / / Domain name, such as "agv", "stock", "device" Map<String, Object> getVariables(Set <string>variableNames); } Example of implementation class: AgvVariableProvider: Gets AGV location, battery level, and status; StockVariableProvider: Gets storage space occupancy rate, inventory quantity, and storage space status; DeviceVariableProvider: Obtains PLC online status, PLC register values, and sensor readings; (3) Parallel data acquisition: Before the process reaches a node that requires dynamic variables, the engine loads the corresponding variable provider through the SPI (Service Provider Interface) mechanism to obtain the required variables in batches. Variable retrieval adopts a parallel call mode.

[0077] (4) Multi-level caching strategy: To prevent excessive device load due to frequent calls, a local cache (Caffeine) is implemented for dynamic variables, using the Least Recently Used (LRU) strategy with an expiration time of 30 seconds. The cache key format is {domain}:{variableName}:{resourceId}.

[0078] (5) Dynamic routing decision: The configuration expressions for the condition gateway support referencing dynamic variables. The engine parses the expressions, calculates Boolean values ​​based on real-time data, and determines the flow branch direction. If the dynamic variable retrieval times out or fails, a preset default value is used or the exception handling sub-flow is entered.

[0079] The end-to-end execution tracing and visualization replay data structure of this invention is as follows: Figure 6 As shown, it includes three modules: data acquisition, data storage, and visualization analysis. The specific implementation details are as follows: (1) Data Acquisition Module: This module intercepts all lifecycle events of node execution through the AOP aspect of the process engine, including events such as node start execution, execution completion, execution failure, rollback start, and rollback completion. The acquired data includes fields such as node ID, node name, process instance ID, process version number, start time, end time, input parameters, output results, exception information, and operator ID. Data acquisition is asynchronous, using a message queue to buffer acquired events, avoiding blocking normal process execution. The acquisition latency is less than 10ms, and its impact on process performance is negligible. The acquisition module supports on / off control, allowing users to enable or disable the tracing function for specific processes as needed.

[0080] (2) Data Storage Module: Elasticsearch is used as the storage engine, specifically for storing execution tracing data, isolated from business data storage. Indexes are created daily, and automatic cleanup of historical data exceeding the retention period is supported. The retention period is configurable, with a default retention period of 90 days. Each execution record is associated with the process instance ID and version number, supporting multi-dimensional retrieval by process instance ID, node ID, time range, operator, etc. The storage module supports TB-level data storage, ensuring data reliability and query performance through sharding and replication mechanisms, with a single data query response time of less than 100ms.

[0081] (3) Visualization and Analysis Module: This module includes three core components: an execution chain visualization component, an execution sequence diagram component, and a performance statistics and analysis component. The execution chain visualization component graphically displays the complete execution path of a process instance, with different colors used to identify nodes in different states. Hovering the mouse over a node allows you to view its detailed execution information. The execution sequence diagram component displays the execution timeline of each node in chronological order, intuitively showing the execution duration and parallel relationships of each node. The performance statistics and analysis component supports statistics on the average execution duration, execution success rate, and number of exceptions for each node, automatically identifying bottlenecks where the execution duration exceeds a threshold and providing optimization suggestions. It also supports replaying the complete execution process by process instance, helping maintenance personnel quickly locate faults.

[0082] like Figure 7 As shown, this embodiment is applied to the intelligent warehouse management system of a home appliance manufacturing company, with the scenario being the outbound task of a 55-inch smart TV. The specific execution flow is as follows: Initiate outbound task: After a sales order is placed, the WMS system initiates a finished goods outbound task, passing in the following process start parameters: Material ID=TV-55UHD, Outbound Quantity=2, Target Storage Location=A03-05-08, Business Type=Normal Outbound, Tenant ID=TENANT001.

[0083] The process engine selects the process version for gray-scale routing: Based on the configured 10% random gray-scale strategy, if the task hits the gray-scale rule, it will select the new version 1.3.0 process definition for execution, while the remaining 90% of tasks will still use the stable version 1.2.5.

[0084] Load the corresponding version of the process definition: The engine loads the outbound process XML definition with version number 1.3.0 from the database and parses it into an internally executable process object.

[0085] The context-aware engine collects data in parallel: It calls AgvVariableProvider and StockVariableProvider in parallel through the SPI mechanism to collect real-time data: AGV_08 status = idle, power = 88%, coordinates = (X=12.3, Y=45.6); target storage location A03-05-08 status = occupied, material = TV-55UHD, quantity = 2; the data is stored in the local LRU cache with an expiration time of 30 seconds.

[0086] Execute the pre-set strategy binding: Trigger the pre-set strategy AGV_ALLOC_001, and allocate the optimal AGV as AGV_08 based on the comprehensive score of real-time AGV status, distance, and power consumption. Configuration parameters: priority=7, timeout=180 seconds, number of retries=2.

[0087] Create AGV task node: Unload task: Instantiate AGV task node, configure attributes: Task type=Unload, Starting location=A03-05-08, Ending location=B01-02-03, Material ID=TV-55UHD, Quantity=2, Specify AGV number=AGV_08.

[0088] Call the RCS interface to issue a task and obtain the TaskID: When the node is executed, call the RCS (Robot Scheduling System) task creation interface, pass in the task parameters, and get the returned TaskID=TASK20260518001.

[0089] Start a 100ms polling listener thread: Start an asynchronous listener thread that calls the RCS task query interface every 100ms to get the real-time execution status of TASK20260518001.

[0090] AGV state machine execution: The state machine of the AGV task node flows in sequence: Pending issuance → Issued → Executing → Picking up → Picking up completed → Unloading in progress → Unloading completed → Completed. Each state change is synchronously updated to the process instance variables.

[0091] Task completion status determination: If the listening thread detects that the task status has changed to "completed", it determines that the task has been completed normally and enters the normal process branch; if the status is "failed", it enters the exception handling branch.

[0092] Exception handling branch: If the task fails, first, automatically retry twice, with a 30-second interval between each retry; if it still fails after two retries, it is determined that the retry was unsuccessful, and the exception self-healing logic is executed: automatically allocate a backup AGV_11, dynamically adjust the execution path to bypass the congested warehouse area, and reissue the task for execution.

[0093] Execute the post-implementation strategy STOCK_SYNC_002: After the task is completed normally, the post-implementation bound inventory synchronization strategy is triggered, the inventory deduction operation is performed, the WMS system inventory data is updated, the outbound record is generated and synchronized to the ERP system.

[0094] End-to-end log collection and storage in Elasticsearch: Execution data of all nodes in the process is collected through AOP aspects, including input parameters, output parameters, start / end time, status, and time consumption, and stored in the process_execution_log index of Elasticsearch.

[0095] Visualized replay / time statistics / bottleneck analysis: The complete execution process of this outbound task can be replayed through the web interface, and the execution time heatmap of each node can be viewed; the system automatically calculates the total time of this task = 215 seconds, with AGV driving time accounting for 62%, providing data support for subsequent process optimization.

[0096] Process End: The outbound task has been completed, the process instance is marked as "completed", and related resources are released.

[0097] Table 2 Comparative Experimental Data Table

[0098] This embodiment fully verifies the feasibility of the technical solution of the present invention. Actual operation data shows that the process execution success rate reaches 99.5%, and the average outbound time is shortened by 35% compared with the traditional solution.

[0099] Example 2: like Figure 8 As shown, the visualized business process dynamic orchestration, strategy binding, and canary execution system for industrial logistics described in this invention is implemented using a four-layer architecture, including: The basic support layer provides underlying technical capabilities, including the Flowable process engine kernel, Redis caching and distributed lock components, Elasticsearch log storage components, and MySQL persistent database; The engine extension layer, based on the Flowable kernel, includes five core extension components: logistics node parser, policy binding interceptor, gray-scale routing filter, context variable injector, and end-to-end tracing aspect. The core functional layer contains five functional modules: The logistics process modeling module is used to extend the standard BPMN 2.0 process modeling metamodel, define the set of process nodes in industrial logistics scenarios, and generate XML format process definition files that conform to the BPMN 2.0 standard through a visual drag-and-drop arrangement tool. The process and strategy binding module is used to establish the mapping relationship between process nodes and business strategies. It supports two modes: pre-binding and post-binding. It performs strategy validity verification during the process definition stage and triggers the corresponding strategy during the process execution stage. The canary release and isolated execution module is used to implement multi-version management of process definitions. It supports canary release strategies based on tenant ID, business type, and random ratio, and enables isolated operation and one-click rollback of new and old version process instances. The context-aware routing execution module is used to construct a process context set containing static parameters and dynamic operating condition data. It collects real-time operating condition data in parallel through the SPI mechanism and makes dynamic routing decisions based on real-time context data at the process routing nodes. The end-to-end tracing and visualization analysis module is used to collect execution data of the entire lifecycle of process nodes, store it in Elasticsearch, and realize the visualization playback of the execution process and performance bottleneck analysis. The application layer includes two interactive entry points: a visual designer and a monitoring and tracking platform, providing operation interfaces for process designers and operation and maintenance managers, respectively.

[0100] The logistics node parser in the engine extension layer extends Flowable's BPMN parsing logic, identifying five exclusive node types: AGV task nodes, inventory operation nodes, strategy trigger nodes, manual confirmation nodes, and conditional exclusive gateways. It parses node attributes and generates corresponding execution logic. The strategy binding interceptor intercepts execution requests before and after node execution, triggering the bound pre- or post-strategy. The gray-scale routing filter selects the corresponding version of the process definition based on the gray-scale strategy when the process instance starts. The context variable injector injects real-time collected dynamic working condition variables before node execution. The end-to-end tracing aspect intercepts node execution events and collects audit logs.

[0101] The visual orchestration tool provided by the process modeling module in the logistics field is developed based on BPMN.js. It supports drag-and-drop configuration of serial, parallel, conditional branching, and event sub-processes. After the process design is completed, it automatically verifies the integrity of node configuration and the effectiveness of strategy binding.

[0102] The end-to-end tracing and visualization analysis module provides a monitoring and tracing platform that supports graphical display of process execution progress. Successfully executed nodes are marked in green, nodes in progress in blue, nodes awaiting execution in gray, and nodes that failed in red. Clicking on a node allows you to view detailed input and output parameters and execution time. It also supports generating node time rankings, average total time trend charts for process instances, and distribution of abnormal nodes. Figure 3 Statistical reports.

[0103] Example 3: This embodiment uses a computer-readable storage medium storing a computer program, which can be deployed in devices such as edge computing gateways, warehouse management servers, and cloud servers in industrial logistics scenarios. The specific implementation is as follows: The storage medium uses a 256GB SSD solid-state drive. The stored computer program includes executable code for the process orchestration engine, policy engine, gray-scale routing module, context-aware module, and tracing analysis module. The program consumes no more than 8GB of memory and the peak CPU utilization does not exceed 40% during runtime. It is compatible with Linux / Windows Server operating systems.

[0104] When the computer program in the storage medium is executed by the server processor, all the steps of the above method embodiments are implemented: Receive visual orchestration operation instructions and generate BPMN 2.0 standard process definition files; Execute policy binding verification, triggering the corresponding policy before and after node execution; Based on the gray-scale strategy routing process example, implement version isolation execution and one-click rollback; Parallel acquisition of real-time operating data from AGVs, storage locations, and equipment; dynamic decision-making for routing branches. Collect full-chain execution logs and provide visualization playback and performance analysis functions.

[0105] The storage medium supports offline deployment mode, allowing it to run independently on-site in the factory without needing to connect to the public network, thus meeting the data security requirements of industrial scenarios. It also supports incremental updates, meaning that program upgrades do not require service restarts, and the upgrade process does not affect currently running process instances.

[0106] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.< / string>

Claims

1. A method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics, characterized in that, Includes the following steps: S1: Logistics process model construction: Extend the standard process modeling meta-model, define the set of process nodes in industrial logistics scenarios, and generate standardized process definition files through visual orchestration tools; The extended standard process modeling meta-model in step S1 is the BPMN2.0 meta-model, and the defined set of process nodes for the industrial logistics scenario includes AGV task nodes, inventory operation nodes, strategy triggering nodes, manual confirmation nodes, and conditional exclusive gateways; the visual orchestration tool is a visual drag-and-drop editor, and the generated standardized process definition file is an XML format file conforming to the BPMN2.0 standard; S2: Two-way binding between process nodes and business policies: Establishes a mapping relationship between process nodes and policy rules, supports multiple binding modes, performs policy validity verification in the process definition stage, and triggers the corresponding policy in the process execution stage; The binding modes in step S2 include pre-binding and post-binding: pre-binding triggers the strategy before the node is executed, and the strategy execution result is used as the node input parameter; The post-binding is triggered after the node is successfully executed, and is used to execute subsequent linked business. The validity verification of the strategy is performed during the process definition saving stage. The strategy code of all strategy triggering nodes is parsed, and the strategy engine health check interface is called to verify the validity of the strategy. If the strategy does not exist or is disabled, the process saving is prevented and an error is prompted. If an exception is thrown during the execution phase of the process, the process direction is determined according to the exception handling policy configured for the node, including terminating the process, skipping the current node, retrying the execution of the policy, or switching to the exception handling subprocess. S3: Process Version Gray Release and Isolated Execution: Implements multi-version management for process definitions, supports various gray release strategies, and enables isolated operation and version rollback of new and old version process instances; S4: Context-aware dynamic routing execution: Construct a process context set containing static parameters and dynamic operating condition data, and make dynamic routing decisions based on real-time context data at process routing nodes; S5: End-to-end execution tracing and visualization analysis: Collects execution data of the entire lifecycle of process nodes to enable visualization playback and performance analysis of the execution process.

2. The method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics according to claim 1, characterized in that, The AGV task node integrates a state machine, with states including pending, issued, executing, picking, picking completed, unloading, unloading completed, completed, failed, and canceled. During execution, it automatically calls the RCS interface to issue the task and starts an asynchronous listening thread to periodically query the task status until the final state is reached. The inventory operation node encapsulates interfaces for locking, unlocking, deducting, and adding inventory, and dynamically reads the storage location ID and storage location code attributes from process variables. The strategy trigger node is used to trigger the external strategy engine, thereby decoupling business rules from process definitions, including two modes: pre-binding and post-binding; the manual confirmation node is used for exception handling or confirmation of key steps, and is bound to mobile or web forms; the conditional exclusive gateway supports conditional expressions that reference dynamic variables.

3. The method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics according to claim 1, characterized in that: The canary release strategies in step S3 include canary release based on tenant ID, canary release based on business type, and canary release based on random ratio: canary release based on tenant ID specifies that the tenant uses the new version of the process, while other tenants use the old version; canary release based on business type only uses the new version for process instances of the specified business type. The grayscale ratio is set based on a random ratio, and newly initiated process instances use the new version according to the corresponding probability.

4. The method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics according to claim 3, characterized in that: The process definition multi-version management in step S3 specifically involves: automatically generating a version number in the format Major.Minor.Build each time a process definition is released; storing multiple versions of the process definition in the process engine; and marking only one version as the default version. When a new process instance starts, it creates an execution instance based on the current default version. The old version process instance that is already running is not affected by the new version release. Version rollback is achieved by updating the default version flag, and the rollback operation takes less than 100ms.

5. The method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics according to claim 1, characterized in that: The process context set in step S4 includes static variables and dynamic variables: static variables are fixed parameters passed in when the process starts, including material type, task type, and tenant ID; dynamic variables are operating condition data collected in real time during runtime, including AGV real-time coordinates, warehouse occupancy rate, equipment online status, and battery power.

6. The method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics according to claim 5, characterized in that: The dynamic routing execution uses the SPI mechanism to collect runtime condition data in parallel and implements local LRU caching for dynamic variables with an expiration time of 30 seconds. The configuration expression of the condition gateway supports referencing dynamic variables. After the engine parses the expression, it calculates a Boolean value based on real-time data to determine the flow branch direction. If the dynamic variable acquisition times out or fails, it uses a preset default value or enters the exception handling subprocess.

7. A system for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics, based on the method for dynamic orchestration, strategy binding, and canary execution of visualized business processes for industrial logistics as described in any one of claims 1-6, characterized in that, Implemented using a four-layer architecture, including: The basic support layer provides underlying technical capabilities, including the Flowable process engine kernel, Redis caching and distributed lock components, Elasticsearch log storage components, and MySQL persistent database; The engine extension layer, based on the Flowable kernel, includes five core extension components: logistics node parser, policy binding interceptor, gray-scale routing filter, context variable injector, and end-to-end tracing aspect. The core functional layer comprises five functional modules: including: The logistics process modeling module is used to extend the standard process modeling metamodel, define the set of process nodes in industrial logistics scenarios, and generate standardized process definition files through visual orchestration tools. The process and strategy binding module is used to establish the mapping relationship between process nodes and business strategies. It supports multiple binding modes, performs strategy validity verification during the process definition stage, and triggers the corresponding strategy during the process execution stage. The canary release and isolated execution module is used to implement multi-version management of process definitions, supports various canary release strategies, and realizes the isolated operation of new and old version process instances and version rollback; The context-aware routing execution module is used to construct a process context set containing static parameters and dynamic operating condition data, and to make dynamic routing decisions based on real-time context data at the process routing node; The end-to-end tracing and visualization analysis module is used to collect execution data throughout the entire lifecycle of process nodes, enabling visualized playback and performance analysis of the execution process. The application layer includes two interactive entry points: a visual designer and a monitoring and tracking platform, providing operation interfaces for process designers and operation and maintenance managers, respectively.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for dynamic orchestration, strategy binding, and canary execution of a visualized business process for industrial logistics as described in any one of claims 1-6.

Images