Intelligent document processing method and device, equipment and medium

Abstract

The invention relates to the technical field of artificial intelligence, can be applied to business scenes of financial science and technology, medical health and the like, and discloses an intelligent document processing method, device, equipment and medium, comprising: receiving a document processing request and generating a task identifier, creating and sending a document processing task, constructing an intermediate document structure and generating a plurality of subtasks, and processing the sub-tasks, writing states and page contents into a cache, regularly querying task states, updating accessible identifiers, responding to an access request, loading the page contents, and integrating pages to generate a complete document after all the sub-tasks are completed. According to the method, the document generation task is divided into a plurality of sub-tasks which can be independently processed, and page-level asynchronous loading is realized in combination with a state cache and a regular query mechanism, so that the response speed and the system processing efficiency are remarkably improved while the generation accuracy is ensured; the problems that in the prior art, document generation delay is high, loading is slow, and user waiting time is long are effectively solved.

Description

Technical Field

[0001] The present invention relates to the field of artificial intelligence technology, and in particular to an intelligent document processing method, device, equipment and storage medium. Background Art

[0002] Among current applications of intelligent document generation, automated generation of PPT documents, such as proposals, has become widely adopted across various business systems, particularly with growing demand in the financial technology and healthcare sectors. Traditional technologies typically utilize synchronous loading and one-time rendering to complete document generation. This approach can lead to slow system responses and long page rendering times when processing complex documents with deep hierarchical structures and diverse template styles, severely impacting user experience and smooth operation.

[0003] In the fintech sector, demand continues to rise for automated generation of PPT-like documents, such as investment research reports, client risk assessment reports, and credit review materials. These documents often involve the integration and processing of large amounts of structured and unstructured data, as well as the dynamic invocation of modular components such as charts and indicator models. Existing document generation solutions often suffer from high resource consumption and frequent system blockages during the generation process. These solutions struggle to achieve stable performance when handling multiple concurrent tasks, failing to meet the high real-time and concurrent processing requirements of financial services.

[0004] In the healthcare sector, the automated generation of PPT-style materials, such as medical reports, clinical pathway summaries, and chronic disease management plans, has gradually become a key support tool for data-driven development. These documents typically require pulling historical medical records, indicator trend data, and template structures from multiple systems. Traditional processing methods are inefficient in data integration and content splicing, often resulting in long page load times and failures in some modules. This hinders doctors from quickly obtaining high-quality document output within a limited timeframe, impacting diagnosis and treatment efficiency.

[0005] Furthermore, existing document generation technology architectures still suffer from issues such as insufficient reliance on caching strategies, ineffective system decomposition of long-running tasks, difficulty tracking subtask status, and delayed result return mechanisms. These flaws not only limit document generation efficiency but also prevent users from receiving clear feedback while waiting, reducing the system's interactivity and usability.

[0006] In summary, current technologies still have significant shortcomings in meeting the requirements for fast response, progressive rendering, and on-demand loading of complex documents across multiple terminals. In particular, in high-concurrency, high-complexity, and multi-page scenarios, there is a lack of an intelligent processing mechanism that balances efficiency and stability. These issues urgently need to be addressed through architectural optimization, improved scheduling mechanisms, and enhanced access efficiency. Summary of the Invention

[0007] The main purpose of the present invention is to provide an intelligent document processing method, device, equipment and storage medium, aiming to solve the problems in the existing technology of slow response, untimely loading and lack of on-demand access capability in the document generation process, and the technical problem of difficulty in meeting the requirements of efficient and phased delivery of multi-page documents.

[0008] To achieve the above object, the present invention provides an intelligent document processing method, comprising:

[0009] Receive a document processing request initiated by a user terminal, and generate a task identifier corresponding to the document processing request;

[0010] Creating a document processing task based on the task identifier, and sending the document processing task to a document processing module;

[0011] Based on the document processing task, obtaining original data through the document processing module, and constructing an intermediate document structure based on the original data;

[0012] Generate a plurality of subtasks based on the intermediate document structure by the document processing module, and assign a subtask identifier to each subtask;

[0013] Processing the subtasks through the document processing module, and storing the processing status of each subtask and the generated page content in a status buffer;

[0014] Sending a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers;

[0015] Updating the subtask identifier set accessible to the user terminal according to the completed subtask identifier list;

[0016] In response to an access request for a target subtask identifier in the subtask identifier set initiated by a user terminal, loading page content associated with the target subtask identifier from the state cache;

[0017] When it is detected that the completed subtask identifier list contains all subtask identifiers, the status query request is terminated and the loaded page contents are integrated to generate a complete document.

[0018] Furthermore, to achieve the above-mentioned object, the present invention provides an intelligent document processing device, comprising:

[0019] A request receiving module, configured to receive a document processing request initiated by a user terminal and generate a task identifier corresponding to the document processing request;

[0020] A task scheduling module, configured to create a document processing task based on the task identifier and send the document processing task to a document processing module;

[0021] A data construction module, configured to obtain raw data through the document processing module based on the document processing task, and to construct an intermediate document structure based on the raw data;

[0022] A task splitting module, configured to generate a plurality of subtasks based on the intermediate document structure through the document processing module, and assign a subtask identifier to each subtask;

[0023] A subtask processing module, configured to process the subtasks through the document processing module and store the processing status of each subtask and the generated page content in a status buffer;

[0024] A status query module, configured to send a status query request to the document processing module at preset time intervals to obtain a list of currently completed subtask identifiers;

[0025] A permission update module, configured to update a set of subtask identifiers accessible to the user terminal according to the list of completed subtask identifiers;

[0026] a content loading module, configured to load, from the state cache, page content associated with a target subtask identifier in the subtask identifier set in response to an access request initiated by a user terminal to the target subtask identifier;

[0027] The document synthesis module is configured to terminate the status query request and integrate the loaded page contents to generate a complete document when detecting that the completed subtask identifier list contains all subtask identifiers.

[0028] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and an intelligent document processing program stored in the memory and executable on the processor, and the intelligent document processing program, when executed by the processor, implements the steps of the intelligent document processing method described above.

[0029] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which an intelligent document processing program is stored. When the intelligent document processing program is executed by a processor, the steps of the intelligent document processing method described above are implemented.

[0030] Beneficial effects: The present invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as financial technology and medical health. It discloses an intelligent document processing method, including: receiving a document processing request initiated by a user terminal and generating a task identifier, creating a document processing task and sending it to a document processing module, obtaining raw data to construct an intermediate document structure, generating multiple subtasks based on the structure and assigning subtask identifiers, processing the subtasks and storing the processing status and page content in a status cache, sending a status query request to obtain a list of completed subtask identifiers, updating the set of subtask identifiers accessible to the user terminal, loading the page content associated with the access request, and when it is detected that the list of completed subtask identifiers contains all subtask identifiers, integrating the loaded page content to generate a complete document. The present invention splits the document generation task into multiple subtasks that can be processed independently, and combines the status cache with a periodic query mechanism to achieve asynchronous loading at the page level. While ensuring generation accuracy, it significantly improves the response speed and system processing efficiency, effectively solving the problems of high document generation delay, slow loading, and long user waiting time in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0032] Figure 1 A schematic diagram of an application environment of an intelligent document processing method according to an embodiment of the present invention;

[0033] Figure 2 This is a flow chart of an embodiment of the intelligent document processing method of the present invention;

[0034] Figure 3 A schematic diagram of the functional modules of a preferred embodiment of the intelligent document processing device of the present invention;

[0035] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0036] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0037] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0038] The intelligent document processing method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can receive a document processing request initiated by the user terminal through the user terminal and generate a task identifier, create a document processing task and send it to the document processing module, obtain raw data to build an intermediate document structure, generate multiple subtasks based on the structure and assign subtask identifiers, process the subtasks and store the processing status and page content in a status cache, send a status query request to obtain a list of completed subtask identifiers, update the set of subtask identifiers accessible to the user terminal, load the page content associated with the access request, and when it is detected that the list of completed subtask identifiers contains all subtask identifiers, integrate the loaded page content to generate a complete document. The present invention splits the document generation task into multiple subtasks that can be processed independently, and combines the status cache with a periodic query mechanism to achieve page-level asynchronous loading, significantly improving the response speed and system processing efficiency while ensuring generation accuracy, effectively solving the problems of high document generation delay, slow loading, and long user waiting time in the prior art. The user terminal can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices. The server terminal can be implemented as an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific examples.

[0039] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the intelligent document processing method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0040] like Figure 2 As shown, the intelligent document processing method proposed by the present invention includes the following steps:

[0041] S10, receiving a document processing request initiated by a user terminal, and generating a task identifier corresponding to the document processing request;

[0042] In this embodiment, a document processing request is received from a user. This request represents a document generation operation triggered by the user through a client interface or a system interface. The request includes information such as the generation target, format requirements, content structure type, user identity credentials, and data source parameters. This processing request can be received by various system access layers, such as REST-based API services, WebSocket communication protocols, GraphQL interfaces, or RPC service frameworks. The specific communication protocol selected will be adjusted based on the business latency tolerance, security requirements, and system deployment model.

[0043] The structure of a document processing request is typically encapsulated in a structured format, such as JSON or Protocol Buffers, which offers good parsability and cross-platform compatibility. The content structure may include fields such as the purpose of document generation (e.g., project planning, data reporting, industry analysis), target format type (e.g., PPT, PDF, HTML), page template preferences (e.g., mixed text and image layout, table structure, icon presentation), and data source type (e.g., database query, file upload, real-time data interface). Upon receiving the request, the system must perform artificial intelligence and field validity verification to ensure parameter integrity for subsequent processing.

[0044] The mechanism for generating task identifiers should ensure global uniqueness and traceability. Typically, a hash code generated from a combination of a timestamp and a random factor, UUID version 5, or the Snowflake algorithm is used for identifier generation. Incorporating a service instance number or region code enhances system scalability and disaster recovery. The generated task identifier not only identifies the current document processing request but also serves as the primary key for task tracking, linking to subsequent task scheduling, status tracking, cache hits, asynchronous notifications, and security audits.

[0045] The generation of task identifiers is typically completed in the task access module or access control gateway module. This process needs to be completed in a short time and be stable under high concurrency. The generation logic can introduce request time window segmentation, user unique identifiers (such as tokens, UIDs), data source types, or document generation priorities as input parameters to achieve task granularity differentiation and priority scheduling support. After the identifier is generated, it needs to be bound to the context of the current request and written to the task scheduling center or task registration module to serve as the root node for task lifecycle tracking.

[0046] After the task identifier is successfully generated, it will be passed to the document processing module through the internal task bus or task scheduling mechanism. The document processing module will pull the request parameters based on the identifier and initialize the intermediate structure. This structure serves as the only logical entry point for a series of subsequent processes such as subtask splitting, content generation, and asynchronous loading.

[0047] By configuring a load-balancing gateway, document processing requests can be routed to multiple task access nodes. Each node internally parses the request body using an asynchronous I / O framework (such as Netty, Vert.x, or Nginx) and converts the user-submitted document parameters into structured objects using deserialization tools (such as Jackson, Gson, or a protobuf parser). The task registration component then uses a built-in unique identifier generator (such as one based on distributed ID generation components like Snowflake and Leaf) to generate a task identifier. This identifier is then cached in Redis to prevent duplicate generation. Once the identifier is generated, the task parameters are bound to the identifier and stored in a task-centric database (such as MongoDB, MySQL, or TiDB) or messaging middleware (such as Kafka or RabbitMQ) to drive the subsequent document construction process. Alternatively, within a microservices architecture, an event-driven model can be used to encapsulate the task identifier and task parameters into a message body and publish it to the queue channel corresponding to the document processing module, triggering subsequent document construction tasks. To improve performance, task identifier generation can be decoupled from the task registration process, and batch identifier pre-generation can be supported to increase throughput.

[0048] Example: In the financial sector, when a credit assessment system needs to generate a personal credit report PPT, the user selects the data range, credit score dimensions, and report format in the backend management interface and submits the request. The system generates a task identifier for the request and binds the user ID and parameter source, driving the automatic generation process of the credit data interface, scoring model output, and PPT module.

[0049] In healthcare scenarios, when a doctor requests a patient medical record presentation from the auxiliary diagnosis platform, the platform immediately generates a task identifier upon receiving the request, which includes the patient ID, diagnosis code, and visualization template. The task information is then distributed to the analysis chart module and the medical imaging module for concurrent processing. Through the unified scheduling of task identifiers, both scenarios enable coordinated access to multi-source data, highly concurrent task processing, and user-level result feedback, significantly improving system responsiveness and document generation accuracy.

[0050] By establishing a unified user request reception mechanism and introducing a high-performance task identifier generation strategy, we can effectively support concurrent user document generation requests and full-process task tracking. The task identifier provides a unique mapping path for the request lifecycle, enabling isolated processing between modules at each stage of document generation and ensuring information consistency. This avoids issues such as difficulty tracing requests, data scheduling conflicts, and unclear status feedback.

[0051] S20, creating a document processing task based on the task identifier, and sending the document processing task to a document processing module;

[0052] In this embodiment, after the task identifier is generated, a specific document processing task needs to be constructed based on the identifier. The construction of the task is not only a copy and encapsulation of the original request parameters, but also a structural transformation process, the purpose of which is to map the document requirements submitted by the user into a task description unit that is recognizable, executable, and schedulable by the system. The document processing task usually contains multiple fields, of which the task identifier is the primary key parameter, and other contents may include the original data source identifier, document format requirements, page template index, graphic and text typesetting rules, data cleaning instructions, task priority and resource scheduling tags, etc. The design of the task structure should be modular, hierarchical and extensible, and suitable for multi-scenario processing with complex document content structure and heterogeneous generation paths.

[0053] The original data source identifier is used to determine the data input path that the task depends on, which can be a database connection string, API path, file storage index, message subscription channel or temporary cache location of intermediate data; the document format requirements are used to standardize the final output format, such as PPT, PDF, DOCX or structured JSON structure, which is used to form a target drive for the rendering module; the page template index is used to specify the layout template of each page content, which can be a preset template ID or a dynamically parsed style template object. The task priority provides a resource allocation basis for the scheduling module to ensure that urgent tasks can be processed in advance. All task parameters must be bound to the task identifier to form a task description entity.

[0054] After a task is constructed, it needs to be sent to the document processing module via the document task distribution mechanism. This can be accomplished through a variety of communication mechanisms, including synchronous RPC calls, asynchronous message queues, event-driven publishing, or distributed task scheduling systems. This distribution mechanism must support retry upon failure, status receipts, and task tracking, and ensure idempotence of task distribution. Upon receiving a task, the document processing module uses the task identifier as the primary thread to parse, schedule, and perform concurrent processing of the task content, driving subsequent processes such as data reading, template rendering, and page splitting and synthesis.

[0055] Task dispatch is the interface coupling point between multiple modules within the system. Its accuracy and efficiency directly impact the execution chain of the entire process. Therefore, parameter verification mechanisms, task delivery status tracking, and error recovery channels are required to ensure reliable and timely task delivery. Tasks can also be forwarded to edge nodes or remote document processing engines deployed in multiple locations based on load balancing strategies, forming a task sharding and distributed processing architecture.

[0056] The task service module can be built based on a microservice framework such as Spring Cloud or Dubbo. After receiving the task identifier, the task parameter object is constructed, and an object mapper (such as MapStruct or ModelMapper) is used to map the structured request parameters to a task description structure. This structure is sent to the document processing module through a Kafka message channel, a RabbitMQ exchange, or a gRPC-based service node call. It is also possible to build a task control center, register task scheduling records in it, and use the task flow status table to manage the task lifecycle. After sending, the processing module returns a receipt confirmation signal to the task source node through a callback channel or a message confirmation mechanism, and the task status is marked as "delivered" or "processing" in the database. When there are a large number of concurrent document requests in the system, tasks can be evenly distributed to different processing sub-nodes based on Consistent Hash or task priority strategies.

[0057] Example: In a healthcare scenario, when a doctor initiates a request to generate a patient follow-up report, the system generates a task identifier for the request and constructs the task content, including the patient's historical examination data path, target format (such as PPT), report template index, and analysis dimension requirements. The task is then sent via a message channel to the backend chart rendering module and graphic summary module, where each submodule executes the task in parallel. This mechanism makes medical report generation more fluid and scalable.

[0058] During the financial credit review process, business personnel initiate batches of credit report generation requests. The system packages each request into a separate task, identifies the data interface address and template configuration, and distributes the task to the report generation nodes in the cluster. The task processing module uses task identifiers to callback status progress, ensuring low latency and high completion rates throughout the process even under high concurrency.

[0059] By creating and sending structured document processing tasks, the system transforms unstructured user requests into highly controllable task entities with clear identification, a clear parameter structure, and schedulability, facilitating task tracking and module decoupling in asynchronous environments. The introduction of a task dispatching mechanism enables dynamic resource allocation based on task load, improving the stability and fault tolerance of task transmission, and effectively avoiding issues such as task scheduling failures, inter-module blocking, and imbalanced processing priorities.

[0060] S30, based on the document processing task, obtaining original data through the document processing module, and constructing an intermediate document structure based on the original data;

[0061] In this embodiment, upon receiving a document processing task, the document processing module's primary operation is to parse the task content, extract the original data source identifier, and access the corresponding data. The original data source identifier is a parameterized reference that can point to a variety of data entities, including structured database table names, SQL statement fragments, file storage paths, REST API addresses, cache key-value paths, data warehouse tags, medical system interfaces, or financial transaction flow indexes. The document processing module needs to invoke the corresponding data access protocol based on the source identifier type and introduce a data format adapter or protocol parser during the data extraction phase to ensure data readability and consistency.

[0062] After data ingestion is complete, the extracted data is often non-uniformly structured content blocks, such as JSON with nested fields, tabular CSV, text information with inconsistent encodings, and content collections with formatting controls. These data cannot be directly used as input for page presentation. To convert this raw data into a usable data structure for subsequent rendering and processing, a series of build operations are required to form an intermediate document structure. This intermediate document structure can be considered a temporary data container for the task. It carries the document's semantic information, paging logic, content fragments, and structural hierarchy, and has excellent structuring and template mapping capabilities.

[0063] Constructing the intermediate document structure usually includes the following key operations: field extraction and classification, label marking and content identification, paging anchor calculation, data format unification, image and text block reconstruction, and structural specification standardization. The extraction and classification process is to group data fields based on task parameters, such as grouping "basic information", "image summary", "product revenue status" and other content into different structural blocks. Paging anchor calculation is used to subsequently divide the intermediate structure into multiple page content units. The anchor basis can be dynamic indicators such as word count, semantic paragraph boundaries, image-text ratio, and keyword frequency. Format unification operations include steps such as encoding standard conversion of content blocks, field cleaning, blank filling, and field order reorganization to build a data model that can be directly fed into the page template.

[0064] The intermediate document structure is usually designed with a hierarchical structure. For example, the top layer of the structure is a list of document blocks, each of which corresponds to a future page. The document block contains sub-modules such as the text area, chart area, and conclusion area. Each sub-module stores formatting fields, image binary links, chart metadata, and other content. The structure should also record metadata such as the binding relationship with the task identifier, the field source path, and the content hash checksum to ensure task tracking and content accuracy. This structure has strong semantics while maintaining decoupling from content blocks, and is the basis for implementing content paging, modular editing, and template rendering.

[0065] In one implementation, the original data source identifier can point to a Parquet-formatted file stored in an enterprise's private data lake. The document processing module, based on a Spark task, reads the data blocks and converts them into a unified format using a structured mapper. After the conversion is complete, an embedded paragraph recognition model (e.g., a variant of TextRank) is used to annotate logical paging anchors. The intermediate document structure is constructed using these anchors as demarcations, with each paging node independently carrying both text and image data and corresponding contextual references.

[0066] In another embodiment, the original data is manually filled in by the user, transmitted to the background service through the API and cached in Redis. The document processing module extracts the cached data and parses the field structure. According to predefined rules (such as the data field with the content type of "customer profile" must appear on the first page), structured nodes are constructed, a title hierarchy tree is established, and the intermediate document structure is integrated to generate.

[0067] It is also possible to perform word segmentation, entity recognition and indicator clustering on the original text entered by the doctor based on medical natural language processing tools (such as medical terminology standardization tools), so as to convert the original text into multiple structured content units in the intermediate structure, such as "test result segment", "clinical diagnosis segment" and "treatment plan segment", realizing the construction process from disordered text to structured content.

