Integrationer
Del af Integrationer og workflows
Undgå dobbelte handlinger ved genforsøg
Vælg en stabil handlingsnøgle, afklar tabte svar og begræns genforsøg, så samme oprettelse ikke sker to gange.
Et tabt svar betyder ikke nødvendigvis, at en handling mislykkedes. Hvis et oprettelseskald nåede målsystemet, kan et blindt genforsøg skabe endnu en post. Definér derfor den logiske handling, giv den en stabil nøgle, og afklar usikre udfald før et nyt kald.
Vælg nøglen efter den ønskede virkning
En besked og dens virkning er ikke det samme. En kilde kan sende samme besked igen eller udsende en ny besked om samme tilstand. Hvis en ordre skal give én arbejdsopgave, skal nøglen svare til netop den regel. Hvis hver ordrelinje skal give sin egen opgave, skal nøglen også indeholde ordrelinjen.
Et leverings-ID kan genkende en gentaget besked, men genkender ikke nødvendigvis den samme forretningshandling i en ny besked. Gem derfor forbindelsen mellem kildereference, handlingsnøgle og resultat i målsystemet. Hvis flere arbejdere kan behandle samme handling samtidig, skal kontrollen håndhæves samlet, eksempelvis med en atomisk unik registrering eller en dokumenteret idempotensfunktion hos målsystemet.
Skil usikkert udfald fra fejl
Målsystemet opretter måske opgaven, men svaret går tabt. Registrér udfaldet som ukendt, indtil resultatet kan findes via en stabil reference eller afklares på anden sikker måde.
| Tilstand | Betydning | Næste skridt |
|---|---|---|
| Afventer | Handlingen er registreret, men ikke sendt. | Start et kontrolleret forsøg. |
| Under behandling | Et forsøg er startet med den valgte nøgle. | Afvent eller undersøg forsøget. |
| Gennemført | Resultatets reference er kendt. | Undlad ny oprettelse. |
| Ukendt udfald | Svaret fastslår ikke virkningen. | Find eller afstem resultatet først. |
| Afvist | Data eller beslutning skal ændres. | Ret årsagen før genbehandling. |
Hvis målsystemet hverken tilbyder sikkert opslag eller idempotent oprettelse, kan en handling med væsentlig virkning kræve manuel afklaring.
Læs leverandørens idempotensvilkår
Stripe er et produktspecifikt eksempel. Stripe gemmer statuskode og svar for det første udførte POST-kald med en idempotensnøgle og returnerer det samme svar ved gentagelse, også hvis svaret er en 500-fejl.
En gentaget 500-fejl beviser derfor ikke, at et nyt forsøg er udført eller at virkningen er afklaret. Stripe kan fjerne nøgler, når de er mindst 24 timer gamle, og afviser ændrede parametre med samme nøgle. Undersøg dækkede kald, nøglens levetid og samtidige anmodninger i jeres faktiske målsystem.
En beskedkøs dubletkontrol ved afsendelse erstatter heller ikke sikker behandling hos modtageren. Azure Service Bus beskriver, at en besked kan leveres igen, hvis en modtager mister låsen eller genstarter.
Idempotens i praksis: Stripe & Azure Service Bus
- Stripe - Nøgletid
- Mindst 24 timer
- Stripe - Genbrug af nøgle
- Funktioner ved gentagelse, også ved 500-fejl
- Azure Service Bus - Dubletkontrol
- Kun ved afsendelse – modtager må håndtere gentagne beskeder
- Azure Service Bus - Genlevering
- Mulig, hvis modtager mister låsen eller genstarter
Giv genforsøg en grund og en grænse
Midlertidige fejl kan egne sig til genforsøg med pause. Ugyldige data eller manglende rettigheder kræver normalt en anden handling. Aftal et begrænset antal forsøg, tag højde for genforsøg i eventuelle SDK'er, og følg en Retry-After-anvisning, hvis tjenesten giver en.
Brug fiktive tilfælde med to ens beskeder, et tabt svar og to samtidige forsøg til at kontrollere den konkrete opsætning. Angiv på forhånd, hvor mange resultater hvert tilfælde må skabe.
