CN106874325A

CN106874325A - 数据的查询方法及装置

Info

Publication number: CN106874325A
Application number: CN201610500357.5A
Authority: CN
Inventors: 李兆贵; 周杰; 李少翀; 王义龙; 蒋超; 樊宏伟
Original assignee: Alibaba Group Holding Ltd
Current assignee: Ant Fortune Shanghai Financial Information Service Co ltd
Priority date: 2016-06-29
Filing date: 2016-06-29
Publication date: 2017-06-20
Anticipated expiration: 2036-06-29
Also published as: CN106874325B

Abstract

本申请提供一种目标数据的查询方法及装置，包括：接收查询端发送的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；查询所述查询数据所指示的所述目标数据分组对应的数据，基于查询到的所述数据构建响应报文；其中，所述响应报文包含至少一个子报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中；将构建完成的响应报文发送至所述查询端。本申请可以提升目标数据的查询灵活度。

Description

数据的查询方法及装置

技术领域

本申请涉及通信领域，尤其涉及一种数据的查询方法及装置。

背景技术

在实际应用中，在针对某一类包含众多属性的数据执行数据查询时，为避免针对不同的属性执行多次查询，而造成得查询效率比较低，系统开销较大的问题，通常可以将这一类数据中所包含的各属性的数据通过特定的报文格式组装在一条报文中，然后返回给查询端，来完成本次查询。

然而，通过这种方式，虽然可以在某种程度上减少用户的查询次数，但如果查询的数据中所包含的属性繁多，可能会造成报文臃肿，用户的查询不够灵活的问题。

发明内容

本申请提出一种数据的查询方法，该方法包括：

接收查询端发送的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

查询所述查询数据所指示的所述目标数据分组对应的数据，

基于查询到的所述数据构建响应报文；其中，所述响应报文包含至少一个子报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中；

将构建完成的响应报文发送至所述查询端。

可选的，所述子报文体包括主标签、子标签、取值标签以及自定义标签中的一个或者多个；

其中，所述主标签，用于指示所述子报文体对应的属性；

所述子标签，用于在所述属性包含子属性时，指示所述属性所包含的子属性的标识；

所述取值标签，用于指示与所述属性对应的取值；

所述自定义标签，用于在所述属性包含子属性时，指示为所述子属性定义的关联属性的取值；以及，在所述属性不包含子属性时，指示为所述属性定义的关联属性的取值。

可选的，当所述属性不包含子属性时，所述子报文体包括主标签、取值标签以及至少一个自定义标签；

当所述属性包含子属性时，所述子报文体包括主标签、子标签以及至少一个自定义标签；

其中，当所述属性包含多个子属性时，每一子属性分别对应不同的子报文体。

可选的，所述基于查询到的所述数据构建响应报文包括：

当所述查询数据指示针对所述目标数据中的多个目标数据分组时，基于查询到的与所述多个目标数据分组对应的数据，针对所述多个目标数据分组分别构建响应报文。

可选的，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识。

可选的，所述目标数据为金融账户数据。

本申请还提出一种数据的查询方法，该方法包括：

向查询响应端发送查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

接收查询响应端发送的响应报文；其中，所述响应报文中包含至少一个报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中。

可选的，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识；

所述方法还包括：

将解析所述响应报文中的子报文体获得的与所述目标数据分组对应的数据，提交至与所述业务标识对应的业务中进行处理。

本申请还提出一种数据的查询装置，该装置包括：

第一接收模块，用于接收查询端发送的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

查询模块，用于查询所述查询数据所指示的所述目标数据分组对应的数据，

构建模块，用于基于查询到的所述数据构建响应报文；其中，所述响应报文包含至少一个子报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中；

第一发送模块，用于将构建完成的响应报文发送至所述查询端。

其中，所述主标签，用于指示所述子报文体对应的属性；

所述取值标签，用于指示与所述属性对应的取值；

可选的，所述构建模块进一步用于：

可选的，所述目标数据为金融账户数据。

本申请还提出一种数据的查询装置，该装置包括：

第二发送模块，用于向查询响应端发送针对所述目标数据的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

第二接收模块，用于接收查询响应端发送的响应报文；其中，所述响应报文中包含至少一个报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中。

所述第二接收模块进一步用于：

本申请还提出一种目标数据的查询系统，系统包括：

查询端，以及与所述查询端对接的至少一个查询响应端；

所述查询端，向查询响应端发送查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

所述查询响应端，接收查询端发送的所述查询报文；查询所述查询数据所指示的所述目标数据分组对应的数据，基于查询到的所述数据构建响应报文，以及将构建完成的响应报文发送至所述查询端；其中，所述响应报文包含至少一个子报文体；所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中。

本申请中，通过将目标数据划分出若干属性分组，在接收查询端发送的针对该目标数据的查询报文时，基于该查询报文中携带的查询数据所指示的该若干属性分组中的一个或者多个目标数据分组，来查询与该目标数据分组对应的数据，然后将查询到的数据作为查询结果承载在响应报文中的子报文体中，返回至所述查询端，实现了用户在查询目标数据时，可以指定针对该目标数据中的查询维度，针对该目标数据被划分出的若干属性组中的一个或者多个属性分组的数据进行批量查询，从而既可以降低用户在针对目标数据执行查询时的查询次数，又可以提升查询效率以及查询灵活度。

附图说明

图1是本申请一实施例提供的一种数据的查询方法的流程图；

图2是本申请一实施例提供的一种查询金融账户数据的交互示意图；

图3是本申请一实施例提供的一种对FIX协议的报文封装格式进行扩展后构建出的查询报文、响应报文以及结束报文的报文结构示意图；

图4是本申请一实施例提供的一种扩展后的FIX协议中定义的标签含义的对照表；

图5是本申请一实施例提供的一种数据的查询装置的逻辑框图；

图6是本申请一实施例提供的承载所述一种数据的查询装置的查询端的硬件结构图；

图7是本申请一实施例提供的另一种数据的查询装置的逻辑框图；

图8是本申请一实施例提供的承载所述另一种数据的查询装置的查询响应端的硬件结构图。

具体实施方式

在相关技术中，在针对包含众多属性的某一类数据执行查询操作时，为避免针对不同的属性执行多次查询，通常可以将这一类数据中所包含的各属性的数据通过特定的报文格式组装在一条报文中，返回给查询端来完成查询；然而，将各属性的数据组装在一条报文中，可能会造成报文臃肿，用户的查询不够灵活的问题。

例如，在示出的一种应用场景中，上述包含众多属性的一类数据可以是金融账户数据。

其中，金融账户数据，是指用户在券商等金融机构的柜台系统中留存的数据，这些数据包含与用户账户相关的众多不同属性的数据，比如金融账户数据通常可以包括诸如资金余额、可用余额、总资产等不同的属性。

在日常的交易中，通常可以通过访问券商等金融机构的柜台系统来实时查询上述金融账户数据。在针对金融账户数据进行查询操作时，为避免针对上述金融账户数据中所包含的不同的属性执行多次查询，上述金融账户数据所在的柜台系统，在收到来自查询端的查询报文时，可以基于诸如FIX(Financial Information exchange，金融信息交换)协议等标准的金融账户查询协议，通过FIX协议定义的报文格式将上述金融账户数据中所包含的各属性的数据组装在一条报文中。

其中，FIX协议，是一种用于金融机构之间实时传递交易数据的开放式的金融账户查询协议。在该协议中，规定了若干定义的标签，每一个标签对应一种属性，在报文中采用“标签＝值”的形式承载需要传递的某一数据所包含的各种属性的数据。

比如，假设需要在传递的报文中增加一段“消息类型为U”的数据，消息类型为需要传递的该数据的一种属性，该属性在协议中定义的标签为35，那么可以在该报文中增加一段“35＝U”的标签和值的配对即可。

当上述金融账户数据所在的柜台系统通过FIX协议为上述金融账户数据中所包含的各属性定义的标签，将上述金融账户数据所包含的各属性的数据组装在一条报文后，可以将该报文作为查询结果返回给查询端，来完成本次查询。

然而，将上述金融账户数据所包含的各属性的数据组装在一条报文中，虽然可以在某种程度上减少用户的查询次数，但由于金融账户数据所包含的属性繁多，并且不同的金融机构的属性可能还会存在一定的差异，因此将上述金融账户数据中包含的所有属性的数据组装在一条报文中，可能会面临上述报文中定义的标签数量过多造成报文臃肿，用户的查询不够灵活；而且，当与多个不同的金融机构的柜台系统对接时，如果不同的金融机构针对同一属性定义的标签发生了变化，或者不同的金融机构针对某一属性定义的标签含义互不相同时，为了避免数据解析错误，在与不同的金融结构的柜台系统进行对接时，将不得不对报文中的部分标签进行修改，从而会导致上述报文的可扩展性差无法更好适应数据的变化的问题。

有鉴于此，本申请提出一种数据的查询方法，通过将目标数据划分出若干属性分组，在接收查询端发送的针对该目标数据的查询报文时，基于该查询报文中携带的查询数据所指示的该若干属性分组中的一个或者多个目标数据分组，来查询与该目标数据分组对应的数据，然后将查询到的数据作为查询结果承载在响应报文中的子报文体中，返回至所述查询端：

一方面，实现了用户在查询目标数据时，可以指定该目标数据被划分出的若干属性组中的一个或者多个属性分组，仅针对该一个或者多个属性分组的数据进行批量查询，从而既可以降低用户在针对目标数据执行查询时的查询次数，又可以提升查询效率以及查询灵活度；

另一方面，通过将查询结果中所包含的若干不同的属性对应的数据，分别承载在不同的子报文体中，可以利用不同的子报文体来组织各种不同的属性的数据，通过子报文体对各属性进行隔离，使得某一个属性的标签发生了变化，或者新增了属性时，可以通过扩展子报文体，快速的适应属性的数据变化，而不需要针对属性对应的标签进行单独修改，从而使得报文的可扩展性更好。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1，图1是本申请一实施例提供的一种数据的查询方法，应用于查询端以及查询响应端，所述查询端与所述查询响应端互相配合，执行以下步骤：

步骤101，查询端向查询响应端发送针对所述目标数据的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

上述目标数据，可以是包含了若干不同属性的数据集合。该数据集合中所包含的属性可以被划分出多个属性分组，每一个属性分组可以被定义为一个数据维度。

其中，在每一个属性分组中所包含的属性中，可以包含目标属性以及为该目标属性定义的关联属性。所谓目标属性可以是每一个属性分组中所包含的独立属性，而关联属性可以是对目标属性作进一步解释说明的附加属性。

例如，在金融交易的应用场景中，上述目标数据可以是指金融账户数据，在金融账户数据中通常可以包括若干不同的属性，比如可以包括诸如资金余额、可用余额、账户持有的股票名称、持有头寸、账户的总市值等独立的属性，也可以包括诸如货币类型等对以上各独立的属性作进一步解释说明的附加属性。而金融账户数据所包含的这些不同的属性，通常可以按照属性所指示的具体含义，划分成投资组合信息，市场价值信息，以及账户基本信息等不同的数据维度，每一个数据维度可以包含金融账户信息中含义相关的一组属性。

上述查询端，可以是指能够发起针对上述目标数据的查询操作的一端；而上述查询响应端，可以是指能够响应上述查询端发起的查询操作的另一端。

其中，上述查询端和查询响应端的具体形态在本例中不进行特别限定；在实际应用中，上述查询响应端可以是存储了上述目标数据的存储服务器，也可以是该存储服务器上具有调用上述目标数据的权限的系统；而上述查询端则可以是用户侧的客户端(比如APP)，也可以是与上述查询响应端对接的业务服务器上一具有目标数据查询需求的业务系统(比如交易系统)，等等，在本例中不再进行一一列举。

例如，如果上述目标数据为金融账户数据，那么上述查询响应端可以是金融机构的服务器上的柜台系统，上述查询端可以是用户侧的交易软件，或者是与金融机构的服务器对接的另一第三方金融服务机构的服务器上的交易系统。用户可以通过上述交易软件，或者上述交易系统，通过与金融机构的服务器之间预先建立的通信链路，与上述柜台系统进行通信，来查询上述金融账户数据。

在本例中，上述目标数据可以预存储在上述查询响应端一侧，查询端可以通过与查询响应端之间预先建立的通信链路进行通信，向查询响应端发起针对上述目标数据的查询操作，而上述查询响应端可以响应该查询操作，通过上述通信链路向查询端返回查询结果。

其中，上述目标数据中所包含的若干不同的属性，具体可以由查询响应端基于一定的规则划分出若干属性分组，并为划分出的属性分组设置数据分组标识。

在示出的一种实施方式中，查询响应端可以基于不同的属性之间固有的相关性来划分属性分组。在这种情况下，上述查询响应端在针对本地存储的目标数据进行属性划分时，可以将该目标数据中所包含的若干不同的属性中，具有相关性的一组或者一类属性划分为同一个数据属性。其中，该目标数据中所包含的若干不同的属性中的。

例如，仍以上述目标数据为金融账户数据为例，在金融账户数据中通可以包括诸如资金余额、可用余额、账户持有的股票名称、持有头寸、账户的总市值等不同的属性，而金融账户数据所包含的这些不同的属性，通常可以按照属性之间是否存在相关性，划分成多个数据属性；比如，对于资金余额、可用余额以及账户的总市值这些属性，通常为账户的基本属性，因此这些属性之间存在相关性，可以被划分到账户基本数据这个属性分组；而对于账户持有的股票名称、持有头寸这些属性，通常用于描述账户的投资组合，因此这些属性之间也存在相关性，可以被划分到投资组合数据这个属性分组。

