Implementation method for dynamic display of examination and approval verification and examination and approval verification system
By introducing storage middleware between the server and the front-end, the dynamic display of the approval process is realized, and the problems of numerous processes and repeated verification in traditional OA systems are solved, improving the approval efficiency and user experience.
Patent Information
- Application Number
- CN202510298953.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-13
- Publication Date
- 2025-07-04
AI Technical Summary
In traditional OA systems, process approval and verification are numerous and repeated, resulting in low process processing efficiency, serious waste of resources, and poor user experience.
The storage middleware is introduced between the server and the front-end. The server classifies multiple check items and caches the results. The front-end reads the results from the middleware and generates a structured collection, and dynamically displays the real-time status and progress bars of the check items.
It realizes dynamic display of multi-item verification, reduces duplicate operations, improves approval efficiency, improves system performance and user experience, and is suitable for the approval stage of various business flows.
Smart Images
Figure CN120258706A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of data processing, intelligent healthcare, and financial technology, and specifically relates to a method for implementing dynamic display of approval verification and an approval verification system. Background Art
[0002] There are many scenarios of online approval in the business processes of all walks of life. Workflow approval is an important system tool for business approval in many companies. Especially in the old office systems (OA systems) of many companies, due to the relatively backward technical framework and the long-term iteration of business, the process approval verification has become extremely bloated, resulting in complex process approval processes, numerous submission verifications, and repeated verifications, and the user experience is very poor.
[0003] Traditional OA systems usually submit approvals serially based on processes, and each verification item is executed sequentially. There is a situation where the verified items that have been processed are submitted repeatedly for approval. The disadvantages of this method are relatively obvious: low process processing efficiency, repeated operations by approvers, waste of system resources caused by each repeated submission, and inability to directly process when jumping to third-party links, etc. Summary of the Invention
[0004] To solve the above problems, this application provides a method for implementing dynamic display of approval verification and an approval verification system to overcome or at least partially overcome the deficiencies of the prior art.
[0005] This application adopts the following technical solutions:
[0006] In a first aspect, this application provides a method for implementing dynamic display of approval verification. The method is implemented through an approval verification system, and the approval verification system includes: a server, a storage middleware, and a front end. The method includes:
[0007] The server classifies and processes multiple verification items of the approval process, and caches the processing results in the storage middleware;
[0008] The front end reads the processing results from the storage middleware and stores them in a structured set. The structured set at least includes: a status field, and the status field is a field used to identify the status of the verification item;
[0009] The front end generates a visual pop-up window interface based on the structured set to dynamically display the real-time status and progress bar of each verification item.
[0010] In a second aspect, this application provides an approval verification system. The approval verification system includes: a server, a storage middleware, and a front end. The storage middleware is communicatively connected to the server and the front end respectively;
[0011] The server is used to classify and process multiple verification items of the approval process, and cache the processing results in the storage middleware;
[0012] The storage middleware is used to store the processing results of the server's classification and processing of multiple verification items, and provide them for the front end to read;
[0013] The front end is used to read the processing results from the storage middleware and store them in a structured set. The structured set at least includes a status field, and the status field is a field used to identify the status of the verification item;
[0014] The front end is used to generate a visual pop-up window interface based on the structured set to dynamically display the real-time status and progress bar of each verification item.
[0015] The above at least one technical solution adopted by this application can achieve the following beneficial effects:
[0016] This application adds a storage middleware between the server and the front end. Based on this, an implementation method for dynamic display of verification applied to the approval process business is proposed. After receiving multiple verification items of the approval process, the server classifies and processes them, and then caches the processing results in the storage middleware; the front end reads the above processing results from the storage middleware and stores them in a structured set. The structured set at least includes: a status field, and the status field is a field used to identify the status of the verification item; then the front end generates a visual pop-up window interface based on the structured set, thereby dynamically displaying the real-time status and progress bar of each verification item.
[0017] This application comprehensively considers issues such as process approval, process flow, and multi-terminal adaptation access. Combining the caching function of the storage middleware and the front-end data sorting function, it realizes the dynamic display of multi-project verification, and is applicable to the approval stage of various business processes, especially applicable to the approval process with a large number of verification items in a leasing company.
[0018] In this application, the server completes all verification items at one time and updates the verification status in real time, avoiding repeated operations of single serial submission, and realizing redundancy removal for the existing verification process.
[0019] In this application, the front end flexibly integrates all verification items into a data set in the form of a structured set, while providing reusability and supporting the diversity of verification items, making the verification more flexible and highly scalable.
[0020] In this application, the approver does not need to submit the items that have been verified after each modification. Instead, the approver only needs to process all the failed verification items at once and then submit, which greatly reduces the review time and improves the approval efficiency. All verification items are displayed in a pop-up window, facilitating the approver to handle them more intuitively and clearly.
[0021] In this application, the server-side caches and processes all verification tasks. The way it can adapt to multi-terminal applications is more fault-tolerant, eliminating the problem of the mixing of front-end and back-end services in traditional technologies. Following the idea of front-end and back-end separation, the front-end can focus more on the interface presentation between the user web content and user interaction; the server-side is responsible for data processing and business logic processing, and can adapt to the use of multi-terminal applications, resulting in a greater improvement in the system service performance and a better user experience. Brief Description of the Drawings
[0022] The drawings described herein are used to provide a further understanding of this application and form a part of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation to this application. In the drawings:
[0023] Figure 1 A schematic structural diagram of an approval verification system according to an embodiment of this application is shown;
[0024] Figure 2 A schematic flow diagram of an implementation method for dynamic display of approval verification according to an embodiment of this application is shown. Detailed Embodiments
[0025] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.
[0026] To enable those of ordinary skill in the art to more clearly understand the technical solutions provided by the embodiments of this application, the technical solution concept of this application will be described first.
[0027] Currently, many companies, institutions, hospitals, etc. have achieved paperless office. There are approval scenarios in many scenarios of the business process, such as medical device procurement business, physical asset leasing business, etc. In a business link, sometimes different roles are required to perform approvals, and there are scenarios where multiple business nodes need to be approved. For approvals, verifications are usually required, such as verifying the identity of the approver, verifying whether the information filled in by business personnel is correct, etc.
[0028] In traditional OA systems, serial submission for approval is usually adopted in the approval process of business processes. Each verification item is executed sequentially. If an approval item fails the verification, it is necessary to resubmit the processed verification items for re-approval. This results in low processing efficiency of the approval verification process, repeated operations by approvers, waste of system resources caused by each repeated submission, inability to directly process when it is necessary to jump to a third-party link, and other problems.
[0029] In view of the above problems, this application proposes an implementation method for dynamic display of approval verification. Taking a leasing company as an example, the concept of this application is described as follows: Currently, the work flow approvals of leasing companies in the industry are mostly the same, and the systems of different companies only differ in the underlying framework of the approval flow. The mainstream process engine frameworks include Jbpm4, Activiti, Flowable, camunda, etc. Therefore, without considering modifying the underlying framework, this application filters all the verification items that need to be verified in the approval on the server side, executes all the verification items at once, updates the verification status in real time, and the front end summarizes and displays all the verification results through pop-up windows by data processing.
[0030] Figure 1 FIG. shows a schematic structural diagram of an approval verification system according to an embodiment of the present application. It can be seen from the figure that a storage middleware 120 is added between the server side 110 and the front end 130 in the approval verification system 100 of the present application. The storage middleware 120 is respectively communicatively connected to the server side 110 and the front end 130; the storage middleware 120 is used to cache the result data generated by the server side 110 and provide it for the front end 130 to read.
[0031] It should be noted that the approval verification system of this application is not limited to Figure 1 the example of Figure 1 The storage middleware 120 in can be set independently of the server side 110 or integrated with the server side 110. This application does not make any limitations in this regard. Any system or architecture that can implement the business logic of the implementation method for dynamic display of approval verification provided by this application is acceptable.
[0032] The storage middleware 120 can be any data storage device and technology in the prior art. In some embodiments of the present application, Redis is recommended. Redis data is stored in memory, with extremely fast reading and writing speeds, suitable for high-concurrency scenarios; and it adopts a single-threaded model, avoiding the competition and lock overhead of multiple threads, simplifying the design and improving the performance; it supports multiple data structures such as strings, hashes, lists, sets, ordered sets, etc., with a wide range of application scenarios and high availability and scalability; the memory operation and efficient data structures bring extremely low latency, suitable for real-time applications.
[0033] Figure 2The figure shows a schematic flowchart of an implementation method for dynamically displaying approval verification according to an embodiment of the present application. The implementation method for dynamically displaying approval verification of the present application can be implemented through, but not limited to, Figure 1 the exemplary approval verification system. From Figure 2 it can be seen that this embodiment includes steps S210 to S230:
[0034] Step S210: The server classifies and processes multiple verification items of the approval process, and caches the processing results in the storage middleware.
[0035] In the approval process of a business flow, there are often multiple verification items. The staff submitting for approval can submit the approval node once or multiple times. After submission, multiple verification items are generated, and the server classifies and processes these verification items.
[0036] Specifically, in some embodiments of the present application, the server classifies and processes multiple verification items received for the approval process, including: classifying the multiple verification items according to pre-divided verification types, and verifying each of the verification items according to the corresponding verification rules to obtain the processing results; wherein, the verification types are pre-divided according to preset categories, each verification type includes at least one verification rule, and the verification rules are divided into automatic verification rules and manual confirmation rules according to the verification types; and trigger conditions for each verification rule are set.
[0037] For classification, it can be classified according to multiple dimensions. For example, classified according to verification content, such as data format verification items, data range verification items, business rule verification items, security verification items, etc. Among them, for data format verification, it is to check whether the data conforms to the expected format, such as email, mobile phone number, date format, etc.; for data range verification, it is to check whether the data is within the legal range, such as age, amount, length, etc.; for business rule verification, it is to check whether the data conforms to the business logic, such as order status, user permissions, etc.; for security verification, it is to check whether the data contains sensitive information or potential security risks, such as SQL injection, etc.
[0038] In some embodiments, it can also be classified according to the verification timing, such as pre-request verification items, in-business-process verification items, pre-persistence verification items, etc. Among them, for pre-request verification: verify when the request reaches the server, such as whether the parameters are empty and whether they conform to the interface specification; for in-business-process verification: verify during the execution of the business logic, such as whether the inventory is sufficient and whether the user has permissions; for pre-persistence verification: verify before the data is stored in the database, such as data uniqueness, integrity, etc.
[0039] In some embodiments, classification can also be performed according to the verification scope. For example, it can be divided into global verification and local verification. Among them, global verification is applicable to the general verification of all requests, such as identity authentication and request header verification; local verification is only applicable to the verification of specific business scenarios, such as inventory verification when creating an order, etc.
[0040] For each category, that is, the verification type, there is at least one corresponding verification rule. According to business needs or the requirements of the verification category, the verification rules can be divided into automatic verification rules and manual confirmation rules. Among them, the automatic verification rules are automatically verified by the server according to the preset verification logic; the manual confirmation rules are items that require the operation and confirmation of the reviewer; and trigger conditions are set for each verification rule.
[0041] After classifying the verification items, the server can perform batch verification processing according to the category and based on the trigger conditions. Usually, the verification logic for one category is consistent or general. For example, a rule engine is used to centrally manage the verification rules of the same category and execute them in batches. Exemplarily, the verification rules related to rental orders (inventory, amount, user permissions) are concentrated in a rule file and executed uniformly; another example is to develop a custom batch validator to implement unified verification logic for different categories of verification items. Exemplarily, a UserValidator is written to batch verify information such as the username, password, and email when a user registers.
[0042] Adopting the method of classification and batch processing has many advantages. For example, it can improve the verification efficiency. Batch processing reduces duplicate code and multiple calls, thus enhancing the execution efficiency of verification; it reduces code redundancy. Centralizing the verification logic of the same category avoids code duplication and is convenient for maintenance; it enhances maintainability. After centralizing the batch verification logic, it is more convenient to modify and expand. When adding a new verification rule, only need to add it in the corresponding batch validator without modifying the code in multiple places, etc.
[0043] In some embodiments of the present application, the server performs the verification processing of the multiple verification items through asynchronous threads concurrently in the form of interface tasks.
[0044] Specifically, the server can encapsulate the processing logic of each verification item into an independent interface task. For example, in the loan approval scenario, the "income certificate verification" task is encapsulated into an independent interface. The input is the PDF file uploaded by the user, and the output is the verification status (passed / failed) and the error reason (such as "the file is blurred and cannot be recognized"), etc.
[0045] The server implements high-concurrency processing through a thread pool and an asynchronous framework. The specific steps are as follows: First, task distribution is performed. When a batch of verification items is received, the server splits them into multiple interface tasks and delivers them to a task queue, such as RabbitMQ, Kafka, etc.; then the thread pool manager (such as ExecutorService in Java) pulls tasks from the queue according to the preset number of threads (such as the core thread number = CPU core number × 2); further, the tasks are executed concurrently. Each thread independently executes an interface task and uses non-blocking I / O operations, such as asynchronous database queries and asynchronous HTTP client calls; finally, result aggregation is performed. After each thread completes the task, the result is written to a shared cache, that is, the aforementioned storage middleware. Further optionally, the server monitors the completion status of all tasks. When all tasks are completed, a callback notification is triggered or the global status flag is updated.
[0046] Step S220: The front end reads the processing result from the storage middleware and stores it in a structured set. The structured set at least includes: a status field, which is a field used to identify the status of the verification item.
[0047] The front end obtains the processing result from the storage middleware, and then can store these processing results in an array on the front-end local. Usually, one verification item corresponds to one structured set. Among them, this array is a structured array set, denoted here as the structured set checkList. In this structured set, there is at least one field, and these fields can characterize certain attributes of the verification item.
[0048] In some embodiments, the structured set is presented in a preset structure, and it at least includes a status field (status), which is a field used to identify the status of the verification item.
[0049] In other embodiments, the structured set includes multiple field attributes, and each field attribute is in a parallel relationship. Specifically, the structured set may include but is not limited to the following field attributes:
[0050] A unique identifier field (id), which is used to control the display logic and operation binding of the verification item;
[0051] A status field (status), which is used to display the verification status information. The status field is configured with the following status types: in verification, verification failed, verification passed, and to be confirmed;
[0052] A process prompt message (toast), which is used to dynamically display the text information during the verification process;
[0053] A success prompt message (sucMsg), which is used to display the text information after the verification is successful;
[0054] The success message object (sucMsgObj) is used to display the configuration interaction function after passing the verification;
[0055] The error message list (errMsgList) is used to display several error prompts and their associated operations when the verification fails; among them, the configuration of the error message list specifically includes: configuring corresponding interactive function controls for each error type and associating third-party system jump links or pop-up window trigger instructions; and setting the display priority rules of the error prompts;
[0056] The error prompt message (errMsg) is used to display the error prompt according to the error message list; and
[0057] Whether to display the field (isShow) is used to control whether a verification item is verified and displayed.
[0058] Among them, the unique identification field id is the unique id of the verification operation and is the only attribute for controlling the display of verification items, whether the verification passes, and the display of error messages, etc.;
[0059] The status field status represents the status of the verification item, including but not limited to: loading - in verification, failed - verification failed, success - verification passed, switch - to be confirmed;
[0060] The process prompt message toast is the text display during verification, especially when there may be multiple error prompts;
[0061] The success message object sucMsgObj is the button function information after the success message prompt after the verification is successful, and the staff can perform interactive operations through the virtual buttons on the screen;
[0062] The success message sucMsg displays the text for showing that the verification has passed;
[0063] The error message column errMsgList represents all the prompts when the verification fails. When there is a virtual click button (click) in its sub-items, there will be a button function, and clicking can open a pop-up window or jump to a third-party link for the user to perform secondary operations; errMsg will give prompts according to the corresponding types in errMsgList, which is the type of prompt displayed when the verification fails;
[0064] Whether to display the field isShow represents whether to display the verification item. When it is false, there is no need to perform the verification operation. The following shows an example of a structured set:
[0065]
[0066] In some embodiments of the present application, the front end reads the processing result from the storage middleware and stores it in a structured set, including: the front end traverses the processing result in the storage middleware, and for a verification item, fills the field values under at least one field attribute thereof into the corresponding structured set in a preset format.
[0067] The front end traverses all the verification result items in the storage middleware, and can fill the field values under each field attribute of each verification item into the above-mentioned structured set according to the unique identification field id.
[0068] It should be noted that the above-mentioned structured set is not limited to the format given above, as long as it can contain and represent the information required for the above-mentioned verification items.
[0069] Step S230: The front end generates a visual pop-up window interface based on the structured set to dynamically display the real-time status and progress bar of each verification item.
[0070] The front end generates a visual pop-up window interface based on the structured set, that is, the data in the structured set checkList will be displayed to the user in the form of a pop-up window. The visual pop-up window interface is displayed on the user's terminal device, and the terminal device includes but is not limited to mobile phones, tablet computers, and in-vehicle terminal devices, etc.
[0071] In the visual pop-up window interface, the real-time status and progress bar of each verification item can be dynamically displayed, enabling the user to intuitively see the status and progress of each verification item.
[0072] Optionally, in some embodiments of the present application, the visual pop-up window interface can also synchronously display the statistical data of multiple verification items and the verification items to be confirmed.
[0073] That is, the front end can statistically summarize the data of multiple verification items of the audit service and display it in the visual pop-up window interface, such as the real-time statistical number of verification item statuses.
[0074] The visual pop-up window interface can also display the verification items to be confirmed. The front end receives the interaction operation of the user on the unpassed verification items. When it is detected that the status of each verification item reaches the preset passing standard, the process submission function is activated.
[0075] That is, for the verification items that require manual confirmation, such as when the user clicks the slider to complete the confirmation process, for the content that fails the verification, it can only be submitted after completing the operation according to the information prompt; after all verifications pass, click the submit button to end the entire verification process.
[0076] In some embodiments, to avoid page lags or freezes on the user's terminal device during other operations, the processing results fed back by the server can be asynchronously loaded and stored in the storage middleware, improving the user experience of the system page.
[0077] In this application, the front end can be various forms of user front ends, including but not limited to: APP end, mini-program end, official account end, Web end, and H5 page end, etc. In this application, multi-end applications can directly present to users according to the structured set checkList, eliminating the problem of the original mixing of front-end and back-end services. Following the idea of front-end and back-end separation, the front end focuses more on the interface presentation between user web content and user interaction; the back end is responsible for data processing and business logic processing.
[0078] From Figure 2 It can be seen that this application adds a storage middleware between the server and the front end. Based on this, an implementation method for dynamically displaying the verification applied to the approval process business is proposed. After the server receives multiple verification items of the approval process, it classifies and processes them, and then caches the processing results in the storage middleware; the front end reads the above processing results from the storage middleware and stores them in a structured set. The structured set at least includes: a status field, which is a field used to identify the status of the verification item; then the front end generates a visual pop-up window interface based on the structured set, thereby dynamically displaying the real-time status and progress bar of each verification item.
[0079] This application comprehensively considers issues such as process approval, process flow, and multi-end adaptive access, combines the caching function of the storage middleware and the front-end data sorting function, realizes the dynamic display of multi-project verification, and is applicable to the approval stage of various business processes, especially applicable to the approval process of leasing companies with a large number of verification items.
[0080] In this application, the server executes all verification items at once and updates the verification status in real time, avoiding repeated operations of single serial submission and eliminating redundancy in the existing verification process.
[0081] In this application, the front end flexibly integrates all verification items into a dataset in the form of a structured set, while providing reusability and supporting the diversity of verification items, making the verification more flexible and highly scalable.
[0082] In this application, the approver does not need to continue to submit the verified items every time after submitting modifications. Only need to process all unpassed verification items at once and then submit, greatly reducing the review time and improving the approval efficiency. The pop-up window displays all verification items, facilitating the approver to process more intuitively and clearly.
[0083] In this application, the server cache processes all verification tasks, and the way of adapting to multi-terminal applications is more fault-tolerant. It eliminates the problem of the mixed front-end and back-end services in the traditional technology, follows the idea of front-end and back-end separation, and enables the front-end to focus more on the interface presentation between the user web content and user interaction; the server is responsible for data processing and business logic processing, and can adapt to the use of multi-terminal applications, resulting in greater improvement in the system service performance and better user experience.
[0084] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database or other medium used in the embodiments provided in this application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.
[0085] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.
[0086] The above embodiments are only used to illustrate the technical solutions 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 of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements 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, and should all be included in the protection scope of the present invention.
Claims
1. A method for implementing dynamic display of approval verification, which is implemented through an approval verification system, and the approval verification system includes: A server, a storage middleware, and a front end, characterized in that the method includes: The server classifies and processes multiple verification items of an approval process, and caches the processing results in the storage middleware; The front end reads the processing results from the storage middleware and stores them in a structured set, where the structured set at least includes: a status field, and the status field is a field used to identify the status of the verification item; The front end generates a visual pop-up window interface based on the structured set to dynamically display the real-time status and progress bar of each verification item.
2. The method according to claim 1, wherein The visual pop-up window interface can also synchronously display the statistical data of the multiple verification items and the verification items to be confirmed.
3. The method according to claim 1, characterized in that The method further includes: The front end receives an interaction operation of the user on the unpassed verification item, and activates the process submission function when it detects that the status of each verification item reaches a preset passing standard.
4. The method according to claim 1, wherein The server classifies and processes multiple verification items of the received approval process, including: Classifying the multiple verification items according to pre-divided verification types, and verifying each verification item according to the corresponding verification rules to obtain the processing results; Among them, the verification types are pre-divided according to preset categories, each verification type includes at least one verification rule, and the verification rules are divided into automatic verification rules and manual confirmation rules; and trigger conditions for each verification rule are set.
5. The method according to claim 1, characterized in that, The front end reads the processing results from the storage middleware and stores them in a structured set, including: The front end traverses the processing results in the storage middleware. For a verification item, it fills the field values under at least one field attribute into the corresponding structured set according to a preset format. Among them, the preset format includes multiple field attributes, and the field attributes are in a parallel relationship.
6. The method according to claim 5, characterized in that, The structured set includes the following field attributes: A unique identifier field, used to control the display logic and operation binding of the verification item; A status field, used to display verification status information, and the status field is configured with the following status types: in verification, verification failed, verification passed, and to be confirmed; Process prompt information, used to dynamically display text information during the verification process; Success prompt information word, used to display text information after successful verification; Success prompt object, used to display the configured interaction function after verification passes; Error information list, used to display several error prompts and their associated operations when verification fails; Error prompt information, used to display error prompts according to the error information list; And Whether to display field, used to control whether a verification item is verified and displayed.
7. The method according to claim 6, characterized in that, The configuration of the error information list specifically includes: Corresponding interaction function controls configured for each error type, and associated with third-party system jump links or pop-up window trigger instructions; and Setting the display priority rule of the error prompt.
8. According to any one of the methods described in claims 1 to 5, characterized in that, The server performs the verification processing of the multiple verification items through asynchronous threads in the form of interface tasks.
9. According to any one of the methods described in claims 1 to 5, characterized in that, The front end is any one of an APP end, a mini-program end, a public account end, a Web end, and an H5 page end.
10. An approval and verification system, characterized in that, The approval verification system includes: a server, a storage middleware, and a front end. The storage middleware is communicatively connected to the server and the front end respectively; The server is used for classifying and processing multiple verification items of the approval process, and caching the processing results in the storage middleware; The storage middleware is used for storing the processing results of the server's classification and processing of multiple verification items, and providing them for the front end to read; The front end is used for reading the processing results from the storage middleware and storing them in a structured set. The structured set at least includes a status field, and the status field is a field used to identify the status of the verification item; The front end is used for generating a visual pop-up window interface based on the structured set to dynamically display the real-time status and progress bar of each verification item.