Förstå och testa schemalagda meddelanden

Hur schemalagda notifieringar fungerar

När du konfigurerar ett meddelande måste du konfigurera schemat, vilket innebär när meddelandet kommer att skickas. Du kommer alltid att kunna välja alternativet På händelse , och beroende på vilken typ av utlösarhändelse du kanske också kan välja Före och/eller Efter . De flesta notifieringar om På-händelse behandlas i notifieringssystemet så snart händelsen inträffar och kommer faktiskt att skickas ut vid nästa cronkörning av den schemalagda uppgiften \totara_notification\task\process_event_queue_task. Användare bör ta emot dessa inom en minut eller så efter att händelsen inträffat, förutsatt att cron körs varje minut och uppgiften körs på standardschemat (varje minut). Vissa notifieringar om händelse, och alla notifieringar före och efter schemalagda behandlas på ett annat sätt.

Schemalagda meddelanden behandlas av den schemalagda uppgiften \totara_notification\task\process_scheduled_event_task. Denna uppgift beräknar perioden sedan senaste gången den kördes, tillämpar offset för schemalagda notifieringar och ber varje notifiering att beräkna alla händelser som inträffade under dessa offsetperioder.

Senaste datum/tid då de schemalagda meddelandena behandlades registreras i config_plugins variabeln totara_notification/last_scheduled_event_task_run_time. Det beräknas inte baserat på den schemalagda aktivitetens senaste körtid som du ser när du konfigurerar schemalagda aktiviteter, även om det är troligt att den är liknande, så länge uppgiften och inställningen är kvar för att fungera normalt. Observera att manuell ändring av denna tid i databasen skulle resultera i att antingen duplicerade meddelanden skickas (om de flyttades bakåt) eller att meddelanden aldrig skickas (om de går framåt), så detta bör inte ändras på en produktionsplats.

Låt oss till exempel ta ett meddelande som är planerat att skickas tre dagar innan en händelse inträffar, till exempel ett förfallodatum. Den schemalagda uppgiften är konfigurerad att köras en gång om dagen som standard, kl. 23.00. När den körs kl. 23.00, för det angivna meddelandet, kommer perioden den beräknar att vara ”senaste cron-körning + 3 dagar” till ”nu + 3 dagar”. Meddelandelösaren (kodbiten som definierar hur ett enskilt meddelande fungerar, vilka data som är involverade, etc.) kommer att bli ombedd att hitta alla händelser som inträffar under denna period. För att ett meddelande ska skickas måste datum för evenemanget ligga inom denna period.

Om uppgiften körs oftare, så kommer perioden den söker att vara mindre, men under en hel dag kommer den att bearbeta en hel dags värde av händelser, och det kommer aldrig att bearbeta samma händelse två gånger. Till exempel, om det var inställt på att köra varje timme, så skulle varje timme det hitta alla notifieringar som är planerade att skickas inom den föregående entimmarsperioden. Således är det möjligt att ändra aktivitetsschemat, men det kommer på bekostnad av att behöva upprepa sökningen efter meddelanden som ska skickas oftare. Beroende på webbplatsen kan detta kräva en hel del bearbetning, vilket innebär att standardinställningen är inställd på att endast köras en gång per dag.

I samma scenario som ovan, säg om det var inställt att köra varje minut, då klockan 15:45 skulle det söka efter (och skicka notifieringar för) alla händelser som inträffar mellan 15:44 och 15:45 på tre dagar. För att observera att meddelandet går ut, måste förfallodatumet vara exakt inom den minuten den dagen. När du testar, om du kör den schemalagda uppgiften manuellt, måste du vara medveten om att endast meddelanden som är schemalagda att skickas exakt under perioden sedan uppgiften senast kördes kommer att skickas. När du ställer in händelsen som ska utlösa ett meddelande, har användaren ofta inte kontroll över den exakta minuten för händelsen, så det är osannolikt att händelsen ska skickas exakt inom den beräknade perioden. Detta är ofta orsaken till förvirring när man försöker tvinga schemalagda meddelanden att skickas på en testserver.

I Totara 16 och nedan, när uppgiften körs, krävs alla händelser som inträffar under den angivna perioden och lägger till dem i meddelandekön. När \totara_notification\task\process_notification_queue_task nästa körning, som som standard är varje cron-körning, så kommer den att plocka upp köade notifieringar och skicka dem omedelbart. I Totara 17 och senare, när uppgiften körs, krävs alla händelser som inträffar under den angivna perioden och behandlar dem omedelbart, och skickar meddelandena omedelbart. Den mellanliggande kö som inträffade i Totara 16 och nedan har hoppats över.

Testar schemalagda notifieringar

Testning av schemalagda notifieringar kan vara svårt, främst på grund av det sätt som den schemalagda uppgiften väljer perioden för notifieringshändelser att söka efter.

I följande instruktioner, när du manipulerar datum, behöver du ibland använda Unix tidsstämplar. Använd Epoch Converter för att konvertera mellan Unix tidsstämplar och läsbara datum. Varje gång ett datum eller en tid nämns betyder detta datum och tid – vi arbetar alltid med ett helt datum och en hel tid, och om du ignorerar timmar, minuter och sekunder från någon beräkning så kommer saker inte att fungera som förväntat. ”Aktuellt datum” betyder ”nu, med timmar, minuter och sekunder”.

