A process-based protocol management method and system

Abstract

The present invention provides a process-based protocol management method and system, which relates to the field of fintech. The method includes: initiating protocol request information through a first component and sending the protocol request information to a second component; the second component obtains and sends a first request message to a third component; the third component generates and sends a second request message to a payment system; the payment system sends the second request message to a business object, and the business object sends a response message to the payment system; the payment system returns the response message to the second component through the third component; the second component identifies the status of the response message, and when the identification is successful, the second component sends the response message to a fourth component; the fourth component obtains a protocol processing result according to the response message and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component. The present invention can clearly divide the protocol status and quickly locate the true stage where the protocol is located.

Description

Technical Field

[0001] The present invention relates to the field of financial technology, and in particular to a process-based agreement management method and system. Background Art

[0002] The technical solutions for the same-city agreement business in different places are not the same. Most of them are led by each branch to develop the corresponding same-city system, and directly sign the agreement with the local People's Bank of China and the corresponding enterprise or individual, which has a short process. Some branches also entrust the head office to develop and maintain the business initiation part. Since the interface end is developed by each branch itself, the specifications of each branch are not consistent and cannot be managed uniformly. The original branch same-city system agreement business processing is relatively simple, with fewer participating links and unclear division of agreement status, resulting in technical problems in the agreement processing link that cannot quickly locate the actual stage of the agreement. Summary of the invention

[0003] In view of the problem that the above-mentioned protocol status division is unclear, resulting in the inability to quickly locate the actual stage of the protocol in the protocol processing link, the present invention is proposed to provide a solution to overcome the above-mentioned problem or at least partially solve the above-mentioned problem, thereby achieving a clear division of the protocol status and then realizing rapid positioning of the protocol, thereby achieving a more reasonable system function division and more convenient subsequent maintenance.

[0004] According to one aspect of the present invention, a process-based protocol management method is provided, the method comprising:

[0005] Initiate a protocol request message through the first component, and send the protocol request message to the second component;

[0006] The second component obtains a first request message according to the protocol request information, and sends the first request message to the third component;

[0007] The third component obtains a second request message according to the first request message, and sends the second request message to the payment system;

[0008] The second request message is sent to the business object through the payment system, and the business object processes the second request message and generates a response message and sends it to the payment system;

[0009] The payment system sends the response message to the third component, and the third component returns the response message to the second component;

[0010] The second component identifies the status of the response message, and when the identification result is successful, the second component sends the response message to the fourth component;

[0011] The fourth component obtains a protocol processing result according to the response message and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component.

[0012] Preferably, after the second component obtains a first request message according to the protocol request information and sends the first request message to the third component, it includes:

[0013] Obtain inquiry information through the second component;

[0014] According to the inquiry information, send a protocol processing query request to the payment system and receive an inquiry result sent by the payment system;

[0015] When the inquiry result includes the response message, perform status identification of the response message and subsequent steps.

[0016] Preferably, when the identification result is a failure, it further includes:

[0017] The second component obtains an end message and sends the end message to the first component.

[0018] Preferably, when the inquiry result does not include the response message, it further includes:

[0019] The second component obtains a service tracking number according to the protocol information, and the service tracking number corresponds to the protocol request information one by one;

[0020] Generate query information based on the service tracking number;

[0021] Obtain a query result according to the query information;

[0022] The second component makes corresponding processing according to the query result.

[0023] Preferably, the method includes:

[0024] When the query result is not obtained within a preset time threshold range, set the protocol request information to a status of pending query and authentication;

[0025] When the protocol request information is in the status of pending query and authentication, the second component repeats to initiate the protocol request information.

[0026] Preferably, before initiating the protocol request information through the first component, it includes:

[0027] Obtain input data;

[0028] Send the input data to the first component;

[0029] Verify the input data through the first component to obtain a first verification result;

[0030] When the first verification result is yes, obtain the protocol request information according to the input data.

[0031] Preferably, the second component obtains a first request message according to the protocol request information and sends the first request message to the third component, including:

[0032] Obtain the input data according to the protocol request information;

[0033] Verify the input data to obtain a second verification result;

[0034] When the second verification result is yes, obtain request data according to the input data;

[0035] Generate the first request message according to the request data;

[0036] Send the first request message to the third component.

[0037] Preferably, obtaining the request data according to the input data includes:

[0038] Perform data conversion processing on the input data according to business rules, and use the processed data as request data.

[0039] Preferably, generating the first request message according to the request data includes:

[0040] Obtain the interface format information of the third component;

[0041] Process the request data based on the interface format information of the third component;

[0042] Generate the first request message according to the processed request data.

[0043] Preferably, the third component obtains a second request message according to the first request message and sends the second request message to the payment system, including:

[0044] The third component obtains processed data according to the first request message;

[0045] Send the processed data to the task queue;

[0046] Scan the task queue to obtain unprocessed data;

[0047] Generate the second request message according to the unprocessed data;

[0048] Send the second request message to the payment system.

[0049] Preferably, generating the second request message according to the unprocessed data includes:

[0050] Obtain payment system interface format information;

[0051] Process the unprocessed data according to the payment system interface format information;

[0052] Generate the second request message according to the processed unprocessed data.

[0053] Preferably, the business objects include subordinate institutions of the payment system and protocol response institutions;

[0054] The business objects generate a response message after processing the second request message and send it to the payment system, including:

[0055] The subordinate institution of the payment system sends the second request message to the protocol response institution;

[0056] The protocol response institution processes the second request message, generates a response message, and sends the response message to the subordinate institution of the payment system;

[0057] The subordinate institution of the payment system sends the response message to the payment system.

[0058] Preferably, the first inquiry duration includes a first interval time, a second interval time, and a third interval time, where the first interval time is less than the second interval time, and the second interval time is less than the third interval time.

[0059] Preferably, the inquiry information includes inquiry duration and inquiry times;

[0060] Sending a protocol processing query request to the payment system according to the inquiry information and receiving the inquiry result sent by the payment system includes:

[0061] When the inquiry duration is satisfied, send a protocol processing query request to the payment system and receive the inquiry result sent by the payment system;

[0062] Record the number of protocol processing query requests;

[0063] If the number of protocol processing query requests is less than or equal to the inquiry times, and the inquiry result does not include the response message, then continue to execute the steps after sending a protocol processing query request to the payment system when the inquiry duration is satisfied;

[0064] If the number of times the protocol processing query request is greater than the number of inquiries, stop sending the protocol processing query request to the payment system.

[0065] Preferably, the inquiry duration includes a first interval time, a second interval time, and a third interval time, where the first interval time is less than the second interval time, and the second interval time is less than the third interval time.

[0066] According to another aspect of the present invention, there is provided a process-based protocol management system, which includes: a first component, a second component, a third component, a payment system, a business object, and a fourth component;

[0067] The first component is used to initiate protocol request information and send the protocol request information to the second component;

[0068] The second component is used to obtain a first request message according to the protocol request information and send the first request message to the third component; identify the status of the response message sent by the third component. When the identification result is successful, the second component sends the response message to the fourth component;

[0069] The third component is used to obtain a second request message according to the first request message and send the second request message to the payment system;

[0070] The payment system is used to send the second request message to the business object; send the response message sent by the business object to the third component, and the third component returns it to the second component;

[0071] The business object is used to process the second request message and generate a response message to send to the payment system;

[0072] The fourth component obtains a protocol processing result according to the response message and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component.

[0073] According to another aspect of the present invention, there is provided a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it implements the processing flow of each component.

[0074] According to another aspect of the present invention, there is provided a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it implements the processing flow of each component.

[0075] One or more technical solutions provided by the present invention have at least the following technical effects:

[0076] By using the first component to initiate a protocol request message and sending the protocol request message to the second component; the second component obtains a first request message according to the protocol request message and sends the first request message to the third component; the third component obtains a second request message according to the first request message and sends the second request message to the payment system; the payment system sends the second request message to the service object, and the service object processes the second request message to generate a response message and sends it to the payment system; the payment system sends the response message to the third component, and the third component returns it to the second component; the second component identifies the status of the response message, and when the identification result is successful, the second component sends the response message to the fourth component; the fourth component obtains a protocol processing result according to the response message and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component. By making the protocol flow status run through the modular processing process, each protocol status corresponds to a specific protocol life cycle stage, and thus the current maintenance stage of the protocol can be clearly judged through the protocol status, and accurate protocol positioning can be carried out, which is convenient for later maintenance. By forming a complete closed loop through the signing or revocation of a protocol, each component or system performs its own functions, which is simple and clear, the function processing of each link is clear, which is convenient for later development and maintenance and problem positioning. At the same time, the business processing process of the protocol can be completed only when each link is successful, which reduces the business processing risk, improves the availability and reliability of the system, achieves a clear division of the protocol status, and then realizes the rapid positioning of the protocol, and further achieves a more reasonable system function division and more convenient later maintenance.

[0077] The above description is only an overview of the technical solution of the present invention. In order to be able to understand the technical means of the present invention more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable, the following specifically illustrates the specific embodiments of the present invention. Brief Description of the Drawings

[0078] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0079] Figure 1Schematic flowchart of a process-based protocol management method provided by an embodiment of this application;

[0080] Figure 2 Schematic structural diagram of a process-based protocol management system provided by an embodiment of this application;

[0081] Figure 3 Shows the structural diagram of a computer device according to an embodiment herein.

[0082] Description of the accompanying drawing symbols:

[0083] 201, First component;

[0084] 202, Second component;

[0085] 203, Third component;

[0086] 204, Payment system;

[0087] 205, Business object;

[0088] 206, Fourth component;

[0089] 302, Computer device;

[0090] 304, Processor;

[0091] 306, Memory;

[0092] 308, Driving mechanism;

[0093] 310, Input / output module;

[0094] 312, Input device;

[0095] 314, Output device;

[0096] 316, Presentation device;

[0097] 318, Graphical user interface;

[0098] 320, Network interface;

[0099] 322, Communication link;

[0100] 324, Communication bus. Detailed implementation manners

[0101] This application provides a process-based protocol management method, which solves the technical problem in the prior art that the protocol status is not clearly divided, resulting in the inability to quickly locate the true stage of the protocol in the protocol processing link, and achieves the technical effect of clearly dividing the protocol status, thereby realizing the rapid positioning of the protocol, and further achieving a more reasonable system function division and more convenient later maintenance.

[0102] The technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. It should be understood that this application is not limited by the example embodiments described here. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application. Additionally, it should be noted that for the sake of description, only the parts related to this application rather than all are shown in the accompanying drawings.

[0103] The technical solutions for the same-city agreement services in different regions are not the same. Most of them are led by each branch (various types of bank branches) to develop the corresponding same-city system, directly sign agreements with the local central bank (i.e., the local People's Bank of China) and the corresponding enterprises or individuals, and the process is relatively short. There are also individual branches that entrust the head office to develop and maintain the business initiation part. Since the interface ends are developed by each branch independently, the specifications of each branch are not consistent, making unified management impossible. The original same-city system agreement services of the branches were relatively simple, with fewer participating links, and the agreement status was not clearly defined, resulting in the technical problem that the true stage of the agreement could not be quickly located during the agreement processing stage.

[0104] In view of the problem that the above-mentioned agreement status is not clearly defined, resulting in the inability to quickly locate the true stage of the agreement during the agreement processing stage, the present invention is proposed to provide a solution that overcomes or at least partially solves the above problems, achieving the technical effects of clearly defining the agreement status, thereby realizing the quick positioning of the agreement, and further making the system function division more reasonable and the later maintenance more convenient.

[0105] To address the above technical problems, this application provides a process-based agreement management method, as Figure 1 shown, the method includes:

[0106] Step S100: Initiate agreement request information through a first component and send the agreement request information to a second component;

[0107] Specifically, the first component is an employee channel component, and the second component is an e-city component. The protocol request information is a financial-related service application such as a signing agreement, an agreement change, or an agreement revocation initiated by relevant staff through the employee channel component or a branch-specific channel. Relevant business processing is carried out through the application service and query (data query and authentication query) services provided by the e-city component. The protocol request information for customer payment is initiated through the employee channel component. Among them, the protocol request information includes, but is not limited to: protocol number, regional identifier, payer's unified social credit code, customer number, customer account number, payee account number, and protocol processing type. Among them, the protocol processing type includes addition, change, cancellation, etc. It can be known that the present invention is not limited to the above-listed financial-related services. With the expansion and change of financial-related services, the updated financial-related services can also be implemented through the protocol management method described in the present invention, which will not be elaborated here.

[0108] Step S200: The second component obtains a first request message according to the protocol request information and sends the first request message to the third component;

[0109] The second component, that is, the e-city component, after receiving the protocol request information, performs verification on the protocol request information. When the verification is correct, a first request message is generated according to the protocol request information.

[0110] The verification includes necessary verification of the request information of the employee channel component: such as fields like protocol number, regional identifier, unified social credit code, etc.; verification of whether the trading institution matches the regional code.

[0111] The e-city component will also perform optimization processing on the protocol request information for specific scenarios to further control the protocol status. For example, corresponding data processing is performed according to the different attributes of each branch. For example, the first attribute of the Ningbo Branch is: not supporting protocol change; or the common second attribute of the Ningbo Branch and the Changzhou Branch is: the payment system bank number of the payer is a fixed value; or the common third attribute of the Suzhou Branch and the Guangzhou Branch is: protocol consistency processing is required. Specifically, other branches use the protocol number as the unique identifier, and the Suzhou Branch and the Guangzhou Branch use both the protocol number and the payer's account number as the unique identifier. Refined protocol management according to the above different scenarios can better adapt to different branch systems and perform unified access management.

[0112] In a preferred embodiment, the e-city component will also process the protocol request information, converting the protocol request information into fields required to be stored in the e-city component database.

[0113] Step S300: The third component obtains a second request message according to the first request message and sends the second request message to the payment system;

[0114] Specifically, the third component is a payment and settlement component. The first component, the second component, and the third component are processing systems of the customer's principal, such as the employee channel component, the electronic same-city component, and the payment and settlement component of a certain bank like China Construction Bank or Industrial and Commercial Bank. The second request message is the data required to be received by the payment system, such as data in a format recognizable by the payment system or data content required to be processed by the business object.

[0115] Step S400: The payment system sends the second request message to the business object, and the business object processes the second request message and generates a response message and sends it to the payment system;

[0116] Specifically, after changing and processing the corresponding protocol status in the second request message, the payment system forwards it to the business object. The business object includes the subordinate institutions of the payment system and the protocol response institutions. The subordinate institutions of the payment system correspond to the local sub-branches of the People's Bank of China (i.e., local People's Banks), and the protocol response institution refers to the processing system entrusted by the signing party of the recipient user's agreement, such as the recipient's account of a certain sub-bank.

[0117] The business object processes the second request message and generates a response message and sends it to the payment system, which includes: the subordinate institution of the payment system sends the second request message to the protocol response institution; the protocol response institution processes the second request message, generates a response message, and sends the response message to the subordinate institution of the payment system; the subordinate institution of the payment system sends the response message to the payment system. Among them, the response message includes processing success and processing failure. Processing refers to processing such as signing, changing, and deleting agreements.

[0118] Step S500: The payment system sends the response message to the third component, and the third component returns it to the second component;

[0119] Step S600: The second component identifies the status of the response message. When the identification result is successful, the second component sends the response message to the fourth component;

[0120] Specifically, the second component identifies the status of the response message, that is, it identifies the result of the response message. If the result of the response message is failure, it directly notifies the employee channel component and the process ends. If the result of the response message is successful, it sends the response message to the fourth component. The fourth component is a collection and payment component, which refers to the protocol record and processing component of the customer's principal.

[0121] Step S700: The fourth component obtains the protocol processing result according to the response message, and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component.

[0122] Specifically, the fourth component (collection and payment component) performs protocol processing according to the response message. When the protocol processing is successful, the protocol status is that both the payment system and the collection and payment component are successful, and the request protocol status is signed successfully. The protocol processing result is sent back to the second component (electronic same-city component), and the second component (electronic same-city component) sends the protocol processing result to the first component (employee channel component). When the second component, i.e., the electronic same-city component, fails to call the fourth component, i.e., the collection and payment component, or refuses, or the protocol processing result is a failure, the protocol state is that the payment system is successful and the collection and payment component refuses. Then the corresponding request protocol status is to be synchronized, and at this time, the employee channel component is notified that the process ends.

[0123] Among them, the protocol status is a status description of the protocol request information at different stages and processing results in the entire protocol cycle. During the entire life cycle of the protocol, the protocol status transitions in each step include the following protocol statuses:

[0124] Signed initial - The status when applying for signing a protocol.

[0125] Signed pending authentication - The status when the signing result of the central bank protocol has not been obtained.

[0126] Signed pending synchronization - The status when the successful synchronization of the signed protocol by the collection and payment component has not been obtained.

[0127] Signed successfully - The status when both the central bank and the collection and payment component are signed successfully.

[0128] Signed failed - The status when the central bank refuses to sign the protocol.

[0129] Cancelled initial - The status when applying for cancelling a protocol.

[0130] Cancelled pending authentication - The status when the cancellation result of the central bank protocol has not been obtained.

[0131] Cancelled pending synchronization - The status when the successful synchronization of the cancelled protocol by the collection and payment component has not been obtained.

[0132] Cancelled successfully - The status when both the central bank and the collection and payment component are cancelled successfully.

[0133] Cancelled failed - The status when the central bank refuses to cancel the protocol.

[0134] Each protocol status corresponds to a specific protocol life cycle stage. The current protocol status can clearly determine which maintenance stage the protocol is in and which system or component should handle it later. It has a clear division of labor, each doing its own job, and controls the logical processing of each stage through process control, making the system function division more reasonable.

[0135] The present invention is applicable to a cross-regional multi-party collaborative agreement processing system, wherein the multiple systems include an initiator system, a participant system and a central management system. For intra-city bank agreement services (such as payment of water, electricity, and coal fees), an agreement needs to be signed, and the signing of the agreement involves three-party systems. The initiator system includes a first component, a second component, and a third component, the participant system includes a business object, and the central management system corresponds to a payment system.

[0136] Based on the design of the above-mentioned protocol processing flow, from the initialization of the protocol to the authentication, synchronization, and the final signing success or failure, in this process, each component or system will be passed in turn, corresponding to the different life cycle stage states in the protocol process. Among them, the participants are the first component (employee channel component), the second component (electronic same city component), the third component (payment settlement component), the fourth component (collection and payment component) and the business object. Each component or system has a clear division of labor and clear responsibilities. The protocol status in the process can quickly locate the link in the life cycle of the protocol, and the corresponding protocol status is set according to the different stages of the protocol in the entire life cycle of the protocol, making the operation steps clearer and faster to locate, and facilitating later maintenance. It is realized that in the entire life cycle of the agreement, the corresponding protocol status is set according to the different stages of the agreement, making the operation steps clearer and faster to locate, and facilitating later maintenance, reducing business processing risks, improving the availability and reliability of the system, and achieving a clear division of the protocol status, thereby realizing the rapid positioning of the protocol, and then achieving a more reasonable system function division and more convenient later maintenance.

[0137] Further, after the second component obtains the first request message according to the protocol request information and sends the first request message to the third component, step S200 of the embodiment of the present application further includes:

[0138] Step S210: obtaining inquiry information through the second component;

[0139] Step S220: sending a protocol processing query request to the payment system according to the query information, and receiving the query result sent by the payment system;

[0140] Step S230: When the inquiry result includes the response message, perform status identification of the response message and subsequent steps.

[0141] Further, when the status of the response message is identified as a failure, step S200 of the embodiment of the present application further includes:

[0142] Step S240: The second component obtains end information and sends the end information to the first component.

[0143] Further, the inquiry information includes an inquiry duration and an inquiry count. The inquiry duration includes a first interval, a second interval, and a third interval, where the first interval is less than the second interval, and the second interval is less than the third interval. In specific implementation, the inquiry duration can also be a fixed time interval or include more types of time intervals, which is not limited herein.

[0144] Specifically, during the process of protocol management, due to the long transaction path, there is a problem of a relatively long corresponding time. In a transaction where a protocol application is initiated, after the electronic same-city component, i.e., the second component, sends a request, it inquiries about the process of the protocol management through the corresponding inquiry information. The inquiry information includes multiple inquiry time intervals. Generally, the inquiry time interval includes three time intervals, namely a first time interval, a second time interval, and a third time interval, and the third time interval is greater than the second time interval which is greater than the first time interval. For example, the first time interval is set to 2s, the second time interval is set to 3s, and the third time interval is set to 4s. Then, in a transaction where a protocol application is initiated, after the electronic same-city component sends a request, it will make three polls at intervals of 2s, 3s, and 4s respectively to actively obtain the response message returned by the small-amount payment system. The response message contains the processing result. When the status of the response message is identified as a failure, end information is obtained, and the second component (electronic same-city component) sends the end information to the first component (employee channel component), that is, the processing result is returned to the employee channel component in real time to complete the final protocol process, so as to achieve a seamless customer experience.

[0145] In a further embodiment, step S220 of sending a protocol processing query request to the payment system according to the inquiry information and receiving the inquiry result sent by the payment system includes:

[0146] When the inquiry duration is satisfied, send a protocol processing query request to the payment system and receive the inquiry result sent by the payment system;

[0147] Record the number of protocol processing query requests;

[0148] If the number of times the protocol processing query request is less than or equal to the number of inquiries, and the inquiry result does not include the response message, then continue to execute the steps after sending the protocol processing query request to the payment system when the inquiry duration is met;

[0149] If the number of times the protocol processing query request is greater than the number of inquiries, stop sending the protocol processing query request to the payment system.

[0150] In specific implementation, the inquiry information may also only include the inquiry duration or the number of inquiries. Which specific information is included can be set by the maintenance personnel, and this is not limited herein.

[0151] Furthermore, when the inquiry result does not include the response message, step S200 of the embodiment of the present application further includes:

[0152] Step S231: The second component obtains a service tracking number according to the protocol request information, and the service tracking number corresponds to the protocol request information one by one;

[0153] Step S232: Generate query information based on the service tracking number;

[0154] Step S233: Obtain a query result according to the query information;

[0155] Step S234: The second component makes corresponding processing according to the query result.

[0156] Specifically, when the inquiry result does not include the response message, the second component initiates a query through a separate transaction, locates and concatenates a unique protocol through the service tracking number generated by each transaction, and performs query authentication on it. That is, according to the protocol initiation information, the service tracking number is obtained, and the service tracking number corresponds to the protocol initiation information one by one. The service tracking number is a global tracking number. Through the global tracking number, the protocol can be located and authenticated. Query information is generated based on the service tracking number, and the protocol is queried through the query information to obtain a query result. The second component (electronic same-city component) makes corresponding processing according to the query result. Through the query and authentication of the service tracking number, accurate query authentication and positioning of the protocol can be performed, achieving a clear division of the protocol status, and further realizing the rapid positioning of the protocol, laying a solid foundation for subsequent processing.

[0157] Furthermore, the embodiment of the present application further includes:

[0158] Step S235: When the query result is not obtained within the preset time threshold range, set the protocol initiation information to the status of pending query authentication;

[0159] Step S236: When the protocol initiation information is the authentication status to be queried, the second component may repeatedly initiate protocol request information.

[0160] Specifically, the preset real-time threshold is the corresponding time threshold set for the system. When the second component does not receive the query result within the preset time threshold, the initiation information of the protocol is set to the status of pending query and authentication at this time. When the protocol information is in the status of pending query and authentication, a corresponding repeated initiation instruction is obtained. Based on the repeated initiation instruction, the protocol is repeatedly initiated. For example, for a submitted protocol, if the small-amount payment system fails to return the result for a long time or the payee no longer makes corresponding processing and returns, this protocol is in the status of pending query and authentication. In response to this situation, the electronic same-city component supports repeated initiation at the counter. Even if the small-amount payment system returns a repeated signature, it can be processed normally, avoiding the risk problem that the protocol is suspended for a long time and cannot be operated subsequently.

[0161] Furthermore, the protocol request information initiated by the first component is determined through the following process:

[0162] Step S110: Obtain input data;

[0163] Step S120: Send the input data to the first component;

[0164] Step S130: The first component verifies the input data to obtain a first verification result;

[0165] Step S140: When the first verification result is yes, obtain the protocol request information.

[0166] Specifically, the input data is the protocol processing information input by the teller or the customer into the first component, including but not limited to information such as protocol signing, change, deletion of the protocol, etc. For example, it is the customer number, customer account number, payee account number, payer unified social credit code, regional identifier, etc. The input data is sent to the first component (employee channel component). When the first component (employee channel component) receives the input data, it first verifies the input data at this time. The parts of the verification include but not limited to integrity verification, security verification, execution degree verification, status verification, etc. Based on the verification process, a first verification result is obtained. When the first verification result is yes, it indicates that the verification is correct. At this time, the protocol request information is obtained according to the input data. Specifically, information such as a protocol number is generated according to the input information, and the protocol request information is obtained according to the input information and the information generated by the first component.

[0167] Furthermore, the second component obtains a first request message according to the protocol request information and sends the first request message to the third component. Step S200 of the embodiment of the present application further includes:

[0168] Step S261: Obtain the input data according to the protocol request information;

[0169] Step S262: Verify the input data to obtain a second verification result;

[0170] Step S263: When the second verification result is yes, obtain request data according to the input data;

[0171] Step S264: Generate the first request message according to the request data;

[0172] Step S265: Send the first request message to the third component.

[0173] Specifically, the part described in this embodiment includes the part of cross-bank transactions. The second verification result in step S262 above is the result of the electronic same-city component's verification and processing of account information. The electronic same-city component receives the application request initiated by the employee channel component, obtains the input data according to the protocol request information, verifies the input data. Further, the verification of the input data includes performing corresponding verification on information such as the account number, etc., to obtain a second verification result. When the second verification result is yes, that is, when the verification passes, request data is obtained according to the input data.

[0174] The above step S263 obtains request data according to the input data, including: performing data conversion processing on the input data according to business rules, and using the processed data as request data. For example, for the recipient region code input in the input data, the implementation of step S263 can convert the recipient region code into the recipient bank number.

[0175] Specifically, the business rules can be set according to actual needs, and this is not limited herein. The method of converting data through business rules can improve the efficiency of input data and avoid users from recording complex data.

[0176] The above step S264 generates the first request message according to the request data, including:

[0177] Step S2643: Obtain the interface information of the third component;

[0178] Step S2644: Obtain the interface format information of the third component according to the interface information of the third component;

[0179] Step S2645: Process the request data based on the third component interface format information;

[0180] Step S2646: Generate the first request message according to the processed request data.

[0181] Based on the request data, convert the data format in the request data to the format of the third component (payment settlement component) interface. Generate the first request message according to the conversion result, that is, obtain the interface information of the third component (payment settlement component). Obtain the interface format information of the third component (payment settlement component) according to the interface information of the third component (payment settlement component). Perform format conversion on the request data based on the interface format information of the third component (payment settlement component).

[0182] Furthermore, before the above-mentioned step S264 generates the first request message according to the request data, it also includes performing optimization processing for specific scenarios on the protocol request information to further control the protocol state. For example, corresponding data processing is performed according to the different attributes of each branch. For example, the first attribute of the Ningbo Branch is: protocol change is not supported; or the second attribute shared by the Ningbo Branch and the Changzhou Branch is: the payment system bank number of the payer is a fixed value; or the third attribute shared by the Suzhou Branch and the Guangzhou Branch is: protocol consistency processing is required. Specifically, other branches use the protocol number as the unique identifier, while the Suzhou Branch and the Guangzhou Branch use both the protocol number and the payer's account number as the unique identifier. Performing refined protocol management according to the above different scenarios can better adapt to different branch systems and perform unified access management.

[0183] In an embodiment of this article, before the above-mentioned step S264 generates the first request message according to the request data, it also includes: processing the input data to obtain processed data, and storing the processed data in the database of the second component (electronic same-city component), that is, the electronic same-city component, for convenient subsequent data query and data supervision.

[0184] Furthermore, the third component obtains a second request message according to the first request message and sends the second request message to the payment system. Step S300 of the embodiment of the present application further includes:

[0185] Step S310: The third component obtains processed data according to the first request message;

[0186] Step S320: Send the processed data to the task queue;

[0187] Step S330: Scan the task queue to obtain unprocessed data;

[0188] Step S340: Generate the second request message according to the unprocessed data;

[0189] Step S350: Send the second request message to the payment system.

[0190] Further, step S340 generating the second request message according to the unprocessed data includes:

[0191] Step S341: Obtain the interface format information of the payment system;

[0192] Step S342: Process the unprocessed data according to the interface format information of the payment system;

[0193] Step S343: Generate a second request message according to the processed unprocessed data.

[0194] Specifically, the payment system may be the small-amount payment system of the People's Bank of China. The processed data is the data obtained after the payment component processes the first request message. The third component obtains the processed data according to the first request message and sends the processed data to the task queue. Scan the task queue to obtain the first scan result. Check the data in the first scan result to determine whether all the data in the first scan result has been processed. When the first scan result contains unprocessed data, obtain the unprocessed data, that is, the data that has not been processed in the third component and needs to be processed in the payment system. Process the unprocessed data into the interface format of the payment system (small-amount payment system) for sending. When performing the interface format data conversion, first obtain the interface format information of the payment system, convert the unprocessed data according to the interface format information, and generate a second request message according to the conversion result. The third component sends the second request message to the payment system.

[0195] Further, the business objects include the subordinate institutions of the payment system and the protocol response institutions;

[0196] The business objects generating a response message after processing the second request message and sending it to the payment system includes:

[0197] Step S410: The subordinate institution of the payment system sends the second request message to the protocol response institution;

[0198] Step S420: The protocol response institution processes the second request message, generates a response message, and sends the response message to the subordinate institution of the payment system;

[0199] Step S430: The subordinate institution of the payment system sends the response message to the payment system.

[0200] Specifically, the business objects include the subordinate institutions of the payment system and the protocol response institutions. The subordinate institutions can be the local People's Banks, and the protocol response institution is a certain sub-bank entrusted by the payee. The subordinate institution of the payment system sends the second request message to the protocol response institution; the protocol response institution processes the second request message, generates a response message, and sends the response message to the subordinate institution of the payment system; the subordinate institution of the payment system sends the response message to the payment system. For example, after the payment settlement component receives the request message from the electronic same-city component, it performs corresponding data processing and sends it to the task queue. When unprocessed data is scanned, it processes the data into the format of the small-amount payment system interface and sends it. The small-amount payment system processes the received request message and forwards it to the business object. During the entire life cycle of the protocol, the corresponding protocol status is set according to the different stages of the protocol, making the operation steps clearer, enabling quick positioning, and facilitating later maintenance.

[0201] In the implementation process of the present invention, in view of the problem that the transaction path may be too long and the response time may be long, in the transaction initiated by the protocol application, after the electronic same-city component sends the request, it will perform three polls at intervals of 2s, 3s, and 4s respectively to actively obtain the processing result returned by the small-amount payment system. If the small-amount payment system returns the final result within this time, the electronic same-city component will perform corresponding subsequent processing and return the processing result to the employee channel component in real time to complete the final protocol process, so as to achieve a seamless customer experience. If the small-amount payment system does not return the final result in time within this time, it can also initiate a query through a separate transaction, locate and concatenate a unique protocol through the global tracking number generated by each transaction, perform query authentication on it, and perform corresponding processing on the final result returned by the small-amount payment system.

[0202] Based on the same inventive concept as the method for protocol management based on a process in the foregoing embodiment, the present invention also provides a protocol management system based on a process, as Figure 2 shown, the system includes a first component 201, a second component 202, a third component 203, a payment system 204, a business object 205, and a fourth component 206;

[0203] The first component 201 is used to initiate protocol request information and send the protocol request information to the second component 202;

[0204] The second component 202 is used to obtain a first request message according to the protocol request information, and send the first request message to the third component 203; identify the status of the response message sent by the third component 203, and when the identification result is successful, the second component 202 sends the response message to the fourth component 206;

[0205] The third component 203 is used to obtain a second request message according to the first request message, and send the second request message to the payment system 204;

[0206] The payment system 204 is used to send the second request message to the service object 205; send the response message sent by the service object 205 to the third component 203, and the third component 203 returns it to the second component 202;

[0207] The service object 205 is used to process the second request message and generate a response message to send to the payment system 204;

[0208] The fourth component 206 obtains a protocol processing result according to the response message, and returns the protocol processing result to the second component 202, and the second component 202 sends the protocol processing result to the first component 201.

[0209] In an embodiment of the present invention, the above-mentioned first component, second component, third component, payment system and service object can all be computer devices, such as Figure 3As shown, the computer device 302 may include one or more processors 304, such as one or more central processing units (CPUs), and each processing unit may implement one or more hardware threads. The computer device 302 may also include any memory 306 for storing any kind of information such as code, settings, data, etc. By way of non-limiting example, for instance, the memory 306 may include any one or more combinations of the following: any type of RAM, any type of ROM, flash memory devices, hard disks, optical discs, etc. More generally, any memory may store information using any technology. Further, any memory may provide volatile or non-volatile retention of information, and a computer program that can run on the processor 304 is stored on the memory 306. When the processor 304 executes the computer program, it implements the electric vehicle charging and discharging control method described in any of the foregoing embodiments. Further, any memory may represent a fixed or removable component of the computer device 302. In one case, when the processor 304 executes the associated instructions stored in any memory or combination of memories, the computer device 302 may perform any operation of the associated instructions. The computer device 302 also includes one or more drive mechanisms 308 for interacting with any memory, such as a hard disk drive mechanism, an optical disc drive mechanism, etc.

[0210] The computer device 302 may also include an input / output module 310 (I / O) for receiving various inputs (via the input device 312) and for providing various outputs (via the output device 314). A specific output mechanism may include a presentation device 316 and an associated graphical user interface 318 (GUI). In other embodiments, the input / output module 310 (I / O), the input device 312, and the output device 314 may not be included, and it may only be a computer device in the network. The computer device 302 may also include one or more network interfaces 320 for exchanging data with other devices via one or more communication links 322. One or more communication buses 324 couple the components described above together.

[0211] The communication link 322 may be implemented in any manner, for example, through a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 322 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc. governed by any protocol or combination of protocols.

[0212] It should be understood that in various embodiments of the present invention, the magnitudes of the sequence numbers of the above processes do not imply the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0213] It should also be understood that in the embodiments of the present invention, the term "and / or" is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this text generally represents an "or" relationship between the associated objects before and after.

[0214] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0215] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0216] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed couplings or direct couplings or communication connections to each other can be indirect couplings or communication connections through some interfaces, devices, or units, and can also be electrical, mechanical, or other forms of connection.

[0217] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present invention.

[0218] Specific embodiments of the present invention are used to elaborate on the principles and implementation manners of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A process-based protocol management method, characterized in that, The method includes: Initiate a protocol request message through a first component and send the protocol request message to a second component; The second component obtains a first request message according to the protocol request message and sends the first request message to a third component; The third component obtains a second request message according to the first request message and sends the second request message to a payment system; Send the second request message to a service object through the payment system, and the service object processes the second request message and generates a response message to send to the payment system; The payment system sends the response message to the third component, and the third component returns it to the second component; The second component identifies the status of the response message. When the identification result is successful, the second component sends the response message to a fourth component. When the identification result is failed, the second component obtains an end message and sends the end message to the first component; The fourth component obtains a protocol processing result according to the response message and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component; Wherein, after sending the first request message to the third component, it includes: The second component obtains inquiry information; According to the inquiry information, send a protocol processing query request to the payment system and receive the inquiry result sent by the payment system; When the inquiry result includes the response message, perform the status identification of the response message and subsequent steps.

2. The method according to claim 1, characterized in that, When the inquiry result does not include the response message, the method includes: The second component obtains a service tracking number according to the protocol request message, and the service tracking number corresponds to the protocol request message one by one; Generate query information based on the service tracking number; Obtain a query result according to the query information; The second component makes corresponding processing according to the query result.

3. The method according to claim 2, characterized in that, The method further includes: When the query result is not obtained within a preset time threshold range, set the protocol request message to a status of pending query and authentication; When the protocol request message is in the status of pending query and authentication, the second component repeats to initiate the protocol request message.

4. The method according to claim 1, characterized in that, Before initiating the protocol request message through the first component, it includes: Obtain input data; Send the input data to the first component; The first component verifies the input data to obtain a first verification result; When the first verification result is yes, obtain the protocol request message according to the input data.

5. The method according to claim 4, characterized in that, The second component obtains a first request message according to the protocol request message and sends the first request message to the third component, including: Obtain the input data according to the protocol request message; Verify the input data to obtain a second verification result; When the second verification result is yes, obtain request data according to the input data; Generate the first request message according to the request data; Send the first request message to the third component.

6. The method according to claim 5, characterized in that, Obtaining request data according to the input data includes: Performing data conversion processing on the input data according to business rules, and using the processed data as request data.

7. The method according to claim 5, wherein Generating the first request message according to the request data includes: Obtaining the third component interface format information; Processing the request data based on the third component interface format information; Generating the first request message according to the processed request data.

8. The method according to claim 1, wherein The third component obtains a second request message according to the first request message and sends the second request message to the payment system, including: The third component obtains processed data according to the first request message; Sending the processed data to the task queue; Scanning the task queue to obtain unprocessed data; Generating the second request message according to the unprocessed data; Sending the second request message to the payment system.

9. The method according to claim 8, wherein Generating the second request message according to the unprocessed data includes: Obtaining the payment system interface format information; Processing the unprocessed data according to the payment system interface format information; Generating the second request message according to the processed unprocessed data.

10. The method according to claim 1, wherein The business object includes a subordinate institution of the payment system and a protocol response institution; The business object processes the second request message and generates a response message to send to the payment system, including: The subordinate institution of the payment system sends the second request message to the protocol response institution; The protocol response institution processes the second request message, generates a response message, and sends the response message to the subordinate institution of the payment system; The subordinate institution of the payment system sends the response message to the payment system.

11. The method according to claim 1, wherein The inquiry information includes inquiry duration and inquiry times; Sending a protocol processing query request to the payment system according to the inquiry information and receiving the inquiry result sent by the payment system includes: When the inquiry duration is met, sending a protocol processing query request to the payment system and receiving the inquiry result sent by the payment system; Recording the number of protocol processing query requests; If the number of protocol processing query requests is less than or equal to the inquiry times and the inquiry result does not include the response message, then continue to execute the steps of sending a protocol processing query request to the payment system and subsequent steps when the inquiry duration is met; If the number of protocol processing query requests is greater than the inquiry times, stop sending a protocol processing query request to the payment system.

12. The method according to claim 11, wherein The inquiry duration includes a first interval time, a second interval time, and a third interval time, where the first interval time is less than the second interval time, and the second interval time is less than the third interval time.

13. A process-based protocol management system, wherein The system includes: a first component, a second component, a third component, a payment system, a business object, and a fourth component; The first component is used to initiate protocol request information and send the protocol request information to the second component; The second component is used to obtain a first request message according to the protocol request information, and send the first request message to the third component; identify the status of the response message sent by the third component. When the identification result is successful, the second component sends the response message to the fourth component. When the identification result is failed, the second component obtains end information and sends the end information to the first component; The third component is used to obtain a second request message according to the first request message, and send the second request message to the payment system; The payment system is used to send the second request message to the business object; send the response message sent by the business object to the third component, and the third component returns it to the second component; The business object is used to process the second request message and generate a response message to send to the payment system; The fourth component obtains a protocol processing result according to the response message, and returns the protocol processing result to the second component, and the second component sends the protocol processing result to the first component; Wherein, after sending the first request message to the third component, it includes: Obtain inquiry information through the second component; According to the inquiry information, send a protocol processing query request to the payment system and receive the inquiry result sent by the payment system; When the inquiry result includes the response message, perform the status identification of the response message and subsequent steps.

Images