software, software.sap

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
Standard
software, software.sap

ABAP: UNION DISTINCT vs ALL

As many of you already know, ABAP supports the UNION command now. UNION is an SQL command to combine the results of two separate queries into one dataset.

Here is a sample dataset from the imaginary database table Z1:

ID
TEXT
001
One
002
Two

And here is a sample dataset from another imaginary database table Z2:

CODE
NAME
002
Two
016
Sixteen
019
Nineteen

Before the UNION command existed, we had to run two distinct queries to combine this data into a single internal table.

SELECT
    id AS key,
    text AS value
  FROM z1
  INTO TABLE @DATA(lt_itab).

SELECT
    code AS key,
    name AS value
  FROM z2
  APPENDING CORRESPONDING FIELDS OF @lt_itab.

Now, UNION allows us to merge those queries.

SELECT
      id AS key,
      text AS value
    FROM z1
  UNION
      code AS key,
      name AS value
    FROM z2
  INTO TABLE @DATA(lt_itab).

Here is the catch: If we execute the UNION query above, we get the following resultset:

KEY
VALUE
001
One
002
Two
016
Sixteen
019
Nineteen

Did you notice that record “002” appears only once? In spite of its existence in both of Z1 & Z2, the resultset included a singular “002” entry.

That’s the catch with UNION queries. They can be executed with two logical approaches to handle duplicate records.

UNION DISTINCT is the default mode, and it will eliminate duplicate records from the second query. That’s similar to the logic of SELECT DISTINCT or FOR ALL ENTRIES. That’s why “002” from the second table was missing in the resultset.

UNION ALL needs to be specified explicitly, and it tolerates duplicates from the second query. So, let’s modify our sample query accordingly.

SELECT
      id AS key,
      text AS value
    FROM z1
  UNION ALL
      code AS key,
      name AS value
    FROM z2
  INTO TABLE @DATA(lt_itab).

This time, our recordset will include duplicate records from Z2.

KEY
VALUE
001
One
002
Two
002
Two
016
Sixteen
019
Nineteen

Each approach has its time and place. If I am looking for a unique list of values, such as the combined list of tax numbers of clients & vendors, I would go for UNION DISTINCT. However; if I am querying transactions, such as BSIS / BSAS, I would go for UNION ALL because I probably wouldn’t want to miss any line items.

Standard
software, software.sap

Klasik ABAP, Object Oriented ABAP ve Design Patterns

1464-ppt

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.

Klasik ABAP

Klasik ABAP ile yapılan bir geliştirme; büyük ihtimalle SE38 işlem kodunda oluşturulmuş bir program ve birkaç Include’dan ibaret olacaktır. Programlar arası modülarizasyon ise, tipik olarak SE37 fonksiyonları ile sağlanır. SAP’nin eski geliştirmeleri de bu prensiple oluşturulmuştur. Bu haldeki programlar, yekpare plastik oyuncaklara benzetilebilir.

Klasik ABAP ile yazılan bir program, yazılma amacına uygun bir şekilde çalışıp doğru sonuç getiriyor olabilir. Ancak; bu programın esnekliği düşük olacaktır. Bunun getirdiği bazı tipik dezavantajları inceleyelim.

  • Programa yeni özellikler eklemek istediğimizde; muhtemelen test edilmiş ve canlıya alınmış kısımlarına müdahale edip tekrar test etmek zorunda kalacağız.
  • Program içerisindeki bir algoritmayı bir başka programda daha kullanmak gerekirse, yine test edilmiş kodlara müdahale etmeden bunu yapmak zor olacaktır. Include dosyaları, fonksiyonlar ve PERFORM IN komutları; bu konuda yeterli esnekliği sağlamayabilir.
  • Programın algoritmasını entegrasyon senaryolarına dahil etmek veya Fiori / mobil gibi alternatif bir arayüzden kullanıcılara açmak söz konusu olduğunda, klasik ABAP ile oluşturulmuş yapılar yine ek geliştirme + test eforu ve hata potansiyeli getirecektir.
  • Bir program üzerinde aynı anda tek bir ABAP’çı çalışabilmektedir. Bunun yanı sıra; programın özelliklerinden sadece bir kısmını canlıya almak gerektiğinde, ciddi zorluklar gündeme gelebilir.

Bu ve buna benzer faktörler, yazılımcıları Object Oriented ABAP kullanmaya sevk etmektedir.

Object Oriented ABAP

Klasik ABAP ile yapılan geliştirmeyi yekpare bir oyuncağa benzetirsek; Object Oriented ABAP ile yapılan bir geliştirme Lego parçalarıyla oluşturulmuş bir oyuncağa benzeyecektir. Aynı parçayı (sınıfı) bugün belli bir programda belli bir amaçla kullanırken, yarın bir başka programda başka bir amaçla kullanabiliriz.

Elle tutulur bir örnek olması için; stokları listeleyen bir rapor yazdığımızı varsayalım. Klasik ABAP yaklaşımında; SE38’de yeni bir Z’li program oluşturur, bu programda hem veri okuma işini, hem de ALV ile ekranda gösterme işini yaparız. Object Oriented yaklaşımda ise; önce SE24’te stokları döndüren bir sınıf hazırlarız. Akabinde; SE38’deki program, bu sınıfı çağırır ve gelen sonuçları ALV ile ekrana döker. Bu sınıfı; uzun vadede, stok bilgisine ihtiyaç duyduğumuz tüm SAP programlarında, entegrasyonlarda, Fiori uygulamalarında, vs kullanabiliriz.

Object Oriented dünyaya adım attığımızda; karşımıza Class, Abstract Class, Interface, Public, Protected, Private, Static, Instance gibi kavramlar çıkacaktır. Bu kavramları anlayıp geliştirme yapmaya başladığımızda, Object Oriented ABAP’ın avantajlarından faydalanırız. SAP’nin kendisinin de yeni özellikleri büyük ölçüde Object Oriented yapılarda sunması, önemli bir göstergedir.

Teknik avantajlar, literatürde beş temel prensiple çerçevelenmektedir.

Abstraction: Bu prensip çerçevesinde; ana programın Interface’i tanıması yeterlidir, arkasındaki sınıfın tam olarak ne yaptığını bilmesine gerek yoktur. Bunu, televizyonun HDMI girişi gibi düşünebiliriz. HDMI arayüzü, veri akışını bir anlamda soyut hale getirir. Televizyon, HDMI kablosunun diğer ucunda bir DVD oynatıcı, oyun konsolu, dizüstü bilgisayar, vs olduğundan habersizdir. HDMI arayüzüne uyduğu sürece, her cihazla çalışabilir. Abstraction prensibi, bu yaklaşımı programlarımıza da uygulamamıza olanak tanır. Örneğin; 5 farklı BAPI çağıracak bir ABAP programı, ortak bir Interface üzerinden 5 farklı BAPI sınıfıyla çalışabilir. Arkasındaki sınıfın ne yaptığına bakmaksızın, sadece Interface ile muhatap olur.

Composition: Bir sınıf; aynen değişken ve yordam barındırdığı gibi, diğer sınıfları da barındırabilir. Bu prensip sayesinde; mikro servis mantığında sınıflar geliştirip, mevcut bir sınıfa yeni özellik eklemek gerektiğinde ilgili sınıfı dahil etmek gibi esnek yaklaşımlar uygulanabilmektedir. Örneğin; malzeme stoğu döndüren bir sınıf varsa, bu sınıfı hem kullanılabilirlik kontrolü BADI’sine, hem de stok simülasyonu yapan sınıfa dahil edebiliriz.

Inheritence: Bir sınıftan bir başka sınıf türetip, yordamlarını alt sınıfta kısmen değiştirmek mümkündür. Üst sınıftaki değişiklikler, alt sınıfa otomatik yansıyacaktır.

Encapsulation: Bir sınıfın değişken, yordam gibi bileşenlerini Public / Protected / Private diye işaretleyerek; dış dünyada ne kadarının kullanılabileceğini belirleyebiliriz. Bunu aynen; arabanın direksiyonunu sürücüye açarken motorunu saklamaya benzetebiliriz. Bu şekilde; sınıfımıza erişen bir program, işlevlere sadece izin verilen şekilde erişecek ve böylece hata riski azalacaktır.

