SAP ERP reqeust system-sistem landscape-mimarisi nedir ?

SAP ERP  R2/R3  system landscape – sistem mimarisi genel olarak üç tane sistem den oluşmaktadır. DEV- QAS ve PROD

Alman mühendislerin 1980 yıllarda başarılı ciddi computer engineer (bilgisayar mühendisliği) yaptığı işlerden biride SAP ERP yazılımıdır.

Bu mimarinin kendi literatüründen bir çok yenilik getiren kendine münhasır yaklaşımı sistemin sağlamlığının temelini oluşturmaktadır.

En başlıca reqeust  denilen terminolojik kavramdan biraz bahsedeyim ki bu DEV-QAS-PROD mimarisini sizlere daha iyi anlatabileceğimi düşünüyorum.

Temel de universal (genel kabul görmüş) yani classic  program geliştirme mimarisinde, aslında bir mimari yoktur da diyebiliriz 🙁  kaynak kod ve bu kodun derlenmesi ile üretilen excutable kod vardır. Bir geliştirici (developer) kaynak kodları genelde kendi bilgisayarında saklar ve birden fazla developer’ın aynı geliştirme ortamında çalışması yılların en eski versiyon yönetim sorunlarından biriydi. Buna örnek vermek gerekir ise Qbasic turbo pascal ile geliştirilen text screen (metin yazısı görselindeki programlar) visual programlamaya da visual basic, delphi, en güncel teknoloji olan Microsoft Visual .Net diyebiliriz. gerçi şuadan microsoft’unda versiyon yönetim mimarisi var ama ne kadar yeterli, tartışılır. 🙁

Bir diğer web programlama dillerinde ise durum cidden vasat çünkü herşey bir script dosyasından ibaret sadece web sunucu servisi kodu derleyerek HTML CSS ve Javascript gibi internet tarayıcının (browser) anlayacağı dile çeviriyor. bir web sitesi nin kodu aslında yüzlerce bincerce kod içeren sayfalardan ibaret 🙂  bir hata giderme işlemi (debug) veya yeni bir özellik için geliştirme yapmak çok dev projelerde birden fazla geliştiricinin çalışmasının yol açacağı karmaşıklığa, ve işleri aslında hataları daha da çıkılmaz kılıyor.

SAP AG yeni adı ile SAP SE mühendisleri kafayı kırıp bundan 20 yıl önce bu olayı düşünüp çözmüşler , SAP ERP sisteminin gelişiminde ve müşterinin ihtiyaç duyduğu kendi ek geliştirmeler (programlar, raporlar) için de kullanılan bu versiyon yönetim sisteminin adına terminolojik olarak request  deniliyor. Aslında STMS de denilir.

STMS – Transport Management System

Yapılan bir geliştirmedeki programsal  değişiklikleri (kodsal,objesel,gib gibi) tamamının versiyon paketi olarak request denilen bir referans numara ile takibi ve diğer sitemlere taşınmasının topluca yapılmasını sağlayan paket gibi düşüne biliriz.

Transport yani taşıyıcı demek kamyon simgesi ile bütünleştirilmiş bir icon a sahip.

Genel SAP önerilen sistem mimarisi DEV yani devlopment  QAS  Quality Assurance System yani kalite yönetim sistemi ve en son olarak da PRO yada PROD diye adlandırılan Production canlı live sistemdir. STMS ise tam bu arada devreye giriyor . şimdi bu üç sistemin aslında bir sistemin kopyası olduğunu düşünün DEV = QAS = PROD  veri tabanı bilgiisi ve application uygulama bilgisi olarak eşitler.

Birinin instance DEV diğerinin ki QAS ve gerçek müşterilerin kullandığı canlı sistem ise PROD. PROD an itibari ile veri değişikliğine maruz çünkü yeni fatura kesimi yeni sipariş gibi tüm hareketlerden kullanılan bir sistem olması münasebeti ile  DEV=QAS<PROD  bunu ana veri değişikliği olarak ifade ediyorum ve programların versiyonlarının da aslında hala DEV = QAS = PROD olduğunu var sayıyoruz.

İşte PROD sisteminde kullanıcılar müşteriler her neyse sistemi kullanan grup kitlesi bir hata buluyor ve ilgili çözüm birimlerinden konu bilgi işlem geliştirme uzmanlarına geliyor, hata analizi için DEV veya QAS kullanılıyor aslında hata PROD dada bakıp bulabilirler bir bakış açısı ile PROD hatanın kaynağı ise PROD bakmak en çabuk sonuca ulaştırır ama sistemler aynı seviyede versiyon olarak ama belkide sorunu (hatayı) canlıdaki yeni oluşan ana veri yapıyordur. O zaman PROD da bakmak hata tespiti için en doğrusu hatanın senaryosu öğrenildikten sonra QAS sisteminde aynı hatanın farklı senaryoları üretilebilir (hatanın kaynağındaki sorunun anlaşılabilmesi için). Artık ana verisel olarak DEV =<>QAS  < PROD oldu ama versiyon olarak ise hala DEV = QAS = PROD eşitler.

PROD sistemindeki hatayı gidermek, için yeni bir kodlama yapılacak  hata veren programın kaynak kodunda ilgili düzelmenin yapılacağı ilk sistem DEV sistemi yani developerlar sadece DEV yetkili geliştiricilerdir. QAS ve PROG kaynak koduna müdehale edilemeyen kapalı soruce sistemlerdir.

