Webhook ed ERP: evitare ordini duplicati

Preveda le notifiche ripetute come un caso normale dell'integrazione del negozio. Un webhook è un messaggio HTTP avviato dal sistema mittente. Se manca una conferma, può arrivare di nuovo. Questo non deve creare un ulteriore ordine ERP.

Stripe documenta eventi ripetuti e possibili eventi distinti sullo stesso oggetto. Verifichi le regole del mittente effettivo. L'esempio seguente è immaginario e non descrive l'API Stripe.

Due identificativi con compiti diversi

Il negozio shop-1 ha l'ordine W-240. L'evento evt-17 ne comunica la creazione. L'ERP assegna E-901. L'identificativo dell'evento riconosce una consegna ripetuta; negozio e ordine identificano insieme l'operazione aziendale. Un successivo evt-18 può segnalare una modifica dello stesso ordine.

Registrare la ricezione in modo duraturo

Autentichi prima il messaggio secondo il metodo del mittente. Salvi poi l'evento in modo duraturo prima di confermarne la ricezione. Un vincolo su mittente e identificativo impedisce che copie simultanee creino attività separate. La sola ricerca prima dell'inserimento non basta con accessi concorrenti.

L’elaborazione successiva deve partire in modo affidabile da questo archivio duraturo. Un processo in background può riprendere gli eventi salvati e in attesa. L’operazione resta così rintracciabile dopo un arresto fra ricezione ed elaborazione.

Una possibile risposta dopo il salvataggio:

{
  "eventId": "evt-17",
  "orderId": "W-240",
  "status": "queued"
}

Nell'esempio lo stato HTTP è 202. Conferma l'ingresso nell'elaborazione, non ancora un ordine ERP. Se il salvataggio duraturo non è assicurato, il destinatario non deve dichiarare una ricezione riuscita.

Proteggere anche la chiamata ERP

Usi una chiave di creazione stabile come shop-1:W-240:create se la destinazione la supporta. La mantenga invariata per una ripetizione sicura. Stripe illustra il principio per la propria API; significato preciso e conservazione dipendono dalla destinazione.

Senza tale funzione serve un'altra corrispondenza affidabile: per esempio un identificativo esterno reso univoco nella destinazione e una verifica dell'esito. Se un timeout lascia incerta la creazione, l'operazione resta in attesa di riconciliazione. Una nuova chiave casuale farebbe apparire la ripetizione come una nuova creazione.

Salvataggio dell'evento e creazione ERP in due sistemi non costituiscono automaticamente un'unica transazione. Distingua ricezione, elaborazione, esito incerto e completamento confermato. Qui la creazione termina solo con l'associazione confermata a E-901.

Verificare anche gli errori

Invii nuovamente evt-17 in successione e contemporaneamente. Interrompa la risposta dopo una creazione ERP riuscita. Provi poi evt-18 come vera modifica. Si attendono una sola creazione, corrispondenza conservata e stato di riconciliazione visibile se l'esito è ignoto. Definisca anche quanto conservare gli identificativi per coprire le possibili ripetizioni.

Fonti

• Stripe: Receive events in your webhook endpoint

• Stripe: Idempotent requests