Decorator Design Pattern

Giriş

Bu makalede; sık kullanılan Design Pattern’lardan biri olan Decorator’ı tanıyacağız.

Bu Pattern, size SAP’nin BADI teknolojisi üzerinden tanıdık gelebilir. Şimdiye kadar BADI’lerin içine kod yazmış olabilirsiniz. Bu yazının sonunda, uygulamalarınızı BADI mantığında genişletebilir hale gelmenizi hedefliyoruz.

Ön Koşullar

Bu makalede, aşağıdaki konulara aşina olduğunuz varsayılmaktadır.

  • ABAP bilgisi
  • Object Oriented ABAP tecrübesi
  • Interface ve Class kavramları
  • Casting

Decorator Nedir?

Decorator Design Pattern; aynı veri üzerinde birden fazla değişiklik yapılması gerektiği durumlarda kullanılır. Bu değişikliklerin tamamını ana programa veya merkezi bir sınıfa kodlamak yerine; dağınık haldeki mikro sınıflara kodlama prensibine dayanır.

Bu sayede; yeni bir kod eklemek gerektiğinde, test edilmiş eski kodlara herhangi bir şekilde dokunmadan yeni bir sınıf yazmak yeterli olmaktadır. Veya mevcut bir işlevi çıkarmak gerektiğinde, o işlevi barındıran sınıfı etkisiz hale getirmek yeterlidir.

Örnek Uygulama: User Exit

Decorator mantığını anlamak ve avantajlarını görmek için, tipik uygulama alanlarından biri olan User Exit örneğini inceleyeceğiz.

Aşağıdaki fonksiyonun bir User Exit olduğunu varsayalım.

FUNCTION ornek_user_exit
  IMPORTING
    !iv_bukrs TYPE bukrs
    !iv_waers TYPE waers
  TABLES
    !ct_data STRUCTURE ztt_data.

  INCLUDE zxornek.

ENDFUNCTION.

Bu User Exit içerisinde 3 ayrı iş yapılacağını düşünerek, konuyu irdelemeye başlayalım.

Klasik ABAP Uygulaması

Geleneksel ABAP anlayışında, ZXORNEK dosyası içerisinde bu 3 iş alt alta ve ayrı ayrı kodlanacaktır.

*&----------------
*& Include ZXORNEK
*&----------------

" Exit'te yapılacak 1. iş buraya kodlanır
" Exit'te yapılacak 2. iş buraya kodlanır
" Exit'te yapılacak 3. iş buraya kodlanır

Bu yaklaşımın pek çok sakıncası vardır; bunlardan bazılarını dile getirelim.

  • Bu Include içerisinde kodlar, ister istemez birbirini etkileyecektir. Örneğin üst satırlara yazılmış bir EXIT komutu, alt satırlarda çalışması gereken bir kodun hiç çalışmamasına yol açabilir.
  • ZXORNEK içerisine 4. bir ek yapıldığında, diğer 3 işe ait senaryoların da tekrar test edilmesi gerekir.
  • ZXORNEK üzerinde farklı ABAP’çılar paralel çalışamaz.
  • ZXORNEK altındaki farklı işler farklı Request’lere dahil edilip canlıya ayrı ayrı taşınamaz. Parçalı taşıma gerektiğinde, kodların yıldızlanıp taşınıp tekrar açılması gibi zahmetli ve riskli yaklaşımlar gerekir.
  • ZXORNEK’e kodlar eklendikçe, bu dosya zaman içerisinde uzun ve anlaşılması zor hale gelir, bakım maliyeti ve hata riski gittikçe artar.

Şimdi aynı uygulamayı Decorator Design Patern ile yapıp, bu dezavantajları ortadan nasıl kaldıracağımızı görelim.

Decorator Adım 1: Interface

Çözümümüzün ilk adımı, bu User Exit için bir Interface oluşturmaktır. SAPGUI üzerinde SE24 işlem koduna giderek veya Eclipse içerisinde New → ABAP Interface menüsünü kullanarak Interface tanımlayabiliriz.

INTERFACE zif_decorator PUBLIC.

METHODS decorate
  IMPORTING
    !iv_bukrs TYPE bukrs
    !iv_waers TYPE waers
  CHANGING
    !ct_data TYPE ztt_data.

DECORATE yordamındaki parametrelerin, User Exit parametreleri ile örtüştüğüne dikkat edin.

Basit olması açısından, Interface’imiz içerisinde; hata yönetimi gibi ek işlevleri devre dışı bıraktık.

Decorator Adım 2: Uygulama Sınıfları

Bu adımda, 3 farklı işi yapacak 3 bağımsız sınıf yazacağız. SAPGUI üzerinde SE24 işlem koduna giderek veya Eclipse içerisinde New → ABAP Class menüsünü kullanarak sınıf tanımlayabiliriz.

CLASS zcl_decorator01 DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_decorator.
  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.

CLASS zcl_decorator01 IMPLEMENTATION.

  METHOD zif_decorator~decorate.

    MODIFY ct_data
      FROM VALUE t_data( yabanci_kur = abap_true )
      TRANSPORTING yabanci_kur
      WHERE waers NE iv_waers.

  ENDMETHOD.

ENDCLASS.

Sınıf ZIF_DECORATOR Interface’ini uygulayıp, hayali tablomuzdaki YABANCI_KUR alanını doldurmuş olduk.

Interface’i uygulamamız, bu sınıfın ZIF_DECORATOR içerisinde geçen Method’ları barındırdığını sisteme garanti etmemiz anlamına geliyor. Sistemde ZIF_DECORATOR’u kullanacak şekilde yazılmış herhangi bir program, ZCL_DECORATOR01 sınıfının detaylarını bilmeye ihtiyaç duymadan bu sınıftan faydalanabilir. Zira; içerisinde DECORATE diye bir Method oluğu biliniyor.

Nasıl faydalanacağını birazdan göreceğiz.

Yine basit olması açısından, sınıf içerisindeki kodu basit tuttuk. Gerçek dünyada; bu sınıf içerisinde Type’lar, Private Method’lar, hata yönetimi, vb görmeyi beklerdik.

Aynı mantığı takip ederek, User Exit’te yapmamız gereken ikinci işi barındıran ikinci bir sınıf açıyoruz. Normalde bu sınıfların yapacağı işler daha karmaşık olacaktır, ancak örneği basit tutmak adına işleri de basit tutuyoruz.

CLASS zcl_decorator02 DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_decorator.
  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.

CLASS zcl_decorator02 IMPLEMENTATION.

  METHOD zif_decorator~decorate.

    CHECK zcl_fi_toolkit=>is_company_special(
        iv_bukrs
      ) eq abap_true.

    MESSAGE e300(zfi) WITH iv_bukrs.

  ENDMETHOD.

ENDCLASS.

Dikkat ederseniz; bu sınıfta CHECK komutunu çekinmeden kullanabiliyoruz. CHECK, olsa olsa ZCL_DECORATOR02’den çıkmamız anlamına gelir. Diğer uygulama sınıflarını etkilemeyecektir.

Şimdi son sınıfımızı da kodlayalım.

CLASS zcl_decorator03 DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES zif_decorator.
  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.

CLASS zcl_decorator03 IMPLEMENTATION.

  METHOD zif_decorator~decorate.

    DELETE ct_data WHERE xflag EQ abap_false.
    CHECK ct_data IS INITIAL.
    MESSAGE e301(zfi).

  ENDMETHOD.

ENDCLASS.

Bu şekilde, basitleştirilmiş örnek sınıflarımızı tamamlamış oluyoruz. Elimizde bir Interface ve üç Class var.

Decorator Adım 3: User Exit Uygulaması

Bu son adımda; dağınık Lego parçaları gibi hazırladığımız bileşenleri User Exit içerisinde bir araya getireceğiz.

