Konfigüratör entegrasyonu için kontrol listesi

Sistem ve veri haritasını çıkarın

Ürün adı, SKU, seçenek listesi, fiyat, stok, müşteri ve teklif bilgileri aynı sistemde bulunmayabilir. Önce mevcut sistemleri ve her alanın sahibini belirleyin.

Konfigüratörün hangi veriyi okuyacağı, hangi veriyi yazacağı ve hangi durumda yalnız bağlantı oluşturacağı ayrı ayrı tanımlanmalıdır.

• Ürün ve parça kodlarının kaynağı
• Fiyat listesi ve para birimi
• Stok veya uygunluk bilgisi
• Müşteri ve bayi yetkileri
• Teklif, sipariş ve ödeme durumu

Yapılandırmayı taşınabilir bir kayıt hâline getirin

Sadece ekrandaki toplam fiyatı CRM’ye göndermek yeterli değildir. Yapılandırma kimliği, ürün kodları, seçenek değerleri, miktar ve sürüm bilgisi birlikte tutulursa satış ekibi aynı seçimi yeniden açabilir.

Ürün verisi zaman içinde değişiyorsa, eski bir teklifin hangi kural ve fiyat sürümüyle oluşturulduğu da önem kazanır.

Alan eşleştirmesini bir API sözleşmesine dönüştürün

Entegrasyon toplantısındaki sözlü mutabakat, geliştirme için yeterli değildir. Her alanın adı, veri tipi, zorunluluk durumu, izin verilen değerleri ve hata davranışı örnek istek ve cevaplarla belgelenmelidir.

Ürün kodu bulunamadığında boş değer göndermek, işlemi reddetmek veya manuel inceleme açmak farklı iş sonuçları doğurur. Bu kararların kod yazılmadan önce ürün ve operasyon ekipleriyle paylaşılması tekrar çalışmayı azaltır.

• İstek ve cevap şemaları
• Zorunlu ve isteğe bağlı alanlar
• Kod ve birim sözlükleri
• Kimlik doğrulama ve yetki kapsamı
• Hata kodu, mesaj ve tekrar davranışı
• Sürüm ve geriye uyumluluk politikası

Yetki ve kişisel veri sınırlarını belirleyin

Fiyat listeleri, bayi iskontoları ve müşteri kayıtları herkese açık tarayıcı koduna taşınmamalıdır. Hassas kurallar sunucu tarafında uygulanmalı ve kullanıcı yalnız yetkili olduğu sonucu görmelidir.

Form ve CRM bağlantılarında gerekli olmayan kişisel veriler toplanmamalı; saklama, erişim ve silme sorumlulukları mevcut veri politikalarıyla uyumlu olmalıdır.

Başarısız aktarımı görünür ve düzeltilebilir yapın

Bir API çağrısının başarısız olması kullanıcı talebinin kaybolması anlamına gelmemelidir. Tekrar deneme, benzersiz istek kimliği, hata kaydı ve gerektiğinde manuel devam adımı planlanmalıdır.

Canlıya geçmeden önce yalnız başarılı senaryo değil; eksik ürün kodu, güncel olmayan fiyat, zaman aşımı ve yinelenen istek gibi durumlar da test edilmelidir.

1. Alan eşleştirmelerini örnek kayıtlarla doğrulayın
2. Yetkisiz ve eksik veri cevaplarını test edin
3. Yinelenen gönderimin çift kayıt açmadığını kontrol edin
4. İzleme ve sorumluluk kanalını belirleyin
5. Geri dönüş ve manuel devam prosedürünü belgeleyin

Entegrasyonu kontrollü biçimde yayına hazırlayın

Test ortamında çalışan bağlantı, canlı verinin yetkileri ve hacmiyle aynı davranmayabilir. Örnek kayıtlar; farklı para birimi, özel karakter, yüksek seçenek sayısı ve eski ürün sürümü gibi gerçek çeşitliliği temsil etmelidir.

Canlıya geçişte izleme ekranı, sorumlu kişiler, geri alma koşulu ve ilk gün kontrol listesi hazır olmalıdır. Başarılı cevap oranının yanında eksik alan, eşleşmeyen kod ve manuel müdahale sayısı da izlenmelidir.

1. Test ve canlı erişimlerini ayırın
2. Temsilî veri setiyle uçtan uca prova yapın
3. Yük ve zaman aşımı sınırlarını ölçün
4. Alarm eşikleri ve sorumluları belirleyin
5. Kademeli yayın ve geri alma planı hazırlayın