CN116455918A - Method and system for verifying trial operation of new credit card core system - Google Patents

Method and system for verifying trial operation of new credit card core system Download PDF

Info

Publication number
CN116455918A
CN116455918A CN202310713751.7A CN202310713751A CN116455918A CN 116455918 A CN116455918 A CN 116455918A CN 202310713751 A CN202310713751 A CN 202310713751A CN 116455918 A CN116455918 A CN 116455918A
Authority
CN
China
Prior art keywords
transaction
white list
calling
new
judging whether
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202310713751.7A
Other languages
Chinese (zh)
Other versions
CN116455918B (en
Inventor
潘学良
赵博
郑成彬
翁国海
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jiangrongxin Technology Co ltd
Original Assignee
Beijing Jiangrongxin Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jiangrongxin Technology Co ltd filed Critical Beijing Jiangrongxin Technology Co ltd
Priority to CN202310713751.7A priority Critical patent/CN116455918B/en
Publication of CN116455918A publication Critical patent/CN116455918A/en
Application granted granted Critical
Publication of CN116455918B publication Critical patent/CN116455918B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention relates to the technical field of credit card systems, and particularly discloses a method and a system for verifying the commissioning of a new credit card core system, wherein the method comprises the steps of grouping link groups based on a unified gateway; judging whether the current transaction is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, judging whether the current transaction hits the white list, and if not, calling an old system link controller; if yes, judging whether the current transaction is a maintenance type transaction, and if not, calling a new system link controller; if yes, judging whether the current time is in the trial running transaction time, if yes, judging whether the hit white list is in a locking state, and if yes, rejecting the transaction; if not, locking the white list and calling a new system link controller; judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; if the call fails, unlocking the current white list; the method can realize transaction abnormity monitoring and back-cut.

Description

Method and system for verifying trial operation of new credit card core system
Technical Field
The invention relates to the technical field of credit card systems, in particular to a method and a system for verifying the commissioning of a new credit card core system.
Background
The credit card core development and completion process comprises 4 phases, namely an old core system calling phase, a new and old core system verification double-call phase, a new core system test operation phase and a new core system formal operation phase; in the commissioning phase of a new core system of a credit card, part of production transactions are required to verify whether the new system is feasible, part of transactions are required to verify the system by means of a white list using bank accounts of internal volunteers, and the generated profile, card profile and account profile data of the new core system are required to be synchronized to the old core system in use.
To enable the use of partial production transactions to verify whether a new system is viable, the unifying gateway distinguishes whether the transaction forwards the old core system link or the new core system link based on a locally maintained whitelist: the request transaction is forwarded to the new core system when the white list is hit, and the unified gateway analyzes, encapsulates and forwards the message according to the link processing flow of the new core system; if the white list is missed, the request transaction is forwarded to the existing card core service, and the unified gateway analyzes, encapsulates and forwards the message according to the link requirement of the old core system; at this point a request transaction will only forward either the old core system or the new core system.
During the commissioning phase of the new core system, the new core system synchronizes data to the existing old core system through the UI, for transactions which cannot be synchronized according to the UI mode, the record-broadcast module plays back and forwards the request message to the unified gateway according to the time sequence, and forwards the request message to the old core system for processing according to the forced authorization mark; therefore, the current verification method of the new core system cannot realize the functions of switching flow from time to time, monitoring and switching transaction abnormality, saving verification transaction details and synchronizing system data.
Disclosure of Invention
In view of the above problems, an object of the present invention is to provide a method for verifying the commissioning of a new credit card core system, which implements real-time traffic switching, abnormal transaction monitoring and switching, and storing verification transaction details and synchronization system data by performing a link switching mode on a gateway layer without affecting an old core system.
A second object of the present invention is to provide a credit card new core system commissioning verification system.
The first technical scheme adopted by the invention is as follows: a credit card new core system test run verification method comprises the following steps:
s100: grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers; judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, executing the next step;
s200: judging whether the current transaction hits a white list or not, if yes, executing the next step; if not, calling the old system link controller, and synchronously returning a calling result;
s300: judging whether the current transaction is a maintenance type transaction, if so, executing the next step; if not, calling the new system link controller, and synchronously returning a calling result;
s400: judging whether the current time is in the trial running transaction time, if so, further judging whether the hit white list is in a locking state, if so, rejecting the transaction, and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
s500: judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; and if the call fails, unlocking the current white list and returning abnormal information.
Preferably, the executing the financial transaction processing procedure in step S100 includes:
invoking the test operation transaction time judging interface to judge whether the current time is in the test operation transaction time range, invoking a new system link controller if the current time is in the test operation transaction time range, and synchronously returning the invoking result; if the transaction time is not in the trial operation transaction time range, rejecting the transaction and returning abnormal information.
Preferably, the determining in step S200 whether the current transaction hits the white list includes:
acquiring a white list field requesting to enter a parameter; when the white list field is not acquired, the white list is not hit; when the white list field is obtained, inquiring a white list information table according to the type and the numerical value of the white list field, if the record is inquired, hitting the white list, otherwise, missing the white list.
Preferably, the determining in step S400 whether the hit white list is in the locked state includes:
updating the data in the unlocked state corresponding to the client ID in the white list locking table into a locked state, and returning true when the number of the updated data is 0, so as to indicate that the white list is locked; otherwise, return false, indicate that the whitelist is not locked.
Preferably, the step S500 of determining whether the new system link controller is successfully invoked includes:
and acquiring a response message returned after the new system link controller is called, and judging whether the new system link controller is successfully called or not through a transaction return code in the response message.
Preferably, the step S500 of executing an asynchronous playback procedure includes the following sub-steps:
s501: assembling a request authorization transaction message;
s502: calling an old system link controller by using the assembled request authorization transaction message, and if the calling is successful, unlocking the white list and updating the playback identifier to be successful; if the call fails, retrying, and if the number of times of retrying still fails, keeping the white list locked, waiting for manual unlocking, updating the playback mark as failure, and ending the flow.
Preferably, the step S501 includes:
acquiring a request message, and inserting a forced authorization transaction identification field into the request message;
inquiring mandatory authorization transaction assembly configuration in an interface information table according to the interface number in the response message, wherein the configuration content of the mandatory authorization transaction assembly configuration comprises an assembly field name and a default value; if the configuration is empty, completing the assembly;
if the configuration is not null, the response message is analyzed according to the forced authorization transaction assembly configuration so as to obtain a request field value, and the assembly field name and the request field value or a default value are inserted into the request message to complete assembly.
Preferably, the step S501 further includes: and newly whitening list data based on the response message.
Preferably, before the step S502, the method further includes:
and constructing a test run message storage table based on the test run message, and storing the input and output messages and the assembly message of the transaction into the test run message storage table.
The second technical scheme adopted by the invention is as follows: a credit card new core system test run verification system comprises a link group module, a financial transaction judging module, a white list judging module, a maintenance transaction judging module, a test run transaction time judging module and a link controller calling judging module;
the link group grouping module is used for grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers;
the financial transaction judging module is used for judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, calling the white list judging module;
the white list judging module is used for judging whether the current transaction hits a white list or not, and if yes, the maintenance type transaction judging module is called; if not, calling the old system link controller, and synchronously returning a calling result;
the maintenance transaction judging module is used for judging whether the current transaction is a maintenance transaction, and if yes, the test operation transaction time judging module is called; if not, calling the new system link controller, and synchronously returning a calling result;
the test operation transaction time judging module is used for judging whether the current time is in the test operation transaction time, if so, further judging whether the hit white list is in a locking state, and if the white list is in the locking state, rejecting the transaction and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
the link controller call judging module is used for judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; and if the call fails, unlocking the current white list and returning abnormal information.
The beneficial effects of the technical scheme are that:
(1) The invention provides feasible, reliable and real transaction verification for the credit card new core system in the test operation stage, and realizes the real-time flow switching, abnormal transaction monitoring and back switching, and verification transaction detail and synchronous system data storage by making a link switching form at the gateway layer on the premise of not influencing the old core system.
(2) The credit card system test run flow control realized based on gateway link control has low coupling degree with other processes, and can be switched by one key when needed, and takes effect in real time; the design based on the white name bill lock can terminate the transaction in time when the test run data is wrong, avoid inputting the abnormal data, and record error information for subsequent analysis.
(3) The invention distributes transaction flow to each back-end system of the credit card by a distributed gateway system based on a MySQL configuration table according to a specified rule route, and the communication with an upstream channel and a core back-end system comprises double, http, tcp and the like.
Drawings
FIG. 1 is a schematic flow chart of a method for verifying commissioning of a new credit card core system according to an embodiment of the present invention;
FIG. 2 is a flow chart of asynchronous playback provided by one embodiment of the present invention;
FIG. 3 is a flow chart of a new whitelist of transactions according to an embodiment of the present invention;
FIG. 4 is a flow chart of a forced authorization transaction assembly provided by an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a credit card new core system commissioning verification system according to an embodiment of the present invention.
Detailed Description
Embodiments of the present invention are described in further detail below with reference to the accompanying drawings and examples. The following detailed description of the embodiments and the accompanying drawings are provided to illustrate the principles of the invention and are not intended to limit the scope of the invention, i.e. the invention is not limited to the preferred embodiments described, which is defined by the claims.
In the description of the present invention, it is to be noted that, unless otherwise indicated, the meaning of "plurality" means two or more; the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance; the specific meaning of the above terms in the present invention can be understood as appropriate by those of ordinary skill in the art.
Example 1
Fig. 1 is a schematic diagram of a method for verifying commissioning of a new credit card core system according to an embodiment of the present invention, including the following steps:
s100: grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers; judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, executing the next step;
the credit card calling old core system stage, the new core system formal operation stage, the double call new and old core system verification stage and the new core system trial operation stage are grouped based on the unified gateway, so that corresponding old system link controllers (old system links of the old core system, the query platform, the near line system and the cc gateway system are managed), new system link controllers (new system links of the new core system, the combined query system and the data service system are managed), double transmission link controllers (the transaction double transmission only new and old systems which pass through the unified gateway are controlled) and trial operation link controllers are obtained.
For the gateway system, the link is an abstract concept, and each transaction request can be abstracted into individual links in the process of calling the back-end system and the processing process before and after calling the back-end system; in different stages from the development of the credit card core to completion, the called link groups are different, each stage is abstracted once (namely, the unified gateway abstracts the link groups to form a distributed unified gateway), and the links of each stage are provided with corresponding link controllers; the link controller of the old core system stage is called as an old system link controller, the link controller of the new core system formal operation stage is called as a new system link controller, the link controller of the new and old core system verification stage is called as a double-transmission link controller, and the link controller of the new core system test operation stage is called as a test operation link controller; after the unified gateway performs abstract grouping on the link group, the channel type configuration (with the value of 1: old system link controller, 2: new system link controller, 3: double-transmission link controller, 4: test operation link controller) newly added by the configuration center is used for determining which stage is currently in, and judging whether the current stage is in the test operation stage of the new core system.
Judging whether the current transaction corresponding to the interface is a financial transaction or not through a financial transaction identifier maintained in an interface information table; executing a financial transaction processing flow when the financial transaction is performed; otherwise, entering a white list judgment logic; the interface information is shown in table 1.
Table 1 interface information table
Executing the financial transaction processing flow includes:
invoking the test operation transaction time judging interface to judge whether the current time is in the test operation transaction time range, if so, namely, the current time is the test operation transaction time, invoking a new system link controller (namely, forwarding the transaction to the new system link controller), and synchronously returning the invoking result; if the transaction is not in the trial operation transaction time range, namely, the current time is the non-trial operation transaction time, rejecting the transaction and returning error information (namely, abnormal information).
The invention sets the transaction TIME period control configuration pre-operation TIME of the test run, and the parameters are maintained on the existing system parameter page in the format of: HH: MM: SS to HH-MMSS; the maintenance can be carried out for a plurality of periods of time, and a half angle is used in the middle; "partition".
The invention sets a trial run transaction TIME inquiry interface, inquires the specific configuration content of the configuration PREFFECTIVE_TIME, and then passes the following steps: "segment time period, according to HH: MM: SS to HH: MM: and (3) analyzing the configuration of the format of the SS, returning to the transaction time period, caching by using a caching function, and refreshing the cache when maintaining the effective time.
The invention sets a trial operation transaction time judging interface, calls a trial operation transaction time inquiring interface, acquires all transaction time periods, circularly traverses the transaction time periods, judges whether the current time is in the trial operation transaction time range, and returns true if the current time is in the trial operation transaction time range, namely the current time is the trial operation transaction time; if the current time is not in the trial operation transaction time range, namely the current time is the non-trial operation transaction time, returning to false.
S200: judging whether the current transaction hits the white list, if yes, executing the next step; if not, calling the old system link controller, and synchronously returning a calling result;
in order to identify whether the request field has a field needing to check the white list, the configuration center is newly added with a default configuration for all interfaces, for example, the default white list field judges the configuration white_limit_default_fixed:
｛"cardNo":"cardNo","credAcctNo":"crcdAcctNo","credCardholderNo":"crcdCardholderNo","idNo":"idNo","custNo":"custNo","mobileNo":"mobileNo","crcdBarcode":"crcdBarcode","1nstaltOrderNo＂：＂instaltOrderNo＂｝；
when the request data has the above fields, the fields need white list judgment; when the white list field to be judged by the interface is different from the default white list field, the white list field can be configured in a white list_list_config (white list judging configuration) added in the interface information table, for example: { "cardNo": "newCardNO"; when the white list field is queried, firstly, whether the interface information table has the configuration white list field or not is queried, if yes, configuration content is returned, and if not, default configuration is returned.
Calling a white list judging interface to judge whether the current transaction hits the white list, and forwarding the transaction to the old system link controller when the current transaction does not hit the white list, namely calling the old system link controller, and synchronously returning a corresponding calling result; when the white list is hit, the next process of trial run is entered.
Determining whether the current transaction hits the white list includes:
analyzing the request to enter a parameter through default configuration or new white list configuration of an interface information table so as to acquire a white list field requesting to enter the parameter; when the white list field is not acquired through analysis, the white list is not hit; when the white list field is successfully acquired in the parametrization, inquiring the white list information table according to the type and the numerical value of the white list field in the parametrization, if the record is inquired, hitting the white list, otherwise, missing the white list.
Wherein the whitelist is created by:
storing the white list data into a white list information table by taking the white list data, the type and the client id as main keys, thereby obtaining the white list information table, namely a white list; the white list is shown in table 2.
TABLE 2 whitelist information table
S300: judging whether the current transaction is a maintenance type transaction, if so, executing the next step; if not, calling a new system link controller, and synchronously returning a calling result;
judging whether the transaction is a maintenance type transaction according to an interface_type transaction type field in the Interface information table; when the transaction is a non-maintenance transaction, forwarding the transaction to a new system link controller, namely calling the new system link controller, and synchronously returning a corresponding calling result; and when the transaction is a maintenance transaction, entering a next process of commissioning.
S400: judging whether the current time is in the trial running transaction time, if so, further judging whether the hit white list is in a locking state, if so, rejecting the transaction, and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
invoking the test run transaction time judging interface to judge the execution of the white list maintenance type transaction, comprising the following steps: invoking a test operation transaction time judging interface to judge whether the current time is in the test operation transaction time range, if not, namely, if the current time is the non-test operation transaction time, rejecting the transaction, and returning abnormal information (namely, error information); if the current time is within the trial operation transaction time range, namely the current time is the trial operation transaction time, calling a white list locking and inquiring interface to judge whether the currently hit white list is in a locking state or not; if the current white list is in the locked state, rejecting the transaction, and returning abnormal information, wherein the abnormal information is that the current white list is in the locked state, and trying the transaction later; and if the transaction is in the unlocking state, calling a white list locking and inquiring interface to lock the white list, and calling a new system link controller, namely forwarding the transaction to the new system link controller.
The invention sets a white list locking and inquiring interface, and the participating is client ID; in the white list locking table shown in table 3, updating the data in the unlocking state corresponding to the client ID into the locking state, and returning true when the number of updating is 0, wherein the white list is locked; otherwise, returning to false, indicating that the white list is not locked, and locking the unlocked white list.
TABLE 3 whitelist Lock Table
The white list locking is to lock the white list based on the dimension of the client, and the white list of the corresponding client is associated with the client ID (i.e. the client identification number) generated by the gateway, so the locking state of the corresponding client ID is set to Y (locking) based on the white list locking table.
S500: judging whether the new system link controller is successfully called, if so, executing an asynchronous playback flow; and if the call fails, unlocking the white list and returning abnormal information.
Obtaining a response message returned after the new system link controller is called (the structure of the response message is { "head": { "retCode": "xx", "retMsg": "xxx" } "respBodi": ") and judging whether the new system link controller is called successfully by judging whether a transaction return code retCode in the response message is 000000; if the calling fails, a white list unlocking interface is called to unlock the white list, and the process is ended; and if the call is successful, executing an asynchronous playback flow.
After the maintenance class interface calls the new core system, the forced authorization transaction is required to be played back asynchronously; therefore, the asynchronous playback function needs to newly establish an asynchronous thread to execute playback; as shown in fig. 2, performing an asynchronous playback flow includes the sub-steps of:
s501: assembling a request authorization transaction message;
the configuration content of the forced authorization transaction assembly configuration (force_auth_config) in the interface information table is a JSON format string of an assembly field (pack fixed), a default value (default value), and a response field (output fixed), for example: { "PackageFixed": "cardNo", "default Value": "Y" }.
In the new card issuing test operation stage, for the transaction needing to be played back, the request message needs to be assembled according to a specific rule; as shown in fig. 4, the assembly of the solicited-authorization transaction message includes:
obtaining a request message, and inserting a forced authorization transaction identification field (forceAuthFixed) into the request message, wherein the value is Y; inquiring forced authorization transaction assembly configuration (namely inquiring forced authorization transaction message assembly configuration) in an interface information table according to the interface number in the response message, wherein the configuration content of the forced authorization transaction assembly configuration comprises an assembly field name and a default value; if the configuration is empty, completing the assembly; if the configuration is not null, analyzing the response message according to the forced authorized transaction assembly configuration to obtain a request field value, and inserting the assembly field name and the request field value or the default value in the forced authorized transaction assembly configuration into the request message to complete assembly.
The invention sets a message assembly interface, and is called in the playback stage to realize the logic. And calling a message assembly interface, and assembling the forced authorization transaction message according to the response message according to the configuration, namely assembling and playing back the transaction request according to the response message according to the configuration.
Further, in one embodiment, the step S501 further includes: and newly whitening list data based on the response message.
The invention sets a white list unlocking interface and a white list adding interface; after the white list unlocking interface is called, the locking state of the client locking information corresponding to the client ID is modified to be N (unlocking).
Calling a white list newly added interface, and associating new white list data according to a response message (namely a response result); the newly added interface of the white list is used as a response message and a client ID; as shown in fig. 3, the transaction-based response message newly-whitelist data includes:
acquiring response messages and hit white list (i.e. hit white list information such as white list client ID) information (i.e. the white list information in step S200), and inquiring the newly added white list configuration of the interface in an interface information table according to the interface number in the response messages when the newly added white list interface is called through the acquired response messages and hit white list information; judging whether the newly added white list configuration is empty, when the configuration is not empty, acquiring the type and data of a response message according to the configuration, and storing the white list client ID (i.e. white list information) and the matched type and data (i.e. the type and data of the response message); when the configuration is empty, the configuration value is a default newly added white list configuration, the type and data of the response message are obtained according to the default configuration, and the white list client ID and the matched type and data are saved. The newly added white list data can be used as a judging basis for judging whether the current transaction hits the white list or not when the new credit card core system is tested and validated next time.
Saving whitelist customer IDs and matching types and data includes: and defaulting the state to be effective, defaulting the maintenance mode to be synchronous updating, updating to be CICP, assembling the CICP into a white list entity, inserting the CICP into a white list table, and refreshing a white list query cache.
The configuration content in the newly added white list configuration (new_white_list_config) in the interface information table is { "white list type": "whitelist field" }, the format is a newly added whitelist field configuration in JSON format, such as: { "cardNo" means "cardNo", "crcdacct no" means "crcdacct no".
S502: calling the old system link controller by using the assembled request authorization transaction message, and if the calling is successful, unlocking the white list and updating the playback identifier to be successful; and if the call fails, retrying, and if the number of times (for example, 5 times) of retries still fails, keeping the white list locked, waiting for manual unlocking, updating the playback mark as failure, and ending the flow.
Further, in one embodiment, before step S502, the method further includes: constructing a test run message storage table based on the test run message, and storing the input and output messages and the assembly messages of the transaction into the test run message storage table in the database; the test run message save table is shown in table 4.
Table 4 test run message save table
The message preservation function is used in the playback stage, the input and output messages of the transaction and the assembled messages are used as input parameters, the message preservation entity class is constructed, the message preservation entity class is inserted into the test run message preservation table, and the preservation ID is returned for later use when the playback identification is updated.
Example two
FIG. 5 is a schematic diagram of a credit card new core system commissioning verification system according to an embodiment of the present invention, including a link group module, a financial transaction determination module, a whitelist determination module, a maintenance type transaction determination module, a commissioning transaction time determination module, and a link controller call determination module;
the link group grouping module is used for grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers;
the financial transaction judging module is used for judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, calling the white list judging module;
the white list judging module is used for judging whether the current transaction hits a white list or not, and if yes, the maintenance type transaction judging module is called; if not, calling the old system link controller, and synchronously returning a calling result;
the maintenance transaction judging module is used for judging whether the current transaction is a maintenance transaction, and if yes, the test operation transaction time judging module is called; if not, calling the new system link controller, and synchronously returning a calling result;
the test operation transaction time judging module is used for judging whether the current time is in the test operation transaction time, if so, further judging whether the hit white list is in a locking state, and if the white list is in the locking state, rejecting the transaction and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
the link controller call judging module is used for judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; and if the call fails, unlocking the current white list and returning abnormal information.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk, etc.
The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present invention. Therefore, the protection scope of the invention is subject to the protection scope of the claims.

Claims (10)

1. The test operation verification method of the new credit card core system is characterized by comprising the following steps:
s100: grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers; judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, executing the next step;
s200: judging whether the current transaction hits a white list or not, if yes, executing the next step; if not, calling the old system link controller, and synchronously returning a calling result;
s300: judging whether the current transaction is a maintenance type transaction, if so, executing the next step; if not, calling the new system link controller, and synchronously returning a calling result;
s400: judging whether the current time is in the trial running transaction time, if so, further judging whether the hit white list is in a locking state, if so, rejecting the transaction, and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
s500: judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; and if the call fails, unlocking the current white list and returning abnormal information.
2. The method for verifying commissioning of a new credit card core system of claim 1, wherein said executing a financial transaction process flow in step S100 comprises:
invoking the test operation transaction time judging interface to judge whether the current time is in the test operation transaction time range, invoking a new system link controller if the current time is in the test operation transaction time range, and synchronously returning the invoking result; if the transaction time is not in the trial operation transaction time range, rejecting the transaction and returning abnormal information.
3. The credit card new core system commissioning verification method of claim 1, wherein said determining in step S200 whether the current transaction hits the whitelist comprises:
acquiring a white list field requesting to enter a parameter; when the white list field is not acquired, the white list is not hit; when the white list field is obtained, inquiring a white list information table according to the type and the numerical value of the white list field, if the record is inquired, hitting the white list, otherwise, missing the white list.
4. The credit card new core system commissioning verification method of claim 1, wherein said determining in step S400 whether the hit white list is in a locked state comprises:
updating the data in the unlocked state corresponding to the client ID in the white list locking table into a locked state, and returning true when the number of the updated data is 0, so as to indicate that the white list is locked; otherwise, return false, indicate that the whitelist is not locked.
5. The credit card new core system commissioning verification method of claim 1, wherein the determining in step S500 whether the new system link controller call is successful comprises:
and acquiring a response message returned after the new system link controller is called, and judging whether the new system link controller is successfully called or not through a transaction return code in the response message.
6. The credit card new core system commissioning verification method of claim 5, wherein said performing an asynchronous playback procedure in step S500 comprises the sub-steps of:
s501: assembling a request authorization transaction message;
s502: calling an old system link controller by using the assembled request authorization transaction message, and if the calling is successful, unlocking the white list and updating the playback identifier to be successful; if the call fails, retrying, and if the number of times of retrying still fails, keeping the white list locked, waiting for manual unlocking, updating the playback mark as failure, and ending the flow.
7. The credit card new core system commissioning verification method of claim 6, wherein said step S501 comprises:
acquiring a request message, and inserting a forced authorization transaction identification field into the request message;
inquiring mandatory authorization transaction assembly configuration in an interface information table according to the interface number in the response message, wherein the configuration content of the mandatory authorization transaction assembly configuration comprises an assembly field name and a default value; if the configuration is empty, completing the assembly;
if the configuration is not null, the response message is analyzed according to the forced authorization transaction assembly configuration so as to obtain a request field value, and the assembly field name and the request field value or a default value are inserted into the request message to complete assembly.
8. The credit card new core system commissioning verification method of claim 6, wherein said step S501 further comprises: and newly whitening list data based on the response message.
9. The credit card new core system commissioning verification method of claim 6, further comprising, prior to said step S502:
and constructing a test run message storage table based on the test run message, and storing the input and output messages and the assembly message of the transaction into the test run message storage table.
10. The credit card new core system test run verification system is characterized by comprising a link group module, a financial transaction judging module, a white list judging module, a maintenance type transaction judging module, a test run transaction time judging module and a link controller calling judging module;
the link group grouping module is used for grouping the link groups of the credit card calling old core system stage and the new core system formal operation stage based on the unified gateway, so as to obtain corresponding old system link controllers and new system link controllers;
the financial transaction judging module is used for judging whether the current transaction corresponding to the interface passing through the unified gateway is a financial transaction or not; if yes, executing a financial transaction processing flow; if not, calling the white list judging module;
the white list judging module is used for judging whether the current transaction hits a white list or not, and if yes, the maintenance type transaction judging module is called; if not, calling the old system link controller, and synchronously returning a calling result;
the maintenance transaction judging module is used for judging whether the current transaction is a maintenance transaction, and if yes, the test operation transaction time judging module is called; if not, calling the new system link controller, and synchronously returning a calling result;
the test operation transaction time judging module is used for judging whether the current time is in the test operation transaction time, if so, further judging whether the hit white list is in a locking state, and if the white list is in the locking state, rejecting the transaction and returning abnormal information; if the white list is in an unlocked state, locking the white list and calling the new system link controller;
the link controller call judging module is used for judging whether the new system link controller is successfully called, and if so, executing an asynchronous playback flow; and if the call fails, unlocking the current white list and returning abnormal information.
CN202310713751.7A 2023-06-16 2023-06-16 Method and system for verifying trial operation of new credit card core system Active CN116455918B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310713751.7A CN116455918B (en) 2023-06-16 2023-06-16 Method and system for verifying trial operation of new credit card core system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310713751.7A CN116455918B (en) 2023-06-16 2023-06-16 Method and system for verifying trial operation of new credit card core system

Publications (2)

Publication Number Publication Date
CN116455918A true CN116455918A (en) 2023-07-18
CN116455918B CN116455918B (en) 2023-08-18

Family

ID=87128850

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310713751.7A Active CN116455918B (en) 2023-06-16 2023-06-16 Method and system for verifying trial operation of new credit card core system

Country Status (1)

Country Link
CN (1) CN116455918B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117149661A (en) * 2023-10-27 2023-12-01 建信金融科技有限责任公司 Method, apparatus, device and computer readable medium for monitoring business system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010009117A (en) * 2008-06-24 2010-01-14 Hitachi Omron Terminal Solutions Corp System and method for updating authentication device
US20100050249A1 (en) * 2008-08-20 2010-02-25 Reliant Security Payment card industry (pci) compliant architecture and associated methodology of managing a service infrastructure
CN114358921A (en) * 2022-01-07 2022-04-15 中国工商银行股份有限公司 System switching method, apparatus, device, medium, and program product

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010009117A (en) * 2008-06-24 2010-01-14 Hitachi Omron Terminal Solutions Corp System and method for updating authentication device
US20100050249A1 (en) * 2008-08-20 2010-02-25 Reliant Security Payment card industry (pci) compliant architecture and associated methodology of managing a service infrastructure
CN114358921A (en) * 2022-01-07 2022-04-15 中国工商银行股份有限公司 System switching method, apparatus, device, medium, and program product

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117149661A (en) * 2023-10-27 2023-12-01 建信金融科技有限责任公司 Method, apparatus, device and computer readable medium for monitoring business system
CN117149661B (en) * 2023-10-27 2024-02-09 建信金融科技有限责任公司 Method, apparatus, device and computer readable medium for monitoring business system

Also Published As

Publication number Publication date
CN116455918B (en) 2023-08-18

Similar Documents

Publication Publication Date Title
CN110020860B (en) Cross-chain asset transfer method, system and computer readable storage medium
CN116455918B (en) Method and system for verifying trial operation of new credit card core system
EP2639726B1 (en) Service provision system and unit device
KR101962686B1 (en) System and method for electronic voting
KR101937220B1 (en) Method for generating and verifying a digital signature or message authentication code based on a block chain that does not require key management
US20070143225A1 (en) Method and system for authorizing automated teller machine access
CN103907142B (en) System and method for updating configuration data for sub-systems of an automated banking machine
CN109656778A (en) Data capture method, device, computer equipment and storage medium
CN110222028A (en) A kind of data managing method, device, equipment and storage medium
WO2021008400A1 (en) Blockchain-based batch data processing method, apparatus, and storage medium
WO2021114627A1 (en) Distributed transaction-based data processing method, device, terminal, and storage medium
US10296759B1 (en) Method of controlling whether an uncompleted transaction applied against a database goes forward or is aborted, and for modifying the uncompleted transaction so that it can go forward
CN111967061A (en) Credible account transfer transaction method and device based on block chain
CN109543457A (en) The method and device called between control intelligent contract
CN100466558C (en) Method for realizing tax controlled data monitoring of POS system
US10176243B1 (en) Method and apparatus for logging non-durable attributes of an uncompleted transaction so as to make such attributes durable
CN112269829B (en) Block chain data management method based on resource recovery system platform
WO2020169005A1 (en) Access control
CN114546872B (en) Certificate management testing method and device, computer equipment and storage medium
CN111726365A (en) Online identity authentication method and device
KR20210117731A (en) The blockchain-based transaction history confirmation system
CN112905437A (en) Method and device for testing case and storage medium
CN113312602B (en) Method and system for realizing fingerprint sharing
CN110322346A (en) A kind of condition that supporting uxto model can set method of payment and system
CN112632513B (en) Front-end and back-end separation-based identity authentication implementation method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant