A method and system for real-time synchronization of user data of a multi-service system organization

Abstract

The application discloses a kind of based on non-invasive adapter multi-service system mechanism user data real-time synchronization method and system.Utilize visual interface or rule expression to carry out flexible arrangement to multiple non-invasive adapter flow nodes, define data source, target and synchronization flow direction;Through dynamic credential management module, the automatic management and refresh of access credential are realized;Support full amount manual synchronization to complete initial data construction, based on event listening, realize the automatic real-time synchronization of incremental data, provide manual incremental synchronization as compensation mechanism.In execution synchronization, through existence check intelligent decision making, new or update operation is guaranteed data consistency.System includes logic engine core, non-invasive adapter, dynamic credential management and synchronization execution engine etc.Module.The application realizes the non-invasive, flexible programmable, high-reliable data real-time synchronization of heterogeneous service system, effectively solves the problem of high modification cost, poor flexibility, consistency difficult guarantee of traditional integration scheme.

Description

Technical Field

[0001] This invention relates to a synchronization method and system, and more particularly to a real-time synchronization method for multi-service system organizational user data based on a non-intrusive adapter, belonging to the field of enterprise application integration (EAI) and data synchronization technology. Background Technology

[0002] In modern enterprise IT architectures, the coexistence of multiple heterogeneous business systems (such as OA, HR, and video conferencing) is common. These systems are typically developed by different vendors at different times, resulting in differentiated data models, technology stacks, and interface protocols. Organizational and user data, as the core foundational data of an enterprise, are often scattered across these isolated systems, forming "data silos." Therefore, achieving real-time, accurate, and consistent synchronization of organizational and user data across systems is a crucial prerequisite for enterprises to achieve unified identity management, single sign-on (SSO), and business process collaboration, and falls under the core requirements of Enterprise Application Integration (EAI) and data synchronization technology.

[0003] Currently, the mainstream technical solution for achieving this type of data synchronization relies on point-to-point integration using open APIs (such as RESTful APIs) provided by each business system. Specifically, this solution requires the caller (i.e., the integrator or synchronization middleware) to act as an active HTTP client, developing according to the publicly available interface documentation of the target system. Typical implementation methods include:

[0004] (1) Active Invocation: The caller writes code to actively initiate an HTTP request (such as GET or POST) based on business needs, and calls a specific interface provided by the target system (such as `GET / orgDepartment / {id}`) to obtain or write data.

[0005] (2) Credential Management: Before making a call, the caller must obtain and manage the access token (such as a Restful token) through a dedicated authentication interface and be responsible for refreshing the token when it expires.

[0006] (3) Full data retrieval: For data retrieval, APIs usually only support interfaces that query a single record by identifier or retrieve all data at once, lacking a native incremental data retrieval mechanism.

[0007] (4) Hard-coded adaptation: The caller needs to deeply parse and couple the specific JSON data structure returned by the API (such as field names `orgAccountId`, `properties.fax`, etc.), and write dedicated processing logic for specific error codes defined by the server (such as `DEPARTMENT_REPEAT_NAME`) and complex error response structures.

[0008] The above-mentioned peer-to-peer integration solution based on open APIs has revealed the following significant shortcomings in practical applications:

[0009] (1) The integration and transformation are complex and not "plug and play": the caller must independently implement the entire set of underlying logic such as network communication, serialization / deserialization, and error retries. The development workload is large, and it is impossible to achieve fast and configurable system access. A lot of repetitive adaptation development is required for each new system.

[0010] (2) Heavy burden of credential management: The caller needs to take on the additional responsibility of secure storage, regular refresh and leakage risk management of access tokens, which increases the complexity of the system and the cost of operation and maintenance.

[0011] (3) Lack of efficient incremental synchronization mechanism: Since APIs usually only provide full data query interface, to achieve incremental synchronization, the caller must design and maintain a complex change detection, status tracking and polling mechanism, which is difficult to develop and inefficient, and it is difficult to guarantee the real-time performance of the data.

[0012] (4) Field mapping is hard-coded, resulting in high coupling and poor maintainability: The business logic of the caller is tightly bound to the data structure returned by the third-party API. Once the field name, type or structure of the server changes, all related caller code must be modified synchronously, resulting in poor system maintainability and difficulty in upgrading.

[0013] (5) Error handling is coupled with business logic: The caller needs to write special processing logic for specific error codes and complex nested error information structures of different business systems, which makes the core business logic deeply coupled with the non-standard design of the third-party system, reducing the system's fault tolerance and robustness.

[0014] In summary, existing technical solutions are essentially an "intrusive" integration method, which is not only costly and time-consuming to implement, but also lacks flexibility and reliability, failing to meet the core requirements of "real-time, bidirectional, flexible, and reliable" data synchronization in a multi-business system environment. Therefore, a completely new technical solution is urgently needed to overcome these inherent defects. Summary of the Invention

[0015] To address the shortcomings of existing technologies, this invention discloses a method for real-time synchronization of user data across multiple business systems, the technical solution of which includes the following steps:

[0016] Configuration phase:

[0017] Step S101: Through the core module of the logic engine, multiple non-intrusive adapter process nodes are logically orchestrated in a visual orchestration or rule expression manner, defining at least one data source system, at least one target system, and the synchronous flow of data between them; wherein, each of the non-intrusive adapter process nodes interfaces with a specified business system through pre-configured interaction rules.

[0018] Step S102: Configure access credentials for the data source system and the target system, and have them securely stored and automatically refreshed by the dynamic credential management module;

[0019] Synchronous execution phase:

[0020] Step S103: In response to the full synchronization trigger command, execute the synchronization logic arranged in step S101: obtain all institutional and user data from the data source system, perform existence verification before writing data for each target system, and perform add or update operations based on the verification results.

[0021] Step S104: Configure and enable event listening to receive notifications of institutional or user data change events from the data source system;

[0022] Step S105: After the full synchronization in step S103 is completed, automatically respond to the change event listened to in step S104 and execute the synchronization logic arranged in step S101: obtain the details of the changed data and synchronize it to each target system, perform existence verification before writing the data, and perform add or update operations according to the verification results.

[0023] Compensation phase:

[0024] Step S106: In response to the incremental synchronization trigger command for a specific data range, execute the synchronization logic arranged in step S101: obtain the institution and user data within the specified range from the data source system and synchronize it to the target system, perform existence verification before writing the data, and perform add or update operations based on the verification results.

[0025] This invention also discloses a real-time synchronization system for multi-service system organizational user data based on a non-intrusive adapter for implementing the above method, characterized in that it includes:

[0026] The core module of the logic engine is used to provide a visual orchestration interface and parse rule expressions to define and configure nodes and flow in the synchronization process;

[0027] The non-intrusive adapter module contains multiple process nodes, each corresponding to a business system, and implements data read and write operations with the business system through configurable interaction rules;

[0028] The dynamic credential management module is used to securely store access credentials for various business systems and provides automatic credential refresh service.

[0029] The synchronization execution engine module is connected to the logic engine core module, the non-intrusive adapter module, and the dynamic credential management module, respectively. It is used to receive trigger instructions or events, drive the execution of the orchestrated synchronization process, and coordinate the non-intrusive adapter module to complete data synchronization.

[0030] The present invention also discloses a computer-readable storage medium having a computer program stored thereon, characterized in that, when executed by a processor, the program is used to control a device to perform the method described above.

[0031] The present invention also discloses a terminal device, characterized in that the terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the above method.

[0032] Beneficial effects

[0033] This achieves true non-intrusive integration, significantly reducing transformation costs and risks: By employing configurable, non-intrusive adapter process node encapsulation and interaction logic with various business systems, all synchronous operations are completed within the system through configuration, without requiring modification to the source code or database structure of any existing business systems. This completely avoids the invasive modifications required by traditional point-to-point integration solutions, transforming system integration from "custom development" to "configuration access," greatly reducing implementation complexity, timelines, and long-term maintenance risks.

[0034] It offers extremely high flexibility and orchestration of the synchronization process: Leveraging the visual / expression-based orchestration capabilities provided by the core logic engine module, users can freely define any system as a data source or target through graphical drag-and-drop or by writing rules (such as `THEN(A,B,C)`), and flexibly configure the synchronization flow. This breaks the architectural limitations of traditional unidirectional master-slave synchronization, enabling rapid response to changes in enterprise organizational structure or business processes, easily building bidirectional or even mesh synchronization relationships, and solving the problems of rigidity and poor flexibility in existing technical architectures.

[0035] High reliability and eventual consistency of data synchronization are ensured: First, proactive existence verification before writing and intelligent selection of add or update operations effectively avoid data duplication and overwrite conflicts. Second, the automatic credential refresh mechanism implemented by the dynamic credential management module ensures the continuous availability of the authentication chain. Finally, the combination of event-driven automatic incremental synchronization and the failure retry mechanism provided by the incremental synchronization compensation module constitutes a complete reliability assurance system from normal operation to anomaly recovery, significantly improving the robustness and success rate of data synchronization tasks.

[0036] This enhances the system's maintainability and adaptability: when the interface or data structure of the business system changes (e.g., a field name changes from `departName` to `organName`), the change only requires adjusting the configuration or interaction rules of the field mapping unit in the corresponding non-intrusive adapter process node, without modifying the core synchronization logic or recoding. This configuration-based maintenance approach allows the system to quickly adapt to changes in third-party systems, significantly reducing coupling and long-term maintenance costs. Attached Figure Description

[0037] Figure 1 This is a block diagram of the system structure of the present invention;

[0038] Figure 2 This is a schematic diagram illustrating the process node definition of the present invention;

[0039] Figure 3 This is a schematic diagram of the process node arrangement of the present invention (with system A as the data center);

[0040] Figure 4 This is a schematic diagram of the process node arrangement of the present invention (with system B as the data center);

[0041] Figure 5 This is a schematic diagram illustrating the use of `departName` as the organization name in the video conferencing system of this invention.

[0042] Figure 6 This is a schematic diagram illustrating the synchronous execution of the present invention using departureName as the organization name;

[0043] Figure 7 This is a schematic diagram illustrating the adjustment of the organization name to "organName" in the video conferencing system of the present invention.

[0044] Figure 8 This is a schematic diagram illustrating the synchronous execution of the present invention using organName as the organization name;

