Forskellen ligger først og fremmest i tidspunktet
Klokken 10.14 udgiver en redaktion ændrede oplysninger om et rådgivningssted. Webstedet skal straks vise det nye telefonnummer, søgemaskinen på organisationens egen portal skal opdatere sit indeks, og en forståelig sprogversion kræver senere en faglig gennemgang. Konsekvenserne hører til den samme ændring, men behøver ikke alle blive behandlet på samme tidspunkt.
En webhook er en meddelelse, som et system sender til et andet umiddelbart efter en hændelse. Redaktionssystemet meddeler for eksempel: "Denne side er blevet udgivet." Det modtagende system kan derefter hente og behandle netop dette indhold. Det venter ikke på den næste generelle kørsel og spørger heller ikke konstant efter nye ændringer.
Ved batchbehandling samles flere opgaver og udføres sammen. Hver aften kan for eksempel alle sider, der er ændret i løbet af dagen, kontrolleres til en rapport. En sådan kørsel sker ikke straks, men kan planlægges godt. Den kan behandle store mængder efter hinanden og levere resultatet som en samlet oversigt. Behandlingen følger en kendt begyndelse og en synlig afslutning.
Webhooks passer til enkelte vigtige hændelser
Webhooks giver mening, når en hurtig reaktion har en tydelig værdi. Efter udgivelsen af en advarsel skal appen modtage det samme aktuelle indhold. Når en side trækkes tilbage, skal den forsvinde fra den interne søgning. Meddelelsen opstår hver gang gennem en konkret handling og vedrører et klart identificerbart indhold.
For redaktionen føles forløbet umiddelbart. Den godkender et indlæg og ser kort tid efter den nye version i den tilknyttede kanal. Denne hastighed må dog ikke forveksles med garanteret samtidighed. Netværksfejl, vedligeholdelse eller en overbelastet modtager kan forsinke behandlingen. Systemet skal kunne tåle sådanne afbrydelser.
Ikke alle gemte ændringer bør udløse en webhook. En automatisk gemt kladde er endnu ikke relevant for den offentlige søgning. Meningsfulde hændelser følger den synlige betydning: udgivet, væsentligt opdateret, trukket tilbage eller slettet. Dermed modtager tilknyttede systemer færre meddelelser og kan håndtere de vigtige statusskift mere entydigt. Interne rettelser af slåfejl kan om nødvendigt behandles anderledes end nye fakta.
Batchbehandling passer til store mængder og faste tidspunkter
En større kørsel egner sig, når meget indhold skal behandles efter de samme regler. En organisation vil måske hver nat kontrollere alle udgivne sider for manglende oplysninger om kontroldato. Om resultatet foreligger klokken 02.00 eller 02.20 gør kun lille forskel for læserne. En øjeblikkelig meddelelse efter hver lille redigering ville være unødvendigt krævende.
En fuldstændig genopbygning kan også bevidst ske samlet. Efter en ændring af søgesystemet skal 80.000 sider måske indlæses igen. Enkelte webhooks ville ikke beskrive samlingen pålideligt, fordi uændret indhold også er berørt. En batchkørsel begynder med en kendt mængde og dokumenterer, hvilke sider der blev behandlet korrekt.
Det faste tidspunkt gør det lettere at planlægge belastningen. Billedbeskrivelser, oversættelsesudkast eller omfattende kvalitetskontroller kræver regnekraft og eksterne tjenester. En natlig kørsel kan afgrænse arbejdet uden at gøre udgivelsen i redaktionssystemet langsommere. Dermed bliver varigheden mere forudsigelig for drift og tjenesteudbyder. Akut indhold kræver alligevel en hurtigere vej, hvis lang ventetid ville føre til forkerte oplysninger.
Den tilladte forsinkelse afgør valget først
Det vigtigste spørgsmål er: Hvor længe må det tilknyttede system vise en gammel status? Ved et varsel om voldsomt vejr kan minutter være afgørende. Ved en månedlig analyse af tekstkvalitet er en dag normalt uproblematisk. En klar tidsangivelse hjælper mere end det generelle krav om, at al behandling skal ske så hurtigt som muligt.
Derefter tæller omfanget af en typisk ændring. Hvis der normalt udgives én side ad gangen, kan en webhook angive netop denne side. Hvis hele samlinger regelmæssigt ændres, er en planlagt kørsel mere overskuelig. En import af 4.000 nye placeringer bør ikke ukontrolleret udløse 4.000 samtidige følgeopgaver.
Konsekvenserne af et nedbrud hører også med i beslutningen. Hvis en meddelelse går tabt, bliver et forældet telefonnummer måske stående i appen. Hvis en natlig rapport mislykkes, kan redaktionen starte den igen om morgenen. Den acceptable forsinkelse bør være aftalt udtrykkeligt for hver tilknyttet kanal. Jo større den umiddelbare skade er, desto vigtigere er hurtige gentagelser, synlige advarsler og en supplerende afstemning af hele samlingen.
En webhook-meddelelse skal være lille og entydig
En god meddelelse fortæller, hvad der er sket, hvilket indhold det vedrører, og hvornår hændelsen opstod. Dertil kommer et entydigt hændelsesnummer og versionen af meddelelsesformatet. Det modtagende system kan derefter hente de fuldstændige og aktuelle data gennem en beskyttet grænseflade. Dermed forbliver meddelelsen overskuelig og indeholder ikke unødvendigt hele artiklen.
Fremgangsmåden forhindrer også, at en forsinket meddelelse distribuerer en gammel tekst. Antag, at redaktionen retter det samme telefonnummer to gange hurtigt efter hinanden. På grund af en driftsforstyrrelse ankommer den første meddelelse senere end den anden. Hvis modtageren henter den aktuelle status, får den alligevel den senest godkendte version og ikke indholdet fra den forsinkede meddelelse.
Personoplysninger eller fortroligt indhold hører ikke hjemme i meddelelsen uden grund. Logfiler, fejlrapporter og administrationsflader gemmer ofte webhook-data i længere tid. Et indholds-id og hændelsestypen er tilstrækkelige i mange tilfælde. Den autoriserede modtager henter først yderligere oplysninger, når den reelt skal behandle dem. Dermed forbliver en teknisk fejlrapport også fri for unødvendigt fagindhold.
Gentagne meddelelser er normale
Hvis modtageren ikke bekræfter, at en meddelelse er ankommet, sender kildesystemet den igen. Måske blev den første meddelelse allerede behandlet, men bekræftelsen gik tabt. Derfor skal modtageren kunne acceptere den samme hændelse flere gange uden at udgive et indlæg dobbelt eller bestille den samme oversættelse to gange.
Det entydige hændelsesnummer hjælper. Hvis nummeret allerede er behandlet korrekt, kan systemet bekræfte gentagelsen og springe den over. Det er mere pålideligt end at sammenligne tidspunkter eller titler. To forskellige ændringer kan ske næsten samtidig, og en titel kan ændre sig, selv om det stadig handler om det samme indhold.
Rækkefølgen er heller ikke altid sikker. En meddelelse om udgivelse kan ankomme efter meddelelsen om en senere rettelse. Versionsnumre eller en aktuel hentning af indholdet forhindrer, at den ældre status vinder. For redaktionsteams betyder det: Den synlige status skal være korrekt, selv om tekniske meddelelser tager en urolig vej. Modtagelsesdatoen alene må derfor ikke afgøre, hvilken version der gælder.
Modtageren skal kontrollere oprindelsen
En offentligt tilgængelig webhook-adresse kan i princippet også kontaktes af uvedkommende. Modtageren må derfor ikke stole på en meddelelse, blot fordi den ankommer ad den forventede sti. En digital signatur, der beregnes ud fra indholdet og en fælles hemmelig nøgle, er almindelig. Modtageren beregner den igen og sammenligner de to værdier.
Overførslen sker via HTTPS, så indhold og adgangsoplysninger er beskyttet undervejs. Den hemmelige nøgle hører ikke hjemme i kildekoden, offentlig dokumentation eller meddelelsesteksten. Den opbevares beskyttet, gøres kun tilgængelig for de nødvendige tjenester og fornyes regelmæssigt. Gamle nøgler skal blive ugyldige efter en kontrolleret overgang.
Et tidsstempel begrænser desuden, hvor længe en korrekt signeret meddelelse accepteres. Dermed kan et registreret kald ikke gentages vilkårligt meget senere. Fejlsvar bør ikke afsløre interne detaljer for angribere. Organisationens eget team skal alligevel have nok oplysninger til målrettet at undersøge en afvist signatur eller et forældet meddelelsesformat. Mistænkelig adgang begrænses og logges på en gennemskuelig måde til sikkerhedskontrol. Der gælder passende og klart dokumenterede opbevaringsperioder.
En stor kørsel kræver en gennemskuelig status
Ved 20.000 sider lykkes eller mislykkes en batchkørsel sjældent fuldstændigt. Noget indhold kan indeholde ugyldige oplysninger, mens resten behandles korrekt. Kørslen bør derfor registrere for hver post, hvad der lykkedes, og hvad der skal forsøges igen. En enkelt fejlbehæftet side må ikke blokere alle efterfølgende sider.
Begrænsninger hos eksterne tjenester skal medregnes. En grænseflade tillader måske kun et bestemt antal anmodninger pr. minut. Kørslen opdeler da mængden i acceptable dele og fortsætter efter en pause. Den gemmer sine fremskridt, så en genstart ikke begynder på den første side igen og unødvendigt gentager arbejde, der allerede er betalt for.
For redaktionen er et forståeligt resultat vigtigere end en lang teknisk logfil. Den skal kunne se, hvilken kørsel der er berørt, hvor meget indhold der er færdigt, og hvilke sider der kræver faglig hjælp. En meddelelse som "37 fejl" er ikke tilstrækkelig. Tilknytningen til sidetitel, adresse og konkret årsag gør fejlen til en opgave, der kan behandles. Vellykkede gentagelser forsvinder derefter fra den åbne redaktionelle oversigt.
En planlagt kørsel supplerer ofte webhooks
Webhooks og batchbehandling udelukker ikke hinanden. En nyhedsportal kan straks melde nye indlæg til sin søgning og om natten afstemme hele samlingen. Den hurtige vej holder vigtige ændringer aktuelle. Den planlagte kørsel finder hændelser, der mangler på grund af en forstyrrelse, en forkert indstilling eller en midlertidigt deaktiveret modtager.
En forståelig sprogversion kan også kræve begge tidspunkter. Når en fagside ændres, opretter webhooken straks en opgave til den ansvarlige redaktion. Den gennemgåede version erstattes ikke automatisk. En daglig rapport viser desuden alle åbne opgaver, deres frister og indhold, hvor forbindelsen til kildesiden mangler.
Det afgørende er en klar kilde til den gældende status. En webhook melder en ændring, mens den regelmæssige afstemning bekræfter den aktuelle samling. Hvis de to leverer forskellige oplysninger, må den senest udførte proces ikke tilfældigt vinde. Udgivelsessystemet forbliver den autoritative kilde, og de tilknyttede systemer afstemmer deres status med det. Denne regel skal også forblive entydigt dokumenteret efter et systemskifte.
Driften skal forblive forståelig for mennesker
Teknisk pålidelighed viser sig i den synlige information. Teams bør vide, hvor lang tid en overførsel normalt tager, og hvornår en forsinkelse rapporteres. En advarsel angiver den berørte kanal og det berørte indhold, ikke kun navnet på en intern proces. Så kan redaktionen vurdere, om besøgende aktuelt ser en forældet status.
Hvert forløb kræver en ansvarlig part. Den kan sende en meddelelse, der sidder fast, igen, fortsætte en batchkørsel eller standse en forkert udgivelse. Samtidig skal det være synligt, hvornår der kræves et fagligt ansvar. Et teknisk team kan overføre en fil, men ikke afgøre, om en ændret betingelse for en rettighed er forklaret korrekt.
Den rette løsning følger dermed af indhold, tid og mulig skade. Webhooks reagerer hurtigt på enkelte hændelser. Batchkørsler behandler planlagte mængder og afstemmer samlinger. Sammen dækker de aktuelle ændringer og samlingens fuldstændighed. Når gentagelser, sikkerhed og forståelige meddelelser tænkes ind fra begyndelsen, forbliver tilknyttede websteder og tjenester aktuelle uden at belaste redaktionens hverdag med unødvendig teknik.