Multi-channel message-oriented process orchestration system and method

Abstract

The application provides a multi-channel message-oriented process arrangement system and method, and relates to the field of process automation. The method comprises the following steps: determining a set of available components and displaying them in a visual work area according to a set of channel types applicable to a target process and channel mapping information; when the set of channel types changes, the set of available components is determined again, and channel-specific components in the added components that are no longer compatible are automatically disconnected and deleted; saving the process when all the added components belong to the set of available components in response to a save request; generating a snapshot of the current configuration in response to a message session entering the target process, and subsequently executing the message session based on the snapshot. The application realizes automatic synchronization and cleaning of the work area after channel configuration changes, improves the automation and security of multi-channel message process maintenance, and uses a process snapshot isolation mechanism to realize accurate arrangement and stable execution of the multi-channel message process, thereby comprehensively improving the efficiency and reliability of process development.

Description

Technical Field

[0001] This application relates to the field of process automation technology, and in particular to a process orchestration system and method for multi-channel messaging. Background Technology

[0002] As enterprises deepen their digital transformation, they typically need to connect to multiple messaging channels, including SMS, instant messaging (such as WeChat and WhatsApp), and voice calls. To improve service efficiency, automated reply systems are widely deployed across these messaging channels. However, existing automated message reply systems generally use linear script structures, which cannot support complex process nodes such as conditional routing, loop queries, and external database queries, making it difficult to meet the flexibility requirements of enterprise-level automated message processing.

[0003] To address these issues, some companies have attempted to migrate their voice IVR workflow designers to messaging scenarios. However, voice IVR workflow designers are specifically designed for the synchronous interaction model of voice conversations, and their component semantics are fundamentally incompatible with the asynchronous interaction model of messaging channels: voice IVR requires users to remain online throughout the same call, while messaging conversations allow users to reply at any time, and the workflow needs to be suspended after sending a message, resuming execution only after a callback is triggered. Voice IVR designers lack corresponding asynchronous component semantic support and cannot be directly extended for messaging conversation processing.

[0004] Furthermore, while general-purpose BPM or low-code platforms offer workflow orchestration capabilities, they are unaware of differences in message channel types. Different channels support varying interactive capabilities; for example, WhatsApp supports template messages, while SMS only supports text. This poses a significant risk of configuration errors, which are exposed during deployment and execution at nodes, resulting in extremely high repair costs.

[0005] In view of this, there is an urgent need to provide a process orchestration system for multi-channel messaging, whose process designer can identify channel types and constrain the availability of components, avoid configuration errors from the design source, fill the gap in existing messaging systems in complex automation scenarios, and improve the development efficiency and accuracy of business processes. Summary of the Invention

[0006] This application provides a process orchestration system and method for multi-channel messaging. Through a channel-aware component constraint mechanism and a process snapshot isolation mechanism, it achieves accurate orchestration and stable execution of multi-channel messaging processes, thereby improving the efficiency and reliability of process development.

[0007] To achieve the above objectives, firstly, this application provides a workflow orchestration method for multi-channel messaging, comprising the following steps: S1. In response to the editing operation of the target process, determine the set of available components of the target process based on the set of channel types and channel mapping information applicable to the target process, and display the process components in the set of available components in the visualization workspace. The channel mapping information records the adaptation relationship between each channel type and process component. S2. When the set of channel types applicable to the target process changes, the set of available components is re-determined based on the channel mapping information, and channel-specific components that do not belong to the re-determined set of available components in the added process components are disconnected and deleted from the target process. S3. In response to the request to save the target process, if all added process components belong to the set of available components, save the target process; S4. In response to the trigger signal of the message session entering the target process, generate a snapshot of the current configuration of the target process. The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and the set of channel types applicable to the target process. S5. Execute the message session based on the snapshot.

[0008] This application utilizes a channel constraint controller to dynamically filter available components based on channel mapping information, eliminating the risk of configuration errors caused by channel-component mismatches from the design stage. This avoids the problem of errors only being exposed after deployment and running, and the high cost of repair, common in traditional solutions. Existing general-purpose low-code platforms lack this channel awareness capability; this application significantly improves the design accuracy and development efficiency of multi-channel messaging flows.

[0009] This implementation automatically triggers a refresh of the component toolbox and a compatibility self-check of workspace components when the channel type of the process changes. It also automatically disconnects and deletes incompatible channel-specific components, while simultaneously notifying the user. This achieves automated synchronous cleanup of the workspace state after channel configuration changes, fundamentally preventing process execution errors caused by invalid components remaining in the workspace due to channel contraction, thus improving the automation and security of process maintenance.

[0010] In one possible implementation, the method further includes: When a cross-device migration operation for the target process is detected, the directed branch connections between the pasted components are preserved; When the target process is imported through the configuration file, a skip strategy is adopted for components that cannot be identified in the configuration file and the remaining components are imported. For components with missing associated data in the configuration file, the missing associated data is removed and the component's own configuration parameters are retained.

[0011] This embodiment employs a fault-tolerant import and cross-device paste mechanism. When importing JSON, it skips illegal components instead of aborting them, ensuring that the main structure of the process can still be successfully imported even if some components are incompatible. It also adopts a downgrade retention strategy instead of direct deletion for missing related data to avoid data loss. At the same time, it preserves the branch connection relationship between components when pasting across devices, which significantly reduces the reconstruction cost of migrating process configurations between different devices and improves the reuse efficiency of process resources.

[0012] In one possible implementation, the method further includes: The visual workspace provides at least one of the following visual editing functions: component drag and drop, branch connection, multi-component selection, undo, and redo.

[0013] This implementation provides a graphical visual editing function, enabling process designers to build multi-channel message processes in a WYSIWYG manner without writing any code, thus significantly reducing the technical threshold for process development.

[0014] In one possible implementation, step S5 includes: The snapshot is isolated from subsequent configuration changes in the target process. Based on the directed graph structure in the snapshot, the process is executed node by node starting from the start node until the end node is reached, at which point the current message session is terminated.

[0015] This implementation completely isolates snapshots from subsequent configuration changes, ensuring that each message session instance executes based on the same process definition throughout its entire lifecycle, unaffected by configuration changes occurring simultaneously in the design phase. For scenarios involving asynchronous wait-for-response, this isolation mechanism effectively prevents running instances from entering incorrect branches or referencing deleted nodes due to configuration changes, thus guaranteeing the stability of business processes and the consistency of user experience.

[0016] In one possible implementation, before saving the target process in step S2, the method further includes: in response to the save request, performing at least one of concurrent edit lock verification, configuration validity verification, and logical loop closure verification.

[0017] This implementation method sets up a multi-layered cascading verification mechanism before saving the process, implementing concurrent conflict detection, configuration semantic verification, and process structure integrity verification in layers, completing full-dimensional verification before process persistence. Compared with the traditional approach of only performing basic syntax checks, this implementation method can more comprehensively ensure the correctness and executability of process configuration, effectively reduce the runtime failure rate after process deployment, and reduce the risk of accidental overwriting of design content due to concurrent editing conflicts.

[0018] In one possible implementation, the concurrent edit lock verification includes: Upon receiving a heartbeat signal from any user targeting the visual workspace of the target process, record the timestamp; In response to a user request to enter the visual workspace, query the current edit lock status and the last editor record; If the current edit lock is held by another user, calculate the duration from the other user's last heartbeat signal to the present; if the duration is less than a preset timeout threshold, refuse entry; if the duration is greater than or equal to the timeout threshold, release the edit lock and grant editing rights. If it is detected that the same user has opened the same process's visual workspace in multiple browser windows at the same time, once one window performs a save operation, only the remaining windows are allowed to perform save or close operations.

[0019] This implementation uses a heartbeat mechanism to automatically release pessimistic locks after timeout, effectively solving the problem of permanent lock occupation caused by abnormal user exits and avoiding the predicament of other users being unable to edit the workflow due to deadlock. Simultaneously, by providing an exemption for the last editor's reconnection scenario, it significantly reduces waiting time in normal collaborative scenarios while ensuring concurrency safety, balancing concurrency safety and user experience, outperforming existing optimistic locking solutions in workflow configuration scenarios. Furthermore, special handling for multi-window scenarios for the same user effectively prevents save conflicts and data overwriting issues caused by the same user editing simultaneously in multiple browser tabs, further ensuring the consistency of workflow configuration.

[0020] In one possible implementation, the logical closed-loop verification includes: Based on the added components, identify the main logic tree with the starting component as the root node and connected by directed branches, and exclude isolated components that are not connected to the main logic tree from the scope of channel constraint verification. A depth-first graph traversal is performed on the main logic tree, skipping branches within loops during the traversal of loop components; Examine each leaf node encountered during traversal to determine whether it is an ending component or an ending branch; If any leaf node is not an end-type component or an end branch, the process logic is determined to be not closed, the information of the unclosed components is collected, an error is reported, and saving is prevented. If all leaf nodes are end-of-process components or end-of-process branches, the process logic is considered closed, and the target process can be saved.

[0021] This implementation performs graph traversal validation on the main logic tree upon saving, ensuring that all execution paths have a definite endpoint, thus eliminating the risk of sessions getting stuck in endless dead ends during runtime. A depth-first traversal algorithm automatically identifies the main logic tree and isolated components, and performs finality checks on all leaf nodes of the main logic tree to ensure that the process does not have any "headless" paths. Simultaneously, branches within loops are skipped during traversal, avoiding misclassifying repeatable execution paths within loops as incomplete loops, making the validation logic more aligned with the actual execution semantics of the business process. The isolated component exclusion mechanism allows designers to temporarily store experimental fragments or sub-processes to be improved in the workspace without being blocked by validation, ensuring both the integrity of the process logic and design flexibility. Existing process editors typically lack this type of graph-level semantic validation capability.

[0022] In one possible implementation, the configuration validity verification includes: Verify the completeness of required fields in the verification process components, the validity of associated data, and the mutual exclusion rules between components. If any verification fails, locate the specific component and configuration item, prevent saving, and display the repair guidance information.

[0023] This implementation performs semantic-level validity checks on the configuration parameters of each component before saving the process, including whether required fields are filled, whether referenced data sources or variables exist, and whether there are mutual exclusion conflicts between components. Compared to simply checking the connectivity of the process structure, this implementation delves into the component-level configuration granularity, enabling more precise location of configuration defects. Furthermore, it reduces the user's error correction costs through explicit repair guidance information, thereby improving the first-time success rate of process configuration.

[0024] In one possible implementation, the component types include at least one of the following: condition judgment node, time condition node, message sending node, wait for reply node, menu node, loop node, HTTP request node, database query node, variable assignment node, transfer node, and close node; the components are connected by directed branches, which include special branches carrying semantic tags; Step S5 includes at least one of the following: When execution reaches a node waiting for a reply or a menu node, suspend the current session and start a timeout timer; if a user reply message is received, select the target special branch according to the semantic tag corresponding to the user reply message and continue execution; If a timeout is detected, select the target special branch according to the semantic label corresponding to the timeout state and continue execution; When execution reaches a loop node, the branches within the loop body are executed according to the loop condition configured in the loop node. After the loop ends, execution continues into the branch outside the loop. When an HTTP request node or a database query node is reached, the external interface adapter is invoked to execute the request, and the execution result is updated to the context of the process as a variable.

[0025] This implementation enables the process execution engine to natively support asynchronous interaction models of message channels through waiting response nodes and special branches carrying semantic tags. It accurately routes execution to the corresponding branch, while timeout branches provide fault-tolerant handling paths for abnormal scenarios. Loop nodes support controlled loop execution by a fixed number of times or conditional expressions, suitable for multi-round information collection scenarios. HTTP request nodes and database query nodes achieve data interaction with external systems through external interface adapters, injecting results into context variables for subsequent nodes to reference, enabling the process to make dynamic decisions based on external data. The combination of these execution semantics allows the message flow orchestration system of this application to fully cover all complex process requirements in enterprise-level message automation scenarios, including "multi-round dialogue, data query, loop collection, timeout handling, and dynamic routing," breaking through the capability boundaries of traditional linear script systems.

[0026] Secondly, a process orchestration system for multi-channel messaging is provided, which includes a process creation module and a process execution module. The process creation module is used to respond to the editing operation of the target process, determine the set of available components of the target process based on the set of channel types and channel mapping information applicable to the target process, and display the process components in the set of available components in the visual workspace. The channel mapping information records the adaptation relationship between each channel type and process component. The process creation module is further configured to, when the set of channel types applicable to the target process changes, re-determine the set of available components based on the channel mapping information, and disconnect and delete channel-specific components that do not belong to the re-determined set of available components from the target process; in response to a request to save the target process, save the target process if all added process components belong to the set of available components. The process execution module is used to generate a snapshot of the current configuration of the target process in response to the trigger signal of the message session entering the target process. The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and the set of channel types applicable to the target process. The process execution module is also used to execute the message session based on the snapshot.

[0027] In one possible implementation, the process creation module includes: The component toolbox is used to maintain a collection of process components, which include general components and channel-specific components. The channel constraint controller is used to redetermine the set of available components based on the channel mapping information when the set of channel types applicable to the target process changes, and to disconnect and delete channel-specific components that do not belong to the redetermined set of available components from the target process; in response to a request to save the target process, the target process is saved if all added process components belong to the set of available components.

[0028] In one possible implementation, the system further includes a migration module, the migration module being used to: When a cross-device migration operation for the target process is detected, the directed branch connections between the pasted components are preserved; When the target process is imported through the configuration file, a skip strategy is adopted for components that cannot be identified in the configuration file and the remaining components are imported. For components with missing associated data in the configuration file, the missing associated data is removed and the component's own configuration parameters are retained.

[0029] In one possible implementation, the process creation module includes a visualization module, which is used to provide at least one of the following visual editing functions in the visualization workspace: component drag and drop, branch connection, multi-component selection, undo, and redo.

[0030] In one possible implementation, the process execution module is used to: The system receives a trigger signal indicating that the message session has entered the target process and generates a snapshot of the current configuration of the target process. The snapshot is isolated from subsequent configuration changes in the target process. Based on the directed graph structure in the snapshot, the process is executed node by node starting from the start node until the end node is reached, at which point the current message session is terminated.

[0031] In one possible implementation, the process execution module includes a validator, which is configured to: in response to the save request, perform at least one of concurrent edit lock verification, configuration validity verification, and logical loop closure verification.

[0032] In one possible implementation, the verifier is used for: Upon receiving a heartbeat signal from any user targeting the visual workspace of the target process, record the timestamp; In response to a user request to enter the visual workspace, query the current edit lock status and the last editor record; If the current edit lock is held by another user, calculate the duration from the other user's last heartbeat signal to the present; if the duration is less than a preset timeout threshold, refuse entry; if the duration is greater than or equal to the timeout threshold, release the edit lock and grant editing rights. If it is detected that the same user has opened the same process's visual workspace in multiple browser windows at the same time, once one window performs a save operation, only the remaining windows are allowed to perform save or close operations.

[0033] In one possible implementation, the verifier is used for: Based on the added components, identify the main logic tree with the starting component as the root node and connected by directed branches, and exclude isolated components that are not connected to the main logic tree from the scope of channel constraint verification. A depth-first graph traversal is performed on the main logic tree, skipping branches within loops during the traversal of loop components; Examine each leaf node encountered during traversal to determine whether it is an ending component or an ending branch; If any leaf node is not an end-type component or an end branch, the process logic is determined to be not closed, the information of the unclosed components is collected, an error is reported, and saving is prevented. If all leaf nodes are end-of-process components or end-of-process branches, the process logic is considered closed, and the target process can be saved.

[0034] In one possible implementation, the verifier is used to: verify the completeness of required fields of process components, the validity of associated data, and mutual exclusion rules between components; and, in the event of any verification failure, locate the specific component and configuration item, prevent saving, and display repair guidance information.

[0035] In one possible implementation, the general components in the component toolbox include at least one of the following: condition judgment node, time condition node, message sending node, wait for reply node, menu node, loop node, HTTP request node, database query node, variable assignment node, transfer node, and close node; the nodes are connected by directed branches, and the directed branches include special branches carrying semantic tags.

[0036] In one possible implementation, the process execution module is configured to: suspend the current session and start a timeout timer when executing to a waiting reply node or menu node; and, upon receiving a user reply message, select a target special branch according to the semantic tag corresponding to the user reply message to continue execution.

[0037] In one possible implementation, the process execution module is used to: select a target special branch to continue execution according to the semantic tag corresponding to the timeout state when a timeout state is detected.

[0038] In one possible implementation, the process execution module is used to: when executing a loop node, execute the branch within the loop body according to the loop condition configured in the loop node, and after the loop ends, enter the branch outside the loop to continue execution.

[0039] In one possible implementation, the process execution module is used to: when executing an HTTP request node or a database query node, call an external interface adapter to execute the request, and update the execution result in the context of the process as a variable.

[0040] Thirdly, a computing device is provided, the computing device including a memory and a processor, the memory storing at least one program, the at least one program being executed by the processor to implement the multi-channel messaging flow orchestration method as provided in the first aspect.

[0041] Fourthly, a computer-readable storage medium is provided, wherein at least one program is stored therein, the at least one program being executed by a processor to implement the multi-channel messaging flow orchestration method provided in the first aspect.

[0042] Fifthly, a computer program product is provided, comprising a computer program / instruction, characterized in that, when the computer program / instruction is executed by a processor, it implements the multi-channel message flow orchestration method provided in the first aspect.

[0043] The technical solution provided in this application includes at least the following technical effects: By dynamically constraining the content displayed in the component toolbox through channel mapping information, the misuse of incompatible components is avoided from the design source, reducing the configuration error rate; by performing compatibility checks when saving the process, incompatible configurations are detected and prevented before the process goes live, reducing production environment failures; and by using a snapshot isolation mechanism, the execution environment of each message session is completely isolated from subsequent changes to the process, ensuring the determinism and consistency of long-running processes. Attached Figure Description

[0044] Figure 1 This is an architecture diagram of a multi-channel messaging workflow orchestration system provided in an embodiment of this application; Figure 2 This is another architecture for a multi-channel messaging workflow orchestration system provided in the embodiments of this application; Figure 3 This is a flowchart of a multi-channel message orchestration method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating a process configuration and save verification provided in an embodiment of this application; Figure 5 This is a flowchart of a concurrent edit lock verification method provided in an embodiment of this application; Figure 6 This is a flowchart of a message session execution provided in an embodiment of this application; Figure 7This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0045] To further illustrate the various embodiments, this application provides accompanying drawings. These drawings are part of the disclosure of this application and are mainly used to illustrate the embodiments, and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of this application. Components in the drawings are not drawn to scale, and similar component symbols are generally used to represent similar components. In this application, the term "at least one" means one or more, and the term "multiple" means two or more.

[0046] The present application will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0047] Example 1 This application provides a workflow orchestration system for multi-channel messaging, which includes multiple functional modules. Each functional module can be implemented on at least one identical or different computing device. Figure 1 This is an architecture diagram of a multi-channel messaging workflow orchestration system provided in an embodiment of this application. Figure 1 As shown in the embodiment of this application, the system includes: a process creation module and a process execution module.

[0048] The process creation module is used to determine the set of available components for the target process based on the channel type set and channel mapping information, and display the process components in the available component set in the visualization workspace. In response to a target process creation request, it checks the process components already added in the visualization workspace; if all added process components belong to the available component set, it saves the target process.

[0049] The channel mapping information records the compatibility between each channel type and process component.

[0050] The process execution module is used to generate a snapshot of the current configuration of the target process in response to the trigger signal of the message session entering the target process, and execute the message session based on the snapshot. The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and at least one channel type.

[0051] This application utilizes a channel constraint controller to dynamically filter available components based on channel mapping information, eliminating the risk of configuration errors caused by channel-component mismatches from the design stage. This avoids the problem of errors only being exposed after deployment and running, and the high cost of repair, common in traditional solutions. Existing general-purpose low-code platforms lack this channel awareness capability; this application significantly improves the design accuracy and development efficiency of multi-channel messaging flows.

[0052] In one possible implementation, the process creation module includes a component toolbox and a channel constraint controller.

[0053] The component toolkit is used to maintain a collection of process components, including general components and channel-specific components. Optionally, the component types include at least one of the following: conditional judgment nodes, time-conditional nodes, message sending nodes, wait-for-response nodes, menu nodes, loop nodes, HTTP request nodes, database query nodes, variable assignment nodes, transition nodes, and close nodes. Components are connected by directed branches, which include special branches carrying semantic tags.

[0054] The channel constraint controller is used to redetermine the set of available components for the target process based on the channel mapping information when the set of channel types for the target process changes. It then disconnects and deletes channel-specific components that are not part of the set of available components from the target process.

[0055] This implementation automatically triggers a refresh of the component toolbox and a compatibility self-check of workspace components when the channel type of the process changes. It also automatically disconnects and deletes incompatible channel-specific components, while simultaneously notifying the user. This achieves automated synchronous cleanup of the workspace state after channel configuration changes, fundamentally preventing process execution errors caused by invalid components remaining in the workspace due to channel contraction, thus improving the automation and security of process maintenance.

[0056] In one possible implementation, the process creation module further includes a visualization module, which provides at least one of the following visual editing functions in the visualization workspace: component drag-and-drop, branch connection, multi-component selection, undo, and redo. This implementation, by providing graphical visual editing functions, enables process designers to build multi-channel message processes in a WYSIWYG manner without writing any code, significantly reducing the technical threshold for process development.

[0057] In one possible implementation, the process execution module includes a snapshot isolator and a process execution engine.

[0058] The snapshot isolator is used to: receive the trigger signal when a message session enters the target process, and generate a snapshot of the current configuration of the target process. The process execution engine is used to isolate the snapshot from subsequent configuration changes of the target process, and executes each node one by one from the start node according to the directed graph structure in the snapshot, until the end node is reached and the current message session is terminated.

[0059] Specifically, the process execution engine executes the process node by node according to the directed graph structure in the snapshot, handling execution semantics such as conditional branch judgment, loop control, asynchronous waiting for response, and timeout timing.

[0060] This implementation completely isolates snapshots from subsequent configuration changes, ensuring that each message session instance executes based on the same process definition throughout its entire lifecycle, unaffected by configuration changes occurring simultaneously in the design phase. For scenarios involving asynchronous wait-for-response, this isolation mechanism effectively prevents running instances from entering incorrect branches or referencing deleted nodes due to configuration changes, thus guaranteeing the stability of business processes and the consistency of user experience.

[0061] In one possible implementation, the process execution module further includes a validator, which further includes: a concurrent editing protector, a configuration validity validator, and a logic loop validator.

[0062] This implementation method sets up a multi-layered cascading verification mechanism before saving the process, implementing concurrent conflict detection, configuration semantic verification, and process structure integrity verification in layers, completing full-dimensional verification before process persistence. Compared with the traditional approach of only performing basic syntax checks, this implementation method can more comprehensively ensure the correctness and executability of process configuration, effectively reduce the runtime failure rate after process deployment, and reduce the risk of accidental overwriting of design content due to concurrent editing conflicts.

[0063] In one possible implementation, the concurrent editing protector is configured to: receive a heartbeat signal from any user for the visual workspace of the target process and record the timestamp; respond to a user request to enter the visual workspace, query the current editing lock status and the last editor record; if the current editing lock is held by another user, calculate the duration from the last heartbeat signal of that other user to the present; if the duration is less than a preset timeout threshold, refuse entry; if the duration is greater than or equal to the timeout threshold, release the editing lock and grant editing rights; if it is detected that the same user opens the visual workspace of the same process in multiple browser windows simultaneously, after one window performs a save operation, only allow the remaining windows to perform save or close operations.

[0064] Specifically, the concurrent editing protector maintains the editing lock state of the process through a heartbeat signal mechanism. The frontend sends a heartbeat signal to the backend at fixed time intervals, and the backend calculates the timeout duration based on the time of the last heartbeat; after the timeout, the editing lock is automatically released. The system records the identity of the last editor, so when the last editor re-enters the workspace, they can directly obtain editing rights without waiting for the timeout.

[0065] This implementation uses a heartbeat mechanism to automatically release pessimistic locks after timeout, effectively solving the problem of permanent lock occupation caused by abnormal user exits and avoiding the predicament of other users being unable to edit the workflow due to deadlock. Simultaneously, by providing an exemption for the last editor's reconnection scenario, it significantly reduces waiting time in normal collaborative scenarios while ensuring concurrency safety, balancing concurrency safety and user experience, outperforming existing optimistic locking solutions in workflow configuration scenarios. Furthermore, special handling for multi-window scenarios for the same user effectively prevents save conflicts and data overwriting issues caused by the same user editing simultaneously in multiple browser tabs, further ensuring the consistency of workflow configuration.

[0066] In one possible implementation, the logic loop closing checker is used to: identify the main logic tree rooted at the starting component and connected by directed branches based on the added components; exclude isolated components not connected to the main logic tree from the channel constraint check scope; perform a depth-first graph traversal on the main logic tree, skipping branches within the loop during the traversal of loop components; check each leaf node traversed to determine whether it is an ending component or an ending branch; if any leaf node is not an ending component or an ending branch, the process logic is determined to be not closed, the information of the not-closed-loop components is collected, an error is reported, and saving is prevented. If all leaf nodes are ending components or ending branches, the process logic is determined to be closed, and saving the target process is allowed.

[0067] This implementation performs graph traversal validation on the main logic tree upon saving, ensuring that all execution paths have a definite endpoint, thus eliminating the risk of sessions getting stuck in endless dead ends during runtime. A depth-first traversal algorithm automatically identifies the main logic tree and isolated components, and performs finality checks on all leaf nodes of the main logic tree to ensure that the process does not have any "headless" paths. Simultaneously, branches within loops are skipped during traversal, avoiding misclassifying repeatable execution paths within loops as incomplete loops, making the validation logic more aligned with the actual execution semantics of the business process. The isolated component exclusion mechanism allows designers to temporarily store experimental fragments or sub-processes to be improved in the workspace without being blocked by validation, ensuring both the integrity of the process logic and design flexibility. Existing process editors typically lack this type of graph-level semantic validation capability.

[0068] In one possible implementation, a validity validator is configured to: verify the completeness of required fields in the process components, the validity of associated data, and the mutual exclusion rules between components; and, in the event of any verification failure, locate the specific component and configuration item, prevent saving, and display repair guidance information.

[0069] This implementation performs semantic-level validity checks on the configuration parameters of each component before saving the process, including whether required fields are filled, whether referenced data sources or variables exist, and whether there are mutual exclusion conflicts between components. Compared to simply checking the connectivity of the process structure, this implementation delves into the component-level configuration granularity, enabling more precise location of configuration defects. Furthermore, it reduces the user's error correction costs through explicit repair guidance information, thereby improving the first-time success rate of process configuration.

[0070] In one possible implementation, the process execution engine is used to: suspend the current session and start a timeout timer when execution reaches a waiting reply node or menu node; and, upon receiving a user reply message, select a target special branch according to the semantic tag corresponding to the user reply message to continue execution.

[0071] In one possible implementation, the process execution engine is used to: select a target special branch to continue execution according to the semantic label corresponding to the timeout state when a timeout state is detected.

[0072] In one possible implementation, the process execution engine is used to: when executing a loop node, execute the branch within the loop body according to the loop condition configured in the loop node, and after the loop ends, enter the branch outside the loop to continue execution.

[0073] In one possible implementation, the process execution engine is used to: when executing an HTTP request node or a database query node, invoke an external interface adapter to execute the request, and update the execution result into the process context as a variable. Specifically, the external interface adapter encapsulates the execution logic of the HTTP request and database query, supports timeout control, and injects the execution result into the process context as a variable for reference by expressions in subsequent nodes.

[0074] This implementation enables the process execution engine to natively support asynchronous interaction models of message channels through waiting response nodes and special branches carrying semantic tags. It accurately routes execution to the corresponding branch, while timeout branches provide fault-tolerant handling paths for abnormal scenarios. Loop nodes support controlled loop execution by a fixed number of times or conditional expressions, suitable for multi-round information collection scenarios. HTTP request nodes and database query nodes achieve data interaction with external systems through external interface adapters, injecting results into context variables for subsequent nodes to reference, enabling the process to make dynamic decisions based on external data. The combination of these execution semantics allows the message flow orchestration system of this application to fully cover all complex process requirements in enterprise-level message automation scenarios, including "multi-round dialogue, data query, loop collection, timeout handling, and dynamic routing," breaking through the capability boundaries of traditional linear script systems.

[0075] This application embodiment provides key parameters and their definitions in the proposed process orchestration system, as shown in Table 1 below.

[0076] Table 1

[0077] As shown in Table 1 above, the heartbeat sending interval is used to inform the backend that the current user is editing a workflow and needs to hold an edit lock. This serves as the timing benchmark for the automatic release of the edit lock, and continuous heartbeats maintain editing privileges. The edit lock timeout threshold is used to prevent users from abnormally exiting and occupying workflow editing privileges for an extended period, avoiding resource deadlocks. The external interface execution timeout is used to block stuck external requests, preventing a single session from occupying execution resources for an extended period. The wait-for-response timeout duration is used to prevent sessions from being suspended indefinitely, automatically terminating the current interactive branch workflow after the timeout. The maximum number of loop levels is used to limit infinite nested loops, avoiding call stack overflow and memory exhaustion during execution. The menu branch matching value limit is used to constrain the complexity of menu configuration and reduce the retrieval and computational overhead of branch matching. The maximum number of workflow components is used to manage the workflow scale, preventing excessively large workflows from slowing down validation, snapshot generation, and execution engine performance. The maximum number of undo / redo steps is used to limit the memory space occupied by the operation history cache, balancing the editing experience with service memory consumption.

[0078] Figure 2 This is an architecture diagram of another multi-channel messaging workflow orchestration system provided in this application embodiment. In one possible implementation, such as... Figure 2 As shown, the system includes a configuration layer, a verification layer, an execution layer, and a channel layer. The layered and decoupled structure enables full-link capabilities such as visual process editing, configuration verification, session isolation execution, and multi-channel message distribution.

[0079] refer to Figure 2 The configuration layer includes a visualization module, a component toolbox, and a channel constraint controller. The visualization workspace allows users to drag and drop to build business processes; the component toolbox provides basic process components; and the channel constraint controller binds adaptation rules between channel types and available components, restricting the process to only using components matching the current channel. Edited data is synchronously sent to the verification layer for compliance checks.

[0080] The validation layer consists of a configuration validity validator, a concurrent editing protector, and a logic loop validator connected in series. The validation layer receives process data from the configuration layer and validates it layer by layer: verifying the matching relationship between components and channels, protecting against conflicts in concurrent editing by multiple users, and checking whether there are loop problems such as infinite loops / breakpoints in the process logic. The validation results are synchronously transmitted to the execution layer.

[0081] The execution layer includes a snapshot isolator, a process execution engine, and an external interface adapter. The snapshot isolator generates an independent snapshot of the current process configuration when a message session is triggered, isolating different sessions to avoid interference from configuration changes; the process execution engine drives business processes based on snapshots; and the external interface adapter provides a unified standard interface for connecting to various downstream message channels.

[0082] The channel layer (multi-message channel carrier) integrates messaging channels such as SMS, instant messaging, and online customer service, receives conversation instructions from the execution layer, and completes message push and interaction processing for the corresponding channels.

[0083] In one possible implementation, the system further includes a migration module, which is used to: when a cross-device migration operation for a target process is detected, retain the directed branch connection relationship between the pasted components; when the target process is imported through a configuration file, adopt a skip strategy for components that cannot be recognized in the configuration file and continue to import the remaining components; and remove the missing association data for components with missing association data in the configuration file while retaining the component's own configuration parameters.

[0084] By employing fault-tolerant import and cross-device paste mechanisms, illegal components are skipped instead of aborted during JSON import, ensuring that the main structure of the process can still be successfully imported even if some components are incompatible. Missing related data is retained instead of being directly deleted to avoid data loss. At the same time, the branch connection relationship between components is preserved when pasting across devices, which significantly reduces the reconstruction cost of migrating process configurations between different devices and improves the reuse efficiency of process resources.

[0085] The technical solutions provided in this application include at least the following technical effects: By dynamically constraining the content displayed in the component toolbox through channel mapping information, the misuse of incompatible components is avoided from the design source, reducing the configuration error rate; by performing compatibility checks when saving the process, incompatible configurations are detected and prevented before the process goes live, reducing production environment failures; and by using a snapshot isolation mechanism, the execution environment of each message session is completely isolated from subsequent changes to the process, ensuring the determinism and consistency of long-running processes.

[0086] Example 2 This application provides a workflow orchestration method for multi-channel messaging, which can be executed by any computing device. Figure 3 This is a flowchart of a multi-channel messaging workflow orchestration method provided in an embodiment of this application, such as... Figure 3 As shown, the method includes steps S1 to S5.

[0087] S1. Based on the channel type set and channel mapping information of the target process, determine the set of available components for the target process and display the process components in the set of available components in the visualization workspace.

[0088] The channel mapping information records the compatibility between each channel type and process component. The channel type indicates the message channel. In one possible implementation, the technical solution provided in this application is applied to the automated message processing scenario in an enterprise communication system. Enterprise communication systems typically access multiple message channels simultaneously, such as SMS channels, instant messaging channels, and online customer service channels. Each channel's message session needs to support automated process-oriented processing, including: time- or content-based conditional routing, sending messages or files to users, waiting for user replies, calling external data interfaces to query business data, and looping queries until conditions are met.

[0089] In one possible implementation, the process components include general components and channel-specific components. Optionally, the component types include at least one of the following: conditional judgment nodes, time-conditional nodes, message sending nodes, wait-for-response nodes, menu nodes, loop nodes, HTTP request nodes, database query nodes, variable assignment nodes, transition nodes, and close nodes. The components are connected by directed branches, which include special branches carrying semantic tags.

[0090] In one possible implementation, step S1 includes: S2. When the set of channel types in the target process changes, the set of available components in the target process is redefined based on the channel mapping information. Channel-specific components that do not belong to the redefined set of available components in the added process components are disconnected from and deleted from the target process.

[0091] In one possible implementation, the system administrator creates a messaging flow in a visual workspace. Initially, the administrator configures the set of applicable channels for the flow as "instant messaging channels" (such as WeChat and WhatsApp) and "SMS channels".

[0092] The system queries a mapping table of applicability between components and channel types based on the set of applicable channels for the workflow. This mapping table records: WhatsApp template message components are only applicable to WhatsApp channels; rich text button components are only applicable to instant messaging channels (WeChat, WhatsApp, etc.); plain text sending components are applicable to SMS and instant messaging channels; menu components are applicable to instant messaging channels. The system calculates the currently available set of components based on the mapping table and displays all components applicable to instant messaging and SMS channels (including plain text sending components, menu components, etc.) in the component toolbox of the workspace. Components applicable only to a single channel (such as WhatsApp template message components and rich text button components) are displayed normally in the component toolbox of the visual workspace (because they are still a subset of the current channel set).

[0093] In response to an administrator dragging a WhatsApp template message component into the workspace and configuring the template ID and template parameter fields, and subsequently changing the applicable channel set for the workflow to "SMS channels only," the channel type set for the target workflow changes. The channel constraint controller detects this change in the applicable channel set and executes the following steps: Step S21: Recalculate the current set of available components based on the mapping table. Since the only currently available channel is SMS, the WhatsApp template message component is no longer included in the set of available components (as this component is only applicable to the WhatsApp channel).

[0094] Step S22: Update the display content of the component toolbox in the visualization workspace and remove the WhatsApp template message component from the component toolbox.

