Method and device for generating to-be-signed file, program and storage medium

Abstract

The invention discloses a method and equipment for generating a to-be-signed file, a program and a storage medium. The method comprises the following steps: responding to a signing instruction for a target to-be-signed file, and analyzing a target process identifier, at least one signer and at least one group of corresponding basic parameter key value pairs; determining a target template identifier and a plurality of target file identifiers corresponding to the generation of the target to-be-signed file based on the target process identifier and a preset database; determining a target template for generating the target to-be-signed file based on the plurality of target file identifiers; determining a public page identifier of each page of the target template based on the target template identifier; determining a plurality of non-public pages and a plurality of public pages in the target template according to the public page identifier; and based on a preset database and the basic parameter key value pair corresponding to each signer, filling the plurality of non-public pages, outputting a filled non-public page set, and generating a target to-be-signed file with the plurality of public pages. The efficiency of generating the to-be-signed file can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically to a method, apparatus, program, and storage medium for generating documents to be signed. Background Technology

[0002] In the field of electronic signatures and document generation, electronic processing of contracts, agreements, forms, and other similar documents has become the norm. Traditional processes typically involve template creation and maintenance, process instance creation, page-level resource organization and conversion, and providing users with visual previews before generation. As business scales up, template sources increase, the number of pages rises, and concurrent access increases, significantly increasing the computational and I / O pressure on the system for retrieval, rendering, and assembly. Preview generation response time and generation stability become key factors affecting user experience and business workflow efficiency.

[0003] In practical applications, the same business domain often needs to manage multiple templates and multiple versions of resources. There are logical order relationships and resource pointer relationships between templates and pages, and field-to-position mapping relationships between pages and parameters. How to maintain the structured expression of template information, page resources, and parameter specifications without changing the business semantics, so that it can be stably retrieved and quickly organized, is a fundamental challenge in engineering implementation. In addition, during process execution, the terminal usually expects to see a page preview that can be used for verification as soon as possible; however, in high-concurrency scenarios, repeated template parsing, repeated parameter traversal, and disordered page-level splicing can easily lead to latency fluctuations, abnormal rollbacks, and resource waste.

[0004] On the other hand, electronic documents often contain both fixed, unchanging content and content that changes due to the data of the participating parties. These two types of content differ in their organization, rendering overhead, and caching strategies. Without a clear definition of page-level attributes and a stable index structure, the system often needs to perform multiple rounds of matching and comparison during generation, increasing the cost of cross-table backtracking and easily introducing problems such as page order misalignment and field omissions.

[0005] In summary, for electronic document signing scenarios, establishing a highly cohesive and loosely coupled relationship between template management, parameter management, and page organization, reducing unnecessary repeated parsing and redundant rendering, and improving the efficiency and stability of generating documents to be signed under concurrent conditions remains a technical direction of widespread concern in the industry and requires further optimization. Summary of the Invention

[0006] The purpose of this application is to provide a method, apparatus, program, and storage medium for generating documents to be signed, so as to solve the problem of low efficiency in generating documents to be signed in the prior art.

[0007] To achieve the above objectives, the first aspect of this application provides a method for generating a document to be signed, the method comprising: In response to a signing instruction for a target document to be signed, the target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer are parsed from the signing instruction; Based on the target process identifier and the preset database, determine the target template identifier and multiple target file identifiers corresponding to the target document to be signed; Based on multiple target file identifiers and a preset database, a target template for generating the target document to be signed is determined; The common page identifiers of each page in the target template are determined based on the target template identifier and the preset database; Identify multiple non-public pages and multiple public pages within the target template based on the public page identifier; Based on a preset database and at least one set of basic parameter key-value pairs corresponding to each signer, multiple non-public pages are populated, and the populated set of non-public pages is output. The target document to be signed is generated based on the populated set of non-public pages and multiple public pages.

[0008] In this embodiment, the preset database also includes the correspondence between basic parameter keys and page number values ​​of each page in the target template; the step of filling multiple non-public pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and outputting the filled non-public page set includes: determining the basic parameter keys in each non-public page according to the page number value of each non-public page and the preset database; filling the basic parameter values ​​in the at least one set of basic parameter key-value pairs corresponding to each signer into the position of the basic parameter keys in each non-public page; and adding each filled non-public page to the non-public page set.

[0009] In this embodiment of the application, the step of determining the target template for generating the target document to be signed based on multiple target file identifiers and a preset database includes: determining the file path and page number value corresponding to each target file identifier based on multiple target file identifiers and a preset database; obtaining the file corresponding to each target file identifier based on the file path corresponding to each target file identifier; and sorting the multiple files corresponding to multiple target file identifiers according to their respective page number values ​​to generate the target template.

