A method and system for generating an authentication document

Abstract

The application provides a method and system for generating authentication documents, and relates to the technical field of software architecture design. The method comprises the following steps: obtaining a user request for generating an authentication document; in response to the user request, performing unified code encapsulation processing on a business entity through a general controller based on generic abstraction to obtain underlying support data for providing unified data for a form engine and a fragment engine; according to the underlying support data, calling a plug-in data builder through the form engine to construct form data; according to the form data, calling a plug-in fragment builder through the fragment engine to construct HTML fragment data; using a rendering template to perform rendering processing on the HTML fragment data and form data associated with the HTML fragment data to generate rendering content of the authentication document; and returning the rendering content to a user end to generate the authentication document.

Description

Technical Field

[0001] This invention relates to the field of software architecture design technology, and in particular to a method and system for generating authentication documents. Background Technology

[0002] In fields such as enterprise management, product certification, and compliance audits, there is often a need to generate standardized certification documents with complex structures and rigorous content. These documents are typically assembled from multiple logically independent yet interconnected segments (such as "Project Overview," "Technical Architecture," "Test Cases," and "Compliance Statements"). Traditional development methods involve writing separate front-end and back-end code for each document or segment, resulting in a large amount of repetitive work during development. This not only leads to long project cycles and high costs but also makes the system difficult to maintain and update consistently.

[0003] Currently, there is an improvement scheme based on basic framework components. This scheme reduces repetitive code on the front-end pages to some extent by introducing common front-end UI components (such as forms and tables) and basic utility classes. Developers use these components to manually assemble interfaces for different business entities and write corresponding controller and service layer code to obtain and process data.

[0004] However, existing technical solutions lack standardized constraints on backend fragment development, resulting in significant differences in data validation, exception handling, and interface specifications among fragments implemented by different developers. Data acquisition paths are not uniformly planned, and UI components still access data sources directly through scattered interfaces, failing to guarantee data consistency. Furthermore, the lack of collaboration mechanisms between forms and fragments necessitates manual intervention for data association and content splicing during document assembly, leading to poor system scalability and high maintenance costs. This loosely integrated architecture results in low code reusability and high system coupling. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a method for generating authentication documents, which can solve the problems of the prior art, such as the lack of unified planning of data acquisition paths, the fact that each UI component still directly accesses the data source through scattered interfaces, making it impossible to guarantee data consistency; the lack of a collaborative mechanism between forms and fragments, requiring manual intervention for data association and content splicing during document assembly, resulting in poor system scalability and high maintenance costs. This loosely integrated architecture pattern leads to technical problems such as low code reusability and high system coupling.

[0006] A first aspect of this invention provides a method for generating authentication documents, comprising:

[0007] S1: Obtain the user request to generate the authentication document;

[0008] S2: In response to user requests, a generic controller based on generic abstraction is used to encapsulate business entities in a unified code manner, resulting in underlying support data that provides unified data for the form engine and fragment engine;

[0009] S3: Based on the underlying support data, the form engine calls the plug-in data builder to construct the form data;

[0010] S4: Based on the form data, the HTML fragment data is constructed by calling the plug-in fragment builder through the fragment engine;

[0011] S5: Use rendering templates to render HTML fragment data and form data associated with the HTML fragment data to generate the rendered content of the authentication document;

[0012] S6: Return the rendered content to the user's device to generate the authentication document.

[0013] A second aspect of the present invention provides a system for generating authentication documents, comprising: a processor and a memory;

[0014] The memory stores a program or instructions that can run on the processor, and when the program or instructions are executed by the processor, they implement the steps of the method for generating authentication documents as described in the first aspect.

[0015] A third aspect of the present invention provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the authentication document generation method of the first aspect.

[0016] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0017] In this embodiment of the invention, by establishing a form engine as the sole data source architecture and uniformly planning the data acquisition path, the problem of data inconsistency caused by scattered interfaces is fundamentally eliminated. Through the collaborative working mechanism of the form engine and the fragment engine, the document assembly is automated, eliminating the need for manual intervention, significantly improving the system's scalability and maintainability, and ultimately forming a complete solution with low coupling and high reusability. Attached Figure Description

[0018] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0019] Figure 1This is a flowchart illustrating a method for generating authentication documents according to an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of the structure of an authentication document generation method provided in an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] The method for generating authentication documents provided by the embodiments of the present invention will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0023] Reference manual attached Figure 1 The diagram illustrates a flowchart of a method for generating authentication documents according to an embodiment of the present invention.

[0024] This invention provides a method for generating authentication documents, which may include the following steps:

[0025] S1: Obtain the user request to generate the authentication document.

[0026] Specifically, users initiate requests through a web interface, which are then received and processed by the corresponding controller.

[0027] It should be noted that the development and runtime environment of this invention is built on a mainstream cross-platform technology stack, supporting deployment on Windows, Linux, and macOS operating systems. The project uses Java 17 as the development language and Spring Boot 2.7.18 as the core application framework. MyBatis is chosen as the ORM framework for the data persistence layer, and TK Mapper 4.2.0 is integrated to enhance single-table operation functionality. Maven 3.8 or later is used as the project build and dependency management tool, and MySQL 8.0 or later is used as the database.

[0028] S2: In response to user requests, a generic controller based on generic abstraction performs unified code encapsulation of business entities, resulting in underlying support data that provides unified data for the form engine and fragment engine.

[0029] Among them, the generic controller based on generic abstraction is a unified backend processing program. It uses the "generic" technology in programming, so that instead of writing separate code for each business (such as users and orders), it only needs to write a set of general logic (such as adding, deleting, modifying, and querying) to automatically process all different types of business data.

[0030] The form engine is a core system component for dynamically generating and processing forms. It decouples form definitions from implementation logic, enabling dynamic control over form structure and behavior. Based on predefined metadata models (such as JSON or XML configurations) or form configuration information stored in a database, the engine automatically parses and renders the complete form interface at runtime, while also managing the entire lifecycle of form data, including validation, submission, binding, and persistence.

[0031] The fragment engine is a core system component for dynamically generating and managing UI fragments. It decouples content structure, data logic, and rendering rules to enable on-demand construction and output of HTML fragments. Driven by configurable metadata (such as fragment type, data source mapping, template path, etc.), the engine automatically coordinates data acquisition, business processing, and template rendering processes at runtime, ultimately generating standardized HTML fragments that meet the requirements.

[0032] Specifically, the generic controller based on generic abstraction provides a standard CRUD operation interface. Business controllers only need to inherit this base class to obtain complete controller capabilities without having to rewrite similar code.

[0033] Furthermore, generic code encapsulation achieves code reuse by inheriting WABaseController and WABaseService from traditional MVC business logic.

[0034] For example, besides using the generic-based WABaseController abstract class, an annotation-based generic controller solution can also be adopted. This solution uses custom annotations to mark business entities and operation types, combined with a unified request handler to achieve generic CRUD functionality. The advantage of this solution is that it allows for more flexible definition of controller behavior.

[0035] It should be noted that low-code components are essentially generic code wrapper layers (WABaseController+).

[0036] WABaseService + WABaseMapper forms the "underlying infrastructure" of the entire architecture. While not directly involved in the core document generation process, it provides "generalized data management capabilities" for both the form engine and the fragment engine, resolving their "duplication of code": For the form engine, it provides basic CRUD capabilities for form data (such as saving / querying form configurations and loading form metadata). The form engine doesn't need to repeatedly write code for "adding / deleting / updating form entities"; it only needs to inherit from WABaseService to quickly obtain data manipulation capabilities. For the fragment engine, it provides basic management capabilities for fragment templates and fragment configurations (such as storing the mapping relationship between fragment IDs and builders). The fragment engine doesn't need to repeatedly develop "fragment configuration query interfaces"; it can directly access the database through WABaseMapper. Its core value lies in reducing the amount of redundant development work between the two engines through generic abstraction, allowing developers to focus on core business logic such as "form data logic and fragment rendering specifications," rather than basic CRUD code.

[0037] In this embodiment of the invention, business entities are uniformly encapsulated by a generic controller based on generic abstraction, which realizes the ultimate reuse of standard CRUD operations and fundamentally eliminates the repetitive controller coding work in each business module.

[0038] In one possible implementation, S2 specifically includes sub-steps S201 and S202:

[0039] S201: Receive user requests through the business controller.

[0040] The business controller is the core component of the MVC architecture. As the business endpoint exposed to the outside world, it is responsible for receiving front-end requests, scheduling business processes, and returning responses.

[0041] S202: Determine whether the business controller inherits from the generic controller base class based on generic abstraction. If so, call the generic CRUD methods through the generic controller base class, linking the generic service class and generic data access interface to complete the unified data processing of the business entity and obtain the underlying support data. Otherwise, execute the custom logic.

