Multi-source business data processing and linkage analysis method and system for enterprise collaborative office

Abstract

The application discloses a multi-source business data processing and linkage analysis method and system for enterprise collaborative office, and relates to the technical field of multi-source business data processing. The application generates a data association set of the same collaborative office approval matter by performing update time consistency analysis on the collaborative office data, approval node data and user permission data obtained from each collaborative server; determines whether the collaborative office data, approval node data and user permission data belong to the same collaborative approval time sequence synchronization state; returns the target call data to the office collaboration terminal if they belong to the same collaborative approval time sequence synchronization state, and performs approval state collaborative repair processing if they do not belong to the same collaborative approval time sequence synchronization state, and obtains interface call parameters, synchronization polling period parameters and message queue retry parameters; and helps to solve the problem that the existing data call and permission control mode may be inconsistent in time sequence across servers, affecting the accuracy and reliability of multi-source contract approval data linkage processing.

Description

Technical Field

[0001] This invention relates to the field of multi-source business data processing technology, and in particular to a method and system for multi-source business data processing and linkage analysis for enterprise collaborative office work. Background Technology

[0002] As enterprises increasingly adopt digital office practices, collaborative work has gradually become a crucial platform for internal task flow, approval processes, document processing, communication feedback, and project collaboration. In practical applications, daily office work generates a large amount of data related to business matters, such as task milestones, document versions, and process times. This data not only reflects the progress of individual business tasks but also demonstrates the collaborative relationships between different departments, positions, and systems. Therefore, unified processing, correlation analysis, and status identification of multi-source business data in collaborative work processes are of great significance for accurately understanding the flow of tasks, improving cross-system data consistency, and supporting subsequent anomaly identification.

[0003] In enterprise collaborative office work, the office process usually involves multiple stages such as initiation of matters, task assignment, approval flow, document collaboration, communication feedback, result archiving and follow-up. The relevant business data is generated from different data sources such as office platforms, process engines, instant messaging systems, document management systems, project management systems and permission management systems. In the prior art, existing solutions can manage the permissions of business objects, access to business data, parsing of office instructions, and data transmission processes in office collaboration. For example, the data processing method and related equipment disclosed in Chinese invention patent application CN118035963A include: in response to a preset operation triggered by a first user in the office collaboration system, displaying an authorization-related page, which is used to obtain permissions for at least one business object that the first user has permission to access in the business system; in response to successful authorization, obtaining the target data of at least one business object and displaying the target data to the first user in the office collaboration system. For example, a data processing method, system, device, and medium for office scenarios based on a large language model disclosed in Chinese invention patent application CN121881372A includes: determining the corresponding processing unit according to natural language instructions; selecting a target channel from a preset number of transmission channels according to preset triggering conditions, and using the target channel to transmit de-identified and encrypted data to the corresponding processing unit. The system utilizes a processing unit to convert natural language instructions into prompts, inputs the prompts and desensitized encrypted data into a trained large language model to obtain output data, and obtains the output data returned by the processing unit through a target channel. For example, Chinese invention patent application CN111027079A discloses an office document security system comprising: a data processing unit and a cloud server, the data processing unit and the cloud server being interconnected; the data processing unit is equipped with a document conversion module, an information storage module, and an identity authentication module, while the cloud server is equipped with a backup module; users verify their identity through the identity authentication module and verify their usage permissions through the permission verification module; users transmit documents to the data processing unit, which distributes the documents to the document conversion module; the document conversion module encrypts and decrypts the office documents and transmits them to the cloud server, where they are saved in the backup module; the file conversion process is recorded in the information storage module; the cloud server is connected to the user terminal.

[0004] Therefore, in the process of enterprise collaborative office work, the existing methods for processing and linking business data are as follows: First, based on the user's operation request or natural language command in the office collaboration system, determine the business object, business data, or corresponding processing unit that the user needs to access or process; then, through authorization pages, permission verification, trigger condition judgment, or transmission channel selection, obtain the target data in the business system that matches the user's permissions, or transmit the encrypted data to the corresponding data processing unit; subsequently, the office collaboration system displays the obtained target data, or the data processing unit converts the natural language command into prompt words and calls the large language model to generate the corresponding output results; finally, the displayed data or model output data is returned to the office collaboration system so that users can complete data viewing, content generation, business auxiliary processing, or subsequent operations in the collaborative office environment.

[0005] In the process of collaborative office work in enterprises, data access and access control are important technical links to realize the secure interaction, on-demand access and collaborative processing of business data of multiple systems within the enterprise. Especially when conducting collaborative approval of contracts within the enterprise, the office collaboration terminal or server usually needs to call data from various collaborative servers, such as the process approval server, based on the user's operation requests such as viewing, submitting, returning, and supplementing materials triggered on the approval page, and match, combine and display data from different sources.

[0006] However, since each collaborative server typically completes data writing, status updates, cache maintenance, and interface responses independently according to its own data processing logic during actual operation, and data synchronization between different servers is usually not real-time and strongly consistent, but may use methods such as timed synchronization, asynchronous push via message queues, interface polling, or refresh after cache expiration for data transmission, when the status of the same contract approval item changes, the time when the contract master data, approval node data, and user permission data arrive at the office collaboration terminal or intermediate service layer may differ. This may result in situations where the contract master data has been updated but the process node data has not yet been synchronized and refreshed, or the user permission status has changed but the interface cache still returns the original permission range. The reason for these situations is that the existing methods typically involve user authentication, business object permission query, API call, cache retrieval, and page return. When the office collaboration terminal receives a user operation request, it sends the user account identifier, contract number, and operation type to the server. The server then determines whether the user has the necessary access permissions for the corresponding contract object or field based on the user permission data returned by the permission management server. Once the permission verification is successful, it calls the contract master data, approval node data, or attachment data from the workflow approval server, document storage server, and other collaboration servers, and combines and displays the data returned by different APIs according to preset page fields. This method usually focuses on identity verification and object authorization in a single request, lacking joint comparison between contract master data update time, approval node update time, user permission update time, cache generation time, and API return time. Therefore, it is difficult to promptly identify time sequence misalignments, cache lags, and permission range deviations between data returned across servers.

[0007] In conclusion, in enterprise-wide collaborative contract approval scenarios, existing data retrieval and access control methods may result in inconsistent data timing across servers, causing the returned data to mismatch with the current approval status or permission scope, thus affecting the accuracy and reliability of multi-source contract approval data linkage processing. Summary of the Invention