在示出的一种实施方式中，查询响应端可以基于实际的业务需求，自定义的划分属性分组。在这种情况下，上述查询响应端在针对本地存储的目标数据进行属性分组划分时，可以根据实际的业务需求，将上述目标数据中所包含的若干不同的属性中，隶属于同一个业务的属性划分至同一个属性分组。

例如，上述查询响应端，可以根据实际的业务需求，将上述目标数据中所包含的若干不同的属性中，隶属于同一个业务的属性划分为同一个数据属性。在这种情况下，划分出的数据属性的数量，则取决于具体的业务数量，而且同一个属性分组中的属性可以不具有相关性。

当然，以上示出的属性分组的划分规则仅为示例性的，在实际应用中，上述业务响应端在进行数据属性的划分时，也可以采用以上示出的划分规则以外的其它划分规则，在本例中不再进行一一列举。

在本例中，为了提升目标数据查询的灵活性，在针对上述目标数据进行查询时，可以预先选定上述目标数据中的某一个或者多个属性分组作为查询维度，仅针对上述目标数据被划分出的若干属性分组中的一个或者多个属性分组的数据进行查询。

其中，在从上述目标数据中选定某一个或者多个属性分组作为查询维度时，可以由用户在上述查询端提供的用户界面中人工选定，也可以由上述查询端基于实际的业务需求自动进行选定。

一方面，当上述查询端为用户侧的客户端时，比如用户侧APP，该客户端软件可以面向用户提供一个用于选择查询属性的用户界面；在该界面中可以提供若干供用户选择的标签，每一个标签分别对应上述目标数据中的一个属性分组，用户可以直接在该用户界面中进行操作，通过选定其中的一个或者多个标签，来确定查询维度。

例如，如果上述目标数据为金融账户数据，包括投资组合信息、市场价值信息以及账户基本信息等三个属性分组；上述查询客户端为用户侧的交易软件；那么可以在该交易软件的用户界面中可以分别提供“投资组合信息”、“市场价值信息”以及“账户基本信息”三个标签，用户可以在该用户界面中选择标签，将与该标签对应的属性分组选定为查询维度。比如，假设用户希望查询金融账户数据中的投资组合信息，那么用户在该用户界面中将上述“投资组合信息”的标签选中即可。

另一方面，当上述查询端为与上述查询响应端对接的业务服务器上一具有目标数据查询需求的业务系统(比如交易系统)时，该业务系统可以根据实际的业务需求(比如该业务可能仅需要查询上述目标数据中的某一个属性分组或者其中多个属性分组的数据)，自动从上述目标数据被划分出的若干属性分组中选定一个或者多个属性分组作为查询维度。

例如，如果上述目标数据为金融账户数据，包括投资组合数据、市场价值数据以及账户基本数据等三个属性分组；上述作为查询端的业务系统可以是与金融机构的柜台系统对接的另一第三方金融机构的交易系统；假设该交易系统具有基于金融账户数据中的“投资组合信息”，为用户推荐股票的功能时，由于该交易系统在实现这种功能时，仅需要查询金融账户数据中的“投资组合信息”，那么交易系统可以将金融账户信息中的“投资组合信息”的属性分组自动选定为目标数据分组即可。

在本例中，当查询端获取到针对上述目标数据的查询属性后，可以在本地构建一个用于针对上述目标数据进行查询的查询报文。

在该查询报文中，可以携带查询数据，进一步还可以携带业务标识，以及与上述目标数据对应的用户账号等数据。

上述查询数据，用于指示选定的针对上述目标数据被划分出的若干属性分组中的一个或者多个目标数据分组；其中，该目标数据分组，即为本次需要查询的属性分组。

上述业务标识，用于指示查询结果将在何种业务中继续进行处理。

在实际应用中，可以在查询报文中扩展出一个字段，在该字段中可以填充用于指示选定的目标数据分组的查询数据。

其中，上述查询数据具体可以包括对应于上述目标数据分组的取值标签、数据分组标识、或者用于匹配出上述目标数据分组的属性标识或者数据。

例如，在示出的一种实施方式中，上述查询类型标签可以是一个对应于上述目标数据分组的取值标签。在使用该取值标签来指示选定的查询属性时，可以将查询报文中扩展出一个与上述查询类型标签对应的字段，并在该字段中划分出若干比特位，其中，该字段中比特位的数量，可以与上述目标数据中被划分出的属性分组的数量一致，每一个比特位可以分别对应一个属性分组。

将某一个属性分组选定为目标数据分组后，可以在与该属性分组对应的比特位中填充用于指示与该比特位对应的数据属性被选中的取值标签即可。例如，可以在比特位中填入取值标签1，表示与该比特位对应的属性分组被选定；在比特位中填入取值标签0，表示与该比特位对应的属性分组未被选定。

在示出的另一种实施方式中，上述标识信息也可以是一个对应于上述目标数据分组的信息片段；其中，该信息片段具体可以是被选定的目标数据分组中所包含的属性标识或者数据；比如，在通过信息片段来指示选定的目标数据分组时，也可以在查询报文中扩展出一个与上述标识信息对应的字段，在将某个属性分组选定为目标数据分组时，可以在该字段中填充选定的该目标数据分组中所包含的任一属性的标识或者数据，从而响应端可以通过该属性的标识或者数据与预先划分出的各属性分组中所包含的数据进行匹配，来确定选定的目标数据分组。在示出的另一种实施方式中，上述标识信息也可以是一个对应于上述目标数据分组的数据分组标识；其中该数据分组标识即为查询响应端针对目标数据划分出的各属性分组设置的数据分组标识。比如，在通过数据分组标识来指示选定的目标数据分组时，也可以在查询报文中扩展出一个与上述标识信息对应的字段，在将某个属性分组选定为目标数据分组时，可以在该字段中填充选定的该目标数据分组的数据分组标识，从而响应端可以通过该数据分组标识唯一查询到选定的该目标数据分组。

在本例中，当上述查询客户端构建出上述查询报文后，可以将该查询报文发送至查询响应端进行处理。

需要说明的是，查询端构建完成的上述查询报文中，除了可以包括上述查询数据，业务标识，以及与上述目标数据对应的用户账号等信息以外，还可以包括报文头以及报文尾。

其中，上述报文头和报文尾的具体内容，通常取决于封装上述响应报文的具体协议，在本例中不进行特别限定；

例如，当基于FIX协议封装上述查询报文时，那么该查询报文的报文头和报文尾的格式，可以直接采用FIX协议中规定的报文头和报文尾的标准格式即可，而不需要进行任何更改，因此在本例中对于报文头和报文尾的格式将不再进行详述，本领域技术人员在将本申请中记载的技术方案付诸实施时可以参考相关技术中的记载。

步骤102，查询响应端接收查询端发送的查询报文，查询所述查询数据所指示的所述目标数据分组对应的数据，并基于查询到的所述数据构建响应报文；其中，所述响应报文中包含至少一个子报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中；

在本例中，查询响应端在接收到查询端发送的针对所数据的查询报文后，可以解析该查询报文，获取该查询报文中携带的查询数据、业务标识以及用户账户等信息。

当获取到上述信息后，还可以进一步解析上述查询数据，来获取该查询数据指示的上述目标数据被划分出的若干属性分组中的一个或者多个目标数据分组。

例如，假设上述查询数据为与目标数据分组对应取值标签。上述查询报文中与上述查询类型标签对应的字段中，所包含的比特位填入的取值为1，表示与该比特位对应的属性分组被选定为目标数据分组；填入的取值为0，表示与该比特位对应的属性分组未被选定为目标数据分组，那么查询响应端在解析上述查询类型标签时，可以扫描所有填入了1的比特位，将与填入了1的比特位对应的属性分组，确定为本次需要查询的目标数据分组。

当查询响应端通过解析上述查询数据，获取到查询端选定的针对上述目标数据中的目标数据分组后，可以查询与该目标数据分组对应的数据。

在本例中，查询响应端可以基于针对上述目标数据的属性分组划分结果，在本地创建一张数据维度表，该数据维度表中包含若干个数据维度，每一个数据维度对应一个划分出的属性分组。

在查询与上述目标数据分组对应的数据时，可以从上述数据维度表中查找到该目标数据分组，然后获取该目标数据分组中所包含的若干目标属性的标识，并基于获取到的标识来查询与该目标属性对应的数据。

其中，查询响应端在基于获取到的目标属性的标识，查询该目标属性的值时，可以从本地的数据库中查询，也可以从对接的其它系统中来查询。

例如，在一种情况下，如果上述目标数据已经预存在本地的信息数据库中，那么查询响应端在基于上述属性分组划分结果在本地创建上述数据维度表时，就可以根据该数据维度表中记录的各属性分组中的目标属性的标识，从本地数据库中读取与该标识对应的数据，然后填充在上述数据维度表中。当需要查询目标属性的数据时，可以从上述数据维度表中读取相应的数据即可。

在另一种情况下，如果上述目标数据未预存在本地的信息数据库中，那么查询响应端可以根据该数据维度表中记录的各属性分组中的目标属性的标识，从对接的其它系统中读取对应的数据，然后保存至该数据维度表中，然后再从该数据维度表中读取数据即可。在本例中，当查询响应端查询到与选定的上述目标数据分组中所包含的各目标属性对应的数据后，可以基于查询到的数据来构建响应报文，以向查询端返回查询结果。

在示出的一种实施方式中，为了提升响应报文的可扩展性，使得响应报文可以更好的适应上述目标数据中所包含的目标属性的数据变化，可以针对上述目标属性中所包含的各目标属性，分别构建出一个独立的子报文体，然后将构建出的子报文体封装在响应报文中。

一方面，封装完成的该响应报文的报文体中，将包含一个或者多个子报文体(子报文体的数量与查找到的数据中所包含的目标属性的数量相关)。该子报文体用于承载查询结果。

另一方面，查询到的与上述查询属性对应的数据中所包含的各目标属性的数据，将分别承载在不同的子报文体中，此时每一个目标属性将分别对应一个独立的子报文体。通过这种方式，可以利用子报文体对各目标属性进行隔离，而不会对其它属性造成影响。

在示出的一种实施方式中，在上述子报文体的架构中，组成上述子报文体的基本元素可以包括主标签、子标签、取值标签以及自定义标签。

其中：

上述主标签，用于指示上述子报文体对应的目标属性；

上述子标签，用于在上述子报文体对应的目标属性包含子属性时，指示上述目标属性所包含的子属性的标识；

上述取值标签，用于指示与上述目标属性对应的取值；

上述自定义标签，用于在上述目标属性包含子属性时，指示为上述子属性定义的关联属性的取值；以及，在所述目标属性不包含子属性时，指示为上述目标属性定义的关联属性的取值。

需要说明的是，构成子报文体的主标签、子标签、取值标签和自定义标签等元素，均为基础元素。

在实际应用中，除了上述主标签以外，子标签、取值标签和自定义标签可以均为可选标签；在封装上述子报文体时，可以根据具体的封装协议或者实际的查询需求，使用主标签，和上述可选标签中的一个或多个进行组合。

一方面，如果与上述子报文体对应的目标属性为独立的属性，不包含子属性，此时上述子报文体可以由主标签、取值标签以及自定义标签构成。

在这种情况下，上述子报文体中可以不包含子标签，同时上述自定义标签则用于指示为上述子报文体对应的目标属性定义的关联属性的取值。

当然，如果并未针对上述目标属性单独定义关联属性的话，上述子报文体中也可以不包含上述自定义标签。

另一方面，如果与上述子报文体对应的目标属性还包含子属性，此时上述子报文体可以由主标签、子标签以及自定义标签构成。

在这种情况下，上述子报文体中可以包含子标签，不包含上述取值标签，同时上述自定义标签则用于指示为上述目标属性所包含的子属性定义的关联属性的取值。

例如，假设上述目标数据为金融账户数据，包括投资组合信息、市场价值信息以及账户基本信息等三个属性分组；

在一种情况下，假设选定的属性分组为“账户基本信息”，在“账户基本信息”这个属性分组下通常包括“货币类型”、“资金金额”、“可用余额”、“股票市值”、“总资产”等5种目标属性。以上5种目标属性均不包含子属性。

在基于FIX协议封装上述响应报文时，封装后的响应报文将包含与以上5种查询属性分别对应的5个独立的子报文体，每一个子报文体用于承载对应的目标属性的数据。

在示出的一个例子中，基于FIX协议封装完成的上述响应报文所包含的与上述目标属性“资金金额”对应的子报文体可以如下所示：

8001＝资金余额<SOH>15＝USD<SOH>6066＝1444801729<SOH>8004＝112900.00

其中，在上述子报文体中：

8001是定义的该子报文体中的上述主标签，用于指示上述子报文体对应的目标属性为“资金余额”。

标签15和6066为针对上述目标属性“资金金额”定义的自定义标签，标签15在FIX协议中表示货币类型，15＝USD表示货币类型为美元。6066在FIX协议中表示时间戳，即查询该“资金余额”这个属性时的精确时间。

8004是定义的该子报文体中的上述取值标签，用于指示主标签8001的具体取值；8004＝100表示资金余额为100美元。

通过以上例子可见，由于“资金余额”这个属性不包含子属性，因此上述子报文体可以由主标签8001、取值标签8004和自定义标签构成，可以不包含上述子标签。

在另一种情况下，假设选定的属性分组为“投资组合信息”，在“投资组合信息”这个属性分组下包括“投资组合列表”这个目标属性；其中，“投资组合列表”这个目标属性包含子属性，该子属性可以是该投资组合列表中包含的具体的投资产品的标识；比如股票名称。

在示出的一个例子中，假设“投资组合列表”这个目标属性包含“IBM”这一子属性，那么基于FIX协议封装完成的上述响应报文所包含的与上述属性“投资组合列表”对应的子报文体可以如下所示：

8001＝投资组合列表<SOH>8002＝IBM<SOH>6064＝1000<SOH>15＝USD<SOH>6065＝150.00<SOH>6101＝100.00

其中，在上述子报文体中：

8001是定义的该子报文体中的上述主标签，用于指示上述子报文体对应的目标属性为“投资组合列表”。

8002是定义的该子报文体中的上述子标签，用于指示“投资组合列表”这个目标属性所包含的子属性的具体标识；在该例中，该子属性为“投资组合列表”中所包含的股票，该子属性的标识为“投资组合列表”中所包含的该股票的股票名称，8002＝IBM表示用户的投资组合列表中包含股票IBM。

标签6064、15、6065以及6101为针对上述子属性“IBM”定义的自定义标签，标签6064在FIX协议中表示股票头寸(即持有股票的数量)，6064＝1000表示持有1000股IBM的股票。标签15在FIX协议中表示货币类型，15＝USD表示持有IBM的股票的货币类型为美元。6065在FIX协议中表示市价，6065＝150表示持有IBM的股票的货实价为150美金。6101在FIX协议中平均成本，6101＝100.00表示持有IBM的股票的货实价为100美金。

通过以上例子可见，由于“投资组合列表”这个目标属性，包含子属性，因此在这种情况下，上述子报文体可以由主标签、子标签和自定义标签共同构成，可以不包含上述取值标签。

其中，需要说明的是，在实际应用中，当上述目标属性包含多个子属性时，还可以针对上述目标属性所包含的每一个子属性，分别构建一个独立的子报文体。

在示出的另一个例子中，假设上述“投资组合列表”这个目标属性除了包含“IBM”这一子属性以外，还包含“ALIBABA”这一子属性，那么基于FIX协议封装完成的上述响应报文中，除了可以包含为上述属性“投资组合列表”构建的子报文体，还可以包含如下所示的针对上述子属性“ALIBABA”构建的子报文体：

8001＝投资组合列表<SOH>8002＝ALIBABA<SOH>6064＝1000<SOH>15＝USD<SOH>6065＝150.00<SOH>6101＝100.00

其中，上述子报文体中各标签的含义不再赘述。

在本例中，查询响应端构建完成的上述响应报文，除了可以包括一个或者多个子报文体外，还可以包括报文头、报文尾以及业务标识。

其中，上述业务标识，需要与上述查询端发送的查询报文中携带的业务标识保持一致。

上述报文头和报文尾的具体内容，通常取决于封装上述响应报文的具体协议，可以直接采用封装该响应报文时所使用的协议(比如FIX协议)中规定的报文头和报文尾的标准格式即可。

另外，需要说明的是，在实际应用中，由于可能会对针对多个目标属性定义同一个关联属性，因此对于关联属性而言，可以分别承载在不同的子报文体中；

例如，对于“货币类型”这个属性而言，可以被定义为“资金金额”、“可用余额”、“股票市值”、“总资产”等目标属性的关联属性，因此“货币类型”这个属性可以分别承载在为“资金金额”、“可用余额”、“股票市值”、“总资产”等目标属性构建的子报文体中。

可见，通过扩展子报文体，可以对查询结果中所包含的各属性的数据，重新进行组织并进一步进行归类，将查询结果中所包含的各目标属性，以及为该目标属性定义的关联属性封装在同一个子报文体中，从而使得响应报文中所承载的各目标属性对应的数据将更加易于解析和提取。

步骤103，查询响应端将构建完成的所述响应报文发送至所述查询端，以向所述查询端返回查询结果。

在本例中，上述查询响应端在构建上述响应报文时，如果上述查询端从上述目标数据被划分出的若干属性分组中选定了多个目标数据分组，此时查询响应端可以基于查询到的与该多个目标数据分组对应的数据，分别构建一条响应报文。通过这种方式，可以减少响应报文中携带的信息量，提升响应报文的解析效率。

在这种情况下，上述查询响应端可以将构建完成的多个响应报文，依次发送至查询端，通过构建完成的这些响应报文中的子报文体所封装的数据，将查询结果返回至查询端。

当然，在实际应用中，为了减少数据查询过程中的报文交互数量，降低系统开销，如果上述查询端从上述目标数据被划分出的若干属性分组中选定了多个目标数据分组，查询响应端也可以将查询到的该多个目标数据分组对应的数据封装在一条响应报文。

通过这种方式，可以将查询到的该多个目标数据分组对应的数据承载在一条响应报文，返回至查询端，可以有效减少查询数据时交互报文的数量，降低系统开销。

在本例中，当上述查询端接收到上述查询响应端发送的响应报文后，可以解析该响应报文中携带的子报文体，来获取子报文体中承载的与选定的目标数据分组中所包含的各个目标属性对应的数据，并将解析子报文体获取到的数据提交至与上述业务标识对应的业务中继续进行处理。

例如，假设上述目标数据为金融账户数据：

一方面，如果查询端为用户侧的交易软件；那么与上述业务标识对应的业务，可以是在交易软件的用户界面中显示查询到的数据的业务。

在这种场景下，当交易软件从接收到的响应报文中的子报文体中解析出子报文体承载的查询结果后，可以将查询结果提交至该业务，从而可以在用户界面中向用户显示查询结果。

另一方面，如果上述查询查询客户端为与金融机构的柜台系统对接的另一第三方金融机构的交易系统；假设该交易系统具有基于查询到的金融账户数据，为用户推荐股票的功能，那么与上述业务标识对应的业务，可以是基于查询到的金融账户数据为用户推荐股票的业务。

在这种场景下，当交易软件从接收到的响应报文中的子报文体中解析出子报文体承载的查询结果后，可以将查询结果提交至该业务，从而使得交易系统可以基于该查询结果进行分析计算后为用户推荐股票。

另外，需要说明的是，在本例中，由于在针对上述目标数据进行查询时，可能最终仅会返回从上述目标数据中选定的一个或者其中几个目标数据分组的数据，因此最终返回的数据可能仅能涵盖上述目标数据中所包含的部分属性的数据。

在这种情况下，上述查询端很可能会错误的判定为针对上述目标数据的查询尚未结束，而并没有立刻将查询到数据提交给相应的业务进行处理，从而造成业务处理不够及时的问题。

