Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 104 Next »

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.

 Ver informació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.


 Ver diagrama

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


 Ver Información

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

Además de los parámetros en el path del Servicio, el request espera recibir un array de parámetros de entrada, 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. 


 Formato Request v1

Servicio Ejemplo:

http://host/ws-tarjetahabiente/prmservices/v1/sprunner/usuarios/v1/altaUsuario

Request Body JSON
[
    {
        "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:
    1. NUMERO
    2. TEXTO
    3. 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
 Formato Request v2

Servicio Ejemplo:

http://host/ws-tarjetahabiente/prmservices/v1/sprunner/usuarios/v1/altaUsuario

Request Body JSON
{
   "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:
    1. NUMERO
    2. TEXTO
    3. 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.

Response JSON
{
    "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:
    1. El response es mapeado como un array de estructuras.
    2. En donde cada estructura tiene tantas propiedades como campos o columnas que han sido retornados en el cursor del SP.
    3. En el ejemplo de mas arriba puede verse a este tipo de dato como la propiedad: "departamentos"
  • Para el tipo de dato ESTRUCTURA:
    1. Este tipo de dato es también un CURSOR, pero manejado de manera diferente por el API
    2. La diferencia consiste en que en lugar de retornar un array de registros, solo retorna el primer elemento del Array como una estructura.
    3. 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
 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

  • 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
Tablas de Configuracion
 Ver Info de Tablas

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_spId único de la tabla
categoriaDato informativo sobre la categoria en la que estan divididos los servicios o endpoints. (comercios / autorizaciones / entidades / ceibo / etc. )
descripcionDescripcion del proposito del servicio / procedure
api_path_groupEl 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_nS/N. Indicador que permite simplificar el response del API en el caso de que tenga un solo item de respuesta
fecha_hora_insFecha / hora de insercion del registro
usuario_insUsuario de Insercion
fecha_hora_updFecha Hora de Actualizacion del registro.
usuario_updUsuario 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_spId del SP del API. FK a la tabla: API_CEIBO_PROCEDURES
param_nameNro de Orden en el que se encuentra el parametro de entrada
param_nameNombre del parametro recibido desde el API
tipo_dato

Especifica el tipo de dato permitido. Valores permitidos:

  • NUMERO
  • TEXTO
  • FECHA

Obs: Fecha en formato: dd/mm/yyyy o dd/mm/yyyy hh24:mi:ss

requerido_api_sS/N. Indicador si el dato debe ser enviado o no desde el request del servicio
nulable_s_nS/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:

  • 123456
  • 'S'
  • TO_CHAR(12323)
  • to_date('01/01/2021', 'dd/mm/yyyy')
  • sysdate
  • f_get_dato...



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_spId del SP del API. FK a la tabla: API_CEIBO_PROCEDURES
param_nameNro de Orden en el que se encuentra el parametro de salida
param_nameNombre 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:

  • NUMERO
  • TEXTO
  • FECHA
  • CURSOR
  • ESTRUCTURA

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_nS/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_usuarioId único de la tabla
usuarioSigla del Usuario
passwordcontraseña
fecha_altafecha de alta







Ejemplo de Configuración de Servicios

Ejemplo rápido de configuración de un SP como servicio.

 Ver Ejemplo

Según lo expuesto mas arriba para agregar nuevos servicios se debe:

  1. Contar con un Procedimiento Almacenado (en BAPY/OLPY, parámetros de entrada, luego salida, etc.)
  2. Configurar el mismo en las tablas de configuraciones
    1. Grupo Servicio en el Path
    2. Versión del Servicio en el Path
    3. Nombre Servicio en el Path
    4. Base de Datos
    5. Esquema
    6. Nombre del SP
    7. Parámetros de Entrada.
    8. Parámetros de Salida.

Supongamos que hemos agregado una nueva configuración, con sus parámetros de entrada y salida

id_api_sp9999
categoriaDatos Genéricos
descripcionObtener la Lista de Departamentos y Ciudades
api_path_groupdatosGenericos
api_path_version

v1

api_path_name

getLocalidades

procedure_database

BAPY

procedure_schema

creditopy

procedure_name

pkg_dimo_ceibo.sp_ciudades

simplificar_response_s_nS


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/v1/sprunner/prmGroup/prmVersion/prmServicio

El servicio será:

http://host/ws-tarjetahabiente/prmservices/v1/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