[0008] This invention provides a method for processing and analyzing multi-source business data in collaborative office environments for enterprises.

[0009] To achieve the above-mentioned objectives, the present invention provides the following technical solution: Methods for processing and analyzing multi-source business data in collaborative office environments include: S1. In response to the collaborative office approval call request, retrieve collaborative office data, approval node data, and user permission data from various collaborative servers, perform update time consistency analysis on the collaborative office data, approval node data, and user permission data, and generate a data association set for the same collaborative office approval item; S2. Based on the data association set, perform multi-source call time sequence association analysis to determine whether the collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state; S3. If they belong to the same collaborative approval time sequence synchronization state, generate target call data and return the target call data to the office collaboration terminal; if they do not belong to the same collaborative approval time sequence synchronization state, perform collaborative approval status repair processing on the data source with time sequence deviation, and based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after processing, re-retrieve the corresponding collaborative office data, approval node data, or user permission data from the collaborative server.

[0010] A multi-source business data processing and linkage analysis system for enterprise collaborative office work includes: an update time consistency module, used to respond to collaborative office approval call requests, obtain collaborative office data, approval node data, and user permission data from various collaborative servers, perform update time consistency analysis on collaborative office data, approval node data, and user permission data, and generate a data association set for the same collaborative office approval item; a multi-source call time sequence association analysis module, used to perform multi-source call time sequence association analysis based on the data association set, and determine whether collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state; and an approval time sequence synchronization state determination module, used to generate target call data and return the target call data to the office collaboration terminal if they belong to the same collaborative approval time sequence synchronization state, and perform approval status collaborative repair processing on the data source with time sequence deviations if they do not belong to the same collaborative approval time sequence synchronization state. Based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after processing, the corresponding collaborative office data, approval node data, or user permission data is re-obtained from the collaborative server.

[0011] The above technical solution has at least the following advantages compared with the existing technology: 1. The above solution, in response to collaborative office approval requests, retrieves collaborative office data, approval node data, and user permission data from various collaborative servers. It then performs update time consistency analysis on these data, generating a data association set for the same collaborative office approval item. This helps improve the source consistency and time correlation of multi-source approval data before it enters a combined call, thus preventing the direct mixing of data from different approval items, different update times, or different permission versions. Based on the data association set, it performs multi-source call time sequence correlation analysis to determine whether collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state, which helps strengthen... The system performs time-series linkage verification between contract master data, approval node data, and user permission data. If they belong to the same collaborative approval time-series synchronization state, target call data is generated and returned to the office collaboration terminal. If they do not belong to the same collaborative approval time-series synchronization state, collaborative repair processing of the approval status is performed on the data source with time-series deviation. Based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after processing, the corresponding collaborative office data, approval node data, or user permission data is re-obtained from the collaborative server. This helps to achieve targeted repair and resynchronization of abnormal data sources, thereby improving the consistency between the contract approval data returned to the office collaboration terminal and the current approval status and permission scope.

[0012] 2. The above solution obtains the time deviation of corresponding pairs based on business update time, node update time, and permission update time. It determines whether data from different sources are synchronized within the allowed time window. When the time deviation of each pair is within the corresponding preset qualified synchronization update deviation range, multi-source call time sequence correlation analysis is performed based on the data association set. Otherwise, cache invalidation is triggered. Compared with the shortcomings of existing technologies that directly combine and display pages based on user authentication results, single interface return results, or cached data, and lack judgment on the synchronization relationship between update times of different servers, this solution helps to identify the update time misalignment between contract master data, approval node data, and user permission data before data return. This reduces the problem of inconsistent approval page status caused by process nodes not being refreshed, permission cache lag, or business data being updated but other data not being synchronized.

[0013] 3. The above solution merges the collaborative office data, approval node data, and user permission data corresponding to the preset synchronization analysis time window into the target call data when the business update time, node update time, and permission update time all fall within the preset synchronization analysis time window. Otherwise, it triggers collaborative repair processing of the approval status. Compared with the shortcomings of existing technologies that splice data according to preset page fields after successful interface call, making it difficult to determine whether multi-source data corresponds to the same approval time sequence status, this solution helps to establish a dual time sequence verification mechanism based on interface return time and data update time before the target call data is generated. This ensures that the final returned contract data, approval node, and user permission data are in the same collaborative approval time sequence synchronization state, thereby improving the accuracy and reliability of multi-source approval data linkage display and processing.

[0014] 4. The above solution performs collaborative repair of approval status when multiple terminals concurrently operate on the same approval item. Specifically, when all time deviations are within the corresponding business time deviation range, node update time deviation range, or permission update time deviation range, the update time consistency analysis is re-executed based on the adjusted interface call parameters, synchronous polling cycle parameters, and message queue retry parameters. Compared with the shortcomings of existing technologies that typically only process the interface return results of each terminal's request separately when multiple terminals access concurrently, making it difficult to distinguish between short-term synchronization delays and severe state mismatches, this solution helps to differentiate between retrievable and non-retrievable anomalies in abnormal time data. In the case of minor time sequence deviations, data consistency is restored through interface retry, synchronous polling, or message queue retry. In the case of severe deviations, collaborative anomaly prompts are issued in a timely manner, thereby reducing the risk of returning to the old node status, old permission range, or incorrect approval operation entry in concurrent approval scenarios. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0016] Figure 1 A flowchart illustrating a multi-source business data processing and linkage analysis method for enterprise collaborative office work provided in this application embodiment; Figure 2 This is a schematic diagram of multi-source call timing correlation analysis provided in an embodiment of this application; Figure 3 A schematic diagram of the structure of a multi-source business data processing and linkage analysis system for enterprise collaborative office provided in an embodiment of this application; Figure 4This application provides a diagram illustrating the collaborative processing of multi-source data for collaborative office approvals. Figure 5 This is a diagram of a multi-source data linkage processing architecture provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0018] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms “first,” “second,” and similar terms used in this invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an,” “a,” or “the,” and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms “comprising,” “including,” or “including,” and similar terms mean that the element or object preceding the word encompasses the element or object listed following the word and its equivalents, without excluding other elements or objects. The terms “connected,” “linked,” or “connected,” and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0019] It should be noted that the terms "up", "down", "left", "right", "front", and "back" used in this invention are only used to indicate relative positional relationships. When the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0020] Example 1, such as Figure 1 The flowchart shown is for a multi-source business data processing and linkage analysis method for enterprise collaborative office work provided in this application embodiment. The multi-source business data processing and linkage analysis method for enterprise collaborative office work includes: S1, responding to collaborative office approval requests, retrieves collaborative office data, approval node data, and user permission data from various collaborative servers. It then performs update time consistency analysis on these data to generate a data association set for the same collaborative office approval item. For example, in the scenario of approving supplementary materials for the same contract, after the administrator submits the supplementary materials to the contract approval system via computer, the approver immediately opens the contract approval page on a mobile device to view it. The collaborative office terminal responds to the viewing request for the approval page by retrieving collaborative office data from the business data server, approval node data from the process approval server, and user permission data from the permission management server. By performing consistency analysis on business update time, node update time, and permission update time, it helps to determine whether the above three types of data originate from the same contract approval item and are within the allowed synchronous update time range, avoiding the direct combination of updated contract master data with unsynchronized approval node data or old permission data.

[0021] S2 performs multi-source call timing correlation analysis based on the data association set to determine whether collaborative office data, approval node data, and user permission data belong to the same collaborative approval timing synchronization state. For example, after the person in charge submits supplementary materials, the business data server may have already updated the contract status to "supplementary materials submitted," but the node status of the process approval server and the permission status of the permission management server may have a short delay due to message queue push or cache refresh. Therefore, the system further records the interface return time when the business data server, process approval server, and permission management server return data, and constructs a preset synchronization analysis time window with the latest interface return time as the window benchmark. By determining whether the business update time, node update time, and permission update time all fall within this preset synchronization analysis time window, it helps to identify whether the currently acquired collaborative office data, approval node data, and user permission data belong to the same collaborative approval timing synchronization state, thereby avoiding mismatches between the contract status, node status, and permission scope displayed on the approval page due to inconsistent interface return order or cache lag.

[0022] S3, if the data belongs to the same collaborative approval time synchronization state, generate the target call data and return it to the office collaboration terminal. If the data does not belong to the same collaborative approval time synchronization state, perform collaborative approval status repair processing on the data source with time discrepancies. Based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after processing, re-obtain the corresponding collaborative office data, approval node data, or user permission data from the collaborative server. For example, when the business update time, node update time, and permission update time all fall within the preset synchronization analysis time window, the system will retrieve the contract master data, current approval node data, and... Approval personnel permission data is consolidated into target call data and returned to the approver's mobile device, allowing them to see contract materials and executable operations consistent with the current approval progress. When it is detected that business data has been updated to "supplementary materials submitted," but the node update time returned by the process approval server does not fall within the preset synchronization analysis time window, or the permission management server still returns old field access permissions, the system identifies the corresponding approval node data or user permission data as the data source with time sequence deviation and performs cache invalidation, interface retry, synchronous polling, or message queue retry processing to re-obtain the latest approval node data or user permission data. This helps reduce the situation where approvers see outdated node statuses or page operation buttons that are inconsistent with the current approval stage, improving the accuracy and reliability of multi-source contract approval data linkage processing.

[0023] In this embodiment, there is a progressive relationship between S1-S3. Specifically, S1 obtains collaborative office data, approval node data and user permission data from different collaborative servers by responding to collaborative office approval call requests. It then performs update time consistency analysis on the three types of data, so that data belonging to the same collaborative office approval item and having time correlation conditions are first merged into a data association set, providing a basic data range for subsequent judgment on whether data from different sources can be combined.

[0024] Building upon this, S2 does not independently re-evaluate; instead, it uses the data association set generated by S1 as the analysis object, further performing multi-source call timing correlation analysis on this data association set to determine whether collaborative office data, approval node data, and user permission data are in the same collaborative approval timing synchronization state. Therefore, it can identify whether there are timing misalignments between contract master data, approval node data, and user permission data due to interface return order, cache refresh delays, or server synchronization lags before the data is returned, avoiding the direct display of asynchronous data combinations simply because a single interface call was successful.

[0025] S3 then performs differentiated processing based on the judgment result of S2: when the three types of data belong to the same collaborative approval time synchronization state, it means that the current collaborative office data, approval node data, and user permission data are composable under the same approval item. The system generates target call data accordingly and returns it to the office collaboration terminal; when the three types of data do not belong to the same collaborative approval time synchronization state, it means that at least one data source has a time sequence deviation. The system does not directly return the potentially mismatched data, but performs collaborative approval status repair processing for the data source with time sequence deviation, and re-acquires the corresponding data based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after repair.

[0026] Preferably, in response to the collaborative office approval call request, collaborative office data, approval node data and user permission data are obtained from each collaborative server. The specific process is as follows: receive the collaborative office approval call request sent by the office collaboration terminal, and send the collaborative office approval call request to the corresponding collaborative server to call the collaborative office data, approval node data and user permission data.

[0027] The specific process of calling collaborative office data, approval node data, and user permission data is as follows: retrieve collaborative office data corresponding to the collaborative office approval call request from the business data server; retrieve approval node data corresponding to the collaborative office approval call request from the process approval server; and retrieve user permission data corresponding to the collaborative office approval call request from the permission management server. This helps to extract information such as business objects and user access records from contract approval items.

[0028] Collaboration servers include, but are not limited to, business data servers, workflow approval servers, and access control servers. A business data server is a server used to store, maintain, and respond to business object data corresponding to collaborative office approval items. In a contract collaborative approval scenario, the business data server manages collaborative office data such as contract number, contract version number, contract business object identifier, contract status, contract text, contract attachment identifier, and supplementary material status. A workflow approval server is a server used to maintain workflow instances, approval nodes, and node flow status corresponding to collaborative office approval items. In a contract collaborative approval scenario, the workflow approval server manages workflow instance number, approval node number, node flow sequence number, current handler, node processing status, and node... Approval node data, such as rollback status and node completion status, are managed by the permission management server, which maintains user identity, role permissions, business object access permissions, field access permissions, and operation permissions. In contract collaborative approval scenarios, the permission management server determines a user's permissions to view, edit, submit, roll back, or approve contract data, approval node data, and related fields based on the user account identifier, user role, approval node status, and business object identifier. Collaborative office data includes, but is not limited to, contract number, contract version number, and contract business object identifier. Approval node data includes, but is not limited to, approval node number and node flow sequence number. User permission data includes, but is not limited to, user account identifier, business object access permissions, and field access permissions.

[0029] A consistency analysis of update times for collaborative office data, approval node data, and user permission data is performed. The specific process is as follows: Timers are used to monitor the business update time corresponding to collaborative office data, the node update time corresponding to approval node data, and the permission update time corresponding to user permission data. Business update time represents the time recorded when the status of collaborative office data is refreshed in the corresponding business data server. Node update time represents the time recorded when the status of approval node data changes due to node transfer, node rollback, or node processing in the workflow approval server. Permission update time represents the time recorded when user permission data is added, changed, revoked, or cached for business object access permissions, field access permissions, or operation permissions in the permission management server. Based on the business update time, node update time, and permission update time, the time deviation between each pair of data is obtained. This determines whether data from different sources has been synchronized within the allowed time window. By distinguishing between the three types of update times, it helps avoid judging data usability solely based on interface return results. Instead, it further assesses whether there might be synchronization lag or state misalignment based on the data's own update time. The time deviation between each pair of data includes the time deviation between business update time and node update time, the time deviation between business update time and permission update time, and the time deviation between node update time and permission update time.

[0030] Specifically, the process for determining whether data from different sources has been synchronized within the allowed time window is as follows: When the time deviations of each pair of combinations are within the corresponding preset acceptable synchronization update deviation range, the corresponding data is marked as data with time association conditions and merged into a data association set for the same collaborative office approval item. Multi-source call time sequence association analysis is then performed based on the data association set. When the time deviations of each pair of combinations are not within the corresponding preset acceptable synchronization update deviation range, the collaborative office data, approval node data, or user permission data that exceeds the preset acceptable synchronization update deviation range is marked as data to be synchronized and verified, triggering cache invalidation processing. Specifically, the data to be synchronized and verified is marked as invalid, and the latest data is retrieved from the corresponding collaborative server again.

[0031] By combining the time deviations of business update time, node update time, and permission update time, we can analyze the synchronization relationships between business data and process node data, business data and permission data, and process node data and permission data. In other words, this process doesn't simply determine whether the three types of data are returned simultaneously; instead, it identifies whether the contract master data update has been synchronized with the process node, whether the contract master data update has caused a synchronized change in the permission scope, and whether the approval node change has been synchronously reflected in the user permission data. This allows for more granular detection of cross-server data update asynchrony issues.

[0032] It should be noted that the preset qualified synchronization update deviation range includes the time deviation range between the preset business update time and the node update time, the time deviation range between the preset business update time and the permission update time, and the time deviation range between the preset node update time and the permission update time; these preset ranges are all stored in a pre-set database, which also contains different preset thresholds.

[0033] The following section explains the process of constructing a similar range in the database, using the pre-defined qualified synchronous update deviation range as an example: The process involves acquiring historical collaborative office data, historical approval node data, and historical user permission data corresponding to historical collaborative office approval items, and extracting historical business update time, historical node update time, and historical permission update time from each historical collaborative office approval item. Based on one or more of the following: contract number, process instance number, and user account identifier, the historical business update time, historical node update time, and historical permission update time belonging to the same historical collaborative office approval item are associated to form a historical update time sample group. Based on a preset unified time benchmark, the historical business update time, historical node update time, and historical permission update time in the historical update time sample group are converted into unified timestamps to obtain historical business update timestamps, historical node update timestamps, and historical permission update timestamps. Then, the absolute values ​​of the time differences between the historical business update timestamp and the historical node update timestamp, the historical business update timestamp and the historical permission update timestamp, and the historical node update timestamp and the historical permission update timestamp are calculated respectively to obtain the historical business node time deviation set, the historical business permission time deviation set, and the historical node permission time deviation set.

[0034] Outlier removal and distribution statistics are performed on the historical business node time deviation set, the historical business permission time deviation set, and the historical node permission time deviation set to obtain the corresponding deviation distribution intervals. Outlier removal can be performed using a preset quantile removal method, or historical time deviations exceeding a preset maximum synchronization delay value can be marked as abnormal synchronization samples and removed from the statistical samples. Distribution statistics include calculating one or more of the following: average deviation value, median deviation value, maximum normal deviation value, and preset quantile deviation value.

[0035] Based on this, the time deviation range is determined according to the deviation distribution intervals of the historical business node time deviation set, the historical business permission time deviation set, and the historical node permission time deviation set. Specifically, the preset quantile deviation value in the corresponding historical time deviation set can be used as the upper limit of the corresponding preset qualified synchronization update deviation range, and the zero value or the preset minimum synchronization deviation value can be used as the lower limit of the corresponding preset qualified synchronization update deviation range. The preset quantile deviation value refers to the deviation value selected from the sorted historical time deviation values ​​in the historical time deviation set according to a preset quantile ratio after arranging the historical time deviation values ​​in ascending order. For example, when the preset quantile ratio is the 95th quantile, the preset quantile deviation value represents the boundary deviation value corresponding to no more than 95% of the historical time deviation values ​​in the historical time deviation set. If the 95th quantile deviation value of the time deviation set between historical business update time and node update time is 3 seconds after sorting, it means that in the historical sample, the synchronization deviation between approximately 95% of the business update time and node update time does not exceed 3 seconds. Therefore, 3 seconds can be used as the upper limit of the preset qualified synchronization update deviation range between business update time and node update time.

[0036] The calculation method is illustrated by taking the process of obtaining the time deviation between business update time and node update time as an example: Based on a preset unified time benchmark, the business update time and node update time are converted into unified timestamps respectively to obtain the business update timestamp and the node update timestamp; the preset unified time benchmark represents a pre-defined time reference rule used to uniformly correct and convert the time fields returned by different collaborative servers; the absolute value of the time difference between the business update timestamp and the node update timestamp is calculated to obtain the time deviation of the pairwise combination of business update time and node update time.

[0037] In this embodiment, firstly, a unified multi-source data call is triggered through a collaborative office approval call request, ensuring that business data, approval node data, and user permission data are acquired around the same approval item. Then, by monitoring the update times of the three types of data and calculating the time deviation between pairs, it is determined whether data from different sources has been synchronized within the allowed time window. Next, data meeting the synchronization conditions are grouped into a data association set for the same collaborative office approval item, while data with abnormal deviations are marked as data to be synchronized and verified, triggering cache invalidation and re-acquisition. Thus, before the target call data is generated, the data returned across servers can be screened for time-series consistency and abnormal sources can be handled, avoiding incorrect combinations of updated contract master data, lagging approval node data, and old permission data. This reduces inconsistencies in contract status, node flow status, and the range of user-accessible fields on the approval page, thereby improving the accuracy, reliability, and security of multi-source data linkage calls during enterprise collaborative approval processes.

