CN118350814B

CN118350814B - Method, device, medium and equipment for generating distributed cross-protocol callback transaction

Info

Publication number: CN118350814B
Application number: CN202410767733.1A
Authority: CN
Inventors: 李峰; 肖姝; 常振华; 于浩
Original assignee: Beijing Yusys Technologies Group Co ltd
Current assignee: Beijing Yusys Technologies Group Co ltd
Priority date: 2024-06-14
Filing date: 2024-06-14
Publication date: 2024-08-20
Anticipated expiration: 2044-06-14
Also published as: CN118350814A

Abstract

The invention provides a method, a device, a medium and equipment for generating a distributed cross-protocol callback transaction, belonging to the field of financial science and technology, wherein the method comprises the following steps: distributing the received transaction request to the corresponding business micro service; determining the transaction type and the protocol type of callback transaction according to the service transaction configuration information obtained in the transaction message, and performing service processing on the transaction message; carrying out transaction dynamic configuration on a callback interface according to a service processing result and a protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service; grouping and version matching are carried out on callback transactions according to callback transaction examples, and callback transaction processing is carried out according to matching results; and calling a callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing. The invention can be coupled with the business transaction department to improve callback processing performance.

Description

Method, device, medium and equipment for generating distributed cross-protocol callback transaction

Technical Field

The invention relates to the field of financial science and technology, in particular to a method, a device, a medium and equipment for generating a distributed cross-protocol callback transaction.

Background

With the rapid development of software technology, the complexity of transaction system functions is higher and higher, the performance requirement is higher and the service change is faster and faster, the standards of service processing logic and clients are not uniform, enterprises in a plurality of industries select a distributed service mode when an information system is built, if a plurality of distributed micro services exist in the same system, as the transaction processing of service application under different frames cannot be uniform, how to respond to the service change rapidly and efficiently and the development of effectively controlling the repetition cost input face a great challenge.

In the system iteration and service operation process, continuous iteration is required to be carried out on service processing transaction according to service operation scenes, so that micro services interacted with related systems in public service cannot process different service logics and cannot be compatible with different micro services due to inconsistent system meaning, standardization, transaction standards and the like in the prior art by the same API (application programming interface) gateway (Application Programming Interface). With the increase of service development time, the service volume and service type are continuously increased, the change of service development and the management of industry to product standards are increasingly increased, the requirements of management institutions on operation, monitoring, analysis and management digitization of the service are continuously improved, the iterative optimization development of the gateway in the traditional mode is high in cost, the quality is difficult to guarantee, the response time is long, and the updating efficiency of an information system is low.

The existing service information system has various micro-service architectures such as Dubbo, springCloud, and the interaction between the Dubbo interface and the SpringCloud interface is realized in two ways at present: firstly, integrating two types of micro services through registration and discovery middleware compatible with two frameworks; and secondly, using a micro-service conversion configuration tool to configure SpringCloud interfaces. However, in the current two modes, the business transaction cannot be callback-processed under different protocols, a plurality of callback service instances are required to be provided according to different transaction and protocols, excessive system resources are occupied, system performance is reduced, and development, test, online and business verification investment of an information system are increased.

Disclosure of Invention

Accordingly, an objective of the embodiments of the present invention is to provide a method, apparatus, medium and device for generating a distributed cross-protocol callback transaction, so as to solve the above-mentioned problems in the prior art.

To achieve the above objective, in a first aspect, an embodiment of the present invention provides a method for generating a distributed cross-protocol callback transaction, where the method includes:

receiving a transaction request sent by a cooperative service request end, and distributing the transaction request to a corresponding service micro-service according to interface information of the cooperative service request end;

Acquiring service transaction configuration information from a transaction message according to the transaction request, determining the transaction type and the protocol type of callback transaction according to the service transaction configuration information, and performing service processing on the transaction message according to the transaction type to acquire a service processing result;

Performing transaction dynamic configuration on a callback interface according to the service processing result and the protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service;

Grouping and version matching are carried out on callback transactions according to the callback transaction instance, a matching result is obtained, callback transaction processing is carried out according to the matching result, and callback transaction processing results are obtained;

And calling the callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing.

In some possible embodiments, before the receiving the transaction request sent by the cooperative service request end, the method further includes:

The calling mapping relation between business transactions is configured in a database;

Reading a call mapping relation between business transactions from the database;

and matching the business transaction to a callback transaction needing to be called according to the call mapping relation.

In some possible embodiments, after the performing service processing on the transaction message according to the transaction type, obtaining a service processing result, the method further includes:

The protocol types and API interfaces in the business process are stored in a database in the form of a configuration table.

In some possible embodiments, the performing service processing on the transaction message according to the transaction type specifically includes:

Verifying the transaction message in the transaction request to obtain a verification result of the transaction message;

performing service processing on the verified transaction message according to the transaction type according to the verification result of the transaction message, and sending the service processing result to an association system;

and receiving a real-time return message or an asynchronous query result of the association system, and callback the real-time return message or the asynchronous query result to the cooperative service request end.

In some possible embodiments, the dynamically configuring the callback interface according to the service processing result and the protocol type to generate a callback transaction instance specifically includes:

and generating callback transaction examples by using a class loader provided by spring according to the transaction type, the target transaction name, the protocol type, the transaction message and the service processing result.

In some possible embodiments, the callback transaction processing specifically includes:

Judging whether the call is the first call, if the call is not the first call, directly distributing and calling a callback transaction instance, and if the call is the first call, performing a callback transaction generation process;

the callback transaction generation process specifically comprises the following steps:

acquiring relevant configuration information of business micro-services by using monitoring management;

Generating callback transaction examples in an annotation mode according to the related configuration information;

registering the callback transaction instance to a registration center in a dynamic registration mode of the business micro-service.

In a second aspect, an embodiment of the present invention provides a device for generating a distributed cross-protocol callback transaction, where the device includes:

The transaction request receiving and distributing module is used for receiving the transaction request sent by the cooperative service request end and distributing the transaction request to the corresponding service micro service according to the interface information of the cooperative service request end;

The micro-service processing module is used for acquiring service transaction configuration information from the transaction message according to the transaction request, determining the transaction type and the protocol type of callback transaction according to the service transaction configuration information, and performing service processing on the transaction message according to the transaction type to obtain a service processing result;

The dynamic configuration module is used for carrying out transaction dynamic configuration on a callback interface according to the service processing result and the protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service;

the matching module is used for grouping and version matching the callback transaction according to the callback transaction instance to obtain a matching result, and carrying out callback transaction processing according to the matching result to obtain a callback transaction processing result;

And the callback transaction generating module is used for calling the callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing.

In some possible embodiments, the apparatus further comprises:

And the distribution strategy configuration module is used for configuring the call mapping relation between the business transactions in a database, reading the call mapping relation between the business transactions from the database, and matching the business transactions to callback transactions needing to be called according to the call mapping relation.

In a third aspect, an embodiment of the present invention provides an electronic device, including:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of any of the first aspects.

In a fourth aspect, an embodiment of the present invention provides a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method according to any of the first aspects.

The technical scheme has the following beneficial effects:

the invention provides a method, a device, a medium and equipment for generating a distributed cross-protocol callback transaction, wherein the method comprises the following steps: the interface information of the cooperative service request end distributes the transaction request to the corresponding service micro-service; acquiring business transaction configuration information from a transaction message according to a transaction request, determining the transaction type and the protocol type of callback transaction according to the business transaction configuration information, and carrying out business processing on the transaction message according to the transaction type; carrying out transaction dynamic configuration on a callback interface according to a service processing result and a protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service; grouping and version matching are carried out on callback transactions according to callback transaction examples, callback transaction processing is carried out according to matching results, and callback transaction processing results are obtained; and calling a callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing.

According to the callback transaction routing node, different callback protocols are supported, and callback transaction routing nodes can be processed according to transaction information; the dependence of the client and the service processing end is eliminated, the complexity of construction and later maintenance of the information system is reduced, different protocols are dynamically assembled according to the business transaction configuration information, the transaction protocols and the like, a callback function for processing business transactions universally across transaction types, service protocols or middleware is realized, the callback function can be distributed to different micro-service processing nodes, and the universality and the processing performance of the transaction processing system are improved.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method of generating a distributed cross-protocol callback transaction in accordance with an embodiment of the present invention;

FIG. 2 is a deployment diagram of a distributed cross-protocol callback transaction in accordance with an embodiment of the present invention;

FIG. 3 is a deployment diagram of a payoff business process flow according to an embodiment of the present invention;

FIG. 4 is a flow chart of a payoff application business process according to an embodiment of the present invention;

FIG. 5 is a flow chart of a process of a payoff application result query service according to an embodiment of the present invention;

FIG. 6 is a flow chart of a process of a payoff application result query service according to an embodiment of the present invention;

FIG. 7 is a flow chart of a distributed cross-protocol callback transaction generation of an embodiment of the present invention;

FIG. 8 is a block diagram of a distributed cross-protocol callback transaction generation device according to an embodiment of the present invention;

FIG. 9 is a block diagram of an alternative generation apparatus for a distributed cross-protocol callback transaction according to an embodiment of the present invention;

fig. 10 is a functional block diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.

It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units.

It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.

The names of messages or information interacted between the various devices in the embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

Description of the terminology:

API gateway: is a term in software engineering, and the main function of the invention is to process calls of different APIs according to the requirement of business transaction processing by intermediaries of transaction processing among a plurality of systems.

Dubbo: is an open-source high-performance and lightweight Java RPC (Remote Procedure Call ) framework, the remote call adopts Dubbo protocol, and the interface is generally a Java Service interface and has a fixed format.

SpringCloud: based on Spring Boot framework, a method for quickly constructing a distributed system is provided for Java developers, remote call is carried out by adopting Http (HyperText Transfer Protocol ) protocol, and an interface is generally a Rest (Representational STATE TRANSFER) style.

Fig. 1 is a flowchart of a method for generating a distributed cross-protocol callback transaction, and fig. 2 is a deployment diagram of a distributed cross-protocol callback transaction according to an embodiment of the present invention, as shown in fig. 1 and fig. 2, where the method includes:

Step S1, receiving a transaction request sent by a cooperative service request end, and distributing the transaction request to a corresponding service micro-service according to interface information of the cooperative service request end.

In this embodiment, multiple API protocols are managed in a unified manner, and the transaction request is distributed and processed by receiving the transaction and callback transaction through the API interface according to the type of the co-operating mechanism, the product number, the transaction type, the transaction flow, and the like. Specifically, the transaction request refers to an interface call initiated by an external collaboration mechanism system, each collaboration mechanism has a collaboration service system, and the API gateway distributes the transaction request to the corresponding service micro-service through the micro-service port according to the interface information of the collaboration service request end, such as ip, port, URL (Uniform Resource Locator ) and the like.

Step S2, service transaction configuration information is obtained from the transaction message according to the transaction request, the transaction type and the protocol type of callback transaction are determined according to the service transaction configuration information, and service processing is carried out on the transaction message according to the transaction type, so that a service processing result is obtained. In this embodiment, the receiving and callback transactions are respectively parsed, service transaction configuration information is obtained from the receiving transaction, transaction type and protocol type of the callback transaction are obtained from the callback transaction, and service processing is performed on the transaction message through service processing 1, service processing 2 … …, service processing n, and the like according to the transaction type, and the details are described below by taking the paying as an example.

FIG. 3 is a deployment diagram of a processing flow of a payment service according to an embodiment of the present invention, where, as shown in FIG. 3, a transaction type may be payment, credit, withdrawal, repayment, and payment, and in this embodiment, as shown in FIG. 3, the payment service may include a plurality of partners such as a partner service 1, a service partner 2 … …, and a service partner n, where each service partner corresponds to a micro service, for example, a service 1 micro service, a service 2 micro service … …, and each micro service is deployed with a plurality of transactions, for example, a transaction 1 consumer, a transaction 2 consumer, and a transaction 3 producer, where a payment application consumer, a payment inquiry consumer, and a payment callback producer are a group of transactions of the payment service, and the transaction consumer generally refers to a caller that initiates a transaction request, and is a client; the transaction producer generally refers to a service end for providing transaction processing, the payment application consumer is a calling party of the payment application transaction, and the callback producer is a service end for providing callback transaction.

Specifically, the business microservice consumer performs validity and integrity check on the transaction message, where transaction validity refers to whether the message meets interface conventions, for example: message length, format (text, numerical value, etc.), mandatory padding, etc.; the integrity of the transaction means that the content, structure and sequence of the message remain intact during the transaction process, are not modified, destroyed or lost by unauthorized, and send the transaction request to the micro-service transaction producer for processing after checking the message. The business transaction producer processes the prior processing of the cash release transaction according to business requirements: the business transaction producer analyzes the message according to the requirement, acquires the client identification and the application credit information from the message, and then obtains the credit state, the client information and the contract information in the information system in a correlated inquiry mode according to the client identification. The micro-service of the money release service submits the application to an associated system, such as a core money release system, a super-network money release system and a three-party payment money release system in a banking system, according to the money release type and related information, wherein the money release type refers to the core money release through the super-network, the three-party payment or the core money release; the related information includes: transaction time, business date, application number, application amount, etc. And returning the processing result information to the business micro-service according to the real-time return message or the asynchronous query result of the associated system, and finally returning the result callback to the cooperative business system by the business micro-service. Wherein, the real-time return message refers to whether the money release is successful or not, and interface appointment information such as a service status code is returned to the requester; but the partner does not receive the business return message information and can inquire the result of the money-releasing transaction according to the number of the request transaction, namely, asynchronous inquiry.

And step S3, carrying out transaction dynamic configuration on the callback interface according to the service processing result and the protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of the service micro-service.

In this embodiment, the service processing result and the protocol type are assembled to generate a callback transaction instance for calling by the API; specifically, in this embodiment, a callback transaction instance is dynamically configured and generated according to transaction information, that is, protocol conversion is performed according to a service processing result and a protocol type, a forwarding queue is configured, the protocol type of a target transaction to be called is determined according to analysis and distribution configuration of service transaction, and http transaction or Dubbo transaction is created by using a spring type loader, annotation management and other tools, so that protocol conversion of service transaction is realized. Finally, reasonable expansion and contraction of the general transaction micro-service are realized, and the number of deployment examples and release times of versions are reduced; thereby reducing the workload of operation and maintenance personnel and the complexity of online.

According to the invention, through transaction dynamic configuration, different callback protocols can be supported, and callback transaction routing nodes are processed according to transaction information; the dependence of the client and the service processing end is eliminated, the complexity of construction and later maintenance of the information system is reduced, different protocols are dynamically assembled according to the business transaction configuration information, the transaction protocols and the like, a callback function for processing business transactions universally across transaction types, service protocols or middleware is realized, the callback function can be distributed to different micro-service processing nodes, and the universality and the processing performance of the transaction processing system are improved.

And S4, grouping and version matching are carried out on callback transactions according to the callback transaction instance, a matching result is obtained, callback transaction processing is carried out according to the matching result, and a callback transaction processing result is obtained.

Specifically, the distributed microservice framework itself does not support calls between different packets and versions; in some scenarios, however, a different packet of business transactions is required to invoke a certain fixed packet of business transactions. And configuring the callback transaction corresponding relation in the distribution configuration manager according to the service logic requirement.

And S5, calling a callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing.

In this embodiment, the service logic processing includes determining packet and version information of the transaction according to the requirement, configuring whether the callback transaction is Dubbo protocol or http protocol according to the protocol type, configuring ip address, port, service name, interface name and the like to be specifically used in the transaction, and generating the callback transaction after assembling according to the protocol type and the configuration thereof and the obtained packet and version information of the service logic processing.

According to the embodiment of the invention, the original Dubbo protocol-based transaction call is converted into the http protocol-based transaction call, dubbo transaction or http transaction is dynamically generated according to the transaction configuration, and service registration and discovery with middleware are completed, so that the service transaction design difficulty is reduced, and the code development quantity is reduced; therefore, the workload and the technical difficulty of developers are reduced, and dynamic transaction management is designed and realized by selecting the processes of application extension configuration initialization, micro-service producer and consumer instantiation, and micro-service registration and discovery in the micro-service according to the condition that the service adjustment frequency corresponds to the development quantity.

In some embodiments, before receiving the transaction request sent by the collaboration service request end in step S1, the method may further include:

And configuring the call mapping relation between the business transactions in a database, reading the call mapping relation between the business transactions from the database, and matching the business transactions to callback transactions needing to be called according to the call mapping relation.

In this embodiment, mapping relationships are configured between different protocols according to service requirements, and the mapping relationships are stored in a database, and if callback transaction protocols are different from request transactions, transaction protocols are obtained; the embodiment provides two transaction interfaces, one http protocol and one Dubbo protocol; the configuration information comprises transaction types, interface URLs, groups and versions, and is stored in a database; and managing the supported callback transaction by maintaining the configuration information, and if the information of the callback transaction request is in the supporting range, instantiating and generating the callback transaction when calling.