[0045] Figure 9 This is a schematic diagram of the system call of the present invention;

[0046] Figure 10This is a hierarchical diagram of the logic engine architecture of the present invention;

[0047] Figure 11 This is the UML diagram of the present invention. Detailed Implementation

[0048] Example 1

[0049] This embodiment follows a workflow of 'configuration -> initialization -> real-time synchronization -> anomaly compensation'. First, the synchronization topology and rules are configured through the core module of the logic engine (corresponding to S101, S102, and S104). Second, a data baseline is established through manual full synchronization (corresponding to S103). Subsequently, the system enters normal operation, relying on event listening and automatic synchronization to achieve real-time flow of incremental data (corresponding to S105). Finally, when an anomaly occurs, eventual consistency is ensured through manual fixed-point compensation synchronization (corresponding to S106). The execution of all steps is uniformly scheduled by the orchestration process defined in the core module of the logic engine.

[0050] See attached document Figure 1 This demonstrates how, when different business systems serve as a unified data center, the system synchronizes the organization or user to other business systems by sending HTTP request notifications of changes in the organization or user.

[0051] A method for real-time synchronization of organizational user data across multiple service systems based on a non-intrusive adapter includes the following steps:

[0052] Configuration phase:

[0053] Step S101: Through the core module of the logic engine, multiple non-intrusive adapter process nodes are logically orchestrated in a visual orchestration or rule expression manner, defining at least one data source system, at least one target system, and the synchronous flow of data between them; wherein, each of the non-intrusive adapter process nodes interfaces with a specified business system through pre-configured interaction rules.

[0054] This step, through the central control unit of the logic engine core module, provides users with two equivalent and complementary configuration entry points: one is a rule expression (EL) editing interface for developers or technical personnel, and the other is a graphical drag-and-drop interface for business or operations personnel. These two interfaces are essentially two representations of the same configuration model. Visual operations are converted into rule expressions that can be interpreted by the engine at the underlying level (such as `THEN(a, b, c, d)`), while directly written expressions can also be rendered as graphical processes, thus balancing configuration flexibility and ease of use. The core configuration objects are multiple non-intrusive adapter process nodes, each node being a pre-built, independent software unit that encapsulates the data interaction logic with a specific heterogeneous business system (such as an OA system or a video conferencing system). (Appendix) Figure 2 The diagram illustrates the specific definition of a node, showing that it is a JavaScript-executed node that synchronizes organizational users to the OA system. Users can logically orchestrate these nodes through the interface, defining their execution order and data flow. This can be done by writing `THEN(System A, System B, System C)` or dragging and dropping connections, explicitly specifying at least one system as the data source, at least one system as the target, and the path of data flow between them. The essence of this orchestration is to completely decouple the synchronization logic (i.e., "who provides the data, through whom, and ultimately synchronized to whom") from traditional hard-coded programs, transforming it into an externally dynamically definable, persistently stored "metadata" or "flowchart" that can be parsed in real-time by the logic engine.

[0055] Each orchestrated adapter node can interface with the business system without modifying its code thanks to pre-configured interaction rules within the node. These rules define, in a configurable manner, how the node communicates and transforms data with specific types of system interfaces. For example, configuring SQL statements to query a database, configuring HTTP request URLs and JSON parsing templates to call RESTful APIs, or configuring LDAP filters to access directory services. When a synchronization task is triggered, the core module of the logic engine first parses the orchestration logic defined in step S101, transforming it into a specific, ordered sequence of adapter node calls. Then, the engine drives each node to execute sequentially, and the node, according to its built-in interaction rules, completes specific data query or write operations with the corresponding business system. The entire process achieves a clear separation between "orchestration defining logic and node executing operations."

[0056] The key effects and technological innovations of this step are as follows: First, it achieves true non-intrusion because all adaptation logic for heterogeneous systems is pre-encapsulated within configurable nodes. Business systems do not need to perform any secondary development for integration; they only need to expose standard interfaces, thus completely solving the defects of "intrusive modification and high integration costs." Second, it provides unprecedented flexibility. Users can dynamically switch data sources and synchronization directions by simply dragging and dropping or modifying the order of expressions (e.g., changing `THEN(A, B, C)` to `THEN(B, A, C)`), easily building multi-directional synchronization topologies centered on any system. This directly overcomes the inherent problem of "poor flexibility" in traditional point-to-point or master-slave architectures. (Appendix) Figure 3 and appendix Figure 4 Together, they demonstrated that when using different business systems as data centers, only the data center node on the left needs to be changed from data center A to data center B. Finally, the architecture of separating configuration and execution greatly improves the system's maintainability and scalability; when an interface field of a business system changes (e.g., the organization name field changes from `departName` to `organName`), typically only the field mapping rules within the corresponding adapter node need to be modified, without affecting the overall synchronization process logic, significantly reducing maintenance costs. (Appendix) Figure 5 and appendix Figure 6 This demonstrates that when synchronizing organizations from this system to the video conferencing system, the system uses `departName` provided in its public API as the organization name. After the video conferencing system changes the organization name attribute from `departName` to `organName`, this system will change `departName` to `organName` in the "Synchronize Organization Users to Video Conferencing Components" section (as shown in the attached document). Figure 7 (See attached) Figure 8 This demonstrates that in the subsequent synchronization process, the system will use the latest `organName` as the new organization name attribute.

