| XML Field | Dependencies | Description |
| CommandList | | The surrounding tag |
| -StartRouting | | The command name |
| --LoginId | | The end user login id. See the 'Logins' section within the XML integration guide. |
| --XmlLoginId | | The xml customer login id. See the 'Logins' section within the XML integration guide. |
| --Mode | | The type of routing. Currently only 'Plane' or 'plane' are accepted. 'Plane' is now deprecated,
so only 'plane' should be submitted. |
| --Origin | | The start location of the journey |
| ---Descriptor | | The location name/ code/ identifier.
Currently only city tla (e.g. LON), airport tla (e.g. LHR) or TRAVELfusion location id are accepted.
If a TRAVELfusion location id is submitted, the 'Type' element below must have value 'locationid'.
This field is case insensitive. |
| ---Type | | Possible values: 'airportgroup', 'citycode', 'airportcode', 'auto', 'locationid'. This describes how the above
Descriptor is to be treated. For example, Descriptor 'AMS' with Type 'citycode' will signify Amsterdam city, but 'AMS'
with Type 'airportcode' will signify Amsterdam airport. 'airportgroup' signifies a set of airports. For example 'LON'
with Type 'citycode' signifies London city, but 'LON' with Type 'airportgroup' signifies the London airports. Airport groups currently
can only be city codes, but custom groups may later be introduced. 'auto' requests that TRAVELfusion should automatically
determine the Type of the Descriptor. 'locationid' specifies that the descriptor is a location Id (for example, if the Location
Resolution feature is utilised, locations can be specified using their id) |
| ---ResolutionTypeList | Optional | This will be ignored unless the Type is 'auto'. In this case,
the 'ResolutionTypeList' describes the order in which TRAVELfusion should assess the descriptor-type. For example, if the Descriptor
is 'AMS' (which represents both a city and an airport) and the type is 'auto', and the ResolutionTypeList has 'airportcode' before
'citycode' or it contains 'airportcode' but not 'citycode', TRAVELfusion will treat the location as Amsterdam airport.
If the ResolutionTypeList is omitted, then TRAVELfusion will use an unspecified sequence containing all types. However if a
ResolutionTypeList is supplied, only the types in the list will be considered. Contains 0 or more 'ResolutionType' elements |
| ----ResolutionType | Optional | Contains any one of the possible values for 'Type' above |
| ---Radius | Optional | Distance in metres to search for relevant airports. If the Type is 'airportgroup', the radius
will be ignored if supplied. Otherwise, the radius will be used to search around the specified location for relevant airports. All airports
within the search radius will be considered. Any outside the radius will not be considered.
If omitted, an unspecified default radius will be selected by TRAVELfusion.
If the radius is zero, only the specified location will be used. If the location is not an airport, then no flights will be returned |
| --Destination | | The destination location of the journey. Similar to 'Origin' above |
| --OutwardDates | | Specifies the outward journey date parameters |
| ---DateOfSearch | | The date and time of departure that will be requested from the supplier. Format dd/mm/yyyy-hh:mm. If
the specified date/ time cannot be specifically requested using the supplier's interface, the best approximation will be chosen.
In general, TRAVELfusion guarantee to return all the flights returned by the supplier on the specified day unless the supplier does not return
an entire day's
flights, in which case TRAVELfusion will request the specified time of day from the supplier. TRAVELfusion will not make multiple requests
to the supplier for a paricular route. In some cases, TRAVELfusion may not be able to return all the flights that the supplier returns due to
processing time constraints. Please ask TRAVELfusion for more details of these cases.
|
| ---DepartDateFilter | Optional | Specifies a range of allowed dates. If omitted, no flight results will be discarded.
These filters are only used after the supplier has returned results. They are applied to the flights returned by the supplier.
If caching is enabled, any extra flights that are in the cache between the discard dates will also be returned. |
| ----DiscardBefore | Optional | Format same as DateOfSearch. If supplied, any results found that depart at a time before this date will be discarded by TRAVELfusion. |
| ----DiscardAfter | Optional | Format same as DateOfSearch. If supplied, any results found that depart at a time after this date will be discarded by TRAVELfusion. |
| ---ArriveDateFilter | Optional | Similar to DepartDateFilter, but applied to the arrival dates of the flights. |
| --ReturnDates | Optional | 'ReturnDates' has the same structure as 'OutwardDates'. Specifies the return journey date parameters. If Omitted the
journey will be assumed to be one-way (single) |
| --MaxChanges | | The maximum number of changes acceptable in a single leg (i.e. this limit will be applied
to the outward leg and return leg separately). This value will be submitted to the supplier if they offer this functionality. Otherwise an appropriate
request will be made to the supplier.
Any results returned by the supplier that include more changes than the specified number will noramlly be discarded by TRAVELfusion.
However in some circumstances results may still be returned that contain more changes than requested.
Please contact TRAVELfusion for more information. |
| --MaxHops | | This will be handled similarly to MaxChanges. See the 'Travel
Terminology' section of the XML Integration Guide for definitions of 'changes' and 'hops'. |
| --SupplierList | Optional | The list of suppliers to query. If omitted, all available suppliers will be queried. Contains 0 or more 'Supplier' items |
| ---Supplier | Optional | A supplier identifier. Please contact TRAVELfusion for a list of possible identifiers |
| --RealOperatorFilter |
Optional |
Specifies a list of 'Operator' codes (see Results Response spec) to allow/ discard.
If omitted, all results will be returned. Outward and return legs will be filtered separately. |
| ---Type |
|
If the value is 'select', the operators listed will be the only ones returned.
If the value is 'reject', the operators listed will not be returned. |
| ---AllowPartial |
|
Has value 'true' or 'false'. In cases where a leg has multiple segments where there is a mix of allowed and non-allowed operators,
the ‘allowPartial’ flag will define whether to return these or not. (If the flag is set to ‘true’, these results will be returned.) |
| ---OperatorList |
|
Specifies the list of operators to select/ reject. |
| ----Operator |
|
Specifies an operator as a two letter operator code |
| --VendingOperatorFilter |
Optional |
Similar to RealOperatorFilter except that the filtering is based on the 'VendingOperator' instead of the 'Operator'. |
| --Timeout | | Specifies the maximum time (in seconds) that suppliers should be allowed to respond in. Any supplier queries taking
longer than this will be cancelled. This should be equal to the customer polling timeout - i.e. the time at which the customer stops polling for results even
if some Routers are still incomplete. It will help to minimise the load on the TRAVELfusion system and the suppliers. |
| --TravelClass | Optional | Must be one of the following values: "Economy With Restrictions", "Economy Without Restrictions",
"Economy Premium", "Business", "First". If omitted, an appropriate default value will be used. Travelfusion will request this class or the best approximation from the supplier where possible,
but will not filter the response from the supplier, so any flights returned by the supplier, but not matching the requested class
will be returned by TRAVELfusion. |
| --TravellerList | | Describes the travellers that will be making the journey |
| ---Traveller | | A traveller description |
| ----Age | | The age of the traveller. This is required because suppliers do not all use the same age boundaries to define
adults/ children etc. If the traveller's age is not known then an age should be submitted that will always give the required passenger type.
e.g. 30 for adults, 7 for children, 0 for infants, 90 for senior citizen. Please contact TRAVELfusion for more details |
| --IncrementalResults | Optional | If supplied must have value 'true' or 'false'.
If not supplied the value will be
assumed 'false'. If this is 'false', then ALL available results will be returned for every ResultsRequest. However to save processing and
bandwith usage, it is recommended that it is submitted with value 'true'. In this case, each time the ResultsRequest is submitted (polled), only new
results will be returned in full detail - i.e. any results that have become available since the last poll. Please note that if IncrementalResults
are requested, no sorting or filtering will be done and the SortedList will no longer be applicable. More details of how results will be returned
can be found in the specification for the 'RouterList' element in the results response. |
| --BookingProfile |
Optional |
Any customer profile information can optionally be supplied here. See the Terms Request spec for the structure of this element. All sub-elements are
optional at this stage even if stated otherwise in the Terms Request spec. However some of the custom supplier parameters may affect the results
that are obtained from this search. Please see 'RequiredParameterList' in the Search Response spec for more information. |
| --PerformSearch |
Optional |
If has value 'true' then a search will actually be performed. Will be assumed 'true' if omitted.
In special circumstances a customer may want to submit a search request only to get a search response - i.e. no Results Request will be made.
In this case the value should be set to
'false'. For example, the customer may wish to check the value of 'RequiredParameters' in the Search Response, and then resubmit the
search request including the appropriate parameters. The customer may also use this feature to investigate exactly which routes and suppliers
would be searched for this request, without actually requesting that the flight data be obtained from the suppliers. |