Identificar si el servicio permite una completa sincronización bidireccional o si, por el contrario, está limitado a ciertos apartados. Se debe tomar en cuenta que información se tiene disponible a lo largo del flujo de trabajo de la aplicación de BUQ para identificar que endpoints se pueden consumir con la información que se tiene en el momento. En caso de que la información esté incompleta puede optarse por consumir el endpoint con la información incompleta y posteriormente actualizarla cuando se tenga disponible.

En este apartado se debe poner en variables de entorno y configuraciones de la aplicaciones aquellas variables que contengan datos sensibles o no deban ser expuestas abiertamente. Así como establecer un correcto canal de logueo para la información.

Identificar los parámetros necesarios para completar la autenticación del servicio. Esta información puede provenir de variables de entorno, inputs que ingrese el usuario en la aplicación o de algún otro servicio.

Se debe considerar todos los tipos de respuestas ya sea exitoso o fallida para el logueo y actualización de campos en base de datos si es necesario. En caso de requerir consumir el endpoint cada X cantidad de tiempo se puede generar un trabajo que se ejecute a la misma cantidad de tiempo requerida.

Se debe identificar el endpoint necesario para crear un evento y la información que es requerida para su consumo. Es importante tomar en cuenta el método de autenticación y las cabeceras necesarias para el consumo. Esta información puede provenir ya sea de base de datos si es que la información se guarda en ella al hacer logueo o del resultado de hacer login antes de llamar el servicio.

Identificar en qué flujo del aplicativo de BUQ se cuenta con toda la información que requiere el servicio para ser consumido. Se debe identificar que todos los parámetros obligatorios se tengan en cierto punto en el aplicativo de BUQ y posteriormente evaluar si hace falta actualizar la información cuando se cuente con la misma utilizando el endpoint de actualización.

Una vez creado el evento identificar qué parámetros de la respuesta es importante guardar en la base de datos para identificar el evento cuando se realice una reserva o se ocupe para actualizar el evento.

En caso que el servicio cuente con un endpoint para actualizar el cupo disponible del evento se debe consumir cada que ocurra una reserva desde BUQ para notificar que la cantidad de lugares disponibles ha disminuido. Se debe prestar atención en cómo cada proveedor pide implementar este endpoint o si hay reglas que se deben cumplir.

En caso de que el proveedor tenga un Webhook para notificar una reserva desde su aplicación o servicio se deberá construir un controlador que maneje la información recibida y genere la reserva en el sistema de BUQ. En caso de que el usuario no exista también deberá registrarlo. Se puede solicitar al proveedor un ejemplo del cuerpo de la petición para poder trabajar en ambiente de desarrollo. En este apartado es importante identificar cuáles son los campos que permiten identificar un evento y usuario.

En caso que el proveedor proporcione un endpoint para registrar el webhook que escuchara las reservas desde la aplicación o servicio del proveedor se deberá registrar con una IP que sea pública o que pueda ser consumida por el proveedor. Esta parte puede realizarse manualmente o de manera automática.

En caso de que el proveedor también proporcione la opción de despachar un Webhook cuando en su aplicación o servicio ocurra un check-in se deberán seguir los mismos pasos que el Webhook de reservaciones.

Realizar pruebas desde la aplicación o servicio del proveedor para verificar que la sincronización entre sistemas sea la correcta. Realizar pruebas de sincronización creando reservas desde BUQ

Seguir las políticas de la compañía para subir los cambios a QA