一种航班保障任务的触发方法及相关设备

技术领域

本申请涉及航空领域，尤其涉及一种航班保障任务的触发方法及相关设备。

背景技术

中国民航业发展呈现常态化，业务规模持续增加，可以预期未来的业务规模仍将持续增加。机场持续释放了更多的时刻资源，航班衔接更加紧凑，业务保障模式和流程势必会有所调整。

在传统的企业级项目开发模式中，业务决策逻辑或业务规则往往是程序员硬编码嵌入在系统各处代码中的，系统开发完成之后，业务规则也就完全固定在其中。但航空公司为了适应市场的多变性和旅客的个性化需求，其服务也是多变的。变化的商业规则和业务流程难免引起对应用程序的频繁修改，业务规则随着业务需求的变化不断变化的，需要实时反映在相关信息中。一旦业务需求出现变更，开发人员需修改、更新系统代码来改变业务逻辑才能响应业务规则的变更要求，需要经过需求分析、设计、编码、测试、发布等环节，对于后期的修改和维护带来了极大的困难和挑战，系统维护任务繁重且代价昂贵，既大大的限制了系统的灵活性也影响了系统的稳定性。

发明内容

本申请提供了一种航班保障任务的触发方法及相关设备，降低了系统后期的修改和维护的困难，同时增加了系统的灵活性以及稳定性。

本申请实施例第一方面提供了一种航班保障任务的触发方法，包括：

确定目标事件拆分选型；

根据所述目标事件拆分选型对航班业务流程中的事件进行拆分，得到事件集合；

梳理所述事件集合中每个事件的N个保障任务，其中，N为大于或等于1 的正整数；

对目标保障任务进行任务拆分，得到所述目标保障任务中每个子任务的属性信息，其中，所述目标保障任务为所述N个保障任务中的任意一个任务；

根据所述目标保障任务中每个子任务的属性信息配置目标保障任务中每个子任务的业务规则，所述业务规则包括触发条件、责任部门、执行流程以及预警规则，且所述业务规则包含于规则引擎库，所述规则引擎库中包含有提前配置的多个业务规则；

根据所述业务规则对当前航班进行任务触发。

本申请实施例第二方面提供了一种航班保障任务的触发装置，包括：

确定单元，用于确定目标事件拆分选型；

事件拆分单元，用于根据所述目标事件拆分选型对航班业务流程中的事件进行拆分，得到事件集合；

梳理单元，用于梳理所述事件集合中每个事件的N个保障任务，其中，N 为大于或等于1的正整数；

任务拆分单元，用于对目标保障任务进行任务拆分，得到所述目标保障任务中每个子任务的属性信息，其中，所述目标保障任务为所述N个保障任务中的任意一个任务；

配置单元，用于根据所述目标保证任务中每个子任务的属性信息配置目标保障任务中每个子任务的业务规则，所述业务规则包括触发条件、责任部门、执行流程以及预警规则，且所述业务规则包含于规则引擎库，所述规则引擎库中包含有提前配置的多个业务规则；

触发单元，用于根据所述业务规则对当前航班进行任务触发。

本申请实施例第三方面提供了一种计算机装置，其包括至少一个连接的处理器和存储器，其中，所述存储器用于存储程序代码，所述程序代码由所述处理器加载并执行以实现上述第一方面所述的航班保障任务的触发方法的步骤。

本申请实施例第四方面提供了一种机器可读介质，其包括指令，当其在机器上运行时，使得机器执行上述第一方面所述的航班保障任务的触发方法的步骤。

综上所述，可以看出，本申请提供的实施例中，引入规则引擎将业务规则从繁琐的系统代码中剥离出来，使用预定义的语义模块编写业务决策，将繁琐的规则驻留在规则库中，通过提前将航班业务流程中的事件的各个保障任务进行精细拆分，得到各个保障任务的每个子任务，并根据提前配置的规则引擎库中的业务规则为每个子任务配置业务规则，进而在当前航班的业务流程执行时，通过为该每个子任务配置的业务规则对当前航班的保障任务进行任务触发，保障航班保障任务的顺利执行，且由于提前配置了规则引擎库中的业务规则，在业务需求变化时，只需要更改对应的业务规则即可，降低了后期的修改和维护的困难，同时增加了系统的灵活性以及稳定性。

附图说明

