Büyüyen her işletmede aynı sessiz iş ortaya çıkar: birinin bir ekrandaki veriyi başka bir ekrana yazması. Pazaryerine düşen siparişin muhasebe programına girilmesi, depoda sayılan stoğun panele işlenmesi, kargo takip numarasının müşteriye tek tek yazılması. Bu işin adı genelde konmaz, bir kişinin günlük rutinine yedirilir ve maliyeti fark edilmez. Fark edildiği an ise genelde bir hatanın ortaya çıktığı andır: stok yanlış kaldığı için iki kanaldan satılan tek ürün, ya da faturası kesilmemiş sipariş.
Özel entegrasyon çözümleri tam olarak bu işi devralır. Aşağıda entegrasyon katmanının ne yaptığını, hangi bağlantı türlerinin nasıl kurulduğunu, projenin gerçekte nerede zorlaştığını ve maliyeti neyin belirlediğini anlatıyoruz.
Özel entegrasyon çözümleri ne yapar, ne yapmaz
Entegrasyon katmanı, sistemlerin arasında duran ve veriyi bir taraftan alıp diğerinin anlayacağı biçime çevirerek ileten bir yazılımdır. Dört iş yapar: okur (kaynaktan veriyi çeker veya olay bildirimini karşılar), çevirir (alan adlarını, birimleri, kategori ve durum kodlarını hedef sistemin diline dönüştürür), yazar (hedefe kaydeder ve sonucunu doğrular), kaydeder (ne zaman ne aktardığını, neyin başarısız olduğunu ve neden olduğunu tutar).
Yapmadığı şeyi de söylemek gerekir: entegrasyon, kaynaktaki bozuk veriyi düzeltmez. Stok kodları tutarsızsa, aynı ürün iki farklı kartla açılmışsa veya kategori yapısı iki sistemde bambaşkaysa entegrasyon bu karışıklığı hızlandırarak yayar. Bu yüzden her projenin ilk adımı kod yazmak değil, veriyi hizaya sokmaktır.
API entegrasyonu: bağlantı biçimleri ve pratikte karşılaşılanlar
API entegrasyonu denince akla tek bir teknoloji gelir ama sahada birbirinden çok farklı beş yapıyla karşılaşılır. Hangi yapının kullanılacağını biz değil, bağlanılacak sistem belirler.
| Bağlantı biçimi | Nerede karşılaşılır | Dikkat edilen nokta |
|---|---|---|
| REST | Modern e-ticaret ve pazaryeri servisleri | Hız limiti, sayfalama, kimlik doğrulama süresi |
| SOAP | Kurumsal yazılımlar ve eski altyapılar | Alan sırası ve tip katılığı; hata mesajları çoğu zaman açıklayıcı değildir |
| GraphQL | Yeni nesil platform arayüzleri | Sorgu maliyeti ve kota hesabı |
| Dosya aktarımı (CSV, XML) | ERP ve tedarikçi akışları | Zamanlama, kısmi dosya ve karakter kodlaması |
| Webhook | Olay bildirimi gönderen servisler | Aynı bildirimin tekrar gelmesi ve sıra karışması |
Bu tablodaki uyarılar teorik değil. Somut bir örnek verelim: bazı SOAP servislerinde istek gövdesindeki alanların belirli bir sırada gönderilmesi zorunludur; sıra bozulduğunda servis hata döndürmez, gönderdiğiniz filtreyi sessizce yok sayar ve size tüm kayıtları verir. Böyle bir davranışı dokümandan öğrenemezsiniz; yalnızca beklenenden fazla kayıt döndüğünü fark edip araştırırsanız bulursunuz. Entegrasyon projelerinde asıl deneyim, bu tür sessiz davranışları önceden tahmin edebilmektir.
Benzer şekilde hız limitleri de projeyi şekillendirir. Dakikada sınırlı sayıda istek kabul eden bir servise on bin ürünü göndermek, kod yazmaktan çok kuyruk ve zamanlama tasarlamak demektir. Bu yüzden "kaç sistem bağlanacak" sorusu, "kaç kayıt aktarılacak" sorusundan daha az belirleyicidir.
ERP entegrasyonu: muhasebe ve stok tarafı
ERP entegrasyonunda teknik zorluk, iş kararının yanında ikinci sıradadır. Asıl soru şudur: hangi verinin doğrusu hangi sistemde? Bu soruya net cevap verilmeden kurulan her entegrasyon, iki sistemin birbirinin verisini sırayla ezdiği bir salınım üretir ve kimse hangisinin doğru olduğunu bilemez.
| Veri | Genelde doğruluk kaynağı | Akış yönü | Not |
|---|---|---|---|
| Ürün kartı ve stok kodu | ERP | ERP'den e-ticarete | Yeni ürün açma yetkisi tek yerde olmalı |
| Stok adedi | ERP veya depo sistemi | ERP'den tüm kanallara | Rezerve edilen adedin nasıl sayılacağı baştan kararlaştırılır |
| Satış fiyatı | Değişir | Çift yönlü olabilir | Kanal bazlı fiyat varsa kural motoru gerekir |
| Sipariş | E-ticaret ve pazaryeri | Kanaldan ERP'ye | İptal ve iade akışı da taşınmalı |
| Cari ve fatura | ERP | ERP'de oluşur | E-fatura sağlayıcısıyla ilişki ayrı kurulur |
| Müşteri bilgisi | E-ticaret | Kanaldan ERP'ye | Kişisel veri kapsamı, saklama süresi tanımlanmalı |
Bu tablo bir öneridir, kural değil. Bazı işletmelerde fiyatın doğruluk kaynağı e-ticaret tarafıdır, çünkü kampanya yönetimi orada yapılır. Önemli olan hangisini seçtiğiniz değil, seçtiğinizin yazılı olması ve entegrasyonun ona göre kurulmasıdır. Logo, Mikro, Netsis, Nebim ve SAP tarafında çalışırken ayrıca lisansınızın hangi arayüze izin verdiğini de kontrol ederiz; bazı modüller ek lisans gerektirir ve bu, projenin bütçesini doğrudan etkiler.
Pazaryeri entegrasyonu: stok, fiyat ve sipariş üçgeni
Pazaryeri entegrasyonu üç akıştan oluşur ve üçünün riski birbirinden farklıdır. Stok gönderimi geciktiğinde aşırı satış olur; bu, iptal oranı ve mağaza puanı üzerinden doğrudan cezaya döner. Fiyat gönderimi yanlış olduğunda zararına satış olur ve genellikle geri alınamaz. Sipariş çekme aksadığında operasyon durur ama en kolay fark edilen budur.
Bu yüzden sıralama önemlidir: önce stok, sonra sipariş, en son fiyat otomasyonu devreye alınır. Fiyatın otomatik gönderimini açmadan önce bir güvenlik kuralı tanımlanması önerilir; örneğin belirli bir orandan fazla düşen fiyat gönderilmeden önce onaya düşsün. Tek bir hatalı toplu güncelleme, entegrasyonun getirdiği tüm faydayı bir günde silebilir.
Pazaryeri tarafında satış sonrası da bir entegrasyon konusudur. Ürün yorumlarının ve müşteri sorularının kendi sitenize aktarılması, sorulara üretilen yanıtların tek yerden yönetilmesi ayrı bir katmandır; bunu oto yanıt tarafında ve modül sayfalarında ayrıca anlattık.
Kargo ve teslimat tarafı
Kargo entegrasyonu görünürde basit bir işlemdir: gönderi oluştur, takip numarası al, müşteriye ilet. Zorluğu ayrıntılardadır. Her firmanın desi ve ağırlık hesabı farklıdır; şubeye teslim, adrese teslim ve pazaryerinin anlaşmalı gönderi kodu farklı akışlardır; iade gönderisinin nasıl oluşturulacağı ayrı bir konudur. Bir de sessiz bir tuzak vardır: gönderi oluşturulduğu hâlde etiketin basılmaması veya numaranın müşteriye ulaşmaması, sipariş kaybolmadığı için fark edilmez, yalnızca müşteri sorduğunda ortaya çıkar.
Bu yüzden kargo akışında da geri bildirim döngüsü kurulur: gönderi durumunun panele yazılması, teslim edilmeyen gönderilerin listelenmesi ve müşteriye giden bildirimin kaydının tutulması. Bildirim tarafını hazır çalışan bir yapıyla kurmak isterseniz kargo bildirimi modülü bu işi kurulum gerektirmeden üstlenir.
Sistem entegrasyonu projesinde asıl iş: eşleştirme ve çakışma kuralları
Bir sistem entegrasyonu projesinin başarısı, bağlantının kurulmasıyla değil, aşağıdaki altı kararın doğru verilmesiyle belirlenir. Bu kararlar teklif aşamasında konuşulmazsa, proje ortasında kapsam olarak geri gelir.
- Eşleştirme anahtarı. İki sistemdeki aynı kaydın hangi alanla eşleşeceği: stok kodu, barkod veya harici kimlik. Yanlış anahtar seçilirse entegrasyon çalışır görünür ama yanlış kaydı günceller.
- Doğruluk kaynağı. Aynı alan iki sistemde birden değiştiğinde hangisi kazanır. Cevabı "duruma göre" olan her alan için ayrıca kural yazılması gerekir.
- Tekrar çalıştırılabilirlik. Aynı mesaj iki kez geldiğinde iki kayıt değil tek kayıt oluşmalıdır. Webhook kullanan her akışta bu şarttır, çünkü servisler bildirimi tekrar gönderir.
- Kısmi başarısızlık. Yüz kalemlik bir aktarımın doksanı geçip onu düştüğünde ne olacak: tamamı geri mi alınacak, yoksa kalan on kalem kuyruğa mı girecek. İkisi de geçerli, ama seçilmiş olmalı.
- Hız limiti ve kuyruk. Karşı sistemin kabul ettiği istek hızına uymak, aktarımı sıraya almak ve yoğun saatlerde yayarak göndermek.
- Geri alma senaryosu. Hatalı bir toplu güncelleme yapıldığında önceki değerlere dönmenin yolu. Bunun için önceki değerlerin kaydediliyor olması gerekir.
Bu altı madde, entegrasyon tekliflerini karşılaştırırken kullanabileceğiniz bir kontrol listesidir. Teklifte bunların karşılığı yoksa, sorun çıkmayacağı anlamına gelmez; sorun çıktığında ne olacağının konuşulmamış olduğu anlamına gelir.
WhatsApp ve Meta tarafı
Bildirimlerin WhatsApp üzerinden gitmesi görünürde bir mesajlaşma işidir, aslında tipik bir entegrasyondur: tetikleyen olay bir sistemde (sipariş durumu değişti, kargo hareket etti, stok geldi), mesajı gönderen servis bambaşka bir yerdedir. Arada da onaylanmış bir şablon, doğrulanmış bir numara ve izin kaydı vardır.
Meta Business ve Tech Partner olduğumuz için WhatsApp Business tarafındaki hesap kurulumunu, numara doğrulamasını ve mesaj şablonu onaylarını biz yürütüyoruz. Akışların nasıl kurgulandığını WhatsApp otomasyon rehberinde ayrıntılı anlattık. Hazır çalışan senaryolar için sepet hatırlatıcı gibi modüller kurulum gerektirmeden devreye alınabilir; sipariş verisine bağlı özel bir akış gerekiyorsa entegrasyon kapsamında yazılır.
Bir uyarı: ticari içerikli mesaj gönderiminde izin alma ve İleti Yönetim Sistemi tarafındaki yükümlülük gönderimi yapan tarafa aittir. Teknik kurulum bu sorumluluğu devretmez; kurgu yapılırken izin kaydının nerede tutulduğu ve gönderim öncesi ret kontrolünün nasıl işlediği de tasarlanmalıdır.
İzleme, kayıt ve hata yönetimi
Entegrasyonun en tehlikeli hâli hata vermesi değil, sessizce durmasıdır. Hata veren akış fark edilir ve düzeltilir; duran akış kimseye görünmez ve stok günlerce yanlış kalır. Bu yüzden kurduğumuz her akışta üç katman bulunur.
- Kayıt. Her aktarımın ne zaman çalıştığı, kaç kayıt işlediği, hangi kaydın neden düştüğü tutulur. Sorun çıktığında "ne oldu" sorusunun cevabı tahmin değil, kayıt olmalıdır.
- Yeniden deneme. Geçici hatalar (ağ kesintisi, hız limiti, karşı sistemin bakımı) artan aralıklarla yeniden denenir. Kalıcı hatalar ise kuyrukta bekletilmez, uyarıya dönüşür.
- Uyarı ve canlılık kontrolü. Hata eşiği aşıldığında bildirim gider. Ayrıca akışın belirli bir süredir hiç çalışmadığını da kontrol eden ayrı bir denetim bulunur; sessiz durmayı yakalayan tek mekanizma budur.
Fiyatı belirleyen kalemler
Entegrasyon projelerinde rakam, kapsam netleşmeden verilemez. Bütçeyi oynatan kalemler şunlardır:
- Bağlanacak sistem sayısı ve her birinin olgunluğu. Dokümanı iyi, test ortamı olan bir servis ile dokümanı eksik ve test ortamı olmayan bir servis aynı iş değildir.
- Akış yönü. Tek yönlü aktarım ile çift yönlü senkron arasında büyük fark vardır; çift yönlüde çakışma kuralları da yazılır.
- Veri hacmi ve tazelik ihtiyacı. Günde bir kez çalışan bir aktarım ile anlık senkron farklı mimariler gerektirir.
- Dönüşüm karmaşıklığı. Alan adlarının birebir eşleştiği bir aktarım ile kategori ağacının, birim ve KDV yapısının dönüştürüldüğü bir aktarım.
- Mevcut verinin durumu. Temizlik ve hizalama gerekiyorsa bu ayrı bir iş kalemidir ve genelde küçümsenir.
- Sürekli hizmet. Karşı sistemlerin arayüzleri değişir; bakım ve müdahale süresi taahhüdü ayrı fiyatlanır.
Sık yapılan hatalar
- Doğruluk kaynağını belirlemeden başlamak. Entegrasyon projelerinde en pahalı hata budur ve neredeyse her zaman sonradan yeniden yazmayı gerektirir.
- Veriyi hizalamadan bağlamak. Aynı ürünün iki kartla açılmış olması, entegrasyon kurulunca sorun olmaktan çıkmaz; hızlanarak yayılır.
- Her şeyi ilk gün açmak. Kademeli geçiş, hata kaynağını bulmayı kolaylaştırır ve riski böler.
- Fiyat otomasyonunu kontrolsüz açmak. Belirli bir eşiğin üzerindeki değişimin onaya düşmesi, tek satırlık bir kuralla büyük zararı önler.
- Elle müdahaleyi yasaklamamak. Entegrasyon kurulduktan sonra karşı panelden elle yapılan değişiklikler geri alınır; ekip bunu bilmezse sisteme güven kaybolur.
- İzlemeyi sonraya bırakmak. "Önce çalışsın, izlemeyi sonra ekleriz" denilen projelerde izleme genelde ilk büyük hatadan sonra eklenir.
Entegrasyon işi, altyapı değiştirmenin alternatifi olabilir. Mevcut e-ticaret sisteminizde kalıp eksik parçaları bağlamak çoğu zaman en akılcı yoldur; her şeyi tek panelde toplamak istiyorsanız e-ticaret altyapısı tarafına, ihtiyacınız bir bağlantıdan çok kendi iş akışınıza özel bir uygulamaysa kişiye özel yazılım tarafına bakmanız daha doğru olur. Hangisinin size uyduğunu ilk görüşmede birlikte çıkarıyoruz; sistem listenizi ve bugün elle yapılan işleri paylaşmanız yeterli.