Polymorphism: Aynı Interface’e sahip sınıflar, birbirinin yerine geçebilir. Örneğin; bir entegrasyon programının arkasında FTP’den veya SOAP servisinden veri okuyabilen birer sınıf olduğunu varsayalım. Ek olarak REST servisinden veri okuma ihtiyacı çıkarsa; aynı Interface’e sahip olan yeni bir sınıf açmamız yeterli olacaktır. Ana programın kodunda herhangi bir değişiklik yapmak gerekmez; zira ana program, söz konusu Interface’ten türemiş tüm sınıfları ister istemez destekleyecektir.

Bu prensiplerin sonucunda ortaya çıkan fonksiyonel avantajlardan bazılarını ifade etmek gerekirse;

  • Test edilmiş ve canlıya aktarılmış kod birimleri, farklı yerlerde tekrar tekrar kullanılabilir
  • Algoritmalar; farklı programlar ve entegre olunan farklı platformlar tarafından yeniden kullanılabilir
  • Programlar; HDMI veya USB mantığıyla, tak-çıkar bileşenlerden oluşan yapılar şeklinde tasarlanabilir
  • Programlar, mevcut kodlara dokunmadan genişletilebilir
  • Programcılar, birbirini kilitlemeden paralel çalışabilir
  • Program bileşenleri, birbirinden bağımsız test edilebilir; hatta birim testler otomatize edilebilir
  • Sınıflarda yapılan merkezi iyileştirmeler, sınıfı kullanan tüm programları olumlu etkiler
  • Geliştirmelerin canlıya kısmi olarak alınması kolaylaşır

Bu fonksiyonel avantajlar; proje yönetimi şu anlama gelmektedir:

  • Geliştirme süresi azalır
  • Test süreleri azalır
  • Hata oranı azalır

Üst yönetim açısından; geliştirme & test süresinin ve hataların azalması, doğrudan doğruya maliyetlerin azalması anlamına gelmektedir.

Ancak; bu avantajları yaşamak için, programların arkasına Class tanımlıyor olmak yeterli değildir. Normalde SE37’de fonksiyon formunda yazacağınız kodu SE24’e geçip Method olarak yazmak, Object Oriented kılığında klasik ABAP geliştirmesi yapmak anlamına gelmektedir. Bu avantajların ortaya çıkması için, Object Oriented bileşenlerin doğru kurgulanması gerekmektedir. Bu da, bizi Design Pattern kavramına götürüyor.

Design Patterns

Object Oriented ABAP ile geliştirme yapmayı Lego’ya benzetirsek; Design Pattern’lar hazır Lego şemaları gibi düşünülebilir. Yeni bir Lego oyuncağı aldığınızda; içinden çıkan şema, parçalarla oluşturabileceğiniz çalışır bir oyuncağı tarif edecektir. Aynı şekilde; Design Pattern’lar, Class, Abstract Class, Interface gibi “parçaları” kullanarak oluşturabileceğiniz yapıları tarif edecektir.

Elle tutulur bir örnek olması için; satın alma taleplerine onay verecek kişileri belirleme ihtiyacıyla karşı karşıya olduğumuzu varsayalım. Elimizde 10 tane kural olsun. Bir sınıf tanımlayıp, bu sınıf içerisine bu 10 kuralı IF / CASE zincirleri şeklinde tanımlamak mümkündür. Ancak; gelecekte 11. kural geldiğinde, test edilip canlıya atılmış bu sınıfa müdahale etmeden bunu uygulayamayız. 11. kuralı canlıya atmadan önce, diğer 10 kuralı da en baştan tekrar test etmek gerekir.

Halbuki; Chain of Responsibility adlı Design Pattern, bize tam olarak bu problemi çözen hazır bir şema önermektedir. Bu şemadan; 10 kuralı 10 ayrı sınıf olarak tanımlayıp, uç uca ekliyoruz. Uygulama çalıştığında; her bir kural sınıfı satın alma belgesini değerlendirecek, onaycıları belirleyebiliyorsa belirleyecek, belirleyemiyorsa belgeyi bir sonraki sınıfa paslayacaktır. Bu yapıda; 11. kural gündeme geldiğinde, o kurala ait sınıfı yazıp zincire eklemek yeterlidir. Test edilmiş ve canlıda çalışan kodlara dokunmamıza gerek kalmayacaktır.

Birkaç örnek Design Pattern ifade etmek gerekirse; MVC, Observer, Data Access Object, Multiton, Decorator, Strategy dile getirilebilir. Bu kavramı ortaya atan ilk kitap, 30 civarı Pattern içermekteydi. Günümüzde ise; Flux gibi daha modern Pattern’lar da türetilmektedir.

Design Pattern’lar, genel anlamda aşağıdaki prensiplere uygun Object Oriented yapılar içermektedir:

  • Single Repository: Her bir sınıf, sadece tek bir sorumluluğa sahip olmalıdır.
  • Open-Closed: Sınıflar; genişletmeye açık, ama modifikasyona kapalı olmalıdır.
  • Liskov Substitution: Programın kodu değiştirilmeden, programın kullandığı sınıflar değiştirilebilmelidir.
  • Interface Segregation: Interface’leri opsiyonel Method’lar ile şişirmek yerine, birkaç Interface oluşturmak yeğlenmelidir.
  • Dependency Inversion: Programlar; doğrudan doğruya sınıflarla değil, Interface’lerle çalışacak şekilde tasarlanmalıdır.

Design Pattern’lar; bizi Anti-Pattern olarak bilinen hatalı yaklaşımlardan da uzak tutar. Tipik Anti-Pattern’lardan bazıları şunlardır:

  • Blob: Büyük bir sınıfın, işlerin tamamını yapmaya çalışmasıdır. İşlevler, mimari bir yaklaşımla alt sınıflara kırılmalıdır.
  • Copy-Paste Programming: Parametrik yordam tanımlamak yerine, kodların kopyala & yapıştır ile çoğaltılmasıdır.
  • Functional Decomposition: Object Oriented dünyada klasik ABAP alışkanlıklarını kullanmaktır. Bu durum, Design Pattern bilgisi olmadan Object Oriented kod yazan ABAP’çıların bir kısmında görülmektedir.
  • Jumble: Çok katmanlı yapılarda, alt – üst katmanların izole edilmeden birbirine erişmesidir. Özellikle Event’ler konusunda tecrübesiz programcılar, bu hataya düşmektedir.
  • Object Orgy: Sınıfın tüm bileşenlerinin Public olarak tanımlanmasıdır. Bu durum, sınıfın yapısını iyi tanımayan kişilerin kafasının karışmasına ve hatalı işlem yapmasına yol açar.
  • Spaghetti Code: Alt yordamlara kırılmadan devam eden uzun kod bloklarına bu isim verilir. Bu şekilde kodlanmış yordamların anlaşılması da, bakımının yapılması da çok zordur.

Yazılım literatüründeki Design Pattern’lar, uzun yıllardır sayısız projede test edilmiş ve zamana karşı kendini ispatlamış şemalardır. Pattern’lerin arkasındaki mantığı kavradıkça, münferit Pattern’leri birleştirerek kullanmak veya kendi Pattern’lerimizi geliştirmek de mümkündür.

Programcı ile yazılım mimarı arasındaki en önemli farklardan biri de budur. Mimar; bir yazılım ihtiyacına baktığında, o ihtiyaca uygun yapıyı sezip mevcut Pattern’lerden biri / birkaçını uygulamaya veya kendi yapısını oluşturmaya isabetli bir şekilde karar verebilecektir. Bu esnada; Anti-Pattern tuzaklarından da kaçınacaktır. Programcı, mimarın kurduğu yapı içerisindeki kodlamayı yapacaktır. Kariyerinde mimari yönde ilerlemek isteyen programcılar için, Design Pattern bilgisi elzemdir.

Design Pattern kullanmak; Object Oriented ABAP kullanmanın avantajlarını katlayacaktır. Daha sağlam, esnek ve en önemlisi genişletilebilir uygulamalar geliştirmeyi mümkün kılmaktadır. Amerika’yı tekrar keşfetmek yerine, zamanın sınavından geçmiş ve kendini ispatlamış doğru yapılar kurgulanır. Bunun sonucunda; geliştirme süreleri, hata oranları ve proje maliyetleri daha da azaltılabilir.

