CN106575385B - 自动售票 - Google Patents

Abstract

用于自动签发旅行凭证的方法、系统和计算机程序产品。与签发旅行凭证相关的任务由始发应用响应于预订旅行服务而生成。任务被接收并存储在第一队列中，直到触发事件，诸如用于签发凭证的时间的到达。响应于触发事件，第一队列中的任务可以被放在第二队列中，用于传送到签发应用。要被签发的凭证可以基于存储在数据库中的旅客订座记录(PNR)中的记录来确定。PNR可以基于任务来确定。PNR可以利用指示任务处理是否成功的信息来更新。在错误的情况下，指示错误的原因的信息可以被添加到PNR中。

Description

自动售票

技术领域

本发明一般而言涉及计算机和计算机系统，并且尤其涉及用于自动签发(issue)旅行相关的凭证的方法、系统和计算机程序产品。

背景技术

购买旅行服务的旅行者通常在接收旅行服务之前被签发旅行凭证。然后，旅行凭证，诸如电子票或纸质票，由旅行者兑换，以获得购买的服务。由此，旅行凭证为旅行服务提供者提供了一种确定旅行者有权接收服务的方式。旅行凭证可以基于旅客订座记录(PNR(Passenger Name Record))的内容生成。PNR通常存储在计算机化的预订系统中，并且为旅行者或一起旅行的一组旅行者定义行程。PNR通常在每次旅行服务被预订或添加到旅行时生成或修改。PNR可以由计算机系统(诸如售票和预订计算机系统)访问，以获得关于旅行者或要为旅行提供的服务的信息或者更新PNR。旅行服务提供者和旅行者通过从PNR签发的凭证连接，以完成销售。除了提供付款证明之外，签发凭证可以触发服务提供者和旅行者之间的金融结算。

为了向旅行者签发凭证，旅行社(旅行代理人)可以访问售票系统并请求一次一个地签发凭证。旅行社还可以利用突发售票(burst ticketing)为单个PNR同时签发多个凭证。突发售票导致为PNR中定义的多个服务签发旅行凭证。当同时签发多个凭证时，旅行社选择不同日期或时间签发每个旅行凭证或者在不同售票处签发凭证的能力可能受到限制。因此，如果旅行社想要在不同的天或不同的售票处签发旅行凭证，则旅行社通常必须记住为每个旅行凭证在选定的时间和地点手动地触发签发。如果旅行行程散布在多个PNR上，则突发售票可能需要单独处理每个PNR。突发售票还可以将PNR留在队列中，直到在一个或多个旅行凭证不能针对由PNR定义的服务被签发的情况下被旅行社清除。

因此，需要用于在旅游业中生成和签发旅行凭证的改进的系统、方法和计算机程序产品。

发明内容

在本发明的实施例中，提供了一种为旅行产品签发凭证的方法。该方法包括接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间。每个任务在第一队列中排队，并且响应于满足针对第一队列中的任务的触发条件，将该任务从第一队列转发到第二队列。

在本发明的另一实施例中，提供了一种用于为旅行产品签发凭证的设备。该设备包括处理器和耦合到处理器的存储器。存储器包括指令，当指令由处理器执行时，使得设备接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间。指令还使得设备在第一队列中将每个任务排队，并且响应于满足针对第一队列中的任务的触发条件，将该任务从第一队列转发到第二队列。

在本发明的另一个实施例中，提供了一种计算机程序产品，其包括包含指令的非临时性计算机可读存储介质。指令可以被配置为，当由处理器执行时，使处理器接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间。指令还使得处理器在第一队列中将每个任务排队，并且响应于满足针对第一队列中的任务的触发条件，将该任务从第一队列转发到第二队列。

附图说明

结合在本说明书中并构成其一部分的附图示出了本发明的各种实施例并且，与上面给出的本发明的一般描述以及下面给出的实施例的详细描述一起，用来解释本发明的实施例。

图1是包括经由网络通信的多个计算系统的示例性操作环境的示意图。

图2是图1的示例性计算系统的示意图。

图3是包括调度器模块、签发模块和错误管理模块的任务处理系统的示意图。

图4是可以由图3的任务处理系统执行以处理从原始应用接收的任务的调度过程的流程图。

图5是可以由图3的任务处理系统执行的、用于执行在先前尝试中具有处理错误的任务的重试过程的流程图。

图6是可以由图3的签发模块执行的排队过程的流程图。

图7是可以由图3的签发模块执行的队列管理过程的流程图。

图8是可以由图3的签发模块执行的签发过程的流程图。

具体实施方式

本发明的实施例可以由包括一个或多个联网的计算机或服务器的计算系统来实现。计算系统可以包括全球分布系统(GDS)，并且可以为提供自动售票的旅行相关的系统和模块提供处理和数据库功能。在本发明的实施例中，自动售票可以由调度器模块和签发模块实现。调度器模块可以组织和调度凭证签发任务以传送到签发模块。签发模块然后可以使凭证被签发。由此，调度器和签发模块可以协作工作，以基于从旅客订座记录(PNR)解析的一个或多个任务自动地签发旅行相关凭证。这些凭证可以包括纸质票、电子票、电子杂费凭证(EMD)、杂项费用单(MCO)、电子票记录收据、EMD旅客收据、行程收据、保险证书或任何其它旅行相关凭证。调度和签发模块可以被配置为使得凭证可以在一个或多个指定的售票处并且在期望的时间和日期自动签发。

调度器和签发模块可以具有通过允许根据需要调用附加资源来促进自动售票系统的缩放的并行配置。并行配置还可以使自动化系统能够与多个外部系统同时接口，而不对任务处理的全局流程产生负面影响。这种并行配置还可以使调度器和签发模块能够对发布到不同外部系统的任务提供独立的节流，从而保持外部系统的完整性。

现在参考图1，根据本发明实施例的操作环境10可以包括全球分布系统(GDS)12、一个或多个旅行服务提供者系统(诸如承运人系统14)、一个或多个在线旅行社或其它的间接销售方系统(诸如最终用户系统16)，以及售票系统18。GDS 12、承运人系统14、最终用户系统16和售票系统18中的每一个可以通过网络20通信。网络20可以包括使得数据能够交换的一个或多个专用或公用网络(例如，互联网)。

GDS 12可以被配置为通过使得最终用户(例如，旅行社、用于验证承运人的代理、互联网机器人，或其他间接销售方)能够经由GDS 12在一个或多个承运人系统14上搜索可用服务并且预订预留来促进承运人系统14和终端用户系统16之间的通信。为此，GDS 12可以维持经由网络20到每个承运人系统14的链路。这些链路可以允许GDS 12获得用于来自承运人系统14的服务的调度和可用性数据。由此，最终用户系统16可以经由到GDS 12的单个连接预订来自多个服务提供者的航班、火车、酒店，租车或其它旅行服务。

响应于服务被预订，GDS 12可以为那个服务接收并存储PNR，或者修改现有的PNR以反映预订的服务被添加到行程中。PNR可以至少部分地由承运人系统14生成，并且可以包括定义一个或多个预订的预留(reservation)的一个或多个预留记录。PNR还可以通过将旅行服务识别为主动的(例如，对于还由相应的服务提供者提供的服务)、被动的(例如，对于在另一系统中预留的或由第三方提供的服务)、过去的日期、已飞行、信息、开放(open)(例如，对于具有开放日期的已购买服务)或取消，来跟踪已购买的旅行服务的使用。PNR可以存储在数据库中，使得PNR可以由GDS 12、承运人系统14、最终用户系统16和售票系统18访问。PNR可以由对于那个PNR来说独特的记录定位器来识别，并且可以包括定义用于特定旅行、服务、旅客或旅客组的行程的记录。该行程可以包括来自多个承运人(例如，航班、公共汽车或铁路段)的服务、酒店预留、租车预留或任何其它旅行相关服务。

GDS 12、承运人系统14或售票系统18可以包括存储与和所购买的旅行服务相关联的旅行凭证相关的数据的一个或多个数据库。这种数据可以包括一个或多个电子优惠券，每个电子优惠券对应于由纸质票、电子票、电子杂费凭证(EMD)或杂项费用单(MCO)识别的服务。数据库还可以包括与电子票记录收据、EMD旅客收据、行程收据、保险证书或任何其它旅行相关凭证有关的记录。响应于一个或多个电子优惠券被使用、交换或退还，数据库可以被更新，以反映电子凭证的状态的改变。

售票系统18可以经由网络20或一些其它合适的连接与最终用户系统16通信。在本发明的替代实施例中，售票系统18的全部或一部分可以集成到一个或多个其它系统(诸如GDS 12)中。在任何情况下，最终用户都可以使用最终用户系统16来搜索和预订旅行服务，并且售票系统18可以签发和管理用于所购买的服务的凭证。

现在参考图2，操作环境10的GDS 12、承运人系统14、最终用户系统16、售票系统18和网络20可以在一个或多个计算设备或系统(本文统称为计算机)上实现，诸如计算机30。计算机30可以包括至少一个处理器32、存储器34、大容量存储器设备36、输入/输出(I/O)接口38和人机接口(HMI)40。计算机30还可以经由网络20或I/O接口38可操作地耦合到一个或多个外部资源42。外部资源可以包括但不限于服务器、数据库、大容量存储设备、外围设备、基于云的网络服务，或者可以由计算机30使用的任何其它合适的计算资源。

处理器32可以包括选自微处理器、微控制器、数字信号处理器、微计算机、中央处理单元、现场可编程门阵列、可编程逻辑器件、状态机、逻辑电路、模拟电路、数字电路或者基于存储在存储器34中的操作指令操纵信号(模拟或数字)的任何其它设备的一个或多个设备。存储器34可以包括单个存储器设备或多个存储器设备，包括但不限于只读存储器(ROM)、随机存取存储器(RAM)、易失性存储器、非易失性存储器、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、闪存、高速缓冲存储器，或能够存储数据的任何其它设备。大容量存储存储器设备36可以包括数据存储设备，诸如硬盘驱动器、光盘驱动器、带驱动器、非易失性固态设备，或能够存储数据的任何其它设备。

处理器32可以在驻留在存储器34中的操作系统46的控制下操作。操作系统46可以管理计算资源，使得体现为一个或多个计算机软件应用的计算机程序代码(诸如驻留在存储器34中的应用48)可以具有由处理器32执行的指令。在替代实施例中，处理器32可以直接执行应用48，在这种情况下，操作系统46可以被省略。一个或多个数据结构50也可以驻留在存储器34中，并且可以由处理器32、操作系统46或应用48使用，以存储或操纵数据。

I/O接口38可以提供将处理器32可操作地耦合到其它设备和系统(例如网络20或外部资源42)的机器接口。由此，应用48可以通过经由I/O接口38通信与网络20或外部资源42合作工作，以提供包括本发明实施例的各种特征、功能、应用、过程或模块。应用48还可以具有由一个或多个外部资源42执行或者以其它方式依赖由在计算机30外部的其它系统或网络部件提供的功能或信号的程序代码。实际上，给定几乎无限的可能硬件和软件配置，本领域普通技术人员将理解，本发明的实施例可以包括这样应用和数据库，它们位于计算机30外部、分布在多个计算机或其它外部资源42中，或者由经网络20被提供作为服务(诸如云计算服务)的计算资源(硬件和软件)提供。

HMI 40可以以已知方式可操作地耦合到计算机30的处理器32，以允许用户直接与计算机30交互。HMI 40可以包括视频或字母数字显示器、触摸屏、扬声器和任何其它能够向用户提供数据的合适的音频和视觉指示器。HMI 40还可以包括能够接受来自用户的命令或输入并将录入的输入发送到处理器32的输入设备和控件，诸如字母数字键盘、指向设备、小键盘、按钮、控制旋钮、麦克风等。

数据库44可以驻留在大容量存储存储器设备28上，并且可以被用来收集和组织由本文所述的各种系统和模块使用的数据。数据库44可以包括数据以及存储和组织数据的支持数据结构。特别地，数据库44可以用任何数据库组织或结构来布置，包括但不限于关系数据库、分层数据库、网络数据库，或其组合。以在处理器24上作为指令执行的计算机软件应用的形式的数据库管理系统可以被用来响应于查询而访问存储在数据库44的记录中的信息或数据，其中查询可以由操作系统46、其它应用48或一个或多个模块动态地确定和执行。

