Insurance policy anti-filing method and device, computer equipment and storage medium

Abstract

The invention belongs to the technical field of big data, and relates to an insurance policy anti-archiving method, which comprises the following steps of: querying whether an in-transit anti-archiving task exists at present or not according to an in-transit task query request initiated based on an anti-archiving task; if not, insurance policy information of the insurance policy to be subjected to anti-archiving is acquired, and whether the insurance policy information exists in the business table or not is inquired; when the insurance policy information is not in the service table, inquiring whether the insurance policy information exists in an archiving library or not; when the insurance policy information exists in the archiving library, generating a query task based on the obtained anti-archiving insurance policy data of the anti-archiving task; issuing the query task to an execution end for processing through the message queue, and recording an execution result of the query task; and finally, performing consistency verification on an execution result. The invention further provides an insurance policy anti-filing device, computer equipment and a storage medium. The method can be applied to a financial science and technology business management program system, the recovery process of the insurance policy data can be automatically completed, and the anti-archiving efficiency is greatly improved.

Description

Technical Field

[0001] The present application relates to the field of big data technology and is applied to online financial technology processing business scenarios, and in particular to a policy reverse archiving method, device, computer equipment and storage medium. Background Art

[0002] With the continuous development of the insurance business, the management of policy data has become increasingly complex, especially with the numerous challenges of archiving and unarchiving policies. Policy archiving is the process of transferring inactive policy data from business systems to an archive repository for long-term storage, while policy unarchiving is the process of restoring archived policy data to business systems for query and use when needed.

[0003] Currently, policy data management in the insurance industry typically uses database systems for storage and processing. To improve system performance and reduce storage costs, insurance companies regularly archive inactive policy data.

[0004] Traditional policy archiving methods present the following technical issues: First, archived policy information cannot be directly queried and used in business systems, preventing business personnel from timely accessing customers' historical policy information. Second, when archived policies need to be retrieved, manual data collection and script recovery are typically used. This method is not only time-consuming and inefficient, but also prone to data errors caused by manual operation, such as data entry errors and data matching errors. Furthermore, the manual data collection and script recovery processes pose a security risk of data leakage. More importantly, existing technologies lack an automated, efficient, and secure policy de-archiving method, unable to meet the business system's needs for rapid access to archived policy data, nor can they guarantee data consistency and integrity during the de-archiving process.

[0005] Therefore, there is an urgent need for a policy de-archiving method that can automatically process policy de-archiving tasks, ensure data consistency, improve processing efficiency and reduce the risk of manual operations. Summary of the Invention

[0006] The purpose of the embodiments of the present application is to propose a policy reverse archiving method, device, computer equipment and storage medium to solve the technical problems in the traditional policy archiving processing method, in which the policy information cannot be directly queried and used after archiving, the recovery process is time-consuming and inefficient, manual operation is prone to data errors, and there are security risks of data leakage.

[0007] In the first aspect, a method for reverse archiving of insurance policies is provided, which adopts the following technical solution:

[0008] Obtaining a de-archiving task, initiating an in-transit task query request based on the de-archiving task, and querying whether there is currently an in-transit de-archiving task according to the in-transit task query request;

[0009] When there is no in-transit de-archiving task, obtaining the policy information of the policy to be de-archived, and querying whether the policy information exists in the business table;

[0010] If the policy information is not in the business table, query whether the policy information exists in the archive library;

[0011] When the insurance policy information exists in the archive library, obtaining the de-archived insurance policy data of the de-archived task, and generating a query task based on the de-archived insurance policy data;

[0012] Send the query task to the execution end through the message queue for processing, and record the execution result of the query task;

[0013] A consistency check is performed on the execution result, and when the consistency check passes, the de-archiving task is marked as completed.

[0014] In a second aspect, a policy reverse archiving device is provided, which adopts the following technical solution:

[0015] A task query module is used to obtain a de-archiving task, initiate an in-transit task query request based on the de-archiving task, and query whether there is currently an in-transit de-archiving task according to the in-transit task query request;

[0016] A business table query module is used to obtain the policy information of the policy to be de-archived when there is no de-archiving task in progress, and to query whether the policy information exists in the business table;

[0017] An archive library query module, used for querying whether the policy information exists in the archive library when the policy information is not in the business table;

[0018] a task generating module, configured to obtain the de-archived policy data of the de-archived task when the policy information exists in the archive library, and generate a query task based on the de-archived policy data;

[0019] The task sending module is used to send the query task to the execution end through the message queue for processing and record the execution result of the query task;

[0020] The verification module is used to perform consistency verification on the execution result, and when the consistency verification passes, mark the de-archiving task as completed.

[0021] In a third aspect, a computer device is provided, which adopts the following technical solution:

[0022] The computer device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor implements the steps of the above-mentioned insurance policy reverse archiving method when executing the computer-readable instructions.

[0023] In a fourth aspect, a computer-readable storage medium is provided, which adopts the following technical solution:

[0024] The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the above-mentioned insurance policy de-archiving method.