[0095] Step S23: The system checks the components added to the visual workspace. It finds the WhatsApp template message component already exists in the workspace, but it is no longer part of the currently available component set. The channel constraint controller automatically disconnects the component from the workspace and deletes it, while simultaneously notifying the user: "The WhatsApp template message component is only applicable to the WhatsApp channel. The current workflow's applicable channel set (SMS channel only) does not include this channel, and it has been automatically removed from the workspace." This implementation automatically triggers a refresh of the component toolbox and a compatibility self-check of workspace components when the channel type of the process changes. It also automatically disconnects and deletes incompatible channel-specific components, while simultaneously notifying the user. This achieves automated synchronous cleanup of the workspace state after channel configuration changes, fundamentally preventing process execution errors caused by invalid components remaining in the workspace due to channel contraction, thus improving the automation and security of process maintenance.

[0096] In one possible implementation, the workflow orchestration method for multi-channel messaging further includes providing at least one of the following visual editing functions in a visual workspace: component drag-and-drop, branch connection, multi-component selection, undo, and redo.

[0097] This implementation provides a graphical visual editing function, enabling process designers to build multi-channel message processes in a WYSIWYG manner without writing any code, thus significantly reducing the technical threshold for process development.

[0098] S3. In response to the save request of the target process, save the target process if all added process components belong to the available component set.

[0099] In one possible implementation, after the administrator manually saves the process, they prepare to enable it. When the process is enabled, the system performs a channel constraint check to confirm that all components within the workspace belong to the currently applicable channel set. If the check passes, enabling is allowed.

[0100] In another application scenario, an administrator changed the applicable channel set for a workflow from "Instant Messaging" to "SMS Channel Only," but attempted to enable the workflow without manually saving the changes. Upon enabling, the system performed a channel constraint check, detecting that the WhatsApp template message component in the workspace did not belong to the available component set for SMS channels. The check failed, enabling was blocked, and the system displayed the message: "The following component is incompatible with the current channel set: WhatsApp Template Message Component (only applicable to WhatsApp channels). Please modify and try again."

[0101] In one possible implementation, before saving the target process, the process orchestration method for multi-channel messages provided in this application further includes: in response to a creation request, performing at least one of concurrent edit lock verification, configuration validity verification, and logical loop closure verification. Optionally, in response to the administrator clicking save, the system sequentially performs three access control checks: concurrent edit lock verification, configuration validity verification, and logical loop closure verification. Failure of any one of these checks prevents saving and provides a precise prompt. After all three checks pass, the configuration is persisted and the edit lock state is updated. Figure 4 This is a schematic diagram illustrating a process configuration and save verification provided in an embodiment of this application, such as... Figure 4As shown, the operation starts from "Start Saving" and enters the concurrent editing protector to verify the editing lock. If the lock is held by another user, an error message will be displayed indicating that the current process is being edited. If no lock is held, the configuration validity validator will verify the required fields and associated data. If the verification fails, an error message will be displayed accurately and the problematic component will be located. After the verification passes, the logic closed-loop validator will traverse the logic tree to check for any incomplete leaf nodes without an ending node. If any are found, the problematic component will be listed and an error message will be displayed to terminate the saving process. After all verifications are successful, the process configuration will be persisted, the editing lock status will be updated, and the last editor will be recorded. Finally, a message indicating successful saving will be displayed and the process list will be returned.

[0102] This implementation method sets up a multi-layered cascading verification mechanism before saving the process, implementing concurrent conflict detection, configuration semantic verification, and process structure integrity verification in layers, completing full-dimensional verification before process persistence. Compared with the traditional approach of only performing basic syntax checks, this implementation method can more comprehensively ensure the correctness and executability of process configuration, effectively reduce the runtime failure rate after process deployment, and reduce the risk of accidental overwriting of design content due to concurrent editing conflicts.

[0103] Figure 5 This is a flowchart of a concurrent edit lock verification provided in an embodiment of this application.

[0104] In one possible implementation, the concurrent edit lock verification process includes: Upon receiving a heartbeat signal from any user targeting the visual workspace of the process, record the timestamp. In response to a user request to enter the visual workspace, query the current edit lock status and the last editor record; If the current edit lock is held by another user, calculate the duration from the other user's last heartbeat signal to the present; if the duration is less than the preset timeout threshold, refuse entry; if the duration is greater than or equal to the timeout threshold, release the edit lock and grant editing rights. If it is detected that the same user has opened the same process's visual workspace in multiple browser windows at the same time, once one window performs a save operation, only the remaining windows are allowed to perform save or close operations.

[0105] Specifically, system administrator A accesses the workspace of a message flow through a browser to edit. After the front-end page starts, it sends heartbeat signals to the back-end at fixed time intervals (e.g., every 5 seconds), and the back-end continuously updates administrator A's last heartbeat timestamp. At this time, the edit lock status of this flow is "held by administrator A". Subsequently, system administrator B attempts to access the same flow's workspace through a browser on another computer. The system performs the following concurrent edit lock verification steps: Step 1: Query the current edit lock status and the last editor record. The system has learned that the edit lock is held by administrator A, and the last editor record is administrator A.

[0106] Step 2: Calculate the time elapsed since Administrator A's last heartbeat. Assume Administrator A's last heartbeat was 2 seconds ago, and the preset timeout threshold is 30 seconds. The system determines that 2 seconds is less than 30 seconds, the edit lock has not timed out, rejects Administrator B's entry request, and displays the message "The current process is being edited by Administrator A, please try again later."

[0107] At this time, Administrator A's computer disconnected due to a network failure, and the heartbeat signal stopped sending. After 30 seconds of the last heartbeat, the backend determined that the edit lock had timed out and automatically released the edit lock.

[0108] Administrator B attempts to enter the workspace again. The system checks the edit lock status and finds no edit lock currently in use. It then directly grants Administrator B edit privileges, records Administrator B as the current and last editor, and allows them to enter the workspace to edit.

[0109] After the network is restored, Administrator A attempts to re-enter the workspace for the same workflow. The system checks the current edit lock status and finds that it is held by Administrator B. However, the system recognizes that the requester, Administrator A, matches the last editor record (Administrator A), so it directly grants the editing rights without waiting for a timeout. At this point, the edit lock holder changes from Administrator B to Administrator A, and the system sends a notification to Administrator B: "This workflow has been taken over by the last editor."

[0110] If administrator A attempts to open the same workflow workspace simultaneously in another browser window (window 2) without refreshing the browser, the system detects that the same user (administrator A) has the same workflow workspace open in multiple browser windows at the same time. When administrator A performs a save operation in window 1, window 2 detects a configuration conflict. The system only allows window 2 to perform save or close operations to prevent the old state from overwriting the latest configuration already saved in window 1.

[0111] This implementation uses a heartbeat mechanism to automatically release pessimistic locks after timeout, effectively solving the problem of permanent lock occupation caused by abnormal user exits and avoiding the predicament of other users being unable to edit the workflow due to deadlock. Simultaneously, by providing an exemption for the last editor's reconnection scenario, it significantly reduces waiting time in normal collaborative scenarios while ensuring concurrency safety, balancing concurrency safety and user experience, outperforming existing optimistic locking solutions in workflow configuration scenarios. Furthermore, special handling for multi-window scenarios for the same user effectively prevents save conflicts and data overwriting issues caused by the same user editing simultaneously in multiple browser tabs, further ensuring the consistency of workflow configuration.

[0112] In one possible implementation, the logic loop closure verification process includes: Based on the added components, identify the main logic tree with the starting component as the root node and connected by directed branches. Exclude isolated components not connected to the main logic tree from the channel constraint verification scope. Perform a depth-first graph traversal on the main logic tree, skipping branches within the loop during the traversal of loop components. Check each leaf node traversed to determine if it is an end-type component or an end branch. If any leaf node is not an end-type component or an end branch, the process logic is determined to be incomplete, and information on incomplete components is collected to report errors and prevent saving. If all leaf nodes are end-type components or end branches, the process logic is determined to be complete, and the target process is saved.

[0113] Specifically, the system administrator designed a multi-channel message auto-response process in the visual workspace. The workspace contains the following components: start component, time condition component, transfer component, close component, and a send message component that is not yet connected to the main logic tree (this component is an experimental piece that the user temporarily dragged into the workspace and plans to improve later).

[0114] The administrator clicks "Save," and the system triggers a logical loop closure check. The logical loop closure checker executes the following steps: Step 1: Identify the main logic tree rooted at the start component and connected by directed branches. Traverse the tree starting from the start component, following directed branches to reach the time condition component, then the transition component and the shutdown component. The message sending component is not connected to the start component by directed branches and is identified as an isolated component.

[0115] Step 2: Exclude isolated components (i.e. message sending components) that are not connected to the main logic tree from the scope of verification.

[0116] Step 3: Perform a depth-first graph traversal on the main logic tree. The traversal path is: Start component > Time condition component > Time branch of time condition component > Transfer component > End; Non-time branch of time condition component > Close component > End.

[0117] Step 4: Check each leaf node encountered during traversal. Both the transition component and the closing component are termination components, satisfying the loop closure condition.

[0118] Step 5: Determine if the process logic is closed, and allow subsequent save operations to continue. Although the isolated component (message sending component) exists in the workspace, it does not affect the validation results; the administrator can subsequently connect it to the main logic tree or delete it.

[0119] In another possible application scenario, the administrator introduces a loop component into the process. The loop component contains a message sending component and a response waiting component, with the outer branch connecting to a closing component. When the logic loop checker performs a depth-first graph traversal, it detects the loop component node, skips the branches within the loop body, and only continues traversing the outer branch. It confirms that the leaf node of the outer branch is the closing component (end class), and the check passes.

[0120] This implementation performs graph traversal validation on the main logic tree upon saving, ensuring that all execution paths have a definite endpoint, thus eliminating the risk of sessions getting stuck in endless dead ends during runtime. A depth-first traversal algorithm automatically identifies the main logic tree and isolated components, and performs finality checks on all leaf nodes of the main logic tree to ensure that the process does not have any "headless" paths. Simultaneously, branches within loops are skipped during traversal, avoiding misclassifying repeatable execution paths within loops as incomplete loops, making the validation logic more aligned with the actual execution semantics of the business process. The isolated component exclusion mechanism allows designers to temporarily store experimental fragments or sub-processes to be improved in the workspace without being blocked by validation, ensuring both the integrity of the process logic and design flexibility. Existing process editors typically lack this type of graph-level semantic validation capability.

[0121] In one possible implementation, configuration validity verification includes: verifying the completeness of required fields in the process components, the validity of associated data, and mutual exclusion rules between components; in the event of any verification failure, locating the specific component and configuration item, preventing saving, and displaying repair guidance information.

[0122] Specifically, the system administrator configured a workflow in the visual workspace, including a start component, a message sending component, an HTTP request component, and a close component. The administrator clicked save, and the validity validator was configured to perform the following validation process: Required Field Integrity Validation: The validator detected that the message content field of the message sending component was empty (no text was entered), and the request URL field of the HTTP request component was empty. The validator located the specific component and configuration item, prevented saving, and displayed the repair guidance information: "The message content field of the message sending component is required; please enter the message content. The request URL field of the HTTP request component is required; please enter a valid URL address." Related data validity validation: The validator detected that a variable referenced in the variable binding field configured in the HTTP request component is not defined in the process context (it has not been assigned a value in any preceding variable assignment component). The validator locates the specific configuration item, prevents saving, and displays the repair guidance message: "The variable referenced by the HTTP request component is not defined in the process context. Please add a variable assignment component in the process or check if the variable name is spelled correctly." Component Mutual Exclusion Rule Validation: The validator detected that the process simultaneously includes a "menu component (configured with a wait-for-response branch)" and a "message sending component (configured for automatic sending mode)," both with timeouts configured. According to the mutual exclusion rule, if multiple components in the same process are waiting for user responses, their timeouts should be consistent or nested. The validator detected that the menu component's timeout is 60 seconds, and the message sending component's timeout is 30 seconds; these are inconsistent and not nested. The validator prevented saving and displayed a repair guide: "Both the menu component and the message sending component have inconsistent timeouts. Please unify the timeout configurations or clearly define the nesting relationship logically." After the administrator corrected all configuration issues according to the repair guide, they clicked save again. The configuration validity verification passed, and the process entered the subsequent logical closed-loop verification and saving process.

[0123] This implementation performs semantic-level validity checks on the configuration parameters of each component before saving the process, including whether required fields are filled, whether referenced data sources or variables exist, and whether there are mutual exclusion conflicts between components. Compared to simply checking the connectivity of the process structure, this implementation delves into the component-level configuration granularity, enabling more precise location of configuration defects. Furthermore, it reduces the user's error correction costs through explicit repair guidance information, thereby improving the first-time success rate of process configuration.

[0124] S4. In response to the trigger signal that the message session enters the target process, generate a snapshot of the current configuration of the target process.

[0125] The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and at least one channel type. In one possible implementation, the component types include at least one of the following: condition judgment node, time condition node, message sending node, wait for reply node, menu node, loop node, HTTP request node, database query node, variable assignment node, transfer node, and close node; the components are connected by directed branches, and the directed branches include special branches carrying semantic tags.

[0126] Specifically, the message session is a session instance accessed through at least one message channel, including but not limited to SMS channels, instant messaging channels (such as WeChat, WhatsApp, LINE, Facebook Messenger), email channels, and voice call channels. The trigger signal is the entry signal for the message session to enter the target process. The trigger signal is generated by the message routing component after completing channel identification and session allocation and is sent to the process execution engine.

