Fratres

Dijital Ürün ve Mühendislik

API Entegrasyonları

ERP, CRM, ödeme, e-Fatura ve kargo sistemlerinizi, hatadan toparlanabilen ve bir şey ters gittiğinde size haber veren bağlantılarla birleştiriyoruz.

Problem

Sistemlerimiz birbirine bağlı görünüyor ama rakamlar tutmuyor ve arızaları genellikle müşteriden öğreniyoruz.

Entegrasyonların neredeyse hepsi ilk gün çalışır. Sorun sonradan çıkar: karşı sistem birkaç dakika kapanır, token'ın süresi dolar, hız limitine takılırsınız ya da bir alanın biçimi haber verilmeden değişir. Yeniden deneme ve izleme yoksa kayıt sessizce kaybolur.

En pahalı yanılgı, entegrasyonu veri taşıma işi sanmaktır. Asıl karar sahipliktir: müşteri adresinin, stoğun, fiyatın ana kaydı hangi sistemdedir? Bu yazılmazsa iki sistem birbirinin üzerine yazar durur.

Noktadan noktaya bağlantılar da birikir. Bir süre sonra kimse tüm resmi çizemez, tek sistemi değiştirmek bile tehlikeli görünür.

Bunu yaşıyorsanız

  • Biri her hafta iki sistemi elle eşitliyor.
  • Aynı sipariş veya fatura zaman zaman iki kez oluşuyor.
  • Hangi sistemin hangisiyle konuştuğunu gösteren güncel şema yok.
  • Entegrasyonu yazan kişi ayrıldı, koda kimse dokunmaya cesaret edemiyor.

Nasıl çalışıyoruz

  1. Sistem ve sahiplik haritası

    Mevcut bağlantıları çiziyor, her veri alanı için ana kayıt sistemini ve akış yönünü belirliyoruz.

  2. API sözleşmesi

    Uçları, hata kodlarını, sayfalamayı, hız limitlerini ve sürümlemeyi OpenAPI ile yazıyor, kod başlamadan iki tarafın onayını alıyoruz.

  3. Hataya dayanıklı tasarım

    Yazma isteklerinde idempotency anahtarı, jitter'lı exponential backoff ve imzalı webhook kullanıyoruz. Denemeleri tükenen mesajlar incelenip yeniden işlenmek üzere dead-letter kuyruğuna düşer.

  4. Mutabakat, izleme ve koruma

    Zamanlanmış işler iki sistemi karşılaştırıp farkları raporlar. Correlation ID istekleri izler, hata oranı ve kuyruk derinliği için alarm kurulur. API anahtarları kasada tutulup düzenli yenilenir, kişisel veri KVKK gereği loglarda maskelenir.

Ne teslim ederiz

  • Sistem haritası ve ana kayıt kararları
  • OpenAPI sözleşmeleri
  • Entegrasyon servisleri ve webhook alıcıları
  • Yeniden işleme aracı olan dead-letter kuyruğu
  • Mutabakat işleri ve fark raporu
  • Alarm kuralları ve arıza runbook'ları

Nasıl ölçeriz

  • Dead-letter kuyruğu hacmi: verinin nerede takıldığını gösterir.
  • Arızayı fark etme süresi: sorunu müşteriden önce görüp görmediğinizi ölçer.
  • Mutabakat farkları: sistemler arası tutarlılığın somut kanıtıdır.

Bayi portalı olan bir toptancı

Örnek senaryo: Bir toptan dağıtım firması bayi portalındaki siparişleri ERP'ye gece dosyasıyla aktarıyor, reddedilen satırları sabah elle düzeltiyor. Akış kuyruk tabanlı API entegrasyonuna taşınır. ERP bakımdayken siparişler bekler ve sırayla işlenir, eşleşmeyen kayıtlar sorumlusuna listelenir.

Sık sorulanlar

Karşı sistemin API'si yoksa ne yapılır?

Genellikle yine bir yol vardır: veritabanı görünümü, SFTP ile dosya alışverişi veya üreticinin servisi. Bunu bir adaptörün arkasına alıyoruz; gerçek API geldiğinde diğer sistemlere dokunmak gerekmez.

iPaaS aracı mı, özel kod mu?

Make, Zapier veya n8n basit ve düşük hacimli akışları iyi taşır. Para hareketi, yüksek hacim veya katı sıralama varsa yeniden deneme ve mutabakat üzerinde doğrudan denetim gerekir, özel servis burada kendini amorti eder.

Yayından sonra bakımı kim yapar?

Bunu canlıya çıkmadan kararlaştırın. Runbook, alarmlar ve yeniden işleme aracıyla ekibiniz sık arızaları kendisi çözebilir. Karşı sistemdeki sürüm değişiklikleri ise planlı bakım ister.

Birlikte çalışmadan önce, birlikte düşünelim.

Görüşme talepleri kurucu tarafından yanıtlanır.