- Created by Sistemas, last modified on Jul 16, 2024
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 3 Next »
Resumen
El usuario se conecta por ssh, mediante un cliente de ssh (Putty), al servidor de producción donde están los scripts y programas cobol. Mediante el logueo, por una configuración del servidor, se ejecuta el archivo "LoginOper.sh" lo que muestra al usuario 17 opciones en pantalla.
Opciones desplegadas al usuario
El uso de esta funcionalidad tiene unas de restricciones y limitaciones las cuales detallaremos a continuación.
Imporante
- El API no evalúa, ni evaluará los valores de los parámetros de salida retornados por SP.
- Su única función es ejecutar el SP y devolver el resultado, según lo configurado para sus parámetros de salida.
- Si el SP se ejecuto sin excepciones (fallos, errores, etc.) la ejecución fue exitosa.
- Si se desean hacer controles adicionales sobre lo retornado por el SP, esta tarea queda a responsabilidad del invocador del Servicio.
Servicios
Request:
- Los servicios que son disponibilizados a través de las parametrizaciones SOLO pueden recibir JSON como parámetro de entrada.
- Los únicos tipos de datos aceptados son NUMERO/TEXTO/FECHA. El tipo de dato FECHA debe enviarse como un texto en formato dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss.
- Mas adelante se detallarán ejemplos de como invocar a los servicios.
Response:
- La respuesta del servicio siempre será un JSON.
- Para los diferentes tipos de datos que puedan ser retornados desde el SP, el api SIEMPRE devolverá una representación de un STRING del dato.
- El Servicio siempre devolverá una representación de un STRING de cada dato retornado desde el SP.
Procedimientos Almacenados
Los procedimientos almacenados configurados deben cumplir obligatoriamente con los siguientes criterios:
Criterios Generales
- Los procedimientos almacenados deben existir en @BAPY o en @OLPY. El API no se conecta a ninguna otra Base de Datos.
- Los procedimientos deben poder ser vistos e invocados por el usuario: CREDITOPY.
- Los procedimientos configurados deben estar programados de tal manera que PRIMERO se definan los parámetros de ENTRADA , luego los de SALIDA.
Parámetros de Entrada / Salida:
Entrada:
Solo son soportados los siguientes tipos de datos para los parámetros de entrada:
- Número (Number, Double, Decimal, etc. )
- Texto (Varchar, CHAR, CLOB )
- Fecha (Date)
- Obs: Cualquier otro tipo de dato será tratado por el API como un String.
Salida:
Solo son soportados los siguientes tipos de datos para los parámetros de salida:
- Número
- Texto
- Fecha
- Cursor
- Obs: Cualquier otro tipo de dato será tratado por el API como un String. Con los eventuales errores que esto pueda conllevar.
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.
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
Link del Servicio
Version 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:
- prmGroup: Valor del Parámetro "Grupo" configurado para el Servicio.
- prmVersion: Valor del Parámetro "Versión" configurado para el Servicio.
- prmServicio: Valor del Parámetro del "Nombre" configurado para el Servicio.
Invocación del Servicio
Request:
- Input Type: POST
- Output Type: Content-Type:application/json
Esta version del request espera recibir un array de parámetros de entrada. Estos parametros que son utilizados para realizar la invocación del SP configurado para el servicio. La cantidad de parámetros de entrada así como también los tipos de datos y los nombres de los parámetros, variarán de acuerdo a cada SP configurado. Pudiendo incluso enviarse un array vacío o sin datos.
Servicio Ejemplo:
http://host/ws-tarjetahabiente/prmservices/v1/sprunner/usuarios/v1/altaUsuario
[ { "prmNombre": "prmNroAlta", "prmValor": 123123123, "prmTipo": "NUMERO" }, { "prmNombre": "prmNombreApellido", "prmValor": "Orlando Ojeda", "prmTipo": "TEXTO" }, { "prmNombre": "prmFechaNac", "prmValor": "18/03/1990", "prmTipo": "TEXTO" }, { "prmNombre": "prmFechaHoraRegistro", "prmValor": "18/03/2021 18:30:59", "prmTipo": "FECHA" } ]
Donde:
- prmNombre: Es el nombre del parámetro que fue configurado. Esta propiedad es utilizada para asignar el valor del prm en su lugar especifico como parámetro de entrada del SP.
- prmValor: El valor en sí del parámetro enviado.
- prmTipo: El tipo de dato del parámetro enviado. Solo puede ser uno de tres posibles:
- NUMERO
- TEXTO
- FECHA
- El tipo de Dato FECHA puede y debe enviarse como un texto en uno de los siguientes formatos: dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss.
- Si el valor enviado no puede ser convertido al tipo de dato especificado, las validaciones el servicio retornaran un error
- Si el tipo de dato especificado no es uno de los valores permitidos, las validaciones el servicio retornaran un error
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
{ "prmNroAlta": 123123123, "prmNombreApellido": "Orlando Ojeda", "prmFechaNac": "18/03/1990", "prmFechaHoraRegistro": "18/03/2021 18:30:59" }
Donde:
- Las claves o nombres de las propiedades dentro del JSON representan a los nombres de los parametros de entrada configurados
- El valor de cada propiedad corresponde al VALOR en sí del parámetro enviado.
- El tipo de dato enviado solo puede ser uno de tres posibles:
- NUMERO
- TEXTO
- FECHA
- El tipo de dato FECHA puede y debe enviarse como un texto en uno de los siguientes formatos: dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss.
- Si el valor enviado no puede ser convertido al tipo de dato especificado, las validaciones el servicio retornaran un error
- Si el tipo de dato especificado no es uno de los valores permitidos, las validaciones el servicio retornaran un error
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.
{ "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
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
- En resumen, NO INCLUIR AQUI:
- 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
- Códigos PARTICULARES, PROPIOS del Proyecto en si y NO de este PKG
Tablas de Configuracion
DER:
Detalle de Tablas:
Tabla: | CREDITOPY.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: | CREDITOPY.API_CEIBO_PROCEDURES_PRMS_IN |
---|---|
Descripcion: | Tabla hija de la tabla anterior y tiene como funcion registrar el detalle de los parametros de entrada con los que cuenta el procedure configurado |
CAMPOS | |
id_api_sp | Id del SP del API. FK a la tabla: API_CEIBO_PROCEDURES |
param_name | Nro de Orden en el que se encuentra el parametro de entrada |
param_name | Nombre del parametro recibido desde el API |
tipo_dato | Especifica el tipo de dato permitido. Valores permitidos:
Obs: Fecha en formato: dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss |
requerido_api_s | S/N. Indicador si el dato debe ser enviado o no desde el request del servicio |
nulable_s_n | S/N. Indicador que especifica si el valor puede ser enviado como nulo |
default_value | El valor por defecto del parametro. Los datos deben ponerse en lenguaje SQL. Ejemplos:
|
Tabla: | CREDITOPY.API_CEIBO_PROCEDURES_PRMS_OUT |
---|---|
Descripcion: | Tabla que registra el detalle de los parametros de salida con los que cuenta el procedure configurado |
CAMPOS | |
id_api_sp | Id del SP del API. FK a la tabla: API_CEIBO_PROCEDURES |
param_name | Nro de Orden en el que se encuentra el parametro de salida |
param_name | Nombre del parametro de salida con el que se retornara el dato en el API |
tipo_dato | Mapeo del tipo de dato que es retornado por el SP. Este dato se utiliza para la creacion del statement de ejecucion del SP contra la base de datos. Especifica el tipo de dato permitido. Valores permitidos:
Obs: El tipo de dato "ESTRUCTURA" es un tipo de dato personalizado que representa el primer registro retornado por un Cursor. El API toma este tipo de dato y lo devuelve como un objeto JSON en lugar de como un Array JSON. |
retornar_api_s_n | S/N. Indicador que especifica si el valor de este parametro de salida debe ser o no retornado dentro del response del API |
Tabla: | CREDITOPY.API_CEIBO_USERS |
---|---|
Descripcion: | En esta tabla se registran los usuarios de aplicacion/login que es utilizado por el API para autenticarse y luego ejecutar los procedimientos almacenados |
CAMPOS | |
id_usuario | Id único de la tabla |
usuario | Sigla del Usuario |
password | contraseña |
fecha_alta | fecha de alta |
Ejemplo de Configuración de Servicios
Ejemplo rápido de configuración de un SP como servicio.
Según lo expuesto mas arriba para agregar nuevos servicios se debe:
- Contar con un Procedimiento Almacenado (en BAPY/OLPY, parámetros de entrada, luego salida, etc.)
- Configurar el mismo en las tablas de configuraciones
- Grupo Servicio en el Path
- Versión del Servicio en el Path
- Nombre Servicio en el Path
- Base de Datos
- Esquema
- Nombre del SP
- Parámetros de Entrada.
- Parámetros de Salida.
Supongamos que hemos agregado una nueva configuración, con sus parámetros de entrada y salida
id_api_sp | 9999 |
---|---|
categoria | Datos Genéricos |
descripcion | Obtener la Lista de Departamentos y Ciudades |
api_path_group | datosGenericos |
api_path_version | v1 |
api_path_name | getLocalidades |
procedure_database | BAPY |
procedure_schema | creditopy |
procedure_name | pkg_dimo_ceibo.sp_ciudades |
simplificar_response_s_n | S |
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)
- No labels