A method and system for visualizing call flow orchestration

Abstract

The application relates to the technical field of enterprise communication, and discloses a visual call flow arrangement method and system, which comprises the following steps: receiving a request to enter a call flow editing area; calling a concurrent editing mutex guard to query an editing lock state of the call flow editing area; when the editing lock is in an idle state or a current editing user is the initiator of the request, entering the call flow editing area and starting a heartbeat reporting mechanism; calling a mutex constraint engine in real time to perform legality verification on ordinary components and call end components respectively; if the operation type of a keep instruction is a release state, sequentially performing component configuration legality verification, component mutex relationship verification and logic closed loop detection; tracking reference relationships of each level variable based on an expression evaluator; and triggering a call post-processing chain after executing the call end component. The application solves the technical problems of missing end call semantic constraint, chaotic variable scope and difficult-to-identify suspended branches in the existing call flow arrangement.

Description

Technical Field

[0001] This invention relates to the field of enterprise communication technology, and in particular to a visual call flow orchestration method and system. Background Technology

[0002] In the context of call flow orchestration in enterprise communication technology, the process of a call from system access to final release involves a series of automated processing steps, including playing voice messages, receiving key input, conditional routing, database queries, and transferring to agents. These steps and their jump relationships logically constitute a directed graph, where nodes represent processing actions and edges represent execution flows. The essence of call flow orchestration is the process of building and managing this directed graph. Existing automated call processing relies on script-based configuration of dedicated switches, using domain-specific languages ​​to write dialing plans, and controlling the execution order through line numbers and jump instructions—that is, the business logic is tightly coupled with the underlying execution engine. When the process needs to determine the branch direction based on external real-time data, the conditional judgments embedded in the script are only static expressions, requiring calls to independent programs via external gateway interfaces. Furthermore, composite logic can only be achieved through nested jumps, drastically reducing code readability. Its understanding of the process is linear and static; it only executes commands and cannot detect configuration errors, resulting in a rigid branch structure that is highly prone to errors.

[0003] To address the aforementioned issues, existing technologies employ low-code visual process editors to convert process scripts into a graph structure involving node drag-and-drop and connections. This graph structure is then serialized into a generic data format for storage and parsing and execution by an engine. However, visual editors typically only verify the compatibility of input and output types between directly adjacent nodes, but they cannot understand the deeper semantics of "call termination," thus lacking the ability to perform full-path propagation and constraint inference for call termination semantics. Furthermore, the existing single-scope model cannot isolate state pollution between concurrent calls, nor can it implement read / write permission control for shared configurations. Once a mistake is made, it will pollute the global business logic and cannot guarantee the legality of the entire graph topology. This may result in branches with dangling ends, causing the call to enter a rigid state that cannot be terminated. At the same time, the editor confuses the semantics of call termination and process termination, equating the release of physical links with the termination of logical processes when a call is terminated, and lacks post-call processing orchestration. However, in actual enterprise scenarios, subsequent actions such as database writing and message notifications that no longer depend on call signaling are required after hanging up, which usually requires external polling or hard-coded callbacks. Moreover, multi-user concurrent editing relies on static locking mechanisms, which are prone to configuration overwrite risks or deadlocks. Summary of the Invention

[0004] The purpose of this invention is to provide a call flow orchestration scheme that combines semantic tag propagation, three-layer namespace and access mode control, three-layer progressive verification, and decoupling of scheduling termination conditions. It systematically solves the technical problems of existing call flow orchestration methods, such as single variable scope, uncontrollable lifecycle, and inability to verify the semantic integrity of graph topology, through multiple dimensions including joint graph constraint inference, variable isolation and access control, topology integrity verification, and context lifecycle management.

[0005] In a first aspect, embodiments of the present invention provide a visual call flow orchestration method, including: Received a request to enter the call flow editing area; The concurrent editing mutex guard is invoked to query the edit lock status of the call flow editing area; when the edit lock is in an idle state or the current editing user is the initiator of the request, the request is allowed to enter the call flow editing area, and the heartbeat reporting mechanism is initiated. In response to dragging, connecting and configuring operations of components in the call flow editing area, the mutual exclusion constraint engine is invoked in real time to perform legality checks on ordinary components that do not have call termination semantics and call termination type components that carry call termination semantics. Based on the set of component instances that have passed the legality verification and their connection relationships, a directed graph of the call flow is generated; all variables in the directed graph of the call flow are divided into a local variable layer, a global variable layer, and a system variable layer. Identify the operation type of the instruction to save the directed graph of the call flow and perform the following judgments: If the operation type is draft state, the current canvas data is directly stored in the draft storage; if the operation type is publish state, three layers of verification are performed in sequence, consisting of component configuration validity verification, component mutual exclusion relationship verification, and logical loop detection; if any layer of verification fails, the error information is summarized and publication is prevented; if all three layers of verification pass, the directed graph of the call flow is published and written to the published storage. The expression evaluator tracks the reference relationships of variables at each level, sequentially resolving the system variable layer, local variable layer, and global variable layer, and returning the currently valid variable values. When a variable is deleted or the process to which the variable belongs is disabled, a failure notification is sent to all referencing components, and the failure information is summarized and displayed when re-entering the call process editing area. After executing the call end component, the call post-processing chain is triggered to continue verifying and executing subsequent components in the call post-processing chain.

[0006] Secondly, embodiments of the present invention also provide a visual call flow orchestration system, the system comprising: The concurrent editing mutual exclusion guard module is used to receive requests to enter the call flow editing area, query the editing lock status, and when the editing lock is in an idle state or the current editing user is the initiator of the request, allow the request to enter the call flow editing area and start the heartbeat reporting mechanism; The visualization canvas module is used to generate a directed graph of the call flow consisting of a set of component instances and their connection relationships in response to dragging, connecting, and configuring operations of components in the call flow editing area. The mutual exclusion constraint engine module is used to perform legality checks on ordinary components and call-end components; The variable management module is used to divide all variables in the directed graph of the call flow into local variable layer, global variable layer and system variable layer, and track the reference relationship of variables at each level; The save and verification management module is used to identify the operation type of the save command for the directed graph of the call flow. If the operation type is draft, the current canvas data is directly saved to the draft storage. If the operation type is publish, a three-layer verification consisting of component configuration legality verification, component mutual exclusion relationship verification, and logical loop detection is triggered in sequence. If any layer of verification fails, the error information is summarized and publication is blocked. When all three layers of verification pass, the directed graph of the call flow is published and written to the published storage. The expression evaluator module is used to sequentially parse the system variable layer, local variable layer, and global variable layer and return the currently valid variable values ​​to support the branch selection of the condition component and the operation of the variable assignment component; The variable failure notification module is used to send a failure notification to all referencing processes when a variable is deleted or the process to which the variable belongs is disabled, and to summarize and display the failure information when re-entering the call process editing area. The post-call processing chain module is used to trigger the post-call processing chain after the execution of the call end component, and to continue to verify and execute the subsequent components in the post-call processing chain.

[0007] Thirdly, embodiments of the present invention also provide an electronic device, characterized in that it includes: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any of the first aspects.

[0008] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, characterized in that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the method as described in any of the first aspects.

[0009] This invention fills a technical gap in the field of call flow orchestration regarding the semantic transitivity of call termination. By introducing a whitelist of termination categories, hang-up and transfer components are assigned a "call termination" semantic tag. This allows the mutual exclusion constraint engine to recursively propagate the single-point semantic of "call terminated" along directed edges to all indirect successor nodes, thereby raising the verification granularity from the edge level to the graph topology level. This enables the editor to automatically identify and prevent the configuration of flow paths that will inevitably fail at runtime due to the release of physical links during the flow construction phase. The three-layer scope variable system and reference validity tracking mechanism adapted to call scenarios constructed in this invention establish a three-level isolated namespace in the variable registry, consisting of a system variable layer, a global variable layer, and a local variable layer. Variables in each call flow are physically isolated in storage and semantically consistent in their initial state. This eliminates the temporal coupling problem of residual values ​​between calls and avoids the risk of accidental modification of shared configurations during cross-flow collaboration. Variable conflicts and dangling references are downgraded from occasional runtime failures to being detected and fixed at design time.

[0010] This invention introduces for the first time an automatic detection mechanism for graph topology-level logical closed loops in the field of call orchestration. After verification, it employs a draft and published state partitioned storage mechanism, balancing orchestration efficiency with publishing rigor. The published state is written to the published storage only after undergoing three layers of progressive verification; any error immediately halts subsequent verifications, avoiding unnecessary full graph traversal overhead. Furthermore, this invention decouples the scheduling termination condition from the call link termination event, enabling for the first time the ability to continue scheduling subsequent components within the same process execution engine after a call ends. The scheduling termination condition of the process execution engine is redefined as "the current component has no valid successor," allowing the engine to continue querying subsequent components and reusing the mutual exclusion constraint engine after completing the signaling layer's hang-up or transfer actions. This achieves end-to-end scheduling closed loops within the same execution engine, eliminating the risk of asynchronous external program and process configurations. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a visual call flow orchestration method provided in an embodiment of the present invention.

[0012] Figure 2 This is a flowchart for inferring the transitivity of mutual exclusion constraints for end-class components, provided in an embodiment of the present invention.

[0013] Figure 3 The flowchart for logical closed-loop detection provided in the embodiments of the present invention is shown.

[0014] Figure 4 This is a schematic diagram of the structure of a visual call flow orchestration system provided in an embodiment of the present invention. Detailed Implementation

[0015] The present invention will be described in detail below through embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0016] In this invention, the terms "in one possible embodiment," "exemplary," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "in one possible embodiment," "exemplary," or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "in one possible embodiment," "exemplary," or "for example" is intended to present the relevant concepts in a specific manner.

[0017] In the context of call flow orchestration in enterprise communications, existing visual editors store direct sequential relationships in node pairs. When a hang-up or transfer component carrying call termination semantics appears in the flow, all subsequent nodes are in a state where the physical link has been released. However, the editor's validation granularity remains at the edge level, which cannot converge the constraint semantics to subsequent nodes.

[0018] Furthermore, the existing editor uses an event-driven local validator, which only triggers adjacent node validation during a single connection operation. It cannot automatically detect the topological convergence of the entire graph, resulting in workflows containing dangling branches being successfully published and deployed. Simultaneously, the existing variable system uses a single namespace, lacking hierarchical modeling and differentiated control over access patterns. This makes it impossible to detect variable conflicts and dangling references during the editing phase, severely impacting workflow orchestration efficiency and deployment security.

[0019] The existing process implementation directly maps the session termination event of the communication protocol layer to the scheduling termination command of the process orchestration engine, which causes the process scheduling lifecycle to be coupled with the physical call signaling lifecycle. It fails to provide an independent running environment for data processing logic after the signaling is released, and cannot realize subsequent data persistence, external callbacks and message notifications after the call is hung up.

[0020] Therefore, it is necessary to propose a new method to solve the technical problems existing in the current visual call flow orchestration tools, such as the lack of call semantic constraints, chaotic variable scope, difficulty in identifying dangling branches, and frequent concurrent editing conflicts.

[0021] Firstly, embodiments of the present invention provide a visual call flow orchestration method, such as... Figure 1 As shown, it includes the following steps: S110, a request to enter the call flow editing area has been received.

[0022] Specifically, the call flow editing area is a front-end canvas container that carries visual drag-and-drop arrangement operations. After a user logs into the business platform through a browser, selects the target call flow in the browsing management list and triggers the editing operation, the front-end sends an entry request to the back-end. The request message carries at least the user's identity identifier, the target flow's unique identifier, and the client's session token.

[0023] S120: Invoke the concurrent editing mutex guard to query the edit lock status of the call flow editing area; when the edit lock is in an idle state or the current editing user is the initiator of the request, allow the request to enter the call flow editing area and start the heartbeat reporting mechanism.

