Registrador personalizado

En el caso de que las herramientas listadas arriba para encontrar errores no sean suficientes, siempre puedes hacer tu propio logger e implementar todas tus necesidades en él. Por ejemplo, vamos a crear un logger que añada información sobre el usuario que ha provocado este evento y su nivel de acceso, además de la descripción general del evento.

Modelo de datos del logger

Para ello, vamos a empezar por crear un modelo en la base de datos. Necesitamos un modelo muy sencillo, con tres campos obligatorios.

• info (text) - información general sobre el evento
• user (integer) - ID de usuario
• access (array string) - grupos de usuarios (puede haber varios)
  

Proceso de negocio del registrador

Después, crearemos un proceso de negocio para escribir un registro en la base de datos. Su tarea será recibir información sobre cualquier evento, complementarla con información sobre el usuario, y guardar el resultado final en la base de datos.

Para obtener información sobre el usuario, utilice el bloque Auth: Get current user bloque. Tenga en cuenta que sólo podrá representar el resultado como un modelo de usuario si Middleware Token Auth estaba habilitado en el endpoint que inició su ejecución.

Usamos Expand User para ampliar el resultado y obtener los campos necesarios. En nuestro caso, estos son ID, Login, y Groups. El uso de los dos primeros es bastante banal, sólo hay que convertir Login del formato de correo a un String estándar (To String bloque).

En el caso de los grupos de usuarios, la situación es algo más complicada. Se almacenan en Enum formato. Se trata de un tipo enumerado que sólo almacena una lista de identificadores en la base de datos, no su valor de texto. En nuestro caso, el valor 1 corresponde al grupo de administradores (Admins), y el valor 2 al grupo de usuarios (Users).

Nuestra tarea es descifrar este identificador y escribir el resultado en forma de datos textuales convenientes. Para ello, es necesario:

• Declare una variable en la que se escribirá la información de texto sobre los grupos de usuarios. Utilicemos las etiquetas String Array y Set Variable para ello.
• Inicie el bucle con el bloque For each loop bloque. Recibirá un array de los grupos del usuario y, luego, en cada iteración, convertirá el siguiente grupo en su valor de texto y lo añadirá al array.
• Usando el bloque Switch comprueba el grupo del usuario y, en función del resultado, dirige el proceso más allá.
• Utilizando los botones String y Set Variable almacene el valor requerido del grupo del usuario en una variable.
• Utilice los bloques Append Array y Set Variable para añadir el resultado a un array y almacenarlo en una variable declarada antes del inicio del bucle.
  

Una vez finalizado el bucle, se debe utilizar el bloque Concat Strings (Multiple) para formar una cadena final a partir de los datos dispersos, que se convertirá en Text y escrita en el registro.

Lo último que hay que hacer es generar el log modelo y escribirlo en la base de datos.

El BP resultante debe tener el siguiente aspecto:

Logger endpoint

El proceso de negocio está listo. Ahora necesitamos crear un endpoint para él. Para ello, sustituiremos el proceso de negocio del sistema del POST /log/ con el proceso de negocio que acabamos de crear.

Ahora nuestro propio registro está completamente listo para funcionar. Podemos volver al principio del módulo, al Basic functions proceso de negocio, y sustituir el registro estándar por el que usted mismo ha creado.

Ahora, cada vez que se inicien los cálculos, un registro especial registrará no sólo información sobre el hecho mismo de este evento, sino también sobre qué usuario lo hizo. Podemos comprobar el resultado en Swagger.

Genial, nuestro log funciona de verdad. Ahora contiene información sobre el evento, la entrada del usuario y sus derechos de acceso.

Posibles errores y acciones recomendadas

Como resultado, estructuramos posibles variantes de errores y acciones para corregirlos.

• Errores en el propio proceso de negocio. Se recomienda utilizar los registros para la verificación paso a paso. Así, se puede comprobar el hecho mismo de lanzar un determinado bloque del proceso de negocio y todos los parámetros que utiliza el bloque, tanto en la entrada como en la salida.
• Errores en el envío de la petición al servidor. Para ello, utilice la página Developer Tools del navegador. Puede comprobar que la petición se ha enviado, analizar su estructura y ver la respuesta recibida.
• Las peticiones están mal formadas. Se recomienda utilizar Swagger para realizar pruebas exhaustivas, comprobando varias opciones de consulta y combinaciones de parámetros.
• El resultado de la petición no se analiza correctamente. Ocurre que estamos esperando el resultado donde no debería estar. Por ejemplo, añadimos datos a la base de datos pero no los actualizamos en la tabla que muestra estos datos. Recuerde que cada componente requiere un proceso de negocio correspondiente, y asegúrese de que este proceso está configurado correctamente.