结合附图并参考以下具体实施方式，本申请各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本申请实施例提供的航班保障任务的触发方法的一个流程示意图；

图2为本申请实施例提供的航班保障任务的触发装置的虚拟结构示意图；

图3为本申请实施例提供的机器可读介质的结构示意图；

图4为本申请实施例提供的服务器的硬件结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施例。虽然附图中显示了本申请的某些实施例，然而应当理解的是，本申请可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本申请。应当理解的是，本申请的附图及实施例仅用于示例性作用，并非用于限制本申请的保护范围。

本申请中使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本申请中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本申请中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

下面从航班保障任务的触发装置的角度本申请提供的航班保障任务的触发方法进行说明，该航班保障任务的触发装置可以为服务器，也可以为服务器中的服务单元，具体不做限定。

请参阅图1，图1为本申请实施例提供的航班保障任务的触发方法的流程示意图，包括：

101、确定目标事件拆分选型。

本实施例中，航班保障任务的触发装置可以确定目标事件拆分选型，航班保障任务的触发装置在对事件进行拆分时，存在两种维度的拆分方式，一种是基于业务场景触发动作拆分，另一种是基于业务模型属性变更拆分。两种维度的拆分模式都有一定的优缺点，航班保障任务的触发装置基于对两种拆分模式的优缺点分析，优先选用基于业务场景触发动作拆分的模式，并辅助设置消息分类，以保证消费者模块能够订阅大类消息。当然在实际应用过程中，还可以根据实际的应用场景来选择不同的事件拆分模式，具体不做限定。

也就是说，航班保障任务的触发装置可以首先定义相关业务场景标准触发动作以及所有调用系统进行业务操作的服务，根据标准定义事件组装满足业务场景要求的业务事件，相应模块处理逻辑也相对固定；当某个任务触发时，产生任务消息，并将该任务消息发送至任务的订阅者，该任务消息会携带触发服务标记(该服务标记指示该任务事件具体由那个系统触发)，能够为个性化处理提供有效支持。

需要说明的是，在整体业务事件里，会同时存储至航班以及任务等业务模型，提供足够属性变动信息(模型属性信息的变动，例如航班的预起时间、预达时间等)，供航班以及任务等业务模型进行响应处理，该响应处理指的是主要提供业务模型属性的变动信息，提供给需要关注这些信息的模块，例如航班预达时间变更，航班监控模块在获取到变更时间时，要判断航班是否为过站航班，过站时间是否充足，是否要启动快速过站流程，是否有中转旅客需要提前安排后续任务等等。

102、根据目标事件拆分选型对航班业务流程中的事件进行拆分，得到事件集合。

本实施例中，航班保障任务的触发装置在确定目标事件拆分选型之后，可以根据该目标事件拆分选型对航班业务流程中的事件进行拆分，得到事件集合，也就是说，航班保障任务的触发装置可以基于业务场景触发动作拆分的模式对整个航班业务流程中的事件进行拆分，也即将航班业务流程拆分成多个事件，得到事件集合。

103、梳理事件集合中每个事件的N个保障任务。

本实施例中，航班保障任务的触发装置可以梳理事件集合中每个事件的N 个保障任务，其中，N为大于或等于1的正整数。在航空公司实际的生产运营中，会存在一些高频次发生的保障任务，虽然不同的航空公司保障任务的业务流程不尽相同，但保障任务基本的业务处理流程、管理要求等大致相似，航班保障任务的触发装置可以梳理生产经营过程中所涉及到的保障任务，包括具体业务流，相关的触发条件、触发时机等以流程化的形式固化下来，有助于系统建立更清晰、更完善的处理流程。

104、对目标保障任务进行任务拆分，得到目标保障任务中每个子任务的属性信息。

本实施例中，航班保障任务的触发装置可以对目标保障任务进行任务拆分，得到目标保障任务中每个子任务的属性信息，该目标保障任务为N个保障任务中的任意一个任务。具体的，航班保障任务的触发装置可以首先确定目标保障任务的业务处理流程，并根据该业务处理流程对目标保障任务进行拆分，确定目标保障任务中每个子任务的属性信息。也就是说，航班保障保障任务在实际的生产保障中涉及多岗位、多部门以及多系统，且保障任务有不确定性和高频次等特点。一旦触发要能及时准确的作出响应，就需要对保障任务有完整的业务处理规范，然后基于航空公司针对各个保障任务的具体的业务处理流程对保障任务进行精细化拆分，明确各保障任务中每一条子任务的责任部门以及责任岗位等信息，以保证保障任务能及时高效的完成。下面以登机口减翻行李业务场景的保障任务的拆分进行说明：

1、离港系统做登机口拉下操作；

2、地面航班保障平台接收DCSI登机口减人报文；

3、地面航班保障平台解析报文，并判断旅客是否有托运行李；

4、旅客有托运行李，根据BHS/BRS和GIS数据，判断行李位置；

5、生成“翻行李任务”，将该保障任务发至行李分拣人员或者行李装卸人员。

105、根据目标保障任务中每个子任务的属性信息配置目标保障任务中每个子任务的业务规则。

本实施例中，航班保障任务的触发装置可以根据所述目标保证任务中每个子任务的属性信息配置目标保障任务中每个子任务的业务规则，该业务规则包括任务的触发条件、任务的责任部门以及任务的责任岗位等信息。航班保障任务的触发装置可以根据航班保障任务中每个子任务的属性信息设置航班保障任务业务规则，该保障任务业务规则包括任务的触发条件、任务的责任部门和任务的责任岗位等信息，当然也还可以包括其他的信息，例如任务的发送部门、任务的处理流程规范以及任务的预警规则等信息，具体不做限定。航班保障任务的触发装置可以预先把触发规则添加到规则引擎库里，以便在实际生产使用过程中能简单快速的完成查找与该任务对应的业务规则，并完成业务操作，降低用户在生产高峰时的操作压力。

需要说明的是，航班保障任务的触发装置可以预先配置各个保障任务的触发规则，并将该保障任务的触发规则添加至规则引擎库中，具体如下：

1、航班保障任务的触发装置根据航班业务流程主线，触发相关业务事件 (相关业务事件指的是航班计划(新增、关联VIP以及更新等)、航班动态、航班信息变更、调度信息(到达、值机、登机以及起飞等信息)、航班时刻调整、派工事件以及消息事件(公告、预警)，可以理解的是，在航班运行过程中，达到事件触发条件时，触发对应的事件，如航班计划制作完成后触发新增航班计划事件)，相关模块(该相关模块指的是对特定业务事件关心的模块，如航班监控模块对航班动态比较关注，就会订阅航班动态事件)通过订阅这些事件，进行相应的响应处理，如登机口减客翻行李事件：生成减客翻行李任务，分配给行李装卸人员，行李装卸人员翻找行李(到位、开始翻找、翻找结束)，配载确认是否重做舱单。

2、航空公司为了适应市场的多变性和旅客的个性化需求，其商业规则(如旅客服务标准以及航班保证标准等规则)和业务流程频繁修改，业务规则随着业务需求的变化不断变化的，根据系统架构设计，引入规则引擎来将业务规则(该业务规则包括任务的触发条件、触发部门、接收部门、执行流程以及预警规则)从系统代码中剥离出来，单独配置单独维护，满足航空公司不断变化的业务需求，当业务需求变化时，只需要变更对应的业务规则即可。

3、引入规则引擎之后，繁杂的业务规则就从业务逻辑组件中拆分出来了，此时仅需基于航空公司保障任务，搭建满足业务流程的通用业务逻辑组件和个性化业务逻辑组件，配合业务规则引擎来完成业务流程处理。

4、构建完成的业务逻辑组件，可以在客户端直接调用，来对外提供服务，可以自动或者生产人员手动调用服务，来完成航空公司的生产运营保障任务。

106、根据业务规则对当前航班进行任务触发。

本实施例中，航班保障任务的触发装置在配置完成业务规则之后，可以根据该业务规则对当前航班进行任务触发。

需要说明的是，该任务触发的模式有两种，一种是人工触发，一种是系统自动触发，航班保障任务的触发装置可以在当前航班的保障任务执行流程开始时，展示任务触发模式，并根据用户的第二操作指令选择目标任务触发模式，该目标任务触发模式为任务触发模式中的任意一个任务触发模式，并基于该目标任务触发模式对当前航班进行任务触发。

一个实施例中，航班保障任务的触发装置根据业务规则对当前航班进行任务触发包括：

基于触发条件判断第一任务是否触发成功，第一任务为当前航班中当前执行的任务；

