Business Central kutudan çıktığı haliyle çok geniş bir alanı kapsar. Çoğu şirket, tek bir satır AL kodu yazmadan uygulamayı tamamlar. Ama er ya da geç — genellikle canlıya geçişten altı ay ila bir yıl sonra — biri, standart BC'nin desteklemediği bir iş akışıyla karşılaşır ve soru şuna dönüşür: iş sürecini yazılıma mı uydurmalı, yoksa işletmeye uyan bir şey mi inşa etmeli?
Özel uzantı geliştirmenin gündeme geldiği nokta tam olarak burasıdır. İşte konuyu nasıl değerlendirmek gerektiği.
Gerçekten özel bir uzantıya ihtiyacınız olduğunu nasıl anlarsınız
Her boşluk özel kod gerektirmez. Bir geliştirme projesini kapsamlandırmadan önce, daha ucuz seçenekleri elemekte fayda var:
- Konfigürasyon — "özel bir özelliğe ihtiyacımız var" taleplerinin çoğu, aslında kimsenin henüz yapmadığı bir kurulum veya yetki değişikliği olduğu ortaya çıkar.
- Bir AppSource uzantısı — ihtiyacınız yeterince yaygınsa, muhtemelen biri bunu zaten geliştirip yayınlamıştır. Hazır bir uzantı neredeyse her zaman özel geliştirmeden daha ucuz ve hızlıdır, üstelik sürekli güncellemeler de dahildir.
- Bir geçici çözüm süreci — bazen mevcut alanları biraz farklı kullanmak, hiçbir geliştirme yapmadan sorunu çözer.
Özel geliştirme, yukarıdakilerin hiçbiri geçerli olmadığında maliyetini karşılar — iş akışınız işletmenize o kadar özgüyse (belirli bir onay zinciri, başka kimsenin kullanmadığı bir sistemle entegrasyon, standart BC'nin tasarlanmadığı bir maliyetlendirme ya da planlama modeli) hazır bir çözüm mevcut değildir.
Özel uzantı geliştirme gerçekte neyi kapsar
Doğru inşa edilmiş bir AL uzantısı, Business Central'a eklenmiş bir betikten ibaret değildir — BC'nin yılda iki kez gerçekleşen güncelleme döngüsünü bozulmadan atlatacak şekilde tasarlanır. Bu ayrım, çoğu alıcının başta fark ettiğinden daha önemlidir. Hızlı bir düzeltme ile sürdürülebilir bir uzantı arasındaki fark genellikle şuna dayanır:
- Doğrudan nesne değişikliği yerine uzantı noktalarının kullanılması, böylece Microsoft'un güncellemeleri değişikliklerinizin üzerine yazmaz veya onlarla çakışmaz
- Hiç yayınlamayı düşünmediğiniz uzantılar için bile AppSource teknik yönergelerine uyulması, çünkü bu yönergeler uzantıları yükseltmeye dayanıklı tutmak için vardır
- Herhangi bir şey production'a dokunmadan önce BC'nin sandbox ortamına karşı düzgün test yapılması
- Dokümantasyon, böylece uzantı, ilk geliştiricinin ayrılmasıyla birlikte kara kutuya dönüşmez
Bunlardan herhangi birinin atlanması, genellikle bir BC güncellemesinden sonra bozulan bir uzantı olarak kendini gösterir — o noktada "ucuz" geliştirme, düzgün inşa edilmiş bir sürümün baştan maliyetinden daha fazlasına, acil düzeltmeler şeklinde mal olmaya başlar.
Genellikle ne kadara mal olur
Maliyet büyük ölçüde kapsama bağlıdır, ancak birkaç kaba kategori beklentileri netleştirmeye yardımcı olur:
- Küçük, bağımsız uzantılar (özel bir alan, bir rapor düzenlemesi, basit bir doğrulama kuralı) — yelpazenin en hafif ucu, genellikle birkaç günlük iş.
- İş akışı uzantıları (özel onay süreçleri, belge özelleştirmesi, orta düzey iş mantığı) — karmaşıklığa ve iş akışının ne kadar test gerektirdiğine bağlı olarak birkaç haftalık geliştirme.
- Entegrasyon uzantıları (BC'yi üçüncü taraf bir sistemle bağlamak — bir e-ticaret sitesi, özel bir maliyetlendirme aracı, harici bir API) — genellikle maliyet açısından en değişken olanı, çünkü işin büyük kısmı yalnızca BC tarafına değil, entegre olunan sistemin kalitesine ve dokümantasyonuna bağlıdır.
- Tam özel modüller (standart BC veya herhangi bir AppSource uzantısının kapsamadığı tüm bir işlev alanı) — fiilen küçük bir ürün inşası, buna göre fiyatlandırılır.
Konum da önemlidir. Geliştirme maliyeti pazarlar arasında önemli ölçüde değişir — en yüksek maliyetli bölgelerin dışındaki ekipler, yukarıdaki uzantı noktası ve yükseltme güvenliği pratiklerinden ödün vermeden, aynı AL kalitesini ve AppSource uyumluluğunu anlamlı ölçüde daha düşük oranlarla sunabilir. Kaçınılması gereken tuzak düşük bir fiyat değildir — sürdürülebilirlikten kısılan bir düşük fiyattır, çünkü maliyetin bu kısmı ilk teklifte değil, daha sonra ortaya çıkar.
Özel bir uzantıyı kapsamlandırmak için mantıklı bir süreç
- Keşif — sadece "X'in farklı çalışmasına ihtiyacımız var" değil, iş akışı boşluğunun net ve spesifik bir tanımı. Bu ne kadar spesifik olursa, tahmin de o kadar doğru olur.
- Fizibilite ve seçenekler — özel geliştirmenin gerçekten doğru karar olup olmadığının, bir AppSource uzantısına ya da konfigürasyon değişikliğine karşı doğrulanması.
- Kapsamlı tahmin — belirsiz bir gün ücreti tahmini değil, gerçek gereksinime dayalı sabit veya sınırlı bir tahmin.
- İnşa ve test — sadece bir demo veri seti değil, gerçek veri desenlerinize karşı test edilerek bir sandbox üzerinde geliştirme.
- Dağıtım ve teslim — dokümantasyon dahil, böylece uzantının bakımı tek bir geliştiricinin hafızasına bağlı kalmaz.
Sık Sorulan Sorular
Özel bir uzantı Business Central'ın güncelleme döngülerinde bozulabilir mi? Doğru uzantı noktaları ve AppSource uyumlu pratikler kullanılarak inşa edilmediyse evet, bozulabilir. İyi inşa edilmiş bir uzantı, BC'nin yılda iki kez gerçekleşen güncellemelerini manuel müdahale gerektirmeden atlatacak şekilde tasarlanır; kötü inşa edilmiş bir uzantı ise genellikle her büyük sürümden sonra bir düzeltmeye ihtiyaç duyar.
Bir AppSource uzantısı satın almak mı yoksa özel bir tane geliştirmek mi daha ucuz? Uygun bir uzantı mevcutsa, satın almak neredeyse her zaman daha ucuzdur — geliştirme ve bakım maliyetini o uzantının tüm müşterileri arasında paylaşırsınız. Özel geliştirme, hazır hiçbir şeyin uymadığı durumlarda mantıklıdır.
Özel AL uzantı geliştirmesi ne kadar sürer? Küçük, bağımsız bir değişiklik için birkaç günden, tam bir özel modül için birkaç aya kadar değişir — tahmin, kapsamlandırma/keşif adımından önce değil, sonra gelmelidir.
Özel bir uzantı eklemek için mevcut Business Central kurulumumuzu değiştirmemiz gerekir mi? Hayır — doğru inşa edilmiş bir uzantı eklemelidir. Mevcut temel konfigürasyonunuzu değiştirmeyi gerektirmemelidir; doğrudan nesne değişikliğinin aksine uzantı tabanlı geliştirmenin önemli olmasının nedeni tam olarak budur.
DYNASYS, Microsoft'un AppSource yönergelerini takip ederek Business Central için özel AL uzantıları geliştirir; böylece inşa ettiğimiz her şey her güncelleme döngüsünde sürdürülebilir kalır. Standart BC ya da AppSource'un kapsamadığı bir iş akışı boşluğunuz varsa, bizimle iletişime geçin — herhangi bir teklif vermeden önce özel geliştirmenin gerçekten doğru karar olup olmadığını size dürüstçe söyleyeceğiz.