Table of Contents | ||
---|---|---|
|
Introducción y Conceptos
...
Introduction and Concepts
Through this guide, developers will be able to create their own widgets to embed in the web sites and from it, access via parameters to the E-COMMERCE booking.
Este documento es una guía para el desarrollador web, que explica como obtener y conectar el Widget desarrollado con el motor de reservas.
...
Seach flight: Dedicado únicamente para la búsqueda de vuelos y generado de reservas.
...
Otros formularios embebidos: Servicios foráneos, como reservas de hoteles, alquiler de autos, etc.
Para habilitar esta opción, se necesita enrolar la aplicación en cuestión al listado de aplicaciones pertenecientes al cliente.
Que es un widget?
Es una aplicación pequeña que se incluye en la web del cliente, con el objetivo de ampliar la funcionalidad que ofrece E-COMMERCE booking.
Ofrece KIU un widget?
Si. KIU provee de un widget integrable de forma embebida mediante un iframe cuando el producto E-COMMERCE es creado, pero, posiblemente este no contempla todos los aspectos que requiere el cliente por lo tanto, este puede desarrollar su propio widget y conectarse con E-COMMERCE, con la ayuda de nuestros servicios API REST, los cuales proveen todos los datos necesarios para armar un formulario personalizado y garantizar la compatibilidad con el resto del flujo de reserva.
Embebido de Widget via Iframe
Url para usar iframe
Esta url, es para ser usada en caso de preferir utilizar el widget que Kiu proporciona, dentro de un iframe en la pagina web del cliente.
functionalities.
This document explains how to obtain and connect the developed Widget with the booking engine, detailing the services and fields that must be considered in order to build the tool and achieve the searches to be displayed later in the next SPA, according to the selected flow.
The booking screen, is configurable, since different flows converge there, as listed below:
Search flight: Used only for flight searching and bookings generation
Manage my booking: Used to retrieve a booking previously generated and make changes to it
Web check-in: Dedicated to managing the check-in on a segment that is about to begin
What is a widget?
A Widget is a simple application that can be included on the airline's website aiming to extend the functionality to our e-commerce. We provide a widget that can be embedded using an HTML iframe tag into any website. Nevertheless, if this widget does not has all that is needed, a custom widget can be created using our API REST services. These services will provide all the necessary data to guarantee compatibility through the booking flow.
Embedded Widget via Iframe
Url for the iframe
In case you need to use KIU widget you can add it to yor code using an iframe <iframe src="https://ecommerce-xx-stage.kiusys.net/booking/widget/
De usarse esta opción, solo se necesita agregar esta url a un iframe, como el siguiente ejemplo: <iframe src="https://ecommerce-xx-stage.kiusys.net/booking/widget/"</iframe>
Widget personalizado
Formulario desarrollado totalmente por el cliente. Suponiendo que el desarrollador crea el formulario en HTML (por ejemplo), para generar el widget, hay ciertos campos mandatorios, que deben existir para poder enviar la información mínima necesaria a E-COMMERCE flightresults o pantalla que corresponda según el flujo, y de esta manera obtener resultados.
Consideraciones generales en cuanto al desarrollo del widget personalizado
E-COMMERCE, es una aplicación diseñada bajo la arquitectura cliente-servidor, en donde el cliente está desarrollado bajo el paradigma de Simple Web Application (SPA), que en resumen, cada paso del flujo, es independiente entre el resto, y obviamente es independiente del servidor backend, en donde se mantiene la lógica de negocio, que proveen de las configuraciones. Esta arquitectura, brinda al cliente, la posibilidad de estar desarrollado en cualquier tecnología, con cualquier patrón de diseño, solo debe contemplar que debe mantener comunicación con nuestro servidor, quien provee servicios para compartir información.
El Widget debe contemplar y obtener el contenido en base a la configuración de la brindada por kiu, con el objetivo de realizar las búsquedas de acuerdo a los requerimientos comerciales del cliente. Esta información reside en Backoffice y debe estar completamente configurado al momento de desarrollar e implementar el widget.
En esta guía se explica como conectarse y obtener el contenido a desplegar de acuerdo a la configuración mencionada.
Url general para implementar widget personalizado
La url a utilizar para poder consumir de los servicios necesarios para poder implementar y utilizar el widget personalizado, para por ejemplo, carrier XX y ambiente STAGE: "</iframe>
Custom Widget
Assuming that the developer builds a HTML form, there are some mandatory fields to be sent in order to access the e-commerce filghtresults SPA or any other flow.
General considerations
E-COMMERCE is a client-server application, where the client is built under the Single Page Application (SPA) model. Each step of the flow is independent of the rest, and also, independent from the backend server where the business logic resides.
The widget must obtain the content and configurations stored in the e-commerce backoffice. This guide explains how to connect and get this content.
General Url to implement a custom widget
To consume the necessary services a valid url must be used, for example, this this url it is used for xx carrier int the testing enviroment
https://ecommerce-xx-stage.kiusys.net/
...
Services
Get Applications
E-COMMERCE , es un sistema compuesto por componetizados, reutlizables entre si, sin embargo, se dividen en aplicaciones, por ejemplo, searchflight, manage my booking y webcheckin. Las aplicaciones se pueden configurar en cuanto al flujo, o simplemente, se se quiere habilitar, o no.
Por tal razón, es importante configurar las aplicaciones en el backoffice, y tener muy presente, que ante cualquier cosa, al momento de implementar el widget, necesitamos obtener el listado de aplicaciones disponibles. Para ello se hace uso de este servicio.is divided into applications searchflight, manage my booking y webcheckin. The flow of these apps is set in the backoffice. To get a list of the available applications this service can be used
Url:
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/applications/xx
ImplementaciónImplementation:
Expand | ||
---|---|---|
|
RespuestaResponse:
Expand | |||
---|---|---|---|
Code Block |
| ||
|
Diccionario de respuesta:
Response: No es mas que el listado de aplicaciones o módulos dados de alta en el backoffice.
Get Flow
...
Get Flow
GetFlow is the second service to use, where you should obtain a session key and the flow configuration of the selected app. This sessionkey it's going to be used in the next request. Additionally having the flow will give us the next screen to be rendered.
Url:
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/flow/?carrier=xx&app=ecommerce
...
Implementation:
Expand | ||
---|---|---|
|
...
Response:
Expand | ||
---|---|---|
|
...
Response dictionary:
Expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Get configs
Es el servicio principal, proveedor de toda la configuración de la aplicación seleccionada.
Hay que destacar que no todas las aplicaciones necesitan de este request.
Por el momento, solo searchflight y webcheckin, necesitan ejecutar este request.
Por tal motivo, recomendamos tener este aspecto muy presente, y gestionar la funcionalidad, apoyados en un esquema de configuración, respecto a la lista de aplicaciones.
Por ejemplo:
|
Get configs
This is the main service where we will have all the selected app configuration (only for searchflight and webcheckin)
Expand | ||
---|---|---|
|
Este json, no es mas que una sugerencia, que sirve para configurar lo que, hasta ahora, el widget necesita.
app: sirve para setear la aplicación seleccionada
module: para definir el path url que necesita el request al backend
needConfigs: Para indicar que necesita ejecutar el getConfigsThis json is a suggestion for the developer. It shows what is needed in each app.
Url (app searchflight):
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/configs/
...
Implementation:
Expand | ||
---|---|---|
|
...
Response:
Expand | ||
---|---|---|
|
...
Response Dictionary:
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Basado en esta respuesta, el desarrollador cuenta con la suficiente información para desplegar dentro de los distintos campos del widget:
Aeropuertos de salida y arribo
Rutas habilitadas
Tipos de pasajeros soportados
Cantidad máxima permitida de pasajeros para búsquedas
Tipo de viajes soportados (Ida o Ida y vuelta)
Monedas soportadas, por país
Mensajes temporales y políticas de privacidad
Códigos promocionales
Listado de Cabinas
Traducciones
También en base a esta información puede generar filtros y validaciones del lado del cliente. Based on thius response the developer has enough information to display some fields on the widget, enable routes, different types of pax, and max quantity, types of journey, currencies, cabins, temporary messages, etc...
Url (app webcheckin):
https://ecommerce-xx-stage.kiusys.net/retrievebooking/api/v1/configs/
ImplementaciónImplementation:
Expand | ||
---|---|---|
|
RespuestaResponse:
Expand | ||
---|---|---|
|
Diccionario de respuesta:
Expand | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Por el momento, solo devuelve la configuración de country settings, necesaria para hacer la búsqueda de la reserva. Se espera que mas adelante, vengan mas configuraciones…
Get Dates (Usado para searchflight)
Devuelve el listado de fechas con disponibilidad de vuelos desde el día actual hasta los posteriores 330 días. Este servicio debe ser usado teniendo implementado los inputs de origen y destino y tipo de viaje, (este último no es requerido). De manera que una vez se seleccione el valor para los tres campos especificados anteriormente, puede ejecutar la petición http.
Parámetros:
origin: El código del aeropuerto de origen. Ejemplo: 'AEP'.
destination: El código del aeropuerto de destino. Ejemplo: 'BUE'.Returns a list of dates with the availability of flights from today up to 330 days. Origin and destination must be specified
Parameters:
origin: airport code, for example 'MAD'
destination: airport code, for example 'CUN'
Url:
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/dates/?origin=${origin}&destination=${destination}
...
Implementation:
Expand | ||
---|---|---|
Este endpoint se ejecuta por get, enviado This endpoint run by GET method, with query params
|
...
Response:
Expand | ||
---|---|---|
|
Diccionario de respuesta:
En esta respuesta obtenemos todas las fechas con disponibilidad desde el día actual hasta 330 días después.
ow: Representa las fechas disponibles para vuelos one_way
rt: Representa vuelos round_trip.
La idea de esta información, es tener lo necesario para iniciar el componente “datepicker” indicándole que fechas son las que debe habilitar. En el caso de que el componente usado no tenga este atributo y por el contrario admita fechas para des-habilitar, se puede usar este listado, comparándolo contra los 330 días, de modo que obtendríamos los días sin disponibilidad que necesitaríamos, (según el componente usado).
Post action (searchflight)
Este servicio se encarga de enviar los datos para la búsqueda de disponibilidad, una vez el usuario haya completado todos los campos mínimos requeridos. La petición debe hacerse vía POST AJAX y al obtener la respuesta, basta con hacer una re-dirección a la siguiente url según el flujo obtenido, mediante el servicio get_flow
Parámetros:
country_setting: Configuración de país seleccionada por el pasajero.
session_key: session_key obtenido en get_sessions.
journey_type: Tipo de viaje.
origin: Código de origen seleccionado por el pasajero.
destination: Código de destino seleccionado.
departure_date: Fecha de salida seleccionada por el pasajero.
return_date: Fecha de retorno, en el caso de vuelos ida y vuelta.
adults: Cantidad de pasajeros adultos.
minors: Cantidad de pasajeros menores de edad.
infants: Cantidad de pasajeros infantes.
cabin: Cabina seleccionada por el pasajero.
promo: Código promocional.
Url:
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/action/
...
This response can be used to disable days in the datepicker input.
Post action (searchflight)
This service is used to send all the required data for a flight search. The request must be done using POST AJAX and after the response, a redirect must take place to the next step of the flow.
Parameters:
country_setting: Config selected by the passenger
session_key: previously obtained session_key (get_sessions)
journey_type: type of journey (ow/rt)
origin
destination
departure_date
return_date
adults
minors
infants
cabin
promo
Url:
https://ecommerce-xx-stage.kiusys.net/searchflight/api/v1/action/
Implementation:
Expand | ||
---|---|---|
|
Post action (manage booking)
Este servicio se encarga de enviar los datos para la búsqueda de una reserva, una vez el usuario haya completado todos los campos mínimos requeridos. La petición debe hacerse vía POST AJAX y al obtener la respuesta, basta con hacer una re-dirección a la siguiente url según el flujo obtenido, mediante el servicio get_flow
...
This service is responsible for sending the data to search for a reservation, once the user has completed all the minimum required fields. The request must be made via POST AJAX and when obtaining the response, simply redirect to the following url according to the flow obtained, by get_flow service.
Params:
point_of_sale: Por el momento, tiene el campo “user“, el cual debe ser igual al código del carrier. (onjetoAt the moment, it has the "user" field, which must be the same as the carrier code (object)
record_locator: Código de reserva ingresado por el usuarioReservation code, inserted by user. (string)
last_name_or_grp_name: Apellido del pasajeroPassenger lastname. (string)
Url:
https://ecommerce-xx-stage.kiusys.net/managebooking/api/v1/action/
...
Expand | ||
---|---|---|
|
Post action (Web checkin)
Este servicio se encarga de enviar los datos para la búsqueda de una reserva a checkear, una vez el usuario haya completado todos los campos mínimos requeridos. La petición debe hacerse vía POST AJAX y al obtener la respuesta, basta con hacer una re-dirección a la siguiente url según el flujo obtenido, mediante el servicio get_flow This service is responsible for sending the data to retrieve the reserervation to do checkin, once the user has completed all the minimum required fields. The request must be made via POST AJAX and when obtaining the response, simply redirect to the following url according to the flow obtained, by get_flow service.
Parámetros:
point_of_sale: Debe contener los datos obtenidos previamente en el Data obtained previously in get_configs service (objetoobject)
record_locator: Código de reserva ingresado por el usuarioReservation code, inserted by user. (string)
last_name_or_grp_name: Apellido del pasajeroPassenger lastname. (string)
Url:
https://ecommerce-xx-stage.kiusys.net/retrievebooking/api/v1/action/
...
Expand | ||
---|---|---|
|
...
Response (searchflight, manage my booking, web checkin):
Expand | ||
---|---|---|
Es importante obtener un estado 200 y que dentro de It is important to obtain a 200 status and that within response.response ['session-display'] tengamos el valor de nuestra session key mencionada anteriormente. En ese escenario sabemos que tenemos ya todo preparado para re-direccionar a la siguiente pantallawe have the value of our session key mentioned above. In this scenario we know that we have everything ready to redirect to the next screen. Manage booking y and web checkin, puede devolver un 400, indicando que la reserva o el pasajero no existe. Es importante tener en cuenta este caso, para, en tal caso, mostrar un mensaje al usuarioyou can return a 400, indicating that the reservation or the passenger does not exist. It is important to take this case into account, in order to display an error message to the user.
|
...
Widget
...
El objetivo de este apartado es aprovechar el contenido obtenido en los servicios disponibles, para armar el formulario de búsqueda correspondiente, realizar las validaciones pertinentes y finalmente poder enviar información a la siguiente pantalla del flujo que corresponda.
Lo que a continuación se mostrará, es basado en un desarrollo sencillo, usando bootstrap, javascript y jquery.
En vista de que en este widget, debemos agregar mas de un formulario, Una manera muy sencilla de resolverlo, es implementando tabs, como los que ofrece boostraps. La idea es que al ir navegando entre pestañas, cambie el formulario y las variables de entorno necesarias, para poder hacer request al backend correspondiente
Web assembly (searchflight).
Para evitar ataques contra el servicio de shopping, usado en la pantalla flightresults, se implementó un control mediante WebAssembly, en donde generamos un token válido que debe ser enviado en el payload de https://ecommerce-xx-dev.kiusys.net/searchflight/api/v1/action/.
Ya que este será validado en nuestro backend por fecha de vencimiento y datos.
En este sentido, es importante integrar correctamente algunos tags dentro del html, listados a continuación:
...
Build
The objective of this section is to take advantage of the content obtained in the available services, to create the corresponding search form, carry out the pertinent validations and finally be able to send information to the next screen of the corresponding flow.
Web assembly (searchflight).
To avoid attacks against the shopping service, used in the flightresults screen, a control was implemented through WebAssembly, where we generate a valid token that must be sent in the https://ecommerce-[carrier]-[env].kiusys.net/searchflight/api/v1/action/.
. Since this will be validated in our backend by expiration date and data, in this sense, it is important to follow the following steps:
include wasm folder in your project:
Because the widget implemented by the carrier would have a different DNS than the one provided by Kiu, to generate the search screen, the client must include the wasm folder in its development, avoiding errors by CORS ORIGIN. In this way, you will be able to generate the webassembly token.
The wasm folder should be located so that the index where the widget is located can fetch the files.
View file | ||
---|---|---|
|
Of the three files within the wasm folder, only the wasm.css file can be modified.
In order to serve the test.wasm file, it is essential to configure location and mimetypes on the configured server. For example, if we use nginx server, it is as shown in the following example:
Expand | ||
---|---|---|
|
The file test.wasm is only served using the mimetype application/wasm wasm;
. Without this configuration, it cannot be resolved. Additionally, because it is a large file, it must be compressed. For this we use gzip;
Insert WASM_URL: This is required to be used within the js loaded later. Pay special attention that it ends with '/' and that the variable is injected into the window object. (The DNS must be that of the carrier)
<script type="text/javascript"> window.WASM_URL = "https://ecommerce-xx-stage.kiusys.netairline-webpage/wasm/"; </script>
Insertar Polyfill: Hace posible la compatibilidad con navegadores de versiones antiguasEmbed Polyfill: Makes compatibility with older version browsers possible.
<script crossorigin="anonymous" src="https://polyfill.io/v3/polyfill.min.js?features=blissfuljs%2Cdefault%2Ces2015%2Ces2016%2Ces2017%2Ces2018%2Ces5%2Ces6%2Ces7%2CBlob%2CArray.prototype.forEach"</script>
Insertar validación para Insert validation for Microsoft IE: Internet Explorer no es soportado, por tal motivo, es importante avisar al usuario que debe cambiar de medio. Por eso, se recomienda agregar el siguiente tag, pudiendo ademas modificar el alerta por uno de preferencia del clienteis not supported, for this reason, it is important to warn the user that they must change the browser. For this reason, it is recommended to add the following tag, also being able to modify the alert for one of the client's preference.
<script type="text/javascript">
document.addEventListener("DOMContentLoaded", function(event) {
var ua = window.navigator.userAgent;
if ( ua.indexOf("MSIE ") > -1 || ua.indexOf("Trident/") > -1) {
alert('This website does not support your current version of your web browser')
}
});
</script>
Insertar Insert wasm.css file: El DNS debe ser la asignada al The DNS must be that of the carrier.
<link rel="stylesheet" type="text/css" href="https://ecommerce-xx-stage.kiusys.netairline-webpage/wasm/wasm.css">
Insert wasm_load.js file: Very important tag, since it is the one that loads the WebAssembly file, responsible for generating the token. (The DNS must be that of the carrier).
<script type="text/javascript" src="https://airline-webpage/wasm/wasm_load.cssjs">
Insertar wasm_load.js: Tag muy importante, puesto que es el que hace la carga del archivo WebAssembly, encargado de generar el token. (El DNS debe ser la asignada al carrier).
<script type="text/javascript" src="https://ecommerce-xx-stage.kiusys.net/wasm/wasm_load.js"</script>
Una vez se hayan cargado los scripts descritos anteriormente, solo podremos generar el token en un solo momento, luego de que el usuario completó el formulario, por lo que debemos generar el token en el momento que el usuario hace click en el botón “search“. Agregando de alguna manera la key wasm_token, al objeto que será enviado por post al backend.
Debemos hacer uso de la funcion validateForm() (Recordar que se puede invocar una sola vez, de querer re usarla, es necesario recargar la pantalla). Suponiendo que nuestro payload está dentro una variable “formData”:formData.wasm_token = validateForm(JSON.stringify(formData))
Posteriormente se haría el post hacia …/action.
Verificar que se envía el wasm_token
HTML
El el siguiente archivo .zip, puedes obtener una versión de inicio, para implementar un widget desde cero</script>
Once the scripts described above have been loaded, we can only generate the token in a single moment, after the user has completed the form, so we must generate the token when the user clicks on the "search" button. . Adding in some way the key wasm_token, to the object that will be sent by post to the backend.
We must make use of the validateForm() function (Remember that it can be invoked only once, if we want to reuse it, it is necessary to reload the screen). Assuming that our payload is inside a "formData" variable:
formData.wasm_token = validateForm(JSON.stringify(formData))
Later the post would be made towards… / action.
Note: Verify that the wasm_token is sent.
HTML
Note |
---|
IMPORTANT NOTE This is meant to be used an implementation guideline for developers; it is not meant to be used within the development. This HTML should not be used as it is. It is not adapted to work on all browsers, devices, or their versions. This widget needs to be adjusted and a certification process is required before going live where all parties must be involved (airline, website developer, Kiu) |
What will be shown next is based on a simple development, using bootstrap, javascript and jquery.
In view of the fact that in this widget, we must add more than one form. A very simple way to solve it is by implementing tabs, such as those offered by boostraps. The idea is that when navigating between tabs, change the form and the necessary environment variables, in order to make a request to the corresponding backend.
In the following .zip file, you can get the home version, to implement a widget from scratch.
View file | ||
---|---|---|
|
Si se necesita probarlo en local, y no se tiene servidor corriendo, puede instalarse nodejs, y con seguir los pasos del readme, inicia. Si cuentan con un servidor nginx o se prefiere probarlo dentro de un VPS (por ejemplo), puede tomarse el archivo widgetBooking.html y utilizarlo directamente.
Link de pruebas
Por medio de este, puede probarse directamente en el dns de kiusys.com. Puede usarse dev, qa o stage. Para ello, basta con agregar via queryparams, la key env con el valor que se prefiera, así como cambiar de If you need to test it locally, you can install nodejs, and with following the readme steps, it starts. If you have an nginx server or if you prefer to test it within a VPS (for example), you can take the widgetBooking.html file and use it directly.
Test link:
Through this, it can be tested directly in the DNS of kiusys.com. You can use dev, qa, or stage. To do this, simply add via queryparams, the env key with the value you prefer, as well as change the carrier.
https://apps-dev.kiusys.com/tests/custom_widget_/booking_custom.html?env=stage&carrier=xx
Validaciones recomendadas
Mas allá que la aplicación E-COMMERCE tiene sus propias validaciones en el backend, debemos realizar ciertas recomendaciones a los desarrolladores, sobre algunas validaciones a realizar del lado del cliente (Front-end), con el objetivo de evitar errores de búsqueda inconsistentes y generar un proceso mas eficiente.
Código de reserva - Apellido:
Debe procurarse que la reserva exista, y el apellido sea extactamente el mismo usado en la reserva. Importante, validar la cantidad de caracteres, acentos, o la letra “Ñ”, por ejemplo.
Origen - Destino:
La respuesta de Get_config devuelve la lista de rutas habilitadas para búsquedas configuradas en el backoffice. Basado en esta información, el desarrollador puede filtrar y validar las opciones que estén relacionadas y así optimizar los resultados de las búsquedas. Este filtro se realiza por ejemplo en la funcion javascript filterRoute(), Esta debe usarse en un evento onkeyup
Fechas:
El formato soportado de fechas es YYYY-MM-DD (ejemplo: 2020-04-06). El desarrollador puede desplegar en el formulario en diferentes formatos de acuerdo a la zona en la que se encuentre, pero debe considerar hacer la transformación para respetar el formato soportado y evitar de esta manera que E-COMMERCE devuelva error de formato.
Fecha de salida:
La fecha de salida debe considerarse desde la fecha actual a futuro y no mas allá de 330 días en futuro. La aplicación por estándar de la industria soporta búsquedas de disponibilidad hasta 330 días a futuro de la fecha actual. Esto lo especificamos en el apartado Get_dates, y le damos uso en la funcion javascript manageDates().
Fecha de regreso:
La fecha de regreso debe validarse contra la fecha de salida. Esta no puede ser anterior a la fecha fijada como salida y no debe ser superior a 330 días a futuro.
Pasajero adulto:
Recomendamos que el valor default sea 1. No se acepte 0, para evitar la solicitud vía canal de ventas web de menores no acompañados que lleva consigo una proceso interno de la línea aérea para su autorización. De igual manera, estas configuraciones vienen incluidas en la respuesta de Get_configs, campo passenger_types.
Pasajeros infantes:
Por una lógica propia de la industria, debe existir previamente un adulto antes de agregar un infante. Si existe mas de un pasajero Infante, debe existir la misma cantidad de adultos puesto que solamente se puede asociar un pasajero infante y solo uno a un pasajero adulto.
Envío de datos a E-COMMERCE:
El servicio Post action es usado para el envío de datos de búsqueda vía AJAX, no debe ser usado en un evento form submit, ya que no admite re-direcciones. El uso correcto de este servicio, es: una vez obtenida la respuesta con status 200, debemos hacer una re-dirección hacia la siguiente pantalla E-COMMERCE, Dicha información, la provee el servicio Get flow, utilizado de primero en el flujo de integración, cuya información debe ser guardada en el cliente.
...
Required validations
Beyond the fact that the E-COMMERCE application has its own validations in the backend, we must make certain recommendations to the developers, about some validations to be carried out on the client side (Front-end), in order to avoid inconsistent search errors and generate a more efficient process.
Reservation code - Surname:
It must be ensured that the reservation exists, and the surname is exactly the same as the one used in the reservation. Important, validate the number of characters, accents, or the letter "Ñ", for example.
Origin destiny:
The Get_config response returns the list of search-enabled routes configured in the backoffice. Based on this information, the developer can filter and validate the related options and thus optimize the search results. This filter is performed for example in the javascript function filterRoute(), This must be used in an onkeyup event
Dates:
The supported date format is YYYY-MM-DD (example: 2020-04-06). The developer can display the form in different formats according to the area in which it is located, but should consider doing the transformation to respect the supported format and thus avoid E-COMMERCE returning a format error.
Departure date:
The departure date must be considered from the current date to the future and not beyond 330 days in the future. The industry standard application supports availability searches up to 330 days in the future from the current date. We specify this in the Get_dates section, and we use it in the javascript manageDates() function.
Return date:
The return date must be validated against the departure date. This cannot be earlier than the date set as departure and must not be more than 330 days in the future.
Adult passenger:
We recommend that the default value be 1. 0 is not accepted, to avoid the request via the web sales channel of unaccompanied minors that carries with it an internal airline process for authorization. Likewise, these configurations are included in the response to Get_configs, passenger_types field.
Infant passengers:
By industry logic, an adult must first exist before adding an infant. If there is more than one Infant passenger, there must be the same number of adults since only one infant passenger and only one can be associated with an adult passenger.
Sending data to E-COMMERCE:
The Post action service is used to send search data via AJAX, it should not be used in a form submit event, since it does not support redirects. The correct use of this service is: once the response with status 200 is obtained, we must redirect to the next screen E-COMMERCE, This information is provided by the Get flow service, used first in the integration flow , whose information must be stored in the client.
To do the redirection, based on the flow, we can make use of the handlePostResponse() function, or directly, taking into account the general url, the session data obtained previously and the Post Action response. Starting from the fact that the first screen of any of the flows is the one we are in, and it would be position 0 of the list, we can simply obtain the next one, that is, position 1, and from this, obtain the corresponding path to make the re -dicection. Under that context, one option would be to use something like the following:
Code Block |
---|
let nextUrl = session.flow[1].url
window.location.href = `${mainUrl}${nextUrl}?carrier=${carriercode}&lang=${language}&session_id=${session.session_key}` |
ENGLISH VERSION
Througout this I hope the exposed information is of your total utility. Good luck!