ERP Entegrasyonunda Mesaj Tekrarlamaları ve Sıralama Sorunlarını Çözme: Teknik Rehber

Giriş: Neden bu konu önemli?

Üretim hattından ERP'ye veya üretim takip sistemine gönderilen olaylar (ör. parça üretildi, seri numarası atandı, stok güncellendi) gerçek dünyada güvenilirlikle ulaşmayabilir: aynı olay birden fazla kez iletilebilir, mesajlar gecikebilir veya kaynak sistemler farklı bir sıra ile gönderim yapabilir. Bu durum stok hatalarına, üretim siparişlerinin yanlış kapanmasına veya müşteri teslimat hatalarına yol açar. Aşağıda, özel yazılım hizmetimiz bağlamında uygulanabilecek, ASP.NET Core, C# ve SQL Server temelli pratik yaklaşımlar sunuyorum.

Problemin tanımı ve tipik senaryolar

Somut senaryolar:

• PLC veya barkod okuyucudan gelen aynı üretim tamamlandı olayı ağ kopması yüzünden tekrar gönderiliyor.
• Bir makine offline iken ürettiği kayıtları bufferlayıp sonra topluca gönderiyor; sıra karışıyor.
• İki sistem arasındaki saat uyuşmazlığı nedeniyle olay zamanına göre yanlış sıralama oluşuyor.
• ERP tarafında tekil constraint (ör. stok hareketine ilişkin benzersiz anahtar) ihlal ediliyor veya çift kayıt oluşuyor.

Bu sorunlar operasyonel müdahale gerektirir. Ama müdahale maliyetini düşürmek için yazılımsal önlemler almak daha sürdürülebilir bir çözümdür.

Çözüm yaklaşımı: Temel prensipler

• Idempotency: Aynı mesajın birden çok kez işlenmesi sistem durumunu değiştirmemeli.
• Sıralama / Ordering: Olayların mantıksal sırasının korunması veya en azından tutarlı hale getirilmesi.
• Atomicity ve Tutarlılık: Mesaj işlendiğinde ilgili ERP güncellemesi ile üretim takip verisi tutarlı olmalı (veya geri alınabilir).
• Gözlemlenebilirlik: Hangi mesajın ne zaman, nasıl işlendiği açıkça izlenebilmeli.

İdempotency: Nerede ve nasıl uygularsınız?

İdempotency için en yaygın yöntemler:

• Her olay için benzersiz bir Idempotency-Key üretmek ve işleme başlamadan önce bu anahtarın daha önce kullanılıp kullanılmadığını kontrol etmek.
• İşlenmiş mesajları tutan bir MessageLog tablosu kullanmak; burada MessageId, Kaynak, İşlemZamanı, Durum(başarılı/başarısız) saklanır.
• İşlem başarılıysa aynı mesaj tekrar geldiğinde kaynak sisteme sadece "accepted/duplicate" yanıtı döndürmek.

Uygulama notu: Idempotency-Key üretiminde kaynağın özgün mesaj kimliği (ör. PLC mesaj UID, cihaz ID + sıra numarası) kullanılmalı. Eğer kaynak id sağlamıyorsa, alıcı taraf bir deterministik hash (ör. payload + kaynak + timestamp) üretebilir; ancak bu, payload değişirse tekrar işleme riskine neden olur.

Sıralama (Ordering) sorunlarını ele alma stratejileri

Sıralama gereksinimi iki türdür: global ordering (tüm olaylar arasında kesin sıra) ve per-entity ordering (ör. tek bir iş emri/seri numarası için sıra). Global ordering genellikle pahalıdır; çoğu senaryoda per-entity ordering yeterlidir.

• SequenceNumber ile per-entity ordering: Kaynak sistem her mesaj için bir sıra numarası gönderebilir. Alıcı, beklenen sıra numarasını izler; eksik numara gelirse mesaj buffer'lanır.
• Watermark (yüksek işlenmiş sıra): İşlenmiş en yüksek sıra numarası per-entity saklanır; gelen mesajın numarası daha yüksekse işlenir, daha düşükse muhtemelen duplicate olarak reddedilir.
• Gecikmeli işler için zaman pencereleme: Ağ gecikmelerine tolerans için bir zaman penceresinde yeniden sıralama ve tamponlama uygulanabilir. Ancak bu, gerçek zamanlı cevap beklentisi olan süreçlerde problem yaratır.

Pratik uygulama: ASP.NET Core tarafında tamponlama

İstemciden gelen olaylar API'ye ulaşır. API, kısa süreli bellek içi tampon veya Redis gibi merkezi bir cache'e mesajları sırayla kaydedip, arka planda çalışan bir IHostedService ile per-entity sıraya göre işler. Bu tasarım, API'nin hızlı yanıt vermesini sağlarken sıralama politikasını arka planda yönetir.

Veritabanı tasarımları ve kilit stratejileri (SQL Server)

SQL Server üzerinde uygulanabilecek pratik yaklaşımlar:

• Unique constraint ile duplicate oluşumunu engelleyin: Stok hareketleri için (Kaynak, KaynakMesajId) kombinasyonunda UNIQUE index.
• Idempotency tablosu: MessageId PK, Status, ProcessedAt, PayloadHash. İşlem öncesi SELECT ile kontrol, işlem sonrası UPDATE/INSERT. Tek adım garantisi için transaction kullanın.
• sp_getapplock ile per-entity locking: Aynı iş siparişi/seriye ilişkin paralel işlemleri seri hale getirmek için application lock kullanmak düşük maliyetli bir yöntemdir.
• MERGE veya koşullu INSERT/UPDATE: Tek bir transaction içinde stok miktarını güncelleyin; INSERT başarısız olursa duplicate olduğu anlaşılır.

