ERP Entegrasyonu: Kayıp ve Mükerrer Siparişi Önleme

Başarılı bağlantı testi, doğru sipariş akışı değildir

API erişiminin çalışması yalnızca iki sistemin iletişim kurabildiğini gösterir. Gerçek iş akışı ürün kimliği, fiyat, para birimi, vergi alanları, adres ve sipariş durumlarını da doğru eşleştirmelidir. Bunların her biri için bilginin esas kaynağını belirleyin. Stok ERP’den geliyor ama kampanya fiyatı mağazada yönetiliyorsa, iki alanı aynı yönde güncellemek doğru olmayabilir.

Bu rehberdeki örnek, üreticiye ait varsayımsal bir mağazanın ERP’ye sipariş aktarmasıdır. Gerçek müşteri sonucu veya belirli bir ERP’nin hazır özelliği anlatılmıyor. Önerilen tasarımı uygulamadan önce sağlayıcının kimlik, tekrar, kota ve durum kurallarını doğrulayın. Kendi veritabanınızda yapabildiğiniz bir işlemi dış sağlayıcıda da yapabileceğinizi varsaymayın.

Siparişin kimliğini ve yaşam döngüsünü önce yazın

Bir siparişin kaynak mağaza kimliği ile ERP’deki belge numarası farklı olabilir. Eşleştirme kaydında kaynak kuruluş, kaynak sistem, sipariş kimliği ve hedef belgeyi ayrı alanlar olarak düşünün. Aynı siparişin oluşturulması, iptali ve kısmi iadesi de farklı iş komutlarıdır. Hepsini tek bir tekrar anahtarına bağlamak gerçek bir değişikliğin kaybolmasına yol açabilir.

Örneğin magaza-A / siparis-1042 / olustur / v1 anahtarı oluşturma niyetini temsil edebilir. Aynı niyet tekrar denendiğinde anahtar değişmez. Siparişe sonradan yeni ürün eklenmesi ise yeni bir komut veya sürüm olabilir. Anahtarı yalnızca istek gövdesinin benzerliğinden çıkarmak yerine iş niyetini açıkça modelleyin. Kullanıcının aynı ürünü gerçekten iki kez sipariş verebilmesi ile ağ nedeniyle tekrarlanan isteği ayırt etmek gerekir.

Amazon’un idempotent API rehberi, çağıranın sağladığı istek kimliğiyle tekrar niyetinin tanınmasını ve tekrarların ek yan etki üretmemesini ele alır. Aynı anahtarın farklı parametrelerle gelmesi gibi durumların da sözleşmede tanımlanması gerekir. [2]

Veriyi kaydetmek ile mesajı göndermek arasındaki boşluğu kapatın

Mağaza siparişi kendi veritabanına kaydedip sonrasında ERP’ye mesaj gönderebilir. Ancak iki adım arasında uygulama kapanırsa sipariş vardır, aktarım yoktur. Ters sırada ilerlemek de başka bir tutarsızlık oluşturabilir. İki farklı sisteme ayrı ayrı yazmayı tek başarılı işlem gibi kabul etmeyin.

Transactional outbox yaklaşımında iş kaydı ve gönderilecek olay, aynı yerel veritabanı işlemi içinde kaydedilir. Ayrı bir çalışan, tamamlanmış işlemdeki olayları aktarır. Böylece iş kaydıyla aktarılacak olayın birlikte kalması hedeflenir. Ancak olay birden fazla kez iletilebilir; alıcının tekrarları güvenli işlemesi hâlâ gerekir. Bu yöntem bütün dış sistemlerde uçtan uca “tam bir kez” etkiyi kendiliğinden garanti etmez. [1]

Önerilen örnekte sipariş satırı ve outbox kaydı birlikte oluşur. Çalışan kaydı alır, hedefe gönderir ve sonucu kalıcı duruma geçirir. Hedef yanıtı kaybolduğunda iş “kesin başarısız” değil, “sonucu belirsiz” olarak incelenebilir. Kuyrukta olmak, ERP’ye yazılmış olmakla aynı durum değildir. Operasyon panelinde bunların farklı görünmesi destek ekibinin yanlış karar vermesini önler.

Hedef sistem tekrar anahtarını desteklemiyorsa ne yapmalı?

Yerel tabloda “gönderildi” yazmak, hedef sisteme yazıldığı an ile bu tablonun güncellendiği an arasındaki belirsizliği tek başına çözmez. Hedefte dış referansa göre sorgulama veya benzersizlik desteği varsa bundan yararlanmayı değerlendirin. Yoksa yeniden deneme stratejisini daha ihtiyatlı kurun; bazı belirsiz işlemler insan incelemesi gerektirebilir.

Böyle bir durumda satıcıya şu senaryoyu sorun: “Belge oluştu fakat bağlantı koptu. Tekrar gönderdiğimde aynı belgeyi mi bulacağım, ikinci belge mi oluşacak?” Somut cevap alınmadan otomatik tekrar sayısını artırmak sorunu büyütebilir. Hedefin yetenek sınırını yazılı tutmak, geliştiricinin gizli varsayımla sistem kurmasını engeller.

Tekrar denemeleri sınırsız bir döngü olarak tasarlamayın. Önerilen plan, geçici bağlantı hatasıyla geçersiz ürün kodunu ayırır. Bağlantı sorunu gecikmeli yeniden denenebilir; eksik ürün eşleştirmesi ise düzeltme bekleyebilir. Gecikme, üst sınır, uyarı ve son inceleme sorumlusu birlikte tanımlanmalıdır.

Sıra ve eşzamanlılık için ayrı karar verin

Sipariş oluşturma olayı ile iptal olayı farklı zamanlarda ulaşabilir. İptal önce gelirse ne olacak? Bir siparişin eski sürümü yeni sürümün üzerine yazabilecek mi? Bu sorular yalnızca kuyruk seçimiyle bitmez; hedefte izin verilen durum geçişlerinin de tanımlanması gerekir.

Örnek ürün kuralında iptal, sipariş görülene kadar bekletilebilir veya kaynak sistemden güncel durum okunarak işlenebilir. Hangisinin doğru olduğu iş akışına bağlıdır. Sürüm numarası, olay zamanı ve son işlenen durum birbirini tamamlayabilir; yalnız cihaz saatine dayanan sıralama bütün senaryolar için yeterli kabul edilmemelidir.

Mutabakatı yedek çözüm değil, işletim parçası yapın

Başarılı API yanıtları saymak yerine kaynak ve hedef kayıtlarını iş kimliği üzerinden karşılaştıran bir mutabakat planı önerilir. “Bugün 100 sipariş gönderdik” ile “beklenen 100 siparişin her biri doğru belgeyle eşleşti” farklı kontrollerdir. Toplam sayılar aynı olsa bile bir sipariş iki kez, diğeri hiç oluşmamış olabilir.

Karşılaştırmada kaynak kimliği, hedef kimliği, son durum, ürün adedi, tutar alanlarının tanımı ve para birimi bulunabilir. Tutarları vergi dahil veya hariç farklı anlamlarla karşılaştırmayın. Kısmi iade ve iptal sonrası beklenen sonucun ne olduğunu işletme sorumlusu belirlemelidir. Bu kontrol mali muhasebenin yerine geçmez; entegrasyon tutarlılığını inceler.

Alarmı yalnızca hata sayısına bağlamayın. Örneğin en eski bekleyen işin yaşı ve belirli durumlarda biriken kayıtlar da değerlendirilebilir. Alarmların kime gideceği ve hangi işlemin güvenle yeniden başlatılabileceği açıklanmalıdır. Destek ekibinin “yeniden gönder” düğmesine basması da izlenebilir bir iş olsun.

Teslim paketinde ne bulunmalı?

Önerilen teslim, alan eşleştirme belgesi, iş kimliği kuralı, durum geçişleri, hata sınıfları, tekrar sınırları, sentetik test raporu ve mutabakat örneğini içerir. Her belgenin kullanılan entegrasyon sürümüyle ilişkisi kurulmalıdır. API sağlayıcısının değişiklikleri için takip sorumlusu ayrıca belirlenmelidir.

Outbox kullanırsak hiç sipariş kaybetmez miyiz?

Böyle bir mutlak sonuç çıkarılamaz. Outbox belirli bir yerel çift yazma problemini ele alır. Yanlış alan eşleştirmesi, hedef sistem davranışı, veri silme veya işletim hataları için ayrı kontroller gerekir. Tasarım deseni, doğrulanmış uçtan uca süreç yerine geçmez.

Entegrasyon için ilk gösterilecek demo ne olmalı?

Yalnız başarılı sipariş değil, sonucu belirsiz bir siparişin nasıl bulunduğu ve güvenle çözüldüğü gösterilmelidir. İyi entegrasyon, her şey yolundayken veri aktaran değil; işler ters gittiğinde hangi kaydın nerede olduğunu açıklayabilen entegrasyondur.