Dynamics 365 Business Central Entegrasyonu

Çevrim içi mi, yerinde mi? Cevap entegrasyonun tamamını değiştiriyor

Business Central entegrasyonlarında ilk ayrım modül değil, kurulum biçimi. Çevrim içi sürümde ürün Microsoft’un bulutunda çalışır ve müşterinin veritabanına erişimi yoktur; ayrıca ortam başına toplam veri boyutu için 3 TB’lık teknik bir tavan tanımlıdır; lisansla gelen depolama kapasitesi bu tavandan ayrı hesaplanır. Yerinde kurulumda ise ürün SQL Server üzerinde çalışır ve sunucu tarafında Named Pipes ile TCP/IP protokollerinin etkin olması gerekir.

Bu ayrım, entegrasyonun yalnızca bağlantı biçimini değil, sürüm stratejisini ve operasyon modelini de belirliyor. Çevrim içi tarafta güncelleme takvimi Microsoft’un elinde; yerinde kurulumda ise yükseltme kararı sizde ama sorumluluk da sizde. Birinde entegrasyonu değişime dayanıklı yazmak zorundasınız, diğerinde yükseltme öncesi regresyon turu planlamak.

Buna karşılık iyi haber şu: API yüzeyi tarafında ikisi büyük ölçüde aynı dili konuşuyor. Yani doğru kurulmuş bir entegrasyonun iş mantığı, kurulum biçimi değişse bile büyük ölçüde korunabiliyor. Bunun şartı, çağrı katmanının iş kurallarından ayrılmış olması — bunu tasarımın en başında yapıyoruz, sonradan eklemek kolay olmuyor.

Microsoft’un kendi cümlesi: mümkün ama desteklenmiyor

Yerinde kurulumda SQL Server erişilebilir durumda olduğu için “sunucuyu atlayıp doğrudan veritabanına bağlanalım” fikri sık gündeme geliyor. Microsoft bu konuda yorum bırakmamış: SQL Server nesneleriyle doğrudan, Business Central Server’ı atlayarak entegre olmanın mümkün olduğunu, ancak tavsiye edilmediğini, hatta desteklenmediğini yazıyor.

Gerekçe de soyut değil, iki somut sonuç üzerinden anlatılıyor. Birincisi: Business Central Server’ın oluşturduğu SQL nesnelerini doğrudan değiştirmek, yükseltme sürecini ve uygulama/uzantı senkronizasyonunu bozabilir. İkincisi: veritabanına doğrudan tetikleyici ya da saklı yordam eklemek hem yükseltme ve senkronizasyonu bozabilir, hem de Business Central senkronizasyonu tablo şemasını değiştirdiğinde o nesnelere bağlı entegrasyonları kırar.

Bu ikinci maddenin altını çizmek gerekiyor, çünkü Business Central’ı diğer ERP’lerden ayıran nokta burada. Bu üründe şema, yalnızca sürüm yükseltmesiyle değil, uzantı senkronizasyonuyla da değişebiliyor. Yani bir uzantı kurulduğunda veya güncellendiğinde tablo yapısı değişebilir ve doğrudan veritabanına bağlanmış bir entegrasyon, hiç kimse “yükseltme yaptık” demeden çalışmayı bırakabilir.

API v2.0, OData ve SOAP: üçü de var, biri öneriliyor

Business Central tarafında dışarıya açılan birden fazla yüzey var ve hangisini seçtiğiniz entegrasyonun ömrünü doğrudan etkiliyor. Bizim varsayılanımız API v2.0 — OData v4 üzerine kurulu, sürümlü ve Microsoft’un önerdiği yüzey. Çevrim içi tarafta üretim ortamının ortak uç noktası https://api.businesscentral.dynamics.com/v2.0/production/api/v2.0 kalıbını izliyor.

Yanında OData web servisleri ve SOAP web servisleri de duruyor. SOAP tarafı için Microsoft açık bir uyarı yazmış: bu yüzeyin verimini düşüreceğini ve ileride kullanımdan kaldıracağını belirtiyor. Yani SOAP üzerine kurulan yeni bir entegrasyon, doğduğu gün bir son kullanma tarihiyle doğuyor. Elinizde SOAP üzerinden çalışan eski bir entegrasyon varsa bu acil durum değil ama takvim kalemi — geçişi baskı altında değil, kendi planınızla yapmak çok daha ucuz.