[0068] Example: In healthcare, the system receives an outpatient follow-up form completed by a doctor. The data access module parses the fields returned by the electronic medical record system API, such as the patient's chief complaint, allergy history, recent imaging summary, test report, medication regimen, and so on. The document processing module converts this information into an intermediate document structure based on field priority and paragraph division rules. This creates a multi-layered content body consisting of text blocks and chart references, providing a semantic foundation for subsequent page splitting and image-text matching rendering in PowerPoint presentations.

[0069] In the FinTech business scenario, a customer initiates a request to generate an asset performance report for a certain product. The system calls the data source interface to read the customer's historical transaction records, product position changes, profit charts, asset allocation, and other information. The document processing module constructs a paginated intermediate document structure based on product type and page template rules, where each page document block corresponds to a topic paragraph or chart section, ensuring that the subsequent page structure is clear and the content is orderly.

[0070] By converting raw data into an intermediate document structure, key technical issues such as heterogeneous raw data structures, disordered content distribution, and difficulty defining paging are effectively addressed. By constructing an intermediate document structure, the system can implement precise paging, template content matching, and paragraph-to-text mapping in subsequent steps, avoiding issues such as low processing efficiency, high typographical error rates, and adaptation failures caused by directly processing complex raw data during rendering. The introduction of an intermediate document structure enhances the modularity, controllability, and system scalability of the document generation process, supporting stable generation capabilities in highly concurrent, heterogeneous data environments.

[0071] S40, generating a plurality of subtasks based on the intermediate document structure by the document processing module, and assigning a subtask identifier to each subtask;

[0072] In this embodiment, after the intermediate document structure is constructed, it is necessary to convert it into task units suitable for parallel processing, step-by-step rendering, and asynchronous loading. During this process, the document processing module generates subtasks based on the paging information, logical block structure, and content division rules in the intermediate document structure, and assigns a unique and traceable identification value to each generated task unit. This process involves not only structural decomposition but also content packaging, metadata attachment, and identification generation strategy design for the task units.

[0073] The generation of subtasks is based on the "paging anchor" or "logical page unit" in the intermediate document structure. Each page-level document block will be converted into an independent processing task. Each task unit usually includes data such as graphic content fragments, title or tag information, template index, page sequence number, etc. During the processing process, the document processing module will call the task cutter module to automatically adjust the page division granularity based on parameters such as content complexity, graphic density, and rendering difficulty, thereby ensuring that the content load of each subtask is reasonable and the processing time is controllable, thereby improving the system's concurrent processing capabilities.

[0074] The subtask identifier is a core field for task tracking and cache reading and writing. This identifier should be unique, hierarchical, and resolvable. Common methods for generating it include prefixing the task identifier with the task type, page sequence number, timestamp, or hash value. For example, an identifier such as taskID_pg_0003 represents the third subtask of a task. After the identifier is generated, it should be recorded synchronously in the task scheduling index table for use in subsequent status queries, cache writes, and user-side access paths.

[0075] After the identifier is assigned, each subtask should be mapped to the original task identifier, supplemented with the bound page template index information and the field path of the corresponding node in the intermediate document structure. The document processing module typically uses a queue-based structure to cache the generated subtask list and pass it to the downstream task scheduling module, state cache module, or template rendering engine. Through this structured task generation mechanism, the system achieves the transition from unified documents to asynchronously loadable page units, providing the technical foundation for subsequent parallel processing, real-time response, and access control.

[0076] In one embodiment, the document processing module maps each paging block in the intermediate document structure to a subtask. Each paging block consists of a logical title, body paragraphs, image references, chart metadata, and other content. Based on content density rules, the system automatically segments document blocks with graphic elements exceeding a set threshold into multiple subtasks. Each subtask is assigned a unique identifier, such as taskA_pg_0001 and taskA_pg_0002. Identifier generation uses a combination of task identifier, page number, and timestamp fragments to ensure uniqueness.

[0077] In another implementation, the system sets different subtask granularities for different content types. For example, in a financial report, modules such as asset overview, customer profile, and earnings trends are used as subtask division units. In a medical summary, the system uses the "Chief Complaint," "Diagnosis Conclusion," and "Image Summary" fields within the intermediate structure as division boundaries. This approach, through understanding structural semantics, achieves a task division that better aligns with industry logic.

[0078] The subtask division strategy can also be dynamically adjusted based on the performance of the user's device. For low-performance devices, the system will generate more small-scale subtasks to minimize the content per page, improving the loading experience. If the user's device supports high bandwidth and parallel processing, multiple document blocks can be merged into a single subtask, reducing the number of tasks and scheduling overhead.

[0079] By dividing the processing of the intermediate document structure into multiple subtasks and assigning them identifiers, the system achieves granular refinement, parallel processing, and asynchronous control of the document processing flow. It effectively avoids the problems of long task processing time, high cost of failed retry, and uncontrollable user waiting time in traditional full-text processing methods. The subtask structure allows users to browse some pages immediately after they are generated. The system can also locate the specific task unit to roll back or retry when the generation fails, significantly improving stability and user experience. At the same time, through a resolvable task identification system, the system has achieved unified indexing in data caching, task scheduling, and access permission control, improving the clarity and management efficiency of the overall processing link.

[0080] S50, processing the subtasks by the document processing module, and storing the processing status of each subtask and the generated page content in a status buffer;

[0081] In this embodiment, once a subtask unit is successfully generated and assigned a subtask identifier, the document processing module is responsible for independently processing each subtask. This processing process covers multiple operational stages, including template file loading, page content parsing, image and text filling, style rendering, and typesetting layout verification. Upon completion, each subtask must generate page content that meets the target format requirements and write the processing results and status to the status buffer in a structured manner. This processing flow not only ensures concurrent task processing capabilities but also provides data support for asynchronous access and incremental loading.

[0082] The first step in subtask processing is typically to load the corresponding page template file from the template repository using the page template index bound to the subtask. The template file defines the page's layout structure, graphic and text placeholders, font specifications, color scheme, and layer order. Once loaded, it serves as the framework for rendering operations. After obtaining the template file, the document processing module parses all predefined placeholders and region rules within the template and initializes page layout parameters, including page margins, row and column divisions, chart slot positions, font size, and style.

[0083] The module then fills the page content fragments from the subtask units into the designated locations in the template, one by one, according to the placeholder rules. These content fragments may include text paragraphs, image links, table structures, and visual chart data. During this filling process, the processing module determines the compatibility of the content, such as matching image size with template slots and text content with the capacity of the text box. If necessary, it implements content compression, cropping, segmentation, and page wrapping strategies to ensure a complete page structure and a consistent visual style.

[0084] Once data is populated, the document processing module invokes the rendering engine to perform style rendering on the populated template. This process applies graphics and optimized layout processing to all visual elements on the page, forming standardized page data blocks that can be cached and loaded. After rendering is complete, the module updates the processing status of the current subtask based on the execution results. The status can be "Processing," "Completed," or "Failed," and includes the current timestamp and exception log (if processing fails) to support subsequent monitoring and debugging.

[0085] Finally, the system uses the subtask identifier as the primary key, encapsulates the processing status, formatted page data block, and completion timestamp into a structured key-value pair, and writes it to the status cache. The status cache can be an in-memory database or a high-speed file cache built on a key-value structure, with high concurrent read and write capabilities and support for status polling.

[0086] In one implementation, the document processing module loads the template file based on the task parameters and sequentially fills the corresponding areas of the template with the page title, content summary, and chart information. After rendering, the module outputs a standard SVG graphic format as a page data block, which is then stored in a Redis cache database along with a status field. If processing fails, the system generates a failure status and writes an error code and failure log, which can be used by the scheduling module for retrying or manual intervention.

[0087] In another implementation, for image- or chart-intensive pages, the document processing module encapsulates the template rendering results into a compressed image format, encodes them using Base64, and writes them to the cache to save bandwidth and improve loading speed. The status field retains its original structure and is written to the backend status database through a timed synchronization mechanism.

[0088] Different rendering paths can also be set for different subtask types. For example, a mixed text and image page calls the text and image template renderer, while a data chart page calls the visualization engine for chart synthesis. Ultimately, a unified data structure format is generated and written to the cache. This diversion strategy improves processing efficiency and quality stability for different content types.

[0089] By independently processing each subtask and writing its processing status and page content to a status cache, the system achieves concurrent task processing, asynchronous data loading, and visual status monitoring. This structured storage of processing status allows the scheduling module to obtain real-time information about task processing progress, and the user end can also load content page by page based on a status polling mechanism, significantly reducing wait times and improving the responsiveness experience. Furthermore, page data is written to the cache in a standard format, providing efficient data support for subsequent access requests, content decompression, preview generation, and other operations.

[0090] S60, sending a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers;

[0091] In this embodiment, after subtask processing enters the execution phase, the system needs to establish a task completion status awareness mechanism to dynamically monitor the progress of each subtask and implement asynchronous visual output. This mechanism is implemented by setting a fixed-period status query logic, typically relying on a timed task scheduler or event-driven poller to periodically trigger status query requests driven by system events.

[0092] Query requests are generated by the client-side state scheduling module or the server-side task controller, targeting the interface service responsible for maintaining subtask status in the document processing module. Request parameters include the current task identifier to limit the query scope, and can also include the last query timestamp to optimize query granularity and avoid duplicate queries.

[0093] After receiving a query request, the document processing module retrieves the processing status of all subtasks associated with the current identifier from its internal or external status cache or task status mapping table. The system selects subtasks marked as "completed" and encapsulates them into a list of completed subtask identifiers using a pre-defined data structure format.

[0094] The list is generally organized in an array, linked list, or hash structure. Each item contains a subtask ID, a processing completion timestamp, and possible execution log reference information, forming a data set with time sorting and identification tracking capabilities.

[0095] The status query cycle can be adjusted based on system processing power, the average execution time of subtasks, and the user's tolerance for refresh delays. A query cycle that is too short can waste resources and cause interface pressure, while a cycle that is too long can cause display delays on the user side. To this end, the system can introduce a dynamic adjustment strategy to optimize the query frequency in real time based on task execution intensity or user activity.

[0096] After obtaining the list of currently completed subtask identifiers, the system passes the list to the accessible identifier set management module for updating, which is used to drive the front-end loading logic or determine the overall document generation status.

[0097] In one implementation, a status query task is triggered by front-end page polling logic. Every three seconds, an HTTPS request is made to the back-end status service interface. The request body contains the task identifier and the user's session token. The back-end interface then queries the Redis status cache for the status fields of all subtasks under the task, filters them for completion status, and returns an array of subtask identifiers.

[0098] In another embodiment, a server-side asynchronous timer is used to create an asynchronous loop thread inside the task scheduling module. The task control table is checked every 5 seconds, and the subtask processing module status record table is queried one by one for the task being processed. A set of completed subtask identifiers is constructed from it and sent to the user data channel for access interface calls.

[0099] You can also use a message-driven approach to monitor state change events in the state cache. Each change triggers a query process, but additional polling is only performed after a no-notification timeout, reducing the pressure of invalid requests.

[0100] Through a time-interval-based status query mechanism, the system continuously monitors the progress of subtasks in an asynchronous, low-coupling manner, eliminating the need to block and wait for all tasks to complete. By combining periodic requests with dynamically adjusted frequency, front-end users are guaranteed the ability to progressively load available page content, avoiding interruptions caused by lengthy waits for complete document generation. This mechanism also boasts excellent system adaptability, enabling adaptive optimization for different types of tasks and server environments with varying performance, enhancing the stability of the entire document processing process and user-perceived interactive performance.

[0101] S70, updating the subtask identifier set accessible to the user terminal according to the completed subtask identifier list;

[0102] In this embodiment, subtasks can be processed in parallel or asynchronously, and their completion times are uncertain. Therefore, the system must maintain a set of completed subtask identifiers in real time and filter out the set of subtask identifiers currently accessible to the user. This set serves as the basis for the user to determine the scope of currently accessible page content and is also a key technical support for the front-end loading control strategy.

[0103] The update process is based on a list of completed subtask identifiers, where each subtask identifier represents a page unit with a "completed" status. The system parses this list, filtering out subtasks that have not yet met other access conditions (such as page content not being written to the cache, content quality verification not passing, etc.), and forms a processed set of candidate identifiers. These candidate identifiers are then compared with the set of subtask identifiers maintained by the current user end, newly added subtask identifiers are identified, and the set update operation is performed.

[0104] Update operations essentially replace or extend a collection, the specific method of which depends on the system's data structure design. If the client uses an object mapping structure to store the subtask identifier collection, the newly added identifier item will be appended as a key value, with an expiration date, content loading flag, or access control field set. If the collection is maintained in an ordered array or linked list format, the update operation must maintain sequential consistency to support sequential rendering.

[0105] The updated set of user-side accessible subtask identifiers will serve as key parameters for subsequent page loading logic, access permission verification, and jump control. Each time a user actively accesses the page content, it will be matched and verified with the target subtask identifier to determine whether access is allowed and whether loading is triggered.

[0106] In one implementation, after receiving a status query request and returning a list of completed subtask identifiers, the backend pushes this list to the frontend control module via a message channel. The frontend module compares this list with a locally maintained set of accessible identifiers and updates the visible page items in the display control table, controlling the range of options available to users when turning pages or navigating through the index.

[0107] Another implementation uses a centralized access control service. The backend maintains a unified mapping table of accessible subtask identifiers. Each time the identifier set changes, a change event is broadcast to the frontend. The frontend then synchronizes the page state and adjusts loading behavior based on the change event. This implementation is suitable for scenarios where multiple devices collaborate on browsing or high-concurrency users access the same document processing task simultaneously.

[0108] A layered strategy can also be adopted to layer the completed subtask identifiers according to the page importance level, and only add high-priority identifiers to the accessible set each time. This can be used to control terminal devices with limited resources to load key content on demand and delay loading of auxiliary pages, thereby improving the overall loading experience.

[0109] Example: In a healthcare scenario, when a user requests a summary report for a patient's examination, the system breaks the report down into multiple subtasks (e.g., image analysis page, laboratory test page, diagnosis conclusion page, etc.). As subtasks are completed, the system updates the accessible subtask identifiers in real time. Doctors can view completed pages first without having to wait for all examination content to be generated, making this particularly useful in emergency diagnosis and treatment situations.

[0110] In financial applications, the process of generating corporate credit reports often requires processing subtasks from multiple data sources, such as historical credit, financial analysis, and industry comparison modules. By updating the accessible identifier set, financial practitioners can prioritize review of key financial summary pages or public opinion summary pages, providing advance reference for decision-making and improving timeliness and efficiency.

[0111] By introducing an update mechanism for subtask identifier sets, we've achieved a shift in document loading control from full-load waiting to phased access. This strategy effectively improves the responsiveness of task processing, allowing users to access partially completed content even when tasks are not fully completed. This strategy offers significant advantages in interactive efficiency and resource utilization, avoiding typical drawbacks such as loading blockages and long user wait times. It also significantly reduces reliance on high-performance devices and possesses strong universal adaptability.

[0112] S80, in response to an access request initiated by the user terminal for a target subtask identifier in the subtask identifier set, loading page content associated with the target subtask identifier from the state cache;

[0113] In this embodiment, when a user attempts to access specific page content, its access request must include the current user context identifier (such as a login session token or access token) and the page identifier of the intended page, i.e., the target subtask identifier. The system first performs a structured parsing of the access request, extracts the target subtask identifier, and verifies whether the identifier belongs to the set of subtask identifiers accessible to the user, thereby preventing the user from accessing unfinished content or content that does not meet their permissions.

[0114] The target subtask identifier is generally composed of a task identifier, a page sequence number, a separator, etc., and is the key value for uniquely locating the page cache unit in the system. After completing the accessibility check, the system retrieves the corresponding page content record from the status cache based on the identifier. The cache usually adopts a key-value pair structure, with the subtask identifier as the primary key. The record content includes the page rendering result (formatted content), status label (such as completion / failure), completion timestamp, compression method or data integrity check value, etc.

[0115] After a cache hit, the system performs pre-processing on the retrieved page data, including decompression, format reconstruction, and rendering compatibility checks, to ensure page rendering efficiency and data consistency. This allows the returned data to be directly recognized and presented by the front-end rendering engine. Page content is typically encapsulated in a structured markup language (such as JSON, HTML fragments, or a custom page description structure), along with additional page-level metadata, such as the current page's sequence number and the presence of a next page indicator.

[0116] The response content returned to the user end adopts the encapsulation format of the access response data packet, which contains the page content body and related metadata, and is transmitted back to the user end through the communication channel associated with the user session token (such as a long connection, a two-way channel or a streaming push channel), realizing low-latency, high-availability page-level data access services.

[0117] In one implementation, when a user turns a page or clicks a navigation button on an H5 page, a GET request is triggered. The backend system receives the request and extracts the target subtask identifier and the user's session ID from the URL parameters. After completing access verification, the system retrieves the page data from the Redis state cache using the subtask identifier as the key. If a match is found, the cached content is gzipped, JSON fields are cleaned, and then packaged into a standardized response structure and returned.

[0118] Another implementation utilizes a persistent WebSocket connection. Upon receiving a "subtask completed" event from the backend, the frontend application immediately initiates a page load request, requesting the page content identified by the specified target subtask. The backend system accesses the state cache through a local LRU cache manager and performs content integrity checks and signature verification before returning the page content, ensuring the data source is trustworthy and has not been tampered with.

[0119] An access routing mechanism for multi-tenant architecture can also be adopted. When different user terminals access the target subtask identifier, their accessible sets are controlled by the policies configured under their respective tenants. The page content access log is written to the log audit module at the same time as it is returned from the cache, realizing page-level access control and audit tracking.

[0120] Through the above steps, users can access the content of any completed page without waiting for the entire document to be generated. Under the premise of ensuring data security and consistency, an access optimization strategy of staged interaction and page-level decoupling is implemented, which greatly reduces the waiting time on the user side and alleviates the concurrency pressure on the server. Through the rapid response capability of state caching and the fine permission verification capability, the system is provided with a high-performance, low-latency and highly secure document service mechanism, which improves the overall access efficiency and user experience.

[0121] S90: When it is detected that the list of completed subtask identifiers contains all subtask identifiers, the status query request is terminated and the loaded page contents are integrated to generate a complete document.

[0122] In this embodiment, while executing a document generation task, the system continuously maintains a list of subtask identifiers indicating completed processing. This list is updated in real time, recording all subtask identifiers with a "Complete" status. Simultaneously, the system maintains a complete mapping of task assignments, including the complete set of subtask identifiers corresponding to the document. By comparing the currently completed subtask identifier list with the originally assigned subtask identifier set, the system can determine whether all page content has been processed.

[0123] This comparison is typically performed using a set difference or total count comparison. If the two are found to be equal, meaning that the processing status of all subtasks has changed to "Complete," no further status query requests are required. Status query requests are typically initiated periodically in a polling manner with a certain scheduling interval. Therefore, their termination not only saves system computing resources but also avoids unnecessary data exchange overhead.

[0124] After confirming that all subtasks have been completed, the system enters the integration phase. The integration logic relies on the page content loaded in the state cache. The page content generated by each subtask can be accurately retrieved from the cache through its subtask identifier. In order to maintain the accuracy of the page order, the system needs to sort all page contents according to the sequence number in each subtask identifier. After the sorting is completed, the system performs structural merging and layout rearrangement operations on all page contents, splicing them into a complete document with a consistent style and coherent structure. This operation may include cross-page style connection, directory reconstruction, unified header and footer elements, etc.

[0125] Once the complete document is generated, its final format can be PDF, PPT, HTML, or a custom format, depending on the task parameters. Once completed, the document data should be written to a stable, persistent storage system, such as a distributed object storage system, document database, or archive server. Metadata indicating the completion of the document generation should be recorded, including the task identifier, document path, generation time, and validity period. The system then sends a notification to the user indicating the completion of the document generation, guiding them to download the entire document, jump to the next page, or continue reading.

[0126] In one implementation, the status polling module initiates a query every five seconds, retrieving the set of subtask identifiers currently marked as completed from the status cache and comparing it with the total set of subtask identifiers initially recorded by the task dispatch module. When the sets are equal in size and no identifiers are missing, the polling module sets the polling flag to "stop" and sends a trigger signal to the consolidation module.

[0127] The integration module reads the sequential numbers of all subtasks corresponding to the task based on the task identifier, extracts the standardized page content corresponding to each subtask from the Redis cache, and splices them into a PPT-formatted page list. The system calls the synthesis service to construct the PPT file from this page list and writes the result to a cloud storage service (such as OSS or S3). Finally, the binding relationship between the document URL and the user ID is recorded in the database.

[0128] Alternatively, if the page content exists as HTML fragments, the integration process must perform cross-page style completion, DOM node optimization, and uniform page width scaling when merging the HTML to generate a complete responsive web document. After the integration is complete, a document generation event is returned to the event bus, and the front-end subscribes to the event to redirect to the page or display a link.

[0129] By monitoring the completion status of subtasks and integrating page content after all subtasks are complete, we not only ensure the integrity and structural consistency of the final document, but also avoid the risk of typographical errors or information loss caused by premature merging. By stopping invalid polling operations, we significantly reduce system resource consumption. Through sequential splicing and unified format synthesis, we ensure that the document structure remains consistent with user expectations. The resulting complete document is highly compatible, readable, and stable, significantly improving document delivery efficiency and user experience.

[0130] The present invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as financial technology and medical health. It discloses an intelligent document processing method, including: receiving a document processing request initiated by a user terminal and generating a task identifier, creating a document processing task and sending it to a document processing module, obtaining raw data to construct an intermediate document structure, generating multiple subtasks based on the structure and assigning subtask identifiers, processing the subtasks and storing the processing status and page content in a status cache, sending a status query request to obtain a list of completed subtask identifiers, updating a set of subtask identifiers accessible to the user terminal, loading the page content associated with the access request, and when it is detected that the list of completed subtask identifiers contains all subtask identifiers, integrating the loaded page content to generate a complete document. The present invention splits the document generation task into multiple subtasks that can be processed independently, and combines the status cache with a periodic query mechanism to achieve asynchronous loading at the page level, while ensuring generation accuracy, significantly improving response speed and system processing efficiency, and effectively solving the problems of high document generation delay, slow loading, and long user waiting time in the prior art.

[0131] In one embodiment, the above step S20 includes:

[0132] S201, generating document processing task parameters associated with the task identifier, wherein the document processing task parameters include document format requirements and page template index, and the task identifier includes an original data source identifier;

[0133] S202, determining the task execution priority according to the document format requirement;

[0134] S203, sending the document processing task including the original data source identifier, task identifier, task execution priority and page template index to the document processing module;

[0135] S204: Receive a task reception confirmation signal returned by the document processing module, and associate the task reception confirmation signal with the task identifier for storage.

[0136] In this embodiment, the creation of a document processing task is based on a previously generated task identifier. This identifier not only serves as an information unit for uniquely identifying the task, but also carries key metadata in the task context, such as the original data source identifier. The original data source identifier is used to clearly identify the data interface or data location that the document generation relies on, such as a database table, API endpoint, distributed file path, etc. Embedding this identifier directly in the task identifier facilitates the subsequent rapid recovery of the task source in the scheduling module, avoiding multiple parsing attempts.

[0137] Based on the task identifier, the system further constructs document processing task parameters. These parameters include multiple fields, with the core fields being the document format requirements and the page template index. The document format requirements define the output format of the final document, such as PDF, PPTX, or HTML, directly influencing subsequent renderer selection and layout logic. The page template index points to the template entity in the template library used to render the page. This is typically a template ID or path reference, and is used to standardize the page structure in subsequent subtasks.

[0138] The task execution priority is further derived based on the document format requirements. This priority is used in the queue sorting or priority scheduling algorithm in the task scheduling module. The priority calculation rules can be constructed based on factors such as document type, estimated file page number, user level, and business urgency, often using weighted scoring or rule matching.

[0139] After the task parameters are prepared, the task scheduling module encapsulates the original data source identifier, task identifier, task execution priority, and page template index into a document processing task package and sends it to the document processing module. Upon receiving the task package, the document processing module generates the corresponding task instance and queues it or processes it concurrently. Upon successful task reception, the processing module returns a task receipt confirmation signal containing information such as the receipt status, timestamp, and task scheduling number.

[0140] After receiving the confirmation signal, the system binds the confirmation status to the original task identifier and stores it in the task status management unit. This storage behavior ensures an auditable closed-loop process from task initiation to task acceptance, which can be used for subsequent task tracking, failure rollback, or process orchestration decision-making.

[0141] In one embodiment, the system first generates a task identifier in the form of a 32-bit UUID, and concatenates the user ID and timestamp to form a task context code with traceability. The original data source identifier embedded in the identifier points to a JSON structured document in a business database, which contains original fields such as customer risk score, behavioral data, credit record, etc. The system then determines that the task should be output in a standard PPT format based on the business scenario, so the document format requirement is set to PPTX, and the page template index points to the "Analysis Report General Template" preset in the template service. The task execution priority is calculated by a multi-factor model and scored 3 (out of 5), marking it as a medium-high priority task. The document processing task is pushed to the document processing module via HTTP POST. The module parses the task parameters and returns a confirmation signal of successful receipt after successfully receiving them. The system writes the confirmation signal to the Kafka queue and synchronously persists it to the task monitoring database for subsequent task progress notification and result output scheduling.

[0142] In another implementation, if the task originates from a file upload, the original data source identifier is the object storage URL. The page template index can be a collection of template tags, and the system automatically parses the specific template file path from the template matching service. The document format must be HTML, adaptive for mobile reading, and the task priority is automatically adjusted based on the document's page count and estimated processing time.

[0143] Example description: In the field of medical and health business, the setting of task priority directly affects the generation order and processing delay of patient reports, which is particularly critical in the face of high concurrency scenarios. For example, when a doctor simultaneously initiates a request to generate a physical examination report for multiple patients, the system will dynamically determine the priority based on the patient's condition urgency field (such as preoperative examination, emergency procedures, etc.). If a patient is marked as "urgent before surgery", the system will set the priority of its document processing task to the highest level, skip the standard queuing logic in the task scheduling module, immediately enter the processing engine and give priority to high-performance computing resources, thereby ensuring the continuity and timeliness of the clinical process.

[0144] This embodiment establishes an information closed loop between task scheduling and processing by explicitly binding the task identifier to document processing task parameters such as the original data source, template index, and format requirements. This not only improves the structural clarity of the task flow, but also makes the tracking, backtracking, and scheduling decisions of task status more controllable. By introducing a multi-dimensional weight model through the task priority mechanism, it effectively supports the dual optimization of importance and timeliness in asynchronous task processing scenarios, thereby improving the overall system response efficiency and resource scheduling accuracy.

[0145] In one embodiment, the above step S40 includes:

[0146] S401, parsing the page segmentation mark of the intermediate document structure;

[0147] S402, determining the start node and end node of each page in the intermediate document structure according to the page segmentation mark;

[0148] S403, extracting a page content segment of a corresponding page in the intermediate document structure based on the start node and the end node of each page;

[0149] S404: creating corresponding subtask units based on the page content fragments, and generating a unique subtask identifier for each subtask unit;

[0150] S405: Associating and binding the subtask unit with the corresponding page template index in the document processing task.

[0151] In this embodiment, when performing subtask division on the intermediate document structure, the document processing module first performs a structural semantic analysis on the structure to identify logical markers used for page division. These markers may include page breaks, structural section nodes, page break styles, or explicit page break meta tags. Page break markers are control signals used to indicate the paging logic in the intermediate document. Their sources may include predefined section instructions in the document template, paging prompts inserted by the content generation model, or paging anchors manually set by the user.

[0152] After parsing is complete, the system determines the boundaries of each page's content based on each page's segmentation markers, extracting the corresponding start and end nodes. Nodes can be semantic units such as paragraphs, graphic blocks, table areas, and title fields within the content tree. They are organized hierarchically within the intermediate document structure and have unique structural path identifiers.

[0153] The process of extracting page content fragments involves truncating the content between the aforementioned boundary nodes into independent content blocks while preserving their structure. These blocks are then used as the minimum processing unit input. Page content fragments not only include display data such as text and images, but also retain metadata such as paragraph styles, structural paths, and content types, facilitating subtask-level style binding and template mapping.

[0154] When creating a subtask unit, the system uses each page content fragment as its core content, encapsulating its metadata, template index, resource references, and other information to generate an independent subtask unit object. The subtask identifier generation logic is based on the original task identifier, using a preset character as a delimiter to construct a unique identifier by concatenating the page sequence number. This ensures traceability and distributed uniqueness within the scheduling system and status cache.

[0155] After generating subtask units, the system binds each subtask unit based on the pre-configured page template index in the document processing task. This binding provides a direct mapping relationship for the subtask to subsequently call the correct template style file, ensuring that each page content accurately matches the pre-defined layout, margins, column layout, and placeholder rules during the generation phase.

[0156] In actual system deployments, page break markers can be parsed using a regular expression parsing engine or identified based on the paging control fields in the structured document model. Some document formats (such as Markdown, LaTeX, and XML) have explicit syntax for paging break markers, allowing the parsing module to directly locate the break points. The start and end nodes of a page can be determined based on a document structure traversal algorithm. Common methods include depth-first search to locate the first and last content nodes and generate a content index path to ensure content integrity and node order consistency. Page content fragment extraction can utilize DOM subtree pruning, structure mapping cache replication, or a blockchain-based double-pointer extraction strategy to ensure the integrity of the page structure and support subsequent style rendering. Subtask units can be created using a class structure maintained in a memory object. The structure fields include: content fragment, template index, initial processing status value, timestamp, and resource reference list. Subtask identifiers are generated by hashing the task ID and page number. An example is: TASK123#PAGE005. The template index binding can be implemented with the help of the template routing table in the task context. The page number of each subtask unit is used as the key value to match the corresponding template path and store it in the style binding table inside the unit for subsequent use by the style engine.

[0157] This embodiment precisely splits the intermediate document structure into independent subtask units based on the page dimension, assigns a uniquely identifiable subtask identifier to each subtask, and pre-binds the corresponding page template index, so that subsequent subtask processing can be efficiently executed in a parallel, structured, and style-standardized manner, thereby improving the scalability of the document generation task, processing efficiency, and structural consistency of the final page presentation.

[0158] In one embodiment, the above step S50 includes:

[0159] S501, obtaining a corresponding template file from a template resource library according to the page template index associated with the subtask by the document processing module;

[0160] S502, parsing the layout definition and placeholder structure in the template file;

[0161] S503, initializing page layout parameters according to the layout definition;

[0162] S504, filling the page content fragment in the subtask into the template file according to the placeholder structure;

[0163] S505: Performing a style rendering operation on the filled template file based on the page layout parameters to generate formatted page content. When the style rendering operation is completed, obtaining the current system time as a completion timestamp and updating the processing status of the corresponding subtask;

