Webhook ve ERP: çift siparişi önlemek

Mağaza bağlantısında tekrarlanan bildirimleri olağan bir durum olarak planlayın. Webhook, gönderen sistemin başlattığı HTTP mesajıdır. Teyit alınamazsa mesaj yeniden gelebilir. Bu durum ERP'de ikinci sipariş oluşturmamalıdır.

Stripe belgeleri hem aynı olayın tekrarını hem de aynı işlem hakkında birden fazla olay oluşabilmesini açıklar. Gerçek göndereninizin kurallarını ayrıca kontrol edin. Aşağıdaki örnek kurgusaldır; Stripe API'sini tarif etmez.

İki kimliğin farklı görevi var

shop-1 mağazasında W-240 siparişi bulunur. evt-17 olayı siparişin açıldığını bildirir. ERP'de siparişin kimliği E-901 olur. Olay kimliği tekrar teslimi tanır; mağaza ve sipariş kimliği birlikte iş işlemini eşleştirir. Daha sonra gelen evt-18, aynı siparişin değişikliğini bildirebilir.

Kabulü kalıcı kaydedin

Önce mesajın gerçekliğini gönderenin yöntemiyle doğrulayın. Sonra kabul yanıtını vermeden olayı kalıcı olarak kaydedin. Gönderen ve olay kimliğindeki benzersizlik, eşzamanlı iki kopyanın ayrı işler oluşturmasını engeller. Kaydetmeden önce yalnız arama yapmak eşzamanlı durumda yeterli değildir.

Sonraki işleme bu kalıcı kayıttan güvenilir biçimde başlamalıdır. Örneğin arka plan işleyicisi, kaydedilmiş açık olayları devralabilir. Böylece kabul ile işleme arasında çökme olsa da işlem bulunabilir.

Bu kayıttan sonra verilebilecek örnek yanıt:

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

Örnekte HTTP durumu 202'dir. Yanıt işleme sırasına alındığını teyit eder; henüz ERP sipariş teyidi değildir. Kalıcı kabul sağlanamıyorsa alıcı başarıyla kabul etmiş gibi yanıt vermemelidir.

ERP çağrısını da tekrara karşı koruyun

Hedef destekliyorsa sipariş açmak için shop-1:W-240:create gibi sabit bir anahtar kullanın. Güvenli tekrar denemesinde anahtar aynı kalır. Stripe kendi API'si için bu yaklaşımı gösterir; anlamı ve saklama süresi hedef sisteme bağlıdır.

Destek yoksa başka güvenilir eşleme gerekir: örneğin hedefte benzersizliği güvence altına alınmış dış sipariş kimliği ve sonucu sorgulama. Süre aşımından sonra siparişin oluşup oluşmadığı bilinmiyorsa işlem açıklama bekler. Yeni rastgele kimlik vermek, tekrarı yeni sipariş açılışı gibi gösterebilir.

İki sistemdeki olay kaydıyla ERP siparişi kendiliğinden tek işlem bütünlüğü oluşturmaz. Kabul, işleniyor, sonucu belirsiz ve tamamlandı durumlarını ayrı izleyin. Örnekte açılış ancak E-901 eşlemesi teyit edilince tamamlanır.

Hatalarla birlikte sınayın

evt-17'yi art arda ve aynı anda yeniden gönderin. ERP siparişi başarıyla açtıktan sonra yanıtı kesin. Ardından evt-18'i gerçek değişiklik olarak deneyin. Beklenen; tek sipariş açılması, eşlemenin korunması ve bilinmeyen sonuçta görünür bekleme durumudur. Olası tekrarları karşılamak için kimliklerin ne kadar saklanacağını da belirleyin.

Kaynaklar

• Stripe: Receive events in your webhook endpoint

• Stripe: Idempotent requests