[0024] Specifically, the concurrent edit mutual exclusion guard is deployed as an independent collaborative protection component on the backend of the business platform. Internally, it maintains an edit lock table with a unique process identifier as the primary key. Each lock record in this edit lock table includes the current lock-holding user ID, the locking timestamp, the last heartbeat timestamp, and a lock status field. The current lock-holding user ID records the identity of the user currently holding editing privileges, the locking timestamp records the initial creation time of the lock, and the lock status field indicates whether the lock is currently idle or locked.

[0025] When a request reaches the backend, the concurrent edit mutex guard first parses the process identifier of the target call process from the request message, retrieves the edit lock table based on the process identifier, and performs the following judgment: First, if there is no record in the lock table with the process identifier as the primary key, or if there is a lock record but the lock status field is idle, it is considered that the current state is unedited. At this time, a new lock record is created for the initiator of the request, the lock holder user identifier field is assigned to the initiator's user identifier, the lock timestamp and the last heartbeat timestamp are both assigned to the current system time, the lock status field is set to locked, and an admission response is returned.

[0026] Second, if a record with the process identifier as the primary key exists in the lock table and is in a locked state, and the value of the lock-holding user identifier field matches the user identifier of the request initiator, then it is determined to be a cross-window re-entry scenario for the same user or a recovery and reconnection scenario after a brief network interruption. In this case, the last heartbeat timestamp of the existing lock record is updated to the current system time, and an admission response is returned.

[0027] Third, if there is a record in the lock table with the process identifier as the primary key and it is locked, and the value of the lock-holding user identifier field is inconsistent with the user identifier of the request initiator, it is determined that someone else is currently editing the process online. At this time, a rejection response with the message "process is being edited" is returned to the front end of the request initiator, and the identifier information of the current lock-holding user is attached to the response body, thus terminating the request process and preventing the initiator from entering the editing area.

[0028] Once the request is granted, the front-end page immediately initiates a heartbeat reporting mechanism while loading the editor's main interface. It also starts a loop timer to send lightweight heartbeat messages to the back-end at fixed intervals of a preset duration. The heartbeat message includes at least two fields: the current process identifier and the current user identifier. After the back-end successfully receives and verifies the heartbeat message each time, it looks up the corresponding lock record in the editor lock table based on the process identifier in the message and updates the last heartbeat timestamp of that record to the current system time.

[0029] S130 responds to drag-and-drop, connection and configuration operations of components in the call flow editing area, and calls the mutual exclusion constraint engine in real time to perform legality checks on ordinary components and call end components respectively.

[0030] Specifically, when a connection action is detected from the front end, the backend mutex constraint engine is synchronously invoked in an event-driven manner. The type, identifier, and current propagation state of the starting and ending components of the connection are submitted. Based on the mutex rule table and the whitelist of ending categories, the mutex constraint engine performs legality checks on ordinary components that do not have call termination semantics and call termination category components that carry call termination semantics. If the check is successful, the component with the corresponding component identifier is immediately fed back to the editing area. If the check fails, the illegal connection is rejected and a mutex reason prompt is displayed.

[0031] S140, Based on the set of component instances that have passed the legality verification and their connection relationships, generate a directed graph of the call flow; divide all variables in the directed graph of the call flow into a local variable layer, a global variable layer and a system variable layer.

[0032] Specifically, the directed graph of the call flow is a formal expression of component instances and connection relationships on the editing area. Each node corresponds to a component instance and carries a snapshot of its configuration parameters. Each directed edge corresponds to a connection operation and carries a conditional branch label, such as the true / false branch of the condition component Condition and the button branch of the menu component Menu.

[0033] S150, identify the operation type of the instruction to save the directed graph of the call flow and perform the following judgment: if the operation type is draft state, the current canvas data is directly stored in the draft storage; if the operation type is publish state, the three-layer verification consisting of component configuration legality verification, component mutual exclusion relationship verification and logical loop detection is performed in sequence; if any layer of verification fails, the error information is summarized and publication is blocked; if all three layers of verification pass, the directed graph of the call flow is published and written to the published storage.

[0034] Specifically, when a user clicks the "Save as Draft" button, the current call flow directed graph, along with its incomplete intermediate states, is directly serialized and written to the draft storage partition. This allows the flow to be in any incomplete state, and the draft storage flow is not open to the call access channel.

[0035] When the user clicks the "Save and Enable" button, a three-layer progressive verification is triggered. If any layer fails, the execution of the subsequent layers is blocked, and the error information collected by that layer is presented to the user in a list. Only when all three layers of verification pass will the system publish the directed graph and write it to the published storage partition.

[0036] S160 tracks the reference relationships of variables at each level based on the expression evaluator, resolves the system variable layer, local variable layer and global variable layer in sequence and returns the currently valid variable value; when a variable is deleted or the process to which the variable belongs is disabled, it sends an invalidation notification to all referencing components and summarizes and displays the invalidation information when re-entering the call process editing area; after executing the call end class component, it triggers the call post-processing chain and continues to schedule subsequent valid components.

[0037] Specifically, the expression evaluator first parses the expression text and extracts all variable references identified by a preset prefix. Then, it searches layer by layer according to the priority order of "system variable layer, local variable layer, global variable layer". If a variable value is found at the current layer, it immediately returns and terminates the search. If no value is found, it continues to search at the next lower layer. If no variable reference is found at any layer, it returns an empty value and records an undefined variable warning message.

[0038] The expression evaluator substitutes the current actual value of the extracted variable into the corresponding position in the expression one by one. After completing the variable substitution, it performs arithmetic or logical operations according to the operator semantics of the expression, returns the operation result to the calling component, and records the current component instance identifier, process identifier, configuration field path and variable name of each referenced variable as a reference record.

[0039] When a variable is deleted or the process to which the variable belongs is disabled, all reference records are retrieved in reverse order using the variable name or the identifier of the disabled process as an index. This identifies all referencing components and their respective processes, and a failure notification is pushed to each referencing component. When the process to which the referencing component belongs is next opened and entered into the editing area, this failure notification will be displayed in a structured list, summarizing the component name, configuration field path, and failed variable name of each failed reference, allowing users to locate and fix each item systematically.

[0040] In addition, after the process reaches the call termination component, it continues to query the successor component of the call termination component along the directed edge, reuses the mutual exclusion constraint and engine, and determines whether each successor component belongs to the predefined post-processing component in the termination whitelist; if it is determined to belong to the termination whitelist, the successor component continues to be scheduled for execution along the directed edge.

[0041] This invention fills a technical gap in the field of call flow orchestration regarding the semantic transitivity of call termination. By introducing a whitelist of termination categories, hang-up and transfer components are assigned a "call termination" semantic tag. This allows the mutual exclusion constraint engine to recursively propagate the single-point semantic of "call terminated" along directed edges to all indirect successor nodes, thereby raising the verification granularity from the edge level to the graph topology level. This enables the editor to automatically identify and prevent the configuration of flow paths that will inevitably fail at runtime due to the release of physical links during the flow construction phase. The three-layer scope variable system and reference validity tracking mechanism adapted to call scenarios constructed in this invention establish a three-level isolated namespace in the variable registry, consisting of a system variable layer, a global variable layer, and a local variable layer. Variables in each call flow are physically isolated in storage and semantically consistent in their initial state. This eliminates the temporal coupling problem of residual values ​​between calls and avoids the risk of accidental modification of shared configurations during cross-flow collaboration. Variable conflicts and dangling references are downgraded from occasional runtime failures to being detected and fixed at design time.

[0042] This invention introduces for the first time an automatic detection mechanism for graph topology-level logical closed loops in the field of call orchestration. After verification, it employs a draft and published state partitioned storage mechanism, balancing orchestration efficiency with publishing rigor. The published state is written to the published storage only after undergoing three layers of progressive verification; any error immediately halts subsequent verifications, avoiding unnecessary full graph traversal overhead. Furthermore, this invention decouples the scheduling termination condition from the call link termination event, enabling for the first time the ability to continue scheduling subsequent components within the same process execution engine after a call ends. The scheduling termination condition of the process execution engine is redefined as "the current component has no valid successor," allowing the engine to continue querying subsequent components and reusing the mutual exclusion constraint engine after completing the signaling layer's hang-up or transfer actions. This achieves end-to-end scheduling closed loops within the same execution engine, eliminating the risk of asynchronous external program and process configurations.

[0043] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, a mutual exclusion constraint engine is invoked to perform legality checks on ordinary components that do not have call termination semantics and call termination class components that carry call termination semantics, such as... Figure 2 As shown, it includes the following steps: 1. Before establishing the connection relationship from the first component A to the second component B, the mutual exclusion constraint engine first identifies and determines whether the first component A is a call-end class component or its indirect successor node.

[0044] Among them, call termination components are special component types that carry call termination semantic markers. Specifically, they include hang-up components for actively disconnecting the current call link and transfer components for transferring call control to an external agent or third-party number, indicating that the main logical path of the current call has ended. Its indirect successor nodes refer to all downstream nodes reachable along the directed graph from any call termination component via any number of directed edges.

[0045] 2. If the first component A is not a call-ending component and is not an indirect successor of a call-ending component, then the first component A is classified as a normal component, and the preset mutual exclusion rule table is queried to check whether the direct connection between the first component A and the second component B is allowed to establish a directed connection; if the check passes, the directed edge is connected and the second component B is marked as a normal component; if the check fails, the connection is rejected and a prompt message containing the reason for the mutual exclusion is returned. The mutual exclusion rule table uses a combination of two component types as the primary key and a boolean value indicating whether a connection is allowed as the value. It is used to define whether a direct directed connection is allowed between any two components.

[0046] 3. If the first component A is a call termination component or its indirect successor node, then determine whether the second component B is included in the termination whitelist; if the second component B is not in the termination whitelist, then block the connection and return a prompt that the call has ended or been transferred; if the second component B is in the termination whitelist, then connect the directed edge and mark the second component as a call termination component.

[0047] The whitelist of termination components is a pre-registered list of post-processing components that are allowed to continue execution in the context of a call ending. Its execution process does not depend on an active call link, involves data processing and external integration, and can be legally executed after the call ends. These include, but are not limited to, variable assignment components (Variable Ops) and developer components (Developer, such as logging components, external interface request components, database access components, and message sending components).

[0048] 4. After establishing the connection, mark the second component B as a call end and pass the end-class constraint mark to all successor nodes of the second component B along the directed graph. Check whether each passed successor node exists in the end-class whitelist. If it exists, continue to pass the end-class constraint mark down along the directed edge; if it does not exist, determine its corresponding directed edge as illegal and refuse the connection.

[0049] This embodiment distinguishes between two verification paths: ordinary paths and termination-constraint paths. Ordinary components only verify the direct preceding and following relationships in the mutual exclusion rule table, resulting in low overhead and fast execution speed. Termination-constraint components, on the other hand, propagate termination-type constraints layer by layer down the directed graph, ensuring that the call termination semantics constrain not only its direct successors but also all its indirect successors. This completely blocks the construction of paths that will inevitably fail at runtime during the orchestration phase, significantly reducing the operational failure rate and user complaint rate of call services. exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, a three-layer verification consisting of component configuration validity verification, component mutual exclusion relationship verification, and logical loop detection is performed sequentially. The specific steps include: The first layer is for validating the component configuration: The component configuration validator iterates through each instance in the directed graph of the call flow, performing mandatory field validation, field type matching validation, and related data existence validation on the configuration items of each component. Validation passes only if all component instances satisfy the validity checks. After completing the full graph traversal, the validator summarizes all non-compliant components and their corresponding error details into a structured report and feeds it back to the front end.

[0050] Specifically, the existence verification of associated data includes: verifying the validity of variables referenced by component instances, voice resources, database connections, and external interface addresses. For example, required field verification might include the voice resource identifier of the Prompt component and the SQL statement body of the Database Access component; field type matching verification is used to confirm that the data type of the attribute value is consistent with the type defined in the configuration template, such as the timeout duration field must be a positive integer and the conditional expression field must conform to the expression syntax.

