Program document generation method and device, equipment, storage medium and product

Abstract

The invention provides a program document generation method and device, equipment, a storage medium and a product, and relates to the field of distribution. The method comprises the following steps: in response to a program document generation request sent by a client, determining a to-be-executed task based on the program document generation request; calling a distributed computing framework, and splitting the to-be-executed task into a plurality of sub-tasks according to the target splitting strategy; distributing the plurality of sub-tasks to each processing node in a distributed cluster through a message passing mechanism, so that each processing node executes the received sub-tasks in parallel; and receiving execution results returned by the processing nodes, summarizing the execution results returned by the processing nodes into a target processing result of the to-be-executed task, and returning the target processing result to the client, the target processing result including the program document. According to the method, the development difficulty and the long-term maintenance cost of the program document generation system can be reduced, and the ability of the system to deal with high-concurrency scenes is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of distribution, and in particular to a program document generation method and device, equipment, storage medium and product. BACKGROUND

[0002] The generation of various program documents (such as litigation materials, tender documents, medical documents, etc.) is not only a simple information transfer, but is also limited by the field characteristics of various program documents, and has complex and diverse characteristics. For example, when a financial institution needs litigation materials for loan collection, it needs to generate more than twenty kinds of litigation materials.

[0003] According to the traditional technical means, after the server receives the program document generation request sent by the client, the task is split into multiple sub-task threads and a result aggregation task thread, a result collection object is created, the sub-task thread is transmitted, the main task thread is suspended, the sub-task thread calls a remote service through a remote procedure call (RPC), and after the processing is completed, the result is assigned to the result collection object, and the aggregation result task is notified. After all sub-tasks are completed, the aggregation result task is started, and the main task is awakened. The main task gets the value of the result object, and returns to the client.

[0004] However, the prior art solution needs to manually manage sub-task threads and exception handling logic, has high development and maintenance cost, and the sub-tasks can only run on a single machine, cannot utilize distributed resources, and cause system crashes when high concurrency occurs, resulting in slow response speed of the server. SUMMARY

[0005] The present application provides a program document generation method, device, equipment, storage medium and product to solve the following technical problems in the prior art: the prior art solution needs to manually manage sub-task threads and exception handling logic, has high development and maintenance cost, and the sub-tasks can only run on a single machine, cannot utilize distributed resources, and cause system crashes when high concurrency occurs, resulting in slow response speed of the server.

[0006] In a first aspect, the present application provides a program document generation method, which comprises:

[0007] In response to a program document generation request sent by a client, determining a to-be-executed task based on the program document generation request;

[0008] Calling a distributed computing framework, and splitting the to-be-executed task into multiple sub-tasks according to a target splitting strategy;

[0009] Distributing the multiple sub-tasks to each processing node in a distributed cluster through a message passing mechanism, so that each processing node executes the received sub-tasks in parallel;

[0010] The system receives the execution results returned by each processing node, summarizes the execution results returned by each processing node into the target processing result of the task to be executed, and returns the target processing result to the client. The target processing result includes: program documents.

[0011] Secondly, this application provides a system for generating procedural documents, including: a service system cluster and a distributed cluster.

[0012] The service system cluster, in response to a program document generation request sent by the client, determines the task to be executed based on the program document generation request.

[0013] The service system cluster is used to call a distributed computing framework to split the task to be executed into multiple sub-tasks according to the target splitting strategy.

[0014] The service system cluster is also used to distribute the multiple subtasks to each processing node in the distributed cluster;

[0015] Each processing node in the distributed cluster is used to execute the received subtasks in parallel;

[0016] The service system cluster is also used to receive the execution results returned by each processing node, summarize the execution results returned by each processing node into the target processing result of the task to be executed, and return the target processing result to the client. The target processing result includes: program documents.

[0017] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0018] The memory stores computer-executed instructions;

[0019] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect.

[0020] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect.

[0021] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0022] The method, apparatus, equipment, storage medium, and product for generating procedural documents provided in this application have the following technical advantages:

[0023] 1. By utilizing a distributed computing framework and message passing mechanism to automate task scheduling and node communication, the complex and error-prone concurrency control code can be written manually, thereby reducing the difficulty of system development and long-term maintenance costs.

