Hantera ett integrationsfel med korrekta statusmeddelanden
Vid ett fel måste mottagning, väntande arbete och bearbetning gå att skilja åt. Ett portalexempel visar vilken återkoppling som passar när.
Visa vad programvaran faktiskt vet vid ett integrationsfel. En portal kan mildra ett avbrott, men bör inte visa ännu öppen ERP-bearbetning som en färdig order. Spårbara tillstånd och en kontrollerad återupptagning är avgörande.
Fastställ det senast tillförlitligt registrerade tillståndet
I en fiktiv portal skickar en kund en begäran om att skapa en order. ERP-systemet är tillfälligt otillgängligt. Portalen måste utifrån sitt eget tillförlitligt registrerade bearbetningstillstånd kunna avgöra om begäran redan har accepterats. En visning ensam sparar ingen begäran.
Tillförlitligt fastställt tillstånd i exemplet | Passande meddelande i portalen |
|---|---|
Begäran inte tillförlitligt sparad | Sändning inte bekräftad; kontrollera status eller försök igen kontrollerat |
Begäran sparad och avsedd för bearbetning | Begäran mottagen; bearbetning väntar |
ERP-bearbetning pågår, resultat fortfarande öppet | Bearbetning pågår; order ännu inte bekräftad |
ERP-order bevisligen skapad och kopplad | Order bekräftad |
Dessa tillstånd är vår exempelmodell. Benämningarna måste stämma med applikationens faktiska bevis. En snabb, lyckad HTTP-mottagning bevisar inte ensam att ordern har skapats färdigt.
Koppla upprepningar till samma åtgärd
Om en kund skickar igen på grund av det oklara läget på skärmen måste applikationen kunna känna igen om samma order avses. Ange identifieraren, dess område och hanteringen av redan bearbetade begäranden. Stripe beskriver upprepade händelseleveranser som ett konkret webhookfall; det ger ingen universell upprepningsregel för ditt ERP-system.
Kontrollera särskilt fallet där ERP-ordern skapades men svaret försvann. Ett nytt försök får då inte utlösa ytterligare en order utan kontroll.
Ange ansvar och kommunikation
Bestäm vem som bedömer felet, vem som tillåter att bearbetningen fortsätter och vem som uppdaterar den synliga statusen. Google SRE Workbook skiljer lösning av en incident från samordning och kommunikation. Ett litet team kan förena rollerna men behöver fortfarande tydliga ansvarsområden.
Fortsätt kontrollerat efter återställningen
Att ERP-systemet är tillgängligt är utgångspunkten för kontrollen. Klargör öppna och redan bearbetade begäranden innan väntande arbete utförs igen. Visa statusen bekräftad först när tillhörande bevis finns.
Testa ett avbrott före lagring, ett avbrott efter lagring och ett förlorat ERP-svar. Kontrollera den synliga portalstatusen och det verkliga antalet skapade order. Då ser du om återkopplingen stämmer även när kunden upplever felet direkt.
Källor
Läs vidare
Alla artiklar
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade