Bank core system upgrade verification method, device and equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for verifying the upgrade of a bank's core system, relating to the field of data processing technology. The method includes: acquiring development-state and runtime data of a first-version database before the upgrade, and development-state and runtime data of a second-version database after the upgrade; comparing the development-state and runtime data of the first-version and second-version databases to obtain initial difference data; filtering the initial difference data according to preset ignorable conditions to obtain difference data to be confirmed; managing the difference baseline of the difference data to be confirmed to obtain the difference baseline for the development and testing phase; and deploying the difference baseline from the development and testing phase to the production phase, so that the production phase can perform difference verification based on the difference baseline from the development and testing phase. Through dual-dimensional difference comparison between development and runtime states and cross-phase difference baseline reuse, an automated closed-loop verification process for the upgrade of the bank's core system is achieved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, equipment and storage medium for upgrading and verifying a bank's core system. Background Technology

[0002] As the scale of banking business continues to expand and digital transformation deepens, core banking systems need to undergo regular major version upgrades to adapt to changes in business rules and regulatory requirements. The upgrade process involves database structure migration, program code modification, and business data conversion, making the need to verify data consistency and functional correctness before and after the upgrade increasingly urgent.

[0003] Current verification methods primarily rely on manual comparison of data before and after the upgrade. This approach suffers from drawbacks when dealing with massive amounts of static configuration data in development and dynamic business data in runtime, including a large workload, long verification cycle, and a tendency to miss data. Furthermore, existing technologies lack comprehensive automated difference verification methods for major version upgrades of core banking systems, making it difficult to establish reusable difference benchmarks during the development / testing and production phases, thus limiting upgrade acceptance efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, apparatus, device and storage medium for verifying upgrades of a bank's core system, aiming to solve the technical problem of insufficient automation in the differential verification process during major version upgrades of a bank's core system.

[0006] To achieve the above objectives, this application proposes a method for verifying the upgrade of a bank's core system, the method comprising: Obtain the development and runtime data of the first version database before the upgrade of the bank's core system, as well as the development and runtime data of the second version database after the upgrade; The development state data and the runtime state data of the first version database and the second version database are compared to obtain initial difference data; The initial difference data is filtered according to a preset ignorable condition to obtain the difference data to be confirmed; The difference data to be confirmed is managed to obtain the difference baseline for the development and testing phase. The development and testing phase difference baseline is deployed to the production phase so that the production phase can perform difference verification based on the development and testing phase difference baseline.

[0007] In one embodiment, the step of comparing the development-state data and the runtime data of the first version database and the second version database to obtain initial difference data includes: The development state data of the first version database and the development state data of the second version database are compared to obtain development state difference data. The runtime data of the first version database and the runtime data of the second version database are compared to obtain runtime difference data. The development-state difference data and the runtime difference data are aggregated to obtain the initial difference data.

[0008] In one embodiment, the runtime data includes transaction data, receipt text, original message text, report files, and response messages. The step of comparing the runtime data of the first version database with the runtime data of the second version database to obtain runtime difference data includes: The transaction data in the first version database and the transaction data in the second version database are compared to obtain transaction difference data; The transaction order text in the first version database and the transaction order text in the second version database are compared based on the transaction number to obtain transaction order difference data. Based on the transaction number and message type, the original message text in the first version database and the original message text in the second version database are identified and compared according to the message field to obtain message difference data; Subject data is extracted from the report files in the first version database and compared with the report files in the second version database to obtain report difference data; The response messages in the first version database and the response messages in the second version database are compared to obtain response message difference data. The transaction difference data, the receipt difference data, the message difference data, the report difference data, and the response message difference data are aggregated to obtain the runtime difference data.

[0009] In one embodiment, the step of comparing the transaction data in the first version database with the transaction data in the second version database to obtain transaction difference data includes: The transaction data in the first version database is compared with the transaction data in the second version database to obtain the transaction quantity difference data; New transactions are identified in the transaction quantity difference data to obtain new transaction difference data; The deleted transactions are identified in the transaction quantity difference data to obtain the deleted transaction difference data. The transaction data in the first version database and the transaction data in the second version database are compared in terms of transaction content to obtain transaction content difference data; The newly added transaction difference data, the deleted transaction difference data, and the transaction content difference data are aggregated to obtain transaction difference data.

[0010] In one embodiment, the step of comparing the development-state data of the first version database with the development-state data of the second version database to obtain development-state difference data includes: The development state data of the first version database and the development state data of the second version database are compared by field attributes to obtain the field attribute difference data; The number of records in the development state data of the first version database and the development state data of the second version database are compared to obtain the difference in the number of records. The field values ​​of the development state data in the first version database and the development state data in the second version database are compared to obtain the field value difference data; The program text is compared between the development state data of the first version database and the development state data of the second version database to obtain program text difference data; The development state data of the first version database and the development state data of the second version database are compared in batch processing to obtain batch processing difference data; The difference data of the field attributes, the difference data of the number of records, the difference data of the field values, the difference data of the program text, and the difference data of the batch processing are aggregated to obtain the development state difference data.

[0011] In one embodiment, the step of performing difference baseline management on the difference data to be confirmed to obtain the difference baseline for the development and testing phase includes: The discrepancy data to be confirmed is categorized and displayed according to business modules to obtain module-categorized discrepancy data; The module-specific difference data is divided into negligible differences and differences requiring modification. The negligible differences are stored in the negligible difference database to obtain the negligible difference storage result; The differences to be modified are modified and then stored in the database of negligible differences, resulting in the storage result of negligible differences. The negligible difference storage results are aggregated with the modified negligible difference storage results to obtain the difference baseline for the development and testing phase.

[0012] In one embodiment, the step of deploying the development and testing phase difference baseline to the production phase, so that the production phase performs difference verification based on the development and testing phase difference baseline, includes: The development state data and the running state data of the first version database and the second version database in the production stage are compared to obtain the initial production difference data. The initial production difference data is filtered according to the preset ignorable conditions to obtain the production difference data to be filtered. The production-ready difference data is filtered based on the development and testing phase difference baseline to obtain the production-ready-confirmation difference data. The production-to-be-confirmed discrepancy data is categorized and displayed according to the business module to obtain the production module-categorized discrepancy data. The production module categorizes the difference data and sends it to the confirmation terminal for confirmation, and the confirmed production difference data is obtained. Based on the confirmed production discrepancy data, a production discrepancy verification result is generated.

[0013] Furthermore, to achieve the above objectives, this application also proposes a bank core system upgrade difference verification device, the device comprising: The data acquisition module is used to acquire the development and runtime data of the first version database before the upgrade of the bank's core system, as well as the development and runtime data of the second version database after the upgrade. The difference comparison module is used to compare the development state data and the running state data of the first version database and the second version database to obtain initial difference data. The conditional filtering module is used to filter the initial difference data according to preset ignorable conditions to obtain the difference data to be confirmed. The baseline management module is used to manage the difference baselines of the difference data to be confirmed, and to obtain the difference baselines for the development and testing phase. The baseline deployment module is used to deploy the development and testing phase difference baseline to the production phase, so that the production phase can perform difference verification based on the development and testing phase difference baseline.