[0024] 2. By splitting the task to be executed into multiple subtasks and utilizing the parallel processing capabilities of the distributed cluster, multiple subtasks can be executed simultaneously on different processing nodes, thereby significantly shortening the total processing time of a single task and improving the server's response speed to high-concurrency requests.

[0025] 3. Since the subtasks are distributed to run on multiple nodes in the distributed cluster, the system's processing capacity is no longer limited by the performance of a single server. When the concurrency pressure increases, the system capacity can be horizontally expanded by increasing the number of cluster nodes, thereby avoiding system crashes in high-concurrency scenarios. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] Figure 1 A flowchart illustrating a method for generating procedural documents provided in an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of a distributed cluster architecture provided in an embodiment of this application;

[0029] Figure 3 This is a flowchart illustrating a method for splitting a task to be executed into multiple subtasks, as provided in an embodiment of this application.

[0030] Figure 4 This is a schematic diagram of the method for summarizing target processing results provided in the embodiments of this application;

[0031] Figure 5 This is a schematic flowchart of a method for timeout monitoring provided in an embodiment of this application;

[0032] Figure 6 A schematic diagram of the structure of the procedural document generation system provided in the embodiments of this application;

[0033] Figure 7 This is a schematic diagram of the electronic device structure provided in an embodiment of this application.

[0034] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0035] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0036] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0037] It should be noted that the method, apparatus, device, storage medium and product for generating procedural documents provided in this application can be used in the distributed field, or in any field other than the distributed field. The application field of the method, apparatus, device, storage medium and product for generating procedural documents in this application is not limited.

[0038] The generation of various procedural documents (such as litigation materials, bidding documents, medical documents, etc.) is not merely a simple transfer of information; rather, it is constrained by the domain-specific characteristics of each type of procedural document, exhibiting complex and diverse features. For example, when financial institutions need litigation materials for loan collection, they may need to generate more than twenty different types of litigation materials.

[0039] According to traditional technical methods, after the server receives the program document generation request sent by the client, it splits the task into multiple sub-task threads and a result aggregation task thread, creates a result collection object, passes it to the sub-task threads, suspends the main task thread, and the sub-task threads call remote services through remote procedure calls (RPC). After processing, the sub-task threads assign the result to the result collection object and notify the result aggregation task. After all sub-tasks are completed, the result aggregation task starts and wakes up the main task. The main task gets the value of the result object and returns it to the client.

[0040] However, existing technical solutions require manual management of subtask threads and exception handling logic, resulting in high development and maintenance costs. Furthermore, subtasks can only run on a single machine and cannot utilize distributed resources, which can lead to system crashes under high concurrency and slow server response.

[0041] To address the aforementioned technical problems, the inventors of this application have considered that a distributed computing framework can be used to automate complex manual thread management (such as thread creation, suspension, and waking) and resource scheduling tasks, thereby reducing the requirements for developers' concurrent programming capabilities and encapsulating technical complexity within the framework to achieve abstraction of processing logic. Furthermore, by distributing subtasks in parallel to different processing nodes, computing resources can be expanded to handle high-concurrency scenarios. Moreover, based on the distributed processing architecture, a message passing mechanism can be used as the communication method for subtask distribution and result collection, thus ensuring loose coupling between processing nodes, eliminating the need for direct calls to each other's interfaces, and supporting distributed deployment and execution of tasks.

[0042] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0043] Figure 1 This application provides a flowchart illustrating a method for generating procedural documents, which can be applied to a server, such as... Figure 1 As shown, the method includes:

[0044] S101. In response to the program document generation request sent by the client, determine the task to be executed based on the program document generation request;

[0045] After the business personnel enter the customer's three key elements (name, document type, and document number) into the front-end interface of the judicial collection system and trigger the generation operation, the client will send a request to the server to generate a procedural document (i.e., litigation materials). After receiving the request, the server can parse out the type of litigation materials to be generated. The types of litigation materials can include more than 20 kinds of materials such as complaint, list of evidence, and power of attorney, thereby determining the task to be executed - that is, generating a complete set of litigation materials based on the customer information.

[0046] S102. Call the distributed computing framework and, according to the target splitting strategy, split the task to be executed into multiple sub-tasks;

[0047] In this context, a distributed computing framework refers to a technical architecture that supports parallel processing of tasks across multiple computing nodes. In this embodiment, it could be, for example, the Akka framework. It should be noted that the Akka framework is an open-source toolkit and runtime environment based on the Actor model, used to build highly concurrent, distributed, fault-tolerant, event-driven applications on the JVM (Java Virtual Machine). The core of the Akka framework is the Actor model, which abstracts concurrent computing entities into Actors, where each Actor is a lightweight, independent unit that communicates with each other through message passing.

[0048] A target splitting strategy refers to a method or rule used to break down a task into multiple subtasks. For example, a target splitting strategy could be to split the task into multiple subtasks based on customer identification information.

[0049] A subtask is an independently executable task that is broken down from a task to be executed. For example, in a judicial debt collection scenario, the task to be executed, "generating litigation materials," can be broken down into subtasks such as "generating a complaint" and "generating a list of evidence."

[0050] Each subtask includes independent input parameters and processing logic. For example, when the subtask is to generate an evidence list, its input parameters include collection records, and the processing logic is to generate an evidence list based on the collection records.

[0051] In this step, after the server determines the task to be executed, it calls the integrated distributed computing framework, which provides the ability to split the task. That is, according to the preset target splitting strategy, the task to be executed is split into multiple subtasks of the smallest granularity that can be executed independently.

