Banking general basic component layered decoupling system and construction method thereof

Abstract

The application discloses a bank intermediary service general basic component layered decoupling system and a construction method thereof, and relates to the technical field of financial data processing. The system comprises: a service layer containing a plurality of intermediary service subsystems, a general basic component module being introduced through dependency management; a core component layer being independently deployed and being used for respectively executing enumeration bidirectional conversion, multi-source parameter loading and verification, transaction idempotent control based on a composite unique key, and asynchronous polling and retry of a configurable delay strategy; and a rule management and control layer, which centrally stores and maintains rule data and supports dynamic configuration and real-time effect. Each unit of the core component layer acquires rule data from the rule management and control layer in real time and executes general logic, and the service layer calls a standardized interface to delegate common processing to the core component layer and then executes exclusive logic. The application realizes layered decoupling and component reuse of general basic capabilities, and improves the technical standard uniformity and scalability of multi-service systems.

Description

Technical Field

[0001] This invention relates to the field of financial data processing technology, specifically to a layered decoupling system for general basic components of banking intermediary business and its construction method. Background Technology

[0002] In the banking intermediary business sector, systems such as bill payment, interbank interconnection, and bank-insurance integration all require routine data interaction with third-party payment institutions, interbank banks, and insurance companies. These systems generally share common basic processing requirements such as enumeration adaptation, parameter parsing, transaction deduplication prevention, and delayed polling. Currently, these intermediary business systems are typically developed, deployed, and maintained independently. Each system adopts a self-coded and independently implemented development model for the aforementioned common basic capabilities, failing to form a unified and reusable technical foundation.

[0003] Chinese patent application CN122086710A discloses a system performance optimization architecture based on layered decoupling. This architecture decouples the system performance optimization framework from the underlying operating system by layering hardware abstraction layer services and kernel service nodes, effectively reducing the difficulty of code refactoring and adaptation. However, this solution primarily targets performance optimization scenarios for mobile terminal operating systems. Its layered decoupling concept involves separating performance tuning logic from the system framework layer to address compatibility issues arising from operating system version upgrades. This solution does not address banking intermediary business scenarios, nor does it address the reuse of common basic capabilities across multiple business systems.

[0004] In real-world banking intermediary business scenarios, the independent development of each business system leads to repetitive development of common logic such as enumeration conversion, parameter validation, transaction deduplication, and delay scheduling. This not only results in code redundancy and low development efficiency but also, due to the different coding standards, validation rules, and scheduling parameters used by each system, inconsistencies in the processing logic for similar transactions across different business scenarios. This can easily cause production failures such as third-party data adaptation failures, duplicate transactions, and polling timeouts. When the enumeration dictionary, validation rules, or scheduling parameters need optimization or adjustment, multiple business systems must be modified, tested, and deployed separately, making the operation and maintenance iteration process cumbersome and prone to omissions or version inconsistencies. Furthermore, when adding new intermediary business types or third-party partners, the lack of reusable basic technical capabilities necessitates developing underlying common logic from scratch, severely hindering rapid business expansion.

[0005] To address the aforementioned issues, the industry has yet to propose an integrated, universal component decoupling and reuse solution that can adapt to various intermediary business scenarios in banks. This makes it difficult to eliminate core defects such as redundant development of basic capabilities across multiple business systems, inconsistent technical standards, and insufficient scalability at the architectural level. Summary of the Invention

[0006] To address the aforementioned issues, this invention provides a layered decoupling system for general basic components of banking intermediary business and its construction method.

[0007] The layered decoupling system for general basic components of banking intermediary business provided by this invention includes: The business layer includes multiple intermediate business subsystems. Each intermediate business subsystem is used to execute its own exclusive business logic. Each intermediate business subsystem introduces a general basic component module through a dependency management component to call the standardized interface provided by the general basic component module. The core component layer, deployed independently of each intermediate business subsystem, serves as a common technical foundation and includes at least an enumeration conversion unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit. Specifically, the enumeration conversion unit performs bidirectional standardized conversion between internal bank enumeration values ​​and third-party institution enumeration values ​​based on a preset enumeration mapping relationship; the unified parameter acquisition unit loads transaction parameters from a multi-source configuration center and performs parameter validity verification; the transaction deduplication unit performs idempotent control and duplicate request interception based on a configurable composite unique key; and the sleep scheduling unit performs asynchronous waiting, polling, or retry operations according to a configurable delay strategy. The rule management layer is communicatively connected to each unit of the core component layer. It is used to centrally store and maintain the rule data required for the operation of each unit of the core component layer. The rule data includes at least enumeration mapping relationships, parameter verification rules, transaction deduplication rules, and delay scheduling parameters. The rule management layer supports dynamic configuration and real-time activation of the rule data. When each unit of the core component layer performs its corresponding function, it obtains the corresponding rule data from the rule management layer in real time and executes the corresponding general basic processing logic based on the rule data. After receiving a transaction request, each intermediate business subsystem calls the standardized interface corresponding to the general basic component module according to the current transaction scenario, delegates the common processing requirements in the transaction request to the core component layer for execution, receives the standardized processing result returned by the core component layer, and executes its own exclusive business logic based on the standardized processing result to complete the complete transaction process.

[0008] Preferably, the enumeration conversion unit is specifically used for: receiving an encoding mapping object containing a product number, an item key, and a source code; obtaining an enumeration mapping relationship from the rule control layer based on the product number and the item key; preferentially using the source code to query the corresponding target code, and if no target code is found, querying again using the default code; and returning the queried target code.

[0009] Preferably, the parameter unified acquisition unit is specifically used for: batch loading parameter configuration data from the rule control layer according to business type, wherein the parameter configuration data includes static parameters and dynamic parameters; caching the static parameters in local memory and supporting timed refresh; performing non-empty verification, format verification, range verification and legality filtering on the parameter configuration data; and returning the parameter data that has passed the verification.

[0010] Preferably, the transaction deduplication unit is specifically used for: obtaining the deduplication rule corresponding to the current product number from the rule control layer, wherein the deduplication rule includes at least one deduplication field column name; extracting the field values ​​corresponding to each deduplication field from the transaction request object and concatenating them to generate a composite unique key; associating the composite unique key with the transaction date and transaction time and writing it into the deduplication detail table, wherein the deduplication detail table uses the product number, the deduplication rule code, the composite unique key, and the transaction date as a composite primary key; if the writing is successful, it is determined that the current transaction is not duplicated and allowed to proceed; if the writing fails due to a primary key conflict, it is determined that the current transaction is duplicated and is blocked.

[0011] Preferably, the sleep scheduling unit is specifically used for: after sending a transaction request to a third-party institution, loading the delay scheduling parameters corresponding to the current business type from the rule control layer, wherein the delay scheduling parameters include at least the initial delay duration, the maximum number of retries, the retry interval strategy, the basic interval duration, and the total timeout duration; causing the current thread to enter a sleep state according to the initial delay duration; waking up after sleep and initiating result polling; if the polling result is in the final state, returning the result; if the polling result is in the process of processing and the current number of retries has not exceeded the maximum number of retries, calculating the next delay duration according to the retry interval strategy and continuing to sleep and wait for retry; if the current number of retries exceeds the maximum number of retries, returning the timeout result.

[0012] Preferably, the retry interval strategy includes at least one or a combination of a fixed interval strategy, a linear increment strategy, and an exponential increment strategy.

[0013] Preferably, the rule management layer includes a distributed database and a cache module. The rule data is stored in the distributed database. Each unit of the core component layer queries the rule data through the cache module. The rule data stored in the cache module supports two refresh mechanisms: expiration and active expiration, so that the rule data takes effect in real time after being updated by the rule management layer.

[0014] Preferably, each of the intermediate business subsystems imports the general basic component module through Maven dependency management. The general basic component module is deployed in the form of a JAR package in a Maven remote repository. Each of the intermediate business subsystems declares its dependency relationship and version number on the general basic component module through a project object model file, and automatically pulls the general basic component module from the Maven remote repository during compilation.

[0015] This invention also provides a method for constructing a layered decoupling system for general basic components of banking intermediary business, comprising the following steps: Step S1, constructing the business layer, specifically includes: providing multiple intermediate business subsystems, each of which executes its own exclusive business logic; deploying the common basic component module as a JAR package to a Maven remote repository; declaring the dependency relationship and version number of the common basic component module in the project object model file of each intermediate business subsystem; configuring each intermediate business subsystem to automatically pull the common basic component module from the Maven remote repository during compilation, so that each intermediate business subsystem can import the common basic component module through the dependency management component and call the standardized interface provided by the common basic component module; Step S2, constructing the core component layer, specifically includes: building a common technical foundation independent of the deployment of each intermediate business subsystem; deploying an enumeration conversion unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit in the common technical foundation; configuring the enumeration mapping relationship storage structure of the enumeration conversion unit, enabling the enumeration conversion unit to query the mapping relationship between the bank's internal enumeration values ​​and the enumeration values ​​of third-party institutions based on the product number and item key, and performing bidirectional standardized conversion; configuring the multi-source parameter loading logic of the unified parameter acquisition unit, enabling the unified parameter acquisition unit to batch load static and dynamic parameters from the rule control layer according to business type, cache the static parameters in local memory and refresh them periodically, and perform non-empty verification, format verification, range verification, and legality filtering on the parameter configuration data; configuring the deduplication rule storage structure and deduplication detail table storage structure of the transaction deduplication unit, enabling the transaction deduplication unit to perform deduplication based on the product number... The system obtains deduplication rules containing at least one deduplication field column name from the rule management layer, extracts the field values ​​corresponding to each deduplication field from the transaction request object and concatenates them to generate a composite unique key, associates the composite unique key with the transaction date and transaction time and writes it into the deduplication detail table, and uses the product number, deduplication rule code, composite unique key and transaction date as the joint primary key of the deduplication detail table, and realizes transaction idempotency control and duplicate request interception through database unique constraints; configures the delay scheduling parameter storage structure of the sleep scheduling unit, so that after the sleep scheduling unit sends the transaction request to the third-party institution, it can load the delay scheduling parameters containing the initial delay duration, maximum number of retries, retry interval policy, basic interval duration and total timeout duration from the rule management layer, control the current thread to enter the sleep state according to the initial delay duration, wake up after the sleep ends and initiate result polling, and perform retry or timeout processing according to the polling result and the retry interval policy; Step S3, constructing a rule management layer, specifically includes: building a distributed database as the underlying storage for rule data, wherein the rule data includes at least enumerated mapping relationships, parameter validation rules, transaction deduplication rules, and delay scheduling parameters; building a caching module on top of the distributed database, configuring the caching module to cache the rule data; configuring the rule data stored in the caching module to support two refresh mechanisms: expiration and active expiration, so that the rule data takes effect in real time after being updated by the rule management layer; configuring the rule management layer to support dynamic configuration and real-time effectiveness of rule data. Step S4, establishing a data interaction channel between the core component layer and the rule management layer, specifically includes: configuring each unit of the core component layer to query the rule data through the cache module when performing corresponding functions; configuring the cache module to load the rule data from the distributed database when a cache miss occurs; configuring the rule management layer to invalidate the corresponding cached data in the cache module through expiration or active invalidation when the rule data is updated, so that each unit of the core component layer can obtain the updated rule data in real time and execute the corresponding general basic processing logic based on the rule data; Step S5, establishing the calling relationship between the business layer and the core component layer, specifically includes: exposing the standardized interface of the general basic component module to each of the intermediate business subsystems; configuring each of the intermediate business subsystems to call the standardized interface corresponding to the general basic component module according to the current transaction scenario after receiving a transaction request, and delegating the common processing requirements in the transaction request to the core component layer for execution; configuring each of the intermediate business subsystems to receive the standardized processing result returned by the core component layer; Step S6: After receiving the standardized processing result returned by the core component layer, each intermediate business subsystem is configured to execute its own exclusive business logic based on the standardized processing result to complete the complete transaction process.

[0016] Compared with the prior art, the technical solution of this application has the following beneficial effects: 1. A three-tiered, decoupled architecture oriented towards business dimensions Existing layered architectures are based on operating system hierarchies, with a layering between hardware abstraction layer services (user space) and kernel service nodes (kernel space). This represents a classic layered architecture in the operating system domain applied to performance optimization scenarios. This invention, however, is based on a business dimension, employing a three-layer decoupled architecture: the business layer (various intermediate business subsystems), the core component layer (general-purpose basic components), and the rule control layer (configuration center). This layered design completely separates general-purpose basic capabilities from each business system, forming a three-layer architecture with clear responsibilities and well-defined boundaries. Interactions between layers are achieved through standardized interfaces, ensuring that adjustments to any layer do not affect the normal operation of other layers, thus achieving high cohesion and low coupling at the architectural level. From a business perspective, each intermediate business subsystem can evolve and be deployed independently, fundamentally changing the traditional tightly coupled model of self-built and self-used general-purpose capabilities in multi-business systems. This offers significant advantages in architectural flexibility and maintainability.

[0017] 2. A collection of dedicated functional units for banking intermediary business scenarios The core functional units of existing technologies include a monitoring module, a first control layer, a first processing layer, a second control layer, and a second processing layer. These units collectively form a performance regulation chain of "scenario recognition—performance decision-making—kernel execution," targeting common system performance optimization scenarios. This invention, however, addresses four common technical needs in the banking intermediary business field by constructing four functional units: an enumeration conversion unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit. Each functional unit is designed to address specific technical issues in data interaction between banking intermediary businesses and third-party institutions (payment units, insurance companies, other banks). Its functional definitions and processing logic are highly aligned with the technical requirements of banking intermediary businesses, providing specialized technical support.

[0018] 3. Independent architecture-level rule control mechanism In existing technologies, the scenario-performance configuration mapping relationship and the scenario business logic mapping relationship are pre-stored in the local storage of the first processing layer, and updates require code modification or system upgrades. This invention constructs the rule control layer as an independent architectural layer, employing a two-level storage architecture of a distributed database plus a caching module to centrally manage all rule data. This rule control layer has the following advanced features: First, rule data is centrally stored in a structured form in a distributed database, and each unit uniformly obtains rule data from the rule control layer, achieving a single source of fact for rule data and eliminating the problem of inconsistent rules across multiple systems from an architectural perspective; Second, it supports operations and maintenance personnel to dynamically modify configurations through the management interface, with real-time effects, without requiring any modification to business code or a system restart, achieving complete separation of rules and code.

[0019] 4. Component reuse mechanism based on Maven dependency management In existing technologies, the hardware abstraction layer service and kernel service nodes have a fixed pairing relationship, oriented towards a single operating system environment, and lack an independent deployment and dependency import mechanism for multiple upper-layer systems. This invention establishes a component reuse mechanism based on Maven dependency management: common basic component modules are deployed independently as JAR packages in a Maven remote repository. Each intermediate business subsystem declares dependencies and version numbers through a project object model file, and automatically pulls component modules from the remote repository during compilation. This mechanism allows each business subsystem to import common basic capabilities on demand without local copying or manual integration, supports unified upgrades and canary releases of component versions, and achieves standardized, traceable component-level reuse across multiple business systems.

[0020] 5. Dual-strategy cache refresh mechanism under a "distributed database + cache" two-level storage architecture In existing technologies, configuration parameters are stored in a preset memory area, and their updates depend on data call requests from designated system services, resulting in a relatively simple cache refresh mechanism. This invention employs a two-tier storage architecture of "distributed database + Redis cache" and configures two cache refresh strategies: expiration expiration and proactive expiration. The expiration expiration strategy automatically invalidates cached data after a fixed expiration time, and the latest data is reloaded from the distributed database on the next query. The proactive expiration strategy allows operations personnel to immediately invalidate the corresponding cached data in Redis by calling the cache refresh tool after modifying the configuration at the rule control layer, and the latest data is automatically reloaded from the distributed database on the next query. The combined use of these two strategies ensures both the consistency and real-time performance of cached data while avoiding frequent database queries, achieving a good balance between data consistency and system performance.

[0021] 6. Supports a sleep scheduling mechanism with dynamic configuration of multiple strategies. Existing technologies do not address delayed scheduling and asynchronous retries. The sleep scheduling unit in this invention supports three configurable retry interval strategies: fixed interval, linear increment, and exponential increment. Operations personnel can flexibly configure parameters such as initial delay duration, maximum number of retries, retry interval strategy type, basic interval duration, increment step size, and total timeout duration through the rule management layer, according to the technical requirements of different business scenarios. This allows for adaptation to the response characteristics of different third-party organizations without code modification, effectively solving the problems of polling timeouts and high-frequency invalid requests caused by traditional fixed delay strategies.

[0022] The beneficial effects of this invention are not only reflected in the realization of the functions of each unit, but also in the collaborative integration between the four functional units and between the core component layer and the rule control layer. This collaborative relationship enables the system as a whole to generate technical benefits that cannot be achieved when each unit operates independently.

[0023] First, functional coordination between units: In the complete transaction processing flow, each unit is sequentially connected and interdependent: A progressive defense chain of "verification-duplicate detection" is formed between the unified parameter acquisition unit and the transaction deduplication unit. Before executing idempotent control, the transaction deduplication unit relies on the parameter verification results from the unified parameter acquisition unit—if the parameter verification fails, the transaction is directly rejected without entering the deduplication process; only after the parameter verification passes can the transaction enter the deduplication stage. This collaborative relationship effectively prevents illegal parameters from polluting the deduplication details table, improving the quality and reliability of the deduplication data.

[0024] A preprocessing pipeline of "parameter loading - enumeration conversion - parameter verification" is formed between the enumeration conversion unit and the parameter unified acquisition unit. In the scenario of cross-institutional data interaction, the parameter data loaded by the parameter unified acquisition unit may contain enumeration values returned by a third-party institution. This enumeration value needs to be converted into the bank's internal standard enumeration by the enumeration conversion unit before the parameter unified acquisition unit can perform subsequent legality verification. The front-to-back connection of the two units ensures the format compliance of cross-institutional interaction data throughout the entire process.

[0025] A full-life cycle traceability link of "recording - tracing" is formed between the transaction duplicate checking unit and the sleep scheduling unit. The transaction duplicate checking unit records the unique transaction identifier when a transaction is initiated, and the sleep scheduling unit continuously uses this transaction identifier to query the status during asynchronous polling. The two together ensure that the same asynchronous transaction can be uniquely traced and its status tracked throughout the full life cycle.

[0026] Secondly, the collaborative closed-loop between the core component layer and the rule control layer: Each unit in the core component layer is connected to the rule control layer through a standardized data interaction channel, forming a closed-loop collaboration of "centralized rule management - component call on demand - real-time data synchronization". The advanced value of this collaborative relationship is reflected in: First, a single source of truth for rule data. All enumeration mapping relationships, parameter verification rules, duplicate checking rules, and scheduling parameters are centrally managed in the same configuration record. Each unit uniformly obtains rule data from the rule control layer, fundamentally eliminating the data inconsistency problems caused by the independent maintenance of rules by each system in the traditional architecture.

[0027] Second, the unified risk control ability of multi-component linkage. When an operator adjusts a certain rule in the rule control layer, this adjustment can immediately联动 affect the behaviors of multiple units. For example, when the transaction failure rate of a certain third-party institution exceeds the threshold, the operator can simultaneously adjust the duplicate checking field configuration of the transaction duplicate checking unit through the rule control layer to tighten the anti-duplicate strategy, the retry interval parameter of the sleep scheduling unit to avoid excessive pressure on the third-party institution, and the verification rules of the parameter unified acquisition unit to intercept abnormal transactions. This multi-component linkage response mechanism is a technical effect that cannot be achieved when each unit operates independently, reflecting the integrated innovation at the system architecture level.

[0028] Thirdly, the overall division of labor and cooperation of the three-layer architecture: Based on the aforementioned collaborative relationships, this invention establishes a clear three-tiered division of responsibilities: the business layer focuses on its specific logic, the core component layer provides general capabilities, and the rule management layer centrally manages rules. This system generates a cumulative technical effect of three-tiered collaboration: the business layer does not need to concern itself with the implementation details of the underlying general logic, the core component layer does not need to concern itself with the storage location and update method of rule data, and the rule management layer does not need to concern itself with which business systems call the rules. The layers interact through standardized interfaces and unified data channels, and adjustments to any layer do not affect the normal operation of other layers, achieving high cohesion and low coupling at the architectural level. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall system architecture; Figure 2 Workflow diagram for enumeration conversion unit; Figure 3 A flowchart for the unified acquisition of parameters in the unit; Figure 4 Workflow diagram for the transaction deduplication unit; Figure 5 Workflow diagram of the sleep scheduling unit; Figure 6 This is a schematic diagram of the main process of system construction. Detailed Implementation

[0030] To better understand this invention, some technical terms involved in this invention will be defined and explained before providing a detailed description of specific embodiments.

[0031] Definitions: Intermediary services: In this invention, this specifically refers to various agency, consulting, custody, and guarantee services provided by banks to clients on behalf of them, acting as intermediaries or agents. These services do not constitute the bank's own assets or liabilities. The core intermediary service scenarios involved in this invention include bill payment (such as water, electricity, gas, and telecommunications fees), interbank interbank connections (interbank lending, clearing, and reconciliation), and bank-insurance integration (sales, application, and policy inquiry of insurance products).

[0032] Product ID: In this invention, it serves as a unique code to identify different types of intermediate business products. For example, different bill payment services (water bill payment, electricity bill payment), different insurance products, and different intermediary cooperation services are all assigned a unique, non-repeating product ID, which is the core basis for rule configuration, parameter loading, and business routing.

[0033] Enumeration mapping refers to a conversion rule that establishes a correspondence between enumeration values ​​with the same or similar business meanings across different systems or standards. For example, the correspondence between the bank's internal transaction status code "00" (success) and the status code "S" of a third-party payment institution. The enumeration conversion in this invention is based on this mapping relationship, enabling bidirectional translation between internal bank standards and external third-party standards.