[0038] Preferably, multi-source call time-series correlation analysis is performed based on the data association set. The specific process is as follows: Using the interface return time of the collaborative office approval call request as the window benchmark, a preset synchronous analysis time window is constructed. The process is as follows: Record the interface return time corresponding to the collaborative server returning collaborative office data, approval node data, and user permission data for the same collaborative office approval item; the interface return time represents the time recorded by the corresponding collaborative server when it returns collaborative office data, approval node data, or user permission data to the office collaboration terminal or intermediate service layer after receiving the collaborative office approval call request; based on the preset unified time benchmark, the return times of each interface are converted into unified timestamps to obtain the collaborative office data interface return timestamp, approval node data interface return timestamp, and user permission data interface return timestamp. The process compares the time sequence of the timestamps returned by the collaborative office data interface, the approval node data interface, and the user permission data interface, selecting the interface return timestamp as the window reference time. This process not only focuses on the update time of the data itself but also on the return time of the data in this call chain. This reflects the order of interface responses from the business data server, the process approval server, and the permission management server under the same approval call request, providing a time reference for subsequent judgment on whether there is out-of-order interface return, cache lag, or synchronization delay in multi-source data. At the same time, the return times of the collaborative office data interface, the approval node data interface, and the user permission data interface can be compared on the same time scale, which can improve the accuracy of the window reference time selection.

[0039] It should be added that the specific process for selecting the interface return timestamp as the window base time is as follows: When there is a unique latest interface return timestamp among the collaborative office data interface return timestamp, approval node data interface return timestamp, and user permission data interface return timestamp, the unique latest interface return timestamp is selected as the window base time. This helps ensure that the synchronous analysis window can cover the latest arriving data in this call. When there are at least two interface return timestamps that are the same, and the same interface return timestamp is not earlier than other interface return timestamps, any one of the same interface return timestamps is selected as the window base time. This helps avoid the inability to determine the base time due to the same timestamp, thereby ensuring that the synchronous analysis process can continue to execute.

[0040] like Figure 2The diagram illustrates a multi-source call timing correlation analysis provided in an embodiment of this invention: An interface return timestamp is selected as the window reference time. Based on this window reference time, a preset time length is extended forward and backward to form a preset synchronization analysis time window. It is then determined whether the business update time, node update time, and permission update time fall within the preset synchronization analysis time window. If all fall within it, the collaborative office data, approval node data, and user permission data corresponding to the preset synchronization analysis time window are merged into the target call data; otherwise, collaborative repair processing of the approval status is triggered.

[0041] Based on the window reference time, a preset time length is extended forward and backward to form a preset synchronization analysis time window. This window uses the interface return time as the central reference, which can take into account the response delay in the data return link and the normal synchronization error between different servers. This allows subsequent judgments to be not limited to a certain absolute time point, but to identify the synchronization status of multi-source data under the same approval item within a reasonable time range. The business update time, node update time, and permission update time are extracted from the data association set, and it is determined whether they belong to the same collaborative approval time sequence synchronization status. The specific process is as follows: When the business update time, node update time, and permission update time all fall within the preset synchronization analysis time window, it is determined that the collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state. The collaborative office data, approval node data, and user permission data corresponding to the preset synchronization analysis time window are merged into the target call data. This reduces the possibility of incorrectly combining data from different approval stages, different update times, or different permission versions, making the contract status, approval node status, and permission range returned to the office collaboration terminal more consistent. The target call data is used to generate an approval display page and operation control information matching the current collaborative office approval item on the office collaboration terminal. This allows the office collaboration terminal to display basic contract information, the current approval node, approval workflow status, accessible field range, and executable operations based on the target call data. This serves as the entry point, controlling operations such as viewing, submitting, returning, supplementing materials, or approving based on user permission data. The same collaborative approval timeline synchronization status refers to the status of collaborative office data, approval node data, and user permission data corresponding to the same collaborative office approval item. Conversely, if at least one of the business update time, node update time, or permission update time does not fall within the preset synchronization analysis time window, it indicates that the corresponding data source may have issues such as status not being refreshed, cache not being invalidated, interface returning old data, or message synchronization lag. Exception handling is required, marking the business update time, node update time, or permission update time that does not fall within the preset synchronization analysis time window as abnormal time data. This determines that the collaborative office data, approval node data, and user permission data do not belong to the same collaborative approval timeline synchronization status, triggering collaborative repair processing of the approval status.

[0042] It should be noted that the preset time length is a threshold stored in the database in advance. Taking the preset time length as an example, the method for obtaining such a threshold in the database is as follows: Obtain the historical business update time, historical node update time, historical permission update time, and historical interface return time corresponding to each collaborative server in the historical collaborative office approval call records; calculate the time difference between the historical business update time, historical node update time, and historical permission update time and the corresponding historical interface return time, respectively, to obtain the historical update time deviation set; count the maximum deviation value, average deviation value, or preset percentile deviation value in the historical update time deviation set, and combine it with the preset safety redundancy time to determine the preset time length; for example, if the preset percentile deviation value in the historical update time deviation set is 30 seconds and the preset safety redundancy time is 10 seconds, then 40 seconds can be determined as the preset time length, and this preset time length is stored in the database; subsequently, when constructing the preset synchronization analysis time window, the window base time is used as the center, extending forward by 40 seconds and backward by 40 seconds to form the corresponding synchronization analysis time window.

[0043] In this embodiment, the aforementioned multi-source call timing correlation analysis process and the aforementioned data association set form a progressive relationship: first, the data association set is used to limit collaborative office data, approval node data, and user permission data to belong to the same collaborative office approval item; then, a window benchmark time is determined based on the interface return time of each collaborative server, and a preset synchronization analysis time window is constructed around this benchmark time; subsequently, the business update time, node update time, and permission update time in the data association set are compared with this window to determine whether the three types of data belong to the same collaborative approval timing synchronization state. Through this continuous processing of same item aggregation, interface return benchmark determination, synchronization window construction, update time window judgment, and target data merging or anomaly repair, timing misalignment and cache lag of cross-server data can be identified before the target call data is returned.

