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.

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. 

[
    {
        "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"
    }
]

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.

{
    "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"

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

DER:

Detalle de Tablas:

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

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)