Förtydliga uppgiften och beslutet
Den här guiden förvandlar webhooks och batchbearbetning till ett operativt arbetsflöde som kan granskas. Det kopplar samman domänbeslut, ägande, bevis och acceptans så att resultatet fortsätter att fungera i produktionen.
Välj synkron, webhook eller batchleverans från volym, latens, försök igen och operativt ägande.
Praktiskt arbetsflöde
- 1
Källtyper, identifierare, fält, lokaler, ägare och publiceringstillstånd.
- 2
Välj leveransmönster från volym, latens, redaktionell kontroll och feltolerans.
- 3
Mappa källposten till en separat språkversionspost med hållbar länkning.
- 4
Lägg till autentisering, idempotens, försök igen, cache-ogiltigförklaring, loggning och åtkomstkontroller.
- 5
Testpublicering, källändringar, otillgängliga resultat, återställning, tangentbordsdrift och övervakning före release.
Exempel eller verktyg
Ett livscykeldiagram blir ett implementeringskontrakt för omförsök, idempotens, övervakning och omspelning. I verktyget registrerar du även baslinje, ägare, beslut, bevis, öppen fråga och godkännandedatum. Använd en riktig sida eller transaktion så att teamet ser beroenden, undantag och underhållsarbetet som följer efter release.
| Beslutspunkt | Spela in | Acceptanskriterium |
|---|---|---|
| Baslinje | Observerat aktuellt tillstånd | Källa och datum registreras |
| Beslut | Valt alternativ och motivering | Risk och publik beaktas |
| Bevis | Testa, dokumentera eller mäta | Granskbar och versionsspecifik |
| Godkännande | Namn, roll och datum | Alla obligatoriska kriterier uppfyllda |
Välj leverans från latens, volym och ägande
Använd synkron leverans för små interaktiva förfrågningar som normalt slutförs inom gränssnittets timeout och kan rapportera ett resultat omedelbart. Använd webhooks när arbetet är asynkront men varje resultat bör komma in i CMS så snart det är klart. Använd batchbearbetning för stora schemalagda insamlingar, kontrollerad import eller migrering där genomströmning och reproducerbarhet är viktigare än omedelbar leverans. Mönstren kan samexistera, men varje innehållsklass bör ha en dokumenterad standard.
Uppskatta daglig och toppvolym, artikelstorlek, acceptabel färdigställandetid, försök igen, beställningskrav, granskarkapacitet och operativ ägare. Ett snabbt resultat har inget värde om redaktionskön inte kan bearbeta det. Inkludera uppströms- och nedströmsgränser: CMS-export, API-hastighet, köarbetare, återuppringningsslutpunkt, databasskrivningar, cache-invalidering och granskningsarbetsbelastning. Välj det enklaste mönstret som uppfyller hela servicemålet.
| Mönster | Använd när | Viktig kontroll |
|---|---|---|
| Synkron | Liten begäran och kort begränsad latens | Timeout med säker klientförsök igen |
| Webhook | Oberoende jobb bör komma omgående | Signaturverifiering och idempotent händelsehantering |
| Sats | Stort kontrollerat set och planerat färdigställande | Manifest, kontrollpunkt, försoning och repris |
Implementera en verifierbar webhook-livscykel
Acceptera endast HTTPS POST, verifiera signaturen mot råtexten, kontrollera tidsstämpelstoleransen och avvisa händelseversioner som inte stöds. Lagra händelse-ID:t under en unik begränsning innan du tillämpar affärsändringar. Returnera framgång efter hållbart kvitto och bearbeta sedan asynkront. En upprepad händelse ger framgång utan att biverkningen upprepas. Rotera signeringshemligheter med en överlappningsperiod och begränsa diagnostisk utdata så att den inte avslöjar signaturer eller innehåll.
Modelltillstånd som mottagna, validerade, matchade, tillämpade, ignorerade, försöker igen och misslyckades. Matcha resultatet med jobb-ID, käll-ID, källrevision, språk och läge. Om den aktuella källan är nyare, lagra resultatet för granskning men öppna eller ersätt inte det aktuella utkastet. Hantera händelser som inte fungerar enligt statliga övergångsregler snarare än ankomstorder. Behåll ett uppspelningsverktyg som kräver en anledning, operatörsidentitet och omfattning.
- 1
Verifiera transport, råkroppssignatur, tidsstämpel, händelsetyp och kontraktsversion.
- 2
Fortsätt den unika händelsen och bekräfta ett hållbart mottagande.
- 3
Lös jobb och exakt källrevision innan du ändrar CMS.
- 4
Tillämpa en idempotent tillståndsövergång och skapa det granskningsbara utkastet.
- 5
Spela in slutförandet eller dirigera händelsen till kontrollerat försök och uppspelning.
Gör partier reproducerbara och förenliga
Skapa ett oföränderligt manifest med batch-ID, skapandetid, fråge- eller urvalsregel, individuellt artikel-ID, källrevision, språkläge, läge, prioritet och kontrollsumma. Frys manifestet före inlämning så att en senare CMS-fråga inte kan ändra vad partiet betyder. Dela upp den i avgränsade bitar och använd stabila idempotensnycklar för varje föremål. Kontrollpunktsavslut efter hållbara skrivningar så att arbetare kan återuppta utan att börja om.
I slutet stämmer in skickade, accepterade, slutförda, avvisade, inaktuella, misslyckade och avsiktligt överhoppade objekt. Antalet måste balanseras mot det ursprungliga manifestet, och varje icke-slutfört objekt behöver en anledning och nästa åtgärd. Genom att spela om en delmängd skapas ett nytt uppspelningsmanifest kopplat till originalet. Ändra inte de ursprungliga räkningarna eller radera misslyckade bevis. Publicera batchresultat endast i granskningslägen, med arbetsbelastningsgränser som skyddar redaktionen.
Manifestet fixar objektidentitet, källrevision, inställningar och kontrollsumma.
Varje objektoperation är idempotent och oberoende omprövning.
Kontrollpunkter återupptas efter avbrott utan att duplicera utkast.
Slutliga statusräkningar överensstämmer exakt med manifestet.
Uppspelning är avgränsad, auktoriserad, länkad och kan granskas.
Övervaka köer och repetera återhämtning
Övervaka accepterad frekvens, slutförandefrekvens, felfrekvens per kategori, ködjup, äldsta artikels ålder, bearbetningsvaraktighetspercentiler, webhook-verifieringsfel, antal försök igen, dödbokstavsvolym, inaktuella resultatfrekvens och tid från resultat till redaktionellt godkännande. Varning om användarpåverkan och växande eftersläpning snarare än isolerade övergående misslyckanden. Dashboards separerar leverantörsbearbetning, återuppringningsleverans, CMS-applikation och redaktionell väntetid.
Runbooken identifierar ägare, säker paus, skalningsgränser, rotation av autentiseringsuppgifter, godkännande av omspelning, hantering av dödbokstäver, leverantörskommunikation och återställningsverifiering. Utöva förlorad återuppringning, upprepad händelse, urdrifthändelse, leverantörsavbrott, CMS-avbrott, schemafelmatchning, utgången hemlighet och partiell slutförande av batch. Acceptans kräver återställning utan duplicerad publicering, tyst förlust, manuell databasredigering eller borttagning av det senast godkända innehållet.
Roller, bevis och godkännande
Håll generation åtskild från publicering. Ett framgångsrikt svar är ett utkast, inte ett godkännande. Lagra källidentifierare och version, transformationsinställningar, resultatidentifierare, granskningsstatus, godkännare och publiceringstid. När källan ändras, markera språkversionen för granskning istället för att tyst ersätta godkänt innehåll. Detta gör återställning och revision möjlig över plattformar.
Drift och underhåll
Arbetet slutar inte vid publicering. Länka språkversionen eller konfigurationen till dess källa, övervaka kvalitets- och serviceåtgärder och definiera konkreta granskningsutlösare. Triggers inkluderar källändringar, juridiska ändringar, nya publikbehov, återkommande supportfrågor, tekniska förändringar och incidenter. En namngiven ägare utvärderar utlösaren, öppnar en ny revision vid behov och registrerar förnyat godkännande.
Checklista före publicering
Integrationen använder hållbara källidentifierare.
Inloggningsuppgifter lagras på serversidan och roteras.
Timeout, försök igen och hastighetsgräns-beteende definieras.
Upprepade förfrågningar är idempotenta.
Genererat innehåll går in i ett granskningsläge.
Källändringar ogiltigförklarar eller öppnar versionen igen.
Språknavigering fungerar med tangentbord och hjälpmedel.
Övervakning täcker fel, köer, latens och inaktuellt innehåll.