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: yüz binlerce satırlık stok hareketini web servisten sayfa sayfa çekmek uzun sürer, aynı veri doğrudan SQL ile çok daha kısa sürede gelir. Ya da raporlarınız her gece toplu olarak hazırlanacaktır ve her sorgu için ayrı çağrı yapmak hem yavaş hem maliyetlidir.

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 en kötü ihtimalle sistemi yavaşlatır, diğeri veriyi bozar. Bu yazı, hangi durumda hangi yöntemin neden doğru olduğunu üreticilerin kendi dokümanlarına dayanarak anlatıyor.

Üreticiler yazma için resmi arayüzü şart koşar. Okuma tarafında ise durum üründen ürüne değişir: bazı üreticiler doğrudan okumayı kendi dokümanında anlatır, bazıları desteklemez. Çoğu projede en mantıklı sonuç hibrit bir mimaridir.

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. Bu raporu web servisten kayıt kayıt toplamak uzun sürer ve zaman aşımına düşebilir. Salt-okunur kopya üzerinde doğrudan SQL ile aynı rapor çok daha kısa sürede hazırlanır.

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

Ağır sorguları canlı sistemden ayırmak, veritabanı yönetiminde yaygın bir uygulamadır.

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: Stok fişi satırlarında satır türü bir kod olarak saklanır. Program ekranında "Malzeme" ya da "Hizmet" yazar, tabloda ise bir sayı durur. Hangi sayının neye karşılık geldiği ürüne ve sürüme göre değişir; doğru karşılıklar üreticinin dokümanından alınır.

Doğrudan SQL ile okuduğunuzda metni değil kodu görürsünüz. Bazı üreticiler bu kodları çözmek için hazır fonksiyonlar sunar. Mikro'da stok cinsi, döviz sembolü ve cari hareket tipi gibi alanlar için çözümleme fonksiyonları vardır.

Yani SQL ile okursanız:

• Kod karşılıklarını siz eşleştirirsiniz; üretici çözümleme fonksiyonu sunuyorsa onu kullanın
• 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 maliyettir, yeter ki eşlemeler tahminle değil dokümandan yazılsın.

Ç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 Mikro'da firma ve şube ayrımı kolon bazlıdır:

-- YANLIŞ: tüm firmaların hareketleri sayılır
SELECT COUNT(*) FROM STOK_HAREKETLERI

-- DOĞRU: yalnızca 1 numaralı firma
SELECT COUNT(*) FROM STOK_HAREKETLERI WHERE sth_firmano = 1

Netsis'te aynı ayrım SUBE_KODU ve ISLETME_KODU kolonlarıyla yapılır. Logo Tiger'da ise firma ve dönem numarası tablo adının içindedir; orada risk filtreyi unutmak değil, yanlış tabloya bağlanmaktır.

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.

Resmi arayüzlerde firma bilgisi çoğunlukla oturum açarken ya da istekle birlikte verilir; bu yüzden aynı hata orada daha zor yapılır.

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 arayüzüne (ürüne göre COM nesnesi, REST servisi ya da web servisi) 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 365 Business Central: Microsoft, SQL Server nesneleriyle doğrudan entegre olmanın mümkün olduğunu ama tavsiye edilmediğini, hatta desteklenmediğini yazıyor. Gerekçesi somut: veritabanına eklenen tetikleyici ya da saklı yordamlar yükseltmeyi ve uzantı senkronizasyonunu bozabilir. Önerilen yol API v2.0'dır.

SAP Business One: Resmi arayüzler Service Layer ve DI API'dir. Sistem tablolarına doğrudan yazmak üretici tarafından desteklenmez. Service Layer üzerinden gönderilen SQL sorgusu salt okunurdur.

Logo Tiger: Resmi arayüzler Logo Objects ve, destekleyen ürünlerde, Logo REST Servis'tir. Kayıt bu yoldan geçtiğinde Logo'nun kendi kontrolleri çalışır.

Netsis: Resmi arayüz NetOpenX'tir. Amacı, kaydı iş mantığını bozmadan sisteme almaktır.

Mikro: Resmi arayüz Mikro Desktop API'dir. Üretici, API içindeki serbest SQL ucunu yalnızca SELECT için belgeliyor; yazma tipli uç noktalara bağlı.

Nebim V3: Geliştirici dokümantasyonu herkese açık değil. Hangi arayüzün kullanılacağı kurulumda ve yetkili bayi kanalında netleşir.

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 yazma tarafının Logo Objects ya da REST Servis üzerine taşınması gerekir. Geriye kalan hatalar çoğunlukla veri kalitesiyle ilgilidir: eksik adres bilgisi ya da tanımsız stok kodu 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. Ürünün resmi arayüzü
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: WEB123 numaralı sipariş ERP'ye gönderilmeden önce, entegrasyonun kendi eşleme tablosunda kontrol edilir:

-- Entegrasyonun kendi tablosu; ERP tablosu değil
SELECT COUNT(*) FROM AKTARIM_KAYDI WHERE KAYNAK_NO = 'WEB123'

Kayıt zaten varsa sipariş yeniden gönderilmez. ERP'nin döndürdüğü kayıt anahtarı da aynı tabloda saklanır; böylece iki sistemdeki kayıt birbiriyle eşleşir.

Performans ve Maliyet Dengesi

API Çağrısı Limitleri

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

• Dynamics 365 Business Central: Limitler yayımlanmış durumda. Kullanıcı başına 5 dakikalık pencerede 6.000 istek ve en fazla 5 eşzamanlı istek.
• Paraşüt: Resmi dokümana göre 10 saniyede 10 istek.
• DİA: İstek sınırı yerine kontör var; her web servis çağrısı kontör tüketir.
• Kendi sunucunuzdaki ürünler: Sınırı çoğunlukla sunucunun kaynağı belirler.

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

Hangi Yol Neden Daha Hızlı?

On binlerce satırlık bir stok hareketini okumak gerektiğini düşünün.

Yöntem	Davranış	Not
Web servis ya da REST	Kayıtlar sayfa sayfa gelir	Her sayfa ayrı istek ve ayrı bekleme demektir
Doğrudan SQL, canlı veritabanı	Tek sorguda gelir	Ağır sorgu, program kullanıcılarını yavaşlatabilir
Doğrudan SQL, salt-okunur kopya	Tek sorguda gelir	Canlı sistem etkilenmez

Gerçek süreler sunucuya, veri hacmine ve sorguya göre değişir; rakamı kendi kurulumunuzda ölçmeniz gerekir. Toplu okumada SQL belirgin biçimde hızlıdır. Yazma için ise resmi arayüz şarttır.

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!';
-- Tablo adı örnektir; kendi kurulumunuzdaki adları yazın
GRANT SELECT ON dbo.TABLO_ADI 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

Kimlik doğrulama yöntemi üründen ürüne değişir: API anahtarı, OAuth ya da oturum kimliği.

Sık Sorulan Sorular

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

Okuma için çoğu üründe evet, ama sorumluluk sizdedir. Salt-okunur (SELECT) sorgular veriyi değiştirmez, bu yüzden programın bütünlüğünü tehdit etmez. Yine de üreticinin tutumunu bilmek gerekir: bazı üreticiler doğrudan okumayı kendi dokümanında anlatır, bazıları doğrudan veritabanı entegrasyonunu desteklemediğini açıkça yazar. Bizim yaklaşımımız: okuma için SQL kullanılabilir, yazma için istisnasız resmi arayüz.

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

Kendi sunucunuzda kurulu ürünlerde veritabanına erişim teknik olarak mümkündür, çünkü sunucu sizin kontrolünüzdedir. Ama erişebilmek başka, desteklenmek başka. Ürünler bu açıdan birbirinden ayrılır:

• ETA ve Wolvox: Üretici, ODBC ile okumayı kendi dokümanında anlatıyor.
• Logo, Netsis ve Mikro: Raporlama için doğrudan okuma yaygın. Yazma resmi arayüzden yapılır.
• Zirve: Veritabanı şeması kamuya açık değil.
• Dynamics 365 Business Central ve SAP Business One: Üretici doğrudan veritabanına yazmayı desteklemiyor.
• Bulut ürünler (Paraşüt, DİA, Luca, Logo İşbaşı): Veritabanına erişim yok.

Kullandığınız ürüne özel mimari keşif görüşmesinde netleşir.

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). Resmi arayüzler çoğunlukla sürümlenir, bu yüzden değişiklik daha yönetilebilir gelir. 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 hızı, veri güvenliğini ve desteklenen kullanım sınırında kalmayı 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 de ürün, arayüz ve kapsam netleştikten sonra yazılı takvimle verilir. Teslim sonrası 15 gün ücretsiz hata düzeltme kapsamdadır.

Ç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 firma filtresini asla atlamayın. Şablon sorgular hazırlayın, firma kodunu parametre olarak geçirin.
2. View'larda otomatik filtre ekleyin — mesela her firma için ayrı view: vw_Stok_Firma1, vw_Stok_Firma2.
3. Resmi arayüzde firma bilgisini koda sabit yazmayın; oturum açarken ya da istekte yapılandırmadan okuyun.
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 ürünün resmi arayüzünü 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 doğrudan veritabanına yazmayı desteklemediğini açıkça yazıyor. Logo, Netsis ve Mikro'da doğrudan yazmak teknik olarak mümkündür, ama doğru yol resmi arayüzdür: Logo Objects, NetOpenX ve Mikro Desktop API.

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.