[0051] The second layer is for component mutual exclusion validation: By reusing the mutual exclusion constraint engine, a global validity inference is performed on all directed edges of the directed graph of the call flow. The validation passes if and only if all directed edges are valid. This prevents the retention of historical illegal edges caused by changes in component type, rule table updates, or undo / redo operations during the editing process, and ensures consistency of the published flow in the mutual exclusion constraint dimension.

[0052] The third layer is for logical loop closure detection: Construct a main logic tree with the starting component of the call flow directed graph as the root node, and traverse all leaf nodes of the main logic tree to determine whether each leaf node converges to the call end class component or the end branch; the verification passes if and only if all leaf nodes meet the convergence condition.

[0053] Among them, the ending branch refers to the branch endpoint that is identified as closed in the logical loop detection and does not need to be connected to the call end component.

[0054] This invention's three-layer verification decouples three orthogonal constraints—configuration correctness, connection validity, and topology integrity—into independent and ordered verification stages. The progressive verification strategy prioritizes exposing the lowest-cost and most frequently occurring configuration errors, avoiding energy-intensive full graph traversal when the configuration is incomplete, thus improving overall verification efficiency. Simultaneously, any failure at a verification layer results in a summary list of errors for that layer, providing users with structured feedback that allows for item-by-item location and repair, rather than a general release failure message. This invention, while ensuring the release process is free of configuration defects, illegal connections, or dangling branches, minimizes the cost of manual item-by-item checks before release.

[0055] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, it is determined whether each leaf node converges to the call end class component or the end branch.

[0056] like Figure 3 The flowchart for logical loop detection shown below, after triggering the save command and enabling verification, constructs the main logic tree with the starting component as the root node. During the traversal of the main logic tree, the following judgment is performed on each leaf node visited: Step a1: Determine whether the leaf node is a loop component.

[0057] Specifically, a loop component is a flow control component that repeatedly schedules a specified sequence of components. It includes three topological elements: loop entry, loop body subgraph, and loop exit. The loop entry is used to mark the starting point of repeated execution, the loop body subgraph is used to carry the repeatedly scheduled sequence of components, and the loop exit is used to export to the downstream when the loop terminates.

[0058] In step a2, if the leaf node is a loop component, skip the repeatedly executed path within the loop body, only obtain the exit directed edge of the loop component, include the subsequent path of the exit directed edge in the monitoring, and determine whether each end node of the subsequent path converges to a call end component or an end branch. If any end node does not converge, mark the corresponding component as an unclosed loop component.

[0059] Step a3: If the leaf node is not a circular component, determine whether the current leaf node is connected to the main logic tree; if not, determine that the current leaf node is an independent node and skip the current leaf node and do not participate in the detection; if connected, further determine whether the leaf node is a call end component or an end branch.

[0060] If so, the current branch is determined to be closed, and the process continues to traverse the next leaf node; otherwise, the current leaf node is marked as an unclosed component, and the component identifier and the branch path information are recorded.

[0061] Step a4: After the traversal is complete, summarize all marked unclosed components, generate a pop-up prompt containing the identifier of each component and the branch path it belongs to, and prevent the save or enable operation.

[0062] This invention achieves automatic identification of suspended branches at the graph topology level, avoiding infinite recursion and misjudgments caused by loop structures while ensuring the closed-loop requirement of the path after the loop. By exempting independent nodes, it avoids the accidental blocking of reasonable temporary segments. By recording the identifier and branch path of unclosed components and displaying pop-up prompts, users can accurately locate problematic branches. If a user configures a timeout branch and an invalid input branch for the employee ID input component but misses subsequent processing, the detector will accurately locate and display a pop-up prompt that the two branches are not closed, thereby preventing call anomaly errors caused by "reaching a branch after an incoming call but having no exit" before release.

[0063] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, all variables in the directed graph of the call flow are divided into a local variable layer, a global variable layer, and a system variable layer.

[0064] Specifically, a two-level namespace, namely a global variable layer and a local variable layer, is pre-established in the variable registry, and a system variable layer is configured. The three namespaces are distinguished from each other by a unified variable prefix, forming a hierarchical isolation.

[0065] The global variable layer is used to persistently record the definition information and reference records of each global variable. Global variables are prefixed with "$GlobalCustom." and their values ​​are shared across multiple processes. They are restored to their initial values ​​upon system restart and support both read-write and read-only modes. In read-only mode, global variables can only be read and cannot be written by assignment-type components, which can prevent accidental writing of shared configurations during multi-process collaboration.

[0066] The local variable layer is used to persistently record the definition information and reference records of each local variable. Local variables are uniformly prefixed with "$Custom.", and their scope is strictly limited to the current process instance. They are restored according to their initial values ​​each time a call process is entered, and released when the call ends. This ensures that local variables between different call instances and different processes do not interfere with each other.

[0067] The definition information includes the variable name, variable type, initial value, and access mode.

[0068] The system variable layer is dynamically maintained by the process execution engine at runtime, including session fixed variables and component output dynamic variables. Session fixed variables are automatically injected by the telecommunications signaling layer when a call is received and remain unchanged throughout the call lifecycle. These include, but are not limited to, the caller ID "$ani", the unique call identifier "$callid", the called access number "$did", and the process number "$flowNum". Component output dynamic variables are written into the system variable layer according to pre-defined fields after each component is executed. Examples include the case result of the menu component, the recording file identifier of the recording component, and the query results of the database access component.

[0069] This invention provides a hierarchical model of variables based on the scope of data sharing and lifecycle requirements. On the one hand, it provides a complete expressive capability for call scenarios, from "single call transient data" to "cross-process persistent data" and then to "runtime session data". On the other hand, it avoids mis-referencing of variables by forcibly isolating them through namespace prefixes, fundamentally overcoming the naming conflicts and lifecycle chaos caused by the traditional IVR (Interactive Voice Response) flat variable pool.

