Alper Somuncu – BlogNotes

Geçtiğimiz yıl Pekin Olimpiyatları’nda 9.69′luk derecesiyle dünya rekoru kıran Jamaikalı, bu rekoru yalnızca bir yıl sonra 11 salise daha geliştirerek, Berlin’de 12. Dünya Atletizm Şampiyonası’nda 100 metre erkeklerde altın madalyanın sahibi oldu. Bolt, tabancanın sesini duyduktan sonra şimşek gibi bir çıkış yaptı.

Rakipleri (?) Asafa Powell ve Tyson Gay önde başlayıp dayanabilmeyi umuyorlardı. Fakat Usain Bolt durmadı. Yalnızca son 20 metrede dönüp Gay’in nerede olduğuna baktı. Bitiş çizgisini gördükten sonra dünya 9:58′i gördü. Tysan Gay, 9:71′lik derecesiyle 2. oldu.

Pekin Olimpiyatları’na kadar 9:71 inanılmaz bir derece sayılabilirdi. Usain Bolt olmasa Tyson Gay bir efsane olabilirdi… Asafa Powell ise 9.84 ile bronz madalyanın sahibi oldu.

İnsanlığın geldi son nokta şimdilik 9:58

Güvenlik ile alakalı bazı SAP note’larını görebilmek ve kolayca sisteme uygulayabilmek amacıyla RSECNOTE uygulamasını kullanıyoruz. Bu uygulamayı SAP sistemine yükleyebilmek için öncelikle SAP Note # 888889’u sisteme yüklememiz gerekiyor. Fakat ilgili OSSnote’unu sisteme yüklemeden önce yapmamız gereken bazı pre-installation adımları mevcut..

Öncesinde SE06: Post-Installation Actions for Transport Organizer transaction’ına girerek burada Standart Installation sekmesi seçiliyken üst menüdeki “System Change Option” seçeneğine giriyoruz.

Gelen ekrandaki Namespace/Name Range kısmındaki Service Software Addon Packages (SSA) ve Service Software Framework (SSF) kısımlarını modifiable olarak işaretlememiz gerekiyor. Aksi halde ilgili note’u sisteme yükleyemeyiz.

Bu kısma OK dedikten sonra /SSA/INT için ana program seçmemiz gerekiyor. Bu seçeneği de /SSA/RTC olarak seçtikten sonra bu uygulamayı derlemeye başlıyor. İşlem bittikten sonra Note #888889’un sisteme sorunsuz bir şekilde implemente edebiliriz.

Yukarıdaki şekilde değişiklikleri yaptıktan sonra kaydedip çıkıyoruz ve SNOTE: Note Assistant transaction’ını yürüterek SAP Note #888889’u yükleyeceğimiz kısmı açıyoruz. Burada SAP Note Download butonuna basarak download edeceğimiz ve yükleyeceğimiz SAP Note’unun numarasını yazıyoruz.

Onayladıktan sonra, eğer SAPOSS bağlantısında bir sorun bulunmuyorsa (ki onun kontrolü de SM59: RFC Destinations transaction’ı ile yapılabilir) ilgili note sisteme indirilip yüklenecek.

Yükleme yaparken note’u varolan bir transaction’a bağlayabiliriz ya da yeni bir transaction yaratarak onun sayesinde diğer sistemlere aktarabiliriz.

Kontrolünü yapmak için ST13:Analysis & Service Tools Launchpad transactionunu yürütüyoruz. Tool name kısmına gelip F4’e bastığımızda gelen ekrandan RSECNOTE seçiyoruz:

Bu adımdan sonra execute butonuna basarak programı çalıştırıyoruz:

Yukarıdaki ekranda görüldüğü üzere Missing recommendations kısmında, yüklememiz gereken SAP Note’larını görüyoruz. Buradaki SAP Note’larını kontrol edip, öncelikle development sistemlere yükleyip test ettikten sonra production sistemlere yine transport etme vasıtasıyla aktarabiliriz.

SAP Note#888889: https://service.sap.com/sap/support/notes/888889

Google Docs: http://docs.google.com/View?id=ddhw5r9m_52htc4srgg

JSPM (Java Support Package Manager), temel olarak SAP sistemlerinde support patchlerin güncelleştirme işlemini yapmamızı sağlayan araçtır. Aynı şekilde JSPM’in güncellemesi de yine kendi üzerinden yapılır. JSPM’i çalıştırmak için /usr/sap/<SID>/<Central instance name>/j2ee/JSPM/go.bat dosyasını çalıştırıyoruz. JSPM’i çalıştırdıktan sonra karşımıza gelen aşağıdaki ekranda öncelikle SDM parolasını girip, Java Support Package Manager’a logon oluyoruz:

JSPM’e logon olduktan sonra, sisteme support package (bundan sonra SP) implementasyonu için altı farklı tipte seçeneğimiz mevcuttur. Bunlar;

• Support Package Stack: Yığın halinde birden fazla SP güncelleştirmesi yapmak için bu seçenek kullanılır.
• Java Support Package Manager (JSPM) : JSPM’in kendisi bu seçenek vasıtasıyla güncelleştirilir.
• Single Support Packages: Tek bir SP’yi update etmek için bu seçenek kullanılır.
• New Software Components: Sistemde olmayan bir SP’yi yüklemek için kullanılır.
• Business and Enchancement Packages: Business ve enhancement paketleri bu seçenek ile sisteme yüklenir.
• Install Additional Usage Type: Ek paketlerin yüklemesi için kullanılır.

Çoğunlukla, tek support package (=SP) güncelleştirmesi yapmak istediğimizde mutlaka JSPM versiyonunu kontrol etmemiz gerekiyor. JSPM eğer düşük versiyonda ise, anlamsız hatalar alıp güncellemelerin yapılmasına imkan vermeyebilir. Single Support Package seçeneği ile sistemdeki SP’lerin hangi seviyede olduğunu görebiliriz:

Görüldüğü üzere Support Package güncelleştirme aracımız olan JSPM 13. patch seviyesinde bulunuyor. Şu an güncelleyeceğimiz paketleri ilgili dizine koymadığımız için JSPM, “Target SPLevel.PatchLevel” kısmında herhangi bir hedef patch seviyesi bulamıyor. Öncelikle JSPM’i güncelleyeceğiz. Bunun için http://service.sap.com/swdc linkinden JSPM patchini indireceğiz. Adrese gittikten sonra sol menüden Download -> Support Packages and Patches -> Entry by Application Group menüsüne indikten sonra gelen sayfadan aşağıdaki adımları takip ediyoruz:

SAP NetWeaver -> SAP NETWEAVER -> SAP NETWEAVER 7.0 -> Entry by Component -> Application Server Java -> Java SP Manager 7.0 -> #OS Independent

Sayfanın alt kısmında, download sekmesine baktığımızda karşımıza JSPM paketlerinin listelendiğini görüyoruz. Bizdeki JSPM seviyesi 13. patchlevel’da idi. Buradan JSPM19_0-10003470.SCA’ya tıklayarak JSPM 19. patchlevel’ı indiriyoruz.

Bu aşamadan sonra indirdiğimiz JSPM19_0-10003470.SCA dosyasını, update işlemini gerçekleştireceğimiz sunucu üzerindeki /usr/sap/trans/EPS/in dizinine kopyalıyoruz.

Kopyalama işleminden sonra JSPM’i tekrar çalıştırıyoruz (/usr/sap/<SID>/<Central instance name>/j2ee/JSPM/go.bat, bunu masaüstüne kısayol olarak atmamız ileride kolaylık sağlar.) SDM parolasını girdikten sonra, gelen ekrandan Java Support Package Manager (JSPM)’i seçerek ilerliyoruz. Aşağıda görüldüğü gibi bu kez karşımıza mevcut JSPM patch seviyemiz ve update edeceğimiz patch seviyesini gösteren ekran geliyor.

Burada next butonuna basarak ilgili paketlerin validasyon işlemlerini başlatıyoruz ve bir sonraki adıma geçiyoruz:

Burada önemli olan nokta Status kısmında OK görüyor olmaktır. Eğer herhangi bir uyarı veriyorsa o zaman ya hatalı stack yüklemeye çalıştığımızı, ya da öncelikle manuel olarak SDM update etmemiz gerektiğini belirtir. SDM Update işlemi için #860939 numaralı SAP Note’una bakılabilir.

Altta “Validation of selected components has finished.” uyarısını gördükten sonra “Start” butonuna bakarak JSPM’i 19.patch level’i uygulama işlemini başlatıyoruz. İşlem kendi kendine yürütülüyor olacak. “Deployment has finished” notunu gördükten sonra işlem tamamlanmış demektir. Exit diyerek çıkış yapabiliriz.

Konuya refer eden SAP note’ları: #891983, #884537, #723909

JSPM User’s Guide: http://help.sap.com/saphelp_nw04s/helpdata/en/1F/C45B4211AAC353E10000000A1550B0/frameset.htm

Google Docs: http://docs.google.com/View?id=ddhw5r9m_51dgrwtscw

SAP sistemlerinde database backuplarını takvimleyebilmek (scheduling) için db13 (DBA planning calendar) transaction’ını kullanabiliriz. DBA Planning Calendar ekranına girdikten sonra karşımıza gelen takvimde boş bir alana tıkladığımız zaman yeni bir backup ayarlayabileceğimiz aşağıdaki gibi bir pencere açılır:

Bu ekranda görüldüğü üzere; online (SAP sistemleri aktifke) veya offline (SAP sistemleri kapatılıp) backup alınma opsiyonlarının yanı sıra, veritabanının tamamını veya belirli bir tablespace’in de yedeğini alabiliriz. Buradan uygun olan seçeneği seçelim. Ben sisteme yeni kurulan backup sistemini test etmek için tek bir tablespace’in online backup’ını alacağım. Bu yüzden “Partial Database Online Backup” seçiyorum. Hemen alttaki satırda backup’ın hangi tarih ve saatte başlayacağını da yazıyorum.

Bu işlemleri tamamladıktan sonra “Action Parameters” kısmında yer alan tablespace’lerden birini seçiyorum. İsterseniz bu backup’ı bir tape ünitesine de yazdırabiliriz. Bunun için “Tapes for Database Backups” kısmından uygun seçeneği işaretlemek gerekiyor.

Action Parameters’in yanındaki Recurrence sekmesinde bu backup’ı belirli bir gün veya saatte sürekli tekrarlanacak şekilde schedule edebiliriz.

İşlemlerimizi bir kez daha kontrol ettikten sonra Add butonu ile aktif hale getiriyoruz.

Backupların sorunsuz alınıp alınmadığını db12 : Backup Logs ekranından görebiliriz.

Google Docs: http://docs.google.com/View?id=ddhw5r9m_49kwgdx26f

Periyodik sistem kontrolleri, sistemlerde meydana gelen ve çözümü SAP AG‘de olan bazı kritik problemler ve SAP Almanya’nın buna benzer çeşitli nedenlerle SAP sistemlerine bağlanabilmesi için servis bağlantılarını açmak gerekiyor. Bu işlemleri aşağıdaki şekilde yapabiliriz.

Öncelikler SAP Support Portal‘e bağlantıyı açacağımız sistemlerin kayıtlı olduğu OSS user’ı ile bağlanıyoruz.

Üst menüde “Data Administration” kısmından “System Data” ekranına bağlanıyoruz. Gelen ekran “System Data Maintenance” ekranıdır. Burada mevcut OSS kullanıcısına bağlantılı olan sistemleri arayabilir veya daha önceden bu ekranda işlem yaptığımız sistemleri seçebiliriz.

Bu kısımda önemli olan servis bağlantısını sağlayacağımız SAP sisteminin SID ve Installation numarasına dikkat etmek ve buna göre uygun seçimi yapmaktır.

Servis bağlantılarını düzenleyeceğimiz sisteme tıkladıktan sonra yeni bir pencere’de “Display and Maintenance System Data” ekranına ulaşmış oluruz. Burada servis bağlantılarını yönetmenin yanı sıra seçtiğimiz sistem bilgilerini düzenleyebilir, sistem atamalarını düzenleyebilir ve aynı zamanda sistem bilgilerinde herhangi bir hata olma ihtimaline karşı “consistency check” yani tutarlılık kontrolü yapabiliriz.

Üst menüde yer alan “Maintain Access Data” kısmından SAPAG’nin sistemlere bağlanacağı kullanıcının ayrıntılarını görebiliriz. Sistem bağlantılarını ayarladıktan sonra, buradaki kullanıcının (OSS, OSSUSER, OSSSUPPORT vs..) kendi sistemimizde tanımlı olup olmadığını ve yetkilendirmesinin eksiksiz olduğunu kontrol ettkikten sonra SAP AG’ye iletiyor olacağız.