[0034] Item key: In the enumeration mapping unit of this invention, a key value used to classify enumeration values. That is, under the same product number, different item keys are used to distinguish different types of enumeration mappings, such as transaction status code mapping, error code mapping, business type code mapping, etc.

[0035] Composite unique key: In the transaction deduplication unit of this invention, it refers to a string composed of multiple business field values ​​used to uniquely identify a transaction. Its generation logic and the combination of fields used are configurable. For example, it can be composed of fields such as "institution number + transaction date + customer number + transaction amount" to achieve more accurate and flexible idempotent control of transactions.

[0036] Final state: In the sleep scheduling unit of this invention, this refers to the final result state of a transaction processing. This state indicates that the transaction processing flow has ended and there will be no further state changes. It typically includes two states: "Transaction successful" and "Transaction failed." The opposite is the "Processing" state, which indicates that the transaction is still in progress and requires continued polling to wait for the result.

[0037] Maven Remote Repository: In this invention, it refers to a server that conforms to the Maven project management tool specification and is used for centralized storage and distribution of software components (such as JAR packages). Developers can deploy compiled code components to this repository, and other projects can automatically download and import the required components from this repository during the build process by declaring dependencies, thus achieving standardized code reuse.

[0038] GoldenDB: In this invention, the underlying storage database serving as the rule configuration center is a distributed relational database with characteristics such as high availability, strong consistency, and linear scalability. It is used to securely and reliably store rule data such as all enumeration mappings, parameter validation, transaction deduplication, and scheduling strategies. Those skilled in the art will understand that it can also be replaced by other distributed databases or traditional database clusters with similar functions.

[0039] Example 1 This embodiment details the specific architecture implementation of the layered decoupling system for general basic components of bank intermediary business proposed in this invention, as well as the construction methods of its various components.

[0040] 1. System Overall Architecture like Figure 1As shown, this system adopts a three-tiered, decoupled architecture, including a business layer, a core component layer, and a rule control layer. The core component layer is deployed and version-managed independently of all business systems, and is not bound to any specific business scenario, serving as the bank's common technical foundation. The core component layer and the business layer establish a calling relationship through a Maven dependency management mechanism, while the core component layer and the rule control layer establish a data interaction channel through a standardized data query interface. The specific construction of each layer is described below.

[0041] 2. Construction of the business layer The business layer includes a payment processing subsystem, an interbank interconnection subsystem, and a bank-insurance integration subsystem. Each subsystem retains only its own proprietary business logic, stripping away all underlying common logic such as general preprocessing, data transformation, transaction deduplication prevention, and delay scheduling.

[0042] Each business subsystem imports the common basic component module using Maven dependency management. The dependency on the common basic component module is declared in the project object model file (pom.xml) of each business subsystem, as follows: Under the dependencies node in the pom.xml file, add a dependency sub-node, where groupId is fixed to com.sccba.xbus.ssbp, artifactId is fixed to ssbp-component-common, and version is the version number of the component library. The version is managed uniformly through the variable ${ssbp.component.version}.

[0043] During the compilation of the business subsystem, the Maven build tool automatically pulls the specified version of the common basic component module JAR package from the Maven remote repository to the local project classpath based on the dependency declaration, eliminating the need for local copying or manual integration. When the component version is upgraded, simply modify the value of the version variable in pom.xml and recompile to complete the component update.

[0044] 3. Construction of the core component layer The core component layer is an independent software engineering module. This project is compiled, packaged, and deployed to a Maven remote repository as a JAR file. This layer contains four functional units: an enumeration transformation unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit. Each unit is independent of the others, handling different types of basic technical requirements. There are no direct dependencies between units, and data is transferred through a standardized data format.

[0045] 3.1 Enumeration Conversion Unit The enumeration conversion unit is used to perform bidirectional standardized conversion between internal bank enumeration values ​​and third-party institution enumeration values.

[0046] like Figure 2 As shown, the enumeration conversion unit internally maintains an enumeration mapping engine named EnumConvertComponent. The core data of this engine comes from the enumeration mapping relationship table stored in the rule control layer. This mapping relationship table is stored in structured record format, and each record contains the following fields and their descriptions: The Product ID field (pd_no) identifies the business product to which the mapping belongs; the Item Key field (itm_key) identifies the type classification of the mapping. Under the same Product ID, different Item Keys can be used to distinguish different classifications such as transaction status code mapping, error code mapping, and business type code mapping; the Original Code field (orgn_cd) stores the original enumeration value of the source system; the Original Description field (orgn_dsc) stores the description text corresponding to the original enumeration value; the Target Code field (targ_cd) stores the target enumeration value of the target system; the Target Description field (targ_dsc) stores the description text corresponding to the target enumeration value; the Creation Timestamp field (crt_tms) and Update Timestamp field (upd_tms) record the creation and last modification times of the mapping relationship, supporting audit traceability of configuration changes.

[0047] The product number field and the item key field together constitute the classification dimension of the enumeration mapping, while the original code field and the target code field together constitute the transformation mapping relationship. The records in this table are maintained by operations and maintenance personnel through the visual interface of the rule control layer.

[0048] When the enumeration conversion unit receives a conversion request, it retrieves the corresponding enumeration mapping record set from the rule control layer based on the input product number and item key, then matches it with the original code and returns the corresponding target code.

[0049] The signature of the core transformation method in this unit is as follows: publicStringdoExecute(SspCodemapsspCodemap); SspCodemap is an encoding mapping object that contains three fields: product number attribute (pd_no), item key attribute (itm_key), and original code attribute (orgn_cd).

[0050] The execution logic of this method is as follows: First, based on the product number attribute and item key attribute, the corresponding enumeration mapping relationship set is queried from the rule control layer. During the matching process, the passed-in original code attribute value is preferentially used to match the original code field value in the mapping record; if the match is successful, the target code field value corresponding to the record is returned. If the match fails, the predefined default code constant DEFAULTCODE is used as the original code to execute the query again to obtain the corresponding default target code. If no matching result is obtained in both queries, an empty string is returned, and the upper-level business system handles the exception based on the returned result.

[0051] 3.2 Unified Parameter Acquisition Unit like Figure 3 As shown, the unified parameter acquisition unit loads transaction parameters from the multi-source configuration center and performs validity checks on the loaded parameters. This unit supports loading parameter data from three sources: database, registry center, and local configuration file. The database is the primary source, while the registry center and local configuration file serve as supplementary sources, used to provide fallback parameters or override specific configuration items when the database is unavailable. The priority order for multi-source loading is as follows: local configuration file has the highest priority and is used for emergency configuration overriding; the registry center is next and is used for dynamic configuration distribution; the database has the lowest priority and is used for full configuration for persistent storage. This priority order allows operations personnel to flexibly choose the configuration method according to the actual situation, enabling flexible switching of configuration sources.

[0052] When the unified parameter acquisition unit starts, it loads all product parameter configuration data for that business type from the rule management layer in batches, based on the business type. The loaded parameter data is divided into two categories: static parameters and dynamic parameters. Static parameters are relatively fixed configuration items, including payment rates, channel limits, timeout thresholds, etc. These parameters are cached in the local memory of the node where the unit is located after loading, and are kept synchronized with the data of the rule management layer through a timed refresh mechanism (refreshed every 5 minutes by default). Dynamic parameters are parameters that change with the business status, including real-time limits, risk control switches, etc. These parameters are queried from the rule management layer in real time as needed for each transaction processing, and are not cached locally.

[0053] Parameter configuration data is stored in the rule management layer in the form of structured records. The fields and their descriptions in each record are as follows: The member row number field (bk_id) identifies the member row to which this configuration belongs; the product number field (pd_no) identifies the business product to which this configuration belongs, and together with the member row number, forms the primary key of this table; the English abbreviation field (eng_shrtnm) stores the English abbreviation of the product; the product name field (pd_nm) stores the full name of the product; the contract type field (sign_typ) identifies the contract authentication type required for this product; the accounting flag field (acct_flg) indicates whether this product involves accounting processing; the reconciliation flag field (recon_flg) indicates whether this product requires reconciliation; and the product status field (pd_no) indicates whether the product is in reconciliation. The `_sts` field indicates whether the product is currently available, disabled, or under maintenance. The `shlvs_dt` and `udcrg_dt` fields indicate the valid date range of the product, used for timeliness filtering when loading parameters. The `login_flg` field indicates whether the product requires login authentication. The `hol_oprt_flg` field indicates whether operation is allowed on holidays. The `pd_dsc` field stores supplementary description information of the product. The `crt_tms` and `upd_tms` fields record the creation and last modification times of the configuration.

[0054] The parameter loading and validation method of this unit executes the following logic: Based on the input member row number and product number, a query condition is constructed, and the corresponding product parameter configuration record is first queried from the local cache. If the cache is hit, the record is directly retrieved. If the cache is not hit, the parameter query interface of the rule control layer is called to retrieve the corresponding complete record from the parameter configuration table. After retrieving the parameter record, the following validation logic is executed: First, a non-empty check is performed to check if any of the required fields (such as product status field and contract type field) contain empty values; second, a format check is performed to check if the field values ​​conform to the predefined format requirements, such as whether the date format field is a valid yyyy-MM-dd format; third, a range check is performed to check if the numeric fields (such as rate and limit) are within the allowed numerical range; finally, an enumeration validity check is performed to check if the field values ​​are in the allowed enumeration value set. After all checks pass, the complete parameter object is returned to the caller; if any check fails, a parameter exception is thrown with specific error information, and the transaction processing flow is terminated.

[0055] 3.3 Transaction Deduplication Unit like Figure 4 As shown, the transaction deduplication unit is used to perform idempotent control and duplicate request interception based on a configurable composite unique key. The implementation of this unit relies on two types of data tables stored in the rule management layer: a deduplication rule configuration table and a deduplication detail table.

[0056] The deduplication rule configuration table stores the deduplication rule definitions for different business products. Each record contains the following fields and their descriptions: The Product ID field (pd_no) identifies the business product to which the rule applies; the Rule Type field (chk_rule_typ) identifies the classification type of the rule; the Rule Code field (chk_rule_cd) serves as the unique identifier for the rule; the Rule Column Name field (chk_fld_col_nm) stores the business field names required to generate the composite unique key, with multiple field names connected by the separator "|", such as "ACCT_NO|TXN_DT|AMOUNT". The specific content of this field determines which field values ​​are extracted from the transaction request object and their concatenation order; the Creation Timestamp field (crt_tms) and Update Timestamp field (upd_tms) record the creation and last modification times of the rule.

[0057] The deduplication details table stores successfully processed transaction records. Each record contains the following fields and their descriptions: The Product ID field (pd_no) identifies the business product to which the transaction belongs; the Deduplication Rule Code field (chk_rule_cd) identifies the deduplication rule used for the transaction; the Deduplication Field Value field (chk_fld_col_val) stores a composite unique key string generated by concatenating the business fields specified by the Deduplication Field Name field in the Deduplication Rule Configuration Table; the Transaction Date field (tx_dt) stores the business date of the transaction; the Transaction Time field (tx_tm) stores the specific time of the transaction; and the Creation Timestamp field (crt_tms) and Update Timestamp field (upd_tms) record the creation and last modification times of the detailed record.