In some embodiments, in step S2, performing service processing on the transaction message according to the transaction type, and after obtaining the service processing result, the method may further include: and uniformly managing the protocol types and the API interfaces in the service processing process, and storing the protocol types and the API interfaces in a database in a configuration table form.

In the process of service processing, the embodiment carries out unified standard management on the communication protocol types and the API interfaces of all transactions related to service processing and stores the unified standard management in a database in the form of a configuration table.

In some embodiments, the performing service processing on the transaction message according to the transaction type specifically includes:

Verifying the transaction message in the transaction request to obtain a verification result of the transaction message; carrying out service processing on the verified transaction message according to the transaction type according to the verification result of the transaction message, and sending the service processing result to the association system; and receiving a real-time return message or an asynchronous query result of the associated system, and calling back the real-time return message or the asynchronous query result to the cooperative service request end.

As an illustration, taking the case of money release, in the process of business processing money release, the money release business processing converts the money release type submitted by the business micro-service into a message, and then sends the transaction message submitted by the business cooperation system to the banking system. In this embodiment, the payoff application producer, the payoff inquiry producer and the payoff callback consumer together complete the payoff business processing flow. The method comprises the steps that a payment application producer processes a payment application, a payment inquiry producer inquires a payment application result, and a payment callback consumer inquires a payment application result.

Fig. 4 is a flowchart of a service process of a payment application according to an embodiment of the present invention, as shown in fig. 4, including the steps of:

s11, receiving a payment application transaction submitted by a cooperative service;

s12, checking whether a payment application number exists in the payment application transaction; if the application number of the money is present, executing the step S13, and if the application number of the money is not present, executing the step S15;

s13, judging whether the transaction is a failed transaction, if so, recording transaction time and transaction data, executing S16, and if not, executing S14;

S14, judging whether the transaction state is a overtime transaction state, if not, executing S17, and if so, recording overtime information, and executing S16;

And S15, judging whether the payment application transaction passes through the payment rule, executing S17 if the payment application transaction passes through the payment rule, and executing S18 if the payment application transaction does not pass through the payment rule. In this embodiment, the payment rule includes a payment amount, a credit check state, and the like.

In this embodiment, the payment amount is the maximum payment amount of the customer in the transaction message of the payment application, and the general customer payment amount is determined by the financial institution after comprehensive evaluation according to a plurality of factors such as credit status, borrowing usage, economic status, collateral or guarantee of the customer. The credit check state refers to a credit check state of a loan, and the credit check state refers to a state of a loan application in the checking process, and generally has the passing or non-passing state, the used credit state, the loan state and the like in the application. For example, when applying for a credit card, the credit card amount of the third party is determined to be the payment amount according to the income information and the like. The three-card application is in a credit examination state when the three-card application is not passed, passes or other credit cards are used or overdue.

S16, executing the transaction failure processing of the money release application;

in this embodiment, the transaction status parameter is marked as a failure identifier, a log is output in a log file, and the transaction result field is updated by the detail record corresponding to the payment application form corresponding to the database as failure.

S17, executing a money release application transaction, and recording a transaction state and transaction information;

S18, ending the flow of the money release application.

Fig. 5 is a flowchart of a processing of a result query service of a payment application according to an embodiment of the present invention, as shown in fig. 5, including the following steps:

s21, receiving a payment result inquiry transaction submitted by the cooperation service;

S22, checking whether a payment result inquiry transaction has a payment application number or not; if the payment application number exists, executing S25; if the request number does not exist, executing S23;

s23, inquiring whether detail transaction data exist, and if so, executing step S24; if the detail transaction data does not exist, recording transaction time and query times, and executing S26;

s24, judging whether the transaction is overtime transaction, if not, the transaction is inquiry failure transaction, executing step S27, if yes, returning to overtime exception, and executing step S26;

S25, returning to a transaction state of the money release application;

S26, returning to the process of paying money;

In this embodiment, in the process of paying money, the transaction result flag in the json message to be returned by the transaction is set to "in the process of paying money".

S27, ending the flow of the result inquiry of the money release application.

Fig. 6 is a flowchart of a processing of a result query service of a payment application according to an embodiment of the present invention, as shown in fig. 6, including the following steps:

s31, paying-out application callback: a general transaction initiates an application callback request;

s32, dynamic transaction processing: the micro-service release callback producer dynamically processes callback transactions;

in this embodiment, the dynamic configuration refers to the process of performing protocol conversion on the business transaction according to the transaction result and the transaction type, and the dynamic configuration is essentially a transaction conversion process.

S33, inquiring the paying-out result: processing information of a paying-out result;

In this embodiment, through the call of the micro-service interface, the customer information and the payment application number are used to query the database for the corresponding payment application detail information, obtain the corresponding result state, and transmit the return value to the next processing procedure according to the interface requirement. For example: inquiring the paying-out result, wherein the inquiring message information is (client number: cure 001, application number: apply001, field n.) and inquiring the client identification card number through the client number, then taking the identification card number and the application number, taking the processing result field of the paying-out application from the application detail table, and finally converting the result into success, failure, abnormality and the like according to the interface standard.

S34, transaction of a cash deposit result: and carrying out the transaction processing of the money release callback.

In this embodiment, according to the result information obtained in S33, a message is assembled, and the transaction of the payment result is called by the micro service, and the subsequent business logic (such as payment contract processing, borrowing generation, payment plan generation, etc.) is processed by the transaction.

Specifically, the embodiment designs and develops a universal transaction API at a business application layer, ensures that stock transaction and subsequent transaction are unified with the transaction interface interaction standard and mode in the platform, ensures that the mode is consistent, initiates an application callback request by the universal transaction after the application transaction is completed, uses a unified interface of the embodiment of the universal transaction when the callback transaction initiates the request to process the transaction in a banking system, needs a transaction processing service of a cash deposit business as a consumer initiates the transaction callback request, and sends a cash deposit result message to a micro service of the cash deposit application.

In some embodiments, in step S3, the transaction dynamic configuration is performed on the callback interface according to the service processing result and the protocol type to generate a callback transaction instance, which specifically includes: performing protocol conversion according to the service processing result, and creating or using the created transaction callback consumer according to the converted protocol; the transaction callback consumer sends a message of a transaction result to a transaction callback producer of the business micro-service; and the transaction callback producer generates callback transaction examples according to the transaction type, the target transaction name, the protocol type, the transaction message and the service processing result.

In this embodiment, according to the analysis and distribution configuration of the service transaction, the protocol type of the target transaction to be invoked is determined, and the http transaction or Dubbo transaction is created by using a spring type loader, annotation management and other tools, so as to implement the protocol conversion of the service transaction. According to the transaction type, the target transaction name, the protocol type, the transaction message and the service processing result, the class loader provided by spring is used for generating micro-service transaction, so that development and release of service transaction codes and service micro-service deployment can be reduced.

FIG. 7 is a flowchart of a distributed cross-protocol callback transaction generation according to an embodiment of the present invention, as shown in FIG. 7, the embodiment designs and develops a general transaction API at a service application layer, and ensures that the interaction standard and mode of stock transaction and subsequent transaction and the transaction interface are unified in the platform, and the mode is consistent; in this embodiment, the existing transactions in the existing system are not modified, and the newly added transaction design criteria are not affected.

The remote procedure call layer in this embodiment includes transaction type processing, business transaction processing, interface configuration processing, packet matching, version matching, callback transaction processing, etc., and specifically includes the following steps:

Transaction type processing: in the embodiment, dubbo transaction or http transaction is needed when transaction callback is distinguished in transaction type processing; namely, acquiring configuration information from a transaction message, and determining the transaction type during transaction callback according to the configuration information;

business transaction processing: and completing the general processing logic required to be processed in the business transaction processing, wherein the general processing logic is a process for uniformly requiring processing of business requirements.

Interface configuration processing: in the embodiment, in interface configuration, according to a transaction result and a transaction type of service processing, a callback interface is dynamically configured; the method comprises the steps that through distributing configuration information, a created callback transaction instance is created or used according to service processing requirements, and a result message is sent to a service micro-service;

packet matching: in the embodiment, callback transaction management performs grouping matching on callbacks according to service logic in grouping matching; and configuring the callback transaction corresponding relation in the distribution configuration manager according to the service logic requirement.

Version matching: in the version matching, callback transaction management carries out version matching on callbacks according to service logic;

Callback transaction processing: judging whether the call is the first call, if the call is not the first call, directly distributing and calling a callback transaction instance, and if the call is the first call, performing a callback transaction generation process; the callback transaction generation process specifically comprises the following steps:

The method comprises the steps of acquiring relevant configuration information of a business micro-service by using monitoring management, generating callback transaction examples through notes according to the relevant configuration information, and registering the callback transaction examples to a registration center of the business micro-service in a dynamic registration mode, namely, a scanning application program is registered to the registration center of the business micro-service when the callback transaction examples are started, wherein the dynamic registration in the embodiment means that the callback transaction examples configured in a database can be registered when the callback transaction examples can be used, and meanwhile, the callback transaction examples configured in the database can also be registered to the registration center. In Java, the monitoring management generally involves the use of event monitors, which are used to monitor the occurrence of specific events (such as button clicks, mouse movements, keyboard inputs, etc.), and perform corresponding operations when the events occur. The annotation generation is to generate or configure java classes by using Spring annotations. In the Spring framework, annotations (Annotations) are heavily used, which serve to reduce the complexity of XML configuration files and provide a declarative way to configure applications.

In the callback transaction generation process, monitoring management is used to obtain configuration information related to micro-services, a required callback transaction instance is generated through annotation according to the related configuration information such as interfaces, grouping and version information matched by service processing logic, and then micro-services are dynamically registered to a registry for service transaction through transaction instance management; the embodiment of the invention can register when in use, and can register the transaction configured in the database to the registration center.

The embodiment ensures that the micro-service management of the transaction is consistent with other micro-services in the platform, and the existing remote control layer can be reused. The existing remote control layer is provided by a micro-service development framework, and all micro-services are used and conform to the unified development specification; multiplexing means that the embodiment of the invention does not affect the existing and newly added micro services, and aims to reduce development cost and release times without modifying the existing micro services.

Normally, the micro-service is registered with the registry by the scanning application at start-up, but the invention can be used to register at the same time as the transaction configured in the database is registered with the registry. The micro-service management of the transaction is guaranteed to be consistent with other micro-services in the platform, and the existing remote control layer is reused. The existing remote control layer is provided by a micro-service development framework, and all micro-services are used and conform to the unified development specification; multiplexing means that the present invention does not affect existing and newly added micro services; the aim is to reduce development cost and release times without modifying the existing micro service.

The embodiment of the invention provides two transaction interfaces, one of which is of an http protocol and one of which is of a Dubbo protocol, can receive transaction requests of different protocols, perform conversion of different protocols, support Dubbo transaction and http transaction, and can quickly integrate micro-service transactions under two frameworks, uniformly manage initialization of service transactions, service transaction distribution execution logic and newly-added transactions, and can be configured and expanded.

When the embodiment of the invention is applied to various distributed micro-service architecture systems, the transaction design and micro-service transformation range and difficulty are reduced, repeated investment of software technology research and development personnel is reduced, the quality of transaction callback processing design development work is improved, the expansibility of the system is improved, the development requirement of rapid change of operation business can be met, the resource investment of enterprises in the construction of the business operation system is reduced, and the speed of digital transformation construction of the enterprises is accelerated.

FIG. 8 is a block diagram of a distributed cross-protocol callback transaction generation device according to an embodiment of the present invention, and as shown in FIG. 8, the device 100 includes:

The transaction request receiving and distributing module 110 is configured to receive a transaction request sent by a cooperative service request end, and distribute the transaction request to a corresponding service micro service according to interface information of the cooperative service request end;

The micro service processing module 120 is configured to obtain service transaction configuration information from the transaction message according to the transaction request, determine a transaction type and a protocol type of the callback transaction according to the service transaction configuration information, and perform service processing on the transaction message according to the transaction type to obtain a service processing result;

The dynamic configuration module 130 is configured to dynamically configure the callback interface according to the service processing result and the protocol type to generate a callback transaction instance, and register the callback transaction instance to a registration center of the service micro-service;

The matching module 140 is configured to group and version match callback transactions according to the callback transaction instance, obtain a matching result, and perform callback transaction processing according to the matching result, so as to obtain a callback transaction processing result;

And the callback transaction generating module 150 is used for calling a callback transaction instance to perform service logic processing according to the callback transaction processing result, assembling the service logic processing result and the protocol type, and completing callback transaction generation and callback transaction processing.

Fig. 9 is a structural block diagram of another generation apparatus for a distributed cross-protocol callback transaction according to an embodiment of the present invention, and as shown in fig. 9, the apparatus 100' provided in this embodiment further includes: the distribution policy configuration module 105 is configured to configure a call mapping relationship between service transactions in a database, read the call mapping relationship between service transactions from the database, and match the service transactions to callback transactions to be invoked according to the call mapping relationship.