若是，则根据第一任务对应的业务规则确定第一任务的责任部门、执行流程以及预警规则；

发送第一任务的执行流程以及预警规则至第一任务的责任部门。

本实施例中，航班保障任务的触发装置可以首先根据触发条件判断第一任务是否触发成功，若该第一任务触发成功，则根据该第一任务的业务规则确定第一任务的责任部门、执行流程以及预警规则，并将该第一任务的执行流程以及预警规则发送至第一任务的责任部门，以使得该第一任务得到快速的执行。

需要说明的是，在航班保障任务执行的过程中，当用户想查看任务的执行进度时，可以发出指令信息，航班保障任务的触发装置可以根据用户的指令信息发送任务反馈信息至第一任务的责任部门，接收并展示该第一任务的责任部门返回的第一任务的进度信息。

还需要说明的是，在航班保障任务执行的过程中，航班保障任务的触发装置接收用户的第一操作指令，所述第一操作指令为取消第二任务的操作，所述第二任务为所述当前航班中的任务；

根据所述第二任务的业务规则判断所述用户是否有权限；

若是，则取消所述第二任务，并发送取消信息至所述第二任务的责任部门；

若否，则展示提示信息，所述提示信息指示所述用户没有权限取消所述第二任务。

也就是说，航班保障任务的触发装置在接收到用于对任务的取消操作指令时，可根据该任务的业务规则判断该用户是否有权限取消，如果有权限取消，则发送取消信息至相关的责任部门，如果没有权限取消，则发出提示信息指示用户没有权限取消任务。

一个实施例中，生成成第一操作指令的操作至少包括手势操作、滑动操作、点击操作以及声控操作中的一种，例如用户对显示该第二任务的界面进行点击操作时，航班保障任务的触发装置可以接收到该点击操作，此时，该点击操作即生成该第一操作指令，也就是说，可以提前定义操作指令，例如提前定义滑动操作为取消第二任务的操作(如左滑操作、右滑操作、上滑操作以及下滑操作等等)，或者定义点击操作为取消第二任务的操作(如双击操作、鼠标滑动操作、长按操作、单击操作、鼠标左右键同时按操作以及滚轮鼠标中键等等)，或者定义手势操作为取消第二任务的操作(如向左摆动手腕或手臂，向右摆动手腕或手臂，如四根手指收缩操作或者三根手指上滑操作等等)，或者定义声控操作为取消第二任务的操作(如收到取消第二任务对应的声音)，上述仅为举例说明，并不代表对生成第一操作指令的操作进行限定。当然该第一操作指令还可以通过在输入设备上设置对应的快捷键进行生成，例如该输入设备为键盘，通过设置键盘上的“CTRL+A键”作为取消第二任务的操作，具体不限定。

综上所述，可以看出，本申请提供的实施例中，引入规则引擎将业务规则从繁琐的系统代码中剥离出来，使用预定义的语义模块编写业务决策，将繁琐的规则驻留在规则库中，通过提前将航班业务流程中的事件的各个保障任务进行精细拆分，得到各个保障任务的每个子任务，并根据提前配置的规则引擎库中的业务规则为每个子任务配置业务规则，进而在当前航班的业务流程执行时，通过为该每个子任务配置的业务规则对当前航班的保障任务进行任务触发，保障航班保障任务的顺利执行，且由于提前配置了规则引擎库中的业务规则，在业务需求变化时，只需要更改对应的业务规则即可，降低了后期的修改和维护的困难，同时增加了系统的灵活性以及稳定性。

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

本申请实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本申请的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本申请的范围在此方面不受限制。

另外，本申请还可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

上面从的航班保障任务的触发方法的角度对本申请进行说明，下面从航班保障任务的触发装置的角度对本申请进行说明。

请参阅图2，图2为本申请实施例提供的一种航班保障任务的触发装置的虚拟结构示意图，该航班保障任务的触发装置200包括：

确定单元201，用于确定目标事件拆分选型；

事件拆分单元202，用于根据所述目标事件拆分选型对航班业务流程中的事件进行拆分，得到事件集合；

梳理单元203，用于梳理所述事件集合中每个事件的N个保障任务，其中， N为大于或等于1的正整数；

任务拆分单元204，用于对目标保障任务进行任务拆分，得到所述目标保障任务中每个子任务的属性信息，其中，所述目标保障任务为所述N个保障任务中的任意一个任务；

配置单元205，用于根据所述目标保障任务中每个子任务的属性信息配置目标保障任务中每个子任务的业务规则，所述业务规则包括触发条件、责任部门、执行流程以及预警规则，且所述业务规则包含于规则引擎库，所述规则引擎库中包含有提前配置的多个业务规则；

触发单元206，用于根据所述业务规则对当前航班进行任务触发。

一种可能的实现方式中，所述触发单元206具体用于：

基于所述触发条件判断第一任务是否触发成功，所述第一任务为所述当前航班中当前执行的任务；

若是，则根据所述第一任务对应的业务规则确定所述第一任务的责任部门、执行流程以及预警规则；

发送所述第一任务的执行流程以及预警规则至所述第一任务的责任部门。

一种可能的实现方式中，所述装置还包括：

收发单元207，所述收发单元207用于：

发送任务反馈信息至所述第一任务的责任部门；

接收并展示所述第一任务的责任部门返回的所述第一任务的进度信息。

一种可能的实现方式中，所述任务拆分单元204具体用于：

确定所述目标保障任务的业务处理流程；

根据所述业务处理流程对所述目标保障任务进行拆分，确定所述目标保障任务中每个子任务的属性信息。

一种可能的实现方式中，所述收发单元207，还用于接收用户的第一操作指令，所述第一操作指令为取消第二任务的操作，所述第二任务为所述当前航班中的任务；

所述确定单元201还用于：

根据所述第二任务的业务规则判断所述用户是否有权限；

若是，则取消所述第二任务，并发送取消信息至所述第二任务的责任部门；

若否，则展示提示信息，所述提示信息指示所述用户没有权限取消所述第二任务。

一种可能的实现方式中，所述触发单元206还具体用于：

当所述当前航班的保障任务执行流程开始时，展示任务触发模式；

根据用户的第二操作指令选择目标任务触发模式，所述目标任务触发模式为所述任务触发模式中的任意一个任务触发模式；

基于所述目标任务触发模式对所述当前航班进行任务触发。

综上所述，可以看出，本申请提供的实施例中，引入规则引擎将业务规则从繁琐的系统代码中剥离出来，使用预定义的语义模块编写业务决策，将繁琐的规则驻留在规则库中，通过提前将航班业务流程中的事件的各个保障任务进行精细拆分，得到各个保障任务的每个子任务，并根据提前配置的规则引擎库中的业务规则为每个子任务配置业务规则，进而在当前航班的业务流程执行时，通过为该每个子任务配置的业务规则对当前航班的保障任务进行任务触发，保障航班保障任务的顺利执行，且由于提前配置了规则引擎库中的业务规则，在业务需求变化时，只需要更改对应的业务规则即可，降低了系统后期的修改和维护的困难，同时增加了系统的灵活性以及稳定性。

需要说明的是，描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，获取单元还可以被描述为“获取目标用户的证件信息的单元”。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

请参阅图3，图3为本申请实施例提供的一种机器可读介质的实施例示意图。

如图3所示，本实施例提供了一种机器可读介质300，其上存储有计算机程序311，该计算机程序311被处理器执行时实现上述图1所述航班保障任务的触发方法的步骤。

需要说明的是，本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

需要说明的是，本申请上述的机器可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM 或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

请参阅图4，图4是本申请实施例提供的一种服务器的硬件结构示意图，该服务器400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)422(例如，一个或一个以上处理器)和存储器432，一个或一个以上存储应用程序440或数据 444的存储介质430(例如一个或一个以上海量存储设备)。其中，存储器432 和存储介质430可以是短暂存储或持久存储。存储在存储介质430的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器422可以设置为与存储介质430 通信，在服务器400上执行存储介质430中的一系列指令操作。

服务器400还可以包括一个或一个以上电源426，一个或一个以上有线或无线网络接口450，一个或一个以上输入输出接口458，和/或，一个或一个以上操作系统441，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM， FreeBSDTM等等。

上述实施例中由航班保障任务的触发装置所执行的步骤可以基于该图4 所示的服务器结构。

还需要说明的，根据本申请的实施例，上述图1中的流程示意图描述的所述航班保障任务的触发方法的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行上述图2的流程示意图中所示的方法的程序代码。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本申请的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

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