Introducción

A nivel funcional cabe destacar dos pilares fundamentales entorno a la gestión de la API:

• Un procedimiento almacenado de gestión llamado AhoraAPI.
• Una estructura de tablas en SQL que controlan todo lo que se puede y no se puede hacer con la API.

Con estos datos, y sin necesidad de pensar mucho, ya podemos intuir que el grueso de la parte funcional de la API (por no decir todo) reside en SQL Server. Este concepto, que a simple vista pudiera chocar, está completamente alineado con la intención de potenciar y cuidar lo realmente importante y trascendental en todos nuestros módulos y aplicaciones, es decir: la propia base de datos.

Procedimiento Almacenado

No es objeto de esta documentación destripar el proceso principal (ni los secundarios) que gestiona todas las llamadas de la API, pero sí es necesario conocer de su existencia y entender cómo funciona aunque sea de una forma superficial.

Para poner en antecedentes vamos a esbozar un proceso de llamada a la API en unos poco pasos descriptivos y simplificados:

1. Una aplicación o usuario se loguea en la API con usuario y contraseña del ERP.
2. El sistema le devuelve un Token que debe incluir en cada una de las llamadas para dotar de un marco seguro al proceso de comunicación.
3. Una aplicación o usuario lanza una petición a la API con los parámetros que se requieran en formato JSON, además del Token de autenticación.
4. La API los traduce a XML y lanza el procedimiento de base de datos, pasándole esa traducción como parámetro de entrada.
5. Se procesa y se devuelven los datos de respuesta de la llamada en XML.
6. La API los traduce a JSON y se los devuelve a la aplicación o usuario que ha realizado la llamada.
   
   

Este, a grandes rasgos, sería el proceso normal de utilización de la API, siendo el procedimiento almacenado el corazón de la misma.

Estructura de Tablas

Actualmente la API admite dos modos de funcionamiento:

• Ejecución de procedimientos almacenados
• Consultas sobre vistas o tablas

Para controlar qué puede hacer y qué no puede hacer la API, se ha dotado de una estructura de tablas donde se definen los procesos que se pueden ejecutar (sólo y sólo esos procesos), y las vistas y tablas que pueden leerse, así como qué campos concretos de esas vistas y tablas:

• Existe una tabla (API_EXEC) que contiene los procedimientos almacenados que puede ejecutar la API. De esta forma, agregar una nueva funcionalidad de ejecución es algo tan sencillo como añadir el nombre de un procedimiento (que ya exista en la base de datos) a esta tabla. Desde ese mismo momento el procedimiento podrá ser usado desde la API sin requerir ninguna acción adicional.
• Existe una tabla (API_LIST) que contiene las vistas y tablas que se pueden acceder desde la API. Estas tablas se leen conformando una SELECT (dentro del procedimiento almacenado de gestión) con los campos que se quieren leer y el filtro WHERE de la consulta, ambos parámetros recibidos desde la API. 
• Existe una tabla (API_LIST_COLUMN) con las columnas de la vista o la tabla que vamos a exponer a la API. Es decir, se controla qué información se va a mostrar a nivel de vista y tabla, y a nivel de columnas de la misma, de forma que se podría permitir una consulta sobre una tabla con campos críticos, pero evitando que estos campos se devuelvan en la respuesta.

Además de estas tablas principales, existen un par más de configuración:

• Una tabla que contiene los tipos de llamadas (API_TYPES) que se permiten en la API. Al realizar una llamada concreta se construye el XML asociado a la misma, asignándole uno de estos tipos para que el procedimiento almacenado de gestión (AhoraAPI) sepa cómo tiene que tratar la llamada.
• Una tabla (API_CONFIG) que contiene todos los parámetros de configuración que pudiera requerir la API.

De esta estructura de tablas se deduce lo simple que es dotar de nueva funcionalidad a la API (añadiendo un simple registro a una tabla), y lo robusta que es ante intentos de ejecución y consulta no permitidos.