Seçim sadece “hangisi modern” meselesi de değil. API v2.0 sürümlü bir yüzey olduğu için değişiklikler yönetilen bir şekilde geliyor; OData web servisleri ise doğrudan sayfa nesnelerine bağlı olduğu için o sayfanın değişmesinden etkilenebiliyor. İhtiyacınız standart API’nin kapsamadığı bir alansa, doğru çözüm SOAP’a dönmek değil, özel API sayfası tanımlamak oluyor — bu, uygulama ortağınızla birlikte yürütülen bir iş.

Kimlik doğrulama: erişim anahtarları dönemi çevrim içi tarafta kapandı

Business Central’da önerilen kimlik doğrulama yöntemi OAuth 2.0 ve Microsoft Entra ID. Bu bir tercih önerisi değil, çevrim içi tarafta fiilî zorunluluk: Ekim 2022’den itibaren web servis erişim anahtarları, yani temel kimlik doğrulama yöntemi, çevrim içi Business Central’da kullanımdan kaldırıldı ve desteklenmiyor. Yerinde kurulumlarda bir süre daha kullanılabiliyor.

Bu, eski entegrasyonları olan firmalar için somut bir kontrol maddesi. Yıllar önce yazılmış ve hâlâ çalışan bir entegrasyon varsa, hangi yöntemle kimlik doğruladığını bilmek gerekiyor. Yerinde kurulumdan çevrim içine geçiş planlıyorsanız bu madde geçişin ilk sıralarında yer almalı — sonradan fark edilen bir kimlik doğrulama bağımlılığı, göç planının en can sıkıcı sürprizi oluyor.

Sık sorulan bir soruya da burada cevap verelim: uygulama kullanıcısı, yani hizmet sorumlusu ile normal bir kullanıcı arasında operasyonel limitler açısından bir fark yok. İkisi de aynı istek limitlerine tabi. Bu, kapasite planlamasını doğrudan etkileyen bir bilgi ve bir sonraki bölümün konusu.

Kimlik bilgileri ve gizli anahtarlar her koşulda sunucu tarafında, erişimi sınırlı bir sır yönetimi katmanında tutulur. Kod deposuna, düz metin yapılandırma dosyasına veya istemci tarafına yazılmaz. Bu, tercih değil asgari koşul.

Limitler yayımlanmış: kapasiteyi tahmin etmiyoruz, hesaplıyoruz

Bu bölüm, Business Central’ı diğer ERP’lerden ayıran yer. Çoğu üründe “saniyede kaç istek atabiliriz” sorusunun cevabını yük testiyle bulmak zorunda kalıyoruz. Microsoft burada sayıları yayımlamış — bu da kapasite planlamasını tahminden çıkarıp hesaba dönüştürüyor.

Aşağıdaki tablo, entegrasyon tasarımını doğrudan etkileyen limitleri ve aşıldığında dönen yanıtı bir arada gösteriyor. Bunlar bizim ölçtüğümüz değerler değil, üreticinin yayımladığı değerler; sizin kurulumunuzda geçerli olan ortam tipine göre değişen satırları keşifte birlikte netleştiriyoruz.

Webhook: el sıkışmasını atlarsanız abonelik hiç kurulmaz

Business Central, bildirim tarafını bu listedeki ürünler arasında en net tanımlayan ürün. Abonelik, ortamın API adresine yapılan bir istekle oluşturuluyor; istek gövdesinde bildirim adresi, izlenecek kaynak ve entegrasyonun kendi tanımladığı bir durum bilgisi taşınıyor.

Kritik nokta el sıkışma adımı. Abonelik oluşturulurken Business Central, verdiğiniz bildirim adresine bir doğrulama jetonuyla istek atıyor ve abone tarafın bu jetonu yanıt gövdesinde aynen geri döndürüp başarılı bir yanıt vermesi gerekiyor. Bu adım tamamlanmazsa abonelik kurulmuyor. Webhook entegrasyonlarının klasik hatası tam olarak burada: uç nokta yazılıyor, jeton yok sayılıyor ve “webhook çalışmıyor” diye günlerce başka yerde sorun aranıyor.

İkinci kritik nokta aboneliğin ömrü. Abonelik süresiz değil; yenilenmediği takdirde varsayılan olarak üç gün sonra düşüyor. Yani bir kez kurup unutulacak bir yapı değil — entegrasyonun kendi aboneliklerini takip edip zamanında yenilemesi gerekiyor. Bunu bir arka plan görevi olarak kurguluyor ve yenileme hatalarını izleme paneline bağlıyoruz. Yenilenmeyen bir abonelik hata üretmez; sadece bildirimler sessizce gelmemeye başlar, ki bu çok daha tehlikelidir.

Üçüncüsü kapasite: bir ortamda en fazla 200 webhook aboneliği bulunabiliyor. Çok sayıda kaynağı ayrı ayrı izlemeyi planlıyorsanız bu sınırı tasarım aşamasında hesaba katmak gerekiyor.

