Alper Somuncu

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

Uzun süredir, iş hayatımdan arta kalan zamanlarda inceleme imkanı bulduğum strateji ve taktik kavramları ve etkileri artık bir hobi olmaktan çıkıp, ciddi olarak vakit ayırdığım ve araştırma yaptığım bir uğraş haline geldi. Bu yüzden, blogumda artık bu konulara da yer vermek istiyorum.

Strateji ve taktik, farklı kişilerce farklı şekillerde tarif ediliyor. Ben, en uygun ve anlaşılır şekilde bahsetmeye çalışacağım.

Strateji kavramı yüzyıllardır, bugünkü kadar olmasa bile kullanılıyor. Uzun bir süre bu kavram askeri ve/veya politik anlamda kullanılan bir terimdi. Stratejinin bu alanlar ile birlikte; ekonomi, yönetim ve iş dünyasında da yer bulması ancak 20.yüzyılın ortalarından sonra olabilmiştir. Fakat önemli devlet adamları ve komutanlar, (Napoléon Bonaparte, Büyük İskender, Cengiz Han vb.) stratejiye bir anlam kazandırararak her şeyden önce bir “düşünme yöntemi” olduğunu göstermişlerdir.

Geçmişte, bir savaş durumunda sonuca ulaşabilmek amacıyla askeri kuvvetlerin sevk ve idaresini kullanma sanatı olarak tanımlanabilecek stratejinin iş hayatına girmesiyle birlikte bilinen bu tanımından daha geniş bir anlama oturtulması gerekliliği ortaya çıkmıştır.

Politik anlamda strateji; bir ulusun, hedeflerine ulaşabilmek için ekonomik, askeri, siyasi ve motivasyon güçlerinin birbiriyle uyumlu olarak kullanılma sanatı olarak tanımlanabilir. Stratejik öngörüler sayesinde devletler; gelebilecek tehlikelerin şiddet ve yönünü, olası tahribatını zamanında görebilme ve önlem alma olanağına sahip olabilirler. Buna karşın strateji günümüzde en çok yanlış anlaşılan kavramdır. Strateji özü itibariyle ekonomik politikalar, rakamlar veya hedefler ile ilgili değil; bugün bulunduğunuz yer ile yarın bulunmak istediğiniz yer arasında sağlam ve kalıcı bir köprü oluşturabilen somut olguların bütünüdür.

Bulunduğumuz çağda her ortamda uygulanabilecek evrensel bir strateji bulunduğuna inanmıyorum. Zaten, herkes tarafından aynı temel prensiplere bağlı kalınarak uygulanabilir olmak, stratejinin özüne aykırıdır. Stratejik düşünme, rakibe üstün gelme amacıyla yapılırken, aynı şeyin size karşı da uygulanabileceğini göz ardı etmemeyi gerektirir.

Taktik de stratejinin bulunduğu hemen her ortamda gündeme gelen bir kavramdır, hatta çoğu kez strateji ile benzer anlamlarda kullanılabilmektedir. Fakat taktik ile strateji birbirini destekleyen kavramlar olmasına rağmen, tamamen farklıdırlar. Taktik, bir fikirdir. Başarıya ulaşabilmesi için olmazsa olmaz gerekliliği ise bana göre rekabetçi olmasıdır. Bu koşul da taktiğin tek başına yeterli olmasını sağlamaz. Süreci başarıyla tamamlayabilmek için taktiğin stratejiye dönüştürülmesi gerekir. Bu noktada stratejinin bir hedef olmadığını, yalnızca hedefe ulaşabilmek için alınması gereken yola odaklanmış bir düşünce sistemi olduğunu bilmek gerekir.

Taktik zamandan bağımsız bir kavramdır, buna karşın strateji belirli bir dönem ile sınırlandırılmalıdır. Örneğin, indirimli satışlar çoğu mağazanın kullandığı bir pazarlama taktiğidir. Fakat, sürekli indirimli satışları olan mağazanın yaptığı ise bir stratejidir. Taktik, rekabette üstünlüğü oluşturur; strateji ise bu üstünlüğü korumayı amaçlar.

Genel olarak stratejinin amacı ise, taktiği daha etkin kılabilmek amacıyla tüm kaynakların en verimli ve uyumlu şekilde seferber edilmesi olarak belirtilebilir.

Bahsettiğim birbirine yakın bu iki kavramı dikkatle incelenirse; stratejinin yönetme sanatı ve yönetim bilimi, taktiğin ise düzenleme, sevk ve idare ile ilgili olduğu görülecektir.

Temel olarak her iki kavramı da anlatmaya çalıştım. Bundan sonraki süreçte sıklıkla bu iki kavram ve etkileri üzerine elimden geldiğince yazacağım.

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? :)

SAP R/3 sistemi, yürüttükleri görevlere bağlı olarak üç farklı katmandan oluşmaktadır. Bu katmanlar Presentation, Application ve Database olarak isimlendirilir ve yalnızca tek bir sunucu üzerine locate edilebileceği gibi, birden fazla sunucu üzerinde de konumlandırılabilirler. SAP’nin önerdiği yöntem de budur.

Şimdi bu üç katmanın temel yapısı ve görevlerini inceleyelim:

• Database katmanı tamamen RDBMS (Relational Database Management System) dediğimiz yapıyı barındırmaktadır. RDBMS processleri, R/3 sistem üzerindeki tüm datalardaki değişiklikler ve gelen isteklerin işlenmesinden sorumludur.
• Application katmanı; ABAP dialog processor, dispatcher ve work processleri gibi bileşenleri barındırır. Aynı zamanda tüm ABAP programlarının yürütülmesi için gerekli ortamı sağlar. Application katmanı tek bir sunucu üzerinde barındırılabileceği gibi, görevsel kullanımı ayırmak ve load balancing sağlamak için birden fazla sunucu üzerinde de barındırılabilir.
• Presentation katmanı ise istemci tarafında konumlandırılmıştır. İstemci tarafında kurulmuş olan ve istemci tarafında yapılması istenen değişiklikleri yapmamızı sağlayan grafik arayüzlü SAPGUI yazılımı (Linux/Unix üzerinde PlatinGUI) bu katmanı temsil eder.

R/3 System Configuration

Üç tür R/3 yapılandırması mevcuttur. Bunlar;

• Central System
• Two-Tier Configuration
• Three-Tier Configuration

Central System‘de Application, Presentation ve Database katmanları, bu üç katman için gerekli tüm processleri üzerine bulunduran tek bir sunucu üzerinde barındırılmaktadır. Az sayıda istemci bulunduran firmalarda, Solaris/Unix sistemler üzerinde central system konfigürasyonuna sahip SAP R/3 sistemleri donanım ve yazılım maliyeti yönünden tercih edilen bir yöntemdir.

Two-Tier Configuration‘da iki tür yapılanma bulunmaktadır. İlk yöntemde presentation katmanı, application ve database’den ayrılarak farklı bir sunucu üzerinde bulunmaktadır. Daha az yaygın olan ikinci yöntemde ise; database server, application ve presentation’dan ayrılarak farklı bir sunucu üzerinde bulunur. İstemci tarafında ABAP development vs. gibi geliştirme işlemleri için kullanılan ve hem application hem de presentation processlerini taşıyabilecek masaüstü bilgisayarlar bulunur ve bu iki katman da bu bilgisayarlar üzerinde koşar.

Three-Tier Configuration‘da ise; presentation, application ve database katmanlarının üçü de farklı sunucular üzerinde bulunur. Bu sistemin en mükemmel avantajı ise load distribution dediğimiz, yük dağılımını optimum şekilde sağlayabilmesidir. SAP‘nin önerdiği yöntem de budur.

Şimdilik hem yapılandırma türleri hem de katmanlar ile ilgili genel bir bilgi vermek istedim. İlerleyen zamanlarda ayrıntılı olarak spesifik konulara yöneleceğim.

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