[0164] S506: Store the processing status of the subtask, the formatted page content, and the completion timestamp in a status buffer in a key-value pair format.

[0165] In this embodiment, after receiving a subtask, the document processing module retrieves the template file corresponding to the page template index bound to the subtask from the template resource library. The page template index is a predefined structure identifier, commonly in the form of template codes, file path references, template classification keys, etc., used to quickly locate the target template in the template resource library. The template resource library can contain a collection of structured templates that predefine the page layout, placeholder fields, and style rules, and can be adapted for different types of document output targets.

[0166] After the template file is loaded, the document processing module will parse the layout structure defined in it, including the arrangement order of element blocks, margin parameters, image and text distribution areas, color settings, header and footer areas, and functional components. The placeholder structure is a replaceable field tag in the template, representing the content injection point that will be replaced by content data at runtime. Common forms include {{text_block}}, [image_slot], <data:table>etc. syntax.

[0167] Page layout parameters are extracted and initialized based on the parsed layout definition to control page rendering. This parameter set typically includes, but is not limited to, margins (top, bottom, left, and right), column styles (single, double, proportional), font configuration (font type, size, weight, and line spacing), and can be extended to advanced formatting parameters such as color themes and content block spacing. These parameters are maintained consistently at the template level to ensure consistent and controllable page rendering.

[0168] Page content fragments are the core data blocks extracted from subtasks, including structured graphic content, table data, image links, and other information. The system then populates these fragments into the template, one by one, according to the fields defined in the placeholder structure, completing content injection. This process may involve content truncation, restyling, and template area expansion to ensure structural adaptability and page visibility.

[0169] The populated template file serves as the page rendering input, and the document processing module invokes the style rendering engine to render the file. The rendering process is based on the previously initialized page layout parameters, including formatting paragraph alignment, adaptive image scaling, table reconstruction, and style reuse, ultimately generating formatted page content with output quality. Upon rendering completion, the current system time is retrieved as the subtask's completion timestamp, and the subtask's processing status is updated based on the processing result. The status enumeration includes "processing," "completed," or "failed," facilitating subsequent polling and result push.

[0170] After rendering, each subtask generates a key-value pair record. The structure uses the subtask identifier as the primary key and includes fields for processing status, formatted page content data, and a completion timestamp. Formatted page content is typically stored in a structured, compressed format to support fast loading and subsequent decompression. This record is written to the status cache for on-demand loading on the user side and for unified scheduling during the final document synthesis phase.

[0171] By combining template indexes, content fragments, and page layout parameters, this embodiment enables the document processing module to handle subtasks in a highly templated and standardized manner, significantly reducing page rendering complexity and improving the parallel efficiency and consistency of each page generation. Furthermore, by recording rendering results and processing status in a state cache, the document generation process is asynchronous and progressively loaded, optimizing overall task execution performance and enhancing the system's ability to handle large-scale concurrent tasks.

[0172] In one embodiment, after the above step S50, the method further includes:

[0173] S507, when it is detected that the processing status of any subtask is changed to completed, a status event associated with the subtask identifier of the subtask with the processing status of completed is generated;

[0174] S508, encapsulating the status event into a message queue data packet, wherein the message queue data packet includes the subtask identifier, processing status, and completion timestamp of the subtask with a processing status of completed;

[0175] S509: Push the message queue data packet to the user terminal through the pre-established long connection channel, and determine whether the message queue data packet is pushed successfully;

[0176] S510, if the push fails, record the number of retries and the last attempt timestamp of the unsuccessful push event corresponding to the subtask identifier of the subtask with a processing status of completed;

[0177] S511, regenerating a message queue data packet according to a preset retry strategy, wherein the regenerated message queue data packet includes the subtask identifier, processing status, completion timestamp, and current retry count mark of the subtask with a processing status of completed;

[0178] S512: Execute a push operation on the regenerated message queue data packet until the maximum number of retries is reached or the push succeeds.

[0179] In this embodiment, after completing a subtask, the document processing module detects whether the subtask's processing status has changed. Subtask processing statuses include "Processing," "Completed," and "Failed." These statuses are dynamically updated based on the execution results returned by the rendering engine. Status change detection is typically implemented through event triggering or periodic scanning. Each time the status field changes from "Processing" to "Completed," the system identifies it as a "valid completion status change event."

[0180] Status events are structured data objects associated with completion status changes. They carry the current subtask's identifier and its latest processing status field, along with a task completion timestamp. Subtask identifiers are generated by concatenating the task identifier and the page sequence number, allowing precise tracking of subtask origin within the global task context. Timestamps are generated based on the system time of task completion and can be recorded in ISO8601 or millisecond-level Unix time format, facilitating sorting and retry record comparison.

[0181] Message queue packets are data structures used for asynchronous communication, encapsulated by the system based on status events. Packet fields include subtask identifiers, processing status, completion timestamps, and, during retries, an extended "current retry count" field. Each packet is serialized into a transportable format such as JSON, protobuf, or Avro during push, and a signature or digest field is appended for data integrity verification.

[0182] The client maintains a communication link with the server through a persistent connection, which can be implemented using WebSocket, Server-Sent Events, or HTTP / 2. Push operations send data packets to the target user's session in a non-blocking manner. Receiving the data on the client triggers a front-end refresh or local cache update.

[0183] If a push fails, the system records the failure event under the subtask identifier, including the current retry count and the timestamp of the last push attempt. The record structure uses a key-value mapping to support fast retrieval and writing, usually supported by a cache service such as Redis or an in-memory hash table.

[0184] The preset retry policy defines the recovery logic for failed pushes, including parameters such as the maximum number of retries, the minimum retry interval, and an exponential backoff factor. Regenerated packets will have a retry count field appended to the original packet and the push timestamp reset. The system can be configured to execute the next push within a specified time window and stop after the maximum number of attempts is reached or a success is achieved.

[0185] Retry push operations support synchronous and asynchronous mechanisms, and are usually combined with task scheduling systems (such as timers and message queue consumers) to control execution to ensure that message delivery is eventually achieved, improve the availability of task feedback and the reliability of the notification mechanism.

[0186] This embodiment automatically generates status events upon subtask completion and asynchronously pushes them to the user. This not only enables real-time notification of the task processing process, improving user experience and responsiveness, but also avoids the waste of system resources caused by client polling. Furthermore, the structured encapsulation and retry mechanism of message queue data packets effectively improves the delivery rate of task notifications and system stability. Combined with a retry strategy, fault tolerance can be implemented in the event of network instability or temporary client offline conditions, enhancing the overall robustness and availability of the system.

[0187] In one embodiment, the above step S80 includes:

[0188] S801, parsing the access request of the user terminal, and extracting the target subtask identifier and the user terminal session token from the access request;

[0189] S802, verifying the legitimacy of the user-side session token, and checking whether the target subtask identifier is accessible in the subtask identifier set;

[0190] S803: If the verification is successful, query the status cache for a key-value pair record corresponding to the target subtask identifier, wherein the key-value pair record includes a mark indicating that the processing status is completed and a page data block;

[0191] S804: If the key-value pair record exists and the processing status is completed, decompress the page data block to generate renderable page content;

[0192] S805: Encapsulate the renderable page content and the target subtask identifier into an access response data packet, and return the access response data packet to the user terminal through the persistent connection channel associated with the user terminal session token.

[0193] In this embodiment, a user-side access request is typically initiated dynamically after a task is created, intending to access the content of a specific page within the completed task. The access request carries the target subtask identifier and the user-side session token. The target subtask identifier indicates the page number or logical fragment to be accessed, and the user-side session token represents the identity of the initiator of the current request. This session token can be derived from a pre-established login session, a token authentication mechanism, or a device fingerprint authentication mechanism.

[0194] After receiving an access request, the system first parses it, extracting key fields and verifying their validity. Verification of a subtask ID primarily involves two steps: confirming whether the ID exists within the set of completed subtask IDs and verifying whether the user has access rights to the ID. This permission model is typically implemented by comparing the user ID associated with task creation with the token ID associated with the request.

[0195] If verification passes, the system queries the status cache for the data entry corresponding to the subtask ID in the form of a key-value pair. The status cache is implemented using a distributed cache system such as Redis, Memcached, or local shared memory. Each cache record is keyed by the subtask ID, and the record value contains the processing status field, the formatted page data block, and the data generation timestamp (i.e., the subtask completion timestamp).

[0196] If the cache record exists and is marked as "Complete," the page data has been generated and is available for access. The system then decompresses the page data block. Compression mechanisms may include GZIP, LZ4, ZSTD, and others, primarily to reduce resource usage during data transmission and caching. Decompression restores the renderable page content, which can be represented as HTML, rich text, a PowerPoint presentation, an image stream, or a JSON object.

[0197] Finally, the system encapsulates the page content and subtask identifier into a response data packet. This data packet is organized in a structured format, with fields including page content, subtask identifier, and status information. The response data packet is transmitted back to the client via a persistent connection channel bound to the user's session token, ensuring timely and secure data transmission. Persistent connections can be implemented over WebSocket, SSE, or HTTP / 2, providing bidirectional communication capabilities and a persistent connection state.

[0198] This embodiment uses a pull mode where the user initiates access requests, combined with a backend cache query and data decompression mechanism, to achieve instant return and on-demand loading of specific page content, avoiding the delays and system resource pressure caused by loading all content at once. Access control and session token verification mechanisms effectively ensure the legitimacy of data access and isolate user data, improving system security and stability. The introduction of compression and caching mechanisms reduces storage and transmission loads, while combining long connection push methods to ensure real-time data return and network efficiency.

[0199] In one embodiment, the above step S90 includes:

[0200] S901, polling and checking the list of completed subtask identifiers in the status buffer area to obtain the total number of currently completed subtask identifiers;

[0201] S902, comparing the total number of currently completed subtask identifiers with the total number of allocated subtask identifiers to see if they are equal;

[0202] S903: If the total number of currently completed subtask identifiers is equal to the total number of allocated subtask identifiers, terminate sending the status query request to the document processing module;

[0203] S904, extracting all associated page contents from the status buffer in order according to the page sequence numbers of the subtask identifiers in the completed subtask identifier list;

[0204] S905, performing a global typesetting and synthesis operation on the extracted page content to generate a complete document;

[0205] The complete document is stored in a document persistent storage area, and a document generation completion notification is sent to the user terminal.

[0206] In this embodiment, the document generation process utilizes an asynchronous subtask processing mechanism. The system must merge each subtask to generate the final document after completion. To this end, a polling-based completion status detection logic is implemented. This polling check relies on a real-time updated list of completed subtask identifiers in the status cache. This list is periodically retrieved from the document processing module via status query requests and synchronously written to the cache. The total number of completed subtask identifiers currently in this list serves as a key indicator of task execution progress.

[0207] At the same time, the system maintains a baseline value for the total number of subtask identifiers. This value is usually determined by the intermediate document structure during the splitting phase, corresponds one-to-one to the number of subtasks, and is usually registered in the task context or task scheduling controller when the task is initialized.

[0208] When the system determines that the total number of currently completed subtasks is equal to the total number of initially allocated subtask identifiers, it means that all page processing work has been completed. At this time, the status query request can be terminated to release the load channel of the document processing module and prevent redundant status pulling from continuously occupying system resources.

[0209] The page consolidation operation is based on the page sequence number field embedded in the subtask identifier. This field can be a sequence code, a structure tag, or a physical page number defined in the document. The corresponding formatted page content is extracted from the status buffer based on the number. The extraction order remains consistent with the final document structure to ensure document restoration accuracy.

[0210] The merged page content undergoes a global layout synthesis operation. This operation reconstructs a unified document skeleton and populates the page data based on the document format requirements and page template specifications set during task initialization. Layout synthesis not only includes page splicing but also involves global rendering operations such as table of contents generation, page numbering, unified style application, and cross-page object alignment.

[0211] The final, complete document is written to a persistent storage area, which can be an object store, document database, or file system, to support subsequent document preview, download, or archiving. To ensure timely access, the system also pushes a document generation completion message to the user via an asynchronous event or notification mechanism. This message can trigger a user interface refresh or the activation of the download portal.

[0212] Example: In financial business scenarios, commercial banks or insurance companies often need to periodically generate financial analysis reports, credit rating materials, or investment and financing proposals for corporate clients. For example, in a commercial bank's credit risk control system, when a corporate client submits a loan application, the system automatically initiates a document processing request. This request includes the client's business data source identifier and the required proposal format. The system generates a task identifier and, based on this identifier, creates task parameters, including a page template index (e.g., financing summary template, solvency template) and a priority level (e.g., credit approval takes precedence over due diligence archiving tasks). The task is then sent to the document processing module. The document processing module extracts structured data and attachments from the company's internal credit review database, credit reporting interface, and customer history tables to construct an intermediate document structure encompassing structural elements such as financing background, financial trends, and risk summary. Based on the logical page breaks in the intermediate structure, the system extracts content fragments from each page, such as "Company Profile" on page one, "Financial Trends for the Last Three Years" on page two, and "Risk Radar Chart" on page three. Each page is assigned a unique subtask identifier and bound to its own page template file. After each subtask is processed by the parallel rendering engine, the processing status and generated page content are written to the status cache in real time. The task status management module polls the document processing module every two seconds to obtain the completed subtask identifiers and update the subtask list accessible to the user front-end. Based on the feedback, the account manager can view the generated content of the first two pages and preview some report pages to improve the efficiency of approval decisions. If the user attempts to access an unfinished page, the system will verify the identifier set and return a prompt. When it detects that all subtasks have been completed, the system automatically terminates the polling request, extracts all page content by page sequence number, and performs global typesetting, template unification, and footer annotation operations to generate a financing plan with complete structure and unified format. The final document will be persisted to the document storage area and automatically trigger a task completion notification. Users can view or download the complete report with one click in the client interface, completing the end-to-end automatic document generation process.

[0213] In the healthcare sector, health management platforms provide user-level health reporting services for physical examination centers, insurance underwriting systems, or chronic disease management programs. After a patient completes a physical examination, the system initiates a document processing request, which includes the user ID, data interface ID, and report type (e.g., a graphic-based physical examination report, a nutritional intervention PPT, etc.). The system generates a task identifier and creates task parameters, including a chart priority strategy (e.g., prioritizing abnormal indicator pages) and template types (e.g., a basic physical examination template, a children's growth template). The document processing module extracts blood routine, BMI trends, exercise and sleep data from electronic medical records, physical examination systems, or wearable device data platforms to construct a standardized intermediate document structure. This intermediate structure is broken down into multiple subtask units based on indicator classification and recommended rendering paths, such as "Cardiovascular Indicator Analysis," "Chronic Disease Risk Prediction," and "Lifestyle Recommendations." Each subtask is associated with a corresponding template style (e.g., an electrocardiogram template, a line trend chart template), assigned a subtask identifier, and written to the scheduling system. After the page rendering task is completed on the backend, the processing status, formatted page content, and completion timestamp are stored in the status cache for client access. Health consultants or users themselves can access the generated pages in real time, for example, to view high-risk items or key recommendations first. The task processing module encapsulates the processing completion status into an event message and pushes it to the user-side H5 interface or the App health card entrance to improve the timeliness of interaction. When all pages are processed, the platform extracts the page content in sequence according to the task identifier set, merges and generates a complete PDF physical examination report, and generates a QR code link and a user return visit node. The complete document is uploaded to the health record system and used as a reference for insurance product conditions or subsequent intervention recommendations. Through this mechanism, the system supports large-scale, low-latency, and highly customized health data-driven document generation processes, which are widely applicable to medical examinations, health assessments, and remote health management services.

[0214] This embodiment effectively determines the completion time of the entire document task processing process by detecting the consistency between the number of completed subtasks and the total number of tasks, thereby avoiding redundant consumption of status query requests. After the task is completed, the page extraction logic driven by the sequential numbering ensures the accuracy of the document content integration. At the same time, the typesetting synthesis mechanism uniformly renders all pages into a complete structured document to meet the needs of subsequent display and archiving. After the generation is completed, the system immediately pushes a notification to the user end to achieve closed-loop feedback on the document visualization status, which improves the overall generation efficiency, resource utilization and user experience stability.

[0215] In one embodiment, an intelligent document processing device is provided, which corresponds one-to-one to the intelligent document processing method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the intelligent document processing device of the present invention. It includes a request receiving module 10, a task scheduling module 20, a data construction module 30, a task splitting module 40, a subtask processing module 50, a status query module 60, a permission update module 70, a content loading module 80, and a document synthesis module 90. Each functional module is described in detail below:

[0216] The request receiving module 10 is used to receive a document processing request initiated by a user terminal and generate a task identifier corresponding to the document processing request;

[0217] A task scheduling module 20, configured to create a document processing task based on the task identifier and send the document processing task to a document processing module;

[0218] A data construction module 30 is configured to obtain raw data through the document processing module based on the document processing task, and to construct an intermediate document structure based on the raw data;

[0219] A task splitting module 40 is configured to generate a plurality of subtasks based on the intermediate document structure through the document processing module, and assign a subtask identifier to each subtask;

[0220] The subtask processing module 50 is used to process the subtasks through the document processing module and store the processing status of each subtask and the generated page content in the status buffer;

[0221] A status query module 60 is configured to send a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers;

[0222] The permission updating module 70 is used to update the subtask identifier set accessible to the user terminal according to the completed subtask identifier list;

[0223] a content loading module 80 for responding to a request initiated by a user terminal for accessing a target subtask identifier in the subtask identifier set, and loading a page content associated with the target subtask identifier from the state cache;

[0224] The document synthesis module 90 is configured to terminate the status query request and integrate the loaded page contents to generate a complete document when it is detected that the completed subtask identifier list contains all subtask identifiers.

[0225] In one embodiment, the task scheduling module 20 is specifically configured to:

[0226] Generating document processing task parameters associated with the task identifier, wherein the document processing task parameters include document format requirements and page template indexes, and the task identifier includes an original data source identifier;

[0227] Determine the task execution priority according to the document format requirements;

[0228] Sending the document processing task including the original data source identifier, task identifier, task execution priority and page template index to the document processing module;

[0229] A task reception confirmation signal returned by the document processing module is received, and the task reception confirmation signal is associated with the task identifier and stored.

[0230] In one embodiment, the task splitting module 40 is specifically configured to:

[0231] Parsing page segmentation marks of the intermediate document structure;

[0232] Determining the start node and the end node of each page in the intermediate document structure according to the page segmentation mark;

[0233] Extracting a page content segment of a corresponding page in the intermediate document structure based on the start node and the end node of each page;

[0234] Creating corresponding subtask units based on the page content fragments, and generating a unique subtask identifier for each subtask unit;

[0235] The subtask unit is associated and bound with the corresponding page template index in the document processing task.

[0236] In one embodiment, the subtask processing module 50 is specifically configured to:

[0237] Obtaining the corresponding template file from the template resource library according to the page template index associated with the subtask by the document processing module;

[0238] Parsing the layout definition and placeholder structure in the template file;

[0239] Initialize page layout parameters according to the layout definition;

[0240] Filling the page content fragment in the subtask into the template file according to the placeholder structure;

[0241] Performing a style rendering operation on the filled template file based on the page layout parameters to generate formatted page content; when the style rendering operation is completed, obtaining the current system time as a completion timestamp, and updating the processing status of the corresponding subtask;

[0242] The processing status of the subtask, the formatted page content and the completion timestamp are stored in the status buffer in a key-value pair format.

[0243] In one embodiment, the subtask processing module 50 is specifically configured to:

[0244] When it is detected that the processing status of any subtask is changed to completed, a status event associated with the subtask identifier of the subtask with the processing status of completed is generated;

[0245] Encapsulating the status event into a message queue data packet, wherein the message queue data packet includes a subtask identifier, a processing status, and a completion timestamp of the subtask with a processing status of completed;

[0246] Pushing the message queue data packet to the user end through a pre-established long connection channel, and determining whether the message queue data packet is pushed successfully;

[0247] If the push fails, record the number of retries and the last attempt timestamp of the unsuccessful push event corresponding to the subtask ID of the subtask with the processing status of completed;

[0248] Regenerate a message queue data packet according to a preset retry strategy, wherein the regenerated message queue data packet includes a subtask identifier, a processing status, a completion timestamp, and a current retry count mark of the subtask with a processing status of completed;

[0249] Execute the push operation of the regenerated message queue data packet until the maximum number of retries is reached or the push succeeds.

[0250] In one embodiment, the content loading module 80 is specifically configured to:

[0251] Parsing the access request of the user terminal, and extracting the target subtask identifier and the user terminal session token from the access request;

[0252] Verify the legitimacy of the user-side session token and check whether the target subtask identifier is accessible in the subtask identifier set;

[0253] If the verification is successful, query the state cache for a key-value pair record corresponding to the target subtask identifier, wherein the key-value pair record includes a mark indicating that the processing state is completed and a page data block;

[0254] If the key-value pair record exists and the processing status is completed, decompress the page data block to generate renderable page content;

[0255] The renderable page content and the target subtask identifier are encapsulated into an access response data packet, and the access response data packet is returned to the user terminal through a long connection channel associated with the user terminal session token.

[0256] In one embodiment, the document synthesis module 90 is specifically configured to:

[0257] Polling and checking the list of completed subtask identifiers in the status buffer area to obtain the total number of currently completed subtask identifiers;

[0258] Comparing whether the total number of currently completed subtask identifiers is equal to the total number of allocated subtask identifiers;

[0259] If the total number of currently completed subtask identifiers is equal to the total number of allocated subtask identifiers, then terminating the sending of the status query request to the document processing module;

[0260] Extracting all associated page contents from the status buffer in sequence according to the page sequence numbers of the subtask identifiers in the completed subtask identifier list;

[0261] Perform global typesetting and synthesis operations on the extracted page content to generate a complete document;

[0262] The complete document is stored in a document persistent storage area, and a document generation completion notification is sent to the user terminal.

[0263] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of an intelligent document processing method.

[0264] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of an intelligent document processing method.

[0265] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0266] Receive a document processing request initiated by a user terminal, and generate a task identifier corresponding to the document processing request;

