Travelport Booking Feed

Transcription

1 Version November 2012

2 THE INFORMATION CONTAINED IN THIS DOCUMENT IS CONFIDENTIAL AND PROPRIETARY TO TRAVELPORT. Copyright Copyright Travelport and/or its subsidiaries. All rights reserved. Travelport provides this document for information purposes only and does not promise that the information contained in this document is accurate, current or complete. This document is subject to change without notice.. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the licensee s personal use without the prior written permission of Travelport and/or its subsidiaries. Trademarks Travelport and/or its subsidiaries may have registered or unregistered patents or pending patent applications, trademarks copyright, or other intellectual property rights in respect of the subject matter of this document. The furnishing of this document does not confer any right or license to or in respect of these patents, trademarks, copyright, or other intellectual property rights. All other companies and product names are trademarks or registered trademarks of their respective holders. 26 November 2012 Travelport ii

3 Contents Introduction... 1 Background... 1 Benefits... 1 Supporting Documentation... 2 Data Types... 2 Data Flow... 3 Accessing Travelport Booking Feed... 5 Queuing... 5 Queue Ownership... 5 Travelport Booking Feed Queue IDs... 5 Error Queue IDs... 6 Queue Thresholds Policy and Guidelines... 6 Multiple Queues for Associated Locations... 7 Logging... 8 Error Logging... 8 Host XML Logging... 8 JDBC Logging for Database Failures... 9 Logging for Client Adapter Console Output... 9 Technical Details... 9 Hardware Prerequisites... 9 Software Prerequisites Travelport Booking Feed Installation Connectivity Connection Speed Queues Firewall Settings Pricing Provisioning Support License Agreements Training FAQs November 2012 Travelport iii

4 Introduction Travelport Booking Feed is a Travelport proprietary data source that collects both pre- and postticketing data from the Apollo and Galileo Global Distribution Systems (GDS). This data enables travel-related businesses to meet the growing needs of their customers. This document provides a high-level functional and technical overview of the Travelport Booking Feed product. This overview supports release 2.09 of Travelport Booking Feed, which supersedes the 09 October 2012 release of Travelport Booking Feed Background The nature of travel-related businesses has undergone a radical change. The role of the travel agency has moved forward from merely being a reservations service to a business management consultant. Corporations require their business management consultants to provide meaningful and accurate information in a timely manner. With Travelport Booking Feed, travel business managers have the ability to extensively analyze travel patterns and travel policy compliance, as well as assist in vendor negotiations, business operations and budgeting. Travelport Booking Feed also supplies customers with factual management guidance by providing cost containment based on database management. The power of Travelport Booking Feed allows the ability to gain strategic, operational, and tactical views of a business, as well as help agencies to win and maintain corporate accounts by providing them with relevant travel reports. Agencies, corporations, and third-party developers can create in-house ad hoc reports to help run their business. Benefits Travelport Booking Feed: Provides the ability to streamline robotic activity. Eliminates excessive transactions. Provides reliable data to monitor reservation compliance with travel policy immediately after booking, not after the trip. Offers a revenue-generating product for agencies as it increases their service product line. This increase allows agencies to move to a travel management role with their existing corporate customers and thus strengthen the agency s overall value. Allows agencies and corporations to monitor sales of preferred vendors as well as create sales forecasts and market share reports. Provides corporations that use Travelport Booking Feed with greater access to travel data to assist in vendor negotiations, travel policy compliance, and travel budgeting. 26 November 2012 Travelport 1

5 Supporting Documentation See the following companion documents for more information about implementing Travelport Booking Feed: Travelport Booking Feed Installation Guide Travelport Booking Feed Data Definitions Release Notes (included with the installation) Data Types The following actions cause a Travelport Booking Feed message to be generated to a customer s unique data queue when a booking record (PNR/Booking File) is end transacted : A booking is created. An existing booking is modified by adding or deleting an itinerary item. A fare quote is added or deleted. A ticket is issued, voided, or un-voided (Galileo GDS only). The following data categories are passed within Travelport Booking Feed. Specifications for Travelport Booking Feed data fields are contained within the Travelport Booking Feed Data Definitions document. Air Segment Data Open Air Segments Air Reserved Segment Air Ticket Segment Air Fare Quote Passenger Air Quote Manual Air Quote Fare Components Fare Components by Route Plus Up Charges Plus Up Location Air Tax Air Tax Breakdowns Air Surcharges Flight Itinerary Seat Segments Seat Assignments Flying Taxi Segments Operating Carrier Air Segments Non-Air Segment Data Non-Air Segments Car Segments Car Segment Optional Information Hotel Segments Hotel Segment Optional Information Train Segments Passenger Information Booking Information Corporate ID Information Frequent Flyer Information Phone Information Ticket Information Ticketing/Document Invoice Remarks Ticket Transaction Net Remit Transaction Form of Payment Exchange Information Carrier Ticketing (OB) Fees and Taxes 26 November 2012 Travelport 2

6 Please note that the following ticketing entries will not generate a Travelport Booking Feed message in the respective host systems: Apollo MIR MCOs Itinerary Galileo MIR MCOs Itinerary Delivery Document Service Fee Pocket Itinerary Data Flow There are three major components to the Travelport Booking Feed product: The Apollo or Galileo GDS. The Travelport UNIX environment, which stores ticket data and booking file change information. The Client Adapter in the customer environment, which receives and processes the data. The following diagram shows an example of the processing flow for Travelport Booking Feed data. 26 November 2012 Travelport 3

7 Data Collection. After Travelport Booking Feed is activated, all initial reservations and subsequent updates to fare, ticketing, and itinerary on the Galileo or Apollo systems are included in the data source. After Travelport activates Travelport Booking Feed, the data feed begins immediately. General PNR data, such as itinerary segments, passenger name, and ticketing remarks, is collected in a structured format from the CRS at end transact when the PNR/Booking File is completed. Note: There is no retroactive data download and/or database update. Existing PNRs/Booking Files are not downloaded until a change is made to the PNR/ Booking File itself. Data Conversion. The data is then passed to the Travelport Booking Feed application, where it is sent to an XML translator, which converts the data to XML format. The data is then passed to the agency configuration file, which determines the appropriate customer queue for the data. Queuing. Each Travelport Booking Feed customer is assigned to one or more data queues. Data is sent to the owning pseudo city s customer queue. However, data for each pseudo city can map into a single data queue or multiple associated queues. See Queuing on page 5 for more details. Positive Acknowledgement. Travelport Booking Feed assures delivery of data within the defined threshold limit. Delivery to the agency database, or to an exclusive XML file, is retried until a positive acknowledgement has been returned from the client indicating the data has been saved successfully. Client Adapter. Data is then received by the agency s Client Adapter, which is networked by either a VPN connection or an SSL connection. The Travelport Booking Feed Client Adapter can be initiated as needed, or installed as a service that launches automatically when a Travelport Booking Feed-designated computer is started. Whenever possible, it is recommended to leave Client Adapter to run continuously; therefore, the service is the recommended option. The service option is especially convenient for customers with computers dedicated to the Travelport Booking Feed application. The service also gives us customers the ability to integrate other programs/applications with Travelport Booking Feed to create start/stop jobs. Data Storage. After data is sent through the Client Adapter, it is stored in a SQL database. A command line console for the Client Adapter is available to capture the output from Travelport Booking Feed to the database. As of the 2.05 release, customers also have the option to turn off database storage and log data directly to an XML file. See Host XML Logging on page 8 for more information. Note: The command line console is not available when the Client Adapter is installed as a service. However, the output data is available as a log. See on JDBC Logging for Database on page 9 for more details. 26 November 2012 Travelport 4

8 Accessing Travelport Booking Feed A GIDS field in Travelport s AAT controls access to the product. Each customer is assigned a Travelport Booking Feed user name and password for the VPN connection. Each customer is also assigned one or more Queue IDs. Please contact your local Travelport representative for more details. Queuing Each Travelport Booking Feed customer is assigned to one or more data queues. Each queue can hold up to a maximum of 50,000 messages, and is assigned a unique Queue ID. However, individual queues can receive data from more than one Pseudo City. Data can be downloaded to the same secure customer data queue from various locations (pseudo cities). The pseudo city must be activated for each location. Queue Ownership Data is sent to the owning pseudo city s customer queue. In most cases, the owner of a booking is the pseudo city to which an Apollo or Galileo subscriber is either initialized or emulated. Even if a branch or service bureau location is set up for Travelport Booking Feed, if either of these type locations modifies a booking, the data continues to be sent to the owning pseudo city. If Change of Ownership is invoked on a PNR/Booking File, subsequent data is sent to the new PNR/Booking File owner s customer queue. If the new PNR/Booking File owner is not turned onto Travelport Booking Feed, no data is be sent to either the previous owner or the new owner. Travelport Booking Feed Queue IDs Before a customer s data can be logged, a unique data queue must be assigned for that customer in a customer configuration file. The customer data queue consists of: The three- or four-character Pseudo City Code (PCC) of the agency where the data is gathered. A three-character code uses an underscore (_) for the fourth character. IDs are case sensitive and must be in upper-case letters. The CRS code (i.e., 1G for Galileo or 1V for Apollo) A system-generated four-digit ending. For example: A four-character PCC would be assigned a Queue ID such as: 79YW1G3848. A three-character PCC would be assigned a Queue ID such as: EK4_1G4982. For Travelport Booking Feed version and later, the customer s Corporate IDs can be used to accommodate multiple queues assigned to a PCC. For example, two Corporate IDs, IBM001USABC and IBM001USXYZ, can be assigned to PCC EK4. Events associated with each 26 November 2012 Travelport 5

9 of these IDs are then routed to the appropriate Corporate ID-specific queue: EK4_1G4982_ABC and EK4_1G4982_XYZ, respectively. This functionality is optional, and must be provisioned for the customer by Travelport. A single default queue per PCC remains for use by customers who do not opt into this functionality, or if a Corporate ID is not sent or is not recognized by the GDS. Using multiple queues requires a separate Client Adapter for each queue. See the Travelport Booking Feed Installation Guide for instructions to install multiple Client Adapters on the same machine. Error Queue IDs An Error Queue is also configured and assigned for each customer. The Error Queue consists of: The three- or four-character PCC of the agency where the data is gathered. A three-character uses an underscore (_) for the fourth character. IDs are case sensitive and must be in upper case letters. The CRS code (i.e., 1G for Galileo or 1V for Apollo) The word ERROR in upper case. For example: A four-character PCC would be assigned an Error Queue ID such as: 79YW1GERROR. A three-character PCC would be assigned an Error Queue ID such as: EK4_1GERROR. Queue Thresholds Policy and Guidelines Travelport Booking Feed queues are not infinitely sized; therefore, the adapter software must be run regularly to drain the data. If a queue reaches threshold limits, action will be taken by Travelport to ensure that system stability is maintained. The following policies are enacted when a queue reaches the threshold: If a customer s queue reaches a threshold of 25,000 backed up messages, automated notifications are sent to the agency support contact. These s are sent once an hour until the threshold is under 25,000 messages. If customer s queue reaches a threshold of 50,000 backed up messages, Travelport Booking Feed will discard any new data. After it is discarded, the data will not be available. Note: To ensure that threshold messages can be received, please provide a current, working address for an appropriate contact to your Travelport Representative. When ordering Travelport Booking Feed, customers should consider the following concerns to determine the number of queues that will be required: How often queues will be drained of data. The number of Pseudo Cities that will log data to that queue. It is highly recommended to limit the number of PCCs assigned to a Queue ID. The volume of transactions. Note that transactions are defined not only as segments and tickets, but also changes to PNRs/Booking Files because Travelport Booking Feed also transmits this data as queue items. 26 November 2012 Travelport 6

10 The following guidelines should be considered carefully to help determine the number of Queue IDs required: Single Branch Agent Multi Branch Agent (less than 10 PCCs) Multi Branch Agent (10 20 PCCs) Multi Branch Agent (20+ PCCs) = 1 Queue ID = 1 Queue ID = 1 Queue ID, unless each PCC is likely to produce over 1,000 segments per day. = at least 1 Queue ID per 20 PCCs Note: This information is offered as a guideline only. It should be noted that the true measure of capacity is the number of transactions that the customer will create. For customers with exceptionally high transaction volume, it is possible that a limit of one Queue ID per one PCC will be needed. Multiple Queues for Associated Locations Data can be sent to multiple customer queues. For example, a large travel agency may have different locations in which data is needed to produce comprehensive management reports. One location may be responsible for monitoring booking quotas, while another location may be responsible for ensuring compliance to the company travel policy. With Travelport Booking Feed, both of these locations can have the same data they both need to do their jobs. Additional recipient locations are assigned in the agency configuration file as associated locations. Only authorized Travelport personnel can view and/or modify the agency configuration file. Each associated location must also have a unique Queue ID setup to receive data. Associated locations do not need to load the Travelport Booking Feed application. However, they do need a working database and valid Queue ID. 26 November 2012 Travelport 7

11 Logging Travelport Booking Feed supports the following types of logging: Error logging Host XML logging JDBC message logging for database failures Logging for Client Adapter console output All logging files are saved into the logs directory of the Travelport Booking Feed application. By default, this directory is located in \Program Files\Galileo International\Travelport Booking Feed\logs. In addition to the error queue, there are also additional logging capabilities within the client application. Error Logging When a non-critical error is encountered, the Travelport Booking Feed Client Adapter application retries to send a message three times before logging the message as an error and trying a new message. Non-critical errors are usually associated with a condition that may resolve itself in a short amount of time. For example, if the database becomes temporarily unavailable because of a lock or pause condition, the application is unable to commit a transaction to the database. Because these conditions are usually temporary, by waiting for a few seconds and retrying the message, the application may be able to commit the message and continue. When a critical error message is detected, the message is immediately moved to the agency error queue. The Travelport Booking Feed application automatically shuts down after three consecutive critical errors. A critical error usually occurs when the application detects that the message is corrupt. Host XML Logging The Client Adapter can be configured to exclusively log XML data and bypass the agency data database for receiving data. Host XML logging is managed through the Travelport Booking Feed Client Configuration panel. The file names for these logs are directly associated with the transaction ID for the message. For example, if the last transaction was assigned a transaction ID of 1, the XML file is saved as Msg1.xml. The transaction ID for a message a message can be identified in the command line console window. As each message is processed, the transaction ID of the message displays as ID = ##. In addition to the XML logging, the application keeps a copy of the last message sent to the adapter, and the last bad message sent to the adapter. These files are respectively named LastMsg.xml and LastBadMsg.xml. Note: The Host XML logging option should not be turned on unless there are problems, as there is no automatic cleanup of these logs, and the computer can eventually run out of disk space. The log files can be manually deleted from this directory at any time. 26 November 2012 Travelport 8

12 JDBC Logging for Database Failures The JDBC message logging creates a file in the log whenever a database update fails. This file, JDBC.txt, contains a running log of all database commands that fail. JDBC message logging is managed through the Travelport Booking Feed Client Configuration panel. Logging for Client Adapter Console Output The wrapper.log file is always created to capture the output the Travelport Booking Feed application sends to the Client Adapter console. This file is very important when running the Travelport Booking Feed as a service because no console window displays. Wrapper.log contains all output from the application that would normally be displayed to the console. This file can be opened with Notepad or any other text editing program. When wrapper.log reaches 1 MB, it automatically rolls into a new file, called wrapper1.log. Log data rolls up to three files; after the third file reaches 1 MB, the output then rolls back into Wrapper.log, and the file naming sequence restarts. Technical Details The following technical requirements are necessary to support a Travelport Booking Feed implementation. Hardware Prerequisites The recommended/minimum hardware requirements to run Travelport Booking Feed are: Recommended Hardware Intel Pentium 4 (or later) with 512 MB RAM 1 GB of hard disk space CD-ROM drive Minimum Hardware Intel Pentium 200 MHz with 256 MB RAM 500 MB of hard disk space CD-ROM drive Note: The Travelport Booking Feed Client Adapter can be configured to exclusively log XML data and bypass the client database for receiving data. In this implementation, the XML data logs must be manually deleted. Therefore, the hard drive must allow for enough space to capture the anticipated amount of logs accumulate between purges. See Host XML Logging on page 8 for details. 26 November 2012 Travelport 9

13 Software Prerequisites Each user is required to purchase and install the following software in support of Travelport Booking Feed. Operating System Any version of Microsoft Windows or Microsoft Server currently supported by Microsoft. Recommended Databases For customers who choose to use a database to receive Travelport Booking Feed data, the following databases are recommended: Microsoft SQL Server Sybase Adaptive Server Recent versions of both Microsoft SQL Server and Sybase Adaptive Server have worked successfully with Travelport Booking Feed to date, although not all versions have been formally certified. Contact your representative if you encounter difficulties with using Travelport Booking Feed in conjunction with a specific version of these products. If you do not have either of these databases, you can download trial versions from or Reporting Software For customers who want to produce ready-made reports for management teams, it is recommended that an application, such as Crystal Reports, is used with the database. Travelport Booking Feed Installation The following Travelport Booking Feed installation tools are required: Travelport Booking Feed Adapter, including Java version 15.0_13. This application serves as the interface between the Galileo or Apollo GDS system and the customer s local database. A SQL database server, if the database implementation of Travelport Booking Feed will be used. The currently supported database servers are Microsoft SQL Server and Sybase Adaptive Server. Setup scripts are also included for the client database for both Adaptive Server and SQL Server. These setup scripts can be installed with the adapter or manually installed, as preferred. Connectivity Internet connectivity is the standard method to access Travelport Booking Feed. However, if a site currently has a direct IP subscriber line to Galileo or Apollo, or already has Extranet installed for an application, a VPN connection does not need to be installed. 26 November 2012 Travelport 10

14 Previous versions of the Travelport Booking Feed installation included a companion Nortel Contivity VPN installation for customers that did not already have the necessary connectivity to Galileo or Apollo. The Nortel installation is no longer included as part of the Travelport Booking Feed installation. The following connectivity options are supported with this version of Travelport Booking Feed: SSL connection (Recommended) If SSL is being used for connectivity, customer must also have Port 443 open to gdssl-atl.galileo.com. Refer to the SSL Installation Guide for further details. A copy of the guide is available at Existing unmanaged VPN connection Directly connected lease line Contact your Travelport representative to discuss connectivity options suitable for your environment. Connection Speed A high-speed connection, such as DSL or Broadband, is required. A dialup connection is not supported, as even low-volume customers may experience difficulties such as backed up queues that lead to a potential loss of data. Note: The Travelport Booking Feed product is not a query/reply (synchronous) architecture whereby clients initiate a request and receive a real-time response. Instead, Travelport Booking Feed uses a workflow (asynchronous) architecture in which data volume represents a combination of all available data for Travelport Booking Feed-designated transactions at a given time. Therefore, an individual agency s response time can be affected by the aggregate volume of transactions. Queues A Queue ID for each customer queue will be assigned by Travelport. Additional connectivity permissions will be required, depending on the type of connection. Firewall Settings If Travelport Booking Feed is used through a direct connection, i.e., a leased line rather than a VPN connection, the following firewall settings must be adhered to: If the market runs its own network, they must also ensure that they open Port 1415 on their firewall. If SSL is being used for connectivity, customer must also have Port 443 open to gdssl-atl.galileo.com. Refer to the SSL Installation Guide for further details. A copy of the guide is available at Pricing Please contact your local Travelport representative for further details on the pricing. 26 November 2012 Travelport 11

15 Provisioning Please contact your local Travelport representative for further details. Support Please contact your local Travelport representative for contact details. Travelport provides support for Travelport Booking Feed data delivery to the client s queue to ensure that data flows to the Client Adapter. This support includes: Installing Client Adapter. Addressing any issues that occur: Before data reaches the Client Adapter. Between the Client Adapter and the customer s database. Travelport does not support any issues related to the use of Travelport Booking Feed data after it has successfully reached the Client Adapter, unless these issues are caused by an error in the Travelport Booking Feed product or data. Support for any customised implementations, such as SQL scripting, are the responsibility of the customer. As such, Travelport does not support the use of this data within the client environment, including its use with third-party applications, servers, databases, or back-office systems. Knowledge of the travel domain is strongly recommended when working with Travelport Booking Feed data, and should be considered when planning a Travelport Booking Feed implementation. License Agreements Travelport Booking Feed licensing requirements are dependent on the type of organization applying for the product: If the Travelport Booking Feed customer is a travel agency/subscriber that already holds a Travelport subscriber agreement, and no third-party development is involved, no separate special agreement is required. If a third-party developer will be using Travelport Booking Feed, they are required to sign a Non-Disclosure Agreement. Training A dedicated trainer or training course is not required. The following documents are available to assist with installing and using Travelport Booking Feed: Travelport Booking Feed Data Definitions Travelport Booking Feed Installation Guide 26 November 2012 Travelport 12

16 FAQs How is Travelport Booking Feed different from Galileo Web Services (GWS)? Travelport Booking Feed provides a set data stream, whereas GWS allows customers to access any of the PNR data fields. The advantage of using Travelport Booking Feed is that the data is a push rather than a pull, so customer are not required to access the GDS to obtain the data and potentially incur excessive transaction charges. Another advantage of using Travelport Booking Feed is that the data structure has already been established. Customers do not need to create the data calls necessary to capture this information from the host. How is Travelport Booking Feed different from the MIR? Generally, the Travelport Booking Feed product was developed to provide a pre-ticketing data stream to customers. This product was originally envisioned to allow customers to do compliance data reporting on the data provided by Travelport. Therefore, a corporate location can receive this information in before the ticket is issued, and determine if the travel is within compliance of that organization. For example, an employee may be required to use coach class tickets between London and Paris, but is allowed business class between London and Delhi. A set of rules can be run against the Travelport Booking Feed data, and immediately flag an itinerary outside of these parameters before the ticket is issued. Much of the data Travelport provides is also available in the MIR. The biggest difference is that Travelport Booking Feed data contains pre-ticket information, and the data is provided in a much more user-friendly format. Because the data is populated in a relational database, there are many off-the-shelf products that an agency can purchase to work with or report the data. Also, many big agencies have internal IT groups that can write their own applications to work with this data. In addition, the message infrastructure is completely different from messages received from the host today. An agency must use linkage to send data to a MIR device. Also, no pre-ticketing information is sent unless the agent manually requests a MIR. And if an agency outside of the owning agency issues the ticket, they must be linked to the owning agency s MIR device to receive any data. With Travelport Booking Feed, all information is placed into a persistent queue on UNIX where it waits for the agency or third party to retrieve the data. A site that receives the data does not need a connection to the Apollo or Galileo CRS to retrieve the data. With an internet connection and VPN, they can connect to this box through the internet and drain the data. Travelport also has the ability to send this data to multiple queues. This feature can be used for large travel agency customers that want to send the data to both a corporate site and the local agency that owns the PNR/BF. Will data on bookings made prior to the activation of Travelport Booking Feed be made available after Travelport Booking Feed is activated? Data on bookings made prior to the activation of Travelport Booking Feed can be downloaded if a change is made to the booking after Travelport Booking Feed is activated. If no change is made, the details of the booking will not be available on the GDS. 26 November 2012 Travelport 13

17 The Travelport Booking Feed queue allows a maximum of 50,000 messages. Is it possible to increase this limit? No, it is not possible to request an increase to the limit. If a customer handles large volumes of data throughput, they can request to split their agencies among multiple queues using multiple Client Adapters. What happens if a queue becomes full? The automated notification process is designed to eliminate this issue. When a customer s queue reaches a threshold of 25,000 backed-up messages, an automated notification is sent to the nominated agency support contact. The is sent once an hour until the threshold is under 25,000 messages. If a queue reaches the threshold limit of 50,000 backed-up messages, the Travelport Booking Feed application discards any new data. After the data is discarded, it will not be available. Note: To ensure that threshold messages can be received, please provide a current, working address for an appropriate contact to your Travelport representative. Where can I find specific data fields in my database? All data fields and XML equivalents included in Travelport Booking Feed are documented in the Travelport Booking Feed Data Definitions document. The configuration is all set up but no data is flowing to my queue? Contact your Travelport account manager to make sure that the Travelport Booking Feed field in your AAT has been set to yes. 26 November 2012 Travelport 14