[0025] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0026] The policy de-archiving method provided in this application realizes the automatic recovery of policy data by establishing an intelligent interactive de-archiving mechanism, and can automatically complete the policy data recovery process, greatly improving the de-archiving efficiency, reducing manual intervention, and solving the problem of time-consuming and inefficient recovery process in traditional methods; through a systematic data verification and consistency check mechanism, the accuracy and integrity of the data are ensured, and data errors caused by manual operations are avoided; the use of message queues and automated processing processes reduces the number of links in which manual contact with data occurs, reducing the security risks of data leakage; the automated task management and processing mechanism significantly reduces data maintenance costs and improves system operation efficiency; the system can quickly respond to policy recovery needs, improve business processing capabilities, and enable policy data to be directly queried and used in the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0028] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0029] Figure 2 is a flow chart of an embodiment of a policy reverse archiving method according to the present application;

[0030] Figure 3 This is a schematic structural diagram of an embodiment of an insurance policy reverse archiving device according to the present application;

[0031] Figure 4 It is a structural diagram of an embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0033] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0034] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0035] like Figure 1 As shown, system architecture 100 may include a terminal device 101, a network 102, and a server 103. Terminal device 101 may be a laptop computer 1011, a tablet computer 1012, or a mobile phone 1013. Network 102 is a medium for providing a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0036] The user can use the terminal device 101 to interact with the server 103 via the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0037] The terminal device 101 can be various electronic devices with a display screen and supporting web browsing. In addition to the laptop computer 1011, tablet computer 1012 or mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV) player, a laptop computer and a desktop computer, etc.

[0038] The server 103 may be a server that provides various services, such as a background server that provides support for web pages displayed on the terminal device 101 .

[0039] It should be noted that the insurance policy reverse archiving method provided in the embodiment of the present application is generally executed by a server / terminal device, and accordingly, the insurance policy reverse archiving device is generally set in the server / terminal device.

[0040] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0041] Continue to refer Figure 2 , shows a flow chart of an embodiment of the policy reverse archiving method according to the present application, comprising the following steps:

[0042] Step S201: Obtain a de-archiving task, initiate an in-transit task query request based on the de-archiving task, and query whether there is currently an in-transit de-archiving task according to the in-transit task query request.

[0043] In insurance business systems, to optimize system performance and storage space, inactive policy data is typically migrated from business tables to archives for storage. However, in certain business scenarios, such as customer inquiries about historical policy transactions, handling customer complaints, and claims settlement, archived policy data needs to be restored to the business tables. This is the process of policy de-archiving.

[0044] First, the system retrieves a de-archiving task. De-archiving tasks are typically initiated by business personnel through the system interface or automatically triggered by the system based on preset rules. De-archiving tasks contain the identification information of the policy to be de-archived, such as the policy number and the policy's business type. After receiving the de-archiving task, the system initiates an in-transit task query request based on the task to check whether a de-archiving task for the same policy already exists in the system.

[0045] In this embodiment, the electronic device (eg Figure 1 The server / terminal device shown in the figure can initiate an in-transit task query request via a wired connection or a wireless connection. It should be noted that the wireless connection method may include but is not limited to 3G / 4G / 5G connection, WiFi connection, Bluetooth connection, WiMAX connection, Zigbee connection, UWB (ultra wideband) connection, and other wireless connection methods currently known or to be developed in the future.

[0046] In some optional implementations, the step of querying whether there is currently an in-transit anti-archiving task according to the in-transit task query request includes:

[0047] Extract the de-archiving task ID from the in-transit task query request, and obtain status data based on the de-archiving task ID;

[0048] Use the preset parsing rules to process the status data and obtain the task status and timestamp;

[0049] If the task status is displayed as being processed, the difference between the timestamp and the current time is compared with the preset threshold condition to obtain the comparison result;

[0050] Determine whether the de-archiving task is an in-transit task based on the comparison result;

[0051] When the de-archiving task is an in-transit task, it is determined that there is currently an in-transit de-archiving task; otherwise, it is determined that there is currently no in-transit de-archiving task.

[0052] Specifically, the de-archiving task ID is extracted from the in-transit task query request. This ID usually contains information such as the policy number and task type. Based on the de-archiving task ID, a query is performed through the task management table to obtain the status data of the relevant task.

[0053] The acquired status data is processed using preset parsing rules to extract task status and timestamp information. Task status includes "pending," "processing," "completed," and "failed." The timestamp records the time when the task status was last updated. The preset parsing rules can be parsed using JSON format. Status data is stored as a JSON string containing fields such as "status," "timestamp," and "operator," representing task status, timestamp, and operator, respectively. The values ​​of these fields are extracted using a JSON parser for subsequent task status determination.

[0054] If the task status is displayed as "Processing," the system further compares the difference between the timestamp and the current time and compares it with the preset threshold. The preset threshold is typically set to the maximum expected task processing time, i.e., the preset time threshold, for example, 30 minutes. If the time difference is less than the preset time threshold, the task is processing normally. If the time difference is greater than the preset time threshold, it may indicate that the task is processing abnormally or has been stuck.

[0055] If the time difference is less than the preset time threshold and the task status is "Processing", it is determined that there is currently an in-transit de-archiving task, and the system will terminate the de-archiving operation to avoid repeated processing; otherwise, the system determines that there is currently no in-transit de-archiving task, and you can continue to execute subsequent de-archiving steps.

[0056] By checking whether there is an in-progress de-archiving task, repeated de-archiving operations for the same policy can be avoided, data conflicts and resource waste can be prevented, and system stability and data consistency can be improved.

[0057] Step S202: When there is no in-transit de-archiving task, obtain the policy information of the policy to be de-archived and query whether the policy information exists in the business table.

[0058] In this embodiment, after confirming that there are no in-progress de-archiving tasks, the system retrieves the policy information for the policy to be de-archived. This policy information includes key data such as the policy number, insurance type, policyholder information, insured information, policy term, and insurance amount. The system then checks to see if this policy information already exists in the business table to avoid duplicate data import.

[0059] It should be emphasized that in order to further ensure the privacy and security of policy information, the above policy information can also be stored in a blockchain node.

[0060] The blockchain referred to in this application is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0061] In some optional implementations, the step of querying whether the policy information exists in the business table includes:

[0062] Construct database query conditions based on policy information, call the business table query interface, and obtain the business policy record set from the business table based on the database query conditions;

[0063] Using data validation rules, the policy information is compared field by field with the policy records in the policy record set;

[0064] If the fields are matched, it is determined that the policy information exists in the business table; otherwise, it is determined that the policy information does not exist in the business table.

[0065] Construct database query conditions based on policy information. These conditions can include exact match fields, fuzzy match fields, and more. Parameterized query statements can be used to combine multiple query conditions to generate a complete database query statement. Exact match fields include policy number and insurance type, while fuzzy match fields include policyholder name and policyholder ID number. For example, a query condition can be constructed based on three key fields: policy number, policyholder ID number, and insurance start date, to form a corresponding query statement.

[0066] Call the business table query API to retrieve a set of business policy records from the business table that meet the database query criteria. After obtaining the set of business policy records, apply data validation rules to compare the policy information to be de-archived with the policy records in the set field by field. The fields typically compared include key information such as the policy number, policyholder name, ID number, and policy term.

[0067] Among them, the data verification rules can adopt a multi-level verification mechanism, first comparing whether the policy number is completely matched, then comparing whether the insured's basic information (name, ID type, ID number) matches, and finally comparing whether the business data such as insurance liability and insurance amount matches.

[0068] Only when all key fields are matched, the policy information is determined to exist in the business table and no de-archiving operation is required; otherwise, the policy information is determined not to exist in the business table and the de-archiving process needs to be continued.

[0069] The data verification mechanism ensures the accuracy of the de-archiving operation and avoids business confusion and data redundancy caused by repeated data import.

[0070] Step S203: When the policy information is not in the business table, query whether the policy information exists in the archive library.

[0071] In this embodiment, when it is confirmed that the policy information does not exist in the business table, it is queried whether the policy information exists in the archive library.

[0072] Furthermore, a business comparison field is constructed based on the insurance policy information; the archived record of the archive library is obtained, and the business comparison field is compared with the corresponding field in the archived record using the preset mapping rule to obtain a preliminary matching result; the business field details of the preliminary matching result are obtained, and the business comparison field and the business field details are compared according to the preset threshold rules; if the field value of the business comparison field is consistent with the business field details, it is determined that the insurance policy information exists in the archive library; if the field value of the business comparison field is inconsistent with the business field details, it is marked as a record to be verified, and a set of records to be verified is obtained; the marked field in the set of records to be verified is checked again, and if it meets the preset matching conditions, it is determined that the insurance policy information exists in the archive library, otherwise, it is determined that the insurance policy information does not exist in the archive library.

[0073] First, business comparison fields are constructed based on the policy information. These fields typically contain key information that identifies the policy, such as the policy number, policyholder ID number, insurance product type, insurance product code, premium amount, and policy date. Next, the data matching interface is called to convert the constructed business comparison fields into structured query parameters, which are then sent to the archive repository for comparison with the archived records.

[0074] Preset mapping rules define the correspondence between policy table fields and archive database fields. Field mapping comparison yields preliminary matching results. For example, if the field is the policy number, "policy_no" in the policy table corresponds to "archive_policy_no" in the archive database; if the field is the policyholder ID number, "insured_id_no" in the policy table corresponds to "archive_insured_id" in the archive database.

