A method and system for concurrent editing and merging of multiple administrators of a communication call routing

Abstract

This invention provides a method and system for concurrent editing and merging of communication call routes by multiple administrators, comprising: acquiring interactive operations of a first administrator frontend at the canvas layer and encapsulating them into atomic operation objects; logically marking the atomic operation objects based on vector clocks; persistently storing and transmitting the operation logs of the marked atomic operation objects to a second administrator frontend; comparing the local vector clock with the vector clock of the marked atomic operation objects before executing the interactive operation, and obtaining the comparison result; if the comparison result indicates that a preceding operation object has not yet arrived, writing the currently received operation object into a waiting buffer until the preceding operation object is completed, and performing a replay operation according to the causal order in the marked atomic operation objects; and performing concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local unoperated object of the second administrator frontend. This method reduces the probability of concurrent operations overlapping each other and avoids configuration loss and routing loops impacting the underlying engine.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method and system for concurrent editing and merging of communication call routes by multiple administrators within the field of data processing technology. Background Technology

[0002] In large enterprise communication systems, private branch exchanges (PBXs), call centers, and multi-tenant unified communication platforms, call routing rules, interactive voice response (IVR) processes, and transfer policies are typically configured in the form of a visual directed graph. This configuration includes both node attributes and strict topological relationships. In actual operation, the configuration result must maintain the characteristics of a directed acyclic graph (DAG); otherwise, it can easily lead to call deadlocks, floating routes, or underlying engine malfunctions. In scenarios with multiple administrators concurrently maintaining the system, pessimistic locking mechanisms can easily cause emergency maintenance blockages, full-packet overwrite saving can lead to configuration loss, general text merging cannot understand the semantics of graph topology, and illegal topologies may directly impact the underlying communication engine. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for concurrent editing and merging of communication call routes by multiple administrators. The specific technical solution adopted is as follows: In a first aspect, embodiments of the present invention provide a method for concurrent editing and merging of communication call routes by multiple administrators, the method comprising: Obtain the interactive operations of the first administrator's front end on the canvas layer; The interactive operations are encapsulated into atomic operation objects; Logically mark atomic operation objects based on vector clocks to obtain marked atomic operation objects; The operation logs of the marked atomic operation objects are persistently stored and transmitted to the second administrator's front end; Before performing interactive operations on the second administrator front end, the local vector clock of the second administrator front end is compared with the vector clock of the marked atomic operation object to obtain the comparison result; If the comparison result indicates that a preceding operation object has not yet arrived, the currently received operation object is written into the waiting buffer until the preceding operation objects are completed, and the replay operation is performed according to the causal order in the marked atomic operation objects; wherein, the preceding operation object is the object on which the execution of the marked atomic operation object depends; The operation object to which the replay operation belongs is subjected to concurrent conflict detection and merging with the local non-operated object in the second administrator front end to obtain the merged object.

[0004] Secondly, a communication call routing system for concurrent editing and merging by multiple administrators is provided, the system comprising: The acquisition module is used to acquire the interactive operations of the first administrator's front end on the canvas layer; An encapsulation module is used to encapsulate the interactive operations into atomic operation objects; The marking module is used to logically mark atomic operation objects based on a vector clock to obtain marked atomic operation objects. The storage module is used to persistently store the operation logs of the marked atomic operation objects and transmit them to the second administrator front end; The comparison module is used to compare the local vector clock of the second administrator front-end with the vector clock of the marked atomic operation object before the second administrator front-end performs the interactive operation, and obtain the comparison result; The replay module is used to write the currently received operation object into a waiting buffer if the comparison result indicates that a preceding operation object has not yet arrived, until the preceding operation object is completed, and then perform the replay operation according to the causal order in the marked atomic operation objects; wherein, the preceding operation object is the object on which the execution of the marked atomic operation object depends; The merging module is used to perform concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object of the second administrator front end to obtain the merged object.

[0005] Thirdly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0006] Fourthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0007] This invention has the following beneficial effects: After obtaining the interactive operations of the first administrator frontend at the canvas layer, the interactive operations are atomically encapsulated to obtain atomic operation objects; thus, the system uses atomic operation logs instead of writing back the entire configuration package, which can reduce the probability of configuration loss. Then, the atomic operation objects are logically marked based on vector clocks to obtain marked atomic operation objects, thus marking the causal order of each object in the execution order. The operation logs of the marked atomic operation objects are persistently stored and transmitted to the second administrator frontend; before the second administrator frontend executes the interactive operation, the local vector clock of the second administrator frontend is compared with the vector clock of the marked atomic operation objects to obtain a comparison result; if the comparison result indicates that a preceding operation object has not yet arrived, the currently received operation object is written to the waiting buffer until the preceding operation object is completed, and the replay operation is executed according to the causal order in the marked atomic operation objects; wherein, the preceding operation object is the object that the marked atomic operation object depends on; simultaneously, the operation object to which the replay operation belongs and the local unoperated object of the second administrator frontend are subjected to concurrent conflict detection and merging to obtain merged objects. In this way, the system replaces the full package configuration write-back with atomic operation logs and combines vector clocks to determine causal relationships, so that legitimate modifications can be retained in the final state, reducing the probability of concurrent operations overwriting each other. This allows multiple administrators to edit the same routing canvas at the same time, and ensures that valid nodes, valid edges and distributed configurations always maintain topological validity during final convergence, thereby avoiding configuration loss and routing loops from impacting the underlying engine. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram illustrating the implementation process of a method for concurrent editing and merging of communication call routes by multiple administrators, provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of another implementation process of a method for concurrent editing and merging of communication call routing by multiple administrators provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the implementation framework of a method for concurrent editing and merging of communication call routing by multiple administrators, provided in an embodiment of the present invention. Figure 4This is a schematic diagram of the interactive process of a method for concurrent editing and merging of communication call routes by multiple administrators, provided in an embodiment of the present invention. Figure 5 This is a schematic diagram of the composition structure of a communication call routing multi-administrator concurrent editing and merging system provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of a computer block device provided in an embodiment of the present invention. Detailed Implementation

[0010] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a method for concurrent editing and merging of communication call routing by multiple administrators according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments may be combined by any suitable form.

[0011] In the description of the embodiments of the present invention, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present invention, "multiple" means two or more.