Son olarak güvenlik: bildirim adresi internete açık olduğu için gelen isteğin gerçekten beklenen kaynaktan geldiğini doğrulamak gerekiyor. Abonelikte tanımlanan durum bilgisi bunun için var ve entegrasyon tarafında doğrulanmadan hiçbir işlem başlatılmıyor.

Değişim yalnızca yükseltmeden gelmiyor

Business Central’da sürüm riski, alışılmış ERP mantığından farklı çalışıyor ve bu farkı kavramamak tipik bir kopma sebebi.

Klasik ERP dünyasında şema bir yükseltmeyle değişir; tarih bellidir, hazırlık yapılır. Business Central’da ise şema, uzantı senkronizasyonuyla da değişebiliyor. Bir uzantı kurulduğunda ya da güncellendiğinde tablo yapısı değişebilir ve buna bağlı entegrasyonlar kırılabilir. Yani “biz yükseltme yapmadık” cümlesi, entegrasyonun neden bozulduğunu açıklamaya yetmiyor. Microsoft’un doğrudan veritabanı entegrasyonunu desteklememesinin en somut gerekçelerinden biri de bu.

Çevrim içi tarafta ikinci bir katman daha var: güncelleme takvimi Microsoft’un elinde ve siz onaylamıyorsunuz. Bu, entegrasyonun “o gün müsait değilim” deme lüksünün olmaması demek. Bu yüzden dayanıklılığı ilk günden koda yazıyoruz — beklenmeyen alanlar yok sayılıyor, eksik alanlar patlamaya değil kayda dönüşüyor, başarısız çağrılar kuyrukta bekliyor ve kademeli beklemeyle yeniden deneniyor.

Bunlara karşı yaklaşımımız üç maddeli. Birincisi: API v2.0 gibi sürümlü bir yüzeye bağlanmak ve sayfa nesnelerine doğrudan bağımlılıktan kaçınmak. İkincisi: uç nokta adresi, sürüm, ortam adı ve kimlik bilgileri gibi değişmeye açık her şeyi yapılandırma katmanına almak, koda gömmemek. Üçüncüsü: uzantı kurulumu ve güncellemesi gibi olayları da bir değişim tetikleyicisi olarak kabul edip, bu durumlarda regresyon turu çalıştırmak.

Teslimden sonraki 15 gün hata düzeltme ücretsizdir. Uzantı takibi, abonelik yenileme sağlığı ve yükseltme öncesi regresyon turu ise tek seferlik değil sürekli işler; bunları bakım hizmeti olarak ayrı fiyatlıyor ve sözleşmede ayrı satırda gösteriyoruz.

Uygulama ortağınızın yerine değil, onun kapsamı dışındaki işte

Business Central kullanan firmalarda tablo genellikle şöyle: bir Microsoft uygulama ortağı kurulumu yapmış, ürün tarafındaki destek yürüyor ve muhasebe ile finans süreçleri oturmuş durumda. Sorun ürünün kendisinde değil — sahada, depoda, üretimde 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 ve konumumuzu baştan net söylüyoruz: Microsoft iş ortağı değiliz, bayisi ya da çözüm ortağı değiliz. Lisans, abonelik, ortam yönetimi, uzantı yayını ve ürün danışmanlığı uygulama ortağınızın alanı ve o alana girmiyoruz. Yaptığımız iş, ürünün belgelenmiş API’si üzerinden yazılan entegrasyon ve dış uygulama geliştirmesi ile onun bakımı.

Bu netlik, kurumsal KOBİ segmentinde bir avantaj: ürün desteğiniz bozulmadan özel bir ihtiyacı karşılıyorsunuz, uygulama ortağınız kendi kapsamı dışındaki bir talebi geri çevirmek zorunda kalmıyor ve biz ürün tarafında taahhüt vermediğimiz için yalnızca gerçekten yapabileceğimiz işi üstleniyoruz.

• Hangi uç noktaların, hangi kaynaklar üzerinde ve hangi sıklıkta kullanıldığı yazılı olarak paylaşılır; uygulama ortağınız kapasite etkisini kendi tarafında görebilir
• Kapasite planı limit tablosuna göre yapılır ve teslim dosyasında raporlanır — beklenen istek hacmi tahmin değil hesap olarak sunulur
• Kendi geliştirme ekibi olmayan uygulama ortakları için taşeron geliştirme modelinde ç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
• Kodun dokümantasyonu, yapılandırma haritası ve abonelik envanteri teslim edilir; iş birliği sonlansa bile elinizde devredilebilir bir varlık kalır