[0075] Preset threshold rules define the degree of field matching, setting different matching criteria for different types of fields. For example, for text fields, a small number of character differences are allowed, which can be expressed as similarity. A similarity threshold is preset. When the similarity is greater than or equal to the similarity threshold, it means that the business comparison field and the business field details match, that is, the business comparison field and the business field details are consistent. Otherwise, the business comparison field and the business field details are inconsistent. For date fields, the date fields are uniformly converted to a standard format and matched using regular expressions. For string type fields (such as insurance policy numbers and ID numbers), an exact match is required. Different weights can be set for the consistency of different business comparison fields, and the final matching degree is obtained through weighted scoring. For example, matching degree = 0.5 × policy number consistency + 0.3 × insurance type consistency + 0.2 × insurance date consistency, where the policy number consistency score is 1.0, the date consistency score is 1.0, and the type consistency score is 1.0. The final matching degree = 0.5 × 1.0 + 0.3 × 1.0 + 0.2 × 1.0 = 1.0, reaching the full score and being judged as a perfect match.

[0076] If the value of the business comparison field completely matches the business field details, it indicates consistency, and the policy information is determined to exist in the archive, and subsequent unarchiving operations can be performed. If the value of the business comparison field does not completely match the business field details, it indicates inconsistency, and the business comparison field is marked as a pending verification record. All pending verification records are aggregated into a pending verification record set.

[0077] For the records in the set of records to be verified, the secondary verification mechanism will be automatically triggered, and the historical change record interface will be called to query whether there is a field update record for the insurance policy. If there is a field update record, the corresponding changed field value in the field update record will be obtained, and the deviation rate between the changed field value and the field value of the marked business comparison field will be calculated. If the deviation rate is lower than the fault tolerance threshold, it means that the preset matching conditions are met, and the field value of the business comparison field can still be determined to match the business field details; otherwise, it is determined that the field value of the business comparison field does not match the business field details, and the insurance policy information does not exist in the archive library, and the de-archiving process is terminated.

[0078] Through a multi-level and multi-dimensional data comparison mechanism, the accuracy and fault tolerance of policy information queries in the archive library are improved, providing a reliable data foundation for subsequent de-archiving operations.

[0079] Step S204: When the insurance policy information exists in the archive library, the de-archived insurance policy data of the de-archived task is obtained, and a query task is generated based on the de-archived insurance policy data.

[0080] Among them, the de-archived policy data includes all policy-related data that needs to be migrated from the archive library to the business library, which may involve records in multiple data tables.

[0081] Furthermore, the number of policy tables is determined based on the de-archived policy data, and the table field information and policy number of each policy table are extracted; a batch number generation mechanism is adopted to bind the pre-established task batch number with the policy number to obtain a unique query task identifier; and a query task for each policy table is generated based on the table field information and the query task identifier.

[0082] Insurance policy data is typically distributed across multiple related tables, such as the policy master table, policyholder table, insured table, and insurance liability table. These tables typically include six basic tables: the policy master table, policyholder table, insured table, insurance liability table, premium table, and claim record table. Additionally, specific tables may be added based on the insurance product type, such as the health disclosure table and physical examination information table. In this embodiment, the number and structure of tables to be processed are dynamically determined based on the insurance product type to which the policy belongs.

[0083] By extracting the table field information and policy number of each policy table, we prepare for subsequent data query and migration.

[0084] The task batch number usually contains a date and time stamp and a serial number to ensure the uniqueness of the task. In this embodiment, the task batch number and the policy number are combined, and a unique query task identifier is generated based on the combination. The query task identifier is used to track the execution status of each query task in the entire de-archiving process. Specifically, the batch number generation mechanism can adopt the format of "year, month, day, hour, minute, second + 4-digit random number" to ensure uniqueness in a high-concurrency environment. The task batch number and the policy number are bound through an association table to form a one-to-many relationship, that is, one batch can contain de-archiving tasks for multiple policies.

[0085] Query tasks can be generated using a templated design. Predefined query templates for various policy tables are available. Simply enter the policy number, table field information, and query task identifier into the template to generate a complete query task. Query tasks are encapsulated in JSON format and include the query statement, target table information, data conversion rules, and task control parameters. It should be noted that each policy table generates a separate query task.

[0086] Through the structured and templated task generation mechanism, the processing efficiency and scalability of the de-archiving task are improved, and it can adapt to the de-archiving needs of different types of insurance policies.

[0087] Step S205: Send the query task to the execution end through the message queue for processing, and record the execution result of the query task.

[0088] As the middle layer for task distribution, the message queue is equipped with persistence and message confirmation mechanisms. This allows for asynchronous task processing, load balancing, and retry upon failure, ensuring that messages are not lost due to system failures. The message queue is divided into multiple queues based on policy table type, such as the policy master table queue and the policyholder table queue, enabling categorized task processing.

[0089] Submit the query task to the message queue, which then distributes it to the corresponding execution end. Upon receiving the query task, the execution end generates an execution script for the query task, uses the generated execution script to execute the query task, extracts the corresponding de-archived policy data, and writes the de-archived policy data to the business table in the business database. A record update mechanism is then used to save task execution information, such as the task batch ID, task submission time, and task execution status, to the task tracking database for subsequent tracking and monitoring.

[0090] In some optional implementations, after the above step of sending the query task to the execution end through the message queue for processing, the following steps are further included:

[0091] Using a pre-established monitoring mechanism, the task batch identifier of the query task is extracted from the message queue;

[0092] According to the task batch identifier, the execution status of the corresponding query task is obtained by using a timed polling method;

[0093] The execution result of the query task is determined based on the execution status.

[0094] The monitoring mechanism can capture status changes of query tasks in real time, providing timely information on the progress and results of task execution. Specifically, the monitoring mechanism uses a message subscription model. The system launches a dedicated monitoring thread that subscribes to status change events in the message queue. When a message is successfully consumed or an exception occurs, the monitoring thread captures the corresponding event and updates the task status record.

[0095] Scheduled polling uses an increasing interval strategy, typically set to a few seconds to tens of seconds, adjusted based on business needs and system load. For example, the initial polling interval is 5 seconds. If the status remains unchanged after three consecutive polls, the polling interval is increased to 10 seconds, with a maximum polling interval of no more than 60 seconds. If a task remains uncompleted after exceeding the preset maximum number of polls (typically 72, meaning a maximum wait time of 1 hour), the system marks the task as timed out and triggers an alarm notification.

[0096] The task execution status may include "Queued," "Executing," "Completed," and "Failed." If the execution status is "Completed," the task successfully executed; if the execution status is "Failed," the reason for the task failure is recorded. The execution status is determined based on the status code and status description returned by the execution end. For example, status codes include 0 (success), 1 (partial success), and 2 (failure). In the case of partial success, the system records the success and failure details to provide a basis for subsequent data repair.

[0097] Through a reliable message queue and a complete task monitoring mechanism, the traceability and reliability of the anti-archiving task are ensured, and the system's fault tolerance and operation and maintenance efficiency are improved.

[0098] Step S206: Perform a consistency check on the execution result. If the consistency check passes, mark the de-archiving task as completed.

[0099] After obtaining the execution result, it is necessary to perform a consistency check on the execution result to ensure the integrity and accuracy of the data migration. Specifically, based on the execution result, the number of records of the de-archiving policy data returned by the query task is obtained; the actual number of de-archiving policy data written is extracted from the write records of the business database; the numerical values ​​of the number of records and the actual number of writes are compared to see if they are consistent. If the values ​​are consistent, it is determined that the consistency check has passed, and the step of marking the de-archiving task as completed is executed; if the values ​​are inconsistent, it is determined that the consistency check has failed, and the de-archiving task is marked as failed, and the retry process is triggered.

[0100] The record count refers to the number of de-archiving policy data records that meet the criteria in the query task's execution results, as verified by a count function. The number of de-archiving policy data records actually written to the business table is also extracted from the business database's write records. Write records are typically recorded by database triggers or application logs and contain detailed information about each data write operation.

[0101] The number of records and the number of writes are compared for consistency. This comparison uses both table-by-table statistics and aggregate comparisons. The number of records and writes for each policy table are counted separately, followed by a table-level comparison. Finally, the comparison results for all tables are summarized. If the two values ​​are identical, all policy data in the de-archiving task has been successfully written to the business table. The consistency check is considered passed, and the de-archiving task is marked as completed. If the number of records and the number of writes are inconsistent, indicating possible data loss or write failure during the data migration process, the consistency check is considered failed, the de-archiving task is marked as failed, and a retry mechanism is triggered.

[0102] Specifically, after the retry mechanism is triggered, the preset number of retries is retrieved to determine whether the retry limit has been reached. If not, a retry task instruction is generated. Using this retry task instruction, the unarchiving operation is reinitiated and verified again. If it still fails, the retry counter is incremented and the current number of retries is recorded in a database table, with a timestamp updated. This operation is ensured through a database transaction to ensure consistency. If all retries fail after reaching the preset number of retries, the task status is marked as "failed," the database table is updated, and the reason for failure is recorded. Next, the retry failure rate is analyzed. Assuming a total of 50 tasks, 5 failed tasks, and a failure rate of 10%, if the failure rate exceeds 5%, an alert is sent via a message queue in JSON format to the monitoring module. The task batch identifier, failure time, failure reason, and number of retries for the failed task are also recorded. This process forms a tight logical chain from verification failure to retry, status update, failure analysis, and recording, ensuring traceability of task exception handling.

[0103] If the consistency check fails, different retry strategies can be adopted based on the severity and type of inconsistency. If the inconsistency is minor (for example, only a few records are inconsistent), the system will retry only the inconsistent part; if the inconsistency is severe, the system will clean up the written data and re-execute the entire de-archiving task.

[0104] In some optional implementations, consistency checks employ a multi-dimensional mechanism that not only compares the number of records but also the consistency of key fields. The checksum of the de-archived policy data is extracted from the execution results, and the checksum of the data written to the business table is also calculated. Both must be identical for the check to pass.

[0105] By performing consistency checks on execution results and implementing a flexible retry mechanism, the integrity and accuracy of de-archiving data are ensured, improving the data quality and reliability of the system.

[0106] This application uses an intelligent interactive anti-archiving mechanism to automatically complete the policy data recovery process, greatly improves the anti-archiving efficiency, reduces manual intervention, and solves the problem of time-consuming and inefficient recovery process in traditional methods; through a systematic data verification and consistency check mechanism, it ensures the accuracy and integrity of the data and avoids data errors caused by manual operations; the use of message queues and automated processing processes reduces the number of links where manual contact with data occurs and reduces the security risks of data leakage; the automated task management and processing mechanism significantly reduces data maintenance costs and improves system operation efficiency; the system can quickly respond to policy recovery needs, improve business processing capabilities, and enable policy data to be directly queried and used in the business system.

[0107] The embodiments of the present application can acquire and process relevant data based on artificial intelligence technology. Artificial Intelligence (AI) is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to achieve optimal results.

[0108] Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interaction systems, and mechatronics. AI software technologies primarily encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0109] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware via computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0110] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0111] Further references Figure 3 , as a response to the above Figure 2 In order to realize the method shown in the figure, the present application provides an embodiment of a policy reverse archiving device. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0112] like Figure 3 As shown, the insurance policy reverse archiving device 300 of this embodiment includes: a task query module 301, a business table query module 302, an archive library query module 303, a task generation module 304, a task issuing module 305 and a verification module 306. Among them:

[0113] The task query module 301 is used to obtain a de-archiving task, initiate an in-transit task query request based on the de-archiving task, and query whether there is a de-archiving task in-transit according to the in-transit task query request;

[0114] The business table query module 302 is used to obtain the policy information of the policy to be de-archived when there is no de-archiving task in progress, and query whether the policy information exists in the business table;

[0115] The archive library query module 303 is used to query whether the insurance policy information exists in the archive library when the insurance policy information is not in the business table;

[0116] The task generating module 304 is used for obtaining the de-archiving policy data of the de-archiving task when the policy information exists in the archiving library, and generating a query task based on the de-archiving policy data;

[0117] The task sending module 305 is used to send the query task to the execution end through the message queue for processing, and record the execution result of the query task;

[0118] The verification module 306 is used to perform a consistency check on the execution result, and when the consistency check passes, mark the de-archiving task as completed.

[0119] It should be emphasized that in order to further ensure the privacy and security of policy information, the above policy information can also be stored in a blockchain node.

[0120] Based on the above-mentioned insurance policy anti-archiving device 300, through the intelligent interactive anti-archiving mechanism, the insurance policy data recovery process can be automatically completed, which greatly improves the anti-archiving efficiency, reduces manual intervention, and solves the problem of long recovery time and low efficiency of the traditional recovery process; through the systematic data verification and consistency check mechanism, the accuracy and integrity of the data are ensured, and data errors caused by manual operation are avoided; the use of message queues and automated processing procedures reduces the links of manual contact with data and reduces the security risks of data leakage; the automated task management and processing mechanism significantly reduces data maintenance costs and improves system operation efficiency; the system can quickly respond to insurance policy recovery needs, improve business processing capabilities, and enable insurance policy data to be directly queried and used in the business system.

[0121] In some optional implementations, the task query module 301 is further configured to:

[0122] Extracting a de-archiving task identifier from the in-transit task query request, and acquiring status data based on the de-archiving task identifier;

[0123] Processing the status data using preset parsing rules to obtain task status and timestamp;

[0124] If the task status is displayed as being processed, a comparison result is obtained by comparing the difference between the timestamp and the current time with a preset threshold condition;

[0125] Determine whether the de-archiving task is an in-transit task according to the comparison result;

[0126] When the anti-archiving task is an in-transit task, it is determined that there is an in-transit anti-archiving task currently; otherwise, it is determined that there is no in-transit anti-archiving task currently.

[0127] By checking whether there is an in-progress de-archiving task, repeated de-archiving operations for the same policy can be avoided, data conflicts and resource waste can be prevented, and system stability and data consistency can be improved.

[0128] In some optional implementations, the business table query module 302 includes:

[0129] A query submodule is used to construct a database query condition based on the policy information, call the business table query interface, and obtain a set of business policy records from the business table based on the database query condition;

[0130] A data verification submodule, configured to compare the policy information with the policy records in the policy record set field by field using data verification rules;

[0131] The business table determination submodule is used to determine that the policy information exists in the business table if the field comparison is consistent, otherwise, determine that the policy information does not exist in the business table.

[0132] The data verification mechanism ensures the accuracy of the de-archiving operation and avoids business confusion and data redundancy caused by repeated data import.

[0133] In some optional implementations, the archive library query module 303 includes:

[0134] A construction submodule, configured to construct a business comparison field based on the policy information;

[0135] A mapping submodule is used to obtain archive records from the archive library, and compare the business comparison field with the corresponding field in the archive record using a preset mapping rule to obtain a preliminary matching result;

[0136] A threshold comparison submodule, configured to obtain the business field details of the preliminary matching result, and compare the business comparison field with the business field details according to a preset threshold rule;

[0137] A business determination submodule, configured to determine whether the policy information exists in the archive library if the field value of the business comparison field is consistent with the business field details;

[0138] a marking submodule, configured to mark a record as to be verified if the field value of the business comparison field is inconsistent with the business field details, thereby obtaining a set of records to be verified;

[0139] The secondary verification submodule is used to perform a secondary verification on the mark field in the record set to be verified. If the preset matching conditions are met, it is determined that the insurance policy information exists in the archive library; otherwise, it is determined that the insurance policy information does not exist in the archive library.

[0140] Through a multi-level and multi-dimensional data comparison mechanism, the accuracy and fault tolerance of policy information queries in the archive library are improved, providing a reliable data foundation for subsequent de-archiving operations.

[0141] In some optional implementations, the task generation module 304 is further configured to:

[0142] Determine the number of policy tables based on the de-archived policy data, and extract table field information and policy number of each policy table;

[0143] Adopting a batch number generation mechanism, the pre-established task batch number is bound to the policy number to obtain a unique query task identifier;

[0144] Generate a query task for each insurance policy table according to the table field information and the query task identifier.

[0145] Through the structured and templated task generation mechanism, the processing efficiency and scalability of the de-archiving task are improved, and it can adapt to the de-archiving needs of different types of insurance policies.

[0146] In some optional implementations, the policy reverse archiving device 300 further includes a monitoring module configured to:

[0147] Using a pre-established monitoring mechanism, extracting the query task identifier of the query task from the message queue;

[0148] According to the query task identifier, the execution status of the corresponding query task is obtained by using a timed polling method;

[0149] An execution result of the query task is determined according to the execution status.

[0150] Through a reliable message queue and a complete task monitoring mechanism, the traceability and reliability of the anti-archiving task are ensured, and the system's fault tolerance and operation and maintenance efficiency are improved.

[0151] In some optional implementations, the verification module 306 is further configured to:

[0152] Obtaining the number of records of the de-archived insurance policy data returned by the query task according to the execution result;

[0153] Extracting the actual number of entries of the de-archiving policy data actually written from the write records of the business database;

[0154] Comparing the number of records with the number of records actually written to see if they are consistent, and if so, determining that the consistency check has passed, and executing the step of marking the de-archiving task as completed;

[0155] If the values ​​are inconsistent, it is determined that the consistency check fails, and the de-archiving task is marked as a failure state and a retry process is triggered.

[0156] By performing consistency checks on execution results and implementing a flexible retry mechanism, the integrity and accuracy of de-archiving data are ensured, improving the data quality and reliability of the system.

[0157] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0158] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected through a system bus. It should be noted that the figure only shows a computer device 4 with a memory 41, a processor 42, and a network interface 43, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.

[0159] The computer device may be a desktop computer, notebook computer, PDA, cloud server, etc. The computer device may interact with the user via a keyboard, mouse, remote control, touchpad, or voice control device.

[0160] The memory 41 includes at least one type of readable storage medium, including flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, a magnetic disk, an optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash memory card, etc. equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit of the computer device 4 and its external storage device. In this embodiment, the memory 41 is generally used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for the insurance policy reverse archiving method. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or are to be output.

[0161] In some embodiments, the processor 42 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is generally used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or process data, such as computer-readable instructions for executing the policy de-archiving method.

[0162] The network interface 43 may include a wireless network interface or a wired network interface. The network interface 43 is generally used to establish a communication connection between the computer device 4 and other electronic devices.

[0163] Through the intelligent interactive anti-archiving mechanism, the policy data recovery process can be completed automatically, which greatly improves the anti-archiving efficiency, reduces manual intervention, and solves the problem of time-consuming and inefficient recovery process in traditional methods; through the systematic data verification and consistency check mechanism, the accuracy and integrity of the data are ensured, and data errors caused by manual operations are avoided; the use of message queues and automated processing processes reduces the links of manual contact with data and reduces the security risks of data leakage.

[0164] The present application also provides another embodiment, namely, providing a computer-readable storage medium, which stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to enable the at least one processor to perform the steps of the above-mentioned insurance policy reverse archiving method.

[0165] Through the intelligent interactive anti-archiving mechanism, the policy data recovery process can be completed automatically, which greatly improves the anti-archiving efficiency, reduces manual intervention, and solves the problem of time-consuming and inefficient recovery process in traditional methods; through the systematic data verification and consistency check mechanism, the accuracy and integrity of the data are ensured, and data errors caused by manual operations are avoided; the use of message queues and automated processing processes reduces the links of manual contact with data and reduces the security risks of data leakage.

[0166] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0167] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of patent protection of the present application.

[0168] The non-Company software tools or components appearing in the embodiments of this application are merely examples and do not represent actual use.

Claims

1. A method for reverse archiving an insurance policy, characterized in that: The steps include: Obtaining a de-archiving task, initiating an in-transit task query request based on the de-archiving task, and querying whether there is currently an in-transit de-archiving task according to the in-transit task query request; When there is no in-transit de-archiving task, obtaining the policy information of the policy to be de-archived, and querying whether the policy information exists in the business table; If the policy information is not in the business table, query whether the policy information exists in the archive library; When the insurance policy information exists in the archive library, obtaining the de-archived insurance policy data of the de-archived task, and generating a query task based on the de-archived insurance policy data; Send the query task to the execution end through the message queue for processing, and record the execution result of the query task; A consistency check is performed on the execution result, and when the consistency check passes, the de-archiving task is marked as completed.

2. The insurance policy reverse archiving method according to claim 1, characterized in that: The step of querying whether there is an in-transit anti-archiving task currently according to the in-transit task query request includes: Extracting a de-archiving task identifier from the in-transit task query request, and acquiring status data based on the de-archiving task identifier; Processing the status data using preset parsing rules to obtain task status and timestamp; If the task status is displayed as being processed, a comparison result is obtained by comparing the difference between the timestamp and the current time with a preset threshold condition; Determine whether the de-archiving task is an in-transit task according to the comparison result; When the anti-archiving task is an in-transit task, it is determined that there is an in-transit anti-archiving task currently; otherwise, it is determined that there is no in-transit anti-archiving task currently.

3. The insurance policy reverse archiving method according to claim 1, characterized in that: The step of querying whether the policy information exists in the business table includes: Constructing a database query condition based on the policy information, calling a business table query interface, and obtaining a set of business policy records from the business table based on the database query condition; Using data verification rules, the policy information is compared field by field with the policy records in the policy record set; If the fields are compared and consistent, it is determined that the policy information exists in the business table; otherwise, it is determined that the policy information does not exist in the business table.

4. The insurance policy reverse archiving method according to claim 1, characterized in that: The step of querying whether the insurance policy information exists in the archive library includes: Constructing a business comparison field based on the policy information; Obtaining archive records from the archive library, and using preset mapping rules to compare the business comparison field with the corresponding field in the archive record to obtain a preliminary matching result; Obtaining the business field details of the preliminary matching result, and comparing the business comparison field with the business field details according to a preset threshold rule; If the field value of the business comparison field is consistent with the business field details, it is determined that the insurance policy information exists in the archive library; If the field value of the business comparison field is inconsistent with the business field details, it is marked as a record to be verified, and a set of records to be verified is obtained; A secondary check is performed on the mark field in the record set to be verified. If the preset matching condition is met, it is determined that the insurance policy information exists in the archive library. Otherwise, it is determined that the insurance policy information does not exist in the archive library.

5. The insurance policy reverse archiving method according to claim 1, characterized in that: The step of generating a query task based on the de-archived insurance policy data includes: Determine the number of policy tables based on the de-archived policy data, and extract table field information and policy number of each policy table; Adopting a batch number generation mechanism, the pre-established task batch number is bound to the policy number to obtain a unique query task identifier; Generate a query task for each insurance policy table according to the table field information and the query task identifier.

6. The insurance policy reverse archiving method according to claim 1, characterized in that: After the step of sending the query task to the execution end for processing through the message queue, the method further includes: Using a pre-established monitoring mechanism, extracting the query task identifier of the query task from the message queue; According to the query task identifier, the execution status of the corresponding query task is obtained by using a timed polling method; An execution result of the query task is determined according to the execution status.

7. The insurance policy reverse archiving method according to claim 1, characterized in that: The step of performing consistency check on the execution result includes: Obtaining the number of records of the de-archived insurance policy data returned by the query task according to the execution result; Extracting the actual number of entries of the de-archiving policy data actually written from the write records of the business database; Comparing the number of records with the number of records actually written to see if they are consistent, and if so, determining that the consistency check has passed, and executing the step of marking the de-archiving task as completed; If the values ​​are inconsistent, it is determined that the consistency check fails, and the de-archiving task is marked as a failure state and a retry process is triggered.

8. A policy reverse archiving device, characterized in that: include: A task query module is used to obtain a de-archiving task, initiate an in-transit task query request based on the de-archiving task, and query whether there is currently an in-transit de-archiving task according to the in-transit task query request; A business table query module is used to obtain the policy information of the policy to be de-archived when there is no de-archiving task in progress, and to query whether the policy information exists in the business table; An archive library query module, used for querying whether the policy information exists in the archive library when the policy information is not in the business table; a task generating module, configured to obtain the de-archived policy data of the de-archived task when the policy information exists in the archive library, and generate a query task based on the de-archived policy data; The task sending module is used to send the query task to the execution end through the message queue for processing and record the execution result of the query task; The verification module is used to perform consistency verification on the execution result, and when the consistency verification passes, mark the de-archiving task as completed.

9. A computer device, characterized in that: The invention comprises a memory and a processor, wherein the memory stores computer-readable instructions, and when the processor executes the computer-readable instructions, the steps of the insurance policy reverse archiving method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the insurance policy reverse archiving method according to any one of claims 1 to 7.

Images