SAP B1 Geliştirme: SDK mı, Service Layer mı Seçmeli?

Kısa cevap: dışarıdan B1'e bağlanan yeni bir entegrasyon yazıyorsanız varsayılanınız Service Layer olmalı; B1'in Windows istemcisi içinde ekran eklemeniz gerekiyorsa tek yol UI API; sunucu tarafında çalışan, yoğun toplu işlem yapan ya da Service Layer'da karşılığı olmayan nadir bir nesneye dokunan işlerde DI API hâlâ yerini koruyor. Seçim bir moda tercihi değil, işin nerede çalıştığıyla ilgili: arayüz mü yazıyorsunuz, veri mi taşıyorsunuz, yoksa hazır bir senaryoyu mu işletiyorsunuz?

Bu yazı SAP Business One üzerinde geliştirme yapacak ekipler için bir seçim rehberi. Service Layer'ın mimarisi, authentication akışı ve ilk çağrısı ayrı bir yazının konusu; oraya girmeden önce hangi aracı seçeceğinizi netleştirmek istiyorsanız doğru yerdesiniz. Uygulamaya geçtiğinizde Service Layer'da ilk API çağrısı rehberimiz kaldığınız yerden devam ediyor.

Dört araç, dört farklı iş

SAP Business One'ın geliştirme yüzeyi tek bir API'den ibaret değil. Dördünü aynı tabloda görmek, çoğu tartışmayı başlamadan bitiriyor:

Araç	Ne için	Nerede çalışır	Asıl sınırı
DI API	Sunucu tarafında veri okuma ve yazma, toplu işlemler	Windows, COM bileşeni olarak	Platform bağımlı; makineye kurulum ister
UI API	Windows istemcisinin ekranlarını değiştirmek, yeni ekran eklemek	Çalışan B1 Windows istemcisinin içinde	Web Client'ta görünmez
Service Layer	Dış sistemlerle REST/OData entegrasyonu	Sunucunun yanında HTTP servisi olarak	Nadir birkaç nesne/işlem henüz kapsam dışı olabilir
Entegrasyon çerçevesi	Hazır senaryolar, şirketler arası akışlar	Sunucuda servis olarak	Özel iş mantığında kod kadar esnek değil

Bu tabloyu gördükten sonra en sık sorulan soru şu oluyor: "DI API artık ölü mü?" Hayır. Ama yeni bir projeye DI API ile başlamak için somut bir gerekçeniz olmalı; gerekçe yoksa Service Layer daha ucuz bir gelecek satın alır.

Karar ağacı: hangi iş hangi araçla

Sahada kullandığımız sıralama şu şekilde işliyor:

1. İş B1'in kendi ekranında mı geçiyor? Kullanıcı bir belgeyi açtığında ek alan, ek sekme, ek doğrulama görecekse cevap UI API'dir; başka seçenek yok. Ama önce şunu sorun: bu gerçekten ekran mı olmalı, yoksa kullanıcı tanımlı alan ve onay şablonuyla çözülebilir mi? Kod yazmadan çözülen her ihtiyaç, bakım maliyeti sıfır olan ihtiyaçtır.
2. Dış bir sistem B1 ile konuşacak mı? E-ticaret, depo yönetimi, banka, saha satış, özel yazılım — hepsinde cevap Service Layer. Platform bağımsızdır, sunucuya istemci kurulumu gerektirmez, HTTP olduğu için loglama ve izleme standart araçlarla yapılır.
3. Şirketler arası veya hazır bir akış mı kuruyorsunuz? Çok şirketli yapılarda ana veri kopyalama ve karşılıklı belge oluşturma gibi işler için entegrasyon çerçevesindeki hazır senaryolar, sıfırdan kod yazmaktan hem hızlı hem daha az bakımlıdır.
4. Geriye kalan durumlar. Sunucu tarafında çalışan yoğun toplu iş, Service Layer'da karşılığı olmayan nadir bir nesne veya hâlihazırda sorunsuz çalışan eski bir add-on'u genişletme: DI API.

Tek bir projede birden fazla aracın birlikte kullanılması normaldir. Tipik bir kurgu şöyle görünür: dış sistemle konuşan servis Service Layer üzerinden yazar, kullanıcının belgede gördüğü ek kontrol UI API add-on'unda yaşar, gece çalışan toplu mutabakat işi DI API ile koşar.

Performans, ölçekleme ve sürüm bağımlılığı

Performans tartışması genellikle yanlış yerden başlıyor: "hangisi daha hızlı" sorusunun tek bir cevabı yok, çünkü darboğaz araçta değil desendedir.

Service Layer yatay ölçeklenir; istekler bir yük dengeleyici üzerinden birden çok düğüme dağılır. Yoğun entegrasyonda kazanç, düğüm sayısını ve oturum yönetimini doğru kurmaktan gelir. Her istekte yeniden oturum açan bir istemci, kaç düğüm eklerseniz ekleyin yavaş kalır. Çok sayıda belgeyi tek seferde yazacaksanız OData'nın toplu istek (batch) yapısı, aynı isteği tek tek göndermekten belirgin biçimde verimlidir ve işlem bütünlüğünü de korur.

DI API tarafında maliyet nesne başına ödenir: her nesne örneği oluşturma ve bağlantı kurma işlemi bedelli bir iştir. Tek bir bağlantıyı açıp tekrar kullanmak, nesneleri döngü içinde gereksiz yere yeniden yaratmamak ve mümkün olduğunca az sayıda işlem penceresi açmak temel disiplinlerdir. Çok kullanıcılı, eşzamanlı bir yük bekliyorsanız DI API'nin sunucu tarafı barındırma modelini kullanmadan ilerlemeyin.

Sürüm bağımlılığı tarafında iki uyarı: UI API ile yazılmış add-on'lar, B1 istemcisinin sürümüne ve ekran yapısına en sıkı bağlı olan katmandır — sürüm yükseltmelerinde en çok iş çıkaran taraf burasıdır. DI API tarafında ise derleme hedefinin (32/64 bit) sunucudaki bileşenle eşleşmemesi, yıllardır aynı hata mesajıyla karşımıza çıkan klasik bir tuzaktır.

HANA ve SQL farkının geliştiriciye yansıması

Service Layer ve DI API, her iki veritabanı platformunda da aynı arayüzü sunar; bu yüzden iş nesneleriyle çalışan kod büyük ölçüde taşınabilirdir. Fark, doğrudan SQL yazdığınız anda başlar.

Ham sorgu çalıştıran her kod, veritabanına bağımlı hale gelir. HANA tarafında kolon adları tırnak içinde ve büyük-küçük harfe duyarlı yazılmak zorundadır; SQL Server tarafında köşeli parantez alışkanlığı geçerlidir. Null işleme, tarih fonksiyonları ve satır sınırlama sözdizimi de iki tarafta ayrışır. Bu yüzden kuralımız net: iş nesneleriyle yapılabilecek hiçbir işi ham sorguyla yapmayız. Ham sorgu yalnızca okuma amaçlı raporlamada, ayrı bir katmanda ve hangi platforma ait olduğu açıkça işaretlenerek yaşar. Sorgu performansı tarafındaki ayrıntıları HANA sorgu optimizasyonu yazısında ayrıca ele aldık.

Hata yönetimi ve işlem bütünlüğü

Entegrasyon projelerinde destek taleplerinin büyük kısmı, yutulmuş hata mesajlarının peşinde geçiyor. İki tarafta da kural aynı: B1'in ürettiği gerçek mesajı olduğu gibi loglayın.

Service Layer tarafında hata gövdesindeki mesaj alanı, B1'in iş kuralı metnini taşır — "stok yetersiz", "iş ortağı bloke" gibi. DI API tarafında ise hata, dönüş kodundan ve son hata çağrısından okunur:

if (oCompany.Connect() != 0)
{
    oCompany.GetLastError(out int errCode, out string errMsg);
    throw new InvalidOperationException($"B1 bağlantı hatası {errCode}: {errMsg}");
}

İşlem bütünlüğü ikinci kritik başlık. Birbirine bağlı birden fazla belge yazıyorsanız (örneğin sipariş ve ardından ön tahsilat), bunların ya hepsi yazılmalı ya da hiçbiri. DI API tarafında bu, açık bir işlem penceresiyle yönetilir:

oCompany.StartTransaction();
try
{
    // birbirine bağlı belgeler burada yazılır
    oCompany.EndTransaction(SAPbobsCOM.BoWfTransOpt.wf_Commit);
}
catch
{
    oCompany.EndTransaction(SAPbobsCOM.BoWfTransOpt.wf_RollBack);
    throw;
}