[0042] Among them, the general controller base class is an abstract controller built on generic programming and the template method pattern. It achieves unified operation encapsulation of entity models through type parameterization.

[0043] In this embodiment of the invention, by using an inheritance check mechanism, the standardized encapsulation capabilities of the general controller are intelligently reused while maintaining the custom flexibility of the business controller, effectively balancing architectural specifications and special business requirements.

[0044] In one possible implementation, S202 specifically includes sub-steps S2021 to S2024:

[0045] S2021: Generate invocation instructions by calling general CRUD methods through the general controller base class.

[0046] Among them, the general CRUD method refers to a standardized data operation interface that is decoupled from specific business entities and implemented through parameterized types.

[0047] S2022: Trigger service processing based on the call command.

[0048] S2023: Determine whether the service processing business inherits from the general service class. If yes, proceed to S2024. Otherwise, execute the custom data logic.

[0049] Among them, the general service class is the basic abstraction of the business logic layer, which provides standardized business operation implementations decoupled from entity types through generic programming.

[0050] Specifically, general-purpose service classes provide unified business logic processing capabilities.

[0051] S2024: By calling the general data access interface through the general service class, the business entities are processed in a unified manner, and the underlying support data is output for subsequent form engine and fragment engine to call.

[0052] Among them, the generic data access interface is the basic contract of the persistence layer, which defines a standard data operation specification that is decoupled from database technology and entity types through generic abstraction.

[0053] Furthermore, by inheriting the general data access interface, the data access interface of a business entity can automatically acquire complete CRUD operation capabilities.

[0054] Specifically, common data manipulation methods include adding, deleting, updating, querying, soft deletion, and transaction management.

[0055] Soft deletion is a data persistence strategy that uses flags instead of physical deletion to maintain data integrity and traceability.

[0056] In this embodiment of the invention, a multi-level generic abstract architecture comprising a controller, service layer, and data access layer is adopted. Generic parameters establish the relationships between each layer, forming a complete abstract system. Combined with an inheritance-based code reuse mechanism, business components can obtain standard data operation capabilities simply by inheriting from a base class, eliminating the need to write repetitive code. Furthermore, a runtime behavior dynamic configuration mechanism is introduced, supporting dynamic adjustment of component behavior through parameters without modifying the code. This architecture, through generic abstraction and inheritance mechanisms, achieves unified code encapsulation and efficient reuse, significantly reducing repetitive development workload.

[0057] S3: Based on the underlying supporting data, the form engine calls the plug-in data builder to construct the form data.

[0058] The pluggable data builder is an extension unit in the form engine responsible for data supply and processing. It adopts a pluggable design pattern, encapsulating the data acquisition logic from different sources and structures into independent, pluggable components. Each data builder corresponds to a specific data acquisition strategy (such as calling remote APIs, executing database queries, accessing local caches, or performing data transformation calculations) and follows a unified interface specification.

[0059] Specifically, the form engine adopts a plug-in architecture design, using a dynamic builder pattern to separate form structure from data processing. It is responsible for handling the dynamic form structure definition and data retrieval, supporting the dynamic construction of various form types.

[0060] Furthermore, the dynamism of the form engine primarily stems from the following three aspects: First, the pluggable builder mechanism, through the abstract class `DefaultDataBuilder` and its concrete implementation classes (usually specific forms), allows for the dynamic extension of data construction logic for different forms without modifying the core engine code. Second, runtime-configurable rules and templates, with the form structure stored in the database (e.g., `Form` entities), allow for dynamic modification of the form structure at runtime without redeploying the application. Third, a metadata-driven model supports dynamic loading, using `FormMapper` to load form metadata from the database and dynamically construct the form based on the metadata, enabling adjustments to form behavior without modifying the code.

[0061] For example, a form engine can use a rule engine (such as Drools) instead of the existing plug-in builder mechanism. By defining form processing rules, the system can dynamically process form data according to those rules. The advantage of this approach is that the rule definition is flexible and can handle complex business logic.

[0062] It's important to note that the form engine is the "data hub" of the entire architecture, with the core function of resolving inconsistencies in authentication document data across different fragments. It stores and supplies the common data required by authentication documents through a "plug-in builder + metadata-driven" approach, serving as the "sole data source" for the fragment engine. In terms of data supply logic, all Fragment builders in the fragment engine (such as TsfModuleFragment) must obtain data through the form engine's DefaultDataBuilder (rather than directly querying the database or hard-coding), ensuring that "the same data is completely consistent across different fragments." Its extended adaptability supports the needs of authentication documents based on different standards (such as ISO standards and enterprise-defined standards). Different forms can be configured to achieve differentiated data supply, while common data fields remain consistent, ensuring data compatibility across standard documents. Furthermore, its collaboration with low-code components, through inheritance of WABaseService, allows for quick acquisition of "soft deletion and transaction management" capabilities for form data, avoiding logical vulnerabilities in form data operations (such as accidental deletion of form configurations).

[0063] In this embodiment of the invention, a pluggable form builder and a unified data processing interface are used to separate the form structure from the data processing logic, supporting dynamic construction and flexible configuration to meet the needs of different business scenarios and solve the problem of lack of dynamism and uniformity in form processing.

[0064] In one possible implementation, S3 specifically includes sub-steps S301 to S307:

[0065] S301: Receives user request form data and obtains form request parameters through the form engine controller.

[0066] S302: The FormEngine class processes the form request parameters to obtain the initial form request parameters, which include the form ID and the business ID.

[0067] The FormEngine class is the core driver class of the form engine, responsible for coordinating the entire lifecycle of form construction. This class dynamically loads corresponding component plugins and data builders by parsing form metadata configurations, and organizes the form structure according to predefined rendering logic. Internally, it encapsulates core mechanisms such as form initialization, data binding, validation rule execution, and event handling. As a unified scheduling center, it integrates scattered form elements, data sources, and interactive behaviors into a complete, runnable form instance.

[0068] The form ID is a key-value pair that uniquely identifies a specific form configuration or template in the system.

[0069] The business ID is a key identifier used to uniquely identify a business instance or entity within a specific business context or operational process.

[0070] S303: Query form structure information based on form ID.

[0071] S304: Locate the plug-in data builder based on the form ID.

[0072] S305: Execute the buildData method of the pluggable data builder.

[0073] The `buildData` method is the core interface method of the pluggable data builder, defining a standard contract for data construction. This method receives form parameters and context information, and processes the raw data into a standardized data model recognizable by the form by executing specific data retrieval logic (such as database queries, API calls, or computational transformations). Its implementation follows the open / closed principle, allowing for expansion to support multiple data sources through different plug-ins, ensuring the form engine can dynamically adapt to various data supply needs without affecting the main architecture.

[0074] S306: Obtain business data.

[0075] S307: Combine form structure information and business data to form form data.

[0076] In this embodiment of the invention, the plug-in data construction mechanism of the form engine achieves complete decoupling between form structure and data logic, supports dynamic adaptation to multiple data sources through an extensible builder, and significantly improves the flexibility and maintainability of form processing while ensuring the stability of the system architecture.

[0077] S4: Based on the form data, the HTML fragment data is constructed by calling the plug-in fragment builder through the fragment engine.

[0078] The pluggable fragment builder is the execution unit within the fragment engine responsible for specific fragment generation tasks. It employs a pluggable architecture to encapsulate fragment building logic for different business scenarios into independent, pluggable components. Each builder focuses on a single fragment type and follows a unified build interface, implementing the complete process of data processing, HTML assembly, and style binding. When a fragment generation request is received, the engine dynamically calls the matching builder instance based on the fragment identifier, executing its standardized methods (such as `buildHtml`) to output the target fragment. This design allows the system to quickly support new fragment types by extending the plugin library, flexibly adapting to the diverse and changing needs of front-end views without modifying the core engine.

[0079] HTML fragment data refers to local HTML code blocks that are dynamically generated by the backend and have independent semantics and display functions.

[0080] It should be noted that a fragment refers to a specific section within the certification document. Different sections have different rendering logic (such as paragraphs, lists, tables, etc.).

[0081] Optionally, all the data required to build the HTML fragment data in S4 is forced to be obtained by calling the pluggable data builder in S3.

[0082] It should be noted that the fragment engine must retrieve data from the form engine through DefaultDataBuilder (fragments are prohibited from retrieving data independently). The form engine must rely on the low-code component WABaseService to implement data transactions / soft deletion (the form engine is prohibited from developing its own data logic).

