Spoedcursus 101
10 modules
5 weken

Aangepaste logger

Klik om te kopiëren

Uw eigen logger maken


In het geval dat de bovenstaande hulpmiddelen voor het vinden van fouten niet voldoende zijn, kunt u altijd uw eigen logger maken en daarin al uw behoeften implementeren. Laten we bijvoorbeeld een logger maken die naast de algemene beschrijving van de gebeurtenis ook informatie toevoegt over de gebruiker die deze gebeurtenis heeft veroorzaakt en zijn toegangsniveau.

Logger gegevensmodel

Om dit te doen, beginnen we met het maken van een model in de database. We hebben een heel eenvoudig model nodig, met drie verplichte velden.

  • info (text) - algemene informatie over de gebeurtenis
  • user (integer) - Gebruikers-ID
  • access (array string) - gebruikersgroepen (er kunnen er meerdere zijn)


Logger bedrijfsproces

Daarna maken we een bedrijfsproces aan om een logboek naar de database te schrijven. Zijn taak zal zijn om informatie te ontvangen over een gebeurtenis, deze aan te vullen met informatie over de gebruiker, en het eindresultaat op te slaan in de database.

Om informatie over de gebruiker te krijgen, gebruik je het Auth: Get current user blok. Merk op dat het alleen het resultaat als gebruikersmodel kan weergeven als Middleware Token Auth ingeschakeld was op het eindpunt dat de uitvoering ervan initieerde.


We gebruiken Expand User om het resultaat uit te breiden en de vereiste velden te verkrijgen. In ons geval zijn dat ID, Login, en Groups. Het gebruik van de eerste twee is vrij banaal, u hoeft alleen maar Login te converteren van het mailformaat naar een standaard String (To String blok).

In het geval van gebruikersgroepen is de situatie iets gecompliceerder. Zij worden opgeslagen in Enum formaat. Dit is een opgesomd type dat alleen een lijst van identifiers in de database opslaat, niet hun tekstwaarde. In ons geval komt de waarde 1 overeen met de groep beheerders (Admins), en de waarde 2 met de groep gebruikers (Users).

Onze taak is deze identificatiecode te ontcijferen en het resultaat weg te schrijven in de vorm van handige tekstuele gegevens. Hiervoor is nodig:

  • Declareer een variabele waarin tekstinformatie over gebruikersgroepen zal worden geschreven. We gebruiken de String Array en Set Variable blokken.
  • Begin de lus met het For each loop blok. Het zal een array ontvangen van de groepen van de gebruiker en vervolgens in elke iteratie de volgende groep omzetten in zijn tekstwaarde en toevoegen aan de array.
  • Met behulp van het Switch blok de gebruikersgroep controleren en, afhankelijk van het resultaat, het proces verder sturen.
  • Met behulp van de String en Set Variable blokken de vereiste waarde van de gebruikersgroep in een variabele opslaan.
  • Gebruik de Append Array en Set Variable blokken om het resultaat toe te voegen aan een array en op te slaan in een variabele die voor het begin van de lus is gedeclareerd.


Na afloop van de lus moet u het Concat Strings (Multiple) blok een definitieve string vormen uit verspreide gegevens, die zal worden geconverteerd naar Text en naar het logboek wordt geschreven.


Het laatste wat u moet doen is het genereren van het log model en het naar de database schrijven.


Het resulterende BP moet er zo uitzien:


Logger eindpunt

Het bedrijfsproces is klaar. Nu moeten we er een eindpunt voor maken. Hiervoor vervangen we het systeembedrijfsproces van het POST /log/ eindpunt vervangen door het zojuist aangemaakte bedrijfsproces.


Nu is ons eigen logboek helemaal klaar. U kunt terugkeren naar het begin van de module, naar het Basic functions bedrijfsproces, en het standaard logboek vervangen door het logboek dat u zelf hebt gemaakt.


Nu zal, telkens wanneer berekeningen worden gestart, een speciaal logboek niet alleen informatie vastleggen over het feit zelf van deze gebeurtenis, maar ook over welke gebruiker dit heeft gedaan. We kunnen het resultaat bekijken in Swagger.


Geweldig, ons logboek werkt echt. Nu bevat het informatie over de gebeurtenis, de aanmelding van de gebruiker en zijn toegangsrechten.

Mogelijke fouten en aanbevolen acties

Als resultaat structureren we mogelijke varianten van fouten en acties om ze te corrigeren.

  • Fouten in het bedrijfsproces zelf. Het verdient aanbeveling logboeken te gebruiken voor stapsgewijze verificatie. Zo kunt u het feit zelf van het starten van een bepaald blok van het bedrijfsproces en alle parameters die het blok gebruikt, zowel bij de invoer als bij de uitvoer, controleren.
  • Fouten bij het verzenden van het verzoek naar de server. Gebruik hiervoor de Developer Tools in de browser. U kunt controleren of het verzoek is verzonden, de structuur ervan analyseren en het ontvangen antwoord bekijken.
  • Verzoeken zijn misvormd. Het wordt aanbevolen Swagger te gebruiken voor grondige tests, waarbij verschillende query-opties en parametercombinaties worden gecontroleerd.
  • Het resultaat van het verzoek wordt niet correct geparseerd. Het gebeurt dat we wachten op het resultaat waar het niet zou moeten zijn. We voegen bijvoorbeeld gegevens toe aan de database, maar werken ze niet bij in de tabel die deze gegevens weergeeft. Vergeet niet dat elk onderdeel een overeenkomstig bedrijfsproces vereist, en zorg ervoor dat dit proces correct is geconfigureerd.
Was this article helpful?
Nog op zoek naar een antwoord?
Word lid van de community