[0012] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0014] In related technologies, existing configuration platforms often apply exclusive locks to individual routing objects, preventing administrator B from entering the same process while administrator A is editing. When multiple people need to collaborate on scenarios such as backbone failures, number migrations, or emergency switching, serial queuing significantly prolongs fault recovery time. If the system is not locked or the lock is invalid, multiple administrators can modify different branches of the same routing graph and submit their changes. The later submitted version usually overwrites the previous version with a complete JSON package, causing previous legitimate changes to be completely erased, leading to risks such as missed calls and incorrect traffic routing. Common version merging or field overwriting strategies cannot identify node dependencies, edge relationships, and loop semantics. In concurrent scenarios, if one party deletes a node and another party adds an edge pointing to that node, dangling nodes are easily created; if one party reconnects to an upstream node, a routing dead loop may be formed. FreeSWITCH, Asterisk, or equivalent PBX engines typically rely on legitimate call routing configurations for parsing and execution. Once an illegal topology is directly deployed without prior blocking, infinite bounces, resource exhaustion, routing black holes, or parsing anomalies may occur, affecting the availability of the entire platform.

[0015] Based on this, embodiments of the present invention provide a method for concurrent editing and merging of communication call routes by multiple administrators. By using atomic operation logs, vector clock causal determination, dedicated graph CRDT data model, and topology merging rules with DAG constraints, multiple administrators can edit the same routing canvas simultaneously. During final convergence, the method ensures that valid nodes, valid edges, and distributed configurations always maintain topological validity, thereby avoiding configuration loss and routing loops from impacting the underlying engine.

[0016] The specific scheme of the multi-administrator concurrent editing and merging method for communication call routing provided by the present invention is described below with reference to the accompanying drawings. The implementation process of the multi-administrator concurrent editing and merging method for communication call routing is as follows: Figure 1 As shown, the method includes: 101, retrieve the first administrator's front-end interaction operations on the canvas layer.

[0017] Here, interactive operations include: intercepting node addition, node deletion, adding and deleting nodes simultaneously, and modifying attributes in the front-end routing canvas layer.

[0018] 102. The interactive operation is encapsulated into an atomic operation object.

[0019] Here, each interaction operation is encapsulated into an indivisible atomic operation object.

[0020] 103. Logically mark the atomic operation objects based on the vector clock to obtain the marked atomic operation objects.

[0021] Here, after atomically encapsulating the interactive operation, an operation identifier, author identifier, logical time, and vector clock are attached to the atomic operation object to obtain a marked atomic operation object.

[0022] In some possible implementations, after obtaining the marked atomic operation object, the amount of stored data in the operation log of the marked atomic operation object is determined; if the amount of stored data is greater than a preset data amount threshold, the stored operation log of the marked atomic operation object is snapshot compressed to obtain a compressed log; and the stored operation log of the marked atomic operation object is updated based on the compressed log.

[0023] Here, the server stores operation logs and snapshots separately. When the cumulative number of operations on a single route object reaches a preset data threshold, for example, a preset data threshold of 1000 records, the system collapses the current graph CRDT state into a complete snapshot and persists it, while simultaneously cleaning up the collapsed logs. Thus, after the operation logs reach the threshold, the current state is collapsed into a snapshot and synchronized with incremental logs, which controls the storage pressure of long-term collaborative editing and improves the state recovery speed for newly added administrators.

[0024] In some possible implementations, when a newly added third-party administrator frontend is detected, the latest snapshot is obtained from the compressed log; the interaction operations of the third-party administrator frontend on the canvas layer are atomically encapsulated to obtain incremental operation logs; and the current state of the canvas layer is updated based on the latest snapshot and the incremental operation logs of the third-party administrator frontend.

[0025] Here, the latest state is read, a compressed binary or JSON snapshot is generated, and written to the configuration snapshot storage. Old logs are cleaned up, allowing newly joined administrators to directly load the snapshot plus a small amount of incremental logs, achieving second-level startup. In this way, newly joined administrators can quickly restore the canvas state by "pulling the latest snapshot + incremental operation logs".

[0026] In some possible implementations, firstly, the operation identifier, author identifier, and logical time of the atomic operation object are obtained; then, based on the causal order and logical time of the atomic operation object, the vector clock of the atomic operation object is determined; finally, the atomic operation object is marked using the vector clock, operation identifier, and author identifier to obtain the marked atomic operation object. In this way, by attaching operation identifiers, author identifiers, logical time, and vector clocks to each operation object, the marked atomic operation object carries the causal order of the relationships between each object during execution.

[0027] 104. Persistently store the operation logs of the marked atomic operation objects and transmit them to the second administrator front end.

[0028] Here, after obtaining the marked atomic operation object, the local CRDT state is updated (e.g., joining a point addition set Vadd or an edge addition set Eadd). The canvas is immediately updated and optimistic rendering is performed: based on the updated local state, the new graphic is immediately drawn on the screen without waiting for server confirmation, providing a zero-latency experience.

[0029] In some possible implementations, the first administrator frontend sends a tagged atomic operation object to the WebSocket server, which then forwards the tagged atomic operation object to the backend central hub via WebSocket. The WebSocket server receives the data packet from administrator A. Based on the server central hub, the WebSocket server then forwards the tagged atomic operation object to the second administrator frontend.

[0030] 105. Before performing interactive operations on the second administrator front end, the local vector clock of the second administrator front end is compared with the vector clock of the marked atomic operation object to obtain the comparison result.

[0031] Here, after the second administrator frontend receives the tagged atomic operation object, it compares the vector clock of the received operation with the locally known clock to obtain a comparison result. This comparison result is used to characterize the sequential relationship between the clock of the received operation object and the locally suppressed clock.

[0032] 106. If the comparison result indicates that a preceding operation object has not yet arrived, write the currently received operation object into the waiting buffer until the preceding operation object is completed, and then perform the replay operation according to the causal order in the marked atomic operation objects.

[0033] The preceding operation object is the object on which the marked atomic operation object depends.

[0034] If the comparison results indicate that all preceding operations have been completed, then a conflict detection is performed directly on the local unoperated objects and the marked atomic operation objects. If there is no conflict, they are merged; if there is a conflict, the local unoperated objects and the marked atomic operation objects are merged according to the preset merging rules.

[0035] In a specific example, suppose there are five steps in the interactive operation to be performed. By comparing the local vector clock of the second administrator's front end with the vector clock of the marked atomic operation object, if the comparison result indicates that the local vector clock of the second administrator's front end corresponds to the third step, while the vector clock of the marked atomic operation object corresponds to the fifth step, that is, the second administrator's front end finds "I haven't received operation #4 yet, how come I received operation #5?", then it is determined that there is a preceding operation object that has not yet arrived, and the second administrator's front end puts operation #5 into the waiting buffer.

[0036] 107. Perform concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object in the second administrator's front end to obtain the merged object.

[0037] Here, while performing the replay operation, concurrent conflict detection and merging are performed on the operation object and the local non-operation object in the second administrator's front end to obtain the merged object.

[0038] In some possible implementations, it can be achieved through Figure 2 The steps shown are to be implemented as follows: 201. Determine whether there is a concurrent conflict between the local unoperated object of the second administrator front end and the marked atomic operation object received by the second administrator front end.

[0039] Here, it is determined whether there is a conflict between the local unoperated objects and the marked atomic operation objects of the second administrator frontend in the canvas layer. For example, if the first and second administrator frontends perform the same operation in the canvas layer. If there is no conflict, the local unoperated objects and marked atomic operation objects of the second administrator frontend are directly merged.

[0040] In some possible implementations, the system compares two operations. and The vector clock is used to identify causal or concurrent relationships, and its determination rule can be expressed as:

[0041] The system only triggers the merging rules for conflict scenarios when two operations satisfy a concurrency relationship, such as deletion priority, attribute field LWW merging, or loop breaking rules; if the two have a clear causal order, they are applied directly in sequence.

[0042] For fields that do not change the topology, such as node name, TTS broadcast text, timeout duration, and tag description, this embodiment of the invention uses Last-Write-Wins register merging. Each attribute field is bound to a mixed logical clock or an equivalent monotonically increasing version flag. If two replicas concurrently write to the same field, the system retains the value with the larger logical time, thereby achieving field-level eventual consistency without compromising graph topology security.

[0043] 202. If there is a concurrent conflict between the local unoperated object and the marked atomic operation object, obtain the preset merging rule of the second administrator front end.

[0044] Here, the preset merging rules can be custom rules, including: concurrent rules for node deletion and attribute modification, concurrent rules for node attribute modification, and concurrent addition and deletion of edges. Specifically, the concurrent rules for node deletion and attribute modification are: if administrator A is modifying a node attribute and administrator B is deleting a node, the final result is that the node does not exist; the concurrent rules for node attribute modification are: the LWW register retains the more recent value. If administrator A and administrator B simultaneously modify the name of the same node, the one with the later clock / timestamp is executed; concurrent addition and deletion of edges are: the set of edges added and the set of edges deleted are merged. This is achieved through set operations (E=Eadd). The `Eremove` function is used to determine whether an edge exists, where `Eadd` means adding an edge to the set and `Eremove` means removing an edge from the set.

[0045] 203. Based on the preset merging rules, merge the local unoperated objects of the second administrator front-end and the marked atomic operation objects received by the second administrator front-end to obtain merged objects.

[0046] Here, if conflicts exist, a preset merging rule is first obtained. Then, according to this rule, local unoperated objects and marked atomic operation objects are merged to obtain merged objects. In this way, through atomic operation logs and replica merging mechanisms, the concurrent editing capabilities of multiple administrators are implemented in the scenario of strong topological constraints such as communication routing. After merging, a DAG validity check and automatic loop edge cutting mechanism are added to ensure that the consistency result simultaneously satisfies the executable constraints of communication routing.

[0047] In some possible implementations, firstly, the first operation type of the local unoperated object and the second operation type of the marked atomic operation object are determined; then, based on the first operation type and the second operation type, a matching target merging rule is selected from the preset merging rules; then, based on the target merging rule, the local unoperated object of the second administrator front-end and the marked atomic operation object received by the second administrator front-end are merged to obtain the merged object.

[0048] Here, the first operation type and the second operation type can be the same or different, including: modifying node class, deleting node class, and adding node class, etc.

[0049] In some possible implementations, if administrator A deletes node N1, and administrator B concurrently adds an edge (N2, N1) pointing to N1, even if the edge addition operation arrives later at the propagation level than the node deletion, the system will still determine the edge to be invalid when resolving the valid edge set because the target node N1 does not belong to V. Therefore, edge additions can be automatically masked by the valid topology view without explicit rollback, preventing dangling routes from entering the published links.

[0050] In some possible implementations, if the second operation type is a node modification type and the first operation type is a node deletion type, the target merging rule is to select the node deletion method in the preset merging rules; for example, if administrator A modifies a node attribute and administrator B deletes the node, then the target merging rule is to delete the node. If both the second and first operation types are node modification types, the target merging rule is to select the node modification method with the later timestamp in the preset merging rules, based on the timestamps corresponding to the second and first operation types; for example, if administrators A and B both modify the name of the same node, then the modification instruction with the later clock / timestamp is executed. If the second operation type is an edge addition type and the first operation type is an edge deletion type, the target merging rule is to select concurrent addition and deletion of edges in the preset merging rules. For example, through set operations (E=Eadd...). The `Eremove` function determines whether an edge exists. If it exists, the interaction is ignored; otherwise, the interaction is executed directly.

[0051] In some embodiments, after performing concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object in the second administrator frontend to obtain the merged object, the routing topology map construction and loop detection can be performed through the following process: First, extract the current set of valid nodes and the current set of valid edges from the merged objects.

[0052] Here, the node addition set Vadd, node deletion set Vremove, edge addition set Eadd, and edge deletion set Eremove are maintained in memory or an equivalent state machine. These four sets are preferably maintained using an append-only recording method to ensure consistent results when any replica receives the same set of operations. The current valid node set and valid edge set satisfy: V = Vadd \\ Vremove. Therefore, whether an edge is effective depends not only on whether the edge itself has been deleted, but also on whether the nodes at both ends of the edge are still in the set of valid nodes.

[0053] Secondly, a routing topology graph is constructed based on the current set of valid nodes and the current set of valid edges.

[0054] Here, an effective routing graph G(V,E) is constructed based on the current set of valid nodes and the current set of valid edges.

[0055] Next, depth-first loop detection is performed on the routing topology to determine whether a closed loop path exists.

[0056] Here, topology sorting, depth-first loop detection, or equivalent directed acyclic graph (DAG) validity checks are performed on the routing topology graph to determine whether a closed loop path exists.

[0057] Furthermore, if a closed-loop path is detected, the target edge leading to the closed-loop path is identified in the routing topology graph.

[0058] Here, if a closed loop path is detected, the set of candidate edges that form the loop is traced, and the last edge that caused the loop is selected based on timestamp, priority, or preset conflict weight, thus obtaining the target edge.

