İçeriğe geçin

Webhook entegrasyonlarında tekrarlar için kural gerekir

Tekrarlanan webhookların iş üzerindeki etkisi kontrol altında kalmalıdır. Kaybolan alındı bildirimi, denetlenmeden ikinci siparişe yol açmamalıdır.

Tobias Krüger1 dk okuma
Aynı mor mesaj simgesini taşıyan, üst üste kaydırılmış iki zarf.

Webhook entegrasyonu planlarken tekrarlanan teslimleri olası bir işletim durumu olarak ele almak gerekir. Yazılım kararında belirleyici olan, mesaj ikinci kez geldiğinde iş eylemine ne olduğudur. Güvenilir bir bağlantı tek başına bu soruyu cevaplamaz.

Kaybolan bildirim sonucu belirsiz bırakır

Varsayımsal bir müşteri portalında bir bildirim, ERP'de sipariş oluşturmayı başlatır. Sipariş oluşturulur; ancak yanıt gönderene ulaşmaz. Gönderen, bildirimi yeniden iletir. Gelen her bildirim koşulsuz olarak yeni bir sipariş oluşturursa tek bir işlem talebinden iki sipariş doğar.

Stripe, olayların birden fazla kez teslim edilebileceğini açıkça belirtir. Bu, belirli bir sağlayıcı örneğini doğrular. Kendi bağlantınızın hangi tekrarları üretebileceğini, o bağlantının sözleşmesinden kontrol etmelisiniz. Alındı bildiriminin gelmemesi, ne kesin başarı ne de kesin başarısızlık anlamına gelir.

Tekrarı iş üzerindeki etkisiyle değerlendirin

Örnekte istenen kural şudur: Aynı bildirim, yeni sipariş oluşturmak yerine zaten oluşturulmuş siparişi bulabilmelidir. Bunun için entegrasyon, kararlaştırılmış bir kimliğe ve bu kimlikle işleme sonucu arasında güvenilir bir eşlemeye ihtiyaç duyar. Koruma, aynı anda gelen iki kopyayı da dikkate almalıdır; birbirinden bağımsız kontrol ve sonradan kaydetme adımları bu soruyu açık bırakır.

Kabul senaryosunda ERP'deki siparişi, yeniden denemenin yanıtını ve portalda görünen durumu kontrol edin. Taşıma düzeyindeki onay ile tamamlanmış sipariş farklı durumlar olabilir.

Gerekli çaba eyleme bağlıdır

Bir bildirim yalnızca ekranda görünen değeri aynı değerle yeniden güncelliyorsa tekrarı sorunsuz olabilir. Sipariş oluşturma veya bir kez gerçekleşmesi amaçlanan başka bir etki için daha fazla koruma gerekir. Bu, her küçük bağlantıya ek bir kuyruk koymayı zorunlu kılmaz.

Tekrarlar görünür kalmalıdır. Sayılarının artması bir arızaya işaret edebilir. Önerimiz, beklenebilir tekrarları yönetirken olağandışı örüntüleri de inceleyebilmektir.

Kaynaklar

Yazan

  • Tobias KrügerSistem Entegrasyonu EditörüTobias Krüger, ASES'te farklı yazılım sistemlerinin birlikte çalışmasıyla ilgilenir. Yazılarında ERP, CRM ve online mağazaların birbirine bağlanmasını ve veri alışverişindeki hataların nasıl ele alınacağını açıklar.

ASES'i takip edin

Devamını okuyun

Tüm yazılar

ASES ile API ve entegrasyon

ERP, CRM ve mağaza sorunsuz bağlantılı