[0083] In this embodiment of the invention, by mandating that HTML fragment data must be obtained by calling the plug-in data builder of the form engine, a strict data supply closed loop is established, which completely eliminates the problem of inconsistency of multi-fragment data from the architectural level, and ensures the accuracy and reliability of the content of the authentication document.

[0084] Specifically, the fragment engine is built upon the core class FragmentEngine and is dedicated to data acquisition, cleaning, and rendering into specific styles according to specific rules. This engine achieves flexible data processing and diverse outputs through a pluggable fragment builder mechanism.

[0085] Furthermore, the dynamism of the fragment engine primarily stems from the following three aspects: A pluggable builder mechanism, through the abstract class `DefaultFragmentBuilder` and its concrete implementations, allows for the dynamic extension of the construction logic for different fragments without modifying the core engine code. Runtime-configurable templates: Fragment rendering templates are stored in the `templatePath` field of the `Fragment` entity, allowing for dynamic modification of the template path at runtime without redeploying the application. Support for a dynamically loaded metadata-driven model: Fragment metadata is loaded from the database via `FragmentService`, and fragments are dynamically constructed based on this metadata, enabling adjustments to fragment behavior without modifying the code.

[0086] For example, a fragment engine can use the pipeline pattern instead of the existing chain-of-responsibility pattern. By defining a series of processing steps, data is processed sequentially through each step. The advantage of this approach is that the processing flow is clear, easy to understand, and easy to maintain.

[0087] It's important to note that the fragment engine is the "upper-level specification and rendering core" of the entire architecture. With the goal of "solving the chaos in authentication document fragment development," it defines a "standardized architecture for fragment development" through "base class constraints + engine scheduling + Velocity templates." Dependence on the form engine: The fragment engine cannot independently obtain data; it needs to call the form engine's interface through DefaultDataBuilder to obtain the basic data required for authentication document fragments. Dependence on low-code components: By inheriting from WABaseMapper, it quickly obtains the ability to query the "fragment ID and builder mapping relationship," eliminating the need to repeatedly develop the access logic for mapping configuration. Core value: Ensuring that all fragments have "unified development logic (inheriting from DefaultFragmentBuilder), unified API calls (FragmentUnifyController's getHtmlById), and unified data sources (form engine)," ultimately enabling the rapid generation of a complete authentication document by "concatenating multiple fragments."

[0088] In this embodiment of the invention, HTML fragments are dynamically generated by scheduling a pluggable fragment builder through a fragment engine, thereby achieving complete decoupling between view content and business logic and improving the reusability and maintainability of front-end components.

[0089] In one possible implementation, S4 specifically includes sub-steps S401 to S405:

[0090] S401: Receives user-requested fragment data and obtains fragment request parameters through the fragment engine controller.

[0091] S402: The FragmentEngine class processes the fragment request parameters to obtain the initial fragment request parameters, which include the fragment ID and the business ID.

[0092] The FragmentEngine class serves as the central coordinator and execution core of the fragment engine, responsible for scheduling the entire fragment generation process. This class dynamically locates and invokes the corresponding pluggable fragment builder by parsing fragment metadata configuration, while coordinating supporting aspects such as data preparation, dependency injection, and exception handling. Internally, it encapsulates key mechanisms such as fragment cache management, builder lifecycle control, and rendering pipeline assembly, acting as the central hub of the system's view layer, providing unified and efficient fragmented content output services for upper-layer business logic.

[0093] Among them, the fragment ID is the business primary key used in the fragment system to uniquely identify and locate a specific UI fragment resource.

[0094] S403: Search for fragment information based on fragment ID.

[0095] S404: Locate the pluggable fragment builder based on the fragment ID, where the pluggable fragment builder is a subclass of DefaultFragmentBuilder.

[0096] It should be noted that the new form must inherit from DefaultDataBuilder, and the new fragment must inherit from...

[0097] Following DefaultFragmentBuilder, all fragment calls must be made through FragmentEngine+Frag-

[0098] mentUnifyController (prevents custom base classes or API calls).

[0099] S405: Call the buildHtml method of the pluggable fragment builder to construct HTML fragment data.

[0100] The `buildHtml` method is the core interface method in the pluggable fragment builder, responsible for defining a unified contract for HTML fragment generation. This method receives business data, context parameters, and configuration information as input, and outputs HTML code fragments that conform to front-end rendering standards by performing data transformation, logic processing, and template combination. Its implementation follows the dependency inversion principle, allowing different builder plugins to implement specific HTML construction logic according to business scenarios. The system ensures the pluggability of various fragments and the consistency of generation behavior through standardized interface calls.