[0057] Without adopting this "arrangement-based, configurable adapter node" approach, we can only revert to the traditional integration model: either hard-coded programs are written for synchronization between each pair of systems, leading to tight coupling and difficulty in modification; or simple tools that only support static configuration are used, which cannot achieve dynamic and complex multi-source, multi-objective logic orchestration. Therefore, the technical approach of combining visual / expression-based orchestration logic with configurable adapter nodes, as embodied in step S101, is not a simple combination of common knowledge, but a creative technical solution proposed to solve the core defects of existing technologies such as poor flexibility, strong invasiveness, and high cost. It is the fundamental architectural innovation that enables the invention to achieve its beneficial effects.

[0058] Step S102: Configure access credentials for the data source system and target system, and securely store and automatically refresh them using the dynamic credential management module. Specifically, it is necessary to pre-configure the initial account information for authorized access for each business system, such as the secretId and secretKey for a video conferencing system, or the REST account for an OA system. This initial information is centrally and securely stored in the dynamic credential management module (also known as the credential manager).

[0059] This module is responsible for the full lifecycle management of credentials. Its working principle is as follows: When a synchronization process needs to call an API interface of a business system, it requests valid access credentials (such as a token) from this module. The module first checks whether a valid credential already exists for that system. If it does not exist, it immediately uses pre-configured initial account information to initiate a standard authentication request to the target system to obtain a new access credential. If the credential already exists, the module does not passively provide it, but rather monitors the validity of its use. The key is that when an API call using this credential is rejected by the target system due to expiration and a specific unauthorized status (e.g., HTTP 401 Unauthorized) is returned, this module captures this signal and determines that the credential is invalid. Subsequently, the module automatically triggers a credential refresh process, re-applies for a new credential using the stored initial account information, and updates the storage, thus seamlessly ensuring the continued smooth operation of all subsequent synchronization calls and achieving full automation and high availability of the authentication process.

[0060] A separate dynamic credential management module is introduced. Authentication information (such as secretId / secretKey, OAuth tokens) from various business systems is centrally and securely stored in this module, which is responsible for managing the credential lifecycle, especially automatic refresh. The system pre-configures initial authentication information for each business system. When a system's API needs to be called during the synchronization process, a valid token is requested from the credential management module. This module not only returns the token but also monitors the API call result. If the target system returns "unauthorized" (such as an HTTP 401 status code), the module determines that the token is invalid and automatically re-initiates the authentication request using the pre-stored initial authentication information, obtains a new token, and updates the storage, ensuring smooth subsequent calls.

[0061] Synchronous execution phase:

[0062] Step S103: In response to the full synchronization trigger command, execute the synchronization logic arranged in step S101: obtain all institutional and user data from the data source system, perform existence verification before writing data for each target system, and perform add or update operations based on the verification results.

[0063] This step is triggered manually, for example, when a user clicks the "Full Synchronization" button on the system page. The system will then send an HTTP request to initiate the execution of the orchestrated logical flow. The core purpose of full synchronization is to provide an initial data consistency benchmark for business systems that are already in use and contain organizational and user data, thereby creating conditions for subsequent incremental automatic synchronization.

[0064] Its execution process follows a rigorous "recursive retrieval and intelligent verification" procedure:

[0065] 1. Recursive Acquisition of Full Data: Following the process defined in step S101, the system recursively acquires all organizational levels and all user data under them, starting from the specified data source system. The hierarchical relationships between organizations are typically maintained using the parent organization identifier (parentOrgId or pid) and the current organization identifier (orgId or objuid). For example, the pid of a lower-level organization is equal to the objuid of its parent organization. The system traverses this relationship layer by layer to construct a complete organizational tree and user list.

[0066] 2. Perform existence verification and synchronization for each item: For each piece of organization data obtained, the system will call the corresponding adapter node of the target business system according to the orchestration logic, and first perform a query operation to determine whether the organization (usually identified by the organization ID) already exists in the target system.

[0067] If the target system's new interface is not found, the adapter node calls the new interface of the target system to create the organization.

[0068] If the system is determined to already exist, the adapter node calls the target system's update interface to refresh the organization's information with the latest data.

[0069] 3. Users under a Synchronization Organization: After synchronizing an organization or confirming its existence, the system then retrieves all user data under that organization. For each user, the system also calls the adapter node of the target system to first query whether the user (usually identified by a user ID) exists.

[0070] If the user does not exist, perform the add operation.

[0071] If the user already exists, perform an update operation.

[0072] 4. Loop until completion: The above "organization synchronization - user synchronization" process will be executed cyclically according to the hierarchical relationship of the data source until all organizations and their subordinate users have been processed, thereby ensuring that all organizational and user data of the data source system are completely and accurately synchronized to one or more target business subsystems.

[0073] The entire synchronization process, including its steps, sequence, and the systems involved, is entirely controlled by the orchestration flow (i.e., the synchronization logic flow) configured through the core module of the logic engine in step S101. The mechanism implemented in this step—"actively verifying existence before writing and deciding whether to call the add or update interface based on the result"—is the core anti-conflict measure to ensure data consistency across multiple systems. It prevents data duplication or erroneous overwriting caused by blindly inserting data from the outset, laying a reliable data foundation for the entire synchronization scheme.

[0074] Step S104: Configure and enable event listening to receive notifications of institutional or user data change events from the data source system. Provide a configurable HTTP Webhook listening interface for the data source system to proactively push event notifications when data changes occur.

[0075] This step aims to establish an event-driven triggering channel to achieve real-time awareness of incremental data. The system provides a configurable HTTP Webhook listening interface, which serves as the unified endpoint for receiving data change events. During implementation, access paths (e.g., ` / api / organizations` and ` / api / users`) and necessary security authentication (such as Bearer Token authentication) need to be configured for this listening interface in the system.

[0076] The core of its configuration and operation is as follows: When the business system designated as the data center (i.e. the main data source) undergoes changes such as adding, deleting, or modifying organizational or user information, the data center system will proactively initiate an HTTP POST request to the aforementioned listening interface address pre-configured in this system, thereby "pushing" the change event notification.

[0077] The request body for this event notification must carry key information about the changed entity in a structured data format (such as JSON):

[0078] For organizational change events, the notification data should include at least: the organization name (`orgName`), the display sorting information (`orgOrder`), the identifier of the current level organization as a unique identifier (`orgId`), and the identifier of the parent organization indicating its hierarchical relationship (`parentOrgId`).

[0079] For user change events, the notification data should include at least the following information: user unique identifier (`userId`), user name (`userName`), user's organization identifier (`orgId`), user login account (`userAccount`), and user security level (`securityLevel`).

[0080] Upon receiving this HTTP request, the system performs security verification and parses the event data in the request body, converting it into an internal event object. This event object marks the start of an incremental synchronization task and is the direct signal to trigger the subsequent automatic synchronization process in step S105. Through this design, the data synchronization triggering method is transformed from the traditional, inefficient "polling query" to the efficient "event-driven" approach, laying the foundation for achieving true real-time synchronization.

[0081] Step S105: After the full synchronization in step S103 is completed, automatically respond to the change event listened to in step S104 and execute the synchronization logic arranged in step S101: obtain the details of the changed data and synchronize it to each target system, perform existence verification before writing the data, and perform add or update operations according to the verification results.

[0082] This step is the core process for achieving real-time, automatic incremental synchronization. With the initial full synchronization (step S103) completed and event listening (step S104) configured and enabled, the entire process will run completely automatically without any manual intervention.

[0083] The specific workflow is as follows:

[0084] 1. Event Reception and Data Processing: When this system receives an organization or user change event notification pushed by the data source system through the listening interface configured in step S104 (the event carries the key identifier of the changed entity, such as `orgId` or `userId`), the system will first parse and verify the event.

[0085] 2. Reverse lookup to obtain the latest complete data: The system does not rely solely on the limited information carried in event notifications. To ensure the integrity and accuracy of synchronized data, the system proactively calls the query interface provided by the business system serving as the data source, based on the event type and change identifier, to obtain the latest and most complete detailed information about the organization or user.

[0086] 3. Execute the orchestration synchronization logic: After obtaining the latest data details, the system will execute synchronization according to the synchronization orchestration process (e.g., the logic defined by the EL expression `THEN(a, b, c, d)`) pre-configured in step S101 through the core logic engine module. This orchestration process defines the complete path of data from source to destination.

[0087] 4. Intelligent Synchronization for Each Target System: Following the orchestration process, changed data will be sequentially synchronized to one or more target business subsystems. For each target system, its corresponding non-intrusive adapter node (i.e., the synchronization component, such as the component synchronizing to the OA system) will perform the following atomic operations:

[0088] Existence check: The adapter node first calls the query interface of the target system to determine whether the data (by unique identifier) ​​already exists in the target system.

[0089] Decision-making and execution:

[0090] If the data already exists, the adapter node calls the target system's update interface to refresh the record using the latest information obtained from the data source.

[0091] If the data does not exist, the adapter node calls the target system's new interface to create the new record.

[0092] For example, in an orchestration `THEN(a, b, c)` that uses the HR system (component a) as the data source and needs to be synchronized to the OA system (component b) and the email system (component c), when a user change event is received, the system will: 1) query the latest data of the user from the HR system; 2) first drive the "OA system synchronization component b" to execute the above "query -> judgment -> update / add" process; 3) then drive the "email system synchronization component c" to execute the same "query -> judgment -> update / add" process.

[0093] Through the above mechanism, this step ensures that any changes that occur in the data source can be synchronized to all relevant target business systems in near real-time, accurately and reliably, while strictly avoiding the conflict of duplicate data creation or old data overwriting new data, perfectly realizing the automation, real-time and high consistency of incremental synchronization.

[0094] Appendix Figure 11 The sequence of events for receiving organization change notifications in S104 and S105 and automatically incrementally synchronizing organization information to other business systems is demonstrated.

[0095] Steps S104 and S105 together achieve real-time, automatic incremental synchronization. This fundamentally changes the inefficient traditional API integration model, which requires callers to constantly poll to detect changes. By adopting an event-driven push model, near real-time data synchronization is achieved, solving the problems of "lack of incremental synchronization mechanism" and "difficulty in guaranteeing data consistency" in the background technology. Without event listeners, real-time performance cannot be achieved; without automatic triggering, automation cannot be achieved.

