W tej części kursu poznamy budowę programu ABAP i zobaczymy, gdzie umieszcza się typy, stałe, zmienne, ekran selekcji oraz właściwą logikę programu.

W pierwszej części kursu ABAP utworzyliśmy nasz pierwszy program w transakcji SE38. Poznaliśmy edytor, sprawdziliśmy składnię, aktywowaliśmy program i uruchomiliśmy go bezpośrednio w systemie.

Najważniejsze przyciski w SE38 – zapis, kontrola, aktywacja i uruchomienie

Samo wpisanie kodu nie wystarczy. Aby uruchomić jego aktualną wersję, trzeba ją zapisać, sprawdzić i aktywować. W edytorze ABAP najczęściej korzystamy z następujących funkcji:

Pretty Printer nie naprawia logiki programu. Może uporządkować źle wcięty kod, ale nie sprawdzi, czy program robi to, czego oczekujemy. Do błędów składni służy kontrola składni, a do sprawdzenia zachowania programu – jego uruchomienie i testy.

Najbezpieczniejsza kolejność pracy początkującego wygląda więc tak:

1. zapisz program,
2. sprawdź składnię,
3. użyj Pretty Printera,
4. aktywuj program,
5. uruchom go klawiszem F8.

Nasz pierwszy kod był bardzo krótki:

Taki program łatwo zrozumieć, ponieważ zawiera zaledwie dwie instrukcje. Prawdziwe programy szybko jednak zaczynają rosnąć. Pojawiają się własne typy, stałe, zmienne, struktury, tabele wewnętrzne, field symbole, parametry użytkownika oraz właściwa logika.

Kiedy pierwszy raz otworzyłem większy program ABAP, miałem wrażenie, że wszystkie te deklaracje zostały wrzucone do jednego worka. Dopiero później zrozumiałem, że większość raportów można podzielić na kilka logicznych części.

W tej lekcji nie będziemy jeszcze szczegółowo uczyć się każdej instrukcji. Najpierw zbudujemy sobie mapę programu ABAP i zobaczymy:

• gdzie znajduje się definicja programu,
• gdzie deklaruje się własne typy,
• gdzie umieszcza się stałe i obiekty danych,
• gdzie mogą znajdować się deklaracje field symboli,
• w jaki sposób powstaje ekran selekcji,
• gdzie rozpoczyna się właściwe wykonywanie programu.

Po tej lekcji nie musisz jeszcze umieć samodzielnie napisać całego raportu. Ważne, abyś potrafił spojrzeć na kod i rozpoznać jego najważniejsze części.

Czy każdy program ABAP ma identyczną budowę?

Nie. ABAP nie wymaga, aby każdy program posiadał wszystkie sekcje przedstawione w tej lekcji. Bardzo prosty raport może zawierać tylko instrukcję REPORT i kilka kolejnych poleceń. Bardziej rozbudowany może korzystać z lokalnych klas, metod albo dodatkowych obiektów repozytorium.

Nie istnieje również obowiązkowa sekcja DATA, do której trzeba wrzucić wszystkie zmienne z całego programu. Część deklaracji może znajdować się na poziomie całego raportu, a część lokalnie – możliwie blisko miejsca, w którym dane są używane.

Pokazany niżej układ jest zatem czytelnym szkieletem edukacyjnym, a nie jedyną dozwoloną budową programu.

Jak wygląda budowa programu ABAP?

Na początek spójrzmy na uproszczoną mapę raportu:

REPORT zabap_lekcja_02.

" 1. Definicje własnych typów
TYPES ...

" 2. Stałe
CONSTANTS ...

" 3. Globalne obiekty danych
DATA ...

" 4. Field symbole
FIELD-SYMBOLS ...

" 5. Ekran selekcji
PARAMETERS ...
SELECT-OPTIONS ...

" 6. Zdarzenia programu
INITIALIZATION.
  ...

AT SELECTION-SCREEN.
  ...

START-OF-SELECTION.
  ...

Nie każdy raport wykorzystuje wszystkie te elementy. Ich kolejność pomaga jednak szybko odnaleźć się w kodzie.

Oto przykład na prawdziwym systemie:

1. REPORT – definicja programu wykonywalnego

Program rozpoczynamy instrukcją REPORT:

REPORT zabap_lekcja_02.

