Data calling method, apparatus, device, medium and program product

Abstract

This application provides a data retrieval method, apparatus, device, medium, and program product, which can be applied to the distributed system and fintech fields. The method includes: verifying the caller in response to the caller uploading the name and retrieval parameters of a stored routine through a general service interface; obtaining the name and retrieval parameters of the stored routine in response to the caller passing the verification, and querying the data processing type and data belonging group based on the name of the stored routine; forwarding the retrieval parameters and data processing type to the group database corresponding to the data belonging group based on a database flow-switching mechanism, and calling the group database to execute the data processing operation corresponding to the stored routine; and obtaining and processing the execution result from the group database to obtain the retrieval result, and returning the retrieval result to the caller.

Description

Technical Field

[0001] This application relates to the fields of distributed systems and financial technology, and more specifically to a data retrieval method, apparatus, device, medium, and program product. Background Technology

[0002] With the development of information technology application innovation and transformation (IT innovation transformation) in the financial industry, corporate online banking (corporate online banking), as a core service channel for corporate clients, directly impacts business stability and customer experience through its underlying architecture upgrades. As platform-based group decoupling and separation progresses, data interoperability and process collaboration between applications become fundamental to supporting complex corporate transactions. Stable data access is crucial for ensuring the continuous operation of core businesses such as payment approval, account management, and fund settlement, directly affecting system performance, development efficiency, and maintenance costs. Efficient and secure data access is a core element in reducing cross-database interaction overhead, simplifying interface management, and ensuring data consistency and security.

[0003] During the transformation of enterprise online banking with information technology innovation, various split groups and external applications involve multi-party data interaction and processing in business processes. Currently, data calls between multiple applications are mainly achieved using database links and independent atomic interfaces. Cross-database access via database links increases database load, complicates permission and security management, and results in a large number of independent atomic interfaces, lengthy call chains, and a lack of unified orchestration. Therefore, the existing data call solution lacks a general service mechanism, has poor versatility and standardization, weak reusability and scalability, and is difficult to adapt to the multi-application scenarios after splitting and decoupling, failing to meet the needs of complex business scenarios and significantly reducing system iteration efficiency and operational efficiency. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a data retrieval method, apparatus, device, medium, and program product.

[0005] According to a first aspect of this application, a data retrieval method is provided, comprising: verifying the caller in response to the caller uploading the name of a stored routine and retrieval parameters through a general service interface; obtaining the name of the stored routine and the retrieval parameters in response to the caller passing the verification, and querying the data processing type and data belonging group based on the name of the stored routine; forwarding the retrieval parameters and the data processing type to the group database corresponding to the data belonging group based on a database flow switching mechanism, and retrieval the group database to execute the data processing operation corresponding to the stored routine; and obtaining and processing the execution result of the group database to obtain a retrieval result, and returning the retrieval result to the caller.

[0006] According to an embodiment of this application, the method further includes: if the obtained execution result is execution failure, extracting the data processing type corresponding to the failed storage routine, determining the exception handling type; and performing exception handling operations based on the exception handling type.

[0007] According to an embodiment of this application, the anomaly handling operation includes a data rollback operation and / or a fallback push operation. The execution of the anomaly handling operation based on the anomaly handling type includes: when the anomaly handling type is maintenance-related, identifying the maintenance data attributes of the failed storage routine based on a first whitelist; if the maintenance data attribute is sensitive data or time-constrained data, then performing the data rollback operation; if the maintenance data attribute is non-time-constrained data, then performing the fallback push operation.

[0008] According to an embodiment of this application, forwarding the call parameters and the data processing type to the group database corresponding to the data's home group includes: obtaining the dependencies of the table execution statements in the stored routine, determining the group dependencies, and splitting the table operation logic of the stored routine; if the group dependency is no dependency, then according to the split table operation logic, asynchronously forwarding the call parameters and the data processing type to the group database corresponding to the data's home group; if the group dependency is a sequential dependency, then according to the dependency order corresponding to the split table operation logic, synchronously forwarding the call parameters and the data processing type to the group database corresponding to the data's home group.

[0009] According to an embodiment of this application, invoking the group database includes: invoking the corresponding database access interface based on a distributed service framework; and synchronously or asynchronously invoking the group database through the database access interface.

[0010] According to an embodiment of this application, the database flow-switching mechanism includes: configuring a second whitelist; and forwarding data to the group database according to preset flow-switching rules based on the flow-switching parameters of the second whitelist; the preset flow-switching rules include at least one of no flow-switching, one-time flow-switching, region flow-switching, card number flow-switching, transaction instruction word flow-switching, and table dimension split flow-switching.

[0011] According to an embodiment of this application, the verification of the caller includes: receiving the authentication result of the caller; wherein the authentication result is obtained by verifying the data signature of the caller through an authentication platform; reading the configuration file, verifying the function access permission of the caller, and obtaining an access verification result; and if both the authentication result and the access verification result are passed, then the caller passes the verification.

[0012] According to a second aspect of this application, a data retrieval apparatus is provided, comprising: a verification module, configured to verify the caller in response to the caller uploading the name of a stored routine and the call parameters through a general service interface; a query module, configured to obtain the name of the stored routine and the call parameters in response to the caller passing the verification, and query the data processing type and data belonging group based on the name of the stored routine; a data operation module, configured to forward the call parameters and the data processing type to the group database corresponding to the data belonging group based on a database flow switching mechanism, and invoke the group database to execute the data processing operation corresponding to the stored routine; and a result return module, configured to obtain and process the execution result of the group database to obtain the retrieval result, and return the retrieval result to the caller.

[0013] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0014] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0015] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0016] In the embodiments of this application, various groups, external applications, and other callers upload data uniformly through a common service interface. This interface can receive multi-source call requests and then verify the callers, achieving standardization and normalization of data calls. Based on the stored routine name, the data processing type and its associated group are matched, and combined with a database flow-switching mechanism, the data is accurately forwarded to the corresponding group database for execution. This eliminates the need for callers to access other group databases across databases, avoiding load and permission issues associated with cross-database access and simplifying interface management. The unified orchestration of the data call process constructs a common service mechanism, reducing lengthy call chains, improving data reusability and scalability, ensuring continuous operation of core businesses, reducing system development, iteration, and maintenance costs, and adapting to the complex multi-application scenarios after the decoupling of enterprise online banking, significantly improving system performance and operating efficiency. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1The illustrations depict application scenarios of data retrieval methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a data retrieval method according to an embodiment of this application is shown schematically.

[0020] Figure 3 This illustration schematically shows a database retrieval flowchart of a data retrieval method according to an embodiment of this application;

[0021] Figure 4 A flowchart illustrating a multi-group database retrieval method according to an embodiment of this application is shown.

[0022] Figure 5 This schematic diagram illustrates a structural block diagram of a data retrieval apparatus according to an embodiment of the present application;

[0023] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a data retrieval method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a rule having at least one of A, B and C" should include, but is not limited to, a rule having only A, only B, only C, having A and B, having A and C, having B and C, and / or a rule having A, B and C, etc.).

[0028] The following will explain and clarify the terms used in this article.

[0029] Corporate online banking: A financial service platform provided by commercial banks to corporate clients based on internet channels, supporting enterprises to conduct banking business such as account management, fund settlement, investment and financing, and trade finance through dedicated network channels.

[0030] Information technology innovation transformation: In order to break through the dependence on key technologies, organizations are undergoing a strategic transformation process to achieve full-stack autonomy and control over information systems through domestic technology substitution (basic hardware, basic software, application software) and technology system reconstruction (distributed architecture).

[0031] Electronic Banking Internal Management System (Internal Management System): A back-end management platform used by financial institutions to configure, monitor, and maintain electronic banking services, covering functional modules such as user access management, transaction risk control, system parameter configuration, and audit log tracking.

[0032] General Services: During the IT innovation transformation phase, corporate online banking provides a comprehensive service mechanism for corporate online banking platform groups and internal electronic banking management systems, including stored procedure execution, corporate online banking data query, maintenance, access checks, and forwarding.

[0033] Stored routines (stored procedures): A set of structured query statements pre-compiled and stored in the database server, used to encapsulate high-frequency business logic and perform complex database operations.

[0034] Interface: A standardized communication protocol agreed upon between systems to achieve data exchange or service calls, including technical specifications, data format, transmission mechanism and security requirements.

[0035] At this crucial stage of banks' comprehensive transformation towards information technology innovation, corporate online banking is a vital channel for serving core corporate clients, making the optimization and upgrading of its underlying architecture essential. During this transformation, a prominent technical pain point has gradually emerged: significant dependencies exist between applications in terms of business processes and data. The platform-based decoupling and splitting of corporate online banking during the information technology innovation transformation has exacerbated the difficulty of data acquisition and maintenance.

[0036] For the multiple application groups after decomposition, the following methods are currently used to realize data access and interoperability: (1) cross-database access through database links; (2) each application group provides independent atomic interfaces for callers to query and maintain data; (3) synchronize the data tables of each application to the transaction database through real-time data synchronization.

[0037] However, cross-database access via database links significantly increases database load and network overhead, especially when processing complex transactions involving multiple databases, where performance degradation and latency issues become prominent. Furthermore, the need to configure and manage cross-database access permissions increases the complexity of permission management and the difficulty of security auditing, leading to more potential security risks.

[0038] Each data request in a transaction corresponds to an independent atomic interface, which leads to a rapid increase in the number of interfaces. This makes interface registration, development, version control, and access control difficult. Completing a complete business transaction (such as a payment approval process) often requires the client or service layer to continuously call multiple single-function interfaces. The call chain is lengthy and fragile, increasing the probability of errors and debugging difficulty. Although atomic interfaces have clear intent, actual business scenarios often require combined logic, causing the client or middleware layer to bear too much orchestration responsibility, resulting in code duplication and difficulty in maintenance.

[0039] Real-time data synchronization of application data tables to the trading party's database has the following drawbacks: Data synchronization is delayed, potentially resulting in the trading party receiving outdated data, impacting the timeliness of business decisions; network interruptions or system failures during synchronization can easily lead to data inconsistencies, increasing data repair and verification costs; synchronizing full table data consumes significant storage space and bandwidth resources, especially with large data volumes, significantly increasing operational costs; furthermore, the trading party needs to maintain a complete copy of the synchronized data, posing a risk of sensitive data leakage and increasing the complexity of data security management.

[0040] This application provides a data retrieval method. In response to a caller uploading the name and retrieval parameters of a stored routine via a general service interface, the caller is verified. Upon successful verification, the caller obtains the name and retrieval parameters of the stored routine and queries the data processing type and data group based on the stored routine name. Using a database flow-switching mechanism, the call parameters and data processing type are forwarded to the group database corresponding to the data group, and the group database is invoked to execute the data processing operation corresponding to the stored routine. The execution result from the group database is obtained and processed to obtain the retrieval result, which is then returned to the caller. In this application, various groups and external applications upload data uniformly through a general service interface, enabling the reception of multi-source retrieval requests. Verification of the caller then achieves standardization and normalization of data retrieval. Matching the data processing type and group based on the stored routine name, combined with the database flow-switching mechanism, accurately forwards the data to the corresponding group database for execution. This eliminates the need for the caller to access other group databases across databases, avoiding the load and permission issues associated with cross-database access and simplifying interface management. The unified orchestration of data call processes has built a general service mechanism, reduced lengthy call chains, improved data reusability and scalability, ensured the continuous operation of core businesses, reduced system development, iteration and maintenance costs, adapted to the complex multi-application scenarios after the decoupling of enterprise online banking, and significantly improved system performance and operating efficiency.

[0041] In the technical solution of this application, the caller / user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0042] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0043] Figure 1 The illustrations depict application scenarios of data retrieval methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0044] like Figure 1As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101 and the second terminal device 102 to interact with the server 105 and / or the database 103 through the network 104 to receive or send information, etc.

[0045] The first terminal device 101 and the second terminal device 102 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal device. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, including but not limited to applications, mini-programs, etc., installed on the terminal device, and can also be in web page form.

[0046] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101 and the second terminal device 102 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data. The server can be a backend server for the aforementioned target application, used to provide backend services to the clients of the target application.

[0047] Database 103 is a professional storage system for storing and managing data. It can store various types of data related to the target application, such as user account information, business transaction records, and content resource data. It supports structured, semi-structured, or unstructured data storage and has management capabilities such as adding, deleting, modifying, querying, backing up, and restoring data. In this application scenario, database 103 can be connected to server 105 via a communication link. Server 104 can retrieve the required data from database 103 for processing based on requests from the first terminal device 101 and the second terminal device 102. It can also synchronously store new data generated by the operations of the first terminal device 101 and the second terminal device 102 into database 103, thereby achieving data persistence and efficient retrieval.

[0048] It should be noted that the data retrieval method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-102. Accordingly, the data retrieval device provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-102.

[0049] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0050] Figure 2 A flowchart illustrating a data retrieval method according to an embodiment of this application is shown. Figure 2 As shown, the data retrieval method 200 according to an embodiment of this application may include steps S210 to S240. This data retrieval method is applied to a general service of corporate online banking, and a general service based on an integrated service mechanism is built in corporate online banking. The core objective of this general service is to eliminate cross-database link calls, integrate atomic single-function interfaces, provide more coarse-grained service capabilities with richer business semantics, and integrate a unified service mechanism that includes stored routine (stored procedure) execution, corporate online banking data query, maintenance, access checks, and forwarding.

[0051] In step S210, in response to the caller uploading the name of the stored routine and the calling parameters through the general service interface, the caller is verified.

[0052] Various callers, including enterprise online banking groups, internal e-banking management systems (internal management systems), and external applications, can invoke the corresponding general service interface by initiating a call request and uploading call parameters and the name of the stored routine. The general service provides a common program for enterprise online banking and internal management systems to call the interface. Callers only need to reference the common method, configure the name of the stored routine (stored procedure name), and send the call parameters. The common program can then call the general service interface via DSF (Distributed Service Framework). The general service interface has a unified format (stored routine name + sent parameters) and flexible input parameter format (no restrictions on the type, length, or number of sent parameters, but they must conform to the stored routine requirements). Callers can quickly access the interface through the common program. During the information technology innovation transformation, hundreds of external departments can access the stored routine, handling hundreds of cross-platform departmental transaction processes.

[0053] Upon receiving the name of a stored routine and its call parameters uploaded by a caller through the unified general service interface, the general service immediately initiates a verification process for that caller. The verification covers dimensions such as identity legitimacy, interface access permissions, and data access scope, while also verifying the integrity and format compliance of the request message. A verification log is generated synchronously during the verification process, recording the request source, time, and verification node status. If verification fails, the corresponding call request is immediately intercepted, and an exception message such as insufficient permissions or invalid identity is returned, rejecting further data processing. If verification passes, the request is marked as legitimate and automatically proceeds to the next processing stage, ensuring that only compliant callers can enter the data access process and guaranteeing access security.

[0054] It's worth noting that the caller is the entity initiating the data call request. This includes various business groups within the corporate online banking system, external partner systems, internal management systems, and other systems / applications that need to access corporate network data or perform data operations. The general service interface is the unified access point provided by the general service, serving as a bridge for interaction between the caller and the general service. All callers upload requests and receive results through this interface, standardizing the access method. The name of the stored routine, or stored procedure name, is a unique identifier for the pre-compiled data processing logic in the database. By specifying this name, the caller informs the general service of the specific database operation logic to be executed. Call parameters are the business data parameters uploaded by the caller to the general service. These are the input information required for the stored routine to execute, supporting the stored procedure in completing data querying, maintenance, and other operations.

[0055] In step S220, in response to the caller passing the verification, the name of the stored routine and the calling parameters are obtained, and the data processing type and data belonging group are queried based on the name of the stored routine.

[0056] After confirming the caller's verification, the general service accurately extracts the name of the stored routine and its corresponding call parameters from the request message of the general service interface, completes parameter parsing and format standardization conversion, and eliminates invalid and redundant data. Using the stored routine name as the sole search condition, a precise query is initiated in the whitelist configuration library built into the general service to match preset configuration information. The whitelist pre-stores the associated configurations of all authorized stored routines, quickly identifying the corresponding data processing type through name matching, clarifying whether the current request is a data query, data maintenance, or data update operation, and determining the data belonging group corresponding to the stored routine, distinguishing between the enterprise online banking platform group, internal management system group, and external application group. The query process synchronously records configuration matching logs. If no corresponding configuration is found, the stored routine is deemed invalid, the process terminates, and an exception is returned; if the query is successful, the processing type and belonging group information are encapsulated to provide a basis for subsequent forwarding operations.

[0057] It's worth noting that the data processing type represents the operation category configured in the general service whitelist, identifying the execution purpose of the current stored routine. It is mainly divided into query (data reading) and maintenance (data addition, modification, deletion), etc. The data ownership group refers to the business management entity to which the data belongs, corresponding to different business groups such as the enterprise online banking platform group and the electronic banking internal management system, clearly defining the data's management permissions and business scope. The group database is a platform-based database, serving as the dedicated database for each data ownership group. It stores the business data of the corresponding group and is the database carrier for the stored routine to ultimately execute data operations.

[0058] In step S230, based on the database flow switching mechanism, the call parameters and data processing type are forwarded to the group database corresponding to the data belonging group, and the group database is called to execute the data processing operation corresponding to the stored routine.

[0059] After obtaining the data processing type and data group, the general service initiates a database traffic switching mechanism. Based on the group identifier, it matches the corresponding routing rules to achieve precise distribution of request traffic. The call parameters and data processing type are encapsulated and forwarded synchronously / asynchronously to the dedicated group database of the data group according to the group's corresponding routing address. The forwarding process follows the domestic IT innovation transformation adaptation specifications, ensuring the stability and compatibility of cross-platform and cross-group data transmission. The general service provides unified maintenance, management, and logging for data forwarding between external application requests for enterprise network data and various groups within the enterprise online banking system, enabling controlled access, real-time monitoring, and traceable data access.

[0060] Once data arrives at the group database, the general service triggers stored routine execution instructions, driving the database to perform corresponding operations based on the data processing type: query operations invoke database query logic, while maintenance operations execute data addition, modification, deletion, and other maintenance logic, strictly following the stored routine's preset logic. During execution, the running status is monitored in real time, ensuring data consistency when handling cross-platform transactions, and execution node logs are recorded synchronously for easy operation traceability.

[0061] It's worth noting that the execution result of the group database is the raw result returned after the group database completes the stored routine, such as the dataset for query-type operations, the operation status for maintenance-type operations, and the number of data rows affected. The call result, on the other hand, is the standardized response data returned to the caller after the general service performs format concatenation, normalization, and standardization on the raw database execution results; this is the final processing result received by the caller.

[0062] According to an embodiment of this application, the database flow-switching mechanism includes: configuring a second whitelist; and forwarding data to the group database according to preset flow-switching rules based on the flow-switching parameters of the second whitelist; the preset flow-switching rules include at least one of no flow-switching, one-time flow-switching, region flow-switching, card number flow-switching, transaction instruction word flow-switching, and table dimension split flow-switching.

[0063] After completing caller verification and determining the data's group affiliation, the general service initiates the database traffic switching mechanism. First, using the stored routine name as an index, it precisely extracts the corresponding traffic switching parameters from the second whitelist, determines the type of traffic switching rule to be executed, and then forwards the corresponding stored routine, call parameters, and other data to the corresponding group database according to the traffic switching rule. The general service supports multi-type, batch-based new and old database traffic switching mechanisms. Groups with different progress in domestic IT innovation can perform batch-based database traffic switching by configuring the second whitelist without affecting each other.

[0064] It's worth noting that the second whitelist is a fine-grained configuration list specifically built by the general service for database traffic switching scenarios. It includes key configuration items such as the stored instance name, its group affiliation, traffic switching parameter type (no traffic switching / one-time traffic switching, etc.), traffic switching matching rules (region code, card number, command word, etc.), and the traffic switching progress of each table. The second whitelist is the core basis for distinguishing different traffic switching methods and implementing batch traffic switching. It can be configured independently for groups with different progress in domestic IT innovation, ensuring that traffic switching operations in each group do not affect each other.

[0065] The general service supports the following preset traffic switching rules:

[0066] No flow switching: If the whitelist flow switching parameter is configured to 0, the flow will be forwarded to the relational database to execute the stored routine.

[0067] One-time traffic switching: When the whitelist traffic switching parameter is configured to 1, the execution of the stored routine will be directly forwarded to the distributed relational database to execute the stored routine.

[0068] Region-based traffic switching: Traffic is switched based on region. Configure the whitelist traffic switching parameter to region-based switching, and append the region code to the parameter. Check the region of the account executing the transaction. Transactions matching the region's region are forwarded to the distributed relational database for execution of the stored routine; otherwise, they are forwarded to the relational database for execution of the stored routine.

[0069] Card Number-Based Traffic Switching: Traffic is switched based on the card number. Configure the whitelist traffic switching parameter to card number-based switching, appending the card number or its last two digits to the parameter. Check the card number of the account calling the transaction execution to determine if it meets the traffic switching criteria. If the criteria are met, forward the transaction to a distributed relational database for execution of the stored routine; otherwise, forward it to the relational database for execution of the stored routine.

[0070] Transaction command word flow switching: Flow switching is performed according to the transaction command word. Configure the whitelist flow switching parameter as command word flow switching and append the command word after the parameter. Each transaction has an independent command word. Transactions with configured command words will be forwarded to the distributed relational database to execute stored routines, while those without configured command words will still be executed in the relational database.

[0071] Table-based splitting and flow control: Flow control is split according to table dimensions. When a storage instance performs operations on multiple tables or tables from multiple departments, the flow control progress of the tables can be configured in a whitelist. For example, only O (switching only to the old cluster), double write G based on O (based on the old cluster, double write traffic to the new cluster), double write O based on G (based on the new cluster, double write traffic to the old cluster), only G (switching only to the new cluster), etc. When executing the storage instance, the operations on the tables can be performed in the corresponding database according to the flow control progress of the tables.

[0072] In the embodiments of this application, by configuring a second whitelist and according to its flow-cutting parameters, database flow-cutting and forwarding are performed according to various flow-cutting rules. It supports multiple flexible flow-cutting methods such as no flow-cutting and one-time flow-cutting, realizing fine-grained control of data forwarding. The flow-cutting strategy can be flexibly adjusted according to business needs, avoiding cross-database interaction, improving system stability and operational flexibility, and meeting the data call needs of multiple scenarios.

[0073] In step S240, the execution result of the group database is obtained and processed to obtain the call result, and the call result is returned to the caller.

[0074] After the group database completes the stored routine, the general service receives the raw execution results returned by the database in real time and performs result processing actions according to different data processing types. Query operations extract the dataset and perform formatting and field concatenation; maintenance operations extract result information such as execution status and the number of affected data rows, and encapsulate and format the results according to a unified response standard to form standardized call results. During processing, the integrity and accuracy of the results are verified, and abnormal results are marked and logged. After the execution result processing is completed, it is returned to the caller through the general service interface. The return process ensures data transmission security, synchronously generates a complete operation log, records the entire request process information, and achieves traceability of data calls. The returned call results are compatible with the caller's access format, requiring no additional adaptation from the caller, ensuring that the caller can quickly receive and parse the call results, completing the entire standardized data call closed loop.

[0075] In the embodiments of this application, various groups, external applications, and other callers upload data uniformly through a common service interface. This interface can receive multi-source call requests and then verify the callers, achieving standardization and normalization of data calls. Based on the stored routine name, the data processing type and its associated group are matched, and combined with a database flow-switching mechanism, the data is accurately forwarded to the corresponding group database for execution. This eliminates the need for callers to access other group databases across databases, avoiding load and permission issues associated with cross-database access and simplifying interface management. The unified orchestration of the data call process and the construction of a common service mechanism reduce lengthy call chains, improve data reusability and scalability, ensure continuous operation of core businesses, reduce system development, iteration, and maintenance costs, and adapt to the complex multi-application scenarios after the decoupling of enterprise online banking, significantly improving system performance and operating efficiency.

[0076] According to an embodiment of this application, the verification of the caller includes: receiving the caller's authentication result; wherein the authentication result is obtained by verifying the caller's data signature through an authentication platform; reading the configuration file, verifying the caller's function access permissions, and obtaining an access verification result; and if both the authentication result and the access verification result are passed, the caller passes the verification.

[0077] Upon receiving the stored routine name and calling parameters uploaded by the caller, the general service immediately initiates a two-layer verification process. First, it receives the caller's authentication result synchronously pushed by the intermediate authentication platform. This result is verified by the authentication platform based on the caller's private key signature. The caller then uses its private key to sign the uploaded data (stored routine name and calling parameters) and the request message. The intermediate authentication platform verifies the signature to complete authentication. The authentication platform extracts the digital signature of the caller's uploaded data and request message, and verifies the integrity and validity of the signature by matching it with the caller's public key to decrypt it. This confirms that the caller's identity has not been tampered with and that they are a legitimate entity. The general service only receives standardized authentication results, such as authentication passed / failed.

[0078] Subsequently, the general service reads the locally preset function access configuration file. This file, indexed by the caller's unique identifier, stores a list of authorized interface functions for each caller, access scope of stored routines, and other permission information. After parsing the configuration file, it verifies whether the interface function requested by the current caller is within its authorized list and generates an access verification result. Finally, a dual result judgment is performed: if both the identity verification result and the access verification result are "passed," the caller is deemed to have passed the verification, and subsequent data acquisition and query actions are automatically performed; if either result is "failed," the process is immediately terminated, a verification failure message containing the specific failure reason (invalid identity / unauthorized function) is returned to the caller, and a complete verification log is recorded to ensure that only legitimate callers with the corresponding permissions can proceed to the next step.

[0079] In the embodiments of this application, the identity verification of the caller is completed by verifying the data signature of the caller through the authentication platform, and the identity verification result is obtained. Then, the access permission of the function is checked by reading the configuration file. The dual verification ensures that the caller's identity is legitimate and the permissions are compliant, effectively blocking illegal access and unauthorized operations, and ensuring the security of data access.

[0080] According to an embodiment of this application, after obtaining the execution result of the group database, the data calling method further includes: if the obtained execution result is an execution failure, extracting the data processing type corresponding to the storage routine that failed to execute, determining the exception handling type; and performing exception handling operations based on the exception handling type.

[0081] After obtaining the execution results returned by each group database, the general service parses the execution result status. If an execution failure indicator is identified (such as operation timeout, data conflict, etc.), an exception handling mechanism is immediately initiated. Specifically, first, the data processing type (such as query or maintenance) corresponding to the failed stored routine is extracted. Combined with a pre-defined exception handling rule base, the corresponding exception handling type is determined. If only maintenance-type execution fails, differentiated exception handling (such as rollback or fallback operation) is triggered. If query-type execution fails, a standardized failure response is directly generated, only returning a failure message and logging it, without performing rollback or fallback operations. During the exception handling process, it is also necessary to record log information such as the failure reason, execution node, and exception code, making all failure data traceable and providing data for subsequent troubleshooting.

[0082] In the embodiments of this application, when the database fails to execute, the data processing type is automatically extracted and the exception handling type is determined, and then the corresponding handling operation is performed to quickly handle the exception situation, avoid the abnormal call state from continuously affecting the business, and ensure the stability and continuity of the data call process.

[0083] According to embodiments of this application, the exception handling operation includes a data rollback operation and / or a fallback push operation. The exception handling operation is performed based on the exception handling type, including: if the exception handling type is maintenance type, identifying the maintenance data attributes of the failed storage routine based on a first whitelist; if the maintenance data attribute is sensitive data or time-constrained data, then performing a data rollback operation; if the maintenance data attribute is non-time-constrained data, then performing a fallback push operation.

[0084] After the exception handling type is determined to be maintenance-related, the general service uses a first whitelist and the name of the failed stored routine as an index to accurately match the corresponding maintenance data attributes (such as sensitive, time-constrained, and non-time-constrained). If sensitive data or time-constrained data (data with time requirements) is identified, a data rollback operation is immediately executed. For example, a three-stage transaction mode is used to process the data step by step. First, the pre-operation results of the attempt phase are traced back to confirm that the data has not been irreversibly modified. If the execution of the commit phase fails, a rollback operation is triggered to restore the data to its pre-operation state according to the preset rollback rules. The entire rollback process records the rollback nodes and data change trajectory to ensure data consistency.

[0085] If the data is identified as non-time-sensitive (low-time-sensitivity or non-time-sensitivity), the general service performs a fallback push operation. For example, the information of the failed maintenance operation (storage routine name, call parameters, and failure reason) is encapsulated into a standardized message and pushed to a designated message queue topic through a message queue. The platform department listens to the message queue topic to retrieve the exception information and re-executes the corresponding maintenance operation according to the attribution table dimension. The general service continuously monitors the execution status of the fallback operation until the operation is successful or the preset retry limit is reached. At the same time, it records the fallback push time, retrieval status, re-execution results, and other full-process logs to ensure the eventual consistency of non-time-sensitive data.

[0086] It is worth noting that the first whitelist is a fine-grained control list for maintenance storage routines in the general service. In addition to the basic storage routine name and its group, it also includes multi-dimensional information such as maintenance data attribute tags (sensitive, time-sensitive, non-time-sensitive), exception handling rules, data rollback trigger conditions, and fallback push configuration.

[0087] In the embodiments of this application, for maintenance-related anomalies, the maintenance data attributes of stored routines are accurately identified through a whitelist. Data rollback is performed on sensitive and time-constrained data to ensure data security and consistency. For non-time-constrained data, fallback push is performed to ensure that business processes are not interrupted. This achieves refined and intelligent anomaly handling, taking into account both data security and business continuity, and improving system fault tolerance and operational efficiency.

[0088] According to an embodiment of this application, forwarding call parameters and data processing types to the group database corresponding to the data's home group includes: obtaining the dependencies of table execution statements in the stored routine, determining the group dependencies, and splitting the table operation logic of the stored routine; if the group dependency is no dependency, then according to the split table operation logic, the call parameters and data processing types are asynchronously forwarded to the group database corresponding to the data's home group; if the group dependency is a sequential dependency, then according to the dependency order corresponding to the split table operation logic, the call parameters and data processing types are synchronously forwarded to the group database corresponding to the data's home group.

[0089] After obtaining the data's group and processing type, the general service parses and forwards the stored routine. Specifically, it first decomposes the complete execution logic of the stored routine, extracting all execution statements involving group tables. Using pre-defined syntax parsing rules, it identifies the relationships between the execution statements of each table, focusing on verifying for data transitive dependencies (e.g., the execution of a later table requires referencing the query results of a previous table) and execution sequence dependencies (e.g., table A must be inserted before table B can be updated). This determines the group dependencies (no dependency / sequential dependency) for each table. Simultaneously, according to the different groups to which the tables belong, the original stored routine is split into multiple independent table operation logic units. Each unit contains only the execution instructions for the corresponding group tables and retains the original call parameter adaptation logic.

[0090] If the group dependency is determined to be independent, the general service uses an asynchronous forwarding mechanism to distribute the split table operation logic units, call parameters and data processing types to the databases of the corresponding groups. Each group database executes the split storage routine fragments independently without waiting for the execution results of other groups. The general service only needs to monitor the execution status of each asynchronous task to achieve parallel processing and improve efficiency.

[0091] If a group dependency is determined to be sequential, the general service strictly follows the parsed dependency order, synchronously forwarding the split table operation logic units, call parameters, and data processing types to the corresponding group databases. After the previous group database completes execution and returns results, the forwarding and execution process of the next group database is triggered. After all group databases have completed execution, the general service summarizes the execution results of each stage and completes the result splicing according to preset rules to ensure that it meets the execution logic and data output requirements of the stored routine.

[0092] In the embodiments of this application, by analyzing the table execution statement dependencies of stored routines and decomposing table operation logic, differentiated data forwarding processing is achieved. Asynchronous forwarding is performed when there are no dependencies, improving concurrent processing efficiency; synchronous forwarding is performed when there are sequential dependencies, ensuring the consistency and accuracy of data operations, realizing a general forwarding service, effectively optimizing the data call process, reducing cross-database interaction overhead, and improving system performance and business processing stability.

[0093] Figure 3 A schematic diagram illustrates a database retrieval flowchart of a data retrieval method according to an embodiment of this application. For example... Figure 3 As shown, calling the group database includes steps S310 to S320.

[0094] In step S310, the corresponding database access interface is called based on the distributed service framework.

[0095] After determining the group database to be invoked, the general service matches the standardized access interface address, interface protocol, and invocation rules corresponding to that group database from the preset interface mapping configuration library, based on the data's group identifier and data processing type. Subsequently, it initializes the DSF invocation client, completing the framework parameter configuration, such as setting core parameters like the service registry address, invocation timeout, retry mechanism, and data transmission encryption rules, ensuring compliance with the technical specifications for enterprise network information technology innovation transformation. After configuration, the DSF client initiates a database access interface addressing request to the service registry, locating the access interface instance of the target group database through the service discovery mechanism; if multiple instances are deployed, the optimal interface instance is selected based on a load balancing strategy (such as round-robin or weighted allocation). After confirming the interface instance, the general service encapsulates the split table operation logic, invocation parameters, and data processing type into a standard DSF invocation message, initiates an interface invocation request, establishes a communication link with the database access interface, and completes the pre-link construction for the interface invocation.