[0044] Preferably, the collaborative repair process for approval status is as follows: The collaborative server corresponding to the abnormal time data is read. Based on the abnormal time data, the corresponding interface call parameters, synchronization polling cycle parameters, and message queue retry parameters of the collaborative server are obtained. Specifically, the abnormal time data is input into the preset server parameter adjustment model of the collaborative server, and the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters are output. Based on the adjusted interface call parameters, synchronization polling cycle parameters, and message queue retry parameters, the corresponding collaborative office data, approval node data, or user permission data is re-obtained from the collaborative server, and the update time consistency analysis is re-executed. The number of times the update time consistency analysis is re-executed cannot exceed the preset maximum number of time consistency executions. If the preset maximum number of time consistency executions is exceeded, and at least one of the business update time, node update time, and permission update time still does not fall within the preset synchronization analysis time window, an update time consistency alarm is sent. The interface call parameters include one or more of the number of interface retries and the interface retry interval. The synchronization polling cycle parameters include one or more of the polling interval duration and the duration of a single polling. The message queue retry parameters include one or more of the number of message retries and the message retry interval.

[0045] This invention provides a model built using existing machine learning models, such as a model with preset server parameter adjustments, which can be constructed based on the random forest regression algorithm. The specific process is as follows: First, acquire historical anomaly time data, historical interface call parameters, historical polling cycle parameters, and historical message queue retry parameters. Then, extract model input features based on the historical anomaly time data. These features include the update time type, collaborative server type, and average interface response time corresponding to the anomaly time data. Update time types include business update time, node update time, and permission update time. Next, determine model output labels for each historical collaborative office approval call record. These labels include one or more of the following: historical interface retry count, historical interface retry interval, historical polling interval duration, historical single polling duration, historical message retry count, and historical message retry interval. Specifically, a set of parameters that restores the corresponding historical anomaly time data to the same collaborative approval time sequence synchronization state within a preset repair time, and whose interface call count or waiting time meets preset resource consumption conditions, can be used as the output labels for that historical sample.

[0046] Subsequently, the model input features and model output labels are combined to form a training sample set, which is then preprocessed. Preprocessing includes normalizing continuous features, encoding discrete features, and removing abnormal samples where the repair results failed and the cause of the failure could not be identified. For discrete features such as server type, update time type, and approval operation type, one-hot encoding or numbered encoding methods can be used; for continuous features such as time deviation, average interface response time, and message queue latency, max-min normalization or standardization methods can be used.

[0047] Next, a random forest regression model is trained using the training sample set. The random forest regression model consists of multiple regression decision trees, each trained based on randomly sampled samples and randomly selected feature subsets from the training sample set. In each regression decision tree, the model input features are used as the splitting criteria, and the interface call parameters, synchronous polling cycle parameters, and message queue retry parameters in the model output labels are used as the prediction targets. The sample nodes are divided layer by layer until the preset tree depth, preset minimum number of leaf node samples, or preset error convergence condition is met.

[0048] After training multiple regression decision trees, the average or weighted average of the interface retries, interface retry intervals, polling intervals, single polling durations, message retries, and message retry intervals output by each regression decision tree for the same input sample is obtained to obtain the comprehensive output of the random forest regression model. For parameters that require integer output, such as the number of interface retries and message retries, the comprehensive output can be rounded; for parameters that need to meet a preset range, such as the interface retry interval, polling interval, and message retry interval, the comprehensive output can be limited to the corresponding preset parameter range.

[0049] Finally, the trained random forest regression model is validated using a validation sample set to determine whether the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters output by the model can restore the abnormal time data to the same collaborative approval time synchronization state within a preset number of repairs. If the validation results meet the preset accuracy conditions or preset repair success rate conditions, the trained random forest regression model is used as the preset server parameters to adjust the model. If not, the number of trees, maximum tree depth, minimum number of leaf node samples, or feature sampling ratio in the random forest are adjusted, and the model is retrained until the preset conditions are met.

[0050] like Figure 3The diagram shows the structure of a multi-source business data processing and linkage analysis system for enterprise collaborative office work provided in an embodiment of this invention. The system includes: an update time consistency module, used to respond to collaborative office approval call requests, obtain collaborative office data, approval node data, and user permission data from various collaborative servers, perform update time consistency analysis on the collaborative office data, approval node data, and user permission data, and generate a data association set for the same collaborative office approval item; a multi-source call time sequence association analysis module, used to perform multi-source call time sequence association analysis based on the data association set, and determine whether the collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state; and an approval time sequence synchronization state determination module, used to generate target call data and return the target call data to the office collaboration terminal if they belong to the same collaborative approval time sequence synchronization state, and to perform approval status collaborative repair processing on the data source with time sequence deviations if they do not belong to the same collaborative approval time sequence synchronization state, based on the interface call parameters, synchronization polling cycle parameters, and message queue retry parameters obtained after processing, and to re-obtain the corresponding collaborative office data, approval node data, or user permission data from the collaborative server.

[0051] In this embodiment, the collaborative repair process for approval status is closely linked to the timing synchronization judgment result: the aforementioned steps first identify abnormal time data and their corresponding data sources through a synchronization analysis time window; this step then determines the collaborative server that needs repair based on the abnormal time data, and generates an adapted interface retry, synchronization polling, and message queue retry strategy by adjusting the model through preset parameters, re-acquiring the corresponding data, and re-performing the update time consistency analysis. Therefore, when collaborative office data, approval node data, or user permission data are found to be not in the same collaborative approval timing synchronization state, it helps avoid directly returning data with timing deviations, and instead improves the consistency, accuracy, and reliability of multi-source approval data through targeted repair and review mechanisms.

[0052] Example 2, based on Example 1, addresses the concurrent operation of the same approval item across multiple terminals. For instance, if the administrator submits supplementary materials via computer while approvers simultaneously view the approval item on a mobile device, or if different approvers view, return, or provide supplementary explanations for the same approval item via different terminals, inconsistencies may arise in the interface return order and server synchronization status between different terminals. This can cause deviations in the order in which business update time, node update time, and permission update time reach the intermediate service layer. Consequently, collaborative office data may be updated, but approval node data or user permission data may remain in the old state. The collaborative approval status repair process further includes: obtaining the time deviation of each abnormal time data relative to the preset synchronization analysis time window boundary based on a timer. The time deviation indicates that the timestamp corresponding to the abnormal time data exceeds... The system presets the time difference within a synchronous analysis time window. When all time deviations fall within the corresponding preset business time deviation range, node update time deviation range, or permission update time deviation range, the abnormal time data is determined to be retrievable and repairable. The system then reads the corresponding collaborative server, interface call parameters, synchronization polling cycle parameters, and message queue retry parameters. Based on the adjusted interface call parameters, synchronization polling cycle parameters, and message queue retry parameters, the system re-obtains the corresponding collaborative office data, approval node data, or user permission data from the collaborative server and re-executes the update time consistency analysis. When a time deviation falls outside the corresponding business time deviation range, node update time deviation range, or permission update time deviation range, the abnormal time data is determined to be non-retrievable and repairable, and an approval status collaboration anomaly alert is sent.

[0053] For example, a preset synchronous analysis time window can be set to 10:00:00 to 10:00:10. In a contract supplementary material approval scenario, the person in charge submits supplementary materials via computer, and the approver views the approval item almost simultaneously via mobile device. The system obtains the following time data: The business update time for collaborative office data is 10:00:05, falling within the preset synchronization analysis time window; the node update time for approval node data is 10:00:12, exceeding the end boundary of the preset synchronization analysis time window by 2 seconds; the permission update time for user permission data is 10:00:08, falling within the preset synchronization analysis time window. Therefore, the node update time of 10:00:12 is marked as abnormal time data, with a time deviation of 2 seconds relative to the boundary of the preset synchronization analysis time window.

[0054] In this embodiment, by introducing the time deviation of abnormal time data relative to the preset synchronization analysis time window boundary in scenarios where multiple terminals concurrently operate on the same approval item, it is possible to further distinguish whether the abnormal data is a recoverable deviation caused by short-term interface return disorder, cache refresh delay, or message queue synchronization lag, or an unrepairable deviation caused by long-term asynchronous approval status, mismatched permission versions, or abnormal server status. When the time deviation falls within the corresponding business time deviation range, node update time deviation range, or permission update time deviation range, it indicates that the anomaly is still within the range that can be repaired by re-calling the interface, adjusting the polling cycle, or retrying the message queue. Therefore, it is determined to be retrievable data and the corresponding data is retrieved again, which helps to restore the consistency of multi-source data without directly interrupting the approval operation. When the time deviation exceeds the corresponding deviation range, it indicates that the anomaly may have exceeded the normal synchronization delay range. If retrieval continues, consistent data may still not be obtained, and it may even return an incorrect approval status or incorrect permission range to the terminal. Therefore, it is determined to be unretrievable data and an approval status collaboration anomaly prompt is sent. Therefore, it is possible to classify and process abnormal data in cases where the return order of interfaces is inconsistent due to concurrency of multiple terminals. This avoids frequent interruptions of the approval process caused by slight synchronization delays and prevents the return of mismatched data under serious timing deviations, thereby improving the stability, accuracy and security of collaborative approval data calls.

[0055] like Figure 4 The diagram shown illustrates the collaborative processing of multi-source data for collaborative office approvals provided in an embodiment of this invention. The outer frame represents the functional platform of the entire system, responsible for multi-source data collection, analysis, synchronization, and anomaly repair. The small blue box, when detecting data timing anomalies or synchronization deviations, re-acquires collaborative office data, approval node data, and user permission data through interface parameter adjustment, synchronization polling, and message queue retry mechanisms. The small green box helps to display the logical boundaries within the module, while the small gray box is used to label and distinguish the overall module and does not undertake actual processing functions. The green box on the left performs correlation analysis on business data, approval node data, and user permission data from different collaborative servers to generate a unified data association set. The green box on the right performs timing analysis of multi-source calls based on the data association set to determine whether each data belongs to the same approval timing synchronization state. The green box at the bottom is triggered when anomalies or asynchrony are detected in the approval data, and the state is repaired by calling parameter adjustment and data re-retrieval. The large box at the bottom provides multi-source data support for the collaborative processing platform.

[0056] like Figure 5The diagram shown is a multi-source data linkage processing architecture provided in an embodiment of the present invention. After the office collaboration terminal initiates an operation request, the system obtains data from servers such as contract master data, process approval, user permissions, and documents / attachments, and performs core processing such as data association set generation, multi-source call time sequence association analysis, and valid approval status judgment.

[0057] The following points need to be explained: (1) The accompanying drawings of the embodiments of the present invention only involve the structures involved in the embodiments of the present invention. Other structures can refer to the general design.

[0058] (2) For clarity, the thickness of layers or regions is enlarged or reduced in the drawings used to describe embodiments of the invention, i.e., these drawings are not drawn to scale. It is understood that when an element such as a layer, film, region or substrate is referred to as being “above” or “below” another element, the element may be “directly” located “above” or “below” the other element or there may be intermediate elements.

[0059] (3) Where there is no conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other to obtain new embodiments.

[0060] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for processing and analyzing multi-source business data in collaborative office environments for enterprises, characterized in that: include: S1, in response to the call request for collaborative office approval, retrieve collaborative office data, approval node data and user permission data from each collaborative server, perform update time consistency analysis on the collaborative office data, approval node data and user permission data, and generate a data association set for the same collaborative office approval item; S2, perform multi-source call time sequence correlation analysis based on the data association set, and determine whether the collaborative office data, approval node data and user permission data belong to the same collaborative approval time sequence synchronization state; S3. If the data belongs to the same collaborative approval time synchronization state, generate the target call data and return the target call data to the office collaboration terminal. If the data does not belong to the same collaborative approval time synchronization state, perform collaborative repair processing on the approval status for the data source with time deviation. Based on the interface call parameters, synchronization polling cycle parameters and message queue retry parameters obtained after processing, re-obtain the corresponding collaborative office data, approval node data or user permission data from the collaborative server.

2. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 1, characterized in that, The specific process for performing update time consistency analysis on the collaborative office data, approval node data, and user permission data is as follows: Monitor the business update time corresponding to collaborative office data, the node update time corresponding to approval node data, and the permission update time corresponding to user permission data; Based on business update time, node update time, and permission update time, the time deviation of each pair of corresponding combinations is obtained to determine whether data from different sources is synchronized within the allowed time window. The time deviations between the pairs include the time deviation between business update time and node update time, the time deviation between business update time and permission update time, and the time deviation between node update time and permission update time.

3. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 2, characterized in that, The specific process for determining whether data from different sources has been synchronized within the allowed time window is as follows: When the time deviations of each pair of combinations are all within the corresponding preset qualified synchronous update deviation range, the corresponding data are marked as data with time correlation conditions and merged into the data correlation set of the same collaborative office approval item. Multi-source call time sequence correlation analysis is performed based on the data correlation set. When there are two pairs of time deviations that are outside the corresponding preset acceptable synchronization update deviation range, the collaborative office data, approval node data or user permission data that exceed the preset acceptable synchronization update deviation range are marked as data to be synchronized and verified, triggering cache invalidation processing. Specifically, the data to be synchronized and verified is marked as invalid, and the latest data is retrieved from the corresponding collaborative server again.

4. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 3, characterized in that, The specific process of performing multi-source call time-series correlation analysis based on data association sets is as follows: Using the API response time of collaborative office approval requests as the window benchmark, a preset synchronous analysis time window is constructed, as follows: Record the interface return time when the collaborative server returns collaborative office data, approval node data, and user permission data for the same collaborative office approval item; Convert the return times of each interface into a unified timestamp to obtain the timestamps returned by the collaborative office data interface, the approval node data interface, and the user permission data interface. Compare the time sequence of the timestamps returned by the collaborative office data interface, the approval node data interface, and the user permission data interface, and select the timestamp returned by the interfaces as the window reference time; Based on the window reference time, the window is extended forward by a preset time length and backward by a preset time length to form a preset synchronous analysis time window; Extract the business update time, node update time, and permission update time from the data association set, and determine whether they belong to the same collaborative approval time synchronization state.

5. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 4, characterized in that, The specific process for determining whether they belong to the same collaborative approval time synchronization state is as follows: When the business update time, node update time, and permission update time all fall within the preset synchronization analysis time window, it is determined that the collaborative office data, approval node data, and user permission data belong to the same collaborative approval time sequence synchronization state, and the collaborative office data, approval node data, and user permission data corresponding to the preset synchronization analysis time window are merged into the target call data. Conversely, business update times, node update times, or permission update times that do not fall within the preset synchronization analysis time window are marked as abnormal time data. It is determined that the collaborative office data, approval node data, and user permission data do not belong to the same collaborative approval time synchronization state, triggering collaborative repair processing of the approval state.

6. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 5, characterized in that, The collaborative repair process for the approval status is specifically as follows: Read the collaborative server corresponding to the abnormal time data, and obtain the interface call parameters, synchronization polling cycle parameters and message queue retry parameters corresponding to the collaborative server based on the abnormal time data. Specifically, input the abnormal time data into the preset server parameter adjustment model of the collaborative server, and output the interface call parameters, synchronization polling cycle parameters and message queue retry parameters. Based on the adjusted interface call parameters, synchronous polling cycle parameters, and message queue retry parameters, the corresponding collaborative office data, approval node data, or user permission data are retrieved from the collaborative server again, and the update time consistency analysis is re-executed. The interface call parameters include one or more of the following: the number of interface retries and the interface retry interval; The synchronous polling cycle parameters include one or more of the polling interval duration and the duration of a single polling session; The message queue retry parameters include one or more of the following: message retries number and message retry interval.

7. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 4, characterized in that, The specific process for selecting the timestamp returned by the interface as the window base time is as follows: When there is a unique latest timestamp among the timestamps returned by the collaborative office data interface, the approval node data interface, and the user permission data interface, the unique latest timestamp is selected as the window base time. When at least two interfaces return the same timestamp, and the timestamp of the same interface is not earlier than the timestamps of other interfaces, any one of the timestamps of the same interface is selected as the window reference time.

8. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 1, characterized in that, In response to collaborative approval requests, collaborative office data, approval node data, and user permission data are retrieved from various collaborative servers. The specific process is as follows: Receive collaborative office approval call requests sent by the office collaboration terminal, and send the collaborative office approval call requests to the corresponding collaborative server to call collaborative office data, approval node data and user permission data; The specific process of accessing collaborative office data, approval node data, and user permission data is as follows: Retrieve collaborative office data corresponding to the collaborative office approval call request from the business data server; Retrieve approval node data corresponding to the collaborative office approval call request from the workflow approval server; Retrieve user permission data corresponding to the collaborative office approval call request from the permission management server; The collaborative server includes, but is not limited to, a business data server, a process approval server, and a permission management server.

9. The method for multi-source business data processing and linkage analysis for enterprise collaborative office work according to claim 5, characterized in that, The collaborative repair process for the approval status also includes: The time deviation of each abnormal time data relative to the boundary of the preset synchronous analysis time window is obtained. The time deviation represents the time difference between the timestamp corresponding to the abnormal time data and the preset synchronous analysis time window. When all time deviations are within the corresponding business time deviation range, node update time deviation range, or permission update time deviation range, the abnormal time data is determined to be retrievable and repairable data. The corresponding collaborative server, interface call parameters, synchronous polling cycle parameters, and message queue retry parameters are read. Based on the adjusted interface call parameters, synchronous polling cycle parameters, and message queue retry parameters, the corresponding collaborative office data, approval node data, or user permission data are retried from the collaborative server, and the update time consistency analysis is re-executed. When the time deviation is outside the corresponding business time deviation range, node update time deviation range, or permission update time deviation range, the abnormal time data is determined to be irretrievable and repairable data, and an approval status collaboration abnormality prompt is sent.

10. A multi-source business data processing and linkage analysis system for enterprise collaborative office work, the system being used to implement the multi-source business data processing and linkage analysis method for enterprise collaborative office work as described in any one of claims 1-9, characterized in that, include: The update time consistency module is used to respond to the call request of collaborative office approval, obtain collaborative office data, approval node data and user permission data from each collaborative server, perform update time consistency analysis on the collaborative office data, approval node data and user permission data, and generate a data association set for the same collaborative office approval item; The multi-source call time sequence correlation analysis module is used to perform multi-source call time sequence correlation analysis based on the data association set, and to determine whether the collaborative office data, approval node data and user permission data belong to the same collaborative approval time sequence synchronization state. The approval time sequence synchronization status determination module is used to generate target call data and return the target call data to the office collaboration terminal if the data belongs to the same collaborative approval time sequence synchronization status. If the data does not belong to the same collaborative approval time sequence synchronization status, the module performs collaborative approval status repair processing on the data source with time sequence deviation. Based on the interface call parameters, synchronization polling cycle parameters and message queue retry parameters obtained after processing, the module re-obtains the corresponding collaborative office data, approval node data or user permission data from the collaborative server.

Images