Rehber Otomasyon aynı kaydı iki kez oluşturuyorsa nasıl tasarlanmalı?

Bir otomasyon bağlantı hatasında tekrar çalışabiliyorsa aynı olayın ikinci kez gelmesini normal bir durum kabul edin. Çift kaydı yalnız “bir kez çalıştır” ayarıyla önlemek yerine olayın değişmeyen kimliğini saklayıp işlemin daha önce tamamlanıp tamamlanmadığını kontrol edin. Buna idempotent, yani tekrar edildiğinde aynı etkiyi koruyan işlem tasarımı denir.

İstek ile gerçek işlemi ayırın​

Varsayımsal bir sipariş aktarımında kaynak sipariş kimliği ORD-104 olsun. İlk istek hedefte kaydı oluşturduktan sonra yanıt yolda kaybolabilir. Kaynak sistem başarısız sanıp aynı siparişi tekrar gönderirse, yalnız yanıt durumuna bakan otomasyon ikinci kayıt oluşturur. Olay kimliği burada yeni rastgele sayı değil, aynı siparişi tanıyan sabit değerdir.

Tek etki üreten akış kurun​

1. Sabit olay anahtarını seçin. Kaynak sistem, olay türü ve olay kimliğini birlikte değerlendirin. Sipariş oluşturma ile sipariş iptalini aynı anahtarda yanlışlıkla birleştirmeyin.
2. Hedefte benzersiz alan tanımlayın. Aynı anahtarın iki kayda dönüşmesini veri tabanı veya hedef hizmetin benzersizlik desteğiyle engelleyin. Önce ara, sonra ekle yaklaşımı eş zamanlı iki istekte tek başına yeterli olmayabilir.
3. İşlem durumunu saklayın. Alındı, işleniyor ve tamamlandı gibi durumları gerçek etkiyle ilişkilendirin. Hedef işlem başarısızken olayı tamamlandı işaretlemeyin.
4. Tekrar geldiğinde uygun sonuç döndürün. Tamamlanan olay için yeni kayıt açmadan önceki sonucu kullanın. İşlenmekteyse çakışmayı yönetip kontrolsüz paralel işlem başlatmayın.
5. Aynı örneği iki kez gönderin. Sonuçta bir hedef kayıt bulunduğunu ve ikinci isteğin farklı bir yan etki üretmediğini kontrol edin. Ardından ilk denemenin yarıda kesildiği durumu deneyin.

Her tekrar aynı veri demek değildir​

Aynı anahtar altında farklı içerik geldiyse bunu sessizce ilk olayla birleştirmeyin. Güncelleme olayı mı, hatalı yeniden kullanım mı olduğunu belirleyin. Gerekirse içerik özeti veya sürüm numarasıyla farkı kaydedin.

Bir HTTP yönteminin adı da tek başına iş kuralını güvenilir yapmaz. Uygulamanın gerçek yan etkisi ve hedef hizmetin idempotency desteği birlikte değerlendirilmelidir. Özellikle e-posta gönderme gibi dış etkilerde, hedef sistemin tekrar anahtarını destekleyip desteklemediğini ayrıca kontrol edin.

Sabit olay anahtarıyla çift kayıt önlenirken aynı siparişin daha sonraki güncellemesi yanlışlıkla eski olay sayılabilir mi? Örnek olarak sipariş oluşturma ile adres güncellemenin aynı sipariş numarasını taşıdığını düşünelim. Anahtarın yalnız sipariş kimliğinden oluşması burada hangi ayrımı kaybettirir?

Olayın türü ile varlığın kimliği ayrılmalı. Aynı siparişe ait oluşturma ve güncelleme, farklı etkiler taşıyabilir; anahtar tasarımı bu sözleşmeye dayanmalı. Aynı olayın yeniden teslimi yeni işlem üretmemeli, fakat gerçekten yeni bir güncelleme de önceki olayın tekrarı sanılmamalı. Gerekirse kaynak olay kimliği ve sürümü kullanılır.

Aynı anahtar altında farklı içerik gelmesi de sessizce geçilecek bir durum değil. Bunun beklenen güncelleme mi, anahtarın yanlış yeniden kullanımı mı olduğu belirlenmeli. Ayrıca önce ara sonra ekle yaklaşımı eş zamanlı iki istekte yarışabilir; hedefteki benzersizlik güvencesi bu nedenle ayrı önem taşır.