CN111008222A - 数据状态查询方法和装置 - Google Patents

Abstract

本申请公开了数据状态查询方法和装置。该方法包括：接收业务系统发送的交易数据；将交易数据发送至网络节点；接收网络节点针对交易数据返回的交易结果，其中，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息；发送交易结果至业务系统，以供业务系统基于交易结果对交易数据执行相应的处理。根据本申请实施例的技术方案，为业务系统提供数据状态以便其基于数据状态对业务数据进行相应的处理，来解决由于网络或者原子操作等原因导致客户端的数据上链不成功的问题，并获得提升数据上链成功率的技术效果。

Description

数据状态查询方法和装置

技术领域

本申请一般涉及计算机计算领域，尤其涉及数据状态查询方法和装置。

背景技术

Hyperledger Project由Linux基金会创办于2015年10月，是一个开源的区块链研发孵化项目，致力于提供可协同开发以区块链为底层的分布式账本。旗下的Fabric项目目标为打造一个提供分布式账本解决方案的联盟链平台。

目前成员将交易数据上传至Fabric网络时，可能由于网络或原子操作等原因导致客户端上链的数据不成功，这种情况可能导致上链不成功的数据丢失。

因此，亟待提出一种新的机制来解决上述问题。

发明内容

鉴于现有技术中的上述缺陷或不足，期望提供一种基于Fabric网络的数据状态查询方法、装置来确保上链数据的成功，避免数据丢失的问题。

第一方面，本申请实施例提供了一种基于Fabric网络的数据状态查询方法，该方法包括：

接收业务系统发送的交易数据；

将交易数据发送至网络节点；

接收网络节点针对交易数据返回的交易结果，其中，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息；

发送交易结果至业务系统，以供业务系统基于交易结果对交易数据执行相应的处理。

第二方面，本申请实施例提供了一种基于Fabric网络的数据状态查询方法，该方法包括：

向客户端发送交易数据，以使得客户端将交易数据发送至网络节点；

从客户端接收交易结果，交易结果由网络节点针对交易数据返回，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息；

基于交易结果对交易数据执行相应的处理。

第三方面，本申请实施例提供了一种基于Fabric网络的数据状态查询装置，该装置包括：

第一接收单元，用于接收业务系统发送的交易数据；

第一发送单元，用于将交易数据发送至网络节点；

第二接收单元，用于接收网络节点针对交易数据返回的交易结果，其中，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息；

第二发送单元，用于发送交易结果至业务系统，以使得业务系统基于交易结果对交易数据执行相应的处理。

第四方面，本申请实施例提供了一种基于Fabric网络的数据状态查询装置，该装置包括：

第五发送单元，用于向客户端发送的交易数据，以使得客户端将交易数据发送至网络节点；

第五接收单元，用于从客户端接收交易结果，交易结果由网络节点针对交易数据返回，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息；

第一处理单元，用于基于交易结果对交易数据执行相应的处理。

本申请实施例提供的基于Fabric网络的数据状态查询的方法，通过在客户端与业务系统之间建立查询通道，为业务系统提供数据状态以便其基于数据状态对业务数据进行相应的处理，来解决由于网络或者原子操作等原因导致客户端的数据上链不成功的问题，并获得提升数据上链成功率的技术效果。

进一步地，通过业务系统主动发起查询未返回数据状态的数据查询，有效避免在Fabric网络中相同数据造成重复上链的问题，并有效减少传统方案中，一直循环查询上链数据结果，造成资源浪费的问题。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了本申请实施例提供的基于Fabric网络的数据状态查询方法的流程示意图；

图2示出了本申请又一实施例提供的基于Fabric网络的数据状态查询方法的流程示意图；

图3示出了本申请实施例提供的调用时序示意图；

图4示出了本申请实施例提供的基于Fabric网络的数据状态查询方法装置的结构示意图；

图5示出了本申请又一实施例提供的基于Fabric网络的数据状态查询方法装置的结构示意图；

图6示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

请参考图1，图1示出了本申请实施例提供的基于Fabric网络的数据状态查询方法的流程示意图。

如图1所示，该方法由客户端侧执行，其包括：

步骤110，接收业务系统发送的交易数据。

步骤120，将交易数据发送至网络节点。

本申请实施例中，通常业务系统(也可以称为外部系统)通过调用Fabric sdk程序实现业务系统与Fabric网络的交互。Fabric sdk作为客户端，接收到业务系统的交易请求后，将交易请求发送至网络节点(也称为peer节点)，网络节点中的背书节点对交易请求执行对应的智能合约，并对执行结果进行背书签名，然后将背书签名后的执行结果返回给客户端。客户端收到所有背书节点签名后的执行结果后，通过网络服务进行广播。

在完成上述之后，通过客户端回调网络节点来获取反馈交易数据的状态。

步骤130，接收网络节点针对交易数据返回的交易结果，其中，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息。

在客户端通过回调网络节点得到交易数据的交易结果。交易结果例如可以包括交易数据的交易标识(也可称为交易ID)和用于表示交易数据是否被成功地写入本地账本的指示信息。交易ID具有唯一性，能够唯一标识用户所进行的交易，并且无需用户名的重复检验。每个网络节点与客户端保持一个Eventhub的连接，在网络节点完成交易之后，发送消息通知客户端，该消息里可以包括指示信息来表示交易数据是否被成功地写入本地账本。

步骤140，发送交易结果至业务系统，以供业务系统基于交易结果对交易数据执行相应的处理。

本申请实施例中，考虑到将区块写入本地账本后，客户端可以从Fabric网络获知交易结果后，并将交易结果发送至业务系统，业务系统可以根据交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

即如果交易结果表示交易数据未被成功地写入本地账本，则客户端从业务系统接收重新发送的交易数据，并将重新发送的交易数据发送至网络节点。

本申请实施例，通过将交易数据的交易结果发送至业务系统，使得业务系统可以根据反馈结果处理交易数据，提高了数据写入账本的成功率。

在上述实施例基础上，进一步还包括：

接收业务系统发送的状态查询请求，状态查询请求用于请求查询第二交易数据的交易状态，其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合；

响应于状态查询请求执行对应的查询操作。

其中，响应于状态查询请求执行对应的查询操作，还可以包括：

调用与Fabric网络预先建立的通道来查找与状态查询请求对应的第二交易数据的第二交易结果；

将第二交易结果发送至业务系统，以使得业务系统基于第二交易结果对第二交易数据执行相应的处理。

本申请实施例中，进一步考虑在Peer节点完成交易后，虽然在将区块写入账本后会发送消息通知客户端，但是回调方式也不能排除信息丢失的可能性。在上述实施例基础上，还可以通过定时器，例如预设时间之后，触发业务系统向客户端发送状态查询请求。状态查询请求用于请求查询第二交易数据的交易状态。状态查询请求例如可以携带第二交易数据的交易标识，通过交易标识可以向Fabric网络查询与之对应的交易数据的交易状态。其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合。例如业务系统向客户端发送10条交易数据，其中6条的交易状态已知，还有4条交易数据的交易状态未知，业务系统可以将4条交易数据的交易ID整合在状态查询请求中，通过调用与Fabric网络预先建立的通道实现查找，从而获得这4条交易数据的交易状态。预设时间，例如可以是5分钟。

如图3示出调用时序图，查询5分钟之前，已发送但还未收到通知的上链数据，向Fabric sdk请求查询为收到通知的数据状态，sdk通过预先建立的通道向Fabric网络查询未收到通知的数据状态，返回未收到通知的数据状态，业务系统则根据返回的数据状态，对相应的数据进行删除或者重新提交上链失败的数据。

即如果第二交易结果表示第二交易数据未被成功地写入本地账本，则客户端从业务系统接收重新发送的第二交易数据；将重新发送的第二交易数据发送至网络节点。

本申请实施例通过业务系统主动查询交易数据的交易结果，克服仅通过回调获取交易数据的状态，可能导致数据丢失的问题，并进一步确保数据上链的成功率。

请参考图2，图2示出了本申请又一实施例提供的基于Fabric网络的数据状态查询方法的流程示意图。

如图2所示，该方法由业务系统执行，其包括：

步骤210，向客户端发送交易数据，以使得客户端将交易数据发送至网络节点。

