一种NDC聚合器的预警方法、系统、设备及存储介质与流程

一种ndc聚合器的预警方法、系统、设备及存储介质
技术领域
1.本技术涉及计算机技术领域，尤其涉及一种ndc聚合器的预警方法、系统、设备及存储介质。


背景技术：

2.近年，ndc(new distribution capability，新分销能力)实施进程加快，进入量化阶段。随着航空公司新分销能力的建立，越来越多的航空公司发布了自己的ndc销售接口，由于每个航空公司都会发布大量的ndc航班信息，而且由于国际航线复杂，城市机场多，航班数据量非常庞大，使得航司对热门航线的查询会返回非常多的ndc查询结果。
3.这使得对于多航司版本统一并聚合将面临很大数据量的挑战。由于各个航司的接口应用的ndc标准版本不同、业务理解不同、应用方式不同，所以航司接口各不相同，下游渠道用户对接航司接口的成本很高、难度很大。因此诞生了聚合器(aggregator)，聚合器对接各个航司的ndc接口，将其ndc内容进行汇总、解析、转换、融合，生成聚合后的内容，然后按照ndc标准向下游渠道客户提供统一接口，下游客户只需对接该统一接口，即可快速实现多家航司的对接。
4.但是，航空公司即便使用同一ndc版本，但在给下游的接口内容中也会不停新增节点或调整原有节点使用方法的情况，例如航空公司在航班查询的时候通过新增节点支持了更多查询条件、返回的结果里支持了更多的支付方式等等。航空公司的这种改变往往不会及时通知下游的使用者，这就导致聚合器无法及时发现变化，从而导致对航空公司的变化后知后觉，进而降低了对接效率。


技术实现要素：

5.为了解决现有技术存在的上述技术问题，本技术提供了一种ndc聚合器的预警方法、系统、设备及存储介质，能够较为快速的发现上游业务的变化，提升了聚合器上游和下游之间的对接效率。
6.第一方面，本技术提供了一种ndc聚合器的预警方法，ndc聚合器用于利用自身的处理规则将第一对象集合的各个ndc接口转换为标准接口后提供给第二对象集合。其中，第一对象集合中的各第一对象可以为ndc聚合器的上游航空公司，第二对象集合中的各个第二对象为ndc聚合器下游的使用者，该方法包括：获取目标报文，目标报文包括第一对象集合产生的交易报文和查询报文；比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配，处理规则数据用于表征ndc聚合器将各个ndc接口转换为标准接口的处理规则；当目标报文的数据与处理规则数据不匹配时，进行预警处理。
7.本技术提供的技术方案中，预先构建了ndc聚合器的规则库，并在规则库中存储了处理规则数据，该处理规则数据用于表征所述ndc聚合器将各个所述ndc接口转换为所述标准接口的处理规则。本领域技术人员当知晓的是，评判一个ndc聚合器能力高低的一个重要
标准为是否能够准确处理各第一对象的所有接口和接口所有节点逻辑。所以面对第一对象的主动变更，如何及时发现上游的变化对ndc聚合器来说至关重要。本技术的方案通过比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配，当不匹配时进行预警，因此可以更快发现上游变化，以便于进行及时的维护与更新，提升了ndc聚合器的稳定性，进而并且为下游的第二对象提供更好的服务，提升了ndc聚合器上游和下游之间的对接效率。
8.在一种可能的实现方式中，处理规则数据包括多个字段，以及与多个字段中的每个字段分别对应的处理逻辑数据，多个字段中包括第一对象的节点名称，比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配，具体包括：从规则库中读取处理规则数据，并将所述处理规则数据存储于redis缓存；对比目标报文中的节点名称是否在处理规则数据中已经存在，若不存在，则确定目标报文的数据与处理规则数据不匹配；若存在，则确定目标报文的各个字段是否在处理规则数据中全部存在，若否，则确定目标报文的数据与处理规则数据不匹配；若是，则确定目标报文的字段对应的处理逻辑数据，与规则库存储的相应字段的处理逻辑数据是否匹配，若匹配，则确定目标报文的数据与ndc聚合器的规则库中存储的处理规则数据匹配；否则，确定目标报文的数据与ndc聚合器的规则库中存储的处理规则数据不匹配。
9.以上的比对过程中，首先需要对比目标报文中的节点是否在处理规则中已经记录和分析，如果是一个新的节点未进行过分析，则需要记录并进行预警。也即在当前存储的字段中不包括第一对象的节点名称。当确定所有的节点都进行过分析，也即的规则库中存储有所有节点的处理规则时，接下来分析处理规则是否匹配。首先需要比对目标报文中的数据的字段是否均是处理规则数据中的字段。若否，则表明出现了新增的字段，也即出现新的未记载的处理规则数据。当未出现新增的字段，也即未出现新增的处理规则时，至此说明聚合器已经对所有字段都有处理逻辑，接下来分析处理规则是否正确。当获取目标报文中的字段对应的处理逻辑数据，与规则库记载的处理规则数据中的处理逻辑数据不匹配时，表面此时的处理规则发生了变化，并且该变化未被记载。
附图说明
10.图1为本技术实施例提供的一种ndc聚合器的预警方法的流程图；图2为本技术实施例提供的另一种ndc聚合器的预警方法的流程图；图3为本技术实施例提供的一种字段转换的处理规则的规则库样式的示意图；图4为本技术实施例提供的一种枚举记录的处理规则的规则库样式的示意图；图5为本技术实施例提供的又一种ndc聚合器的预警方法的流程图；图6为本技术实施例提供的一种ndc聚合器的预警系统的示意图；图7为本技术实施例提供的一种电子设备的示意图。
具体实施方式
11.为了使本技术领域的人员更清楚地理解本技术方案，下面首先说明本技术中涉及的专业术语及其含义。
12.新分销能力(new distribution capability，ndc)：是国际航空运输协会
(international air transport association，iata)近年来力推的新的分销行业标准。它主要制定了统一的数据传输标准（xml），航空公司与其合作伙伴之间可以通过这一统一的标准来进行数据的交互。航司可以根据卖家的请求以及卖家和旅客的信息，动态实时构建航班运价机票产品、以及辅营产品（也就是ndc里常说的offer），再通过统一的标准提供给卖家，改变了传统机票领域主要由全球分销系统(global distribution system，gds)构建offer的进行分销模式，让航空公司重回交易的主导地位，促进航司的直销。
13.ndc标准版本：每个ndc版本里都会包括若干接口，例如airshopping接口、servicelist接口、offerprice接口等等。自国际航空运输协会发布ndc标准以来，以每年2个版本的速度对ndc接口进行持续完善和更新。各版本之间会存在接口数量变化，接口内节点变化等情况。使用ndc标准的各参与方，如航空公司、聚合商以及机票代理人可根据自身情况升级至新版本或维持原有版本其中，airshopping交易集（消息对）支持匿名的或个性化的shopping、提供按条件查询或灵活查询的shopping体验，同时支持指定属性及出行目的的shopping，指定日期范围或月份（日历搜索）的shopping，此外还灵活支持其他shopping属性。
14.airshopping交易的响应包含返回的offer集，这些offer可以是品牌运价offer或者针对行程定价的offer（即普通offer），可包含或不包含附加服务产品。包含offer的打包运价及其适用规则，也能包含每项服务产品的单独价格和适用规则。响应消息还可返回消息级别的富媒体内容，以及针对每个单独offer的富媒体内容链接，内容链接通常指向内容分发网络(content delivery network，cdn)服务器）。
15.servicelist交易集（消息对）能返回满足请求查询条件以及对应航班限制的所有适用的附加服务列表。该消息对支持：在选定offer的前提下，以“菜单点选”方式搜索和购买额外的附加服务项目，或者，搜索和购买在正常的offer中不会包含的特殊附加服务（例如用于运动器材的超规行李，无人陪伴儿童服务等），可基于已选定offer进行，或单纯使用服务搜索过滤器。该消息对还可在消息级别以及在单个服务级别（通过offer item id机制指向offer项）返回服务的富媒体内容。
16.offerprice交易集（消息对）能够返回不同的两组内容。根据请求的属性，响应消息的内容可能是为被选定offer提供的额外附加服务产品，并可供客户自由选择（“菜单点选式”）和动态打包。如果针对选定的offer没有可使用的附加服务，则响应消息返回offer的最终定价。如果有可使用的附加服务，则需要修改offerprice请求，以包含选定的offer和附加服务，之后返回的offer询价响应将包含选定的附加服务的价格。
17.聚合器(aggregator)：是ndc销售模式下一个新的角色。由于各个航司的接口应用的ndc标准版本不同、业务理解不同、应用方式不同，所以航司接口各不相同，下游渠道用户对接航司接口的成本很高、难度很大。因此诞生了aggregator，它对接各个航司的ndc接口，将其ndc内容进行汇总、解析、转换、融合，生成聚合后的内容，然后按照ndc标准向下游渠道客户提供统一接口，下游客户只需对接该统一接口，即可快速实现多家航司的对接销售。
18.机票代理人：同时销售一家或多家航空公司机票的企业，根据经营特点一版包括在线机票代理人、差旅管理企业、机票批发零售商等多种类型。以下简称代理人。
19.ndc的aggregator，一直致力于将使用不同ndc标准版本的多个航空公司的ndc结果进行翻译、聚合和统一，屏蔽航空公司差异化结果，再以统一标准输出给代理人，帮助代
理人实现一次对接即可获得多个航空公司ndc内容的目标。这有效提高了代理人对接效率，帮助其大幅降低对接成本，推动了代理人航空新零售业务转型。
20.但是航空公司在新零售业务的发展方面是不断完善和升级的，这些更改往往体现在交互的接口内容发生变化，也就是说航空公司出现了即便使用同一ndc版本，但在给下游的接口内容中也会不停新增节点或调整原有节点使用方法的情况。
21.例如：航空公司在航班查询的时候通过新增节点支持了更多查询条件、返回的结果里支持了更多的支付方式等等。航空公司的这种改变往往不会及时通知下游的使用者，这就导致aggregator无法及时发现变化，从而导致对航空公司的变化后知后觉，进而降低了对接效率。
22.为了解决以上问题，本技术实施例提供了一种ndc聚合器的预警方法、系统、设备及存储介质，通过比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配，当不匹配时进行预警，因此可以更快发现上游变化，以便于进行及时的维护与更新，提升了ndc聚合器的稳定性，进而并且为下游的第二对象提供更好的服务，提升了ndc聚合器上游和下游之间的对接效率。
23.为了使本技术领域的人员更清楚地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
24.本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。
25.本技术说明中的“第一”、“第二”等用词仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。
26.本技术以下实施例中的聚合器即为ndc聚合器，不再赘述。
27.本技术实施例提供了一种ndc聚合器的预警方法，下面结合附图说明。
28.参见图1，该图为本技术实施例提供的一种ndc聚合器的预警方法的流程图。
29.该方法包括以下步骤：s101：获取目标报文。
30.目标报文包括第一对象集合产生的交易报文和查询报文。
31.实际应用中，该目标报文为第一对象针对第二对象的业务请求报文产生的处理结果报文。
32.对于交易业务的请求报文，产生交易报文；对于查询业务的请求报文，产生查询报文。其中的交易报文和查询报文均为处理结果报文。
33.s102：比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配。
34.处理规则数据用于表征ndc聚合器将各个ndc接口转换为标准接口的处理规则。
35.s103：当目标报文的数据与处理规则数据不匹配时，进行预警处理。
36.当目标报文的数据与处理规则数据不匹配时，表征此时第一对象的发布了新的处理规则，或者进行了处理规则的更新，而第一对象对于处理规则的更新并未记录在ndc聚合器的规则库中。
37.本技术实施例提供的方案，通过比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配，当不匹配时进行预警，因此可以更快发现上游变化，以便于进行及时的维护与更新，提升了ndc聚合器的稳定性，进而并且为下游的第二对象提供更好的服务，提升了ndc聚合器上游和下游之间的对接效率。
38.下面结合具体的实现方式进行说明。
39.参见图2，该图为本技术实施例提供的另一种的流程图。
40.在ndc的环境下，如果想法主动发现航空公司的变化，就要将aggregator是如何处理航司每个接口进行归纳和整理形成基础逻辑库。
41.然后在此基础上，记录每天系统的交易报文，再通过每天的夜间维护，去比对每天的交易报文与规则库中存储的处理规则是否匹配，如果不匹配则进行预警。
42.其中，第一对象集合也即aggregator上游的航空公司的集合，第二对象集合也即aggregator下游的用户的集合。
43.基于以上的构思，该方法具体包括以下步骤：s201：预先构建aggregator的规则库。
44.aggregator每接入一家ndc航空公司，就需要处理这家航空公司所使用的所有ndc接口，记录每个接口处理过程。aggregator需要记录从航空公司接口到aggregator为下游提供接口之间，一个节点应如何被记录成另一个节点。
45.例如：是如何将航空公司airshopping接口上的某一个节点通过翻译形成aggregator自己的标准节点输出给下游。该步骤为基础步骤，记录的准确程度与否关系到后面的分析是否准确。
46.除了记录节点转换关系，构建规则库另一个工作还包括对一些特别字节（暂且定义为枚举类型字段）返回内容进行汇集和整理，以便了解航空公司业务变化。
47.对照iata标准，分析aggregator针对每一个航空公司的每一个接口的每一个节点的处理规则，并将处理规则存储在规则库中。
48.处理规则在存储时，形成多条处理规则数据，每条处理规则数据包括对应的字段与处理逻辑数据。
49.每一个节点包括的字段可以参见表1所示。
50.表1：处理规则包括的字段
51.以上的字段仅是举例说明，并不构成对于本技术技术方案的限定，实际应用中包括的字段可以更少或者更多，再次不再赘述。
52.规则库的表结构建立好后，将规则入库。
53.具体的，将aggregator针对每个航空公司的每一个接口的每一个节点的处理逻辑数据写入表1中的对应的字段，以实现处理规则数据存储。
54.一个iata ndc标准接口，一般涉及几百个节点需要分析。
55.下面以新加坡航空公司的airshoppingrs接口返回为例，如果想要构建aircraftscheduleddatetime和name节点处理逻辑，一般会得到下表2的数据。
56.其中，处理规则数据用于表征处理规则，在规则库中存储了处理规则数据，也即存储了处理规则。
57.表2：写入数据后的处理逻辑表
58.字段转换的处理规则的规则库样式可以参见图3所示的示意图。
59.同时再建立一张基础表，用以收集枚举字段的内容，进而便于用于辨识航空公司业务变更。
60.用于收集枚举内容的表结构如以下表3所示。
61.表3：记载枚举字段的处理规则表
62.例如，某航空公司在servicelistrs中返回了若干附加服务内容，则会记录如下表所示的数据。
63.表4：写入数据后的枚举字段的处理规则表
64.枚举字段的逻辑处理数据，为该枚举字段对应的所有枚举内容，也即对应表中的baggage、meal以及pet等。
65.枚举记录的处理规则的规则库样式可以参见图4所示的示意图。
66.通过形成以上的数据表并存储对应的处理规则数据后，实现了对于规则库的构建。
67.s202：收集报文并对报文进行去重处理，以获取目标报文。
68.报文包括查询报文以及交易报文等，由于系统每天产生的查询报文和交易报文的数量即为庞大，所以需要对获取的初始报文进行有针对性的数据收集和分析，提高系统效率。
69.将系统每日产生的初始报文进行记录，但是因为报文数量庞大，且有些查询是重复数据，所以需要将报文进行去重处理后再与处理规则进行比对。
70.进行去重处理时，需要去除包含返回错误的初始报文。以及根据各初始报文的数据，确定第一对象集合中产生各报文的第一对象，也即确定产生各初始报文的航空公司。并且确定各所述报文携带的报文信息，所述报文信息为交易信息或查询信息。交易信息可以包括价格，出发日期、出发地和目的地等。查询信息可以包括出发日期、出发地和目的地等，本技术实施例不作具体限定。去重处理时，保留同一航空公司产生的且具有相同报文信息的多条初始报文中的一条初始报文。
71.也即在实际应用中，去重处理的标准为相同航空公司，相同出发日期、相同出发地和目的地的请求，只分析一份返回结果即可。
72.s203：比对目标报文的数据是否满足规则库记载的处理规则。
73.若是，执行s204，否则执行s205。规则库中每一条规则的基本单位是由“航空公司+版本号+接口名称+节点路径+节点名称”，所以用航空公司返回报文中每一个节点和规则进行对比时，关注以下三种情况需要预警：第一种情况：当航空公司某版本接口里某条路径上一个节点并未存储在规则库，则说明航空公司增加了新的内容。
74.第二种情况：当某条规则明确记录了航空公司报文上的节点输入长度是固定值，而返回的报文里该节点字符长度与规则不符时。例如，上文中记录了新加坡航空公司在airshopping中节点aircraftscheduleddatetime的输入规则，输入长度应为19个字符。若新加坡航空公司更改了逻辑，返回的内容长度不为19个字符时，则需要预警。
75.第三种情况：当对比的节点在规则库中记录的枚举字段的内容时，则需要关注该枚举字段在本次航空公司返回结果中是否增加了规则库中枚举表里没记录过内容。例如某
航空公司在servicelistrs返回结果中servicecode和name节点被判定为枚举类型节点，若节点中增加了一个新的编码“xleg”，name节点上增加“extra leg room seat”名称，而规则库中并未记录到该编码和该名称，此时则需要预警。说明航空公司新增了一类名为“超长腿部空间座位”的新服务。除了预警以外，此类情况，系统可以自行添加一条枚举规则入库。
76.在一些实施例中，可以在夜间维护的时间，也即在每天凌晨读取规则库中的处理规则，并将读取到的处理规则写入redis缓存。此步骤是为了避免反复读取数据库造成系统运行效率降低。
77.redis缓存是一个开源的使用ansic语言编写、支持网络、可基于内存亦可持久化的日志型、键值对(key-value)数据库，并提供多种语言的应用程序编程接口(application programming interface，api)。
78.下面进一步具体说明。
79.明确产生目标报文的航空公司和报文接口名称，将目标报文中的数据与处理规则数据进行比对。
80.在进行比对时，首先需要对比目标报文中的节点是否在处理规则中已经记录和分析，如果是一个新的节点未进行过分析，则需要记录并进行预警。也即在当前存储的字段中不包括第一对象的节点名称。
81.当确定所有的节点都进行过分析，也即aggregator的规则库中存储有所有节点的处理规则时，接下来分析处理规则是否匹配。
82.按照iata标准，每个节点都应该有相应的填写规则，例如该节点应该填写日期。但对于日期用什么格式是不定义的。所以需要对比已有航司该接口该节点原有的处理规则是否与目标报文中的数据匹配。
83.下面分别具体说明。
84.首先需要比对目标报文中的数据的字段是否均是处理规则数据中的字段。若否，则表明出现了新增的字段，也即出现新的未记载的处理规则数据，由于处理规则数据用于表征处理规则，因此此时可以确定出现了新的处理规则。需要记录该变化，并发送对应的预警信息。
85.在一种可能的实现方式中，当确定出现了新的处理规则时，可以自动记录该处理规则，也即在表1所示的逻辑表中进行字段的更新，并且获取新的字段的处理逻辑数据，将新的字段与新的处理逻辑数据进行对应存储，以更新处理规则数据。
86.在另一种可能的实现方式中，当确定出现了新的处理规则时，发送对应的预警信息，触发人工干预，由操作人员主动进行处理规则的更新。
87.当未出现新增的字段，也即未出现新增的处理规则时，至此说明aggregator已经对所有字段都有处理逻辑，接下来分析处理规则是否正确。此时可能出现两种情况，下面分别说明。
88.第一种情况：处理规则发生了变更。
89.字段对应的处理逻辑数据指示了处理规则，当获取目标报文中的字段对应的处理逻辑数据，与规则库记载的处理规则数据中的处理逻辑数据不匹配时，表面此时的处理规则发生了变化，并且该变化未被记载，下面举例具体说明。
90.继续参见表2，规则库中存储的处理规则数据记录了某航空公司节点的返回结果
中，日期格式为yyyy-mm-dd。但如果从redis缓存读取到该航司的目标报文的返回结果中，日期格式为“15dec25”，此时的日期格式不匹配，说明航空公司变化出了一个新的日期格式，系统未处理过此种情况。此时获取目标报文中的字段对应的处理逻辑数据，与规则库记载的处理规则数据中的处理逻辑数据不一致，应该记录错误，准备发送预警信息。
91.在一种可能的实现方式中，当确定出现了处理规则的变更时，可以自动记录该处理规则的变更，也即在表2所示的逻辑表中进行处理逻辑数据的变更，将字段与新的处理逻辑数据进行对应存储，以变更处理规则数据。例如可以将表2中的处理逻辑数据2中的yyyy-mm-dd修改为对应的格式；或者还可以在表2中增加处理逻辑数据3，用于对应存储当前的日期格式。
92.在另一种可能的实现方式中，当确定出现了处理规则的变动时，发送对应的预警信息，触发人工干预，由操作人员主动进行处理规则的更新。
93.下面说明第二种情况：第二种情况：处理规则未发生变更。
94.当获取目标报文中的字段对应的处理逻辑数据，与规则库记载的处理规则数据中的处理逻辑数据匹配时，表面此时的处理规则未发生变化，下面举例具体说明。
95.继续参见表2，规则库中存储的处理规则数据记录了某航空公司该节点返回结果长度为三个字符。但如果从redis缓存读取到该航司的目标报文中返回节点的实际内容长度为三个字符，说明此时获取目标报文中的字段对应的处理逻辑数据，与规则库记载的处理规则数据中的处理逻辑数据匹配，不需要进行更新或预警处理。
96.对于较为特殊枚举类字段，在进行比对时，查看目标报文的内容是否已经完全包括在处理规则数据中枚举的内容中，如果没有，则说明航空公司增加了新的内容或业务，需要进行预警处理。
97.s204：进行预警处理。
98.通过进行预警，以促使进行人工干预，并完善规则引擎。
99.根据s203中的描述，当s204被执行时，主要工作是预警和分析并完善规则处理规则。
100.根据s203中的不同情况，预警处理时可以自动生成预警邮件，并发送给工作人员。
101.工作人员根据预警邮件的指示以及数据的比对情况对aggregator的规则库进行更新维护。如果是新增节点则判断该节点是否需要返回给下游，如果需要返回则修改代码逻辑，增加该部分处理，并通知下游客户。如果是处理逻辑数据发生变化同样需要修改代码逻辑，将格式统一，但该情况对下游客户无感。如果是字段的增加，修改系统处理逻辑，视具体情况决定是否通知下游客户航司业务变化。
102.下面举例说明预警邮件的格式。
103.主题：航空公司接口发生变化内容：1、出现不匹配的目标报文的编号；2、航空公司两字码；3、节点名称；4、节点路径。
104.航空公司两字码，也即生成所述出现不匹配的目标报文的第一对象的标识信息。
105.节点名称，也即生成出现不匹配的目标报文的第一对象的节点名称。
106.节点路径，也即生成出现不匹配的目标报文的第一对象的节点路径。
107.系统监控员当天收到变更预警邮件后，根据邮件内容进行处理，进行代码修复。修复完成后进行两个工作：（1）修复规则引擎，将航司新的规则加入到引擎库中；（2）根据航司变更具体情况，对于给下游客户带来业务变化或者开发变化的航司变更，需要通知到下游客户。帮助客户完善自身系统。
108.s205：提示处理规则未发生变化。
109.综上所述，利用本技术实施例提供的方法，能够更快发现上游变化，以便于进行及时的维护与更新，提升了ndc聚合器的稳定性，进而并且为下游的第二对象提供更好的服务，提升了ndc聚合器上游和下游之间的对接效率。
110.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
111.下面结合具体的应用场景进行说明。
112.参见图5，该图为本技术实施例提供的又一种ndc聚合器的预警方法的流程图。
113.其中，聚合器上游的第一对象为航空公司，聚合器下游的第二对象为机票代理人。
114.该方法包括以下步骤：s501：首次对接第一对象时，发送接口请求报文。
115.当ndc聚合器首次与第一对象对接时，发送符合该第一对象的当前ndc版本的接口请求报文。
116.s502：聚合器获取第一对象接口返回结果。
117.s503：将第一对象接口返回结果的各节点的处理规则记录入库，以形成规则库。
118.s504：第二对象向聚合器发送业务请求报文。
119.该业务请求可以为交易请求或者查询请求，例如航班查询请求、行李查询请求、附加服务查询请求以及订单生成请求等。
120.s505：ndc聚合器将第二对象的业务请求报文转换为第一对象所使用的ndc版本的标准请求报文。
121.s506：向第一对象发送标准请求报文。
122.s507：第一对象向ndc聚合器发送业务请求报文对应的处理结果报文。
123.处理结果以报文的形式进行发送。
124.s508：ndc聚合器在本地记录处理结果。
125.s509：将处理结果报文按照处理规则转换后返回给第二对象。
126.s510：对当天的初始报文进行去重处理以获取目标报文，并将目标报文的数据与ndc聚合器的规则库中存储的处理规则数据进行比对。
127.本步骤可以在ndc聚合器的夜间维护阶段进行。
128.s511：确定第一对象的节点发生变更，启动预警。
129.s512：通知第二对象接口发生接口变化。
130.可以理解的是，如果处理规则的变化对第二对象无感，则可以不通知第二对象发生接口的变化。
131.基于以上实施例提供的ndc聚合器的预警方法，本技术实施例还提供了一种ndc聚合器的预警系统，下面具体说明。
132.参见图6，该图为本技术实施例提供的一种ndc聚合器的预警系统的示意图。
133.预警系统包括：获取单元301、比对单元302以及预警单元303。
134.其中，获取单元301用于获取目标报文。目标报文包括所述第一对象集合产生的交易报文和查询报文。
135.比对单元302用于比对目标报文的数据与ndc聚合器的规则库中存储的处理规则数据是否匹配。处理规则数据用于表征ndc聚合器将各个ndc接口转换为标准接口的处理规则。
136.预警单元303用于当目标报文的数据与处理规则数据不匹配时，进行预警处理。
137.在一种可能的实现方式中，获取单元301，具体用于获取第一对象集合产生初始报文。对初始报文进行去重处理，以获取目标报文；将目标报文存储于redis缓存。
138.本技术实施例中的处理规则数据包括多个字段，以及与多个字段中的每个字段分别对应的处理逻辑数据，多个字段中包括第一对象的节点名称。
139.比对单元302具体用于：从规则库中读取处理规则数据，并将处理规则数据存储于redis缓存；对比目标报文中的节点名称是否在处理规则数据中已经存在，若不存在，则确定目标报文的数据与处理规则数据不匹配；若存在，则确定目标报文的各个字段是否在处理规则数据中全部存在，若否，则确定目标报文的数据与处理规则数据不匹配；若是，则确定目标报文的字段对应的处理逻辑数据，与规则库存储的相应字段的处理逻辑数据是否匹配，若匹配，则确定目标报文的数据与ndc聚合器的规则库中存储的处理规则数据匹配；否则，确定目标报文的数据与ndc聚合器的规则库中存储的处理规则数据不匹配。
140.ndc聚合器的预警系统包括处理器和存储器，上述获取单元、比对单元以及预警单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。
141.处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来实现以上实施例中的ndc聚合器的预警方法。
142.本技术实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现以上实施例中的ndc聚合器的预警方法。
143.本技术实施例还提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行以上实施例中的ndc聚合器的预警方法。
144.本技术实施例还提供了一种电子设备，下面结合附图具体说明。
145.参见图7，该图为本技术实施例提供的一种电子设备的示意图。
146.电子设备40包括至少一个处理器401、以及与处理器401连接的至少一个存储器402，还包括总线403。
147.其中，处理器401、存储器402通过总线403完成相互间的通信；处理器401用于调用存储器402中的程序指令，以执行上述的ndc聚合器的预警方法。本技术中的设备可以是服务器、pc、pad、手机等。
148.本技术还提供了一种计算机程序产品，当在数据处理设备上执行时，实现以上实施例中所述的ndc聚合器的预警方法。
149.该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置被安装，或者从rom被安装。在该计算机程序被处理装置执行时，执行本公开实施例的方法中限定的上述功能。
150.需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（ram）、只读存储器（rom）、可擦式可编程只读存储器（eprom或闪存）、光纤、便携式紧凑磁盘只读存储器（cd-rom）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、rf（射频）等等，或者上述的任意合适的组合。
151.尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。
152.虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。
153.以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。