[0127] In one possible implementation, when a user sends a message to an enterprise service account via an instant messaging application, the message gateway receives the message and parses the message header information, extracting the channel type (e.g., WhatsApp), sender identifier (e.g., user's mobile phone number or social media account ID), and message content. The message routing component determines the target flow that the message session should enter based on preset routing rules (e.g., based on message keywords or user profiles) and generates a trigger signal. The trigger signal carries session context information, including but not limited to: a unique session identifier, channel type, sender identifier, receiver identifier, and initial message content. Upon receiving the trigger signal, the process execution engine performs a snapshot generation operation. The snapshot is a deep read-only copy of the current configuration of the target flow, containing the following core data: (a) Directed graph structure The directed graph structure consists of a set of nodes and a set of edges.

[0128] Each node in the node set corresponds to a process component, which is the smallest functional unit for process execution. Each node contains the following attributes: Node unique identifier: A string used to uniquely identify the node in the process; Node Type: Identifies the component type corresponding to this node. The component types include, but are not limited to: start component, condition judgment component, time condition component, send message component, wait for reply component, menu component, loop component, HTTP request component, database query component, variable assignment component, transfer component, and close component; Node display name: The name of the node to be displayed in the visualization workspace; Node configuration parameters: The specific configuration data of this node (see below for details); Node coordinate information: The position coordinates of this node in the visualization workspace (x-coordinate and y-coordinate), used for visualization restoration when displaying snapshots.

[0129] Each edge in the edge set corresponds to a directed branch connecting two nodes, and each edge contains the following attributes: Unique identifier for an edge: A string used to uniquely identify the directed branch in the process; Source node identifier: The unique identifier of the node that marks the starting point of this directed branch; Target node identifier: The unique identifier of the node at the end of this directed branch; Branch type: Identifies the type of the directed branch, including ordinary branches and special branches. Special branches carry semantic tags, which include, but are not limited to: successful transmission, failed transmission, timeout, received reply, condition met, condition not met, etc. Branch condition expression: For conditional branches, record the condition expression corresponding to the branch.

[0130] (ii) Configuration parameters of each node The configuration parameters are the complete configuration data required by each node during execution, and different types of nodes have different configuration parameter structures. Specifically: Start Component: The configuration parameters are empty; it is only used as the entry point identifier for the process.

[0131] Conditional judgment component: Configuration parameters include the judgment field, operators (including >, <, =, ≠, contain, do not contain, between, etc.), and threshold. The conditional judgment component generates two special branches: the condition-satisfied branch (semantically labeled "condition satisfied") and the condition-unsatisfied branch (semantically labeled "condition unsatisfied").

[0132] Time Condition Component: Configuration parameters include a time expression, which supports cron expression format (e.g., "0 0 9-18 * * MON-FRI" represents Monday to Friday 9:00-18:00) and natural language format (e.g., "Weekdays 9:00-18:00"). The time condition component generates two special branches: a time-satisfied branch (semantically labeled "time satisfied") and a time-unsatisfied branch (semantically labeled "time unsatisfied").

[0133] The message sending component's configuration parameters include the message content template, message content type (including text, image, video, file, etc.), whether template variable replacement is supported, and a variable mapping table. During execution, the process execution engine reads the corresponding variable values ​​from the process context and replaces them.

[0134] The Waiting for a Response component has configuration parameters including timeout, allowed response types (including text, button clicks, images, etc.), response content matching rules, and maximum number of waits. The Waiting for a Response component generates three special branches: a Reply Received branch (semantically labeled "Reply Received"), a Timeout Waiting branch (semantically labeled "Timeout Waiting"), and a No Matching branch (semantically labeled "No Matching").

[0135] Menu component: Configuration parameters include menu message content, menu option list (each option includes an option identifier, display text, and corresponding target node), timeout, maximum number of returns, and return counter. The menu component generates three special branches: a receive reply branch (semantically labeled "receive reply"), a wait timeout branch (semantically labeled "wait timeout"), and a no-match branch (semantically labeled "no match"). The wait timeout branch and the no-match branch can be configured with the menu component itself as the target node (i.e., a return menu) to enable looping queries.

[0136] Loop component: Configuration parameters include loop mode (fixed-number loop and conditional loop), number of loops (valid for fixed-number loop), loop condition expression (valid for conditional loop), loop start node identifier, and loop end node identifier. The loop component generates two branches: the loop entry branch (semantic label: "enter loop") and the loop exit branch (semantic label: "exit loop").

[0137] The HTTP request component's configuration parameters include the request URL, request method (including GET, POST, PUT, DELETE, PATCH, etc.), request headers (JSON key-value pairs), request body template, timeout, number of retries, result variable name, and error variable name. The HTTP request component generates two special branches: a success branch (semantically labeled "sent successfully") and a failure branch (semantically labeled "sent failed").

[0138] The database query component's configuration parameters include the data source identifier, query type (including SELECT, INSERT, UPDATE, DELETE), query statement, parameter binding list (mapping process context variables to query parameters), result variable name, and error variable name. The database query component generates two special branches: a query success branch (semantically labeled "sent successfully") and a query failure branch (semantically labeled "sent failed").

[0139] Variable assignment component: The configuration parameters include a list of assignment operations. Each assignment operation includes the target variable name, the assignment source (including constants, process context variables, and expression calculation results), and the assignment expression.

[0140] Transfer component: Configuration parameters include the transfer target type (including message queue, human agent group, external system URL, other processes, etc.) and target address. The transfer component is a termination component; the process terminates after execution.

[0141] Closing component: Configuration parameters include the reason for closing and whether to send an end prompt message. The closing component is a termination component; the process terminates after its execution.

[0142] (III) Channel Type Information The snapshot also records at least one channel type applicable to the target process. The channel type information includes a channel type identifier (such as "whatsapp", "wechat", "sms", "email"), a channel capability set (describing the functions supported by the channel, such as whether it supports template messages, whether it supports button interaction, whether it supports rich text, etc.), and a channel mapping information snapshot (i.e., a mapping table of component and channel type adaptation relationship at the time the snapshot is generated).

[0143] S5. Execute message sessions based on snapshots.

[0144] In one possible implementation, step S4 includes: isolating the snapshot from subsequent configuration changes in the target process, and executing node by node from the start node according to the directed graph structure in the snapshot, until the end node is reached and the current message session is terminated.

[0145] This implementation completely isolates snapshots from subsequent configuration changes, ensuring that each message session instance executes based on the same process definition throughout its entire lifecycle, unaffected by configuration changes occurring simultaneously in the design phase. For scenarios involving asynchronous wait-for-response, this isolation mechanism effectively prevents running instances from entering incorrect branches or referencing deleted nodes due to configuration changes, thus guaranteeing the stability of business processes and the consistency of user experience.

[0146] In one possible implementation, the component types include at least one of the following: condition judgment node, time condition node, message sending node, wait for reply node, menu node, loop node, HTTP request node, database query node, variable assignment node, transfer node, and close node; the components are connected by directed branches, and the directed branches include special branches carrying semantic tags.

[0147] In one possible implementation, step S5 includes: when executing to a waiting reply node or menu node, suspending the current session and starting a timeout timer; and, upon receiving a user reply message, selecting a target special branch according to the semantic tag corresponding to the user reply message to continue execution.

[0148] In another possible implementation, step S5 includes: if a timeout state is detected, selecting a target special branch to continue execution according to the semantic label corresponding to the timeout state.

[0149] In another possible implementation, step S5 includes: when execution reaches a loop node, executing the branch within the loop body according to the loop condition configured in the loop node, and continuing execution by entering the branch outside the loop after the loop ends.

[0150] In another possible implementation, step S5 includes: when executing an HTTP request node or a database query node, calling an external interface adapter to execute the request and updating the execution result in the context of the process as a variable.

[0151] Figure 6 This is a flowchart of a message session execution provided in an embodiment of this application, such as... Figure 6As shown, after receiving a message session creation request, the system first generates a snapshot of the current process configuration using the snapshot isolator, and then hands it over to the process execution engine to start running from the process start node. The engine first determines the type of the current execution node and executes the corresponding logic. Among them, the transfer node executes optional message sending and session destination jump; the close node executes optional message sending and closes the session; the condition / time condition node evaluates the expression and matches the corresponding branch; the send message node pushes the message or file to the corresponding channel and enters the corresponding branch according to the sending result; the wait reply node suspends the session and starts the timeout count; the menu node pushes the menu message and waits for the user's reply and matches the branch; the loop node controls the loop execution according to the number of times or conditions; the HTTP request / database query node executes the call through the external interface adapter and stores the return result; and the variable assignment node updates the process context variable. After completing the processing of various nodes, the system enters the "whether the process has ended" judgment. If it has not ended, it returns to the process execution engine to continue processing the next node. If it determines that the process has ended, it uniformly flows to the session process end node. Relying on snapshot isolation, the session and process configuration are decoupled, covering the standardized execution logic of all node types in the process orchestration.

[0152] Specifically, the following describes the workflow orchestration method for multi-channel messages provided by the embodiments of this application based on a specific application scenario.

[0153] A telecommunications company deployed a message orchestration system that integrates SMS, instant messaging (such as WeChat and WhatsApp), and online customer service channels. The system administrator created an automated message reply workflow suitable for both SMS and online customer service channels using a visual workspace. The directed graph structure of this target workflow is as follows: The root node is the Start component, which connects sequentially to the Time Condition component, the Transition component, and the Close component. The Time Condition component is configured with a working time period expression (e.g., Monday to Friday 09:00-18:00). Its working time branch connects to the Transition component, whose destination is the human agent message queue. Its non-working time branch connects to the Send Message component, which is configured with automated reply text (e.g., "Currently outside working hours, your message has been received, we will process it for you during working hours"). The Send Message component is followed by the Close component. After the administrator completes the workflow configuration and clicks Save, the system sequentially performs concurrent edit lock checks, configuration validity checks, and logical loop closure checks. The logic loop validator traverses the main logic tree, confirms that the endpoint of the working time branch is a transfer component (belonging to the end-of-term component), and the endpoint of the non-working time branch is a closing component (belonging to the end-of-term component). After the verification is successful, the process is saved.

[0154] Subsequently, the system administrator deployed the process online. When a message session enters this process, the system receives a trigger signal and generates a snapshot of the current process configuration. This snapshot includes the directed graph structure of the process, complete configuration parameters for each node (including the working time period expression for the time condition component, the queue address for the transfer component, and the reply text content for the sending message component), and channel application information (SMS channel and online customer service channel). The system completely isolates this snapshot from subsequent process configuration changes. After the first message session A started execution based on the snapshot, the system administrator modified the process configuration—changing the automatic reply text during non-working hours from "Currently it is non-working time, your message has been received, we will process it for you during working hours" to "Currently it is non-working time, please contact us during working hours (Monday to Friday 09:00-18:00)". This modification only affects newly entered message session B after the modification, while message session A continues execution based on the original reply text in its initial snapshot until it terminates upon reaching the close component. The process execution engine executes node by node from the start component based on the directed graph structure in the snapshot: For message session A, the time it enters the process is Monday 20:00. The time condition component determines that the current time is outside of working hours, enters the outside working hours branch, executes the message sending component, sends the original reply text, and then enters the close component to terminate the process execution of this message session.

[0155] This implementation enables the process execution engine to natively support asynchronous interaction models of message channels through waiting response nodes and special branches carrying semantic tags. It accurately routes execution to the corresponding branch, while timeout branches provide fault-tolerant handling paths for abnormal scenarios. Loop nodes support controlled loop execution by a fixed number of times or conditional expressions, suitable for multi-round information collection scenarios. HTTP request nodes and database query nodes achieve data interaction with external systems through external interface adapters, injecting results into context variables for subsequent nodes to reference, enabling the process to make dynamic decisions based on external data. The combination of these execution semantics allows the message flow orchestration system of this application to fully cover all complex process requirements in enterprise-level message automation scenarios, including "multi-round dialogue, data query, loop collection, timeout handling, and dynamic routing," breaking through the capability boundaries of traditional linear script systems.

[0156] In one possible implementation, the method proposed in this application also supports cross-device migration of the target process. After step S3, when implementing cross-device migration, the method proposed in this application includes the following cases A to C.

[0157] Scenario A: When a cross-device migration operation for the target process is detected, the directed branch connections between the pasted components are preserved.

[0158] The configuration file should include at least the directed graph structure of the target process, the configuration parameters of each node, and the set of channel types applicable to the target process. For details, please refer to the previous introduction, which will not be repeated here.

[0159] Specifically, directed branch connections describe the branch connections between components.

[0160] For example, system administrator A designed a multi-channel messaging workflow on one device, including a start component, a conditional decision component, an HTTP request component, a message sending component, and a close component. These components are connected via directed branches. Administrator A exported the workflow configuration as a JSON file. Administrator B then attempted to import this JSON file into the system on another device. For example, in a cross-device paste scenario, administrator A saved the conditional decision component and its downstream branch components on device 1, including the conditional decision component, the message sending component (downstream of the time branch), and the close component (downstream of the non-time branch), all of which have established directed branch connections. Administrator A switched to the same workflow workspace on device 2 and performed a paste operation. The system preserves the branch connections between components during paste—the directed branches between the conditional decision component and the message sending and close components are fully preserved, without requiring administrator B to manually reconnect them.

[0161] Scenario B: When importing the target process through a configuration file, skip components that are not recognized in the configuration file and continue importing the remaining components.

[0162] Optionally, the process configuration file can be in the format of a JSON file, or in other formats such as XML, CVS, YAML, etc.

[0163] For example, system administrator A designed a multi-channel messaging workflow on a device, including a start component, a conditional judgment component, an HTTP request component, a message sending component, and a close component. These components are connected via directed branches. Administrator A exported the workflow configuration as a JSON file. For example, unrecognized components are also called illegal components. For instance, administrator B attempts to import this JSON file into the system on another device. The JSON file contains a node with a component type of "internal test component," which is deprecated in the current system version on the second device and is therefore an illegal component not supported by the system.

[0164] Specifically, a skip strategy is adopted for unrecognized components, skipping the component and its related connections, while continuing to import all other components and connections of the target process, so that the main structure of the process remains complete and usable.

[0165] Optionally, during the import process, a prompt message will be triggered for the skipped components, for example, prompting administrator B "The following component is not supported by the current system and has been skipped: internal test component (ID: node_123)".

[0166] Case C: When importing the target process through a configuration file, remove the missing associated data for components with missing associated data in the configuration file, and retain the component's own configuration parameters.

[0167] For example, associated data refers to data referenced by a component.

[0168] Optionally, trigger a prompt message for the abnormal component, such as prompting administrator B "The data table referenced by the following component does not exist and has been downgraded and retained. Please fix it manually."

[0169] For example, in a cross-device import scenario, the target component includes a database query component whose configuration parameters include the referenced data table "historical_orders". Since this data table has been deleted from the current device system's database, the system executes fault-tolerant import logic, adopting a downgraded retention strategy for the database query component. This retains the component's configuration context (including query SQL statements, variable bindings, etc.) and marks the component's status as "Abnormal - Data Table Does Not Exist". Administrator B is then prompted that "The following component references a data table that does not exist and has been downgraded for retention. Please manually repair: Database Query Component (ID: node_456)". After the import process is complete, Administrator B can repair the abnormal components one by one according to the prompts, without needing to redesign the entire process.

[0170] This embodiment employs a fault-tolerant import and cross-device paste mechanism. When importing JSON, it skips illegal components instead of aborting them, ensuring that the main structure of the process can still be successfully imported even if some components are incompatible. It also adopts a downgrade retention strategy instead of direct deletion for missing related data to avoid data loss. At the same time, it preserves the branch connection relationship between components when pasting across devices, which significantly reduces the reconstruction cost of migrating process configurations between different devices and improves the reuse efficiency of process resources.

[0171] This application utilizes a channel constraint controller to dynamically filter available components based on channel mapping information, eliminating the risk of configuration errors caused by channel-component mismatches from the design stage. This avoids the problem of errors only being exposed after deployment and running, and the high cost of repair, common in traditional solutions. Existing general-purpose low-code platforms lack this channel awareness capability; this application significantly improves the design accuracy and development efficiency of multi-channel messaging flows.

[0172] It should be noted that the workflow orchestration system for multi-channel messages provided in Embodiment 1 above is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the workflow orchestration system for multi-channel messages provided in the above embodiments and the workflow orchestration method for multi-channel messages are based on the same concept, and their specific implementation process can be referred to the method embodiments. Some repeated steps will not be repeated.

[0173] This application provides a computing device for executing the above-described multi-channel messaging workflow orchestration method. Figure 7 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application, such as... Figure 7 As shown, the computing device includes a processor 701, a memory 702, a bus 703, and a computer program stored in the memory 702 and executable on the processor 701. The processor 701 includes one or more processing cores. The memory 702 is connected to the processor 701 via the bus 703 and is used to store program instructions. When the processor executes the computer program, it implements all or part of the steps in the above-described multi-channel message flow orchestration method embodiments provided in this application.

[0174] Furthermore, as an executable solution, the aforementioned computing device can be a computer unit, which may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer unit may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above-described computer unit structure is merely an example and does not constitute a limitation on the computer unit. It may include more or fewer components, or combine certain components, or different components. For example, the computer unit may also include input / output devices, network access devices, buses, etc., which are not limited in this application embodiment.

[0175] Furthermore, as an executable solution, the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer unit, connecting various parts of the entire computer unit via various interfaces and lines.

[0176] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer unit by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital card (SD card), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0177] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements all or part of the steps of the multi-channel message flow orchestration method described in the embodiments of this application.

[0178] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements all or part of the steps of the multi-channel message flow orchestration method described in the embodiments of this application.

[0179] If the modules / units integrated by the aforementioned computing units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

[0180] Although this application has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to this application without departing from the spirit and scope of this application as defined by the appended claims, and all such changes shall be within the scope of protection of this application.

Claims

1. A workflow orchestration method for multi-channel messaging, characterized in that, include: S1. In response to the editing operation of the target process, determine the set of available components of the target process based on the set of channel types and channel mapping information applicable to the target process, and display the process components in the set of available components in the visualization workspace. The channel mapping information records the adaptation relationship between each channel type and process component. S2. When the set of channel types applicable to the target process changes, the set of available components is re-determined based on the channel mapping information, and channel-specific components that do not belong to the re-determined set of available components in the added process components are disconnected and deleted from the target process. S3. In response to the request to save the target process, if all added process components belong to the set of available components, save the target process; S4. In response to the trigger signal of the message session entering the target process, generate a snapshot of the current configuration of the target process. The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and the set of channel types applicable to the target process. S5. Execute the message session based on the snapshot.

2. The method according to claim 1, characterized in that, The method further includes: When a cross-device migration operation for the target process is detected, the directed branch connections between the pasted components are preserved; When the target process is imported through the configuration file, a skip strategy is adopted for components that cannot be identified in the configuration file and the remaining components are imported. For components with missing associated data in the configuration file, the missing associated data is removed and the component's own configuration parameters are retained.

3. The method according to claim 1, characterized in that, The method further includes: The visual workspace provides at least one of the following visual editing functions: component drag and drop, branch connection, multi-component selection, undo, and redo.

4. The method according to claim 1, characterized in that, Step S5 includes: isolating the snapshot from subsequent configuration changes of the target process, and executing each node one by one from the start node according to the directed graph structure in the snapshot until the end node is reached and the current message session is terminated.

5. The method according to claim 1, characterized in that, Before saving the target process, the method further includes: in response to the save request, performing at least one of concurrent edit lock verification, configuration validity verification, and logical loop closure verification.

6. The method according to claim 5, characterized in that, The concurrent edit lock verification includes: Upon receiving a heartbeat signal from any user targeting the visual workspace of the target process, record the timestamp; In response to a user request to enter the visual workspace, query the current edit lock status and the last editor record; If the current edit lock is held by another user, calculate the duration from the other user's last heartbeat signal to the present; if the duration is less than a preset timeout threshold, refuse entry; if the duration is greater than or equal to the timeout threshold, release the edit lock and grant editing rights. If it is detected that the same user has opened the same process's visual workspace in multiple browser windows at the same time, once one window performs a save operation, only the remaining windows are allowed to perform save or close operations.

7. The method according to claim 5, characterized in that, The logical closed-loop verification includes: Based on the added components, identify the main logic tree with the starting component as the root node and connected by directed branches, and exclude isolated components that are not connected to the main logic tree from the scope of channel constraint verification. A depth-first graph traversal is performed on the main logic tree, skipping branches within loops during the traversal of loop components; Examine each leaf node encountered during traversal to determine whether it is an ending component or an ending branch; If any leaf node is not an end-type component or an end branch, the process logic is determined to be not closed, the information of the unclosed components is collected, an error is reported, and saving is prevented. If all leaf nodes are end-of-process components or end-of-process branches, the process logic is considered closed, and the target process can be saved.

8. The method according to claim 5, characterized in that, The configuration validity verification includes: Verify the completeness of required fields in the verification process components, the validity of associated data, and the mutual exclusion rules between components. If any verification fails, locate the specific component and configuration item, prevent saving, and display the repair guidance information.

9. The method according to claim 1 or 4, characterized in that, The types of components include at least one of the following: condition judgment node, time condition node, message sending node, wait for reply node, menu node, loop node, HTTP request node, database query node, variable assignment node, transfer node, and close node; the components are connected by directed branches, which include special branches carrying semantic tags; Step S5 includes at least one of the following: When execution reaches a node waiting for a reply or a menu node, suspend the current session and start a timeout timer; if a user reply message is received, select the target special branch according to the semantic tag corresponding to the user reply message and continue execution; If a timeout is detected, select the target special branch according to the semantic label corresponding to the timeout state and continue execution; When execution reaches a loop node, the branches within the loop body are executed according to the loop condition configured in the loop node. After the loop ends, execution continues into the branch outside the loop. When an HTTP request node or a database query node is reached, the external interface adapter is invoked to execute the request, and the execution result is updated to the context of the process as a variable.

10. A workflow orchestration system for multi-channel messaging, characterized in that, include: The process creation module and the process execution module; The process creation module is used to respond to the editing operation of the target process, determine the set of available components of the target process based on the set of channel types and channel mapping information applicable to the target process, and display the process components in the set of available components in the visual workspace. The channel mapping information records the adaptation relationship between each channel type and process component. The process creation module is also used to redetermine the available component set according to the channel mapping information when the set of channel types applicable to the target process changes, and disconnect and delete channel-specific components that do not belong to the redetermined set of available components from the target process among the added process components; In response to a request to save the target process, the target process is saved if all added process components belong to the set of available components. The process execution module is used to generate a snapshot of the current configuration of the target process in response to the trigger signal of the message session entering the target process. The snapshot includes the directed graph structure of the target process, the configuration parameters of each node, and the set of channel types applicable to the target process. The process execution module is also used to execute the message session based on the snapshot.

Images