[0267] Creating a document processing task based on the task identifier, and sending the document processing task to a document processing module;

[0268] Based on the document processing task, obtaining original data through the document processing module, and constructing an intermediate document structure based on the original data;

[0269] Generate a plurality of subtasks based on the intermediate document structure by the document processing module, and assign a subtask identifier to each subtask;

[0270] Processing the subtasks through the document processing module, and storing the processing status of each subtask and the generated page content in a status buffer;

[0271] Sending a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers;

[0272] Updating the subtask identifier set accessible to the user terminal according to the completed subtask identifier list;

[0273] In response to an access request for a target subtask identifier in the subtask identifier set initiated by a user terminal, loading page content associated with the target subtask identifier from the state cache;

[0274] When it is detected that the completed subtask identifier list contains all subtask identifiers, the status query request is terminated and the loaded page contents are integrated to generate a complete document.

[0275] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0276] Receive a document processing request initiated by a user terminal, and generate a task identifier corresponding to the document processing request;

[0277] Creating a document processing task based on the task identifier, and sending the document processing task to a document processing module;

[0278] Based on the document processing task, obtaining original data through the document processing module, and constructing an intermediate document structure based on the original data;

[0279] Generate a plurality of subtasks based on the intermediate document structure by the document processing module, and assign a subtask identifier to each subtask;

[0280] Processing the subtasks through the document processing module, and storing the processing status of each subtask and the generated page content in a status buffer;

[0281] Sending a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers;

[0282] Updating the subtask identifier set accessible to the user terminal according to the completed subtask identifier list;

[0283] In response to an access request for a target subtask identifier in the subtask identifier set initiated by a user terminal, loading page content associated with the target subtask identifier from the state cache;

[0284] When it is detected that the completed subtask identifier list contains all subtask identifiers, the status query request is terminated and the loaded page contents are integrated to generate a complete document.

[0285] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0286] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0287] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0288] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.< / data:table>

Claims

1. An intelligent document processing method, characterized in that: The following steps are involved: Receive a document processing request initiated by a user terminal, and generate a task identifier corresponding to the document processing request; Creating a document processing task based on the task identifier, and sending the document processing task to a document processing module; Based on the document processing task, obtaining original data through the document processing module, and constructing an intermediate document structure based on the original data; Generate a plurality of subtasks based on the intermediate document structure by the document processing module, and assign a subtask identifier to each subtask; Processing the subtasks through the document processing module, and storing the processing status of each subtask and the generated page content in a status buffer; Sending a status query request to the document processing module at a preset time interval to obtain a list of currently completed subtask identifiers; Updating the subtask identifier set accessible to the user terminal according to the completed subtask identifier list; In response to an access request for a target subtask identifier in the subtask identifier set initiated by a user terminal, loading page content associated with the target subtask identifier from the state cache; When it is detected that the completed subtask identifier list contains all subtask identifiers, the status query request is terminated and the loaded page contents are integrated to generate a complete document.

2. The intelligent document processing method according to claim 1, wherein: Creating a document processing task based on the task identifier and sending the document processing task to a document processing module includes: Generating document processing task parameters associated with the task identifier, wherein the document processing task parameters include document format requirements and page template indexes, and the task identifier includes an original data source identifier; Determine the task execution priority according to the document format requirements; Sending the document processing task including the original data source identifier, task identifier, task execution priority and page template index to the document processing module; A task reception confirmation signal returned by the document processing module is received, and the task reception confirmation signal is associated with the task identifier and stored.

3. The intelligent document processing method according to claim 1, wherein: Generating a plurality of subtasks based on the intermediate document structure by the document processing module and assigning a subtask identifier to each subtask includes: Parsing page segmentation marks of the intermediate document structure; Determine the start node and end node of each page in the intermediate document structure according to the page segmentation mark; Extracting a page content segment of a corresponding page in the intermediate document structure based on the start node and the end node of each page; Creating corresponding subtask units based on the page content fragments, and generating a unique subtask identifier for each subtask unit; The subtask unit is associated and bound with the corresponding page template index in the document processing task.

4. The intelligent document processing method according to claim 1, wherein: Processing the subtasks by the document processing module and storing the processing status of each subtask and the generated page content in the status buffer area includes: Obtaining the corresponding template file from the template resource library according to the page template index associated with the subtask by the document processing module; Parsing the layout definition and placeholder structure in the template file; Initialize page layout parameters according to the layout definition; Filling the page content fragment in the subtask into the template file according to the placeholder structure; Performing a style rendering operation on the filled template file based on the page layout parameters to generate formatted page content; when the style rendering operation is completed, obtaining the current system time as a completion timestamp, and updating the processing status of the corresponding subtask; The processing status of the subtask, the formatted page content and the completion timestamp are stored in a status buffer in a key-value pair format.

5. The intelligent document processing method according to claim 1, wherein: After the subtasks are processed by the document processing module and the processing status of each subtask and the generated page content are stored in the status buffer, the method further includes: When it is detected that the processing status of any subtask is changed to completed, a status event associated with the subtask identifier of the subtask with the processing status of completed is generated; Encapsulating the status event into a message queue data packet, wherein the message queue data packet includes a subtask identifier, a processing status, and a completion timestamp of the subtask with a processing status of completed; Pushing the message queue data packet to the user end through a pre-established long connection channel, and determining whether the message queue data packet is pushed successfully; If the push fails, record the number of retries and the last attempt timestamp of the unsuccessful push event corresponding to the subtask ID of the subtask with the processing status of completed; Regenerate a message queue data packet according to a preset retry strategy, wherein the regenerated message queue data packet includes a subtask identifier, a processing status, a completion timestamp, and a current retry count mark of the subtask with a processing status of completed; Execute the push operation of the regenerated message queue data packet until the maximum number of retries is reached or the push succeeds.

6. The intelligent document processing method according to claim 1, wherein: In response to an access request initiated by a user terminal for a target subtask identifier in the subtask identifier set, loading page content associated with the target subtask identifier from the state cache area includes: Parsing the access request of the user terminal, and extracting the target subtask identifier and the user terminal session token from the access request; Verify the legitimacy of the user-side session token and check whether the target subtask identifier is accessible in the subtask identifier set; If the verification is successful, query the state cache for a key-value pair record corresponding to the target subtask identifier, wherein the key-value pair record includes a mark indicating that the processing state is completed and a page data block; If the key-value pair record exists and the processing status is completed, decompress the page data block to generate renderable page content; The renderable page content and the target subtask identifier are encapsulated into an access response data packet, and the access response data packet is returned to the user terminal through a long connection channel associated with the user terminal session token.

7. The intelligent document processing method according to claim 1, wherein: When it is detected that the completed subtask identifier list contains all subtask identifiers, the status query request is terminated and the loaded page content is integrated to generate a complete document, including: Polling and checking the list of completed subtask identifiers in the status buffer area to obtain the total number of currently completed subtask identifiers; Comparing whether the total number of currently completed subtask identifiers is equal to the total number of allocated subtask identifiers; If the total number of currently completed subtask identifiers is equal to the total number of allocated subtask identifiers, then terminating the sending of the status query request to the document processing module; Extracting all associated page contents from the status buffer in sequence according to the page sequence numbers of the subtask identifiers in the completed subtask identifier list; Perform global typesetting and synthesis operations on the extracted page content to generate a complete document; The complete document is stored in a document persistent storage area, and a document generation completion notification is sent to the user terminal.

8. An intelligent document processing device, characterized in that: The intelligent document processing device comprises: A request receiving module, configured to receive a document processing request initiated by a user terminal and generate a task identifier corresponding to the document processing request; A task scheduling module, configured to create a document processing task based on the task identifier and send the document processing task to a document processing module; A data construction module, configured to obtain raw data through the document processing module based on the document processing task, and to construct an intermediate document structure based on the raw data; A task splitting module, configured to generate a plurality of subtasks based on the intermediate document structure through the document processing module, and assign a subtask identifier to each subtask; A subtask processing module, configured to process the subtasks through the document processing module and store the processing status of each subtask and the generated page content in a status buffer; A status query module, configured to send a status query request to the document processing module at preset time intervals to obtain a list of currently completed subtask identifiers; A permission update module, configured to update a set of subtask identifiers accessible to the user terminal according to the list of completed subtask identifiers; a content loading module, configured to load, from the state cache, page content associated with a target subtask identifier in the subtask identifier set in response to an access request initiated by a user terminal to the target subtask identifier; The document synthesis module is configured to terminate the status query request and integrate the loaded page contents to generate a complete document when detecting that the completed subtask identifier list contains all subtask identifiers.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and an intelligent document processing program stored in the memory and executable on the processor. When the intelligent document processing program is executed by the processor, the steps of the intelligent document processing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores an intelligent document processing program, which, when executed by a processor, implements the steps of the intelligent document processing method according to any one of claims 1 to 7.

Images