Teknik Makaleler
ERP–WMS entegrasyonunda idempotency: Aynı istek iki kez gelirse ne olur?
Zaman aşımı, tekrar deneme ve çift kayıt riskini iş niyeti, istek kimliği ve işlem durumu üzerinden değerlendiren teknik entegrasyon yazısı.
Bu yazıda neler var?
ERP bir sevkiyat kaydını WMS'ye gönderdi, fakat yanıtı alamadı. Bağlantı kesilmiş olabilir; işlem sunucuda tamamlanmış da olabilir. Aynı isteği yeniden göndermek, ikinci bir sevkiyat oluşturmadan nasıl mümkün olur? İdempotent işlem tasarımı tam bu belirsizliği ele alır.
Yanıt gelmemesi, işlemin yapılmadığı anlamına gelmez
Bir isteğin istemciden çıkması, alıcıda işlenmesi ve yanıtın geri dönmesi ayrı adımlardır. Ağ hatası bu adımların herhangi birinde oluşabilir. Bu yüzden yalnızca zaman aşımı mesajına bakarak iş kaydını tekrar oluşturmak riskli bir varsayımdır.
AWS Builders' Library, istemcinin verdiği benzersiz istek kimliğini API isteğine dahil ederek aynı niyetle gelen tekrarları ayırt etmeyi ele alıyor. Aynı anahtarın farklı parametrelerle yeniden kullanılması da ayrıca değerlendirilmesi gereken bir durum olarak açıklanıyor.
İş niyetini tanımlayan anahtar seçin
Örnek olarak bir kaynak sistemin, belirli bir sevkiyat oluşturma talebi için tek bir istek kimliği üretmesini düşünün. Taşıma sırasında tekrar denemeler yapılabilir; ancak aynı iş niyetinin anahtarı değiştirilmez. Yeni bir iş gerçekten isteniyorsa ayrı anahtar kullanılır.
Bu, uygulama örneğidir; evrensel anahtar formatı önermez. Anahtarın hangi müşteri veya kaynak sistem kapsamında benzersiz olduğu sözleşmede belirtilmelidir. Yalnızca mesaj gövdesinin aynı görünmesine bakmak, farklı zamanlarda bilinçli olarak yapılan iki benzer işlemi yanlışlıkla birleştirebilir.
Tekrar kaydı ile iş sonucunu tutarlı yönetin
Tekrar kontrolü yapıldıktan sonra başka bir işlem aynı anahtarı kullanabiliyorsa WMS içerisinde yanlış işlemlerin oluşması durumu oluşabilir. Bu nedenle kalıcılık, benzersizlik ve transaction sınırları tasarımın parçasıdır. Veritabanında bir anahtarın bulunması tek başına fiziksel işlemin tamamlandığını kanıtlamaz.
Depo ekipmanı, harici servis veya mesaj kuyruğu aynı transaction'a katılmıyorsa işin durum makinesi ayrıca tanımlanmalıdır. Bekliyor, işleniyor, tamamlandı ve sonucu belirsiz gibi durumların anlamı açık olmalı. Bu yazı belirli bir veritabanı için eksiksiz uygulama reçetesi sunmaz.
Aynı anahtar, farklı içerik
Tekrar gelen isteğin anahtarı aynıyken miktar veya ürün değişmişse bunu normal tekrar gibi kabul etmek doğru olmayabilir. Kendi sözleşmenizde hangi alanların iş niyetini oluşturduğunu tanımlayın; çelişkili kullanımı anlaşılır bir hata ile ele alın.
Yanıt davranışı da önemlidir. İstemci, önceki işlemin sonucunu güvenli biçimde öğrenebilmeli. Sadece “kayıt var” mesajı, ilk işlemin kendisine ait olup olmadığını açıklamıyorsa operasyon ekibinin belirsizliğini artırabilir.
Depo entegrasyonu için test listesi
- İlk istek tamamlandı, yanıt ağda kayboldu.
- Aynı anahtarlı iki istek aynı anda geldi.
- Aynı anahtarla farklı miktar gönderildi.
- İstek gecikerek yeniden ulaştı.
- İş harici sisteme iletildi, sonucu henüz kesinleşmedi.
Her testte oluşturulan iş kaydı sayısını, mevcut durumun sorgulanmasını ve operatöre gösterilen açıklamayı kontrol edin. “Retry ekledik” ifadesi, tek başına entegrasyon güvenilirliğini kanıtlamaz.
Kapsam
AWS kaynağı genel API tasarım yaklaşımını destekler. Depo örnekleri ve test listesi özgün teknik değerlendirmedir. Finansal, fiziksel veya harici yan etkiler için ayrıca sisteminize uygun bir hata ve uzlaştırma tasarımı gerekir.
Kaynaklar
Kaynak kontrol tarihi: 1 Kasım 2026.