Vi har använt programmets förfallodatum som ett exempel här, men processen som beskrivs kan användas för att testa de flesta schemalagda meddelanden. Anpassa bara stegen där så är lämpligt.

Gör så här för att testa att skicka ett schemalagt meddelande:

1. Ställ in ditt meddelande med ett schema för Före, till exempel ”3 dagar före”. Observera att det mest tillförlitliga sättet att ta emot meddelanden för testning är att skicka till leveranskanalen för webbplatsmeddelanden, så att meddelandet ska visas i användarens popup-fönster för meddelanden på webbplatsen. Du bör också se till att meddelandet har viss text i patienten som tydligt identifierar testmeddelandet, t.ex. ”Testmeddelande för programförfallodatum utlöst 3 dagar före”.
2. Konfigurera händelsedata som ska resultera i att ett meddelande skickas. I detta fall skulle vi ställa in en användare i programmet med ett förfallodatum för tilldelning satt till tre dagar efter idag.
3. Hitta den exakta tiden för evenemanget. Beroende på vilken funktion du använder kan det finnas en plats där du kan se exakt vad den här gången är. För program kan du använda redigeraren för programslutförande för att hitta användarens exakta förfallodatum. Annars kan du behöva leta upp detta datum i databasen.
4. Med tanke på händelsedatum, tillämpa meddelandeförskjutningen på datumet. Om ditt schema är Före så subtraherar du offsetet. Till exempel betyder 3 dagar före att du subtraherar 3 * 24 * 60 * 60 sekunder. Om det är På händelse, ändra det inte. Om det är efter så lägg till det. Vi kommer att kalla detta beräknade datum för ”aviseringssändningsdatum”.
5. Kontrollera värdet totara_notification/last_scheduled_event_task_run_time i config_plugins tabellen i databasen. Ändra inte detta värde på en live-webbplats! Vi kommer att kalla detta datum för ”senaste körtid”.
6. Jämför den senaste körtiden med det datum för meddelandesändning som du beräknade:
   1. Om datumet för aviseringssändning är mindre än den senaste körtiden kommer aviseringen inte att skickas eftersom datumet för aviseringen är för tidigt.
   2. Om datumet för aviseringssändning är mer än det aktuella datumet (till höger just nu) måste du vänta tills avsändningsdatumet har uppnåtts.
   3. Om datumet för aviseringssändning är mer än den senaste körtiden och före det aktuella datumet är det klart att skickas. Hoppa över nästa steg.
7. Om datumet för meddelandesändning inte ligger mellan den senaste körtiden och det aktuella datumet kommer meddelandet inte att skickas förrän denna situation ändras. Det finns några möjliga alternativ här:
   1. Om sändningsdatumet är i framtiden kan du helt enkelt vänta tills den tiden har nåtts.
   2. Om sändningsdatumet är i framtiden kan du ändra datum för händelsen. I vårt exempel kan du ställa in programmets förfallodatum så att det är ett tidigare datum med hjälp av redigeraren för programslutförande, eller så kanske du kan ändra datum för händelsen i databasen.
   3. Om sändningsdatumet är i framtiden kan du justera meddelandeschemat. I vårt exempel kan du minska det till ”2 dagar före”.
   4. Om sändningsdatumet ligger före den senaste körtiden kan du ändra datum för händelsen. I vårt exempel kan du ställa in programmets förfallodatum så att det senare kan användas med hjälp av redigeraren för programslutförande, eller så kan du ändra datum för händelsen i databasen.
   5. Om sändningsdatumet ligger före den senaste körtiden kan du justera meddelandeschemat. I vårt exempel kan du öka det till ”4 dagar före”.
   6. Om sändningsdatumet ligger före den senaste körtiden kan du justera värdet totara_notificationlast_scheduled_event_task_run_time i config_plugins tabellen i databasen så att det ligger före datumet för meddelandesändningen.
      
      Gör inte detta på en produktionsanläggning.
8. Antingen vänta på eller kör den schemalagda uppgiften \totara_notification\task\process_scheduled_event_task. Som standard körs detta en gång om dagen, men det kan köras säkert när som helst, så länge det inte orsakar serveröverbelastning om det körs på en produktionsplats. Det är inte tillrådligt att ändra aktivitetsschemat så att det körs varje minut, eftersom det kan ta mer än en minut att bearbeta alla poster, men det bör gå bra att köra det enstaka för testning.
9. Om du är på Totara 16 eller lägre så måste du också vänta på eller köra den schemalagda uppgiften \totara_notification\task\process_notification_queue_task. Som med föregående uppgift, bör du inte ändra schemat så att det körs varje minut för allmän användning.
10. Meddelandet borde ha skickats. Kontrollera antingen utgående loggar eller logga in som mottagare för att kontrollera att meddelandet skickades och mottogs.

Om du fortfarande har problem, se till att du framgångsrikt kan utlösa och ta emot ett annat icke-På-händelsemeddelande.