ABAP Kodu Kopyalayarak Program Çalınabilir Mi?

ABAP Nedir?

ABAP, SAP R/3 sistemlerinin yazılım geliştirme dilidir. SAP’nin içerisinde hazır gelen programların tamamı ABAP ile yazılmıştır. SAP üzerinde ek geliştirme yapmak isteyen bir programcı, program kodlarını yine ABAP dili ile yazmaktadır.

ABAP, açık kaynak kodlu bir dildir. Yani; SAP’nin standart programlarına ait kaynak kodları, sisteme giren ve yetkisi olan herhangi bir kişi tarafından serbest bir şekilde kopyalanıp alınabilir. Bir firmanın kendine özel geliştirdiği programların kaynak kodları da, aynı şekilde serbest bir şekilde kopyalanıp alınabilir.

Bu konuda, SAP sisteminin özel bir önlemi bulunmamaktadır. Bilakis; kodların açık olması, hata analizi, yedekleme, program taşıma gibi pek çok işlemi kolaylaştırmaktadır.

Diğer Teknik Nesneler

SAP sisteminde; ABAP kodlarının yanı sıra Table, Data Element, Domain, Structure, Lock Object, Authorization Object, Class, Function, Transformation, Checkpoint Group gibi sayısız teknik nesne bulunmaktadır. Yazılım geliştiren bir programcı, ABAP kodunun yanı sıra, bu ve benzeri nesneleri de oluşturmaktadır.

Bir ABAP programının çalışabilmesi için, kaynak kodunun yanı sıra, sonradan geliştirilmiş tüm bu nesnelerin de sistemde mevcut olması gerekir.

SAP, tam da bu yüzden, geliştirmelerin şirkete ait sistemler arasında taşınabilmesi için Transport Request adı verilen bir mekanizma geliştirmiştir.

Kodların Kopyalanması

Bir programcı, sadece ABAP kodlarını kopyalayarak bir programı bir firmadan bir başka firmaya taşıyabilir mi?

Eğer geliştirme sadece ABAP kodundan ibaret basit bir program ise; evet, bu mümkün olabilir. Ancak, sadece ABAP kodundan ibaret olup diğer teknik nesneleri içermeyen bir geliştirme, muhtemelen görece basit ve önemsiz bir geliştirme olacaktır.

Daha büyük çaptaki programlarda ise; programın kaynak kodlarının yanı sıra, programcının geliştirdiği sayısız yardımcı teknik nesne bulunacaktır. Sadece programın kodlarının kopyalanması, o programın bir başka sistemde çalıştırılabilmesi anlamına gelmemektedir.

Zira; kaynak kodların yanı sıra; yukarıda zikredilen diğer teknik nesnelerin de hedef sisteme taşınıyor olması gerekmektedir. Bu teknik nesneler ise, program kodları gibi kopyala & yapıştır ile alınabilecek karakterde değildir.


Şirketlere ait süreçleri kapsayacak çaptaki bir geliştirme, ABAP kodunun yanı sıra, muhtemelen pek çok yardımcı teknik nesne içerecektir. Bu tarz bir geliştirmeyi, sadece ABAP kodunu kopyalamak suretiyle bir başka firmaya taşımak pratikte pek mümkün gözükmemektedir.

Sadece program kodlarını kopyalayarak bir başka sisteme taşıyabileceğimiz geliştirmeler, teknik anlamda çok basit geliştirmelerdir. Muhtemelen şirket süreçlerini kapsayacak hassasiyette olmayacaklardır.


“NOT EXISTS” Subqueries in ABAP CDS Views

ABAP CDS Views are great and all; however, it doesn’t support subqueries at this time. In this post, I would like to share a workaround which functions similar to “NOT EXISTS”.
The requirement was to exclude material document items (MSEG) which were reverse posted; and the reversal documents themselves.
If I was writing a regular ABAP SQL statement, I could easily achieve this with the help of a NOT EXISTS subquery. Check the code snippet below – I have excluded unrelated WHERE conditions for simplicity.
SELECT mblnr, mjahr, zeile 
  FROM mseg AS mseg1 
    ( sjahr EQ '0000' OR sjahr IS NULL )
    ( NOT EXISTS (
      SELECT mandt FROM mseg AS mseg2 WHERE
        sjahr EQ mseg1.mjahr AND
        smbln EQ mseg1.mblnr AND
        smblp EQ mseg1.zeile
    ) )
  INTO TABLE @DATA(lt_mseg).
