Ingeplande notificaties begrijpen en testen

Hoe geplande notificaties werken

Bij het configureren van een notificatie moet je de planning configureren, wat betekent wanneer de notificatie wordt verzonden. Je kunt altijd de optie Bij gebeurtenis selecteren, en afhankelijk van het type triggergebeurtenis kun je misschien ook Voor en/of Na selecteren. De notificaties voor de meeste uitvoeringen worden verwerkt in het notificatiesysteem zodra de uitvoering plaatsvindt en worden verzonden bij de volgende cron die wordt uitgevoerd door de geplande taak \\totara_notification\\taak\\process_event_queue_task. Gebruikers moeten deze ontvangen binnen een minuut of zo nadat de gebeurtenis heeft plaatsgevonden, ervan uitgaande dat cron elke minuut wordt uitgevoerd en de taak volgens het standaardschema wordt uitgevoerd (elke minuut). Sommige Aan-gebeurtenis notificaties en alle Voor en Na geplande notificaties worden op een andere manier verwerkt.

Geplande notificaties worden verwerkt door de geplande taaktotara_notification.process_scheduled_event_task Deze taak berekent de periode sinds de laatste keer dat het werd uitgevoerd, past de offsets van de geplande notificaties toe en vraagt elke notificatie om alle gebeurtenissen te berekenen die zich tijdens deze offsetperiodes hebben voorgedaan.

De laatste datum/tijd waarop de geplande notificaties zijn verwerkt, wordt vastgelegd in de totara_notification/last_scheduled_event_task_run_timeconfig_plugins-variabele. Het wordt niet berekend op basis van de geplande taak laatste runtime die je ziet bij het configureren van geplande taken, hoewel het waarschijnlijk is dat het gelijk is, zolang de taak en instelling normaal blijven werken. Let op dat het handmatig wijzigen van deze tijd in de databank zou resulteren in ofwel dubbele notificaties (als het naar achteren is verplaatst), of notificaties die nooit worden verzonden (als je verder gaat), dus dit mag niet worden gewijzigd op een productiesite.

Laten we bijvoorbeeld een notificatie maken die gepland is om drie dagen voor een gebeurtenis te worden verzonden, zoals een uiterste datum. De geplande taak is geconfigureerd om standaard één keer per dag te worden uitgevoerd, om 23.00 uur. Wanneer het om 23.00 uur wordt uitgevoerd, is de periode die het berekent 'laatste cron-run + 3 dagen' tot 'nu + 3 dagen'. De notificatie-oplosser (het stuk code dat bepaalt hoe een individuele notificatie werkt, welke gegevens er zijn, enz.) wordt gevraagd om alle gebeurtenissen te vinden die tijdens deze periode plaatsvinden. Om een notificatie te kunnen verzenden, moet de uitvoeringsdatum binnen deze periode liggen.

Als de taak vaker wordt uitgevoerd, dan zal de periode die het zoekt kleiner zijn, maar gedurende een hele dag zal het een hele dag aan gebeurtenissen verwerken en het zal deze gebeurtenis nooit twee keer verwerken. Als het bijvoorbeeld is ingesteld om elk uur te lopen, dan zal het elk uur alle notificaties vinden die gepland zijn om binnen de vorige periode van een uur te worden verzonden. Het is dus mogelijk om het taakschema te wijzigen, maar het gaat ten koste van het herhalen van de zoekopdracht voor notificaties die vaker worden verzonden. Afhankelijk van de site kan dit veel verwerken, vandaar dat de standaardinstelling is ingesteld om slechts één keer per dag te werken.

In hetzelfde scenario als hierboven, bijvoorbeeld als het was ingesteld om elke minuut te laten lopen, dan zou het om 15:45 uur alle gebeurtenissen die plaatsvinden tussen 15:44 en 15:45 uur binnen drie dagen zoeken (en notificaties sturen). Om te zien hoe de notificatie eruit gaat, moet de uiterste datum precies binnen die minuut op die dag zijn. Als je de geplande taak manueel uitvoert, moet je er rekening mee houden dat alleen meldingen die gepland zijn om precies te worden verzonden in de periode sinds de laatste uitvoering, worden verzonden. Bij het instellen van de gebeurtenis die een notificatie zou moeten activeren, heeft de gebruiker vaak geen controle over de exacte minuut van de gebeurtenis, dus het is onwaarschijnlijk dat de gebeurtenis precies binnen de berekende periode wordt verzonden. Dit is vaak de oorzaak van verwarring bij het afdwingen van geplande notificaties die op een testserver worden verzonden.

In Totara 16 en lager worden alle gebeurtenissen die in de gegeven periode plaatsvinden, meegenomen in de wachtrij. Wanneer de volgende uitvoering van de \\totara_notification\\taak\\process_notification_queue_task, die standaard elke cron-run is, dan zal deze de in de wachtrij geplaatste notificaties opnemen en ze onmiddellijk verzenden. In Totara 17 en hoger worden alle gebeurtenissen die zich in de gegeven periode voordoen, verwerkt en onmiddellijk verwerkt, waarbij de notificaties onmiddellijk worden verzonden. De tussenliggende wachtrij die zich voordeed in Totara 16 en lager is overgeslagen.

Testen van geplande notificaties

Het testen van geplande notificaties kan moeilijk zijn, vooral door de manier waarop de geplande taak de periode van notificaties kiest waarnaar moet worden gezocht.

In de volgende instructies moet je bij het manipuleren van datums soms Unix-tijdstempels gebruiken. Gebruik de Epoch Converter om te converteren tussen Unix-tijdstempels en voor mensen leesbare data. Telkens wanneer een 'datum' of 'tijd' wordt genoemd, betekent dit 'datum en tijd' - we werken altijd met een volledige datum en tijd, en als je de uren, minuten en seconden van een berekening negeert, dan zal alles niet werken zoals verwacht. 'Huidige datum' betekent 'nu, met uren, minuten en seconden'.

We hebben de uiterste datum van het programma hier als voorbeeld gebruikt, maar het beschreven proces kan worden gebruikt voor het testen van de meeste geplande notificaties. Pas de stappen aan waar nodig.

Volg deze stappen om het versturen van een geplande notificatie te testen:

1. Stel je notificatie in met een Voor- schema, bijvoorbeeld '3 dagen van tevoren'. Let op dat de meest betrouwbare manier om notificaties voor testen te ontvangen is om te verzenden naar het e-mailkanaal van de site, zodat de notificaties verschijnen in de notificaties popup van de gebruiker op de site. Je moet er ook voor zorgen dat de notificatie wat tekst in het onderwerp bevat die de testnotificatie duidelijk identificeert, bijv. 'Testnotificatie voor programma uiterste datum geactiveerd 3 dagen van tevoren'.
2. Stel de gebeurtenisgegevens in die zouden moeten resulteren in het verzenden van een notificatie. In dit geval zouden we een gebruiker in het programma instellen met een uiterste datum voor toewijzing ingesteld op drie dagen na vandaag.
3. Zoek het exacte tijdstip van de uitvoering. Afhankelijk van de functie die je gebruikt, kan er een plaats zijn waar je precies kunt zien wat deze tijd is. Voor programma's kun je de programma voltooiingseditor gebruiken om de exacte uiterste datum van de gebruiker te vinden. Anders moet je deze datum misschien opzoeken in de databank.
4. Pas de notificatieverschuiving toe op de datum, gegeven de gebeurtenisdatum. Als je planning voor is , dan trek je de offset af. Bijvoorbeeld: 3 dagen voor de start betekent dat je 3 * 24 * 60 * 60 seconden aftrekt. Als het Aan is, wijzig het dan niet. Als het na is, voeg het dan toe. We zullen deze berekende datum de 'datum voor het verzenden van een notificatie' noemen.
5. Controleer de totara_notification/last_scheduled_event_task_run_time waarde in de config_plugins tabel in de databank. Wijzig deze waarde niet op een live site! We zullen deze datum de 'laatste runtime' noemen.
6. Vergelijk de laatste runtime met de verzenddatum van de notificatie die je hebt berekend:
   1. Als de verzenddatum van de notificatie minder is dan de laatste runtime, wordt de notificatie niet verzonden, omdat de uitvoeringsdatum te vroeg is.
   2. Als de verzenddatum van de notificatie meer is dan de huidige datum (op dit moment), dan moet je wachten tot de verzenddatum is bereikt.
   3. Als de verzenddatum van de notificatie meer is dan de laatste runtime en vóór de huidige datum, is deze klaar om te worden verzonden. Sla de volgende stap over.
7. Als de verzenddatum van de notificatie niet tussen de laatste runtime en de huidige datum ligt, wordt de notificatie niet verzonden totdat deze situatie is gewijzigd. Er zijn hier enkele mogelijke opties:
   1. Als de verzenddatum in de toekomst ligt, kun je gewoon wachten tot die tijd is bereikt.
   2. Als de verzenddatum in de toekomst ligt, kun je de datum van de gebeurtenis wijzigen. In ons voorbeeld kun je de uiterste datum van het programma instellen op een eerdere datum met behulp van de editor voor het voltooien van het programma, of je kunt de datum van de uitvoering misschien wijzigen in de databank.
   3. Als de verzenddatum in de toekomst ligt, kun je het notificatieschema aanpassen. In ons voorbeeld kun je het terugbrengen naar '2 dagen voor'.
   4. Als de verzenddatum voor de laatste runtime is, kun je de datum van de gebeurtenis wijzigen. In ons voorbeeld kun je de uiterste datum van het programma instellen om later te zijn met de editor voor programmavoltooiingen, of je kunt de datum van de uitvoering misschien wijzigen in de databank.
   5. Als de verzenddatum voor de laatste runtime is, kun je het notificatieschema aanpassen. In ons voorbeeld kun je het verhogen naar '4 dagen voor'.
   6. Als de verzenddatum voor de laatste runtime is, kun je de totara_notification/last_scheduled_event_task_run_time-waarde in de config_plugins tabel in de databank aanpassen, zodat deze voor de verzenddatum van de notificatie is.
      
      Doe dit niet op een productiesite.
8. Wacht op of voer de geplande taak \\totara_notification\\taak\\process_scheduled_event_task uit. Standaard wordt dit één keer per dag uitgevoerd, maar het kan veilig op elk moment worden uitgevoerd, zolang het geen serveroverbelasting veroorzaakt als het op een productiesite wordt uitgevoerd. Het wordt afgeraden om het schema van de taak te wijzigen om elke minuut te laten lopen, omdat het meer dan één minuut kan duren om alle records te verwerken, maar het zou goed moeten zijn om het eenmalig te laten lopen voor testen.
9. Als je op Totara 16 of lager bent, moet je ook wachten op de geplande taak totara_notificationof dezeprocess_notification_queue_task taak uitvoeren. Zoals met de vorige taak, moet je het schema niet wijzigen om elke minuut te laten lopen voor algemeen gebruik.
10. De notificatie zou verzonden moeten zijn. Controleer uitgaande logs of log in als ontvanger om te controleren of de notificatie is verzonden en ontvangen.

Als je nog steeds problemen hebt, zorg er dan voor dat je met succes een andere niet-bij uitvoering notificatie kunt activeren en ontvangen.