Benutzerdefinierter Logger

Wenn die oben aufgeführten Tools zur Fehlersuche nicht ausreichen, können Sie jederzeit einen eigenen Logger erstellen und alle Ihre Anforderungen darin implementieren. Lassen Sie uns zum Beispiel einen Logger erstellen, der neben der allgemeinen Beschreibung des Ereignisses auch Informationen über den Benutzer, der dieses Ereignis ausgelöst hat, und seine Zugriffsebene enthält.

Logger-Datenmodell

Zu diesem Zweck erstellen wir zunächst ein Modell in der Datenbank. Wir brauchen ein sehr einfaches Modell mit drei erforderlichen Feldern.

• info (text) - Allgemeine Informationen über das Ereignis
• user (integer) - Benutzer-ID
• access (array string) - Benutzergruppen (es kann mehrere geben)
  

Logger-Geschäftsprozess

Danach erstellen wir einen Geschäftsprozess, der ein Protokoll in die Datenbank schreibt. Seine Aufgabe wird es sein, Informationen über ein beliebiges Ereignis zu erhalten, sie mit Informationen über den Benutzer zu ergänzen und das Endergebnis in der Datenbank zu speichern.

Um Informationen über den Benutzer zu erhalten, verwenden Sie den Auth: Get current user Block. Beachten Sie, dass er das Ergebnis nur dann als Benutzermodell darstellen kann, wenn Middleware Token Auth auf dem Endpunkt, der seine Ausführung initiiert hat, aktiviert wurde.

Wir verwenden Expand User um das Ergebnis zu erweitern und die erforderlichen Felder zu erhalten. In unserem Fall sind dies ID, Login und Groups. Die Verwendung der ersten beiden ist ziemlich banal, Sie müssen nur Login vom Mail-Format in einen Standard String (To String Block).

Im Fall der Benutzergruppen ist die Situation etwas komplizierter. Sie werden im Enum Format gespeichert. Dabei handelt es sich um einen Aufzählungstyp, der nur eine Liste von Bezeichnern in der Datenbank speichert, nicht aber deren Textwert. In unserem Fall entspricht der Wert 1 der Gruppe der Administratoren (Admins), und der Wert 2 der Gruppe der Benutzer (Users).

Unsere Aufgabe ist es, diese Kennung zu entschlüsseln und das Ergebnis in Form von geeigneten Textdaten zu schreiben. Dazu benötigen Sie:

• Deklarieren Sie eine Variable, in die Textinformationen über Benutzergruppen geschrieben werden sollen. Verwenden wir die String Array und Set Variable Blöcke.
• Beginnen Sie die Schleife mit dem For each loop Block. Er erhält ein Array mit den Gruppen des Benutzers und konvertiert dann in jeder Iteration die nächste Gruppe in ihren Textwert und fügt sie dem Array hinzu.
• Verwenden Sie den Switch Block wird die Benutzergruppe überprüft und je nach Ergebnis wird der Prozess weitergeführt.
• Mit Hilfe der String und Set Variable Blöcke speichern Sie den gewünschten Wert der Benutzergruppe in einer Variablen.
• Verwenden Sie die Append Array und Set Variable Blöcke fügen Sie das Ergebnis zu einem Array hinzu und speichern es in einer Variablen, die vor dem Start der Schleife deklariert wurde.
  

Nach Beendigung der Schleife sollten Sie den Concat Strings (Multiple) Block verwenden, um aus den verstreuten Daten eine endgültige Zeichenkette zu bilden, die dann in Text konvertiert und in das Protokoll geschrieben wird.

Als letztes müssen Sie das log Modell zu generieren und es in die Datenbank zu schreiben.

Der resultierende BP sollte wie folgt aussehen:

Logger-Endpunkt

Der Geschäftsprozess ist fertig. Jetzt müssen wir noch einen Endpunkt für ihn erstellen. Zu diesem Zweck ersetzen wir den Systemgeschäftsprozess des POST /log/ Endpunkts durch den soeben erstellten Geschäftsprozess.

Jetzt ist unser eigenes Protokoll komplett fertig. Sie können zum Anfang des Moduls zurückkehren, zu dem Basic functions Geschäftsprozess zurückkehren und das Standardprotokoll durch das von Ihnen erstellte Protokoll ersetzen.

Jetzt werden bei jedem Start von Berechnungen in einem speziellen Protokoll nicht nur Informationen über die Tatsache dieses Ereignisses aufgezeichnet, sondern auch darüber, welcher Benutzer es durchgeführt hat. Wir können das Ergebnis in Swagger.

Großartig, unser Protokoll funktioniert wirklich. Jetzt enthält es Informationen über das Ereignis, die Anmeldung des Benutzers und seine Zugriffsrechte.

Mögliche Fehler und empfohlene Aktionen

Als Ergebnis strukturieren wir mögliche Fehlervarianten und Maßnahmen zu deren Behebung.

• Fehler im Geschäftsprozess selbst. Es wird empfohlen, Protokolle zur schrittweisen Überprüfung zu verwenden. So können Sie den Start eines bestimmten Geschäftsprozessblocks und alle Parameter, die der Block verwendet, sowohl am Eingang als auch am Ausgang überprüfen.
• Fehler beim Senden der Anfrage an den Server. Verwenden Sie dazu die Seite Developer Tools im Browser. Sie können überprüfen, ob die Anfrage gesendet wurde, ihre Struktur analysieren und die erhaltene Antwort einsehen.
• Anfragen sind fehlerhaft geformt. Es wird empfohlen, Swagger für gründliche Tests zu verwenden und verschiedene Abfrageoptionen und Parameterkombinationen zu prüfen.
• Das Ergebnis der Anfrage wird nicht korrekt geparst. Es kommt vor, dass wir auf das Ergebnis warten, wo es nicht sein sollte. Zum Beispiel fügen wir der Datenbank Daten hinzu, aktualisieren sie aber nicht in der Tabelle, die diese Daten anzeigt. Denken Sie daran, dass jede Komponente einen entsprechenden Geschäftsprozess erfordert, und stellen Sie sicher, dass dieser Prozess richtig konfiguriert ist.