[0052] One approach to task decomposition is to break it down by type of litigation material. For instance, the task of generating a complete set of litigation materials can be divided into a series of subtasks such as "generating the complaint," "generating a list of evidence," and "generating a power of attorney." Each subtask is responsible for generating a specific type of litigation material. They all require the same input data (the three elements of the client's case), but their internal data processing logic and output formats are completely different. It should be noted that these subtasks are independent of each other and can be executed independently and in parallel.

[0053] S103. Distribute multiple subtasks to each processing node in the distributed cluster through a message passing mechanism, so that each processing node can execute the received subtasks in parallel.

[0054] After tasks are split, they can be distributed using the messaging mechanism provided by the Akka framework. Figure 2 This is a schematic diagram of the distributed cluster architecture provided in the embodiments of this application, such as... Figure 2As shown, specifically, the servers in the service system cluster can create task-splitting Actors. These Actors encapsulate each subtask into an independent, serializable message object. These messages are then asynchronously sent to the business processing system cluster, which consists of multiple processing nodes. Each processing node in the business processing system cluster has a corresponding business processing Actor running. The Akka framework's underlying routing mechanism (such as round-robin or random) evenly distributes subtask messages to different business processing Actors in the business processing system cluster. Each Actor, upon receiving a message, immediately begins executing its specific business logic. For example, an Actor receiving the "generate evidence list" message can call the corresponding template and data processing services to generate an evidence list document. Because messages are distributed in parallel, all subtasks begin processing almost simultaneously, thus achieving distributed parallel computing.

[0055] S104. Receive the execution results returned by each processing node, summarize the execution results returned by each processing node into the target processing result of the task to be executed, and return the target processing result to the client. The target processing result includes: program documents.

[0056] In this step, after the business processing Actor on the processing node completes its subtask, it returns the execution result (e.g., the generated PDF complaint file, evidence list file, etc.) to the task splitting Actor that initially issued the task via a message passing mechanism. The task splitting Actor internally maintains a result collector, which receives and temporarily stores the results of each returned subtask. Simultaneously, the result collector monitors whether all subtask results have been returned using a counter. Once it is confirmed that all subtasks have been successfully completed, the task splitting Actor can package and integrate all the collected individual litigation material files into a complete litigation material dossier, which is the target processing result of the aforementioned task. Finally, the server returns this result to the front-end client, allowing business personnel to download the complete litigation material package. Compared to the serial execution method, the entire processing time is reduced to the execution time of the slowest subtask.

[0057] The above-mentioned method for generating procedural documents has the following technical effects:

[0058] 1. By utilizing a distributed computing framework and message passing mechanism to automate task scheduling and node communication, the complex and error-prone concurrency control code can be written manually, thereby reducing the difficulty of system development and long-term maintenance costs.

[0059] 2. By splitting the task to be executed into multiple subtasks and utilizing the parallel processing capabilities of the distributed cluster, multiple subtasks can be executed simultaneously on different processing nodes, thereby significantly shortening the total processing time of a single task and improving the server's response speed to high-concurrency requests.

[0060] 3. Since the subtasks are distributed to run on multiple nodes in the distributed cluster, the system's processing capacity is no longer limited by the performance of a single server. When the concurrency pressure increases, the system capacity can be horizontally expanded by increasing the number of cluster nodes, thereby avoiding system crashes in high-concurrency scenarios.

[0061] Figure 3 This is a flowchart illustrating a method for splitting a task to be executed into multiple subtasks, as provided in an embodiment of this application. Figure 3 As shown, optionally, a distributed computing framework is invoked to split the task to be executed into multiple subtasks according to the splitting granularity of the target splitting strategy, including:

[0062] S301. Obtain the real-time load status of each processing node in the distributed cluster;

[0063] In this step, the task splitting Actor can use the cluster management function of the distributed computing framework to distribute tasks to a distributed cluster (e.g., Figure 2 In the business processing system cluster, each processing node sends a heartbeat detection or query request, and each processing node returns its current performance metrics, such as CPU utilization, memory usage, and the length of the task queue being processed. The task splitting Actor collects these metrics as the real-time load status of each processing node.

[0064] S302. Based on the real-time load status of each processing node, determine the current processing capacity level of the distributed cluster;

[0065] In this step, the task splitting actor can evaluate the collected load status according to preset rules, for example:

[0066] "High" processing capacity level: When more than 80% of the nodes have a central processing unit utilization rate of less than 60% and a short task queue, the cluster is considered to have sufficient processing capacity to handle more granular tasks.

[0067] Processing capacity level "medium": When most nodes are under medium real-time load, the processing capacity level is set to "medium".

[0068] Processing capacity level "low": When more than half of the nodes have high real-time load, the cluster processing capacity is considered to be strained, and communication overhead should be reduced and a coarser-grained task split should be adopted.

[0069] S303. From multiple preset splitting strategies, select the preset splitting strategy corresponding to the processing capability level as the target splitting strategy, wherein the splitting granularity of different preset splitting strategies is different.

[0070] Optionally, the granularity of segmentation includes: customer identification information, litigation document type, and litigation document content segment. The server can pre-configure multiple segmentation strategies, each corresponding to a different granularity (customer identification information, litigation document type, and litigation document content segment), and these strategies are linked to the processing capacity level. For example, a pre-configured segmentation strategy could be:

[0071] 1. If the processing capacity level is "high", then select the most granular "splitting by content section of litigation materials". For example, the task of generating a complaint can be broken down into multiple sub-tasks such as "preamble", "claims", "facts and reasons", "list of evidence", and "conclusion". This strategy can maximize parallel processing, but the large number of sub-tasks results in high communication overhead.

[0072] 2. If the processing capacity level is "Medium", then select "Split by Litigation Material Type". This is the default strategy, which splits the task of generating all litigation materials for a client into independent sub-tasks such as "Payment Order Application", "Complaint", "Power of Attorney", and "List of Evidence", with each sub-task generating a complete type of material.

[0073] Third, if the processing capacity level is "low", then select the coarsest option, "Split by Customer Identification Information". In this case, a batch generation request involving multiple customers is split into independent subtasks based on the customer dimension. Each subtask is responsible for generating a complete set of litigation materials for a single customer, thereby reducing the number of subtasks and the communication pressure within the cluster.

[0074] S304. According to the splitting granularity of the target splitting strategy, the task to be executed is split into multiple subtasks that can be executed independently.

[0075] In this step, based on the granularity of the determined target splitting strategy, the task to be executed can be segmented according to customer identification information, litigation material type, or litigation material content segment, generating multiple independently executable subtasks associated with the granularity of the target splitting strategy. Specifically, the task splitting actor can segment the complete litigation material compilation task according to the target splitting strategy determined in S303 (e.g., "splitting by litigation material type"). For example, when the target splitting strategy is "splitting by litigation material type," the task splitting actor parses the list of materials to be generated, creating an independent subtask message for each material type. Each subtask message contains all the data required to generate that type of material (such as customer information, case data, etc.), and because there are no dependencies between these subtasks, they can be processed independently and in parallel.

[0076] Figure 3 The method shown obtains the real-time load of the distributed cluster and dynamically adjusts the task splitting granularity to match the task complexity with the current processing capacity of the distributed cluster. Thus, under high load, coarse-grained splitting is used to reduce communication and management overhead and protect system stability; under low load, fine-grained splitting is used to make full use of idle resources and accelerate task processing, thereby maximizing the utilization of distributed cluster resources and improving the overall throughput of the system.

[0077] Furthermore, by using "customer identification information," "litigation material type," and "litigation material content section" as the granularity of the breakdown, Figure 3 The method shown can flexibly address different business needs in practical applications. For example, when it is necessary to quickly complete all materials for a single customer, it can be split "by material type"; when it is necessary to process a large number of customers in batches, it can be split "by customer identifier"; for a single complex document with extremely tight processing time, it can be split "by content section". Figure 3 The method shown can handle complex business scenarios.

[0078] Figure 4 This is a schematic diagram of the method for summarizing target processing results provided in the embodiments of this application, such as... Figure 4 As shown, optionally, the execution results returned by each processing node are received, and the execution results returned by each processing node are summarized into the target processing result of the task to be executed, including:

[0079] S401. After receiving the execution results returned by each processing node, the received execution results are summarized and processed to obtain the cached results;

[0080] In this step, after distributing subtasks to each processing node, the task splitting Actor can immediately create a result cache container (such as a set or mapping structure) and record the total number (N) of subtasks to be recycled. Simultaneously, the task splitting Actor can listen to a dedicated message queue. After each processing node completes a subtask, it can send a message containing the task ID and execution result to this message queue. Once the task splitting Actor's message receiver hears the message, it can parse the corresponding task ID and result and store them in the result cache container. A completion counter is incremented by 1 for each successfully received and cached result. At this point, the result cache container stores the intermediate state of all currently returned results.

[0081] S402. Based on the task execution time threshold, timeout monitoring is performed on each processing node in the distributed cluster. If any processing node times out, a retry or migration execution is triggered.

[0082] In this step, while the task splitting Actor has distributed all subtasks, an independent timeout monitoring timer can be started. It should be noted that the timeout threshold (task execution duration threshold) of this timeout timer can be preset based on historical data.

[0083] Specifically, in this step, the timeout timer runs independently and continuously checks whether the time elapsed since the task was initiated has exceeded a preset threshold. Simultaneously, the task splitting actor can continuously compare the number of received results with the total number of subtasks (N). Once the timer expires, and the number of results has not yet reached N (i.e., a processing node has timed out), a fault-tolerant process is immediately triggered, initiating a retry or migration execution. Retry or migration execution could be, for example:

[0084] Compare the received result IDs with the list of all subtask IDs to quickly locate the set of subtasks that have timed out and have not returned results;

[0085] The task splitting actor repackages these unfinished subtasks into new task messages. Furthermore, the task splitting actor can redistribute these tasks to other currently available processing nodes in the cluster for execution based on simple strategies (such as random selection) or by querying the real-time health status of cluster nodes, thereby achieving migration execution.

[0086] After a retry / migration is triggered, the task splitting actor can reset the timeout timer for this newly assigned subtask (or start a new monitoring cycle) to ensure that this newly assigned subtask can be completed within the new time.

[0087] Optionally, trigger a retry or migration execution, including:

[0088] Based on the execution results returned by each processing node, the processing node that timed out the execution of the subtask is determined as the timeout processing node;

[0089] Based on the mapping relationship between multiple subtasks and processing nodes, determine the subtasks to be executed that will be handled by the timeout processing node;

[0090] The subtask to be executed can be resent to the timeout handling node or migrated to another handling node for execution.

[0091] In the above method, the task splitting actor can use a task status mapping table to record the distribution timestamp of each subtask. At the same time, the task splitting actor periodically or each time it receives the result of a subtask checks the difference between the current time and the distribution timestamp. If the execution time of a subtask exceeds the preset task execution time threshold, the execution of the subtask is determined to have timed out.

[0092] Furthermore, based on the "subtask-ID-processing node-Actor" mapping relationship, the task splitting Actor can locate the specific business processing Actor (i.e., the timeout processing node) that executes this timeout subtask.

[0093] After identifying the timeout handling node, if the timeout is likely caused by temporary network jitter or a sudden high load on the timeout handling node, the task splitting actor can resend the original pending subtask message (containing task data and processing logic identifiers) to the same timeout handling node for retry. Simultaneously, the status timer for that subtask is reset, awaiting its next response. To avoid infinite retries, a maximum number of retries can be set.

[0094] In cases where the timeout processing node may have crashed, is under continuous high load and unable to process new tasks, or fails to retry, the task splitting Actor can use the routing mechanism of the Akka cluster to redistribute the subtask message to be executed to another healthy business processing Actor in the cluster. At the same time, it updates the internal "subtask-ID-processing node-Actor" mapping relationship to bind the subtask to the new processing node.

[0095] The retry and migration method described above locates the problematic task by utilizing the mapping relationship between multiple subtasks and processing nodes, and performs flexible retry or migration processing. This allows for rapid and targeted isolation and repair of faults, minimizing the impact of a single node failure on the overall task execution progress.

[0096] S403. If the timeout monitoring passes, the cached result will be used as the target processing result for the task to be executed.

[0097] Specifically, timeout monitoring is considered successful if and only if both of the following conditions are met:

[0098] Condition 1: The number of received results equals the total number of subtasks (N);

[0099] Condition 2: At the moment when condition 1 is met, the total execution time has not exceeded the timeout threshold.

[0100] If the timeout monitoring passes, all subtasks can be considered successfully completed. The task splitting actor can then perform a final aggregation of all intermediate results summarized in the result cache container (such as merging documents, generating lists, etc.) to form the complete target processing result (i.e., the program documentation). Finally, the task splitting actor returns this target processing result to the client that initially issued the request.

[0101] Figure 4 The method shown has the following technical effects:

[0102] 1. By introducing independent timeout monitoring and automated retry / migration mechanisms, it can handle abnormal situations such as node failure and network latency. Even if some nodes fail, subtasks can still be completed through task transfer, thereby avoiding single point of failure from causing the entire task to fail.

[0103] 2. By employing a "summarize-monitor-confirm" process, the final target processing result is generated only after all subtasks have successfully returned results. This mechanism effectively prevents the generation of incomplete or erroneous procedural documents due to missing data, making it suitable for scenarios with extremely high requirements for document accuracy, such as judicial debt collection.

[0104] Optionally, the cached result can be used as the target processing result of the task to be executed, including:

[0105] By using a distributed transaction mechanism, the consistency of the execution results returned by each processing node is checked based on multiple sub-tasks to obtain the consistency check result.

[0106] If the consistency check result indicates that the consistency check passed, the cached result will be determined as the target processing result of the task to be executed.

[0107] If the consistency check result indicates that the consistency check failed, a compensation operation is triggered.

[0108] Specifically, the task splitting actor can temporarily store the execution results of all collected subtasks in a temporary cache result set. Subsequently, the task splitting actor can initialize a distributed transaction. The context of this transaction can include, for example, all subtask IDs of this main task, the expected number of results, and the business verification rules for the results of each subtask (e.g., legal chapters or data fields that certain documents must include).

[0109] Next, the task-splitting actor can initiate a consistency verification request to all processing nodes through a distributed computing framework. For example, the verification content includes:

[0110] Integrity check: Verify that the number of received results is completely consistent with the number of issued subtasks;

[0111] Business logic validation: Based on predefined rules, validate the logical correctness of each result data. For example, in a judicial debt collection case compilation scenario, validate whether key information such as customer names and ID numbers are consistent across different materials;

[0112] Data format validation: Ensures that the returned data format meets expectations and can be successfully summarized and assembled;

[0113] If all validations pass, the task splitting actor commits the transaction, setting the cached result as the final target processing result for the tasks to be executed in this round. Then, the task splitting actor can return this complete and consistent set of litigation materials to the server, which then responds to the client.

[0114] If any verification step fails (e.g., a subtask result is missing, data is contradictory, or the format is incorrect), the consistency verification is deemed to have failed, and a compensation operation is triggered. The compensation operation may include, for example:

[0115] Automatically correct some correctable errors, such as re-requesting specific data;

[0116] Subtasks that fail validation are marked and added back to the processing queue for execution by an idle business processing actor. At the same time, cached incomplete or erroneous result sets can be discarded or rolled back to ensure that the data state does not become chaotic.

[0117] The method described above, which uses cached results as the target processing result for tasks to be executed, introduces a distributed transaction mechanism for consistency verification. This prevents data incompleteness and inconsistency caused by network fluctuations, node failures, or program anomalies. In applications requiring high accuracy, such as legal documents, this method ensures the legal validity of the generated materials.

[0118] Figure 5 This is a schematic flowchart of a method for timeout monitoring provided in an embodiment of this application, as shown below. Figure 5 As shown, optionally, based on a task execution duration threshold, timeout monitoring is performed on each processing node in the distributed cluster, including:

[0119] S501. Based on the time difference between the current time node and the distribution time node of multiple sub-tasks, determine the current execution duration of each processing node;

[0120] In this step, after the task splitting Actor successfully distributes multiple subtasks to each processing node, a monitoring context can be created for the batch of subtasks. This monitoring context can record: the distribution timestamp, the total number of subtasks pending results counter, the task execution time threshold, and a set for caching returned results.

[0121] Meanwhile, the server can continuously calculate the time difference from the time of distribution to the current time. The time difference is equal to the current time minus the time of distribution, and is used as the current execution time of all subtasks.

[0122] S502. Determine if the current execution time is less than the task execution time threshold;

[0123] If so, execute S503, record the number of received execution results, and if the number of received execution results is consistent with the number of multiple subtasks, determine that the timeout monitoring has passed;

[0124] Specifically, in S503, if the current execution time has not expired, the number of execution results received is immediately checked and compared with the total number of subtasks (N). If the number of execution results received is consistent with the total number of subtasks, it means that all subtasks have successfully returned results, and the timeout monitoring is deemed to have passed.

[0125] If not, execute S504 to determine if the execution time of the pending task has expired.

[0126] Figure 5 The method shown introduces a task execution time threshold, setting a time limit for the execution of each task. This prevents the entire user request from becoming unresponsive due to indefinite blocking or extreme delays in individual subtasks, thus improving the user experience.

[0127] Figure 6 A schematic diagram of the system structure for generating procedural documents provided in this application embodiment, as shown below. Figure 6 As shown, the system 60 includes: a service system cluster 601 and a distributed cluster 602.

[0128] Service system cluster 601 responds to the program document generation request sent by the client and is used to determine the task to be executed based on the program document generation request;

[0129] Service system cluster 601 is used to call the distributed computing framework and split the task to be executed into multiple sub-tasks according to the target splitting strategy;

[0130] The service system cluster 601 is also used to distribute multiple subtasks to the processing nodes in the distributed cluster 602;

[0131] Each processing node in the distributed cluster 602 is used to execute the received subtasks in parallel;

[0132] Service system cluster 601 is also used to receive the execution results returned by each processing node, summarize the execution results returned by each processing node into the target processing result of the task to be executed, and return the target processing result to the client. The target processing result includes: program documents.

[0133] Figure 7 This is a schematic diagram of the electronic device structure provided in the embodiments of this application, such as... Figure 7 As shown, the device 70 includes at least one processor 701 and a memory 702. Optionally, the device 70 also includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0134] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0135] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0136] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0137] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0138] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0139] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0140] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0141] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0142] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0143] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0144] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0145] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0146] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0147] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0148] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0149] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0150] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0151] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for generating procedural documents, characterized in that, The method includes: In response to a program document generation request sent by the client, determine the task to be executed based on the program document generation request; The distributed computing framework is invoked to split the task to be executed into multiple subtasks according to the target splitting strategy; The multiple subtasks are distributed to each processing node in the distributed cluster through a message passing mechanism, so that each processing node can execute the received subtasks in parallel. The system receives the execution results returned by each processing node, summarizes the execution results returned by each processing node into the target processing result of the task to be executed, and returns the target processing result to the client. The target processing result includes: program documents.

2. The method according to claim 1, characterized in that, The aforementioned call to the distributed computing framework, according to the granularity of the target splitting strategy, divides the task to be executed into multiple sub-tasks, including: Obtain the real-time load status of each processing node in the distributed cluster; Based on the real-time load status of each processing node, the current processing capacity level of the distributed cluster is determined. From multiple preset splitting strategies, a preset splitting strategy corresponding to the processing capability level is selected as the target splitting strategy, wherein different preset splitting strategies have different splitting granularities; According to the granularity of the target splitting strategy, the task to be executed is split into multiple independently executable subtasks.

3. The method according to claim 2, characterized in that, The procedural documents include: litigation materials; the granularity of the breakdown includes: customer identification information, litigation material type, and litigation material content segment; the distributed computing framework is invoked to break down the task to be executed into multiple sub-tasks according to the target breakdown strategy, including: Based on customer identification information, litigation material type, or litigation material content segment, the task to be executed is segmented to generate multiple independently executable sub-tasks associated with the segmentation granularity of the target segmentation strategy.

4. The method according to claim 1, characterized in that, The step of receiving the execution results returned by each processing node and summarizing the execution results returned by each processing node into the target processing result of the task to be executed includes: After receiving the execution results returned by each processing node, the received execution results are aggregated and processed to obtain the cached results; Based on the task execution time threshold, timeout monitoring is performed on each processing node in the distributed cluster. If any processing node times out, a retry or migration execution is triggered. If the timeout monitoring passes, the cached result will be used as the target processing result for the task to be executed.

5. The method according to claim 4, characterized in that, The timeout monitoring of each processing node in the distributed cluster based on a task execution duration threshold includes: Based on the time difference between the current time node and the distribution time node of the multiple sub-tasks, the current execution duration of each processing node is determined; It is determined that the current execution time is less than the task execution time threshold; If so, record the number of received execution results. If the number of received execution results is consistent with the number of the multiple subtasks, the timeout monitoring is deemed to have passed. If not, then the execution time of the task to be executed has expired.

6. The method according to claim 5, characterized in that, The triggering of retry or migration execution includes: Based on the execution results returned by each processing node, the processing node that timed out of executing the subtask is determined to be the timeout processing node; Based on the mapping relationship between the multiple subtasks and processing nodes, the subtasks to be executed by the timeout processing node are determined; The subtask to be executed can be resent to the timeout processing node or the subtask to be executed can be migrated to another processing node for execution.

7. The method according to claim 4, characterized in that, The step of using the cached result as the target processing result of the task to be executed includes: Through a distributed transaction mechanism, the consistency of the execution results returned by each processing node is verified based on the multiple subtasks to obtain a consistency verification result. If the consistency check result indicates that the consistency check has passed, then the cached result is determined as the target processing result of the task to be executed; If the consistency check result indicates that the consistency check has failed, a compensation operation is triggered.

8. A system for generating procedural documents, characterized in that, include: Service system clusters and distributed clusters The service system cluster, in response to a program document generation request sent by the client, determines the task to be executed based on the program document generation request. The service system cluster is used to call a distributed computing framework to split the task to be executed into multiple sub-tasks according to the target splitting strategy. The service system cluster is also used to distribute the multiple subtasks to each processing node in the distributed cluster; Each processing node in the distributed cluster is used to execute the received subtasks in parallel; The service system cluster is also used to receive the execution results returned by each processing node, summarize the execution results returned by each processing node into the target processing result of the task to be executed, and return the target processing result to the client. The target processing result includes: program documents.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images