[0096] Compensation phase:

[0097] Step S106: In response to the incremental synchronization trigger command for a specific data range, execute the synchronization logic arranged in step S101: obtain the organization and user data within the specified range from the data source system and synchronize it to the target system, perform existence verification before writing the data, and perform add or update operations based on the verification results.

[0098] This step provides a fallback mechanism in addition to full manual synchronization (step S103) and incremental automatic synchronization (step S105). It is a manual retry and compensation mechanism for a defined scope. It is specifically designed to address the failure or data loss of the automatic synchronization process (step S105) caused by abnormal situations such as temporary network interruptions, short-term unavailability of the target system, or temporary adjustments to the data structure of the business system interface. It is a key safety net to ensure the eventual consistency and operational reliability of the system.

[0099] The specific process of its triggering and execution is as follows:

[0100] 1. Manual Location and Trigger: When an administrator discovers a data synchronization failure for a specific organization or user through monitoring or a system alarm, the user can manually locate and select the specific organization (or the organization to which the failed user belongs) on the system's management interface. Then, by clicking the "Incremental Synchronization" button for that range, the user can manually issue a synchronization command for that specific data range.

[0101] 2. Recursively Retrieve Data Within a Specified Range: Upon receiving this instruction, the system will, according to the synchronization logic arranged in step S101, recursively retrieve the complete data subtree starting from the selected institution from the data source system (data center). This means that the system not only retrieves the information of the institution itself, but also retrieves all its subordinate sub-institutions and all user information under all these institutions layer by layer according to the hierarchical relationship of the institution (associated through `pid`, `objuid`, etc.).

[0102] 3. Execute the standard intelligent synchronization process: For each piece of institutional and user data acquired within this data range, the system will strictly follow the same core synchronization logic as steps S103 and S105, executing the following for each target system:

[0103] Existence verification: Call the query interface of the target system to determine whether the data (identified by organization ID or user ID) exists.

[0104] Decision and Execution: If the data does not exist in the target system, its new interface is called to create it; if the data already exists in the target system, its update interface is called to refresh it.

[0105] 4. Loop until completion: The above "acquire-verify-synchronize" process will be executed in a loop on the entire data subtree of the selected institution until all data of the institution and all its subordinate sub-institutions and users are synchronized.

[0106] Through this mechanism, step S106 provides the entire synchronization system with robust self-healing capabilities and operational flexibility. It acknowledges the inevitability of anomalies in complex distributed integrated environments and offers a direct, efficient, and controllable recovery path. This enables the system to quickly and accurately restore data consistency after experiencing partial failures, without the need for costly full resynchronization or complex underlying data repair. Therefore, this step complements the aforementioned automatic synchronization process, together forming a complete data synchronization solution that combines real-time performance, automation, high reliability, and strong fault tolerance, significantly improving the overall robustness of the system and representing one of the key inventive designs of this invention.

[0107] This step serves as a "safety net" to ensure the system's eventual consistency and high reliability. It acknowledges that anomalies are inevitable in a distributed environment and provides a robust recovery mechanism. As a supplement and fallback to S105 automatic synchronization, it enhances the overall robustness of the system and is the last effective line of defense against the "difficulty in guaranteeing data consistency" flaw. Without this compensation mechanism, the system might remain in a state of data inconsistency for an extended period after an error, requiring complex manual intervention.

[0108] In summary, the sequence of steps from S101 to S106 constitutes a complete closed loop, from flexible configuration to initialization and construction, and then to normal automated operation and anomaly compensation and recovery. Each step employs targeted technical means to collaboratively address the systemic deficiencies of existing technologies in terms of invasiveness, flexibility, reliability, and incremental synchronization, thereby achieving the invention's objective of real-time, reliable, and bidirectional data synchronization among multiple business systems.

[0109] Example 2

[0110] This system aims to specifically implement the synchronization method described in Embodiment 1 above, achieving separation of configuration, execution, and management through a modular architecture. The system mainly includes a logic engine core module, a non-intrusive adapter module, a dynamic credential management module, and a synchronization execution engine module. Each module is interconnected with the data flow through clear interfaces, together forming a complete data synchronization solution.

[0111] The logic engine core module provides users with an entry point for defining synchronization processes.

[0112] This module contains three core sub-units: a rule parser, a process scheduler, and a visual configurator (see attached diagram). Figure 9 (Logical hierarchy). Appendix Figure 9 The diagram illustrates how the data center notifies this system of changes to organizations or users, and how this system uses a process scheduler to invoke the changes according to a pre-defined logical flow. The rule parser controls the specific execution path of the logical nodes according to EL expressions. The diagram shows how organizations or users are synchronized to various business systems in the execution order of process nodes A, B, C, and D.

[0113] The visual configurator provides a graphical interface, converting drag-and-drop operations into an abstract model of nodes and connections. The rule parser is responsible for compiling and executing EL expressions such as THEN(a, b, c), IF...THEN..., etc., transforming the visual model or directly written expressions into an executable sequence of instructions. The process scheduler coordinates the invocation of subsequent modules at runtime based on this sequence. Its working principle is: receiving configuration input (graphics / expressions) → parsing into an intermediate representation (synchronization blueprint) → scheduling the execution engine to run according to the blueprint steps. This ensures that the synchronization logic is definable, storable, and interpretable.

[0114] This module offers two equivalent interaction methods: a visual graphical orchestration interface for business or implementation personnel, allowing users to intuitively build synchronous flowcharts by dragging and dropping icons and connecting lines; and a rule expression (EL) editing and parsing environment for technical personnel, supporting the direct writing of complex logic such as `THEN(A, B, C)` or containing conditional judgments. Regardless of the method used, the essence is to generate a "synchronous blueprint" that can be persistently stored and interpreted by the system. This module transforms the user's orchestration intent into a machine-recognizable sequence of instructions, thereby defining which business systems serve as data sources or targets, and the order and rules of data flow between various process nodes in the non-intrusive adapter module. This design decouples business logic from execution logic, forming the foundation for the system's flexibility and maintainability.

[0115] The non-intrusive adapter module is the "execution terminal" for the system to conduct actual data interaction with external heterogeneous business systems (such as OA, HR, and video conferencing systems).

[0116] The specific structure and working principle of the non-intrusive adapter module: Each adapter process node is an independently configurable software unit, whose internal structure includes a connector, a rule executor, and a field mapper (corresponding to claim 7 and appendix). Figure 10 (Attached) Figure 10This demonstrates the underlying principles by which different scripting languages ​​(Java, JavaScript, Python, etc.) can be executed in the Java Virtual Machine (JVM). Through different script compilers, all scripting languages ​​are eventually converted into bytecode, which is then interpreted or just-in-time (JIT) compiled and executed by the JVM. Bytecode is the core of Java's cross-platform capabilities and is also the key to the implementation of this system.

[0117] The connector supports multiple protocol templates (HTTP / JDBC / LDAP); the rule executor loads and runs pre-configured interactive scripts (such as SQL and API call parameter templates) for specific business systems; and the field mapper stores and executes the conversion relationship between source and target fields. Its working principle is: based on the input instruction (read / write) → call the corresponding connector and inject rules (such as concatenating SQL or assembling JSON) → execute the protocol call → convert the data format according to the field mapping rules → return the result. This structured configuration encapsulation is key to achieving "non-intrusiveness".

[0118] This module consists of multiple independent process nodes, each dedicated to interfacing with a specific business system. The core of each node lies in its configurable interaction rules, such as: accessing the database via pre-configured SQL scripts; calling RESTful APIs by setting request URLs, parameter templates, and response parsing rules; or communicating with directory services by configuring LDAP filters. This makes each node a plug-and-play "adapter," enabling data reading and writing without modifying any code in the target system, embodying the concept of "non-intrusive" integration. Furthermore, the integrated field mapping unit allows users to easily define the mapping between source system field names and target system field names through configuration (e.g., mapping `departName` to `organName`), thereby decoupling the hard-coded coupling between the caller code and the third-party API data structure, greatly improving the system's adaptability and maintainability in the face of interface changes.

[0119] The dynamic credential management module handles authentication for all external business systems. This module securely and centrally stores access credentials (such as `secretId / secretKey` and API tokens) for each system. Its key innovation lies in its automatic refresh mechanism: when the synchronization execution engine module receives an authentication failure response (such as HTTP 401) due to expired credentials when calling a business system interface, this module automatically intervenes, re-initiating the authentication request using pre-stored root credentials, obtaining and updating a valid token, thus ensuring that the synchronization process is not interrupted due to credential expiration. This automated process completely frees business logic from the tedious and error-prone task of credential management, significantly improving the reliability and automation level of the entire synchronization process.

[0120] The synchronization execution engine module is the "scheduling and execution hub" driving the entire system. It receives various trigger commands from external sources (such as manual full synchronization clicks or scheduled task triggers) or change events transmitted by event listeners. Then, based on the "synchronization blueprint" provided by the logic engine core module, it orderly schedules the corresponding nodes in the non-intrusive adapter module to execute tasks. At critical moments during data write operations, the module's built-in conflict handling unit initiates its workflow: it first instructs the adapter node corresponding to the target system to perform a query operation, checking for existence based on a unique identifier (such as user ID or organization ID). Based on the check result ("exists" or "does not exist"), the unit intelligently decides and calls the target system's add or update interface, strictly adhering to the "update if exists, add if does not exist" strategy. This fundamentally avoids data duplication or erroneous overwriting and is the core mechanism for ensuring strong data consistency across systems.

[0121] Furthermore, to ensure the system's ultimate reliability in complex network environments, an incremental synchronization compensation module is integrated. This module continuously monitors the execution status of synchronization tasks. When a synchronization failure is detected due to network jitter, temporary unavailability of the target system, or other reasons, it automatically records key information about the failed task (such as data range and failure time). Once the system recovers or retry conditions are met (such as after a delay), the module automatically or, with administrator confirmation, re-triggers the corresponding range of synchronization tasks, thus achieving self-healing capabilities for abnormal situations. This module serves as a safety fallback for the automatic synchronization process, working in conjunction with the aforementioned modules to jointly construct a highly available and highly reliable data synchronization system.

[0122] In summary, through the precise division of labor and collaboration among the aforementioned modules, this system transforms the configuration, initialization, automatic synchronization, and compensation recovery methods and steps described in claims 1 to 5 into a stable, easily managed, and highly automated entity. Each module specifically addresses specific pain points in existing technologies (such as intrusiveness, poor flexibility, complex credential management, difficulty in ensuring consistency, and lack of fault tolerance), and through the organic connection between modules, ultimately achieves the inventive objective of real-time, accurate, and reliable user data synchronization among multiple heterogeneous business systems.

[0123] This invention constructs a complete real-time data synchronization solution for multi-business system organizations by introducing a visual orchestration mechanism that combines a core logic engine module with a non-intrusive adapter, along with a conflict handling unit for dynamic credential management and the execution engine. The method and system replace traditional intrusive development with configurable node adaptation, achieving zero-modification integration and flexible topology definition; event-driven and automatic credential refresh ensure the real-time performance and high availability of synchronization tasks; and existence verification and incremental compensation mechanisms guarantee data consistency and ultimate reliability. Ultimately, this solution significantly reduces system integration costs and maintenance difficulty while providing highly flexible and reliable data synchronization capabilities, effectively solving the integration challenge of data silos between heterogeneous systems.

Claims

1. A method for real-time synchronization of user data in a multi-service system based on a non-intrusive adapter, characterized in that, Includes the following steps: Configuration phase: Step S101: Through the core module of the logic engine, multiple non-intrusive adapter process nodes are logically orchestrated in a visual orchestration or rule expression manner, defining at least one data source system, at least one target system, and the synchronous flow of data between them; wherein, each of the non-intrusive adapter process nodes interfaces with a specified business system through pre-configured interaction rules. Step S102: Configure access credentials for the data source system and the target system, and have them securely stored and automatically refreshed by the dynamic credential management module; Synchronous execution phase: Step S103: In response to the full synchronization trigger command, execute the synchronization logic arranged in step S101: obtain all institutional and user data from the data source system, perform existence verification before writing data for each target system, and perform add or update operations based on the verification results. Step S104: Configure and enable event listening to receive notifications of institutional or user data change events from the data source system; Step S105: After the full synchronization in step S103 is completed, automatically respond to the change event listened to in step S104 and execute the synchronization logic arranged in step S101: obtain the details of the changed data and synchronize it to each target system, perform existence verification before writing the data, and perform add or update operations according to the verification results. Compensation phase: Step S106: In response to the incremental synchronization trigger command for a specific data range, execute the synchronization logic arranged in step S101: obtain the institution and user data within the specified range from the data source system and synchronize it to the target system, perform existence verification before writing the data, and perform add or update operations based on the verification results.

2. The method according to claim 1, characterized in that, In step S101, the pre-configured interaction rules include at least one of the following: a structured query language (SQL) script for database queries; a request address, parameters, and response parsing template for calling a RESTful API; Lightweight LDAP filter for directory service queries.

3. The method according to claim 1, characterized in that, In step S101, the visual orchestration supports configuring synchronization nodes and flow through graphical drag-and-drop, and can set at least one of event triggering, timed triggering or manual triggering as the triggering condition for synchronization tasks.

4. The method according to claim 1, characterized in that, In step S102, when the dynamic credential management module detects that the business system interface returns authentication failure information, it automatically uses the pre-configured access credentials to reapply for and refresh the valid token.

5. The method according to claim 1, characterized in that, The existence verification described in steps S103, S105, and S106, and the execution of the add or update operation based on the verification result, specifically include: querying whether the primary key identifier of the data to be synchronized exists based on the interface of the target system; if it does not exist, calling the add interface of the target system; if it exists, calling the update interface of the target system.

6. A real-time synchronization system for organizational user data of a multi-service system based on a non-intrusive adapter for implementing the method of any one of claims 1 to 5, characterized in that, include: The core module of the logic engine is used to provide a visual orchestration interface and parse rule expressions to define and configure nodes and flow in the synchronization process; The non-intrusive adapter module contains multiple process nodes, each corresponding to a business system, and implements data read and write operations with the business system through configurable interaction rules; The dynamic credential management module is used to securely store access credentials for various business systems and provides automatic credential refresh service. The synchronization execution engine module is connected to the logic engine core module, the non-intrusive adapter module, and the dynamic credential management module, respectively. It is used to receive trigger instructions or events, drive the execution of the orchestrated synchronization process, and coordinate the non-intrusive adapter module to complete data synchronization.

7. The system according to claim 6, characterized in that, The non-intrusive adapter module also includes a field mapping unit for configuring the data field name mapping relationship between the source system and the target system; the system also includes an incremental synchronization compensation module for recording the failed task information after a synchronization failure is detected, and re-triggering execution when the conditions are met.

8. The system according to claim 6, characterized in that, The synchronous execution engine module includes a conflict handling unit, which is used to verify the existence of data by calling the target system query interface before executing data writing, and decide whether to call the add or update operation interface based on the verification result.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program is used to control the device to perform the method as described in claim 1.

10. A terminal device, characterized in that, The terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the method as described in claim 1 above.

Images