现在参考图3，任务处理系统60可以包括调度器模块62、签发模块64和错误管理模块66。调度器模块62可以被配置为从可以在GDS 12、最终用户系统16或售票系统18上操作的始发应用接收任务68。调度器模块62还可以被配置为处理多种任务类型，包括来自其它应用的任务68。任务68可以包括例如自动售票可靠性相关的任务、具体PNR元素的取消(例如，任务类型＝“PNR元素取消”)，或任何其它合适类型的任务。任务68可以涉及凭证(诸如纸质票、电子票、EMD、MCO或任何其它合适的旅行凭证)的签发。作为例子，任务68可以由最终用户在经由最终用户系统16预订旅行服务期间发起。最终用户可以选择签发的日期和时间、签发办公室、要打印什么许可证(comfort documents)，并将这种数据作为记录存储在对应的PNR中。最终用户还可以在预订时打印相关联的许可证，或者选择手动签发一个或多个凭证。

调度器模块62可以与签发模块64合作工作，以通过与外部系统(诸如售票系统18、电子凭证数据库70、销售报告数据库72和PNR数据库74)通信来签发凭证和更新数据库。错误管理模块66可以从调度器模块62和签发模块64接收状态消息75，并通过最终用户系统16将对应的状态更新传送给最终用户。

调度器模块62可以包括任务管理器76、多个队列或数据库78a-78n，以及递送管理器80。任务管理器76可以接收任务68并将每个任务68存储在数据库78a-78n之一当中。任务68可以基于任务68的类型被存储到数据库78a-78n，使得不同类型的任务68通过类型被隔离。为此，任务管理器76可以在接收到任务68时识别任务68的类型，并将任务68存储在数据库78a-78n中对应的一个当中。

递送管理器80可以包括一个或多个调度守护进程82，其从数据库78a-78n检索任务并将任务68分组成队列或任务列表84a-84m，用于传送到签发模块64。调度守护进程82可以包括用于每个任务类型的单独的守护进程82，并且可以以可单独选择的频率查询它们相应的数据库78a-78n。由此，准备好被处理的任务68可以以对应于所讨论的任务类型的预期处理时间的速率(例如，每秒的任务数)被发送到签发模块64。为此，调度守护进程82可以包括调整任务被出列的速率的节流特征。

每个任务列表84a-84m可以包括准备好被处理的多个任务。每个列表的任务数量以及列表的配置可以由最终用户确定。每个列表可以例如包括对应于具体PNR任务、与具体旅行相关联的一组PNR、要在特定时间或地点签发的一个或多个凭证，或者被调度在大约同一时间处理的一组任务。在本发明的实施例中，递送管理器80可以响应于生成的任务列表84a-84m而将任务列表84a-84m排队，以便传送到签发模块64。因此，调度守护进程82可以确定任务68何时被传送到签发模块64用于处理。

签发模块64可以包括列表缓冲器86、排队守护进程88、签发管理器90以及多个售票识别器(TID)92。列表缓冲器86可以包括被配置为接收任务列表(诸如示例性任务列表84o)的任务队列。响应于任务列表84o中的所有任务都被接收和排队，列表缓冲器可以向调度器模块62传送应答94。响应于从签发模块64接收到指示任务列表84o已经由列表缓冲器86成功排队的应答94，接收到的任务列表84o可以在调度器模块62中出列。

排队守护进程88可以通过从任务队列中移除任务68并且向签发管理器90传送请求以处理被移除的任务68来管理任务队列。响应于从排队守护进程88接收到请求，签发管理器90可以从多个售票识别器92中选择售票识别器92。每个售票识别器92可以被配置为与一个或多个凭证签发应用或数据库通信。凭证签发应用可以由外部系统(诸如售票系统18)提供。数据库可以包括电子凭证数据库70、销售报告数据库72或PNR数据库74。凭证签发应用可以生成对应于任务68的凭证并且数据库被相应地更新，以处理任务68。响应于任务68被处理，签发管理器90可以向调度器模块62传送指示任务68已经被处理的任务状态消息95。在任务68不能被处理的情况下，任务状态消息95可以向调度器模块62指示这一点，使得该任务可以被重新传送送到签发模块64。

错误管理模块66可以包括图形用户接口(GUI)96、定制设置97和报告管理器98。调度器模块62和签发模块64可以将状态消息75发送到错误管理模块66，使得错误管理模块66可以基于状态消息75生成报告文件。报告生成可以在非工作时间作为批处理运行。最终用户可以经由GUI 96访问这些状态报告，以确定自动化的凭证签发过程的状态。在本发明的实施例中，报告可以被格式化为网页并且通过web浏览器应用访问。

状态报告可以是定制的，并且可以被发送到一个或多个预定义的地址。签发结果可以存储在数据库(未示出)中，并且由最终用户经由GUI 96查看。由此，最终用户可以在预定义时段期间访问统计信息。这些统计信息可以包括成功的签发、失败的签发、失败和成功签发的百分比、失败任务的失败身份号码(failure identity numbers)、打印凭证的数量、排名、最频繁的错误或任何其它合适的统计信息。GUI 96还可以允许最终用户确定针对错误的可能的变通方法(workaround)、访问维护记录参考、确定当前过程的状态，以及访问PNR数据库74中的PNR。

报告管理器98可以基于状态报告、签发结果和系统统计信息来生成报告文件。报告文件可以在任何时间、以任何格式并且经由不同的媒体(诸如通过电子邮件或任何其它合适的通信媒体)被传送到最终用户。GUI 96还可以使最终用户能够通过调整定制设置97来定制报告文件。由此，可以裁剪通知，以向既定的最终用户警告具体事件。例如，报告管理器98可以被配置为响应于接收到指示已经发生大量签发故障的状态消息75而向系统技术人员发送呼叫。作为另一个例子，报告管理器98可以被配置为响应于接收到指示任务状态已改变的状态消息75而向最终用户发送电子邮件。错误管理模块66还可以被配置为将在自动售票过程期间既定的时间段检测到的事件和执行的动作归档。

