Interface docking interaction method, device and medium across systems

Abstract

The application relates to a cross-system interface docking interaction method and device and a medium, and belongs to the technical field of computers. The method comprises the following steps: in response to obtaining an interaction demand of interaction between a first business system and a second business system, associating a second smart contract of the second business system with a first smart contract to trigger the second smart contract to instruct the second business system to respond to the interaction demand to obtain response data, and feeding back the response data to the first smart contract through the second smart contract; and in the case that the response data is obtained through the first smart contract, feeding back the response data to the first business system through the first smart contract. The method can solve the problem that an interface cannot be self-adaptively changed when a cross-system interface docking interaction is realized in a point-to-point interface parameter passing mode. Since all interfaces are contracted, the interaction circulation of different business systems is realized through automatic matching of the smart contract, and the publicization and self-adaptation of different business system interfaces can be realized.

Description

[Technical Field]

[0001] This application relates to a cross-system interface docking and interaction method, device and medium, belonging to the field of computer technology. [Background Technology]

[0002] A business system refers to a software program consisting of multiple business processes that provide at least one service. Examples include government e-government systems and enterprise office workflow systems. Since the services provided by a single business system are limited, cross-system interaction between different business systems is often necessary. This requires interface connections between different business systems.

[0003] Currently, common methods for cross-system interface integration and interaction mainly include interface-to-interface integration, providing integration services through an interface gateway to forward integration requests, or using a unified open platform interface.

[0004] However, in traditional interface-based cross-system interaction, business systems can only provide fixed methods, parameters, and interfaces based on the explicit requirements of the client. They cannot adaptively expand interfaces to meet the needs of multiple business systems, nor can they achieve data feedback and extended applications based on updates to their own business systems. Furthermore, if multi-scenario matching of interfaces is required, it often necessitates finding the business system vendor to customize the interfaces. However, due to the vendor's internal development, relevant personnel and technology are subject to significant changes, resulting in low efficiency and high difficulty in interface customization. [Summary of the Invention]

[0005] This application provides a cross-system interface interface interaction method, device, and storage medium, which can contractualize all interfaces and achieve interactive flow between different business systems through automatic matching of smart contracts, realizing the commonality and adaptability of interfaces between different business systems. This application provides the following technical solution:

[0006] Firstly, a cross-system interface interface interaction method is provided, which runs on a first device containing a first business system. The first device connects to a blockchain network and publishes a first smart contract corresponding to the first business system in the blockchain network. The first smart contract is used to execute the interaction specifications between the first business system and the second business system of a second device. The method includes:

[0007] In response to the received interaction request between the first business system and the second business system, the second smart contract of the second business system is associated with the first smart contract to trigger the second smart contract to instruct the second business system to respond to the interaction request and obtain response data. The response data is then fed back to the first smart contract through the second smart contract. The response data is used to indicate that the second business system and the first business system have successfully connected.

[0008] If the response data is obtained through the first smart contract, the response data is fed back to the first business system through the first smart contract.

[0009] Optionally, the method further includes:

[0010] The first smart contract is used to parse the type of the interaction requirement;

[0011] When the demand type includes a business flow, the following steps are triggered: associating the second smart contract with the first smart contract; and feeding back the response data to the first business system through the first smart contract; the business flow is used to request the docking of the target application scenario with the second business system.

[0012] When the demand type includes an interaction flow, the following steps are triggered: first, the first smart contract is associated with the second smart contract; second, the first smart contract feeds back the response data to the first business system; and after the response data is fed back to the first business system via the first smart contract, the first business system stores the demand data corresponding to the interaction demand in the blockchain network; third, the first smart contract is associated with the second business system to trigger the second smart contract to instruct the second business system to read the demand data on the blockchain network, generate received signal data based on the demand data, and store the received signal data in the blockchain network; and fourth, when the first smart contract is associated with the second smart contract, the first smart contract triggers the first business system to read the received signal data from the blockchain network. The interaction flow includes a signaling flow and / or a data flow, wherein the signaling flow is used to request signaling interaction with the second business system, and the data flow is used to indicate the data required during the signaling interaction.

[0013] Optionally, the first smart contract and the second smart contract are stored in a smart contract pool, and the second smart contract associated with the second business system through the first smart contract includes:

[0014] The first smart contract obtains the contract address of the second smart contract corresponding to the system identifier based on the system identifier carried in the interaction request;

[0015] The first smart contract initiates a session request to the smart contract pool to trigger the smart contract pool to call a preset function, which in turn triggers the preset function to call the second smart contract based on the contract address in the session request; wherein, the session request carries the contract address, the request type of the interaction request, and the request content of the interaction request.

[0016] Optionally, the method further includes:

[0017] In the event that the first smart contract fails to associate with the second smart contract, the first business system is triggered to output the first alarm data through the first smart contract;

[0018] or,

[0019] If the interaction request type is an interaction flow, then if the first smart contract successfully associates with the second smart contract, but the received signal data corresponding to the interaction request is not obtained, an abnormal alarm request is generated through the first business system; the first smart contract responds to the abnormal alarm request and associates with the second smart contract to trigger the second smart contract to instruct the second business system to respond to the abnormal alarm request, obtain alarm response data, and feed the alarm response data back to the first smart contract through the second smart contract; the first smart contract feeds the alarm response data back to the first business system.

[0020] Secondly, a cross-system interface interface interaction method is provided, which runs on a second device containing a second business system. The second device connects to a blockchain network and publishes a second smart contract corresponding to the second business system in the blockchain network. The second smart contract is used to execute the interaction specifications between the second business system and the first business system in the first device. The method includes:

[0021] In response to the second smart contract obtaining the associated operation of the first smart contract of the first business system, the second smart contract triggers the second business system to respond to the interaction request indicated by the associated operation; the interaction request is generated by the first business system.

[0022] Obtain response data generated by the second business system in response to the interaction request; the response data is used to indicate that the second business system has successfully connected with the first business system.

[0023] The response data is fed back to the first smart contract through the second smart contract, thereby triggering the first smart contract to feed back the response data to the first business system.

[0024] Optionally, when the demand type includes an interaction flow, after triggering the second business system to respond to the interaction demand of the associated operation indication via the second smart contract, the method further includes:

[0025] The second smart contract triggers the second business system to read the demand data corresponding to the interaction demand from the blockchain network.

[0026] The second business system generates received signal data based on the demand data and stores the received signal data in the blockchain network.

[0027] The first smart contract is associated with the second smart contract, so that the first smart contract triggers the first business system to read the received signal data from the blockchain network.

[0028] Optionally, the step of responding to the second smart contract obtaining the associated operation of the first smart contract of the first business system, and triggering the second business system to respond to the interaction request indicated by the associated operation through the second smart contract, includes:

[0029] In response to the smart contract pool's call to the second smart contract, the second smart contract is used to obtain the request type and content of the interaction request sent by the smart contract pool. After receiving the session request initiated by the first smart contract, the smart contract pool calls a preset function to trigger the preset function to call the second smart contract based on the contract address in the session request. The session request carries the contract address, the request type, and the content of the interaction request.

[0030] The second smart contract triggers the second business system to respond to the interaction request.

[0031] Optionally, the method further includes:

[0032] If it fails to send the response data back to the first smart contract through the second smart contract, the second business system is triggered to output the second alarm data through the second smart contract.

[0033] or,

[0034] If the response data is successfully fed back to the first smart contract through the second smart contract, and an abnormal alarm request sent by the first smart contract is received through the second smart contract, then the second smart contract is triggered to instruct the second business system to respond to the abnormal alarm request; the alarm response data obtained by the second business system in responding to the abnormal alarm request is obtained; the alarm response data is fed back to the first smart contract through the second smart contract; thereby triggering the first smart contract to feed back the alarm response data to the first business system.

[0035] Thirdly, an electronic device is provided, the device including a processor and a memory; the memory stores a program, the program being loaded and executed by the processor to implement the cross-system interface docking and interaction method provided in the first aspect, or to implement the cross-system interface docking and interaction method provided in the second aspect.

[0036] Fourthly, a computer-readable storage medium is provided, wherein a program is stored in the storage medium, and the program, when executed by a processor, is used to implement the cross-system interface docking and interaction method provided in the first aspect, or to implement the cross-system interface docking and interaction method provided in the second aspect.

[0037] The beneficial effects of this application include at least the following: by responding to the interaction request between the first business system and the second business system, a second smart contract of the second business system is associated with a first smart contract to trigger the second smart contract to instruct the second business system to respond to the interaction request and obtain response data, and the response data is fed back to the first smart contract through the second smart contract; when the response data is obtained through the first smart contract, the response data is fed back to the first business system through the first smart contract; it can solve the problem that the interface cannot adapt to change when implementing cross-system interface docking interaction by point-to-point interface parameter passing; since all interfaces are contractualized, the interaction flow between different business systems can be realized through the automatic matching of smart contracts, and the publicization and adaptability of interfaces of different business systems can be achieved.

[0038] Meanwhile, since different smart contracts can be automatically matched and associated and can be modified adaptively, the interaction between different business systems is no longer limited to the traditional way of interaction between single business system interfaces or between single business system interfaces and multiple business system interfaces, and can realize the interface docking and interaction of multiple business systems.

[0039] In addition, by setting corresponding interaction methods for different types of interaction requests in smart contracts, it is possible to respond to various types of interaction requests and ensure the comprehensiveness of interface interaction.

[0040] In addition, by defining alarm interaction methods corresponding to various exceptions in smart contracts, it is possible to monitor and issue alarms for each stage of interface interaction, thereby improving the efficiency of exception handling.

[0041] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, the preferred embodiments of this application are described in detail below with reference to the accompanying drawings. [Attached Image Description]

[0042] Figure 1 This is a schematic diagram of a cross-system interface docking and interaction system provided in one embodiment of this application;

[0043] Figure 2 This is a schematic diagram illustrating the business system publishing smart contracts according to one embodiment of this application;

[0044] Figure 3 This is a flowchart of a cross-system interface docking and interaction method provided in one embodiment of this application;

[0045] Figure 4 This is a flowchart of a cross-system interface docking and interaction method provided in another embodiment of this application;

[0046] Figure 5 This is a schematic diagram of a service flow interaction provided in one embodiment of this application;

[0047] Figure 6 This is a schematic diagram of instruction flow interaction provided in one embodiment of this application;

[0048] Figure 7 This is a schematic diagram of data flow interaction provided in one embodiment of this application;

[0049] Figure 8 This is a schematic diagram of a first type of abnormal alarm interaction provided in an embodiment of this application;

[0050] Figure 9 This is a schematic diagram of a second type of abnormal alarm interaction provided in one embodiment of this application;

[0051] Figure 10 This is a schematic diagram illustrating the interaction of service flow, instruction flow, and data flow according to one embodiment of this application;

[0052] Figure 11 This is a block diagram of a cross-system interface interoperability device provided in one embodiment of this application;

[0053] Figure 12 This is a block diagram of a cross-system interface interoperability device provided in another embodiment of this application;

[0054] Figure 13 This is a block diagram of an electronic device provided in one embodiment of this application.

Detailed Implementation Methods

[0055] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings and examples. The following examples are used to illustrate this application, but are not intended to limit the scope of this application.

[0056] First, let me introduce some of the terms used in this application.

[0057] Distributed ledger technology (DLT), also known as a consensus network (e.g., composed of peer-to-peer nodes) or a blockchain network, enables participating entities to securely and immutably transact and store data. While the term blockchain is often associated with specific networks and / or use cases, in this document, blockchain generally refers to DLS without referring to any particular use case. A blockchain is a data structure that stores transactions in an immutable manner. Therefore, transactions recorded on a blockchain are reliable and trustworthy. A blockchain consists of one or more blocks. Each block in the chain is linked to the preceding block by a cryptographic hash of the block immediately preceding it in the chain; thus, a blockchain is a chain-like structure that combines data blocks in chronological order.

[0058] A smart contract is a computer protocol designed to transmit, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without the need for a third party; these transactions are traceable and irreversible.

[0059] Smart contracts typically have two attributes: value and state. The code uses If-Then and What-If statements to predefine the corresponding triggering scenarios and response rules for the contract terms. After being jointly agreed upon and signed by multiple parties, the smart contract is submitted along with a user-initiated transaction (Transaction, Txn). It is then propagated through a P2P network, verified by miners, and stored in a specific block on the blockchain. Users, after receiving the returned contract address and interface information, can invoke the contract by initiating a transaction. The smart contract code automatically determines whether the current scenario meets the contract triggering conditions based on trusted external data sources (also known as oracles) and world state checks, strictly executing response rules and updating the world state. Once the transaction is verified as valid, it is packaged into a new data block. This new block is then certified by the consensus algorithm and linked to the main blockchain, making all updates effective.

[0060] As smart contract data accumulates, storing it all in expensive storage media such as caches can become prohibitively costly. In some embodiments, smart contract data can be stored in a so-called smart contract pool on the blockchain.

[0061] In this embodiment, each node in the blockchain network is an electronic device running a business system. Specifically, Figure 1 This is a schematic diagram of the structure of a cross-system interface docking and interaction system provided in one embodiment of this application. The system includes at least: multiple electronic devices 100 and a network 200.

[0062] Electronic device 100 includes any suitable computing device capable of participating as a node in blockchain network 102. Exemplary examples include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smartphones.

[0063] In this embodiment, multiple electronic devices 100 are interconnected via a network 200 and serve as nodes in a distributed processing system. Each electronic device 100 carries one or more computer-implemented services for interacting with the blockchain network 102. For example, an electronic device 100 may carry a computer-implemented business system for a first entity (e.g., user A). Different electronic devices 100 carry different business systems. Figure 1 In the example, blockchain network 102 is represented as a peer-to-peer network of nodes, and electronic device 100 provides nodes from different business systems participating in blockchain network 102.

[0064] Each business system provides one or more application scenarios. Taking the drone application system as an example, the application scenarios included in the drone application system include, but are not limited to: patrol flight scenario, communication scenario and scheduling scenario. Other business systems can request to connect to a certain application scenario in the drone application system, or request to connect to the entire drone application system.

[0065] Multiple electronic devices 100 can access network 200 via wired and / or wireless communication links. Network 200 enables communication with and within the blockchain network. Typically, network 200 represents one or more communication networks. In some examples, network 200 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user equipment (e.g., computing devices), and backend systems. This embodiment does not limit the implementation of network 200.

[0066] In this embodiment, reference Figure 2After each electronic device 100 connects to the blockchain network 102, it generates a smart contract using predefined convention rules for multi-business system interaction management. This smart contract is then published to the blockchain network 102 and, after consensus authentication by various nodes on the blockchain network 102, is stored in a block on the blockchain network 102. Subsequently, the business systems in the electronic device 100 can connect with the business systems in other electronic devices by calling this smart contract.

[0067] The convention rules include: matching methods between different smart contracts, and rules for achieving business scenario interaction, instruction data interaction, data interaction, and alarm interaction. All entities connected to the blockchain network are bound by the convention rules and subject to unified and standardized management. This can meet the interaction needs of multiple scenarios and multiple businesses.

[0068] Specifically, taking electronic device 100, which includes a first device 110 and a second device 120, as an example, the first device 110 runs a first business system, and the second device 120 runs a second business system. Both the first device 110 and the second device 120 are connected to the blockchain network as nodes. The first device publishes a first smart contract corresponding to the first business system, and the second device publishes a second smart contract corresponding to the second business system. The first and second smart contracts are used to execute the interaction specifications between the first and second business systems. The first device is the initiator of the interaction request, and the second device is the receiver of the interaction request. Accordingly, the first smart contract executes the interaction specifications of the initiator, and the second smart contract executes the interaction specifications of the receiver. In this embodiment, the first device and the second device are different electronic devices. In actual implementation, the same electronic device can act as both the initiator and receiver of the interaction request. In this case, the smart contract corresponding to the electronic device includes both the interaction specifications of the initiator and the receiver.

[0069] The first device 110 is used to: respond to an interaction request received between the first business system and the second business system, associate a second smart contract of the second business system with a first smart contract, trigger the second smart contract to instruct the second business system to respond to the interaction request and obtain response data, and then feed the response data back to the first smart contract through the second smart contract. The response data is used to indicate that the second business system and the first business system have successfully connected.

[0070] Accordingly, the second device 120 is used to: respond to the second smart contract obtaining the associated operation of the first smart contract of the first business system, trigger the second business system to respond to the interaction request of the associated operation instruction through the second smart contract; obtain the response data generated by the second business system in response to the interaction request; and feed the response data back to the first smart contract through the second smart contract to trigger the first smart contract to feed the response data back to the first business system.

[0071] The first device 110 is also used to: when response data is obtained through the first smart contract, to feed the response data back to the first business system through the first smart contract.

[0072] In this embodiment, by using blockchain and smart contracts, the business interactions, command interactions, data interactions, and alarm interactions of multiple business systems can be made on-chain and contractualized. Instead of using traditional interface-to-interface communication and relying on point-to-point interface parameter passing to achieve cross-system interface docking and interaction, all interfaces are contractualized, and the interaction flow of different business systems is realized through smart contracts, which can realize the publicization and adaptability of interfaces of different business systems.

[0073] Figure 3 This is a flowchart of a cross-system interface interoperability method provided in one embodiment of this application. In this embodiment, the method is used for... Figure 1 The system shown is used as an example for illustration, and includes at least the following steps:

[0074] Step 301: In response to receiving the interaction request between the first business system and the second business system, the first device associates the second smart contract of the second business system with the first smart contract.

[0075] The associated operation of the first smart contract is used to trigger the second smart contract to instruct the second business system to respond to the interaction request, obtain response data, and then feed the response data back to the first smart contract through the second smart contract.

[0076] In one example, the first smart contract and the second smart contract are stored in a smart contract pool. The first smart contract is associated with the second smart contract of the second business system, which includes: obtaining the contract address of the second smart contract corresponding to the system identifier based on the system identifier carried in the interaction requirements through the first smart contract; and initiating a session request to the smart contract pool through the first smart contract to trigger the smart contract pool to call a preset function, which in turn triggers the preset function to call the second smart contract based on the session request.

[0077] The session request carries the contract address, the type of interaction request, and the content of the interaction request.

[0078] The contract address is the storage address of the second smart contract in the blockchain.

[0079] The requirement type indicates the interaction method for that interaction requirement. Different requirement types correspond to different interaction methods. For example, if the requirement type is only for connecting to a specific business scenario in a second business system, then only a communication loop needs to be built through the association of smart contracts. Another example is if the requirement type, in addition to connecting to a specific business scenario in a second business system, also requires data reading and writing. In this case, not only is a communication loop built through the association of smart contracts required, but interaction with blocks in the blockchain network is also necessary for data reading and writing. See the description below for the interaction methods corresponding to each requirement type.

[0080] The content of the requirement is the value carried by the interaction requirement.

[0081] The preset function is the method function for the smart contract pool to call the second smart contract. When calling the second smart contract through the preset function, the smart contract pool can also send the request type and request content in the session request to the second smart contract, so that the second smart contract can respond to the request content according to the interaction method indicated by the request type.

[0082] Optionally, a smart contract pool can be implemented as a specified smart contract. When associating different smart contracts, a session request needs to be initiated to the specified smart contract to achieve the association between the different smart contracts.

[0083] The first device, acting as the initiator of the interaction request, pre-searches for the contract address of the second smart contract in the second business system indicated by the interaction request, and uses this contract address as an interface parameter to generate a first smart contract. After the interaction request is initiated, the first smart contract, upon receiving the interaction request with a system identifier, automatically obtains the contract address corresponding to that system identifier, generates a session request, and triggers the smart contract pool to search for the second smart contract according to the contract address, thereby establishing communication between the first and second smart contracts.

[0084] The system identifier can be the identifier of the second business system, or it can be the identifier of the target application scenario in the second business system. This embodiment does not limit the implementation method of the system identifier.

[0085] Optionally, after the first smart contract is generated, if the first business system needs to connect to other business systems newly connected to the blockchain network, the first device can obtain the interface parameters by finding the contract address of the newly connected smart contract corresponding to the other business system, and use the interface parameters to regenerate the first smart contract.

[0086] Step 302: In response to the second smart contract obtaining the associated operation of the first smart contract of the first business system, the second device triggers the second business system to respond to the interaction request of the associated operation instruction through the second smart contract.

[0087] The interaction requirements are generated by the first business system.

[0088] In one example, in response to a call from the smart contract pool to the second smart contract, the second device obtains the request type and content of the interaction request sent by the smart contract pool through the second smart contract; and triggers the second business system to respond to the interaction request through the second smart contract.

[0089] After receiving a session request initiated by the first smart contract, the smart contract pool calls a preset function to trigger the preset function to call the second smart contract based on the session request.

[0090] Step 303: The second device acquires the response data generated by the second business system in response to the interaction request.

[0091] The response data indicates that the second business system has successfully integrated with the first business system. Specifically, after the second business system receives the request type and content based on the triggering of the second smart contract, it generates the response data.

[0092] Step 304: The second device sends response data back to the first smart contract through the second smart contract, thereby triggering the first smart contract to send response data back to the first business system.

[0093] Step 305: After obtaining the response data through the first smart contract, the first device feeds the response data back to the first business system through the first smart contract.

[0094] Optionally, the first smart contract also defines the interaction methods corresponding to different types of interaction requirements. In this case, the first device will also parse the requirement type of the interaction requirement through the first smart contract; if the requirement type includes business flow, steps 301 to 305 are executed to build a communication closed loop, realize the connection between the first business system and the second business system, and the process ends.

[0095] When the requirement type includes interactive flow, refer to Figure 4 After performing steps 301 to 305 to establish a communication loop, the following steps are also included:

[0096] Step 401: The first device stores the requirement data corresponding to the interaction requirement into the blockchain network through the first business system;

[0097] Step 402: The first device associates the second smart contract of the second business system with the first smart contract to trigger the second smart contract to instruct the second business system to read the demand data on the blockchain network, generate the received signal data based on the demand data, and store the received signal data in the blockchain network.

[0098] Step 403: The second device triggers the second business system to read the demand data corresponding to the interaction demand from the blockchain network through the second smart contract;

[0099] Step 404: The second device generates received signal data based on demand data through the second business system and stores the received signal data in the blockchain network;

[0100] Step 405: The second device associates with the first smart contract through the second smart contract, so that the first smart contract triggers the first business system to read the received signal data from the blockchain network;

[0101] The received signal data is used to indicate that the second business system has successfully received the requested data.

[0102] Step 406: When the first smart contract is associated with the second smart contract, the first business system is triggered by the first smart contract to read and receive signal data from the blockchain network.

[0103] As shown in steps 401-406, when the demand type is an interactive flow, the second smart contract also needs to trigger the second business system to read the demand data from the blockchain based on the interactive flow, and the first smart contract also needs to trigger the first business system to read the received signal data from the blockchain based on the interactive flow. That is, when the demand type is an interactive flow, cross-system data transmission is required to achieve a closed loop in data transmission.

[0104] In addition, the way smart contracts are associated (or matched) in steps 402 and 405 is described in steps 301 and 302, and will not be repeated here in this embodiment.

[0105] Optionally, the business flow is used to request and connect with the target application scenario of the second business system. That is, the interaction requirements of the business flow are used to match the user's scenario requirements.

[0106] The interaction flow includes a signaling flow and / or a data flow. The signaling flow is used to request signaling interaction with the second service system, and the data flow is used to indicate the data required during the signaling interaction. The interaction requirements of the signaling flow are used to match the signaling requests of different service system interactions. The interaction requirements of the data flow are used to match the data to be exchanged for the instruction flow interaction.

[0107] The methods by which a first smart contract parses interaction requests include, but are not limited to:

[0108] The first method: When there are type identifiers for requirement types in the business flow, signaling flow, and data flow, the requirement type is determined based on the type identifier carried in the interaction requirement. For example: 1 represents business flow, 2 represents signaling flow, and 3 represents data flow.

[0109] The second approach is to determine the requirement type based on the data format of the interaction requirements when the data formats of the business flow, signaling flow, and data flow are different.

[0110] In actual implementation, the first smart contract can also parse the request type of the interaction request in other ways, which will not be listed in this embodiment.

[0111] Taking the business flow requirement type as an example, refer to Figure 5 As shown, after business system 1 initiates an interaction request, it uses smart contract 1 to match and associate with smart contract 2. Smart contract 2 then triggers business system 2 to respond to the interaction request and sends the response data back to business system 1 via smart contract 2's smart contract matching and association with smart contract 1. At this point, business system 1 is the first business system, and business system 2 is the second business system.

[0112] Taking the instruction flow as an example of the requirement type of interactive flow, refer to Figure 6 As shown, business system 1 and business system 2 are based on Figure 5 After successful connection confirmation as shown, Business System 1 stores the instruction request data from the interaction requirements on the blockchain network and associates it with Smart Contract 2. Smart Contract 2 then triggers Business System 2 to read the instruction request data from the blockchain network via addressing. Next, Business System 2 uses the instruction request data to generate received signal data (i.e., received signal data) and stores this received signal data on the blockchain network. Smart Contract 2 is then associated with Smart Contract 1, so that Smart Contract 1 triggers Business System 1 to read the received signal data from the blockchain network via addressing. The storage address of the data on the blockchain network can be transmitted during the smart contract association process. At this point, Business System 1 is the first business system, and Business System 2 is the second business system.

[0113] Among them, the received signal data is used to indicate that the business system 2 has successfully received the request instruction.

[0114] Taking the data flow as an example of the requirement type of interactive flow, refer to Figure 7 As shown, business system 1 and business system 2 are based on Figure 5 The connection was confirmed to be successful as shown, and according to the instructions... Figure 6After receiving the instruction request data, Business System 2 processes the received instruction request, aggregates the business data required by Business System 1, and stores the required response processing data on the blockchain. Smart Contract 2 triggers Associated Smart Contract 1, which in turn triggers Business System 1 to retrieve the response processing data via addressing on the blockchain network. Based on the received response processing data, Business System 1 generates received signal data and feeds it back to the blockchain. Smart Contract 1 is then linked to Smart Contract 2, which triggers Business System 2 to retrieve the received signal data via addressing on the blockchain network, forming a closed-loop data interaction management system. Business System 2 is the first business system, and Business System 1 is the second business system.

[0115] In summary, the cross-system interface docking and interaction method provided in this embodiment, in response to the interaction request between the first business system and the second business system, associates the second smart contract of the second business system with the first smart contract, triggering the second smart contract to instruct the second business system to respond to the interaction request and obtain response data, and then feeds the response data back to the first smart contract through the second smart contract; when the response data is obtained through the first smart contract, it is fed back to the first business system through the first smart contract; this can solve the problem that the interface cannot adapt to change when implementing cross-system interface docking and interaction through point-to-point interface parameter passing; since all interfaces are contractualized, the interaction flow between different business systems can be realized through the automatic matching of smart contracts, and the commonality and adaptability of interfaces of different business systems can be achieved.

[0116] Meanwhile, since different smart contracts can be automatically matched and associated and can be modified adaptively, the interaction between different business systems is no longer limited to the traditional way of interaction between single business system interfaces or between single business system interfaces and multiple business system interfaces, and can realize the interface docking and interaction of multiple business systems.

[0117] In addition, by setting corresponding interaction methods for different types of interaction requests in smart contracts, it is possible to respond to various types of interaction requests and ensure the comprehensiveness of interface interaction.

[0118] Optionally, since the first and second business systems may experience interaction failures, the first and second smart contracts also specify alarm methods for handling interaction anomalies. Interaction anomalies may occur at various stages of cross-system interaction execution. To ensure effective and accurate system interaction, this embodiment categorizes interaction anomalies into two types for handling. The first type is anomalies where the channel is not successfully established through the smart contract; the second type is anomalies where the channel is successfully established through the smart contract.

[0119] The following sections will introduce the handling methods for the two types of anomalies mentioned above.

[0120] In the first category, after step 301, if the first device fails to associate with the second smart contract through the first smart contract, it triggers the first business system to output first alarm data through the first smart contract. And / or, if it fails to send response data back to the first smart contract through the second smart contract, the second device also triggers the second business system to output second alarm data through the second smart contract.

[0121] For example: Reference Figure 8 If, during the process of business system 1 initiating a request, a call to smart contract 1 fails, or a connection between smart contract 1 and smart contract 2 fails, smart contract 1 automatically triggers business system 1 to output the first alarm data. And / or, if, during the process of business system 2 providing response data feedback, a call to smart contract 2 fails, or a connection between smart contract 2 and smart contract 1 fails, smart contract 2 automatically triggers business system 2 to output the first alarm data.

[0122] In the second category, after step 305, if the first device successfully associates with the second smart contract through the first smart contract but fails to obtain the received signal data corresponding to the interaction request, it generates an abnormal alarm request through the first business system; it associates with the second smart contract through the first smart contract in response to the abnormal alarm request, thereby triggering the second smart contract to instruct the second business system to respond to the abnormal alarm request, obtain alarm response data, and feed the alarm response data back to the first smart contract through the second smart contract; and feeds the alarm response data back to the first business system through the first smart contract.

[0123] Accordingly, if the second device successfully sends the response data back to the first smart contract through the second smart contract, and receives an abnormal alarm request sent by the first smart contract through the second smart contract, it triggers the second smart contract to instruct the second business system to respond to the abnormal alarm request; obtains the alarm response data obtained by the second business system in responding to the abnormal alarm request; sends the alarm response data back to the first smart contract through the second smart contract; and triggers the first smart contract to send the alarm response data back to the first business system.

[0124] Among them, the alarm response data is used to indicate that the second business system has received an abnormal alarm request.

[0125] For example: Reference Figure 9 An exception occurs during the interaction of instruction streams or data streams between business system 1 and business system 2. Figure 6If business system 2 fails to obtain instruction request data, business system 2 can trigger smart contract 2 to associate with smart contract 1 by generating an abnormal alarm request. Smart contract 1 then triggers business system 1 to respond to the abnormal alarm request and obtain alarm response data. If... Figure 7 If business system 1 fails to obtain response processing data, business system 1 can trigger smart contract 1 to associate with smart contract 2 by generating an abnormal alarm request. Through smart contract 2, business system 2 can be triggered to respond to the abnormal alarm request and obtain alarm response data.

[0126] Optionally, after generating alarm response data, the second business system can also output alarm prompts to notify users to handle abnormal alarm requests. Accordingly, abnormal alarm requests can carry abnormal error codes, and these error codes can be output through alarm prompts so that users can handle abnormal alarm requests in a targeted manner based on the error codes, thereby improving the efficiency of abnormal handling.

[0127] In this embodiment, by defining alarm interaction methods corresponding to various anomalies in the smart contract, it is possible to monitor and issue alarms for anomalies at each stage of interface interaction, thereby improving the efficiency of anomaly handling.

[0128] To better understand the cross-system interface interaction method provided in this application, an example is given below. (Reference) Figure 10 Taking the interface interaction process between business system 1 and business system 2 as an example, this method specifically includes the following steps:

[0129] Step 1: Business System 1 initiates an interaction request to Business System 2;

[0130] There can be at least one interaction requirement, and at least one interaction requirement can include business flow, instruction flow and / or data flow.

[0131] Step 2: Decompose the interaction requirements through the smart contract 1 associated with business system 1 to obtain business flow, instruction flow and / or data flow;

[0132] Step 3: Smart Contract 1 initiates a session request to the smart contract pool by relying on the interaction specifications of various business systems specified in the convention mechanism and through function or method body interaction.

[0133] Step 4: The smart contract pool associates with smart contract 2 through agreed methods or function values, thus establishing a physical channel between smart contract 1 and smart contract 2.

[0134] Step 5, Smart Contract 2 aggregates business flows;

[0135] Step 6: Smart Contract 2 constructs a virtual channel to send response data back to Smart Contract 1, forming a communication loop.

[0136] In step 6, the virtual channel is still essentially implemented through the connection between smart contracts.

[0137] Step 7: Smart contract 1 sends the instruction stream to smart contract 2 through the established entity channel;

[0138] Step 8: Smart Contract 2 aggregates the instruction stream;

[0139] Step 9: Smart Contract 2 constructs a virtual channel to send response data back to Smart Contract 1, forming a communication loop;

[0140] Step 10: Business system 1 uploads the instruction request data of the instruction stream to the blockchain network. Smart contract 2 triggers business system 2 to read and process the instruction request data to obtain response processing data. Business system 2 generates the received signal data corresponding to the instruction request data and uploads the received signal data to the blockchain network. Smart contract 2, associated with smart contract 1, triggers business system 1 to read the received signal data from the blockchain network.

[0141] In step 10, the received signal data is transmitted through a virtual channel established by the blockchain. This virtual channel, along with the virtual channel in step 6, can avoid the problem of data interaction disorder caused by using the same channel to simultaneously feed back response data corresponding to the business flow and received signal data corresponding to the instruction flow.

[0142] Step 11: Business system 2 uploads the response and handling data to the blockchain network and stores the response and handling data on the blockchain network by addressing the data.

[0143] Step 12: Business system 2 triggers associated smart contract 2, digitizes the on-chain address and sends it to smart contract 1 through the physical channel;

[0144] Step 13: Smart contract 1 obtains an address on the blockchain network through a physical channel, triggering business system 1 to read the response and processing data stored in that address;

[0145] Step 14: Smart contract 1 constructs a virtual channel to send the received signal data corresponding to the response and processing data to smart contract 2, forming a communication closed loop;

[0146] In step 14, the virtual channel is still implemented by uploading and reading data through the blockchain. The virtual channel in step 14 and the virtual channel in step 6 can avoid the problem of data interaction disorder caused by using the same channel to simultaneously feed back the response data corresponding to the business flow and the received signal data corresponding to the response processing data.

[0147] Step 15: Smart contract 1 triggers business system 1 to feed back response and processing data to business system 1, completing the interface-level data interaction;

[0148] Figure 10 The black dots indicate alerts for abnormal behaviors during communication and interaction. The alert flow automatically initiates when an anomaly occurs during contract execution, and sends feedback on the anomaly to the requesting party for handling. The alert flow's handling mechanism primarily involves providing alerts and feedback on requests from the previous node.

[0149] Figure 11 This is a block diagram of a cross-system interface interface interaction device provided in one embodiment of this application. The device is used in a first device running a first business system. The first device connects to a blockchain network and publishes a first smart contract corresponding to the first business system in the blockchain network. The first smart contract is used to execute the interaction specifications for interaction between the first business system and a second business system. The device includes at least the following modules: a demand transmission module 1110 and a demand response module 1120.

[0150] The demand transmission module 1110 is used to respond to the acquisition of the interaction demand between the first business system and the second business system, and to associate the second smart contract of the second business system with the first smart contract to trigger the second smart contract to instruct the second business system to respond to the interaction demand and obtain response data, and to feed back the response data to the first smart contract through the second smart contract.

[0151] The demand response module 1120 is used to feed back the response data to the first business system through the first smart contract when the response data is obtained through the first smart contract.

[0152] For relevant details, please refer to the above method implementation examples.

[0153] Figure 12 This is a block diagram of a cross-system interface interaction device provided in another embodiment of this application. The device is used in a second device running a second business system. The second device connects to a blockchain network and publishes a second smart contract corresponding to the second business system in the blockchain network. The second smart contract is used to execute the interaction specifications between the second business system and the first business system. The device includes at least: a demand acquisition module 1210, a response acquisition module 1220, and a response transmission module 1230.

[0154] The requirement acquisition module 1210 is used to respond to the second smart contract acquiring the associated operation of the first smart contract of the first business system, and to trigger the second business system to respond to the interaction requirement indicated by the associated operation through the second smart contract; the interaction requirement is generated by the first business system;

[0155] Response acquisition module 1220 is used to acquire response data generated by the second business system in response to the interaction request;

[0156] The response transmission module 1230 is used to send the response data back to the first smart contract through the second smart contract, so as to trigger the first smart contract to send the response data back to the first business system.

[0157] For relevant details, please refer to the above method implementation examples.

[0158] It should be noted that the cross-system interface docking and interaction device provided in the above embodiments is only illustrated by the division of the above functional modules when performing cross-system interface docking and interaction. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the cross-system interface docking and interaction device can be divided into different functional modules to complete all or part of the functions described above. In addition, the cross-system interface docking and interaction device and the cross-system interface docking and interaction method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0159] Figure 13 This is a block diagram of an electronic device provided in one embodiment of this application. The device includes at least a processor 1301 and a memory 1302.

[0160] Processor 1301 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 1301 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1301 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1301 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1301 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0161] The memory 1302 may include one or more computer-readable storage media, which may be non-transitory. The memory 1302 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1302 is used to store at least one instruction, which is executed by the processor 1301 to implement the cross-system interface interoperability method or cross-system interface interoperability method provided in the method embodiments of this application.

[0162] In some embodiments, the electronic device may also optionally include a peripheral device interface and at least one peripheral device. The processor 1301, memory 1302, and peripheral device interface can be connected via a bus or signal lines. Each peripheral device can be connected to the peripheral device interface via a bus, signal lines, or a circuit board. Indicatively, peripheral devices include, but are not limited to, radio frequency circuits, touch displays, audio circuits, and power supplies.

[0163] Of course, electronic devices may also include fewer or more components, and this embodiment does not limit this.

[0164] Optionally, this application also provides a computer-readable storage medium storing a program that is loaded and executed by a processor to implement the cross-system interface docking interaction method or the cross-system interface docking interaction method of the above method embodiments.

[0165] Optionally, this application also provides a computer product including a computer-readable storage medium storing a program, the program being loaded and executed by a processor to implement the Weston-based cross-system interface interaction method or the cross-system interface interaction method of the above method embodiments.

[0166] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0167] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A cross-system interface interface interaction method, characterized in that, The method is used to run on a first device containing a first business system, wherein the first device connects to a blockchain network and publishes a first smart contract corresponding to the first business system in the blockchain network, and the first smart contract is used to execute the interaction specifications between the first business system and the second business system of the second device; the method includes: In response to the received interaction request between the first business system and the second business system, the second smart contract of the second business system is associated with the first smart contract to trigger the second smart contract to instruct the second business system to respond to the interaction request and obtain response data. The response data is then fed back to the first smart contract through the second smart contract. The response data is used to indicate that the second business system and the first business system have successfully connected. If the response data is obtained through the first smart contract, the response data is fed back to the first business system through the first smart contract. The method further includes: parsing the demand type of the interaction demand through the first smart contract; if the demand type includes an interaction flow, triggering the execution of the step of associating the second smart contract through the first smart contract; feeding back the response data to the first business system through the first smart contract; and after feeding back the response data to the first business system through the first smart contract, storing the demand data corresponding to the interaction demand in the blockchain network through the first business system; associating the second smart contract of the second business system through the first smart contract to trigger the second smart contract to instruct the second business system to read the demand data on the blockchain network, generate received signal data based on the demand data, and store the received signal data in the blockchain network; if the first smart contract is associated with the second smart contract, triggering the first business system to read the received signal data from the blockchain network through the first smart contract; the received signal data is used to indicate that the second business system has successfully received the demand data.

2. The method according to claim 1, characterized in that, The method further includes: When the demand type includes a business flow, the following steps are triggered: associating the second smart contract with the first smart contract; feeding back the response data to the first business system through the first smart contract; the business flow is used to request the docking of the target application scenario with the second business system; When the demand type includes an interaction flow, the interaction flow includes a signaling flow and / or a data flow, wherein the signaling flow is used to request signaling interaction with the second business system, and the data flow is used to indicate the data required during the signaling interaction process.

3. The method according to claim 1, characterized in that, The first smart contract and the second smart contract are stored in a smart contract pool. The second smart contract, which is associated with the second business system through the first smart contract, includes: The first smart contract obtains the contract address of the second smart contract corresponding to the system identifier based on the system identifier carried in the interaction request; The first smart contract initiates a session request to the smart contract pool to trigger the smart contract pool to call a preset function, which in turn triggers the preset function to call the second smart contract based on the contract address in the session request; wherein, the session request carries the contract address, the request type of the interaction request, and the request content of the interaction request.

4. The method according to claim 1, characterized in that, The method further includes: In the event that the first smart contract fails to associate with the second smart contract, the first business system is triggered to output the first alarm data through the first smart contract; or, If the interaction request type is an interaction flow, then if the first smart contract successfully associates with the second smart contract, but the received signal data corresponding to the interaction request is not obtained, an abnormal alarm request is generated through the first business system; the first smart contract responds to the abnormal alarm request and associates with the second smart contract to trigger the second smart contract to instruct the second business system to respond to the abnormal alarm request, obtain alarm response data, and feed the alarm response data back to the first smart contract through the second smart contract; the first smart contract feeds the alarm response data back to the first business system.

5. A cross-system interface interface interaction method, characterized in that, The method is used to run on a second device containing a second business system, the second device accessing a blockchain network and publishing a second smart contract corresponding to the second business system on the blockchain network. The second smart contract is used to execute the interaction specifications between the second business system and the first business system in the first device; the method includes: In response to the second smart contract obtaining the associated operation of the first smart contract of the first business system, the second smart contract triggers the second business system to respond to the interaction request indicated by the associated operation; the interaction request is generated by the first business system. Obtain response data generated by the second business system in response to the interaction request; the response data is used to indicate that the second business system has successfully connected with the first business system. The response data is fed back to the first smart contract through the second smart contract, thereby triggering the first smart contract to feed back the response data to the first business system; After triggering the second business system to respond to the interaction request of the associated operation instruction through the second smart contract, the method further includes: triggering the second business system to read the request data corresponding to the interaction request from the blockchain network through the second smart contract; generating received signal data based on the request data through the second business system and storing the received signal data in the blockchain network; associating the first smart contract with the second smart contract so that the first smart contract triggers the first business system to read the received signal data from the blockchain network, wherein the received signal data is used to indicate that the second business system has successfully received the request data.

6. The method according to claim 5, characterized in that, The step of responding to the second smart contract obtaining the associated operation of the first smart contract of the first business system, and triggering the second business system to respond to the interaction request indicated by the associated operation through the second smart contract, includes: In response to the smart contract pool's call to the second smart contract, the second smart contract is used to obtain the request type and content of the interaction request sent by the smart contract pool. After receiving the session request initiated by the first smart contract, the smart contract pool calls a preset function to trigger the preset function to call the second smart contract based on the contract address in the session request. The session request carries the contract address, the request type, and the content of the interaction request. The second smart contract triggers the second business system to respond to the interaction request.

7. The method according to claim 5, characterized in that, The method further includes: If it fails to send the response data back to the first smart contract through the second smart contract, the second business system is triggered to output the second alarm data through the second smart contract. or, If the response data is successfully fed back to the first smart contract through the second smart contract, and an abnormal alarm request sent by the first smart contract is received through the second smart contract, then the second smart contract is triggered to instruct the second business system to respond to the abnormal alarm request; the alarm response data obtained by the second business system in responding to the abnormal alarm request is obtained; the alarm response data is fed back to the first smart contract through the second smart contract; thereby triggering the first smart contract to feed back the alarm response data to the first business system.

8. An electronic device, characterized in that, The device includes a processor and a memory; the memory stores a program that is loaded and executed by the processor to implement the cross-system interface docking and interaction method as described in any one of claims 1 to 4; or, to implement the cross-system interface docking and interaction method as described in any one of claims 5 to 7.

9. A computer-readable storage medium, characterized in that, The storage medium stores a program that, when executed by a processor, is used to implement the cross-system interface docking and interaction method as described in any one of claims 1 to 4; or, to implement the cross-system interface docking and interaction method as described in any one of claims 5 to 7.

Images