[0059] In some possible implementations, a set of candidate edges forming the closed-loop path is determined; and from this set, the candidate edge with the largest timestamp or the smallest preset conflict weight is selected as the target edge. The preset conflict weight is a numerical indicator used to measure the "responsibility" or "backoff cost" of an edge (routing connection) in causing the loop. The preset conflict weight can be customized according to the priority of each candidate edge; alternatively, it can be set by statistically analyzing the number of times the edge is involved in "concurrent modification conflicts" over a period of time—the more times it is involved in "concurrent modification conflicts," the smaller the preset conflict weight.

[0060] In the candidate edge set, to address routing loops caused by concurrent editing, the system will not roll back all operations in the current round after detecting a loop. Instead, it will only select the target edge that caused the loop and perform deletion set writing. Let the candidate edge set be... Then, the edge with the largest timestamp or the lowest preset conflict weight is selected first. As a back edge, and execute: In this way, the system can quickly restore the legality of the DAG while preserving other legitimate concurrent modifications to the greatest extent possible, thus realizing an automatic repair mechanism based on the backtracking of cyclic edges.

[0061] Finally, the target edge is forcibly written into the edge deletion set to cut off the closed loop path, and alarm information is generated and output.

[0062] Here, if an infinite loop like A->B->C->A is found in the closed-loop path, the server forcibly marks the last edge as deleted (writes it to the Eraseve set) and pushes an alarm message to the front end. Thus, after the basic CRDT merging is completed, a valid routing graph G(V,E) is constructed based on the current V and E (i.e., the current set of valid nodes and the current set of valid edges). Topology sorting, depth-first loop detection, or equivalent DAG validity verification is performed on this graph. If a loop is detected, the candidate edge set forming the loop is traced, and the last edge causing the loop is selected based on timestamp, priority, or preset conflict weight. This edge is then forcibly written to the Eraseve set (i.e., the edge deletion set) to break the loop. Simultaneously, the system pushes an alarm message to the front end, notifying the administrator that this concurrent change has triggered automatic protection.

[0063] In this embodiment of the invention, the system replaces the full package configuration write-back with atomic operation logs, which can reduce the probability of configuration loss. Then, atomic operation objects are logically marked based on vector clocks to obtain marked atomic operation objects. Thus, the marked atomic operation objects indicate the causal order of each object in the execution order. The operation logs of the marked atomic operation objects are persistently stored and transmitted to the second administrator frontend. Before the second administrator frontend performs interactive operations, the local vector clock of the second administrator frontend is compared with the vector clock of the marked atomic operation objects to obtain a comparison result. If the comparison result indicates that a preceding operation object has not yet arrived, the currently received operation object is written to a waiting buffer until the preceding operation object is completed. Then, a replay operation is performed according to the causal order in the marked atomic operation objects. The preceding operation object is the object that the marked atomic operation object depends on. Simultaneously, concurrency conflict detection and merging are performed on the operation object to which the replay operation belongs and the local unoperated objects of the second administrator frontend to obtain merged objects. In this way, the system replaces the full package configuration write-back with atomic operation logs and combines vector clocks to determine causal relationships, so that legitimate modifications can be retained in the final state, reducing the probability of concurrent operations overwriting each other. This allows multiple administrators to edit the same routing canvas at the same time, and ensures that valid nodes, valid edges and distributed configurations always maintain topological validity during final convergence, thereby avoiding configuration loss and routing loops from impacting the underlying engine.

[0064] This invention provides a communication call routing system for concurrent editing and merging by multiple administrators. The system includes: The front-end atomic operation capture and vector clock marking module is used to intercept operations such as node addition, node deletion, edge addition, edge deletion, and attribute modification at the front-end routing canvas layer. Each interaction is encapsulated into an indivisible atomic operation object, and this object is appended with an operation identifier, author identifier, logical time, and vector clock. In a preferred embodiment, the atomic operation object can adopt the following structure: { "opId": "uuid-v4", "type": "ADD_EDGE", "payload": { "source": "IVR-01", "target": "Queue-02"}, "vectorClock": { "adminA": 5, "adminB": 3}, "timestamp": 1710000000123, "authorId": "adminA } The CRDT (Chart-Based Graph) data model module for communication routing is used to maintain the node addition set (Vadd), node deletion set (Vremove), edge addition set (Eadd), and edge deletion set (Eremove) in memory or an equivalent state machine. These four sets preferably maintain historical operations using an append-only record approach, ensuring that any replica receives a consistent result upon receiving the same set of operations.

[0065] The current set of valid nodes and the set of valid edges satisfy: V=Vadd\Vremove E={(u,v)∣(u,v)∈(Eadd\Eremove)∧u∈V∧v∈V} Therefore, whether an edge is effective depends not only on whether the edge itself has been deleted, but also on whether the nodes at both ends of the edge are still in the set of valid nodes.

[0066] The operation log broadcasting and causal replay module is used by the system to broadcast atomic operations via WebSocket or an equivalent bidirectional communication channel. Before applying a remote operation, the receiving end compares its local vector clock with the target operation vector clock. If a prerequisite dependency is found to be missing, the operation is written to a waiting buffer. Once the prerequisite operation is complete, the system replays the operation in causal order, avoiding state drift caused by weak network conditions or out-of-order transmission.

[0067] The DAG constraint verification and automatic loop repair module is used to construct a valid routing graph G(V,E) based on the current V and E after the basic CRDT merging is completed. This graph is then subjected to topology sorting, depth-first loop detection, or equivalent DAG validity verification. If a loop is detected, the system traces the set of candidate edges that formed the loop and selects the last edge causing the loop based on timestamp, priority, or preset conflict weights, forcibly adding it to the Eraseve set to break the loop. Simultaneously, the system pushes an alarm message to the front end, notifying the administrator that automatic protection has been triggered for this concurrent change.

[0068] The server-side snapshot compression and persistence module is used to separate and store operation logs and snapshots on the server side. When the cumulative number of operations on a single route object reaches a threshold, such as 1000, the system collapses the current graph CRDT state into a complete snapshot and persists it, while simultaneously cleaning up the collapsed logs. Newly joined administrators can quickly restore the canvas state by "pulling the latest snapshot + incremental operation logs".

[0069] The overall implementation architecture of a method for concurrent editing and merging of communication call routing by multiple administrators provided in this embodiment of the invention is as follows: Figure 3 As shown in the diagram, this architecture diagram illustrates a distributed collaborative editing system based on CRDT, designed to resolve data conflicts and consistency issues when multiple administrators simultaneously configure complex routes. The entire process can be broken down into four core stages, including: Phase 1: Front-end Operation Capture and Local Response. This phase occurs on Administrator A's front-end (and similarly for Administrator B) to achieve "user-unobtrusive instant response" and "operation standardization." The user interacts on the canvas, and Administrator A interacts on the ReactFlow interface of the routing canvas (e.g., dragging a new node or connecting lines). The operation event is captured and flows to the CRDT local state machine. Then, the interaction operation is atomically encapsulated. After receiving the interaction event, the CRDT local state machine does not directly modify the DOM but encapsulates it into a standard atomic operation object. During the atomic encapsulation process, a unique opId (unique operation identifier) ​​is generated, the operation type is recorded (ADD_NODE, ADD_EDGE, etc.), and the vector clock is updated: for example, {"adminA": 5, "adminB": 3}, marking the causal relationship. The encapsulated atomic operation flows to the WebSocket client to immediately update the canvas state locally (Optimistic UI), so that Administrator A does not perceive any delay. The atomic operation is then sent to the server-side central hub via a bidirectional push channel.

[0070] Phase Two: Message distribution and persistence at the server-side hub, including: The WebSocket broadcast and ordering service receives operation logs from administrator A. This service splits the message in two: Downward: flowing to the operation log storage OpLog for persistence. Rightward / loopback: flowing to other connected administrators (e.g., the WebSocket client in front of administrator B).

[0071] The operation log, OpLog, appends this atomic operation to the storage system to achieve persistent storage of the operation log. The data remains in the database, awaiting further processing.

[0072] Phase 3: Remote synchronization and causal consistency assurance, including: receiving remote operations at the front end of administrator B (or other collaborators). Administrator B's WebSocket client receives the operation sent by administrator A, causing data to flow to the CRDT local state machine.

[0073] The CRDT local state machine checks the vector clock in the operation. If the preconditions that administrator A's operation depends on are all met locally in administrator B, then the operation is directly merged. If administrator B finds that "I haven't received operation #4 yet, how come I've already received operation #5?", it puts operation #5 into the waiting buffer. Then, it performs completion and replay: once the missing operation #4 arrives, the system will execute #4 first, then #5. In this way, regardless of network jitter, administrator B's canvas state will eventually be completely consistent with administrator A's, without state drift. Finally, after the state machine is updated, the routing canvas ReactFlow is notified to re-render, and administrator B sees administrator A's changes.

[0074] The fourth stage: Backend verification, compression, and distribution, including: This stage is an asynchronous processing flow in the server-side central control. After the merge operation, the server constructs the current routing graph G(V,E). It performs topology sorting or cycle detection to achieve backend verification. If an infinite loop like A->B->C->A is found, the server will forcibly mark the last edge as deleted (written as `Eremove`) and push an alert to the frontend to verify the DAG's validity. When the operation log storage `OpLog` accumulates too much, it triggers the snapshot compression service, reads the latest state, generates a compressed binary or JSON snapshot, and writes it to the configuration snapshot storage. Afterwards, a secure configuration distribution is performed. The final routing configuration, after verification and merging, is pushed to the PBX's underlying communication engine through a secure configuration distribution channel (possibly file synchronization, API call, or message queue). This calls the route parsing and execution engine to load the new configuration, and the new routing rules officially take effect. In this way, by utilizing CRDT and vector time, the conflict problem when multiple administrators concurrently modify the routing graph is solved, ensuring that all administrators see the same final routing topology regardless of the operation order.

[0075] In some embodiments, the timing relationship between concurrent edit conflict merging and anti-loop timing is as follows: Figure 4 As shown, administrator A is deleting a node, while at the same time, administrator B is modifying the node that is about to be deleted. Figure 4 This can be achieved through the following five stages: Phase 1: Initial State Synchronization: The initial state is routing graph version V5, and both sides are synchronized. That is, in the initial stage, administrator A and administrator B see the exact same canvas, both at version V5. At this time, node IVR-002 exists.

[0076] Phase Two: Administrator A initiates a deletion operation and executes the operation: Administrator A executes "Operation ①: Delete node IVR-002" on the canvas. A-side state machine processing: The A-side CRDT state machine receives the instruction and immediately executes the deletion logic locally. It adds the node ID to the deletion set, i.e., executes Vremove.add(IVR-002). At this point, the node has disappeared from A's canvas.

[0077] A-end broadcast: A-end encapsulates this operation into message Op①, which includes the operation type (DEL_NODE) ​​and vector clock (VC: {A:6, B:5}), and sends it to the server for broadcast.

[0078] Phase 3: Administrator B initiates a modification operation. At this point, Administrator B has not yet received the deletion notification from A and believes the node still exists. Administrator B executes the operation: Administrator B executes "Operation ②: Modify node IVR-002 attributes" on the canvas (e.g., rename it). B-side state machine processing: The B-side CRDT state machine receives the instruction and executes the modification logic locally. It updates the attribute value using the LWW (Last Write Wins) register. B-side broadcast: B encapsulates this operation into message Op②, containing the operation type (UPDATE_PROP) and vector clock (VC: {A:5, B:6}), and sends it to the server for broadcast.

[0079] Phase 4: Server-side Concurrency Detection and Distribution: Server-side Detection: The server-side broadcast module receives Op① from A and Op② from B. The system determines that these two operations are concurrent. The server pushes Op① to B: The server pushes A's delete command to administrator B. The server pushes Op② to A: The server pushes B's modify command to administrator A.

[0080] Phase 5: Achieving conflict resolution and eventual consistency. B's processing logic (deletion priority): B receives Op①: B receives the "delete node" instruction from A. Triggering rule: B's state machine executes Vremove.add(IVR-002). Canvas update: Because the deletion operation has the highest priority (or according to CRDT rules), B's canvas is automatically updated, and the node and its associated edges disappear. Although B just modified the attributes, the modification is lost because the node was deleted.

[0081] Processing logic on end A (ignoring invalid modifications): End A receives Op②: A receives the "modify attribute" instruction from B. State check: A's state machine checks and finds IVR-002 is already in the deletion set. Discard operation: According to the rules, attribute modifications are ignored because a non-existent node does not need to update its attributes. Canvas maintenance: A's canvas maintains the node's deleted state.

[0082] Phase 6: Final state convergence prevents dangling nodes from entering the publishing chain. Despite the conflicts that occurred, the canvas states of A and B eventually reached consistency: node IVR-002 was successfully deleted. The system successfully avoided the anomaly of data inconsistency where "a node was deleted but its attributes were still being modified."

[0083] In some embodiments, the multi-administrator concurrent operation and DAG verification process includes: In administrator A's browser, the administrator performs an operation on the canvas: The process begins with administrator A interacting on the ReactFlow canvas (e.g., adding nodes, connecting lines). The front-end intercepts the operation and encapsulates it into an atomic operation object: The system intercepts the interaction event and converts it into a standard data structure (JSON). A logical timestamp (Vector Clock) is added to the operation for subsequent determination of causal order. The operation is immediately executed in memory, updating the local CRDT state (e.g., adding to the Vadd or Eadd collection). The canvas is immediately updated and optimistic rendering is performed: Based on the updated local state, the new graphic is immediately drawn on the screen without waiting for server confirmation, providing a zero-latency experience.

[0084] Broadcast operation logs to the server via WebSocket: Send atomic operation objects to the backend hub via WebSocket.

[0085] The server-side central processing unit receives the operation log: The WebSocket server receives the data packet sent by administrator A. It then persists the data to the operation log storage: the operation is written to the OpLog database to ensure no data loss. It forwards the data to other online administrators: the server identifies other collaborators on this route (such as administrator B) and pushes the operation to administrator B. In administrator B's browser, administrator B's client receives the operation from administrator A. The system compares the vector clock of the received operation with the locally known clock.

[0086] If the received data is "Step 5", but "Steps 1-4" are not yet available locally, it indicates that the data is out of order. This data is written to the waiting buffer, and the operation is temporarily suspended and not involved in rendering. Afterwards, a loop process begins: the system continuously waits for the preceding operations to arrive. Once all the data is complete, the process returns to this decision point.

[0087] If the dependent data already exists, or if this is the next operation arriving in sequence, proceed to the next concurrency processing judgment to achieve concurrency conflict detection and 2P2P-Graph merging.

[0088] Once the causal order is satisfied, the system needs to address the issue of "two people simultaneously modifying the same location." It determines whether the remote operation has a concurrent relationship with an unsynchronized local operation by administrator B (i.e., vector clocks are not comparable). If there is no concurrency, the causal order is applied directly without conflict, and execution proceeds immediately. If concurrency exists, the 2P2P-Graph merging rule is triggered, and conflict resolution logic is invoked.

[0089] Here, the system selects different merging strategies based on the operation type: Scenario A: Node deletion and attribute modification occur concurrently. If node A is modifying node attributes while node B is deleting a node, the final result will be that the node does not exist.

[0090] Scenario B: Node attributes are modified concurrently; the LWW register retains the more recent value. If A and B simultaneously change the name of the same node, the instruction with the later clock / timestamp will be executed.

[0091] Case C: Concurrent addition and deletion of edges, combining the sets of edges added and deleted. This is achieved through set operations (E=Eadd). The `Eremove` function is used to determine whether an edge exists.

[0092] Finally, the system performs DAG constraint verification and loop repair, executing topology sorting verification and loop detection: A temporary graph is constructed, and a DFS or topology sorting algorithm is run to check if the current merge result has led to an infinite loop (e.g., A->B->A). Afterward, loop detection is performed; if a loop is found, the last edge of the loop is written to EdgeRemove. The system automatically identifies the edge causing the loop and forcibly marks it as "deleted," thus breaking the loop and triggering the alarm step. If no loop is found, the system proceeds directly to the application step.

[0093] The system pushes an alarm that the routing loop has been automatically blocked to the front end. If the previous step triggered a repair, the system will pop up a prompt box to tell administrator B: "The previous operation would have caused an infinite loop, and the system has automatically blocked it."

[0094] The final state, after conflict resolution and security checks, is written into administrator B's local CRDT state machine and triggers ReactFlow to re-render, thus achieving eventual consistency between administrators A and B.

[0095] In a specific example, during an emergency cutover and loop prevention scenario in a large call center, a large bank's call center needed to urgently switch the routing of its entry numbers to a backup trunk due to a backbone line failure, while simultaneously adjusting the IVR menu and timeout routing strategy. Operations manager Zhang and technical specialist Li needed to perform these modifications simultaneously on the same routing configuration canvas. The implementation steps are as follows: The first step is concurrent lock-free entry: When Zhang and Li open the same route configuration at the same time, the system does not add a pessimistic lock to the route object, but instead displays the number of people currently collaborating and the cursor position of the other party in the interface.

[0096] The second step involves simultaneously executing different changes: Engineer Zhang deletes the obsolete "transfer to manual node" NodeA; Engineer Li almost simultaneously connects the exit of the "timeout overflow node" NodeB to NodeA in an attempt to build a new fallback transfer path.

[0097] The third step is to remove dangling paths that are prioritized for blocking: Two atomic operations are broadcast from the server to both replicas. The system writes NodeA... The set of valid edges is analyzed, and when resolving valid edges, it is found that the target node of the newly added edge is invalid. Therefore, (NodeB, NodeA) will not enter the set of valid edges, thus avoiding the continued distribution of dangling routes.

[0098] Fourth step, misoperation creates a loop: Subsequently, Li connected another exit of NodeB back to its upstream IVR main menu node, forming a closed loop of IVR to NodeB to IVR.

[0099] Step 5: Local state machine automatic repair: After CRDT merging, the system performs DAG detection, identifies loops in the current graph, and writes the last edge causing the loop into Eremove. This risky connection is highlighted on the canvas and then automatically removed, with an alarm popping up saying "Route dead loop detected, risky link automatically disconnected".

[0100] Step 6, Secure Release: After two administrators confirm that the remaining topology is legitimate, the system persists the current snapshot and sends it to the PBX underlying communication engine, completing the emergency cutover without configuration overwrite or routing dead loop.

[0101] In some embodiments, administrators can still edit locally even when the data center is offline or in a high-latency environment. Operation logs are first written to the browser's IndexedDB or equivalent local storage, and then merged with the server's CRDT (Credit Data Table) after network recovery to achieve eventual consistency prioritizing offline operations. Large routing maps are divided into multiple CRDT sub-maps based on business departments, number pools, or tenant ranges. Different administrators can only edit their authorized sub-maps, and sub-maps are connected through read-only interface nodes to balance collaboration efficiency and access control. When the system triggers automatic loop termination or large-scale edge failure, it can further link with the alarm center, audit logs, or change approval module to record and track high-risk concurrent editing activities.

[0102] In this embodiment of the invention, CRDT is introduced into the field of collaborative editing of communication routes. Through atomic operation logs and replica merging mechanisms, the concurrent editing capabilities of multiple administrators are applied to the strongly topologically constrained scenario of communication routes. This embodiment constructs a dedicated graph CRDT model for communication routes around node addition / deletion sets, edge addition / deletion sets, and effective topology resolution rules. This ensures that the validity of edges is naturally constrained by node states, providing anti-dangling capabilities. After merging, a DAG validity detection and automatic loop edge cutting mechanism are added, embedding DAG security constraints at the consistency convergence layer to ensure that the consistency result simultaneously satisfies the executable constraints of communication routes. Through causal buffering, snapshot compression, and incremental tracking synchronization, new administrators can quickly join collaborative sessions, and historical operations can be used for version tracing, issue auditing, and replay analysis, thus achieving both real-time collaboration and long-term recoverability.

[0103] This invention provides a communication call routing system for concurrent editing and merging by multiple administrators, such as... Figure 5 As shown, the system 500 includes: Module 501 is used to acquire the interactive operations of the first administrator's front end on the canvas layer. The encapsulation module 502 is used to encapsulate the interactive operation into an atomic operation object; The marking module 503 is used to logically mark atomic operation objects based on a vector clock to obtain marked atomic operation objects; Storage module 504 is used to persistently store the operation logs of the marked atomic operation objects and transmit them to the second administrator front end; Comparison module 505 is used to compare the local vector clock of the second administrator front-end with the vector clock of the marked atomic operation object before the second administrator front-end performs the interactive operation, and obtain the comparison result; The replay module 506 is used to write the currently received operation object into a waiting buffer if the comparison result indicates that a preceding operation object has not yet arrived, until the preceding operation object is completed, and then perform the replay operation according to the causal order of the marked atomic operation objects; wherein, the preceding operation object is the object on which the execution of the marked atomic operation object depends; The merging module 507 is used to perform concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object of the second administrator front end to obtain the merged object.

[0104] In some possible implementations, the merging module 507 is further configured to determine whether there is a concurrent conflict between the local unoperated object of the second administrator frontend and the marked atomic operation object received by the second administrator frontend; if there is a concurrent conflict between the local unoperated object and the marked atomic operation object, obtain the preset merging rule of the second administrator frontend; based on the preset merging rule, merge the local unoperated object of the second administrator frontend and the marked atomic operation object received by the second administrator frontend to obtain the merged object.

[0105] In some possible implementations, the merging module 507 is further configured to determine the first operation type of the local unoperated object and the second operation type of the marked atomic operation object; based on the first operation type and the second operation type, select a matching target merging rule from the preset merging rules; and based on the target merging rule, merge the local unoperated object of the second administrator front-end and the marked atomic operation object received by the second administrator front-end to obtain a merged object.

[0106] In some possible implementations, the merging module 507 is further configured to: if the second operation type is a modify node type and the first operation type is a delete node type, select the delete node as the target merging rule in the preset merging rules; if both the second operation type and the first operation type are modify node types, select the modify node with the later timestamp as the target merging rule in the preset merging rules according to the timestamps corresponding to the second operation type and the first operation type; if the second operation type is an add edge type and the first operation type is a delete edge type, select concurrent addition and deletion of edges as the target merging rule in the preset merging rules.

[0107] In some possible implementations, the merging module 507 is further configured to: extract the current set of valid nodes and the current set of valid edges from the merged object; construct a routing topology graph based on the current set of valid nodes and the current set of valid edges; perform depth-first loop detection on the routing topology graph to determine whether a closed loop path exists; if a closed loop path is detected, identify the target edge causing the closed loop path in the routing topology graph; forcibly write the target edge into the edge deletion set to cut off the closed loop path; and generate and output alarm information.

[0108] In some possible implementations, the merging module 507 is further configured to determine a set of candidate edges that form the closed-loop path; and select the candidate edge with the largest timestamp or the smallest preset conflict weight from the set of candidate edges as the target edge.

[0109] In some possible implementations, the storage module 504 is further configured to determine the amount of stored data in the operation log of the marked atomic operation object; if the amount of stored data is greater than a preset data volume threshold, perform snapshot compression on the stored operation log of the marked atomic operation object to obtain a compressed log; and update the stored operation log of the marked atomic operation object based on the compressed log.

[0110] In some possible implementations, the storage module 504 is further configured to, when a newly added third administrator frontend is detected, obtain the latest snapshot from the compressed log; atomically encapsulate the interaction operations of the third administrator frontend on the canvas layer to obtain incremental operation logs; and update the current state of the canvas layer based on the latest snapshot and the incremental operation logs of the third administrator frontend.

[0111] In some possible implementations, the marking module 503 is further configured to obtain the operation identifier, author identifier, and logical time of the atomic operation object; determine the vector clock of the atomic operation object based on the causal order and logical time of the atomic operation object; and mark the atomic operation object using the vector clock, operation identifier, and author identifier to obtain the marked atomic operation object.

[0112] Optionally, the transmission medium can be a wired link (e.g., but not limited to, coaxial cable, optical fiber, and Digital Subscriber Line (DSL)) or a wireless link (e.g., but not limited to, Wireless Fidelity (WIFI), Bluetooth, and mobile block device networks). It should be noted that the control block device provided in the above embodiments is only an example illustrating 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 computer block device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0113] Figure 6 This is a schematic diagram of the structure of a computer block device provided in an embodiment of the present invention. For example, as shown... Figure 6 As shown, the computer block device 600 includes: a memory 601, a processor 602, and a computer program 603 stored in the memory 601 and running on the processor 602, wherein when the processor 602 executes the computer program 603, the computer block device can execute any of the communication call routing multi-administrator concurrent editing and merging methods described above.

[0114] Furthermore, embodiments of the present invention also protect a control block device, which may include a memory and a processor. The memory stores executable program code, and the processor is used to call and execute the executable program code to perform a method for concurrent editing and merging of communication call routes by multiple administrators provided in this embodiment of the present invention. Embodiments of the present invention can divide the control block device into functional modules based on the above method examples. For example, each module may correspond to a specific function, or two or more functions may be integrated into a single processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment of the present invention is illustrative and only represents a logical functional division; in actual implementation, there may be other division methods. It should also be noted that all relevant content of each step involved in the above method embodiments can be referenced to the functional description of the corresponding functional module, and will not be repeated here. It should be understood that the control block device provided in this embodiment of the present invention is used to execute the above-mentioned method for concurrent editing and merging of communication call routes by multiple administrators, and therefore can achieve the same effect as the above-described implementation method. When using integrated units, the control block device may include a processing module and a storage module. When the control block device is applied to a block device, the processing module can be used to control and manage the actions of the block device. The storage module can be used to support the block device in executing mutual program code, etc. The processing module can be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of Digital Signal Processing (DSP) and a microprocessor, etc., and the storage module can be a memory.

[0115] Furthermore, the control block device provided in the embodiments of the present invention may specifically be a chip, component, or module. The chip may include a connected processor and a memory; wherein, the memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute the communication call routing multi-administrator concurrent editing and merging method provided in the above embodiments. The embodiments of the present invention also provide a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned related method steps to implement the communication call routing multi-administrator concurrent editing and merging method provided in the above embodiments.