This logic doesn’t work in CDS views directly due to lack of subquery support. To get the same result using CDS views, I have split the query into two views. The first one returns a wide list where original and reversal MSEG records are listed side by side.
@AbapCatalog.sqlViewName: 'ZMMV_001'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Original and reversal docs side by side'
  select from
    mseg as mseg1
    left outer join mseg as mseg2 on
      mseg2.sjahr = mseg1.mjahr and
      mseg2.smbln = mseg1.mblnr and
      mseg2.smblp = mseg1.zeile
    mseg1.mblnr as mblnr1,
    mseg1.mjahr as mjahr1,
    mseg1.zeile as zeile1,
    mseg1.sjahr as sjahr1,
    mseg1.smbln as smbln1,
    mseg1.smblp as smblp1,
    mseg2.mblnr as mblnr2,
    mseg2.mjahr as mjahr2,
    mseg2.zeile as zeile2,
    mseg2.sjahr as sjahr2,
    mseg2.smbln as smbln2,
    mseg2.smblp as smblp2
The second view filters out the reversed & reversal documents from the first view, which leaves effective material documents only.
@AbapCatalog.sqlViewName: 'ZMMV_002'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Effective material document items'
  select distinct from ZMMV_MAT_DOC_ITEM_REV_STATUS
    key mblnr1 as mblnr,
    key mjahr1 as mjahr,
    key zeile1 as zeile
    sjahr1 = '0000' and
      mjahr2 = '0000' or
      mjahr2 is null
    ) and
      sjahr2 = '0000' or
      sjahr2 is null
This approach can be implemented to replace NOT EXISTS in many other cases as well.
life, software,

How To Pick A Profession

In this post, I’ll share some hints about picking a profession. This question has been asked me multiple times; therefore, I felt the urge to write a general guidance on the subject.

Basics of Trade

First, we need to focus on the basics. In a primitive community with no monetary system, people would trade goods and services. A hunter would give meat and pelt to a farmer in exchange of fruit and vegetables. Both provide something others need.

In such a community, a painter might find a hard time finding someone to trade because the houses might not have walls at all.

In order to be a part of the trade system and obtain things from others, one needs to provide something that others need.

Today, the same basic principles apply. Although money has become the main media of trading, the basic system of “provide to obtain” is still active. When you provide work, you get money as a symbol that you have provided something. Later on, you can give out this money to obtain another thing you need.

In the light of the basics of trade; one of the first questions that need to be asked is “What can I provide that my community needs?” . If you provide something that no one needs, you can’t expect to obtain anything in exchange.

This question can be broken into a few sub-questions.

What Does Your Community Need?

Analysing the country you plan to live in is an important step.

Different communities have different needs. A painter in an aboriginal tribe might be unemployed, but the same painter can make a living in a modern country. If you studied art history, good luck finding a job in in undeveloped country. You get the idea.

If you are familiar with Maslow’s hierarchy of needs, you can easily relate to the idea that every community has an average place in the needs hierarchy.

An underdeveloped country struggling for nutrition and security has needs on the most basic levels. By default, you would need to focus on those levels.

On the other hand; a well developed country might have diverse needs covering academicians, artists and psychologists. In such a country, you could have a hard time finding a job as a blue collar worker (because production is automated) but might find a place as a shrink.

You need to consider the supply / demand balance of the need as well. You might think that the community needs yoga teachers, but if there are already thousands of yoga teachers seeking students, it means that the market is full and the need is satiated.

Future needs of the community is as important as the needs of today. If you foresee that a profession might be obsolete in 10 years (due to AI, for instance); it makes sense to stay away from it.

What Are You Good At?

Analysing your own strengths is another important step. In my opinion, one should focus on things that he/she does easily and others don’t.

Some tasks can be done easily by anyone because the task is easy. Those can be eliminated.

Some tasks can be done easily by certain people because the tasks comply with his/her strenghts. Those should be inspected as potential professions.

Many people tend to underrate their strenghts because they do it easily. If you do something easily which others don’t; this can lead to your future profession. This doesn’t mean that you aren’t going to work and sweat, but it means that putting the same energy as others will get you farther than others.

Here are some examples.

If you are naturally good at math, you might become an engineer or programmer.

If you feel comfortable with words and are an introvert, you might consider a career in writing or publishing.

If you are a naturally organized extrovert, project management or tourism might be your call.

If you have a strong natural compassion, becoming a social worker might be just the thing for you.

Those over-generalized examples should give you the basic idea.

The school system, or society overall, might have given you the impression that you need to be doing something you don’t like in order to gain something you like. While that might be true in some cases, it is not always true. Be mindful of your pre-learned patterns, and don’t let them make you unconsciously pick a profession where you would struggle for success because it’s requirements are your weaknesses (instead of strengths).

What Do You Love To Do?

Your profession will cover a significant part of your life. If you are not happy on your job, it is improbable to be happy in your overall life.

Confucius said “Choose a job you love, and you will never have to work a day in your life”.

Jessica Hische said “The work you do while you procrastinate is probably the work you should be doing for the rest of your life”.

If you enjoy doing something even without compensation, in your free time, like a game of hobby, turning that thing into a profession might lead you to a happy life.

If you play an instrument in your spare time, you might consider a career on music. If you really enjoy airplanes and heights, why not becoming a pilot? If you create websites and/or small games in your spare time, you might consider a career on programming. If you love animals a lot, how about being a vet? You get the idea.

Realistically consider the future of your beloved hobby though. It would be a good idea to talk to professionals of the field in question to get a better insight about what is involved and expected if your hobby turned into a job.

For example; if you like to drive around and eat donuts in your free time, being a cop may seem appealing to you. However; after talking to a professional and understanding the dynamics of the job, you may start to consider if dealing with criminals is suitable for you or not. So, early reality checks are healthy.

Who Do You Know?

I have seen companies with ~100K employees look for new members through personal reference of the close circle – despite the large CV pool.

Personal reference is a significant factor in many industries. As a fresh graduate, you might get frustrated because your CV is ignored. However, if an influential person provides personal reference, the same company would possibly be willing to meet you.

Industries are actually large communities built of many sub-communities. Just like any community, having someone influential to introduce and initiate you makes your accretion much easier.

Considering your future career, close relations with important people from the industry is a significant advantage.

Bringing It All Together

The answer is to find something that the community needs, which you love doing and have a natural ability for. Knowing some key people from the industry is also important. Those are the basic ingredients you should be looking for.

  • The community always needs doctors and you may love the idea of healing people. But if you are unable to tolerate blood, you would have a hard time keeping up.
  • You may enjoy playing an instrument a lot, but if you fear airplanes and can’t travel, you might not be fit for touring.
  • You may love animals a lot, but you can’t be a competent vet if you have a hard time operating on them.
  • You may be in love with abstract art, but if your community doesn’t care about it, maybe you should keep it as a personal interest and look for a profession somewhere else.
  • You may feel like you would be a talented director, but if you know absolutely no one from the movie industry, you might have a hard time climbing up the career ladder.

You get the idea; the ideal case should mix all the ingredients.

  • If your missing ingredient is the need of the community, you could end up being poor.
  • If your missing ingredient is ability, you could be pigeonholed into a mediocre position.
  • If your missing ingredient is love, you could end up lacking enjoyment and life satisfaction.
  • If your missing ingredient is entourage, you could be left out of the industry altogether.

Find the profession that combines all ingredients, and you are one step closer to ikigai.

Hint: Early internship is a great way to understand if a potential job works for you or not.


A General Purpose ABAP Multiton Class

In this post, I will share a general purpose class covering the multiton design pattern. By implementing a simple interface, you can add multiton functionality to your existing classes.

Multiton is a performance oriented design pattern. It is based on the idea of caching and re-using objects corresponding to the same key. For each object key (such as a vendor number), a static object instance of a class (such as a vendor class) is kept in a central location. Whenever a client requests an object corresponding the key, the existing object is returned instead of creating a new one. This approach reduces the memory footprint due to the decreased number of objects, and avoids the performance cost to re-create objects having the same key.

