Vad är centraliserade meddelanden?

Utveckling av centraliserade notifieringar

I Totara 14 introducerade vi ett nytt system för att generera notifieringar. Vi ändrade hur utvecklare skriver meddelandefunktioner i funktioner och hur användare konfigurerar och interagerar med meddelanden. I vår dokumentation hänvisar vi till denna funktion som ”centraliserade notifieringar”. Historiskt sett var utvecklare tvungna att fatta många beslut om hur notifieringar skulle fungera, vilket resulterade i en inkonsekvent upplevelse för användare när det gällde att konfigurera och interagera med notifieringar. Det centraliserade notifieringssystemet ger utvecklare ett konsekvent sätt att implementera notifieringar och användare att använda dem.

Den första utgåvan av centraliserade notifieringar inkluderade migrering av program och certifieringsnotifieringar till det nya systemet. I efterföljande utgåvor har fler funktioners notifieringar lagts till i centraliserade notifieringar, medan andra fortfarande hanteras utanför det centraliserade notifieringssystemet och nu benämns ”legacynotifieringar”. När Totara avancerar kommer vi att fortsätta att migrera befintliga meddelanden och lägga till nya meddelanden till det centraliserade meddelandesystemet. Till exempel Totara 16 såg introduktionen av kursanmälningar, som hanteras via centraliserade notifieringar.

Centraliserade meddelanden förklarade

”Centraliserade notifieringar” är den term som används för det nya notifieringssystemet. Utvecklare lägger till funktionalitet till funktioner, så att användare kan konfigurera meddelanden som ska skickas i samband med händelser som inträffar. Det finns två olika typer av händelser som du kan konfigurera notifieringar för:

• Händelser kan vara åtgärder som en användare utför, till exempel när en användare slutför en kurs
• Händelser kan representeras av datum som registrerats i databasen, såsom ett förfallodatum för programmet

Utvecklare måste implementera en aviseringsutlösare för varje typ av händelse som måste resultera i en avisering. Till exempel kan en utvecklare implementera en meddelandeutlösare baserat på kursens förfallodatum. Användare kan sedan konfigurera valfritt antal notifieringar för varje notifieringsutlösare. Till exempel kan en kursadministratör skapa en avisering om ”På grund av sju dagar” samt en avisering om ”två dagar försenad”, båda baserat på samma aviseringsutlösare.

När en händelse inträffar kontrollerar det centraliserade meddelandesystemet för att se om några meddelanden är konfigurerade för att skickas. Det finns flera steg involverade i att bestämma vilka meddelanden som kommer att skickas, vem som kommer att få dem, vad innehållet kommer att vara och hur de kommer att levereras.

Fördelar med centraliserade notifieringar

Det centraliserade notifieringssystemet är ett standardsätt för utvecklare och slutanvändare att interagera med notifieringar. Här har vi beskrivit några av de viktigaste fördelarna med att använda centraliserade meddelanden:

• Meddelanden för en rad olika funktioner delar ett gemensamt gränssnitt. Tidigare tillhandahöll olika funktioner olika gränssnitt för att konfigurera notifieringar, med olika funktioner och konfigurerbarhet.
• Meddelanden kan återanvändas över mer än en instans (t.ex. samma meddelande i mer än en kurs). Tidigare implementerade olika funktioner olika sätt att dela mellan instanser, till exempel använda mallar.
• Användare har ett enda sätt att konfigurera alla sina meddelandeinställningar i det centraliserade meddelandesystemet. Tidigare kunde vissa notifieringar konfigureras i användarinställningar, medan andra var hårdkodade för att levereras via e-post, eller hade något annat konfigurationssätt.
• Beteendet för hur meddelanden skickas är konsekvent. Tidigare användes olika system för att avgöra vilka meddelanden som skickades och när. Det fanns olika sätt att hantera meddelanden som borde ha skickats tidigare, till exempel när ett nytt meddelande skapades för att skickas när en händelse inträffade, när den händelsen redan hade inträffat för vissa användare.
• Vid inställning av notifieringar har användare ett konsekvent sätt att välja vem varje notifiering ska skickas till. Tidigare, om ett meddelande behövde skickas till en användares chef, behövde en utvecklare implementera koden för att få det att hända, och anpassade gränssnittselement för att tillåta användare att kontrollera när den skulle användas.
• Ett delat schemaläggningssystem, som gör det möjligt att schemalägga nästan alla meddelanden, med minimalt arbete som krävs av utvecklaren. Tidigare var utvecklarna tvungna att implementera anpassade lösningar för att lägga till schemaläggning, inklusive gränssnittet som gjorde det möjligt för användare att konfigurera scheman.
• Ett enhetligt platshållarsystem, som möjliggör återanvändning av platshållare mellan olika anmälningstriggers, och en gemensam syntax för användare att använda platshållare i sitt meddelandeinnehåll. Tidigare var utvecklarna tvungna att implementera en anpassad lösning i varje funktion där platshållare krävdes, och användare var tvungna att lära sig rätt platshållarsyntax för den specifika funktionen.
• Konsekvent implementering av flerspråkiga funktioner. Tidigare var utvecklarna tvungna att implementera användningen av flerspråkiga funktioner i varje funktion med hjälp av notifieringar.
• En ny, enda källa för granskning av alla meddelanden och alla utgångstyper. Tidigare var användare tvungna att förlita sig på loggar som gjorts specifikt för en funktion, där det var tillgängligt, eller försöka använda interna varningar och uppgifter aviseringsdata som en källa för rapportering.
• Ett kärnsystem för utvecklare att implementera anmälningsutlösare på ett konsekvent och enkelt sätt. Mycket av arbetet med att utveckla anmälningsutlösare har gjorts för utvecklaren. Tidigare var utvecklare ofta tvungna att implementera sina egna lösningar på problem som schemaläggning och platshållare, men dessa tas alla om hand i centraliserade meddelanden.

