CN114157714B - Method, system and storage device for realizing financial system protocol communication based on Netty - Google Patents
Method, system and storage device for realizing financial system protocol communication based on Netty Download PDFInfo
- Publication number
- CN114157714B CN114157714B CN202111452107.6A CN202111452107A CN114157714B CN 114157714 B CN114157714 B CN 114157714B CN 202111452107 A CN202111452107 A CN 202111452107A CN 114157714 B CN114157714 B CN 114157714B
- Authority
- CN
- China
- Prior art keywords
- request
- protocol
- message
- target
- netty
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 title claims abstract description 48
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000004044 response Effects 0.000 claims abstract description 18
- 230000006978 adaptation Effects 0.000 claims description 53
- 230000001360 synchronised effect Effects 0.000 claims description 29
- 238000004806 packaging method and process Methods 0.000 claims description 17
- 230000007246 mechanism Effects 0.000 claims description 14
- 230000001960 triggered effect Effects 0.000 claims 2
- 238000006243 chemical reaction Methods 0.000 abstract description 11
- 238000012545 processing Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 230000014509 gene expression Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
Abstract
The invention relates to the technical field of financial systems, in particular to a method, a system and storage equipment for realizing financial system protocol communication based on Netty. The method for realizing financial system protocol communication based on Netty comprises the following steps: acquiring a request side protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; sending a message to a target side according to different request modes; and transmitting the acquired response back according to the request side protocol. Through the method, when the protocol types of the target side and the request side are different, the target side and the request side can also perform mutual conversion, including the mutual conversion between the ISO and the http protocols, and when the protocols are the same type, the corresponding relation between the target side and the container does not need decoding, so that the message is not bulked.
Description
Technical Field
The invention relates to the technical field of financial systems, in particular to a method, a system and storage equipment for realizing financial system protocol communication based on Netty.
Background
The communication protocol commonly used in the financial system to the ISO system is a non-plaintext ASCII or binary message, and commonly used Socket communication development is based on a blocking IO (BlockingIO) code (or frame) -BIO for short; or Non-blocking IO (Non-blocking IO) -NIO.
2. Conventional service systems mostly use json format based on Http protocol, or other XML, webSocket protocol message development.
The existing NIO framework, netty, encapsulates only communications. The realization of the centralized processing of the service converted between the two protocols can greatly facilitate the development of us and solve the problem of service dispersion.
Existing patents using Netty protocol are:
CN201610357751 Netty-based financial message processing system
The invention discloses a system for realizing financial message processing based on Netty, which adopts Netty as a bottom framework for sending, receiving and forwarding messages, and realizes the conversion of message multi-format configuration and conversion processing among messages including ISO8583, XML, manager, placeholder, indefinite length, TLV, COP, internal nesting and combined messages through customization in project application. The application realizes format conversion processing of messages including ISO8583, XML, manager, placeholder, indefinite length, TLV, COP, internal nested and combined messages. However, no interworking between the ISO and the common Http protocol is achieved.
CN201711115075: a multi-protocol service communication method, a device and an electronic device:
the embodiment of the invention provides a multi-protocol service communication method, a device and electronic equipment, wherein the method comprises the following steps: receiving a communication protocol request sent by a client, and decoding the communication protocol request to obtain target data; according to the type of the target protocol corresponding to the target data and the corresponding relation between each container and each protocol, mapping the target data into a corresponding target container, and analyzing the target data in the target container to obtain target information corresponding to the target data; and sending the target information to the client through the target protocol. The corresponding relation between the target protocol and the container can be obtained in the decoded target data, so that the transmission among the same protocols is wasted, and the message is also bulked.
In addition, the existing NIO framework-Netty has no disconnection reconnection mechanism, synchronous request, idle client connection recovery and other functions. There is a lack of a system that opens up with the ISO protocol and extends new protocols continuously.
Disclosure of Invention
In view of the above problems, the present application provides a method for implementing financial system protocol communication based on Netty, which is used for solving the technical problems that the existing financial system communication protocol does not implement the inter-conversion between the ISO and http protocols, and the existing financial system communication protocol has no disconnection reconnection mechanism. The specific technical scheme is as follows:
a method for implementing financial system protocol communications based on Netty, comprising the steps of:
acquiring a request side protocol type, and analyzing a request message to obtain service parameters;
encapsulating the service parameters according to the type of the target side protocol;
sending a message to a target side according to different request modes;
and transmitting the acquired response back according to the request side protocol.
Further, the request side protocol type is acquired, and the request message is analyzed to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; ", specifically further comprising the steps of:
if the respective message protocols of the request side and the target side are known, analyzing the request message directly according to the protocol specification of the request side to obtain service parameters;
and acquiring a target side message protocol according to the corresponding relation between the request side and the target side configured in the container, and packaging the service parameters into a message which can be analyzed by the target side.
Further, the request side protocol type is acquired, and the request message is analyzed to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; ", specifically further comprising the steps of:
if the message protocol is the self-defined message protocol, acquiring a request side identifier in the request message and acquiring a target side identifier;
inquiring corresponding request and accepted protocol standards in a container according to the request side identifier and the target side identifier;
analyzing service parameters of the request message;
and packaging the service parameters according to a target side protocol.
Further, the step of sending the message to the target side according to different request modes specifically further includes the steps of:
if the request is an asynchronous request, directly sending a message to a target side;
if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request.
Further, before the step of obtaining the request side protocol type, the method further includes the steps of:
the request side and the target side establish Socket connection through the adaptation service;
triggering a reconnection mechanism when the connection between the request side and the target side is disconnected;
the request side protocol types include: http protocol or ISO protocol, the target side protocol types include: ISO protocol or http protocol;
the http protocol is based on a Spring framework, and the ISO protocol is based on a Netty framework;
when the request side protocol type is http protocol, the request side includes: a server;
when the target side protocol type is an ISO protocol, the target side includes: POS and/or Unionpay.
In order to solve the technical problems, the invention also provides a system for realizing financial system protocol communication based on Netty, which comprises the following specific technical scheme:
a system for implementing financial system protocol communications based on Netty, comprising: the system comprises a request end, a target end and an adaptation service end;
the adaptation service end is respectively connected with the request end and the target end;
the adaptation server is used for: acquiring a request end protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the protocol type of the target end; sending a message to a target end according to different request modes; and transmitting the acquired response back according to the request end protocol.
Further, the adaptation server is further configured to:
if the respective message protocols of the request end and the target end are known, the request message is directly analyzed according to the request end protocol specification to obtain service parameters; acquiring a target end message protocol according to the corresponding relation between a request end and a target end configured in a container, and packaging the service parameters into a message which can be analyzed by the target end;
if the protocol is the self-defined message protocol, acquiring a request end identifier in the request message and acquiring a target end identifier; inquiring corresponding request and accepted protocol standards in a container according to the request end identifier and the target end identifier; analyzing service parameters of the request message; and packaging the service parameters according to a target end protocol.
Further, the adaptation server is further configured to:
if the request is an asynchronous request, directly sending a message to a target end;
if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request.
Further, the adaptation server is further configured to:
before the protocol type of the request end is acquired, the request end and the target end establish Socket connection through the adaptation service;
triggering a reconnection mechanism when the connection between the request end and the target end is disconnected;
the request end protocol types include: http protocol or ISO protocol, and the target protocol types include: ISO protocol or http protocol;
the http protocol is based on a Spring framework, and the ISO protocol is based on a Netty framework;
when the protocol type of the request end is http protocol, the request end comprises: a server;
when the protocol type of the target end is an ISO protocol, the target end includes: POS and/or Unionpay.
In order to solve the technical problems, the invention also provides a storage device, which comprises the following specific technical scheme:
a storage device having stored therein a set of instructions for performing: any of the steps of a method for implementing financial system protocol communications based on Netty as mentioned above.
The beneficial effects of the invention are as follows: a method for implementing financial system protocol communications based on Netty, comprising the steps of: acquiring a request side protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; sending a message to a target side according to different request modes; and transmitting the acquired response back according to the request side protocol. Through the method, various inter-protocol communication is integrated, so that the message forwarding problem of a request side and a target side is solved in a configuration mode. The method comprises the mutual conversion between the ISO protocol and the http protocol, and when the ISO protocol and the http protocol are the same type of protocol, the corresponding relation between the target protocol and the container does not need to be decoded, so that the message is not bloated.
Furthermore, high concurrency and high stability Socket communication is realized based on the Netty framework, and a disconnection reconnection mechanism and a synchronization request are added in the connection process of the target side and the request side, so that the ISO protocol based on the Netty framework can support more functions.
The foregoing summary is merely an overview of the present application, and is provided to enable one of ordinary skill in the art to make more clear the present application and to be practiced according to the teachings of the present application and to make more readily understood the above-described and other objects, features and advantages of the present application, as well as by reference to the following detailed description and accompanying drawings.
Drawings
The drawings are only for purposes of illustrating the principles, implementations, applications, features, and effects of the present application and are not to be construed as limiting the application.
In the drawings of the specification:
FIG. 1 is a flow chart of a method of implementing financial system protocol communications based on Netty in accordance with an embodiment;
FIG. 2 is a flow chart of a message protocol of each of a known request side and a target side according to an embodiment;
FIG. 3 is a flow chart of a custom message protocol according to an embodiment;
FIG. 4 is a schematic diagram of a request side http protocol and a target side ISO853 protocol according to an embodiment;
FIG. 5 is a schematic block diagram of a system for implementing financial system protocol communications based on Netty in accordance with an embodiment;
FIG. 6 is a schematic block diagram of a memory device according to an embodiment;
fig. 7 is a schematic diagram of an Unionpay ISO interface according to an embodiment.
Reference numerals referred to in the above drawings are explained as follows:
500. a system for implementing financial system protocol communications based on Netty,
501. the request end is provided with a data processing unit,
502. the server side is adapted to be used for the service,
503. the target end of the network is provided with a network interface,
600. a storage device.
Detailed Description
In order to describe the possible application scenarios, technical principles, practical embodiments, and the like of the present application in detail, the following description is made with reference to the specific embodiments and the accompanying drawings. The embodiments described herein are only used to more clearly illustrate the technical solutions of the present application, and are therefore only used as examples and are not intended to limit the scope of protection of the present application.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present application. The appearances of the phrase "in various places in the specification are not necessarily all referring to the same embodiment, nor are they particularly limited to independence or relevance from other embodiments. In principle, in the present application, as long as there is no technical contradiction or conflict, the technical features mentioned in the embodiments may be combined in any manner to form a corresponding implementable technical solution.
Unless defined otherwise, technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application pertains; the use of related terms herein is for the description of specific embodiments only and is not intended to limit the present application.
In the description of the present application, the term "and/or" is a representation for describing a logical relationship between objects, which means that there may be three relationships, e.g., a and/or B, representing: there are three cases, a, B, and both a and B. In addition, the character "/" herein generally indicates that the front-to-back associated object is an "or" logical relationship.
In this application, terms such as "first" and "second" are used merely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual number, order, or sequence of such entities or operations.
Without further limitation, the use of the terms "comprising," "including," "having," or other like terms in this application is intended to cover a non-exclusive inclusion, such that a process, method, or article of manufacture that comprises a list of elements does not include additional elements but may include other elements not expressly listed or inherent to such process, method, or article of manufacture.
As in the understanding of the "examination guideline," the expressions "greater than", "less than", "exceeding", and the like are understood to exclude the present number in this application; the expressions "above", "below", "within" and the like are understood to include this number. Furthermore, in the description of the embodiments of the present application, the meaning of "a plurality of" is two or more (including two), and similarly, the expression "a plurality of" is also to be understood as such, for example, "a plurality of groups", "a plurality of" and the like, unless specifically defined otherwise.
Referring to fig. 1 to 4, in this embodiment, a method for implementing a financial system protocol communication based on Netty may be applied to a system for implementing a financial system protocol communication based on Netty, where the system for implementing a financial system protocol communication based on Netty includes: the system comprises a request end, a target end and an adaptation service end.
In the field of financial systems, ISO protocols are often used for POS machines, on the one hand because of the security of ISO protocols and on the other hand because of the greater traffic savings of ISO protocols. The http protocol is used for the server which is in communication with the POS machine, so that the method is very important for realizing the mutual conversion between the ISO protocol and the http protocol in the field of financial systems.
The following describes a method for implementing financial system protocol communication based on Netty with reference to the accompanying drawings:
step S101: and acquiring the protocol type of the request side, and analyzing the request message to obtain the service parameters.
Step S102: and packaging the service parameters according to the type of the target side protocol.
For the discussion of step S101 and step S102, the first is known message protocols of the request side and the destination side, please refer to fig. 2:
step S201: if the respective message protocols of the request side and the target side are known, the request message is directly analyzed according to the request side protocol specification to obtain the service parameters.
Step S201: and acquiring a target side message protocol according to the corresponding relation between the request side and the target side configured in the container, and packaging the service parameters into a message which can be analyzed by the target side.
The second is a custom message protocol, in which the request message carries the identifiers of the request side and the target side and contains a specific service message, so that the communication between the two ends is more flexible, and the protocol can be changed according to the configuration, please refer to fig. 3:
step S301: if the message protocol is the custom message protocol, the request side identifier in the request message is acquired, and the target side identifier is acquired. The request side identity may be denoted as srmid, for example, and the target side identity may be denoted as desId.
Step S302: and inquiring the corresponding request and accepted protocol standard in the container according to the request side identifier and the target side identifier.
Step S303: and analyzing the service parameters of the request message.
Step S304: and packaging the service parameters according to a target side protocol.
After the service parameters are encapsulated according to the target side protocol type, step S103 and step S104 are executed:
step S103: and sending the message to the target side according to different request modes.
Step S104: and transmitting the acquired response back according to the request side protocol.
The request mode corresponding to step S103 may be an asynchronous request or a synchronous request, and if the request mode is an asynchronous request, the message is directly sent to the target side; if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request. A detailed description will be given below with reference to fig. 4.
In fig. 4, the request side is taken as an http protocol platform, and based on a Spring framework, the target side is taken as an ISO8583 protocol, and based on a Netty framework, the following description is developed as an example:
the request side and the target side establish Socket connection through the adaptation service;
triggering a reconnection mechanism when the connection between the request side and the target side is disconnected;
when the request is asynchronous, the http protocol platform sends a service request of an http protocol to an adaptation service, the adaptation service converts the service request into an ISO8583 message, if the connection exists between the service request and the adaptation service, the availability of the connection is checked, if the connection exists, the message is sent, the ISO8583 protocol platform carries out service processing on the received message and responds to the ISO8583 message to the adaptation service, the adaptation service analyzes the message, converts the message into an http protocol format, and returns an http protocol response to the http protocol platform.
When the synchronous request is made, the http protocol platform sends a service request of the http protocol, a callback is suspended, the adaptation service converts the service request into an ISO8583 message, the ISO8583 message adopts a syncId as a transparent field of the synchronous request, the syncId is stored in a cache, if the synchronous Id and the syncId exist, the availability of the connection is checked, if the synchronous Id and the syncId exist, a message with syncId parameters is sent, the ISO8583 protocol platform carries out service processing on the received message, and responds to the ISO8583 message to the adaptation service, the syncId is attached, the adaptation service analyzes the message, converts the message into an http protocol format, the cache is searched according to the syncId, a callback method is taken out, and the response of the http protocol is returned to the http protocol platform.
A method for implementing financial system protocol communications based on Netty, comprising the steps of: acquiring a request side protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; sending a message to a target side according to different request modes; and transmitting the acquired response back according to the request side protocol. Through the method, various inter-protocol communication is integrated, so that the message forwarding problem of a request side and a target side is solved in a configuration mode. The method comprises the mutual conversion between the ISO protocol and the http protocol, and when the ISO protocol and the http protocol are the same type of protocol, the corresponding relation between the target protocol and the container does not need to be decoded, so that the message is not bloated.
Furthermore, high concurrency and high stability Socket communication is realized based on the Netty framework, and a disconnection reconnection mechanism and a synchronization request are added in the connection process of the target side and the request side, so that the ISO protocol based on the Netty framework can support more functions.
Referring to fig. 4 to 5, in the present embodiment, a system 500 for implementing financial system protocol communication based on Netty includes: a request end 501, a target end 503 and an adaptation service end 502;
the adaptation service terminal 502 is respectively connected with the request terminal 501 and the target terminal 503;
the adaptation server 502 is configured to: the method comprises the steps of obtaining a protocol type of a request terminal 501, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the protocol type of the target end 503; sending the message to the target end 503 according to different request modes; the acquired response is returned in accordance with the protocol of the requesting end 501.
Further, the adaptation server 502 is further configured to:
if the message protocols of the request terminal 501 and the target terminal 503 are known, the request message is directly analyzed according to the protocol specification of the request terminal 501 to obtain service parameters; according to the corresponding relation between the request terminal 501 and the target terminal 503 configured in the container, obtaining the message protocol of the target terminal 503, and encapsulating the service parameters into a message which can be resolved by the target terminal 503;
if the protocol is a custom message protocol, acquiring a request end 501 identifier in a request message and acquiring a target end 503 identifier; according to the identification of the request end 501 and the identification of the target end 503, the corresponding request and accepted protocol standard in the query container are inquired; analyzing service parameters of the request message; and packaging the service parameters according to a target end 503 protocol.
Further, the adaptation server 502 is further configured to:
if the request is an asynchronous request, directly sending a message to the target end 503;
if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request.
Further, the adaptation server 502 is further configured to:
before acquiring the protocol type of the request terminal 501, the request terminal 501 and the target terminal 503 establish Socket connection through an adaptation service;
triggering a reconnection mechanism when the requesting end 501 is disconnected from the target end 503;
the request end 501 protocol types include: http protocol or ISO protocol, the target 503 protocol types include: ISO protocol or http protocol;
the http protocol is based on a Spring framework, and the ISO protocol is based on a Netty framework;
when the protocol type of the request terminal 501 is http protocol, the request terminal 501 includes: a server;
when the protocol type of the target terminal 503 is an ISO protocol, the target terminal 503 includes: POS and/or Unionpay. The silver-colored alliance also has an interface based on the ISO protocol, see corresponding links: https:// download.csdn.net/download/jiehu 3156/9599561utm_source=iteye_new, and fig. 7.
The following is explained in connection with fig. 4:
taking the request end 501 as an http protocol platform and based on a Spring framework, the target end 503 is an ISO8583 protocol and based on a Netty framework for example, the following description is developed:
the request terminal 501 and the target terminal 503 establish Socket connection through the adaptation service terminal 502;
triggering a reconnection mechanism when the requesting end 501 is disconnected from the target end 503;
when the request is an asynchronous request, the http protocol platform sends a service request of an http protocol to the adaptation service end 502, the adaptation service end 502 converts the service request into an ISO8583 message, if the connection exists, the availability of the connection is checked, if the connection is available, the message is sent, the ISO8583 protocol platform carries out service processing on the received message and responds to the ISO8583 message to the adaptation service end 502, the adaptation service end 502 analyzes the message, converts the message into an http protocol format, and returns an http protocol response to the http protocol platform.
When the synchronous request is made, the http protocol platform sends a service request of the http protocol, suspends a callback, the adaptation server 502 converts the service request into an ISO8583 message, the ISO8583 message adopts a syncId as a transparent field of the synchronous request, the syncId is stored in a cache, if the synchronous Id and the syncId exist, the availability of the connection is checked, if the synchronous Id and the syncId exist, a message with a syncId parameter is sent, the ISO8583 protocol platform carries out service processing on the received message, and responds to the ISO8583 message to the adaptation server 502, the syncId is attached, the adaptation server 502 analyzes the message, converts the message into an http protocol format, searches the cache according to the syncId, takes out a callback method, and returns a response of the http protocol to the http protocol platform.
A system 500 for implementing financial system protocol communications based on Netty, comprising: a request end 501, a target end 503 and an adaptation service end 502; the adaptation service terminal 502 is respectively connected with the request terminal 501 and the target terminal 503; the adaptation server 502 is configured to: the method comprises the steps of obtaining a protocol type of a request terminal 501, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the protocol type of the target end 503; sending the message to the target end 503 according to different request modes; the acquired response is returned in accordance with the protocol of the requesting end 501. Through the above system, various inter-protocol communications are integrated to solve the message forwarding problem of the request end 501 and the target end 503 in a configurable manner. The method comprises the mutual conversion between the ISO protocol and the http protocol, and when the ISO protocol and the http protocol are the same type of protocol, the corresponding relation between the target protocol and the container does not need to be decoded, so that the message is not bloated.
Furthermore, high concurrency and high stability Socket communication is realized based on the Netty framework, and a disconnection reconnection mechanism and a synchronization request are added in the connection process of the target end 503 and the request end 501, so that the ISO protocol based on the Netty framework can support more functions.
Referring to fig. 6, in this embodiment, a specific embodiment of a storage device 600 is as follows:
a storage device 600 having stored therein a set of instructions for performing: and acquiring the protocol type of the request side, and analyzing the request message to obtain the service parameters.
And packaging the service parameters according to the type of the target side protocol.
The above discussion is further divided into two cases, the first is the message protocol of each of the known request side and the target side:
if the respective message protocols of the request side and the target side are known, the request message is directly analyzed according to the request side protocol specification to obtain the service parameters.
And acquiring a target side message protocol according to the corresponding relation between the request side and the target side configured in the container, and packaging the service parameters into a message which can be analyzed by the target side.
The second type is a custom message protocol, the request message carries the identifiers of the request side and the target side and contains a specific service message, so that the communication between two ends is more flexible, and the protocol can be changed according to configuration:
if the message protocol is the custom message protocol, the request side identifier in the request message is acquired, and the target side identifier is acquired. The request side identity may be denoted as srmid, for example, and the target side identity may be denoted as desId.
And inquiring the corresponding request and accepted protocol standard in the container according to the request side identifier and the target side identifier.
And analyzing the service parameters of the request message.
And packaging the service parameters according to a target side protocol. After the service parameters are packaged according to the protocol type of the target side, sending messages to the target side according to different request modes; and transmitting the acquired response back according to the request side protocol.
The corresponding request mode may be an asynchronous request or a synchronous request, and if the request mode is an asynchronous request, the message is directly sent to the target side; if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request. A detailed description will be given below with reference to fig. 4.
In fig. 4, the request side is taken as an http protocol platform, and based on a Spring framework, the target side is taken as an ISO8583 protocol, and based on a Netty framework, the following description is developed as an example:
the request side and the target side establish Socket connection through the adaptation service;
triggering a reconnection mechanism when the connection between the request side and the target side is disconnected;
when the request is asynchronous, the http protocol platform sends a service request of an http protocol to an adaptation service, the adaptation service converts the service request into an ISO8583 message, if the connection exists between the service request and the adaptation service, the availability of the connection is checked, if the connection exists, the message is sent, the ISO8583 protocol platform carries out service processing on the received message and responds to the ISO8583 message to the adaptation service, the adaptation service analyzes the message, converts the message into an http protocol format, and returns an http protocol response to the http protocol platform.
When the synchronous request is made, the http protocol platform sends a service request of the http protocol, a callback is suspended, the adaptation service converts the service request into an ISO8583 message, the ISO8583 message adopts a syncId as a transparent field of the synchronous request, the syncId is stored in a cache, if the synchronous Id and the syncId exist, the availability of the connection is checked, if the synchronous Id and the syncId exist, a message with syncId parameters is sent, the ISO8583 protocol platform carries out service processing on the received message, and responds to the ISO8583 message to the adaptation service, the syncId is attached, the adaptation service analyzes the message, converts the message into an http protocol format, the cache is searched according to the syncId, a callback method is taken out, and the response of the http protocol is returned to the http protocol platform.
A storage device 600 having stored therein a set of instructions for performing: acquiring a request side protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the type of the target side protocol; sending a message to a target side according to different request modes; and transmitting the acquired response back according to the request side protocol. Through the above storage device 600, various inter-protocol communications are integrated to solve the message forwarding problem of the request side and the target side in a configurable manner. The method comprises the mutual conversion between the ISO protocol and the http protocol, and when the ISO protocol and the http protocol are the same type of protocol, the corresponding relation between the target protocol and the container does not need to be decoded, so that the message is not bloated.
Furthermore, high concurrency and high stability Socket communication is realized based on the Netty framework, and a disconnection reconnection mechanism and a synchronization request are added in the connection process of the target side and the request side, so that the ISO protocol based on the Netty framework can support more functions.
Finally, it should be noted that, although the foregoing embodiments have been described in the text and the accompanying drawings of the present application, the scope of the patent protection of the present application is not limited thereby. All technical schemes generated by replacing or modifying equivalent structures or equivalent flows based on the essential idea of the application and by utilizing the contents recorded in the text and the drawings of the application, and the technical schemes of the embodiments are directly or indirectly implemented in other related technical fields, and the like, are included in the patent protection scope of the application.
Claims (7)
1. A method for implementing financial system protocol communication based on Netty, comprising the steps of:
acquiring a request side protocol type, analyzing a request message to obtain service parameters, and packaging the service parameters according to a target side protocol type;
sending a message to a target side according to different request modes;
the acquired response is returned according to a request side protocol;
the method comprises the steps of obtaining the protocol type of a request side, analyzing a request message to obtain service parameters, and packaging the service parameters according to the protocol type of a target side, and specifically further comprises the steps of:
if the respective message protocols of the request side and the target side are known, analyzing the request message directly according to the protocol specification of the request side to obtain service parameters; acquiring a target side message protocol according to the corresponding relation between the request side and the target side configured in the container, and packaging the service parameters into a message which can be analyzed by the target side;
if the message protocol is the self-defined message protocol, acquiring a request side identifier in the request message and acquiring a target side identifier; inquiring corresponding request and accepted protocol standards in a container according to the request side identifier and the target side identifier; analyzing service parameters of the request message; packaging the service parameters according to a target side protocol;
the request side protocol type includes: http protocol or ISO protocol, the target side protocol types include: ISO protocol or http protocol; the http protocol is based on a Spring framework, and the ISO protocol is based on a Netty framework;
when the request side protocol type is http protocol, the request side includes: a server;
when the target side protocol type is an ISO protocol, the target side includes: POS and/or Unionpay.
2. The method for implementing financial system protocol communication based on Netty according to claim 1, wherein the step of sending the message to the target side according to different request modes specifically further comprises the steps of:
if the request is an asynchronous request, directly sending a message to a target side;
if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request.
3. The method for implementing financial system protocol communication based on Netty according to claim 1, wherein before the obtaining the request side protocol type, further comprising the steps of:
the request side and the target side establish Socket connection through the adaptation service;
the reconnection mechanism is triggered when the request side is disconnected from the target side.
4. A system for implementing financial system protocol communications based on Netty, comprising: the system comprises a request end, a target end and an adaptation service end;
the adaptation service end is respectively connected with the request end and the target end;
the adaptation server is used for: acquiring a request end protocol type, and analyzing a request message to obtain service parameters; encapsulating the service parameters according to the protocol type of the target end; sending a message to a target end according to different request modes; the acquired response is transmitted back according to the request end protocol;
the adaptation server is further configured to:
if the respective message protocols of the request end and the target end are known, the request message is directly analyzed according to the request end protocol specification to obtain service parameters; acquiring a target end message protocol according to the corresponding relation between a request end and a target end configured in a container, and packaging the service parameters into a message which can be analyzed by the target end;
if the protocol is the self-defined message protocol, acquiring a request end identifier in the request message and acquiring a target end identifier; inquiring corresponding request and accepted protocol standards in a container according to the request end identifier and the target end identifier; analyzing service parameters of the request message; packaging the service parameters according to a target end protocol;
the request end protocol types include: http protocol or ISO protocol, and the target protocol type includes: an ISO protocol or an http protocol, wherein the http protocol is based on a Spring framework, and the ISO protocol is based on a Netty framework;
when the protocol type of the request end is http protocol, the request end comprises: a server;
when the protocol type of the target end is an ISO protocol, the target end includes: POS and/or Unionpay.
5. The system for implementing a financial system protocol communication based on Netty of claim 4,
the adaptation server is further configured to:
if the request is an asynchronous request, directly sending a message to a target end;
if the request is a synchronous request, a preset field is used as a transparent field of the synchronous request.
6. The system for implementing a financial system protocol communication based on Netty of claim 4,
the adaptation server is further configured to:
before the protocol type of the request end is acquired, the request end and the target end establish Socket connection through the adaptation service;
when the connection between the request end and the target end is disconnected, a reconnection mechanism is triggered.
7. A storage device having stored therein a set of instructions for performing: a method of implementing financial system protocol communications based on Netty as claimed in any one of claims 1 to 3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111452107.6A CN114157714B (en) | 2021-12-01 | 2021-12-01 | Method, system and storage device for realizing financial system protocol communication based on Netty |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111452107.6A CN114157714B (en) | 2021-12-01 | 2021-12-01 | Method, system and storage device for realizing financial system protocol communication based on Netty |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114157714A CN114157714A (en) | 2022-03-08 |
| CN114157714B true CN114157714B (en) | 2024-02-13 |
Family
ID=80455224
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111452107.6A Active CN114157714B (en) | 2021-12-01 | 2021-12-01 | Method, system and storage device for realizing financial system protocol communication based on Netty |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114157714B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116055577B (en) * | 2023-01-28 | 2023-07-14 | 东方合智数据科技(广东)有限责任公司 | Protocol conversion method, device, equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004056071A1 (en) * | 2002-12-17 | 2004-07-01 | Sema | Communication method between servers with data format conversion and device therefor |
| CN106027534A (en) * | 2016-05-26 | 2016-10-12 | 浪潮（苏州）金融技术服务有限公司 | System for implementing financial message processing based on Netty |
| CN107835178A (en) * | 2017-11-13 | 2018-03-23 | 北京奇艺世纪科技有限公司 | A kind of multi-protocols communication for service method, apparatus and electronic equipment |
| CN110971614A (en) * | 2019-12-17 | 2020-04-07 | 软通动力信息技术（集团）有限公司 | Internet of things adaptation method and system, computer equipment and storage medium |
| CN111641528A (en) * | 2020-05-29 | 2020-09-08 | 山东浪潮通软信息科技有限公司 | Device management method, device, storage medium and computer readable medium |
-
2021
- 2021-12-01 CN CN202111452107.6A patent/CN114157714B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004056071A1 (en) * | 2002-12-17 | 2004-07-01 | Sema | Communication method between servers with data format conversion and device therefor |
| CN106027534A (en) * | 2016-05-26 | 2016-10-12 | 浪潮（苏州）金融技术服务有限公司 | System for implementing financial message processing based on Netty |
| CN107835178A (en) * | 2017-11-13 | 2018-03-23 | 北京奇艺世纪科技有限公司 | A kind of multi-protocols communication for service method, apparatus and electronic equipment |
| CN110971614A (en) * | 2019-12-17 | 2020-04-07 | 软通动力信息技术（集团）有限公司 | Internet of things adaptation method and system, computer equipment and storage medium |
| CN111641528A (en) * | 2020-05-29 | 2020-09-08 | 山东浪潮通软信息科技有限公司 | Device management method, device, storage medium and computer readable medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114157714A (en) | 2022-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2002351015B2 (en) | Method and device for defining objects allowing to establish a device management tree for mobile communication devices | |
| CN107018147B (en) | Internet of things communication method and system and gateway module | |
| CN110022289B (en) | Data transmission method, device and system | |
| US7103676B2 (en) | User-identifier translator and linking apparatus for XML-based services and corresponding method | |
| CN111176180B (en) | Heterogeneous internet of things equipment management system | |
| CN105245445A (en) | Internet of things gateway | |
| EP2571224B1 (en) | Method for processing messages on m2m platform and m2m platform system | |
| CN111083161A (en) | Data transmission processing method and device and Internet of things equipment | |
| CN101521615B (en) | Communication method for different networks and internetwork for smart machine | |
| CN112688952B (en) | Message processing method, device, radio remote unit and medium | |
| CN114157714B (en) | Method, system and storage device for realizing financial system protocol communication based on Netty | |
| CN113141673B (en) | Link configuration method, device, system and storage medium in multi-link system | |
| CN111294235A (en) | Data processing method, device, gateway and readable storage medium | |
| EP2913977A2 (en) | Resource information acquisition method, system and device for internet of things terminal device | |
| CN114338274B (en) | Heterogeneous industrial field bus fusion method and system | |
| CN108446105A (en) | A kind of Lightweight AP I Server Development Frameworks and development approach | |
| CN104253763A (en) | Method for realizing data transmission in gateway equipment of ubiquitous network and gateway equipment using method | |
| US10645184B2 (en) | Information transmission method, gateway, and controller | |
| CN107181794A (en) | DICOM network transmission systems with receiving are sent based on DIMSE message | |
| CN113890891A (en) | Data sharing interaction method and device of energy cloud network | |
| WO2016110070A1 (en) | Data acquiring method and device, and storage medium | |
| CN105656760B (en) | Communication means and system between software package | |
| CN102263707A (en) | Method and system for sending messages | |
| CN115150207B (en) | Industrial network equipment identification method and device, terminal equipment and storage medium | |
| CN102523069A (en) | Method for sending message |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |