ERP Entegrasyonunda Doğrudan SQL mi, Resmi API mi? Okuma ve Yazma Ayrımı

ERP entegrasyonu dendiğinde herkes hemen "API kullan" der. Sonra gerçek dünyada proje başlayınca işler değişir: Logo Tiger'daki 200 bin satırlık stok hareketini web servis ile çekmek 40 dakika sürüyor, aynı veri doğrudan SQL'den 8 saniyede geliyor. Ya da e-ticaret platformunuz her gece saat 03:00'te analitik raporları hazırlayacak — her sorgu için API çağrısı yapmak hem yavaş hem maliyetli.

Gerçek şu: okuma ve yazma aynı risk sınıfında değil. ERP veritabanına SELECT yazmakla INSERT atmak arasında uçurum var. Biri performans problemi yaratır, diğeri firma batırır. Bu yazıda hangi durumda hangi yöntemin neden doğru olduğunu anlatacağım.

Üretici firma desteğiyle çalışıyorsanız "sadece API" diyebilirler — çünkü garanti kapsamı dışına çıkmak istemiyorlar. Ama siz bağımsız yazılım ekibiyseniz ve sorumluluğu üstlenebiliyorsanız, hibrit mimari çok daha mantıklı olabilir.

Okuma İşlemlerinde Doğrudan SQL: Yaygın ve Kabul Edilebilir

Neden Raporlama İçin SQL Tercih Ediliyor?

ERP sistemlerinin kendi raporlama araçları genellikle yetersiz kalır. Özellikle:

• Power BI, Tableau, Metabase gibi BI araçları doğrudan veritabanına bağlanmak ister
• Gerçek zamanlı dashboard'lar API gecikmesini kaldıramaz
• Karmaşık JOIN'ler ve aggregate sorgular web servis üzerinden çalıştırılamaz
• Veri ambarı (data warehouse) senaryolarında toplu okuma şart

Tipik bir senaryo: Bir mobilya üreticisi her sabah 08:00'de tüm şubelerin önceki gün satış, tahsilat ve stok devir hızı raporunu yönetim ekibine mail atmak ister. Logo Tiger API'si ile bu rapor 15 dakika sürebilir — sorgular timeout'a düşebilir. Salt-okunur replika üzerinde doğrudan SQL ile aynı rapor 25 saniyede hazır hale gelebilir.

Salt-Okunur (Read-Only) Veritabanı Kopyası

Üretim veritabanına doğrudan bağlanmak yerine:

1. Replikasyon ile salt-okunur kopya oluşturun (SQL Server Always On, PostgreSQL streaming replication)
2. Ağır analitiği bu kopyada çalıştırın — canlı sistemi yavaşlatmaz
3. Veri gecikmesi 5-10 saniye olsa bile raporlama için sorun olmaz
4. Primary veritabanı çökse bile okuma işlemleri devam eder

Bu mimariyi Microsoft ve SAP dahil tüm büyük üreticiler öneriyor.

Ham Kolon Değerleri ve Kod Çözümleme Sorunu

İşte kritik nokta: ERP tablolarında gördüğünüz değerler ham kodlar olabilir.

Örnek: Logo'da STLINE tablosundaki LINETYPE kolonu:

• 0 = Malzeme
• 1 = Hizmet
• 2 = Depozit
• 3 = Masraf
• 4 = Promosyon

Doğrudan SQL çektiğinizde LINETYPE = 0 görürsünüz, "Malzeme" metnini görmezsiniz. ERP'nin kendi ekranında "Malzeme" yazmasının nedeni, uygulamanın kod tablosundan çeviri yapması.

Yani SQL ile okursanız:

• Kod tablolarını siz eşleştirmeli
• ERP güncellemesinde yeni kodlar eklenirse sizin sözlüğünüz eksik kalır
• Çok dilli kurulumda dil çevirimini siz yapmalısınız

Bu kabul edilebilir bir maliyet — çünkü kod eşlemeleri genellikle sabittir ve dokümante edilebilir.

Çok Firmali Kurulumda Filtre Felaketi

En tehlikeli tuzak: ERP'de 5 ayrı şirket tanımlı, siz SQL sorgusunda WHERE LOGICALREF > 0 yazıp geçiyorsunuz. Firma filtresi koymayı unuttuğunuz için tüm firmaların toplamını alıyorsunuz.

Örneğin Netsis'te:

-- YANLIŞ: Tüm firmaların stok toplamı
SELECT SUM(MIKTAR) FROM STOK_HAREKETLERI

-- DOĞRU: Sadece Firma 1
SELECT SUM(MIKTAR) FROM STOK_HAREKETLERI WHERE FIRMANO = 1

Bu hatayı yaptığınızda rapor sessizce yanlış çıkar. Kullanıcı "stok toplamı 10.000 adet" görür, gerçekte kendi firmasında 2.000 adettir. Ay sonunda fiili sayım yapana kadar kimse fark etmez.

API kullandığınızda, oturum açarken zaten bir firmaya bağlanırsınız — bu filtre otomatik gelir.

Yazma İşlemlerinde API Zorunluluğu: Doğrulama ve İlişki Bütünlüğü

Neden Doğrudan INSERT Felakettir?

Bir satış faturası kaydettiğinizde arka planda 10-15 kontrol döner:

1. Cari hesap kontrolü: Müşteri kodu var mı, blokeli mi?
2. Stok bakiye kontrolü: Depo-renk-beden bazında yeterli stok var mı?
3. Fiyat-iskonto doğrulaması: Maliyetin altına satış yapılmış mı?
4. KDV oranı kontrolü: Ürün ve müşteri ülkesine göre doğru oran uygulanmış mı?
5. Zorunlu alan kontrolü: İrsaliye numarası, vade tarihi gibi alanlar dolu mu?
6. Fiş-satır ilişki kontrolü: STFICHE ve STLINE tabloları LOGICALREF üzerinden doğru bağlanmış mı?
7. Sıra numarası üretimi: Yıl sonu sıfırlanmalı mı, hangi seriden devam edilmeli?
8. Muhasebe fişi oluşturma: Satış kaydı muhasebe tarafına yansımalı mı?

ERP'nin resmi API'sine (SOAP web servisi, REST endpoint, ya da stored procedure) veri gönderdiğinizde bu kontrollerin tamamı çalışır. Hata varsa size anında dönüt verir: "Stok yetersiz", "Cari bulunamadı", "KDV oranı hatalı".

Doğrudan INSERT atarsanız: Yukarıdaki hiçbir kontrol çalışmaz. Veri tabloya yazılır, ama:

• Stok ekside gözükür, kimse anlamaz
• KDV matrahı yanlış hesaplanır, vergi beyanında farklılık çıkar
• Muhasebe fişi oluşmaz, ay sonu maliyet çalışmaz
• Fiş-satır ilişkisi kopuksa ERP'de fatura açılmaz, "orphan record" kalır

Sorun aynı gün değil, ay sonunda ortaya çıkar. Mizanda "eksik kayıt" görülünce, tüm entegrasyonu sorgularsınız — ama hangi satırın sorunlu olduğunu bulmak haftalarca sürebilir.

Üreticilerin Resmi Yaklaşımı

Microsoft Dynamics: Dokümantasyonda açıkça yazıyor — "Direct SQL write is not supported. Use OData/SOAP services." Destek almak istiyorsanız, veritabanına manuel müdahale yaptığınız anda garanti kaybedersiniz.

SAP Business One: DI API (Data Interface API) zorunlu. Doğrudan tablo yazımı yaparsanız lisans ihlali sayılabilir.

Logo Tiger / Netsis / Mikro: Stored procedure'lar sunuyorlar (sp_InsertSatFat gibi). Bu procedure'lar içinde tüm doğrulamalar var. SQL Server'a doğrudan INSERT yerine bu SP'leri çağırmanız öneriliyor.

Nebim V3: RESTful API üzerinden JSON gönderimi. Veritabanı şeması dokümante edilmemiş — zaten doğrudan erişim tasarlanmamış.

Bazı küçük ERP'ler "serbest SQL" vermiş gibi gözükür, ama genellikle bu sadece SELECT içindir. Örneğin bir ERP üreticisi veritabanı kullanıcısına db_datareader rolü vermiş ama db_datawriter vermemiştir — siz okuyabilirsiniz ama yazamazsınız.

Örnek Hata Senaryosu: E-Ticaret Entegrasyonu

Şöyle bir durum düşünün: Bir giyim firması Ticimax e-ticaret sitesinden gelen siparişleri Logo Tiger'a aktarıyor. İlk versiyonda geliştirici doğrudan INSERT kullanmış:

INSERT INTO LG_001_01_ORFICHE (FICHENO, DATE_, CLIENTREF, ...)
VALUES ('WEB2024010001', '2024-01-15', 1234, ...)

INSERT INTO LG_001_01_ORFLINE (ORDFICHEREF, STOCKREF, AMOUNT, ...)
VALUES (@@IDENTITY, 5678, 2, ...)

İlk 100 sipariş sorunsuz geçebilir. Sonra:

• Bir üründe stok sıfır olsa bile sipariş yazılır → Tedarik planlama şaşırır
• Kampanyalı ürünlerde iskonto alanı boş kalır → Fiyat yanlış olur
• ORDFICHEREF ilişkisi bazı kayıtlarda NULL kalır → Siparişler "hayalet" olur, ekranda gözükmez

Böyle bir durumda tüm entegrasyonun Logo'nun sp_ORAddOrder stored procedure'üne çevrilmesi gerekir. Hata oranı önemli ölçüde düşer — kalan hatalar da genellikle veri kalitesi sorunlarıdır (müşteri adres bilgisi eksik gibi).

Hibrit Mimari: Okuma SQL, Yazma API

Pratik Öneri

Gerçek dünyada en sağlıklı yaklaşım:

OKUMA katmanı:

1. Salt-okunur replika veritabanı
2. Doğrudan SQL sorguları (ORM ya da raw query)
3. Veri ambarına ETL (Extract-Transform-Load) ile toplu aktarım
4. BI araçları doğrudan bağlantı

YAZMA katmanı:

1. Resmi API / web servisi / stored procedure
2. Ara katman (message queue: RabbitMQ, Azure Service Bus)
3. İdempotent yazma mantığı (aynı istek 2 kez gelirse çift kayıt olmasın)
4. Detaylı hata kaydı ve retry mekanizması

Ara Katman ve Kuyruk Mimarisi

E-ticaret sitesinden ERP'ye sipariş aktarımı örneği:

1. Sipariş geldiğinde: Web hook bir mesaj kuyruğuna yazar (RabbitMQ)
2. Kuyruk işleyici (consumer): Mesajı alır, ERP API'sine gönderir
3. API hatası dönerse: Mesaj kuyruğa geri bırakılır, 5 dakika sonra tekrar denenir
4. 3 denemede başarısız olursa: "Dead letter queue"ya düşer, teknik ekip uyarı alır
5. Başarılı olursa: Mesaj kuyrudan silinir, e-ticaret sitesine "ERP'de oluşturuldu" işareti gönderilir

Bu mimari ile:

• ERP geçici çökse bile siparişler kaybolmaz
• Aynı sipariş 2 kez gelse bile ERP'de çift kayıt olmaz (idempotency key kontrolü)
• Hata logları düzenli saklanır, analiz edilebilir

İdempotent Yazma Nedir?

Aynı işlem birden fazla kez yapılsa bile sonuç aynı kalmalı.

Örnek: OrderID = WEB123 olan sipariş ERP'ye yazılırken, önce kontrol et:

SELECT COUNT(*) FROM ORDERS WHERE EXTERNAL_REF = 'WEB123'

Eğer zaten varsa, tekrar INSERT atma. API'ye gönderirken de benzer mantık — üretici genellikle ExternalReference alanı sunar, siz buraya e-ticaret sipariş numarasını yazarsınız. ERP ikinci seferde aynı referansı görünce "zaten var" der.

Performans ve Maliyet Dengesi

API Çağrısı Limitleri

Bazı ERP üreticileri API kullanımına kota koyar:

• SAP Business One DI API: Eşzamanlı bağlantı sayısı lisansa bağlı (Named User bazında)
• Cloud ERP'ler (Netsuite, Odoo SaaS): Saatlik/günlük API call limiti olabilir
• Self-hosted sistemler: Genellikle limit yok, ama sunucu kaynak tüketimine dikkat

Doğrudan SQL bu limitlerden etkilenmez — veritabanı sunucusunun izin verdiği kadar sorgu çalıştırabilirsiniz.

Örnek Performans Karşılaştırması

Senaryo: 50.000 satırlık stok hareketini çekme

Yöntem	Süre	Not
Logo Tiger Web Servisi	38 dakika	Sayfalama 100'lük
Logo SQL (canlı DB)	12 saniye	Production yavaşladı
Logo SQL (read replica)	8 saniye	Canlıya etki yok
Mikro SOAP API	22 dakika	Timeout ayarı gerekti
Netsis Stored Procedure	15 saniye	SP içinde zaten SQL

Görüldüğü gibi okuma için SQL çok daha hızlı. Ama yazma için SP ya da API kullanmak şart.

Güvenlik ve Yetkilendirme

SQL Kullanıcısı İzinleri

Doğrudan SQL erişimi verirseniz:

1. Ayrı bir SQL kullanıcısı oluşturun (sa hesabını kullanmayın)
2. Sadece gerekli tablolara SELECT yetkisi verin
3. INSERT/UPDATE/DELETE yetkisi vermeyin
4. View'lar oluşturup direkt tabloya erişimi kapatın (özellikle hassas kolonlar için)
5. IP kısıtlaması koyun (sadece entegrasyon sunucusundan erişim)

Örnek SQL Server komutu:

CREATE USER etl_readonly WITH PASSWORD = 'GüçlüŞifre123!';
GRANT SELECT ON dbo.STLINE TO etl_readonly;
GRANT SELECT ON dbo.CARI TO etl_readonly;
DENY INSERT, UPDATE, DELETE ON SCHEMA::dbo TO etl_readonly;

API Kullanıcısı Güvenliği

API tarafında:

1. Her entegrasyon için ayrı kullanıcı (e-ticaret, CRM, BI ayrı login)
2. Role-based izinler: Sadece sipariş yazabilir, fatura silemez gibi
3. Token expiration: Oturum 24 saat sonra kapanmalı
4. Rate limiting: Dakikada 100 istek gibi limitler

Üreticilerin çoğu bunu API anahtarı (API key) ile yönetiyor.

Sık Sorulan Sorular

ERP üreticisi "garanti için sadece API kullanın" diyor, yine de SQL kullanabilir miyiz?

Kullanabilirsiniz ama riski üstlenirsiniz. Salt-okunur (SELECT) sorgular genellikle sorun çıkarmaz çünkü veriyi değiştirmiyorsunuz. Ama bir sorun yaşadığınızda üretici desteği "siz veritabanına doğrudan bağlanmışsınız, garanti dışı" diyebilir. Bizim yaklaşımımız: Okuma için SQL, yazma için kesinlikle API. Bu hibrit model hem performanslı hem güvenli. Üreticiye de "veritabanına yazma yapmıyoruz, sadece okuyoruz" diyerek durumu açıklayabilirsiniz.

Hangi ERP'ler doğrudan SQL erişimine izin veriyor?

Çoğu self-hosted (kendi sunucunuzda kurulu) ERP'de veritabanı erişimi teknik olarak mümkün — çünkü SQL Server / PostgreSQL sizin kontrolünüzde. Ama izin vermek başka, desteklemek başka. Logo, Mikro, Netsis, Zirve gibi yerli ERP'lerde veritabanı şeması dokümante edilmiş, stored procedure'lar sunuluyor. Microsoft Dynamics, SAP, Oracle Netsuite gibi global ürünler ise "doğrudan DB erişimi desteklenmez" diyor. Cloud ERP'lerde (SaaS) zaten veritabanına erişiminiz yok, sadece API var. Keşif görüşmesinde kullandığınız ERP'ye özel mimariyi tartışabiliriz.

Doğrudan SQL kullanırsak ERP güncellemesi geldiğinde ne olur?

ERP üreticisi versiyon güncellemesi yayınladığında tablo yapısı değişebilir (kolon eklenebilir, kaldırılabilir, tipinde değişiklik olabilir). API kullanıyorsanız, üretici genellikle geriye dönük uyumluluk sağlar (backward compatibility). Ama SQL sorgularınız doğrudan kolon adına bağlıysa, güncelleme sonrası çalışmayabilir. Çözüm: View'lar kullanın. Siz vw_StokRaporu diye bir view oluşturun, entegrasyon buna bağlansın. ERP güncellemesi geldiğinde sadece view'ı güncellemeniz yeterli, entegrasyon kodunu değiştirmezsiniz. Ayrıca test ortamında önce güncellemeyi yapıp SQL sorgularınızı test etmek şart.

Performans için SQL, güvenlik için API dediniz — ikisini aynı anda nasıl kullanırız?

Tam olarak hibrit mimari önerimiz bu zaten. Günlük işleyişte iki kanal açarsınız:

Kanal 1 — Okuma (SQL):
BI tool, raporlar, analitiği salt-okunur replika üzerinden doğrudan SQL ile çalıştırırsınız. Hızlı ve canlı sistemi yavaşlatmaz.

Kanal 2 — Yazma (API):
E-ticaret siparişleri, CRM'den gelen fırsatlar, saha satış uygulamasından girilen siparişler ERP'nin resmi API'sine gönderilir. Kuyruk mimarisi ile hata toleransı sağlarsınız.

Böylece hem hız hem güvenlik hem de garanti kapsamında kalma avantajını birleştirirsiniz. Mimari karmaşıklaşır ama orta-büyük ölçekli işletmelerde bu kaçınılmaz.

Entegrasyon projesinin maliyeti ne kadar, süre ne kadar?

Değişkenlik çok fazla — hangi ERP, kaç modül, kaç yön (tek yön mü çift yön mü), veri hacmi, temizlik ihtiyacı, özel doğrulama kuralları gibi faktörlere bağlı. Keşif görüşmesinde sisteminizi inceleyip sabit fiyat teklif ediyoruz, sözleşmede yazılı tutar dışında ek maliyet çıkmaz. Süre genellikle 3-8 hafta arası (basit e-ticaret entegrasyonu 3 hafta, karmaşık çok modüllü ERP-CRM-BI üçgeni 8 hafta sürebilir). İlk 15 gün ücretsiz hata düzeltme garantimiz var — canlıya aldıktan sonra çıkan bug'ları ek ücret almadan çözüyoruz.

Çok firmali yapıda veri karışmasını nasıl önleriz?

Bu gerçekten kritik. ERP'de birden fazla şirket/şube tanımlıysa:

1. SQL sorgularında WHERE FIRMANO = X filtresini asla atlamayın. Şablon sorguları hazırlayın, parametre olarak firma kodunu geçirin.
2. View'larda otomatik filtre ekleyin — mesela her firma için ayrı view: vw_Stok_Firma1, vw_Stok_Firma2.
3. API kullanıyorsanız login sırasında firma seçimi yapılır, oturum zaten bir firmaya kilitli olur.
4. Test senaryolarında mutlaka "yanlış firma filtresi" durumunu simüle edin. Firma 1 kullanıcısı Firma 2 verisini görebiliyor mu diye kontrol edin.
5. Row-level security (RLS) özelliğini kullanın (SQL Server 2016+, PostgreSQL RLS) — veritabanı seviyesinde kullanıcıya göre otomatik filtre.

Tipik bir senaryo: Holding yapısındaki bir firma 12 ayrı şirketin konsolide raporunu hazırlamak ister — her şirket kendi datasını görsün ama yönetim kurulu hepsini topluca görsün. RLS ile çözülebilir, kod tarafında firma kontrolü yazmaya gerek kalmaz.

Sonuç ve Öneriler

ERP entegrasyonunda "doğrudan SQL mi, API mi?" sorusunun cevabı hem hem olmalı. Okuma ve yazma işlemlerinin risk profilleri birbirinden çok farklı:

Okuma işlemleri için doğrudan SQL makul, hatta bazen zorunlu — özellikle BI, raporlama, veri ambarı senaryolarında. Salt-okunur replika kullanarak canlı sistemi etkilemeden yüksek performans alabilirsiniz. Kod çözümleme ve firma filtresi gibi tuzaklara dikkat ettiğiniz sürece güvenli.

Yazma işlemleri için mutlaka resmi API, web servisi ya da stored procedure kullanın. Doğrudan INSERT/UPDATE atmak kısa vadede işe yarar gibi görünür, ama ay sonunda mizan tutmaz, muhasebe fişleri eksik çıkar, stok sayımı uymaz — o zaman geriye dönüp hatayı bulmak çok zor olur.

Microsoft ve SAP gibi üreticiler bunu zaten politika olarak koymuş: veritabanına yazma desteği yok. Logo, Netsis, Mikro gibi yerli ERP'lerde teknik olarak mümkün ama stored procedure'ları kullanmak çok daha güvenli.

Hibrit mimari kurun: okuma katmanında SQL, yazma katmanında API. Araya message queue ekleyerek hata toleransı sağlayın. İdempotent yazma ile çift kayıt sorununu önleyin. Detaylı loglama ile sorunları erken tespit edin.

D'Cloud Software ile Entegrasyonunuzu Planlayın

Her ERP'nin (Logo, Netsis, Mikro, SAP Business One, Microsoft Dynamics, Netsuite) kendine özgü mimarisi var — hangisini kullanıyorsanız, en uygun okuma-yazma stratejisini birlikte tasarlayalım.

Ücretsiz online keşif görüşmesinde:

• Mevcut ERP altyapınızı inceliyoruz
• Okuma ve yazma ihtiyaçlarınızı haritalıyoruz
• Hibrit mimari önerimizi çiziyoruz
• Sabit fiyat ve süre taahhüdü veriyoruz

İlk 15 gün ücretsiz hata düzeltme garantisiyle, entegrasyonunuz canlıya alındıktan sonra çıkabilecek sorunları ek ücret almadan çözüyoruz. Sözleşmede yazan tutarın dışında maliyet çıkmaz.

WhatsApp hattımızdan ya da web sitemizden iletişime geçin — entegrasyonunuzu doğru temelle inşa edelim.

---

Yazar: Doğuhan Bulut — D'Cloud Software İçerik Ekibi