因此，为了解决上述问题，当上述查询响应端在将构建完成的响应报文，发送至上述查询端后，还可以向查询端发送一条结束报文。

其中，该结束报文，用于指示查询端针对上述目标数据的查询结束。在该结束报文中可以携带报文头、报文尾以及业务标识。

该业务标识，需要与上述查询端发送的查询报文中携带的业务标识保持一致。而上述报文头和报文尾的具体内容，通常取决于封装上述响应报文的具体协议，可以直接采用封装该结束报文时所使用的协议(比如FIX协议)中规定的报文头和报文尾的标准格式即可，不再赘述。

当上述查询端通过解析上述响应报文，获取到上述响应报文中的子报文所承载的查询结果后，如果接收到了上述查询响应端的结束报文，表明当前查询已经结束，则可以立即将解析出的查询结果提交至相应的业务进行处理，从而可以确保该业务处理的实时性。

至此，上述查询端针对上述目标数据的查询结束。

通过以上实施例可知，一方面，本申请实现了用户在查询目标数据时，可以指定针对该目标数据中的查询维度，针对该目标数据被划分出的若干属性组中的一个或者多个属性分组的数据进行批量查询，从而既可以降低用户在针对目标数据执行查询时的查询次数，又可以提升查询效率以及查询灵活度；

另一方面，通过将查询结果中所包含的若干不同的目标属性对应的数据，分别承载在不同的子报文体中，可以利用不同的子报文体来组织各种不同的目标属性的数据，通过子报文体对各属性进行隔离，使得某一个属性的标签发生了变化，或者新增了属性时，可以通过扩展子报文体，快速的适应属性的数据变化，而不需要针对属性对应的标签进行单独修改，从而使得报文的可扩展性更好。

而且，通过扩展子报文体，可以对查询结果中所包含的各属性的数据，重新进行组织并进一步进行归类，将查询结果中所包含的各目标属性，以及为该目标属性定义的关联属性封装在同一个子报文体中，从而使得响应报文中所承载的各目标属性对应的数据将更加易于解析和提取。

以下以上述目标数据为金融账户数据，并结合金融账户数据查询的应用场景对以上实施例中的技术方案进行详细说明。

当然，需要说明的是，以上述目标数据为金融账户数据仅为示例性的，在实际应用中，上述目标数据也可以是诸如社交账户信息、产品信息等其它类型的目标数据，即本申请以上实施例示出的技术方案也可以是应用于金融账户数据查询以外的其它应用场景，在本例中不再进行一一列举。

请参见图2，图2为本例示出的一种查询金融账户数据的交互示意图。

在图2所示出的交互场景中，包括金融机构A的柜台系统以及与该金融机构A对接的交易系统。

其中：

用户A在金融机构A的柜台系统完成交易账户注册，与该交易账户对应的金融账户数据存储在金融机构A的柜台系统中。

上述交易系统，为具有查询用户A的金融账户数据需求的系统。在本例中，该交易系统具有基于查询到的用户A的金融账户数据为用户A推荐股票数据的业务功能。

金融机构A的柜台系统(以下简称柜台系统)与交易系统(以下简称交易系统)之间预先建立了通信链路，该通信链路用于承载查询用户A的金融账户数据时的报文交互。

请参见表1，表1为本例示出的上述柜台系统存储的用户A的金融账户数据包含的信息图表。

由表1可知，用户A的账户名称为U900147，与该账户对应的金融账户数据包含账户基本信息、投资组合信息以及市场价值信息等三个属性分组。

在本例中，交易系统和柜台系统在执行查询用户A的账户U900147的金融账户数据的过程中所交互的查询报文，仍然采用FIX协议进行封装。

同时，为了使基于FIX协议封装的查询报文，能够实现针对从用户A的账户U900147的金融账户数据中选定的一个或者多个属性分组进行查询的功能，可以对FIX协议的报文封装格式进行扩展。

请参见图3，图3为本例示出的对FIX协议的报文封装格式进行扩展后构建出的查询报文、响应报文以及结束报文的报文结构。

如图3所示，上述查询报文包括报文头、报文尾、查询类型标签、业务标识以及用户A的用户账号U900147。

其中，上述查询类型标签可以包含3干个比特位，每一个比特位对应一个金融账户数据的属性分组，取值为1表示选定对应的属性分组；取值为0表示未选定对应的属性分组。

上述响应报文包括报文头、报文尾、业务标识以及一个或者多个子报文体。

上述结束报文包括报文头、报文尾以及业务标识。

其中，查询报文、响应报文以及结束报文中的报文头和报文尾，遵循FIX协议中定义的标准格式，可以直接采用FIX协议中规定的报文头和报文尾的标准格式即可。查询报文、响应报文以及结束报文中的业务标识需要保持相同。

请继续参见图3，组成上述子报文体的基本元素包含主标签8001、子标签8002、取值标签8004以及自定义标签。

其中，子标签8002、取值标签8004以及自定义标签为可选标签，可以根据实际情况进行增减。

如果与上述子报文体对应的目标属性不包含子属性，此时上述子报文体可以由主标签8001、取值标签8004以及自定义标签构成。如果与上述子报文体对应的目标属性包含子属性，此时上述子报文体可以由主标签8001、子标签8002以及自定义标签构成。

请参见图4，图4为本例示出的扩展后的FIX协议中定义的标签含义的对照表。

在本例中，可以基于图4中所示出的FIX协议中定义的各标签，来封装查询报文、响应报文以及结束报文。

请继续参见图2，在初始状态下，交易系统可以基于实际的业务需求从账户U900147的金融账户数据所包含的3种属性分组中选定一个或者多个作为需要查询的目标数据分组，然后基于图3所示出的查询报文的格式，图4中所示出的标签以及表1中记载的信息来封装查询报文。

交易系统封装出的查询报文如下：

8＝FIX.4.2<SOH>9＝94<SOH>35＝U<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6095＝U900147<SOH>6096＝XXX<SOH>6529＝20140333<SOH>10＝191

其中：

8＝FIX.4.2<SOH>9＝94<SOH>35＝U<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>，为基于FIX协议构建的报文头；<SOH>10＝191，为基于FIX协议构建的报文尾；

标签6095在FIX协议中表示交易账户；标签6529在FIX协议中表示用于区分业务的消息标识(即业务标识)。

6096为对FIX协议进行扩展定义的查询类型标签，其具体取值指示选定的目标数据分组。

其中，当标签6096的取值为0x7(二进制表示为111，表示三个比特位均置位为1)时，指示金融账户数据的三个属性分组均被选定为目标数据分组。当标签6096的取值为0x4(二进制表示为100，表示第一个比特位置位为1)时，指示金融账户数据的属性分组“账户基本信息”被选定为目标数据分组。当标签6096的取值为0x2(二进制表示为010，表示第二个比特位置位为1)时，指示金融账户数据的属性分组“投资组合信息”被选定为目标数据分组。当标签6096的取值为0x1(二进制表示为001，表示第三个比特位置位为1)时，指示金融账户数据的属性分组“市场价值信息”被选定为目标数据分组。

