Entegrasyon bir kablo değil, veri sahipliği ve hata yönetimi tasarımıdır. Her veri alanı için ana kaynağı, güncelleme yönünü, gecikme toleransını ve başarısız işlem davranışını belirlemeden geliştirmeye başlamayın.
Önce veri sahipliğini kararlaştırın
Ürün adı, açıklama, stok, fiyat, kampanya, müşteri ve sipariş aynı sistemde doğmayabilir. Her alan için “doğru kayıt nerede tutulur?” sorusunu yanıtlayın. Örneğin stok ERP’den mağazaya giderken sipariş mağazadan ERP’ye akabilir; ürün görseli ise içerik yönetiminde tutulabilir. İki sistemin aynı alanı serbestçe değiştirmesi sessiz veri kaybına yol açar.
Alan eşleme belgesi yalnızca teknik isimleri değil, iş kurallarını da içermelidir. Vergi dahil fiyat, varyant, paket ürün, depo, iptal, kısmi sevkiyat ve iade kavramlarının iki tarafta aynı anlama gelip gelmediğini gerçek örneklerle doğrulayın. “Müşteri” veya “stok” gibi tanıdık kelimelerin sistemlerde aynı modeli temsil ettiğini varsaymayın.
- Her alanın ana kaynağı ve güncelleme yönü
- Kimlik eşleme yöntemi: SKU, varyant kodu, sipariş numarası
- Senkron veya kuyruklu aktarım kararı
- Kişisel veri, erişim yetkisi ve saklama sınırı
Veri sahibini atayın
Her alanın ana sistemini ve hangi yönde güncelleneceğini belirleyin.
Eşleme kurallarını yazın
Alan adlarının yanında vergi, varyant, stok, iptal ve iade anlamlarını da eşleyin.
Hatayı ve mutabakatı planlayın
Tekrar deneme, çift kayıt önleme, uyarı ve manuel uzlaştırma yolunu tanımlayın.
Başarılı akış kadar hata akışını tasarlayın
Bir API çağrısının başarılı olması siparişin işlenmiş olduğu anlamına gelmeyebilir. Zaman aşımı sonrasında tekrar gönderilen siparişin iki kez oluşmaması için benzersiz işlem anahtarları kullanılmalıdır. Geçici hatalar kontrollü olarak yeniden denenmeli; kalıcı doğrulama hataları ise anlaşılır bir kayıtla ilgili ekibe yönelmelidir.
Gözlemlenebilirlik yönetim ekranındaki “bağlı” işaretinden ibaret değildir. Son başarılı aktarım zamanı, bekleyen kayıt sayısı, hata nedeni ve tekrar deneme durumu görülebilmelidir. Entegrasyonun sahibi belli değilse küçük bir eşleme hatası günlerce fark edilmeden fiyat veya stok tutarsızlığı yaratabilir.
Testi mutlu senaryonun ötesine taşıyın
Önce sınırlı ürün ve sipariş kümesiyle uçtan uca prova yapın. Normal satışın yanında stok bitmesi, aynı anda gelen siparişler, fiyat değişimi, başarısız ödeme, iptal, kısmi iade ve bağlantı kesintisini deneyin. Canlıya geçişte eski siparişlerin aktarılıp aktarılmayacağı ve açık işlemlerin hangi sistemde tamamlanacağı da planlanmalıdır.
Mutabakat raporu iki sistemin aynı gerçeği taşıyıp taşımadığını gösterir. Günlük sipariş toplamı, satır adetleri, ödeme ve iade tutarları gibi değerler karşılaştırılabilir. Fark oluştuğunda düzeltmenin otomatik mi manuel mi yapılacağı önceden kararlaştırılmalıdır. Böylece ekip tek tek ekran kontrol etmek yerine istisnalara odaklanır.
| Veri | Sık kullanılan yön | Kritik kontrol |
|---|---|---|
| Ürün ve varyant | ERP/PIM → mağaza | Kod, kategori ve görsel eşlemesi |
| Stok ve fiyat | ERP → mağaza | Gecikme ve kampanya önceliği |
| Sipariş | Mağaza → ERP | Tekilleştirme ve durum eşlemesi |
| İade ve sevkiyat | Çift yönlü | Kısmi işlem ve mutabakat |
UYGULAMA LİSTESİ
Geliştirme başlamadan önce
- Alan bazında ana sistem ve veri yönü belirlendi.
- API sınırları, kotalar ve kimlik doğrulama yöntemi incelendi.
- Tekrar deneme ve çift kayıt önleme kuralları yazıldı.
- Hata kaydı, uyarı ve operasyon sahibi tanımlandı.
- İade, iptal ve bağlantı kesintisi senaryoları teste eklendi.
- Geri dönüş ve manuel çalışma planı hazırlandı.
Birincil kaynaklar
Uygulamaya geçmeden önce güncel ürün ve arama motoru belgelerini kendi koşullarınız için yeniden kontrol edin.