A typical multiton class would have the following skeleton structure.



    DATA gv_lifnr TYPE lifnr READ-ONLY

    CLASS-METHODS get_instance
      IMPORTING !iv_lifnr TYPE lifnr
      RETURNUNG VALUE(ro_obj) TYPE REF TO zcl_vendor.


      BEGIN OF t_multiton,
        lifnr TYPE lifnr,
        obj TYPE REF TO zcl_vendor,
      END OF t_multiton,

      tt_multiton TYPE HASHED TABLE OF t_multiton
        WITH UNIQUE KEY primary_key COMPONENTS lifnr.

    CLASS-DATA gt_multiton TYPE tt_multiton.

    METHODS constructor
        !iv_lifnr TYPE lifnr.




  METHOD constructor.
    “ Check if IV_LIFNR exists in LFA1 and raise error if not
    gv_lifnr = iv_lifnr.

  METHOD get_instance.

    ASSIGN gt_multiton[ KEY primary_key
      COMPONENTS lifnr = iv_lifnr ]
      TO FIELD-SYMBOL(<ls_multiton>).

    IF sy-subrc NE 0.

      “ Check if IV_LIFNR exists in LFA1 and raise error if not
      DATA(ls_multiton) = VALUE t_multiton( lifnr = iv_lifnr ).
      ls_multiton-obj = NEW #( iv_lifnr ).
      INSERT ls_multiton 
        INTO TABLE gt_multiton
        ASSIGNING <ls_multiton>.


    ro_obj = <ls_multiton>-obj.



When ZCL_VENDOR=>GET_INSTANCE( ‘12345’ ) is called for the first time, a new instance of ZCL_VENOR is created and stored in GT_MULTITON; and that very instance is returned.

When ZCL_VENDOR=>GET_INSTANCE( ‘12345’ ) is called again, the existing instance of ZCL_VENDOR in GT_MULTITON is returned instead of a new instance. That saves memory and runtime.

For more information on multiton, you can refer to my book Design Patterns in ABAP Objects.

Now, what is the value-add of this post?

Instead of creating a specialized multiton implementation into every required class, I have created a general purpose multiton class which does all the hard work of caching objects. All you have to do is to implement an interface into your existing class to add multiton functionality.

Let’s assume that our vanilla class looks like this.

CLASS zcl_bc_multiton_demo DEFINITION


      gv_id    type char15,
      gv_erdat type erdat,
      gv_ernam type ernam.

      constructor importing iv_id type char15.


CLASS zcl_bc_multiton_demo IMPLEMENTATION.

  method constructor.
    gv_id = iv_id.
    gv_erdat = sy-datum.
    gv_Ernam = sy-uname.


Pretty simple, huh? This is the class we presumably need multiton functionality on.

This is the interface we need to implement.

  public .

          !iv_objectid type CDOBJECTV
          value(ro_obj) type ref to ZIF_BC_MULTITON


After implementing the interface, our vanilla class looks like this.

CLASS zcl_bc_multiton_demo DEFINITION


    interfaces ZIF_BC_MULTITON.

      gv_id    type char15,
      gv_erdat type erdat,
      gv_ernam type ernam.

      constructor importing iv_id type char15.


CLASS zcl_bc_multiton_demo IMPLEMENTATION.

  method constructor.
    gv_id = iv_id.
    gv_erdat = sy-datum.
    gv_Ernam = sy-uname.

  METHOD zif_bc_multiton~get_instance.
    ro_obj ?= new zcl_Bc_multiton_demo( conv #( iv_objectid ) ).


And here is the general purpose class that does the caching.

CLASS zcl_bc_multiton DEFINITION
  CREATE public .


          !iv_clsname   TYPE seoclsname
          !iv_objectid  TYPE cdobjectv
          VALUE(ro_obj) TYPE REF TO zif_bc_multiton


      BEGIN OF t_multiton,
        clsname  TYPE seoclsname,
        objectid TYPE cdobjectv,
        cx       TYPE REF TO cx_sy_create_object_error,
        obj      TYPE REF TO zif_bc_multiton,
      END OF t_multiton,

        TYPE HASHED TABLE OF t_multiton
        WITH UNIQUE KEY primary_key COMPONENTS clsname objectid.

      gt_multiton TYPE tt_multiton.



  METHOD get_obj.

    ASSIGN gt_multiton[
        KEY primary_key COMPONENTS
        clsname  = iv_clsname
        objectid = iv_objectid
      ] TO FIELD-SYMBOL(<ls_mt>).

    IF sy-subrc NE 0.

      DATA(ls_mt) = VALUE t_multiton(
        clsname  = iv_clsname
        objectid = iv_objectid


          CALL METHOD (ls_mt-clsname)=>zif_bc_multiton~get_instance
              iv_objectid = ls_mt-objectid
              ro_obj      = ls_mt-obj.

        CATCH cx_sy_create_object_error INTO ls_mt-cx ##no_handler.
        CATCH cx_root INTO DATA(lo_diaper).

          ls_mt-cx = NEW #(
            textid    = cx_sy_create_object_error=>cx_sy_create_object_error
            classname = CONV #( ls_mt-clsname )
            previous  = lo_diaper


      INSERT ls_mt
        INTO TABLE gt_multiton
        ASSIGNING <ls_mt>.


    IF <ls_mt>-cx IS NOT INITIAL.
      RAISE EXCEPTION <ls_mt>-cx.

    ro_obj = <ls_mt>-obj.



Now, if we need to create an instance of ZCL_BC_MULTITON_DEMO bypassing the multiton cache, all we need to do is to create the object regularly as demonstrated below.

DATA(lo_obj) = NEW zcl_bc_multiton_demo( 'DUMMY' ).

If we need to get advantage of multiton, here is what we need to do.

DATA(lo_obj) = CAST zcl_bc_multiton_demo(
    iv_clsname = 'ZCL_BC_MULTITON_DEMO'
    iv_objectid = 'DUMMY'


Pretty neat, eh? Having ZCL_BC_MULTITON_DEMO, we don’t need to deal with caching anywhere else. This class will do the multiton caching for you, and return the cached instance in case you re-call GET_OBJ with the same object id.

In case you need the original source codes of the samples mentioned here, you can visit my GitHub ABAP library.


Eğlencelik SAP Entry’leri

Her seferinde aramak zorunda kalmamak için; Ekşi Sözlük’te yazdığım eğlencelik SAP Entry’lerimi buraya toplamak istedim.


Decorator Design Pattern


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
    !iv_bukrs TYPE bukrs
    !iv_waers TYPE waers
    !ct_data STRUCTURE ztt_data.

INCLUDE zxornek.


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
    !iv_bukrs TYPE bukrs
    !iv_waers TYPE waers
    !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

    INTERFACES zif_decorator.



  METHOD zif_decorator~decorate.

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



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

    INTERFACES zif_decorator.



  METHOD zif_decorator~decorate.

    CHECK zcl_fi_toolkit=>is_company_special(
      ) eq abap_true.

    MESSAGE e300(zfi) WITH iv_bukrs.



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

    INTERFACES zif_decorator.



  METHOD zif_decorator~decorate.

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



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

  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
  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.

      iv_bukrs = iv_bukrs
      iv_waers = iv_waers
      ct_data = ct_data[]


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.


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.


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.


Technical SAP Cutover Steps

Here are some of the significant cutover steps for SAP go live.

System integrity:

  • Ensure that packages in dev / QA / live are identical
  • Ensure that E-Mails can be sent from the live system

Transport paths:

  • Ensure that “Transport of Copy” requests can be carried between dev – live systems
  • Ensure that requests in QA STMS can be forwarded to the live system
  • Ensure that workbench / customizing requests can be sent between dev – QA – live

Transport execution:

  • Transport external requests to the live system
  • Transport requests of all finished developments to the live system by selecting original requests & a transport of copies request containing everything
  • Ensure that all requests imported to QA are imported to the live system as well. TPALOG table + Excel VLOOKUP will help.

Soft config:

  • Definition of SM59 connections
  • Definition of SOAMANAGER connections
  • Definition of Z* number ranges in SNRO
  • Customizing of technical Z* tables
  • Ensure SCAL definitions & future maintenance
  • Define jobs

Workflow configuration:

  • Setting up WF-BATCH
  • Workflow configuration in SWU3
  • Ensure that Z* tasks are classified as general task (PFTC_DIS)
  • Execute SWU_OBUF and define a job if needed
  • If you use deadline monitoring, define  job for RSWWDHEX