本发明涉及互联网技术，尤其涉及一种信息处理方法及接入处理装置。
背景技术：
：：大数据时代，不同数据之间的融合是非常重要的，而不同数据的类型和结构都可能不同，需要对不同数据进行处理，解决数据间的差异性而使其符合整个业务流程的需求。以互联网金融业务为例，一个可对接多家金融机构的理财平台，如该平台在接收用户的业务申请后，去多家金融机构中的一家金融机构处理该业务，由于平台和金融机构之间这二者间在数据类型、结构、接口等都各有不同，需要对申请数据和反馈数据在平台侧进行处理，这个处理成本非常繁琐和复杂，因为，每增加一条新的数据，平台都需要重新针对这个数据对处理逻辑进行修改，处理效率低下，处理成本也偏高。另，申请数据和反馈数据在处理的过程中容易出现实际数据与预期不符合的问题，比如数据不具备完整性、数据不致性等，然而，相关技术中，对于该问题，尚无有效解决方案，目前迫切需要一种能提高处理效率、降低处理成本和降低数据处理错误概率的信息处理方案。技术实现要素：有鉴于此，本发明实施例提供了一种信息处理方法及接入处理装置，至少解决了现有技术存在的问题。本发明实施例的技术方案是这样实现的：本发明实施例的一种信息处理方法，所述方法包括：获取发送端的业务申请数据；根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端；获取接收端的业务反馈数据；根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端；根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。上述方案中，根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，包括：根据所述业务申请数据查询到对应的第一业务标识，所述第一业务标识为预先配置于发送端和接收端的标识；根据所述第一业务标识加载对应的配置项参数，将所述配置项参数确定为所述第一配置参数；根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据。上述方案中，根据所述配置项参数对所述业务申请数据进行转换处理，包括：所述配置项参数包括至少一个接口格式定义数据；根据所述业务申请数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，对通过合法性验证的业务申请数据进行所述接口适配的转换。上述方案中，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，包括：根据所述第一接口格式定义数据对所述业务申请数据的文件头和数据体进行解析，以检查数据合法性；当未通过合法性验证时，将数据不合法的原因信息返回给发送端。上述方案中，根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端，包括：根据所述业务反馈数据查询到对应的第二业务标识，所述第二业务标识为预先配置于发送端和接收端的标识；根据所述第二业务标识加载对应的配置项参数，将所述配置项参数确定为所述第二配置参数；根据所述配置项参数对所述业务反馈数据进行转换处理，得到符合发送端业务接口需求的反馈数据。上述方案中，根据所述配置项参数对所述业务反馈数据进行转换处理，包括：所述配置项参数包括至少一个接口格式定义数据；根据所述业务反馈数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务反馈数据进行所述接口适配的转换，得到所述反馈数据，将所述配置项参数和所述反馈数据提供给发送端进行数据合法性验证。上述方案中，根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息，包括：加载所述反馈数据；加载所述申请数据；从所述预设策略中提取用于数据校验和对账的第一策略；根据所述第一策略判断所述反馈数据和所述申请数据在数据完整性和数据正确性上是否保持一致，如果不一致，则将根据数据校验结果及失败原因生成的所述失败信息封装到回退处理请求中，发送所述回退处理请求给接收端。上述方案中，所述方法还包括：当所述申请数据和所述反馈数据在处理过程中出现实际数据与预期不符合的偏差情况时，从所述预设策略中提取用于增强或增减偏差调整的第二策略；根据所述第二策略生成偏差调整量，将所述偏差调整量封装到回退处理请求中；获取出现偏差情况的发送端对应的第三业务标识，将所述回退处理请求发送给与所述第三业务标识对应的发送端。本发明实施例的一种接入处理装置，所述装置包括：第一获取单元，用于获取发送端的业务申请数据；第一适配单元，用于根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端；第二获取单元，用于获取接收端的业务反馈数据；第二适配单元，用于根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端；验证单元，用于根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。上述方案中，所述第一适配单元，进一步用于：根据所述业务申请数据查询到对应的第一业务标识，所述第一业务标识为预先配置于发送端和接收端的标识；根据所述第一业务标识加载对应的配置项参数，将所述配置项参数确定为所述第一配置参数；根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据。上述方案中，所述第一适配单元，进一步用于：所述配置项参数包括至少一个接口格式定义数据；根据所述业务申请数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，对通过合法性验证的业务申请数据进行所述接口适配的转换。上述方案中，所述第一适配单元，进一步用于：根据所述第一接口格式定义数据对所述业务申请数据的文件头和数据体进行解析，以检查数据合法性；当未通过合法性验证时，将数据不合法的原因信息返回给发送端。上述方案中，所述第二适配单元，进一步用于：根据所述业务反馈数据查询到对应的第二业务标识，所述第二业务标识为预先配置于发送端和接收端的标识；根据所述第二业务标识加载对应的配置项参数，将所述配置项参数确定为所述第二配置参数；根据所述配置项参数对所述业务反馈数据进行转换处理，得到符合发送端业务接口需求的反馈数据。上述方案中，所述第二适配单元，进一步用于：所述配置项参数包括至少一个接口格式定义数据；根据所述业务反馈数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务反馈数据进行所述接口适配的转换，得到所述反馈数据，将所述配置项参数和所述反馈数据提供给发送端进行数据合法性验证。上述方案中，所述验证单元，进一步用于：加载所述反馈数据；加载所述申请数据；从所述预设策略中提取用于数据校验和对账的第一策略；根据所述第一策略判断所述反馈数据和所述申请数据在数据完整性和数据正确性上是否保持一致，如果不一致，则将根据数据校验结果及失败原因生成的所述失败信息封装到回退处理请求中，发送所述回退处理请求给接收端。上述方案中，所述装置还包括：偏差调整单元，用于：当所述申请数据和所述反馈数据在处理过程中出现实际数据与预期不符合的偏差情况时，从所述预设策略中提取用于增强或增减偏差调整的第二策略；根据所述第二策略生成偏差调整量，将所述偏差调整量封装到回退处理请求中；获取出现偏差情况的发送端对应的第三业务标识，将所述回退处理请求发送给与所述第三业务标识对应的发送端。本发明实施例的信息处理方法包括：获取发送端的业务申请数据；根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端；获取接收端的业务反馈数据；根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端；根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。采用本发明实施例，对申请数据和反馈数据在接入处理装置侧进行接口适配的转换处理后再提供给平台和金融机构，不需要每增加一条新的数据就重新修改处理逻辑，因此，处理成本低，处理效率高。另，通过在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息，可以避免申请数据和反馈数据在处理的过程中出现的实际数据与预期不符合的问题，降低数据处理错误概率。附图说明图1为本发明实施例中进行信息交互的各方硬件实体的示意图；图2为本发明实施例一的处理流程示意图；图3为本发明实施例二的处理流程示意图；图4为本发明实施例二中转换处理一实际应用的处理流程示意图；图5为本发明实施例三的处理流程示意图；图6为本发明实施例四的处理流程示意图；图7为本发明实施例五的系统组成结构示意图；图8为现有互联网理财平台的基金产品接入示意图；图9为应用本发明实施例的互联网理财平台、接入处理装置和基金公司组成的框架示意图；图10为应用本发明实施例的接入处理装置对申请接口的处理逻辑示意图；图11为应用本发明实施例的接入处理装置与申请数据接口的交互逻辑示意图；图12为应用本发明实施例的申购申请接口的标准格式定义示意图；图13为应用本发明实施例的接入处理装置对确认接口的处理逻辑示意图；图14为应用本发明实施例的接入处理装置与确认数据接口的交互逻辑示意图；图15为应用本发明实施例的申购确认接口的标准格式定义示意图；图16为应用本发明实施例的接入处理装置在把数据处理成标准数据之后需要之前的申请数据进行校验和核对的处理逻辑示意图；图17为应用本发明实施例的接入处理装置份额数据强增强减处理逻辑示意图；图18为应用本发明实施例的接入处理装置强增强减标准接口的数据格式定义示意图。具体实施方式下面结合附图对技术方案的实施作进一步的详细描述。现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明实施例的说明，其本身并没有特定的意义。因此，″模块″与″部件″可以混合地使用。在下面的详细说明中，陈述了众多的具体细节，以便彻底理解本发明。不过，对于本领域的普通技术人员来说，显然可在没有这些具体细节的情况下实践本发明。在其他情况下，没有详细说明公开的公知方法、过程、组件、电路和网络，以避免不必要地使实施例的各个方面模糊不清。另外，本文中尽管多次采用术语“第一”、“第二”等来描述各种元件(或各种阈值或各种应用或各种指令或各种操作)等，不过这些元件(或阈值或应用或指令或操作)不应受这些术语的限制。这些术语只是用于区分一个元件(或阈值或应用或指令或操作)和另一个元件(或阈值或应用或指令或操作)。例如，第一操作可以被称为第二操作，第二操作也可以被称为第一操作，而不脱离本发明的范围，第一操作和第二操作都是操作，只是二者并不是相同的操作而已。本发明实施例中的步骤并不一定是按照所描述的步骤顺序进行处理，可以按照需求有选择的将步骤打乱重排，或者删除实施例中的步骤，或者增加实施例中的步骤，本发明实施例中的步骤描述只是可选的顺序组合，并不代表本发明实施例的所有步骤顺序组合，实施例中的步骤顺序不能认为是对本发明的限制。本发明实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的任何和全部的可能组合。还要说明的是：当用在本说明书中时，“包括/包含”指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在，但是不排除一个或多个其他特征、整数、步骤、操作、元件和/或组件和/或它们的组群的存在或添加。本发明实施例的智能终端(如移动终端)可以以各种形式来实施。例如，本发明实施例中描述的移动终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、个人数字助理(pda，personaldigitalassistant)、平板电脑(pad)、便携式多媒体播放器(pmp，portablemediaplayer)、导航装置等等的移动终端以及诸如数字tv、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。图1为本发明实施例中进行信息交互的各方硬件实体的示意图，图1中包括：接入处理装置11、终端设备21-24、平台31和金融机构41，终端设备21-24通过有线网络或者无线网络与服务器进行信息交互，终端设备包括手机、台式机、pc机、一体机等类型。接入处理装置11、平台31和金融机构41在图1中只是示例用一个服务器表述，在实际应用中，接入处理装置11、平台31和金融机构41可以是多个服务器及其配套装置构成的集群系统，采用本发明实施例，终端设备21-24通过有线网络或者无线网络与平台31进行信息交互，提出业务申请，并接收经平台31、接入处理装置11和金融机构41协同处理得到的业务反馈。其中，平台接受终端设备的业务申请，将其提交给接入处理装置进行接口适配后，以适应金融机构的数据格式，经接口适配后的业务申请提交给金融机构进行业务受理，金融机构受理业务申请，得到业务反馈，将其提交给接入处理装置进行接口适配后，以适应平台的数据格式，经接口适配后的业务反馈提交给平台，最终将业务反馈提交给终端设备，终端设备完成业务申请和受理的过程，得到预期的业务反馈。就接入处理装置而言，其处理逻辑10包括：s1、获取平台端的业务申请数据，根据第一配置参数对所述业务申请数据进行接口适配，得到符合金融机构业务接口需求的申请数据；s2、发送所述申请数据；s3、获取金融机构的业务反馈数据，根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据；s4、发送所述反馈数据；s5、根据预设策略在申请数据和反馈数据间进行数据交互验证；s6、将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。上述图1的例子只是实现本发明实施例的一个系统架构实例，本发明实施例并不限于上述图1所述的系统结构，基于图1所述的系统架构，提出本发明方法各个实施例。实施例一：本发明实施例的一种信息处理方法，如图2所示，所述方法包括：步骤101、获取发送端的业务申请数据。这里，发送端在实际应用中可以是托管金融业务的平台(如，互联网理财平台)，该平台可以接入多个终端设备，并接受多个终端设备的业务申请。步骤102、根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。这里，第一配置参数只是一个方便表达的表述，指针对业务申请数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。其中，对于接口适配而言，平台(如互联网理财平台)需要向金融机构(如基金公司)提交申请数据的接口主要包括开户申请接口、申购申请接口、赎回申请接口。步骤103、获取接收端的业务反馈数据。这里，接收端在实际应用中可以是金融机构，可以接入多个金融机构(如中国银行和工商银行等要银行类、股票证券等公司或基金公司等，可以为终端设备提供各种不同类型的金融业务)。步骤104、根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。这里，第二配置参数只是一个方便表达的表述，指针对业务反馈数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。步骤105、根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。这里，根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，至少要保证数据交互的完整性和正确性。针对正确性的保证而言，由于接入处理装置会处理平台(如互联网理财平台)和金融机构(如基金公司)之间的交互数据，因此接入处理装置必须要保证提供给平台(如互联网理财平台)和金融机构(如基金公司)的数据都是正确的。主要靠以下两种策略来保证：1)数据校验和对账逻辑；2)份额强增强减逻辑。采用本发明实施例，通过接入处理装置对平台(如互联网理财平台)和金融机构(如基金公司)间的接口差异等进行适配。如，以基金公司为例，需要)适配不同基金公司的对外接口差异。目前，基金/保险公司的对外接口主要分为两类：一类是互联网理财平台向基金公司提交申请数据的接口；一类是基金公司向互联网理财平台反馈确认数据的接口。通过接入处理装置(一个具体实现形式可以为中间件的形式)来适配申请数据接口和确认数据接口(或称反馈数据接口)的差异，通过接入处理装置的接口适配，可以向各个互联网理财平台提供标准的申请数据接口和确认数据接口。该接入处理装置可复用且独立于互联网理财平台和基金公司，实现屏蔽和适配不同基金产品的对外接口差异。可通过包括第一配置参数和第二配置参数的配置项参数的配置的方式来灵活地适配不同基金产品的业务逻辑差异，无需针对每更新的数据来修改处理逻辑，并向多个互联网理财平台提供标准的接口服务；在申请数据和反馈数据间的校验核对，可以保证数据在处理和传输过程中的准确性和完整性，从而大幅提供互联网理财平台的新产品接入效率，降低互联网理财平台的系统开发和维护成本。本实施例中的发送端和接收端的位置可以互相调换，这里，只是用于说明方便定义的称谓。实施例二：本发明实施例的一种信息处理方法，如图3所示，所述方法包括：步骤201、获取发送端的业务申请数据。这里，发送端在实际应用中可以是托管金融业务的平台(如，互联网理财平台)，该平台可以接入多个终端设备，并接受多个终端设备的业务申请。这里，所述业务申请数据的业务类型至少包括：开户申请、申购申请、赎回申请中的至少一种，所述业务申请数据，根据业务类型分别对应开户申请接口、申购申请接口、赎回申请接口进行所述接口适配。也就是说，不同的申请接口只能处理对应的申请数据文件，例如申购申请接口只能处理申购申请数据文件。这里，业务申请数据的传输方式可以采用以下两种方案：1)接入处理装置从平台(如互联网理财平台)的系统中主动下载业务申请数据；2)平台(如互联网理财平台)主动把业务申请数据上传到接入处理装置的系统中。在实际应用中，业务申请数据可以周期性的批量发送。针对理财产品t日的业务申请数据，基金公司会在t+1日进行确认并返回确认数据，由于在理财业务中对数据传输的实时性要求不高，互联网理财平台可以使用文件方式一次性地传输业务申请数据，这样还可以减轻对接入处理装置接口的并发请求压力。互联网理财平台t日的业务申请数据传输时间一般为t+1日开始的2-3个小时内，为接入处理装置服务和基金公司保证足够的数据处理时间。所谓t日，一个示例为：某上海交易所对外公布的交易日，不包括周末以及国家所有法定假日。步骤202、根据所述业务申请数据查询到对应的第一业务标识，所述第一业务标识为预先配置并存储于发送端和接收端的标识。这里，所述第一业务标识的一种实现方式为：通过在发送端和接收端之间建立的通信协议接口进行协商时得到。这里，第一业务标识的一个示例为：商户号。所述商户号为互联网理财服务平台和理财/保险公司之间商定的某款理财产品的产品标识，比如，买中国银行的基金业务，对应的标识就是中国银行某基金业务的基金号。步骤203、根据所述第一业务标识加载对应的配置项参数，将所述配置项参数确定为所述第一配置参数。步骤204、根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据。这里，通过上述步骤202-204，能根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。一个示例为：业务申请数据中携带商户号，则接入处理装置获取互联网理财平台提交的业务申请数据后，加载基金产品的配置项数据，并根据具体的配置项参数对互联网理财平台提交的申请数据进行转换处理，生成符合基金公司要求的数据，并把处理后的数据发送给对应的基金公司，以适配对应基金公司的接口差异。这里，第一配置参数只是一个方便表达的表述，指针对业务申请数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。其中，对于接口适配而言，平台(如互联网理财平台)需要向金融机构(如基金公司)提交申请数据的接口主要包括开户申请接口、申购申请接口、赎回申请接口。这里，根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据，如图4所示，包括：步骤2041、所述配置项参数包括至少一个接口格式定义数据。步骤2042、根据所述业务申请数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换。这里，所述业务申请数据的不同业务类型对应不同的接口格式定义数据，比如，申购申请，对应申购申请接口格式定义数据。步骤2043、加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，对通过合法性验证的业务申请数据进行所述接口适配的转换。这里，在一个实际应用中，根据所述第一接口格式定义数据对所述业务申请数据的文件头和数据体进行解析，以检查数据合法性，当未通过合法性验证时，将数据不合法的原因信息返回给发送端。步骤205、获取接收端的业务反馈数据。这里，接收端在实际应用中可以是金融机构，可以接入多个金融机构(如中国银行和工商银行等要银行类、股票证券等公司或基金公司等，可以为终端设备提供各种不同类型的金融业务)。步骤206、根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。这里，第二配置参数只是一个方便表达的表述，指针对业务反馈数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。步骤207、根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。这里，根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，至少要保证数据交互的完整性和正确性。针对正确性的保证而言，由于接入处理装置会处理平台(如互联网理财平台)和金融机构(如基金公司)之间的交互数据，因此接入处理装置必须要保证提供给平台(如互联网理财平台)和金融机构(如基金公司)的数据都是正确的。主要靠以下两种策略来保证：1)数据校验和对账逻辑；2)份额强增强减逻辑。采用本发明实施例，通过接入处理装置对平台(如互联网理财平台)和金融机构(如基金公司)间的接口差异等进行适配。如，以基金公司为例，需要)适配不同基金公司的对外接口差异。目前，基金/保险公司的对外接口主要分为两类：一类是互联网理财平台向基金公司提交申请数据的接口；一类是基金公司向互联网理财平台反馈确认数据的接口。通过接入处理装置(一个具体实现形式可以为接入处理装置(如理财中间件)的形式)来适配申请数据接口和确认数据接口(或称反馈数据接口)的差异，通过接入处理装置的接口适配，可以向各个互联网理财平台提供标准的申请数据接口和确认数据接口。该接入处理装置可复用且独立于互联网理财平台和基金公司，实现屏蔽和适配不同基金产品的对外接口差异。可通过包括第一配置参数和第二配置参数的配置项参数的配置的方式来灵活地适配不同基金产品的业务逻辑差异，无需针对每更新的数据来修改处理逻辑，并向多个互联网理财平台提供标准的接口服务；在申请数据和反馈数据间的校验核对，可以保证数据在处理和传输过程中的准确性和完整性，从而大幅提供互联网理财平台的新产品接入效率，降低互联网理财平台的系统开发和维护成本。本实施例中的发送端和接收端的位置可以互相调换，这里，只是用于说明方便定义的称谓。实施例三：本发明实施例的一种信息处理方法，如图5所示，所述方法包括：步骤301、获取发送端的业务申请数据。这里，发送端在实际应用中可以是托管金融业务的平台(如，互联网理财平台)，该平台可以接入多个终端设备，并接受多个终端设备的业务申请。这里，所述业务申请数据的业务类型至少包括：开户申请、申购申请、赎回申请中的至少一种，所述业务申请数据，根据业务类型分别对应开户申请接口、申购申请接口、赎回申请接口进行所述接口适配。也就是说，不同的申请接口只能处理对应的申请数据文件，例如申购申请接口只能处理申购申请数据文件。这里，业务申请数据的传输方式可以采用以下两种方案：1)接入处理装置从平台(如互联网理财平台)的系统中主动下载业务申请数据；2)平台(如互联网理财平台)主动把业务申请数据上传到接入处理装置的系统中。在实际应用中，业务申请数据可以周期性的批量发送。针对理财产品t日的业务申请数据，基金公司会在t+1日进行确认并返回确认数据，由于在理财业务中对数据传输的实时性要求不高，互联网理财平台可以使用文件方式一次性地传输业务申请数据，这样还可以减轻对接入处理装置接口的并发请求压力。互联网理财平台t日的业务申请数据传输时间一般为t+1日开始的2-3个小时内，为接入处理装置服务和基金公司保证足够的数据处理时间。所谓t日，一个示例为：某上海交易所对外公布的交易日，不包括周末以及国家所有法定假日。步骤302、根据所述业务申请数据查询到对应的第一业务标识，所述第一业务标识为预先配置并存储于发送端和接收端的标识。这里，所述第一业务标识的一种实现方式为：通过在发送端和接收端之间建立的通信协议接口进行协商时得到。这里，第一业务标识的一个示例为：商户号。所述商户号为互联网理财服务平台和理财/保险公司之间商定的某款理财产品的产品标识，比如，买中国银行的基金业务，对应的标识就是中国银行某基金业务的基金号。步骤303、根据所述第一业务标识加载对应的配置项参数，将所述配置项参数确定为所述第一配置参数。步骤304、根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据。这里，通过上述步骤302-304，能根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。一个示例为：业务申请数据中携带商户号，则接入处理装置获取互联网理财平台提交的业务申请数据后，加载基金产品的配置项数据，并根据具体的配置项参数对互联网理财平台提交的申请数据进行转换处理，生成符合基金公司要求的数据，并把处理后的数据发送给对应的基金公司，以适配对应基金公司的接口差异。这里，第一配置参数只是一个方便表达的表述，指针对业务申请数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。其中，对于接口适配而言，平台(如互联网理财平台)需要向金融机构(如基金公司)提交申请数据的接口主要包括开户申请接口、申购申请接口、赎回申请接口。这里，根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据，包括：所述配置项参数包括至少一个接口格式定义数据；根据所述业务申请数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换，所述业务申请数据的不同业务类型对应不同的接口格式定义数据，比如，申购申请，对应申购申请接口格式定义数据；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，对通过合法性验证的业务申请数据进行所述接口适配的转换。这里，在一个实际应用中，根据所述第一接口格式定义数据对所述业务申请数据的文件头和数据体进行解析，以检查数据合法性，当未通过合法性验证时，将数据不合法的原因信息返回给发送端。步骤305、获取接收端的业务反馈数据。这里，所述业务反馈数据的业务类型至少包括：开户确认、交易确认、收益对账、强增强减中的至少一种。所述业务反馈数据，根据业务类型分别对应开户确认接口、交易确认接口、收益对账接口、强增强减接口进行所述接口适配。也就是说，不同的反馈接口只能处理对应的反馈数据文件，例如开户确认接口只能处理开户确认数据文件。这里，接收端在实际应用中可以是金融机构，可以接入多个金融机构(如中国银行和工商银行等要银行类、股票证券等公司或基金公司等，可以为终端设备提供各种不同类型的金融业务)。步骤306、根据所述业务反馈数据查询到对应的第二业务标识，所述第二业务标识为预先配置并存储于发送端和接收端的标识。这里，所述第二业务标识的一种实现方式为：通过在发送端和接收端之间建立的通信协议接口进行协商时得到。这里，第二业务标识的一个示例为：商户号。所述商户号为互联网理财服务平台和理财/保险公司之间商定的某款理财产品的产品标识，比如，买中国银行的基金业务，对应的标识就是中国银行某基金业务的基金号。本实施例中的第一业务标识和第二业务标识在同一个数据交互流程中是相同的标识。步骤307、根据所述第二业务标识加载对应的配置项参数，将所述配置项参数确定为所述第二配置参数。步骤308、根据所述配置项参数对所述业务反馈数据进行转换处理，得到符合发送端业务接口需求的反馈数据。通过上述步骤306-308，能根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。一个示例为：业务反馈数据中携带商户号，则接入处理装置获取基金公司提交的业务反馈数据后，加载互联网理财平台的配置项数据，并根据具体的配置项参数对基金公司提交的反馈数据进行转换处理，生成符合互联网理财平台对应接口要求的数据，并把处理后的数据发送给互联网理财平台的对应接口，以适配对应互联网理财平台对应接口的接口差异。这里，第二配置参数只是一个方便表达的表述，指针对业务反馈数据进行接口适配的配置参数，具体可以为配置项参数，配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端。这里，根据所述配置项参数对所述业务反馈数据进行转换处理，得到符合发送端业务接口需求的反馈数据，包括：所述配置项参数包括至少一个接口格式定义数据；根据所述业务反馈数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换，确认数据接口(或称反馈数据接口)主要是生成并传输标准确认数据(文件)到互联网理财平台，其中不同的确认接口只能处理对应的确认数据文件；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务反馈数据进行所述接口适配的转换，得到所述反馈数据，将所述配置项参数和所述反馈数据提供给发送端进行数据合法性验证。在实际应用中，基金公司会在t+1日对互联网理财平台t日的申请数据进行确认并把确认数据文件返回给接入处理装置，接入处理装置对初始的确认数据按照之前与互联网理财平台约定的规则进行处理后，再把通过确认接口把确认数据返回给互联网理财平台，在接入处理装置和互联网理财平台间直接、确认数据文件的传输方式可以采用以下两种方案：1)互联网理财平台从接入处理装置(如理财中间件)服务的系统中主动下载确认数据文件；2)接入处理装置的系统主动把确认文件上传到互联网理财平台中。而互联网理财平台在处理确认文件时需要加载接入处理装置(如理财中间件)的接口格式定义数据，然后据此解析确认数据文件的文件头和数据体部分。具体的，可以根据文件名判断文件类型，根据文件类型加载接口格式定义，根据确认接口定义解析文件头，根据确认接口定义解析文件数据体，检查文件数据合法性，返回文件数据不合法原因信息给接入处理装置。步骤309、根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。这里，根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，至少要保证数据交互的完整性和正确性。针对正确性的保证而言，由于接入处理装置会处理平台(如互联网理财平台)和金融机构(如基金公司)之间的交互数据，因此接入处理装置必须要保证提供给平台(如互联网理财平台)和金融机构(如基金公司)的数据都是正确的。主要靠以下两种策略来保证：1)数据校验和对账逻辑；2)份额强增强减逻辑。采用本发明实施例，通过接入处理装置对平台(如互联网理财平台)和金融机构(如基金公司)间的接口差异等进行适配。如，以基金公司为例，需要)适配不同基金公司的对外接口差异。目前，基金/保险公司的对外接口主要分为两类：一类是互联网理财平台向基金公司提交申请数据的接口；一类是基金公司向互联网理财平台反馈确认数据的接口。通过接入处理装置(一个具体实现形式可以为中间件的形式)来适配申请数据接口和确认数据接口(或称反馈数据接口)的差异，通过接入处理装置的接口适配，可以向各个互联网理财平台提供标准的申请数据接口和确认数据接口。该接入处理装置可复用且独立于互联网理财平台和基金公司，实现屏蔽和适配不同基金产品的对外接口差异。可通过包括第一配置参数和第二配置参数的配置项参数的配置的方式来灵活地适配不同基金产品的业务逻辑差异，无需针对每更新的数据来修改处理逻辑，并向多个互联网理财平台提供标准的接口服务；在申请数据和反馈数据间的校验核对，可以保证数据在处理和传输过程中的准确性和完整性，从而大幅提供互联网理财平台的新产品接入效率，降低互联网理财平台的系统开发和维护成本。综上这几个实施例的描述，可以得出，采用本发明实施例，当平台(如互联网理财平台)选择接入处理装置(如理财中间件)来接入新的理财产品时，就不需要为了适配金融机构(如基金公司)的接口差异而进行系统维护和开发工作，因为这部分工作已经移交到接入处理装置(如理财中间件)的服务中，从而大幅提高了整个信息交互流程的处理效率，以基金产品为例，则是提高了互联网理财平台接入新基金的效率。同时，由于接入处理装置(如理财中间件)会保证提供给平台(如互联网理财平台)的数据是完整和准确的，因此，平台(如互联网理财平台)就不需要在系统内部对金融机构(如基金公司)的确认数据进行核对和校验，这样可以在很大程度上减轻平台(如互联网理财平台)内部系统业务逻辑的复杂性，使系统更新便于维护。本实施例中的发送端和接收端的位置可以互相调换，这里，只是用于说明方便定义的称谓。实施例四：本发明实施例的一种信息处理方法，上述实施例中，通过接入处理装置处理互联网理财平台和基金公司之间的交互数据，需要确保通过接入处理装置处理后提供给互联网理财平台和基金公司的数据都是正确的，因此，需要根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息，其具体处理过程，如图6所示，包括：步骤401、加载所述反馈数据。步骤402、加载所述申请数据。步骤403、从所述预设策略中提取用于数据校验和对账的第一策略。根据所述第一策略判断所述反馈数据和所述申请数据在数据完整性和数据正确性上是否保持一致，如果不一致，则将根据数据校验结果及失败原因生成的所述失败信息封装到回退处理请求中，发送所述回退处理请求给接收端。这里，对于基金公司提供给互联网理财平台的确认数据(或称反馈数据)，接入处理装置在把数据处理成标准数据之后需要之前的申请数据进行校验和核对。具体的，加载请求数据，加载处理后的确认数据，校验确认数据完整性，校验确认数据正确性，如果校验失败，则中间件返回数据校验结果及失败原因给基金公司，如果校验成功，则返回该商户号的确认数据给互联网理财平台。这里，采用本发明实施例的第一策略进行数据校验和核对，可以对处理后的确认数据(或称反馈数据)与互联网理财平台提供的申请数据进行检查，主要包括双方数据一致性、确认数据正确性等方面的检查，以保证返回给互联网理财平台的确认数据是可靠的。这里，步骤403后还可以包括如下步骤：步骤404、当所述申请数据和所述反馈数据在处理过程中出现实际数据与预期不符合的偏差情况时，从所述预设策略中提取用于增强或增减偏差调整的第二策略。这里，比如，当由于基金公司系统或接入处理装置自身系统的原因导致数据校验和核对逻辑检查后的确认数据(主要是用户的收益和份额数据)出现偏差时，接入处理装置需要采用强增强减接口来为互联网理财平台提供一种数据校正的功能，通过接入处理装置的第二策略如强增强减逻辑，互联网理财平台可以及时地调整每个商户号的异常份额数据。具体的，接入处理装置接收基金公司发送的份额数据调整请求，请求中携带商户号，检查基金公司请求数据，汇总每个商户号的强加强减数据，生成标准的强加强减数据，接入处理装置返回强加强减数据给互联网理财平台，由互联网理财平台来校验份额强加强减数据，如果校验失败，则互联网理财平台返回错误信息给接入处理装置，如果校验成功，则互联网理财平台校正用户份额等反馈数据。其中，第二策略的一个示例“强增强减逻辑”，其接口格式定义中的操作类型包括2种：1)强增份额；2)强减份额。由于份额强增强减操作是一项十分敏感的操作，直接影响理财用户的持有份额数据，因此互联网理财平台在操作前也需要进行数据核对。步骤405、根据所述第二策略生成偏差调整量，将所述偏差调整量封装到回退处理请求中。步骤406、获取出现偏差情况的发送端对应的第三业务标识，将所述回退处理请求发送给与所述第三业务标识对应的发送端。这里，针对第三业务标识而言，一个示例可以是商户号，商户号为互联网理财服务平台和理财/保险公司之间商定的某款理财产品的产品标识，比如，买中国银行的基金业务，对应的标识就是中国银行某基金业务的基金号。这里，数据不是全部回退，是针对性的回退，即只针对出现偏差的发送端进行回退，比如，有11个发送端发送了请求，但是在校验中发现有2个发送端的实际数据与预期不符合而导致出现偏差的情况，那么，采用本发明实施例，可以只对这2个发送端进行数据回退，并让这2个终端根据数据回退中的偏差调整量自行检验和核对，看看这个偏差量是否正确，如果正确，就针对这个偏差量调整后重新发出请求。实施例五：本发明实施例的一种信息处理系统，其中，该系统包括平台51，接入处理装置52及金融机构53，如图7所示，平台51用于发出业务申请，提交业务申请数据，金融机构53用于受理业务申请，返回对于业务申请的确认数据(或称反馈数据)，而接入处理装置52用于对业务申请数据和确认数据(或称反馈数据)进行相应的接口适配，以避免接口差异性导致的问题。接入处理装置52包括：第一获取单元521，用于获取发送端的业务申请数据；第一适配单元522，用于根据第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端；第二获取单元523，用于获取接收端的业务反馈数据；第二适配单元524，用于根据第二配置参数对所述业务反馈数据进行接口适配，得到符合发送端业务接口需求的反馈数据，将所述反馈数据转发给发送端；验证单元525，用于根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，将交互验证失败的数据进行回退处理，并在生成的回退处理请求中携带失败信息。这里，发送端在实际应用中可以是托管金融业务的平台(如，互联网理财平台)，该平台可以接入多个终端设备，并接受多个终端设备的业务申请。相应的，接收端在实际应用中可以是金融机构，可以接入多个金融机构(如中国银行和工商银行等要银行类、股票证券等公司或基金公司等，可以为终端设备提供各种不同类型的金融业务)。第一配置参数只是一个方便表达的表述，指针对业务申请数据进行接口适配的配置参数，具体可以为配置项参数。同理，第二配置参数只是一个方便表达的表述，指针对业务反馈数据进行接口适配的配置参数，具体也可以为配置项参数。配置项参数既可以保存在数据库(db)中，也可以保存在配置文件中。将配置项参数保存在采用分布式系统的db中，db共享，适用于集群系统，只需要保存一份配置项参数，db的设置相对复杂；将配置项参数保存在配置文件中相对简单，但是参数不共享，需要在每个地方都存储一份配置项参数才行。通过第一配置参数对所述业务申请数据进行接口适配，得到符合接收端业务接口需求的申请数据，将所述申请数据转发给接收端。其中，对于接口适配而言，平台(如互联网理财平台)需要向金融机构(如基金公司)提交申请数据的接口主要包括开户申请接口、申购申请接口、赎回申请接口。根据预设策略在所述申请数据和所述反馈数据间进行数据交互验证，至少要保证数据交互的完整性和正确性。针对正确性的保证而言，由于接入处理装置会处理平台(如互联网理财平台)和金融机构(如基金公司)之间的交互数据，因此接入处理装置必须要保证提供给平台(如互联网理财平台)和金融机构(如基金公司)的数据都是正确的。主要靠以下两种策略来保证：1)数据校验和对账逻辑；2)份额强增强减逻辑。采用本发明实施例，通过接入处理装置对平台(如互联网理财平台)和金融机构(如基金公司)间的接口差异等进行适配。如，以基金公司为例，需要)适配不同基金公司的对外接口差异。目前，基金/保险公司的对外接口主要分为两类：一类是互联网理财平台向基金公司提交申请数据的接口；一类是基金公司向互联网理财平台反馈确认数据的接口。通过接入处理装置(一个具体实现形式可以为中间件的形式)来适配申请数据接口和确认数据接口(或称反馈数据接口)的差异，通过接入处理装置的接口适配，可以向各个互联网理财平台提供标准的申请数据接口和确认数据接口。该接入处理装置可复用且独立于互联网理财平台和基金公司，实现屏蔽和适配不同基金产品的对外接口差异。可通过包括第一配置参数和第二配置参数的配置项参数的配置的方式来灵活地适配不同基金产品的业务逻辑差异，无需针对每更新的数据来修改处理逻辑，并向多个互联网理财平台提供标准的接口服务；在申请数据和反馈数据间的校验核对，可以保证数据在处理和传输过程中的准确性和完整性，从而大幅提供互联网理财平台的新产品接入效率，降低互联网理财平台的系统开发和维护成本。本实施例中的发送端和接收端的位置可以互相调换，这里，只是用于说明方便定义的称谓。在本发明实施例一实施方式中，所述业务申请数据的业务类型至少包括：开户申请、申购申请、赎回申请中的至少一种。所述业务申请数据，根据业务类型分别对应开户申请接口、申购申请接口、赎回申请接口进行所述接口适配。在本发明实施例一实施方式中，所述第一适配单元，进一步用于：根据所述业务申请数据查询到对应的第一业务标识，所述第一业务标识为预先配置并存储于发送端和接收端的标识，一种实现方式为：通过在发送端和接收端之间建立的通信协议接口进行协商时得到；根据所述第一业务标识加载对应的配置项参数，将所述配置项参数确定为所述第一配置参数；根据所述配置项参数对所述业务申请数据进行转换处理，得到符合接收端业务接口需求的申请数据。在本发明实施例一实施方式中，所述第一适配单元，进一步用于：所述配置项参数包括至少一个接口格式定义数据；根据所述业务申请数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务申请数据进行数据合法性验证，对通过合法性验证的业务申请数据进行所述接口适配的转换。在本发明实施例一实施方式中，所述第一适配单元，进一步用于：根据所述第一接口格式定义数据对所述业务申请数据的文件头和数据体进行解析，以检查数据合法性；当未通过合法性验证时，将数据不合法的原因信息返回给发送端。在本发明实施例一实施方式中，所述业务反馈数据的业务类型至少包括：开户确认、交易确认、收益对账、强增强减中的至少一种。所述业务反馈数据，根据业务类型分别对应开户确认接口、交易确认接口、收益对账接口、强增强减接口进行所述接口适配。在本发明实施例一实施方式中，所述第二适配单元，进一步用于：根据所述业务反馈数据查询到对应的第二业务标识，所述第二业务标识为预先配置并存储于发送端和接收端的标识，一种实现方式为：通过在发送端和接收端之间建立的通信协议接口进行协商时得到；根据所述第二业务标识加载对应的配置项参数，将所述配置项参数确定为所述第二配置参数；根据所述配置项参数对所述业务反馈数据进行转换处理，得到符合发送端业务接口需求的反馈数据。在本发明实施例一实施方式中，所述第二适配单元，进一步用于：所述配置项参数包括至少一个接口格式定义数据；根据所述业务反馈数据的第一业务类型从所述至少一个接口格式定义数据中提取对应的第一接口格式定义数据，以用于接口适配的转换；加载所述第一接口格式定义数据，根据所述第一接口格式定义数据对所述业务反馈数据进行所述接口适配的转换，得到所述反馈数据，将所述配置项参数和所述反馈数据提供给发送端进行数据合法性验证。在本发明实施例一实施方式中，所述验证单元，进一步用于：加载所述反馈数据；加载所述申请数据；从所述预设策略中提取用于数据校验和对账的第一策略；根据所述第一策略判断所述反馈数据和所述申请数据在数据完整性和数据正确性上是否保持一致，如果不一致，则将根据数据校验结果及失败原因生成的所述失败信息封装到回退处理请求中，发送所述回退处理请求给接收端。在本发明实施例一实施方式中，所述装置还包括：偏差调整单元，用于：当所述申请数据和所述反馈数据在处理过程中出现实际数据与预期不符合的偏差情况时，从所述预设策略中提取用于增强或增减偏差调整的第二策略；根据所述第二策略生成偏差调整量，将所述偏差调整量封装到回退处理请求中；获取出现偏差情况的发送端对应的第三业务标识，将所述回退处理请求发送给与所述第三业务标识对应的发送端。其中，对于用于数据处理的处理器而言，在执行处理时，可以采用微处理器、中央处理器(cpu，centralprocessingunit)、数字信号处理器(dsp，digitalsingnalprocessor)或可编程逻辑阵列(fpga，field-programmablegatearray)实现；对于存储介质来说，包含操作指令，该操作指令可以为计算机可执行代码，通过所述操作指令来实现上述本发明实施例信息处理方法流程中的各个步骤。这里需要指出的是：以上涉及终端和服务器项的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明终端和服务器实施例中未披露的技术细节，请参照本发明方法流程描述的实施例所描述内容。以一个现实应用场景为例对本发明实施例阐述如下：在金融理财领域采用本发明实施例，是在互联网理财平台接入的多个终端设备、互联网理财平台、接入处理装置和接入处理装置接入的多家金融机构间的信息处理流程。首先对本文中涉及的技术用语进行描述：1)t日：即上海交易所对外公布的交易日，不包括周末以及国家所有法定假日；2)d日：表示自然日，包括周末以及国家所有法定假日。3)商户号：互联网理财服务平台和理财/保险公司之间商定的某款理财产品的产品标识。金融理财领域中，目前的互联网理财服务平台一般都会接入种类繁多的基金产品，以方便用户进行选购，但是由于历史原因不同基金公司使用的接口格式和业务交易模式都有很大的差异，甚至是相同基金公司内部不同类型的基金产品所提供的对外接口格式也存在很大的差异。现在互联网理财平台在接入一款新的理财产品时，为了适配理财产品在技术和业务上的差异，一般都需要对已有的系统进行调整或者重新开发系统来适配(或特殊处理)该产品的差异。而且对互联网理财平台而言，每接入一款新的理财产品时都需要从开户申请、申购申请、赎回申请、申购对账、赎回对账、收益对账等多个环节和基金公司进行接口适配，涉及的功能模块如图8所示，图8为现有互联网理财平台目前的基金产品接入方案。在图8中，目前在接入不同基金/保险公司的理财产品时，主要由互联网理财平台来负责实现对产品差异的适配，并对相应的系统进行开发和维护工作。目前在互联网理财平台接入不同类型的理财产品时，现有的接入和维护方案存在如下问题：一，影响互联网理财平台的新产品接入效率由于不同理财产品的业务规则和对外接口差异很大，因此互联网理财平台每次在接入新的理财产品时，都需要针对该款产品的差异和特点来对已有的系统功能模块(如图8中的功能模块lista和功能模块listb)进行修改或者重新开发工作，然后再与基金公司进行接口联调，这样每接入一款新的基金产品平均耗时都需要耗费很大的时间成本和人力成本。二、互联网理财平台的系统维护复杂随着互联网理财平台接入的基金产品越来越多，其系统中相关的功能模块(如图8中的功能模块lista和功能模块listb)会越来越多，并且业务逻辑也会变得越来越复杂。尤其是当基金公司的接口规范发生变化时，互联网理财平台首先需要准确地评估出需要修改的模块，然后需要再次投入人力进行开发、测试和联调工作。因此，互联网理财平台的系统会随着接入基金/保险产品个数的不断增加其维护成本也会越来越高。三、接口差异适配的逻辑无法复用由于对基金公司接口的适配和处理逻辑是在互联网理财平台自身的功能模块中实现的，因此不同的互联网理财平台在接入同一款基金产品时，都需要对该款产品的差异进行适配和处理。但是这些适配和处理逻辑无法在不同的互联网理财平台的系统中实现功能复用，也存在比较严重的模块重复开发和资源浪费的问题。针对上述问题，在金融理财场景中采用本发明实施例，实现了一种可复用的并且独立于互联网理财平台和基金公司的接入处理装置，一个示例为理财中间件，通过该接入处理装置可以实现屏蔽和适配不同基金产品的对外接口差异，可通过配置的方式来灵活地适配不同基金产品的业务逻辑差异并向多个互联网理财平台提供“标准”的接口服务，并保证数据在处理和传输过程中的准确性和完整性，从而大幅提供互联网理财平台的新产品接入效率，降低互联网理财平台的系统开发和维护成本。在金融理财场景中采用本发明实施例，所实现的接入处理装置，独立于互联网理财平台和基金公司，由互联网理财平台、接入处理装置(理财中间件)和基金公司组成的框架如图9所示。其中，针对接入处理装置(理财中间件)具体阐述如下：一、适配不同基金公司的的对外接口差异目前，基金/保险公司的对外接口主要分为两类：一类是互联网理财平台向基金公司提交申请数据的接口；一类是基金公司向互联网理财平台反馈确认数据的接口。本发明实施例中的接入处理装置(如理财中间件)与基金公司的接口定义与处理逻辑符合目前互联网理财平台与基金公司的接口定义与处理逻辑，以便可以通过该接入处理装置(如理财中间件)来适配申请数据接口和确认数据接口的差异；而接入处理装置(如理财中间件)会向各个互联网理财平台提供标准的申请数据接口和确认数据接口。1)互联网理财平台需要向基金公司提交申请数据的接口主要包括开户申请接口、申购申请接口、赎回申请接口，接入处理装置(如理财中间件)对于这类接口的处理逻辑如图10所示，图10为接入处理装置(如理财中间件)对申请数据标准接口的处理逻辑示意图，该处理逻辑包括：步骤501、生成请求数据；步骤502、发送请求数据[商户号＝prol]；步骤503、加载该商户号的配置；步骤504、根据配置选项处理请求数据；步骤505、生成符合基金公司要求的数据；步骤506、发送处理后的请求数据；步骤507、处理请求数据；步骤508、返回处理结果。步骤509、记录处理结果。从图10可以看出，对于申请数据的标准接口(一般是文件处理接口)，理财接入处理装置(如理财中间件)的主要处理逻辑是接收互联网理财平台所有基金产品的申请数据(包括开户申请、申购申请、赎回申请等数据)，然后加载该基金产品的配置项数据，并根据具体的配置项对联网理财平台提交的申请数据进行转换处理，并把处理后的数据发送给对应的基金公司。其中，每个理财产品都拥有一份独立的配置项列表，这些配置项主要是定义了对应的基金公司对数据的特殊要求，并根据该配置把互联网理财平台提交的数据转换成符合基金公司要求的数据，以适配对应基金公司的接口差异。而对互联网理财平台则提供标准、统一的数据交互接口，因此不需要进行特殊的配置。而接入处理装置(如理财中间件)的配置数据既可以保存在数据库(db)中，也可以保存在配置文件中，格式可以如下：其中，每个理财产品都拥有一份独立的配置项，这些配置项主要是定义了对应的基金公司对数据的特殊要求，并根据该配置把互联网理财平台提交的数据转换成符合基金公司要求的数据，以适配对应基金公司的接口差异。针对申请数据传输时间和传输方式进行说明如下：一般情况下，理财产品t日的申请数据基金公司会在t+1日进行确认并返回确认数据，由于在理财业务中对数据传输的实时性要求不高，互联网理财平台可以使用文件方式一次性地传输请求数据，这样还可以减轻对接入处理装置(如理财中间件)接口的并发请求压力。互联网理财平台t日的请求数据文件传输时间一般为t+1日开始的2-3个小时内，为接入处理装置(如理财中间件)服务和基金公司保证足够的数据处理时间。申请文件的传输方式可以采用以下两种方案：1，接入处理装置(如理财中间件)服务从互联网理财平台的系统中主动下载申请数据文件；2，互联网理财平台主动把申请文件上传到接入处理装置(如理财中间件)的系统中。针对接入处理装置(如理财中间件)提供给互联网理财平台的申请接口封装说明如下：如图11所示，图11为接入处理装置(如理财中间件)申请数据接口的交互逻辑示意图，该交互逻辑包括：步骤601、传输申请文件，具体包括如下两种方式：步骤601a、主动上传请求文件来传输申请文件；步骤601b、主动下载请求文件，包括请求下载文件和返回申请文件；步骤602、根据文件名判断文件类型；步骤603、根据文件类型加载接口格式定义；步骤604、根据申请接口定义解析文件头；步骤605、根据申请接口定义解析文件数据体；步骤606、检查文件数据合法性；步骤607、若文件不合法，则返回文件数据不合法原因信息。从图11可以看出，申请数据接口主要是处理互联网理财平台的申请数据(文件)，其中不同的申请接口只能处理对应的申请数据文件，例如申购申请接口只能处理申购申请数据文件。接入处理装置(如理财中间件)在处理对应的申请文件时需要加载接口格式定义数据，然后据此解析申请数据文件的文件头和数据体部分，例如申购申请(文件)接口的标准格式定义可以如图12所示，如果接入处理装置(如理财中间件)的申请接口在解析申请数据文件并检查到存在不合法的数据时，会向互联网理财平台反馈具体的失败信息。2)基金公司需要向互联网理财平台向基金公司返回确认数据接口主要包括开户确认接口、交易确认接口、收益对账接口、强增强减接口，接入处理装置(如理财中间件)对于这类接口的处理逻辑如图13所示，图13为接入处理装置(如理财中间件)对确认数据标准接口的处理逻辑示意图，该处理逻辑包括：步骤701、生成确认文件；步骤702、发送确认数据[商户号＝prol]；步骤703、加载该商户号的配置；步骤704、根据配置项处理确认数据；步骤705、生成标准的确认数据；步骤706、返回处理结果；步骤707、返回处理后的确认数据；步骤708、处理请求数据；步骤709、记录处理结果。从图13可以看出，对于申请数据的标准接口(一般是文件处理接口)，理财接入处理装置(如理财中间件)主要是把每个基金/保险公司输出的确认数据(包括开户确认数据、交易确认数据、强增强减数据等)根据对应商户号的配置项进行转换和处理，把数据的处理结果通过标准的确认数据接口提供给互联网理财平台。针对确认数据传输时间和传输方式说明如下：一般情况下，基金公司会在t+1日对互联网理财平台t日的申请数据进行确认并把确认数据文件返回给接入处理装置(如理财中间件)，接入处理装置(如理财中间件)对初始的确认数据按照之前与互联网理财平台约定的规则进行处理后，再把通过确认接口把确认数据返回给互联网理财平台。在接入处理装置(如理财中间件)和互联网理财平台直接，确认数据文件的传输方式可以采用以下两种方案：1)互联网理财平台从接入处理装置(如理财中间件)服务的系统中主动下载确认数据文件；2)接入处理装置(如理财中间件)的系统主动把确认文件上传到互联网理财平台中。针对接入处理装置(如理财中间件)提供给互联网理财平台的确认数据接口封装说明如下，图14为接入处理装置(如理财中间件)确认数据接口的交互逻辑示意图，该逻辑包括：步骤801、生成标准的确认文件；步骤802、传输申请文件，具体包括如下两种方式：步骤802a、主动上传请求文件来传输确认文件；步骤802b、主动下载请求文件，包括请求下载文件和返回标准格式的确认数据(文件)；步骤803、根据文件名判断文件类型；步骤804、根据文件类型加载接口格式定义；步骤805、根据确认接口定义解析文件头；步骤806、根据确认接口定义解析文件数据体；步骤807、检查文件数据合法性；步骤808、当文件不合法时，返回文件数据不合法原因信息。从图14可以看出，确认数据接口主要是生成并传输标准确认数据(文件)到互联网理财平台，其中不同的确认接口只能处理对应的确认数据文件，例如申购确认接口只能处理申购确认数据文件。而互联网理财平台在处理确认文件时需要加载接入处理装置(如理财中间件)的接口格式定义数据，然后据此解析确认数据文件的文件头和数据体部分，例如申购确认(文件)接口的标准格式定义可以如图15所示。如果互联网理财平台的处理逻辑在解析申请数据文件并检查到存在不合法的数据时，会向接入处理装置(如理财中间件)反馈具体的失败信息。综上所述，当互联网理财平台选择接入处理装置(如理财中间件)来接入新的理财产品时，就不需要为了适配基金公司的接口差异而进行系统维护和开发工作，因为这部分工作已经转移到了接入处理装置(如理财中间件)的服务中，从而大幅提供互联网理财平台接入新基金的效率。同时，由于接入处理装置(如理财中间件)会保证提供给互联网理财平台的数据是完整和准确的，因此互联网理财平台就不需要在系统内部对基金公司的确认数据进行核对和校验，这样可以在很大程度上减轻互联网理财平台内部系统业务逻辑的复杂性，使系统更新便于维护。针对数据正确性的保证而言，由于接入处理装置(如理财中间件)会处理互联网理财平台和基金公司之间的交互数据，因此接入处理装置(如理财中间件)必须要保证提供给互联网理财平台和基金公司的数据都是正确的。这主要靠以下两种策略来保证：1)数据校验和对账逻辑对于互联网理财平台提供基金公司的申请数据，接入处理装置(如理财中间件)只需要把这些标准化的数据记录下来。对于基金公司提供给互联网理财平台的确认数据，接入处理装置(如理财中间件)在把数据处理成标准数据之后需要之前的申请数据进行校验和核对，流程如图16所示，图16为接入处理装置(如理财中间件)数据校验和核对的处理逻辑示意图，该处理逻辑包括：步骤901、加载请求数据；步骤902、加载处理后的确认数据；步骤903、校验确认数据完整性；步骤904、校验确认数据正确性；步骤905、返回数据校验结果及失败原因；步骤906、返回该商户号的确认数据。从图16可以看出，数据校验和核对部分主要是用处理后的确认数据与互联网理财平台提供的申请数据进行检查，主要包括双方数据一致性、确认数据正确性等方面的检查，以保证返回给互联网理财平台的确认数据是可靠的。2)份额强增强减逻辑当由于基金公司系统或接入处理装置(如理财中间件)自身系统的原因导致数据校验和核对逻辑检查后的确认数据(主要是用户的收益和份额数据)出现偏差时，接入处理装置(如理财中间件)就需要强增强减接口来为互联网理财平台提供一种数据校正的功能，主要逻辑如图17所示，图17为接入处理装置(如理财中间件)份额数据强增强减处理逻辑示意图，该处理逻辑包括：步骤1001、份额数据调整请求(商户号＝prol)；步骤1002、检查基金公司请求数据；步骤1003、汇总每个商户号的强加强减数据；步骤1004、生成标准的强加强减数据；步骤1005、返回强加强减数据；步骤1006、校验份额强加强减数据；步骤1007、返回错误信息；步骤1008、校正用户份额等确认数据。从图17可以看出，通过接入处理装置(如理财中间件)强增强减逻辑，互联网理财平台可以及时地调整每个商户号的异常份额数据。其中，接入处理装置(如理财中间件)强增强减标准接口的数据格式可以定义如图18所示。其中，接口格式定义中的操作类型包括2种：1)强增份额；2)强减份额。由于份额强增强减操作是一项十分敏感的操作，直接影响理财用户的持有份额数据，因此互联网理财平台在操作前也需要进行数据核对，规则如下：1)份额强减操作：操作前持有份额＝系统计算实际份额；调整份额＜操作前持有份额；调整份额数据＞0。2)份额强增操作：操作前持有份额＝系统计算实际份额；调整份额数据＞0。在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。或者，本发明上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本
技术领域：
：的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。当前第1页12当前第1页12