Diferencia entre revisiones de «Price Surfer - Export contable»
(Página creada con «= Introducción = El Web Services permite al cliente conectarse de manera transparente a la aplicación a través de un conjunto de funciones que pueden ser llamadas, d...») |
|||
| Línea 6: | Línea 6: | ||
Además de este manual, están disponibles los esquemas XML (.XSD) para validar los mensajes antes de ser enviados al Web Service, así como también mensajes XML de ejemplo para cada función. | Además de este manual, están disponibles los esquemas XML (.XSD) para validar los mensajes antes de ser enviados al Web Service, así como también mensajes XML de ejemplo para cada función. | ||
| + | |||
== Interfaz Cliente Simplificada == | == Interfaz Cliente Simplificada == | ||
| Línea 15: | Línea 16: | ||
* Protocolos estandards de su empresa | * Protocolos estandards de su empresa | ||
* No se requiere de ningún componente adicional. | * No se requiere de ningún componente adicional. | ||
| + | |||
== Requisitos de los clientes == | == Requisitos de los clientes == | ||
| Línea 20: | Línea 22: | ||
* Los pedidos de los clientes deben ser hechos desde una dirección pública y estática que esté registrada con NEMO. | * Los pedidos de los clientes deben ser hechos desde una dirección pública y estática que esté registrada con NEMO. | ||
* Client requests must be made via an HTTP POST request. Los pedidos del cliente deben ser hechos a través de un pedido POST de HTTP. | * Client requests must be made via an HTTP POST request. Los pedidos del cliente deben ser hechos a través de un pedido POST de HTTP. | ||
| − | * Toda la información enviada y recibida a traves de la interface va a ser guardada en UTF- | + | * Toda la información enviada y recibida a traves de la interface va a ser guardada en UTF-8 |
| − | + | ||
== Autenticación del Cliente == | == Autenticación del Cliente == | ||
Los headers del POST deben contener autenticación HTTP de tipo basic estandar, con nombre y usuario habilitado de Navigator (las mismas credenciales que se usan para ingresar en el backend). | Los headers del POST deben contener autenticación HTTP de tipo basic estandar, con nombre y usuario habilitado de Navigator (las mismas credenciales que se usan para ingresar en el backend). | ||
| + | |||
== Acceso == | == Acceso == | ||
1. URL del mensaje: URL de la API (según entorno) + nombre del mensaje | 1. URL del mensaje: URL de la API (según entorno) + nombre del mensaje | ||
| + | |||
URL de la API (según entorno): | URL de la API (según entorno): | ||
| Línea 35: | Línea 39: | ||
* QA: http://qanav.nemo.com.ar/backend_qa.php/api/ | * QA: http://qanav.nemo.com.ar/backend_qa.php/api/ | ||
* producción: http://<dominio>/backend.php/api/ | * producción: http://<dominio>/backend.php/api/ | ||
| + | |||
Los nombres de los mensajes disponibles son: | Los nombres de los mensajes disponibles son: | ||
| Línea 41: | Línea 46: | ||
* AgencyQueryRQ: Pedido de detalle de agencias | * AgencyQueryRQ: Pedido de detalle de agencias | ||
* BookingPaymentStatusRQ: Cambio de estado de reserva a pagado | * BookingPaymentStatusRQ: Cambio de estado de reserva a pagado | ||
| + | |||
Ejemplo de pedido de una agencia al servidor de QA: | Ejemplo de pedido de una agencia al servidor de QA: | ||
http://qanav.nemo.com.ar/backend_qa.php/api/AgencyQueryRQ | http://qanav.nemo.com.ar/backend_qa.php/api/AgencyQueryRQ | ||
| + | |||
2. La consulta: El POST debe llevar adjunto un archivo XML con igual nombre al mensaje (en el ejemplo “AgencyQueryRQ”) cuyo contenido será el de la consulta que se quiere hacer al WebService. | 2. La consulta: El POST debe llevar adjunto un archivo XML con igual nombre al mensaje (en el ejemplo “AgencyQueryRQ”) cuyo contenido será el de la consulta que se quiere hacer al WebService. | ||
| Línea 79: | Línea 86: | ||
= Mensajes soportados = | = Mensajes soportados = | ||
| − | Buscar reservas (BookingQuery) | + | |
| + | == Buscar reservas (BookingQuery) == | ||
| + | |||
Búsqueda de reservas de aéreos en un rango de fechas determinado. Retorna un listado de reservas correspondientes a las fechas ingresadas. | Búsqueda de reservas de aéreos en un rango de fechas determinado. Retorna un listado de reservas correspondientes a las fechas ingresadas. | ||
| + | |||
Recibe BookingsQueryRQ, retorna BookingsQueryRS. | Recibe BookingsQueryRQ, retorna BookingsQueryRS. | ||
| + | |||
La búsqueda incluye aéreos y hoteles. | La búsqueda incluye aéreos y hoteles. | ||
| + | |||
Se pueden ingresar como parámetros para la búsqueda: | Se pueden ingresar como parámetros para la búsqueda: | ||
| − | + | * fecha de creación | |
| − | + | * fecha de checkin | |
| − | + | * identificador de la agencia | |
| − | + | * nombre de pasajero | |
| − | + | * nombre de cliente | |
| + | |||
| + | |||
| + | == Solicitar información detallada de reservas (BookingDetails) == | ||
| − | |||
Consulta de información detallada de una reserva determinada especificando un identificador de la reserva. | Consulta de información detallada de una reserva determinada especificando un identificador de la reserva. | ||
| + | |||
| + | |||
Recibe BookingsDetailsRQ, retorna BookingsDetailsRS. | Recibe BookingsDetailsRQ, retorna BookingsDetailsRS. | ||
| − | Cambiar estado del pago de reservas (BookingPaymentStatus) | + | |
| + | == Cambiar estado del pago de reservas (BookingPaymentStatus) == | ||
| + | |||
Cambio de estado de pago de una reserva. Retorna el resultado de la transacción. Podrá indicar si el cambio fue realizado con éxito o en caso contrario notificar qué evento se produjo por el cual no pudo realizarse el cambio. | Cambio de estado de pago de una reserva. Retorna el resultado de la transacción. Podrá indicar si el cambio fue realizado con éxito o en caso contrario notificar qué evento se produjo por el cual no pudo realizarse el cambio. | ||
| + | |||
| + | |||
Recibe BookingPaymentStatusRQ, retorna BookingPaymentStatusRS. | Recibe BookingPaymentStatusRQ, retorna BookingPaymentStatusRS. | ||
| − | Consultar info de agencia (AgencyQuery) | + | |
| + | == Consultar info de agencia (AgencyQuery) == | ||
| + | |||
Consulta de información detallada de una agencia determinada especificando el ID de agencia o el nombre de la misma. | Consulta de información detallada de una agencia determinada especificando el ID de agencia o el nombre de la misma. | ||
| + | |||
| + | |||
Recibe AgencyQueryRQ, retorna AgencyQueryRS. | Recibe AgencyQueryRQ, retorna AgencyQueryRS. | ||
| − | + | ||
| − | + | ||
| + | = Documentos XML = | ||
| + | |||
| + | |||
| + | == Mensaje BookingsQuery: Buscar reservas == | ||
| + | |||
La búsqueda de reservas permite obtener un listado de reservas con toda la información referida a cada reserva en particular. | La búsqueda de reservas permite obtener un listado de reservas con toda la información referida a cada reserva en particular. | ||
| + | |||
El método BookingsQuery recibe un documento BookingsQueryRQ y retorna un documento BookingsQueryRS. | El método BookingsQuery recibe un documento BookingsQueryRQ y retorna un documento BookingsQueryRS. | ||
| + | |||
| + | |||
| + | === BookingsQueryRQ === | ||
Revisión del 17:56 7 nov 2012
Introducción
El Web Services permite al cliente conectarse de manera transparente a la aplicación a través de un conjunto de funciones que pueden ser llamadas, desde las páginas web de sus sitios.
A través del servicio web un mayorista podrá buscar reservas de aéreos, solicitar información detallada de reservas, cambiar el estado del pago de reservas y consultar información de agencias. Todo a través de una interfaz única basada en el intercambio de documentos XML, que será descripta en esta guía de uso.
Además de este manual, están disponibles los esquemas XML (.XSD) para validar los mensajes antes de ser enviados al Web Service, así como también mensajes XML de ejemplo para cada función.
Interfaz Cliente Simplificada
El API va a usar protocolos HTTP estandard. Lo único que se requiere es un pedido de POST del HTTP.
Esto le otorgará las siguientes ventajas.
- Protocolos estandards de su empresa
- No se requiere de ningún componente adicional.
Requisitos de los clientes
- Los pedidos de los clientes deben ser hechos desde una dirección pública y estática que esté registrada con NEMO.
- Client requests must be made via an HTTP POST request. Los pedidos del cliente deben ser hechos a través de un pedido POST de HTTP.
- Toda la información enviada y recibida a traves de la interface va a ser guardada en UTF-8
Autenticación del Cliente
Los headers del POST deben contener autenticación HTTP de tipo basic estandar, con nombre y usuario habilitado de Navigator (las mismas credenciales que se usan para ingresar en el backend).
Acceso
1. URL del mensaje: URL de la API (según entorno) + nombre del mensaje
URL de la API (según entorno):
- desarrollo: http://navigator/backend_dev.php/api/
- QA: http://qanav.nemo.com.ar/backend_qa.php/api/
- producción: http://<dominio>/backend.php/api/
Los nombres de los mensajes disponibles son:
- BookingsQueryRQ: Búsqueda de reservas
- BookingsDetailsRQ: Pedido de detalle de reservas
- AgencyQueryRQ: Pedido de detalle de agencias
- BookingPaymentStatusRQ: Cambio de estado de reserva a pagado
Ejemplo de pedido de una agencia al servidor de QA:
http://qanav.nemo.com.ar/backend_qa.php/api/AgencyQueryRQ
2. La consulta: El POST debe llevar adjunto un archivo XML con igual nombre al mensaje (en el ejemplo “AgencyQueryRQ”) cuyo contenido será el de la consulta que se quiere hacer al WebService.
Códigos de respuesta de la petición HTTP
La respuesta del WebService puede tomar diferentes códigos, a continuación se detalla el significado de cada una.
| Código | Respuesta |
|---|---|
| 200 | OK |
| 400 | No valida el XML de la consulta |
| 401 | Fallo de autenticación |
| 404 | No se encontró el archivo XML de la consulta |
| 404 | No se encontraron agencias con los parámetros de búsqueda ingresados |
| 404 | No se encontraron reservas con los parámetros de búsqueda ingresados |
| 503 | No se pudo conectar con el core de navigator |
Por cualquier consulta recuerde dirigirse al mail de Soporte Técnico:
support@pricenavigator.net
Mensajes soportados
Buscar reservas (BookingQuery)
Búsqueda de reservas de aéreos en un rango de fechas determinado. Retorna un listado de reservas correspondientes a las fechas ingresadas.
Recibe BookingsQueryRQ, retorna BookingsQueryRS.
La búsqueda incluye aéreos y hoteles.
Se pueden ingresar como parámetros para la búsqueda:
- fecha de creación
- fecha de checkin
- identificador de la agencia
- nombre de pasajero
- nombre de cliente
Solicitar información detallada de reservas (BookingDetails)
Consulta de información detallada de una reserva determinada especificando un identificador de la reserva.
Recibe BookingsDetailsRQ, retorna BookingsDetailsRS.
Cambiar estado del pago de reservas (BookingPaymentStatus)
Cambio de estado de pago de una reserva. Retorna el resultado de la transacción. Podrá indicar si el cambio fue realizado con éxito o en caso contrario notificar qué evento se produjo por el cual no pudo realizarse el cambio.
Recibe BookingPaymentStatusRQ, retorna BookingPaymentStatusRS.
Consultar info de agencia (AgencyQuery)
Consulta de información detallada de una agencia determinada especificando el ID de agencia o el nombre de la misma.
Recibe AgencyQueryRQ, retorna AgencyQueryRS.
Documentos XML
Mensaje BookingsQuery: Buscar reservas
La búsqueda de reservas permite obtener un listado de reservas con toda la información referida a cada reserva en particular.
El método BookingsQuery recibe un documento BookingsQueryRQ y retorna un documento BookingsQueryRS.
