Web Services 3.0

Manual de Referencia - Inicial

Cambios desde la versión anterior de los Web Services

Los Web Services 3.0 son una reescritura de las interfaces de aplicación mantenidas desde la primera versión. Se adopta como modelo el standard OTA y se deja de lado el sistema de llamada remota SOAP en favor del uso de XML puro mediante métodos HTTP POST sobre SSL. La nueva suite de mensajes provee mayor flexibilidad y funcionalidades no cubiertas y es a partir de la misma sobre la que se van a realizar los futuros desarrollos, por lo que recomendamos iniciar el proceso de migración de todo aquello implementado sobre las versiones 2.X, así como la implementación en 3.0 de los nuevos desarrollos. Los Web Services son la interfaz que permite acceder en forma programática al inventario del sistema de reservas, desde la disponibilidad hasta la la emisión. El propósito de este manual de referencia es describir en forma detallada cada uno de los mensajes soportados así como sus respuestas. Las definiciones de los mensajes están basadas en estandar OTA, descripto por la Open Travel Alliance (http://www.opentravel.org). Recomendamos leer la información provista por ellos, siendo el modelo en el cual se basa nuestra implementación. Asimismo, el roadmap de implementación de nuevas características toma en cuenta las disponibles en la definición OTA que no estén aun desarrolladas. Se presupone que el equipo encargado de la implementación posee un conocimiento adecuado de las tecnologías que forman la base de la misma y por ende no serán cubiertas dentro de este manual. Es responsabilidad del implementador ocuparse de cómo hará los requerimientos usando POST vía HTTPS, formar mensajes XML válidos e interpretar adecuadamente los mensajes XML que recibe en respuesta.

Volver al índice

Elementos comunes en las peticiones

Todo mensaje de petición incluye en su cabecera un set de atributos que facilita su identificación y procesamiento. Estos elementos son:

EchoToken: Alfanumérico [0...128] (Opcional). Sirve como identificación y se envía junto con la respuesta sin modificación alguna. Se recomienda implementar un sistema que envíe las llamadas con un identificador único en este campo para facilitar la posterior búsqueda de llamadas en logs.
TimeStamp: Fecha y Hora ISO. Momento de generación del mensaje.
Target: [Production|Testing]. Partición sobre la cual va a trabajarse.
Versión: Decimal (Opcional). Versión implementada.
SequenceNmbr: Entero positivo. Sirve para identificar un número de secuencia en un set de mensajes relacionados. Se envía junto con la respuesta sin modificación alguna. Se recomienda implementar un sistema que asigne números correlativos del 1 en adelante a cada llamada que un mismo cliente genera en una visita a la web, para facilitar la posterior identificación de la secuencia de llamadas en logs.

Ejemplo de inicio de petición:

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

Volver al índice

Elementos comunes en las respuestas

Además de los elementos comunes en las peticiones, las respuestas incluyen elementos para informar el éxito o fracaso de las operaciones realizadas. En caso de éxito, se incluye el elemento "Success" junto con los datos de la respuesta. De esta forma, el encabezado de la respuesta para una petición sería:

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

Mientras que en caso de fracaso, se incluye un elemento "Error" el cual incluye un "ErrorCode" con el código numérico y un "ErrorMsg" con una descripción:

<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

Errores comunes en las respuestas

Volver al índice