A method, apparatus and equipment for reporting credit information
By parsing the business database logical logs and performing scenario judgments in the credit reporting preprocessing module, the decoupling of the business system and credit reporting is achieved. This solves the problem of the impact of credit reporting on the business system in existing technologies, improves data timeliness and upgrade efficiency, and reduces repetitive work and system burden.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-06
- Publication Date
- 2026-03-10
AI Technical Summary
The existing credit reporting scheme is tightly bound to business processes, resulting in high pressure on business systems, low efficiency, and cumbersome work. Furthermore, the high coupling between the credit reporting service and business systems affects the response speed and deployment efficiency of the business systems.
By parsing the logical logs of the business database, the data is synchronized to the message middleware, and scenario judgment and data storage are performed in the credit reporting preprocessing module. Finally, the credit reporting is completed through the credit reporting module, thus decoupling the business system from the credit reporting.
It enables zero-awareness credit reporting for business systems, improves data timeliness and upgrade and deployment efficiency, reduces repetitive work, lowers the burden on business systems, and facilitates location and troubleshooting when problems occur.
Smart Images

Figure CN116823436B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of business data reporting, and in particular to a credit investigation data reporting method, device and equipment. BACKGROUND
[0002] A business system refers to a system that provides services for each business line within an organization, such as the underwriting, claims handling, and fee collection systems in the insurance industry, and is the first system in which business data appears within an organization.
[0003] Credit investigation reporting mainly involves collecting and processing financial-related business information (including customer personal basic information, credit transaction information, and guarantee information) within an organization into a message required by a bank, and reporting to a credit investigation center. That is, the information displayed on the credit investigation report is reported by each access agency, and the bank credit investigation center is only responsible for summarizing and arranging the relevant information to be displayed on each person's credit investigation report. Credit investigation reporting within an organization often involves multiple data sources of multiple business systems (such as the underwriting system and the claims handling system in the insurance industry).
[0004] The business systems within an organization (hereinafter exemplified by the insurance industry) are often complex, and the data of each link of credit investigation reporting is scattered in multiple data sources of multiple business systems within an organization. The corresponding logical topology diagram is as shown in Figure 1 As can be seen from Figure 1 , the data required for credit investigation reporting within an organization comes from multiple business systems (underwriting, claims handling, etc.), and the trigger point of credit investigation reporting (when to trigger the credit investigation reporting action, such as approval of underwriting, approval of claims handling, etc.) and the business process have a strong binding relationship.
[0005] Since the trigger point of credit investigation reporting is strongly bound to the business process, the existing general solution is to embed the reporting action into the business process, and the reporting element data query involved in the reporting is also based on the business database, which will bring double pressure to the application and database of the business line, slow down the response speed of the core system to the business request, and in severe cases, will cause the core service to be unavailable, business interruption, etc.
[0006] The advantages and disadvantages of the credit reporting scheme are mainly based on whether the scheme can complete the credit reporting action timely, accurately and comprehensively under the premise of zero awareness of the business system. The conventional credit reporting scheme has the following disadvantages: 1. Strong binding with the business process, sharing the business core application host service, which will cause mutual influence between the reporting service and the business core service; 2. Strong binding with the business process, involving mutual influence during upgrade and deployment, such as waiting for the business process requirements to be online on the same version when the credit reporting related changes; 3. Strong binding with the business process, the business system is deployed in different provinces due to the large differences in business processes between provinces, which will slow down the deployment of credit reporting requirements changes in the whole country; 4. Because the credit trigger point and the credit reporting elements are scattered in various business systems, the same verification rules need to be implemented multiple times in multiple business systems, which exists the phenomenon of repeated wheel building; 5. From the business side, credit reporting should be independent of the business system and is not a necessary action of the business, and the business system does not need to care about the credit reporting related rules and reporting elements. SUMMARY
[0007] The application provides a credit data reporting method, device and equipment, which solves the problems of high pressure, low efficiency, tedious work and high coupling degree of credit reporting service and business system caused by credit reporting.
[0008] A credit data reporting method, comprising:
[0009] Persisting the business data of the business system into the business database and forming the corresponding logical log;
[0010] Analyzing the logical log and transmitting the analysis result to the first message middleware;
[0011] Consuming the message in the first message middleware through the credit preprocessing module, storing the record corresponding to the message into the credit reporting database, and performing reporting scene judgment;
[0012] When the reporting scene is determined and it is determined that the reporting condition is met under the reporting scene, transmitting the credit reporting scene feature data to the second message middleware;
[0013] Consuming the message in the second message middleware through the credit reporting module, querying and acquiring the data in the credit reporting database according to the consumption result for reporting processing, so as to complete the credit reporting.
[0014] In one embodiment of the present invention, storing the record corresponding to the message in the credit reporting database and determining the credit reporting scenario specifically includes: when the credit preprocessing module consumes the message in the policy application subject of the first message middleware, converting the message into a corresponding record and storing it in the policy application main table of the credit reporting database; if the credit preprocessing module determines that there is a policy number in the consumed message, then according to the policy number included in the message, querying whether the record related to the policy number in the credit reporting database exists in the policy application related person table and the policy application related person table sub-table; each policy application number corresponds to one policy application; when it is determined that the record related to the policy number has been stored in the credit reporting database, determining that the business actions and element records required in the current reporting scenario meet the reporting conditions.
[0015] In one embodiment of the present invention, storing the record corresponding to the message in the credit reporting database and performing credit reporting scenario determination specifically includes: when the credit preprocessing module consumes a message in the policyholder relationship topic of the first message middleware, converting the message into a corresponding record and storing it in the policyholder relationship table of the credit reporting database; when it is determined that the message does not include a policy number field, querying the policyholder main table in the credit reporting database according to the policy number included in the record; if a record related to the policy number is found in the policyholder main table, determining whether the policy number of the corresponding record in the policyholder main table has a value; if the policy number has a value, querying whether the record related to the policy number has been stored in the policyholder relationship table sub-table; if it has been stored, determining that the business actions and element records required in the current reporting scenario meet the reporting conditions; if the policy number has no value, continuing to consume the next message.
[0016] In one embodiment of the present invention, storing the record corresponding to the message in the credit reporting database and performing credit reporting scenario determination specifically includes: when the credit preprocessing module consumes a message in the policyholder relationship subtopic of the first message middleware, converting the message into a corresponding record and storing it in the policyholder relationship table sub-table of the credit reporting database; when it is determined that the message does not include a policy number field, querying the policyholder main table in the credit reporting database according to the policy number included in the record; if a record related to the policy number is found in the policyholder main table, determining whether the policy number of the corresponding record in the policyholder main table has a value; if the policy number has a value, querying whether the record related to the policy number has been stored in the policyholder relationship table; if it has been stored, determining that the business actions and element records required in the current reporting scenario meet the reporting conditions; if the policy number has no value, continuing to consume the next message.
[0017] In one embodiment of the present invention, when determining the reporting scenario and determining that the reporting conditions are met in the reporting scenario, the credit reporting scenario feature data is transmitted to the second message middleware. Specifically, this includes: when it is determined that the reporting conditions are met in a specific reporting scenario, generating a credit reporting feature message corresponding to the specific reporting scenario through the credit preprocessing module; and transmitting the credit reporting feature message to the second message middleware.
[0018] In one embodiment of the present invention, the step of consuming messages in the second message middleware through the credit reporting module, querying and obtaining data from the credit reporting database based on the consumption results, and performing reporting processing to complete the credit reporting specifically includes: consuming messages in the credit feature topic of the second message middleware through the credit reporting module, determining the reporting scenario and business primary key corresponding to the message; querying the business elements required for reporting in the credit reporting database based on the reporting scenario and business primary key; generating corresponding text files from the business elements, encrypting the text files, and submitting the encrypted text files for credit reporting on the browser side.
[0019] In one embodiment of the present invention, the credit reporting database and the business database are isomorphic subsets, and only the data tables involved in credit reporting are stored.
[0020] A credit data reporting device, comprising:
[0021] The business database is used to persist business data from the business system to the business database and generate corresponding logical logs.
[0022] The first transmission module is used to parse the logical log and transmit the parsing result to the first message middleware;
[0023] The credit reporting preprocessing module is used to consume messages in the first message middleware, store the records corresponding to the messages in the credit reporting database, and determine the reporting scenario.
[0024] The second transmission module is used to determine the reporting scenario and, when it is determined that the reporting conditions are met under the reporting scenario, transmit the credit reporting scenario feature data to the second message middleware.
[0025] The credit reporting module is used to consume messages from the second message middleware, query and obtain data from the credit reporting database based on the consumption results, and perform reporting processing to complete the credit reporting.
[0026] A credit data reporting device, comprising:
[0027] At least one processor; and,
[0028] The memory is communicatively connected to the at least one processor via a bus; wherein,
[0029] The memory stores instructions that can be executed by the at least one processor to implement the method described in any of the above embodiments.
[0030] A non-volatile storage medium storing computer-executable instructions, which are executed by a processor to implement the method described in any of the above embodiments.
[0031] This invention provides a method, apparatus, and device for reporting credit information, which has at least the following beneficial effects:
[0032] 1. Decoupling of business systems
[0033] Because the data is synchronized by parsing logical logs, the data synchronization action and all downstream credit reporting logic processing are unaffected by the core business system and will not affect the business system. Conventional implementation solutions often embed the credit reporting logic into multiple business systems, which will cause unnecessary burden on the business system (credit reporting is not a necessary part of the business).
[0034] 2. High data timeliness
[0035] After changes occur in the business database, the data can be synchronized to the message middleware within seconds, which is more timely than the conventional T+1 reporting (reporting is done on the 1st of the transaction day).
[0036] 3. Centralized credit reporting logic
[0037] All logic processing related to credit reporting is completed in the credit reporting preprocessing module. Compared with the conventional approach of implementing the reporting logic within multiple business systems (which requires multiple systems to be upgraded simultaneously), this approach has higher upgrade and deployment efficiency, faster response speed to requirement changes, and accelerates the overall iteration speed.
[0038] 4. Original data holding
[0039] The original business database data was synchronized through logical log parsing, and the original business data was stored in the credit reporting database, which facilitates the troubleshooting and location of problems when disputes arise.
[0040] 5. Minimize the reporting workflow.
[0041] The additional work generated by credit reporting does not require the business system to be included in the upstream and downstream chains, thus reducing the workload of IT professionals such as business system developers and testers.
[0042] 6. Reduce repetitive work
[0043] Credit reporting requires verification of data elements. Compared to the reporting schemes of various systems, which require the same verification rules to be implemented repeatedly in each system, this scheme only needs to be implemented once during credit preprocessing, reducing the need to reinvent the wheel. Attached Figure Description
[0044] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:
[0045] Figure 1 A logical topology diagram for business data transmission provided in this embodiment of the invention;
[0046] Figure 2 This is a schematic diagram illustrating the steps of a credit data reporting method provided in an embodiment of the present invention;
[0047] Figure 3 This is a schematic diagram of a credit data reporting process provided in an embodiment of the present invention;
[0048] Figure 4 A schematic diagram of a credit data reporting device provided in an embodiment of the present invention;
[0049] Figure 5 This is a schematic diagram of a credit data reporting device provided in an embodiment of the present invention. Detailed Implementation
[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described clearly and completely below in conjunction with specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0051] It should be noted that those skilled in the art will understand, explicitly and implicitly, that the embodiments described in this invention can be combined with other embodiments without conflict. Unless otherwise defined, the technical or scientific terms used in this invention should be understood in their ordinary sense by those skilled in the art. The terms "a," "an," "an," "the," etc., used in this invention do not indicate quantity limitation and can represent singular or plural. The terms "comprising," "including," "having," and any variations thereof used in this invention are intended to cover non-exclusive inclusion; the terms "first," "second," "third," etc., used in this invention are merely to distinguish similar objects and do not represent a specific ordering of objects.
[0052] The following describes the terminology used in the embodiments of this disclosure:
[0053] Terminology Explanation (Explaining terms that are deemed necessary to be listed):
[0054] A business database refers to a collection of services that provide data persistence for business systems. Business data often originates in a business database, and common business databases are relational databases that support transactions, such as MySQL and Oracle.
[0055] A relational database is a database that uses a relational model to organize data. It stores data in rows and columns for ease of understanding by users. These rows and columns are called tables, and a set of tables makes up the database. Users retrieve data from the database through queries, which are executable codes used to limit access to specific areas within the database. The relational model can be simply understood as a two-dimensional table model, and a relational database is a data organization composed of two-dimensional tables and the relationships between them.
[0056] Logical logs are logs that record database modification operations. These operations are often simple variations of user input, without detailed parsing, and are unrelated to the underlying data organization of the database. They are only related to the logical view style provided by the database. By parsing these logs, the corresponding insert, delete, and modify operations can be "reconstructed".
[0057] Message middleware is a supporting software system that provides synchronous or asynchronous reliable message transmission for application systems in a network environment based on queue and message passing technology. It has many advantages such as improving performance through asynchronization, reducing coupling, and traffic shaping, and is widely used in information systems.
[0058] Producer: The producer is responsible for creating messages and then delivering them to the message middleware.
[0059] Consumer: This is the party that receives the message. The consumer connects to the message middleware, receives the message, and then performs the corresponding business logic processing.
[0060] Topics: Messages in a message middleware are categorized by topics. Producers are responsible for sending messages to specific topics, while consumers are responsible for subscribing to topics and consuming them.
[0061] The core of this invention is to achieve zero-awareness credit reporting for related business systems based on business database logical log parsing and message middleware, thereby achieving timely, accurate, and comprehensive credit reporting while decoupling credit reporting from business systems. This will be explained in detail below.
[0062] Figure 2A schematic diagram illustrating the steps of a credit data reporting method provided in this embodiment of the invention may include the following steps:
[0063] S210: Persist the business data of the business system to the business database and generate corresponding logical logs.
[0064] Specifically, such as Figure 3 As shown, core business systems (such as underwriting core applications and claims core applications) persist business data to the business database. During the persistence process, the database will be modified by adding, deleting, modifying and querying operations. Only the addition, deletion and modification operations involving data changes will be recorded in the logic log.
[0065] S220: Parse the logical log and transmit the parsing result to the first message middleware.
[0066] Specifically, after business data is persisted to the business database, the database service will generate corresponding logical logs. By parsing the logical logs, the corresponding modification (add, delete, update) operations in the business database are translated into the corresponding JSON format and produced to the message middleware. The topic names in the message middleware should be consistent with the business database name and the business database table name to ensure that the names are self-explanatory.
[0067] For example, in the scenario where basic information is submitted upon underwriting approval (this scenario will be used as an example below), the underwriting database is named prpc and the database tables are named prpcmain (main table of the application), prpcinsured (table of the applicant), and prpcinsurednature (sub-table of the applicant). In this case, the recommended topic names in the message middleware are prpc.prpcmain, prpc.prpcinsured, and prpc.prpcinsurednature.
[0068] S230: The credit reporting preprocessing module consumes messages from the first message middleware, stores the corresponding records to the credit reporting database, and performs reporting scenario judgment.
[0069] In one embodiment of the present invention, the credit reporting database and the business database are isomorphic subsets, storing only the data tables related to credit reporting. This decouples the credit reporting and business systems, reducing the dual pressure from business applications and the database, and improving the response speed of business requests. Dedicated databases for specific purposes improve read / write performance, reduce latency, save costs, and achieve efficient management.
[0070] In one embodiment of the present invention, the record corresponding to the message is stored in the credit reporting database, and a credit reporting scenario determination is performed. Specifically, this includes: when the credit preprocessing module consumes the message in the policy application subject of the first message middleware, the message is converted into a corresponding record and stored in the policy application main table of the credit reporting database; if the credit preprocessing module determines that there is a policy number in the consumed message, it queries whether the record related to the policy application number in the credit reporting database exists in the policy application related person table and the policy application related person table sub-table according to the policy application number included in the message; each policy application number corresponds to one policy application; when it is determined that the record related to the policy application number has been stored in the credit reporting database, it is determined that the business actions and element records required in the current reporting scenario meet the reporting conditions.
[0071] Specifically, the credit reporting preprocessing module consumes messages from the message middleware topic and stores the corresponding messages in the credit reporting database (the credit reporting database and the business database are isomorphic subsets, storing only the tables involved in credit reporting). Simultaneously, it performs credit reporting scenario judgment. For example, when consuming a message from the prpc.prpcmain topic, the structure is as follows:
[0072]
[0073] The above message indicates that a record has been inserted into the `prpcmain` table of the business database `cq5000prp3gdb`. The application number `proposalno` is `VExEVjIwMjM1MDAxTUEwMDAwNTc2Ng==`, and the policy number `policyno` is `UExEVjIwMjM1MDAxTUEwMDAwNTM2Ng==`. The credit reporting preprocessing module stores the message in the `prpcmain` table of the credit reporting database. Since the message contains the policy number `policyno`, it indicates that this application has been underwritten (underwriting approved, policy number generated). When submitting basic information after underwriting approval, it is necessary to simultaneously submit the element information from the `prpc.prpcinsured` and `prpc.prpcinsurednature` tables. Therefore, at this time, it is necessary to utilize... Using the insurance policy number of the message, a reverse lookup is performed in the insurance policy related person table and its sub-tables in the credit reporting database to confirm whether the credit preprocessing module has consumed the prpc.prpcinsured and prpc.prpcinsurednature subject records corresponding to the insurance policy and stored them in the credit reporting database. If they are consumed, it indicates that the business actions and elements (prpc.prpcmain, prpc.prpcinsured, prpc.prpcinsurednature) required for the underwriting approval reporting basic information scenario are all available. If the credit reporting database lacks the prpc.prpcinsured or prpc.prpcinsurednature information for the corresponding insurance policy, the next message is consumed.
[0074] In one embodiment of the present invention, the record corresponding to the message is stored in the credit reporting database, and a credit reporting scenario determination is performed. Specifically, this includes: when the credit preprocessing module consumes a message in the policyholder relationship topic of the first message middleware, the message is converted into a corresponding record and stored in the policyholder relationship table of the credit reporting database; when it is determined that the message does not include the policy number field, the policyholder main table in the credit reporting database is queried according to the policy number included in the record; if a record related to the policy number is found in the policyholder main table, it is determined whether the policy number of the corresponding record in the policyholder main table has a value; if the policy number has a value, it is queried whether the record related to the policy number has been stored in the policyholder relationship table sub-table; if it has been stored, it is determined that the business actions and element records required in the current reporting scenario meet the reporting conditions; if the policy number has no value, the consumption of the next message continues.
[0075] Specifically, when consuming a message from the prpc.prpcinsured topic, the structure is as follows:
[0076]
[0077]
[0078] The above message indicates that a record has been inserted into the prpcinsured table of the business database cq5000prp3gdb. The policy number proposalno is VExEVjIwMjM1MDAxTUEwMDAwNTc2Ng==, the ID number identifynumber is MTEwMTAxMTk5MDAzMDc2ODUx, and the insured name insuredname is 5byg5LiJ. The credit reporting preprocessing module stores the message in the prpcinsured table of the credit reporting database. Since the message does not contain the policy number policyno field, it needs to use the policy number proposalno of this record to look up the prpcmain table of the credit reporting database. If no relevant record is found in the prpcmain table according to the corresponding policy number proposalno, it means that the credit reporting preprocessing module has not yet consumed the record corresponding to the policy number in the topic prpc.prpcmain, and then continues to consume the next message.
[0079] If a record for the corresponding policy number proposalno is found in the prpcmain table of the credit reporting database, then it is determined whether the policy number policyno of the corresponding record in the prpcmain table has a value. If it does, the database is then checked against the prpcinsurednature table, which is another table required for reporting, to see if a record exists. If a record exists, it means that the business actions and elements required for the current reporting scenario meet the reporting conditions. If the policy number policyno of the corresponding record has no value, it means that no record of underwriting approval for that policy number proposalno has been found in the current records of the prpc.prpcmain topic.
[0080] In one embodiment of the present invention, the record corresponding to the message is stored in the credit reporting database, and a credit reporting scenario determination is performed. Specifically, this includes: when the credit preprocessing module consumes a message from the policyholder relationship subtopic of the first message middleware, the message is converted into a corresponding record and stored in the policyholder relationship sub-table of the credit reporting database; when it is determined that the message does not include the policy number field, the policyholder main table in the credit reporting database is queried according to the policy number included in the record; if a record related to the policy number is found in the policyholder main table, it is determined whether the policy number of the corresponding record in the policyholder main table has a value; if the policy number has a value, it is queried whether the record related to the policy number has been stored in the policyholder relationship table; if it has been stored, it is determined that the business actions and element records required in the current reporting scenario meet the reporting conditions; if the policy number has no value, the consumption of the next message continues.
[0081] Specifically, for example, if a record is inserted into the table `prpcinsurednature` in the business database `cq5000prp3gdb`, with the policy number `VExEVjIwMjM1MDAxTUEwMDAwNTc2Ng==`, the birth date `MjAxOS0wNy0xMw==`, and the address `5YyX5Lqs5biC6YCa5bee5Yy6546J5qGl5Y2X6YeM`, the credit preprocessing module will... The message is stored in the prpcinsurednature table of the credit reporting database. Since the message does not contain the policy number field, the policy number proposalno of the record needs to be used to look up the prpcmain table of the credit reporting database. If no relevant record is found in the prpcmain table according to the corresponding policy number proposalno, it means that the credit preprocessing module has not yet consumed the record corresponding to the policy number in the topic prpc.prpcmain, so it continues to consume the next message.
[0082] If a record for the corresponding policy number proposalno is found in the prpcmain table of the credit reporting database, then it is checked whether the policy number policyno of the corresponding record in the prpcmain table has a value. If it does, the database is then checked against the prpcinsured table, which is another table required for reporting, to see if a record exists. If a record exists, it means that the business actions and elements required for the current reporting scenario meet the reporting conditions. If the policy number policyno of the corresponding record does not have a value, it means that no record for underwriting approval for that policy number proposalno has been found in the records currently consuming the prpc.prpcmain topic, and the next message is consumed.
[0083] S240: When the reporting scenario is determined and the reporting conditions are met under the reporting scenario, the credit reporting scenario feature data is transmitted to the second message middleware.
[0084] In one embodiment of the present invention, when a reporting scenario is determined and it is determined that the reporting conditions are met under the reporting scenario, the credit reporting scenario feature data is transmitted to the second message middleware. Specifically, this includes: when it is determined that the reporting conditions are met under a specific reporting scenario, generating a credit reporting feature message corresponding to the specific reporting scenario through the credit preprocessing module; and transmitting the credit reporting feature message to the second message middleware.
[0085] Specifically, when the reporting conditions are met in a specific reporting scenario, the credit reporting preprocessing module generates a credit reporting feature message to indicate that specific elements are being reported in this scenario. The structure is as follows:
[0086] {
[0087] "businessNo":"UExEVjIwMjM1MDAxTUEwMDAwNTM2Ng==",
[0088] "reportType":"110 - Personal Basic Information Record"
[0089] }
[0090] The above information indicates that this is a scenario where personal basic information is submitted upon approval of underwriting (reportType is 110). The business primary key produced in this topic is businessNo. The messages produced in this topic have all been processed by the credit reporting preprocessing module, meaning that the messages entering this credit reporting feature topic have all met the reporting conditions in the credit reporting database.
[0091] S250: Consume messages from the second message middleware through the credit reporting module, query and retrieve data from the credit reporting database based on the consumption results, and perform reporting processing to complete the credit reporting.
[0092] In one embodiment of the present invention, the credit reporting module consumes messages from the second message middleware, queries and retrieves data from the credit reporting database based on the consumption results, and performs reporting processing to complete the credit reporting. Specifically, this includes: consuming messages from the credit feature topics of the second message middleware through the credit reporting module, determining the reporting scenario and business primary key corresponding to the message; querying the required business elements for reporting in the credit reporting database based on the reporting scenario and business primary key; generating corresponding text files from the business elements; encrypting the text files; and submitting the encrypted text files for credit reporting on the browser side.
[0093] Specifically, the credit reporting module consumes credit feature topics, determines the reporting scenario and business primary key corresponding to the message in the credit feature topic, and queries the credit reporting data for the required business elements based on the business primary key and reporting scenario (e.g., in the scenario of reporting personal basic information through underwriting, it is necessary to collect the elements corresponding to the three tables prpc.prpcmain, prpc.prpcinsured, and prpc.prpcinsurednature from the credit reporting database based on the business primary key). It generates the corresponding text file according to the structure specified by the bank, encrypts the corresponding text file, and finally performs credit reporting on the PC browser.
[0094] The above describes a credit data reporting method provided by an embodiment of the present invention. Based on the same inventive concept, the present invention also provides a corresponding credit data reporting device, such as... Figure 4 As shown.
[0095] The business database 402 is used to persist business data from the business system to the business database and form corresponding logical logs; the first transmission module 404 is used to parse the logical logs and transmit the parsing results to the first message middleware; the credit reporting preprocessing module 406 is used to consume messages in the first message middleware, store the records corresponding to the messages in the credit reporting database, and determine the reporting scenario; the second transmission module 408 is used to determine the reporting scenario and, when it is determined that the reporting conditions are met under the reporting scenario, transmit the credit reporting scenario feature data to the second message middleware; the credit reporting module 410 is used to consume messages in the second message middleware, query and obtain data from the credit reporting database based on the consumption results, and perform reporting processing to complete the credit reporting.
[0096] This invention also provides a corresponding credit data reporting device, such as... Figure 5 As shown, it includes:
[0097] The system includes at least one processor 502, a communication interface 504, a memory 506, and a communication bus 508; wherein the processor 502, the communication interface 504, and the memory 506 communicate with each other via the communication bus 508; the processor 502 can call logical instructions stored in the memory 506 to cause at least one processor 502 to execute:
[0098] The business data of the business system is persisted to the business database and corresponding logical logs are generated. The logical logs are parsed, and the parsing results are transmitted to the first message middleware. The credit reporting preprocessing module consumes the messages in the first message middleware, stores the records corresponding to the messages in the credit reporting database, and determines the reporting scenario. When the reporting scenario is determined and the reporting conditions are met, the credit reporting scenario feature data is transmitted to the second message middleware. The credit reporting module consumes the messages in the second message middleware, queries and retrieves the data in the credit reporting database based on the consumption results, and performs reporting processing to complete the credit reporting.
[0099] Based on the same idea, some embodiments of the present invention also provide media corresponding to the above methods.
[0100] Some embodiments of the present invention provide a storage medium storing computer-executable instructions, which are executed by a processor to perform the following steps:
[0101] The business data of the business system is persisted to the business database and corresponding logical logs are generated. The logical logs are parsed, and the parsing results are transmitted to the first message middleware. The credit reporting preprocessing module consumes the messages in the first message middleware, stores the records corresponding to the messages in the credit reporting database, and determines the reporting scenario. When the reporting scenario is determined and the reporting conditions are met, the credit reporting scenario feature data is transmitted to the second message middleware. The credit reporting module consumes the messages in the second message middleware, queries and retrieves the data in the credit reporting database based on the consumption results, and performs reporting processing to complete the credit reporting.
[0102] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are relatively simple in description because they are fundamentally similar to the method embodiments; relevant parts can be referred to the descriptions in the method embodiments.
[0103] The devices, media, and methods provided in the embodiments of the present invention are one-to-one correspondences. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.
[0104] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process method or product that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process method or product. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process method or product that includes that element.
[0105] The above are merely embodiments of the present invention and are not intended to limit the invention. Although the present invention has been described in detail above with general descriptions and specific embodiments, modifications or improvements can be made to it, which will be obvious to those skilled in the art. Therefore, all such modifications or improvements made without departing from the spirit of the present invention fall within the scope of protection claimed by the present invention.
Claims
1. A credit investigation data reporting method, characterized in that, The application relates to a credit reporting method and device. Business data of a business system is persisted into a business database, and a corresponding logical log is formed; The logical log is parsed, and a parsing result is transmitted to a first message middleware; A message in the first message middleware is consumed by a credit pre-processing module, records corresponding to the message are stored into a credit reporting database, and a reporting scene judgment is performed; When a reporting scene is determined and reporting conditions are met in the reporting scene, credit reporting scene feature data is transmitted to a second message middleware; The message in the second message middleware is consumed by a credit reporting module, data in the credit reporting database is queried and acquired according to a consumption result, and reporting processing is performed, so that credit reporting is completed; The records corresponding to the message are stored into the credit reporting database, and a credit reporting scene judgment is performed, specifically including: after the credit pre-processing module consumes the message in the insurance policy subject in the first message middleware, the message is converted into corresponding records and stored into a policy main table in the credit reporting database; If the credit pre-processing module determines that a policy number exists in the consumed message, whether the records related to the policy number exist in a policy relationship person table and a policy relationship person table sub-table in the credit reporting database is queried according to the policy number included in the message; each policy number corresponds to an insurance policy; when it is determined that the records related to the policy number have been stored into the credit reporting database, it is determined that the required business action and element records in the current reporting scene meet the reporting conditions.
2. The method of claim 1, wherein, The records corresponding to the message are stored into the credit reporting database, and a credit reporting scene judgment is performed, specifically including: After the credit pre-processing module consumes the message in the policy relationship person subject in the first message middleware, the message is converted into corresponding records and stored into a policy relationship person table in the credit reporting database; When it is determined that the message does not include a policy number field, the policy main table in the credit reporting database is queried according to the policy number included in the record; If the record related to the policy number is found in the policy main table, whether the policy number of the corresponding record in the policy main table has a value is judged; If the policy number has a value, whether the record related to the policy number has been stored in the policy relationship person table sub-table is queried, and if yes, it is determined that the required business action and element records in the current reporting scene meet the reporting conditions; If the policy number has no value, consumption of the next message is continued.
3. The method of claim 1, wherein, The records corresponding to the message are stored into the credit reporting database, and a credit reporting scene judgment is performed, specifically including: After the credit pre-processing module consumes the message in the policy relationship person sub-subject in the first message middleware, the message is converted into corresponding records and stored into a policy relationship person table sub-table in the credit reporting database; When it is determined that the message does not include a policy number field, the policy main table in the credit reporting database is queried according to the policy number included in the record; If a record related to the insurance policy number is found in the main policy form, it is determined whether the policy number corresponding to the record in the main policy form has a value; If the policy number has a value, it is determined whether the record related to the insurance policy number has been stored in the policy relationship table, and if so, it is determined that the required business action and element record under the current submission scenario meet the submission conditions; If the policy number has no value, the next message consumption is continued.
4. The method of claim 1, wherein, When the submission scenario is determined and it is determined that the submission conditions are met under the submission scenario, the credit investigation submission scenario feature data is transmitted to the second message middleware, specifically including: When it is determined that the submission conditions are met under a specific submission scenario, the credit investigation preprocessing module generates a credit investigation submission feature message corresponding to the specific submission scenario; The credit investigation submission feature message is transmitted to the second message middleware.
5. The method of claim 1, wherein, The credit investigation submission module consumes the messages in the second message middleware, queries and obtains the data in the credit investigation submission database according to the consumption result for submission processing to complete credit investigation, specifically including: The credit investigation submission module consumes the messages in the credit investigation feature topic of the second message middleware, determines the submission scenario and business primary key corresponding to the messages; According to the submission scenario and business primary key, the business elements required for submission are queried in the credit investigation submission database; The business elements are generated into corresponding text files, the text files are encrypted, and the encrypted text files are submitted on the browser side.
6. The method of claim 1, wherein, The credit investigation submission database and the business database are in a homogeneous subset relationship, and only the data tables involved in credit investigation submission are saved.
7. A credit information reporting apparatus characterized by comprising: It includes: A business database is used to persist the business data of a business system into a business database and form a corresponding logical log; A first transmission module is used to parse the logical log and transmit the parsing result to a first message middleware; A credit investigation preprocessing module is used to consume messages in the first message middleware, store records corresponding to the messages to a credit investigation submission database, and perform submission scenario judgment, specifically including: after the credit investigation preprocessing module consumes the messages in the policy subject of the first message middleware, the messages are converted into corresponding records and stored in the policy main table of the credit investigation submission database; if the credit investigation preprocessing module determines that there is a policy number in the consumed messages, according to the insurance policy number included in the messages, it is determined whether the record related to the insurance policy number exists in the policy relationship table and the policy relationship table sub-table in the credit investigation submission database; each insurance policy number corresponds to a policy; after it is determined that the record related to the insurance policy number has been stored in the credit investigation submission database, it is determined that the required business action and element record under the current submission scenario meet the submission conditions; A second transmission module is used to determine the submission scenario and determine that the submission conditions are met under the submission scenario, and transmit the credit investigation submission scenario feature data to the second message middleware. The credit reporting module is configured to consume the message in the second message middleware, query and acquire data in the credit reporting database according to a consumption result, and perform reporting processing, so as to complete credit reporting.
8. A credit data reporting device, characterized in that, Comprise: At least one processor; And, The memory is in communication connection with the at least one processor through the bus;Wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed to implement the method of any one of claims 1-6.
9. A non-transitory storage medium storing computer-executable instructions, the computer-executable instructions comprising: The computer executable instructions are executed by the processor to implement the method of any one of claims 1-6.
Citation Information
Patent Citations
Quasi-real-time data processing method and device, server and storage medium
CN112434062A
Credit investigation data submission method, device, system, equipment and medium
CN114862552A