[0096] In step S320, the group database is called synchronously or asynchronously through the database access interface.

[0097] After the general service successfully calls the database access interface, it selects the corresponding calling mode based on the previously determined group dependencies. If there are no dependencies, an asynchronous calling process is triggered, sending the encapsulated calling message to the group database through the interface. No execution result is needed; only the asynchronous task identifier is recorded and the execution status is monitored. The interface immediately returns a task acceptance receipt, allowing the general service to process calling requests from other groups in parallel. If there are sequential dependencies, a synchronous calling process is triggered. After sending the calling message through the interface, the communication link remains blocked, waiting for the group database to fully execute the stored routine and return the execution result. If execution timeouts or interface exceptions occur during this period, the call is re-initiated according to preset retry rules. Regardless of synchronous or asynchronous mode, the database access interface parses the calling parameters and passes them to the group database, driving the database to execute the table operation logic of the corresponding stored routine, completing core operations such as data querying and maintenance. Simultaneously, the interface provides real-time feedback on the execution status to the general service, ensuring the calling process is monitorable.

[0098] In the embodiments of this application, the database access interface is called based on the distributed service framework, and then the group database is called synchronously or asynchronously through the interface. The unified call to the group database simplifies the database call process, realizes the standardization and flexibility of database calls, and can select the call mode according to the group dependency relationship, which improves the call efficiency and enhances the system adaptability.

[0099] For example, Figure 4 A flowchart illustrating a multi-group database retrieval method according to an embodiment of this application is shown. Figure 4 As shown, enterprise online banking groups or external applications act as callers. The general service provides adapted general service interfaces (such as online banking interfaces, external interfaces, etc.). Enterprise online banking groups call the online banking interface, while external applications call the externally provided interfaces. After the caller initiates a request, it first enters the whitelist verification stage to verify the caller's identity and the legitimacy of the operation. After the verification is successful, the general service reads the call parameters and configuration information, determines the data processing type and the group to which it belongs, and then, according to the dependencies between group tables, splits the stored routine and forwards it synchronously or asynchronously to the databases corresponding to platform groups 1, 2, and 3 for execution. The databases of platform group 1 and platform group 2 are asynchronous, while the databases of platform group 1 and platform group 3 are synchronous. Subsequently, the general service obtains the execution results of each group database and performs summary processing. If the processing fails, a rollback / fallback mechanism is triggered. If successful, the standardized call result is returned to the caller, realizing unified management and data interaction throughout the entire process.

[0100] Based on the above data retrieval method, embodiments of this application also provide a data retrieval device. The following will be combined with... Figure 5 The device is described in detail.

[0101] Figure 5 A schematic block diagram of a data retrieval device according to an embodiment of this application is shown.

[0102] like Figure 5 As shown, the data retrieval device 1000 of this embodiment includes a verification module 1010, a query module 1020, a data operation module 1030, and a result return module 1040.

[0103] The verification module 1010 is used to verify the caller in response to the caller uploading the name of the stored routine and the calling parameters through the general service interface. In one embodiment, the verification module 1010 can be used to perform step S210 described above, which will not be repeated here.

[0104] The query module 1020 is used to obtain the name of the stored routine and the calling parameters in response to the caller passing the verification, and to query the data processing type and data belonging group based on the name of the stored routine. In one embodiment, the query module 1020 can be used to execute step S220 described above, which will not be repeated here.

[0105] The data operation module 1030 is used to forward the call parameters and the data processing type to the group database corresponding to the data's belonging group based on the database flow switching mechanism, and then call the group database to execute the data processing operation corresponding to the stored routine. In one embodiment, the data operation module 1030 can be used to execute step S230 described above, which will not be repeated here.

[0106] The result return module 1040 is used to obtain and process the execution result of the group database, obtain the call result, and return the call result to the caller. In one embodiment, the result return module 1040 can be used to execute the step S240 described above, which will not be repeated here.

[0107] According to an embodiment of this application, the device 1000 further includes: an exception handling module, configured to, when the obtained execution result is an execution failure, extract the data processing type corresponding to the failed stored routine, determine the exception handling type, and perform an exception handling operation based on the exception handling type.

[0108] According to an embodiment of this application, the anomaly handling operation includes a data rollback operation and / or a fallback push operation. The anomaly handling module includes: an attribute identification unit, used to identify the maintenance data attribute of the failed storage routine based on a first whitelist when the anomaly handling type is maintenance-related; a rollback unit, used to perform the data rollback operation if the maintenance data attribute is sensitive data or time-constrained data; and a push unit, used to perform the fallback push operation if the maintenance data attribute is non-time-constrained data.

[0109] According to an embodiment of this application, the data operation module 1030 includes: a routine processing unit, configured to obtain the dependency relationships of table execution statements in the stored routine, determine group dependency relationships, and split the table operation logic of the stored routine; an asynchronous forwarding unit, configured to, if the group dependency relationship is non-dependent, asynchronously forward the call parameters and the data processing type to the group database corresponding to the data's home group according to the split table operation logic; and a synchronous forwarding unit, configured to, if the group dependency relationship is sequential dependency, synchronously forward the call parameters and the data processing type to the group database corresponding to the data's home group according to the dependency order corresponding to the split table operation logic.

[0110] According to an embodiment of this application, the data operation module 1030 includes: an interface calling unit, used to call the corresponding database access interface based on the distributed service framework; and a database calling unit, used to synchronously or asynchronously call the group database through the database access interface.

[0111] According to an embodiment of this application, the data operation module 1030 further includes: a database flow-switching unit, used to configure a second whitelist; and to forward data to the group database according to preset flow-switching rules based on the flow-switching parameters of the second whitelist; the preset flow-switching rules include at least one of no flow-switching, one-time flow-switching, region flow-switching, card number flow-switching, transaction instruction word flow-switching, and table dimension split flow-switching.

[0112] According to an embodiment of this application, the verification module 1010 includes: an identity verification unit, used to receive the identity verification result of the caller; wherein the identity verification result is obtained by verifying the data signature of the caller through an authentication platform; an access function verification unit, used to read a configuration file, verify the function access permission of the caller, and obtain an access verification result; and a verification judgment unit, used to determine if the caller passes the verification if both the identity verification result and the access verification result are passed.

[0113] According to embodiments of this application, any multiple modules among the verification module 1010, query module 1020, data operation module 1030, result return module 1040, and exception handling module can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the verification module 1010, query module 1020, data operation module 1030, result return module 1040, and exception handling module can be at least partially implemented as hardware circuits, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or any other reasonable means of integrating or packaging circuits, or implemented in hardware or firmware, or in any one of software, hardware, and firmware implementations, or in a suitable combination of any of these. Alternatively, at least one of the verification module 1010, query module 1020, data operation module 1030, result return module 1040, and exception handling module can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0114] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a data retrieval method according to an embodiment of this application.

[0115] like Figure 6 As shown, an electronic device 1200 according to an embodiment of this application includes a processor 1201, which can perform various appropriate actions and processes according to a program stored in a read-only memory 1202 or a program loaded from a storage portion 1208 into a random access memory 1203. The processor 1201 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 1201 may also include onboard memory for caching purposes. The processor 1201 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0116] Random access memory 1203 stores various programs and data required for the operation of electronic device 1200. Processor 1201, read-only memory 1202, and random access memory 1203 are interconnected via bus 1204. Processor 1201 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 1202 and / or random access memory 1203. It should be noted that the programs may also be stored in one or more memories other than read-only memory 1202 and random access memory 1203. Processor 1201 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0117] According to embodiments of this application, the electronic device 1200 may further include an input / output interface 1205, which is also connected to the bus 1204. The electronic device 1200 may also include one or more of the following components connected to the input / output interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card, such as a local area network card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0118] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0119] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 1202, and / or random access memory 1203, and / or one or more memories other than read-only memory 1202 and random access memory 1203 described above.

[0120] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0121] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 1209, and / or installed from the removable medium 1211. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0122] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by processor 1201, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0123] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0124] 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 a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may 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.

[0125] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A data calling method, characterized by, The method includes: In response to the caller uploading the name of the stored routine and the calling parameters through the general service interface, the caller is verified. In response to the caller passing the verification, the name of the stored routine and the call parameters are obtained, and the data processing type and data belonging group are queried based on the name of the stored routine; Based on the database flow-switching mechanism, the call parameters and the data processing type are forwarded to the group database corresponding to the data's group, and the group database is invoked to execute the data processing operation corresponding to the stored routine; and The execution results of the group database are obtained and processed to obtain the call result, and the call result is returned to the caller.

2. The method of claim 1, wherein, The method further includes: If the execution result is failure, extract the data processing type corresponding to the failed stored routine to determine the exception handling type; and Perform exception handling operations based on the exception handling type.

3. The method of claim 2, wherein, The anomaly handling operations include data rollback operations and / or fallback push operations. The execution of the anomaly handling operations based on the anomaly handling type includes: When the exception handling type is maintenance type, the maintenance data attributes of the failed stored routine are identified based on the first whitelist; If the maintenance data attribute is sensitive data or time-constrained data, then the data rollback operation is performed; If the maintenance data attribute is non-time-constrained data, then the fallback push operation is performed.

4. The method of claim 1, wherein, The step of forwarding the call parameters and the data processing type to the group database corresponding to the data's belonging group includes: Obtain the dependencies of the table execution statements in the stored routine, determine the group dependencies, and decompose the table operation logic of the stored routine; If the group dependency is no dependency, then according to the split table operation logic, the call parameters and the data processing type are asynchronously forwarded to the group database corresponding to the data belonging to the group; If the group dependency is a sequential dependency, then according to the dependency order corresponding to the split table operation logic, the calling parameters and the data processing type are synchronously forwarded to the group database corresponding to the data belonging group.

5. The method according to claim 1, characterized in that, The invocation of the group database includes: Based on the distributed service framework, call the corresponding database access interface; and The group database can be accessed synchronously or asynchronously through the database access interface.

6. The method according to claim 1, characterized in that, The database flow switching mechanism includes: Configure a second whitelist; and Based on the flow-cutting parameters of the second whitelist, data is forwarded to the group database according to the preset flow-cutting rules; The preset traffic switching rules include at least one of the following: no traffic switching, one-time traffic switching, regional traffic switching, card number traffic switching, transaction instruction word traffic switching, and table dimension splitting traffic switching.

7. The method according to claim 1, characterized in that, The verification of the caller includes: Receive the authentication result of the caller; wherein the authentication result is obtained by verifying the data signature of the caller through an authentication platform; Read the configuration file, verify the caller's access permissions, and obtain the access verification result; and If both the identity verification result and the access verification result are passed, then the caller passes the verification.

8. A data retrieval device, characterized in that, The device includes: The verification module is used to verify the caller in response to the caller uploading the name of the stored routine and the calling parameters through the general service interface. The query module is used to obtain the name of the stored routine and the call parameters in response to the caller passing the verification, and to query the data processing type and data belonging group based on the name of the stored routine; The data operation module is used to forward the call parameters and the data processing type to the group database corresponding to the data's home group based on a database flow switching mechanism, and then call the group database to execute the data processing operation corresponding to the stored routine; and The result return module is used to obtain and process the execution result of the group database, obtain the call result, and return the call result to the caller.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images