Alper Somuncu – BlogNotes

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

Uzun süre olmuş kendimden bahsetmeyeli. Elbette bu süre içerisinde hayatımda bir takım değişiklikler oldu.

Öncelikle Kocaeli Üniversitesi Bilgisayar Mühendisliği bölümünden yarım dönem gecikmeyle de olsa bu dönem mezun oldum. Bu süreçte eski çalıştığım firmadan ayrılma kararı aldım. Elbette, yaklaşık bir yıldır içinde bulunduğum ekipten ayrılma kararı almak zor oldu fakat, kapsamlı bir değerlendirme yaptığımda artık kendi yolumu çizmem gerektiğini anladım. Her ne kadar zamanında Sevgili Ali Işıngör, kriz zamanında işten ayrılmamın riskli olduğunu söylese de risk almadan başarı gelmeyeceğini de bu sayede öğrenmiş oldum. :-)

Görüştüğüm iki firmadan da benzer pozisyonlarda sözleşme teklifi aldım. Fakat, çalışma ortamının bana daha cana yakın gelmesi, bununla birlikte kendimi geliştirebilmek adına bana daha fazla imkan sunması ve son yıllarda her iki şirketin de sektördeki durumlarını da göz önüne alarak Siemens’i tercih ettim. Bundan sonra System Engineer / SAP BC Admin pozisyonunda Siemens’de iş hayatıma devam edeceğim. Hafta başında işe başlamış olmama rağmen, şimdiden ne kadar doğru bir karar verdiğimi anladım bile…

Aklıma gelmişken, çalıştığım bir yıllık süre boyunca benden desteklerini esirgemeyen tüm BimSA personeline teşekkür etmeden geçemeyeceğim. Aynı zamanda, IBM’in bana teklif yapmak için – her ne kadar o teklifi kabul etmesem de – izin istediği eski şirketimdeki genel müdürüm ve direktörüme de bu duruma onay verdikleri için teşekkür ediyorum. IT dünyası küçük, umarım bir gün tekrar birlikte çalışma fırsatı bulabiliriz.

Pardus’a gelince, artık eskisi kadar destek veremesem de, gelişmeleri sürekli takip etmekteyim ve geçen her zaman daha fazla gurur duyuyorum. Bir projede geliştiricisinden camiaya kadar herkes üzerine düşeni bu kadar mükemmele yakın yapınca ortaya da tadına doyulmaz bir yemek çıkıyor.

Sağlıcakla kalın…

Seni bulmadan önce aramak isterim.

Seni sevmekten önce anlamak isterim.

Seni bir yaşam boyu bitirmek değil de,

Sana hep yeniden başlamak isterim.