[0101] In this embodiment of the invention, the fragment engine achieves complete decoupling between data processing and style rendering through a pluggable builder mechanism, runtime configurable templates, and a metadata-driven mode. This allows the system to dynamically expand fragment types, adjust rendering templates, and update fragment behavior in real time without modifying the core code. This design significantly improves the system's flexibility and maintainability. Simultaneously, diverse processing solutions such as the pipeline pattern provide a clear and scalable data processing flow for complex business scenarios, reducing development complexity and maintenance costs.

[0102] S5: Using a rendering template, render the HTML fragment data and the form data associated with the HTML fragment data to generate the rendered content of the authentication document.

[0103] Among them, the rendering template is a document architecture that embeds specific syntax tags, serving as a blueprint mechanism to separate data from presentation logic. It structurally integrates dynamic data with the static HTML skeleton through predefined instructions such as placeholders, conditional statements, and loop structures.

[0104] In this embodiment of the invention, HTML fragments and associated form data are rendered in a unified manner by using a rendering template, which achieves the separation of data and view, improves the efficiency of interface generation, and ensures the consistency of multi-terminal output.

[0105] In one possible implementation, S5 specifically includes sub-steps S501 and S502:

[0106] S501: By applying a data cleaning rule chain, form data with related HTML fragment data is processed to obtain standardized data.

[0107] Among them, the data cleaning rule chain is a standardized processing pipeline composed of multiple ordered data processing rules, which is specifically used to perform a series of standardized, secure and structured transformation operations on the original business data.

[0108] S502: Renders standardized data and HTML fragment data using template rendering rules to generate rendered content.

[0109] The template rendering rules are a set of logical instructions that control the process of merging data and view. They define specific rules for how to map cleaned, standardized data into HTML templates.

[0110] Optionally, the data cleaning rule chain includes: field filtering rules, formatting rules, de-identification rules, transformation rules, and aggregation rules.

[0111] Among them, field filtering rules are the basic processing units in the data cleaning chain, responsible for selectively retaining or removing data fields according to predefined whitelist or blacklist strategies.

[0112] Among them, formatting rules are structured processing specifications specifically for standardized data display, which uniformly convert the original data types through predefined format templates.

[0113] Among them, the desensitization rule is a data security processing strategy designed to protect sensitive information, which uses a specific masking algorithm to irreversibly transform key fields.

[0114] Among them, the transformation rules are mapping specifications for solving the heterogeneity of data structures, and are used to achieve bidirectional transformation between different data models.

[0115] Among them, aggregation rules are synthesis strategies for multi-dimensional data association calculations, which perform joint operations on discrete fields through preset aggregation functions.

[0116] In this embodiment of the invention, a data cleaning rule chain and a template rendering mechanism are introduced to achieve standardized processing of form data and efficient content generation. First, a data cleaning chain, including multi-dimensional rules such as field filtering, formatting, data masking, transformation, and aggregation, transforms the original form data into standardized data that conforms to business specifications. Then, combined with template rendering rules, the standardized data is fused and rendered with HTML fragment data to ultimately generate rendered content. This solution effectively improves the standardization and consistency of data processing. Simultaneously, configurable cleaning rules ensure data security and output quality, significantly enhancing system reliability and content generation efficiency.

[0117] S6: Return the rendered content to the user to generate the authentication document.

[0118] In this invention, the user terminal refers to the front-end carrier that interacts with the back-end service, which is the terminal interface through which the user directly operates and receives rendering results.

[0119] In this embodiment of the invention, by returning standardized rendered content to the user end, a complete closed-loop delivery from the data layer to the presentation layer is achieved, which ensures the consistency of the certification document output while eliminating the repetitive coding work in the traditional front-end and back-end integration.

[0120] It should be noted that the entire architecture of this invention aims to "efficiently generate standardized certification documents" and adopts a "layered design + plug-in extension" model, which is divided into 5 layers from bottom to top. Each layer communicates through a "standardized interface", which ensures the stability of the architecture and supports business expansion.