[0014] In addition, to achieve the above objectives, this application also proposes a bank core system upgrade verification device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the bank core system upgrade verification method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the bank core system upgrade verification method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the bank core system upgrade verification method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By acquiring and comparing development and runtime data from both versions of the bank's core system before and after the upgrade, and combining this with automatic filtering based on preset ignorable conditions and cross-phase deployment of difference baselines, automated verification of dual-dimensional differences between the development and runtime states was achieved during a major version upgrade of the bank's core system. The difference baselines confirmed during the development and testing phase can be directly reused in the production phase, avoiding repeated verification of confirmed differences, reducing manual comparison workload, improving the automation and efficiency of upgrade verification, and ensuring consistency between verification results in the development and testing phases and the production phase, thus achieving closed-loop management of the entire upgrade verification process. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating the first embodiment of the bank core system upgrade verification method for this application; Figure 2 The basic architecture diagram provided for Implementation Example 1 of the Bank Core System Upgrade Verification Method of this Application; Figure 3 This is a flowchart illustrating the second embodiment of the bank core system upgrade verification method for this application. Figure 4 This is a schematic diagram of the module structure of the bank core system upgrade verification device according to an embodiment of this application; Figure 5This is a schematic diagram of the hardware operating environment involved in the bank core system upgrade verification method in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a bank core system upgrade verification device. The following description uses a bank core system upgrade verification device as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, the embodiments of this application provide a method for verifying the upgrade of a bank's core system, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for upgrading and verifying equipment in the core banking system of this application.

[0026] In this embodiment, the method for upgrading and verifying the bank's core system includes steps S10 to S50: Step S10: Obtain the development state data and runtime state data of the first version database before the upgrade of the bank's core system, and the development state data and runtime state data of the second version database after the upgrade. It should be noted that the core banking system refers to the core accounting platform of the bank, which is the core business processing platform that carries out the bank's daily transaction recording and fund clearing. It is the most basic business processing component in the bank's information technology architecture.

[0027] It should be noted that the first version database refers to the collection of all data tables and data records corresponding to the version of the bank's core system before the upgrade, that is, the unified organization of all development-state data and runtime data stored in the database before the upgrade.

[0028] It should be noted that development-state data refers to static data such as field definitions, program code, configuration parameters, and batch processing parameters that do not change in real time with a single transaction. In other words, it is data content formed during the development and configuration process that does not change frequently due to business operations.

[0029] It should be noted that runtime data refers to dynamic data such as transaction logs, receipt information, message content, report data, and response messages that are generated in real time as business operations proceed. In other words, it is the data content that is continuously generated during business transactions due to customer operations or batch processing execution.

[0030] It should be noted that the second version database refers to the collection of all data tables and data records corresponding to the upgraded version of the bank's core database, that is, the unified organization of all development-state data and runtime data stored in the upgraded database.

[0031] Understandably, obtaining the development and runtime data of the first version database before the upgrade of the bank's core system, as well as the development and runtime data of the second version database after the upgrade, means extracting all data content in the development and runtime states from the two databases before and after the upgrade, respectively, in order to establish the data source foundation required for subsequent difference comparison.

[0032] By acquiring development and runtime data from both versions before and after the upgrade, a complete data source for difference comparison was established, providing a data foundation for subsequent multi-dimensional difference verification.

[0033] It should be understood that this solution uses a low-code frontend and the ZA21 backend framework to implement the difference comparison function. Data is divided into development-state and runtime-state data. Development-state data contains information used by IT developers, while runtime-state data contains business transaction-related information. To achieve automated difference verification, during the development and testing phase, rules are generated to ensure that differences between development-state and runtime are negligible. During the production phase, these differences can be quickly ignored, which helps improve the efficiency and quality of upgrade acceptance.

[0034] like Figure 2 As shown, Figure 2The basic architecture diagram is divided into two main modules: the development and testing phase and the production phase. Both phases share the same data source on the left. This data source includes development-state comparisons (branched by APPLICATION, VERSION, ENQUIRY, and blank ellipsis boxes) and runtime comparisons (branched by Transaction, Policy, Message, and blank ellipsis boxes). All data sources are aggregated and combined with data from the database output of the "preset whitelist of table fields with no impact" into the system's automatic ignore difference node. In the development and testing phase, the data source and whitelist enter the system, where differences are automatically ignored. The process then proceeds to the module-based difference statistics display, followed by a manual confirmation node. Manual confirmation has two branches: the "ignore" branch points to the "evaluate differences with no impact" database, which connects back to the system's automatic ignore difference input; the "to be modified" branch points to the modification node, which outputs to the "modified expected differences" section. The database is also connected to the system's automatically ignored difference input. In the production phase, the process is as follows: after the data from the same source and the whitelist enter the system and the differences are automatically ignored, the data first flows to the node where the differences have been manually confirmed, then to the difference statistics display by module, and finally to the manual confirmation node. There is no branching processing link for manual confirmation in the production phase. At the same time, the data from the two sets of backflow databases of the evaluation of no impact differences and the expected differences that have been modified in the development and testing phases are connected to the input front end of the system's automatically ignored differences in the production phase through a vertical cross-phase connection.

[0035] Step S20: Compare the development state data and runtime state data of the first version database and the second version database to obtain initial difference data; It should be noted that difference comparison refers to the process of comparing and analyzing the corresponding data content in different versions of the database item by item. That is, the process of identifying and recording the inconsistencies in the data content between the two versions. It is the core technical means to discover data changes before and after the upgrade.

[0036] It should be noted that the initial difference data refers to the complete set of difference results obtained after the difference comparison is completed. That is, it includes the unprocessed original difference information of development state difference and runtime state difference, and is the input data source for subsequent filtering and confirmation processing.

[0037] Understandably, comparing the development and runtime data of the first and second version databases to obtain initial difference data means comparing the development data of the two versions of the database before and after the upgrade, comparing the runtime data, and summarizing the two types of difference results to form a complete set of difference results.

[0038] By comparing and aggregating the differences between development and runtime data, full coverage identification of data changes before and after the upgrade was achieved, improving the completeness of difference discovery.

[0039] Step S30: Filter the initial difference data according to the preset ignorable conditions to obtain the difference data to be confirmed; It should be noted that the preset ignoreable condition refers to the pre-configured criteria for determining whether a difference is not worth paying attention to. In other words, data differences that meet the condition can be excluded from the subsequent confirmation process. It is a pre-screening mechanism to reduce interference from invalid differences.

[0040] It should be noted that the difference data to be confirmed refers to the set of difference data retained after being filtered by preset ignore conditions. That is, the difference information that needs to be further manually confirmed or analyzed. It is the direct object of difference baseline management in the development and testing phase.

[0041] Understandably, filtering the initial difference data according to the preset ignorable conditions to obtain the difference data to be confirmed means matching the initial difference data with the preset ignorable conditions, removing the difference data that matches the preset ignorable conditions, and retaining the difference data that does not match the conditions as the objects for subsequent confirmation processing.

[0042] By automatically filtering with preset ignorable conditions, known non-influencing difference data is removed in advance, reducing the workload of subsequent manual confirmation and improving verification efficiency.

[0043] In one example, the preset ignorable conditions are configured separately for table dimensions and field dimensions. The table dimension configuration sets the ignorable range based on the data table as the basic unit, and the field dimension configuration sets the ignorable range based on a single field within the table as the basic unit. Furthermore, the development state data and the running state data are each configured with corresponding ignorable conditions.

[0044] Step S40: Perform difference baseline management on the difference data to be confirmed to obtain the difference baseline for the development and testing phase; It should be noted that difference baseline management refers to the management process of classifying, storing and tracking the status of confirmed difference data. In other words, it involves establishing a reusable difference baseline library to support subsequent verification stages and is the core management link for achieving cross-stage difference reuse.

[0045] It should be noted that the difference baseline in the development and testing phase refers to the set of difference benchmarks formed after the development and testing phase is completed. It is an aggregated result that includes all negligible differences and modified differences, and is the core basis for difference filtering and verification reuse in the production phase.

[0046] Understandably, managing the difference baselines for the data to be confirmed and obtaining the difference baselines for the development and testing phase involves classifying and displaying the difference data to be confirmed according to business modules, dividing it into negligible differences and differences to be modified after manual confirmation, storing them in the corresponding databases, and then aggregating them after modification to form a complete set of difference benchmarks.

[0047] By managing the difference baseline, the differences confirmed during the development and testing phase can be directly reused in the production phase, avoiding repetitive manual confirmation work and improving the efficiency of cross-phase verification.

[0048] In one feasible implementation, step S40 may include steps A11-A15: Step A11: Categorize and display the discrepancy data to be confirmed according to business modules to obtain module-categorized discrepancy data; It should be noted that a business module refers to a functional unit within the core of a bank, divided according to business functions. These include different business responsibility domains such as deposits, loans, and payment settlements. They are the basic organizational units for classifying and displaying different data and allocating responsibilities.

[0049] It should be noted that module-classified difference data refers to a structured set of difference information formed by grouping the difference data to be confirmed according to business modules. That is, the summary of difference data corresponding to each business responsibility domain, which is the direct processing object for business leaders to verify and judge differences.

[0050] Understandably, classifying and displaying the discrepancy data to be confirmed by business module to obtain module-classified discrepancy data means grouping the discrepancy data to be confirmed according to its business functional domain and presenting it in a visual form so that business leaders can quickly locate the discrepancy information within their domain of responsibility.

[0051] By categorizing and displaying data according to business modules, discrepancies are structured and allocated to each business responsibility domain, making it easier for business leaders to quickly locate and handle discrepancies within their scope of responsibility.

[0052] In one example, before the comparison, all tables to be compared are aggregated and categorized by business domain, and the business module to which each table belongs is identified. The difference data to be confirmed is then categorized and displayed according to the business module.

[0053] In one example, the discrepancy data to be confirmed is categorized and displayed according to business modules, and the discrepancy content is visually annotated using a highlighting method to obtain module-categorized discrepancy data.

[0054] Step A12: Divide the module classification difference data into negligible differences and differences that need to be improved; It should be noted that negligible differences refer to difference data that have no substantial impact on the upgrade after manual confirmation, i.e., difference information that does not require modification. These are difference categories that are determined to not affect the correctness of business after verification during the development and testing phase.

[0055] It should be noted that the differences to be modified refer to the difference data that needs to be modified after manual confirmation. That is, the difference information that affects the correctness of business and needs to be fixed. It is the difference category that is determined to require program or configuration correction after verification during the development and testing phase.

[0056] Understandably, classifying module-specific differences into negligible differences and differences requiring modification means that the business manager verifies each of the classified differences to determine whether the difference will affect the upgraded business operation, and marks the result as either no need for processing or needing repair.

[0057] By dividing the differences into negligible differences and differences requiring modification, the priority and responsibility boundaries for handling differences are clarified, thus avoiding the occupation of subsequent modification resources by invalid differences.

[0058] Step A13: Store the negligible differences to the negligible differences database to obtain the negligible differences storage result; It should be noted that the negligible difference database refers to a dedicated dataset that stores negligible difference data. That is, a persistent storage area where differences that have been confirmed to have no impact during the development and testing phase are used as the data carrier for the no-impact judgment conclusions in the subsequent verification phase.

[0059] It should be noted that the negligible difference storage result refers to the storage state record formed after the negligible difference data is persisted, that is, the storage form of the non-impact difference in the database, and is the data carrier of the non-impact difference in the difference baseline during the development and testing phase.

[0060] Understandably, storing negligible differences in a negligible difference database to obtain negligible difference storage results means persistently saving difference data that has been manually confirmed to have no substantial impact to a dedicated storage area so that the judgment conclusion can be directly reused in subsequent verification stages.

[0061] By persistently storing negligible differences, the conclusions of the no-impact judgment during the development and testing phases are solidified, and the stored results can be directly called for difference filtering during the production phase.

[0062] Step A14: After modifying the differences to be modified, store them in the database of modified and negligible differences to obtain the storage result of modified and negligible differences; It should be noted that the modified and negligible difference database refers to a dedicated dataset that stores the difference data after the modification is completed. That is, it is a persistent storage area that records the state of the differences to be modified after they have been repaired. It is the data carrier that can be directly reused in the subsequent verification stage.

[0063] It should be noted that the modified negligible difference storage result refers to the storage state record formed by persistently storing the difference to be modified after repair. That is, the storage form of the processed difference in the database, and it is the data carrier of the repaired difference in the difference baseline during the development and testing phase.

[0064] Understandably, storing the differences to be modified into the database of modified and negligible differences after modification, and obtaining the storage result of modified and negligible differences, means that the difference data to be repaired is modified at the program or configuration level, and after the modification is completed, the difference status is updated to processed, and it is persistently saved to a dedicated storage area.

[0065] By persistently storing the modified differences, the fixes from the development and testing phases are solidified, and the stored results can be directly called for difference filtering during the production phase.

[0066] Step A15: Aggregate the negligible difference storage results with the modified negligible difference storage results to obtain the difference baseline for the development and testing phase.

[0067] Understandably, aggregating the results of negligible difference storage with the results of modified negligible difference storage to obtain the difference baseline in the development and testing phase means merging the non-impact difference data with the corrected difference data to form a complete set of difference benchmarks, which serves as the basis for difference filtering in the production phase.

[0068] By aggregating the storage results with negligible differences and the modified storage results with negligible differences, a benchmark set covering all confirmed differences is formed, providing a complete data foundation for cross-stage reuse during the production phase.

[0069] Step S50: Deploy the development and testing phase difference baseline to the production phase so that the production phase can perform difference verification based on the development and testing phase difference baseline.

[0070] It should be noted that the production phase refers to the operational phase after the bank's core system upgrade, when it officially provides services to the public. In other words, it is the production environment phase after the upgrade and the system goes live. It is the environment state for actual business operations after the major version upgrade of the bank's core system is completed.

[0071] It should be noted that difference verification refers to the process of comparing the differences between the database before and after the upgrade in the production phase and confirming the status of the difference processing. In other words, it is the verification process to determine whether the upgrade and production are successful. It is the final judgment step in the acceptance phase of the bank's core major version upgrade.

[0072] Understandably, deploying the difference baseline from the development and testing phase to the production phase, so that the production phase can perform difference verification based on the difference baseline from the development and testing phase, means transferring the set of difference benchmarks formed in the development and testing phase to the production environment, so that the production phase can directly filter the confirmed differences after difference comparison, and thus only focus on newly emerging differences.

[0073] By deploying the baseline differences from the development and testing phases to the production phase, the production phase can directly reuse the confirmation conclusions from the development and testing phases, avoiding repeated verification of known differences and improving the efficiency of production acceptance.

[0074] In one feasible implementation, step S50 may include steps A21 to A26: Step A21: Compare the development and runtime data of the first and second version databases during the production phase to obtain the initial production difference data; It should be noted that the initial production difference data refers to the unprocessed original difference set obtained after comparing the differences between the databases before and after the upgrade in the production environment. That is, the complete difference discovery results in the production stage, which is the original input for difference filtering and confirmation in the production stage.

[0075] Understandably, comparing the development and runtime data of the first and second version databases during the production phase to obtain the initial production difference data means performing an item-by-item comparison of the development and runtime data before and after the upgrade in the production environment to obtain the original set of difference results during the production phase.

[0076] By conducting a full-dimensional difference comparison again in the production environment, the integrity of the difference discovery during the production stage was ensured, providing a raw data foundation for subsequent baseline-based filtering.

[0077] Step A22: Filter the initial production difference data according to preset ignorable conditions to obtain the production difference data to be filtered; It should be noted that the production-to-be-filtered difference data refers to the set of production-to-be-filtered difference data retained after being filtered by preset ignoreable conditions. In other words, it is the difference information that needs to be further compared with the difference baseline. It is the intermediate data state before the difference baseline is filtered in the production-to-be-filtered stage.

[0078] Understandably, filtering the initial production difference data according to preset ignorable conditions to obtain the production difference data to be filtered means matching the initial production difference data with preset ignorable conditions, eliminating the difference data that hit the conditions, and retaining the difference information that needs further processing.

[0079] By filtering again with preset ignorable conditions, the production phase first eliminates known, non-influential common differences, reducing the amount of data to be compared with the difference baseline in the later stage.

[0080] Step A23: Filter the production-ready difference data based on the development and testing phase difference baseline to obtain the production-ready-confirmation difference data; It should be noted that the production-pending discrepancy data refers to the set of production discrepancy data that still needs to be manually confirmed after being filtered by the discrepancy baseline. That is, the discrepancy information that appears in the production stage and was not recorded in the development and testing stage. It is the set of discrepancies that the business person in charge needs to verify in the production stage.

[0081] Understandably, filtering production-ready difference data based on the development and testing phase difference baseline to obtain production-ready-confirmation difference data means comparing the production-ready-ready-filtered difference data with the development and testing phase difference baseline, removing difference data that has been confirmed to have no impact or has been repaired in the development and testing phase, and retaining the difference information that newly appears in the production phase.

[0082] By filtering differences across stages, differences already identified during the development and testing phases are automatically excluded, allowing business owners to focus only on differences that emerge during the production phase, significantly reducing the workload of production verification.

[0083] Step A24: Categorize and display the production launch discrepancy data according to business modules to obtain the production launch module categorized discrepancy data; It should be noted that the production module categorized difference data refers to the structured difference information set formed by grouping the production-to-be-confirmed difference data by business module. In other words, it is the summary of difference data corresponding to each business responsibility domain in the production phase, and is the direct processing object for the business person in charge to verify differences in the production phase.

[0084] Understandably, categorizing and displaying the production-stage unconfirmed discrepancy data by business module to obtain production-stage categorized discrepancy data means grouping the unconfirmed discrepancy data retained during the production stage according to its business functional domain and presenting it in a visual format so that business leaders can conduct final verification.

[0085] By categorizing and displaying the differences in the production phase according to business modules, newly emerging differences are structurally assigned to each business responsibility domain, making it easier for business leaders to quickly locate and verify differences within their scope of responsibility.

[0086] Step A25: Send the production module's categorized difference data to the confirmation terminal for confirmation, and obtain the confirmed production difference data; It should be noted that the confirmation terminal refers to the interactive device used to receive discrepancy data and return the results of manual confirmation. In other words, it is the operation interface for the business manager to verify and judge discrepancies, and it is the front-end carrier for realizing human-computer interaction in the discrepancy confirmation process.

[0087] It should be noted that the confirmed production discrepancy data refers to the set of production discrepancy data after manual verification by the confirmation terminal, that is, the final confirmed discrepancy results in the production stage, which is the direct data source for generating production discrepancy verification results and acceptance reports.

[0088] Understandably, sending the production module's categorized difference data to the confirmation terminal for verification, and obtaining the confirmed production difference data, means that the categorized difference data in the production stage is pushed to the business manager's operation interface, where the business manager performs the final verification and returns the confirmation conclusion, forming the final difference dataset for the production stage.

[0089] Through final manual verification at the confirmation terminal, the handling conclusions for newly emerging discrepancies during the production phase were confirmed by the business manager, ensuring the accuracy and reliability of the production verification results.

[0090] Step A26: Generate production difference verification results based on the confirmed production difference data.

[0091] It should be noted that the production difference verification result refers to the final output of the production phase difference verification process, that is, the verification conclusion that determines whether the upgrade and production are successful, and is the final judgment basis for the bank's core major version upgrade acceptance phase.

[0092] Understandably, generating production difference verification results based on confirmed production difference data means summarizing and analyzing the production stage difference data that has been manually confirmed, forming a verification conclusion to determine whether the upgrade and production were successful, and outputting a corresponding verification report.

[0093] By generating production difference verification results, the status of difference handling during the production phase is comprehensively summarized, providing a clear basis for determining whether the upgrade and production are successful, and realizing closed-loop management of the entire upgrade verification process.

[0094] This embodiment provides a method for verifying upgrades to a bank's core system. By comparing the development and operational data of the database before and after the upgrade across all dimensions, it achieves complete verification of static configuration and dynamic business data. Pre-defined ignorable filtering conditions reduce interference from known, insignificant differences. Categorized display of business modules allows business leaders to quickly locate differences within their respective areas of responsibility. Difference baseline management aggregates ignorable differences confirmed during the development and testing phases, along with already modified differences, into a baseline set for reuse in the production phase, avoiding redundant verification of confirmed differences. Through difference comparison, baseline filtering, and confirmation during the production phase, a difference acceptance report is generated, providing a basis for determining the success of the upgrade and production deployment. This achieves closed-loop management of the entire process from difference discovery to acceptance report generation, improving the automation and efficiency of bank core system major version upgrade verification.

[0095] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S20 includes steps S201 to S203: Step S201: Compare the development state data of the first version database with the development state data of the second version database to obtain the development state difference data; It should be noted that development-state difference comparison refers to the process of comparing and analyzing the static development-state data in the databases before and after the upgrade item by item. This involves identifying inconsistencies in static content such as field definitions, program code, configuration parameters, and batch processing parameters. Furthermore, development-state difference data refers to the complete set of difference results obtained after completing the development-state difference comparison. This includes unprocessed raw difference information such as field attributes, record count, field values, program text, and batch processing differences. It serves as one of the input data sources for subsequent runtime difference data aggregation.

[0096] Understandably, comparing the development-state data of the first version database with the development-state data of the second version database to obtain development-state difference data means comparing the development-state static data in the pre-upgrade version database with the corresponding development-state static data in the post-upgrade version database item by item, identifying and recording the inconsistencies between the two, and forming a set of difference results at the development-state level.

[0097] By conducting a specific comparison of development-state data, a complete identification of static configuration and code changes before and after the upgrade was achieved, providing a static data-level basis for subsequent full-dimensional difference verification.

[0098] In one feasible implementation, step S201 may include steps A31 to A36: Step A31: Compare the field attributes of the development data in the first version database and the development data in the second version database to obtain the field attribute difference data; It should be noted that field attributes refer to the technical definition information of each field in a database table, namely, the data type, length limit, and single or multiple value identifier of the field, etc., which are metadata characteristics and are the basic structural elements for defining data storage rules. Additionally, field attribute difference data refers to the difference results obtained by comparing the field attributes of the database before and after the upgrade; that is, the set of records where the data type, length, or single or multiple value identifier of the field has changed. This is an important component of the development-state difference data reflecting changes in data structure.

[0099] Understandably, comparing the field attributes of the development data of the first version database and the development data of the second version database to obtain the field attribute difference data means comparing the field definition information in the database table before the upgrade with the field definition information in the corresponding table after the upgrade item by item, identifying the fields whose data type, length, or single or multiple value identifier has changed, and recording the difference results.

[0100] By comparing field attributes, changes to the database table structure before and after the upgrade can be accurately identified, providing a basis for subsequent assessment of the impact of structural changes on business.

[0101] Step A32: Compare the number of records in the development state data of the first version database with the number of records in the development state data of the second version database to obtain the difference in the number of records; It should be noted that the record count refers to the total number of data entries in a database table, that is, the number of data rows stored in the table, which is a basic statistical indicator reflecting the scale and integrity of the data. Additionally, the record count difference data refers to the difference obtained by comparing the number of records in the database table before and after the upgrade, that is, the information on the number of data records added or deleted after the upgrade compared to before the upgrade, which is an important component reflecting changes in data scale within the development-state difference data.

[0102] Understandably, comparing the number of records in the development state data of the first version database with the development state data of the second version database to obtain the record number difference data means counting the total number of data record entries in the corresponding database tables before and after the upgrade, comparing the difference between the two, identifying the number of added or deleted records, and forming the difference result.

[0103] By comparing the recorded quantities, abnormal changes in data scale before and after the upgrade can be quickly identified, providing a quantitative basis for locating omissions in the data migration or synchronization process.

[0104] Step A33: Compare the field values ​​of the development data in the first version database with the development data in the second version database to obtain the field value difference data; It should be noted that field values ​​refer to the specific data content of the corresponding fields in each record of a database table, that is, the actual stored business data or configuration values, and are the core data entities that carry business information in the data table. Additionally, field value difference data refers to the difference results obtained after comparing the field values ​​of database records before and after the upgrade. This includes detailed information on inconsistencies in the data content of the same field in the same record before and after the upgrade, and is an important component reflecting data content changes in the development-state difference data.

[0105] Understandably, comparing field values ​​between the development state data of the first version database and the development state data of the second version database to obtain field value difference data means comparing the field values ​​of each record in the database table before the upgrade with the same field values ​​of the same records in the corresponding table after the upgrade item by item, identifying the specific fields in which the data content has changed and the values ​​before and after the change, and forming the difference results.

[0106] By comparing field values, we can accurately pinpoint the specific changes in data content before and after the upgrade, providing detailed data support for analyzing the accuracy of data migration and the impact of business rule adjustments.

[0107] Step A34: Compare the program text between the development state data of the first version database and the development state data of the second version database to obtain the program text difference data; It should be noted that program text refers to the source code content of the application in the bank's core system, that is, the program code text that implements business logic and data processing functions, and is the core software asset that defines business processing rules. Additionally, program text difference data refers to the difference results obtained after comparing the program text before and after the upgrade, that is, the specific content information of additions, deletions, and modifications that occurred in the program source code before and after the upgrade, and is an important component reflecting code changes in the development-state difference data.

[0108] Understandably, comparing the program text of the development state data of the first version database with the development state data of the second version database to obtain program text difference data means comparing the program code text stored in the database before the upgrade with the corresponding program code text after the upgrade line by line or segment by segment to identify the additions, deletions and modifications in the code content and form the difference results.

[0109] By comparing program text, the changes in program code before and after the upgrade can be fully recorded, providing a direct basis for assessing the impact of code modification on business functions and subsequent program regression verification.

[0110] Step A35: Perform batch processing comparison of the development state data of the first version database and the development state data of the second version database to obtain batch processing difference data; It should be noted that batch processing refers to batch data processing tasks automatically executed according to a predetermined cycle within the bank's core system. This includes backend processing programs such as batch accounting, batch settlement, and batch report generation triggered at the end of the day or at scheduled times. It is the core operational unit for achieving automated processing of large-scale business data. Additionally, batch processing difference data refers to the difference results obtained by comparing batch processing configurations or execution results before and after the upgrade. This includes detailed information on changes in batch processing parameters, execution logic, or output content before and after the upgrade, and is an important component of the development-state difference data reflecting batch processing changes.

[0111] Understandably, performing batch processing comparison between the development state data of the first version database and the development state data of the second version database to obtain batch processing difference data means comparing the batch processing configuration parameters and execution logic stored in the database before the upgrade with the corresponding batch processing configuration and logic after the upgrade item by item, identifying the batch processing-related changes, and forming the difference results.

[0112] By comparing batch processing data, changes in batch processing task configuration and logic before and after the upgrade can be identified, providing a specific verification basis for assessing the impact of batch processing transformation on end-of-day business processing and report generation.

[0113] Step A36: Aggregate the field attribute difference data, record quantity difference data, field value difference data, program text difference data, and batch processing difference data to obtain the development state difference data.

[0114] It is understandable that aggregating the differences in field attributes, record quantity, field value, program text, and batch processing data to obtain development-state difference data means summarizing and merging the difference results of the five dimensions of field attributes, record quantity, field value, program text, and batch processing to form a complete set of differences covering all development-state data types.

[0115] By aggregating the development-state difference data across five dimensions, a comprehensive summary of development-state differences was achieved, providing a complete static difference foundation for the unified processing of subsequent operational-state difference data.

[0116] Step S202: Compare the runtime differences between the runtime data of the first version database and the runtime data of the second version database to obtain runtime difference data; It should be noted that runtime difference comparison refers to the process of comparing and analyzing runtime dynamic data in the databases before and after the upgrade item by item. This involves identifying inconsistencies in dynamic business data such as transaction logs, receipt information, message content, report data, and response messages. Additionally, runtime difference data refers to the complete set of difference results obtained after runtime difference comparison. This includes unprocessed raw difference information related to transactions, receipts, messages, reports, and response messages, and serves as one of the input data sources for subsequent aggregation with development-state difference data.

[0117] Understandably, comparing the runtime data of the first version database with the runtime data of the second version database to obtain runtime difference data means comparing the runtime dynamic data in the pre-upgrade version database with the corresponding runtime dynamic data in the post-upgrade version database item by item, identifying and recording the inconsistencies between the two, and forming a set of runtime-level difference results.

[0118] By conducting a specific difference comparison of the operational data, a complete identification of dynamic business data changes before and after the upgrade was achieved, providing a basis for subsequent multi-dimensional difference verification at the dynamic business data level.

[0119] In one feasible implementation, step S202 may include steps A41 to A46: Step A41: Compare the transaction data in the first version database with the transaction data in the second version database to obtain the transaction difference data; It should be noted that transaction data refers to the transaction logs generated by the bank's core system during customer business operations. This includes business operation logs containing information such as transaction number, transaction amount, transaction time, and transaction status, and is core dynamic data recording the process of banking transactions. Additionally, transaction discrepancy data refers to the differences obtained after comparing transaction data before and after the upgrade. This includes detailed information on changes in transaction quantity and content before and after the upgrade, and is an important component of operational discrepancy data reflecting changes in transaction operations.

[0120] Understandably, comparing the transaction data in the first version database with the transaction data in the second version database to obtain transaction difference data means comparing the transaction records in the database before the upgrade with the corresponding transaction records after the upgrade item by item to identify changes in the number and content of transactions and form the difference results.

[0121] By comparing the differences in transaction data, we can identify the changes in transaction business before and after the upgrade, providing a business-level verification basis for verifying the impact of the upgrade on the transaction processing logic.

[0122] In one feasible implementation, step A41 may include steps B11-B15: Step B11: Compare the transaction data in the first version database with the transaction data in the second version database to obtain the transaction quantity difference data; It should be noted that transaction volume comparison refers to the process of comparing and analyzing the total number of transaction records in the database before and after the upgrade. This involves statistically analyzing and comparing the differences in the number of transaction records between the two versions of the database, serving as a fundamental comparison method for identifying changes in transaction scale. Additionally, transaction volume difference data refers to the difference results obtained after completing the transaction volume comparison, i.e., the change in the total number of transaction records after the upgrade relative to before the upgrade. This is a fundamental component of the transaction difference data reflecting changes in transaction scale.

[0123] Understandably, comparing the transaction data of the first version database with the transaction data of the second version database to obtain the transaction quantity difference data means counting the total number of transaction records in the database before and after the upgrade, and comparing the difference between the two to form the difference result.

[0124] By comparing transaction volumes, abnormal changes in transaction volume before and after the upgrade can be quickly identified, providing a quantitative basis for locating changes in transaction processing logic or data migration issues.

[0125] Step B12: Identify the new transactions in the transaction quantity difference data to obtain the new transaction difference data; It should be noted that "new transactions" refers to transaction records that appear in the upgraded database relative to the database before the upgrade. These are transaction records that exist only in the second version database and not in the first version database. This is a specific category of difference reflecting an increase in transactions within the transaction quantity difference data. Additionally, "new transaction difference data" refers to the difference results obtained after identifying new transactions; that is, a detailed collection of information about the new transaction records. This represents the specific difference content within the transaction difference data that requires confirmation or processing by the business manager.

[0126] Understandably, identifying new transactions in the transaction quantity difference data to obtain new transaction difference data means filtering out the newly added transaction records after the upgrade from the transaction quantity difference results, extracting the detailed information of these new transactions, and forming a special difference result.

[0127] By identifying new transactions, we can clearly define the types or quantities of new business transactions added after the upgrade, providing specific data for analyzing the impact of the upgrade on the scope of business transactions.

[0128] Step B13: Identify deleted transactions in the transaction quantity difference data to obtain deleted transaction difference data; It should be noted that deleted transactions refer to transaction records that existed in the database before the upgrade but disappeared after the upgrade. In other words, these are transaction records that only existed in the first version of the database and not in the second version. This is a specific category of difference reflecting a reduction in transactions within the transaction quantity difference data. Additionally, deleted transaction difference data refers to the difference results obtained after identifying deleted transactions; that is, a detailed collection of information on deleted transaction records. This represents the specific difference content within the transaction difference data that requires confirmation or processing by the business manager.

[0129] Understandably, identifying deleted transactions in the transaction quantity difference data to obtain deleted transaction difference data means filtering out transaction records that disappeared after the upgrade from the transaction quantity difference results, extracting detailed information of these deleted transactions, and forming specific difference results.

[0130] By identifying deleted transactions, it is possible to clarify the types of business transactions that are reduced or canceled after the upgrade, providing specific data for analyzing the impact of the upgrade on the scope of business transactions.

[0131] Step B14: Compare the transaction data in the first version database with the transaction data in the second version database to obtain the transaction content difference data; It should be noted that transaction content comparison refers to the process of comparing and analyzing the specific fields of the same transaction record before and after the upgrade, that is, comparing the differences in the values ​​of fields such as transaction amount, transaction status, and additional transaction information. It is a refined comparison method to identify changes in transaction details. Additionally, transaction content difference data refers to the difference results obtained after completing the transaction content comparison, that is, detailed information on inconsistencies in field values ​​for the same transaction number corresponding to the record before and after the upgrade. It is an important component of the transaction difference data reflecting changes in transaction details.

[0132] Understandably, comparing transaction data from the first version database with transaction data from the second version database to obtain transaction content difference data means comparing the field content of transaction records in the database before the upgrade with the same field content of the corresponding transaction records after the upgrade item by item, identifying the specific content of the changed field values, and forming the difference results.

[0133] By comparing transaction content, we can accurately pinpoint the specific data changes caused by adjustments to transaction business rules, providing detailed evidence for verifying the correctness of the upgraded transaction processing logic.

[0134] Step B15: Aggregate the newly added transaction difference data, deleted transaction difference data, and transaction content difference data to obtain transaction difference data.

[0135] It is understandable that aggregating new transaction difference data, deleted transaction difference data, and transaction content difference data to obtain transaction difference data means summarizing and merging the difference results of the three dimensions of new transactions, deleted transactions, and transaction content to form a complete set of transaction difference data covering changes in the number of transactions and transaction content.

[0136] By aggregating transaction difference data from three dimensions, a comprehensive summary of transaction differences was achieved, providing a complete foundation for the unified processing of subsequent runtime difference data.

[0137] Step A42: Compare the transaction receipt text in the first version database with the transaction receipt text in the second version database based on the transaction number to obtain the transaction receipt difference data; It should be noted that the transaction number is a unique identifier assigned by the bank's core system to each business transaction. This identifier distinguishes different transaction records and is a core index field for associated business data such as receipts, messages, and response messages. Additionally, the receipt text refers to the text content of the customer receipt document generated by the bank's core system after processing the transaction. This document records the transaction result and serves as a business confirmation for the customer, representing core voucher data for providing feedback on the processing result after the transaction is completed. Furthermore, receipt discrepancy data refers to the difference results obtained by comparing the receipt texts before and after the upgrade. This detailed information shows changes in the receipt text content before and after the upgrade and is an important component of the operational discrepancy data reflecting changes in receipt content.

[0138] Understandably, comparing the transaction receipt texts in the first version database with those in the second version database based on the transaction number to obtain the receipt difference data means using the transaction number as a correlation index to extract the receipt text content corresponding to the same transaction from the databases before and after the upgrade, and then comparing the two receipt texts segment by segment to identify content differences and form the difference results.

[0139] By associating transaction numbers with receipt texts and comparing the differences, the correctness of the upgraded receipt generation logic can be verified, ensuring the accuracy and consistency of customer receipt information.

[0140] Step A43: Based on the transaction number and message type, identify and compare the original messages in the first version database and the original messages in the second version database according to the message fields to obtain message difference data; It should be noted that the message type refers to the message classification identifier used by the bank's core operations when processing cross-border or interbank business. This type of identifier distinguishes the message format and purpose under different business scenarios and is the core classification basis for identifying the business attributes of the message. Additionally, the original message text refers to the complete text content of the message generated or received by the bank's core operations during business processing. This includes all field information in the original message data and is the core communication data recording detailed information about business transactions.

[0141] It should be noted that a message field refers to an independent data unit in the original message text that is divided according to business rules. That is, a fixed position or marked area in the message that identifies different business information segments, and it is a basic component of the structured parsing of the message.

[0142] It should be noted that the message difference data refers to the difference results obtained by comparing the original messages before and after the upgrade. That is, the detailed information on the changes in the content of each field of the message before and after the upgrade. It is an important part of the operational difference data that reflects the changes in message content.

[0143] Understandably, comparing the original text of the telegram in the first version database with the original text of the telegram in the second version database according to the transaction number and the telegram type, and obtaining the telegram difference data, means using the transaction number and the telegram type as a joint index to locate the original text of the same business in the database before and after the upgrade, and then performing structured parsing on the two original texts according to their respective fields and comparing them item by item to identify the differences in the content of each field and form the difference results.

[0144] By jointly locating the original message text using the transaction number and message type, and performing a detailed comparison according to the message fields, the correctness of the upgraded message generation and parsing logic can be verified, ensuring the accuracy of cross-border and intra-industry business communication data.

[0145] Step A44: Extract account data from the report files in the first version database and compare them with the report files in the second version database to obtain the report difference data; It should be noted that report files refer to the document data of accounting or business statistical reports generated by the bank's core business during the business processing. That is, structured report files summarized by subject or business dimension, which are the core output data reflecting the bank's business operation status and financial results.

[0146] It should be noted that subject data refers to the data content in the report file that is categorized and summarized by accounting subject or business subject. That is, it is the statistical value that identifies a specific business category or accounting category and is the basic data unit that carries the core statistical information in the report file.

[0147] It should be noted that report difference data refers to the difference results obtained after comparing the subject data in the report files before and after the upgrade. That is, detailed information on the inconsistency of statistical values ​​for the same subject before and after the upgrade. It is an important part of the operational difference data that reflects changes in report data.

[0148] Understandably, extracting subject data from report files in the first version database and comparing them with report files in the second version database to obtain report difference data means extracting statistical data categorized by subject from report files before and after the upgrade, comparing the statistical values ​​of the same subject before and after the upgrade, identifying numerical differences, and forming difference results.

[0149] By extracting and comparing report data by subject, the correctness of the upgraded report generation logic and statistical rules can be verified, ensuring the accuracy of accounting reports and business statistics.

[0150] Step A45: Compare the response messages in the first version database with the response messages in the second version database to obtain the response message difference data; It should be noted that the response message refers to the data packet of processing results returned by the bank's core after receiving an external request. It is a formatted communication data containing transaction processing results, status codes, and return information. It is the core communication content for obtaining processing feedback after external interaction with the bank's core.

[0151] It should be noted that response message difference data refers to the difference results obtained by comparing response messages before and after the upgrade, that is, detailed information on changes in response message content before and after the upgrade, and is an important component of runtime difference data reflecting interface communication changes.

[0152] Understandably, comparing the response messages in the first version database with the response messages in the second version database to obtain response message difference data means comparing the response message content stored in the database before the upgrade with the corresponding response message content after the upgrade item by item to identify changes in message structure or returned information and form difference results.

[0153] By comparing the differences in the response messages, the correctness of the interface return logic after the upgrade can be verified, ensuring the consistency of the processing feedback information obtained when interacting with the bank's core operations.

[0154] Step A46: Aggregate the transaction difference data, receipt difference data, message difference data, report difference data, and response message difference data to obtain the runtime difference data.

[0155] It is understandable that aggregating transaction difference data, receipt difference data, message difference data, report difference data, and response message difference data to obtain runtime difference data means summarizing and merging the difference results of the five dimensions of transactions, receipts, messages, reports, and response messages to form a complete difference set covering all runtime data types.

[0156] By aggregating runtime difference data across five dimensions, a comprehensive summary of runtime differences is achieved, providing a complete dynamic difference foundation for the unified processing of subsequent development-state difference data.

[0157] Step S203: Aggregate the development state difference data and the runtime state difference data to obtain the initial difference data.

[0158] Understandably, aggregating development-state and runtime difference data to obtain initial difference data means summarizing and merging the static difference results obtained from development-state difference comparisons with the dynamic difference results obtained from runtime difference comparisons to form a complete difference set that simultaneously covers both static configuration and dynamic business data.

[0159] By aggregating development-state and runtime-state difference data, a unified summary of the differences between static and dynamic business data before and after the upgrade is achieved, providing a comprehensive basis for subsequent filtering based on preset ignorable conditions.

[0160] This embodiment provides a method for verifying upgrades to a bank's core system. By comparing the differences in development-state data of the database before and after the upgrade across five dimensions—field attributes, record quantity, field values, program text, and batch processing—it achieves complete identification of static configuration data and program code changes. By comparing the differences in runtime-state data across five dimensions—transactions, receipts, messages, reports, and response messages—it achieves complete identification of dynamic business data and communication interaction data. By aggregating the development-state and runtime-state difference data, initial difference data covering both static and dynamic business data is formed, providing a comprehensive data foundation for subsequent difference filtering, baseline management, and production reuse, thus improving the completeness and accuracy of difference verification for major version upgrades of the bank's core system.

[0161] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the bank core system upgrade verification method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0162] This application also provides a bank core system upgrade verification device, please refer to... Figure 4 The bank's core system upgrade verification device includes: The data acquisition module 10 is used to acquire the development state data and runtime state data of the first version database before the upgrade of the bank's core system, as well as the development state data and runtime state data of the second version database after the upgrade. The difference comparison module 20 is used to compare the development state data and runtime state data of the first version database and the second version database to obtain the initial difference data. The conditional filtering module 30 is used to filter the initial difference data according to preset ignorable conditions to obtain the difference data to be confirmed. The baseline management module 40 is used to manage the difference baselines of the difference data to be confirmed, and to obtain the difference baselines in the development and testing phase. The baseline deployment module 50 is used to deploy the difference baseline from the development and testing phase to the production phase, so that the production phase can perform difference verification based on the difference baseline from the development and testing phase. The bank core system upgrade verification device provided in this application, employing the bank core system upgrade verification method in the above embodiments, can solve the technical problem of insufficient automation in difference verification during major version upgrades of bank core systems. Compared with the prior art, the beneficial effects of the bank core system upgrade verification device provided in this application are the same as those of the bank core system upgrade verification method provided in the above embodiments, and other technical features in the bank core system upgrade verification device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0163] In one embodiment, the difference comparison module 20 is further used to perform a development-state difference comparison between the development-state data of the first version database and the development-state data of the second version database to obtain development-state difference data; The runtime differences between the runtime data of the first version database and the runtime data of the second version database are compared to obtain the runtime difference data. The initial difference data is obtained by aggregating the development-state difference data and the runtime difference data.

[0164] In one embodiment, the difference comparison module 20 is further configured to perform a difference comparison between the transaction data in the first version database and the transaction data in the second version database to obtain transaction difference data; The transaction number is used to compare the receipt text in the first version database with the receipt text in the second version database to obtain the receipt difference data. Based on the transaction number and message type, the original messages in the first version database and the original messages in the second version database are identified and compared according to the message fields to obtain message difference data. Subject data is extracted from the report files in the first version database and compared with the report files in the second version database to obtain the report difference data; The response messages in the first version database and the response messages in the second version database are compared to obtain the response message difference data. By aggregating transaction difference data, receipt difference data, message difference data, report difference data, and response message difference data, runtime difference data is obtained.

[0165] In one embodiment, the difference comparison module 20 is further used to compare the transaction data of the first version database with the transaction data of the second version database to obtain transaction quantity difference data. New transactions are identified in the transaction quantity difference data to obtain new transaction difference data; Deleted transactions are identified in the transaction quantity difference data to obtain deleted transaction difference data. The transaction content of the transaction data in the first version database is compared with that in the second version database to obtain the transaction content difference data; The newly added transaction difference data, deleted transaction difference data, and transaction content difference data are aggregated to obtain the transaction difference data.

[0166] In one embodiment, the difference comparison module 20 is further used to compare the field attributes of the development state data of the first version database and the development state data of the second version database to obtain the field attribute difference data. The number of records in the development state data of the first version database and the development state data of the second version database are compared to obtain the difference in the number of records. The field values ​​of the development data in the first version database and the development data in the second version database are compared to obtain the data on the differences in field values. The program text is compared between the development state data of the first version database and the development state data of the second version database to obtain the program text difference data. The development state data of the first version database and the development state data of the second version database are compared in batch processing to obtain batch processing difference data; The difference data in the development state is obtained by aggregating the difference data in field attributes, the difference data in the number of records, the difference data in field values, the difference data in program text, and the difference data in batch processing.

[0167] In one embodiment, the baseline management module 40 is further configured to categorize and display the difference data to be confirmed according to business modules, thereby obtaining module-categorized difference data; The module classification difference data is divided into negligible differences and differences that need to be improved; Store the negligible differences into the negligible differences database to obtain the negligible differences storage result; After the differences to be modified are modified, they are stored in the database of modified and negligible differences, and the storage result of modified and negligible differences is obtained. The negligible difference storage results are aggregated with the modified negligible difference storage results to obtain the difference baseline for the development and testing phase.

[0168] In one embodiment, the baseline deployment module 50 is also used to compare the development state data and runtime state data of the first version database and the second version database during the production phase to obtain the initial production difference data. The initial production difference data is filtered according to preset ignorable conditions to obtain the production difference data to be filtered. Based on the baseline differences during the development and testing phases, filter the production-ready difference data to obtain the production-ready-confirmation difference data. The production launch discrepancy data is categorized and displayed according to business modules, resulting in production launch module categorized discrepancy data; Send the production module's categorized difference data to the confirmation terminal for confirmation, and obtain the confirmed production difference data; The production difference verification results are generated based on the confirmed production difference data.

