Ö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’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

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

Ö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

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

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

Ş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