Canias ERP Sürüm Yükseltmesinde Özel Geliştirmeler Nasıl Korunur?

Canias Sürüm Yükseltmesi Özel Geliştirmeleri Neden Riske Atar?

Canias sürüm yükseltmesi, standart yazılımı, çalışma ortamını ve bazen geliştirme araçlarını birlikte değiştirdiği için özel geliştirmeleri riske atar. Özel kod bu üç katmanın üzerinde durur; altındaki herhangi biri değiştiğinde davranışı da değişebilir.

Üreticinin kendi zaman çizelgesine göre caniasERP ana sürümleri 6.01, 6.02, 6.03, 6.04, 8.02, 8.03 ve 9.03 olarak ilerledi; güncel ana sürüm 9.03. TROIA kitabı da 6.02'den bu yana her ana ERP sürümüne karşılık gelen bir TROIA build serisi listeliyor ve build yükseltmelerinin bazen yönetici ya da geliştiricinin elle yapacağı işlemler gerektirdiğini not ediyor. Uzun süre güncellenmemiş bir kurulumda birkaç ana sürüm birden atlanabilir ve aradaki tüm değişiklikler aynı anda karşınıza çıkar.

Risk üç yerde toplanır:

• Standart koda dayanan özel sınıf ve ekranlar: Standart tarafta bir alan, metot ya da ekran değiştiğinde ona yaslanan özel öğe beklenmedik davranabilir.
• Çalışma ortamı: TROIA platformunu anlatan açık kitaba göre lisans sunucusu ve web sunucusundaki Canias bileşeni, uygulama sunucusuyla aynı sürümde olmalıdır; sunucu ve masaüstü istemci Java üzerinde çalışır. Biri eski kalırsa sistem açılsa bile bağlantılar kopabilir.
• Dışarıdan bağlanan uygulamalar: E-ticaret sitesi, bayi portalı, el terminali ve raporlama araçları Canias'a servis üzerinden bağlanır. Bu uygulamalar Canias ekibinin gözü önünde değildir; yükseltme günü ilk onlar sessizce durur.

Canias Özelleştirmeyi Standart Koddan Nasıl Ayırıyor?

Canias'ta özelleştirmenin standart koddan ayrı tutulmasını sağlayan mekanizma, TROIA platformunu anlatan açık kitapta "Cross" adıyla anlatılır. Bu kitap IAS yöneticisi tarafından yazılmıştır, ancak kendini açıkça resmî olmayan bir kitap olarak tanımlar; aşağıdaki bilgiler bu çekinceyle okunmalıdır.

Kitaba göre cross, sınıf ya da diyalog yükleyicisini tanımlı öğe yerine başka bir sınıfı ya da diyaloğu kullanmaya zorlayan bir tanımdır. Bir veritabanı kaydıdır, çalışma anında uygulanır ve derlemeye girmez. İki seviyesi vardır: aynı veritabanına bağlı tüm kullanıcıları etkileyen sistem cross'u ve bir kullanıcıya ya da profile tanımlanan kullanıcı cross'u. Öncelik sırası kullanıcının kendi cross'u, profil ve sistem şeklindedir. Cross zincir hâlinde kurulabilir, döngü ise hatadır. Değişiklik kullanıcı yeniden giriş yaptığında etkili olur. Kitap, bu yolla standart uygulamayı değiştirmeye gerek kalmadığını söyler.

Üretici ne diyor, belge ne söylemiyor?

IAS kendi geliştirme sayfasında, yapılan değişikliklerin standart kodun kendisini değil, ondan türetilen işlevi etkilediğini ve müşteriye özel uyarlamaların güncellemelerden sonra da kaldığını belirtiyor. Türkçe sayfada da standart sınıfların yerine müşteriye özel sınıfların kullanılabildiği anlatılıyor.

Bu bir üretici beyanıdır ve ciddiye alınmalıdır. Ancak cross'ların sürüm yükseltmesi sırasında nasıl davrandığını adım adım anlatan teknik bir belge bulamadık; açık kitap da bu konuya girmiyor. Bu yüzden "uyarlamalarınız her güncellemede sorunsuz kalır" demiyoruz.

Mantıksal olarak bir noktaya da dikkat etmek gerekir. Kitaba göre cross çoğunlukla standart sınıftan kalıtımla türetilen bir sınıfla kullanılır; bu durumda özel sınıf yalnız değiştirdiği (override ettiği) metotları kendisi taşır. Ancak override edilen metot standart metodun eski hâli kopyalanarak yazıldıysa ya da cross kalıtımsız, bağımsız bir sınıfa yönlendiriyorsa, yeni sürümde standart tarafa eklenen düzeltme özel tarafa kendiliğinden geçmeyebilir.

