Web Services 3.0

User Guide

Updates since the previous version of Web Services

Web Services 3.0 is a rewrite of the application interfaces maintained since the first version. The OTA standard is adopted as a model and the SOAP remote call system is left out using pure XML through HTTP POST over SSL methods. The new message suite provides greater flexibility and functionality not covered before and it is from here that future developments are going to be made, so we recommend starting the migration process of everything implemented on the 2.X versions, as well as the implementation in 3.0 of the new developments. Web Services are the interface that allows programmatic access to the inventory of the reservation system, from availability to issuance. The purpose of this reference guide is to describe in detail each of the messages supported as well as their responses. The definitions of the messages are based on the OTA standard, described by the Open Travel Alliance (http://www.opentravel.org). We recommend reading the information provided by them, being the model on which our implementation is based. Likewise, the roadmap for implementing new features takes into account those available in the OTA definition that are not yet developed. It is assumed that the team responsible for the implementation has adequate knowledge of the technologies that form the basis of the same and therefore will not be covered within this guide. It is the responsibility of the implementer to deal with how it will do the request using POST via HTTPS, form valid XML messages and properly interpret the XML messages it receives in response.

Volver al índice

Common elements in requests

Every request message includes in its header a set of attributes that facilitates its identification and processing. These elements are:

EchoToken: Alphanumeric [0 ... 128] (Optional). It serves as identification and is sent along with the response without any modification. It is recommended to implement a system that sends calls with a unique identifier in this field to facilitate the subsequent search of calls in logs.
TimeStamp: Date and ISO Time. Moment of message generation.
Target: [Production | Testing]. Partition on which it will work.
Version: Decimal (Optional). Version implemented.
SequenceNmbr: Positive integer. It is used to identify a sequence number in a set of related messages. It is sent together with the response without any modification. It is recommended to implement a system that assigns correlative numbers from 1 onwards to each call that the same client generates in a visit to the web, to facilitate the subsequent identification of the sequence of calls in logs.

Example of request initiation:

<KIU_AirAvailRQ EchoToken="12345" TimeStamp="2010-07-17T09:30:47-02:00" Target="Production" Version="3.0" SequenceNmbr="1">

Volver al índice

Common elements in the answers

In addition to the common elements in the requests, the responses include elements to inform the success or failure of the operations carried out. In case of success, the "Success" element is included together with the response data. In this way, the response header for a request would be:

<KIU_AirAvailRQ EchoToken="12345" TimeStamp="2010-07-17T09:30:47-02:00" Target="Production" Version="3.0" SequenceNmbr="1">
<Success/>

While in case of failure, an "Error" element is included which includes an "ErrorCode" with the numeric code and an "ErrorMsg" with a description: 

<KIU_AirAvailRQ EchoToken="12345" TimeStamp="2010-07-17T09:30:47-02:00" Target="Production" Version="3.0" SequenceNmbr="1">
<Error>
      <ErrorCode>55023</ErrorCode>
      <ErrorMsg>Test error message</ErrorMsg>
</Error>

Volver al índice

Common errors in the answers

The production environment was requested with the password of the testing environment or vice versa.

The AgentSine sent does not correspond to the format described (alphanumeric of nine characters) or does not belong to the user.

Volver al índice

Methods and User Guide:

Volver al índice