[0169] This application provides a bank core system upgrade verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the bank core system upgrade verification method in the above embodiment 1.

[0170] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a bank core system upgrade verification device suitable for implementing embodiments of this application. The bank core system upgrade verification device in this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The bank core system upgrade verification device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0171] like Figure 5As shown, the bank core system upgrade verification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the bank core system upgrade verification device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the bank core system upgrade verification device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a bank core system upgrade verification device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0172] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0173] The bank core system upgrade verification device provided in this application, employing the bank core system upgrade verification method in the above embodiments, can solve the technical problem of insufficient automation in difference verification during major version upgrades of bank core systems. Compared with the prior art, the beneficial effects of the bank core system upgrade verification device provided in this application are the same as those of the bank core system upgrade verification device method provided in the above embodiments, and other technical features in this bank core system upgrade verification device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0174] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0175] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0176] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the bank core system upgrade verification method in the above embodiments.

[0177] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0178] The aforementioned computer-readable storage medium may be included in the bank's core system upgrade verification equipment; or it may exist independently and not be assembled into the bank's core system upgrade verification equipment.

[0179] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the bank's core system upgrade verification device, they cause the following to occur: The development and runtime data of the first version database before the upgrade, and the development and runtime data of the second version database after the upgrade, are acquired; the development and runtime data of the first and second version databases are compared to obtain initial difference data; the initial difference data is filtered according to preset ignorable conditions to obtain difference data to be confirmed; difference baseline management is performed on the difference data to be confirmed to obtain the difference baseline for the development and testing phase; and the difference baseline for the development and testing phase is deployed to the production phase so that the production phase can perform difference verification based on the difference baseline for the development and testing phase.

[0180] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0181] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0182] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0183] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described bank core system upgrade verification method. This addresses the technical problem of insufficient automation in differential verification during major version upgrades of bank core systems. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the bank core system upgrade verification method provided in the above embodiments, and will not be elaborated upon here.

[0184] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the bank core system upgrade verification method described above.

[0185] The computer program product provided in this application can solve the technical problem of insufficient automation in the difference verification during major version upgrades of bank core systems. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the bank core system upgrade verification method provided in the above embodiments, and will not be repeated here.

[0186] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A bank core system upgrade verification method, characterized by, The bank core system upgrade verification method includes: Obtain the development and runtime data of the first version database before the upgrade of the bank's core system, as well as the development and runtime data of the second version database after the upgrade; The development state data and the runtime state data of the first version database and the second version database are compared to obtain initial difference data; The initial difference data is filtered according to a preset ignorable condition to obtain the difference data to be confirmed; The difference data to be confirmed is managed to obtain the difference baseline for the development and testing phase. The development and testing phase difference baseline is deployed to the production phase so that the production phase can perform difference verification based on the development and testing phase difference baseline.

2. The method as described in claim 1, characterized in that, The step of comparing the development state data and the runtime state data of the first version database and the second version database to obtain initial difference data includes: The development state data of the first version database and the development state data of the second version database are compared to obtain development state difference data. The runtime data of the first version database and the runtime data of the second version database are compared to obtain runtime difference data. The development-state difference data and the runtime difference data are aggregated to obtain the initial difference data.

3. The method as described in claim 2, characterized in that, The runtime data includes transaction data, receipt text, original message text, report files, and response messages. The step of comparing the runtime data of the first version database with the runtime data of the second version database to obtain runtime difference data includes: The transaction data in the first version database and the transaction data in the second version database are compared to obtain transaction difference data; The transaction order text in the first version database and the transaction order text in the second version database are compared based on the transaction number to obtain transaction order difference data. Based on the transaction number and message type, the original message text in the first version database and the original message text in the second version database are identified and compared according to the message field to obtain message difference data; Subject data is extracted from the report files in the first version database and compared with the report files in the second version database to obtain report difference data; The response messages in the first version database and the response messages in the second version database are compared to obtain response message difference data. The transaction difference data, the receipt difference data, the message difference data, the report difference data, and the response message difference data are aggregated to obtain the runtime difference data.

4. The method as described in claim 3, characterized in that, The step of comparing the transaction data in the first version database with the transaction data in the second version database to obtain transaction difference data includes: The transaction data in the first version database is compared with the transaction data in the second version database to obtain the transaction quantity difference data; New transactions are identified in the transaction quantity difference data to obtain new transaction difference data; The deleted transactions are identified in the transaction quantity difference data to obtain the deleted transaction difference data. The transaction data in the first version database and the transaction data in the second version database are compared in terms of transaction content to obtain transaction content difference data; The newly added transaction difference data, the deleted transaction difference data, and the transaction content difference data are aggregated to obtain transaction difference data.

5. The method as described in claim 2, characterized in that, The step of comparing the development-state data of the first version database with the development-state data of the second version database to obtain development-state difference data includes: The development state data of the first version database and the development state data of the second version database are compared by field attributes to obtain the field attribute difference data; The number of records in the development state data of the first version database and the development state data of the second version database are compared to obtain the difference in the number of records. The field values ​​of the development state data in the first version database and the development state data in the second version database are compared to obtain the field value difference data; The program text is compared between the development state data of the first version database and the development state data of the second version database to obtain program text difference data; The development state data of the first version database and the development state data of the second version database are compared in batch processing to obtain batch processing difference data; The difference data of the field attributes, the difference data of the number of records, the difference data of the field values, the difference data of the program text, and the difference data of the batch processing are aggregated to obtain the development state difference data.

6. The method as described in claim 1, characterized in that, The step of performing difference baseline management on the difference data to be confirmed to obtain the difference baseline for the development and testing phase includes: The discrepancy data to be confirmed is categorized and displayed according to business modules to obtain module-categorized discrepancy data; The module-specific difference data is divided into negligible differences and differences requiring modification. The negligible differences are stored in the negligible difference database to obtain the negligible difference storage result; The differences to be modified are modified and then stored in the database of negligible differences, resulting in the storage result of negligible differences. The negligible difference storage results are aggregated with the modified negligible difference storage results to obtain the difference baseline for the development and testing phase.

7. The method as described in claim 1, characterized in that, The step of deploying the development and testing phase difference baseline to the production phase, so that the production phase can perform difference verification based on the development and testing phase difference baseline, includes: The development state data and the running state data of the first version database and the second version database in the production stage are compared to obtain the initial production difference data. The initial production difference data is filtered according to the preset ignorable conditions to obtain the production difference data to be filtered. The production-ready difference data is filtered based on the development and testing phase difference baseline to obtain the production-ready-confirmation difference data. The production-to-be-confirmed discrepancy data is categorized and displayed according to the business module to obtain the production module-categorized discrepancy data. The production module categorizes the difference data and sends it to the confirmation terminal for confirmation, and the confirmed production difference data is obtained. Based on the confirmed production discrepancy data, a production discrepancy verification result is generated.

8. A device for verifying differences in upgrades to a bank's core system, characterized in that, The device includes: The data acquisition module is used to acquire the development and runtime data of the first version database before the upgrade of the bank's core system, as well as the development and runtime data of the second version database after the upgrade. The difference comparison module is used to compare the development state data and the running state data of the first version database and the second version database to obtain initial difference data. The conditional filtering module is used to filter the initial difference data according to preset ignorable conditions to obtain the difference data to be confirmed. The baseline management module is used to manage the difference baselines of the difference data to be confirmed, and to obtain the difference baselines for the development and testing phase. The baseline deployment module is used to deploy the development and testing phase difference baseline to the production phase, so that the production phase can perform difference verification based on the development and testing phase difference baseline.

9. A bank core system upgrade verification device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the bank core system upgrade verification method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the bank core system upgrade verification method as described in any one of claims 1 to 7.

Images