[0010] In this embodiment of the application, before the step of generating the target document to be signed based on the filled non-public page set and multiple public pages, the method further includes: determining the union of each page number value of the multiple public pages and each page number value of the multiple non-public pages; sorting all page number values ​​in the union in order; and determining that all sorted page number values ​​are continuous and non-repeating.

[0011] In this embodiment, the preset database includes a first data table, a second data table, and a third data table. The steps of constructing the preset database include: in response to receiving an initial template, parsing the initial template to obtain the template identifier of the initial template, the basic parameter key set of each page of the initial template, the file identifier, and the page number value; storing the template identifier of the initial template and the file identifier of each page of the initial template in the first data table; converting each page of the initial template into multiple corresponding images, and storing the file path, corresponding file identifier, and page number value of each image in the second data table; determining the common page identifier of each page of the initial template based on the basic parameter key set of each page of the initial template and the preset keyword library; and storing the template identifier, the basic parameter key set of each page of the initial template, the common page identifier, and the page number value in the third data table.

[0012] In this embodiment of the application, the step of determining the common page identifier of each page of the initial template based on the basic parameter key set of each page and the preset keyword library includes: if the basic parameter key set of the current page of the initial template is not empty, matching all the basic parameter keys in the basic parameter key set with the preset keyword library respectively; if the matching is successful, the common page identifier of the current page is determined to be a non-public page; if the matching fails, the common page identifier of the current page is determined to be a public page.

[0013] In this embodiment of the application, the method further includes: when the set of basic parameter keys for the current page of the initial template is empty, determining that the public page identifier of the current page is a public page.

[0014] A second aspect of this application provides an apparatus for generating a document to be signed, comprising: a parsing module, configured to, in response to a signing instruction for a target document to be signed, parse a target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer from the signing instruction; a document identifier determination module, configured to determine a target template identifier and multiple target document identifiers corresponding to the target document to be signed based on the target process identifier and a preset database; a target template determination module, configured to determine a target template for the target document to be signed based on the multiple target document identifiers and the preset database; a page identifier determination module, configured to determine a common page identifier for each page of the target template based on the target template identifier and the preset database; a common page determination module, configured to determine multiple non-common pages and multiple common pages within the target template based on the common page identifiers; a filling module, configured to fill the multiple non-common pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and output a set of filled non-common pages; and a generation module, configured to generate the target document to be signed based on the set of filled non-common pages and the multiple common pages.

[0015] A third aspect of this application provides a computer device, comprising: The memory is configured to store instructions; and The processor is configured to retrieve the instructions from the memory and to implement the methods described above when executing the instructions.

[0016] A fourth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0017] A fifth aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to perform the methods described above.

[0018] The above technical solution responds to the target process identifier to obtain the target template identifier and multiple target file identifiers. Based on file paths and page number values, it aggregates and sorts to generate the target template. Then, based on the target template identifier, it determines the common page identifiers of each page in the target template from a preset database, thereby distinguishing between multiple non-common pages and multiple common pages. Utilizing the correspondence between basic parameter keys and page number values, it accurately fills at least one set of basic parameter key-value pairs corresponding to each signer into multiple non-common pages to form a filled non-common page set. Before assembly, it calculates the union of page number values ​​of multiple common pages and page number values ​​of multiple non-common pages, sorts them, and verifies that they are continuous and non-repeating. Finally, it efficiently synthesizes the target document to be signed using the filled non-common page set and multiple common pages. This reduces invalid retrieval, comparison, and rendering, avoids cross-template mixing and parameter mapping mismatch, compresses the page assembly chain and I / O costs, improves throughput and stability in concurrent scenarios, and significantly improves the efficiency of generating the target document to be signed.

[0019] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 A flowchart illustrating a method for generating a document to be signed according to an embodiment of this application is shown schematically; Figure 2 A flowchart illustrating another method for generating a document to be signed according to an embodiment of this application is shown schematically; Figure 3 A flowchart illustrating a method for generating a document to be signed according to a second embodiment of this application is shown schematically; Figure 4 This schematic diagram illustrates the structure of a preset database according to an embodiment of this application; Figure 5 This schematic diagram illustrates a structural diagram of an apparatus for generating a document to be signed according to an embodiment of this application; Figure 6 The schematic diagram illustrates a structural diagram of a computer device according to an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0022] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0023] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0024] Figure 1 A flowchart illustrating a method for generating a document to be signed according to an embodiment of this application is shown schematically. Figure 1 As shown in the figure, this application provides a method for generating a document to be signed, which may include the following steps.

[0025] Step 101: In response to the signing instruction for the target document to be signed, parse the target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer from the signing instruction.

[0026] In this embodiment, the signing instruction can be understood as a request message initiated by the client or server to trigger a business process related to document signing; the target document to be signed refers to an electronic document that needs to be signed and confirmed; the target process identifier is a business identifier used to uniquely identify the current signing business process instance; the signer is a participant in the signing process who completes the signing or confirmation operation on the target document to be signed; the basic parameter key-value pairs are data mapping items used to render page elements within the target document to be signed or to generate the signing context, where the key is used to indicate a placeholder field in the page or content, and the value is used to carry specific business data; at least one set emphasizes that one or more independent data mapping sets can be provided for each signer to adapt to the needs of multi-page, multi-role, or multi-round rendering. By responding to the signing instruction for the target document to be signed, the target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer are parsed from the signing instruction to obtain the process-level and participant-level inputs necessary to drive subsequent template selection, public and non-public page discrimination, and page filling, thereby establishing a complete and traceable initial data entry and parameter baseline for generating the target document to be signed.

[0027] Step 102: Based on the target process identifier and the preset database, determine the target template identifier and multiple target file identifiers corresponding to the target document to be signed.

[0028] In this embodiment, the target template identifier is used to uniquely identify the template entity used to generate the target document to be signed, ensuring that subsequent public page identifier determination and page filling consistently point to the same template source; multiple target file identifiers are used to uniquely locate the page-level file resources associated with the target template, enabling the system to directly obtain the corresponding file path and page number value.

[0029] Step 103: Determine the target template for generating the target document to be signed based on multiple target file identifiers and a preset database.

[0030] In this embodiment, the target template refers to a set of pages corresponding to multiple target file identifiers. These multiple target file identifiers serve as indexes for page-level resources, used to retrieve the corresponding page sets from a preset database and aggregate them into a target template. By determining the target template for generating the target document to be signed based on multiple target file identifiers and the preset database, page order anomalies or parameter mapping deviations caused by incorrect cross-template retrieval are avoided. This reduces the lookup and verification overhead of page assembly from the source, improving the overall efficiency of generating the target document to be signed.

[0031] Step 104: Determine the common page identifiers of each page in the target template based on the target template identifier and the preset database.

[0032] In this embodiment, the public page identifier is used to distinguish whether each page of the target template is a page marker whose content remains consistent regardless of changes in the basic parameter key-value pairs. The determination is based on the association information between the page number value of the target template identifier in the preset database and the basic parameter keys, used to identify pages containing only process-level or template-level static information (public pages) and pages containing content requiring data population (non-public pages). Determining the public page identifier of each page of the target template based on the target template identifier and the preset database allows for rapid, batch partitioning of page roles at the source, reducing subsequent invalid rendering and redundant data processing. This reduces computational and retrieval overhead in the page retrieval and resource scheduling stages, improving the overall efficiency of generating documents to be signed.

[0033] Step 105: Identify multiple non-public pages and multiple public pages within the target template based on the public page identifier.

[0034] Step 106: Based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, populate multiple non-public pages and output the populated non-public page set.

[0035] Step 107: Generate the target document to be signed based on the populated set of non-public pages and multiple public pages.

[0036] In this embodiment, the public page identifier is used to distinguish between multiple public pages and multiple non-public pages at the page level of the target template, thus obtaining two types of page sets. Multiple non-public pages refer to pages that require data assignment and layout rendering depending on each signer. The basic parameter key-value pairs and page number values, as well as the correspondence between parameter keys and page elements, upon which their filling depends are provided by a preset database. The filled non-public page set is an ordered result set after field assignment, graphic layout, and resource pointer confirmation for multiple non-public pages. Multiple public pages are pages whose content does not need to remain stable with changes in signers and can be directly used as static resources in the assembly process. The target document to be signed is an electronic document synthesized by combining the filled non-public page set and multiple public pages in page number order. First, page-level routing is completed using the public page identifier. Then, targeted filling is performed only on multiple non-public pages, which are directly merged with multiple public pages. This avoids repeated parsing and rendering of public pages, reduces computational and storage overhead, shortens the page assembly chain, improves generation throughput and reduces response latency in concurrent scenarios, and overall improves the efficiency of generating documents to be signed.

[0037] The above technical solution responds to the target process identifier to obtain the target template identifier and multiple target file identifiers. Based on file paths and page number values, it aggregates and sorts to generate the target template. Then, based on the target template identifier, it determines the common page identifiers of each page in the target template from a preset database, thereby distinguishing between multiple non-common pages and multiple common pages. Utilizing the correspondence between basic parameter keys and page number values, it accurately fills at least one set of basic parameter key-value pairs corresponding to each signer into multiple non-common pages to form a filled non-common page set. Before assembly, it calculates the union of page number values ​​of multiple common pages and page number values ​​of multiple non-common pages, sorts them, and verifies that they are continuous and non-repeating. Finally, it efficiently synthesizes the target document to be signed using the filled non-common page set and multiple common pages. This reduces invalid retrieval, comparison, and rendering, avoids cross-template mixing and parameter mapping mismatch, compresses the page assembly chain and I / O costs, improves throughput and stability in concurrent scenarios, and significantly improves the efficiency of generating the target document to be signed.

[0038] In this embodiment, the preset database also includes the correspondence between basic parameter keys and page number values ​​of each page in the target template; the step of filling multiple non-public pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and outputting the filled non-public page set includes: determining the basic parameter keys in each non-public page according to the page number value of each non-public page and the preset database; filling the basic parameter values ​​in the at least one set of basic parameter key-value pairs corresponding to each signer into the position of the basic parameter keys in each non-public page; and adding each filled non-public page to the non-public page set.

[0039] In this embodiment, the correspondence is used to indicate the mapping and positioning rules between the basic parameter keys and the page number values ​​of each page in the target template, and can be further associated with placeholder identifiers and element placement points within the page; the basic parameter value is the value part of the basic parameter key-value pair; the position is the placeholder placement point or rendering placement point corresponding to the basic parameter key within the page. Based on the correspondence stored in the preset database, the system can quickly determine the required basic parameter keys for each non-public page according to its page number value, and accurately fill the basic parameter values ​​in at least one set of basic parameter key-value pairs corresponding to each signer into the corresponding positions. Subsequently, the pages that have been assigned values ​​are added to the filled non-public page set. Through explicit key-to-page and key-to-position indexing, repeated matching and traversal of pages and parameters are avoided, improving the determinism and first-time hit rate of parameter positioning and writing, reducing invalid rendering and data transfer, thereby accelerating the filling speed and aggregation efficiency of non-public pages under the same computing resources, and supporting the overall improvement of the efficiency of generating documents to be signed.

[0040] In this embodiment of the application, the step of determining the target template for generating the target document to be signed based on multiple target file identifiers and a preset database includes: determining the file path and page number value corresponding to each target file identifier based on multiple target file identifiers and a preset database; obtaining the file corresponding to each target file identifier based on the file path corresponding to each target file identifier; and sorting the multiple files corresponding to multiple target file identifiers according to their respective page number values ​​to generate the target template.

[0041] In this embodiment, multiple target file identifiers are used to locate page-level resource entries from the same source in a preset database; file paths indicate the access location of the corresponding resources in the storage system; page numbers represent the logical sequence number of the resource within the template; and files are specific page resource objects obtained based on file paths. By obtaining the corresponding file paths and page numbers from the preset database based on multiple target file identifiers, and then obtaining the corresponding files according to the file paths, and arranging them in an orderly manner according to their respective page numbers to generate target templates, the aggregation and order verification of page-level resources can be completed in one go, avoiding disordered splicing and cross-source erroneous retrieval, reducing multiple rounds of queries and repeated comparisons, thereby reducing retrieval and sorting overhead in the resource assembly stage and improving the efficiency of generating target documents to be signed.

[0042] In this embodiment of the application, before the step of generating the target document to be signed based on the filled non-public page set and multiple public pages, the method further includes: determining the union of each page number value of the multiple public pages and each page number value of the multiple non-public pages; sorting all page number values ​​in the union in order; and determining that all sorted page number values ​​are continuous and non-repeating.

[0043] In this embodiment, page number values ​​are used to identify the logical sequence number of a page in the target template; the union refers to the unified index set formed by merging the page number values ​​of multiple common pages with the page number values ​​of multiple non-common pages; sorting refers to the sequential arrangement of all page number values ​​in the union in ascending or descending order; continuity and non-repetition are used to verify whether the sorting result has no missing or duplicate numbers, thereby ensuring the integrity and uniqueness of the page order. By performing the union, sorting, and continuity and uniqueness checks sequentially before generating the target document to be signed, assembly ambiguities caused by page number conflicts, gaps, and duplications can be eliminated at the index level in one go, avoiding invalid splicing and rollback correction of page resources, reducing page traversal and exception handling overhead, and thus completing the subsequent assembly with fewer calculations and checks, improving the efficiency of generating the target document to be signed.

[0044] In this embodiment, the preset database includes a first data table, a second data table, and a third data table. The steps of constructing the preset database include: in response to receiving an initial template, parsing the initial template to obtain the template identifier of the initial template, the basic parameter key set of each page of the initial template, the file identifier, and the page number value; storing the template identifier of the initial template and the file identifier of each page of the initial template in the first data table; converting each page of the initial template into multiple corresponding images, and storing the file path, corresponding file identifier, and page number value of each image in the second data table; determining the common page identifier of each page of the initial template based on the basic parameter key set of each page of the initial template and the preset keyword library; and storing the template identifier, the basic parameter key set of each page of the initial template, the common page identifier, and the page number value in the third data table.

[0045] In this embodiment, the first data table stores the primary and foreign key relationships between the initial template and its page-level resources. Each record item includes at least a template identifier and the file identifier of the corresponding page, serving as an index entry point from the template to the page resources. The second data table stores image resource information converted from each page of the initial template. Each record item includes at least a file path, file identifier, and page number value, enabling page-level images to be quickly located and organized sequentially. The third data table stores page semantic and attribute information. Each record item includes at least a template identifier, a set of basic parameter keys, a common page identifier, and a page number value, supporting page attribute determination and retrieval based on parameters and keywords. The initial template is the original template file to be added to the database. Parsing is used to extract the template identifier, the set of basic parameter keys for each page, the file identifier, and the page number value from the initial template. The preset keyword library is a set of keywords used for matching when determining page attributes. The file path is the access location information of the corresponding image resources in the storage system. By placing structured relationships, image resource indexes, and page attribute definitions in the first, second, and third data tables respectively, a hierarchical organization and rapid retrieval of templates to pages, pages to images, and pages to attributes can be achieved at the data layer. This reduces cross-table backtracking and redundant parsing from the source, significantly lowering the computational and I / O costs of subsequent page location, attribute determination, and resource assembly, thereby improving the efficiency of generating documents to be signed.

[0046] In this embodiment of the application, the step of determining the common page identifier of each page of the initial template based on the basic parameter key set of each page and the preset keyword library includes: if the basic parameter key set of the current page of the initial template is not empty, matching all the basic parameter keys in the basic parameter key set with the preset keyword library respectively; if the matching is successful, the common page identifier of the current page is determined to be a non-public page; if the matching fails, the common page identifier of the current page is determined to be a public page.

[0047] In this embodiment, the current page refers to the page unit within the initial template whose attributes are being determined. Matching refers to the process of comparing each basic parameter key in the basic parameter key set of the current page with a preset keyword library according to rules. This may include retrieval strategies such as case normalization, synonym merging, prefix and suffix pruning, and regularization to determine whether the semantics point to content that needs to change with the data of the participating parties. When the match is successful, it is determined to be a non-public page; when the match fails, it is determined to be a public page. By replacing the deep analysis of the entire page content with a lightweight semantic comparison from key to word, page-level attribute determination is completed at the lowest cost, significantly reducing determination latency and computational overhead, reducing the number of false positives and reviews, and providing a clear page routing basis for subsequent assembly, thereby improving the overall efficiency of generating documents to be signed.

[0048] In this embodiment of the application, the method further includes: when the set of basic parameter keys for the current page of the initial template is empty, determining that the public page identifier of the current page is a public page.

[0049] Through the above technical solution, in the stage of constructing the preset database, the first, second, and third data tables respectively solidify the primary and foreign key relationship between template identifiers and file identifiers, the resource index of file paths and page number values, and the attribute scope of basic parameter key sets and common page identifiers and page number values. Based on the preset keyword library, the basic parameter key sets of each page of the initial template are matched to determine the common page identifier in one go, reducing cross-file backtracking and repeated parsing from the source. In the generation stage, the target process identifier is responded to to obtain the target template identifier and multiple target file identifiers. The target template is generated by aggregating and sorting according to the file paths and page number values. Then, based on the target template identifier, the common page identifier of each page of the target template is determined from the preset database. This approach distinguishes between multiple non-public pages and multiple public pages. Utilizing the correspondence between basic parameter keys and page number values, it accurately fills at least one set of basic parameter key-value pairs corresponding to each signer into multiple non-public pages, forming a filled set of non-public pages. Before assembly, it calculates the union of page number values ​​from multiple public pages and multiple non-public pages, sorts them, and verifies that they are consecutive and non-repeating. Finally, it efficiently synthesizes the target document to be signed using the filled set of non-public pages and multiple public pages. This reduces invalid searches, comparisons, and rendering, avoids cross-template mixing and parameter mapping mismatches, compresses the page assembly process and I / O costs, improves throughput and stability in concurrent scenarios, and significantly increases the efficiency of generating the target document to be signed.

[0050] The following is a first embodiment of this application: Figure 2 A flowchart illustrating a method for generating a document to be signed according to a first embodiment of this application is shown schematically. Figure 2As shown. First, the initial template is uploaded and a preview image is generated: the initial template is parsed to obtain the template identifier, file identifiers and page number values ​​for each page, and a set of basic parameter keys, which are then written into the first, second, and third data tables respectively. Simultaneously, based on the set of basic parameter keys and a preset keyword library, the public page identifier is determined, thereby establishing a hierarchical index and page attribute definition in the preset database, from template to page, page to image, and page to attribute. Subsequently, when initiating the signing process, the target template identifier and multiple target file identifiers are determined in the preset database based on the target process identifier. The target template is then generated by aggregating and sorting based on file paths and page number values. The public page identifier is then obtained based on the target template identifier, distinguishing between multiple public pages and multiple non-public pages. For multiple non-public pages, according to the correspondence between basic parameter keys and page number values, at least one set of basic parameter key-value pairs corresponding to each signer is written into the corresponding position to form a filled set of non-public pages. For multiple public pages, image resources in the second data table are directly reused (image data is copied as a logical reference and not rendered repeatedly).

[0051] During the preview generation phase, the page number values ​​of multiple public pages and multiple non-public pages are joined, sorted, and verified to be continuous and non-repeating. These are then organized into a visual preview sequence in page number order for the front-end to display previews of the relevant signing documents. Users confirm the signing documents based on this preview sequence, and the process ends here. By first performing page-level traffic splitting and resource indexing, and then selectively populating only multiple non-public pages and directly assembling them with multiple public pages, redundant parsing, rendering, and cross-table backtracking are reduced. This significantly shortens the response time for generation and preview in concurrent scenarios, thereby improving the efficiency and stability of generating the target documents to be signed.

[0052] The following is a second embodiment of this application: Figure 3 A flowchart illustrating a method for generating a document to be signed according to a second embodiment of this application is shown schematically. Figure 3As shown. First, the template upload is executed: the initial template is received and parsed to obtain the template identifier, the file identifier and page number value corresponding to each page, and the set of basic parameter keys for the page; the template identifier and file identifier are written into the first data table, the file path and page number value of the image resources converted from the page are written into the second data table, and the common page identifier is determined during the data entry based on the set of basic parameter keys and the preset keyword library, and written into the third data table along with the page number value and template identifier, thus completing the hierarchical indexing from template to page, page to image, and page to attribute. Then, a template preview is generated: the images are organized in order according to the file path and page number value in the second data table, and a template preview corresponding to the current template is output to verify whether the page order and basic visual presentation are correct. Next, the template parameters are configured: the set of basic parameter keys is added, deleted, modified, or adjusted according to business needs (such as revisions to key-to-page and key-to-position), and the corresponding records are updated in the third data table to ensure consistent association with the template identifier, page number value, and common page identifier. Finally, a new template preview is generated: the preview is regenerated based on the updated set of basic parameter keys and common page identifiers (no additional rendering of common pages is required, just confirm that their references and order are correct), which is used to confirm the impact of parameter configuration on page presentation and page-level attributes. The process ends after confirmation.

[0053] The following is the third embodiment of this application: Figure 4 The diagram schematically illustrates the structure of a preset database according to an embodiment of this application. For example... Figure 4 As shown.

[0054] `file_version` (file version table): `version_id` is the version identifier; `file_id` is a foreign key pointing to `file`; `ver_status` indicates the current version processing status (e.g., `processing`, `done`, `failed`); the remaining omitted bits are used for extended metadata. This table can handle the processing results of "generating template preview" and "generating target documents to be signed", using `ver_status` to indicate whether the version can be previewed. After locating the target template based on the target process identifier, distinguishing between public and non-public pages, and then populating the non-public pages, the system adds a version entry at the `file_id` granularity and sets `ver_status`, thus enabling version-controlled visibility and rollback when "viewing previews of process-related signed documents".

[0055] The file table (i.e., the first data table) contains: file_id (file identifier); file_name (file name, which can be generated according to process and template rules for easy idempotent lookup); prod_id (associated with prod, indicating the target process to which the file belongs); temp_id (associated with temp, indicating the target template referenced by the file); and the remaining omitted characters are extensions. This table is the assembly carrier: after the system determines the target template identifier and multiple target file identifiers based on the target process identifier in the preset database, and aggregates and generates the target template according to the file path and page number value, it will create or reuse the corresponding file record for this process, and then continue to attach version and page-level images to achieve a closed loop from process to template to file.