Hur centraliserade notifieringar behandlas

Aviseringshändelser baserade på åtgärder och de som baseras på registrerade datum behandlas på något olika sätt:

• Om händelsen var en åtgärd som en användare utförde, så registreras händelsen i en kö för aviseringshändelser. Uppgiften Bearbeta händelseutlösta meddelanden (\totara_notification\task\process_event_queue_task) konfigureras som standard för att köras i bakgrunden varje minut och tittar på alla händelser som registrerats i kön och kontrollerar om det finns några motsvarande meddelanden som är konfigurerade för att skickas till händelse . Att minska frekvensen för denna schemalagda uppgift resulterar i att användare väntar längre innan de får dessa meddelanden och har ingen prestandafördel, så det bör därför lämnas att köra varje minut.
• Meddelanden som är schemalagda att skickas före eller efter registrerade datum, eller som är schemalagda att skickas på händelse och är baserade på registrerade datum, behandlas av uppgiften Behandla datumutlösta meddelanden (\totara_notification\task\process_scheduled_event_task), som är konfigurerad som standard för att köras i bakgrunden en gång per dag. Denna process hittar alla meddelanden som var planerade att skickas sedan den senaste gången uppgiften kördes. Även om det är möjligt att köra denna uppgift oftare, överväg effekten av detta beslut, eftersom denna uppgift måste utvärdera mycket data för att avgöra om några registrerade datum matchar de scheman som konfigurerats i meddelandena.

När en meddelandehändelse hittas sker följande process:

1. Om aviseringsutlösaren är inaktiverad så kommer aviseringen att kasseras (detta kan faktiskt inträffa tidigare, men är inte relevant ur användarens synvinkel).
2. Om meddelandet är inaktiverat så kasseras det.
3. Meddelandeutlösaren kan implementera ytterligare villkor som måste uppfyllas innan meddelandet skickas. Händelsedata utvärderas och meddelandet kommer att kasseras om det inte uppfyller dessa kriterier.
4. Listan över mottagare beräknas baserat på händelsedata.
5. Meddelandeinnehållet genereras för varje användare. Platshållare i patienten och kroppen ersätts med värden som beräknas med hjälp av händelsedata.
6. Varje mottagares aktiverade utgångar beräknas.
7. Meddelandeinnehållet skickas via varje utgång för varje användare.

Särskild anmärkning om när meddelanden skickas

Tidigare implementerades olika notifieringar på olika sätt. Ett viktigt problem var hur systemet visste om ett meddelande hade skickats, vilket hjälpte till att avgöra om ett meddelande behövde skickas. I många fall, om ett nytt meddelande skapades av en administratör, skulle systemet avgöra att meddelandet inte hade skickats till ett antal användare som redan uppfyllde kriterierna för att ta emot det meddelandet, och skulle sedan skicka det meddelandet till dessa användare. I de flesta fall var detta inte det avsedda resultatet. I det centraliserade meddelandesystemet skickas meddelanden endast när de ska skickas. Meddelanden placeras inte i en kö som väntar på att levereras vid någon senare tidpunkt. Systemet söker inte efter meddelanden som missades eller borde ha skickats tidigare. Systemet förlitar sig på timing för att avgöra vad som behöver skickas vid varje given tidpunkt. Den frågar "Vilka meddelanden borde ha skickats mellan nu och sista gången som meddelanden skickades?" och endast dessa meddelanden skickas.

