General Error Handling
When an error occurs whilst processing an XML request, the details of the error will be returned using three attributes within the related XML tag. These attributes will provide the error code, a textual description of the error and the details of this occurrence of the error. For example:
<StartRouting ecode="2-1-7" etext="DNS error connecting to supplier
" edetail="Lookup failed for 'www.flyplane.com'
Error codes are classified into a hierarchy of groups and sub groups. In the above example, the
2 signifies the top level group which may be, for example, 'routing errors'. The
1 signifies the sub-group within routing errors, for example 'supplier connectivity errors'. The
7 indicates the specific error type, for example 'DNS error connecting to supplier'. Occasionally, the
ecode attribute may contain a question mark followed by a hyphen and an error code. e.g.
?-6. This will indicate that the code-group could not be determined. It is an error in itself and should be reported to Travelfusion.
edetail attribute contains a free text description of any extra information pertaining to this specific occurrence of error 2-1-7. The
edetail should normally only be used to aid development but may occasionally be used to convey extra information that may be used at runtime by the customer application. In some cases the
edetail attribute may not be supplied.
In principle, errors can occur at any level within the request-handling process so these attributes may occur in any tag within any XML response although there will be many tags where errors will rarely occur under normal operation. In general, the data contents of an XML element containing an
ecode attribute will be invalid, missing or may not conform to the XML specification and should be ignored.
Input Data Errors
If an XML request contains invalid data/ parameters then the entire request will be returned instead of the usual response. Any fields in which errors were detected will have appropriate error code attributes. To see an example of this, try submitting the search request so that the Origin location descriptor is invalid. e.g.
<Descriptor>zzzz</Descriptor>. Then, submit the search request. Notice that the response is a reproduction of the request except that the
Descriptor tag contains an error code:
<Descriptor ecode="2-2411" etext="Invalid location descriptor
Also notice that the returned search request is now surrounded by a
DataValidationFailure tag. This will always surround the returned request in these cases.
An exception to this behaviour is the booking profile. This may be submitted to Travelfusion in fragments (at the search, details and terms stages), and may not get fully validated until the
ProcessTerms stage (by which stage, all parts of the booking profile have been submitted). If a validation failure occurs at this point, the whole booking profile will be returned, not just the fragment that was submitted in the ProcessTerms request.
Command Execution Failures
If a command fails to be executed at the highest level, a
CommandExecutionFailure element will be returned. Within that will be the related command element which will have no content, but will have the
edetail attributes which will describe the reason for failure. For example, if a details request is submitted with a bad routing id, the following response is returned:
XML Schema Validation Failures
Please note that Travelfusion does not currently validate XML at runtime. However validation will be activated in the near future. Once activated, if invalid XML is submitted to or returned by Travelfusion, an XML validation error will be returned. For example, if the
Mode element is mis-spelt as 'Mod' in a search request, the following is returned:
If invalid XML is generated by the Travelfusion server, this is effectively a serious internal error and should be reported to Travelfusion immediately. In this case the response will look something like:
In certain circumstances, an 'Internal Error' may be returned (error code 1012). This represents an unforeseen error situation that has not been handled correctly by the Travelfusion system. In these cases, please contact Travelfusion as soon as possible to report the fault. Similarly, the 'Service unavailable' error (1019) will be returned if the Travelfusion system is completely offline. This will be returned in the
CommandList tag as follows:
<CommandList ecode="1-1019" etext="Service currently unavailable
Error Code Hierarchy
The full hierarchy of error codes and their meanings can be obtained via the
GetErrorCodes request and Travelfusion reserves the right to add and remove error codes and groups without prior notification. The customer should therefore monitor the hierarchy occasionally to check for new error codes. However in the case where an XML response from Travelfusion contains an error code that has not yet been fully handled by your application, the meaning of the code should be taken from the parent group. If the group is also unrecognised by the customer, then its parent group must be used and so on. For example, if the customer has put code in place to handle error group
2-1 but has not yet specifically handled error code
2-1-7, then the error
2-1-7 can be taken as a general
Travelfusion supplies text descriptions for every error code and the customer may choose to display this directly to the user - at least for error codes that are not recognised.