[0058] The composite primary key of this deduplication details table consists of four fields: product number, deduplication rule code, deduplication field value, and transaction date. It uses the database's unique constraint mechanism to deduplicate transactions. When attempting to insert a record into this table, the database performs a uniqueness check based on this composite primary key. If the primary key already exists, the insertion operation fails and throws a primary key conflict exception; if the primary key does not exist, the insertion operation succeeds.

[0059] The core deduplication method execution flow of this unit is as follows: The first step is parameter validation. Verify that the incoming request object contains the necessary deduplication parameters, including the product number and deduplication rule code. If any parameter is missing or empty, a parameter exception is thrown, terminating the deduplication process.

[0060] The second step is to obtain the deduplication field configuration. Based on the product number and deduplication rule code, the corresponding deduplication rule configuration record is first retrieved from the local cache; if the cache is not found, the deduplication field column name value corresponding to the rule is retrieved from the deduplication rule configuration table of the rule management layer.

[0061] The third step is to concatenate the values ​​of the deduplication fields obtained in the second step using the delimiter "|". This results in a list of field names. The list is then iterated through, and the corresponding field values ​​are extracted from the transaction request object one by one using Java reflection. If any field value is empty, an exception is thrown, terminating the deduplication process. Finally, all extracted field values ​​are concatenated in the original field name order using the delimiter "|" to generate a composite unique key string.

[0062] Step 4: Perform deduplication insertion. Construct a deduplication detail record where the product number field is the passed-in product number, the deduplication rule code field is the passed-in deduplication rule code, the deduplication field value field is the composite unique key string generated in step 3, the transaction date field is the current business date, and the transaction time field is the current time. Attempt to insert this record into the deduplication detail table. If the insertion operation is successful, it means that the composite primary key does not exist in the database, the current transaction is the first occurrence, and it is determined to be non-duplicate. A success flag indicating non-duplicate is returned to the caller. If a primary key conflict exception is captured in the database, it means that the composite primary key already exists in the deduplication detail table, the current transaction is a duplicate request, it is determined to be duplicate, a failure flag indicating duplicate is returned to the caller, and the transaction is intercepted.

[0063] In high-concurrency scenarios, this deduplication mechanism relies on the database layer's atomicity guarantee for INSERT statements and the uniqueness constraint of composite primary keys. When multiple concurrent transactions attempt to insert records with the same composite primary key, the database management system's transaction isolation mechanism ensures that these INSERT operations are serialized, allowing only one transaction's INSERT operation to execute successfully, while the remaining transactions will receive a primary key conflict exception. The application layer does not require additional distributed lock control or application-level locking; it relies entirely on the underlying database mechanism to arbitrate concurrency conflicts.

[0064] 3.4 Sleep Scheduling Unit like Figure 5 As shown, the sleep scheduling unit is used to perform asynchronous waiting, polling, or retry operations according to a configurable delay strategy. The implementation of this unit relies on the delay scheduling parameter configuration table stored in the rule management layer.

[0065] The delay scheduling parameter configuration table is stored in the form of structured records. Each record contains the following fields and their descriptions: The member row number field (bk_id) identifies the member row to which this configuration belongs; the product number field (pd_no) identifies the business product to which this configuration belongs; the initial delay duration field (fst_dlay_dur) identifies the duration of the thread's first sleep after the transaction is first initiated, in seconds; the maximum number of retries field (max_rtry_times) identifies the maximum number of retries for result polling; if the final result is not obtained after reaching this number, a timeout is determined; the retry interval strategy field (rtry_itrv_strtg) identifies the type of interval strategy used for this retry, with possible values ​​including FIXED (fixed interval), LINEAR (linear increment), and EXPONENTIAL (exponential increment); Basic The interval duration field (base_itrv_dur) stores the base duration for interval calculation, in seconds. The meaning of this field varies slightly depending on the strategy. The increment step size field (incm_step_unit) is used to calculate the increment for each increment in a linear increment strategy, in seconds. It only takes effect when the strategy is LINEAR. The total timeout duration field (totl_ovtm_dur) identifies the maximum allowed total waiting time, in seconds. A timeout is determined when the accumulated waiting time exceeds this value. The validity field (whth_eff) indicates whether the configuration record is currently in effect. The creation timestamp field (crt_tms) and update timestamp field (upd_tms) record the creation and last modification times of the configuration.

[0066] The execution flow of the core scheduling method in this unit is as follows: The first step is to send the transaction request to a third-party institution and obtain the query credentials (such as serial number, query identifier, etc.) returned by the third-party institution.

[0067] The second step is to load the corresponding delay scheduling parameter configuration record of the service from the rule control layer according to the product number, and obtain parameters such as the initial delay duration, maximum number of retries, retry interval strategy, basic interval duration, increment step size and total timeout duration.

[0068] The third step is to initialize the total wait timer (totalWait) to 0 and the retry counter (retryCount) to 1.

[0069] Fourth step: Determine if the current retry counter is less than or equal to the maximum number of retries. If yes, enter a sleep-wait and polling loop; otherwise, proceed to step eight.

[0070] The fifth step is to calculate the sleep duration (delay) for the current loop based on the value of the retry interval policy field. Three types of retry interval policies are supported, and the specific calculation methods are as follows: When the retry interval strategy is FIXED, the sleep duration is equal to the base interval duration, and the calculation formula is: delay = base_itrv_dur.

[0071] When the retry interval strategy is LINEAR (linearly increasing strategy), the sleep duration increases linearly with the number of retries. The calculation formula is: delay = base_itrv_dur + (retryCount - 1) * incm_step_unit, where retryCount is the current retries (starting from 1); and incm_step_unit is the increment step size. For example, if the base interval is set to 10 seconds and the increment step size is set to 5 seconds, then the sleep duration for the first retry is 10 seconds, the sleep duration for the second retry is 15 seconds, the sleep duration for the third retry is 20 seconds, and so on.

[0072] When the retry interval strategy is EXPONENTIAL, the sleep duration increases exponentially by powers of 2. The calculation formula is: delay = base_itrv_dur * 2^(retryCount - 1), where the base is fixed at 2, implementing a binary exponential backoff algorithm. For example, if the base interval is set to 10 seconds, the sleep duration for the first retry will be 10 seconds, the second 20 seconds, the third 40 seconds, and so on.

[0073] Step 6: After calculating the current sleep duration, determine whether the sum of the current cumulative waiting time and the current sleep duration is greater than the total timeout duration. If it is greater, a timeout is determined, a timeout exception is returned to the caller, and the scheduling process is terminated; if it is less than or equal to, the current thread calls the Thread.sleep method to enter a sleep state, and the sleep duration is the calculated delay value.

[0074] Step 7: After the sleep period ends, the thread is automatically woken up and sends a result polling request to the third-party institution based on the query credentials obtained in Step 1 to obtain the transaction processing status. It then determines whether the polling result is in a final state (i.e., transaction successful or failed). If it is in a final state, the result is returned to the caller, and the scheduling process ends. If it is in a processing state, the retry counter is incremented by 1, the sleep duration is accumulated to the cumulative wait timer, and then the process returns to Step 4 to continue the loop.

[0075] Step 8: If the retry counter exceeds the maximum number of retries and still does not obtain the final result, return an exception result indicating that the maximum number of retries has been exceeded to the caller, and the scheduling process ends.

[0076] 4. Construction of the rule control layer The rule control layer is an independent rule management platform, employing a two-tier storage architecture combining a distributed database and a caching module. The distributed database serves as the underlying persistent storage for rule data, storing all structured rule data, including enumeration mapping tables, product parameter configuration tables, deduplication rule configuration tables, deduplication detail tables, and delay scheduling parameter configuration tables. In this embodiment, GoldenDB, a distributed relational database, is used as the underlying storage, leveraging its high availability, strong consistency, and linear scalability to ensure the security and reliability of the rule data. The caching module is built upon the distributed database, using Redis as the caching medium to cache frequently accessed rule data, reducing database query pressure and improving rule data read performance.

[0077] The rule data stored in the cache module supports two refresh mechanisms: The first strategy is an expiration / expiration policy. Each rule data stored in the caching module has a fixed expiration time, with a default expiration time of 24 hours (86400 seconds). After the expiration time, the cached data automatically becomes invalid. When a unit in the core component layer queries this rule data again, the caching module returns a miss due to data invalidation. At this point, the caching module automatically reloads the latest version of the rule data from the distributed database, synchronously writes it to the caching module, and resets the expiration time. This strategy is suitable for scenarios where rule data changes infrequently, reducing the query pressure on the database while ensuring eventual consistency.

[0078] The second strategy is proactive invalidation. When operations personnel modify any rule configuration data in the visual management interface of the rule control layer, the management backend, while performing a database update operation to persist the changes to the distributed database, immediately sends an invalidation command (Redis's DEL command) to the cache module via the cache refresh tool, causing the corresponding cached data in the cache module to be cleared instantly. Subsequently, when a unit in the core component layer queries this rule data again, the cache module returns a miss state because the data has been cleared, and then reloads the latest version of the data from the distributed database and refreshes the cache module. This strategy is suitable for scenarios where rule changes need to take effect immediately, ensuring that the rule data is reloaded in the next query after the update.

[0079] The combined use of these two refresh mechanisms allows the rule control layer to ensure data consistency while also maintaining query performance. The expiration / expiration policy, as a fallback mechanism, ensures eventual consistency of cached data even if the proactive expiration policy fails to trigger due to abnormal circumstances, through a timed expiration mechanism.

[0080] Example 2 This embodiment details the specific implementation of the construction method for the layered decoupling system of general basic components for bank intermediary business provided by the present invention. For example... Figure 6 As shown, this construction method establishes a three-layer architecture of business layer, core component layer and rule control layer and their standardized interaction relationships through a series of orderly construction steps.

[0081] Step S1: Build the business layer Step S1 specifically includes the following sub-steps: Sub-step S11 provides multiple intermediate business subsystems, including a payment processing subsystem, an interbank interconnection subsystem, and a bank-insurance integration subsystem. Each intermediate business subsystem executes its own specific business logic, including but not limited to payment order management in the payment processing business, interbank transfer process control in the interbank interconnection business, and insurance policy status management in the bank-insurance integration business. These subsystems do not include general basic processing logic such as enumeration conversion, parameter validation, transaction deduplication, and delay scheduling.

[0082] Sub-step S12 involves deploying the common basic component module as a JAR package to the Maven remote repository. Specifically, the developers compile, package, and upload the independent project ssbp-component-common to the enterprise's internal Maven remote repository server using the Maven deploy command. This JAR package contains all the compiled class files and configuration files for the enumeration transformation unit, parameter unified acquisition unit, transaction deduplication unit, and sleep scheduling unit.

[0083] Sub-step S13 involves declaring the dependencies and version numbers of the common basic component modules in the project object model file (pom.xml) of each intermediate business subsystem. The specific format of the dependency declaration is as follows: add a dependency sub-node under the dependencies node, set groupId to com.sccba.xbus.ssbp, artifactId to ssbp-component-common, and version to the version number variable of the component library, ${ssbp.component.version}.

[0084] Sub-step S14 configures each intermediate business subsystem to automatically pull common basic component modules from the Maven remote repository during compilation. Specifically, the compile phase of the Maven build lifecycle is configured in the subsystem's pom.xml file. During this phase, the Maven build tool automatically downloads the specified version of the ssbp-component-commonJAR package from the Maven remote repository to the local repository based on the dependencies declared in sub-step S13, and adds it to the project's classpath, enabling the subsystem to load and call the functional unit classes in the common basic component module at runtime.

[0085] Through the above sub-steps, each intermediate business subsystem introduces a common basic component module through the Maven dependency management mechanism, enabling it to call the standardized interfaces provided by the common basic component module at runtime without having to copy or maintain the source code of any common basic capabilities in the local project.

[0086] Step S2: Construct the core component layer Step S2 specifically includes the following sub-steps: Sub-step S21 involves building a common technical foundation independent of the deployment of each intermediate business subsystem. This common technical foundation is an independent Java project that does not depend on any specific business system and does not contain any business-related logic code. This project is independently version-managed and built / released.

[0087] Sub-step S22 involves deploying the enumeration conversion unit, unified parameter acquisition unit, transaction deduplication unit, and sleep scheduling unit within the public technology foundation. Specifically, Java source files for four core classes are created in the source code directory of the public technology foundation. The class names and functional definitions for each class are as follows: The `EnumConvertComponent` class is created as the implementation class for the enumeration conversion unit; the `ParamFetchComponent` class is created as the implementation class for the unified parameter acquisition unit; the `DupChkComponent` class is created as the implementation class for the transaction deduplication unit; and the `SleepScheduleComponent` class is created as the implementation class for the sleep scheduling unit.

[0088] Sub-step S23 configures the enumeration mapping relationship storage structure of the enumeration conversion unit. Specifically, an enumeration mapping relationship table is created in the distributed database of the rule control layer. The fields of this table are defined as follows: product number (pd_no), item key (itm_key), original code (orgn_cd), original description (orgn_dsc), target code (targ_cd), target description (targ_dsc), creation timestamp (crt_tms), and update timestamp (upd_tms). The product number and item key fields serve as a composite index for this table, used for fast retrieval during queries. The query logic in the EnumConvertComponent class is configured to retrieve the corresponding enumeration mapping relationship record set from this table based on the input product number and item key, and then match the original code within the record set to return the corresponding target code. Configure the unit to perform bidirectional conversion, enabling it to support both forward conversion from internal bank enumeration values ​​to third-party institution enumeration values ​​and reverse conversion from third-party institution enumeration values ​​to internal bank enumeration values. Both conversions are based on the same enumeration mapping table for query matching. The difference is that during forward conversion, the internal bank enumeration values ​​are used as the source code and the third-party institution enumeration values ​​are used as the target code for querying, while the reverse is true for reverse conversion.

[0089] Sub-step S24 configures the multi-source parameter loading logic for the unified parameter acquisition unit. Specifically, it configures the parameter loading method in the ParamFetchComponent class to support loading parameter data from three sources: database, registry center, and local configuration file. The priority order for multi-source loading is local configuration file first, followed by registry center, and then database. The parameter classification processing logic for this unit is configured, dividing the loaded parameter data into two categories: static parameters and dynamic parameters. Static parameters include relatively fixed configuration items such as payment rates, channel limits, and timeout thresholds. These parameters are cached in local memory after loading and a scheduled refresh task is configured, triggering a refresh every 5 minutes by default. During refresh, the latest data is reloaded from the rule control layer and the local cache is updated. Dynamic parameters include parameters that change with business status, such as real-time limits and risk control switches. These parameters are queried from the rule control layer in real-time on demand for each transaction and are not cached locally. The parameter validation logic for this unit is configured to perform non-empty validation, format validation, range validation, and enumeration validity validation on the loaded parameter data in sequence. The validation rules match the field definitions in the product parameter configuration table. Configure the cache-first query logic for this unit so that when it receives a query request, it first looks up the parameter data in the local cache based on the member row number and product number. If the cache is hit, it returns the data directly. If the cache is not hit, it sends a query request to the rule control layer.

[0090] Sub-step S25 configures the storage structure for the deduplication rules and the storage structure for the deduplication details table of the transaction deduplication unit. Specifically, two data tables are created in the distributed database of the rule control layer: a deduplication rule configuration table and a deduplication details table. The fields of the deduplication rule configuration table are defined as follows: product number (pd_no), deduplication rule type (chk_rule_typ), deduplication rule code (chk_rule_cd), deduplication field column name (chk_fld_col_nm, multiple field names separated by "|"), creation timestamp (crt_tms), and update timestamp (upd_tms). The fields of the deduplication details table are defined as follows: product number (pd_no), deduplication rule code (chk_rule_cd), deduplication field column value (chk_fld_col_val), transaction date (tx_dt), transaction time (tx_tm), creation timestamp (crt_tms), and update timestamp (upd_tms). The composite primary key of the deduplication details table is configured as a combination of four fields: product number, deduplication rule code, deduplication field value, and transaction date. Uniqueness control is achieved through primary key constraints in the database. The deduplication execution logic in the `DupChkComponent` class is configured to perform the following sequence: Retrieve the corresponding deduplication field column name and value from the deduplication rule configuration table based on the input product number and deduplication rule code; Split the deduplication field column name and value using the separator "|" to obtain a list of field names; Extract the field values ​​corresponding to each field name from the transaction request object using reflection and concatenate them to generate a composite unique key string; Associate the composite unique key string with fields such as product number, deduplication rule code, current transaction date, and current transaction time to construct a deduplication details record and attempt to insert it into the deduplication details table; If the insertion is successful, the transaction is determined to be unique; if a primary key conflict exception is detected, the transaction is determined to be duplicated.

[0091] Sub-step S26: Configure the storage structure for delay scheduling parameters of the sleep scheduling unit. Specifically, create a delay scheduling parameter configuration table in the distributed database of the rule control layer. The fields of this table are defined as follows: member row number (bk_id), product number (pd_no), initial delay duration (fst_dlay_dur), maximum number of retries (max_rtry_times), retry interval policy (rtry_itrv_strtg, optional values ​​are FIXED, LINEAR, EXPONENTIAL), base interval duration (base_itrv_dur), increment step size (incm_step_unit, only effective when the policy is LINEAR), total timeout duration (totl_ovtm_dur), validity status (whth_eff), creation timestamp (crt_tms), and update timestamp (upd_tms). Configure the scheduling execution logic in the SleepScheduleComponent class to perform the following sequence of operations: After sending the transaction request to the third-party institution, load the corresponding delay scheduling parameter record from the delay scheduling parameter configuration table according to the product number; put the current thread into a sleep state according to the value of the initial delay duration field; wake up after the sleep ends and initiate result polling; if the polling result is in the final state, return the result; if the polling result is in the process state, calculate the next delay duration according to the value of the retry interval policy field, the calculation formula is as described in Examples 1 and 3 above, and determine whether the cumulative waiting time exceeds the value of the total timeout duration field. If it does not exceed the value, continue to sleep and wait before retrying; if it exceeds the value, return the timeout result.

[0092] Step S3: Construct the rule control layer Step S3 specifically includes the following sub-steps: Sub-step S31 involves building a distributed database as the underlying storage for rule data. Specifically, a GoldenDB distributed database cluster is deployed, and a dedicated database instance for rule management is created within this cluster. Within this instance, tables for enumeration mapping relationships, product parameter configuration, deduplication rule configuration, deduplication details, and delay scheduling parameters are created. The structure definitions of each table are as described in sub-steps S23, S24, S25, and S26 above. This distributed database serves as persistent storage for all rule data, ensuring high availability and consistency.

[0093] Sub-step S32 involves building a caching module on top of the distributed database. Specifically, a Redis caching cluster is deployed, and the caching module is configured to cache frequently accessed rule data, including enumerating mapping relationships, parameter configurations, deduplication rule configurations, and delay scheduling parameter configurations, in order to reduce the query pressure on the distributed database.

[0094] Sub-step S33 configures the rule data stored in the cache module to support an expiration and refresh mechanism. Specifically, when writing rule data to the cache module, the cache module sets a fixed expiration time for each piece of data, with a default expiration time of 86400 seconds (24 hours). When cached data reaches its expiration time, the cache module automatically deletes it. Subsequently, when a unit in the core component layer queries this data, the cache module returns a miss status and automatically reloads the latest version of the data from the distributed database, writes it to the cache module, and resets the expiration time.

[0095] Sub-step S34 configures the rule data stored in the cache module to support an active invalidation and refresh mechanism. Specifically, a cache refresh tool is built, which provides a cache invalidation interface. The management backend of the rule control layer is configured to call this interface when the rule data is updated. The implementation logic of this interface is to send a data deletion command (Redis's DEL command) for the specified key to the cache module, immediately clearing the corresponding old version data in the cache module. After configuration, when the rule data is updated in the rule control layer, the corresponding old data in the cache is immediately cleared through the active invalidation mechanism, and the core component layer reloads the latest data from the distributed database on the next query.

[0096] Sub-step S35 configures the rule management layer to support dynamic configuration and real-time application of rule data. Specifically, a visual management interface for the rule management layer is developed, providing CRUD (Create, Read, Update, Delete) operations for enumerated mapping relationships, parameter configurations, deduplication rules, and delay scheduling parameters. After operations personnel modify any rule data through this interface, the management backend performs the following operations in sequence: updates the modified data to the distributed database and commits the transaction; calls the invalidation interface of the cache refresh tool to clear the corresponding old version data in the cache module. Through the above operation sequence, changes to rule data take effect immediately upon modification and submission to all business subsystems.

[0097] Step S4: Establish a data interaction channel between the core component layer and the rule control layer. Step S4 specifically includes the following sub-steps: Sub-step S41 configures each unit in the core component layer to query rule data through the cache module when executing corresponding functions. Specifically, client instances of the cache module are uniformly injected into the EnumConvertComponent, ParamFetchComponent, DupChkComponent, and SleepScheduleComponent classes. When each unit needs to obtain rule data, it first calls the query method of the cache module, using the unique key of the rule data as the query parameter to initiate a query request.

[0098] Sub-step S42 configures the caching module to load rule data from the distributed database when a match is not found. Specifically, the query processing logic of the caching module is configured as follows: When the caching module receives a query request, it first checks whether data with the corresponding key exists in the local cache; if it exists, it directly returns the cached data; if it does not exist, the caching module automatically initiates a query request to the distributed database to obtain the latest version of the rule data, returns the obtained data to the caller, and simultaneously writes the data to the caching module and sets an expiration time.

[0099] Sub-step S43 configures the rule management layer to invalidate the corresponding cached data in the caching module through expiration or active invalidation when rule data is updated. Specifically, the expiration mechanism described in sub-step S33 and the active invalidation mechanism described in sub-step S34 are configured as a dual-protection mechanism running in parallel. When maintenance personnel modify rule data in the management interface, the active invalidation mechanism is triggered, immediately clearing the old data in the cache and ensuring that data changes take effect immediately. If the active invalidation mechanism fails to trigger successfully due to network anomalies or other reasons, the expiration mechanism serves as a fallback, automatically invalidating the cached data after its expiration time and reloading the latest data to ensure that the cached data is ultimately consistent with the database data.

[0100] Through the above sub-steps, a standardized data interaction channel is established between each unit of the core component layer and the rule control layer. This channel is a one-way query channel, through which the core component layer obtains rule data without directly modifying the rule data.

[0101] Step S5: Establish the calling relationship between the business layer and the core component layer. Step S5 specifically includes the following sub-steps: Sub-step S51 exposes the standardized interfaces of the general basic component module to each intermediate business subsystem. Specifically, a set of public interface classes are defined in the general basic component module, and each interface class declares method signatures that can be called externally. The enumeration conversion unit exposes the doExecute(SspCodemap) method, the parameter unified acquisition unit exposes the doExecute(StringbkId,StringpdNo) method, the transaction deduplication unit exposes the doExecute(DupChkParam) method, and the sleep scheduling unit exposes the pollWithDelay(TransactionRequest,ScheduleConfig) method. All methods are declared as public and standard Java documentation comments are added to explain the meaning of parameters, return value types, and exception conditions.

[0102] Sub-step S52 configures each intermediate business subsystem to call the standardized interface corresponding to the general basic component module based on the current transaction scenario after receiving a transaction request. Specifically, in the business code of each intermediate business subsystem, object references of each functional unit class in the general basic component module are obtained through Spring framework dependency injection (@Autowired annotation) or manual instantiation. The corresponding interface method is selected to be called based on the business type of the transaction request and the current processing stage. For example, when receiving a response from a third-party institution requiring enumeration conversion, the doExecute method of the enumeration conversion unit is called; when parameter validation is required, the doExecute method of the parameter unification unit is called.

[0103] Sub-step S53 configures each intermediate business subsystem to receive standardized processing results returned by the core component layer. Specifically, it configures the return value processing logic for each interface method: the return value of each interface method is encapsulated using a unified data structure, including three parts: execution result status code, result description information, and business data object. After calling the interface method, each intermediate business subsystem extracts the execution result status code from the return value. If the status code indicates success, the business process continues; if the status code indicates failure, exception handling is performed based on the error information.

[0104] Step S6: Configure the complete transaction processing flow Step S6 specifically includes the following sub-steps: Sub-step S61 configures each intermediate business subsystem to execute its own proprietary business logic based on the standardized processing result returned by the core component layer. Specifically, the business code of each intermediate business subsystem executes its own specific business processing based on the processing result returned by the core component layer—including the standard enumeration value after enumeration conversion, the parameter object that passed the verification, the deduplication result identifier, the final state result obtained by polling, etc., including but not limited to updating the local transaction status table, recording business audit logs, sending transaction notifications to customers, and calling other internal services.

[0105] Sub-step S62 configures the complete cross-institutional intermediary transaction process. Through the construction of steps S1 to S5 above, the complete transaction processing flow of each intermediary business subsystem is configured as follows: First, the business subsystem receives transaction requests initiated by the front-end channel or back-end, and calls the standardized interface corresponding to the general basic component module according to the current transaction scenario; if the transaction involves data interaction with a third-party institution, the enumeration conversion unit is called to complete the bidirectional conversion of enumeration values; the unified parameter acquisition unit is called to batch load transaction parameters and complete parameter verification; the transaction deduplication unit is called to perform idempotent control and intercept duplicate requests; if asynchronous polling is required, the sleep scheduling unit is called to execute delayed waiting and result polling; after completing the above general logic, the general basic component module sends the standardized processing result back to the business subsystem; after receiving the processing result, the business subsystem executes its own exclusive business logic to complete the complete transaction process; when the general rules need to be iteratively optimized, only the corresponding configuration items need to be updated in the rule control layer, and all intermediary business subsystems will automatically take effect without requiring business code modification or version release.

[0106] Through the above steps S1 to S6, a layered decoupling system for general basic components of bank intermediary business is fully constructed, realizing the complete separation, standardized encapsulation, unified management and control, and on-demand reuse of general basic capabilities from various business systems.

[0107] Example 3 This embodiment details the specific working method of the transaction deduplication unit of the present invention in high-concurrency scenarios of banking intermediary business.

[0108] In interbank transfer transactions within banking intermediary services, the same transfer request may be repeatedly sent to the system within a very short time (milliseconds) due to network jitter, retrying by the caller, or other reasons. If the system processes all duplicate requests, it will lead to a serious production accident involving duplicate fund transfers. The transaction deduplication unit of this invention achieves idempotent control of transactions in high-concurrency scenarios through database unique constraints and atomic INSERT operations. Its specific working method is as follows.

[0109] The composite primary key of the deduplication details table consists of four fields: product number (pd_no), deduplication rule code (chk_rule_cd), deduplication field value (chk_fld_col_val), and transaction date (tx_dt). This primary key constraint is declared as PRIMARYKEY at the database level. When multiple nodes in the application server cluster simultaneously receive two or more identical transfer requests, each node's transaction deduplication unit independently performs the following operations: First, based on the same product number and deduplication rule code, it retrieves the same deduplication field column name configuration from the deduplication rule configuration table; second, it extracts the same business field values ​​from each request object and concatenates them to generate an identical composite unique key string; third, using the current transaction date as the transaction date field value, it constructs multiple deduplication details records with identical composite primary keys; finally, each node initiates an INSERT operation to the database almost simultaneously.

[0110] The database management system handles concurrent INSERT operations as follows: Each INSERT operation is executed serially under the database transaction isolation level. The first INSERT operation successfully executes, inserting the record corresponding to the composite primary key into the data page and committing the transaction. The database returns an affected row count of 1. The application layer determines the transaction is not duplicated and allows the request to continue with subsequent transfer processing. When the second INSERT operation arrives, the database detects that the composite primary key already exists in the table, violating the uniqueness constraint and throwing an SQLIntegrityConstraintViolationException (or a similar primary key conflict exception). The application layer's transaction deduplication unit catches this exception using a try-catch block, determines the current request as a duplicate transaction, directly returns a duplicate identifier to the caller, and does not execute subsequent transfer deduction logic. This mechanism ensures that under any concurrency conditions, only one of multiple requests with the same composite primary key will successfully execute, while the rest are intercepted.

[0111] This mechanism pushes the complexity of concurrency control down to the database layer, avoiding the introduction of distributed locks or complex synchronization control logic at the application layer, reducing the complexity of system implementation, and making full use of mature database concurrency control protocols (such as two-phase locking protocols or multi-version concurrency control protocols) to ensure deduplication performance under high throughput.

[0112] Example 4 This embodiment details the specific calculation logic and applicable scenarios of the three configurable retry interval strategies supported by the sleep scheduling unit of the present invention.

[0113] The retry interval policy field (rtry_itrv_strtg) of the sleep scheduling unit supports three values, each corresponding to a different interval calculation method. Each business product can configure these values ​​as needed through the rule management layer. The calculation logic for each of the three policies is explained below: When the retry interval strategy field is set to FIXED, a fixed interval strategy is adopted. Under this strategy, the waiting time between each retry remains constant. The calculation of a single retry interval depends only on the base interval duration field (base_itrv_dur) and is independent of the current number of retries. The calculation formula is: delay = base_itrv_dur. This strategy is suitable for scenarios where the response time of third-party organization interfaces is stable and the processing capacity fluctuates little.

[0114] When the retry interval strategy field is set to LINEAR, a linearly increasing strategy is adopted. Under this strategy, the waiting time between each retry increases linearly with the number of retries. The calculation of a single retry interval depends on the base interval duration field (base_itrv_dur), the increment step size field (incm_step_unit), and the current retry count (retryCount), and its calculation formula is: delay = base_itrv_dur + (retryCount - 1)incm_step_unit. This strategy is suitable for scenarios where the response time of third-party organization interfaces may increase linearly with request backlog and the system load gradually increases. By gradually increasing the interval, it reduces the continuous pressure on the third-party system while ensuring eventual success.

[0115] When the retry interval strategy field is set to EXPONENTIAL, an exponentially increasing strategy is adopted. Under this strategy, the waiting time between each retry increases exponentially by a power of 2. The calculation of a single retry interval depends on the base interval duration field (base_itrv_dur) and the current retry count (retryCount), and its calculation formula is: delay = base_itrv_dur²^(retryCount-1), where the base is fixed at 2, implementing the classic binary exponential backoff algorithm. This strategy is suitable for scenarios where the processing capability of third-party institutions' interfaces is extremely unstable or where it is necessary to significantly reduce the retry frequency during fault recovery. By rapidly lengthening the interval, it effectively avoids secondary impacts on the third-party system caused by invalid high-frequency polling.

[0116] The following comparison illustrates the interval calculation results under three strategies, using a base interval of 10 seconds, an increment step size of 5 seconds (applicable to linear increment strategies), and a maximum number of retries of 5 as examples: Under the fixed interval strategy, the interval between the first to the fifth retries is 10 seconds.

[0117] Under the linear incremental strategy, the interval between the first retry is 10 seconds, the second is 15 seconds (10+(2-1)5), the third is 20 seconds (10+(3-1)5), the fourth is 25 seconds (10+(4-1)5), and the fifth is 30 seconds (10+(5-1)5).

[0118] Under the exponentially increasing strategy, the interval between the first retry is 10 seconds (102^0), the second is 20 seconds (102^1), the third is 40 seconds (102^2), the fourth is 80 seconds (102^3), and the fifth is 160 seconds (102^4).

[0119] During execution, the sleep scheduling unit also performs a total timeout check. After calculating the single retry interval, this interval is added to the cumulative wait timer, and it is checked whether the cumulative wait time exceeds the maximum wait time specified in the total timeout duration field (totl_ovtm_dur). If it does, the scheduling process is immediately terminated and a timeout exception result is returned to avoid unlimited waiting that could lead to long-term occupation of thread resources. This total timeout check is performed in every retry cycle, not just after the maximum number of retries is reached, to ensure that the total timeout limit is not exceeded at any retry node.

[0120] Example 5 This embodiment details the specific working method of the dual-strategy cache refresh mechanism under the "distributed database + cache" two-level storage architecture adopted by the rule control layer of this invention.

[0121] In the rule management layer, the distributed database (GoldenDB) serves as the persistent storage for rules, while the caching module (Redis) acts as a query acceleration layer. When executing functions, each unit in the core component layer first queries the required rule data through the caching module, only accessing the distributed database if the cache misses. Data consistency between the caching module and the distributed database is ensured collaboratively through the following two strategies.

[0122] 1. Implementation of the Expiration and Invalidation Strategy Each rule data stored in the caching module includes an expiration date attribute. When data is written to the cache, the caching module sets a fixed expiration time for that data. In this embodiment, the expiration time is set to one day (86,400 seconds) by default. When the residence time of a rule data in the cache reaches this expiration time, the caching module automatically marks the data as invalid and removes it. Subsequently, when any unit in the core component layer initiates a query request for that rule data to the caching module, the caching module returns a miss status because the data has been removed. The caching module then initiates a query request to the distributed database to obtain the latest version of the rule data, returns the latest data to the caller, and simultaneously rewrites the latest data into the cache and resets the expiration time to one day. This strategy, as a fallback data synchronization mechanism, ensures that even if the active invalidation strategy fails to trigger normally, the cached data will not be indefinitely inconsistent with the database data.

[0123] 2. Implementation methods of proactive failure strategy When operations and maintenance personnel modify any rule configuration data in the visual management interface of the rule control layer, the system performs the following sequence of operations: 1) The management backend updates the modified rule data to the distributed database (GoldenDB), executes the transaction commit, and ensures data persistence.

[0124] 2) The management backend calls the interface provided by the cache refresh tool, passing in the unique key identifier of the rule data in the cache module. The cache refresh tool can be implemented as an independent service module deployed in the rule management platform, exposing an HTTP interface or RPC interface for the management backend to call.

[0125] 3) After receiving an invalidation request, the cache refresh tool sends a DEL command to the cache module (Redis) to delete the cached data corresponding to the specified key. After the deletion operation is executed, the old version of the rule data in the cache module is immediately cleared.

[0126] 4) Subsequently, when any unit in the core component layer needs to query the rule data for business processing, the request reaches the cache module. The cache module returns a miss status because the corresponding key has been deleted, and then initiates a query request to the distributed database to retrieve the latest version of the data that has just been updated. This latest data is then returned to the caller and rewritten into the cache module.

[0127] The combined application of the two strategies mentioned above produces the following technical effects: the proactive invalidation strategy ensures that cached data can be cleared immediately after rule changes, so that the latest version can be obtained in the next query; the expiration invalidation strategy serves as a fallback guarantee, avoiding the risk of long-term inconsistency of cached data due to failure or omission of proactive invalidation calls, thus forming a dual guarantee mechanism.

[0128] Example 6 This embodiment details the collaborative working method of the enumeration conversion unit, parameter unified acquisition unit, transaction deduplication unit, and sleep scheduling unit in the core component layer of the present invention in the complete transaction processing flow, as well as the timing and conditional relationships of data transmission between the units.

[0129] In the complete cross-institutional intermediary business transaction processing flow, the four functional units are executed sequentially according to a fixed logical order. The output of the previous unit serves as the input prerequisite for the next unit. The specific collaborative relationship is as follows: 1) A progressive defense link of "verification-deduplication" between the parameter acquisition unit and the transaction deduplication unit.

