Travel XML Proxy was created to enhance the real time interoperability of the tour operator’s management system with that of other players of the distribution chain, irrespective whether to accomplish a supply tool or a distribution tool.

Supply

The Travel XML Proxy is based on a web service interface, to which you may submit OTA XML syntax requests and the engine provides to send to all preconfigured tour resource providers simultaneously, translated into a comprehensible syntax. Answers are collected and reassembled into a single OTA XML packet.

Supply Connector

Thanks to the modular architecture achieved by separate processes capable of conversing online, the Travel XML Proxy maintains the specific functions of each provider separate from the common ones, confining them in a specific process named “Supply Connector”. This architecture allows for the tour operator to develop on his/her management system a single interface (client web services), and a single XML syntax (OTA), leaving the complex job of managing the diversities between the various providers to the Travel XML Proxy.

Infotech has already created the diverse “Supply Connectors” necessary for each types of tour resources (Flights, low cost Flights, Hotels, Cars, Transfers, Excursions, etc.) for the biggest IDS providers, of which:

• Booking
• Click
• Expedia
• GTA
• HotelBeds
• HotelClub
• Kuoni
• Laterooms
• Octopus
• Restel
• Sehrs
• Smilo
• Teamamerica
• Tourico
• TransHotel
• Travco
• Travalco
• Venere
• HolidayAuto
• Flightscanner
• etc.

..and for the main GDS providers:

• Amadeus
• Galileo
• Sabre
• Ultradirect XML (Pegasus)

Infotech is also capable of developing in relatively little time (low cost) contents for “Supply Connectors” on commission for any IDS/GDS that distributes tour resources on line.

Distribution

Associating a public internet address to the Travel XML Proxy’s OTA XML web service interface, and endowing it with a “Supply Connector” to the tour operator’s management system, the Travel XML Proxy may create an interface for the online distribution of the tour operator’s resources.

Infotech has already realized the “Supply Connectors” for some tour operator managements, in particular managements achieved with products from:

• Datagest
• Dolphin Italia
• (Dolphin Tour Operator)
• SIAP

..and is also capable of realizing “Supply Connectors” on commission, even for management systems, non derivative from commercial software.

Distribution Connectors

Distribution towards some GDS subjects, renders an interface, which is different from webservices using OTA XML packets, essential. Just as before, with the Supply Connectors, the diversities are bound to a separate process called “Distribution Connector”.

For this reason, integration with the operator’s management system remains unique and unaltered, whilst the logistics associated with the distribution channel, is managed by a separate process.

Infotech has already created the Distribution Connectors for the channel:

• Pegasus (UltraConnect and UltraSelect)

and is also doing so for some GDSs and IDSs that require push technology.

Functionality Map of the Providers of Accomodation Facilities

Not all functions are fully sustainable by the various receptive structure providers, for this reason we have shown below some matrices that illustrate some substantial differences.

Matrix 1

• Hotel-List Browsing (the provider allows for availability searches, specifying a list of hotels to check)
• Multi-Room Browsing (the provider allows for availability searches for more than one room and with different participant profiles for each room)
• Multi-Profile Browsing (the provider, in case of multi-room browsing, with different participant profiles (number of adults, children and ages of each) given each room, supplies indications that allow us to establish which are the usable profiles for each room).
• Geo-Referenced Browsing (the provider allows for the search of hotels that have availabilities, based not only on an area code, but also on a geo-referenced indication).
• Multi-Room Booking (the provider allows for simultaneous booking of multiple rooms with different participant profiles for every room booked).
• Session-less Booking (the provider allows for booking without having to explicitly attributing it to a search done in the same session

Matrix 2

• Total Price (✔= It shall be returned to a single roomstay, with the total price of all the rooms; ✔*= The room price is calculated by dividing it to the total number of rooms, considering eventual wastes)
• Cancellation Policy (CP) (Cancellation policies are made available by the provider in the AV=Avail, and the BR=Booking Response)
• Fix RTC
• Max Child Age
• Child Age RQ
• Board Code

MultiRoom Booking

Not all providers allow for searching and booking more than one room simultaneously (Multi-Room Booking) and in the case of providers that are not “Session-Less”, the booking must be coherent with the “in session” search. Therefore if in one session simultaneous searches have been done, we may book all rooms searched, but not one in particular.

To overcome some inconveniences and homogenise the behaviour amid different providers, the Travel XML Proxy connectors foresee a procedure function that transforms the single Multi-Room search into a collection of parallel Single-Room searches. The downside of this simplification, is that it is no longer feasible to book with a single Multi-Room Booking, but multiple sequential booking requests. In presence of a single element (of a non refundable resource), this may potentially generate a problem known as partial booking, non completable, which contain “non refundable resources”.

On of the main problems that providers face in Multi Room searches, involving multiple profiles participating (number of Adults, number of Children and relative ages), different for each room searched, is that the answer given by the provider does not always allow for backtracking/associating every room to which profile used for calculating the prices, with the consequent problem that it is almost impossible to pinpoint the available rooms for the next booking request. For example, searching for two rooms, the first for two adults and a three year old child, and the second for two adults and a ten year old child, if for each search there is no ID for the profiles searched, it will be impossible later to tell weather the price variations are due to the age differences or not.

The providers solved this problem, classifying those who:

1. give an answer (to the multi room search) and for each room contained in the search, they allow to identify the profile used to calculate the price.

2. give an answer (to the multi room search) and for each room contained in the search, they DO NOT allow to identify the profile used to calculate the price.

The Travel XML Proxy connectors can operate in “Real Multi Room” and in case the provider is of the first type, there are no restrictions, whilst with the second type, the requests that contain different profiles that also include children, will be blocked.