Ett exempel kan hjälpa till att förklara detta. Säg att du har skapat ett meddelande för att välkomna nya användare när de är registrerade på en kurs. Om aviseringen är schemalagd att skicka På-händelse (dvs. så snart användaren är registrerad), så kommer den endast att skickas till användare som registrerar sig efter att du skapat aviseringen. Meddelandet kommer inte att skickas retroaktivt för användare som registrerade sig innan du skapade meddelandet. Om du ställer in samma meddelande så att det ska skickas 1 månad efter registrering, så kommer systemet varje dag att kontrollera om det finns användare med ett registreringsdatum för en månad sedan, och skicka till dessa användare, även om meddelandet inte fanns vid den tidpunkt då de registrerade sig. I detta fall kommer alla användare som registrerat sig under den senaste månaden, och de som registrerar sig i framtiden, så småningom att få meddelandet, på lämpligt datum. De som registrerade sig för mer än en månad sedan kommer aldrig att få det, eftersom de skulle få meddelandet innan det skapades.

Beskedsarv

Notifieringar i det centraliserade notifieringssystemet ärvs från högre sammanhang till lägre sammanhang. Funktionen som tillhandahålls av arv liknar idén med mallar, eftersom meddelanden kan skapas och hanteras på ett ställe och sedan återanvändas på många andra platser.

Meddelanden kan skapas i olika sammanhang, till exempel inom kurser, program, seminarier eller i systemsammanhang (kallas även ”platsnivå”). Meddelanden kan konfigureras i sammanhang som är högre än sammanhanget där händelsen inträffar och ärvs till lägre sammanhangsnivåer. Till exempel så sker kursavslutningshändelser i en kurskontext, men aviseringar om genomförd kurs kan skapas i systemkontexten, såväl som inom individuella kurser. Anmälningarna i vilket sammanhang som helst bestäms av de som skapats i det sammanhanget samt de som ärvts från högre sammanhang. Meddelanden i högre sammanhang ärvs i alla fallande sammanhang där händelsen inträffar.

Meddelanden som ärvs från högre sammanhang kan ha olika egenskaper åsidosatta i ett lägre sammanhang. Till exempel kan en deltagare som tilldelats i programmeddelande skapas i systemkontexten, med generiskt ämnes- och kroppsinnehåll som är lämpligt för de flesta program. Sedan i ett specifikt program kan ämne och kropp anpassas för att vara mer lämpliga för det programmet, eller så kan meddelandet inaktiveras helt i det programmet.

Du kanske till exempel vill att alla kurser på din webbplats ska skicka ett välkomstmeddelande när en användare först registreras. Detta meddelande ska ha samma innehåll i alla kurser, förutom namnet på kursen och namnet på användaren. I gränssnittet för meddelanden på platsnivå kan platsadministratören ställa in ett meddelande och inkludera kursens fullständiga namn och platshållare för användarens förnamn i ämnet och/eller kroppen (1). Detta meddelande kommer att ärvas i alla kurser, vilket innebär att alla nya och befintliga kurser kommer att få detta nya meddelande automatiskt inställt (2). I en viss kurs kan kursadministratören bestämma att meddelandetexten behöver ändras för att ge ytterligare information till nya användare. De kan ändra notifieringen på denna specifika kontextnivå genom att redigera den ärvda notifieringen i kursens notifieringsgränssnitt, aktivera omkopplaren Åsidosätt för kroppen och göra nödvändiga ändringar (3). I en annan kurs kan kursadministratören välja att inaktivera den ärvda notifieringen och skapa en ny anpassad notifiering baserat på samma notifieringsutlösare (4). 

Äldre version (legacy) av notifieringar

För närvarande använder ett antal olika funktioner äldre meddelanden, som fungerar annorlunda än det centraliserade meddelandesystemet. Om funktionaliteten du använder inte täcks av centraliserade notifieringar, kontrollera dokumentationen för den funktionen. Vi kommer att fortsätta att lägga till nya meddelanden och migrera befintliga meddelanden till det centraliserade meddelandesystemet .