*&-----------------
 *& Include ZXORNEK
 *&----------------

DATA:
  lo_decorator TYPE REF TO zif_decorator,
  lo_object TYPE REF TO object.

" ZIF_DECORATOR Interface'ini uygulamış sınıfları tespit et

SELECT clsname
  FROM seometarel
  WHERE refclsname EQ 'ZIF_DECORATOR'
  INTO TABLE @data(lt_class).

" Her bir sınıfa ait nesneyi dinamik yaratıp çalıştır

LOOP AT lt_class ASSIGNING FIELD-SYMBOL(<ls_class>).

  CREATE OBJECT lo_object TYPE (<ls_class>-clsname).
  lo_decorator ?= lo_object.

  lo_decorator->decorate(
    EXPORTING
      iv_bukrs = iv_bukrs
      iv_waers = iv_waers
    CHANGING
      ct_data = ct_data[]
  ).

ENDLOOP.

Gördüğünüz gibi; Exit’in yaptığı iş, ZIF_DECORATOR Interface’ini uygulayan sınıfları tespit edip çağırmaktan ibaret. Exit içerisinde fonksiyonel herhangi bir kod yok.

Exit çalıştığında;

  1. SEOMETAREL tablosundan ZCL_DECORATOR01 & 02 & 03 sınıflarına erişilecektir.
  2. Loop’un ilk adımında, ZCL_DECORATOR01 içindeki DECORATE Method’u çalışacaktır.
  3. Loop’un ikinci adımında, ZCL_DECORATOR02 içindeki DECORATE Method’u çalışacaktır.
  4. Loop’un üçüncü adımında, ZCL_DECORATOR03 içindeki DECORATE Method’u çalışacaktır.

Inteface’i uygulayan sınıfları bulan kodu basit tutarak doğrudan SEOMETAREL tablosuna baktık. Bu basit kod, Abstract Class uygulandığı durumda sınıfları gözden kaçırabilir veya sınıfların sıralı çağırılması gereken durumda yeterli olmayabilir. Bu konudaki alternatif yaklaşımlar, örnek kodlarla birlikte Design Patterns in ABAP Objects adlı kitabımda var.

Değerlendirme

Bu yaklaşım, klasik ABAP yaklaşımının dezavantajlarını nasıl ortadan kaldırıyor, birer birer inceleyelim.

  • Kodlar birbirini etkilememektedir. Örneğin; ZCL_DECORATOR02 içerisindeki CHECK komutu, diğer sınıflarda yer alan kodların çalışmasını etkilememiştir.
  • ZCL_DECORATOR03’te bir değişiklik yaptığımızda, 01 ve 02’yi tekrar test etmemiz gerekmiyor.
  • 3 farklı ABAP’çı, 3 farklı sınıf üzerinde paralel çalışabilir.
  • ZCL_DECORATOR01 canlıya giderken, ZCL_DECORATOR02 geliştirme sisteminde bekleyebilir.
  • Bu Exit’e ek yapmak için tek yapmamız gereken şey ZCL_DECORATOR04 diye yeni bir sınıf açmaktır. Kodlar basit ve modüler parçacıklar halinde olduğundan, değişiklik yönetimi kolaylaşmaktadır.

Yardımcı Diğer Pattern’lar

Sınıflar arasında veri paylaşma ihtiyacı ortaya çıkarsa, Decorator’a yardımcı Property Container Design Pattern uygulanabilir. Bu Pattern; her bir User Exit için ayrı bir Interface açma ihtiyacını ortadan kaldırıp, tüm User Exit’leri (SE19 benzeri) tek bir altyapıdan yönetmeyi de mümkün kılabilir.

Decorator sınıfları arasında, birbirine benzer iş yapan sınıfların işlevleri Template Method veya Servant uygulanarak ortaklaştırılabilir.

Sıralı çağırmak gibi basit ihtiyaçların ötesinde sınıfların koordine edilmesi gerekiyorsa, Mediator kullanılabilir.

Bahsetilen bu Pattern’ların tamamı, örnek uygulamalarla birlikte Design Patterns in ABAP Objects adlı kitabımda var.

Sonuç

Bu makalede, Decorator Design Pattern’i örnek User Exit uygulaması üzerinden incelemiş olduk. Design Pattern kullanmanın avantajlarını da kısmen gördük.

İncelediğimiz bu örnek Pattern’in geliştirmelerinizde faydalı olmasını ve diğer Pattern’leri öğrenmek konusunda sizi teşvik etmesini umuyorum.

Suite on HANA mı? S/4HANA mı?

Uzun bir ara verdikten sonraki ilk yazı konumu belirlemekte çok zorluk çekmedim. Türkiye SAP EkoSistemi HANA platformu konusunda epeyce bilgi sahibi oldu ve faydaları konusunda da kafalar net. Donanım maaliyetleri göreli olarak ucuzladı, Microsoft, Amazon, Google gibi uluslararası oyuncuların yanında, KoçSistem gibi yerel oyuncular da Servis şeklinde ve ihtiyaca göre kapasite sunan donanım alternatiflerini oldukça hesaplı şekilde sunmaya başladılar. https://www.maximus.com.tr/hana-as-a-service/

Şimdi mevcut SAP kullanan şirketler için cevaplanması gereken son bir soru kaldı: Suite on HANA mı yoksa S/4HANA mı?

2 yıl öncesine kadar cevaplanması zor bir soruydu bu, ancak özellikle iki ay önce duyurulan S/4HANA 1709 sürümünden sonra sorunun cevabı çok kolaylaştı. Kesinlikle S/4HANA…Peki Neden?

Suite on HANA, diğer veritabanları üzerinde koşan benzeri SAP ERP 6.0 EHPX ürününe göre ciddi avantajlar ve özellikler sunuyor:

  • Performans İyileştirme: 1000’den fazla optimizasyon SAP tarafından sadece HANA platformunda koşan SAP ERP ürünü için gerçekleştirildi. Genelde mevcut işlem kodunun sonuna H eklenerek ulaşılabiliyor bu iyileştirmelere, benim favorim FBL ile başlayan işlem kodlarının sonuna H ekleyerek elde edilenler, FBL1H, FBL3H gibi. Detaylı bilgi için 1761546  no’lu SAP Note’a ulaşınız.
  • Fiori : Sadece HANA platform sürümü için kullanılabilen Fiori uygulamaları. Smart Business Cocpit türünde olanlar çok başarılı ama çalıştırması çok zahmetli.
  • Gerçek Zamanlı Analitikler: VDM temelli (HANA Live view’leri üzerinden .MDX temelli sorguları gerçek zamanlı gösterebilen) analitikler. Maalesef SAP tarafından hazır içerik olarak sunulan view’lar çok genel ve değiştirilmesi çok zahmetli. Ayrıca yetkilendirme sadece DB seviyesinde yapılabiliyor, her kullanıcıya bir DB user’ı açmak gibi sorun yaşıyorsunuz. Ancak Lumira ile kolayca bağlanıp, bir kaç dakika içinde gerçek zamanlı Analitikler oluşturmak çok keyifli. Hem de veriyi kopyalamadan. No ETL 🙂
  • Daha küçük Veritabanı büyüklüğü: 2016 yılı başında, 2 TB yakın verisi olan bir müşterimizi Suite on HANA’ya migrate ettikten sonra veri 400GB seviyesine indiğini görünce gerçekten ben de çok etkilenmiştim.

Geleneksel SAP ERP’ye göre çok büyük yenilikler sunsa da Suite on HANA sadece geçici bir çözüm. Asıl fayda ve renkli dünya S/4HANA’da saklı. 2 yıl öncesine kadar pek fark yok gibi görünüyordu, özellikle SAP ERP’yi Suite on HANA’ya migrate edip, üzerine de SFIN diye bilinen SAP Accounting Powered by HANA add-onu’nu yükleyip finans verilerini dönüştürdükten sonra. Ancak durum o kadar basit değilmiş. Bunu tecrübe ile sabitleyerek öğrendim maalesef.

Peki S/4HANA Suite on HANA’dan faklı ne sunuyor?

EvolotionOfS4_Sarhan

  • Yeni bir Core component S4CORE, yani yeni veri modeli ve yeni code seti. Gömülü bir sürü fonksiyon: EVM, PPDS, TM…
  • Fiori 2.0, yani gerçek zamanlı bildirimlerin de browser üzerinden kullanıcıyı işlemler konusunda yönlendirebilmesi ve tüm fonksiyonların Fiori Launchpad üzerinden browser temelli çalışabilmesi.
  • Gömülü Analitikler: HANA Live artık yok, çok şükür 🙂 onun yerine CDS (Core Data Services) temelli VDM’ler var. Hiçbir ek ürüne ihtiyaç duymadan Fiori üzerinden gerçek zamanlı Analitiklere erişmek mümkün.

S4HANA_Sarhan_1709

Ancak tüm bunların ötesinde, Operasyonel sisteminiz ile Analitik sisteminiz tek bir kurulum ve veritabanı üzerinde çalışabilir hale geliyor. Bunlara ek olarak da Embedded BPC ile bütçenizi de aynı sistem ve Veritabanı üzerinde yapabilir duruma geliyorsunuz.

Hafif, yalın ve kolay yönetilebilir bir SAP çözüm ailesi. İşte bu yüzden ben S/4HANA diyorum.

Sevgiler,

@sarhanpolatates

 

Klasik ABAP, Object Oriented ABAP ve Design Patterns

Bu yazıda; bana çok sık sorulan bazı soruları cevaplamak adına, SAP projelerinde klasik ABAP yerine Object Oriented yaklaşım kullanmanın faydalarından bahsedeceğim. Bunun yanı sıra, Object Oriented geliştirme yapmak isteyen bir programcının Design Pattern’lardan haberdar olmasının getirdiği avantajları ele alacağım.

Özet

Klasik ABAP ile yapılan geliştirmeler, yeterince esnek ve yeniden kullanılabilir olmamaktadır. Programda bir değişiklik istendiğinde veya programın bir parçasını bir başka noktada kullanmak gerektiğinde; canlı kullanılan kodlara müdahale edileceğinden geliştirme & test süresi uzayabilir ve ortaya hesapta olmayan yeni hatalar çıkabilir.

Object Oriented yaklaşım; geliştirmeleri yekpare yapılar olmaktan çıkarıp, Lego mantığında çok parçalı yapılara çevirmektedir. Bu küçük parçalar; güçlü, esnek, geliştirilebilir, yeniden kullanılabilir ve ikame edilebilir özellikte olmaktadır. Her bir parça; bir kez test edildikten sonra farklı geliştirmelerde tekrar tekrar kullanılabilmektedir. Bu yaklaşımla; geliştirme & test süreleri ve hata oranları azaltılabilir; dolayısıyla geliştirme maliyetleri düşürülebilir.

Design Pattern’lar, kendini zaman içerisinde ispatlamış hazır Object Oriented şemalardır. Bu şemaları tanıyan bir yazılmıcı; bir yazılım ihtiyacıyla karşılaştığında Amerika’yı baştan keşfetmek yerine bu hazır yapıları kullanmayı tercih edebilir. Bu yaklaşımla; Object Oriented kullanmanın avantajları katlanacaktır.

SAP’nin kendisinin de yeni geliştirmelerde Object Oriented yaklaşımı tercih ettiğini hatırlatarak; tüm yazılımcı ve yöneticilere klasik ABAP’tan Object Oriented ABAP’a evrilmeyi ve Design Pattern kullanmayı tavsiye ediyorum.

Continue reading →

OData Servisi Oluştururken Yapılan 10 Hata

Kısaca bahsetmek gerekirse oData servisi; SAP ile dış dünya arasında veri alışverişini sağlayan bir protokoldür.

SAP artık bütün web tabanlı iletişimi bu yeni protokol üzerinden yapmaktadır. Fiori uygulamalarının kullandığı servisler de oData servisleridir.

SAP danışmanları tarafından daha önceleri geliştirilen servislerde, örneğin soap web servislerde geliştiricinin servise müdahelesini çok düşük seviyede olurken, oData servisinde durum biraz daha farklı ve geliştiricinin dikkat etmesi gereken bir çok konu mevcut.

Gördüğüm kadarıyla son yıllarda SAP danışmanları oData servisi oluştururken kulaktan dolma yöntemlerle ya da sezgisel yöntemlerle, bu bence böyle olmalı şeklinde geliştirmeler yapıyor. Bunu yaparken de çok ciddi hatalar yapabiliyorlar.

Bugüne kadar karşılaştığım en ciddi 10 hatayı aşağıda paylaşarak, farkındalık oluşmasına katkı sağlamak istiyorum.

Continue reading →

PMI PMBOK6 (Body of Knowledge 6)

PMBOK6 vs PMBOK5

PMBOK 6. Baskı her baskıda olduğu gibi yenilikler ve değişikliklerle yayımlandı. İlk bakışta dikkatimi çekenler:

AGILE

En önemli eklenti sanırım Agile yaklaşımı ile ilgili ayrı bir ekin yayımlanmış olması. PMI ın aslında Agile için sunduğu PMI-ACP sertifikası için önerdiği PMBOK tarzında bir başvuru kitabı yoktu. Bunun yerine bir dizi referans kitap öneriyordu. Böylelikle ek gibi de olsa PMI onaylı bir başvuru kitabı oldu. Ayrıca her bilgi alanının başında da ilgili alanın agile/adaptive (çevik/uyarlanabilir) yaklaşımlar açısından incelendiği kısa bir bölüm eklenmiş. PMI standartlarının sektör/endüstri bağımsız olduğu düşünüldüğünde, proje yönetiminde genelde yazılım projeleriyle özdeşleşmiş gibi gözüken Agile yaklaşımının ne kadar yaygınlaştığının da bir göstergesi oldu.

Continue reading →

Peloton4 Nedir ve Neden Kuruldu?

Manifestosunda açıkça belirtildiği gibi Peloton4, bireysel özgürlüğünü kaybetmeden, bir grubun içinde yer almanın keyfi, gücü ve huzuru ile daha verimli olacağına inanan, çalışkan, etrafına yardım etmeyi seven, konusunda uzman bireylerin ve şirketlerin bir araya geldiği bir platform aslında Peloton4.

Profesyonel hizmet sunarken, amatör ruhu ve heyecanı kaybetmeyenlerin yer alacağı bir platform olarak düşünebiliriz. Portföyündeki ürün ve hizmetlerden elde ettiği geliri, platformun gelişerek, yetenekli bireylere destek vermesini sağlamak amacı ile de kullanmayı hedefleyen bir platform.

Platformun kapısı herkese açık: en büyük şirketlerden, en genç bireylere kadar. Tek şart, Peloton4 takımı tarafından; sunduğu ürün/hizmetin kalitesi, verimliliği ve güvenilirliği onaylansın yeter. Onaylanmak için gereken şartlar; ilkeler ve etik kurallar olarak açık olarak kamuoyuna duyurulmuştur.

Buna göre bu platform aslında bir tür kalite göstergesi olarak da Türkiye’deki Ekosisteme bilgi sağlamaya da çalışacaktır. Örnek vermek gerekirse, dünya fotoğrafçılığındaki Magnum Photos gibi olmayı hedeflemektedir.

Umarım hedeflerimiz her gün daha ileriyi adresler.

Tüm sorularınız için Peloton4 başkanı olarak bana Sarhan Polatateş‘e ulaşabilirsiniz.

Mail : sarhan.polatates@peloton4.com

Telefon: +90 532 566 1572