5 dk okuma
Giriş
ERP ile e-ticaret platformunu birbirine bağlamak ilk bakışta birkaç API çağrısından ibaret görünebilir. Ürünü gönder, stoğu güncelle, siparişi ERP’ye aktar. Gerçekte ise entegrasyonun zor kısmı veri taşımak değil, iki sistem aynı anda değişirken tutarlı ve tekrar çalıştırılabilir bir operasyon kurmaktır.
ERP e-ticaret entegrasyonu tasarlarken veri sahipliği, idempotency, retry, mapping, hata yönetimi ve izlenebilirlik baştan düşünülmezse sistem büyüdükçe manuel müdahale ihtiyacı artar.
1. Her veri için kaynak sistemi belirleyin
Bir ürünün adı ERP’de mi yönetilecek, e-ticaret panelinde mi? Fiyatın ana kaynağı neresi? Stok hangi sistemde kesin bilgi olarak kabul edilecek? Bu soruların cevabı entegrasyonun temelini oluşturur.
Aynı verinin iki sistemde de serbestçe değiştirilebildiği yapılar zamanla çakışma üretir. Her veri grubu için bir source of truth belirlemek ve diğer sistemleri bu kaynaktan beslemek daha güvenli bir yaklaşımdır.
Sipariş gibi bazı veriler e-ticaret platformunda doğar, finansal ve muhasebesel sonuçları ERP’de devam eder. Bu durumda ownership süreç bazında değişebilir.
2. Kimlik ve mapping tablosunu ayrı yönetin
ERP ürün kodu ile pazaryeri SKU’su her zaman aynı olmak zorunda değildir. Aynı durum kategori, depo, kargo firması, ödeme tipi ve iade nedeni gibi alanlarda da görülür.
Bu eşlemeleri kod içine gömmek yerine ayrı mapping yapılarında tutmak operasyonel değişiklikleri kolaylaştırır. Mapping kayıtlarına tarihçe veya aktif/pasif durumu eklemek de ileride yapılan değişikliklerin nedenini anlamayı kolaylaştırır.
3. İdempotency olmadan otomasyon kurmayın
Entegrasyonlarda timeout sık görülür. İstemci isteği gönderir, karşı taraf işlemi tamamlar ama cevap dönmeden bağlantı kesilir. Aynı mesaj tekrar gönderildiğinde ikinci sipariş veya ikinci fatura oluşmaması gerekir.
Bu nedenle sipariş numarası, claim id, external id veya özel idempotency key üzerinden aynı işlemin daha önce yapılıp yapılmadığı kontrol edilmelidir.
Idempotent tasarım retry mekanizmasının güvenle kullanılabilmesini sağlar.
4. Senkron çağrı ile arka plan işlemini ayırın
Kullanıcının ekranda beklemesi gerekmeyen stok, sipariş, iade veya ürün senkronizasyonları background worker veya queue üzerinden çalıştırılabilir.
Event-driven mimaride producer ve consumer’ın ayrılması ölçeklenebilirlik sağlar ancak eventual consistency gerçeğini de beraberinde getirir. Kullanıcıya verinin anlık mı yoksa birkaç saniye/dakika içinde mi güncelleneceği açık şekilde tasarlanmalıdır.
Kritik ve anında cevap gerektiren işlemler synchronous kalabilir; uzun süren entegrasyon işleri ise arka plana taşınmalıdır.
5. Retry politikasını hata türüne göre uygulayın
Her hata tekrar denenmemelidir. 500 veya geçici network hataları retry için uygun olabilirken 400 validation hatası aynı payload ile tekrar gönderildiğinde yine başarısız olacaktır.
Retry sayısını, bekleme süresini ve exponential backoff politikasını merkezi şekilde tanımlamak gerekir. Belirli sayıda denemeden sonra kayıt dead-letter veya manuel inceleme kuyruğuna alınabilir.
En önemlisi retry’nin idempotency ile birlikte tasarlanmasıdır.
6. Sipariş aktarımını tek transaction gibi düşünmeyin
E-ticaret siparişinin ERP’ye aktarılması çoğu zaman müşteri bulma/oluşturma, adres eşleme, stok kontrolü, sipariş oluşturma ve ödeme bilgisini taşıma gibi birden fazla adımdan oluşur.
Farklı sistemleri kapsayan tek bir ACID transaction çoğu zaman mümkün değildir. Bu nedenle adımların durumunu takip eden bir workflow oluşturmak ve başarısız noktadan devam edebilmek daha gerçekçidir.
Distributed yapılarda eventual consistency ve compensating action kavramları burada önem kazanır.
7. Log değil, operasyon geçmişi tasarlayın
Teknik loglar geliştirici için faydalıdır ancak operasyon ekibinin ‘bu sipariş neden aktarılmadı?’ sorusuna cevap vermesi için yeterli olmayabilir.
İşlem bazında external id, şirket, kanal, başlama zamanı, son durum, hata özeti ve tekrar deneme sayısını gösteren operasyon geçmişi çok değerlidir.
Correlation id kullanmak teknik log ile iş kaydını birbirine bağlamayı kolaylaştırır.
8. Credential ve tenant izolasyonunu baştan düşünün
Birden fazla firma aynı entegrasyon uygulamasını kullanıyorsa API anahtarları, ERP bağlantıları ve operasyon kayıtları şirket bazında ayrılmalıdır.
Secret değerleri kaynak kodda tutulmamalı; güvenli secret store, environment variable veya şifreli veri alanları kullanılmalıdır. Kullanıcı arayüzünde secret değerlerin maskelenmesi ve audit kaydında düz metin görünmemesi gerekir.
9. Entegrasyonu test edilebilir parçalara bölün
Pazaryeri veya ERP istemcisini doğrudan iş servisine gömmek testleri zorlaştırır. Adapter/interface yaklaşımıyla harici sistemi izole etmek, gerçek endpoint olmadan senaryoları test etmeyi sağlar.
Örneğin IMarketplaceClient, IErpClient ve IOrderSyncEngine gibi sorumluluklar ayrıldığında mapping ve workflow kuralları daha rahat test edilebilir.
Sonuç
Sağlam ERP e-ticaret entegrasyonu, API çağrılarının çalışmasından çok daha fazlasıdır. Başarılı bir yapı veri sahipliğini netleştirir, tekrar çalıştırılabilir işlemler tasarlar, arka plan senkronizasyonunu kontrollü kullanır ve hataları operasyon ekibinin anlayabileceği şekilde görünür hale getirir.
Entegrasyon mimarisini bu prensiplerle kurduğunuzda yeni pazaryeri veya ERP akışı eklemek de çok daha az riskli hale gelir.