[0056] `file_image` (the file image table, i.e., the second data table): `image_id` is the identifier for the page image record; `file_id` is a foreign key pointing to `file`; `image_path` is the storage path of the page image (spelled as shown in the image); `page` is the page number value. This table is used for page-level resource organization: when the template is entered into the database, the template preview image is entered into the table with the path and page number. During process generation, multiple common pages directly reference the corresponding `image_path`, and for multiple non-common pages, a new `image_path` is written after population. The `page` is used for union, sorting, and continuity verification. Finally, the preview sequence is output in ascending order to support efficient synthesis of target documents to be signed.

[0057] temp (template information table): temp_id is the template identifier; temp_name is the template name; temp_status is the template status; temp_key is the template business key; the remaining omitted characters are extensions. This table can provide an authoritative entry point for the template source: when building the preset database, after uploading the template, the temp_id is parsed and stored in the database; during the generation stage, after retrieving the target template identifier based on the target process identifier, temp_id is used as the primary key for subsequently obtaining page resources, parameter specifications, and common page identifiers, so that the reuse of common pages and the filling of non-common pages are both anchored to the same template.

[0058] temp_param (template parameter table, i.e., the third data table): param_id is the parameter record identifier; temp_id is associated with temp; param_key is the basic parameter key; pub_flag is the public page identifier; page_num is the page number value. This table is an index of page attributes and parameter specifications: After "Generate Template Preview", a public page identifier is determined for each page based on the basic parameter key set and the preset keyword library and written into pub_flag; during the generation stage, the param_key set required for a certain page is found according to page_num, and then the basic parameter key-value pairs of each signer are filled into the non-public page, realizing the design principle of rendering only for changed pages and directly reusing public pages.

[0059] The `prod` table (process table) contains: `prod_id` as the process identifier; `prod_name` as the process name; and `prod_status` as the process status. This table carries the target process identifier parsed from the signed instruction and serves as the entry index for the entire process: `prod_id` is associated with the file set `file` under this process, and further, `temp_id`, `temp_param`, and `file_image` are used to link the template, parameters, and page-level resources, thus implementing the steps of "determining the common page identifier based on the target template identifier—distinguishing between multiple common pages and multiple non-common pages—populating only multiple non-common pages—assembling and previewing according to page number values" into specific data rows.

[0060] The six data tables above decouple template source, page-level attributes, process affiliation, file instance, version status, and image path into layers: `temp` and `temp_param` are responsible for determining the template to page and public page identifiers; `prod` and `file` establish the assembly boundary from process to file; and `file_version` and `file_image` can store and visualize the ordered synthesis of the "filled set of non-public pages" and "multiple public pages" in the database. Based on this structure, it naturally supports zero-rendering reuse of public pages, incremental updates of non-public pages by page, union and continuity checks before assembly, idempotent creation within the process (generated through regularization of `prod_id` and `file_name`), version-level rollback and grayscale preview, and batch re-rendering of affected files by reverse lookup of `temp_id`, improving the efficiency and stability of generating target documents to be signed.

[0061] Figure 5 The diagram schematically illustrates a structural diagram of an apparatus for generating a document to be signed according to an embodiment of this application. Figure 5As shown in the illustration, this application provides an apparatus for generating a document to be signed, which may include: a parsing module 510, configured to, in response to a signing instruction for a target document to be signed, parse a target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer from the signing instruction; a document identifier determination module 520, configured to determine a target template identifier and multiple target document identifiers corresponding to the target document to be signed based on the target process identifier and a preset database; a target template determination module 530, configured to determine a target template for the target document to be signed based on the multiple target document identifiers and the preset database; a page identifier determination module 540, configured to determine the common page identifiers of each page of the target template based on the target template identifiers and the preset database; a common page determination module 550, configured to determine multiple non-common pages and multiple common pages within the target template based on the common page identifiers; a filling module 560, configured to fill multiple non-common pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and output a set of filled non-common pages; and a generation module 570, configured to generate the target document to be signed based on the set of filled non-common pages and the multiple common pages.

[0062] Figure 6 A schematic diagram illustrating the structure of a computer device according to an embodiment of this application is provided. Figure 6 As shown, this application provides a computer device that may include: Memory 610 is configured to store instructions; and Processor 620 is configured to retrieve instructions from memory 610 and to implement the methods described above when executing instructions.

