Logger personalizzato

Nel caso in cui gli strumenti sopra elencati per la ricerca degli errori non siano sufficienti, è sempre possibile creare un logger personale e implementare in esso tutte le proprie esigenze. Ad esempio, creiamo un logger che aggiunga informazioni sull'utente che ha attivato l'evento e sul suo livello di accesso, oltre alla descrizione generale dell'evento.

Modello di dati del logger

Per farlo, iniziamo a creare un modello nel database. Abbiamo bisogno di un modello molto semplice, con tre campi obbligatori.

• info (text) - informazioni generali sull'evento
• user (integer) - ID utente
• access (array string) - gruppi di utenti (possono essercene diversi)
  

Processo aziendale del logger

Successivamente, creeremo un processo aziendale per scrivere un log nel database. Il suo compito sarà quello di ricevere informazioni su qualsiasi evento, completarle con informazioni sull'utente e salvare il risultato finale nel database.

Per ottenere informazioni sull'utente, utilizzare il blocco Auth: Get current user . Si noti che sarà in grado di rappresentare il risultato come modello utente solo se Middleware Token Auth è stato abilitato sull'endpoint che ha avviato la sua esecuzione.

Si usa Expand User per espandere il risultato e ottenere i campi richiesti. Nel nostro caso, questi sono ID, Login e Groups. L'uso dei primi due è abbastanza banale, basta convertire Login dal formato mail a uno standard String (To String blocco).

Nel caso dei gruppi di utenti, la situazione è un po' più complicata. Essi sono memorizzati nel formato Enum formato. Si tratta di un tipo enumerato che memorizza nel database solo un elenco di identificatori, non il loro valore testuale. Nel nostro caso, il valore 1 corrisponde al gruppo degli amministratori (Admins) e il valore 2 al gruppo degli utenti (Users).

Il nostro compito è decriptare questo identificatore e scrivere il risultato sotto forma di dati testuali. Per questo, è necessario:

• Dichiarare una variabile in cui verranno scritte le informazioni di testo sui gruppi di utenti. Utilizziamo gli elementi String Array e Set Variable e.
• Avviare il ciclo con il blocco For each loop . Riceverà un array di gruppi dell'utente e, a ogni iterazione, convertirà il gruppo successivo nel suo valore di testo e lo aggiungerà all'array.
• Utilizzando il blocco Switch controlla il gruppo dell'utente e, in base al risultato, dirige ulteriormente il processo.
• Utilizzando i comandi String e Set Variable memorizzare il valore richiesto del gruppo dell'utente in una variabile.
• Utilizzare i blocchi Append Array e Set Variable per aggiungere il risultato a un array e memorizzarlo in una variabile dichiarata prima dell'inizio del ciclo.
  

Al termine del ciclo, è necessario utilizzare il blocco Concat Strings (Multiple) per formare una stringa finale dai dati sparsi, che sarà convertita in Text e scritta nel log.

L'ultima cosa da fare è generare il log modello e scriverlo nel database.

Il BP risultante dovrebbe avere questo aspetto:

Punto finale del log

Il processo aziendale è pronto. Ora dobbiamo creare un endpoint per esso. Per farlo, sostituiremo il processo aziendale di sistema dell'endpoint con il processo aziendale appena creato. POST /log/ endpoint con il processo aziendale appena creato.

Ora il nostro registro è completamente pronto. Si può tornare all'inizio del modulo, al processo di business Basic functions processo di business e sostituire il registro standard con quello creato da voi.

Ora, ogni volta che vengono avviati dei calcoli, un registro speciale registrerà non solo le informazioni sul fatto stesso di questo evento, ma anche su quale utente lo ha eseguito. Possiamo controllare il risultato in Swagger.

Bene, il nostro log funziona davvero. Ora contiene informazioni sull'evento, sul login dell'utente e sui suoi diritti di accesso.

Possibili errori e azioni consigliate

Di conseguenza, abbiamo strutturato possibili varianti di errori e azioni per correggerli.

• Errori nel processo aziendale stesso. Si consiglia di utilizzare i log per la verifica passo-passo. In questo modo, è possibile verificare il fatto stesso di lanciare un determinato blocco del processo aziendale e tutti i parametri che il blocco utilizza, sia in ingresso che in uscita.
• Errori nell'invio della richiesta al server. A tale scopo, utilizzare il sito Developer Tools nel browser. È possibile verificare che la richiesta sia stata inviata, analizzarne la struttura e vedere la risposta ricevuta.
• Le richieste sono malformate. Si consiglia di utilizzare Swagger per effettuare test approfonditi, verificando varie opzioni di query e combinazioni di parametri.
• Il risultato della richiesta non viene analizzato correttamente. Succede che si attende il risultato dove non dovrebbe essere. Ad esempio, aggiungiamo dati al database ma non li aggiorniamo nella tabella che li visualizza. Ricordate che ogni componente richiede un processo aziendale corrispondente e assicuratevi che questo processo sia configurato correttamente.