Enregistreur personnalisé

Dans le cas où les outils énumérés ci-dessus pour trouver les erreurs ne sont pas suffisants, vous pouvez toujours créer votre propre logger et y implémenter tous vos besoins. Par exemple, créons un logger qui ajoutera des informations sur l'utilisateur qui a déclenché cet événement et son niveau d'accès en plus de la description générale de l'événement.

Modèle de données du logger

Pour ce faire, commençons par créer un modèle dans la base de données. Nous avons besoin d'un modèle très simple, avec trois champs obligatoires.

• info (text) - informations générales sur l'événement
• user (integer) - ID de l'utilisateur
• access (array string) - groupes d'utilisateurs (il peut y en avoir plusieurs)
  

Processus métier de l'enregistreur

Ensuite, nous allons créer un processus métier pour écrire un journal dans la base de données. Sa tâche consistera à recevoir des informations sur n'importe quel événement, à les compléter par des informations sur l'utilisateur et à enregistrer le résultat final dans la base de données.

Pour obtenir des informations sur l'utilisateur, utilisez le bloc Auth: Get current user pour obtenir des informations sur l'utilisateur. Notez qu'il ne pourra représenter le résultat comme un modèle d'utilisateur que si Middleware Token Auth a été activé sur le point de terminaison qui a initié son exécution.

Nous utilisons Expand User pour développer le résultat et obtenir les champs requis. Dans notre cas, il s'agit de ID, Login, et Groups. L'utilisation des deux premiers est assez banale, il suffit de convertir Login du format mail en un format standard String (To String bloc).

Dans le cas des groupes d'utilisateurs, la situation est un peu plus compliquée. Ils sont stockés au format Enum format. Il s'agit d'un type énuméré qui ne stocke qu'une liste d'identifiants dans la base de données, et non leur valeur textuelle. Dans notre cas, la valeur 1 correspond au groupe des administrateurs (Admins), et la valeur 2 au groupe des utilisateurs (Users).

Notre tâche est de décrypter cet identifiant et d'écrire le résultat sous la forme de données textuelles pratiques. Pour cela, vous avez besoin :

• Déclarez une variable dans laquelle les informations textuelles sur les groupes d'utilisateurs seront écrites. Utilisons les balises String Array et Set Variable .
• Commencez la boucle avec le bloc For each loop pour démarrer la boucle. Il recevra un tableau des groupes de l'utilisateur puis, à chaque itération, convertira le groupe suivant en sa valeur texte et l'ajoutera au tableau.
• À l'aide du bloc Switch vérifie le groupe de l'utilisateur et, en fonction du résultat, dirige la suite du processus.
• À l'aide des boutons String et Set Variable stockez la valeur requise du groupe de l'utilisateur dans une variable.
• Utilisez les blocs Append Array et Set Variable pour ajouter le résultat à un tableau et le stocker dans une variable déclarée avant le début de la boucle.
  

Une fois la boucle terminée, vous devez utiliser le bloc Concat Strings (Multiple) pour former une chaîne finale à partir des données éparses, qui sera convertie en Text et écrite dans le journal.

La dernière chose à faire est de générer le log modèle et de l'écrire dans la base de données.

Le BP résultant devrait ressembler à ceci :

Logger endpoint

Le processus métier est prêt. Maintenant, nous devons créer un point de terminaison pour lui. Pour ce faire, nous allons remplacer le processus métier du système de la POST /log/ avec le processus métier qui vient d'être créé.

Notre propre journal est maintenant prêt à fonctionner. Vous pouvez revenir au tout début du module, au processus d'entreprise Basic functions processus d'affaires, et remplacer le journal standard par celui que vous avez créé vous-même.

Désormais, chaque fois que des calculs sont lancés, un journal spécial enregistrera non seulement des informations sur le fait même de cet événement, mais aussi sur l'utilisateur qui l'a effectué. Nous pouvons vérifier le résultat dans Swagger.

Super, notre journal fonctionne vraiment. Il contient maintenant des informations sur l'événement, le login de l'utilisateur et ses droits d'accès.

Erreurs possibles et actions recommandées

En conséquence, nous structurons les variantes possibles d'erreurs et les actions pour les corriger.

• Erreurs dans le processus métier lui-même. Il est recommandé d'utiliser les journaux pour une vérification étape par étape. Ainsi, vous pouvez vérifier le fait même de lancer un certain bloc de processus métier et tous les paramètres que le bloc utilise, tant en entrée qu'en sortie.
• Erreurs dans l'envoi de la requête au serveur. Pour ce faire, utilisez le site Developer Tools dans le navigateur. Vous pouvez vérifier le fait que la requête a été envoyée, analyser sa structure et voir la réponse reçue.
• Les requêtes sont mal formées. Il est recommandé d'utiliser Swagger pour effectuer des tests approfondis, en vérifiant diverses options de requête et combinaisons de paramètres.
• Le résultat de la requête n'est pas analysé correctement. Il arrive que l'on attende le résultat là où il ne devrait pas l'être. Par exemple, nous ajoutons des données à la base de données mais ne les mettons pas à jour dans le tableau qui affiche ces données. N'oubliez pas que chaque composant nécessite un processus métier correspondant, et assurez-vous que ce processus est configuré correctement.