[0130] Before performing deduplication insertion, the transaction deduplication unit relies on the parameter validation results from the unified parameter retrieval unit. Specifically, after the unified parameter retrieval unit performs non-empty validation, format validation, range validation, and enumeration validity validation on the parameters of the transaction request, if any validation fails, the unified parameter retrieval unit returns a parameter exception to the caller and terminates the transaction processing flow; the transaction deduplication unit will not be invoked. Only when all validations by the unified parameter retrieval unit pass and successfully return a complete parameter object will the transaction deduplication unit be invoked to perform subsequent composite unique key generation and deduplication insertion operations. This collaborative relationship ensures that all transaction records entering the deduplication details table are valid transactions with valid parameters and compliant formats, avoiding problems such as dirty data or null value concatenation in the deduplication details table due to missing or invalid parameters.

[0131] 2) The "conversion-verification" preprocessing pipeline between the enumeration conversion unit and the parameter unified acquisition unit.

[0132] In transaction scenarios involving data exchange with third-party institutions, the parameter data loaded by the unified parameter acquisition unit from the rule control layer may include enumeration values ​​returned by the third-party institutions (such as third-party transaction status codes, third-party error codes, etc.). These third-party enumeration values ​​cannot be directly recognized and processed by the bank's internal system and must first be converted by the enumeration conversion unit. Specifically, before entering the unified parameter acquisition unit, the transaction request calls the enumeration conversion unit, which converts the third-party enumeration value into the bank's internal standard enumeration value based on the product number, item key, and original code. After conversion, the converted internal standard enumeration value is passed as part of the parameters to the unified parameter acquisition unit for subsequent parameter loading and validity verification. This collaborative relationship ensures the format compliance and identifiability of cross-institutional interaction data throughout the entire process.

[0133] 3) The “record-trace” full lifecycle traceability link between the transaction deduplication unit and the sleep scheduling unit.

[0134] Before a transaction is officially initiated, the transaction deduplication unit associates the generated composite unique key with information such as the transaction date and time, and writes it into the deduplication details table. This record serves as the unique identifier for the transaction throughout the entire process. When a transaction involves third-party result polling (i.e., when the sleep scheduling unit needs to be called), the sleep scheduling unit continuously uses the composite unique key or transaction serial number to query the status when initiating the polling request, ensuring that the same transaction can be accurately located during the polling process. Throughout the asynchronous waiting and polling cycle of the entire transaction, the transaction identifier recorded in the transaction deduplication unit and the query identifier used by the sleep scheduling unit remain consistent, ensuring that the same asynchronous transaction can be uniquely traced and its status tracked throughout its entire lifecycle.

[0135] 4) The order in which each unit is called in the complete transaction processing flow.

[0136] Based on the above collaborative relationships, the calling order of each unit in the complete cross-institutional intermediary business transaction processing flow is as follows: First, the enumeration conversion unit is called to convert third-party enumeration values ​​to the bank's internal standard enumeration values; second, the parameter unified acquisition unit is called to load and validate multi-source parameters; after parameter validation, the transaction deduplication unit is called to perform idempotency control and intercept duplicate requests; after transaction deduplication is passed, a transaction request is initiated to the third-party institution. If asynchronous polling of results is required, the sleep scheduling unit is called to perform delayed waiting and result polling; finally, the processing result is returned to the business subsystem. The above sequence constitutes a complete preprocessing link, and any failure result returned at any stage will terminate the execution of subsequent stages.

[0137] Example 7 This embodiment details the closed-loop data interaction relationship between the core component layer and the rule control layer of the present invention, as well as the multi-component linkage and unified risk control capability achieved under the support of this closed-loop mechanism.

[0138] 1. Collaborative closed loop between the core component layer and the rule control layer The core component layer and the rule control layer are connected through standardized data query interfaces, forming a collaborative closed loop of "centralized rule management—on-demand component invocation—real-time data synchronization." This closed loop operates as follows: In terms of centralized rule management, the rule control layer, as the single source of facts for all rule data, stores all enumeration mapping relationships, parameter verification rules, deduplication rules, and scheduling parameters in a unified distributed database. Each rule data is associated through the product number, forming a complete rule set with the product number as the core dimension.

[0139] Regarding on-demand component invocation, the four units in the core component layer request rule data from the rule management layer through a unified query interface when executing their respective functions. The enumeration transformation unit queries the enumeration mapping relationship based on the product number and item key; the unified parameter acquisition unit queries the parameter configuration based on the product number; the transaction deduplication unit queries the deduplication field configuration based on the product number and deduplication rule code; and the sleep scheduling unit queries the delay scheduling parameters based on the product number. Each unit obtains its required portion of rule data independently, without interference from others.

[0140] Regarding real-time data synchronization, the rule management layer employs a dual-strategy cache refresh mechanism—combining expiration and proactive invalidation—as described in Example 4 to ensure that rule data can be retrieved by each unit in real time after an update. When operations personnel modify any rule data in the rule management layer, the modification is persisted to the distributed database, and the corresponding old version data in the cache module is immediately cleared. Each unit automatically retrieves the latest version during the next query.

[0141] The technical effects of this collaborative closed loop are: rule data is transformed from being maintained in a decentralized manner across multiple business systems to being maintained in a centralized and unified manner; hard-coded code is transformed into structured configuration data storage; and modifications are transformed from requiring a system restart to taking effect in real time.

[0142] 2. Multi-component linkage and unified risk control mechanism Building upon the aforementioned collaborative closed loop, the rule control layer enables unified regulation of multiple core components. When operations and maintenance personnel detect an abnormally high transaction failure rate at a third-party institution through the monitoring system, they can execute the following coordinated control operations via the rule control layer's visual interface: The first linked operation is to tighten the deduplication rules. The operations and maintenance personnel modify the column name of the deduplication field corresponding to this product in the deduplication rule configuration table, adding additional deduplication dimension fields (for example, adding a "payment channel" field to the original "customer number + billing month + amount"). This makes the transaction deduplication unit adopt a stricter composite unique key generation logic in subsequent transactions, preventing duplicate submissions caused by network latency from being mistakenly allowed during periods of abnormal failure rate.

[0143] The second coordinated operation involves adjusting scheduling parameters. Maintenance personnel modify the basic interval duration field corresponding to this product in the delay scheduling parameter configuration table, extending the basic interval from 10 seconds to 30 seconds. This allows the sleep scheduling unit to use a longer retry interval in subsequent transactions, avoiding excessive additional pressure on the already malfunctioning third-party system due to high-frequency polling and preventing the fault from spreading.

[0144] The third coordinated action is enhanced parameter validation. Maintenance personnel modify the validation rules corresponding to the product in the product parameter configuration table, adding extra parameter validation items (such as adding validation of the validity of third-party return codes or adding additional range restrictions on transaction amounts). This enables the unified parameter acquisition unit to perform more rigorous filtering and validation of third-party interaction data in subsequent transactions.

[0145] All three of the above-mentioned linked operations are completed in the same management interface of the rule control layer. After the modification is submitted, it takes effect immediately through the cache active invalidation mechanism. No code modification or system restart is required in each business subsystem, and the changes take effect uniformly across the entire business line.

[0146] Example 8 This embodiment illustrates the specific implementation effects of the technical solution of the present invention in three major intermediary business scenarios: bank bill payment, interbank interconnection, and bank-insurance integration.

[0147] 1. Bill payment service scenario In bill payment scenarios, banks need to interact with multiple payment institutions such as water, electricity, gas, and telecommunications companies. The enumeration values ​​for transaction status codes, error codes, and business type codes vary among these institutions. Traditionally, this requires writing separate adaptation code for each institution. After implementing this invention, the enumeration conversion unit uniformly handles bidirectional adaptation of enumeration values ​​across multiple payment institutions. The mapping relationship between the original codes of each payment institution and the bank's standard codes is centrally stored in the enumeration mapping table of the rule control layer. Maintenance personnel can complete the enumeration adaptation for new institutions simply through configuration, without writing adaptation code. The unified parameter acquisition unit standardizes the reading of core parameters such as payment rates, channel limits, and transaction timeouts, unifying the parameter verification standards across all channels and fundamentally eliminating transaction failures caused by inconsistent parameter configurations across multiple channels.

[0148] 2. Interbank Connectivity Business Scenarios In interbank transfer scenarios, it is necessary to prevent duplicate transfers that could lead to fund discrepancies. After implementing this invention, the transaction deduplication unit achieves unified anti-duplicate management across the entire system using a four-field joint primary key: product number, deduplication rule code, composite unique key, and transaction date. In high-concurrency scenarios, it relies on database unique constraints to ensure idempotency, effectively eliminating duplicate transfers and reconciliation failures within the interbank system. In asynchronous reconciliation scenarios, the sleep scheduling unit is configured with a dynamic delay strategy, flexibly configuring fixed or linearly increasing intervals based on the response characteristics of interbank institutions. This resolves the contradiction between the pressure on the interbank system caused by short-term, high-frequency invalid polling and the delay in result feedback caused by long-term fixed polling under traditional fixed-delay strategies.

[0149] 3. Bank-Insurance Linkage Business Scenarios In the insurance application scenario of the Bank-Insurance Link (BIRL) system, the application request involves multiple round trips with the systems of various insurance companies, requiring multi-party enumeration and adaptation, parameter validation, transaction deduplication prevention, and asynchronous polling. After implementing this invention, all the above-mentioned general logic is completed by general basic component modules, and the Bank-Insurance Link subsystem only retains its own business logic such as application, cancellation, and policy inquiry. The business subsystem introduces the general basic component modules through Maven dependencies, reducing the amount of code, significantly improving the clarity of the specific business logic, and greatly reducing the online transaction anomaly rate.

[0150] 4. Effectiveness of dynamic rule control In all the above business scenarios, all operational rules of the general basic component modules are centrally and uniformly managed by the rule control layer. Subsequent operations such as adjusting the enumeration mapping relationship due to changes in third-party institution interfaces, adjusting the anti-duplicate fields and anti-duplicate duration due to changes in business requirements, and adjusting the polling interval and total timeout duration due to operation and maintenance optimization only require operation and maintenance personnel to modify the corresponding configuration items in the visual interface of the rule control layer. After the modification is submitted, it will take effect immediately to all business subsystems through the cache active invalidation mechanism. No business code needs to be modified, no version release is required, no redeployment is required, and the changes take effect in real time across all businesses.

[0151] It should be noted that the specific embodiments described above are merely preferred embodiments of the present invention, intended to elaborate on the technical solutions of the present invention so that those skilled in the art can fully understand and implement them, rather than limiting the scope of protection of the present invention. Those skilled in the art can make equivalent substitutions, modifications, or combinations of the technical features described in the above embodiments without departing from the spirit and scope defined by the claims of the present invention, or apply the above technical solutions to other similar banking intermediary business scenarios or financial data processing scenarios based on the teachings of the specification and drawings of the present invention. For example, although the background technology and the purpose of the invention mention three major categories of specific business scenarios: bill payment, interbank interconnection, and bank-insurance integration, those skilled in the art, based on the core concept of the present invention—namely, the extraction of general basic capabilities, layered decoupling, unified rule management, and component-based reuse—can apply the technical solutions of the present invention equivalently to other types of banking intermediary businesses (such as collection and payment, securities agency, custody and clearing, etc.) or even non-bank financial business systems, as long as these systems have a need for reuse of general basic capabilities for multiple coexisting businesses. Any variations or applications based on the core technical solutions described in the claims of this invention, which can be implemented without creative effort, should fall within the protection scope of this invention. The protection scope of this invention should be determined by the claims and should not be limited by the specific values, specific business scenarios, or specific technical implementation methods listed in the embodiments.

Claims

1. A layered decoupling system for general basic components of bank intermediary business, characterized in that: include: The business layer contains multiple intermediate business subsystems. Each intermediate business subsystem is used to execute its own exclusive business logic and introduces a general basic component module through a dependency management component to call the standardized interface provided by the module. The core component layer, deployed independently of each of the aforementioned intermediate business subsystems, serves as a common technical foundation and includes an enumeration conversion unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit. The enumeration conversion unit performs bidirectional conversion between internal bank enumeration values ​​and third-party institution enumeration values. The unified parameter acquisition unit loads transaction parameters from a multi-source configuration center and performs legality verification. The transaction deduplication unit performs idempotent control and duplicate request interception based on a configurable composite unique key. The sleep scheduling unit performs asynchronous waiting, polling, or retry operations according to a configurable delay strategy. The rule control layer communicates with each unit of the core component layer and is used to centrally store and maintain the rule data required for the operation of each unit of the core component layer, and supports the dynamic configuration and real-time effect of the rule data. When each unit of the core component layer performs its function, it obtains the corresponding rule data from the rule control layer in real time and executes the general basic processing logic accordingly. After receiving a transaction request, each intermediate business subsystem calls the standardized interface corresponding to the general basic component module, delegates the common processing requirements to the core component layer for execution, receives the standardized processing result returned by the core component layer, and executes its own exclusive business logic based on the result.

2. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, The enumeration conversion unit obtains the enumeration mapping relationship from the rule control layer based on the input product number and item key, prioritizes using the input original code to match the target code, and uses the default code to match again and returns the corresponding target code when the match fails.

3. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, The transaction parameters loaded by the unified parameter acquisition unit are divided into static parameters and dynamic parameters. The static parameters are cached in local memory and refreshed periodically, while the dynamic parameters are queried from the rule management layer in real time as needed for each transaction.

4. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, The transaction deduplication unit obtains a deduplication rule containing at least one deduplication field column name from the rule control layer based on the product number, extracts the field values ​​corresponding to each deduplication field from the transaction request object and concatenates them to generate a composite unique key, and writes the composite unique key and the transaction date into the deduplication detail table. The deduplication detail table uses the product number, the deduplication rule code, the composite unique key and the transaction date as a composite primary key, and achieves transaction interception through database primary key conflicts.

5. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, The delay strategy loaded by the sleep scheduling unit includes a retry interval strategy. The retry interval strategy includes at least one of a fixed interval strategy, a linear increment strategy, and an exponential increment strategy. The interval duration of the linear increment strategy is the product of the base interval duration plus the current retry count minus one and the increment step size. The interval duration of the exponential increment strategy is the base interval duration multiplied by 2 and the current retry count minus one.

6. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, The rule management layer includes a distributed database and a cache module. The rule data is stored in the distributed database. Each unit of the core component layer queries the rule data through the cache module. The rule data stored in the cache module supports two refresh mechanisms: expiration and active expiration. The active expiration mechanism is as follows: after the rule data is updated, the rule management layer sends an expiration command to the cache module, so that the corresponding cache data is cleared immediately.

7. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, Each of the intermediate business subsystems imports the common basic component module through Maven dependency management. The common basic component module is deployed in the form of a JAR package in a Maven remote repository. Each of the intermediate business subsystems declares its dependency relationship and version number on the common basic component module through the project object model file, and automatically pulls the common basic component module from the Maven remote repository during compilation.

8. The layered decoupling system for general basic components of bank intermediary business according to claim 3, characterized in that, The multi-source configuration center includes at least a database, a registration center, and a local configuration file. The priority order for the parameter unified acquisition unit to load transaction parameters from the multi-source configuration center is: local configuration file first, registration center second, and database lowest.

9. The layered decoupling system for general basic components of bank intermediary business according to claim 1, characterized in that, Before performing deduplication, the transaction deduplication unit relies on the verification result of the parameter unified acquisition unit, and only performs the composite unique key generation and deduplication insertion operation after the parameter unified acquisition unit has passed the verification.

10. A method for constructing a layered decoupling system for general basic components of bank intermediary business, characterized in that: Includes the following steps: Step S1, Building the Business Layer: Provide multiple intermediate business subsystems, each executing its own specific business logic; deploy the common basic component module as a JAR package to a Maven remote repository; declare the dependencies and version numbers of the common basic component module in the project object model file of each intermediate business subsystem; configure each intermediate business subsystem to automatically pull the common basic component module from the Maven remote repository during compilation, so that each intermediate business subsystem can import the common basic component module through the dependency management component and call the standardized interfaces provided by the common basic component module. Step S2, Construct the core component layer: Build a common technical foundation independent of the deployment of each intermediate business subsystem. Deploy an enumeration conversion unit, a unified parameter acquisition unit, a transaction deduplication unit, and a sleep scheduling unit within this common technical foundation. Configure the enumeration conversion unit to query the mapping relationship between the bank's internal enumeration values ​​and third-party institution enumeration values ​​based on the product number and item key, and perform bidirectional standardized conversion. Configure the unified parameter acquisition unit to batch load static and dynamic parameters from the rule control layer according to business type, cache the static parameters in local memory and refresh them periodically, and perform non-empty validation, format validation, range validation, and legality filtering on the parameter configuration data. Configure the transaction deduplication unit to obtain a deduplication checksum containing at least one deduplication field column name from the rule control layer based on the product number. The rules extract the field values ​​corresponding to each deduplication field from the transaction request object and concatenate them to generate a composite unique key. The composite unique key is associated with the transaction date and transaction time and written into the deduplication detail table. The product number, deduplication rule code, composite unique key, and transaction date are used as the joint primary key of the deduplication detail table. The database unique constraint realizes transaction idempotency control and duplicate request interception. The sleep scheduling unit is configured so that after the transaction request is sent to the third-party institution, it can load the delay scheduling parameters, including the initial delay duration, maximum number of retries, retry interval policy, basic interval duration, and total timeout duration, from the rule management layer. It controls the current thread to enter the sleep state according to the initial delay duration. After the sleep ends, it wakes up and initiates result polling. Retry or timeout processing is performed according to the polling result and the retry interval policy. Step S3, Construct a rule management layer: Build a distributed database as the underlying storage for rule data, which includes at least enumerated mapping relationships, parameter validation rules, transaction deduplication rules, and delay scheduling parameters; build a caching module on top of the distributed database, and configure the caching module to cache the rule data; configure the rule data stored in the caching module to support two refresh mechanisms: expiration and active expiration; configure the rule management layer to support dynamic configuration and real-time effectiveness of rule data. Step S4: Establish a data interaction channel between the core component layer and the rule management layer: Configure each unit of the core component layer to query the rule data through the cache module when performing corresponding functions; Configure the cache module to load the rule data from the distributed database when a cache miss occurs; Configure the rule management layer to invalidate the corresponding cached data in the cache module through expiration or active invalidation when the rule data is updated, so that each unit of the core component layer can obtain the updated rule data in real time and execute the corresponding general basic processing logic based on the rule data; Step S5: Establish the calling relationship between the business layer and the core component layer: expose the standardized interface of the general basic component module to each of the intermediate business subsystems; configure each of the intermediate business subsystems to call the standardized interface corresponding to the general basic component module according to the current transaction scenario after receiving a transaction request, and delegate the common processing requirements in the transaction request to the core component layer for execution; configure each of the intermediate business subsystems to receive the standardized processing result returned by the core component layer. Step S6: After receiving the standardized processing result returned by the core component layer, each intermediate business subsystem is configured to execute its own exclusive business logic based on the standardized processing result to complete the complete transaction process.

Images