En la versión 4.4.2400.48 se implementaron una serie de cambios estructurales tanto a nivel de base de datos, como en AHORA TPV y AHORA API. 


Gracias a estas modificaciones el rendimiento de AHORA TPV se ha visto mejorado en aspectos tan trascendentales como la velocidad, la gestión de errores y la compatibilidad con caracteres reservados al trabajar con XML. 


A modo de resumen, los cambios aplicados son los siguientes:

  • Base de datos
    • Optimización de procesos claves de AHORA TPV, mejorando en tiempos la inserción de línea y el cobro
    • Optimización de procesos estándar tales como la obtención del precio del artículo, decrementando el tiempo necesario para obtener la información de las líneas a introducir en el ticket
    • Inclusión de índices para mejorar la gestión de los datos
  • Ahora API
    • Optimización de la ejecución de procedimientos almacenados
    • Nueva gestión de versiones para garantizar compatibilidad con AHORA TPV
    • Nueva gestión de errores que posibilita, entre otros, identificar y definir casos de uso concretos como errores bloqueantes o pérdidas de sesión
  • Ahora TPV
    • Optimización de la carga del entorno
    • Nueva gestión de versiones para garantizar compatibilidad con AHORA API
    • Nueva gestión de errores avanzada
    • Transiciones aceleradas. Los buscadores y menús abren más rápido permitiendo una usabilidad más fluida y dinámica


AHORA API y AHORA TPV


Las modificaciones incluida en AHORA API permiten ejecutar los procedimientos almacenados que se definen en la tabla API_EXEC sin hacer uso de SQL Dinámico. 


Al evitarse la construcción de las consultas de los procedimientos a partir de cadenas de textos dinámicas, se mejora el rendimiento de las mismas y se permite a SQL Server gestionar y planificar de una forma más óptima los recursos que requiere para su ejecución.


Este cambio es totalmente transparente al usuario, manteniéndose la misma devolución de datos en la ejecución de los procedimientos almacenados, tanto si devuelven datos correctos como si devuelven errores. Cualquier personalización sobre AHORA TPV, o posibles integraciones externas de la API por aplicaciones de terceros, deberían seguir funcionando sin errores. 

IMPORTANTE


Puesto que en fábrica no podemos conocer con absoluta seguridad qué tipo de integraciones se han podido llevar a cabo con AHORA API, o si las mismas han seguido las recomendaciones de buenas prácticas de fábrica, es importante que antes de actualizar a la versión 4.4.2400.48 o superior, se validen en un entorno de preproducción para evitar situaciones no contempladas por el desarrollo estándar.

Otro factor a tener en cuenta en esta versión, incluido tanto en AHORA API como en AHORA TPV, es una nueva gestión de versiones dependientes de ambas aplicaciones. Puesto que las mejoras incluidas en AHORA API facilitan el desarrollo de AHORA TPV, es necesario que ambas aplicaciones sean compatibles para trabajar sin problemas. 


A partir de la versión 4.4.2400.48, AHORA TPV validará que la API sobre la que trabaja es correcta con respecto a su propia versión, dando un error en caso contrario. 




Para poder acceder a la TPV será necesario desinstalar la API obsoleta e instalar la nueva API compatible, utilizando las opciones de Desinstalar módulos existentes y Añadir nuevos módulos de AHORA Install, incluido en el Asistente de Instalación. 





Gestión de Errores


Un aspecto relevante de la optimización es la nueva gestión de errores incluida en AHORA TPV y AHORA API. 

Hasta la fecha, los procedimientos almacenados ejecutados por la API siempre devolvían una llamada HTTP con estado OK (código 200) dejando a las aplicaciones externas la obligación de leer el XML de respuesta para conocer el estado real de la misma (error, ok, warning).


Aunque esta forma de trabajar sigue manteniéndose por retrocompatibilidad con posibles desarrollos externos, todos los nuevos desarrollos en AHORA TPV tendrán una gestión avanzada más próxima a la gestión llevada a cabo por AHORA ERP. 


En lugar de la devolución de parámetros de salida de tipo XML con un nodo de estado en el que se establece si se ha dado un error, la API devolverá un mensaje HTTP de tipo error (código 400 o similar), permitiendo la gestión real de los mismos por parte tanto de AHORA TPV como de cualquier conector externo que consuma AHORA API.


Cualquier desarrollador que desee provechar esta nueva funcionalidad tendrá que modificar sus procedimientos almacenados siguiendo las siguientes directrices:

  • Ya no es necesaria la primera línea de los procedimientos utilizada para reemplazar los caracteres reservados de XML. Se puede eliminar para permitir el uso de los caracteres de apertura y cierre de nodos XML (< y >) que, hasta la fecha, daban error al ser usados.

  • Los errores controlados se devuelven con la instrucción RAISERROR en lugar de utilizar un oXML de salida con el nodo estado Error.


Formato oXML:

Formato RAISERROR:

  • La gestión del CATCH en los procedimientos también cambia, permitiendo no sólo la devolución limpia de los errores, sino también la propagación eficiente de los errores generados en las llamadas internas a otros procedimientos. Además de no devolver el parámetro de salida, también se cambiarán los Return -1 (estado para definir una ejecución correcta) por Return 0 (para definir un mensaje con error), al igual que ya están haciendo el resto de procedimientos almacenados de la base de datos.

Formato oXML:

Formato RAISERROR:


Con estos sencillos cambios (que se irán incluyendo de forma escalonada en los desarrollos ya existentes en AHORA TPV), se facilita la gestión de errores permitiendo un mayor control de los mismos a todos los niveles, tanto de base de datos como de las aplicaciones que los consumen.


NOTA:

Se incluye, de forma estándar, la opción de utilizar el último dígito (State) de las instrucciones RAISERROR('texto error', Severity, State), para definir si el error mostrado es normal o bloqueante. 


La diferencia en AHORA TPV será mostrar la tarjeta del error (no bloqueante, State = 1) siendo el usuario el que debe pinchar sobre la misma para abrirla y leer el error completo, o presentar el error en primer plano (bloqueante, State = 2) en pantalla obligando al usuario a leerlo y cerrarlo.