1)选定表1中“账户基本信息”为目标数据分组

交易系统将封装完成的查询报文发送至柜台系统，柜台系统收到该查询报文后，解析该查询报文获取选定的目标数据分组。

如果交易系统选定的目标数据分组为“账户基本信息”(即上述查询报文中6096＝0x4)：

由表1可知，“账户基本信息”包括“资金金额”、“可用余额”、“股票市值”以及“总资产”等4个目标属性，该4个目标属性均不包含子属性，可以针对上述4个目标属性分别构建一个子报文体，然后基于构建完成的子报文体封装响应报文。

此时，基于图3所示出的报文结构、图4中所示出的标签以及表1记载的信息构建出的响应报文如下：

8＝O<SOH>9＝11<SOH>35＝UT<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6529＝20140333<SOH>8001＝资金余额<SOH>15＝USD<SOH>6066＝1444801729<SOH>8004＝112900.00<SOH>8001＝可用余额<SOH>15＝USD<SOH>6066＝1444801729<SOH>8004＝112900.00<SOH>8001＝股票市值<SOH>15＝USD<SOH>6066＝1444801729<SOH>8004＝160320.00<SOH>8001＝总资产<SOH>15＝USD<SOH>6066＝1444801729<SOH>8004＝272220.00<SOH>10＝376

其中：

8＝O<SOH>9＝11<SOH>35＝UT<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6529＝20140333<SOH>，为基于FIX构建的报文头；<SOH>10＝376，为基于FIX协议构建的报文尾；标签6529在FIX协议中表示用于区分业务的消息标识(即业务标识)；

在该响应报文中，用户A的“账户基本信息”所包含的目标属性“资金金额”、“可用余额”、“股票市值”以及“总资产”分别对应一个独立的子报文体。各子报文体中的内容与表1中记载的数据保持一致。

其中，由于目标属性“资金金额”、“可用余额”、“股票市值”以及“总资产”均不包含子属性，因此上述响应报文中封装的与上述各属性对应的子报文，均不包含子标签8002，而是由主标签8001、取值标签8004，以及若干为上述各属性定义的关联属性对应的标签(比如以上各子报文体中的标签15以及6066)构成。

2)选定表1中“投资组合信息”为目标数据分组

柜台系统收到该查询报文后，如果交易系统选定的目标数据分组为“投资组合信息”(即上述查询报文中6096＝0x2)：

由表1可知，“投资组合信息”包括“投资组合”这一目标属性，而“投资组合”这一目标属性包括“ALIBABA”以及“IBM”等2个子属性，可以针对上述2个子属性分别构建一个子报文体，然后基于构建完成的子报文体封装响应报文。

基于图3所示出的报文结构、图4中所示出的标签以及表1记载的数据构建出的响应报文如下：

8＝O<SOH>9＝12<SOH>35＝UP<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A6529＝20140333<SOH>8001＝投资组合<SOH>8002＝IBM<SOH>6064＝1000<SOH>15＝USD<SOH>6065＝150.00<SOH>6101＝100.00<SOH>8001＝投资组合<SOH>8002＝ALIBABA<SOH>6064＝1000<SOH>15＝HKD<SOH>6065＝80.00<SOH>6101＝70.00<SOH>10＝87

其中：

8＝O<SOH>9＝12<SOH>35＝UP<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A6529＝20140333<SOH>，为基于FIX构建的报文头；<SOH>10＝87，为基于FIX协议构建的报文尾；标签6529在FIX协议中表示用于区分业务的消息标识(即业务标识)；

在该响应报文中，用户A的“投资组合信息”所包含的子属性“ALIBABA”以及“IBM”可以分别对应一个独立的子报文体。各子报文体中的内容与表1中记载的信息保持一致。

其中，由于目标属性“投资组合信息”包含子属性，因此上述响应报文中封装的与上述各子属性对应的子报文体中，可以不包含取值标签8004，由主标签8001、子标签8002，以及若干为上述各子属性定义的关联属性对应的标签(比如以上各子报文体中的标签6064、15、6065以及6101等等)构成。

3)选定表1中“市场价值信息”为目标数据分组

柜台系统收到该查询报文后，如果交易系统选定的目标数据分组为“市场价值信息”(即上述查询报文中6096＝0x1)：

由表1可知，“市场价值信息”包括“市场价值”这一目标属性，而“市场价值”这一目标属性包括“港元市场价值”以及“美元市场价值”等2个子属性，可以针对上述2个子属性分别构建一个子报文体，然后基于构建完成的子报文体封装响应报文。

基于图3所示出的报文结构、图4中所示出的标签以及表1记载的信息构建出的响应报文如下：

8＝O<SOH>9＝13<SOH>35＝RL<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6529＝20140333<SOH>8001＝港元市场价值<SOH>8002＝HKD<SOH>15＝HKD<SOH>9818＝100000.00<SOH>9807＝80000.00<SOH>9808＝0.00<SOH>9809＝0.00<SOH>8001＝美元市场价值<SOH>8002＝USD<SOH>15＝USD<SOH>9818＝10000.00<SOH>9807＝150000.00<SOH>9808＝0.00<SOH>9809＝0.00<SOH>10＝87

其中：

8＝O<SOH>9＝13<SOH>35＝RL<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6529＝20140333<SOH>，为基于FIX构建的报文头；<SOH>10＝87，为基于FIX协议构建的报文尾；标签6529在FIX协议中表示用于区分业务的消息标识(即业务标识)；

在该响应报文中，用户A的“投资组合信息”所包含的子属性“港元市场价值”以及“美元市场价值”分别对应一个独立的子报文体。各子报文体中的内容与表1中记载的信息保持一致。

其中，由于属性“投资组合信息”包含子属性，因此上述响应报文中封装的与上述各子属性对应的子报文体中，可以不包含取值标签8004，由主标签8001、子标签8002，以及若干为上述各子属性定义的关联属性对应的标签(比如以上各子报文体中的标签15、9818、9807、9808＝0.00以及9809等等)构成。

在以上例子中，分别描述了从用户A的金融账户数据所包含的“账户基本信息”、“投资组合信息”以及“市场价值信息”等属性分组中选定唯一的目标数据分组，然后基于FIX协议封装查询报文以及响应报文的过程。

需要指出的是，在实际应用中，也可以从而用户A的金融账户数据中所包含的“账户基本信息”、“投资组合信息”以及“市场价值信息”等信息目标数据分组中选定多个属性分组作为需要查询的目标数据分组；比如，可以同时选定“账户基本信息”、“投资组合信息”以及“市场价值信息”等属性分组中的任意两个作为目标数据分组。

当选定了多个属性分组作为目标数据分组时，仍然可以基于图3所示出的报文结构、图4所示出的标签以及表1中记录的信息，按照以上描述的方式，针对选定的每一个目标数据分组分别构建出一条响应报文。

或者，也可以针对选定的多个目标数据分组构建同一条响应报文，将查询到的与该多个目标数据分组所包含的目标属性的数据，分别承载在不同的子报文体中，然后使用统一的报文头和报文尾，将所有的子报文体封装在同一条响应报文中，用以向交易系统返回查询结果，具体实施过程不再详述。

在本例中，当柜台系统将构建完成的响应报文发送至交易系统后，还可以基于图3所示出的报文结构以及图4中示出的标签构建一条结束报文，构建的结束报文如下：

8＝O<SOH>9＝12<SOH>35＝EB<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>6529＝20140333<SOH>10＝7

其中：

8＝O<SOH>9＝12<SOH>35＝EB<SOH>34＝536<SOH>49＝A<SOH>52＝20151014-05:48:49.771<SOH>56＝A<SOH>，为基于FIX构建的报文头；<SOH>10＝7，为基于FIX协议构建的报文尾；标签6529在FIX协议中表示用于区分业务的消息标识(即业务标识)。

当交易系统接收到上述柜台系统发送的响应报文后，可以解析该响应报文中的子报文体所承载的查询结果，并在接收到上述结束报文后，将该查询结果提交至与上述消息标识对应的业务，然后由交易系统为基于查询结果为用户A推荐股票数据。

通过以上实施例可知，在本例中通过对FIX协议进行扩展：

第一方面，实现了在查询金融账户数据时，可以通过在封装后的查询报文中携带查询类型标签，指定柜台系统返回所选定的目标数据分组的信息，从而使得数据的查询更加灵活。

第二方面，通过对FIX协议进行扩展，在封装响应报文时，通过将与用户选定的目标数据分组中所包含的若干目标属性的数据分别承载在不同的子报文体中，可以利用不同的子报文体来组织各种目标属性的数据，通过子报文来实现目标属性的隔离，使得某一个目标属性的标签发生了变化，或者新增了属性时，可以通过扩展子报文体，快速的适应数据的变化，而不需要针对属性对应的标签进行单独修改，从而使得报文的可扩展性更好。而且，通过扩展子报文体，可以对查询结果中所包含的各属性的数据，重新进行组织并进一步进行归类，将查询结果中所包含的各目标属性，以及为该目标属性定义的关联属性封装在同一个子报文体中，从而使得响应报文中所承载的各目标属性对应的数据将更加易于解析和提取。

第三方面，由于在对FIX协议进行扩展时，封装的报文头以及报文尾的仍然遵循FIX协议标准，从而基于扩展后的FIX协议封装出的查询报文，能够兼容现有的FIX协议，使得基于FIX协议现有的FIX报文处理引擎仍然能够正常处理扩展后的报文，因此在执行数据查询时，仍然可以很好利用金融机构之间原有的通信链路，而不需要基于扩展后的FIX报文重新创建新的通信链路。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图5，本申请提出一种数据的查询装置50，应用于查询端；其中，请参见图6，作为承载所述目标数据的查询装置50的查询端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述目标数据的查询装置50通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置50包括：

第一接收模块501，用于接收查询端发送的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

查询模块502，用于查询所述查询数据所指示的所述目标数据分组对应的数据，

构建模块503，用于基于查询到的所述数据构建响应报文；其中，所述响应报文包含至少一个子报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中；

第一发送模块504，用于将构建完成的响应报文发送至所述查询端。

在本例中，所述子报文体包括主标签、子标签、取值标签以及自定义标签中的一个或者多个；

其中，所述主标签，用于指示所述子报文体对应的属性；

所述取值标签，用于指示与所述属性对应的取值；

在本例中，当所述属性不包含子属性时，所述子报文体包括主标签、取值标签以及至少一个自定义标签；

在本例中，所述构建模块503进一步用于：

在本例中，所述目标数据为金融账户数据。

请参见图7，本申请提出另一种数据的查询装置70，应用于查询响应端；其中，请参见图8，作为承载所述目标数据的查询装置70的查询响应端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述目标数据的查询装置70通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置70包括：

第二发送模块701，用于向查询响应端发送针对所述目标数据的查询报文；所述查询报文携带查询数据；所述查询数据指示目标数据中的一个或者多个目标数据分组；所述目标数据被预先划分为若干数据分组，每一数据分组包含若干属性的数据；

第二接收模块702，用于接收查询响应端发送的响应报文；其中，所述响应报文中包含至少一个报文体；与所述目标数据分组中所包含的属性对应的数据分别承载在不同的子报文体中。

在本例中，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识；

所述第二接收模块702进一步用于：

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种数据的查询方法，其特征在于，该方法包括：

查询所述查询数据所指示的所述目标数据分组对应的数据，

将构建完成的响应报文发送至所述查询端。

2.根据权利要求1所述的方法，其特征在于，所述子报文体包括主标签、子标签、取值标签以及自定义标签中的一个或者多个；

其中，所述主标签，用于指示所述子报文体对应的属性；

所述取值标签，用于指示与所述属性对应的取值；

3.根据权利要求2所述的方法，其特征在于，

当所述属性不包含子属性时，所述子报文体包括主标签、取值标签以及至少一个自定义标签；

4.根据权利要求1所述的方法，其特征在于，所述基于查询到的所述数据构建响应报文包括：

5.根据权利要求4所述的方法，其特征在于，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识。

6.根据权利要求1所述的方法，其特征在于，所述目标数据为金融账户数据。

7.一种数据的查询方法，其特征在于，该方法包括：

8.根据权利要求7所述的方法，其特征在于，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识；

所述方法还包括：

9.一种数据的查询装置，其特征在于，该装置包括：

10.根据权利要求9所述的装置，其特征在于，所述子报文体包括主标签、子标签、取值标签以及自定义标签中的一个或者多个；

其中，所述主标签，用于指示所述子报文体对应的属性；

所述取值标签，用于指示与所述属性对应的取值；

11.根据权利要求10所述的装置，其特征在于，

12.根据权利要求11所述的装置，其特征在于，所述构建模块进一步用于：

13.根据权利要求11所述的装置，其特征在于，所述目标数据为金融账户数据。

14.一种数据的查询装置，其特征在于，该装置包括：

15.根据权利要求14所述的装置，其特征在于，所述响应报文、所述查询报文以及所述结束报文兼容FIX协议报文结构；所述响应报文、所述查询报文以及所述结束报文携带相同的业务标识；

所述第二接收模块进一步用于：

16.一种目标数据的查询系统，其特征在于，该系统包括：

查询端，以及与所述查询端对接的至少一个查询响应端；