DEV ise kaynak kodunda değişiklik yapılan ve yapılan değişikliğin reqeusti alınarak tüm değişiklikler bir pakette DEV346107 gibi bir request numarası aldına obje obje alınır. bu versiyon daki release denilen bir işlem gerçekleşene kadar yani requestin release edilmesi yani QAS sisyemine taşınması için versiyonun kapatılması gibi düşünebilirsiniz DEV de yapılan değişiklik bitince developer tüm yaptığı işlemlerdeki requesti release eder. bölyece değişiklik paketi DEV — > QAS  sisteminin kuyruğuna gider. STMS  ekranından QAS kuyruğuna gelen paket taşınır yani transport işlemi bu sebepten deniliyor .artık DEV sisteminde yapılan değişiklik yani yeni versiyon QAS dedir .

kodsal olarak  DEV=QAS >PROD   yani dev ile qas deki hatalı program yeni sürümündedir, ama prod ise hala eski sürüm dedir. bunun sebebi de QAS sisteminde ilgili birimin testleri yapıp onay verdikten sonra PROD sisteme taşınmasının onaysal güvenli bir süreçten geçirilmesi uygun değil ise yani başka hatalar yada hata giderilmemiş de olabilir o zaman yine DEV de yeni bir sürüm QAS testler şeklinde bu süreç döner taki QAS onayı ilgili sorumlu testerlardan (test eden anahtar kulalnıcılar) alınınca bu request QAS sistemindende PROD sistemine STMS ekranı ile taşınır.

STMS aslında SAP basis yani sistem yöneticilerinin kullandığı teknik bilgi işlem sorumlusu yönetim ekranıdır SAP her ekranın bir TCODE vardır yani transaction code işlem kodu  reqeust leri taşıyan bu ekran kodu STMS dir . SAP sistemini dünya ERP lideri yapan ve tutarlı hata payını en aza indiren 20 yıl önce günümüze ön görülen bu Alman mimarisidir aslında SAP sisteminde una benzer ciddi kendine münhasır diğer programlama mimarilerinde olmayan bir kaç olay var benim mühendisliğim de hayrete düşüren. Bunları da ayrıca bir yazıda toplayacağım adına da SAP SAP yapan mimarisel yada mühendislik abidesi yapılar diyebiliriz. Bu mimariyi kurmasaydı Almanlar, SAP bugünkü popülerliğine ve sağlamlığına güven veremediğinden dünya ERP lideri kesinlikle olamazdı bu benim kanaatim. SAP 20 yıl önceki bu mimariler ile günümüz teknolojik gelişimlerine ne kadar ayak uydurabiliyor ? bu da ayrı bir tartışma konusu , SAP artık hantal mı ? dünyanın gerisinde mi kalıyor ? mimari tam da kullanılabilirlikteki kullanıcı dostluğu ne kadar gelişti ? gibi gibi sorulara da ayrıca makale konusu olur. İşte bu sorunları çözmesi beklenen SAP S4HANA yeni bir SAP sürümü , 20 yıl sonra bazı mimarisel değişimler şart . temeldeki  reqeust mimarisi kesinlikle değişmeyecek ama üstündeki bazı mimariler değişiyor.

Özetlersek :

DEV : Development (geliştirme ortamı da diyebiliriz) sistemi tüm program geliştiricilerine açık ve kodlarlardaki değişikliklerin yapıldığı geliştirme sistemi diyebiliriz. Program kodları hep server (sunucu) üzerinde ve aslında hiç bir programcının bilgisayarında (client- istemci)  kod yok yani versiyon hatası oluşma riski sıfır 🙂

QAS : Programın test edileceği ana verinin PROD da en yakın verilerle test edilmesine olanak sunan, kalite yönetim sistemi denmesinin de sebebi bu olasa gerek. Geliştiriciye güvenerek hiç bir program kodu ve değişikliğinin canlıya yansıtılmadığından, asıl kullanıcın bazı testleri yapıp onayı alınmasından kaynaklı da, aslında sorumluluk da bir nevi kullanıcıya atılıyor da diyebiliriz. Programcılar biraz daha rahat. Kodlara müdahale kapalıdır. DEV deki reqeust paketi release edilerek değişiklikler STMS ile QAS paket olarak taşınır.

PROD : Production yani  live sistem yada canlı da kullanılan tüm operasyonun ( ERP operasyonun ) kullanıldığın koduna müdahalenin her zaman kapalı olduğu değişikliklerin sadece QAS test onayı alınanların aktarılması ile yeni versiyonların QAS den PROD taşınması ile PROD üzerinde değişiklik yapılabilir direkt bir kodsal müdahale  asla yapılamaz.  (bir geliştirici müdahale edemez.) Geliştiriciler hatayı anlamak için DEBUG yani hata ayıklamasını sadece okuma yetkisi ile yapabilirler.

Not : QAS sisteminin daha sağlıklı test sonuçları verebilmesi için, Sürekli verisi değişen PROD sistemi nin belli periyotlarda QAS verileri ile verisel anlamda eşitlenmesinin yapılması gerekmektedir. Bu işlem QAS kalitesinin artması için yapılması gereken bir operasyondur.  Bazen PROD komple kopyalanıp QAS ile de yer değiştirilebilir. Bu SAP basis dünyasında homojen kopyalama işlemi (homogeneous copy) denir.

SAP yi SAP yapan REQUEST mimarisi ile SAP instance landscape literaterünü sizlere elim döndüğünce anlatmaya çalıştım. SAP sisteminin ERP nin ne olduğunu bildiğiniz var sayıyorum. bu kavramlarda bilgi sahibi olmayanlar anlamakta biraz güçlük çekebilir SAP nedir ? neden sap adlı diğer makalelerimi önceden okuyup konuya vakıf bilgi edinilmesi bu yazının anlaşılabilirliği için önem arz etmektedir esen kalın.