[0121] Specifically, this invention adopts a layered architecture design, comprising five layers from bottom to top: The first layer is the data access layer, containing WABaseMapper, whose core responsibility is to provide a unified database operation interface, including CRUD and soft delete, to support the data storage needs of upper-layer components. This layer provides the service layer with database access capabilities for form data and fragment configurations, without directly interacting with the engine layer. The second layer is the service layer, containing WABaseService, whose core responsibility is to encapsulate general business logic, including transaction management and data validation, providing data processing support for the control layer and engine layer. This layer provides data transaction and logic validation capabilities for the form engine's DefaultDataBuilder and the fragment engine's FragmentEngine. The third layer is the control layer, containing WABaseController (business request routing) and FragmentUnifyController (a unified entry point for fragment requests, providing services only through the getHtmlById interface). Its core responsibility is to receive user requests, including form data submissions and fragment rendering requests, and route them to the corresponding engine or service. FragmentUnifyController receives fragment requests and calls the FragmentEngine of the fragment engine for processing, while the business controller handles form configuration requests by inheriting from WABaseController. The fourth layer is the engine layer, containing the form engine and the fragment engine. The form engine consists of FormEngine and DefaultDataBuilder, while the fragment engine consists of FragmentEngine and DefaultFragmentBuilder. This layer is the core business logic layer. The form engine manages data supply, and the fragment engine manages fragment development specifications and rendering. Their interaction logic involves the fragment engine's Fragment builder calling the form engine through DefaultDataBuilder to obtain data. The engine layer also relies on the business logic support of the service layer. The fifth layer is the presentation layer, which contains Velocity templates and front-end interaction interfaces. Its templates are fixed in the resources / template directory with a unified loading path. Its core responsibility is to store fragment rendering templates, output HTML fragments, and finally assemble them into a complete authentication document. This layer loads its Velocity templates by the fragment engine, and after rendering, returns HTML fragments to the front end through the control layer.

[0122] It's important to note that each layer has a clear responsibility (the data layer manages storage, the service layer manages logic, and the engine layer manages the core business logic). Modifying the logic in one layer (such as changing the template engine) does not affect other layers, adhering to the "open / closed principle." Adding a new form type only requires developing a new subclass of DefaultDataBuilder. Adding a new document fragment only requires developing a new Fragment builder, without modifying the core engine code. A closed-loop data flow is implemented: user request → controller layer → engine layer → service layer → data access layer → database. Data collection and output form a complete closed loop, ensuring consistent authentication document data and efficient development.

[0123] Furthermore, adding a new form type only requires developing a subclass of DefaultDataBuilder, without modifying the core form engine code. Adding a new document fragment only requires developing a builder that inherits from DefaultFragmentBuilder, without modifying the core fragment engine code.

[0124] It should be noted that the core features of the low-code component of this invention include a three-layer generic abstract architecture—the hierarchical relationship between WABaseController (control layer), WABaseService (service layer), and WABaseMapper (data layer)—and providing "basic data capabilities that do not require repeated development" for the form / fragment engine. The core features of the form engine include data centralization (serving as the "sole data source" for the fragment engine), pluggable data construction based on subclasses of DefaultDataBuilder for extending different standard forms, and a metadata-driven mechanism that dynamically loads database-stored form structures via FormMapper. The core features of the fragment engine include the development specification constraint that all fragments must inherit the DefaultFragmentBuilder base class, unified scheduling and interface for matching builders based on IDs via FragmentEngine, and template management specifications with fixed storage paths for Velocity templates.

[0125] In practical applications, a three-tier collaborative architecture was constructed, supported by low-code components, with a form engine as the sole data hub, and a fragment engine responsible for standardized rendering. General data capabilities are provided through a three-tier generic abstraction of WABaseController, WABaseService, and WABaseMapper. Plugin-based data provisioning is implemented using subclasses of DefaultDataBuilder, and all fragments are required to inherit the DefaultFragmentBuilder base class to unify development standards. A data loop mechanism is established, requiring the fragment engine to call the form engine, and standardized output is achieved using Velocity templates with fixed paths. This architecture completely solves the problem of inconsistent data across multiple fragments through a closed-loop data supply. Standardized constraints and general encapsulation reduce code duplication and improve development efficiency. The plugin assembly mechanism shortens documentation generation time and significantly improves the system's scalability and maintainability.

[0126] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0127] In this embodiment of the invention, by establishing a form engine as the sole data source architecture and uniformly planning the data acquisition path, the data inconsistency problem caused by scattered interfaces is fundamentally eliminated. Through the collaborative working mechanism of the form engine and the fragment engine, document assembly is automated, eliminating the need for manual intervention, significantly improving system scalability and maintainability, and ultimately forming a complete solution with loose coupling and high reusability.

