Geplante Benachrichtigungen verstehen und testen

Wie geplante Benachrichtigungen funktionieren

Wenn Sie eine Benachrichtigung konfigurieren, müssen Sie den Zeitplan konfigurieren, d. h. wann die Benachrichtigung gesendet wird. Sie können immer die Option Ein Ereignis auswählen. Je nach Art des Auslöserereignisses können Sie auch Vor und/oder Nach auswählen. Die meisten Benachrichtigungen zu On-Events werden im Benachrichtigungssystem verarbeitet, sobald das Event auftritt, und werden beim nächsten Cron-Lauf von der geplanten Aufgabe totara_notification\\task\\process_event_queue_task gesendet. Nutzer sollten diese innerhalb von etwa einer Minute nach dem Eintreten des Ereignisses erhalten, vorausgesetzt, dass Cron jede Minute ausgeführt wird und die Aufgabe nach dem Standardzeitplan (jede Minute) ausgeführt wird. Einige Ereignisbenachrichtigungen und alle Vorher -Nachher -Benachrichtigungen werden auf andere Weise verarbeitet.

Geplante Benachrichtigungen werden von der geplanten Aufgabe \\totara_notification\\task\\process_scheduled_event_task verarbeitet. Diese Aufgabe berechnet den Zeitraum seit der letzten Ausführung, wendet die Versätze der geplanten Benachrichtigungen an und fordert jede Benachrichtigung auf, alle Ereignisse zu berechnen, die während dieser Versatzperioden aufgetreten sind.

Das letzte Datum/die letzte Uhrzeit, zu der die geplanten Benachrichtigungen verarbeitet wurden, wird in der totara_notification Variable last_scheduled_event_task_run_timeconfig_plugins/ aufgezeichnet. Sie wird nicht basierend auf der letzten Ausführungszeit der geplanten Aufgabe berechnet, die Sie bei der Konfiguration der geplanten Aufgaben sehen, obwohl es wahrscheinlich ist, dass sie ähnlich ist, solange die Aufgabe und die Einstellung normal funktionieren. Beachten Sie, dass eine manuelle Änderung dieser Zeit in der Datenbank dazu führen würde, dass entweder doppelte Benachrichtigungen gesendet werden (wenn sie rückwärts verschoben wurde) oder dass Benachrichtigungen nie gesendet werden (wenn sie weiter verschoben werden), sodass dies auf einer Produktionsseite nicht geändert werden sollte.

Nehmen wir zum Beispiel eine Benachrichtigung, die drei Tage vor einem Ereignis gesendet werden soll, z. B. ein Fälligkeitsdatum. Die geplante Aufgabe ist so konfiguriert, dass sie standardmäßig einmal täglich um 23 Uhr ausgeführt wird. Wenn sie um 23:00 Uhr ausgeführt wird, wird für die angegebene Benachrichtigung der Zeitraum 'letzter Cron-Lauf + 3 Tage' bis 'jetzt + 3 Tage' berechnet. Der Benachrichtigungs-Resolver (der Teil des Codes, der definiert, wie eine einzelne Benachrichtigung funktioniert, welche Daten betroffen sind usw.) wird aufgefordert, alle Ereignisse zu finden, die in diesem Zeitraum auftreten. Damit eine Benachrichtigung gesendet werden kann, muss das Eventdatum innerhalb dieses Zeitraums liegen.

Wenn die Aufgabe häufiger ausgeführt wird, ist der Zeitraum, in dem sie gesucht wird, kleiner, aber über einen ganzen Tag wird sie die Ereignisse eines ganzen Tages verarbeiten und es wird nie zweimal dasselbe Ereignis verarbeiten. Wenn es beispielsweise so eingestellt ist, dass es jede Stunde ausgeführt wird, dann finden Sie jede Stunde alle Benachrichtigungen, die innerhalb des vorherigen Zeitraums von einer Stunde gesendet werden sollen. Es ist also möglich, den Aufgabenplan zu ändern, aber es geht darum, die Suche nach Benachrichtigungen zu wiederholen, die häufiger gesendet werden. Abhängig von der Website kann dies eine Menge Verarbeitung erfordern, daher wird die Standardeinstellung nur einmal täglich ausgeführt.

Nehmen wir im selben Szenario wie oben an, wenn es so eingestellt ist, dass es jede Minute läuft, dann würde es um 15:45 Uhr nach allen Ereignissen suchen (und Benachrichtigungen senden), die zwischen 15:44 und 15:45 Uhr in drei Tagen stattfinden. Um zu beobachten, dass die Benachrichtigung abgeht, müsste das Fälligkeitsdatum genau innerhalb dieser Minute an diesem Tag liegen. Wenn Sie die geplante Aufgabe manuell ausführen, müssen Sie beim Testen beachten, dass nur Benachrichtigungen gesendet werden, die für den Zeitraum seit der letzten Ausführung der Aufgabe geplant sind. Bei der Einrichtung des Ereignisses, das eine Benachrichtigung auslösen sollte, hat der Nutzer oft keine Kontrolle über die genaue Minute des Ereignisses. Daher ist es unwahrscheinlich, dass das Ereignis genau innerhalb des berechneten Zeitraums gesendet wird. Dies ist häufig die Ursache für Verwirrung, wenn versucht wird, geplante Benachrichtigungen auf einem Testserver zu erzwingen.

In Totara 16 und darunter werden alle Ereignisse, die im angegebenen Zeitraum auftreten, zur Benachrichtigungswarteschlange hinzugefügt, wenn die Aufgabe ausgeführt wird. Wenn \\ totara_notification\\task\\process_notification_queue_task als nächstes ausgeführt wird, was standardmäßig jeder Cron-Lauf ist, werden die Benachrichtigungen in der Warteschlange aufgenommen und sofort gesendet. In Totara 17 und höher werden bei der Ausführung der Aufgabe alle Ereignisse, die in dem angegebenen Zeitraum auftreten, berücksichtigt und sofort verarbeitet, wobei die Benachrichtigungen sofort gesendet werden. Die Zwischenwarteschlange, die in Totara 16 und darunter aufgetreten ist, wurde übersprungen.

Geplante Benachrichtigungen testen

Das Testen geplanter Benachrichtigungen kann schwierig sein, hauptsächlich aufgrund der Art und Weise, wie die geplante Aufgabe den Zeitraum der Benachrichtigungsereignisse auswählt, nach dem gesucht werden soll.

In den folgenden Anweisungen müssen Sie bei der Änderung von Daten manchmal Unix-Zeitstempel verwenden. Verwenden Sie Epoch Converter, um zwischen Unix-Zeitstempeln und menschenlesbaren Daten zu wechseln. Jedes Mal, wenn ein 'Datum' oder 'Zeit' erwähnt wird, bedeutet dies 'Datum und Zeit' – wir arbeiten immer mit einem vollständigen Datum und einer vollen Zeit. Wenn Sie die Stunden, Minuten und Sekunden aus einer Berechnung ignorieren, funktioniert dies nicht wie erwartet. „Aktuelles Datum“ bedeutet „jetzt mit Stunden, Minuten und Sekunden“.

Wir haben hier das Programmfälligkeitsdatum als Beispiel verwendet, aber der beschriebene Prozess kann zum Testen der meisten geplanten Benachrichtigungen verwendet werden. Passen Sie einfach die Schritte an, wo es angebracht ist.

So testen Sie das Senden einer geplanten Benachrichtigung:

1. Richten Sie Ihre Benachrichtigung mit einem Vor- Zeitplan ein, z. B. '3 Tage vorher'. Beachten Sie, dass das zuverlässigste Mittel zum Empfang von Benachrichtigungen für Tests darin besteht, Benachrichtigungen an den Zustellungskanal der Website zu senden, sodass die Benachrichtigung im Benachrichtigungs-Popup des Nutzers auf der Website angezeigt werden sollte. Sie sollten auch sicherstellen, dass die Benachrichtigung einen Text im Betreff enthält, der die Testbenachrichtigung eindeutig identifiziert, z. B. „Testbenachrichtigung für das Programmfälligkeitsdatum, das 3 Tage vorher ausgelöst wurde“.
2. Richten Sie die Ereignisdaten ein, die zu einer Benachrichtigung führen sollen. In diesem Fall würden wir einen Nutzer im Programm mit einem Zuweisungsfälligkeitsdatum einrichten, das auf drei Tage nach dem heutigen Tag eingestellt ist.
3. Finden Sie die genaue Zeit des Events. Abhängig von der Funktion, die Sie verwenden, kann es einen Ort geben, an dem Sie genau sehen können, was diesmal ist. Für Programme können Sie den Programmabschluss-Editor verwenden, um das genaue Fälligkeitsdatum des Nutzers zu finden. Andernfalls müssen Sie möglicherweise dieses Datum in der Datenbank nachschlagen.
4. Wenden Sie den Benachrichtigungsversatz auf das Datum an, wenn Sie das Eventdatum angeben. Wenn Ihr Zeitplan Vor ist , dann ziehen Sie den Versatz ab. Zum Beispiel bedeutet 3 Tage vorher, dass Sie 3 * 24 * 60 * 60 Sekunden subtrahieren. Wenn es On Event ist, ändern Sie es nicht. Wenn es After ist , fügen Sie es hinzu. Wir nennen dieses berechnete Datum das 'Benachrichtigungssendedatum'.
5. Überprüfen Sie den Wert totara_notification/last_scheduled_event_task_run_time in der config_plugins Tabelle in der Datenbank. Ändern Sie diesen Wert nicht auf einer Live-Website! Wir nennen dieses Datum die „letzte Laufzeit“.
6. Vergleichen Sie die letzte Laufzeit mit dem von Ihnen berechneten Benachrichtigungssendedatum:
   1. Wenn das Sendedatum der Benachrichtigung vor der letzten Laufzeit liegt, wird die Benachrichtigung nicht gesendet, da das Ereignisdatum zu früh ist.
   2. Wenn das Sendedatum der Benachrichtigung länger als das aktuelle Datum ist (derzeit), müssen Sie warten, bis das Sendedatum erreicht ist.
   3. Wenn das Sendedatum der Benachrichtigung länger als die letzte Laufzeit und vor dem aktuellen Datum ist, kann es gesendet werden. Überspringen Sie den nächsten Schritt.
