Bu üründe “doğrudan veritabanına yazalım mı” tartışmasını yapmaya gerek yok: SAP cevabı kendi rehberinde yazmış. Bizim işimiz o çizginin içinde, üretimin ve sahanın ihtiyacını karşılayan katmanı yazmak.
SAP Business One iki veritabanı hattı üzerinde çalışır: MS SQL Server ve SAP HANA. HANA hattı “SAP Business One, version for SAP HANA” adıyla ayrı bir ürün olarak konumlanır.
SAP’nin kendi rehberine göre sistem tablolarına doğrudan ekleme, güncelleme ve silme yapılması desteklenmez — SQL betikleri ve SDK üzerinden çalıştırılan sorgular dahil. Tek istisna, iki tipteki kullanıcı tanımlı tablolardır: “No Object” ve “No Object with Auto Increment”.
Service Layer, OData tabanlı bir REST arayüzüdür ve JSON ile çalışır. Yanında COM tabanlı DI API bulunur; ikisi nesne ve özellik tanımlarının büyük kısmını paylaşır.
İki API sürümü vardır: v1 OData 3.0 (geriye uyum) ve v2 OData 4.0 (yeni entegrasyonlar için önerilen).
FP 2405 itibarıyla OData v3 kullanımdan kaldırılmış sayılıyor — yani v1 üzerinden çalışan entegrasyonlar sürpriz değil, planlı olarak kırılır.
Oturum, Login çağrısıyla açılır ve çerezlerle izlenir. Şirket veritabanı adı büyük/küçük harfe duyarlıdır; v1 ve v2 uçlarının karıştırılması yetkilendirme hatasıyla sonuçlanır.
Önce şunu netleştiriyoruz: hangi hattasınız?
SAP Business One entegrasyonunda ilk soru modül değil, hat. Ürün iki farklı veritabanı hattı üzerinde yaşıyor: MS SQL Server tarafı ve SAP HANA tarafı. HANA hattı ayrı bir ürün adıyla, “SAP Business One, version for SAP HANA” olarak konumlandırılmış durumda. İkisi aynı iş mantığını taşısa da altyapı, kurulum topolojisi ve operasyon alışkanlıkları farklı.
Bu ayrımın proje üzerindeki etkisi, entegrasyon arayüzünün seçilmesinden önce başlıyor. Okuma tarafında hangi yolu kullanacağımız, raporlama yükünü nereye koyacağımız ve test ortamının nasıl kurulacağı hattın ne olduğuna bağlı. Keşif görüşmesinde sorduğumuz ilk üç şey şu: hangi hat, hangi sürüm ve hangi yama seviyesi, kaç şirket veritabanı aktif.
Bu soruların cevabını çoğu zaman firmanın kendisi değil, mevcut SAP iş ortağı biliyor. Bizim için sorun değil — zaten bu segmentte iş ortağının devrede olmasını normal kabul ediyoruz ve süreci onunla birlikte yürütmeyi tercih ediyoruz. Nedenini aşağıda ayrı bir bölümde açıyoruz.
SAP Business One entegrasyonunda mimariyi belirleyen temel başlıklar. Sürüm, yama seviyesi ve kurulum topolojisi proje başında müşteri kurulumunda teyit edilir.
Başlık
Durum
Entegrasyona etkisi
Veritabanı hattı
MS SQL Server ya da SAP HANA (ayrı ürün hattı)
Okuma stratejisi ve test ortamı kurulumu hatta göre belirlenir
Ana entegrasyon arayüzü
Service Layer — HTTP üzerinden OData tabanlı REST, JSON
Yeni entegrasyonların varsayılan yolu budur
İkinci arayüz
DI API — COM tabanlı, Windows bağımlı
Service Layer ile nesne ve özellik tanımlarının büyük kısmını paylaşır
Yeni işler v2 üzerine kurulur; v1 planlı olarak kullanımdan kalkıyor
Ölçekleme
Service Layer önünde Apache HTTP Server yük dengeleyici, paralel işleme
Eşzamanlılık mimari olarak destekleniyor, ancak ölçü yük testiyle bulunur
Bağlantı ucu
Sunucu adresi ve port üzerinden Login çağrısı
Port ve adres yapılandırmadan okunur, koda gömülmez
Bu sayfanın en net cümlesi: doğrudan yazmayı SAP’nin kendisi dışarıda bırakmış
Diğer muhasebe ve ERP ürünlerinde “neden doğrudan veritabanına yazmıyorsunuz” sorusuna mühendislik gerekçeleriyle cevap vermek zorunda kalıyoruz. SAP Business One tarafında bu tartışmayı yapmaya gerek yok, çünkü cevabı üretici kendi rehberinde yazmış.
SAP’nin yayımladığı veri değiştirme rehberine göre, SAP Business One sistem tablolarına doğrudan ekleme, güncelleme veya silme yapılması desteklenmiyor. Bu yalnızca elle çalıştırılan SQL betikleri için değil; SDK üzerinden çalıştırılan doğrudan sorgular da bu kapsamda. Yani “SDK kullanıyoruz, o yüzden sorun yok” savunması bu üründe geçerli değil.
Kuralın tanımlı bir istisnası var: iki tipteki kullanıcı tanımlı tablolar. SAP’nin rehberinde doğrudan veri yazılabilen alan olarak “No Object” (nesne bağlantısı olmayan) ve “No Object with Auto Increment” (nesne bağlantısı olmayan, otomatik artan anahtarlı) tipleri listeleniyor. Pratikte bu, entegrasyonun kendi ara verilerini, eşleme kayıtlarını ve işlem günlüklerini SAP tarafında tutabilmesi için yeterli bir alan sağlıyor — ama iş belgesi oluşturmak için bir kapı değil.
Okuma tarafında ise SAP çizgiyi başka bir yere koymuş. Business One 10.0’ın belirli bir yama seviyesinden itibaren Service Layer üzerinden doğrudan SQL sorgusu çalıştırmak mümkün hale geldi — ancak yalnızca veri okumak için. Bu, okuma ve yazma ayrımının bizim mühendislik tercihimiz değil, üreticinin tasarım kararı olduğunu gösteren en açık kanıt.
Okuma — esneklik var, disiplin şart
Service Layer üzerinden doğrudan sorgu çalıştırabilmek, raporlama ve analiz ihtiyaçlarında ciddi bir kolaylık. Ama esneklik, sorumsuzluk anlamına gelmiyor.
Ağır raporlama sorguları canlı iş yükünün üzerine bindirilmez; sorgu bütçesi ve çalışma zamanı baştan planlanır
Şirket veritabanı bağlamı her sorguda açıkça belirtilir — çok şirketli kurulumlarda bağlam hatası hata vermez, yanlış rapor üretir
Sorgu sonuçları sayfalanır; tek seferde büyük kümeler çekmek hem zaman aşımı hem de bellek sorunu üretir
Sürekli tekrarlanan panel sorguları için düzenli aralıklarla yenilenen yerel bir rapor deposu kurmak, hem paneli hızlandırır hem ERP kullanıcılarının performansını korur
Yazma — istisnasız nesne arayüzü üzerinden
Kayıt oluşturma ve güncelleme işlemlerini istisnasız Service Layer nesneleri ya da DI API üzerinden yapıyoruz. Bunun tek sebebi kurala uymak değil; bu yoldan geçen her işlemde SAP’nin kendi iş mantığı devreye giriyor. Zorunlu alan kontrolleri, muhasebe bağlantıları, belge-satır ilişkisinin doğru kurulması ve numaralandırma mantığı işin içinde. Hata varsa anlamlı bir mesajla geri dönüyor ve veri bozulmuyor.
Doğrudan ekleme bu kontrollerin tamamını atlar ve sonucu çoğu zaman anında görünmez. Belge tablosuna satır yazılır, ilgili muhasebe kaydı oluşmaz; sistem çalışmaya devam eder, tutarsızlık aylar sonra mutabakat sırasında ortaya çıkar. Bu tür bir tutarsızlığı geri almak, entegrasyondan kazanılan tüm zamandan kat kat pahalıya mal olur.
Bir müşteri “daha hızlı olsun, doğrudan yaz” dediğinde bunu yapmayı reddediyoruz. Bu bir üslup tercihi değil: üreticinin desteklemediği bir kullanım biçimine geçmek, o kurulumun destek kapsamı açısından da riskli hale gelmesi demek. Bizim kararımız, sizi bu tartışmaya hiç sokmamak.
Service Layer mi, DI API mi? Aynı nesneler, farklı kapı
SAP Business One’da iki programlama arayüzü yan yana yaşıyor ve seçim çoğu zaman “hangisi daha iyi” sorusundan çok “hangisi bu kurulumda daha uygun” sorusuyla yapılıyor.
Service Layer, HTTP üzerinden çalışan OData tabanlı bir REST arayüzü. JSON ile veri alışverişi yapıyor, yük dengeleyici olarak Apache HTTP Server kullanıyor ve paralel işlemeyle ölçekleniyor. Platform bağımsız olması, entegrasyonu SAP sunucusuyla aynı işletim sisteminde çalıştırma zorunluluğunu ortadan kaldırıyor — bu, modern bir ara katman kurmak isteyen herkes için belirleyici bir avantaj.
DI API ise COM tabanlı, yani Windows dünyasına bağlı bir arayüz. Bunun yanında önemli bir gerçek var: Service Layer, DI API ile nesne ve özellik tanımlarının büyük kısmını paylaşıyor. Yani bir nesnenin alanlarını ve davranışını bir tarafta öğrendiğinizde, bilgi diğer tarafa büyük ölçüde taşınıyor. Bu, özellikle eski bir DI API entegrasyonunu Service Layer’a taşırken işi ciddi şekilde kolaylaştırıyor.
Bizim varsayılan tercihimiz Service Layer. Gerekçesi basit: HTTP üzerinden çalışan, platform bağımsız ve sürümlü bir yüzey, ara katman mimarisine doğrudan oturuyor. DI API’yi ise mevcut bir kurulumda zaten DI API üzerine yazılmış bir yapı varsa veya belirli bir işlemin karşılığı orada daha olgun duruyorsa gündeme alıyoruz. Bu kararı keşifte, varsayım yapmadan veriyoruz — hangi arayüzün o kurulumda mevcut ve kullanılabilir olduğu teyit edilmeden takvim vermiyoruz.
Oturum açma: küçük görünen dört detay, sahadaki hataların çoğu
Service Layer tarafında bağlantı, sunucu adresi ve port üzerinden yapılan bir Login çağrısıyla başlıyor. Adres kalıbı, sunucu adı ya da IP ile port bilgisinin ardından /b1s/v2/Login gelecek biçimde kuruluyor; yerel bir kurulumda bu https://localhost:50000/b1s/v2/Login gibi görünüyor. Varsayılan port 50000; kurulumdaki gerçek değer System Landscape Directory (SLD) kaydından alınır, ayrıntısı kurulumda teyit edilir.
İstek gövdesinde üç bilgi taşınıyor: şirket veritabanı adı, kullanıcı adı ve şifre. Burada ilk tuzak devreye giriyor — şirket veritabanı adı büyük/küçük harfe duyarlı. Adı bir harf farkıyla yazan bir entegrasyon, bağlantı sorunu sanılan ve saatlerce ağ tarafında aranan bir hata alır.
Başarılı oturum bir oturum kimliği döndürüyor ve oturum, çerezler üzerinden izleniyor: oturum kimliği çerezinin yanında bir yönlendirme çerezi de taşınıyor. Bu ikinci çerez yük dengeleme tarafıyla ilgili ve göz ardı edilirse, arkada birden fazla düğüm varsa istekler beklenmeyen şekilde dağılabilir. Entegrasyon katmanının çerezleri koruyup her istekte geri göndermesi gerekiyor. Oturumu kapatmak için ilgili Logout çağrısı kullanılıyor ve başarılı kapanış içerik döndürmeyen bir yanıtla sonuçlanıyor.
İkinci ve daha sinsi tuzak sürüm karışıklığı: OData v1 oturumları v2 oturum açma ucundan kurulmaz. İki sürümü aynı akışta karıştıran bir entegrasyon yetkilendirme hatası alır — ve bu hata kimlik bilgilerinin yanlış olduğu izlenimi verdiği için ekip yanlış yerde arama yapar. Bizim yaklaşımımız, entegrasyonun hangi sürüm üzerinde çalıştığını yapılandırmada tek bir yerde tanımlamak ve tüm çağrıları o tanıma bağlamak.
Oturum ömrü tarafında ise yapılandırmaya bağlı bir durum var: yaygın olarak belirli bir işlemsizlik süresinden sonra oturumun düştüğü, bu sürenin de sunucu yapılandırma dosyası ya da System Landscape Directory (SLD) üzerinden değiştirilebildiği belirtiliyor; ayrıntısı kurulumda teyit edilir. Bu tür yapılandırma değerlerini sayfada mutlak doğru gibi yazmıyoruz; entegrasyon tarafında yaptığımız şey süreye güvenmemek: oturum düştüğünde otomatik yeniden açma ve tek seferlik yeniden deneme mantığı ilk günden koda giriyor.
Sürüm yükseltmesi burada sürpriz değil, takvimli bir kırılma
Entegrasyon sayfalarında genellikle “sürüm değişince bozulabilir” diye yazarız ve bu bir ihtimal beyanıdır. SAP Business One tarafında elimizde ihtimal değil, ilan edilmiş bir takvim var — ve bu, planlama açısından aslında iyi haber.
Durum şöyle: iki API sürümü yan yana yaşıyor. v1 OData 3.0 üzerine kurulu ve geriye uyum için duruyor; v2 ise OData 4.0 üzerine kurulu ve yeni entegrasyonlar için önerilen sürüm. FP 2405 itibarıyla OData v3 kullanımdan kaldırılmış sayılıyor. Yani v1 ucu üzerinden çalışan bir entegrasyon, bir gün beklenmedik şekilde değil, ilan edilmiş bir yol haritasının sonunda çalışmayı bırakacak.
Bunun pratik karşılığı iki farklı müşteri profilinde iki farklı iş. Yeni bir entegrasyon kuruyorsanız karar zaten net: v2 üzerine yazılır, v1 hiç gündeme gelmez. Elinizde yıllardır çalışan bir entegrasyon varsa ve v1 üzerinden konuşuyorsa, bu bir acil durum değil ama bir takvim kalemidir — geçişi yükseltme baskısı altında değil, kendi planınızla yapmak çok daha ucuz.
Geçişte işi kolaylaştıran bir nokta var: Service Layer ile DI API nesne ve özellik tanımlarının büyük kısmını paylaştığı için, mevcut entegrasyonun iş mantığı genellikle korunabiliyor. Değişen şey çağrı katmanı oluyor. Bu yüzden iyi ayrılmış bir mimaride — iş kurallarının bir tarafta, çağrı katmanının başka bir tarafta olduğu bir yapıda — geçiş sınırlı bir işe dönüşüyor. Kötü ayrılmış bir yapıda ise aynı iş baştan yazma anlamına geliyor.
Bizim mevcut entegrasyonlar için önerdiğimiz sıra şu: önce bir tespit turu — hangi uç noktalar hangi sürüm üzerinden çağrılıyor, kaç yerde sabit yazılmış değer var, iş mantığı çağrı katmanından ayrılmış mı. Sonra geçiş planı. Bu tespit turu tek başına da alınabilecek bir iş; entegrasyonu biz yazmamış olsak da yapıyoruz.
Hata düzeltme, teslimden itibaren 15 gün ücretsiz. Yama takibi, yükseltme öncesi regresyon ve sürüm geçişi planlaması ise devam eden işler — bunlar için ayrı bir bakım hizmeti tanımlıyor, kapsamını sözleşmede satır satır yazıyoruz.
SAP iş ortağınızın yerine değil, yanında
Bu segmentteki firmaların çoğunda tablo şu: SAP Business One kurulu, bir SAP iş ortağı devrede, ürün tarafındaki destek yürüyor. Sorun ürünün kendisinde değil; üretim sahasında, depoda ya da bayi kanalında standart ürünün kapsamadığı bir ihtiyaç var ve bunun için özel geliştirme gerekiyor.
Biz tam olarak o noktada masadayız. Açık olalım: SAP iş ortağı değiliz, SAP’nin bayisi ya da çözüm ortağı değiliz ve lisans, kurulum, yükseltme, ürün danışmanlığı gibi alanlara girmiyoruz. Bu alanlar iş ortağınızın uzmanlığı ve orada rekabet etmek gibi bir iddiamız yok. Yaptığımız iş, ürünün belgelenmiş arayüzleri üzerinden yazılan özel geliştirme ve onun bakımı.
Bu ayrım üç tarafın da işine geliyor. Siz, ürün desteğinizi bozmadan özel bir ihtiyacı karşılıyorsunuz. İş ortağınız, kendi kapsamı dışındaki bir talebi geri çevirmek zorunda kalmıyor. Biz ise ürün tarafında taahhüt vermediğimiz için yalnızca gerçekten yapabileceğimiz işi üstleniyoruz.
Geliştirmenin kapsamı yazılı olarak iş ortağınızla paylaşılabilir; hangi arayüzün, hangi nesneler üzerinde kullanıldığı şeffaftır
Yazma işlemlerini istisnasız nesne arayüzü üzerinden yaptığımız için kurulumun desteklenen kullanım sınırları içinde kalırsınız
Kendi geliştirme ekibi olmayan SAP iş ortakları için taşeron geliştirme modelinde de çalışırız — müşteri ilişkisi ve ticari muhatap sizde kalır
İstenirse beyaz etiketli çalışırız; müşteriye karşı görünen taraf siz olursunuz
Yazılan kodun dokümantasyonu ve yapılandırma haritası teslim edilir; iş birliği sonlansa bile elinizde çalışır ve devredilebilir bir varlık kalır
Bilmediklerimizi de yazıyoruz
Entegrasyon sayfalarında genellikle her sorunun cevabı varmış gibi yazılır. Biz tersini yapıyoruz, çünkü proje ortasında çıkan sürprizin bedelini müşteri ödüyor. SAP Business One tarafında doğrulayamadığımız ve bu yüzden taahhüt etmediğimiz üç konu var.
İstek limiti — yayımlanmış bir istek/saniye sınırı veya aşım davranışı bulamadık. Bu yüzden burada rakam yazmıyoruz. Entegrasyonu baştan yeniden deneme, kademeli bekleme ve kontrollü parti gönderimi ile yazıyor, gerçek eşiği yük testiyle ölçüyoruz.
Bildirim mekanizması — Service Layer tarafında dışarıya bildirim gönderen bir yapı olduğunu doğrulayamadık. Bu yüzden senkronizasyonu zamanlanmış ve filtrelenmiş çekme üzerine kuruyoruz; mükerrer işleme, işlenmişlik kontrolü ve tek çalışan kilidiyle engelleniyor.
Arayüz kullanımının lisans tarafındaki karşılığı — Service Layer veya DI API kullanımı için ayrı bir lisans ya da iş ortaklığı şartı olduğuna dair doğrulanmış bir bilgiye ulaşmadık. Bu yüzden ne “gerekiyor” ne de “gerekmiyor” diyoruz; kurulumunuzda ne durumda olduğu iş ortağınızla teyit edilir.
Sahada nasıl görünüyor?
Üretim sahasından SAP’ye iş emri geri bildirimi
Tezgâh başındaki terminalde kapatılan iş emri, mamul girişi ve hammadde sarfı olarak Service Layer nesneleri üzerinden SAP’ye yazılıyor. Excel’den toplu giriş yapan bir kişi yerine SAP’nin kendi doğrulamalarından geçmiş kayıtlar kalıyor; ay sonu maliyeti gerçek saha verisiyle kapanıyor.
El terminaliyle depo sayımı ve fark mutabakatı
Depo sayımı el terminalinden yapılıyor, SAP’deki bakiyeyle karşılaştırılıyor ve fark listesi sorumluya düşüyor. Okuma tarafı Service Layer üzerinden yapıldığı için canlı sistemde hiçbir kayıt riske girmiyor.
Bayi ve müşteri portalinden sipariş akışı
Bayiler siparişi kendi portalinden giriyor, sipariş SAP’ye nesne arayüzü üzerinden düşüyor. SAP’nin kendi doğrulamaları ve numaralandırma serisi devrede olduğu için eksik veya tutarsız sipariş en baştan reddediliyor; sözlü siparişin yanlış anlaşılması diye bir konu kalmıyor.
Yönetim panelinde canlı stok ve sipariş görünümü
Üretim, stok ve sipariş verisi tek panelde birleşiyor. Sürekli tekrarlanan panel sorguları SAP’den ayrı, zamanlanmış olarak beslenen bir raporlama veritabanından okuduğu için ERP kullanıcılarının performansı etkilenmiyor.
Mevcut entegrasyonun sürüm geçişi tespiti
Yıllardır çalışan bir entegrasyonun hangi API sürümü üzerinden konuştuğu, kaç yerde sabit yazılmış değer bulunduğu ve iş mantığının çağrı katmanından ayrılıp ayrılmadığı çıkarılıyor. Çıktı, geçişi yükseltme baskısı altında değil kendi takviminizle yapabilmenizi sağlayan bir yol haritası oluyor.
Referans iş birliği
Entegrasyon tarafında yeni bir hat kuruyoruz ve ilk projeleri referans iş birliğiyle yürütüyoruz: projenin sonunda ölçülebilir sonuçları vaka çalışması olarak yayımlamamıza ve sizi referans göstermemize izin veren firmalara özel koşul uyguluyoruz. Karşılığında alacağınız şey standart bir paket değil, süreçlerinize göre yazılmış bir sistem — ve geliştiren ekibe doğrudan erişim.
Sık sorulan sorular
SAP iş ortağı mısınız?
Hayır. SAP iş ortağı ağının parçası değiliz; bayilik ya da çözüm ortaklığı sıfatımız da yok. Bağımsız bir yazılım geliştiricisi olarak çalışıyoruz. Lisans, kurulum, yükseltme ve ürün danışmanlığı tarafı mevcut SAP iş ortağınızın uzmanlığı ve o alana girmiyoruz. Yaptığımız iş, ürünün belgelenmiş arayüzleri üzerinden özel geliştirme yapmak ve onun bakımını üstlenmek. Bu segmentte iş ortağının devrede olmasını normal kabul ediyoruz; onun yerine değil, yanında çalışıyoruz. Kendi geliştirme ekibi olmayan SAP iş ortaklarıyla da taşeron geliştirme modelinde çalışıyoruz.
Doğrudan SAP veritabanına yazabilir misiniz?
Yazmıyoruz ve bu kez gerekçeyi bizim açıklamamıza bile gerek yok: SAP kendi veri değiştirme rehberinde sistem tablolarına doğrudan ekleme, güncelleme ve silme yapılmasının desteklenmediğini yazmış durumda. Bu kapsam yalnızca elle çalıştırılan SQL betiklerini değil, SDK üzerinden çalıştırılan doğrudan sorguları da içeriyor. Tanımlı istisna iki tip kullanıcı tanımlı tablo: “No Object” ve “No Object with Auto Increment”. Entegrasyonun kendi ara verisine ihtiyacı olduğunda o alanı kullanıyoruz; iş belgesi oluşturmak içinse istisnasız nesne arayüzünden geçiyoruz.
Okuma tarafında da aynı kısıt var mı?
Hayır ve bu ayrımı da SAP kendisi çizmiş. Business One 10.0’ın belirli bir yama seviyesinden itibaren Service Layer üzerinden doğrudan SQL sorgusu çalıştırmak mümkün hale geldi — ancak yalnızca veri okumak için. Yani okuma tarafında esneklik resmen açık, yazma tarafında ise nesne arayüzü zorunlu. Biz de bu çizgiye uyuyoruz: raporlama ve analiz için esnek sorgular yazıyoruz, ama canlı iş yükünü korumak için sorgu bütçesi ve sayfalama disiplinini baştan uyguluyoruz.
Service Layer mi kullanmalıyız, DI API mi?
Varsayılan tercihimiz Service Layer. Gerekçesi basit: HTTP üzerinden çalışan, JSON ile veri alışverişi yapan, platform bağımsız ve sürümlü bir yüzey modern bir ara katman mimarisine doğrudan oturuyor; ayrıca önünde yük dengeleyici bulunması ve paralel işlemeyle ölçeklenmesi eşzamanlı yük tarafında elimizi rahatlatıyor. DI API, COM tabanlı olduğu için Windows dünyasına bağlı; onu mevcut kurulumda zaten DI API üzerine yazılmış bir yapı varsa ya da belirli bir işlemin karşılığı orada daha uygunsa gündeme alıyoruz. İşi kolaylaştıran nokta şu: iki arayüz nesne ve özellik tanımlarının büyük kısmını paylaşıyor, yani bir tarafta öğrenilen bilgi diğer tarafa büyük ölçüde taşınıyor.
Oturum açarken en sık hangi hata yapılıyor?
İki hata öne çıkıyor. Birincisi şirket veritabanı adının büyük/küçük harf duyarlılığı: adı bir harf farkıyla yazan entegrasyon, bağlantı sorunu sanılan ve saatlerce ağ tarafında aranan bir hata alır. İkincisi ve daha sinsisi sürüm karışıklığı — OData v1 oturumları v2 oturum açma ucundan kurulmaz; iki sürümü aynı akışta karıştıran bir entegrasyon yetkilendirme hatası alır ve bu hata kimlik bilgilerinin yanlış olduğu izlenimi verdiği için ekip yanlış yerde arar. Bu yüzden sürümü yapılandırmada tek bir yerde tanımlıyor, tüm çağrıları o tanıma bağlıyoruz. Ayrıca oturum çerezlerinin korunup her istekte geri gönderilmesi gerekiyor; yük dengeleme tarafıyla ilgili yönlendirme çerezi göz ardı edilirse istekler beklenmeyen şekilde dağılabilir.
Sürüm yükseltmesinde entegrasyonumuz bozulur mu?
SAP Business One tarafında bu soru bir ihtimal değil, takvim sorusu. İki API sürümü yan yana duruyor: v1 OData 3.0 üzerine kurulu ve geriye uyum için, v2 ise OData 4.0 üzerine kurulu ve önerilen sürüm. FP 2405 itibarıyla OData v3 kullanımdan kaldırılmış sayılıyor — yani v1 üzerinden konuşan entegrasyonlar sürpriz bir şekilde değil, ilan edilmiş bir yol haritasının sonunda çalışmayı bırakacak. Yeni işlerde karar net: v2 üzerine yazılır. Mevcut bir entegrasyonunuz varsa bu acil durum değil ama takvim kalemi; geçişi kendi planınızla yapmak yükseltme baskısı altında yapmaktan çok daha ucuz. Biz de önce bir tespit turu öneriyoruz — bu turu entegrasyonu biz yazmamış olsak da yapıyoruz.
Saniyede kaç istek atabiliriz, limit nedir?
Yayımlanmış bir istek sınırı veya aşım davranışı bulamadık, bu yüzden burada rakam yazmıyoruz — olmayan bir sınırı uydurmak entegrasyon planını çürük temele oturtur. Service Layer mimari olarak önünde yük dengeleyici bulunan ve paralel işlemeyle ölçeklenen bir yapı; ama gerçek eşik kurulumun donanımına, yama seviyesine ve eşzamanlı kullanıcı yüküne bağlı. Bu yüzden entegrasyonu baştan temkinli yazıyoruz: yeniden deneme ve kademeli bekleme devrede, toplu aktarımlar kontrollü partiler halinde gidiyor ve gerçek eşiği devreye alma öncesinde yük testiyle ölçüyoruz.
Fabrikamız Adana’da. Yerinde çalışır mısınız?
Evet. Adana, Mersin merkezden yerinde çalıştığımız Akdeniz hattında; Tarsus, Hatay, İskenderun ve Osmaniye de aynı kapsamda. Keşif, hat tespiti (MS SQL mi, HANA mı) ve üretim sahasındaki terminal kurulumu yerinde yapılır. Service Layer geliştirmesi ise nerede olursanız olun uzaktan yürür; Türkiye’nin diğer illerinde başlangıç online keşif, saha montajı gerekirse seyahat takvime baştan yazılır.
Hangi programı kullandığınızı, sahada hangi verinin elle girildiğini ve neyi otomatikleştirmek istediğinizi anlatın. İlk görüşmede teknik olarak mümkün olup olmadığını ve hangi yöntemle yapılacağını netleştiriyoruz.
Bu sayfada adı geçen ürün ve markalar ilgili firmaların tescilli ticari markalarıdır. D'Cloud Software bağımsız bir yazılım geliştiricisidir; anılan firmaların yetkili bayisi, çözüm ortağı veya iş ortağı değildir. Entegrasyon hizmeti, ürünlerin kendi belgelenmiş arayüzleri ve veri erişim yöntemleri üzerinden sunulur.