Resumen
Los servicios parametricos son una nueva funcionalidad incorporada en el API Ceibo ( o API Tarjeta habientes ) .
Esta funcionalidad permite crear nuevos servicios dentro del API de Ceibo tan solo configurando datos en tablas parametricas.
La esencia de esta funcionalidad es poder agilizar los procesos de desarrollo, automatizando la comunicacion entre el consumidor de un servicio (Ej: Frontend) y la base de datos (Ceibo), sin la necesidad de tener que programar por cada nuevo procedure un nuevo servicio que lo invoque.
En resumen, esta funcionalidad permite convertir un Procedimientos Almacenados en Servicios RESTFul que retornen JSON y que pueden ser invocados por cualquier programa.
Restricciones y Limitaciones
El uso de esta funcionalidad tiene unas de restricciones y limitaciones las cuales detallaremos a continuación.
Expand | |||||
---|---|---|---|---|---|
| |||||
ServiciosRequest:
Response:
Procedimientos AlmacenadosLos procedimientos almacenados configurados deben cumplir obligatoriamente con los siguientes criterios: Criterios Generales
Parámetros de Entrada / Salida:Entrada:Solo son soportados los siguientes tipos de datos para los parámetros de entrada:
Salida:Solo son soportados los siguientes tipos de datos para los parámetros de salida:
|
Plataforma de los Servicios Paramétricos
Diagrama
Los servicios paramétricos son consumidos desde un servicio principal que recibe los parámetros de acceso (ruta o path del Servicio) y los datos de entrada (de enviarse) , busca los datos parametrizados para el servicio, y luego ejecuta el SP configurado, retornando la respuesta.
Expand | ||
---|---|---|
| ||
API Ceibo / API Tarjeta Habientes
Todos los servicios habilitados o ha habilitarse serán invocados a través de un servicio principal o raíz que se encuentra en el API. Este servicio se encarga de las validaciones, verificaciones, configuración, ejecución y retorno de la respuesta de la ejecución del procedimiento almacenado que fue configurado
Expand | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
Linkraíz deldel ServicioVersion 1: http://host/ws-tarjetahabiente/prmservices/v1/sprunner/prmGroup/prmVersion/prmServicio Observaciones: Este servicio quedará deprecado por la Version 2 Version 2: http://host/ws-tarjetahabiente/prmservices/v2/sprunner/prmGroup/prmVersion/prmServicio Donde:
Invocación del ServicioRequest:Además de los parámetros en el path del Servicio, el
|
Base de Datos
Todas las configuraciones para los Servicios paramétricos se hacen en la base de datos BAPY CEIBO
Paquete PL/SQL
title | Ver Informacion |
---|
CREDITOPY.PKG_API_CEIBO
Todas los métodos necesarios para que los servicios otorgados por el API Paramétrico funcionen se encuentran en este PKG.
Observaciones IMPORTANTES !!:
La idea de este PKG es ser un package aislado, por lo cual dentro de este package SOLO deben existir los métodos relacionados al funcionamiento de la parametrizacion del SPs como servicios- Códigos PARTICULARES, PROPIOS del Proyecto en si y NO de este PKG
- No agregar procedures, funciones, types, referencias, etc.
- No tocar este PCK salvo si sea para hacer ajustes en el API Paramétrico
Tablas de Configuracion
Expand | |||||||
---|---|---|---|---|---|---|---|
| |||||||
DER:Detalle de Tablas: | |||||||
Tabla: | API_CEIBO_PROCEDURES | ||||||
Descripcion: | Tabla principal de configuraciones de los servicios parametricos. En esta tabla se configuran los procedures que seran invocados, la base de datos donde esta alojado el SP y el path de accesion en el API | ||||||
CAMPOS | |||||||
id_api_sp | Id único de la tabla | ||||||
categoria | Dato informativo sobre la categoria en la que estan divididos los servicios o endpoints. (comercios / autorizaciones / entidades / ceibo / etc. ) | ||||||
descripcion | Descripcion del proposito del servicio / procedure | ||||||
api_path_group | El grupo o bloque en el que esta agrupado el servicio. Ej: {group}/v1/getDatos | ||||||
api_path_version | La version del servicio disponibilizado. Ej: tarjetas/{version}/getDatos | ||||||
api_path_name | El nombre del servicio. Ej: tarjetas/v1/{servicio} | ||||||
procedure_database | La base de datos en las que es ejecutado el Procedure (BAPY / OLPY) | ||||||
procedure_schema | El nombre del esquema en el que se encuentra el procedure. Obs: El usuario que ejecuta el SP es CREDITOPY, asi que debe tener permisos de ejecucion sobre el esquema.pkg.procedure | ||||||
procedure_name | El nombre del procedimiento almacenado a ejecutar. Obs: Configurar aqui el procedure procedure_name o pkg_name.procedure_name, sin el esquema. El API concatenará durante la ejecucion el esquema.sp_name o esquema.pkg_name.sp_name | ||||||
simplificar_response_s_n | S/N. Indicador que permite simplificar el response del API en el caso de que tenga un solo item de respuesta | ||||||
fecha_hora_ins | Fecha / hora de insercion del registro | ||||||
usuario_ins | Usuario de Insercion | ||||||
fecha_hora_upd | Fecha Hora de Actualizacion del registro. | ||||||
usuario_upd | Usuario de Actualizacion del registro. | ||||||
Tabla: | API_CEIBO_PROCEDURES_PRMS_IN | Descripcion: | Tabla hija de la tabla anterior y tiene como funcion registrar el detalle de los parametros de entrada
| |||||||
Esta version del request espera Objeto JSON (en lugar de un array de parametros) en donde cada propiedad del JSON representa el nombre del parametro de entrada definido en las configuraciones. Servicio Ejemplo: http://host/ws-tarjetahabiente/prmservices/v2/sprunner/usuarios/v1/altaUsuario
Donde:
|
Response:
La respuesta del servicio depende de las configuraciones de los parámetros de salida del SP configurado. Pudiendo retornar desde ningún parámetro hasta N parametros.
Code Block | ||||
---|---|---|---|---|
| ||||
{
"header": {
"codReturn": "0",
"txtReturn": ""
},
"data": {
"numeroX": "12312312",
"descripcion": "This is a Test",
"fechaSistema": "15/05/2021 14:54:30",
"registro": {
"NRO": "12312312",
"FECHA1": "01/02/2021",
"FECHA2": "01/02/2021 22:01:33",
"TEXTO_RANDOM": "parangaricutirimicuaro"
}
"departamentos": [
{ "ID": "0", "DESCRIPCION": "DISTRITO CAPITAL" },
{ "ID": "1", "DESCRIPCION": "CONCEPCION" },
{ "ID": "2", "DESCRIPCION": "SAN PEDRO" },
{ "ID": "3", "DESCRIPCION": "CORDILLERA" },
{ "ID": "4", "DESCRIPCION": "GUAIRA" },
{ "ID": "5", "DESCRIPCION": "CAAGUAZU" },
{ "ID": "6", "DESCRIPCION": "CAAZAPA" },
{ "ID": "7", "DESCRIPCION": "ITAPUA" },
{ "ID": "8", "DESCRIPCION": "MISIONES" },
{ "ID": "9", "DESCRIPCION": "PARAGUARI" },
{ "ID": "10", "DESCRIPCION": "ALTO PARANA" },
{ "ID": "11", "DESCRIPCION": "CENTRAL" },
{ "ID": "12", "DESCRIPCION": "ÑEEMBUCU" },
{ "ID": "13", "DESCRIPCION": "AMAMBAY" },
{ "ID": "14", "DESCRIPCION": "CANINDEYU" },
{ "ID": "15", "DESCRIPCION": "PRESIDENTE HAYES" },
{ "ID": "16", "DESCRIPCION": "BOQUERON" },
{ "ID": "17", "DESCRIPCION": "ALTO PARAGUAY" }
],
}
} |
Observaciones
- El API transforma cada uno de los datos retornados a su representación de un String. Excepto para los tipos de datos CURSOR o ESTRUCTURA
- Para las fechas aplica automáticamente el formato dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss, dependiendo de si la fecha tiene o no horas.
- Para el tipo de dato CURSOR:
- El response es mapeado como un array de estructuras.
- En donde cada estructura tiene tantas propiedades como campos o columnas que han sido retornados en el cursor del SP.
- En el ejemplo de mas arriba puede verse a este tipo de dato como la propiedad: "departamentos"
- Para el tipo de dato ESTRUCTURA:
- Este tipo de dato es también un CURSOR, pero manejado de manera diferente por el API
- La diferencia consiste en que en lugar de retornar un array de registros, solo retorna el primer elemento del Array como una estructura.
- En el ejemplo de mas arriba puede verse a este tipo de dato como la propiedad: "registro"
Base de Datos
Todas las configuraciones para los Servicios paramétricos se hacen en la base de datos BAPY CEIBO
Paquete PL/SQL
Expand | ||
---|---|---|
| ||
CREDITOPY.PKG_API_CEIBO Todas los métodos necesarios para que los servicios otorgados por el API Paramétrico funcionen se encuentran en este PKG. Observaciones IMPORTANTES !!:
|
Tablas de Configuracion
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DER:Detalle de Tablas:
|
Configuracion de Servicios
Configurando Nuevos Servicios
Segun lo expuesto mas arriba para agregar nuevos servicios se debe:
- Contar con Procedimiento Almacenado (en BAPY/OLPY, parametros de entrada, luego salida, etc.)
- Configurar el mismo en las tablas de configuraciones
Consumir Servicios Configurados
Segun lo expuesto mas arriba agregar nuevos servicios
|
Ejemplo de Configuración de Servicios
Ejemplo rápido de configuración de un SP como servicio.
Expand | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
Según lo expuesto mas arriba para agregar nuevos servicios se debe:
Supongamos que hemos agregado una nueva configuración, con sus parámetros de entrada y salida
Para consumir el servicio tomamos de base el path raíz que mencionamos mas arriba reemplazando el valor por los valores configurados. Tomando como base http://host/ws-tarjetahabiente/prmservices/v2/sprunner/prmGroup/prmVersion/prmServicio El servicio será: http://host/ws-tarjetahabiente/prmservices/v2/sprunner/datosGenericos/v1/getLocalidades Y ya nada mas queda realizar una prueba vía postman. (En este caso el SP no recibe ningún parámetro de entrada) |