现在参考图4，流程图绘出了可以由调度器模块62实现的调度过程100。在方框102中，调度过程100从始发应用接收任务68。始发应用可以是在GDS 12、承运人系统14之一、最终用户系统16、售票系统18或任何其它合适的系统上运行的应用。例如，最终用户可以通过从最终用户系统16报价(quote)和预订旅行服务(诸如航班)来生成或修改PNR。然后最终用户可以向PNR添加一个或多个记录，指示：(1)什么凭证要被签发；(2)签发凭证的日期、时间和地点；及(3)应当为旅行者生成哪些许可证。当最终用户完成旅行服务的预订时，最终用户可以验证交易。响应于最终用户验证交易，解析应用可以检测与预订相关联的PNR活动性，并且创建被发送到调度器模块62的任务68。这个任务68可以被命名为例如“自动售票”并传送到调度器模块62。

响应于接收到任务68，调度过程100可以前进到方框104。在方框104中，调度过程100可以将每个任务68存储在对应于正被存储的任务68的类型的数据库78a-78n中。为此，任务管理器76可以被配置为确定接收到的任务68的类型。任务68的类型可以包括但不限于自动售票、签发纸质票、签发电子票、签发EMD、签发MCO、签发收据或任何其它合适的任务。

响应于任务68被存储在数据库78a-78n中，调度过程100可以前进到方框106。在方框106中，调度过程100可以向始发应用传送任务68已经被接收到的应答。然后调度过程100可以前进到方框108。

在方框108中，调度过程100可以定义任务列表84a-84m。为此，调度守护进程82可以从数据库78a-78n中选择任务并将每个任务添加到任务列表84a-84m之一。任务68可以基于事件的发生(诸如请求任务的处理的时间或日期的到期)来选择。例如，调度守护进程82可以基于凭证的签发时间或日期来查找任务68并将其分组到任务列表84a-84m中。任务68可以通过任务68的类型进行分组，以基于接收任务68的系统提高可扩展性，并提高系统性能。任务68还可以基于功能标准(诸如办公室ID、市场和PNR)来进行分组。

响应于任务68被分组到任务列表84a-84m中，过程可以前进到方框110。在方框110中，任务列表84a-84m可以被传送到签发模块64。散列验证可以被用来验证从调度器模块62传送到签发模块64的任务68和任务列表84a-84m。然后调度过程100可以前进到方框112并且确定签发模块64是否接收到任务列表。这个确定可以例如响应于从签发模块64接收到应答94而做出。

响应于确定未接收到任务列表84a-84m(判定框112的“否”分支)，调度过程100可以前就到方框114并且实现针对失败传送的重试策略。这些重试策略可以由最终用户定制，并且可以包括可选择的参数，诸如：(1)下一次重试尝试之前的初始延迟；(2)重试尝试之间的延迟增加量；(3)最多允许的重试尝试；(4)最大允许的延迟；及(5)超时参数。

响应于确定任务列表84a-84m被签发模块64接收到(判定框112的“是”分支)，调度过程100可以前进到方框116。在方框116中，调度过程100可以从递送管理器80清除接收的任务列表84a-84m。在本发明的实施例中，任务列表84a-84m可以各自包括指针数组，其中每个指针充当对于存储在数据库78a-78n之一中的任务68的索引。

在方框118中，调度过程100可以确定是否处理了传送到签发模块64的任务列表84a-84m之一中的任务68之一。这个确定可以基于从签发模块64接收的任务状态消息95做出。响应于确定任务未被处理(判定块118的“否”分支)，该过程可以前进到方框114并且实现针对失败任务的重试策略。针对失败任务的重试策略可以包括类似于上面关于任务列表84a-84m的失败传送所描述的最终用户可选择的参数。即，重试参数可以包括：(1)初始延迟参数；(2)重试尝试参数之间的延迟增加量；(3)最大允许的重试尝试参数；(4)最大允许的延迟参数；及(5)超时参数。

如果调度过程100确定已经处理了任务68(判定框118的“是”分支)，则调度过程100可以前进到方框120并从对应的数据库78a-78n清除任务68。因为本发明的实施例一直等到确认所接收到的任务68的处理才从数据库78n-78m清除任务68，所以可以保证被调度的任务68的传送。

本发明的实施例可以包括由调度器模块62实现的多个重试策略。这些重试策略可以被应用在传输级和处理级。此外，每个任务类型可以具有对应的一组重试配置参数，其定义用于那个类型的任务的重试周期。完整的重试周期可以由一次或多次尝试，或“循环”，组成，这取决于针对那个任务的参数设置。

现在参考图5，流程图绘出了可以由调度器模块62执行以在调度过程100的方框114中实现重试策略的重试过程130。在方框132中，重试过程130可以确定错误是由于任务列表84a-84m之一的传送失败还是由于处理任务68的失败。响应于确定该错误不是任务列表接收错误(判定块132的“否”分支)，重试过程130可以前进到方框134。例如，如果调度过程100由于任务处理失败(例如，从图4中的方框118)而进入方框114，则这可能发生。

如果该错误是任务列表接收错误(判定块132的“是”分支)，则重试过程130可以前进到方框136。在方框136中，重试过程130可以确定当前失败是否是针对所讨论的任务列表84a-84m的第一次传送失败。响应于确定当前失败是针对任务列表84a-84m的第一次传送失败(判定块136的“是”分支)，重试过程130可前进到方框138并在前进到方框140之前将重试延迟设置为初始延迟值。响应于确定当前失败不是第一次传送失败(判定框136的“否”分支)，重试过程130可以前进到方框142。

在方框142中，重试过程130可以确定调度器模块62已经尝试向签发模块64发送多少次任务列表84a-84m。响应于确定尝试的传送数量超过重试尝试的最大数量(判定块142的“是”分支)，重试过程130可以前进到方框144并重新调度任务列表84a-84m的传送。重新调度可以包括例如使调度器模块62的调度守护进程82将来自数据库78a-78n的失败任务列表中的任务添加到一个或多个新任务列表84a-84m。即，调度器模块62可以重新开始向签发模块64发送任务68的过程。

如果尝试的传送数量没有超过重试尝试的最大可允许数量(判定块142的“否”分支)，则重试过程130可以前进到方框146。在方框146中，重试过程130可以确定重试尝试之间的当前延迟是否超过最大可允许的延迟。响应于确定延迟超过最大可允许的延迟(判定框144的“是”分支)，重试过程130可以前进到方框144并如上所述重新调度任务。响应于确定延迟没有超过最大延迟(判定框146的“否”分支)，重试过程130可以前进到方框148。

在方框148中，重试过程130可以确定任务列表84a-84m的传送是否已经超时。即，从向签发模块64发送任务列表84a-84m的第一次尝试起已经经过了超过最大可允许的时间量的时间。响应于确定传送过程已超时(判定块148的“是”分支)，重试过程130可以前进到方框144并如上所述重新调度任务。响应于确定传送过程尚未超时(判定框148的“否”分支)，重试过程130可以前进到方框150，并且在前进到方框140之前递增延迟。延迟可以递增预定的量、基于已经进行了多少次重试尝试、任务列表中的任务类型或任何其它合适的参数而确定的量。在方框140中，重试过程130可以通过以用于重传的延迟将任务列表84a-84m重新排队来重新尝试将任务列表84a-84m传送到签发模块64。

在本发明的替代实施例中，重试过程130可以在确定是否重新尝试传送任务列表84a-84m时包括或省略重试尝试、最大延迟或超时参数中的任何参数。此外，本发明的实施例可以允许最终用户选择哪些参数被用来定义重试过程130。这些参数也可以依赖于构成正被发送的任务列表84a-84m的任务68的类型而被设置为不同的值。在任何情况下，被保证的传送都可以是可选的，并且可以遵循全有或全无策略来保证任务列表84a-84m的传送。即，或者来自任务列表84a-84m的所有任务68都被接收，或者任务列表84a-84m的传送被认为失败。

现在回到方框134，处理错误可以指示未能处理来自任务列表84a-84m的特定任务68。响应于确定处理错误不是致命的(判定框134的“否”分支)，重试过程130可以前进到方框144并重新调度任务68以进行处理。响应于确定处理错误是致命的(判定框134的“是”分支)，重试过程130可以前进到方框152。例如，如果调度器模块62、签发模块64或者错误管理模块66确定任务68不能被处理，则处理错误可以是致命的。处理错误也可以由于以下原因而被认为是致命的，例如：(1)针对所讨论的任务的重新调度尝试的次数超过重新调度尝试的最大可允许的次数；(2)直到下一次重新调度尝试之前的延迟超过最大可允许的延迟；或(3)超时参数被超过。即，关于确定是否重新尝试任务列表的传送，重试过程130可以应用类似的一组标准来确定是否重新调度任务68。从重试过程130退出的失败任务68可以被维持在被拒绝的任务队列中，以便于系统监视和对系统错误的跟踪。

签发模块64的列表缓冲器86可以被配置为通过将应答94传送到调度器模块62的递送管理器80来应答任务列表84o的接收。响应于给定日期和时间的所有交易列表都在签发模块64被接收，签发模块64可以通过打开对应的PNR来处理任务。然后可以签发所请求的凭证(例如，票据、EMD、MCO等)和如由对应PNR中的任务记录指示的匹配的许可证。签发这些凭证的系统(诸如售票系统18)可以在任务处理系统60的外部。每小时可以由这些外部系统签发的凭证的数量可以依赖所讨论的外部系统的技术能力而变化。

为了优化每小时可以处理的PNR的数量，签发模块64可以包括多个售票识别器(TID)92。售票识别器92可以被配置为接受由签发管理器90生成的签发请求。售票识别器92可以与外部系统通信，以处理签发请求以及接收和处理从外部系统接收的任何错误消息。

现在参考图6，流程图绘出了可以由签发模块64执行的排队过程160。在方框162中，从调度器模块62接收任务列表84o。任务列表84o可以由列表缓冲器86接收。在方框164中，排队过程160可以在前进到方框166之前将任务列表84o的任务68存储在本地队列中。将任务68存储在本地队列中可以通过使签发模块64能够响应于处理错误而重新启动从本地队列的签发过程来提供附加的可靠性级别。由此，本地队列可以使签发模块64能够避免由调度器模块62响应于任务处理错误而请求任务列表84o的重新发送。

在方框166中，排队过程160可以确定任务68是否无错误地排队。响应于确定任务列表84o的所有任务68都无错误地排队(判定框166的“是”分支)，排队过程160可以前进到方框168，并且向调度器模块62传送应答94，其具有任务68被接收到的指示。响应于确定任务列表84o的一个或多个任务68不能排队(判定块166的“否”分支)，排队过程160可以前进到方框170，并且发送应答94，其具有任务列表84o的任务68未成功排队的指示。

现在参考图7，流程图绘出了可以由排队守护进程88执行的队列管理过程180。在方框182中，队列管理过程180可以读取任务列表84o的任务68之一。在方框184中，队列管理过程180可以将任务68传送到签发管理器90并前进到方框186。在方框186中，队列管理过程180可以等待来自签发管理器90的应答。响应于确定签发管理器90应答接收到任务68(判定框186的“是”分支)，队列管理过程180可以前进到方框188并从本地队列中移除任务68。响应于签发管理器90未能应答接收任务68或以其它方式指示接收任务68的错误(判定框186的“否”分支)，队列管理过程180可以前进到方框190并调度重试尝试。

排队守护进程88可以通过确定签发管理器90是否不可用以及将任务68维持在本地队列中直到签发管理器90可用，来提供附加级别的可靠性。因为每个凭证签发系统可以具有处理签发请求的有限能力，所以排队守护进程88可以包括节流特征。节流特征可以根据任务68被寻址到的凭证签发系统所支持的负荷(例如，每秒的交易量)来调整出列速率。这个速率可以依赖于针对所讨论的文件签发系统的已知响应时间而变化。由此，签发模块64可以独立地控制将交易发送到每个凭证签发系统的速率。

现在参考图8，流程图绘出了可以由签发管理器90执行的签发过程200。在方框202中，签发过程200可以从排队守护进程88接收任务68。响应于接收到任务68，签发过程200可以前进到方框204并且通知排队守护进程88已经接收到任务68。这个通知可以是对任务68的接收的应答的形式。然后签发过程200可以前进到方框206。

在方框206中，签发过程200可以请求签发管理器90和售票识别器92之一之间的连接。售票识别器92可以例如基于可用性来选择。为此，签发过程200可以检测售票识别器92是否在使用中，并且等待第一可用的售票识别器92来处理下一个任务。以这种方式，如果资源暂时不可用，则签发过程200可以防止任务68丢失。

签发过程200可以前进到方框208并且确定在签发管理器90和所选择的售票识别器92之间是否已经建立了连接。响应于签发过程200检测到将售票识别器92错误连接到签发管理器90(判定框208的“是”分支)，签发过程200可以通过前进到方框212进入错误管理过程210。响应于签发过程200确定没有将售票识别器92连接到签发管理器90的错误(判定框208的“否”分支)，签发过程200可以前进到方框214。

在方框214中，签发过程200可以检索由正在被处理的任务68识别的PNR。为此，签发过程200可以使售票识别器92向PNR数据库74传送请求。售票识别器92可以通过与计算系统之一(诸如GDS 12、承运人系统14之一、售票系统18或提供对PNR数据库74的访问的任何其它系统)建立通信链路来与PNR数据库74连接。

在方框216中，签发过程200可以确定是否在接收PNR时发生错误。响应于确定发生错误(判定框216的“是”分支)，签发过程200可以通过前进到方框212进入错误管理过程210，如上所述。响应于确定未发生错误(判定框216的“否”分支)，签发过程200可以前进到方框218。

在方框218中，签发过程200可以请求签发凭证。该请求可以由售票识别器92签发。为了定义该请求，可以解析PNR，以确定必须签发什么凭证以满足任务68，以及哪些系统应当签发凭证。签发过程200还可以确定要签发的凭证是否先前已经签发。这个确定可以基于PNR中指示所讨论的凭证被签发的记录。如果凭证还没有签发，则售票标识符92可以向识别出的系统传送签发请求。响应于接收到签发请求，签发系统可以签发凭证。签发系统可以通过电子邮件、传真、短消息服务(SMS)、多媒体消息服务(MMS)、普通邮件或任何其它合适的方式将签发的凭证发送给旅行者。

在方框220中，签发过程200可以确定签发凭证是否存在错误。这种确定可以基于例如售票识别器92从签发系统接收的应答。响应于确定在签发凭证时发生错误(判定框220的“是”分支)，签发过程200可以通过前进到方框212进入错误管理过程210，如上所述。响应于确定未发生错误(判定框220的“否”分支)，签发过程200可以前进到方框222并释放售票识别器92。然后签发过程200可以前进到方框224并且将任务状态消息95发送到调度器模块62。

在方框212中，错误管理过程210可以确定签发管理器90是否应当重试任务68的处理。这个确定可以基于发生的错误的类型、先前进行的重试尝试的次数、重试尝试已在进行中多长时间、任务的类型或任何其它合适的参数。响应于错误管理过程210确定应当进行重试尝试(判定框212的“是”分支)，错误管理过程210可以前进到方框226。在方框226中，错误管理过程210可以调度重试尝试并前进到方框206，以开始重试过程。

响应于确定不应当进行重试尝试(判定框212的“否”分支)，错误管理过程210可以前进到方框228。在方框228中，错误管理过程210可以将记录添加到PNR，从而记录由任务处理系统60采取的动作，以及签发凭证的任何错误。这个记录可以使最终用户能够确定哪些凭证尚未签发，以及为什么，以便最终用户可以纠正任何问题。由此，最终用户可以通过访问PNR来确定自动处理的状态。依赖于这个状态，最终用户可以例如编辑PNR以取消签发、改变凭证要被签发的时间或改变签发的地点。最终用户还可以选择当任务的状态被更新时如何通知他们。在任何情况下，响应于在方框228中PNR被更新，签发过程200都可以退出错误管理过程210并且前进到方框224。在方框224中，签发过程200可以将任务状态消息95传送到调度器模块62，如上所述。

在操作中，最终用户可以通过报价和预订旅行服务(诸如航班)来修改或生成PNR。然后最终用户可以向PNR添加指示要签发哪些凭证、要签发凭证的日期、时间和地点以及要打印哪些许可证的记录。响应于最终用户完成交易，交易可以被验证。解析器应用可以检测PNR活动性并生成自动化的售票任务。解析器应用可以驻留在例如GDS 12上或者可以访问PNR数据库74的任何其它系统上。

自动化的售票任务可以被发送到调度器模块62。然后，调度器模块62可以在预定时间将自动化的售票任务传送到签发模块64。为此，调度守护进程82之一可以以预定义的频率操作，以通过类型和调度的处理日期生成任务列表84a-84m。然后任务列表84a-84m可以通过被保证的传送过程被发送到签发模块64。这个过程的可靠性可以通过数据库持久性和队列到队列体系架构来确保。

由调度器模块62处理的任务68可以在数据库78a-78n、队列和调度守护进程82级别彼此隔离。为了确保每个任务的唯一性，可以使用散列计算。散列计算可以基于将大的、有可能可变大小的数据量转换为用作阵列中的索引的小数据(诸如整数)的数学函数。

然后可以响应于从签发模块64传送的签发请求而由外部系统签发凭证。这些外部系统的完整性可以通过签发模块64节流传送到每个外部系统的签发请求的数量来保持。这种节流可以将每秒传送到特定外部系统的交易的数量调节到那个系统已知是可接受的水平。由此节流特征可以改变到外部系统的传送速率。

如果先前签发了所讨论的凭证，则签发模块64可以确定这一点并将该任务标记为完成，而不采取进一步的动作。签发模块64还可以识别特定的签发错误并确定是立即重试、稍后重试还是放弃任务。在致命错误的情况下，签发模块64可以向PNR添加指示这一状况的记录并将PNR发送给最终用户。由此可以向最终用户通知需要采取手动动作。响应于任务被成功处理，签发模块64可以向调度器模块62发送应答这个结果的通知。然后调度器模块62可以更新任务68的状态并从数据库78a-78n中移除该任务。