Kitap ayrıca kalıtımın derleme anında çözüldüğünü anlatıyor; bu yüzden yükseltmeden sonra özel öğelerin yeniden derlenmesi gerekip gerekmediği de IAS ile netleştirilmelidir. Bu bizim çıkarımımızdır, kitapta yazan bir kural değildir; sizin kurulumunuzda geçerli olup olmadığı ancak yeni sürümün test ortamında çalıştırılmasıyla görülür.

Diğer ERP'lerde aynı ilke

Özelleştirmeyi standart çekirdekten ayırma fikri Canias'a özgü değildir. SAP, S/4HANA için "temiz çekirdek" yaklaşımında yayımlanmış ve kararlı arayüzleri kullanan uzantıları en güvenli düzey sayar; standart nesnelerde değişikliği ve tablolara doğrudan yazmayı en yüksek riskli düzeye koyar. Ortak ders aynıdır: çekirdeğe ne kadar az dokunulursa yükseltme o kadar öngörülebilir olur.

Özelleştirme Envanteri: Yükseltmeden Önce Neyin Elinizde Olduğunu Bilin

Özelleştirme envanteri, kurulumdaki her özel ekranın, raporun, servisin ve dış bağlantının nerede durduğunu, kimin kullandığını ve nasıl test edileceğini gösteren listedir. Envanter olmadan yükseltme testi, neyi aradığını bilmeden yapılan bir aramadır.

Kitaba göre TROIA'da bir öğeyi (diyalog, sınıf vb.) değişiklik talebi olmadan değiştirmek mümkün değildir ve değişiklikler seçilen "hotline" kaydıyla ilişkilendirilerek loglanır. Bu kayıtlar envanterin iyi bir başlangıç noktasıdır. Cross tanımları da veritabanı kaydı olduğundan listelenebilir; kitaba göre sistem düzeyindeki cross'lar sınıflar için DEVT08, diyalog, rapor ve bileşenler için DEVT09 işlemlerinde, kullanıcı ve profil düzeyindekiler ise kullanıcı tanımında tutulur. Eksik kalan kısım genellikle dış uygulamalardır; onlar Canias'ın içinde değil, başka sunucularda ve başka ekiplerde durur.

Tablodaki "Domain" satırı için bir not: kitaba göre domain, bir kontrolün, tablo alanının ya da veritabanı kolonunun tip, uzunluk ve ondalık gibi temel özelliklerini saklayan yeniden kullanılabilir veri tanımıdır ve değişikliği ilgili kolon ve kontrollere tablo dönüştürme işleminden sonra yayılır. Özel bir alanın uzunluğu ya da tipi yeni sürümde standart bir tanımla çakışırsa etkisi birden çok ekranda görülebilir.

Envanterin her satırı için bir sorumlu kişi yazın. "Bu raporu kim kullanıyor?" sorusunun cevabı yoksa, o rapor ya gerçekten kullanılmıyordur ya da kullanan kişi yükseltmeden sonra sorunu ilk fark eden olacaktır.

Dış Uygulamalar Kırılmasın: Servis Katmanını Sabit Tutmak

Dış uygulamaların kırılmamasının en güvenilir yolu, onların çağırdığı servis imzasını sabit tutmak ve Canias tarafındaki değişikliği servisin arkasında karşılamaktır. Dış uygulama yalnız servisin adını, parametrelerini ve cevabını bilir; bunlar değişmediği sürece içerideki değişiklik ona yansımaz.

Canias'ın belgelenmiş dış arayüzü TROIA Web Service'tir. Açık kitaba göre servis, web servisi olarak kaydedilmiş bir TROIA sınıf metodudur ve WSDL ile tanımlanır; parametre ve cevaplar XML'dir. W3C'nin tanımıyla WSDL, ağ servislerini mesajlar üzerinde çalışan uç noktalar olarak tarif eden bir XML biçimidir. Yani WSDL, dış uygulamayla aranızdaki yazılı sözleşmedir.

Yükseltmede bu sözleşmeyi korumak için:

• İmzayı dondurun: Dış uygulamanın çağırdığı servis adı, parametreleri ve cevap alanları yükseltmeden önce yazılı hâle getirilir. Yeni sürümde iç sınıf değişse bile servis aynı imzayla cevap verecek şekilde uyarlanır.
• Değişikliği sürümleyin: İmzada kırıcı bir değişiklik kaçınılmazsa eski servis bir süre yaşatılır, yenisi farklı adla açılır. Anlamsal Sürümleme belgesi de geriye dönük uyumsuz bir değişikliğin ana sürüm numarasını artırması gerektiğini söyler; ilke aynıdır.
• Servis sürümünü kontrol edin: Kitaba göre web servisi 1.0 kullanımdan kaldırılmış, yeni projeler için 2.0 öneriliyor; ikisi de 5.01.01 sonrasında destekleniyor. Dış uygulamalarınızın hangisini kullandığını bilmek, yükseltme planının parçasıdır.
• Web sunucusu bileşenini unutmayın: Kitaba göre web sunucusuna konan Canias bileşeni (canias1.jar), uygulama sunucusuyla aynı sürüm ve build'de olmalıdır. Uygulama sunucusu yükseltilip bu bileşen eski kalırsa servisler çalışmayabilir.

Dış uygulama ile Canias arasına ince bir ara katman koymak bu işi kolaylaştırır. Ara katman dış dünyaya sabit bir arayüz sunar, Canias tarafındaki değişikliği tek yerde karşılar ve hata kayıtlarını tutar. Canias entegrasyonu işlerinde bu katmanı kuruyor ve servisleri yükseltmeyi kaldıracak şekilde tasarlıyoruz.

Canias Güncellemesi Öncesi Kontrol Listesi ve Regresyon Testi

Canias güncellemesi öncesinde sürüm notları okunur, çalışma ortamı gereksinimleri doğrulanır, yeni sürüm test ortamına kurulur ve envanterdeki her kalem orada denenir. Canlı sistemde ilk deneme yapılmaz.

Kontrol listesi

Sürüm notları için kitap üç yer sayar: ReleaseNotes.txt dosyası, "SYST17 - Release Notes" uygulaması ve Workbench. Java konusunda kitap 1.8'in yaygın olduğunu, Java 21 ve OpenJDK 11'in ise daha az kullanılsa da tam uyumlu olduğunu yazıyor; hedef sürümün gereksinimi IAS'tan teyit edilmelidir. Geliştirme ortamı tarafında da bir işaret var: IAS Business Academy takviminde "caniasERP Versiyon 9.03 Yeni Geliştirme Ortamı Eğitimi" bulunuyor. Ekibiniz TROIA ile geliştirme yapıyorsa bu değişikliği yükseltmeden önce öğrenmesi gerekir.

Neden önce test ortamı?

Üretici, mevcut uygulamaları düzenlemek için sistemi yeniden başlatmak gerekmediğini ve canlı ortamda TROIA IDE ile uzaktan geliştirme yapılabildiğini belirtiyor. Bu, günlük işlerde büyük kolaylıktır; yükseltme döneminde ise risktir. Canlıya yapılan bir düzeltme o anda herkesi etkiler. Bu yüzden canlı sisteme doğrudan kod yazmıyoruz; her değişiklik önce test ortamında denenir.

Regresyon testi

Regresyon testi, ISTQB sözlüğündeki tanımıyla, bir değişikliğin yazılımın değişmeyen bölümlerinde hata oluşturup oluşturmadığını ya da var olan bir hatayı açığa çıkarıp çıkarmadığını bulmaya yönelik testtir. Sürüm yükseltmesi tam olarak bu durumdur: özel ekranlarınız değişmedi, altlarındaki zemin değişti.

İyi bir regresyon turu için:

1. Envanterdeki her kalemin test senaryosu yazılı olur.
2. Test ortamına canlıdan alınmış, kişisel verileri maskelenmiş bir veri kopyası yüklenir.
3. Raporlar için bilinen bir dönemin eski sürümdeki sonuçları saklanır ve yeni sürümdekilerle karşılaştırılır.
4. Dış uygulamalar test ortamındaki servise bağlanıp gerçek akışlarını tekrarlar.
5. Bulunan her fark kayda geçer ve kapanmadan canlıya geçiş tarihi verilmez.

Bakım Anlaşması ile 15 Gün Ücretsiz Hata Düzeltme Arasındaki Fark

Teslim sonrası 15 gün ücretsiz hata düzeltme, teslim ettiğimiz kodda o süre içinde çıkan kusurları kapsar; ileride gelecek Canias sürümlerine uyum ise ayrı bir bakım anlaşmasının konusudur. İkisi sık karıştırılır ve yükseltme döneminde bu karışıklık en pahalı hâline ulaşır.

Masada aslında üç ayrı sözleşme vardır:

Üretici, Canias bakım sözleşmesi olan müşterinin uygulamanın kaynak koduna erişebildiğini belirtiyor. Yükseltmede eski ve yeni standart kodu karşılaştırabilmek için bu erişim değerlidir; ne kadarının size açık olduğu IAS'la yaptığınız lisans ve bakım sözleşmesinin kapsamına bağlıdır ve IAS ile netleştirilir.

Bizim tarafımızda kural basittir. Teslim ettiğimiz ekran ya da servis teslim sonrası 15 gün içinde hata verirse ücretsiz düzeltiriz. Bir yıl sonra Canias yeni sürüme geçtiğinde özel geliştirmelerin yeni sürüme uyarlanması bu kapsamda değildir; bunu baştan ayrı bir bakım anlaşmasıyla planlamak, yükseltme günü sürprizle karşılaşmaktan daha sağlıklıdır.

Sıkça Sorulan Sorular

Canias sürüm yükseltmesinde özel geliştirmelerim silinir mi?

IAS, müşteriye özel uyarlamaların güncellemelerden sonra korunduğunu belirtiyor. Ancak bu mekanizmanın yükseltme sırasındaki davranışını anlatan teknik bir belge bulamadık. Uyarlamaların sizin kurulumunuzda nasıl davrandığı, yeni sürümün test ortamında envanterdeki senaryolarla denenmesiyle görülür.

Cross nedir, özel geliştirmeyi nasıl ayırır?

TROIA platformunu anlatan açık kitaba göre cross, sistemin tanımlı bir sınıf ya da diyalog yerine başka bir sınıfı ya da diyaloğu kullanmasını sağlayan bir veritabanı kaydıdır. Böylece standart öğe değiştirilmeden yerine özel öğe kullanılır. Kitap resmî değildir ve cross'ların yükseltmedeki davranışını anlatmaz.

Yükseltmeden sonra e-ticaret sitemizin bağlantısı kopar mı?

Kopabilir, ama önlenebilir. Dış uygulamanın çağırdığı servisin adı, parametreleri ve cevabı sabit tutulur, web sunucusundaki Canias bileşeninin uygulama sunucusuyla aynı sürümde olduğu kontrol edilir ve bağlantı test ortamında denenir. Bu adımlar yükseltme planına baştan yazılmalıdır.

Canias güncellemesini siz mi yapıyorsunuz?

Hayır. Canias'ın kendisinin yükseltilmesi, lisans ve sürüm konuları IAS ile sizin aranızdadır. Biz özel ekran, rapor ve servislerin envanterini çıkarıyor, test senaryolarını yazıyor ve özel geliştirmeleri yeni sürüme uyarlıyoruz.

Envanteri çıkarmak için nereden başlamalıyız?

Kitaba göre TROIA öğelerindeki değişiklikler hotline kaydıyla ilişkilendirilerek loglanır; bu kayıtlar ve cross tanımları iyi bir başlangıçtır. Ardından Canias'a bağlanan dış uygulamalar tek tek listelenir ve her kaleme bir kullanıcı ile bir test senaryosu yazılır.

Sonraki Adım: Envanterle Başlayın

Yükseltme tarihi belli olmadan önce yapılabilecek en değerli iş, özelleştirme envanterini çıkarmaktır. Yukarıdaki tabloyu kendi kurulumunuz için doldurmaya başlayın; boş kalan satırlar, yükseltme planının en riskli yerlerini gösterir.

Mersin merkezli yazılım ekibi olarak Canias kullanan işletmelere ERP entegrasyonu ve Canias ERP entegrasyonu tarafında destek veriyoruz: özelleştirme envanterini çıkarıyor, servis katmanını sabitliyor ve özel geliştirmeleri test ortamında yeni sürüme uyarlıyoruz. IAS'ın bayisi değiliz; lisans ve yükseltme takvimi IAS ile sizin aranızda kalır. İlk keşif görüşmesi online ve ücretsizdir; kapsam yazılı netleşir, sabit fiyatla çalışılır ve teslim sonrası 15 gün ücretsiz hata düzeltme sözleşmede yer alır. Yükseltme öncesi durumu birlikte değerlendirmek için iletişime geçin; isterseniz WhatsApp'tan da yazabilirsiniz.