[0070] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, the method involves tracking the reference relationships of variables at each level using an expression evaluator, sequentially resolving the system variable layer, local variable layer, and global variable layer, and returning the currently valid variable value. Specifically, this includes the following steps: Step b1: Parse the variable values ​​of each namespace and extract all variable references identified by a preset prefix.

[0071] Specifically, after receiving the expression string to be evaluated, the expression evaluator first performs a lexical scan to identify consecutive identifier segments starting with the preset prefix "$" as variable references, and determines their level based on this prefix. Variables starting with the prefix "$Custom." are classified into the local variable level, variables starting with the prefix "$GlobalCustum." are classified into the global variable level, and variables without a second-level prefix are classified into the system variable level.

[0072] Step b2 executes the query according to the priority order of system variable layer, local variable layer, and global variable layer. During the query process, if a variable is found, the query returns and terminates; if no variable is found, the query continues to the next level. If no variable is found at any level, a null value is returned and an undefined variable alarm message is recorded.

[0073] Within the system variable layer, dynamic variables output by the component are queried first. If a match is found, the variable is returned directly and the query is terminated. If no match is found, the query continues to query session fixed variables.

[0074] Step b3: Substitute the parsed variables into the conditional expression, perform logical operations, and return the results to the component that initiated the evaluation. During the evaluation process, record the referenced component instance identifier, process identifier, configuration field path, and variable name of each referenced variable as a reference record and write it into the variable registry.

[0075] The expression evaluator is the core of arithmetic and logical operations built into the process execution engine. It is used to parse and evaluate conditional expressions that contain variable references and function calls. It supports three types of expressions: branch judgment expressions of the condition judgment component, variable assignment expressions of the variable operation component, and SQL parameter concatenation expressions of the database access component.

[0076] Conditional judgment components are flow control components that select different branch paths to execute based on input variable values; variable manipulation components are flow control operations that perform assignment, arithmetic operations, or type conversion operations on specified variables; database access components are integrated components that perform structured query language operations to read and write external databases, and are used to dynamically generate query statements containing variable values ​​at runtime.

[0077] Step b4: When a variable is deleted or the process to which the variable belongs is disabled, a failure notification is sent to all referencing processes based on the reference records stored in the variable registry. When the referencing process is subsequently enabled or re-entered for editing, the failure notifications are summarized into a structured list and displayed, with each entry listing the name of the failed reference component, the path to the configuration field, and the name of the failed variable.

[0078] This invention, through hierarchical masking queries, ensures the determinism and proximity priority of variable values. By synchronously recording references during the evaluation process, it achieves bidirectional traceability between variables and referrers. When a shared variable is deleted or its source process is disabled, the system can accurately locate all affected referrers and provide a summary notification during their next edit. This moves the issue of "variable invalidation," which would normally only be exposed during runtime, to an explicit presentation during the editing phase, avoiding runtime evaluation anomalies or branch misjudgments caused by dangling variable references.

[0079] exist Figure 1 Based on the illustrated embodiment, as one implementation of this invention, after executing the call termination component, the call post-processing chain is triggered to continue scheduling subsequent valid components, specifically including the following steps: Step c1: After completing the hang-up or transfer action, the process execution engine first checks along the directed graph whether there is a successor component after the call end component.

[0080] If no successor component exists, the process is considered terminated, and the execution context of this call is released.

[0081] If a successor component exists, the mutual exclusion constraint engine is invoked to determine whether the component type of the successor component belongs to the post-processing component in the preset termination class whitelist, so as to ensure that subsequent scheduling does not violate the transitivity constraint of call termination semantics.

[0082] Step c2: If the subsequent component is not in the termination whitelist, then terminate the scheduling and release the execution context of this call. Although the process passes the release validation during the editing phase, the subsequent component may become invalid at runtime due to reasons such as updates to the mutual exclusion rule table. Terminating the scheduling at this time can avoid runtime exceptions caused by executing components that depend on the call link in the context of a terminated call.

[0083] If a subsequent component belongs to the whitelist of termination categories, the subsequent components will continue to be scheduled according to the connection order of the directed edges, and operations such as database writing, HTTP callback, message sending and log recording will be performed one by one to form a call post-processing chain.

[0084] Step c3 involves resolving the current values ​​of session fixed variables and component output dynamic variables referenced by the component in the current execution context using the expression evaluator, and then using these values ​​as input parameters for subsequent components.

[0085] The components within the post-call processing chain share the same execution context as all preceding components during the call, allowing direct access to all variable values ​​accumulated during the call. This execution context is a variable container that spans the entire call lifecycle, storing variable data accumulated by all components since the call was initiated. This includes session-fixed variables automatically injected by the system when the call is connected, as well as dynamic variables written by each call component according to agreed-upon fields after execution.

[0086] For example, when a user enters their employee ID to query the database for authentication, the user input value obtained after the UserInput component is executed is written to the execution context, with the variable name "$UserInput1.userInput"; the scalar value of the query result obtained after the DatabaseAccess component is executed is written to the execution context, with the variable name "$DatabaseAccess1.scalarResult" and the value "1".

[0087] When the process execution hangs up and continues to dispatch the logging component (Logger), the Logger records the call's user ID "$UserInput1.userInput", authentication result "$DatabaseAccess1.scalarResult", and call ID "$callid", and concatenates them into a call record. Next, the expression evaluator extracts the three variable references from the call record sequentially and queries their values ​​in the corresponding context. Finally, the external interface request component (HTTP Request) sends the call record back to the enterprise CRM (Customer Relationship Management) system.

[0088] Step c4: After the call post-processing chain is completed or terminated abnormally, release the execution context of this call.

[0089] This invention enables post-processing operations such as data persistence, external callbacks, and notifications to continue even after a call is hung up or transferred. Because the post-processing chain shares the same execution context as the call process, the post-processing component can directly reuse variable values ​​accumulated during the call, meeting the needs of enterprise-level system integration without requiring the development of separate external scripts for actions after the call ends. Furthermore, the runtime and editing phases share the same end-of-phase whitelist, ensuring consistency between build-phase verification and runtime scheduling.

