Method and device for solving real-time inter-system transaction reconciliation and storage medium

Abstract

The application relates to the field of data processing, and provides an implementation method and device for solving real-time inter-system transaction reconciliation and a storage medium. The purpose is to solve the problem of low efficiency caused by the need for cleaning and conversion operation of data captured through a log file in the prior art. The main scheme comprises the following steps: real-time synchronization of upstream and downstream system transaction information; no matter whether it is a data change request of system A or system B, unified processing logic is used to complete the reconciliation operation. After the reconciliation data of the upstream and downstream systems is obtained in the HTTP service, the reconciliation data is cached through redis, because most of the reconciliation data are temporary data, the reconciliation data can be deleted after the reconciliation is completed, the rapid storage and deletion characteristics of redis are utilized, and in addition to the reasonable design of the key value, the reconciliation effect of 'taking one and reconciling one' is realized. In the traditional reconciliation method, the reconciliation data is persisted into a database table, and a timing task is started to batch process the reconciliation data.

Description

Technical Field

[0001] This invention relates to the field of data processing, and provides a method, apparatus, and storage medium for achieving real-time reconciliation of transactions between systems. Background Technology

[0002] Currently, almost all banking systems involved in accounting-related business have reconciliation modules. Traditionally, there are two methods for reconciliation: the first is next-day reconciliation. For example, the payment system sends a real-time accounting request to the core system, but due to network timeouts or other anomalies, the payment system cannot obtain the final result of the request. The payment system will then retrieve the core system's transaction reconciliation file from day T on day T+1 for verification. After verification, the day T transaction is marked as final. This next-day reconciliation approach, in today's internet business environment, has a long processing time, poor customer experience, and may lead to the risk of shortages or overpayments due to improper handling of such abnormal transactions by the payment system.

[0003] The second method is near real-time reconciliation, which involves periodically scanning the database log files of upstream and downstream systems, parsing and obtaining incremental transaction data, and then storing it uniformly in the reconciliation database for reconciliation. This reconciliation approach requires a series of data cleaning, transformation, and storage processes on the business data in the log files, which is inefficient and carries the risk of leaking sensitive business data due to the extra copy of the business data being stored. Summary of the Invention

[0004] The purpose of this invention is to solve the problem of low efficiency caused by the need for cleaning and transformation operations when capturing data through log files in the existing technology.

[0005] To achieve the above objectives, the present invention employs the following technical means:

[0006] This invention provides a method for implementing real-time reconciliation of transactions between systems, comprising the following steps:

[0007] Step 1: Upstream system A sends a request to downstream system B. The request serial number S is saved in the transaction log tables of system A and system B respectively. The serial number S is used as the reconciliation serial number of system A and system B, and is guaranteed to be unique.

[0008] Step 2: Monitor changes in the database tables of upstream system A and downstream system B through the program, and send them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems.

[0009] Step 3: After the HTTP service interface receives the request, regardless of whether it is a data change request from system A or system B, the unified processing logic is as follows: Step 4, Step 9:

[0010] Step 4: Combine the reconciliation serial number S and the system identifier as the key value, and combine the other reconciliation field information as the value value, and store them in Redis. If the key value already exists, proceed to step 5; if the key value does not exist, proceed to step 6.

[0011] The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S.

[0012] Step 5: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S, indicating that it is a data update operation.

[0013] Step 6: If the currently received request data is from system B, proceed to step 7; if the currently received request data is from system A, proceed to step 8.

[0014] Step 7: Use the system identifier of upstream system A and the reconciliation serial number S as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9.

[0015] Step 8: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9.

[0016] Step 9: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

[0017] In the above technical solution, step 2 includes the following steps:

[0018] Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3.

[0019] Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet;

[0020] Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request.

[0021] Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call the function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service.

[0022] Step 2.5: By using step 2.22.4, the real-time data changes of the transaction log in system A are captured. System B can simply repeat the steps in step 2.22.4.

[0023] The present invention also provides an apparatus for implementing real-time reconciliation of transactions between systems, comprising the following modules:

[0024] The request serial number definition module and upstream system A send a request to downstream system B. The request serial number S is saved in the transaction log tables of system A and system B respectively. The serial number S is used as the reconciliation serial number of system A and system B and is guaranteed to be unique.

[0025] The real-time synchronization module monitors changes in the database tables of upstream system A and downstream system B through a program and sends them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems.

[0026] After receiving a request from the HTTP service interface, the logic processing module handles all data change requests, regardless of whether they originate from system A or system B, using the following steps 1-6:

[0027] Step 1: Combine the reconciliation serial number S and the system identifier as the key, and combine the other reconciliation field information as the value, and store them in Redis. If the key already exists, proceed to Step 2; if the key does not exist, proceed to Step 3.

[0028] The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S.

[0029] Step 2: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S, indicating that it is a data update operation.

[0030] Step 3: If the currently received request data is from system B, proceed to step 4; if the currently received request data is from system A, proceed to step 5.

[0031] Step 4: Use the system identifier of upstream system A and the reconciliation serial number s as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6.

[0032] Step 5: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6.

[0033] Step 6: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing later. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

[0034] In the above-mentioned device, the real-time synchronization module implements the following steps:

[0035] Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3.

[0036] Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet;

[0037] Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request.

[0038] Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call the function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service.

[0039] Step 2.5: Through steps 2.2-2.4, the real-time data changes of the transaction log in system A are captured. System B can repeat the steps 2.2-2.4.

[0040] The present invention also provides a storage medium in which a processor executes a program in the storage medium to implement the above-described method for solving real-time reconciliation of transactions between systems.

[0041] Because the present invention employs the above-mentioned technical means, it has the following beneficial effects:

[0042] First, it can achieve true real-time capture of transaction data, without the need for scheduled tasks to constantly scan tables and query the database, resulting in high reconciliation efficiency, no delay, and low server resource consumption.

[0043] Second, monitor changes in upstream and downstream system database tables through Oracle database triggers, and take advantage of Oracle database's ability to call HTTP services to send the data that needs to be reconciled to the program for processing in real time.

[0044] Third, after obtaining reconciliation data from upstream and downstream systems in the HTTP service, the reconciliation data is cached in Redis. Since most of the reconciliation data is temporary, it can be deleted after reconciliation is completed. By leveraging Redis's fast storage and deletion features, coupled with a reasonable design of the key values, the "reconciliation of one item to one item" effect is achieved. In contrast, traditional reconciliation methods persist this reconciliation data to a database table and then start a scheduled task to process this reconciliation data in batches, which cannot achieve true real-time reconciliation and will also frequently perform table operations, affecting performance. Attached Figure Description

[0045] Figure 1 This is a simplified diagram of the inter-system reconciliation process. Detailed Implementation

[0046] The embodiments of the present invention will be described in detail below. Although the present invention will be described and illustrated in conjunction with some specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, any modifications or equivalent substitutions made to the present invention should be covered within the scope of the claims of the present invention.

[0047] Furthermore, to better illustrate the present invention, numerous specific details are set forth in the following detailed embodiments. Those skilled in the art will understand that the present invention can be practiced without these specific details.

[0048] Example 1

[0049] This invention provides a method for implementing real-time reconciliation of transactions between systems, comprising the following steps:

[0050] Step 1: Upstream system A sends a request to downstream system B. The request serial number 's' is saved in the transaction log tables of both system A and system B. The serial number 's' is used as the reconciliation serial number for system A and system B, and is guaranteed to be unique. For example, when a customer purchases a wealth management product in a bank's wealth management system, the wealth management system needs to call the real-time deduction interface of the core system and then update the wealth management system's database table according to the success / failure result returned by the core interface. Here, the wealth management system is the upstream system A, and the core system is the downstream system B.

[0051] Step 2: Monitor changes in the database tables of upstream system A and downstream system B through the program, and send them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems. For example, when the financial system receives a purchase request and records it in the transaction log, it will trigger a database insert operation. This operation will be monitored by the trigger, and all the inserted data can be obtained. Then, the program will be pushed to process it immediately. Similarly, after the core system's transaction information is entered into the database, it will also be pushed to the same program for processing.