[0128] Reference manual attached Figure 2 The diagram shows a schematic representation of the structure of an authentication document generation system provided in an embodiment of the present invention.

[0129] This invention provides an authentication document generation system 20, including a processor 201 and a memory 202.

[0130] The memory 202 stores programs or instructions that can run on the processor 201. When the program or instructions are executed by the processor 201, they implement the steps of the above-described method for generating authentication documents and achieve the same technical effect. To avoid repetition, the present invention will not elaborate further.

[0131] It should be understood that the processor 201 in this embodiment of the invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0132] It should also be understood that the memory 202 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SynchLinkDRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0133] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0134] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0136] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0137] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0138] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0140] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium 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 invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0141] This invention provides a readable storage medium that includes: storing a program or instructions on the readable storage medium, wherein when the program or instructions are executed by a processor, the program or instructions implement the steps of the above-described authentication document generation method and achieve the same technical effect. To avoid repetition, this invention will not elaborate further.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating authentication documents, characterized in that, include: S1: Obtain the user request to generate the authentication document; S2: In response to the user request, the business entity is encapsulated in a unified code manner through a generic controller based on generic abstraction to obtain the underlying support data that provides unified data for the form engine and the fragment engine; Specifically, S2 includes: S201: Receive the user request through the service controller; S202: Determine whether the business controller inherits from the generic controller base class based on the generic abstraction; if so, call the generic CRUD method through the generic controller base class, link the generic service class and the generic data access interface to complete the unified data processing of the business entity and obtain the underlying support data; otherwise, execute custom logic. S3: Based on the underlying support data, construct the form data by calling the plug-in data builder through the form engine; Specifically, S3 includes: S301: Receive user request form data and obtain form request parameters through the form engine controller; S302: The form request parameters are processed through the FormEngine class to obtain the initialization form request parameters, wherein the initialization form request parameters include the form ID and the business ID; S303: Query the form structure information based on the form ID; S304: Locate the plug-in data builder based on the form ID; S305: Execute the buildData method of the pluggable data builder; S306: Obtain business data; S307: Combine the form structure information and the business data to form the form data; S4: Based on the form data, construct HTML fragment data by calling the plug-in fragment builder through the fragment engine; Specifically, S4 includes: S401: Receives user-requested fragment data and obtains fragment request parameters through the fragment engine controller; S402: The fragment request parameters are processed through the FragmentEngine class to obtain the initial fragment request parameters, wherein the initial fragment request parameters include the fragment ID and the business ID; S403: Based on the fragment ID, search for fragment information; S404: Based on the fragment ID, locate the pluggable fragment builder, wherein the pluggable fragment builder is a subclass of DefaultFragmentBuilder; S405: Call the buildHtml method of the pluggable fragment builder to construct the HTML fragment data; S5: Using a rendering template, render the HTML fragment data and the form data associated with the HTML fragment data to generate the rendered content of the authentication document; S6: Return the rendered content to the user terminal to generate the authentication document.

2. The method for generating authentication documents according to claim 1, characterized in that, All the data required to construct the HTML fragment data in S4 is forcibly obtained by calling the pluggable data builder in S3.

3. The method for generating authentication documents according to claim 1, characterized in that, S202 specifically includes: S2021: By calling the general CRUD method through the general controller base class, a calling instruction is generated; S2022: Trigger service processing based on the aforementioned call instruction; S2023: Determine whether the service processing business inherits from the general service class; if yes, proceed to S2024; otherwise, execute the custom data logic; S2024: By calling the general data access interface through the general service class, the business entity is processed in a unified manner, and the underlying support data is output for subsequent form engine and fragment engine to call.

4. The method for generating authentication documents according to claim 1, characterized in that, S5 specifically includes: S501: By applying a data cleaning rule chain, the form data that is related to the HTML fragment data is processed to obtain standardized data; S502: Render the standardized data and the HTML fragment data using template rendering rules to generate the rendered content.

5. The method for generating authentication documents according to claim 4, characterized in that, The data cleaning rule chain includes: field filtering rules, formatting rules, de-identification rules, transformation rules, and aggregation rules.

6. A system for generating authentication documents, characterized in that, include: Processor and memory; The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the method for generating authentication documents as described in any one of claims 1 to 5.

7. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the authentication document generation method as described in any one of claims 1 to 5.

Images