Informuje ona system, że mamy do czynienia z programem wykonywalnym. Nazwa podana po REPORT powinna odpowiadać nazwie programu utworzonego w repozytorium.

W naszym przypadku program nazywa się ZABAP_LEKCJA_02. Litera Z oznacza, że jest to obiekt klienta, a nie standardowy program dostarczony przez SAP.

2. TYPES – definiowanie własnych typów

Instrukcja TYPES służy do tworzenia lokalnych typów danych.

Na początek wystarczy nam bardzo prosty przykład:

TYPES ty_user_name TYPE string.

Samo użycie TYPES nie tworzy jeszcze zmiennej i nie zapisuje żadnej wartości. Tworzymy jedynie wzór danych, z którego skorzystamy później.

Można porównać to do projektu formularza. Projekt określa, jak ma wyglądać formularz, ale nie jest jeszcze jego wypełnionym egzemplarzem.

Za pomocą TYPES możemy również definiować bardziej rozbudowane struktury oraz typy tabel wewnętrznych. Na razie wystarczy wiedzieć, że takie definicje również umieszczamy w części deklaracyjnej. Ich budowę poznamy dokładnie w kolejnych lekcjach.

Definicja typu powinna pojawić się przed deklaracją danych, która z niego korzysta. System musi najpierw poznać ty_user_name, abyśmy mogli później zadeklarować obiekt tego typu.

3. CONSTANTS – wartości, które nie powinny się zmieniać

Stałe deklarujemy za pomocą instrukcji CONSTANTS:

CONSTANTS gc_greeting TYPE string VALUE 'Witaj'.

W przeciwieństwie do zwykłej zmiennej wartość stałej nie może zostać później zmieniona podczas wykonywania programu.

Stała przydaje się wtedy, gdy ta sama wartość ma określone znaczenie i jest wykorzystywana w kodzie. Dzięki nazwie gc_greeting od razu widzimy, że wartość będzie używana jako powitanie.

Prefiks gc_ możemy przeczytać jako global constant, czyli stała globalna.

W późniejszych lekcjach porozmawiamy dokładniej o zasięgu danych i o tym, dlaczego nie należy bez potrzeby deklarować wszystkiego globalnie.

4. DATA – tworzenie obiektów danych

Instrukcja DATA tworzy obiekty, w których program może przechowywać wartości.

W tym miejscu warto zauważyć ważną różnicę:

TYPES ty_user_name TYPE string.
DATA gv_user_name TYPE ty_user_name.

• TYPES opisuje typ danych,
• DATA tworzy konkretny obiekt danych.

Mówiąc prościej: TYPES przygotowuje projekt pudełka, natomiast DATA stawia przed nami prawdziwe pudełko, do którego możemy coś włożyć.

Za pomocą DATA możemy deklarować różne obiekty:

DATA gv_quantity TYPE i.

W kolejnych lekcjach zobaczymy, że za pomocą DATA deklaruje się nie tylko pojedyncze zmienne, lecz także struktury i tabele wewnętrzne. Tabela wewnętrzna nie wymaga osobnej „sekcji tabel”. Jest obiektem danych i dlatego również deklarujemy ją za pomocą DATA, podając odpowiedni typ.

Najczęściej spotykane prefiksy

Prefiksy nie są obowiązkową częścią języka. Najważniejsza pozostaje czytelna nazwa mówiąca, jakie znaczenie ma dana wartość.

5. Czy wszystkie zmienne deklarujemy na początku programu?

Nie. W starszych programach ABAP często zobaczymy dużą sekcję deklaracji umieszczoną na samej górze. Współczesny ABAP pozwala deklarować dane lokalnie i bezpośrednio w miejscu użycia.

Klasyczna deklaracja może wyglądać tak:

DATA lv_quantity TYPE i.

lv_quantity = 10.

Deklaracja inline pozwala połączyć utworzenie zmiennej z przypisaniem wartości:

DATA(lv_quantity) = 10.

W tej lekcji jedynie zaznaczamy istnienie obu sposobów. Deklaracje DATA, podstawowe typy oraz deklaracje inline będą głównym tematem trzeciej części cyklu.

Zgodnie z podejściem Clean ABAP dane powinny być deklarowane możliwie blisko miejsca użycia, jeżeli nie pogarsza to czytelności. Nie oznacza to jednak, że musimy na siłę przerabiać każdą deklarację na inline.

6. FIELD-SYMBOLS – na razie tylko zapowiedź

W części deklaracyjnej programu możemy spotkać również instrukcję FIELD-SYMBOLS.

Field symbol nie przechowuje własnej kopii danych. Może natomiast wskazywać na dane znajdujące się w innym miejscu – na przykład na aktualnie przetwarzany wiersz tabeli wewnętrznej.

Wyobraź sobie kartkę z zapisaną wartością. Zwykła zmienna przypomina samą kartkę, natomiast field symbol przypomina palec wskazujący konkretną kartkę. Nie tworzy kolejnej kopii informacji, tylko pozwala pracować bezpośrednio ze wskazanymi danymi.

Na tym etapie nie będziemy jeszcze deklarować ani używać field symboli w naszym programie. Wrócimy do nich dopiero wtedy, gdy poznamy tabele wewnętrzne, pętlę LOOP AT oraz różnicę pomiędzy INTO i ASSIGNING.

7. Ekran selekcji – dane podawane przez użytkownika

Program wykonywalny może posiadać ekran selekcji, na którym użytkownik podaje wartości przed jego uruchomieniem.

Najprostsze pole możemy utworzyć za pomocą PARAMETERS:

PARAMETERS p_name TYPE string LOWER CASE.

Po uruchomieniu programu system automatycznie wyświetli pole, w którym użytkownik może wpisać swoje imię.

Do wprowadzania zakresów wartości służy natomiast instrukcja SELECT-OPTIONS. Na razie nie będziemy jej używać ani dokładnie analizować różnicy pomiędzy PARAMETERS i SELECT-OPTIONS. Wrócimy do niej w osobnej lekcji o ekranie selekcji.

Ważne jest teraz to, że deklaracje ekranu selekcji umieszczamy przed blokami odpowiedzialnymi za przetwarzanie programu.

Kolejność instrukcji tworzących ekran ma również wpływ na kolejność wyświetlanych pól.

Oto przykład, jak na ekranie selekcji wygląda parametr (w naszym przypadku p_name):

8. Zdarzenia programu ABAP – kiedy wykonywany jest kod?

Po części deklaracyjnej dochodzimy do bloków przetwarzania. Nagłówki takie jak INITIALIZATION, AT SELECTION-SCREEN i START-OF-SELECTION nie są zwykłymi etykietami porządkującymi kod. Są to zdarzenia: środowisko uruchomieniowe ABAP wywołuje je automatycznie w określonych momentach pracy raportu.

INITIALIZATION – wartości początkowe ekranu

INITIALIZATION.
  p_name = 'Marek'.

Blok INITIALIZATION jest wykonywany przed pierwszym wyświetleniem standardowego ekranu selekcji. Najczęściej służy do nadania polom sensownych wartości początkowych.

W tym przykładzie parametr p_name otrzymuje wartość Marek. Gdy ekran selekcji pojawi się na monitorze, pole nie będzie puste – użytkownik zobaczy już wpisane imię i może je zaakceptować albo zmienić.

Nie umieszczamy tutaj głównego odczytu danych ani właściwej logiki biznesowej. To etap przygotowania ekranu, zanim użytkownik zacznie z nim pracować.

AT SELECTION-SCREEN – kontrola danych użytkownika

AT SELECTION-SCREEN.
  IF p_name IS INITIAL.
    MESSAGE 'Wpisz imię.' TYPE 'E'.
  ENDIF.

AT SELECTION-SCREEN jest wywoływane podczas obsługi ekranu selekcji, między innymi po naciśnięciu F8. To dobre miejsce na sprawdzenie, czy użytkownik podał prawidłowe dane.

W naszym przykładzie program sprawdza, czy p_name jest puste. Jeśli tak, komunikat typu E zatrzymuje dalsze przetwarzanie i pozostawia użytkownika na ekranie selekcji. Dzięki temu blok START-OF-SELECTION nie zostanie wykonany z niepoprawnymi danymi.

W większych raportach można stosować także bardziej precyzyjne warianty zdarzenia, na przykład AT SELECTION-SCREEN ON p_name, aby walidować konkretne pole. Na tym etapie prosty blok ogólny jest jednak czytelniejszy.

START-OF-SELECTION – właściwe przetwarzanie raportu

START-OF-SELECTION.
  WRITE |Witaj, { p_name }!|.

Jeśli dane na ekranie selekcji przejdą kontrolę, system rozpoczyna właściwe przetwarzanie raportu i wywołuje START-OF-SELECTION. Tutaj zwykle zaczynamy wykonywać zasadnicze zadanie programu: pobieramy dane, wykonujemy obliczenia albo przygotowujemy wynik.

W naszym prostym przykładzie program wyświetla powitanie. W większym, nowoczesnym raporcie blok zdarzenia nie powinien jednak zawierać setek linii szczegółowej logiki. Najczęściej powinien pozostać krótki i wywoływać odpowiednio nazwaną metodę klasy. Do programowania obiektowego wrócimy w późniejszej części cyklu.

9. W jakiej kolejności wykonywany jest raport?

Dla naszego uproszczonego przykładu przebieg wygląda następująco:

1. System zna deklaracje programu, typów, stałych i obiektów danych.
2. Wykonywane jest zdarzenie INITIALIZATION.
3. Użytkownik widzi ekran selekcji i podaje dane.
4. System obsługuje zdarzenia ekranu selekcji, na przykład AT SELECTION-SCREEN.
5. Po uruchomieniu przetwarzania wykonywany jest blok START-OF-SELECTION.

Nie jest to jeszcze pełna lista wszystkich zdarzeń raportu ABAP. Na początku nie potrzebujemy jednak encyklopedii. Chcemy jedynie zrozumieć główny przepływ prostego programu.

10. Kompletny przykład programu ABAP

Poniższy przykład łączy poznane części w jeden raport:

REPORT zabap_lekcja_02.

*--------------------------------------------------------------------*
* Definicje typów
*--------------------------------------------------------------------*
TYPES ty_user_name TYPE string.

*--------------------------------------------------------------------*
* Stałe
*--------------------------------------------------------------------*
CONSTANTS gc_greeting TYPE string VALUE 'Witaj'.

*--------------------------------------------------------------------*
* Globalne obiekty danych
*--------------------------------------------------------------------*
DATA gv_user_name TYPE ty_user_name.

*--------------------------------------------------------------------*
* Ekran selekcji
*--------------------------------------------------------------------*
PARAMETERS p_name TYPE string LOWER CASE.

*--------------------------------------------------------------------*
* Inicjalizacja
*--------------------------------------------------------------------*
INITIALIZATION.
  p_name = 'Marek'.

*--------------------------------------------------------------------*
* Walidacja ekranu selekcji
*--------------------------------------------------------------------*
AT SELECTION-SCREEN.
  IF p_name IS INITIAL.
    MESSAGE 'Wpisz imię.' TYPE 'E'.
  ENDIF.

*--------------------------------------------------------------------*
* Główne przetwarzanie
*--------------------------------------------------------------------*
START-OF-SELECTION.

  gv_user_name = p_name.

  WRITE |{ gc_greeting }, { gv_user_name }!|.

Najważniejsze jest teraz rozpoznanie:

• gdzie rozpoczyna się program,
• gdzie zdefiniowano typy,
• gdzie znajduje się stała,
• gdzie utworzono obiekt danych,
• gdzie zbudowano ekran selekcji,
• gdzie rozpoczyna się logika programu.

Tak wygląda gotowy program: po wpisaniu imienia na ekranie selekcji (1) i wciśnięciu F8 (uruchomieniu programu) pojawia się tekst jak niżej:

11. Komentarze w ABAP – co oznacza wykomentowanie kodu?

W naszym programie używamy komentarzy do opisania poszczególnych części kodu:

*--------------------------------------------------------------------*
* Definicje typów
*--------------------------------------------------------------------*
TYPES ty_user_name TYPE string.

Komentarz jest informacją przeznaczoną dla programisty. System ABAP go nie wykonuje, dlatego możemy za jego pomocą wyjaśnić trudniejszy fragment programu albo zaznaczyć przeznaczenie danej sekcji.

W ABAP najczęściej spotkasz dwa sposoby zapisywania komentarzy:

• * w pierwszej kolumnie – cała linia jest komentarzem,
• " – komentarzem staje się wszystko od cudzysłowu do końca linii.

* Cała ta linia jest komentarzem
DATA gv_user_name TYPE string. " Komentarz na końcu instrukcji

Wykomentować kod oznacza zmienić działającą instrukcję w komentarz, aby system chwilowo jej nie wykonywał. Przykładowo:

* WRITE |Witaj, { p_name }!|.

Po dodaniu znaku * instrukcja WRITE pozostaje widoczna w edytorze, ale nie zostanie wykonana. Jest to przydatne podczas krótkiego testu, jednak nie warto pozostawiać w programie dużych fragmentów starego, wykomentowanego kodu. Historię zmian przechowuje system wersji, a martwy kod tylko utrudnia czytanie programu.

Dobry komentarz wyjaśnia przede wszystkim dlaczego zrobiliśmy coś w określony sposób. Nie powinien jedynie powtarzać tego, co jasno wynika z instrukcji i dobrze dobranych nazw.

12. Podział na sekcje a Clean ABAP

Komentarze oddzielające sekcje pomagają na początku zobaczyć budowę raportu. W prawdziwym programie nie warto jednak tworzyć ogromnych nagłówków tylko po to, aby ukryć fakt, że kod stał się zbyt długi.

Czytelność powinniśmy osiągać przede wszystkim dzięki:

• dobrym nazwom,
• krótkim fragmentom logiki,
• deklaracjom umieszczanym blisko miejsca użycia,
• unikaniu niepotrzebnych zmiennych globalnych,
• przenoszeniu większej logiki do odpowiednio nazwanych metod.

Na obecnym etapie korzystamy z jednego raportu, ponieważ łatwo uruchomić go w SE38 i obserwować rezultat. Z czasem zaczniemy stopniowo przechodzić do podejścia obiektowego.

13. Zadanie dla czytelnika

Utwórz program ZABAP_LEKCJA_02 i podziel go na następujące części:

1. instrukcja REPORT,
2. własny prosty typ danych,
3. stała,
4. deklaracja zmiennej za pomocą DATA,
5. parametr ekranu selekcji,
6. blok INITIALIZATION,
7. blok START-OF-SELECTION.

Na początku bloku START-OF-SELECTION możesz umieścić tylko prostą instrukcję:

WRITE |Witaj, { p_name }!|.

Następnie odpowiedz sobie na kilka pytań:

• Czy TYPES utworzyło już obiekt zawierający wartość?
• Jaką instrukcją została zadeklarowana zmienna?
• Która część kodu odpowiada za pole widoczne na ekranie?
• W którym miejscu rozpoczyna się główne przetwarzanie?

Podsumowanie

W tej części poznaliśmy ogólną budowę programu wykonywalnego ABAP.

Wiemy już, że:

• • REPORT definiuje program wykonywalny,
  • TYPES pozwala opisywać własne typy danych,
  • CONSTANTS służy do deklarowania stałych,
  • DATA tworzy obiekty danych, w tym zmienne, struktury i tabele wewnętrzne,
  • FIELD-SYMBOLS służy do deklarowania odwołań do istniejących danych – jego praktyczne zastosowanie poznamy później,
  • PARAMETERS i SELECT-OPTIONS budują elementy ekranu selekcji,
  • START-OF-SELECTION rozpoczyna główne przetwarzanie prostego raportu,
  • komentarze opisują kod, ale nie są wykonywane przez system.

Poznaliśmy również bardzo ważną zasadę: zaprezentowany podział jest czytelnym sposobem organizacji kodu, a nie obowiązkowym formularzem, który każdy program musi wypełnić od góry do dołu.

W następnej części zajmiemy się dokładniej zmiennymi. Porównamy klasyczne deklaracje DATA z deklaracjami inline DATA(...), poznamy podstawowe typy danych i zobaczymy, w jaki sposób przypisywać oraz zmieniać wartości.

Źródła i dalsza nauka

• SAP ABAP Keyword Documentation
• Clean ABAP – oficjalny przewodnik SAP
• ABAP Cheat Sheets – przykłady przygotowane przez SAP

Zostaw to pole puste

Chcesz być informowany o nowych wpisach?

Ja nie spamuje! Przeczytaj zasady polityki prywatności tego bloga.

Sprawdź swoją skrzynkę odbiorczą (albo katalog na spam) i potwierdź swoją subskrypcję.