Service Layer tarafında karşılığı, aynı toplu istek içindeki değişiklik kümesidir: küme içindeki işlemlerden biri başarısız olursa tamamı geri alınır. Hangi aracı kullanırsanız kullanın, "yarım kalmış entegrasyon kaydı" senaryosunu tasarımda kapatmadan canlıya çıkmayın.

Yetki, lisans ve güvenlik tarafı

Üç araç da B1'in kendi yetki modeline tabidir; API üzerinden yaptığınız işlem, o kullanıcının ekranda yapabileceğinden fazlasını yapamaz. Bu iyi bir haber: güvenliği uygulama katmanında yeniden kurmanız gerekmez, mevcut yetki tanımlarını kullanırsınız.

Pratikte uyguladığımız kurallar şunlar:

• Entegrasyona özel kullanıcı açın ve yetkisini dokunduğu nesnelerle sınırlayın. Sipariş yazan bir entegrasyonun ana veri silme yetkisi taşıması tasarım değil, ihmaldir.
• Lisans tarafını baştan netleştirin. API üzerinden işlem yapan kullanıcı da lisans modeline tabidir; entegrasyon kullanıcısının lisans tipi teklif aşamasında konuşulmazsa sonradan sürpriz olur.
• Servisi doğrudan internete açmayın. Araya bir ağ geçidi koyun; IP kısıtı, hız sınırı ve istek loglaması o katmanda yaşasın.
• Ortamları ayırın. Test istemcisinin yanlışlıkla canlı şirket veritabanına bağlanamayacağını yapılandırma düzeyinde garanti edin.

Bu disiplinleri projenin başında kurmak birkaç saatlik iş; sonradan kurmak ise genellikle bir olaydan sonra oluyor. Yazılım geliştirme projelerinde bu maddeleri teknik tasarım dokümanının ilk sayfasına koyuyoruz. Entegrasyon mimarisini uçtan uca kurgulamak istiyorsanız SAP entegrasyon çözümlerimiz bu yaklaşımın uygulanmış halidir.

Sık sorulan sorular

DI API artık kullanılmamalı mı?

Kullanılabilir, ama yeni bir entegrasyona DI API ile başlamak için somut bir gerekçe olmalı. Gerekçe olarak kabul ettiklerimiz şunlar: Service Layer'da karşılığı olmayan nadir bir nesne veya işlem, sunucu tarafında çalışan yoğun toplu iş ve halihazırda sorunsuz çalışan bir add-on'un genişletilmesi. Bunların dışında Service Layer daha az bakım ister.

UI API add-on'umuz Web Client'ta çalışır mı?

Hayır; UI API add-on'ları Windows istemcisinin arayüzü içinde çalışır, Web Client bu arayüzü barındırmaz. Web Client'a geçiş planlıyorsanız ekran gerektiren geliştirmeleri baştan gözden geçirin — ayrıntısını Web Client'a geçiş rehberinde anlattık.

Service Layer ile DI API'yi aynı projede birlikte kullanabilir miyiz?

Evet ve bu yaygın bir kurgudur. Dış sistemle konuşan servis Service Layer üzerinden çalışırken, gece koşan toplu iş DI API ile yürüyebilir. Dikkat edilecek tek nokta, aynı veriye iki farklı yoldan yazan iki sürecin birbirinin üzerine geçmemesi için sahiplik kurallarının net olmasıdır.

Toplu veri yüklemede hangisi daha uygun?

İlk göç ve günlük akış aynı araçla tasarlanmamalıdır. On binlerce kaydın taşındığı ilk yükleme için toplu veri araçları ve DI API tarafı daha verimli olabilirken, günlük entegrasyon akışı için Service Layer'ın toplu istek yapısı fazlasıyla yeterlidir. İkisini aynı koddan geçirmeye çalışmak, her iki tarafı da tatmin etmeyen bir tasarım üretir.

Geliştirmeyi kendi ekibimiz yaparsa sizden ne alırız?

En sık kurduğumuz model tam bu: yazılımı müşterinin ekibi yazar, biz B1 nesne modeli danışmanlığı, test şirketi kurulumu, yetki ve performans ayarı ile canlıya alma desteği veririz. Kod sizde kalır, ürün bilgisi bizden gelir; ekibiniz ilk projede öğrenir, ikincisinde bize daha az ihtiyaç duyar.