Skillnaden ligger främst i tidpunkten
Klockan 10.14 publicerar en redaktion ändrade uppgifter om en rådgivningsenhet. Webbplatsen måste genast visa det nya telefonnumret, en sökmotor i den egna portalen ska förnya sitt index och en begriplig språkversion behöver senare en sakkunnig granskning. Följderna hör till samma ändring, men måste inte alla bearbetas samtidigt.
En webhook är ett meddelande som ett system skickar till ett annat direkt efter en händelse. Redaktionssystemet meddelar exempelvis: "Den här sidan har publicerats." Det mottagande systemet kan då hämta och bearbeta just detta innehåll. Det väntar inte till nästa allmänna körning och frågar inte heller hela tiden efter nya ändringar.
Vid batchbearbetning samlas flera uppgifter och körs tillsammans. Varje kväll kan exempelvis alla sidor som ändrats under dagen granskas för en rapport. En sådan körning sker inte direkt, men är lätt att planera. Den kan bearbeta stora mängder efter varandra och tillhandahålla resultatet som en sammanhängande översikt. Bearbetningen följer en känd början och ett synligt slut.
Webhooks passar enskilda viktiga händelser
Webhooks är lämpliga när en snabb reaktion ger tydlig nytta. Efter att en varning har publicerats ska appen få samma aktuella innehåll. När en sida har dragits tillbaka ska den försvinna ur den interna sökningen. Meddelandet uppstår varje gång genom en konkret handling och berör ett tydligt identifierbart innehåll.
För redaktionen känns arbetsflödet omedelbart. Den godkänner ett inlägg och ser kort därefter den nya versionen i den anslutna kanalen. Snabbheten får dock inte förväxlas med garanterad samtidighet. Nätverksfel, underhåll eller ett överbelastat mottagarsystem kan fördröja bearbetningen. Systemet måste tåla sådana avbrott.
Inte varje sparad ändring bör utlösa en webhook. Ett automatiskt sparat utkast är ännu inte relevant för den offentliga sökningen. Meningsfulla händelser utgår från den synliga betydelsen: publicerat, väsentligt uppdaterat, tillbakadraget eller raderat. Då får anslutna system färre meddelanden och kan behandla de viktiga statusbytena mer entydigt. Interna rättelser av skrivfel kan vid behov hanteras annorlunda än nya fakta.
Batchbearbetning passar stora mängder och fasta tider
En större körning passar när många innehåll ska bearbetas enligt samma regler. En organisation kanske vill kontrollera alla publicerade sidor varje natt för att hitta granskningsdatum som saknas. Om resultatet finns klockan 02.00 eller 02.20 gör liten skillnad för läsarna. Ett direkt meddelande efter varje liten redigering vore onödigt resurskrävande för detta.
Även en fullständig nyuppbyggnad kan medvetet utföras samlat. Efter en ändring i söksystemet kan 80 000 sidor behöva läsas in på nytt. Enskilda webhooks skulle inte tillförlitligt beskriva beståndet eftersom även oförändrat innehåll berörs. En batchkörning börjar med en känd mängd och dokumenterar vilka sidor som bearbetades med framgång.
Den fasta tidpunkten underlättar planeringen av belastningen. Bildbeskrivningar, översättningsutkast eller omfattande kvalitetskontroller kräver beräkningskapacitet och externa tjänster. En nattlig körning kan avgränsa arbetet utan att sakta ner publiceringen i redaktionssystemet. Varaktigheten blir då mer förutsägbar för drift och tjänsteleverantörer. Brådskande innehåll behöver ändå en snabbare väg om en lång väntan skulle leda till felaktig information.
Den tillåtna fördröjningen avgör först
Den viktigaste frågan är: Hur länge får det anslutna systemet visa ett gammalt tillstånd? För en varning om extremväder kan minuter vara avgörande. För en månatlig analys av textkvalitet är en dag oftast oproblematisk. En tydlig tidsangivelse hjälper mer än det allmänna kravet att varje bearbetning ska ske så snabbt som möjligt.
Därefter räknas omfattningen av en typisk ändring. Om oftast en enda sida publiceras kan en webhook ange just den sidan. Om hela bestånd regelbundet ändras är en planerad körning mer överskådlig. En import av 4 000 nya platser bör inte okontrollerat utlösa 4 000 samtidiga följdjobb.
Även följderna av ett avbrott hör till beslutet. Om ett meddelande går förlorat kanske ett inaktuellt telefonnummer ligger kvar i appen. Om en nattlig rapport misslyckas kan redaktionen starta den igen på morgonen. Den tolererade fördröjningen bör avtalas uttryckligen för varje ansluten kanal. Ju större den omedelbara skadan är, desto viktigare är snabba nya försök, synliga varningar och en ytterligare avstämning av hela beståndet.
Ett webhook-meddelande förblir litet och entydigt
Ett bra meddelande anger vad som har hänt, vilket innehåll det gäller och när händelsen uppstod. Därtill kommer ett unikt händelse-ID och meddelandeformatets version. Det mottagande systemet kan därefter hämta fullständiga, aktuella data via ett skyddat gränssnitt. Då förblir meddelandet överskådligt och innehåller inte hela artikeln i onödan.
Metoden förhindrar också att ett försenat meddelande distribuerar en gammal text. Anta att en redaktion rättar samma telefonnummer två gånger i snabb följd. Det första meddelandet kommer fram senare än det andra på grund av en störning. Om mottagarsystemet hämtar det aktuella tillståndet får det ändå den senast godkända versionen och inte innehållet i det försenade meddelandet.
Personuppgifter eller konfidentiellt innehåll hör inte hemma i meddelandet om det inte behövs. Loggar, felrapporter och administrationsgränssnitt lagrar ofta webhook-data under längre tid. Ett innehålls-ID och typen av händelse räcker i många fall. Det behöriga mottagarsystemet hämtar fler uppgifter först när det verkligen måste behandla dem. Då förblir även en teknisk felrapport fri från onödigt fackinnehåll.
Upprepade meddelanden är ett normalt fall
Om mottagarsidan inte bekräftar att ett meddelande har kommit fram skickar ursprungssystemet det igen. Det första meddelandet kan redan ha bearbetats medan bekräftelsen gick förlorad. Därför måste mottagarsystemet kunna ta emot samma händelse flera gånger utan att publicera ett inlägg dubbelt eller beställa samma översättning två gånger.
Det unika händelse-ID:t hjälper till. Om numret redan har behandlats med framgång kan systemet bekräfta upprepningen och hoppa över den. Det är mer tillförlitligt än att jämföra tider eller titlar. Två olika ändringar kan ske nästan samtidigt och en titel kan ändras trots att det fortfarande gäller samma innehåll.
Ordningsföljden är inte heller alltid säker. Ett meddelande om publicering kan komma fram efter meddelandet om en senare rättelse. Versionsnummer eller en aktuell hämtning av innehållet förhindrar att det äldre tillståndet vinner. För redaktionsteam innebär det att det synliga tillståndet måste stämma även om de tekniska meddelandena tar en orolig väg. Enbart mottagningsdatumet får därför inte avgöra vilken version som gäller.
Mottagaren måste kontrollera ursprunget
En offentligt åtkomlig webhook-adress kan i princip även anropas av obehöriga. Mottagarsystemet får därför inte lita på ett meddelande bara för att det kommer till den förväntade sökvägen. Vanligt är en digital signatur som beräknas utifrån innehållet och en gemensam hemlig nyckel. Mottagaren beräknar den på nytt och jämför värdena.
Överföringen sker via HTTPS så att innehåll och åtkomstuppgifter skyddas på vägen. Den hemliga nyckeln hör inte hemma i källkoden, offentlig dokumentation eller meddelandetexten. Den lagras skyddat, görs bara tillgänglig för de tjänster som behöver den och förnyas regelbundet. Gamla nycklar måste bli ogiltiga efter en kontrollerad övergång.
En tidsstämpel begränsar dessutom hur länge ett korrekt signerat meddelande accepteras. Då kan ett inspelat anrop inte upprepas hur långt senare som helst. Felsvar bör inte avslöja interna detaljer för angripare. Det egna teamet behåller ändå tillräckliga uppgifter för att särskilt undersöka en nekad signatur eller ett inaktuellt meddelandeformat. Avvikande åtkomst begränsas och loggas så att säkerhetsgranskningen kan följa upp den. För detta gäller rimliga och tydligt dokumenterade lagringstider.
En stor körning behöver en spårbar status
Med 20 000 sidor är en batchkörning sällan helt lyckad eller helt misslyckad. Vissa innehåll kan innehålla ogiltiga uppgifter medan resten bearbetas korrekt. Körningen bör därför för varje post dokumentera vad som lyckades och vad som måste försökas igen. En enda felaktig sida får inte blockera alla följande sidor.
Begränsningar i externa tjänster måste beaktas. Ett gränssnitt tillåter kanske bara ett visst antal begäranden per minut. Körningen delar då upp mängden i hanterbara delar och fortsätter efter en paus. Den sparar sina framsteg så att en omstart inte börjar om från den första sidan och upprepar redan betalt arbete i onödan.
För redaktionen är ett begripligt resultat viktigare än en lång teknisk loggfil. Den måste se vilken körning som berörs, hur många innehåll som är färdiga och vilka sidor som behöver sakkunnig hjälp. Ett meddelande som "37 fel" räcker inte. Kopplingen till sidtitel, adress och konkret orsak gör felet till en uppgift som går att bearbeta. Lyckade nya försök försvinner därefter från den öppna redaktionella vyn.
Ofta kompletterar en planerad körning webhooks
Webhooks och batchbearbetning utesluter inte varandra. En nyhetsportal kan genast meddela nya inlägg till sin sökfunktion och stämma av hela beståndet på natten. Den snabba vägen håller viktiga ändringar aktuella. Den planerade körningen hittar händelser som saknas på grund av en störning, en felaktig inställning eller ett tillfälligt avstängt mottagarsystem.
En begriplig språkversion kan också behöva båda tidsskalorna. När en facksida ändras skapar en webhook genast en uppgift för den ansvariga redaktionen. Den granskade versionen ersätts inte automatiskt. En daglig rapport visar dessutom alla öppna uppgifter, deras tidsfrister och innehåll där kopplingen till originalsidan saknas.
Avgörande är en tydlig källa för det giltiga tillståndet. En webhook meddelar en förändring och den regelbundna avstämningen bekräftar det aktuella beståndet. Om båda ger olika uppgifter får inte processen som råkade köras sist vinna. Det publicerande systemet förblir avgörande och de anslutna systemen stämmer av sitt tillstånd mot det. Regeln måste förbli entydigt dokumenterad även efter ett systembyte.
Driften måste förbli begriplig för människor
Teknisk tillförlitlighet visar sig i den synliga informationen. Team bör veta hur lång tid en överföring normalt tar och från när en fördröjning rapporteras. En varning anger den berörda kanalen och innehållet, inte bara ett internt processnamn. Då kan redaktionen bedöma om besökarna just nu ser ett inaktuellt tillstånd.
Varje arbetsflöde behöver en ansvarig funktion. Den kan skicka ett meddelande som har fastnat på nytt, fortsätta en batchkörning eller stoppa en felaktig publicering. Samtidigt måste det framgå när sakkunnigt ansvar krävs. Ett tekniskt team kan överföra en fil, men inte avgöra om ett ändrat villkor för en rättighet har förklarats korrekt i sak.
Rätt lösning följer alltså av innehåll, tid och möjlig skada. Webhooks reagerar snabbt på enskilda händelser. Batchkörningar bearbetar planerade mängder och stämmer av bestånd. Tillsammans täcker de aktuella ändringar och beståndets fullständighet. När upprepningar, säkerhet och begripliga meddelanden beaktas från början förblir anslutna webbplatser och tjänster aktuella utan att belasta redaktionens vardag med onödig teknik.