Document co-processing method and system based on document processing platform architecture

Abstract

The invention discloses a document co-processing method and system based on a document processing platform architecture, and relates to the technical field of real-time collaborative editing.The method comprises the steps that a front end receives a preview request, a preview link is generated according to a file ID and embedded into a WebOffice interface, and a session request containing the ID is triggered; the collaborative management module analyzes the request and then generates a Token, and the front end establishes WebSocket connection through the Token. And the preview service module pre-converts the document into paging data, transmits the paging data to the front end through WebSocket connection, and renders the paging data to generate a state document. And verifying and adding the watermark when the user initiates an editing request. According to the method, the technical problems that a traditional document processing mode is difficult to realize multi-user real-time cooperation and efficient preview, version management is disordered, and safety protection is not in place are solved, and the technical effects of multi-user real-time cooperation and efficient preview, version management standardization, safety protection strengthening and accurate and efficient document processing are achieved.

Description

Technical Field

[0001] This invention relates to the field of real-time collaborative editing technology, and in particular to a document collaborative processing method and system based on a document processing platform architecture. Background Technology

[0002] Document collaboration is crucial in information-based office work, directly impacting office efficiency, version management, and information security. Online preview and real-time collaboration are core requirements. Existing technologies largely rely on plugins for document processing, requiring users to download documents locally for editing before uploading them back to the system. This is effective in single-machine editing scenarios. However, with increasing demands for collaboration efficiency and security, traditional technologies reveal limitations when applied to online collaboration scenarios: they cannot achieve real-time synchronized editing by multiple users, version confusion is easily encountered, and previewing requires loading the entire file and relies on plugins, resulting in incomplete and inaccurate collaborative data. Consequently, they fail to meet the needs for precise document collaboration, efficient previewing, and secure control. Summary of the Invention

[0003] This application provides a document collaborative processing method and system based on a document processing platform architecture, which solves the technical problems of traditional document processing methods, such as difficulty in achieving real-time collaboration and efficient preview among multiple users, as well as chaotic version management and inadequate security protection.

[0004] The first aspect of this application provides a document collaborative processing method based on a document processing platform architecture. The method includes: after receiving a preview request initiated by a user, the front-end generates a preview link based on the file ID in the preview request; embeds the preview link into a WebOffice interface via an iframe, and automatically sends a session request to WebOffice upon triggering the session request, wherein the session request contains the file ID; the collaborative management module receives and parses the session request to obtain the file ID, and generates a token to return to the front-end; the front-end establishes a WebSocket connection using the token; the preview service module initiates a pre-conversion mechanism based on the file ID, pre-converts the document corresponding to the file ID into paginated data, and transmits the AES-encrypted paginated data through the WebSocket connection; the front-end receives and renders the paginated data in real time, generating a rendered document; if the user initiates an editing request, the collaborative management module verifies the user's permissions through a callback interface and adds a watermark to the rendered document.

[0005] A second aspect of this application provides a document collaborative processing system based on a document processing platform architecture, the system comprising: a preview service module, an editing service module, a format processing module, and a collaborative management module.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application achieves efficient online document preview and real-time collaborative processing by multiple users. It receives preview requests from the front end, generates preview links that are embedded in the WebOffice interface, and the collaborative management module parses the session requests to generate a token for the front end to establish a WebSocket connection. The preview service module pre-converts the document into paginated data based on file information and transmits it encrypted. The front end receives the paginated data and renders it in real time, generating a rendered document. During editing, user permissions are verified and a watermark is added. During collaborative editing, user operations are encapsulated and broadcast to collaborators' terminals. Combined with callbacks from external business platforms, user status and new version files are synchronized. This enables efficient online document preview and real-time collaborative processing by multiple users, improving the efficiency, security, and compatibility of collaborative document processing. It meets the needs of government and enterprise offices for precise document control and collaboration, achieving real-time collaboration and efficient preview for multiple users, standardizing version management, strengthening security protection, and fulfilling the technical requirements for precise and efficient document processing. Attached Figure Description

[0007] 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.

[0008] Figure 1 This is a flowchart illustrating the document collaborative processing method based on a document processing platform architecture provided in this application embodiment.

[0009] Figure 2 This is a schematic diagram of the structure of a document collaborative processing system based on a document processing platform architecture provided in this application embodiment.

[0010] Figure labeling: Collaborative Management Module 1, Preview Service Module 2, Editing Service Module 3, Formatting Processing Module 4. Detailed Implementation

[0011] This application provides a document collaborative processing method and system based on a document processing platform architecture, which solves the technical problems of traditional document processing methods, such as difficulty in achieving real-time collaboration and efficient preview among multiple users, as well as chaotic version management and inadequate security protection.

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0014] Example 1, as Figure 1 As shown, a document collaborative processing method based on a document processing platform architecture includes: After receiving a preview request from a user, the front end generates a preview link based on the file ID in the preview request.

[0015] In this embodiment, the file ID is a string or code used to uniquely identify a specific file in the document processing platform, which facilitates the system to locate and operate the corresponding file.

[0016] Specifically, the front-end continuously monitors user actions on the platform interface through front-end interaction components integrated into the document processing platform. When it captures a document preview command triggered by the user, such as clicking the preview button or selecting a preview option, it receives the document preview request initiated by the user.

[0017] Next, the front end calls the preset request parameter parsing algorithm to perform structured parsing on the received preview request data packet, and extracts the file ID used to uniquely identify the document to be previewed from the request header field or request body data of the data packet.

[0018] Finally, based on the pre-configured preview service basic access address of the document processing platform, the front end uses the extracted file ID as a path parameter or query parameter and concatenates it with the preview service basic access address according to the fixed link concatenation rule of "basic access address + file ID" to generate a preview link that can be directed to the document resource to be previewed.

[0019] The preview link is embedded in the WebOffice interface via an iframe, and WebOffice automatically sends a session request upon triggering the session request, wherein the session request contains the file ID.

[0020] In this embodiment, an iframe is an embedded element in HTML that can load and display the content of another independent page within the current web page, achieving nested content display. WebOffice is an online office editing tool developed based on web technology, providing document creation and editing functions similar to local office software, while also supporting multi-user collaborative operation.

[0021] Optionally, the front-end first uses a DOM lookup method to locate the DOM node that will hold the preview content within the preset container area of ​​the WebOffice interface. Next, the front-end calls the DOM element creation interface to generate an iframe element and assigns the preview link generated in the previous steps to the iframe element's src attribute. Then, the front-end uses a DOM node insertion method to embed the iframe element with the configured src attribute into the located WebOffice interface container DOM node, completing the embedding of the preview link within the WebOffice interface.

[0022] Next, after the iframe is embedded, the WebOffice interface loads the preview link resource within the iframe. WebOffice's built-in session initialization trigger mechanism is automatically activated. This mechanism first parses the file ID information carried by the preview link in the iframe, retrieving the file ID from the path or query parameters of the preview link. Then, WebOffice encapsulates the obtained file ID into a session request data packet according to a preset session request data format. Finally, WebOffice sends the session request containing the file ID to the backend collaboration management module 1 using either HTTP or HTTPS protocol.

[0023] After receiving and parsing the session request to obtain the file ID, the collaborative management module 1 generates a token and returns it to the front end.

[0024] In this embodiment, the collaborative management module 1 is the core backend module of the document processing platform. It is mainly responsible for receiving session requests sent by the frontend, parsing file IDs, generating authentication tokens, and managing collaborative session-related logic. The token is a temporary credential used for identity authentication and permission verification during frontend-backend interaction. It is generated by the backend module and returned to the frontend for use by the frontend when establishing connections or accessing resources.

[0025] In one embodiment of this application, the collaborative management module 1 continuously listens for session requests sent by the front end through a preset HTTP interface listening mechanism. When request data matching the interface path configuration within the module is detected, the collaborative management module 1 calls the request receiving component to obtain the complete session request data packet from the network transmission channel. Then, a JSON data parsing tool is invoked to perform structured processing on the obtained session request data packet. The tool parses the field information in the data packet layer by layer according to the format specifications of the request data, reads the specific field used to store document identifiers in the request body, and extracts the file ID corresponding to that field.

[0026] Next, the collaboration management module 1 calls the JWT token generation tool, using the extracted file ID as core data, and combines it with the pre-configured encryption key and token validity period parameters. The tool performs signature encryption on the combined dataset according to the JWT encryption algorithm, generating a token containing the file ID information and a timestamp. Then, it calls the HTTP response building tool to write the generated token into a pre-formatted response body and sets the response status code to 200 to indicate successful request processing. Subsequently, the collaboration management module 1 sends the encapsulated response data to the front end via the original request channel through the network transmission component, completing the token return to the front end.

[0027] The front end establishes a WebSocket connection using the Token.

[0028] In this embodiment, WebSocket connection is a network connection technology that supports bidirectional real-time data transmission between the front-end and back-end. Once established, it can continuously exchange data without frequently re-initiating requests.

[0029] Specifically, the frontend first calls the response data parsing function to process the response data containing the token returned by the collaborative management module 1. This function reads the specified field storing the token from the response body according to a preset data format specification, extracting the token value used for authentication from the response data. Then, based on the base access address of the document processing platform's backend WebSocket service, it uses string concatenation to append the extracted token as a query parameter to the base access address. Through these operations, a complete WebSocket connection address containing token authentication information is constructed, ensuring that the connection request can carry authentication data. Subsequently, the frontend calls the browser's built-in WebSocket constructor, passing the constructed WebSocket connection address containing the token as a parameter. After the constructor executes, a WebSocket instance is initialized, initiating the connection establishment process with the backend WebSocket service.

[0030] Next, after the WebSocket instance initialization is complete, a connection handshake request is automatically sent to the backend WebSocket service, carrying connection address information including a token. The backend's collaborative management module 1 verifies the token in the request, and returns a connection confirmation response upon successful verification. The frontend listens for the WebSocket instance's onopen event; when this event is detected, it confirms that the WebSocket connection has been successfully established, forming a channel for real-time data transmission between the frontend and backend.

[0031] Preview service module 2 initiates a pre-conversion mechanism based on the file ID, pre-converts the document corresponding to the file ID into pagination data, and then transmits the AES-encrypted pagination data through the WebSocket connection.

[0032] In this embodiment, the preview service module 2 is a module in the document processing platform responsible for file preview processing. It can parse document attributes based on the file ID, generate scheduling instructions, perform differentiated conversion to obtain pagination data, and transmit the data in an encrypted manner.

[0033] Specifically, the file extension is first parsed using the file ID to obtain the document format attribute. Then, the usage frequency count and last upload timestamp in the file metadata are queried based on the file ID. These two pieces of information are combined to generate a distributed task scheduling instruction. Finally, based on this instruction, the document format attribute is matched to perform differential conversion on the document corresponding to the file ID to obtain paginated data. Subsequently, the paginated data is encrypted with AES and transmitted via a WebSocket connection.

[0034] The front end receives and renders the pagination data in real time, generating a rendering status document.

[0035] Specifically, the front-end first listens for the message event of the WebSocket connection to continuously capture the encrypted pagination data transmitted by the back-end preview service module 2. When new data transmission is detected, the front-end calls the preset AES-GCM decryption tool, inputs the pre-configured decryption key and the initialization vector and authentication tag carried in the data, and performs decryption operations on the encrypted pagination data to obtain the original pagination data, providing a usable data foundation for subsequent rendering operations.

[0036] Next, the decrypted raw pagination data is processed. According to the pagination data format agreed upon by the backend, the page number, SVG or Canvas format data of the content data, and page size parameters corresponding to each page are extracted. This information is then categorized by page number and stored in the local data cache of the frontend to ensure orderly management of pagination data and facilitate sequential rendering.

[0037] Then, differentiated rendering operations are performed based on the format type of the paginated data: SVG or Canvas. If the data is in SVG format, the front end generates an SVG element using DOM creation methods, assigns the SVG content data to the element's innerHTML property, and inserts the SVG element into the specified position in the preview container of the WebOffice interface. If the data is in Canvas format, the front end first obtains the Canvas element in the preview container, calls the getContext method to obtain the 2D drawing context, and renders the paginated data in Canvas format into the Canvas element using the drawImage method or related pixel drawing methods of the drawing context, thus achieving a visual presentation of the single-page content.

[0038] As paginated data is continuously received and rendered, the front-end records the page number and quantity rendered in real time. Once all paginated data has been rendered, the front-end integrates all rendered page elements into a unified hierarchy within the WebOffice preview container, forming a complete document visualization interface. Simultaneously, the front-end updates the locally stored document rendering status flag, marking the document as fully rendered, ultimately generating a rendered document that can be viewed by the user.

[0039] If a user initiates an editing request, the collaborative management module 1 verifies the user's permissions through a callback interface and adds a watermark to the rendered document.

[0040] Specifically, the front-end captures user-triggered editing operations through a UI interaction listening mechanism, obtaining the current user's identity and the file ID of the document to be edited. This information is then encapsulated into editing request data and sent to the collaborative management module 1 via an established communication channel, triggering subsequent permission verification. Upon receiving the editing request data, the collaborative management module 1 calls a pre-defined callback interface, which establishes a connection with the system's user permission management database. The module passes the user's identity and file ID as query parameters to the callback interface. The interface extracts the user's corresponding role permission information and the file's editing permission configuration rules from the permission database and returns this information to the collaborative management module 1. The collaborative management module 1 then compares the user's role permissions with the file's editing permission rules using permission matching logic. If a match is found, the user is deemed to have editing permissions; otherwise, an insufficient permission message is returned.

[0041] Once user permissions are verified, the collaborative management module 1 obtains basic parameters such as page size and content hierarchy of the rendered document and generates watermark data according to the system's preset watermark rules. The module then calls the document watermark embedding tool to overlay the watermark data onto each page of the rendered document's content hierarchy according to preset rules, ensuring that the watermark does not obscure the core content and cannot be easily removed. This completes the watermark addition operation, providing a document foundation with a secure watermark for subsequent editing operations.

[0042] Furthermore, the method provided in this application embodiment includes: After parsing the file extension based on the file ID, the document format attributes are parsed based on the file extension. The usage frequency count and last upload timestamp in the file metadata are queried based on the file ID. A distributed task scheduling instruction is generated based on the usage frequency count and last upload timestamp. The distributed task scheduling instruction is used as the execution basis to perform differential conversion of the document corresponding to the file ID based on the document format attributes, thereby obtaining the pagination data.

[0043] Optionally, the preview service module 2 first calls a string splitting method to process the file ID. The file ID is typically stored in the format "filename.extension_unique identifier". By splitting the string using "." and "_" as delimiters, the file extension is extracted. Then, a format attribute mapping tool is called. This tool has a built-in hash table where the extension is the key and format attributes are the values. For example, docx corresponds to text, xlsx to tables, and pptx to presentations. After matching the extension, the tool outputs the document's format type, whether it contains mixed text and images, and whether it has special formulas, among other format attributes.

[0044] Next, a connection is made to the file metadata storage database via a JDBC interface. The metadata table is indexed using the file ID as the primary key. Preview Service Module 2 constructs the corresponding SQL query statement, passing the target file ID as a parameter to execute the query. The database quickly locates the corresponding data row using the index and returns the queried usage frequency count and the last upload timestamp to Preview Service Module 2, where the frequency count represents the cumulative number of previews / edits.

[0045] Next, the frequency count is converted into a weight value of 0 to 1 according to the interval, with higher usage frequency resulting in a larger weight value. Then, the difference between the current system time and the last upload timestamp is converted into a time weight of 0 to 1, with smaller time differences resulting in a larger weight value. The score is calculated using the formula: Priority Score = Usage Frequency Weight × 0.6 + Time Weight × 0.4. Based on the score, a distributed task scheduling instruction is generated. This instruction includes the file ID, format attributes, priority level, and conversion task identifier, and is encapsulated in JSON format before being pushed to the distributed task queue.

[0046] Finally, based on the distributed task scheduling instructions, if the document format is text or a presentation document, the SVG conversion engine is called to generate pagination data; if it is a table or PDF, the Canvas conversion engine is called to generate pagination data. After generating the pagination data, it is first encrypted using AES-GCM, and then the encrypted pagination data is transmitted paginated via a WebSocket connection, prioritizing the transmission of the first N pages of pagination data, where N≥3.

[0047] By employing methods such as string processing, database queries, and priority algorithms, document information is accurately parsed and reasonable scheduling instructions are generated, achieving the effect of prioritizing the processing of frequently accessed and recently accessed documents and ensuring the efficient generation of preview data.

[0048] Furthermore, the method provided in this application embodiment includes: If the document format attribute is text or a presentation document, the SVG conversion engine is invoked to generate the pagination data; if the document format attribute is a table or PDF, the Canvas conversion engine is invoked to generate the pagination data; after AES-GCM encryption is performed on the generated pagination data, the encrypted pagination data is transmitted paginated through the WebSocket connection, wherein the first N pages of the pagination data are transmitted first, where N≥3.

[0049] In this embodiment, the SVG conversion engine is a tool or component used to convert text, styles, and graphic elements of text, presentation documents, etc., into Scalable Vector Graphics (SVG) format to support document preview and collaborative processing. The Canvas conversion engine is a tool or component used to read data, layout, and charts from documents such as tables and PDFs, and generate Canvas format paginated data through pixel-level rendering to support document preview and collaborative processing.