Örnek yaklaşım akışı: API aldığında transaction başlatır -> Idempotency tablosunu kontrol eder ve kilit alır (sp_getapplock('workorder-123')) -> stok hareketini oluşturur veya atlar -> Idempotency kaydını success ile günceller -> transaction commit. Bu akış aynı mesaj iki kez işlendiğinde ikinci işlemde Idempotency kaydı nedeniyle atlanır.

Dağıtık işlemler ve kompansasyon (SAGA)

ERP'ye HTTP ile güncelleme gönderiliyorsa, uçtan uca atomicite sağlamak zordur. SAGA pattern bu noktada kullanışlıdır:

• Bir iş akışı adım adım yürütülür; her adımın bir ters işlemi (compensating action) tanımlıdır.
• Örneğin stok azaltma başarılı, ancak ERP güncellemesi başarısız olursa, sistem ya tekrar deneyebilir ya da önceki stok hareketini kompansasyonla geri alır ve uyarı üretir.
• SAGA koordinasyonunu Event Store veya bir Durable Task framework (ör. açık kaynak veya Azure Durable Functions) ile yönetebilirsiniz.

Mesaj kuyrukları, retry ve poison handling

Mesajlaşma altyapısı (RabbitMQ, Apache Kafka, Azure Service Bus) ile şu prensipleri uygulayın:

• Retry politikaları: Kısa süreli ağ hataları için artan gecikmeli (exponential backoff) retry uygulayın.
• Deduplication: Kuyruk katmanında da MessageId ile dedup uygulanabiliyorsa, SDS (source dedup support) kullanın. Ancak uygulama katmanında yine de idempotency bırakın.
• Poison queue: Belirli retry sonrası işlenemeyen mesajlar ayrı bir kuyruğa gönderilmeli ve bu kuyruk için manuel veya yarı otomatik inceleme süreci kurmalısınız.

Telemetry ve operasyonel izleme

Problemi hızlı teşhis etmek için gerekli telemetri:

• Message ingress/egress metrikleri: gelen mesaj sayısı, duplicate oranı, ortalama gecikme.
• Idempotency hit/miss oranı.
• Sıra tamponundaki bekleyen mesaj sayıları ve en eski bekleme süreleri.
• ERP tarafı doğrulama hataları ve kompansasyon olayları.

Bu metrikleri Prometheus/Grafana veya Application Insights ile toplayıp dashboard ile yayınlamak operasyonel tepkiyi hızlandırır.

Uygulama örnek mimari önerisi (yüksek seviyede)

• Edge/PLC/Barkod cihazları → IoT Gateway (MQTT/AMQP) → Mesaj Kuyruğu (Kafka/ServiceBus)
• İşleme katmanı: ASP.NET Core API + Background Hosted Service (iş sıralama ve idempotency kontrolü)
• Kalıcı katman: SQL Server (Idempotency, MessageLog, Inventory Transactions) + Redis (geçici tampon/lock hızlandırma)
• ERP Entegrasyonu: Asenkron API çağrıları / webhook'lar ile; SAGA veya compensating transaction yönetimi

Teknik uygulama ipuçları

• C# tarafında idempotency kontrolü için idempotency repository pattern kullanın ve bunları transaction scope içine alın.
• EF Core yerine kritik yüksek trafikli uçlarda Dapper veya raw SQL tercih edin; böylece MERGE/sp_getapplock kullanım performans avantajı sağlar.
• Clock drift sorunlarını azaltmak için tüm bileşenlerin saatlerini NTP ile senkronlayın; mesaj zamanları UTC olmalı.
• Gelen payload büyüklüğünü sınırlandırın ve hash'ini saklayın; payload değiştiğinde hash farklı olacağından tekrar işlenebilirlik kontrolu yapılır.

Ne zaman dışarıdan yardım almalısınız?

Eğer şu durumlardan biri varsa özel yazılım veya entegrasyon uzmanı ile çalışmak verimlidir: sistem karmaşık, birden fazla heterojen kaynak varsa, mevcut ERP'ye zarar verebilecek riskler mevcutsa veya operasyonel kesinti sonuçları ağırsa. Bayrak Bilişim gibi ekipler bu tip entegrasyonlarda mimari değerlendirme, prototip ve üretime alma aşamalarında yol gösterir. Detaylı bir inceleme veya teklif için iletişim sayfamızdan ulaşabilirsiniz.

Sonuç: Uygulanabilir bir yol haritası

Özet adımlar:

1. Kaynak tarafında mümkünse MessageId ve SequenceNumber sağlayın.
2. Idempotency tablosu ve unique constraint'lerle duplicate riskini azaltın.
3. Per-entity sıralama için sequence veya watermark yaklaşımı uygulayın; gerektiğinde tamponlama kullanın.
4. ERP entegrasyonunu SAGA veya kompansasyon ile dizayn edin.
5. Retry, poison queue ve gözlemlenebilirlik mekanizmalarını kurun.

Bu rehber, üretim hattı ve ERP arasındaki mesajlaşma problemlerini teknik olarak ele almak için somut yöntemler sunar. Uygulama ayrıntıları, kullandığınız ekipman/ERP çeşidine göre değişecektir; proje başlangıcında mevcut sistemlerin envanterini çıkarıp, düşük riskli bir pilot ile başlamanız tavsiye edilir.