实施本文所述的本发明任何实施例的程序代码能够以各种不同形式作为程序产品单独地或集体地分送(distribute)。特别地，程序代码可以利用计算机可读介质来分送，计算机可读介质可以包括计算机可读存储介质和通信介质。固有地非临时性的计算机可读存储介质可以包括以用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术实现的易失性和非易失性以及可移动和不可移动的有形介质。计算机可读存储介质还可以包括RAM、ROM、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、闪存或其它固态存储器技术、便携式光盘只读存储器CD-ROM)或其它光学储存器、磁带盒、磁带、磁盘储存器或其它磁性存储设备或者可被用来存储期望的信息并可由计算机读取的任何其它介质。通信介质可以使计算机可读指令、数据结构或其它程序模块具体化。作为例子而非限制，通信介质可以包括有线介质(诸如有线网络或直接连线的连接)以及无线介质(诸如声学、RF、红外和其它无线介质)。任何上述的组合也可以包括在计算机可读介质的范围内。

本文所述的方法可以由提供给任何类型的计算机的处理器的计算机程序指令来实现，以产生具有执行指令以实现本文所指定的功能/动作的处理器的机器。这些计算机程序指令还可以存储在计算机可读介质中，可以指示计算机以特定方式工作。为此，计算机程序指令可以被加载到计算机上，以使得执行一系列操作步骤，并由此产生计算机实现的过程，使得所执行的指令提供用于实现本文所指定的功能/动作的过程。

此外，本文所述的程序代码可以基于其中程序代码在本发明具体实施例中实现的应用或软件部件来识别。但是，应当认识到，以下的任何特定程序命名仅仅是为了方便而使用，因此本发明不应当限于仅在由这样的命名法识别或暗示的任何特定应用中使用。还应当认识到，本文公开的各种特征、应用和设备也可以单独使用或以任何组合使用。而且，给定计算机程序可以被组织为例程、过程、方法、模块、对象等的通常无限数量的方式，以及程序功能可以在驻留在典型计算系统(例如，操作系统、库、API、应用、小应用程序等)内或跨一个或多个硬件平台的各种软件层之间分配的各种方式，应当认识到，本发明不限于本文所述的程序功能的具体组织和分配。

本文所使用的术语仅用于描述特定实施例的目的，而不意在限制本发明。如本文所使用的，除非上下文另有明确说明，否则单数形式“一”、“一个”和“该”也意在包括复数形式。还应当理解，当在本说明书中使用时，术语“包括”指定所述特征、整数、步骤、操作、元件或部件的存在，但不排除一个或多个其它特征、整数、步骤、操作、元件或部件或其组的存在或添加。此外，就在详细说明书或权利要求中使用术语“包含”、“具有”、“由...组成”或其变体的程度而言，这种术语以类似于术语“包括”的方式预期是包含性的。

虽然已经通过各种例子的描述示出了本发明的实施例，并且虽然已经相当详细地描述了这些实施例，但是申请人的意图不是约束或以任何方式限制所附权利要求的范围到这样的细节。附加的优点和修改对于本领域技术人员将是显而易见的。因此，本发明在其更广泛的方面不限于所示出和描述的具体细节、代表性方法和说明性例子。相应地，在不背离申请人的总体发明构思的精神或范围的情况下，可以对这些细节进行改变。

Claims (20)

1.一种为旅行产品签发凭证的方法，该方法包括：

在计算机接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间；

由计算机将每个任务在第一队列中排队；

响应于满足针对第一队列中的第一任务的触发条件，由计算机将第一任务从第一队列转发到第二队列；

响应于第一任务在第二队列中被排队，由计算机生成签发请求；

由计算机在第一售票识别器和第一签发应用之间建立链接，第一签发应用具有每单位时间能够被处理的最大交易数量；

由计算机经由所述链接向第一签发应用传送所述签发请求，所述签发请求是要传送到第一签发应用的多个签发请求中的一个签发请求；

由计算机基于每单位时间的最大交易数量，调整签发请求被传送到第一签发应用的速率；及

响应于所述签发请求被第一签发应用处理，由计算机释放第一售票识别器；

其中，接收包括由递送管理器使用至少一个调度守护进程从至少一个数据库检索任务，并且至少一个调度守护进程以可单独选择的频率查询所述至少一个数据库并以每秒的任务数的速率将任务传送到包括第二队列的签发模块，每秒的任务数的速率对应于在签发模块处所述任务的预期处理时间，

其中，第二队列的任务被存储在本地队列中，并使签发模块能够响应于处理错误而重新启动从本地队列的签发过程，并且能够避免由调度器模块响应于任务处理错误而请求第二队列的重新传送，

其中，排队守护进程确定由签发模块包含的签发管理器是否不可用，以及将任务维持在本地队列中直到签发管理器可用为止，以及

其中，如果有以下情况，则重新启动签发过程：

i)尝试的传送数量不超过重试尝试的最大可允许数量，

ii)重试尝试之间的当前延迟不超过最大可允许的延迟，以及

iii)第一队列的传送还没有超时，即，从向签发模块传送第一队列的第一次尝试起，不超过最大可允许的时间量。

2.如权利要求1所述的方法，还包括：

将第一任务在第二队列中排队；及

响应于第一任务在第二队列中被排队，从第一队列中移除第一任务。

3.如权利要求1所述的方法，其中第一任务与第一队列中的第二任务相关，并且还包括：

使第一任务和第二任务成组；

将第二任务在第二队列中排队；及

响应于第一任务和第二任务在第二队列中被排队，将第一任务和第二任务作为一批从第一队列中移除。

4.如权利要求3所述的方法，其中第一任务和第二任务通过与旅客订座记录的共同关联而相关。

5.如权利要求1所述的方法，其中触发条件包括实际时间到达签发第一任务的时间。

6.如权利要求1所述的方法，其中第一队列包括第一数据库和第二数据库，并且将每个任务在第一队列中排队包括：

确定每个任务的类型；及

对于每个任务，如果该任务属于第一类型，则将该任务存储在第一数据库中，或者，如果该任务属于第二类型，则将该任务存储在第二数据库中。

7.如权利要求6所述的方法，还包括：

以第一频率在第一数据库查询满足所述触发条件的任务；及

以第二频率在第二数据库查询满足所述触发条件的任务，

其中第二频率不同于第一频率。

8.如权利要求1所述的方法，还包括：

响应于凭证由第一签发应用签发，从第一队列中移除第一任务。

9.如权利要求1所述的方法，其中：

第一售票识别器选自包括第一售票识别器和第二售票识别器的多个售票识别器；及

第一签发应用是由第一售票识别器基于由任务指定的售票处从第一签发应用和第二签发应用中选择出的。

10.如权利要求1所述的方法，其中签发请求是基于与第一任务相关联的旅客订座记录生成的。

11.一种为旅行产品签发凭证的设备，该设备包括：

处理器；和

耦接到处理器的存储器，包括当被处理器执行时使得所述设备执行以下操作的指令：

接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间；

将每个任务在第一队列中排队；

响应于满足针对第一队列中的第一任务的触发条件，将第一任务从第一队列转发到第二队列；

响应于第一任务在第二队列中被排队，生成签发请求；

在第一售票识别器和第一签发应用之间建立链接，第一签发应用具有每单位时间能够被处理的最大交易数量；

经由所述链接向第一签发应用传送所述签发请求，所述签发请求是要传送到第一签发应用的多个签发请求中的一个签发请求；

基于每单位时间的最大交易数量，调整签发请求被传送到第一签发应用的速率；及

响应于所述签发请求被第一签发应用处理，释放第一售票识别器；

其中，接收包括由递送管理器使用至少一个调度守护进程从至少一个数据库检索任务，并且至少一个调度守护进程以可单独选择的频率查询所述至少一个数据库并以每秒的任务数的速率将任务传送到包括第二队列的签发模块，每秒的任务数的速率对应于在签发模块处所述任务的预期处理时间，

其中，第二队列的任务被存储在本地队列中，并使签发模块能够响应于处理错误而重新启动从本地队列的签发过程，并且能够避免由调度器模块响应于任务处理错误而请求第二队列的重新传送，

其中，排队守护进程确定由签发模块包含的签发管理器是否不可用，以及将任务维持在本地队列中直到签发管理器可用为止，以及

其中，如果有以下情况，则重新启动签发过程：

i)尝试的传送数量不超过重试尝试的最大可允许数量，

ii)重试尝试之间的当前延迟不超过最大可允许的延迟，以及

iii)第一队列的传送还没有超时，即，从向签发模块传送第一队列的第一次尝试起，不超过最大可允许的时间量。

12.如权利要求11所述的设备，其中第一任务与第一队列中的第二任务相关，并且所述指令还被配置为使得所述设备执行以下操作：

将第一任务在第二队列中排队；及

响应于第一任务在第二队列中被排队，从第一队列中移除第一任务。

13.如权利要求11所述的设备，其中第一任务与第一队列中的第二任务相关，并且所述指令还被配置为使得所述设备执行以下操作：

使第一任务和第二任务成组；

将第二任务在第二队列中排队；及

响应于第一任务和第二任务在第二队列中被排队，将第一任务和第二任务作为一批从第一队列中移除。

14.如权利要求13所述的设备，其中第一任务和第二任务通过与旅客订座记录的共同关联而相关。

15.如权利要求11所述的设备，其中触发条件包括实际时间到达签发第一任务的时间。

16.如权利要求11所述的设备，其中第一队列包括第一数据库和第二数据库，并且所述指令使得所述设备通过执行以下操作来将每个任务在第一队列中排队：

确定每个任务的类型；及

对于每个任务，如果该任务属于第一类型，则将该任务存储在第一数据库中，或者，如果该任务属于第二类型，则将该任务存储在第二数据库中。

17.如权利要求16所述的设备，其中所述指令还被配置为使得所述设备执行以下操作：

以第一频率在第一数据库查询满足所述触发条件的任务；及

以第二频率在第二数据库查询满足所述触发条件的任务，

其中第二频率不同于第一频率。

18.如权利要求11所述的设备，其中所述指令还被配置为使得所述设备执行以下操作：

响应于凭证由第一签发应用签发，从第一队列中移除第一任务。

19.如权利要求11所述的设备，其中：

第一售票识别器选自包括第一售票识别器和第二售票识别器的多个售票识别器；及

第一签发应用是由第一售票识别器基于由任务指定的售票处从第一签发应用和第二签发应用中选择出的。

20.一种非暂时性的计算机可读存储介质，所述非暂时性的计算机可读存储介质上存储有指令，所述指令在被处理器执行时使得处理器执行以下操作：

接收定义多个任务的数据，每个任务与凭证的签发相关并且具有签发时间；

将每个任务在第一队列中排队；

响应于满足针对第一队列中的第一任务的触发条件，将第一任务从第一队列转发到第二队列；

响应于第一任务在第二队列中被排队，生成签发请求；

在第一售票识别器和第一签发应用之间建立链接，第一签发应用具有每单位时间能够被处理的最大交易数量；

经由所述链接向第一签发应用传送所述签发请求，所述签发请求是要传送到第一签发应用的多个签发请求中的一个签发请求；

基于每单位时间的最大交易数量，调整签发请求被传送到第一签发应用的速率；及

响应于所述签发请求被第一签发应用处理，释放第一售票识别器；

其中，接收包括由递送管理器使用至少一个调度守护进程从至少一个数据库检索任务，并且至少一个调度守护进程以可单独选择的频率查询所述至少一个数据库并以每秒的任务数的速率将任务传送到包括第二队列的签发模块，每秒的任务数的速率对应于在签发模块处所述任务的预期处理时间，

其中，第二队列的任务被存储在本地队列中，并使签发模块能够响应于处理错误而重新启动从本地队列的签发过程，并且能够避免由调度器模块响应于任务处理错误而请求第二队列的重新传送，

其中，排队守护进程确定由签发模块包含的签发管理器是否不可用，以及将任务维持在本地队列中直到签发管理器可用为止，以及

其中，如果有以下情况，则重新启动签发过程：

i)尝试的传送数量不超过重试尝试的最大可允许数量，

ii)重试尝试之间的当前延迟不超过最大可允许的延迟，以及

iii)第一队列的传送还没有超时，即，从向签发模块传送第一队列的第一次尝试起，不超过最大可允许的时间量。