Sonuç

Klasik ABAP yerine Object Oriented ABAP kullanmak; geliştirme sürelerini kısaltacak, hata oranını düşürecek ve maliyetleri azaltacaktır. Design Pattern kullanmak ise, bu avantajları katlayacaktır.

Bu yaklaşımların birbiri üzerine inşa edildiği söylenebilir. ABAP’a ilk kez adım atan biri, yazılım dilini klasik ABAP yaklaşımıyla öğrenecektir. Klasik ABAP’tan bir sonraki adım, Object Oriented ABAP ile geliştirme yapmak olacaktır. Bu konuda tecrübe sahibi olup, mimari anlamda daha esnek ve kuvvetli yapılar ortaya çıkarmak isteyenler ise, bir sonraki aşamada Design Pattern’lara adım atabilir.

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.

Kendini geliştirmek isteyen ve kaynak arayışında olanlar için, birer SAP Press kitabı önerelim.

 

Standard
software, software.sap

ABAP Performance Test: Hashed Tables vs Database Buffers

There are two significant techniques to avoid repetitive access to database records: Hashed internal tables and database buffers. We ignore other internal table types because hashed tables are proven to be the fastest approach when reading single records.

If we decide to use the former method, we need to get the database record into a hashed internal table. Whenever we need to access the record, we read the internal table instead of the database table.

If we decide to use the latter method, all we need to do is to activate the table buffer in SE11. If we do that, the accessed data is cached on the application server, and the cache is used whenever possible. Thus, database access is reduced. There are exceptional cases where the buffer is bypassed, but that’s beyond the scope of this article.

Wondering how they compare in terms of performance, I created a fully buffered database table with example data.

Screen Shot 2017-10-20 at 19.12.24

I also wrote a program, which accesses the data using both techniques and compares the runtime.

It turns out that hashed access is 3-4 times faster than database buffering.

Screen Shot 2017-10-20 at 19.14.15

You can use the attached source code yourself and repeat the test; I would like to hear about any disproving results.

REPORT zdummy01.

CLASS main DEFINITION.
 PUBLIC SECTION.
   CLASS-METHODS execute.
 PROTECTED SECTION.
 PRIVATE SECTION.

CONSTANTS:
 c_do_times TYPE i VALUE 100,
 c_matnr TYPE matnr VALUE 'M1'.

CLASS-DATA:
 go_text TYPE REF TO cl_demo_text,
 gv_begin TYPE i.

CLASS-METHODS:
 hash,
 select,
 start_chrono,
 stop_chrono.

ENDCLASS. "main DEFINITION

*----------------------------------------------------------------------*
* CLASS main IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS main IMPLEMENTATION.

METHOD execute.

  go_text = cl_demo_text=>get_handle( ).

  start_chrono( ).
  hash( ).
  stop_chrono( ).

  start_chrono( ).
  select( ).
  stop_chrono( ).

  go_text->display( ).

ENDMETHOD. "execute

METHOD hash.

 DATA:
   lt_dummy
   TYPE HASHED TABLE OF zdummy01
   WITH UNIQUE KEY primary_key COMPONENTS matnr.

  FIELD-SYMBOLS:
   <ls_dummy> LIKE LINE OF lt_dummy.

  go_text->add_line( 'Starting hash read' ).

  SELECT * INTO TABLE lt_dummy FROM zdummy01.

  DO c_do_times TIMES.

    READ TABLE lt_dummy
      ASSIGNING <ls_dummy>
      WITH TABLE KEY primary_key
      COMPONENTS matnr = c_matnr.

  ENDDO.

ENDMETHOD. "hash

METHOD select.

  DATA ls_dummy TYPE zdummy01.

  go_text->add_line( 'Starting select' ).

  DO c_do_times TIMES.

    SELECT SINGLE *
      INTO ls_dummy
      FROM zdummy01
      WHERE matnr EQ c_matnr.

  ENDDO.

ENDMETHOD. "select

METHOD start_chrono.
 GET RUN TIME FIELD gv_begin.
ENDMETHOD. "start_chrono

METHOD stop_chrono.

  DATA:
    lv_diff TYPE i,
    lv_difft TYPE cl_demo_text=>t_line,
    lv_end TYPE i.

  GET RUN TIME FIELD lv_end.
  lv_diff = lv_end - gv_begin.
  WRITE lv_diff TO lv_difft LEFT-JUSTIFIED.

  go_text->add_line(:
    'Runtime result:' ),
   lv_difft ).

ENDMETHOD. "stop_chrono

ENDCLASS. "main IMPLEMENTATION

START-OF-SELECTION.
 main=>execute( ).

 

Standard
software, software.career, software.sap

Tecrübesiz Yeni Mezun Danışman Adayları

Bugün; yeni mezun bir arkadaşımız bana CV’sini göndererek, SAP danışmanlığına adım atmak istediğini ve tavsiyelerimi merak ettiğimi söyledi. CV’yi incelediğimde, üniversite hayatı boyunca herhangi bir SAP tecrübesi kazanmadığını gördüm. Kendisine verdiğim tavsiyeleri; başkalarına da faydalı olabileceğini düşünerek herkesle paylaşmak istiyorum.

Selam, CV’ni inceledim. Gördüğüm kadarıyla SAP tecrüben yok. Şahsen tanışmadığımız için, seni kişilik özelliklerini baz alarak da uygun bir yere öneremem.

Ara sıra SAP danışmanlık firmalarının Junior alımları veya danışman yetiştirme programları oluyor. LinkedIn üzerinden Türk danışmanlık firmalarını takibe alarak bu dönemleri kollamanı tavsiye ederim.

Bunun yanı sıra; kişisel Web sitemin FAQ bölümünde SAP kariyeri ile ilgili oldukça faydalı olacağını tahmin ettiğim bazı kaynaklar var, bunları da incelemeni tavsiye ediyorum.

Yapıcı bir karşılaştırma yapmak gerekirse; CV’si elimden geçen pek çok yeni mezunun, okuldan iş tecrübesiyle mezun olduğunu görüyorum. Ya yazları, ya da okula paralel yarı zamanlı olarak gelecekteki mesleğine istinaden tecrübe kazanmış kişiler daha çok tercih ediliyor.

Dolayısıyla; “ilk işe atılan herkes gibi tecrübesizim” ifadesi pek geçerli değil. Hobilerin ve yurtdışı tecrübesinin insanı çok geliştirdiğini savunan biri olmakla birlikte; işe alım kararı veren kişilerin CV’de aradığı şey hobi değil sıcak iş tecrübesidir. Bir modülün başında hemen iş yapabilir hale gelmiş biri tercih edilecektir.

Bu moralini bozmasın, bu tecrübelerin karşılığını daha uzun vadede alacağından şüphem yok. Ancak, sıcak tecrübe konusundaki açığını kabul edip onu kapatacak çalışmalar yapmanı öneririm. Eğer maddi açıdan karşılayabilirsen, SAP’nin veya yetkili bir kurumun eğitimlerine katılıp sertifika alabilirsin mesela. Bu tarz bir sertifika, istediğin gibi bir pozisyon bulmanı kolaylaştırır.

Seni şahsen tanıyan ve kişilik özelliklerine kefil olabilecek birinin sektöre tavsiye etmesi de etkili olur. O zaman sertifikaya belki de gerek kalmadan, en azından birkaç aylık bir deneme süresinde mutabık kalarak kendine bir pozisyon bulabilirsin. O pozisyonda kendini ispatlamak da sana kalmış.

Standard
software, software.career, software.sap

Architect vs Developer Responsibilities

Responsibilities of an architect and a developer don’t solely depend on the employees role; it also depends on the project and company type. Let me give you an overview based on my personal experience in Turkey.

Support Agreements

A support agreement is the situation where a SAP client makes a deal with a consultancy company to resolve their daily issues over tickets. In that case, the consultant is responsible of understanding the issue, solving it, making the users test it and eventually transporting the solution to the live system. One of the significant responsibilities is to resolve the tickets quickly if the matter in hand is urgent. This sometimes involves working late or at weekends.

Usually; companies agree on response time for priorities. For example; urgent tickets might expected to be replied within an hour & resolved within 24 hours, while low level tickets might expected to be replied within 24 hours & resolved within a day. In that case, this scheme would also act as the KPI of the support consultants. At the performance evaluation at the end of the year, their actual response & resolution rates are compared against the targets. This can run on team and/or personal level. FTR (first time right) is another typical KPI, which indicates the percentage of tickets where the first technical reply got accepted by the client.

In typical support deals, we rarely see architects get involved. Support issues are basically small corrections or enhancements on an existing system, so no architects are full time present. In case a correction needs modification on the fundamental level or some supervisory advice is needed, that’s where they step in. Knowing and understanding the bowels, standards and deep infrastructure of the system much better than developers, the architect can make those fundamental modifications accurately and risk free. Alternatively, the architect can guide the developer on how to proceed – that’s also possible. Whenever a developer without architectural knowledge attempts to do a fundamental change, we usually see anti-patterns emerge.

You can imagine it like this: You can hire a worker to paint your walls, no architect needed. But in case you want to expand your swimming pool, you ask your architect first.

Implementation Projects

This is the deal where a consulting company implements a new functionality to a SAP client. It can be a huge fresh SAP implementation, or a mid-sized implementation of a new functionality over an existing system; or even an upgrade. That’s where ideally developers work under the supervision of an architect.

Each project has a number of tasks to complete. On shallow tasks, the developers would be allowed to directly start with the development. However, the architect walks in for bigger developments, frameworks, integrations and similar comprehensive tasks. The architect usually designs the framework, does the low level coding, does a few demo implementations, and leaves the rest to developers. Other developers build on top of what the architect has prepared.

If I had to list some typical responsibilities on top of my head; an architect would be resposible of:

  • Defining the development standards, naming conventions and document formats
  • Technical supervision to functional consultants during the analysis phase
  • Supporting time estimations
  • Acting as an objective technical authority in meetings
  • Communication and agreement with non-SAP architects on integration points
  • Supervision to project management for task distribution
  • Architectural design & development of complex applications
  • Framework design & development for applications sharing a common ground
  • Supervising developers so they don’t re-invent the wheel
  • Review & validation of code from developers
  • Prevention of code duplication
  • Pursuing and evaluating test results
  • Pursuing architectural, technical, performance and usability excellence
  • Early recognition & proactive measures of architectural risks; such as contradicting or overlapping requirements
  • General responsibility of the big picture

If I had to do the same for developers;

  • Writing clean, understandable, optimized code with enough comments
  • Complying with technical standards of the project and global best practices
  • Re-using code whenever possible
  • Maximizing information flow with co-workers and the architect
  • Finishing tasks on time
  • Supporting tests and correcting bugs
  • Consult the architect on uncertain cases

Pre-Sales

This is the case where the consulting company wants to sell a product or service to a potential client.

In such cases, presence of the architect is more than welcome due to a lot of reasons; of which some are listed below:

  • Knowledge of the architect would positively influence the client
  • An architect can conclude technical discussions with the client’s employees rather quickly
  • In case a demo application is needed, an architect can understand, plan and implement it very well; demonstrating the technical muscle of the consulting company
  • An architect can inform the sales team of technical limitations and regulations; proactively stopping them from making unfulfillable promises
  • Accuracy of development time estimations would increase

Conclusion

The picture I painted in this article is far from complete; however, I think that it gave you the overall insight you needed. In summary; you can imagine the developers like construction workers, and the software architect like a, well, architect (doh).

Standard
software, software.sap

Parsing JSON in ABAP

SAP ECC has two beautiful classes for JSON parsing operations.

/ui2/cl_json is useful in case you know the structure of the JSON file. Similar to the CALL TRANSFORMATION command; you can parse a JSON string directly if you have a corresponding nested structure. This class is very forgiving too; it doesn’t raise any exceptions if your structure has missing or excess fields. Turning a nested ABAP structure into a JSON string is also possible.

/ui5/cl_json_parser is useful in case you don’t know the exact structure of the JSON file. When you pass the JSON string to this class, it simply transforms the data into an internal table of key / value pairs. It is your responsibility to loop through this ITAB to fetch whatever you are looking for. It doesn’t transform your nested structure into JSON format at this time though – it parses JSON strings only.

Standard