Odoo'ya lead gönderirken kaybetmemek: ASP.NET Core'da transactional outbox
Bir lead'i kaydedip ardından Odoo'yu çağırmak, ikisi de başarısız olabilecek iki yazma işlemidir. Anas Amin, lead kaydının ve onu anlatan outbox mesajının tek transaction'da commit edildiği, teslimatın Hangfire job'ına devredildiği bir transactional outbox anlatıyor. Lease ile claim, hata sınıflandırması, dead-letter ve idempotent Odoo yazımı da tasarımın parçası.
Kilit noktalar
- Outbox satırı, iş satırıyla aynı SaveChangesAsync ve aynı SQL transaction'ında commit edilir; Odoo çağrısı düşse bile lead kaybolmaz.
- Mesajlar beş dakikalık lease ve guard'lı bir ExecuteUpdateAsync ile claim edilir; lease'i dolan mesaj çöken worker'dan otomatik geri döner.
- Job 30 saniyede bir çalışır, en fazla 20 saniye veya 500 mesaj işleyerek batch'i sınırlar.
- Timeout, 5xx, 408 ve 429 geçici sayılır ve 1, 5, 15, 60, 360 dakikalık artan gecikmelerle, jitter eklenerek yeniden denenir; 401, 403 ve diğer 4xx anında dead-letter olur.
- Idempotency, Odoo lead'ine yazılan GUID custom field ile sağlanır; teslimat önce bu alanla arar, varsa günceller yoksa oluşturur.
- Odoo 14-18 JSON-RPC ve session kullanırken Odoo 19 bearer key'li JSON-2 API eklediği için iki client tek interface arkasında, factory ile seçilir.
Lead'i veritabanına yazıp ardından Odoo'yu çağırmak, birbirinden kopabilecek iki yazma işlemidir: çağrı kayıttan sonra patlayabilir ya da kayıt, çağrıdan sonra bozulabilir. Transactional outbox ikinci yazmayı request'in dışına taşır. Inquiry ile OutboxMessage satırı (tür, aggregate id, JSON payload, durum, deneme sayısı, sonraki deneme zamanı) tek SaveChangesAsync içinde commit edilir; yani ya ikisi de vardır ya hiçbiri.
Hangfire'da 30 saniyede bir çalışan job, zamanı gelen mesajları en eskiden başlayarak en fazla 500 mesaj veya 20 saniyede işler. Claim, guard'lı bir ExecuteUpdateAsync ile yapılır: yalnızca vakti gelmiş pending satır ya da lease'i dolmuş processing satır processing'e geçebilir. Hatalar Odoo client'ında bir kez sınıflandırılır; timeout, 5xx, 408 ve 429 için 1, 5, 15, 60 ve 360 dakikalık gecikmelere jitter eklenir, 4xx ise dead-letter'a düşer. GUID custom field, teslimatı tekrarlanabilir kılar.
Gerçek dünyada kullanımı
- Satış ekibinin CRM'i olarak Odoo kullanan bir kurumsal site: form enquiry'lerinin bakım penceresinde bile kaybolmadan sıraya girmesi gerektiğinde.
- Onay süreci uygulamanın kendi veritabanında kalan, onaylanan tedarikçilerin ise ERP'ye senkronize edildiği supplier onboarding akışı.
- Birden fazla instance'a deploy edilen bir background worker'ın aynı mesajı iki kez göndermemesi gereken entegrasyonlar.
- Veritabanı yazmasından sonra uygulama yeniden başlasa da gitmesi gereken onay e-postası veya fatura gönderimleri.
Neden önemli
Veritabanı ile harici bir API arasındaki iki yazma er ya da geç ayrışır; outbox bunu kaybolan lead yerine metriklerde görünen gecikmiş bir lead'e çevirir. Lease ve dead-letter ayrıntıları, worker'ı birden fazla instance'a açmayı güvenli hale getirir.
Benzer haberler
- Vertical Slice mı Clean Architecture mı? .NET 10'da kullanılan hibrit yapıMukesh Murugan (codewithmukesh)4 gün önce
- .NET ile SSH, Docker ve Dosya Yönetimi Bir Arada: TermForge İncelemesiHabr C# (ru)2 gün önce
- NebulaGraph'a .NET'ten idempotent toplu yükleme: VID ile çoğaltma sorunuDEV Community: #csharp3 gün önce