[0052] Step 3: After the HTTP service interface receives the request, regardless of whether it is a data change request from system A or system B, the unified processing logic is as follows: Steps 4-9:

[0053] Step 4: Combine the reconciliation serial number S and the system identifier as the key, and combine the other reconciliation field information as the value, and store them in Redis. If the key already exists, proceed to step 5; if the key does not exist, proceed to step 6. Other reconciliation fields refer to the data required for reconciliation logic processing, such as transaction status and transaction amount. The value combination is S_1000.

[0054] The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S.

[0055] Step 5: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S. This indicates a data update operation. Transaction data may initially be in a processing state and then change to a success or failure state, so it is necessary to update the final state of the transaction.

[0056] Step 6: If the currently received request data is from System B, proceed to Step 7; if the currently received request data is from System A, proceed to Step 8. Steps 7 and 8 mainly determine the order in which the reconciliation data from the upstream and downstream systems are received based on the serial number, and compare the reconciliation data received later with the reconciliation data received earlier.

[0057] Step 7: Use the system identifier of upstream system A and the reconciliation serial number S as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9.

[0058] Step 8: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9.

[0059] Step 9: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

[0060] In the above technical solution, step 2 includes the following steps:

[0061] Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3.

[0062] Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet;

[0063] Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request.

[0064] Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call the function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service.

[0065] Step 2.5: By using step 2.22.4, the real-time data changes of the transaction log in system A are captured. System B can simply repeat the steps in step 2.22.4.

[0066] Example 2

[0067] The present invention also provides an apparatus for implementing real-time reconciliation of transactions between systems, comprising the following modules:

[0068] The request serial number definition module and upstream system A send a request to downstream system B. The request serial number S is saved in the transaction serial number tables of system A and system B respectively. The serial number S is used as the reconciliation serial number of system A and system B and is guaranteed to be unique.

[0069] The real-time synchronization module monitors changes in the database tables of upstream system A and downstream system B through a program and sends them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems.

[0070] After receiving a request from the HTTP service interface, the logic processing module handles all data change requests, regardless of whether they originate from system A or system B, using the following steps 1-6:

[0071] Step 1: Combine the reconciliation serial number S and the system identifier as the key, and combine the other reconciliation field information as the value, and store them in Redis. If the key already exists, proceed to Step 2; if the key does not exist, proceed to Step 3.

[0072] The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S.

[0073] Step 2: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S, indicating that it is a data update operation.

[0074] Step 3: If the currently received request data is from system B, proceed to step 4; if the currently received request data is from system A, proceed to step 5.

[0075] Step 4: Use the system identifier of upstream system A and the reconciliation serial number S as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6.

[0076] Step 5: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6.

[0077] Step 6: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing later. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

[0078] In the above-mentioned device, the real-time synchronization module implements the following steps:

[0079] Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3.

[0080] Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet;

[0081] Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request.

[0082] Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call the function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service.

[0083] Step 2.5: Through steps 2.2-2.4, the real-time data changes of the transaction log in system A were captured. System B can repeat the steps 2.2-2.4.

[0084] Example 3

[0085] The present invention also provides a storage medium in which a processor executes a program in the storage medium to implement the method for solving real-time reconciliation of transactions between systems as described in Embodiment 1 above.

Claims

1. A method for implementing real-time reconciliation of transactions between systems, characterized in that, Includes the following steps: Step 1: Upstream system A sends a request to downstream system B. The request serial number S is saved in the transaction log tables of system A and system B respectively. The serial number S is used as the reconciliation serial number of system A and system B, and is guaranteed to be unique. Step 2: Monitor changes in the database tables of upstream system A and downstream system B through the program, and send them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems. Step 3: After the HTTP service interface receives the request, regardless of whether it is a data change request from system A or system B, the unified processing logic is as follows: Steps 4-9: Step 4: Combine the reconciliation serial number S and the system identifier as the key value, and combine the other reconciliation field information as the value value, and store them in Redis. If the key value already exists, proceed to step 5; if the key value does not exist, proceed to step 6. The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S. Step 5: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S, indicating that it is a data update operation. Step 6: If the currently received request data is from system B, proceed to step 7; if the currently received request data is from system A, proceed to step 8. Step 7: Use the system identifier of upstream system A and the reconciliation serial number S as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9. Step 8: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 9. Step 9: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing later. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