[0090] Secondly, embodiments of the present invention also provide a visual call flow orchestration system 40, such as... Figure 4 As shown, it includes: The concurrent editing mutual exclusion guard module 410 is used to receive requests to enter the call flow editing area, query the editing lock status, and when the editing lock is in an idle state or the current editing user is the initiator of the request, allow the request to enter the call flow editing area and start the heartbeat reporting mechanism.

[0091] The visualization canvas module 420 is used to generate a directed call flow graph consisting of a set of component instances and their connection relationships in response to dragging, connecting, and configuring operations of components in the call flow editing area.

[0092] The mutual exclusion constraint engine module 430 is used to perform legality checks on ordinary components and call-end class components.

[0093] The variable management module 440 is used to divide all variables in the call flow directed graph into local variable layer, global variable layer and system variable layer, and track the reference relationship of variables at each level.

[0094] The save and verification management module 450 is used to identify the operation type of the save command for the directed graph of the call flow. If the operation type is draft, the current canvas data is directly saved to the draft storage. If the operation type is publish, a three-layer verification consisting of component configuration legality verification, component mutual exclusion relationship verification, and logical loop detection is triggered in sequence. If any layer of verification fails, the error information is summarized and publication is prevented. When all three layers of verification pass, the directed graph of the call flow is published and written to the published storage.

[0095] The expression evaluator module 460 is used to sequentially parse the system variable layer, local variable layer, and global variable layer and return the currently valid variable values ​​to support the branch selection of the condition component and the operation of the variable assignment component.

[0096] The variable failure notification module 470 is used to send failure notifications to all referencing processes when a variable is deleted or the process to which the variable belongs is disabled, and to summarize and display failure information when re-entering the call process editing area.

[0097] The post-call processing chain module 480 is used to trigger the post-call processing chain after the execution of the call end component, and to continue scheduling subsequent valid components.

[0098] Thirdly, embodiments of the present invention also provide an electronic device, comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described in the above embodiments.

[0099] Fourthly, embodiments of the present invention also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform any of the methods described in the above embodiments.

[0100] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for visualizing call flow orchestration, characterized in that, include: Received a request to enter the call flow editing area; Invoke the concurrent edit mutex guard to query the edit lock status of the call flow editing area; When the edit lock is idle or the current editing user is the initiator of the request, the request is allowed to enter the call flow editing area, and the heartbeat reporting mechanism is activated; In response to dragging, connecting and configuring operations of components in the call flow editing area, the mutual exclusion constraint engine is invoked in real time to perform legality checks on ordinary components that do not have call termination semantics and call termination type components that carry call termination semantics. Based on the set of component instances that have passed the legality verification and their connection relationships, a directed graph of the call flow is generated; all variables in the directed graph of the call flow are divided into a local variable layer, a global variable layer, and a system variable layer. Identify the operation type of the instruction to save the directed graph of the call flow and perform the following judgments: If the operation type is draft state, the current canvas data is directly stored in the draft storage; if the operation type is publish state, three layers of verification are performed in sequence, consisting of component configuration validity verification, component mutual exclusion relationship verification, and logical loop detection; if any layer of verification fails, the error information is summarized and publication is prevented; if all three layers of verification pass, the directed graph of the call flow is published and written to the published storage. The expression evaluator tracks the reference relationships of variables at each level, resolves the system variable level, local variable level and global variable level in sequence and returns the currently valid variable value; When the variable is deleted or the process to which the variable belongs is disabled, a failure notification is sent to all referencing components, and the failure information is summarized and displayed when the call process editing area is re-entered. After executing the call end class component, the call post-processing chain is triggered to continue verifying and executing subsequent components in the call post-processing chain.

2. The method according to claim 1, characterized in that, The invocation of the mutual exclusion constraint engine performs validity checks on ordinary components that do not have call termination semantics and call termination class components that carry call termination semantics, including: Before establishing the connection relationship from the first component to the second component, identify and determine whether the first component is a call termination component or an indirect successor node of the call termination component; the call termination component is a special component type that carries a call termination semantic mark, including hang-up components and transfer components; If the first component is neither a call-end component nor an indirect successor of a call-end component, then the first component is classified as a normal component, and a preset mutual exclusion rule table is queried to check whether a directed connection is allowed between the first component and the second component. If the check passes, a directed edge is connected and the second component is marked as a normal component. If the check fails, a prompt message containing the reason for the mutual exclusion is returned. The mutual exclusion rule table defines whether a direct directed connection is allowed between any two components. If the first component is a call termination component or its indirect successor node, then it is determined whether the second component is included in the termination whitelist; if the second component is not in the termination whitelist, the connection is blocked and a prompt indicating that the call has ended or been transferred is returned; if the second component is in the termination whitelist, a directed edge is connected and the second component is identified as a call termination component; wherein, the termination whitelist pre-registers post-processing components that are allowed to continue execution after the call termination component; The end-class constraint marker is passed to all successor nodes of the second component along the directed graph, and it is determined whether each passed successor node exists in the end-class whitelist. If it exists, the end-class constraint marker is passed down along the directed edge; otherwise, the connection is rejected.

3. The method according to claim 1, characterized in that, The three-layer verification process, consisting of component configuration validity verification, component mutual exclusion relationship verification, and logical loop detection, is performed sequentially. Perform component configuration validity verification: The component configuration validator traverses each component instance in the directed graph of the call flow one by one, and performs mandatory field verification, field type matching verification, and associated data existence verification on the configuration items of each component; the associated data existence verification is to verify whether the variables, voice resources, database connections, and external interface addresses referenced by the component instance are valid; the verification passes only if all component instances satisfy the validity verification. Execution component mutual exclusion relationship verification: Reuse the mutual exclusion constraint engine to perform overall legality inference on all directed edges of the directed graph of the call flow. The verification passes if and only if all directed edges are legal. Perform logical loop closure detection: Construct a main logic tree with the starting component of the directed graph of the call flow as the root node, and traverse all leaf nodes in the main logic tree to determine whether each leaf node converges to the call end class component or the end branch; the verification passes if and only if all leaf nodes meet the convergence condition; wherein, the end branch refers to the branch endpoint that is identified as closed in the logical loop closure detection and does not need to be connected to the call end class component.

4. The method according to claim 3, characterized in that, The determination of whether each leaf node converges to the call end component or the end branch includes: During the traversal of the main logic tree, the following judgment is performed on each leaf node visited: Determine whether the leaf node is a loop component; the loop component is a flow control component that repeatedly schedules a specified component sequence, and includes three topological elements: loop entry, loop body subgraph, and loop exit. If the leaf node is a loop component, skip the path repeatedly executed inside the loop body, only obtain the exit directed edge of the loop component, include the subsequent path of the exit directed edge in the monitoring, and determine whether each end node of the subsequent path converges to the call end component or the end branch; if any end node does not converge, mark the corresponding component as an unclosed loop component. If the leaf node is not a cyclic component, then determine whether the leaf node is a call end component or an end branch; if so, determine that the current branch is closed and continue traversing the next leaf node; if not, mark the current node as an unclosed component and record the component identifier and the branch path information. After the traversal is complete, all marked non-closed-loop components are summarized, a pop-up prompt containing the identifier of each component and the branch path it belongs to is generated, and the save or enable operation is prevented.

5. The method according to claim 1, characterized in that, The step of dividing all variables in the directed graph of the call flow into a local variable layer, a global variable layer, and a system variable layer includes: Establish a two-level namespace in the variable registry, namely the global variable layer and the local variable layer, and configure the system variable layer in advance; The global variable layer is used to persistently record the definition information and reference records of each global variable. The global variables are restored according to their initial values ​​when the system restarts, and support read-write mode and read-only mode. The local variable layer is used to persistently record the definition information and reference records of each local variable. The local variables are restored according to their initial values ​​each time a call process is entered, and released when the call ends. The definition information includes variable name, variable type, initial value, and access mode. The system variable layer is dynamically maintained by the process execution engine at runtime, including session fixed variables and component output dynamic variables; the session fixed variables are automatically injected when a call is received; the component output dynamic variables are written into the system variable layer according to pre-agreed fields after each component is executed.

6. The method according to claim 1, characterized in that, The expression evaluator tracks the reference relationships of variables at each level, sequentially resolving the system variable level, local variable level, and global variable level, and returning the currently valid variable value, including: Parse the variable values ​​of each namespace and extract all variable references marked with a preset prefix; execute queries according to the priority order of system variable layer, local variable layer, and global variable layer; during the query process, if a variable is found, return and terminate the query; if no variable is found, continue to the next level; if no variable is found at any level, return an empty value and record an undefined variable alarm message. Within the system variable layer, dynamic variables output by the query component are queried first. If a match is found, the variable is returned directly and the query is terminated. If no match is found, the query continues to query session fixed variables. Substitute the parsed variables into the conditional expression, perform logical operations, and return the result to the calling component. When a variable is deleted or the process to which the variable belongs is disabled, an invalidation notification is sent to all referencing processes based on the reference records stored in the variable registry. When the referencing process is subsequently enabled or re-entered for editing, the invalidation notifications are summarized into a structured list and displayed.

7. The method according to claim 1, characterized in that, After executing the call end component, the call post-processing chain is triggered to continue verifying and executing subsequent components in the call post-processing chain, including: When execution reaches the call termination component, check if there is a successor component after the call termination component; if there is no successor component, release the execution context of this call; if there is a successor component, call the mutex constraint engine to determine whether the component type of the successor component belongs to the post-processing component in the preset termination whitelist. If the call does not belong to the whitelist of termination categories, the scheduling is terminated and the execution context of this call is released; if the call does belong to the whitelist of termination categories, the subsequent components are scheduled according to the connection order of the directed edges to form a call post-processing chain; the current values ​​of the session fixed variables and component output dynamic variables referenced by the components in the current execution context are parsed by the expression evaluator and used as input parameters for the subsequent components. Once the post-call processing chain is completed or terminated abnormally, the execution context of this call is released.

8. A visual call flow orchestration system, characterized in that, The system includes: The concurrent editing mutual exclusion guard module is used to receive requests to enter the call flow editing area, query the editing lock status, and when the editing lock is in an idle state or the current editing user is the initiator of the request, allow the request to enter the call flow editing area and start the heartbeat reporting mechanism; The visualization canvas module is used to generate a directed graph of the call flow consisting of a set of component instances and their connection relationships in response to dragging, connecting, and configuring operations of components in the call flow editing area. The mutual exclusion constraint engine module is used to perform legality checks on ordinary components and call-end components; The variable management module is used to divide all variables in the directed graph of the call flow into local variable layer, global variable layer and system variable layer, and track the reference relationship of variables at each level; The save and verification management module is used to identify the operation type of the save command for the directed graph of the call flow. If the operation type is draft, the current canvas data is directly saved to the draft storage. If the operation type is publish, a three-layer verification consisting of component configuration legality verification, component mutual exclusion relationship verification, and logical loop detection is triggered in sequence. If any layer of verification fails, the error information is summarized and publication is blocked. When all three layers of verification pass, the directed graph of the call flow is published and written to the published storage. The expression evaluator module is used to sequentially parse the system variable layer, local variable layer, and global variable layer and return the currently valid variable values ​​to support the branch selection of the condition component and the operation of the variable assignment component; The variable failure notification module is used to send a failure notification to all referencing processes when a variable is deleted or the process to which the variable belongs is disabled, and to summarize and display the failure information when re-entering the call process editing area. The post-call processing chain module is used to trigger the post-call processing chain after the execution of the call end component, and to continue to verify and execute the subsequent components in the post-call processing chain.

9. An electronic device, characterized in that, include: At least one processor; Memory for storing the at least one processor-executable instruction; The at least one processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 7.

Images