[0063] This application also provides a machine-readable storage medium storing instructions that cause a machine to perform the above-described method.

[0064] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0065] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0066] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0067] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0068] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0069] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0070] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0071] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0072] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating a document to be signed, characterized in that, The method includes: In response to a signing instruction for a target document to be signed, a target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer are parsed from the signing instruction; Based on the target process identifier and the preset database, a target template identifier and multiple target file identifiers corresponding to the target document to be signed are determined and generated. Based on the multiple target file identifiers and the preset database, a target template for generating the target document to be signed is determined; The common page identifier of each page of the target template is determined based on the target template identifier and the preset database; Based on the public page identifier, multiple non-public pages and multiple public pages are identified within the target template; Based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, the multiple non-public pages are populated, and the populated non-public page set is output. The target document to be signed is generated based on the populated set of non-public pages and the multiple public pages.

2. The method according to claim 1, characterized in that, The preset database also includes the correspondence between basic parameter keys and the page number values ​​of each page of the target template; The step of populating the multiple non-public pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and outputting the populated non-public page set, includes: The basic parameter keys within each non-public page are determined based on the page number value of each non-public page and the preset database; Fill the basic parameter values ​​from at least one set of basic parameter key-value pairs corresponding to each signer into the position of the basic parameter key in each non-public page; Add each non-public page after it has been filled to the non-public page set.

3. The method according to claim 1 or 2, characterized in that, The steps for determining the target template for generating the target document to be signed using the multiple target file identifiers and the preset database include: The file path and page number value corresponding to each target file identifier are determined based on the plurality of target file identifiers and the preset database; The file corresponding to each target file identifier is obtained based on the file path corresponding to each target file identifier; The multiple files corresponding to the multiple target file identifiers are sorted according to their respective page number values ​​to generate the target template.

4. The method according to claim 3, characterized in that, The preset database includes a first data table, a second data table, and a third data table; the steps for constructing the preset database include: In response to receiving an initial template, the initial template is parsed to obtain the template identifier of the initial template, the basic parameter key set of each page of the initial template, the file identifier, and the page number value; The template identifier of the initial template and the file identifier of each page of the initial template are stored in the first data table; Each page of the initial template is converted into a corresponding multiple image, and the file path, corresponding file identifier and page number value of each image are saved in the second data table; Based on the set of basic parameter keys for each page of the initial template and the preset keyword library, the common page identifier for each page of the initial template is determined; The template identifier, the set of basic parameter keys for each page of the initial template, the common page identifier, and the page number value are stored in the third data table.

5. The method according to claim 4, characterized in that, The step of determining the common page identifier of each page of the initial template based on the basic parameter key set of each page and the preset keyword library includes: If the set of basic parameter keys for the current page of the initial template is not empty, all basic parameter keys in the set of basic parameter keys are matched with the preset keyword library respectively; If a match is found, the public page identifier of the current page is determined to be a non-public page; If a match fails, the public page identifier of the current page is determined to be a public page.

6. The method according to claim 5, characterized in that, The method further includes: If the set of basic parameter keys for the current page of the initial template is empty, the public page identifier of the current page is determined to be a public page.

7. The method according to claim 6, characterized in that, The step of generating the target document to be signed based on the populated set of non-public pages and the plurality of public pages also includes: Determine the union of the page number values ​​of the plurality of public pages and the page number values ​​of the plurality of non-public pages; Sort all page number values ​​in the union in order; Ensure that all page number values ​​are consecutive and non-repeating after sorting.

8. An apparatus for generating a document to be signed, characterized in that, include: The parsing module is used to parse the target process identifier, at least one signer, and at least one set of basic parameter key-value pairs corresponding to each signer from the signing instruction in response to the signing instruction for the target document to be signed; The document identifier determination module determines and generates a target template identifier and multiple target document identifiers corresponding to the target document to be signed based on the target process identifier and a preset database. The target template determination module determines and generates the target template for the target document to be signed based on the multiple target file identifiers and the preset database. The page identifier determination module determines the common page identifier of each page of the target template based on the target template identifier and the preset database; The public page determination module determines multiple non-public pages and multiple public pages within the target template based on the public page identifier. The filling module fills the multiple non-public pages based on the preset database and at least one set of basic parameter key-value pairs corresponding to each signer, and outputs the filled non-public page set. The generation module generates the target document to be signed based on the populated set of non-public pages and the multiple public pages.

9. A computer device, characterized in that, include: The memory is configured to store instructions; as well as A processor configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 7.

11. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the method according to any one of claims 1 to 7.

Images