Burada kullanıcının kontrolünü ve gereken ayarları tamamladıktan sonra sonra bir önceki ekranda yer alan Usage Types kısmında SAProuter’ın hostname, IP adresi ve Servis Portu (genelde 3200 ile 3299 arasında olur) bilgilerini hatasız olarak set etmemiz gerekiyor. Ardından hemen alttaki “Maintain Service Connections” kısmına tıklayarak servis bağlantılarını yapılandırma ekranına ulaşıyoruz.

Ekranın üst tarafında yer alan Network Status bölümünden SAProuter’ın bağlantı durumunu kontrol edebiliriz.

Eğer burada SAProuter bağlı değil gözüküyorsa IP ve port bilgilerini doğru girdiğimizden emin olmalı, hata devam ediyorsa SAP üzerinde sm59 transaction’ını ile kendi sistemlerimiz ile SAProuter sunucusu arasındaki bağlantıyı kontrol etmeliyiz.

Ayrıca bu kısımda bulunan Service Connector Download linkinden, SAP servis bağlantılarını açmaya yarayan mini uygulamayı indirmeliyiz. SAP Service Connector hakkında ayrıntılı bilgiyi buradan edinebilirsiniz. Aynı sayfada Network Status’un altında bulunan Set up Connection Types kısmından yapılandırabileceğimiz bağlantı tiplerini görebiliriz. Bu bağlantı tipleri aşağıda listelenmiştir.

• VNC Connection
• HTTP Connect
• Netviewer (Full Access)
• Netviewer (Show only)
• LoadRunner
• JAVA DEBUG
• Windows Terminal Server
• Citrix Metaframe
• T.120 NetMeeting
• PCanywhere
• Telnet Connection
• SSH Connection
• AS/400-5250 Connection
• J2EE Telnet Admin
• BW RFC Connection
• BW GUI Connection
• EarlyWatch
• Remote Consulting
• Upgrade Assistant
• SAPInst-GUI
• SAP-DB Connection
• Integration Directory
• Integration Repository
• TCC Service Download
• R/2 Connection
• TREX/BIA Connection

SAP AG’nin bizden request edeceği bağlantıları buradan seçebiliriz. Bağlantı tipini seçtikten sonra SAP Service Connector vasıtasıyla ilgili bağlantı tipinin bilgilerini içeren stfk.oez dosyası sistemimize yüklenir.

Eğer SAProuter ayarlarımız doğruysa burada bağlantı tipini seçtikten sonra gelen ekrandan bağlantının süresini belirleyerek servisi başlatmış oluruz.

Servis bağlantılarının ayarlanmasında önemli olan iki nokta, SAP AG’nin sisteme bağlanacağı kullanıcının sistemde tanımlı ve yetkilerinin tam olması, diğeri ise SAProuter’ın bilgilerinin eksiksiz olmasıdır.

Google Docs: http://docs.google.com/View?id=ddhw5r9m_4854pz4d3s

Diyarbakırspor, Bank Asya 1. Liginde dün Manisaspor ile 1-1 berabere kalarak Manisaspor ile birlikte Süper Lig’e yükselmeyi garantiledi. Fakat Diyarbakırspor’un bu azim ve başarısını kutlarken,  Diyarbakır eski Emniyet Müdürü Ali Gaffar Okkan’ı anmadan geçmek haksızlık olur.

Aslında havaalanında kafileyi karşılamaya gelen taraftarların Diyarbakır eski Emniyet Müdürü şehit Gaffar Okkan’ın ‘Seni unutmayacağız’ yazılı fotoğraflarını taşımaları bize çok şey anlatıyor. Ali Gaffar Okkan, Emniyet Müdürü olduğu yıllarda kentin sadece huzur ve güven içinde yaşaması için değil, sosyal ve kültürel faaliyetleriyle de ön plana çıkması için çok büyük çaba sarfetti.

Peki sadece bu muydu Gaffar Okkan’ı değerli kılan? Elbette onu Diyarbakırlıların yüreğine taşıyan yalnızca sosyal faaliyetlere verdiği önem değildi. Gaffar Okkan, insana ve insan hayatına değer veren biriydi. Halkın huzur ve refahı için onun döneminde yapılan operasyonlar sırasındaki çatışmalarda ölüm oranı asgari düzeye inmişti.  Özel Harekat polislerine “Çocuklar mecbur kalmadıkça kimseyi öldürmeyin, sağ yakalamaya çalışın” diye öğüt verdiği de basında yer almıştır. Nitekim Emniyet Müdürlüğü yaptığı dönemde Hizbullah örgütüne yapılan operasyonlarda toplamda 1260 militan yakalanmış ve 2 polisin şehit verildiği operasyonlarda bile tek bir Hizbullah militanı öldürülmemiştir. Sadece bu istatistik bile Gaffar Okkan`ın görevini yaparken ne kadar titiz ve insani davrandığının bir göstergesidir.

Gaffar Okkan’ı rahmetle anarken, mimarı olduğu Diyarbakırspor’un Süper Lig’e çıkışını yürekten tebrik ediyorum.

R/3 sistemlerdeki tüm application servisleri, daha önce de belirttiğim gibi application layer’da bulunur. Şimdi bu katmandaki işlevleri biraz daha ayrıntılı inceleyeceğiz.

Application katmanında, R/3 sistemini kontrol eden ABAP programları, work processler ve bu katmanın en önemli bileşeni olan dispatcher bulunur. Dispatcher tüm R/3 processlerini monitör eder ve aynı zamanda R/3 sistemi içerisinde birbirinden farklı görevleri bulunan work processleri de kontrol eder.

Work processler sistem içinde beş farklı türde bulunurlar. Bunlar; dialog wp (work process), background wp, spool wp, enqueue wp ve update wp’dir. Bu work processlerin elbette sistem üzerinde belirli görevleri ve sorumlu oldukları bazı işler mevcut. Aslında isimleri bir şeyler çağrıştırıyor olabilir ama yine de açıklayalım.

Dialog work process: Kullanıcı istekleri dispatcher vasıtasıyla dialog work processe aktarılır. Dialog work processi de ilgili kullanıcı isteğini yürütür ve kullanıcıya bunun çıktısını döner. Bundan sonra yeni bir istek kabul etmeye hazırdır. Yeni bir kullanıcı isteği geldiğinde yine o süreci işletir, işini bitirdiğinde ilgili dialog work process yine release edilir ve aynı veya farklı bir kullanıcıdan yeni bir görev almaya hazır hale gelir.

Background work process: Background work process ise, sistemde arkaplanda çalışan işlerin yürütülmesini gerçekleştirir. Arkaplanda çalışan bu iş, bir ABAP programı veya önceden planlanmış raporlama işlemleri gibi belirli durumlarda çalıştırılan bir uygulama olabilir.

Spool work process: Spool work processi, yazıcı gibi herhangi bir aygıta veri transfer edilmesinden sorumludur. Herhangi bir dialog ya da background wp’i bir yazdırma listesine uygun olarak bir print işlemi başlatabilir, ardından bu süreci spool wp devralarak işlemin sistem üzerinde bir spool request’i olarak konumlandırılmasını sağlar.

Enqueue work process: Enqueue work processi sistem üzerindeki “lock management” mekanizmasını kontrol eder. Lock management denilen sistem birden fazla kullanıcının aynı anda aynı data üzerinde değişiklik yapılmasının önlemektir. Eğer bir kullanıcı bir veri üzerinde işlem yapıyorsa, diğer kullanıcıların o veriye yalnızca view-only erişimi vardır. Veriyi değiştirebilmesi için, o veri ile çalışan kullanıcının çıkış yapması gerekir. Böylece enqueue wp de veri üzerindeki kilidi kaldırarak diğer kullanıcının erişimine izin verir. Bu tam işlevsel lock management yapısının tesis edilmesi önceden tanımlanan iş gereksinimlerine bağlı olarak değişiklik gösterebilir. Her R/3 sistemde bir tane enqueue work process bulunmaktadır.

Update work process: Update work process, sistem üzerine girişi yapılan dataların güncellenmesinden sorumludur. Girilen veri, V1 veya V2 bileşenleri kullanılarak update edilebilir. V1 bileşeni, kritik ve yüksek öncelikli güncellemeleri yapmak için kullanılırken, V2 bileşeni de daha az kritik ve orta öncelikli güncellemelerde kullanılır.

Work processler hakkında genel olarak bilgi verdikten sonra bir kaç önemli noktayı da belirtmek faydalı olacaktır.

Bir dialog work processinde veri üzerinde yapılan her değişikliğin logu geçici olarak VBLOG tablosunda tutulur. Hatalı bir değişiklik yapıldığında, geri dönüş için bu tablonun incelenmesi oldukça kolaylık sağlıyor.

Dialog transaction’ı tamamlandığında (yani dialog processi kullanıp bir değişiklik yapıldığında), dispathcer bir “free work process” başlatarak, düzgün bir şekilde aynı verinin database üzerinde de güncellenmesini gerçekleştirir. Bu işlem aynı zamanda “asenkron güncelleme – asynchronous update” olarak bilinir.
Application katmanında, bu servislerin yanı sıra yine dispatcher tarafından kontrol edilen diğer ek servisler de bulunmaktadır. Bunlar, message server ve gateway server‘dır.

Message server, birden fazla uygulama sunucusunun kullanıldığı R/3 konfigürasyonlarında, birbirinden bağımsız bu uygulama sunucuları üzerindeki haberleşmeden sorumludur.

Gateway server ise mevcut R/3 sistemin, diğer sistemler ile haberleşmesini sağlayan ve destekleyen bir servistir. Gateway server, her uygulama sunucu üzerinde çalışan SAP gateway’i kullanır. Gateway server; diğerR/3 sistemleriyle, R/3 ve R/2 sistemler arasında ve R/3 sistem ile diğer harici programların haberleşmesinden sorumludur. Aynı zamanda CPI-C adı verilen ve farklı yapıdaki programların birbiriyle haberleşmesini sağlayan interface’i yönetir. R/3 sistemlerin diğer mainframe veya harici ortamlarla haberleşmesinin temelinde CPI-C yer alır.

Google Docs: http://docs.google.com/View?id=ddhw5r9m_47fkxpgb63

Türkiye büyük bir heyecanla beklediği ABD’nin 44.başkanı Barack H. Obama’yı uğurladı. Obama’nın görevinin başında ilk Türkiye’yi ziyaret etmesi de, Türkiye’ye verdiği önemin ve 2003′ten bu yana adeta duraklama dönemine giren Türkiye – ABD ilişkilerinde yeni bir dönemin habercisiydi.

TBMM’deki konuşmasında ise, Türkiye’deki sorunları gayet iyi analiz ettiğini ve bu sorunlara taraflarca getirileck ortak çözüm yollarını desteklediği mesajını verdi. Sorunun muhatapları açısından barışçıl ve uzlaşmacı bir konuşma yapsa da Obama’nın öncelikli düşüncesi doğal olarak Türkiye’nin uğraştığı sorunlara çözüm bulabilmek değil, Türkiye ile sürdürülebilir bir stratejik ortaklık ilişkisi içerisine girmektir. Bununla birlikte Obama, geçmişte ABD yönetimlerinin Türkiye’ye karşı yaptığı hataların da tekrarlanmayacağı imajını çizmiştir.

Bir çok kişi, Obama’nın konuşmasından sonra, “herkesin ağzına bir parmak bal çaldı” yorumlarını yapsa da ben bu düşünceye katılmıyorum. Konuşmanın satır başlarından inceleyecek olursak, “ABD, İslam’la savaş halinde değildir ve asla olmayacak” cümlesi Türkiye’de dillendirilen din merkezli kutuplaşmaya bir mesaj değil midir? Ya da “Türkiye, Doğu ile Batı’nın bölündüğü değil birleştiği yerdir” sözüne yaptığı önemli vurgu da AB yolundaki Türkiye için yine önemli bir mesaj niteliği taşımıyor mu? Aslında verilen mesajlar oldukça netti:

• Atatürk’ün mirası olan güçlü, canlı ve laik bir demokrasi
• Türkiye’nin Avrupa Birliği üyeliği’ne olan destek
• Terör ve şiddetin tamamen gündemden çıkarılması
• Din eksenli kutuplaşmanın önüne geçilmesi

Bu mesajlardan yola çıkarak artık rahatlıkla söyleyebiliriz ki, her ne kadar Bush döneminin başında çok iyi gitmesine rağmen, 2003′ten sonra bozulan ABD – Türkiye ilişkileri, Obama ile birlikte yeni bir döneme giriyor. Özellikle Afganistan ve Irak’ta ABD sonrası yapılanmada bizzat Türkiye’nin çok önemli roller üstleneceği de aşikar. Türkiye de bundan sonra Irak ve Afganistan politikalarını tekrardan gözden geçirerek yeni yapılanmaya uygun ve Win-Win esasında dayanan stratejiler geliştirmek zorundadır ki biz de geçmişte yaptığımız hatalara düşmeyelim ve bir fırsatı daha kaçırmayalım.

SAP R/3 sisteminde, global ve local dizinler (directory) arasında belirli bir fark vardır. Global dizinler genelde database server üzerinde bulunurlar ve her R/3 sistemde yalnızca bir adet global dizin vardır. Bunun yanı sıra her SAP instance’ı da uygulama sunucuları (application servers) üzerinde barındırılan local dizinlere sahiptir. Burada instance dediğimiz, R/3 sistemin yönetimsel birimidir ve uygulama katmanına özgü bileşenleri barındırır.

Her iki dizin tipi de (local & global) \usr\sap\<sapsid> dediğimiz path altında bulunur. Buradaki <sapsid> , SAP sistem adıdır ve üç karakterli bir koddan ibarettir (Ör: DEV, PRD, P11,…). Sistem ismini kurulumda istediğimiz gibi ayarlayabiliriz.

Burada en önemli alt dizin R/3 programlarının bulunduğu \usr\sap\<sapsid>\sys\exe\run dizinidir.

\run dizini bu sistemin sorunsuz bir şekilde çalışmasını sağlayan R/3 program dosyalarını barındırır.

R/3 log dosyaları ise, instance dizini altında \usr\sap\<sapsid>\DVEBMGS01\work alt dizininde barındırılır.

SAP sistemlerde herhangi bir process çalıştırıldığı zaman hem SAP sistemleri üzerinden hem de işletim sistemi üzerinden loglarının takibi yapılabiliyor. Burada tarihe göre sıralama yapıldığı zaman en son çalıştırılan işlemin loglarına ulaşılabilir.

R/3 sisteminin client yapısı ise R/3 sistem landscape temelinde çalışır. R/3 sistemlerde client, kendi veri ortamı bulunan organizasyonel ve ticari bir birim olarak görülebilir.

Daha önce de bahsettiğimiz gibi R/3 sistemi genelde; development, quality assurance ve production sistemlerden oluşur. Fakat her bir ortam R/3 sisteminden bağımsız olarak ayarlanabilir veya aynı R/3 sistemi üzerinde client olarak da barındırılabilir.

Information Layer’larda olduğu gibi R/3 sistem landscape’inde de bir, iki ve üç sistemli yapılar oluşturulabilir.

One-system Landscape dediğimiz tek sistemli yapıda; development, quality assurance ve production ortamları, farklı clientlar ile tek bir sunucu üzerinde bulunur. Bu sistemin avantajı minimum donanım gerekliliği ve yönetiminin kolay olmasıdır. Dezavantajı ise, client üzerinde yapılan değişiklikler veya geliştirmelerin direkt olarak production yani canlı sistem üzerinde de etkili olmasıdır. Aynı zamanda performans ve veri güvenliği de etkili değildir. Genelde ayrı bir test sisteminde yeni sürümlerin ve geliştirmelerin yapılması da sıklıkla mümkün değildir.

Two-system Landscape dediğimiz yapıda ise development ve quality assurance ortamları tek bir sunucu üzerinde farklı client numaralarıyla bulunur. Production sistem ise farklı bir sunucu üzerinde barındırılmaktadır. Bu yapılandırma sayesinde production sistem, development ve quality assurance’da yapılan değişikliklerden ve geliştirmelerden etkilenmez. Böylece daha performans ve veri güvenliği bakımından daha kararlı bir production ortamı sağlanmış olur. Dezavantajı ise, clientlarda yapılan değişiklik ve geliştirmelerin test edilememesidir.

Three-system Landscape‘de ise development, quality assurance ve production ortamları farklı sunucular üzerinde barındırılır. Bu yapıda production ortamı için en güvenli sistem sağlanmış olur. Canlı sistem verileri ve performansı, development ve QA (quality assurance)’de yapılan değişikliklerden etkilenmez. Ayrıca development ortamı diğer ortamlardan farklı bir sunucu üzerinde barındırıldığı için, burada yapılan geliştirmeler sonrası production sisteme gönderilecek olan transport requestleri gönderilmeden önce QA sisteminde test edilebilir. Bu sistemin dezavantajı olarak da, fazla donanım gerekliliği ve böylece de maliyetlerin artmasıdır.

Google Docs: http://docs.google.com/View?id=ddhw5r9m_46hn3bpmcv

Hazır Pardus 2009 çok yaklaşmışken, bir çok kişi ne gibi değişiklikler olacağı konusunda merak içinde değil mi? :)