A különbség elsősorban az időzítésben rejlik
Egy szerkesztőség 10:14-kor módosítja egy tanácsadó iroda adatait. A webhelynek azonnal meg kell jelenítenie az új telefonszámot, a saját portál keresőjének frissítenie kell az indexét, a közérthető nyelvi változat pedig később szakmai ellenőrzést igényel. Ezek a következmények ugyanahhoz a módosításhoz tartoznak, de nem kell mindegyiket ugyanabban a pillanatban feldolgozni.
A webhook olyan üzenet, amelyet egy rendszer közvetlenül egy esemény után küld egy másiknak. A szerkesztőségi rendszer például jelzi: „Ezt az oldalt közzétették.” A fogadó rendszer ezután pontosan ezt a tartalmat hívhatja le és dolgozhatja fel. Nem vár a következő általános futásig, és nem kérdez rá folyamatosan az új módosításokra.
Kötegelt feldolgozáskor több feladatot gyűjtenek össze és hajtanak végre együtt. Minden este ellenőrizhető például az aznap módosított összes oldal egy jelentéshez. Egy ilyen futás nem azonnali, viszont jól tervezhető. Nagy mennyiségeket dolgozhat fel egymás után, az eredményt pedig összefüggő áttekintésként adhatja át. A feldolgozásnak ismert kezdete és felismerhető vége van.
A webhookok egyedi, fontos eseményekhez illenek
A webhookok akkor hasznosak, ha a gyors reakciónak egyértelmű előnye van. Egy figyelmeztetés közzététele után az alkalmazásnak is meg kell kapnia ugyanazt az aktuális tartalmat. Egy oldal visszavonása után annak el kell tűnnie a belső keresőből. Az üzenetet minden esetben konkrét művelet váltja ki, és egyértelműen meghatározható tartalomra vonatkozik.
A szerkesztőség számára ez a folyamat közvetlennek érződik. Jóváhagy egy bejegyzést, és röviddel később látja az új változatot a kapcsolódó csatornán. Ezt a gyorsaságot azonban nem szabad garantált egyidejűségnek tekinteni. Hálózati hiba, karbantartás vagy túlterhelt fogadó rendszer késleltetheti a feldolgozást. A rendszernek el kell viselnie az ilyen megszakításokat.
Nem minden mentett módosításnak kell webhookot kiváltania. Egy automatikusan mentett piszkozat még nem fontos a nyilvános kereső számára. Az érdemi események a látható jelentéshez igazodnak: közzététel, lényeges frissítés, visszavonás vagy törlés. Így a kapcsolódó rendszerek kevesebb üzenetet kapnak, és egyértelműbben kezelhetik a fontos állapotváltozásokat. A belső elírások javítása szükség esetén másképp kezelhető, mint az új tények.
A kötegelt feldolgozás nagy mennyiséghez és rögzített időpontokhoz illik
A nagyobb futás akkor megfelelő, ha sok tartalmat ugyanazon szabályok szerint kell feldolgozni. Egy szervezet például minden éjjel ellenőrizheti az összes közzétett oldalon, hogy szerepel-e rajtuk felülvizsgálati dátum. Az olvasóknak keveset számít, hogy az eredmény 02:00-kor vagy 02:20-kor készül el. Ehhez szükségtelenül költséges lenne minden kis szerkesztés után azonnali üzenetet küldeni.
A teljes újraépítés is történhet tudatosan kötegelt módon. A keresőrendszer módosítása után esetleg 80 000 oldalt kell újra beolvasni. Az egyedi webhookok nem írnák le megbízhatóan a teljes állományt, mert a változatlan tartalmakat is érinti a művelet. A kötegelt futás ismert mennyiséggel indul, és dokumentálja, mely oldalakat dolgozta fel sikeresen.
A rögzített időpont megkönnyíti a terhelés tervezését. A képleírások, fordítási tervezetek vagy átfogó minőség-ellenőrzések számítási időt és külső szolgáltatásokat igényelnek. Egy éjszakai futás korlátozhatja ezt a munkát anélkül, hogy lassítaná a szerkesztőségi rendszerben történő közzétételt. Időtartama így jobban kiszámítható az üzemeltetés és a szolgáltatók számára. A sürgős tartalmakhoz ettől függetlenül gyorsabb út kell, ha a hosszú várakozás hibás információhoz vezetne.
Először a megengedett késedelemről kell dönteni
A legfontosabb kérdés: meddig mutathat régi állapotot a kapcsolódó rendszer? Egy időjárási veszélyjelzésnél percek is döntők lehetnek. Egy havi szövegminőségi értékelésnél általában nem jelent problémát egy nap. A világos időbeli követelmény többet segít annál az általános elvárásnál, hogy minden feldolgozás a lehető leggyorsabb legyen.
Ezután a jellemző módosítás terjedelme számít. Ha többnyire egyetlen oldalt tesznek közzé, a webhook pontosan ezt az oldalt nevezheti meg. Ha rendszeresen teljes állományok változnak, a tervezett futás áttekinthetőbb. Egy 4000 új helyszínt tartalmazó import nem válthat ki ellenőrizetlenül 4000 egyidejű utófolyamatot.
A kiesés következményeit is figyelembe kell venni. Ha elveszik egy üzenet, elavult telefonszám maradhat az alkalmazásban. Ha elmarad egy éjszakai jelentés, a szerkesztőség reggel újraindíthatja. Minden kapcsolódó csatornához kifejezetten meg kell állapodni az elfogadható késedelemről. Minél nagyobb a közvetlen kár, annál fontosabb a gyors újrapróbálkozás, a látható figyelmeztetés és a teljes állomány kiegészítő egyeztetése.
A webhooküzenet maradjon kicsi és egyértelmű
A jó üzenet megmondja, mi történt, melyik tartalmat érinti, és mikor jött létre az esemény. Ehhez egyedi eseményazonosító és az üzenetformátum verziója társul. A fogadó rendszer ezután védett interfészen hívhatja le a teljes, aktuális adatokat. Így az üzenet áttekinthető marad, és nem tartalmazza szükségtelenül a teljes cikket.
Ez a megoldás azt is megakadályozza, hogy egy késve érkező üzenet régi szöveget terjesszen. Tegyük fel, hogy a szerkesztőség rövid időn belül kétszer javítja ugyanazt a telefonszámot. Az első üzenet egy zavar miatt később érkezik meg a másodiknál. Ha a fogadó fél az aktuális állapotot hívja le, akkor is a legutóbb jóváhagyott változatot kapja, nem a késve érkező üzenet tartalmát.
Személyes vagy bizalmas tartalom szükségtelenül nem kerülhet az üzenetbe. A naplók, hibajelentések és adminisztrációs felületek gyakran hosszabb ideig tárolják a webhookadatokat. Sok esetben elegendő egy tartalomazonosító és az esemény típusa. A jogosult fogadó rendszer csak akkor hív le további adatokat, amikor valóban fel kell dolgoznia őket. Így a műszaki hibajelentés is mentes marad a szükségtelen szakmai tartalomtól.
Az ismételt üzenetek a normál működés részei
Ha a fogadó fél nem igazolja egy üzenet érkezését, a forrásrendszer újra elküldi. Lehet, hogy az első üzenetet már feldolgozták, csak a visszaigazolás veszett el. A fogadó rendszernek ezért ugyanazt az eseményt többször is el kell tudnia fogadni anélkül, hogy egy bejegyzést kétszer tenne közzé vagy ugyanazt a fordítást kétszer rendelné meg.
Ebben segít az egyedi eseményazonosító. Ha a rendszer már sikeresen kezelte ezt az azonosítót, visszaigazolhatja és kihagyhatja az ismétlést. Ez megbízhatóbb az időpontok vagy címek összehasonlításánál. Két különböző módosítás szinte egyszerre történhet, egy cím pedig megváltozhat úgy, hogy továbbra is ugyanarról a tartalomról van szó.
A sorrend sem mindig biztos. A közzétételről szóló értesítés egy későbbi javítás értesítése után érkezhet meg. A verziószám vagy a tartalom aktuális lekérése megakadályozza, hogy a régebbi állapot kerekedjen felül. A szerkesztőség számára a látható állapotnak akkor is helyesnek kell lennie, ha a műszaki üzenetek útja zavaros. Ezért nem dönthet egyedül a fogadás időpontja az érvényes változatról.
A fogadónak ellenőriznie kell az eredetet
Egy nyilvánosan elérhető webhookcímet jogosulatlanok is megkereshetnek. A fogadó rendszer ezért nem bízhat meg egy üzenetben pusztán azért, mert az a várt útvonalra érkezik. Általában digitális aláírást használnak, amelyet az üzenet tartalmából és egy közös titkos kulcsból számítanak ki. A fogadó újraszámítja, majd összehasonlítja a két értéket.
Az átvitel HTTPS-en történik, hogy útközben védve legyen a tartalom és a hozzáférési adat. A titkos kulcs nem kerülhet a forráskódba, nyilvános dokumentációba vagy az üzenet szövegébe. Védetten kell tárolni, csak a szükséges szolgáltatások számára elérhetővé tenni, és rendszeresen megújítani. A régi kulcsokat ellenőrzött átmenet után érvényteleníteni kell.
Az időbélyeg azt is korlátozza, meddig fogadható el egy helyesen aláírt üzenet. Így egy rögzített hívás később nem ismételhető meg tetszőlegesen. A hibaválaszok nem fedhetnek fel belső részleteket a támadóknak. A saját csapat számára azonban elegendő adat maradjon egy elutasított aláírás vagy elavult üzenetformátum célzott kivizsgálásához. A gyanús hozzáféréseket korlátozni kell, és a biztonsági ellenőrzéshez követhetően naplózni. Ehhez megfelelő, egyértelműen dokumentált megőrzési idők szükségesek.
A nagy futásnak követhető állapot kell
Egy 20 000 oldalas kötegelt futás ritkán teljesen sikeres vagy teljesen sikertelen. Néhány tartalom hibás adatot tartalmazhat, miközben a többi megfelelően feldolgozható. A futásnak ezért minden bejegyzésnél rögzítenie kell, mi sikerült, és mit kell újra megpróbálni. Egyetlen hibás oldal nem blokkolhat minden utána következőt.
Figyelembe kell venni a külső szolgáltatások korlátait. Egy interfész percenként csak meghatározott számú kérést engedhet. A futás ilyenkor kezelhető részekre bontja a mennyiséget, majd szünet után folytatja. Elmenti az előrehaladást, hogy újraindításkor ne az első oldaltól kezdjen, és ne ismételje meg szükségtelenül a már kifizetett munkát.
A szerkesztőség számára az érthető eredmény fontosabb egy hosszú műszaki naplófájlnál. Látnia kell, melyik futás érintett, hány tartalom készült el, és mely oldalak igényelnek szakmai segítséget. A „37 hiba” üzenet nem elegendő. Az oldalcímhez, webcímhez és konkrét okhoz rendelés feldolgozható feladattá teszi a hibát. A sikeres újrapróbálkozások ezután eltűnnek a nyitott szerkesztőségi nézetből.
A webhookokat gyakran tervezett futás egészíti ki
A webhookok és a kötegelt feldolgozás nem zárják ki egymást. Egy hírportál azonnal jelezheti keresőjének az új cikkeket, éjjel pedig egyeztetheti a teljes állományt. A gyors út naprakészen tartja a fontos módosításokat. A tervezett futás megtalálja azokat az eseményeket, amelyek üzemzavar, hibás beállítás vagy ideiglenesen kikapcsolt fogadó rendszer miatt kimaradtak.
A közérthető nyelvi változatnak is szüksége lehet mindkét időzítésre. Egy szakmai oldal módosításakor a webhook azonnal feladatot hoz létre az illetékes szerkesztőségnek. Az ellenőrzött változatot nem cseréli le automatikusan. Egy napi jelentés ezenfelül megmutatja az összes nyitott feladatot, határidejüket és azokat a tartalmakat, amelyeknél hiányzik a kapcsolat a forrásoldallal.
Döntő fontosságú az érvényes állapot egyértelmű forrása. A webhook módosítást jelez, a rendszeres egyeztetés pedig megerősíti az aktuális állományt. Ha eltérő adatokat adnak, nem győzhet véletlenszerűen a legutóbb lefutott folyamat. A közzétevő rendszer marad irányadó, a kapcsolódó rendszerek pedig ehhez igazítják állapotukat. Ezt a szabályt rendszerváltás után is egyértelműen dokumentálni kell.
Az üzemeltetésnek az emberek számára is érthetőnek kell maradnia
A műszaki megbízhatóság a látható információban mutatkozik meg. A csapatoknak tudniuk kell, általában mennyi ideig tart egy átvitel, és mikortól kell késedelmet jelenteni. A figyelmeztetés az érintett csatornát és tartalmat nevezze meg, ne csak egy belső folyamat nevét. Így a szerkesztőség megítélheti, hogy a látogatók éppen elavult állapotot látnak-e.
Minden folyamathoz felelős egység kell. Újraküldheti az elakadt üzenetet, folytathatja a kötegelt futást vagy leállíthatja a hibás közzétételt. Egyúttal felismerhetőnek kell lennie, mikor van szükség szakmai felelősségre. A műszaki csapat átvihet egy fájlt, de nem döntheti el, helyesen magyarázták-e el tartalmilag a módosított jogosultsági feltételt.
A megfelelő megoldást tehát a tartalom, az idő és a lehetséges kár határozza meg. A webhookok gyorsan reagálnak egyedi eseményekre. A kötegelt futások tervezhető mennyiségeket dolgoznak fel és állományokat egyeztetnek. Együtt lefedik az aktuális módosításokat és az állomány teljességét. Ha az ismétlést, a biztonságot és az érthető értesítéseket már kezdettől figyelembe veszik, a kapcsolódó webhelyek és szolgáltatások naprakészek maradnak anélkül, hogy szükségtelen technikával terhelnék a szerkesztőségi munkát.