本申请实施例中，通常业务系统通过调用Fabric sdk程序实现业务系统与Fabric网络的交互。Fabric sdk作为客户端，接收到业务系统的交易请求后，将交易请求发送至网络节点(也称为peer节点)，网络节点中的背书节点对交易请求执行对应的智能合约，并对执行结果进行背书签名，然后将背书签名后的执行结果返回给客户端。客户端收到所有背书节点签名后的执行结果后，通过网络服务进行广播。

在完成上述之后，通过客户端回调网络节点来获取反馈交易数据的状态。

步骤220，从客户端接收交易结果，交易结果由网络节点针对交易数据返回，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息。

步骤230，基于交易结果对交易数据执行相应的处理。

本申请实施例中，考虑到将区块写入本地账本后，客户端可以从Fabric网络获知交易结果后，并将交易结果发送至业务系统，业务系统可以根据交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

步骤230包括：

步骤2301，如果交易结果表示交易数据被成功地写入本地账本，则业务系统删除交易数据；

步骤2302，如果交易结果表示交易数据未被成功地写入本地账本，则业务系统向客户端重新发送交易数据。

在上述实施例基础上，该方法还包括：

等待预设时间后，统计预设时间内已发送但未收到交易结果的交易数据的集合，得到第二交易数据；

向客户端发送状态查询请求，状态查询请求用于请求查询第二交易数据的交易状态；

接收第二交易数据的第二交易结果，第二交易结果是由客户端调用Fabric网络预先建立的通道查找得到的；

基于第二交易结果对第二交易数据执行相应的处理。

本申请实施例中，进一步考虑在Peer节点完成交易后，虽然在将区块写入账本后会发送消息通知客户端，但是回调方式也不能排除信息丢失的可能性。在上述实施例基础上，业务系统还可以通过定时器，例如预设时间之后，向客户端发送状态查询请求。状态查询请求用于请求查询第二交易数据的交易状态。状态查询请求例如可以携带第二交易数据的交易标识，通过交易标识可以向Fabric网络查询与之对应的交易数据的交易状态。其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合。例如业务系统向客户端发送10条交易数据，其中6条的交易状态已知，还有4条交易数据的交易状态未知，业务系统可以将4条交易数据的交易ID整合在状态查询请求中，通过调用与Fabric网络预先建立的通道实现查找，从而获得这4条交易数据的交易状态。

业务系统可以根据第二交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

即如果第二交易结果表示第二交易数据被成功地写入本地账本，则业务系统删除第二交易数据；

如果第二交易结果表示第二交易数据未被成功地写入本地账本，则业务系统向客户端重新发送第二交易数据。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

进一步请参考图4，图4示出了本申请实施例提供的基于Fabric网络的数据状态查询装置的结构示意图。

如图4所示，装置400可以布置在客户端上，该装置包括：

第一接收单元410，用于接收业务系统发送的交易数据。

第一发送单元420，用于将交易数据发送至网络节点。

本申请实施例中，通常业务系统通过调用Fabric sdk程序实现业务系统与Fabric网络的交互。Fabric sdk作为客户端，接收到业务系统的交易请求后，将交易请求发送至网络节点(也称为peer节点)，网络节点中的背书节点对交易请求执行对应的智能合约，并对执行结果进行背书签名，然后将背书签名后的执行结果返回给客户端。客户端收到所有背书节点签名后的执行结果后，通过网络服务进行广播。

在完成上述之后，通过客户端回调网络节点来获取反馈交易数据的状态。

第二接收单元430，用于接收网络节点针对交易数据返回的交易结果，其中，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息。

在客户端通过回调网络节点得到交易数据的交易结果。交易结果例如可以包括交易数据的交易标识(也可称为交易ID)和用于表示交易数据是否被成功地写入本地账本的指示信息。交易ID具有唯一性，能够唯一标识用户所进行的交易，并且无需用户名的重复检验。每个网络节点与客户端保持一个Eventhub的连接，在网络节点完成交易之后，发送消息通知客户端，该消息里可以包括指示信息来表示交易数据是否被成功地写入本地账本。

第二发送单元440，用于发送交易结果至业务系统，以供业务系统基于交易结果对交易数据执行相应的处理。

本申请实施例中，考虑到将区块写入本地账本后，客户端可以从Fabric网络获知交易结果后，并将交易结果发送至业务系统，业务系统可以根据交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

即如果交易结果表示交易数据未被成功地写入本地账本，则客户端从业务系统接收重新发送的交易数据，并将重新发送的交易数据发送至网络节点。

本申请实施例，通过将交易数据的交易结果发送至业务系统，使得业务系统可以根据反馈结果处理交易数据，提高了数据写入账本的成功率。

在上述实施例基础上，进一步还包括：

第三接收单元，用于接收业务系统发送的状态查询请求，状态查询请求用于请求查询第二交易数据的交易状态，其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合；

查找单元，用于响应于状态查询请求执行对应的查询操作。

其中，查找单元还可以进一步包括：

查找子单元，用于调用与Fabric网络预先建立的通道来查找与状态查询请求对应的第二交易数据的第二交易结果；

第三发送子单元，用于将第二交易结果发送至业务系统，以使得业务系统基于第二交易结果对第二交易数据执行相应的处理。

本申请实施例中，进一步考虑在Peer节点完成交易后，虽然在将区块写入账本后会发送消息通知客户端，但是回调方式也不能排除信息丢失的可能性。在上述实施例基础上，还可以通过定时器，例如预设时间之后，触发业务系统向客户端发送状态查询请求。状态查询请求用于请求查询第二交易数据的交易状态。状态查询请求例如可以携带第二交易数据的交易标识，通过交易标识可以向Fabric网络查询与之对应的交易数据的交易状态。其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合。例如业务系统向客户端发送10条交易数据，其中6条的交易状态已知，还有4条交易数据的交易状态未知，业务系统可以将4条交易数据的交易ID整合在状态查询请求中，通过调用与Fabric网络预先建立的通道实现查找，从而获得这4条交易数据的交易状态。

在业务系统基于交易数据或第二交易结果对交易数据或第二交易数据执行相应的处理之后，该装置400还包括：

第四接收单元，用于如果交易结果或第二交易结果表示交易数据或第二交易数据未被成功地写入本地账本，则从业务系统接收重新发送的交易数据或第二交易数据；

第四发送单元，用于将重新发送的交易数据或第二交易数据发送至网络节点。

本申请实施例通过业务系统主动查询交易数据的交易结果，克服仅通过回调获取交易数据的状态，可能导致数据丢失的问题，并进一步确保数据上链的成功率。

进一步参考图5，图5示出了根据本申请又一个实施例提供的基于Fabric网络的数据状态查询装置的结构示意图。

如图5所示，装置500可以布置在业务系统侧或实现为业务系统，其包括：

第五发送单元510，用于向客户端发送交易数据，以使得客户端将交易数据发送至网络节点。

本申请实施例中，通常业务系统通过调用Fabric sdk程序实现业务系统与Fabric网络的交互。Fabric sdk作为客户端，接收到业务系统的交易请求后，将交易请求发送至网络节点(也称为peer节点)，网络节点中的背书节点对交易请求执行对应的智能合约，并对执行结果进行背书签名，然后将背书签名后的执行结果返回给客户端。客户端收到所有背书节点签名后的执行结果后，通过网络服务进行广播。

在完成上述之后，通过客户端回调网络节点来获取反馈交易数据的状态。

第五接收单元520，用于从客户端接收交易结果，交易结果由网络节点针对交易数据返回，交易结果包括交易数据的交易标识和用于表示交易数据是否被成功地写入本地账本的指示信息。

第一处理单元530，用于基于交易结果对交易数据执行相应的处理。

本申请实施例中，考虑到将区块写入本地账本后，客户端可以从Fabric网络获知交易结果后，并将交易结果发送至业务系统，业务系统可以根据交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

第一处理单元可以包括：

删除子单元5301，用于如果交易结果表示交易数据被成功地写入本地账本，则删除交易数据；

重新发送子单元5302，用于如果交易结果表示交易数据未被成功地写入本地账本，则向客户端重新发送交易数据。

在上述实施例基础上，该装置500还可以包括：

统计单元，用于等待预设时间后，统计预设时间内已发送但未收到交易结果的交易数据的集合，得到第二交易数据；

第六发送单元，用于向客户端发送状态查询请求，状态查询请求用于请求查询第二交易数据的交易状态；

第六接收单元，用于接收第二交易数据的第二交易结果，第二交易结果是由客户端调用Fabric网络预先建立的通道查找得到的；

第二处理单元，用于基于第二交易结果对第二交易数据执行相应的处理。

第二处理单元也可以包括：

删除子单元5301，还用于如果第二交易结果表示第二交易数据被成功地写入本地账本，则删除第二交易数据；

重新发送子单元5302，用于如果第二交易结果表示第二交易数据未被成功地写入本地账本，则向客户端重新发送第二交易数据。

本申请实施例中，进一步考虑在Peer节点完成交易后，虽然在将区块写入账本后会发送消息通知客户端，但是回调方式也不能排除信息丢失的可能性。在上述实施例基础上，业务系统还可以通过定时器，例如预设时间之后，向客户端发送状态查询请求。状态查询请求用于请求查询第二交易数据的交易状态。状态查询请求例如可以携带第二交易数据的交易标识，通过交易标识可以向Fabric网络查询与之对应的交易数据的交易状态。其中，第二交易数据是指业务系统统计得到的预设时间范围内已发送的但未收到交易结果的交易数据的集合。例如业务系统向客户端发送10条交易数据，其中6条的交易状态已知，还有4条交易数据的交易状态未知，业务系统可以将4条交易数据的交易ID整合在状态查询请求中，通过调用与Fabric网络预先建立的通道实现查找，从而获得这4条交易数据的交易状态。

业务系统可以根据第二交易结果执行相应的处理，例如区块成功地写入本地账本，则业务系统可以删除对应的交易数据，如果区块未成功地写入本地账本则业务系统可以重新发送交易数据。

应当理解，装置400-500中记载的诸单元或模块与参考图1-2描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置400-500及其中包含的单元，在此不再赘述。装置400-500可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置400-500中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

下面参考图6，其示出了适于用来实现本申请实施例的终端设备或服务器的计算机系统600的结构示意图。

如图6所示，计算机系统600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本公开的实施例，上文参考图1或2描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，上述计算机程序包含用于执行图1或2的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括第一接收单元、第一发送单元以及第二接收单元和第二发送单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，第一接收单元还可以被描述为“用于接收业务系统发送的交易数据的单元”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中前述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，前述程序被一个或者一个以上的处理器用来执行描述于本申请的基于Fabric网络的数据状态查询方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (14)

1.一种基于Fabric网络的数据状态查询方法，其特征在于，该方法包括：

接收业务系统发送的交易数据；

将所述交易数据发送至网络节点；

接收所述网络节点针对所述交易数据返回的交易结果，其中，所述交易结果包括所述交易数据的交易标识和用于表示所述交易数据是否被成功地写入本地账本的指示信息；

发送所述交易结果至所述业务系统，以供所述业务系统基于所述交易结果对所述交易数据执行相应的处理。

2.根据权利要求1所述的方法，其特征在于，该方法还包括：

接收所述业务系统发送的状态查询请求，所述状态查询请求用于请求查询第二交易数据的交易状态，所述第二交易数据是指所述业务系统统计得到的预设时间内已发送的但未收到交易结果的交易数据的集合；

响应于所述状态查询请求执行对应的查询操作。

3.根据权利要求2所述的方法，其特征在于，响应于所述状态查询请求执行对应的查询操作，包括：

调用与所述Fabric网络预先建立的通道来查找与所述状态查询请求对应的第二交易数据的第二交易结果；

将所述第二交易结果发送至所述业务系统，以使得所述业务系统基于所述第二交易结果对所述第二交易数据执行相应的处理。

4.根据权利要求3所述的方法，其特征在于，在所述业务系统基于所述交易结果或第二交易结果对所述交易数据或第二交易数据执行相应的处理之后，该方法还包括：

如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据未被成功地写入本地账本，则从所述业务系统接收重新发送的所述交易数据或第二交易数据；

将所述重新发送的所述交易数据或第二交易数据发送至所述网络节点。

5.一种基于Fabric网络的数据状态查询方法，其特征在于，该方法包括：

向客户端发送交易数据，以使得所述客户端将所述交易数据发送至网络节点；

从所述客户端接收交易结果，所述交易结果由所述网络节点针对所述交易数据返回，所述交易结果包括所述交易数据的交易标识和用于表示所述交易数据是否被成功地写入本地账本的指示信息；

基于所述交易结果对所述交易数据执行相应的处理。

6.根据权利要求5所述的方法，其特征在于，该方法还包括：

等待预设时间后，统计所述预设时间内已发送但未收到交易结果的交易数据的集合，得到第二交易数据；

向所述客户端发送状态查询请求，所述状态查询请求用于请求查询所述第二交易数据的交易状态；

接收所述第二交易数据的第二交易结果，所述第二交易结果是由所述客户端调用所述Fabric网络预先建立的通道查找得到的；

基于所述第二交易结果对所述第二交易数据执行相应的处理。

7.根据权利要求6所述的方法，其特征在于，基于所述交易结果或第二交易结果对所述交易数据或第二交易数据执行相应的处理，包括：

如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据被成功地写入本地账本，则删除所述交易数据或第二交易数据；

如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据未被成功地写入本地账本，则向所述客户端重新发送所述交易数据或第二交易数据。

8.一种基于Fabric网络的数据状态查询装置，其特征在于，该装置包括：

第一接收单元，用于接收业务系统发送的交易数据；

第一发送单元，用于将所述交易数据发送至网络节点；

第二接收单元，用于接收网络节点针对所述交易数据返回的交易结果，其中，所述交易结果包括所述交易数据的交易标识和用于表示所述交易数据是否被成功地写入本地账本的指示信息；

第二发送单元，用于发送所述交易结果至所述业务系统，以供所述业务系统基于所述交易结果对所述交易数据执行相应的处理。

9.根据权利要求8所述的装置，其特征在于，该装置还包括：

第三接收单元，用于接收所述业务系统发送的状态查询请求，所述状态查询请求用于请求查询第二交易数据的交易状态，所述第二交易数据是指所述业务系统统计得到的预设时间内已发送的但未收到交易结果的交易数据的集合；

查找单元，用于响应于所述状态查询请求执行对应的查询操作。

10.根据权利要求9所述的装置，其特征在于，所述查找单元，包括：

查找子单元，用于调用所述Fabric网络预先建立的通道来查找与所述状态查询请求对应的第二交易数据的第二交易结果；

第三发送子单元，用于将所述第二交易结果发送至所述业务系统，以使得所述业务系统基于所述第二交易结果对所述第二交易数据执行相应的处理。

11.根据权利要求10所述的装置，其特征在于，在所述业务系统基于所述交易数据或所述第二交易结果对所述交易数据或所述第二交易数据执行相应的处理之后，该装置还包括：

第四接收单元，用于如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据未被成功地写入本地账本，则从所述业务系统接收重新发送的所述交易数据或第二交易数据；

第四发送单元，用于将所述重新发送的所述交易数据或第二交易数据发送至所述网络节点。

12.一种基于Fabric网络的数据状态查询装置，其特征在于，该装置包括：

第五发送单元，用于向客户端发送交易数据，以使得所述客户端将所述交易数据发送至网络节点；

第五接收单元，用于从所述客户端接收交易结果，所述交易结果由所述网络节点针对所述交易数据返回，所述交易结果包括所述交易数据的交易标识和用于表示所述交易数据是否被成功地写入本地账本的指示信息；

第一处理单元，用于基于所述交易结果对所述交易数据执行相应的处理。

13.根据权利要求12所述的装置，其特征在于，该装置还包括：

统计单元，用于等待预设时间后，统计所述预设时间内已发送但未收到交易结果的交易数据的集合，得到第二交易数据；

第六发送单元，用于向所述客户端发送状态查询请求，所述状态查询请求用于请求查询所述第二交易数据的交易状态；

第六接收单元，用于接收所述第二交易数据的第二交易结果，所述第二交易结果是由所述客户端调用所述Fabric网络预先建立的通道查找得到的；

第二处理单元，用于基于所述第二交易结果对所述第二交易数据执行相应的处理。

14.根据权利要求12或13所述的装置，其特征在于，所述第一处理单元或第二处理单元，包括：

删除子单元，用于如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据被成功地写入本地账本，则删除所述交易数据或第二交易数据；

重新发送子单元，用于如果所述交易结果或第二交易结果表示所述交易数据或第二交易数据未被成功地写入本地账本，则向所述客户端重新发送所述交易数据或第二交易数据。

Images