FAQs

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 customers 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.

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.

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.

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.

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 email notification is sent to the nominated agency support contact. The email 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 email address for an appropriate contact to your Travelport representative.

All data fields and XML equivalents included in Travelport Booking Feed are documented in the Data Definitions.

The following actions cause a 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).

Contact your Travelport account manager to make sure that the Travelport Booking Feed field in your AAT has been set to ‘yes’.

What triggers are available?

Data Events and Triggers

 

Technology and Support

The Booking Feed adapter’s main aim is to collect the data from the host. It listens out for inbound messages, so it can push data to the relevant databases.

 

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 email notifications are sent to the agency support contact. These emails are sent once an hour until the threshold is under 25,000 messages.

 If a customer’s queue reaches a threshold of 50,000 backed up messages, Booking Feed will not collect any further data until the queue has been cleared

Yes, a copy of the latest versions are available via the Travelport Developer Network site.

http://developer.travelport.com

The illustration below shows the capture of flight data within the XML schema:

What is ‘queuing’ functionality and how does it work?

Yes. The Data Elements Diagram document is available via the Travelport Developer Network site.

http://developer.travelport.com

Each 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.

 

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 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 Booking Feed, no data is be sent to either the previous owner or the new owner.

A number of feasible solutions can be developed from the booking feed; it’s not just limited to any one reporting format such as Crystal MI Reporting.

Hotel Rate Checking: Booking Feed captures a vast amount of PNR data, including hotel data. With just the hotel data itself, there is a solution that could be developed and offered to clients.

Revenue Projection - One of the main benefits for Travelport Booking Feed is that it captures both PRE & POST trip data, so another example of what can be produced from the feed is revenue projections. Hotel rates, car hire rates and air ticket information are just some elements of data that can help create revenue projections.