2. The method for implementing real-time reconciliation of transactions between systems according to claim 1, characterized in that, Step 2 includes the following steps: Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3. Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet; Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request. Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service. Step 2.5: Steps 2.2-2.4 were used to capture the real-time data changes of the transaction log in System A. System B can repeat the steps 2.2-2.

4.

3. An apparatus for resolving real-time reconciliation of transactions between systems, characterized in that, Includes the following modules: The request serial number definition module and upstream system A send a request to downstream system B. The request serial number S is saved in the transaction serial number tables of system A and system B respectively. The serial number S is used as the reconciliation serial number of system A and system B and is guaranteed to be unique. The real-time synchronization module monitors changes in the database tables of upstream system A and downstream system B through a program and sends them to the HTTP service in real time to achieve real-time synchronization of transaction information between the upstream and downstream systems. After receiving a request from the HTTP service interface, the logic processing module handles all data change requests, regardless of whether they originate from system A or system B, using the following steps 1-6: Step 1: Combine the reconciliation serial number S and the system identifier as the key, and combine the other reconciliation field information as the value, and store them in Redis. If the key already exists, proceed to Step 2; if the key does not exist, proceed to Step 3. The request from upstream system A has the key value A_S, and the request from downstream system B has the key value B_S. Step 2: If the data being requested belongs to system A, then update the value of the key A_S; if the data being requested belongs to system B, then update the value of the key B_S, indicating that it is a data update operation. Step 3: If the currently received request data is from system B, proceed to step 4; if the currently received request data is from system A, proceed to step 5. Step 4: Use the system identifier of upstream system A and the reconciliation serial number S as the key value A_S, and check again whether the key value A_S exists in Redis. If it exists, retrieve the value information corresponding to the key value A_S and compare it with the data currently received from downstream system B, and execute the reconciliation logic. If it does not exist, use system B and the reconciliation serial number B_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6. Step 5: Use the system identifier of downstream system B and the reconciliation serial number S as the key value B_S, and check again whether the key value B_S exists in Redis. If it exists, retrieve the value information corresponding to the key value B_S and compare it with the data currently received from upstream system A, and execute the reconciliation logic. If it does not exist, use system A and the reconciliation serial number A_S as the key value, and the reconciliation field data currently received as the value value, store it in Redis, and proceed to step 6. Step 6: Delete the successfully reconciled data from Redis. For the data that failed to reconcile, persist it to the reconciliation error table and issue an early warning, then delete it from Redis for easier processing later. For data in Redis that has not been reconciled, set a threshold and reconcile the Redis data that exceeds the threshold time as a failed transaction. Delete the data after successful reconciliation.

4. The apparatus for implementing real-time reconciliation of transactions between systems according to claim 3, characterized in that, The real-time synchronization module is implemented by following these steps: Step 2.1: Develop an HTTP service interface to receive requests for real-time capture of database table changes, and then reconcile these changed data. The reconciliation process begins in step 3. Step 2.2: Create an ACL access control file using the administrator account of the upstream system A database, configure the domain name, IP address, and port for the ACL to access the HTTP service, and grant the database user U1 of the upstream system A execution permission for the UTL_HTTP packet; Step 2.3: Create a function or stored procedure F1 using database user U1. In the function, use the BEGIN_REQUEST method of the UTP_HTTP packet to call the HTTP service interface and send an HTTP request. Step 2.4: Create a trigger using database user U1 to monitor the transaction log of system A. Once an insert or update operation occurs, call function or stored procedure F1 to extract the core fields that need to be reconciled and pass them to the HTTP service. Step 2.5: Steps 2.2-2.4 were used to capture the real-time data changes of the transaction log in System A. System B can repeat the steps 2.2-2.

4.

5. A storage medium, characterized in that, The processor executes the program in the storage medium to implement a method for solving real-time reconciliation of transactions between systems as described in any one of claims 1-2.

Images