[0116] This invention also provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the aforementioned related steps to implement the communication call routing multi-administrator concurrent editing and merging method provided in the above embodiments. The control block device, computer-readable storage medium, computer program product, or chip provided in this invention are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they achieve can be referred to in the beneficial effects of the corresponding methods provided above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art can understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the control block device can be divided into different functional modules to complete all or part of the functions described above. In the embodiments provided by this invention, it should be understood that the disclosed control block device and method can be implemented in other ways. For example, the control block device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another control block device, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between control block devices or units may be electrical, mechanical, or other forms.

[0117] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. The above content is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for concurrent editing and merging of communication call routes by multiple administrators, characterized in that, The method includes: Obtain the interactive operations of the first administrator's front end on the canvas layer; The interactive operations are encapsulated into atomic operation objects; Logically mark atomic operation objects based on vector clocks to obtain marked atomic operation objects; The operation logs of the marked atomic operation objects are persistently stored and transmitted to the second administrator's front end; Before performing interactive operations on the second administrator front end, the local vector clock of the second administrator front end is compared with the vector clock of the marked atomic operation object to obtain the comparison result; If the comparison result indicates that a preceding operation object has not yet arrived, the currently received operation object is written into the waiting buffer until the preceding operation objects are completed, and the replay operation is performed according to the causal order in the marked atomic operation objects; wherein, the preceding operation object is the object on which the execution of the marked atomic operation object depends; The operation object to which the replay operation belongs is subjected to concurrent conflict detection and merging with the local non-operated object in the second administrator front end to obtain the merged object.

2. The method according to claim 1, characterized in that, The step of performing concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object in the second administrator's front end to obtain the merged object includes: Determine whether there is a concurrency conflict between the local unoperated object of the second administrator frontend and the marked atomic operation object received by the second administrator frontend; If there is a concurrent conflict between the local non-operated object and the marked atomic operation object, obtain the preset merging rule of the second administrator frontend; Based on the preset merging rules, the local unoperated objects of the second administrator front-end and the marked atomic operation objects received by the second administrator front-end are merged to obtain merged objects.

3. The method according to claim 2, characterized in that, Based on the preset merging rules, the local unoperated objects of the second administrator frontend and the marked atomic operation objects received by the second administrator frontend are merged to obtain merged objects, including: Determine the first operation type of the locally unoperated object and the second operation type of the marked atomic operation object; Based on the first operation type and the second operation type, select the matching target merging rule from the preset merging rules; Based on the target merging rule, the local unoperated objects of the second administrator frontend and the marked atomic operation objects received by the second administrator frontend are merged to obtain merged objects.

4. The method according to claim 3, characterized in that, The step of selecting a matching target merging rule from the preset merging rules based on the first operation type and the second operation type includes: If the second operation type is to modify a node and the first operation type is to delete a node, then the target merging rule is to delete the node in the preset merging rules. If both the second operation type and the first operation type are modification node types, the modification node with the later timestamp is selected as the target merging rule according to the timestamps corresponding to the second operation type and the first operation type in the preset merging rule. If the second operation type is adding an edge class and the first operation type is deleting an edge class, then the target merging rule is selected as concurrent adding / deleting edges in the preset merging rules.

5. The method according to claim 1, characterized in that, After performing concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object in the second administrator frontend to obtain the merged object, the method further includes: Extract the current set of valid nodes and the current set of valid edges from the merged objects; Construct a routing topology graph based on the current set of valid nodes and the current set of valid edges; Depth-first loop detection is performed on the routing topology map to determine whether a closed loop path exists; If a closed loop path is detected, the target edge that causes the closed loop path is identified in the routing topology graph. The target edge is forcibly written into the edge deletion set to cut off the closed loop path, and an alarm message is generated and output.

6. The method according to claim 5, characterized in that, If a closed loop path is detected, identifying the target edge leading to the closed loop path in the routing topology graph includes: Determine the set of candidate edges that form the closed-loop path; In the candidate edge set, the candidate edge with the largest timestamp or the smallest preset conflict weight is selected as the target edge.

7. The method according to claim 1, characterized in that, The method further includes: Determine the amount of stored data in the operation log of the marked atomic operation object; If the amount of stored data is greater than a preset data threshold, the operation log of the stored marked atomic operation object is snapshot compressed to obtain a compressed log; The operation log of the stored tagged atomic operation object is updated based on the compressed log.

8. The method according to claim 7, characterized in that, The method further includes: When an interactive operation of the third administrator's front end on the canvas layer is detected, the latest snapshot is obtained from the compressed log; The interactive operations of the third administrator's front end on the canvas layer are atomically encapsulated to obtain incremental operation logs; Based on the latest snapshot and the incremental operation logs of the third administrator frontend, update the current state of the canvas layer.

9. The method according to claim 1, characterized in that, Before logically marking the atomic operation objects based on the vector clock to obtain the marked atomic operation objects, the method further includes: Obtain the operation identifier, author identifier, and logical time of the atomic operation object; The causal order and logical time of the atomic operation objects are bound together to obtain the vector clock of the atomic operation objects; Correspondingly, the step of logically marking atomic operation objects based on vector clocks to obtain marked atomic operation objects includes: The atomic operation object is marked using the vector clock, operation identifier, and author identifier to obtain the marked atomic operation object.

10. A communication call routing system for concurrent editing and merging by multiple administrators, characterized in that, The system includes: The acquisition module is used to acquire the interactive operations of the first administrator's front end on the canvas layer; An encapsulation module is used to encapsulate the interactive operations into atomic operation objects; The marking module is used to logically mark atomic operation objects based on a vector clock to obtain marked atomic operation objects. The storage module is used to persistently store the operation logs of the marked atomic operation objects and transmit them to the second administrator front end; The comparison module is used to compare the local vector clock of the second administrator front-end with the vector clock of the marked atomic operation object before the second administrator front-end performs the interactive operation, and obtain the comparison result; The replay module is used to write the currently received operation object into a waiting buffer if the comparison result indicates that a preceding operation object has not yet arrived, until the preceding operation object is completed, and then perform the replay operation according to the causal order in the marked atomic operation objects; wherein, the preceding operation object is the object on which the execution of the marked atomic operation object depends; The merging module is used to perform concurrent conflict detection and merging on the operation object to which the replay operation belongs and the local non-operated object of the second administrator front end to obtain the merged object.

Images