CN112671842B

CN112671842B - Information transmission method and device, electronic equipment and readable storage medium

Info

Publication number: CN112671842B
Application number: CN202011443653.9A
Authority: CN
Inventors: 李立夫; 陈策; 王杰
Original assignee: Chengdu Quality Starker Technology Co Ltd
Current assignee: Chengdu Quality Starker Technology Co Ltd
Priority date: 2020-12-08
Filing date: 2020-12-08
Publication date: 2022-07-12
Anticipated expiration: 2040-12-08
Also published as: CN112671842A

Abstract

The embodiment of the invention provides an information transfer method, an information transfer device, electronic equipment and a readable storage medium, and aims to improve the convenience of information transfer. The method is applied to message middleware and comprises the following steps: obtaining transactions from a blockchain network, wherein each transaction carries a message identifier, and a plurality of transactions analyzed from the same first service message carry the same message identifier; reading a service type identifier and a version number from a plurality of transactions carrying the same message identifier; inquiring a first assembly strategy corresponding to the service type identifier and the version number at the same time from a plurality of first assembly strategies; under the condition that the corresponding first assembly strategy is not inquired, inquiring a second assembly strategy corresponding to the service type identification from a plurality of second assembly strategies; based on the inquired second assembly strategy, reading key information agreed by the second assembly strategy from the plurality of transactions to assemble a second service message; and sending the assembled second service message to an information demand side.

Description

Information transmission method and device, electronic equipment and readable storage medium

Technical Field

The present invention relates to the field of communications technologies, and in particular, to an information transfer method and apparatus, an electronic device, and a readable storage medium.

Background

The block chain technology is realized on a block chain network, distributed node equipment (hereinafter referred to as nodes) in the block chain network realizes generation and consensus of block data by operating a block chain program, finally realizes a tamper-proof mechanism of the data, and provides a safe and reliable new technical idea for business development.

The block chain technology can be applied to various service scenes, such as the financial field, the electronic commerce field, the commodity or raw material tracing field, the electronic evidence storage field and the like.

In the related art, when a user develops a service by using a blockchain network, it is generally required to construct one or more transactions related to the service and submit the constructed one or more transactions to the blockchain network for execution. In addition, in the related art, when a user needs to query service information related to the user or related to another user, one or more transactions related to the service are generally required to be acquired from the blockchain network, and then the acquired one or more transactions are read one by one, so that the corresponding service information is read. However, since the transaction structure is complex and the readability of the transaction data is low, the complexity of the transaction interpretation process is high and the user experience is low.

It can be seen that in the related art, the complexity of querying and interpreting service information from the blockchain network is high, which results in poor convenience of information delivery.

Disclosure of Invention

Embodiments of the present invention provide an information transfer method, an information transfer apparatus, an electronic device, and a readable storage medium, which are intended to improve convenience of information transfer. The specific technical scheme is as follows:

in a first aspect of the embodiments of the present invention, an information transfer method is provided, which is applied to a message middleware, and the method includes:

obtaining transactions from a blockchain network, wherein each transaction carries a message identifier, and a plurality of transactions analyzed from the same first service message carry the same message identifier;

aiming at a plurality of transactions carrying the same message identification, reading a service type identification and a version number carried by the transaction from any one of the transactions, wherein the service type identification and the version number carried by the transaction are from a first service message analyzed into the transaction;

inquiring a first assembly strategy corresponding to the service type identifier and the version number at the same time from a plurality of first assembly strategies according to the read service type identifier and the read version number;

under the condition that a first assembly strategy corresponding to the service type identifier and the version number at the same time is not inquired, inquiring a second assembly strategy corresponding to the service type identifier from a plurality of second assembly strategies;

based on the inquired second assembly strategy, reading key information agreed by the second assembly strategy from the plurality of transactions, and assembling a second service message according to the read key information; the key information in the transactions is part of information in a first service message analyzed into the transactions;

and sending the assembled second service message to an information demand side.

In a second aspect of the embodiments of the present invention, an information delivery apparatus is provided, which is applied to a message middleware, and the apparatus includes:

the transaction acquisition module is used for acquiring transactions from the blockchain network, wherein each transaction carries a message identifier, and a plurality of transactions analyzed from the same first service message carry the same message identifier;

the information reading module is used for reading a service type identifier and a version number carried by any transaction from the transactions aiming at a plurality of transactions carrying the same message identifier, wherein the service type identifier and the version number carried by the transaction are from a first service message analyzed into the transaction;

the first assembly strategy query module is used for querying a first assembly strategy which simultaneously corresponds to the service type identifier and the version number from a plurality of first assembly strategies according to the read service type identifier and the read version number;

the second assembly strategy query module is used for querying a second assembly strategy corresponding to the service type identifier from a plurality of second assembly strategies under the condition that the first assembly strategy corresponding to the service type identifier and the version number at the same time is not queried;

the second service message assembly module is used for reading key information agreed by the second assembly strategy from the plurality of transactions based on the inquired second assembly strategy and assembling a second service message according to the read key information; the key information in the transactions is part of information in a first service message analyzed into the transactions;

and the message sending module is used for sending the assembled second service message to the information demand side.

In a third aspect of the embodiments of the present invention, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;

the memory is used for storing a computer program;

the processor is used for realizing the information transmission method provided by any embodiment of the invention when executing the program stored in the memory.

In a fourth aspect of the embodiments of the present invention, there is provided a computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the information delivery method provided by any of the embodiments of the present invention.

In the invention, each transaction carries a message identifier, and a plurality of transactions analyzed by the same first service message carry the same message identifier. Therefore, a plurality of transactions carrying the same message identifier correspond to the same first service message, and further correspond to services to be processed by the first service message. Therefore, the service information can be reflected according to the messages assembled by a plurality of transactions carrying the same message identification. And then the assembled message is sent to the information demand party, so that the information demand party can obtain the service information simply, conveniently and quickly by analyzing the message. Therefore, the method and the device can improve the convenience of information transfer and improve the user experience.

In addition, considering that the versions of the first service packet may be updated successively, the first service packets of multiple versions may be in a coexisting state. However, since some message middleware may not be updated in time, the message middleware which is not updated cannot assemble a new version of the service message. Therefore, when the message middleware fails to inquire a first assembly strategy corresponding to the service type identifier and the version number at the same time from the plurality of first assembly strategies, inquiring a second assembly strategy corresponding to the service type identifier from the plurality of second assembly strategies, reading key information appointed by the second assembly strategy from a plurality of transactions based on the inquired second assembly strategy, and assembling a second service message according to the read key information. Thus, although the message middleware can not transmit the complete service information to the information demand side, the message middleware can transmit the key information to the information demand side, thereby meeting the user demand as much as possible.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 is a schematic diagram of an information delivery method based on a service processing system according to an embodiment of the present invention;

fig. 2 is a flowchart of an information delivery method according to an embodiment of the present invention;

fig. 3 is a schematic diagram of an information delivery apparatus according to an embodiment of the present invention;

fig. 4 is a schematic diagram of an electronic device according to an embodiment of the invention.

Detailed Description

The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the embodiments described are only a few embodiments of the present invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

In the related art, when a user develops a service by using a blockchain network, it is generally required to construct one or more transactions related to the service and submit the constructed one or more transactions to the blockchain network for execution. In addition, in the related art, when a user needs to query service information related to the user or related to another user, one or more transactions related to the service are generally required to be acquired from the blockchain network, and then the acquired one or more transactions are read one by one, so that the corresponding service information is read. However, since the transaction structure is complex and the readability of the transaction data is low, the transaction interpretation process is complex and the user experience is low. It can be seen that in the related art, the complexity of querying and interpreting service information from the blockchain network is high, which results in poor convenience of information delivery.

In view of the above, the present invention provides an information transfer method, an information transfer apparatus, an electronic device, and a readable storage medium through the following embodiments, which aim to improve convenience of information transfer.

Referring to fig. 1, fig. 1 is a schematic diagram of an information delivery method based on a service processing system according to an embodiment of the present invention. As shown in fig. 1, the service processing system includes: the system comprises a block chain network, a plurality of message middleware and a plurality of user terminals. The client may be communicatively coupled to message middleware, which may in turn be communicatively coupled to any node or designated node within the blockchain network. Thus, the user terminal realizes indirect communication with the block chain network through the message middleware.

Specifically, the user side transmits a service message related to the service to the message middleware, thereby realizing information transfer to the message middleware. The message middleware analyzes the service message sent by the user side into one or more transactions and submits the analyzed transactions to the block chain network, so that information is transmitted to the block chain network. In addition, the message middleware acquires information from the blockchain network through the blocks generated by the synchronous blockchain network or the account book database of the synchronous blockchain network. The message middleware assembles the information acquired from the blockchain network into a service message related to the service and returns the assembled service message to the user side, thereby realizing the information transmission to the user side. Thus, the user terminal realizes indirect communication with the block chain network through the message middleware.

The message middleware encapsulates the complex interface of the blockchain network into a simple and standard financial service interface and provides the interface to the user side, so that the interaction difficulty between the user side and the blockchain network is reduced.

In the service processing system, the user side, the message middleware and the block chain network are three technical layers from top to bottom, and the three technical layers can be represented as a hardware layer or a software layer, which is not limited in the present invention.

For example, the message middleware may be a software program or a hardware device. In the case that the message middleware is a software program, the message middleware may run in a certain node device of the blockchain network, may run in a computer on the user side, and may run in a certain computer between the blockchain network and the user side.

For example, the user terminal may be a software program or a hardware device. In the case that the user terminal is a software program, the user terminal may operate in a certain node device of the blockchain network, or may operate in a computer separately outside the blockchain network.

Optionally, in some embodiments, the information is transferred between the user terminal and the message middleware based on the communication message. When the user end transmits the service information to the message middleware, the user end packages the service message in the message body of the communication message, and the service message is sent to the message middleware by the user end along with the communication message. Similarly, when the message middleware transmits service information to the user terminal, the message middleware encapsulates the service message in the message body of the communication message, and the service message is sent to the user terminal by the message middleware along with the communication message. The communication message may be selected from: hypertext transfer protocol messages (HTTP), user datagram protocol messages (UDP), and the like. It should be noted that the present invention does not limit the type of the communication packet.

Optionally, in some embodiments, each ue corresponds to a message middleware, and one message middleware may correspond to multiple ues. Each user terminal realizes indirect communication with the block chain network through the corresponding message middleware.

In specific implementation, different user groups respectively correspond to different message middleware, so that each user group can independently manage and maintain the message middleware, and the security of the message middleware is favorably improved. For ease of understanding, multiple branches of a bank may, for example, be considered a group of users. For example, a plurality of branches of bank a correspond to message middleware a, a plurality of branches of bank B correspond to message middleware B, and a plurality of branches of bank C correspond to message middleware C. In this scenario, by implementing the following information transfer method, when each bank processes the service using the blockchain network, information can be conveniently transferred between different banks (for example, between bank a and bank B) through the blockchain network.

The structure of the service processing system proposed by the present invention is introduced above. Hereinafter, an information transfer method based on the service processing system will be described.

As shown in fig. 1, the user terminal a1 sends a first service packet to the message middleware a in response to a user operation, where the first service packet carries a service type identifier and a version number.

The service type identifier carried by the first service packet is used for representing: the first service message is used for processing the service type. For ease of understanding, it is assumed by way of example that a user currently wants to publish an asset in a blockchain network, the user may send a first service message for publishing the asset to the message middleware through the user terminal a1, where the service type carried in the first service message is identified as SMTA, and SMTA indicates that the first service message is used for publishing the asset. Or, for example, assuming that the user currently wants to roll back all assets hosted in a certain intelligent contract to its own account, the user may send a first service packet for asset roll-back to the packet middleware through the user end a1, where the service type carried in the first service packet is denoted as SMTC, and the SMTC denotes that the first service packet is used for rolling back assets. The user may be an individual user or an enterprise user (e.g., a financial institution such as a bank or a stock exchange).

The version number carried by the first service message is used for representing: a message version of the first service message. Two first service messages (i.e., first service messages of different versions for processing the same service) carrying the same service type identifier but having different version numbers may have a slight difference. For ease of understanding, the version V2.0 of the first service message for publishing assets is illustratively added with a field for recording the supervisor ID compared to the version V1.0 of the first service message for publishing assets.

In a specific implementation, the service type identifier and the version number carried in the first service packet may be in the form of "SMTC _ V2.0". If the first service message carries 'SMTC _ V2.0', it indicates that the first service message is used for returning back assets, and the message version of the first service message is V2.0.

It should be noted that, because the version of each ue is different, the message version supported by each ue may be different. For ease of understanding, it is assumed by way of example that the message versions currently supported by client a1 include: a first service message V1.0 version for issuing assets, a first service message V2.0 version for issuing assets, a first service message V1.0 version for asset fallback, a first service message V2.0 version for asset fallback. And the message versions currently supported by client B1 include: the first service message V1.0 version for issuing the assets, the first service message V1.0 version for asset rollback and the first service message V2.0 version for asset rollback.

As shown in fig. 1, after receiving a first service message sent by a user a1, a message middleware a parses the first service message into a plurality of transactions, where each transaction in the plurality of transactions carries a message identifier of the first service message, and a part or all of the transactions in the plurality of transactions carries a service type identifier and a version number of the first service message.

Optionally, in some specific embodiments, multiple analysis strategies for analyzing the first service packet are preset in the packet middleware a, each analysis strategy corresponds to one service type identifier and version number, and is used for analyzing the first service packet that simultaneously includes the corresponding service type identifier and the corresponding version number, so as to obtain one or more transactions related to the corresponding service type.

For convenience of understanding, referring to table 1, for example, what is recorded in table 1 is a parsing policy preset in the message middleware a. It can be seen that two first service messages carrying the same service type identifier but with different version numbers respectively correspond to different parsing strategies. Similarly, two first service messages carrying the same version number but different service type identifiers also respectively correspond to different parsing strategies.

Table 1 message middleware a preset parsing strategy

Resolution strategy	Service type identification	Version number
			Resolution strategy X	SMTA (for publishing assets)	V1.0
Resolution strategy Y	SMTC (for backspace assets)	V1.0
			Resolution strategy Z	SMTC (for backspacing assets)	V2.0

It should be noted that, in an actual application scenario, the update time of the message middleware a may be later than the update time of the user terminal a1, so that some message versions supported by the user terminal a1 (for example, the first service message V2.0 version for publishing assets) have no corresponding parsing policy in the message middleware a.

When the message middleware a receives a first service message sent by the user side a1, the message middleware a reads the service type identifier and the version number from the first service message, and searches an analysis policy which simultaneously corresponds to the service type identifier and the version number from a plurality of preset analysis policies by using the read service type identifier and the read version number as indexes. If the message middleware a finds the corresponding analysis strategy, the message middleware a analyzes the first service message into a plurality of transactions based on the found analysis strategy. If the message middleware a does not find the corresponding parsing policy, the message middleware a may not parse the first service message, and may also feed back a prompt message indicating that parsing fails to the client a 1.

In a specific implementation, a parsing policy is actually a segment of computer program, and the message middleware a executes the segment of computer program, thereby executing the parsing policy.

The analysis strategy is at least used for limiting the message analysis operation as follows:

1. the transaction quantity of the transaction and the type of each transaction which are required to be analyzed by the first service message;

2. for each transaction, defining the transaction data required to be carried by the transaction; and for each transaction data, defining from which field of the first service message the transaction data is specifically obtained, and defining at which field of the transaction template the transaction data is filled.

For understanding, the message middleware a illustratively reads the service type identifier and the version number "SMTC _ V2.0" from the first service message after receiving the first service message sent by the user terminal a 1. Then, the message middleware a uses the service type identifier SMTC and the version number V2.0 as an index, and finds out an analysis policy Z corresponding to both the service type identifier SMTC and the version number V2.0 from the analysis policies shown in table 1. And then, the message middleware a analyzes the first service message according to the determined analysis strategy Z.

The analysis strategy Z makes the following restrictions on the message analysis operation:

1. and analyzing the first service message into 2 transactions, namely an asset rollback transaction r and an intelligent contract freezing transaction f.

2-1, reading a transaction code from the 21 st to the 100 th fields of the first service message when constructing the asset rollback transaction r, and filling the read transaction code into the 11 th to the 90 th fields of the transaction template r; reading contract addresses from the 5 th and 6 th fields of the first service message, and filling the read contract addresses into the 9 th and 10 th fields of the transaction template r; and filling the transaction template r of the transaction data to form the asset rollback transaction r.

2-2, when a contract freezing transaction f is constructed, reading a transaction code from the 106 th field to the 150 th field of the first service message, and filling the read transaction code into the 11 th field to the 55 th field of the transaction template f; reading contract addresses from the 5 th and 6 th fields of the first service message, and filling the read contract addresses into the 9 th and 10 th fields of the transaction template f; and filling the transaction template f of the transaction data to form an intelligent contract frozen transaction f.

It should be noted that the specific data (such as the service type identifier, transaction amount, transaction data, field number, etc.) referred to in the above examples are only illustrative examples. During actual implementation of the invention, the actual data involved may be the same as or different from the data in the above examples.

It should be further noted that the above limitation of the parsing policy on the message parsing operation is only an example. Any modification, equivalent replacement, improvement, etc. made by those skilled in the art within the spirit and principle of the above examples are included in the scope of protection of the present invention.

Optionally, in some specific embodiments, after receiving the first service packet, the message middleware a generates a unique message identifier for the first service packet. For example, in order to generate a Unique packet Identifier for the first service packet, the packet middleware a may input data such as a timestamp, a number of the packet middleware a itself, and a Universal Unique Identifier (UUID) into the hash algorithm model, so as to obtain a string of hash values output by the hash algorithm model, and then use the first n bits (for example, the first 25 bits) of the hash value as the packet Identifier of the first service packet. And the message middleware a analyzes the first service message into a plurality of transactions, and fills the message identifier of the first service message into each transaction.

Or alternatively, in other embodiments, the first service packet sent by the user terminal a1 carries the packet identifier itself. The message identifier is generated by the user terminal a1 for the first service message, and the specific generation method can refer to the above. After the message middleware a parses the first service message into a plurality of transactions, the message identifier may be read from the first service message, and the read message identifier is filled into each transaction.

Optionally, in some specific embodiments, after the message middleware a parses the first service message into several transactions, the service type identifier and the version number may be read from the first service message, and then the read service type identifier and the version number are filled into some or all of the several transactions.

As shown in fig. 1, after the message middleware a parses the first service message into a plurality of transactions, the transactions are submitted to the blockchain network for execution. It should be noted that, the invention is not limited to the specific way the blockchain network performs transactions. To simplify the drawing, the specific process of performing transactions by the blockchain network is not shown in fig. 1.

As shown in fig. 1, the message middleware b continuously synchronizes the blocks generated by the blockchain network and reads the transaction recorded by the block from the synchronized block. The message middleware B assembles a second service message or a third service message according to a plurality of transactions carrying the same message identifier, and then sends the assembled second service message or third service message to the user side B1 and the user side B2.

It should be noted that the message middleware b can read the transaction from the block through the block of the synchronous blockchain network. The message middleware b can also synchronize the ledger database of the blockchain network, so as to read the transaction from the ledger data. To simplify the drawing, the way in which the message middleware b synchronizes blocks from the blockchain network is only briefly shown in fig. 1.

Optionally, in some specific embodiments, the message middleware b detects, for each read transaction, a message identifier carried by the transaction, and the message middleware b takes multiple transactions carrying the same message identifier as a group of transactions.

Optionally, in some specific embodiments, multiple first assembly policies for assembling the service packet are preset in the packet middleware b, each first assembly policy corresponds to one service type identifier and version number, and is used for performing assembly processing on a set of transactions carrying the corresponding service type identifier and version number, so as to assemble a third service packet related to the service type. The assembled third service message includes: all information in the first service message of the set of transactions is parsed.

In addition, a plurality of second assembly strategies for assembling the service message are also preset in the message middleware b, each second assembly strategy corresponds to one service type identifier respectively and is used for assembling a group of transactions carrying the corresponding service type identifiers, so that a second service message related to the service type is assembled. The assembled second service message includes: and resolving the key information in the first service message of the group of transactions.

For ease of understanding, by way of example, referring to table 2, recorded in table 2 is a first assembly policy preset in the message middleware b. It should be noted that two sets of transactions carrying the same service type identifier but with different version numbers respectively correspond to different first assembly policies. Similarly, two sets of transactions carrying the same version number but different service type identifications also respectively correspond to different first assembly strategies.

Table 2 first assembly strategy preset in message middleware b

First assembly strategy	Service type identification	Version number
			First Assembly strategy X	SMTA (for publishing assets)	V1.0
First assembly strategy Y	SMTC (for backspacing assets)	V1.0

It should be noted that in an actual application scenario, the update time of the message middleware b may be later than that of the message middleware a, so that some message versions (for example, the first service message V2.0 version for rolling back an asset) supported by the message middleware a have no corresponding first assembly policy in the message middleware b.

For ease of understanding, referring to table 3, a second assembly policy preset in the message middleware b is recorded in table 3, for example. It should be noted that two sets of transactions carrying the same service type identifier but with different version numbers may also correspond to the same second assembly policy. And two groups of transactions carrying different service type identifications respectively correspond to different second assembly strategies. In other words, the second assembly policy is independent of the version number of the service packet.

TABLE 3 second Assembly strategy Preset in message middleware b

Second assembly strategy	Service type identification
		Second assembly strategy r	SMTA (for issuing assets)
Second assembly strategy s	SMTC (for backspacing assets)

When the message middleware b assembles a service message for a group of transactions (namely, a plurality of transactions carrying the same message identifier), the message middleware b firstly reads the service type identifier and the version number carried by the transaction from any transaction in the group of transactions, and then searches a first assembly strategy which simultaneously corresponds to the service type identifier and the version number from a plurality of preset first assembly strategies by taking the read service type identifier and the read version number as indexes.

If the message middleware b finds the corresponding first assembly strategy, the message middleware b can assemble a group of transactions carrying the service type identifier and the version number into a third service message. In this way, the message middleware b reads information for assembling the third service message from the set of transactions based on the found first assembly policy, thereby assembling the third service message.

In a specific implementation, a first assembly policy is actually a segment of computer program, and the message middleware b executes the segment of computer program, thereby implementing the first assembly policy.

Wherein the first assembly policy is at least used to make the following restrictions on the packet assembly operation:

1. a transaction demand defined for assembling the third service message;

2. message data required to be contained in a message header of the assembled third service message; and for each message data required to be contained in the message header, defining which field of which transaction the message data is specifically acquired from, and defining which field of the message header the message data is filled in;

3. the service data required to be contained in the message body of the assembled third service message; and for each service data required to be contained in the message body, defining which field of which transaction the service data is specifically acquired from, and defining which field of the message body the service data is filled in.

In the specific implementation, after the message middleware b finds the corresponding first assembly policy for a group of transactions, the message middleware b reads the transaction demand defined by the first assembly policy. Then, the message middleware b counts the transaction quantity contained in the group of transactions. Finally, the message middleware b compares the transaction quantity contained in the group of transactions with the transaction demand quantity, thereby judging whether the transaction quantity and the transaction demand quantity are equal.

If the two are equal, the message middleware b continues to obtain the message data and the service data for assembling the third service message from the group of transactions based on the definition of the point 2 and the point 3 of the first assembling strategy so as to assemble the third service message.

If the two are not equal, the message middleware b suspends the message assembly operation, counts the transaction quantity contained in the group of transactions again after a preset time length, and compares the transaction quantity with the transaction demand. It should be noted that, during the period of suspending the message assembly operation, the message middleware b still continuously synchronizes the blocks, reads the transaction from the synchronized blocks, and adds the transaction to a corresponding group of transactions according to the message identifier carried by the transaction with respect to the read transaction.

In the invention, a group of transactions are assembled into a third service message based on a first assembly strategy, wherein the third service message comprises: all information contained in the first service message corresponding to the set of transactions. Thus, the message middleware B can completely transfer the information sent by the client a1 through the first service message to the client B1 and the client B2.

In addition, if the message middleware b does not find the corresponding first assembly policy, it indicates that the message middleware b cannot assemble a set of transactions carrying the service type identifier and the version number into a third service message. Thus, the message middleware B cannot completely transfer the information sent by the client a1 through the first service message to the client B1 and the client B2. In response, in order to transfer the key information sent by the user terminal a1 to the user terminal B1 and the user terminal B2 as much as possible, the message middleware B may further use the read service type identifier as an index to search for a second assembly policy corresponding to the service type identifier from a plurality of preset second assembly policies.

It should be noted that, the message middleware b presets a second assembly policy corresponding to each service type identifier. No matter how high the version number carried by a group of transactions is, under the condition that the corresponding first assembly strategy cannot be found, the corresponding second assembly strategy can be found according to the service type identification carried by the group of transactions. And then reading the key information from the group of transactions based on the searched second assembly strategy, and assembling a second service message according to the read key information, so that the key information is transmitted to the user terminal B1 and the user terminal B2 as far as possible through the second service message.

In a specific implementation, a second assembly policy is actually a section of computer program, and the message middleware b executes the second assembly policy by running the section of computer program.

Wherein the second assembly policy is at least used for limiting the message assembly operation as follows:

1. a transaction demand defined for assembling the second service message;

2. key message data required to be contained in a message header of the assembled second service message; and for each key message data required to be contained in the message header, defining which field of which transaction the key message data is obtained from, and defining which field of the message header the key message data is filled in;

3. key service data required to be contained in the message body of the assembled second service message; and for each key service data required to be contained in the message body, defining which field of which transaction the key service data is specifically acquired from, and defining which field of the message body the key service data is filled into.

The key message data and the key service data are also the key information. It should be noted that the key information agreed by the different second assembly policies is not necessarily the same. For ease of understanding, the key information agreed upon by the message identifying the second assembly policy corresponding to the SMTA (for publishing assets) illustratively includes: asset issuer information, type of asset issued, number of assets issued. For another example, the key information agreed by the second assembly policy corresponding to the message identification SMTT (for asset transaction) includes: asset transfer party information, asset transaction amount.

To facilitate understanding of the above packet assembling process, following the above example, assuming that the service type identifier and the version number carried by some or all of the transactions in the group of transactions are "SMTC _ V2.0", the packet middleware b searches, using the service type identifier SMTC and the version number V2.0 as indexes, for a first assembling policy that corresponds to both the service type identifier SMTC and the version number V2.0 from the multiple first assembling policies shown in table 2. However, since table 2 does not include the first assembly policy corresponding to the service type identifier SMTC and the version number V2.0 at the same time, it indicates that the message middleware b cannot assemble a set of transactions carrying the service type identifier SMTC and the version number V2.0 into the third service message.

In response, the message middleware b further uses the read service type identifier SMTC as an index, and searches a second assembly policy corresponding to the service type identifier SMTC from the multiple second assembly policies shown in table 3. Through the searching operation, the message middleware b searches the corresponding second assembly strategy s.

After finding the second assembly strategy s, the message middleware b firstly reads the limited transaction demand from the second assembly strategy s. Then, the message middleware b counts the transaction quantity contained in the group of transactions. Finally, the message middleware b compares the transaction quantity contained in the group of transactions with the transaction demand quantity, thereby judging whether the transaction quantity and the transaction demand quantity are equal.

And under the condition that the two are equal, the message middleware b reads key information limited by the second assembly strategy s from the group of transactions based on the second assembly strategy s, and fills the message header and/or the message body according to the read key information, so as to assemble a second service message. Then, the message middleware B sends the assembled second service message to the clients communicatively connected to the message middleware B, that is, the client B1 and the client B2, so that the client B1 and the client B2 can receive the key information sent by the client a1 through the first service message.

In the foregoing, the present invention provides an information delivery method based on a service processing system through a preferred embodiment. It should be noted that, as for the steps executed by the message middleware a, the message middleware b may also execute. For example, the message middleware B may also receive a first service message sent by the client B1 or the client B2, and after the message middleware B finds a corresponding parsing policy according to the service type identifier and the version number carried in the first service message, the message middleware B will parse the first service message into a plurality of transactions based on the found parsing policy, and submit the parsed transactions to the blockchain network for execution.

Likewise, the message middleware b can also execute the steps executed by the message middleware b. For example, message middleware a may also synchronize blocks generated by the blockchain network and read transactions from the synchronized blocks. Then, an attempt is made to search for a corresponding first assembly strategy, and a plurality of transactions are assembled into a third service message based on the searched first assembly strategy. And under the condition that the corresponding first assembly strategy is not found, the corresponding second assembly strategy is found, and the plurality of transactions are assembled into a second service message based on the found second assembly strategy.

Hereinafter, the present invention provides other information transfer methods by other embodiments. It should be noted that the following embodiments may be referred to with the above embodiments. It should be further noted that the information delivery method proposed in the following embodiments is not necessarily dependent on the service processing system shown in fig. 1 during implementation.

Referring to fig. 2, fig. 2 is a flowchart of an information delivery method according to an embodiment of the present invention, where the information delivery method is applied to a message middleware. As shown in fig. 2, the information delivery method includes the steps of:

step S21: and acquiring transactions from the blockchain network, wherein each transaction carries a message identifier, and a plurality of transactions analyzed from the same first service message carry the same message identifier.

Optionally, in some embodiments, as described above, in order for the message middleware to obtain transactions from the blockchain network, the message middleware may synchronize blocks generated by the blockchain network, where the blocks have records of transactions that have been performed by the blockchain network, and read the transactions from the synchronized blocks.

In particular implementations, for example, when a designated node within a blockchain network generates a new chunk, and the chunk has passed the consensus, the designated node may push the chunk to the message middleware so that the message middleware synchronizes to the chunk. And after the message middleware receives the block, reading the transaction recorded by the block.

Alternatively, in other embodiments, as described above, in order to obtain a transaction from the blockchain network, the message middleware may also synchronize an account database of the blockchain network, where the account database records the transactions that have been executed by the blockchain network, and the message middleware reads the transaction from the synchronized account data.

Or optionally, in other specific embodiments, after obtaining the transaction, the designated node of the blockchain network may directly synchronize the transaction to the message middleware. Thus, the message middleware obtains the transaction.

It should be noted that the invention is not limited to how the message middleware obtains the transaction from the blockchain network. But preferably, the message middleware obtains transactions from the blockchain network in a way of synchronizing the blocks or synchronizing the ledger database. Since the data (including transaction) in the blockchain and ledger databases are usually identified data, the information transferred by the message middleware is identified through the blockchain network, thereby further ensuring the reliability of the information.

Step S22: and aiming at a plurality of transactions carrying the same message identification, reading the service type identification and the version number carried by the transaction from any one of the transactions, wherein the service type identification and the version number carried by the transaction are from being analyzed into a first service message of the transaction.

In the invention, the business type identifier and the version number carried by the transaction are from the first business message analyzed to the transaction, so the business type identifier and the version number carried by the transaction reflect the business type used for processing the first business message and the message version of the first business message.

It should be noted that the present invention focuses on assembling a service packet according to several transactions, rather than how to parse the first service packet into several transactions. For how to parse a first service packet into several transactions, reference may be made to the foregoing preferred embodiment, and other parsing manners may also be adopted, which is not limited by the present invention.

Step S23: and inquiring a first assembly strategy which simultaneously corresponds to the service type identifier and the version number from a plurality of first assembly strategies according to the read service type identifier and the read version number.

As described above, in the present invention, a plurality of first assembly policies are preset in the message middleware, each first assembly policy corresponds to one service type identifier and one version number, and the first assembly policies are used to perform assembly operations on a group of transactions simultaneously carrying the service type identifier and the version number, so as to assemble a third service message. Wherein the set of transactions is: a group of transactions carrying the same message identifier, i.e. a plurality of transactions parsed from the same first service message. The assembled third service message includes: all information in the first service message of the set of transactions is parsed.

In the invention, if the message middleware can assemble a plurality of transactions carrying the same message identifier into a third service message based on the first assembly strategy, and then send the third service message to the information demand party (such as a user side), the information of the first service message can be completely transmitted to the information demand party.

Step S24: and under the condition that the first assembly strategy corresponding to the service type identifier and the version number at the same time is not inquired, inquiring a second assembly strategy corresponding to the service type identifier from a plurality of second assembly strategies.

In the invention, if the first assembly strategy corresponding to the service type identification and the version number at the same time is not inquired according to the read service type identification and the read version number, the message middleware possibly is not updated in time, and the message middleware does not support the service type of the version temporarily. For convenience of understanding, it is exemplarily assumed that the message middleware does not query the first assembly policy corresponding to the service type identifier SMTC (for asset fallback) and the version number V2.0 according to the read service type identifier SMTC (for asset fallback) and the read version number V2.0, and it is explained that the message middleware does not support the asset fallback service of the V2.0 version temporarily.

However, in order to transmit information to the information requiring party as much as possible, in the present invention, as described above, a plurality of second assembly policies are also preset in the message middleware, each second assembly policy corresponds to one service type identifier, and the second assembly policy is used to perform assembly operation on a group of transactions carrying the service type identifier, so as to assemble a second service message. Wherein the set of transactions is: and a group of transactions carrying the same message identifier, namely a plurality of transactions parsed by the same first service message. The assembled second service message includes: and resolving key information in the first service message of the group of transactions.

In the invention, if the message middleware can not assemble the third service message based on the first assembly strategy, the message middleware can also assemble the second service message based on the second assembly strategy, thereby transmitting the key information of the first service message to the information demand party.

Step S25: based on the inquired second assembly strategy, reading key information agreed by the second assembly strategy from the plurality of transactions, and assembling a second service message according to the read key information; and the key information in the transactions is part of information in the first service messages analyzed into the transactions.

In specific implementation, as described above, the second assembly policy agrees with key information for assembling the second service packet. And when the message middleware assembles a second service message based on a second assembly strategy, reading key information agreed by the second assembly strategy from a plurality of transactions, and filling the read key information into a preset field section of the second service message, thereby assembling the second service message.

Step S26: and sending the assembled second service message to an information demand side.

Optionally, in some embodiments, the information demander may be a user side.

Or optionally, in other specific embodiments, the information demander may also be a message conversion system, and after receiving the second service message, the message conversion system converts the second service message into a message under another protocol standard, for example, a swift message. And the message conversion system converts the second service message into a swift message and then sends the converted swift message to the user side.

It should be noted that the present invention does not limit the type of the information demander.

By executing the above steps S21 to S26, each transaction carries a message identifier, and multiple transactions parsed from the same first service message carry the same message identifier. Therefore, a plurality of transactions carrying the same message identifier correspond to the same first service message, and further correspond to services to be processed by the first service message. Therefore, the service information can be reflected according to the messages assembled by a plurality of transactions carrying the same message identification. And then the assembled message is sent to the information demand party, so that the information demand party can obtain the service information simply, conveniently and quickly by analyzing the message. Therefore, the method and the device can improve the convenience of information transfer and improve the user experience.

In addition, considering that the versions of the first service packet may be updated successively, the first service packets of multiple versions may be in a coexisting state. However, since some message middleware may not be updated in time, the un-updated message middleware cannot assemble a new version of the service message. Therefore, when the message middleware cannot inquire the first assembly strategy corresponding to the service type identifier and the version number at the same time from the plurality of first assembly strategies, inquiring the second assembly strategy corresponding to the service type identifier from the plurality of second assembly strategies, reading key information agreed by the second assembly strategy from a plurality of transactions based on the inquired second assembly strategy, and assembling the second service message according to the read key information. Thus, although the message middleware can not transmit the complete service information to the information demand side, the message middleware can transmit the key information to the information demand side, thereby meeting the user demand as much as possible.

Optionally, in some specific embodiments, the information delivery method further includes the following steps:

after the message middleware executes the step S23, if the first assembly policy corresponding to the service type identifier and the version number at the same time is queried, the message middleware reads information from the transactions based on the queried first assembly policy, and assembles a third service message according to the read information. And the message middleware sends the assembled third service message to the information demand party. Wherein the third service message includes: and analyzing all information in the first service messages of the plurality of transactions.

For how the message middleware specifically assembles the third service message based on the first assembly policy, reference may be made to the foregoing preferred embodiment, and in order to avoid repetition, this process is not described in detail in the present invention.

Optionally, in some specific embodiments, before the message middleware sends the assembled third service message to the information demander, the information delivery method may further include the following steps:

the message middleware obtains execution results corresponding to the transactions respectively; the message middleware determines a total service result according to the execution result corresponding to each of the plurality of transactions; and the message middleware fills the total service result into the third service message.

In a specific implementation, for example, in a block to which the message middleware synchronizes from the blockchain network, not only transactions that have been executed by the blockchain network are recorded, but also execution results corresponding to the transactions are recorded. Wherein the execution result is in the form of "yes" or "no". If the execution result corresponding to one transaction is yes, the transaction is successfully executed, and if the execution result corresponding to one transaction is no, the transaction is failed to execute. And after the message middleware reads the execution results corresponding to the transactions from the block, if the execution results of the transactions are all 'yes', the total business result is determined to be successful in execution. And if the execution results of the transactions are not all 'yes', determining that the total business result is execution failure. And after the message middleware determines the total service result, filling the total service result into a preset field section of the third service message.

Optionally, in some specific embodiments, for a plurality of first service packets carrying the same service type identifier but with different version numbers, the first service packets all include key information agreed by a second assembly policy corresponding to the service type identifier.

For ease of understanding, it is assumed by way of example that the key information agreed upon by the second assembly policy corresponding to the service type identifier SMTA (for publishing assets) includes: asset issuer information identity, type of asset issued, number of assets issued, amount. The version V1.0 of the first service packet for publishing assets carries at least: key information such as identity, type and amount. The first service message V2.0 version for publishing assets also carries at least: key information such as identity, type and amount. In addition, the first service message V2.0 version for issuing assets may also carry non-critical information such as "supervisor ID".

Optionally, in some specific embodiments, before the message middleware sends the assembled second service message to the information demander, the information delivery method may further include the following steps:

the message middleware obtains execution results corresponding to the transactions respectively; determining a total business result according to the execution results corresponding to the transactions respectively; and filling the total service result into the second service message.

In a specific implementation, for example, in a block to which the message middleware synchronizes from the blockchain network, not only transactions that have been executed by the blockchain network are recorded, but also execution results corresponding to the transactions are recorded. Wherein the execution result is like "yes" or "no". If the execution result corresponding to one transaction is 'yes', the transaction is successfully executed, and if the execution result corresponding to one transaction is 'no', the transaction is failed to be executed. And after the message middleware reads the execution results corresponding to the transactions from the block, if the execution results of the transactions are all 'yes', the total business result is determined to be successful in execution. And if the execution results of the transactions are not all "yes", determining that the total business result is execution failure. And after the message middleware determines the total service result, filling the total service result into a preset field section of the second service message.

Optionally, in some specific embodiments, the information delivery method may further include the following steps:

the message middleware receives a first service message and reads a service type identifier and a version number carried by the first service message from the first service message; the message middleware queries an analysis strategy which simultaneously corresponds to the service type identifier and the version number from a plurality of analysis strategies according to the service type identifier and the version number carried by the first service message; under the condition that the message middleware inquires the analysis strategy corresponding to the service type identifier and the version number at the same time, the first service message is analyzed into a plurality of transactions based on the inquired analysis strategy, wherein each transaction carries the message identifier of the first service message, and at least one transaction in the transactions carries the service type identifier and the version number of the first service message; and the message middleware submits the analyzed transactions to the blockchain network for execution.

For how the message middleware specifically analyzes the first service message into a plurality of transactions, reference may be made to the foregoing preferred embodiment, and in order to avoid repetition, this process is not described in detail in the present invention.

the message middleware acquires an update package, wherein the update package comprises an analysis strategy and a first assembly strategy which are applicable to a first service message of a new version; the message middleware executes updating operation according to the updating packet so as to store the analysis strategy and the first assembly strategy which are applicable to the first service message of the new version; the stored analysis strategy and the first assembly strategy correspond to the service type identifier and the version number of the first service message of the new version.

For convenience of understanding, the preset parsing policy in the message middleware b is shown in table 4 as an example:

table 4 parsing strategy preset in message middleware b

Resolution strategy	Service type identification	Version number
			Resolution strategy X	SMTA (for publishing assets))	V1.0
Resolution strategy Y	SMTC (for backspacing assets)	V1.0

The first assembly strategy preset in the message middleware b is shown in table 5:

TABLE 5 first Assembly strategy Preset in message middleware b

If the analysis strategy and the first assembly strategy contained in the update package obtained by the message middleware b are applicable to the following first service message: the first service message V2.0 version for fallback assets. After the message middleware b performs the update operation, the tables 4 and 5 are updated, and the updated tables 4 and 5 are as follows:

preset analysis strategy in updated table 4 message middleware b

Resolution strategy	Service type identification	Version number
			Resolution strategy X	SMTA (for publishing assets)	V1.0
Resolution strategy Y	SMTC (for backspacing assets)	V1.0
			Resolution strategy Z	SMTC (for backspacing assets)	V2.0

First assembly strategy preset in updated table 5 message middleware b

First assembly strategy	Service type identification	Version number
			First Assembly strategy X	SMTA (for publishing assets)	V1.0
First assembly strategy Y	SMTC (for backspacing assets)	V1.0
			First assembly strategy Z	SMTC (for backspacing assets)	V2.0

Based on the same inventive concept, the embodiment of the invention also provides an information transmission device. Referring to fig. 3, fig. 3 is a schematic diagram of an information delivery apparatus according to an embodiment of the present invention, which is applied to a message middleware. As shown in fig. 3, the information delivery apparatus includes:

a transaction obtaining module 31, configured to obtain transactions from a blockchain network, where each transaction carries a message identifier, and multiple transactions parsed from a same first service message carry the same message identifier;

the information reading module 32 is configured to, for multiple transactions carrying the same message identifier, read a service type identifier and a version number carried in the transaction from any one of the multiple transactions, where the service type identifier and the version number carried in the transaction are derived from a first service message parsed into the transaction;

a first assembly policy query module 33, configured to query, according to the read service type identifier and version number, a first assembly policy that corresponds to both the service type identifier and the version number from multiple first assembly policies;

a second assembly policy query module 34, configured to query, from among multiple second assembly policies, a second assembly policy corresponding to the service type identifier when the first assembly policy corresponding to the service type identifier and the version number at the same time is not queried;

a second service packet assembling module 35, configured to read key information agreed by the second assembly policy from the multiple transactions based on the queried second assembly policy, and assemble a second service packet according to the read key information; the key information in the transactions is part of information in a first service message analyzed into the transactions;

and the message sending module 36 is configured to send the assembled second service message to the information demander.

Optionally, in some specific embodiments, the apparatus further includes a third service packet assembly module, where the third service packet assembly module is configured to: under the condition that a first assembly strategy corresponding to the service type identifier and the version number at the same time is inquired, reading information from the transactions based on the inquired first assembly strategy, and assembling a third service message according to the read information; wherein the third service message includes: analyzing all information in the first service messages of the plurality of transactions;

the message sending module is further configured to: and sending the assembled third service message to the information demand side.

Optionally, in some specific embodiments, a plurality of first service packets carrying the same service type identifier but with different version numbers all include key information agreed by a second assembly policy corresponding to the service type identifier.

Optionally, in some embodiments, the transaction obtaining module is specifically configured to: synchronizing the blocks generated by the blockchain network, wherein the blocks record the transactions executed by the blockchain network; the transaction is read from the synchronized block.

Optionally, in some embodiments, the apparatus further comprises:

the execution result obtaining module is used for obtaining the execution results corresponding to the transactions before the message sending module sends the assembled second service message to the information demand party;

the total business result determining module is used for determining a total business result according to the execution results corresponding to the plurality of transactions respectively;

and the total service result filling module is used for filling the total service result into the second service message.

Optionally, in some embodiments, the apparatus further comprises:

the first service message receiving module is used for receiving a first service message and reading a service type identifier and a version number carried by the first service message from the first service message;

the analysis strategy query module is used for querying analysis strategies corresponding to the service type identifications and the version numbers simultaneously from a plurality of analysis strategies according to the service type identifications and the version numbers carried by the first service message;

the first service message analysis module is used for analyzing the first service message into a plurality of transactions based on the inquired analysis strategy under the condition that the analysis strategy corresponding to the service type identifier and the version number at the same time is inquired, wherein each transaction carries the message identifier of the first service message, and at least one transaction in the transactions carries the service type identifier and the version number of the first service message;

and the transaction submitting module is used for submitting the analyzed transactions to the blockchain network for execution.

Optionally, in some embodiments, the apparatus further comprises:

the updating package obtaining module is used for obtaining an updating package, and the updating package comprises an analysis strategy and a first assembly strategy which are applicable to a first service message of a new version;

the updating module is used for executing updating operation according to the updating packet so as to store the analysis strategy and the first assembly strategy which are applicable to the first service message of the new version; and the stored analysis strategy and the first assembly strategy correspond to the service type identifier and the version number of the first service message of the new version.

For the device embodiment, since it is basically similar to the method embodiment, the description is simple, and for the relevant points, refer to the partial description of the method embodiment.

Based on the same inventive concept, an embodiment of the present invention further provides an electronic device, as shown in fig. 4, including a processor 401, a communication interface 402, a memory 403, and a communication bus 404, where the processor 401, the communication interface 402, and the memory 403 complete communication with each other through the communication bus 404.

The memory 403 is used for storing computer programs;

the processor 401 is configured to implement the following steps when executing the program stored in the memory 403:

inquiring a first assembly strategy which simultaneously corresponds to the service type identifier and the version number from a plurality of first assembly strategies according to the read service type identifier and the read version number;

and sending the assembled second service message to an information demand side.

Alternatively, the processor 401 is configured to implement the steps of the information delivery method provided by the above other method embodiments of the present invention when executing the program stored in the memory 403.

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.

The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the Integrated Circuit may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, or a discrete hardware component.

In yet another embodiment of the present invention, a computer-readable storage medium is further provided, which has instructions stored therein, and when the instructions are executed on a computer, the computer is caused to execute the information transfer method described in any one of the above embodiments.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims

1. An information transfer method, applied to a message middleware, the method comprising:

and sending the assembled second service message to an information demand side.

2. The method of claim 1, further comprising:

under the condition that a first assembly strategy corresponding to the service type identification and the version number at the same time is inquired, reading information from the transactions based on the inquired first assembly strategy, and assembling a third service message according to the read information; wherein the third service message includes: analyzing all information in the first service messages of the plurality of transactions;

and sending the assembled third service message to the information demand side.

3. The method according to claim 1, wherein the plurality of first service packets carrying the same service type identifier but having different version numbers each include key information agreed by the second assembly policy corresponding to the service type identifier.

4. The method of claim 1, wherein obtaining a transaction from a blockchain network comprises:

synchronizing the blocks generated by the blockchain network, wherein the blocks record the transactions executed by the blockchain network;

the transaction is read from the synchronized block.

5. The method of claim 4, wherein before sending the assembled second service packet to the information requiring party, the method further comprises:

obtaining execution results corresponding to the transactions respectively;

determining a total business result according to the execution result corresponding to each of the plurality of transactions;

and filling the total service result into the second service message.

6. The method of any of claims 1 to 5, further comprising:

receiving a first service message, and reading a service type identifier and a version number carried by the first service message from the first service message;

inquiring analysis strategies corresponding to the service type identification and the version number simultaneously from a plurality of analysis strategies according to the service type identification and the version number carried by the first service message;

under the condition that an analysis strategy corresponding to the service type identifier and the version number at the same time is inquired, analyzing the first service message into a plurality of transactions based on the inquired analysis strategy, wherein each transaction carries the message identifier of the first service message, and at least one transaction in the plurality of transactions carries the service type identifier and the version number of the first service message;

and submitting the analyzed transactions to the blockchain network for execution.

7. The method of claim 6, further comprising:

obtaining an updating package, wherein the updating package comprises an analysis strategy and a first assembly strategy which are applicable to a first service message of a new version;

executing an updating operation according to the updating package so as to store the analysis strategy and the first assembly strategy which are applicable to the first service message of the new version; the stored analysis strategy and the first assembly strategy correspond to the service type identifier and the version number of the first service message of the new version.

8. An information transfer apparatus, applied to message middleware, the apparatus comprising:

the information reading module is used for reading the business type identifier and the version number carried by the transaction from any one transaction in the transactions aiming at a plurality of transactions carrying the same message identifier, wherein the business type identifier and the version number carried by the transaction are from a first business message analyzed into the transaction;

9. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;

the memory is used for storing a computer program;

the processor, when executing a program stored in the memory, is adapted to perform the method steps of any of claims 1-7.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any one of claims 1 to 7.