[0050] Specifically, the preview service module 2 first calls a JSON parsing tool to process the distributed task scheduling instruction, extracting core information such as file ID, document format attributes, and priority level from the instruction. This clarifies the specific object and conversion parameters of the document to be converted, providing an accurate basis for subsequent differentiated conversion operations and preventing the conversion process from deviating from the task requirements.

[0051] Next, the parsed document format attributes are matched using conditional judgment logic. When the document format attribute is identified as text-based (e.g., docx, doc) or presentation-based (e.g., pptx, ppt), the preview service module 2 calls the SVG conversion engine. This engine reads the document's text content, layout style, and graphic elements, splits the document into pages, and generates corresponding SVG vector graphics files for each page, thus forming pagination data. When the document format attribute is identified as table-based (e.g., xlsx, xls) or PDF, the preview service module 2 calls the Canvas conversion engine. This engine first renders each page of the document as a pixel image and compresses it, then generates Canvas format files according to the page order to obtain pagination data, ensuring that the pagination data of different document formats is adapted to the processing characteristics of the corresponding engine.

[0052] Then, the AES-GCM encryption tool is invoked to obtain the preset AES encryption key. The paginated data is split into independent data blocks by page, a random initialization vector is generated for each data block, and the data block is encrypted in combination with the key. At the same time, an authentication tag for verifying data integrity is calculated and generated. After the AES-GCM encryption of all data blocks is completed, the paginated data in the encrypted state is obtained to prevent theft or tampering during data transmission.

[0053] Finally, the preview service module 2 sorts the encrypted pagination data according to page order, marks the first N pages of data as high priority (N≥3), and transmits the first N pages of encrypted pagination data to the front end in sequence through the established WebSocket connection. After the first N pages are transmitted, the remaining pages are transmitted in order, ensuring that the front end can quickly load and render the first few pages of the document, thus improving the user preview experience.

[0054] By parsing scheduling instructions to clarify the conversion basis, calling the corresponding engine to generate pagination data according to format attributes, encrypting data to ensure data security, and prioritizing the transmission of the first N pages to optimize the loading experience, the system achieves the effect of efficiently generating secure pagination data to adapt to different document formats and improving front-end preview efficiency.

[0055] Furthermore, the method provided in this application embodiment includes: After the user enters the editing mode, the editing service module 3 reuses the WebSocket connection, encapsulates the user operation into an atomic operation, and broadcasts it to multiple collaborator terminals through the WebSocket connection; after receiving the atomic operation, the multiple collaborator terminals render and update the document content in real time.

[0056] In this embodiment, the editing service module 3 is a service component that supports document editing scenarios. It is mainly responsible for handling user editing operations, managing collaborative editing logic, and ensuring the stability of the editing process and data synchronization.

[0057] Specifically, when a user triggers the edit mode switch operation, the front end sends an edit mode entry notification to the edit service module 3. The edit service module 3 calls the WebSocket connection status detection method to check the readyState property of the previously established WebSocket instance. Confirming that the connection is in a normal open state, there's no need to create a new connection; the existing WebSocket connection is reused as the transmission channel for subsequent operations, reducing network connection establishment overhead and latency. Next, a user operation monitoring mechanism is activated to capture the user's editing behavior in the WebOffice interface in real time, including text input, deletion, and formatting adjustments. For each editing operation, the module calls the operation structure processing method to extract the core information of the operation, including the event type (e.g., input event, deletion event); the operation location (e.g., line number, column number within the document); the operation content (e.g., the input text or deletion range); and the operation timestamp. This information is combined into JSON structured data according to a preset format, forming a parsable atomic operation data packet, ensuring the completeness and standardization of the operation information.

[0058] Subsequently, the editing service module 3 retrieves the list of collaborating terminals corresponding to the current document from the collaboration management module 1. This list records the identifier information of all terminals that have passed permission verification and joined the editing of the current document. The editing service module 3 calls the terminal traversal sending method to read each collaborating terminal identifier in the list in turn, and calls the send method through a reused WebSocket connection to send the encapsulated atomic operation data packets one by one to each collaborating terminal, ensuring that each terminal participating in collaborative editing can receive the latest editing operation information.

[0059] Finally, each collaborating terminal uses the WebSocket connection's message event listening function to capture the atomic operation data packets sent by the editing service module 3 in real time. The terminal calls a JSON parsing method to parse the data packets, extracting key information such as event type, operation location, and operation content, and executes the corresponding document update logic based on the event type. For example, if it's an input event, the DOM node manipulation method is called to insert the corresponding content at the parsed row and column positions; if it's a deletion event, the content within the specified range is removed at the specified location, completing the real-time update of the local document content and ensuring that the document content displayed on each collaborating terminal is consistent with the operation initiating terminal.

[0060] By reusing WebSocket connections to reduce network overhead, encapsulating atomic operations to ensure information standardization, and broadcasting operations to trigger real-time rendering, the system achieves the effects of improving the response speed of multi-user collaborative editing and ensuring real-time synchronization and consistency of document content across terminals.

[0061] Furthermore, the method provided in this application embodiment includes: After generating user behavior events based on atomic operation increments, the collaborative management module 1 pushes user status change notifications generated based on the user behavior events to the external business platform through a callback interface. The external business platform and the document processing platform have an API integration relationship.

[0062] Specifically, the collaborative management module 1 first receives atomic operation data packets transmitted in real time from the editing service module 3 through a preset message subscription mechanism. This module extracts key information from the atomic operations, such as user identification, operation type (e.g., text input, deletion, formatting), the corresponding document ID, and the operation timestamp. Following the system's preset user behavior event field specifications (e.g., event ID, user ID, document ID, operation type, timestamp), the extracted information is combined into structured data, incrementally generating unique user behavior events. This avoids duplicate recording of already processed operations, ensuring a one-to-one correspondence between events and atomic operations and that the information is complete.

[0063] Next, the collaborative management module 1 parses the incrementally generated user behavior events and maps them to corresponding user status changes based on the operation type. For example, text input is mapped to the "user is editing" status, and deletion is mapped to the "user is modifying content" status. Combining the pre-agreed API data format between the external business platform and the document processing platform (due to their API integration, the format needs to be adapted in advance), the parsed user status change information, along with core data such as user ID, document ID, and timestamp, is encapsulated into a user status change notification data packet that conforms to the external platform's interface requirements. JSON format is typically used to ensure the data can be correctly parsed by the external platform.

[0064] Next, the collaboration management module 1 sends a lightweight test request to the callback interface of the external business platform, confirming the interface's availability based on the returned HTTP status code. Then, the module uses an HTTP POST request method, including pre-configured API authentication information such as an API key or token in the request header to pass the external platform's identity verification. It then sends the encapsulated user status change notification data packet as the request body to the external business platform's callback interface, completing the notification push. After the push, the module records the push time and the interface's return result for subsequent anomaly troubleshooting.

[0065] By receiving atomic operations through message subscription, incrementally generating structured user behavior events, encapsulating notifications according to API integration specifications, and calling callback interfaces to push notifications, the system achieves the effect of enabling external business platforms to synchronize user status changes during document collaborative processing in real time and ensuring cross-platform data consistency.

[0066] Furthermore, the method provided in this application embodiment includes: After the user finishes editing and generates a new version file, the collaborative management module 1 calls back the save interface of the external business platform to transmit the file stream of the new version file.

[0067] In one embodiment, when a user triggers an editing completion operation in the WebOffice interface, the editing service module 3 detects the operation, generates a new version file and associates it with the corresponding file ID, and simultaneously sends an editing completion notification containing the file ID to the collaboration management module 1. Upon receiving the notification, the collaboration management module 1 calls the file storage service interface associated with the document processing platform, passing the file ID as a query parameter. The file storage service locates the storage path of the new version file based on the file ID, reads the file's binary data to form a file stream, and returns the file stream to the collaboration management module 1, enabling the module to obtain the new version file stream to be transmitted.

[0068] Next, the collaborative management module 1 calls the interface testing tool to send an HTTP HEAD request to the storage interface of the external business platform. The request carries the API authentication information preset during API integration. The availability of the storage interface is determined by the received HTTP response status code. If the status code is 200, the interface is normal. At the same time, the validity of the authentication information is verified to ensure that subsequent requests can pass the external platform's identity verification. If the interface is unavailable or authentication fails, the module triggers a retry mechanism, checking again at preset intervals until the interface is available or the retry limit is reached, to avoid transmission failure due to temporary faults.

[0069] The collaborative management module 1 then divides the new version file stream into multiple file blocks of a fixed size, marking each file block with a sequence number and the total number of blocks. The module constructs an HTTP POST request, carrying valid API authentication information, and sends each file block sequentially as part of the request body to the external business platform's storage interface. After sending each file block, it waits for a confirmation response from the external platform before sending the next file block, continuing until all file blocks have been transmitted, ensuring the integrity of the file stream.

[0070] Once the external business platform receives all file blocks, it reassembles them into a complete new version file according to their sequence numbers and saves it. It then returns a success response containing a save identifier and timestamp to the collaborative management module 1. Upon receiving the response, the collaborative management module 1 calls the logging method to store information such as the file ID, external save identifier, transmission time, and response result into the system log database for subsequent status queries and anomaly tracing. If no acknowledgment response is received for an extended period, the module determines that a transmission anomaly and only resends the unacknowledged file blocks, reducing resource consumption from repeated transmissions.

[0071] By acquiring file streams, detecting interface status, transmitting file streams in chunks, and recording transmission results, the system effectively ensures the reliable transmission of new version file streams to external business platforms, achieves data synchronization between the document processing platform and external platforms, and guarantees file storage consistency.

[0072] Furthermore, the method provided in this application embodiment includes: The format processing module 4 obtains the new version file; the format processing module 4 converts the new version file from DOCX format to PDF format by performing an overwrite document format conversion operation; the format processing module 4 adds anti-leakage watermarks to the new version file in batches by performing a watermark addition operation; wherein, the overwrite document format conversion operation and the watermark addition operation are performed independently and in parallel.

[0073] In this embodiment, the format processing module 4 is a component responsible for document format conversion, verification, adaptation and other operations, ensuring that the document is compliant in format and can be used normally in different scenarios or platforms.

[0074] Optionally, the format processing module 4 first calls the file storage service interface of the document processing platform, passing in the unique file ID corresponding to the new version file as a query parameter. The file storage service retrieves the file storage path based on the file ID, reads the file's binary stream data, and returns the binary stream to the format processing module 4 in real time through the interface. The format processing module 4 calls the local temporary storage method to write the received binary stream to a preset temporary directory, generating a directly readable local file copy, providing a stable file data source for the subsequent two operations.

[0075] Next, a DOCX to PDF converter based on the POI component and the OpenPDF library is invoked, passing the path to the new DOCX file in the local temporary directory as input. This tool first parses the XML structure of the DOCX file, extracting text content, paragraph styles, table layouts, and image resources. Then, following PDF page rendering rules, it converts the parsed information page by page into PDF page elements while preserving the original document's formatting and font styles. After conversion, the tool saves the generated PDF file to the specified output directory, completing the document format conversion and generating a PDF version associated with the original DOCX file.

[0076] Then, the format processing module 4 calls the Apache PDFBox and Docx4j tools. The former is for PDF files that need to be processed synchronously later, while the latter is for the original DOCX files. Pre-configured anti-leakage watermark parameters include watermark text, font size, transparency, rotation angle, and page distribution density. The tools read the new version of the DOCX file from the local temporary directory, iterate through each page of the file, and overlay watermark elements on the page background layer according to preset parameters. This ensures that the watermark does not obscure the main text and is embedded in the document's underlying layer, making it difficult to delete. This completes the batch watermarking operation for all pages of the new version file.

[0077] The format processing module 4 then employs Java's ExecutorService thread pool framework, initializing a thread pool containing two core threads. The document format conversion operation is encapsulated as a first Runnable task, and the watermark addition operation as a second Runnable task. Both tasks are submitted simultaneously using the thread pool's submit method. The thread pool automatically allocates two independent threads to execute the first and second tasks respectively. Each task reads a local temporary file copy for processing, operating independently and without blocking, thus achieving parallel execution of the document format conversion and watermark addition operations and avoiding time consumption caused by sequential execution.

[0078] By calling the interface to obtain the file, using professional tools to perform format conversion and watermark addition, and leveraging the thread pool to achieve parallel operation, the system achieves the effect of completing the new version file format conversion and anti-leakage protection while shortening the processing time, thus balancing document processing efficiency and data security.

[0079] In summary, the document collaborative processing method based on a document processing platform architecture provided in this application has the following technical effects: This application utilizes a document processing platform's preview service to pre-convert documents into encrypted paginated data based on file IDs, transmits this data via WebSocket, performs authentication and token generation in the collaborative management module 1, pushes status notifications, reuses connection broadcast atomic operations in the editing service, and performs parallel format conversion and watermarking in the format processing module 4. By coordinating and adjusting the various modules, it accurately achieves document preview, collaborative editing, and secure processing, making document collaborative processing precise and efficient, ensuring data security and cross-platform synchronization, achieving real-time collaboration and efficient previewing for multiple users, standardizing version management, strengthening security protection, and meeting the technical requirements for precise and efficient document processing.

[0080] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a document collaborative processing system based on a document processing platform architecture, the system comprising: Preview Service Module 2, Editing Service Module 3, Format Processing Module 4, and Collaborative Management Module 1.

[0081] The document collaborative processing system based on the document processing platform architecture provided in the embodiments of the present invention can execute the document collaborative processing method based on the document processing platform architecture provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0082] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0083] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A document collaborative processing method based on a document processing platform architecture, characterized in that, The method includes: After receiving a preview request from a user, the front end generates a preview link based on the file ID in the preview request; The preview link is embedded in the WebOffice interface via an iframe, and WebOffice automatically sends a session request upon triggering the session request, wherein the session request contains the file ID; After receiving and parsing the session request to obtain the file ID, the collaborative management module generates a token and returns it to the front end; The front end establishes a WebSocket connection using the Token; The preview service module initiates a pre-conversion mechanism based on the file ID, pre-converts the document corresponding to the file ID into pagination data, and then transmits the AES-encrypted pagination data through the WebSocket connection. The front end receives and renders the pagination data in real time, generating a rendering status document; If a user initiates an editing request, the collaborative management module verifies the user's permissions through a callback interface and adds a watermark to the rendered document.

2. The document collaborative processing method based on a document processing platform architecture as described in claim 1, characterized in that, The preview service module initiates a pre-conversion mechanism based on the file ID, pre-converts the document corresponding to the file ID into pagination data, and then transmits the AES-encrypted pagination data through the WebSocket connection. The method includes: After parsing the file extension based on the file ID, the document format attributes are then parsed based on the file extension. Based on the file ID, query the usage frequency count and last upload timestamp in the file metadata; A distributed task scheduling instruction is generated based on the usage frequency count and the last upload timestamp. Based on the distributed task scheduling instruction, the document ID corresponding to the document is converted according to the document format attribute to obtain the pagination data.

3. The document collaborative processing method based on a document processing platform architecture as described in claim 2, characterized in that, The method includes performing a differential conversion on the document corresponding to the file ID based on the document format attributes to obtain the pagination data. If the document format attribute is text or presentation document, then the SVG conversion engine is invoked to generate the pagination data; If the document format attribute is table or PDF, then the Canvas conversion engine is invoked to generate the pagination data; After AES-GCM encryption is performed on the generated pagination data, the encrypted pagination data is transmitted paginatedly through the WebSocket connection, wherein the first N pages of the pagination data are transmitted first, where N≥3.

4. The document collaborative processing method based on a document processing platform architecture as described in claim 1, characterized in that, The method further includes: After the user enters the edit mode, the edit service module reuses the WebSocket connection, encapsulates the user operation into an atomic operation, and then broadcasts it to multiple collaborator terminals through the WebSocket connection; After receiving the atomic operation, the multiple collaborator terminals render and update the document content in real time.

5. The document collaborative processing method based on a document processing platform architecture as described in claim 4, characterized in that, After generating user behavior events based on atomic operation increments, the collaborative management module pushes user status change notifications generated based on the user behavior events to external business platforms through callback interfaces. The external business platforms and document processing platforms have an API integration relationship.

6. The document collaborative processing method based on a document processing platform architecture as described in claim 5, characterized in that, After the user finishes editing and generates a new version file, the collaborative management module calls back the save interface of the external business platform to transmit the file stream of the new version file.

7. The document collaborative processing method based on a document processing platform architecture as described in claim 6, characterized in that, The method further includes: The format processing module obtains the new version file; The format processing module converts the new version file from DOCX format to PDF format by performing an overwrite document format conversion operation; The format processing module adds anti-leakage watermarks to the new version files in batches by performing a watermark addition operation. The document format conversion operation and the watermark addition operation are performed independently and in parallel.

8. A document collaborative processing system based on a document processing platform architecture, characterized in that: The system comprises: steps for implementing the method according to any one of claims 1 to 7, wherein the system includes: The module includes a preview service module, an editing service module, a format processing module, and a collaborative management module.

Images