For specific details, reference is made to the method embodiments shown in fig. 1 to 7.

Referring now to fig. 10, an electronic device suitable for use in implementing embodiments of the present disclosure is shown.

The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and the like, and stationary terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 10 is merely an example and should not be construed to limit the functionality and scope of use of the disclosed embodiments.

As shown in fig. 10, the electronic device may include a processing means (e.g., a central processor, a graphics processor, etc.) 801 that may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage means 808 into a Random Access Memory (RAM) 803. In the RAM803, various programs and data required for the operation of the electronic device are also stored. The processing device 801, the ROM802, and the RAM803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.

In general, the following devices may be connected to the I/O interface 805: input devices 806 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 807 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, etc.; storage 808 including, for example, magnetic tape, hard disk, etc.; communication means 809. The communication means 809 may allow the electronic device to communicate wirelessly or by wire with other devices to exchange data. While fig. 8 shows an electronic device having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a non-transitory computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via communication device 809, or installed from storage device 808, or installed from ROM 802. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 801.

It should be noted that the computer readable medium described in the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this disclosure, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperTextTransferProtocol ), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the internet (e.g., the internet), and peer-to-peer networks (e.g., ad hoc (peer-to-peer) networks), as well as any currently known or future developed networks.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to:

Acquiring business transaction configuration information from a transaction message according to a transaction request, determining the transaction type and the protocol type of callback transaction according to the business transaction configuration information, and carrying out business processing on the transaction message according to the transaction type to acquire a business processing result;

Carrying out transaction dynamic configuration on a callback interface according to a service processing result and a protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service;

Grouping and version matching are carried out on callback transactions according to the callback transaction instance, a matching result is obtained, callback transaction processing is carried out according to the matching result, and a callback transaction processing result is obtained;

And calling a callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing.

Computer program code for carrying out operations of the present disclosure may be written in one or more programming languages, including but not limited to an object oriented programming language such as Java, smalltalk (an object oriented programming language), c++, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present disclosure may be implemented by means of software, or may be implemented by means of hardware. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this disclosure is not limited to the specific combinations of features described above, but also covers other embodiments which may be formed by any combination of features described above or equivalents thereof without departing from the spirit of the disclosure. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).

Moreover, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims.

Claims

1. A method for generating a distributed cross-protocol callback transaction, the method comprising:

Performing transaction dynamic configuration on a callback interface according to the service processing result and the protocol type to generate a callback transaction instance, and registering the callback transaction instance to a registration center of a service micro-service; wherein the callback interface is dynamically configured to generate callback transaction instances according to the service processing result and the protocol type, the method specifically comprises the following steps: performing protocol conversion according to the service processing result, and creating or using the created transaction callback consumer according to the converted protocol; the transaction callback consumer sends a message of a transaction result to a transaction callback producer of the business micro-service; the transaction callback producer generates callback transaction examples by using a class loader provided by spring according to transaction types, target transaction names, protocol types, transaction messages and service processing results;

Calling the callback transaction instance to carry out service logic processing according to the callback transaction processing result, and assembling the service logic processing result and the protocol type to complete callback transaction generation and callback transaction processing; the business logic processing comprises determining grouping information and version information of a transaction according to requirements, configuring whether a callback transaction is Dubbo protocol or http protocol according to protocol types, and configuring an ip address, a port, a service name and an interface name used by the transaction.

2. The method of claim 1, further comprising, prior to said receiving the transaction request sent by the collaboration service request end:

3. The method of claim 1, further comprising, after said performing a business process on said transaction message according to said transaction type to obtain a business process result:

4. The method of claim 1, wherein the performing service processing on the transaction message according to the transaction type specifically includes:

5. The method of claim 1, wherein the callback transaction processing specifically comprises:

6. A device for generating a distributed cross-protocol callback transaction, said device comprising:

7. The apparatus of claim 6, wherein the apparatus further comprises:

8. An electronic device, comprising:

one or more processors;

Storage means for storing one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the method of generating a distributed cross-protocol callback transaction as claimed in any one of claims 1 to 5.

9. A computer readable medium having stored thereon a computer program, which when executed by a processor implements a method of generating a distributed cross-protocol callback transaction as claimed in any one of claims 1 to 5.