Índice
1. ¿Qué es SiteMinder?
SiteMinder es un software de gestión hotelera que, entre otras funcionalidades, ofrece las de motor de reservas en línea, gestión de canales hoteleros e integración con sistemas de gestión de la propiedad (PMS), entre otras muchas.
Esta integración con los PMS se realiza a través de la interfaz pmsXchange que contiene un conjunto de mensajes compatibles con Open Travel Alliance (OTA) que permiten que un PMS envíe tarifas, disponibilidad y restricciones a SiteMinder y que el PMS recupere reservas, modificaciones y cancelaciones de SiteMinder.
2. Objetivos de la integración
2.2. Sincronización de la disponibilidad
Nuestro software debe ser capaz de comunicar la disponibilidad a los servidores de SiteMinder, a través de las APIS facilitadas y de la forma que SiteMinder exige.
2.3. Recepción y confirmación/rechazo de reservas
Nuestro software debe contestar, una vez recibida la respuesta a la petición de obtención de reservas desde los servidores de SiteMinder, con una confirmación o rechazo motivado para cada uno de los mensajes de reserva recibidos.
3. Las APIS de Open Travel Alliance en SiteMinder
En el caso que nos ocupa, las comunicaciones con los servidores de SiteMinder se realizan mediante peticiones http que intercambian documentos XML usando el protocolo SOAP y adheridos al esquema de Open Travel Alliance, en el que se pueden recibir y comunicar los estados y operaciones que ya se describieron más arriba.
3.1. El protocolo SOAP
El protocolo SOAP (Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de documentos XML, en nuestro caso, empleando un esquema compatible con el de Open Travel Alliance.
Este protocolo está basado en XML y se conforma de tres partes:
Sobre (envelope): el cual define qué hay en el mensaje y cómo procesarlo.
Conjunto de reglas de codificación para expresar instancias de tipos de datos.
La Convención para representar llamadas a procedimientos y respuestas.
De este modo, todas las peticiones que se van a realizar desde GolfManager a SiteMinder, se realizan a una única URL/endpoint, adjuntando en los cuerpos de las peticiones los documentos XML representativos de lo que se quiera notificar/requerir.
Todos estos documentos compartirán la sección de los encabezados, que es donde se comunican las credenciales de acceso y agregarán a la sección del cuerpo del documento el elemento del esquema OTA asociado a la notificación/solicitud que corresponda en cada momento.
4. Requisitos y exigencias de SiteMinder.
Entre otros muchos, conviene destacar varios de los requisitos y patrones de estilo que SiteMinder exige respetar a la hora de mantener comunicaciones con sus servidores.
1. La obtención de las reservas/cancelaciones/modificaciones aún por entregar desde SiteMinder debe realizarse con una frecuencia de entre 3 y 5 minutos.
2. Una vez obtenida la respuesta a la petición de recuperación de reservas, debemos contestar inmediatamente cuál ha sido el resultado de las operaciones para cada reserva, si han podido realizarse satisfactoriamente o si, por el contrario, no han podido realizarse.
3. No se pueden comunicar en el mismo documento las reservas rechazadas y las satisfactorias, ha de realizarse en dos envíos consecutivos.
4. Tras procesar las operaciones, debe notificarse al servidor de SiteMinder la disponibilidad afectada resultante.
5. La notificación de disponibilidad sólo debe contener los datos que realmente hayan variado desde la ultima notificación, nunca deben incluir refrescos masivos o de datos que no hayan variado.
6. La notificación de disponibilidad debe agrupar los cambios por períodos continuos. Si la disponibilidad del tipo de recurso A es 3 durante un período continuo de tiempo, se espera que simplemente se envíe un mensaje con la disponibilidad y el período, y no tantos mensajes cómo días tenga el período.
7. Las reservas rechazadas deben contener el motivo/error del rechazo.
8. Los documentos XML enviados en los cuerpos de las peticiones deben formatearse como una cadena de una sola línea.
9. Debemos tener una política de reintento y guardado de las notificaciones para posterior reenvío que no hayan podido enviarse o que, en abstracto, no hayan recibido respuesta de SiteMinder.
4.1. Implementación de los requisitos en GolfManager.
Tenidos en cuenta los requisitos anteriores, la implementación de estos por nuestra parte se puede resumir en los siguientes puntos:
1. Crearemos un cronJob, que se ejecutará con la frecuencia mínima de 3 minutos exigida por SiteMinder. En él se realizarán las operaciones siguientes:
A) Petición para recibir las operaciones de reserva desde SiteMinder. Recibiremos todas aquellas que SiteMinder no considere entregadas, por no haber recibido aún respuesta de GolfManager sobre ellas.
B) Intentar realizar las operaciones solicitadas.
C) Notificar a SiteMinder los resultados de las operaciones para cada operación de reserva recibida.
D) Notificar la disponibilidad resultante, si es que algo varió, a su servidor.
E) Guardar traza de todo lo enviado, recibido y resultados.
2. Crearemos una tabla que actuará como una cola de mensajes de disponibilidad. Para respetar el principio de sólo enviar los cambios delta, cada vez que se realice una reserva, se modifique o se cancele, se agregarán a esta tabla las líneas con los mensajes que sean necesarios para comunicar la disponibilidad afectada por la operación.
3. Debido a que no queremos guardar en la tabla información de la disponibilidad redundante, cuando se intente guardar en ella un mensaje cuyo período de fechas y tipo de recurso coincida con alguno existente ya en la cola, el mensaje existente será desechado (borrado) y el entrante será colocado el último en la cola, ya que la lógica de servidor de SiteMinder se limitará a procesar los mensajes de disponibilidad secuencialmente en el orden en que los reciba.
Por eso queremos que el orden de los mensajes en la tabla se ajuste realmente al momento en que se van realizando las operaciones que se generan. Si nos limitásemos a actualizar una fila, que puede tener otras veinte por delante, se perdería ese orden y la disponibilidad enviada no se ajustaría a la del momento presente.
4. La política de reenvío viene cubierta por nuestro propio cronJob que ya la implementa, realizando tres intentos si se produce alguna excepción dentro del manejador de la tarea.
Asimismo, la operación de leer la cola de mensajes de disponibilidad y notificarlos a SiteMinder, no vaciará la cola si no ha recibido respuesta de SiteMinder o si la respuesta recibida de siteMinder implica errores ajenos a las propias notificaciones (por ejemplo, unas credenciales inválidas).
Igualmente, ante caídas puntuales de los servicios o de la red, la propia política de reenvío del cronJob, reintentará la operación.
Las operaciones que hace el módulo de SiteMinder están encapsuladas en transacciones que se desharán si ocurre algún error o excepción. De ese modo, si el error ocurrió durante las comunicaciones con SiteMinder y no durante ningún proceso interno nuestro, cuando vuelva a reintentarse por la política de reintento del cronJob, no se producirán solapamiento de datos indeseables.
Para el caso extremo en que algunos envíos funcionen y otros fallen, debido a que se notifican sólo cuando se ha procesado todo correctamente y sin errores, los envíos que hayan llegado correctamente a SiteMinder simplemente se procesarán de tal modo que cuando se reintente la operación, SiteMinder ya no nos regresará de vuelta los mensajes relativos a ellos.
5. El sistema para calcular los períodos continuos que se enviarán en los mensajes de disponibilidad funciona de la siguiente manera:
A) Se obtiene el número de noches del período de la reserva.
B) Se itera ese período y se obtiene la disponibilidad del tipo de recurso reservado para cada noche.
C) Si la disponibilidad diaria no ha variado, se sigue iterando el bucle.
D) Si la disponibilidad diaria ha variado, se guarda el período en el array de períodos, asignando a su fecha de fin la fecha de inicio del día en que la disponibilidad del tipo de recurso varió.
Formulario de autorización
Para poder autorizar la integración entre la empresa y el sistema a través de una API, previamente tendrás que enviar el documento cumplimentado y firmado por ambas partes a Golfmanager. Para más información, dirígete al siguiente link.
5. Configuración del módulo en GolfManager
El módulo realmente es automático, ya que su código corre dentro de una tera programada, y lo único que necesitamos es configurar correctamente las credenciales de acceso con las correspondientes de la cuenta de SiteMinder del club que pretenda utilizarlo de manera integrada con GolfManager.
5.1. Mapeo de códigos inicial
Es necesario que antes de comenzar a funcionar se hayan mapeado correctamente algunos códigos. En nuestro caso, las equivalencias son las siguientes:
-
Room Code/InventoryCode: ID del tipo de recurso.
- Rate Code: ID del tipo de reserva.
5.2. La cola de notificaciones
En esta tabla se van guardando en el orden ya explicado los mensajes XML que se insertarán en la notificación de disponibilidad que se enviará cada 3 minutos. Obviamente, si no hay elementos en la tabla, no se realizará dicha notificación.
5.3. La tarea programada
En la sección de herramientas del menú de GolfManager V3 está el menú de tareas programadas. Cuando el módulo se instala agrega una de estas tareas y la información y resultado de sus operaciones se guardan para cada una de sus ejecuciones. Si la tarea provocó una excepción no manejada también quedará reflejado.
En este caso, vemos que el error está en el código del hotel que tenemos configurado y que SiteMinder nos contesta que no tenemos acceso a dicho código de hotel. En realidad, el código no existe, pero esta es la contestación que recibiremos de SiteMinder en todos los casos en que un código no coincida con alguno de los accesibles por el usuario acreditado.
Por otro lado, la primera operación que se realiza siempre cuando se ejecuta la tarea es la de obtención de las operaciones de reserva aún no contestadas desde SiteMinder. Esta operación no requiere de lógica por nuestra parte más que la de construirla con las credenciales habidas en la configuración del módulo.
Si dicha petición fallase por cualquier razón HTTP o la contestación recibida por parte de SiteMinder incluyera mensajes de error, el módulo automáticamente lanzará una excepción no manejada en este caso, comunicando los errores recibidos desde SiteMinder, abortando por consiguiente el resto de las operaciones.
De este modo, si había mensajes en la cola de envíos de SiteMinder, no se habrán procesado y permanecerán en la tabla hasta que se termine por ejecutar correctamente la tarea.