7. Wenn das Sendedatum der Benachrichtigung nicht zwischen der letzten Laufzeit und dem aktuellen Datum liegt, wird die Benachrichtigung erst gesendet, wenn sich diese Situation ändert. Hier gibt es einige mögliche Optionen:
   1. Wenn das Sendedatum in der Zukunft liegt, können Sie einfach warten, bis diese Zeit erreicht ist.
   2. Wenn das Sendedatum in der Zukunft liegt, können Sie das Datum des Events ändern. In unserem Beispiel können Sie das Fälligkeitsdatum des Programms mit dem Programmabschluss-Editor auf ein früheres Datum setzen oder das Ereignisdatum in der Datenbank ändern.
   3. Wenn das Sendedatum in der Zukunft liegt, können Sie den Benachrichtigungszeitplan anpassen. In unserem Beispiel könnten Sie es auf '2 Tage vorher' reduzieren.
   4. Wenn das Sendedatum vor der letzten Laufzeit liegt, können Sie das Datum des Ereignisses ändern. In unserem Beispiel können Sie das Fälligkeitsdatum des Programms mit dem Programmabschlusseditor auf später setzen oder das Ereignisdatum in der Datenbank ändern.
   5. Wenn das Sendedatum vor der letzten Laufzeit liegt, können Sie den Benachrichtigungszeitplan anpassen. In unserem Beispiel könnten Sie es auf '4 Tage vorher' erhöhen.
   6. Wenn das Sendedatum vor der letzten Laufzeit liegt, können Sie den totara_notification/last_scheduled_event_task_run_time-Wert in der config_plugins Tabelle in der Datenbank so anpassen, dass er vor dem Sendedatum der Benachrichtigung liegt.
      
      Tun Sie dies nicht auf einer Produktionsstätte.
8. Warten Sie entweder auf die \\totara_notification\\task\\process_scheduled_event_task geplante Aufgabe oder führen Sie sie aus. Standardmäßig wird dies einmal täglich ausgeführt, kann aber jederzeit sicher ausgeführt werden, solange es bei Ausführung auf einer Produktionsseite keine Serverüberlastung verursacht. Es wird nicht empfohlen, den Zeitplan der Aufgabe so zu ändern, dass er jede Minute ausgeführt wird, da es mehr als eine Minute dauern kann, um alle Datensätze zu verarbeiten, aber es sollte in Ordnung sein, sie einmal zum Testen auszuführen.
9. Wenn Sie auf Totara 16 oder niedriger sind, müssen Sie auch auf die geplante Aufgabe totara_notification\\task\\process_notification_queue_task warten oder diese ausführen. Wie bei der vorherigen Aufgabe sollten Sie den Zeitplan nicht so ändern, dass er jede Minute für die allgemeine Verwendung ausgeführt wird.
10. Die Benachrichtigung hätte gesendet werden sollen. Überprüfen Sie entweder ausgehende Protokolle oder melden Sie sich als Empfänger an, um zu überprüfen, ob die Benachrichtigung gesendet und empfangen wurde.

Wenn Sie immer noch Probleme haben, stellen Sie sicher, dass Sie erfolgreich eine andere Nicht-Ein-Ereignisbenachrichtigung auslösen und erhalten können.