Podstawy programowania w ABAP.pdf

Podstawy programowania w języku ABAP

Instytut Automatyki i Informatyki Stosowanej Politechniki Warszawskiej

PODSTAWY PROGRAMOWANIA W JĘZYKU ABAP dr inż. Mariusz Kaleta

listopad 2007

Copyright © 2007 by Instytut Automatyki i Informatyki I nformatyki Stosowanej Politechniki Warszawskiej. Wszystkie prawa zastrzeżone. Żadna część tej publikacji nie może być reprodukowana, przechowywana w bazach danych, transmitowana w żadnej formie ani w żaden sposób, elektroniczny, mechaniczny, kserograficzny czy inny, bez uprzedniej pisemnej zgody autorów.

-1-


1.

STRUKTURA SYSTEMU ZINTEGROWANEGO ................................................... ................................................................................. .............................. 4

2.

ŚRODOWISKO PROGRAMISTYCZNE SAP................................................. ........................................ 6

3.

PODSTAWY JĘZYKA ABAP ....................................................... .......................................................... 10

4.

5.

6.

7.

3.1.

TYPY DANYCH.....................................................................................................................................10

3.2.

ELEMENTARNE OPERACJE NA OBIEKTACH...........................................................................................15

3.3.

K ONTROLA ONTROLA PRZEPŁYWU STEROWANIA ................................................................................................18

3.4.

MODULARNOŚĆ ..................................................................................................................................19

PODSTAWOWE KONSTRUKCJE JĘZYKA ABAB ......................................................... .................. 22 4.1.

PRZETWARZANIE NAPISÓW .................................................................................................................22

4.2.

DYNAMICZNY DOSTĘP DO OBIEKTÓW..................................................................................................23

4.3.

PRZETWARZANIE TABEL WEWNĘTRZNYCH..........................................................................................24

OBIEKTOWOŚĆ W ABAP......................................................................................................................29 5.1.

K LASY LASY.................................................................................................................................................29

5.2.

DZIEDZICZENIE I POLIMORFIZM...........................................................................................................32

5.3.

I NTERFEJSY .........................................................................................................................................32

5.4.

ZDARZENIA .........................................................................................................................................34

PROGRAMOWANIE EKRANÓW.........................................................................................................35 6.1.

LISTY ..................................................................................................................................................35

6.2.

EKRANY OGÓLNE ................................................................................................................................37

6.3.

EKRANY WYBORU ...............................................................................................................................44

6.4.

K OMUNIKATY OMUNIKATY .....................................................................................................................................48

6.5.

MENU KONTEKSTOWE .........................................................................................................................49

ZEWNĘTRZNE ŹRÓDŁA DANYCH .................................................... ................................................ 49 7.1.

WSPÓŁPRACA Z BAZĄ DANYCH ...........................................................................................................49

7.2.

OBSŁUGA PLIKÓW ...............................................................................................................................53

-2-


Wstęp Raport rozpoczynamy od omówienia struktury systemu zintegrowanego. Głównym elementem struktury jest centralne repozytorium integrujące całość zasobów informacyjnych przedsiębiorstwa, wokół którego budowane są poszczególne elementy funkcjonalne. Ze względu na kompleksowość rozwiązań zintegrowanych oraz specyfikę poszczególnych poszczególnych wdrożeń, rozwiązania komercyjne muszą dostarczać platformy programistyczne pozwalające rozwijać i dopasowywać moduły systemu do potrzeb danego przedsiębiorstwa. Ze względu na charakter problemu, a więc przede wszystkim zadania przetwarzania danych, platformy programistyczne systemów zintegrowanyc zi ntegrowanychh są często budowane w oparciu o języki programowania czwartej generacji (4GL). Czołowy system na rynku SAP jest zbudowany prawie w całości w oparciu o język ABAP należący do klasy języków 4GL. W ramach niniejszego raportu przedstawiamy środowisko programistyczne ABAB Workbench oraz omawiamy podstawy programowania w języku ABAP. Najpierw skupiamy się na strukturze podstawowych strukturach języka: typach danych, składni, kontroli przepływu sterowania, a następnie omawiamy najważniejsze elementy obejmujące operacje na tablicach wewnętrznych, programowanie ekranów, dostęp do bazy danych danych oraz elementy obiektowości obiektowości w ABAP.

-3-


1. Struktura systemu zintegrowanego Zintegrowane systemy informatyczne to klasa systemów informatycznych odznaczająca się stosunkowo dużym stopniem zaawansowania technologicznego i funkcjonalnego spośród systemów informatycznych wspomagających zarządzanie przedsiębiorstwami. Systemy zintegrowane obejmują większość procesów realizowanych w przedsiębiorstwie jak i jego najbliższym otoczeniu dążąc do jak największej automatyzacji procesów wewnętrznych oraz w ramach współpracy z kooperantami w całym łańcuch dostaw. Cechy charakterystyczne zintegrowanego systemu informatycznego (ZSI) istotne z punktu widzenia jego struktury są następujące: •

obszerna i kompleksowa funkcjonalność,

•

integracja danych i procedur w czasie rzeczywistym,

•

zaawansowanie zaawansowanie merytoryczne,

•

skalowalność,

•

otwartość,

•

ujednolicenie interfejsów i procedur,

zorientowanie na e-biznes. Kompleksowość funkcjonalna jest niezbędna ze względu na zakres działalności przedsiębiorstw, jaki jest pokrywany przez systemy zintegrowane. Obejmuje to wszystkie główne sfery działalności przedsiębiorstw o różnej specyfice, w szczególności obszary związane z aspektami finansowymi, jak również obszary związane z technologią produkcji i logistyką. Systemy odznaczające się tak duża kompleksowością, a co za tym idzie złożonością realizowanych funkcji wymagają stosowania zaawansowanych rozwiązań technologicznych oraz modularyzacji. Systemy zintegrowane są w praktyce zbiorami modułów aplikacyjnych pokrywających się z obszarami działalności przedsiębiorstwa, np. z obsługą finansów, zasobów ludzkich, logistyki, produkcji itd. lub przekrojowych (patrz Rys. 1.1). •

Współpraca modułów aplikacyjnych jak i wymóg dostępu do danych i realizacji procedur w czasie rzeczywistym jest realizowany poprzez centralne repozytorium danych. Całokształt wiedzy przedsiębiorstwa, wszystkie obiekty informacyjne związane z prowadzonymi procesami biznesowymi są przechowywane przechowywane centralnie. Jednym z głównych czynników ZSI jest integracja danych pochodzących pochodzących z wielu źródeł w wielu różnych obszarach organizacji. Moduły aplikacyjne mają dostęp do wszystkich danych przedsiębiorstwa, który może być ograniczony jedynie poprzez system uprawnień. Dzięki temu jest możliwa natychmiastowa aktualizacja danych zasilających jeden moduł aplikacyjny będąca wynikiem przetwarzania danych przez inny moduł. Informacje o zdarzeniach i zmianach w stanie przedsiębiorstwa są wprowadzane tylko raz i natychmiast dostępne dla wszystkich użytkowników w ramach różnych modułów. Z punktu widzenia zarządzania przedsiębiorstwem możliwe staje się zarządzanie i reagowanie na zachodzące zdarzenia w możliwie najkrótszym czasie. Kompleksowość systemów zintegrowanych przejawia się nie tylko poprzez obejmowanie ich działaniem różnych obszarów aktywności przedsiębiorstw, ale również poprzez dostarczanie bogatego zakresu metod wsparcia w optymalizacji i zarządzaniu tymi procesami. Zaawansowanie merytoryczne systemów zintegrowanych uwidacznia się poprzez wsparcie ust I n T ime ime), MRP II ( M anufacturing anufacturing Resorce dla różnych koncepcji zarządzania m.in. JIT ( J ust -4-


P lanning lanning ), ),

otal Quality M anagement anagement ). TQM (T otal ). Poszczególne moduły aplikacyjne tworzą obraz systemu o zaawansowanych rozwiązaniach merytorycznych, w tym elementach prognozowania, prognozowania, optymalizacji, agregacji agregacji danych, ekstrakcji ekstrakcji wiedzy. Rozwój przedsiębiorstwa może powodować wzrost wymagań dotyczących wydajności przetwarzania danych w systemie zintegrowanym. Skalowalność ZSI jest osiągana poprzez stosowanie architektury wielowarstwowej, w której poszczególne elementy systemu mogą być alokowane na wyodrębnionych zasobach sprzętowych tworząc strukturę rozproszoną. Rozwój przedsiębiorstwa może również skutkować wzrostem złożoności operacji biznesowych, aż w konsekwencji konsekwencji do redefinicji tych procesów. Z tego względu modułowa architektura systemów zintegrowanych ułatwia wprowadzanie modyfikacji w systemie oraz rozszerzanie o nowe funkcjonalności. Jest to szczególnie łatwe w systemach dostarczających środowisko rozwoju aplikacji, najczęściej oparte o język programowania czwartej generacji (4GL) wysokiego poziomu ukierunkowany na przetwarzanie danych. Przykładem może być system SAP, w którym środowisko ABAP Workbench umożliwia dostosowywanie oraz tworzenie aplikacji w języku ABAP. Większość modułów funkcjonalnych dostarczanych w ramach SAP jest zakodowana w języku ABAP.

Uniwersalne systemy zintegrowane często są wzbogacane o moduły specyficzne dla określonych branży. Wdrożenia systemów dotyczą zazwyczaj podzbiorów modułów funkcjonalnych, które muszą więc funkcjonować samoistnie oraz we współpracy z innymi podzbiorami modułów. Integracja wielu aspektów działalności przedsiębiorstwa w ramach jednego systemu umożliwia ustandaryzowanie interfejsu systemu używanego zarówno w bezpośredniej komunikacji z użytkownikiem systemu jak i w wymianie danych z systemami zewnętrznymi. Standaryzacja interfejsów dotyczy również aspektów uprawnień dostępu do danych. Zorientowanie systemów zintegrowanych na e-biznes jest silną tendencją rozwojową, mającą wpływ na strukturę techniczną systemów. Wymusza stosowanie rozwiązań charakterystycznych dla systemów działających w sposób rozproszony w sieci typu Internet, w tym protokołów komunikacyjnych między warstwami, usług sieciowych ( web services), serwerów aplikacyjnych (J2EE). Rys. 1.1 przedstawia ogólną strukturę systemu zintegrowanego. Ogólnie jest to architektura wielowarstwowa z wyróżnieniem co najmniej trzech warstw: prezentacji, aplikacji i bazy danych. Przetwarzanie danych i komunikacja między warstwami odbywa się w strukturze klient-serwer z wykorzystaniem standardowych protokołów, np. TCP/IP. Komponenty oprogramowania naturalnie odseparowane od siebie w strukturze warstwowej mogą funkcjonować centralnie lub w sposób rozproszony na odrębnych maszynach serwerowych. Ponieważ strukturę systemu zintegrowanego tworzą zazwyczaj moduły funkcjonalne o pewnej zamkniętej funkcjonalności z dobrze zdefiniowanym interfejsem, to również rozproszenie modułów w ramach tych samych warstw jest możliwe. Warstwę prezentacji tworzy dedykowane środowisko graficzne GUI lub cienki klient w postaci przeglądarki internetowej. Zazwyczaj Zazwyczaj systemy zintegrowane oferują oba typy interfejsów jednocześnie. Poniżej warstwy prezentacji, w warstwie aplikacji znajdują się moduły aplikacyjne realizujące poszczególne funkcje biznesowe, a także komponent spajający wszystkie moduły, tzw. jądro systemu. Jądro systemu może zawierać środowisko rozwojowe, interpreter/kompilator języka 4GL oraz innych użytych do budowy modułów aplikacyjnych, usługi zarządzania systemem, obsługi systemu zabezpieczeń i autoryzacji, obsługę synchronizacji, kolejkowania, komunikacji oraz inne elementy przekrojowe systemu. W najniższej warstwie znajduje się system zarządzania relacyjną bazą danych oraz baza pełniąca rolę centralnego centralnego repozytorium. -5-


Rys. 1.1. Struktura systemu zintegrowanego

2. Środowisko programistyczne SAP Środowiskiem deweloperskim dla tworzenia programów ABAP jest środowisko ABAP Workbench, które jest częścią każdej instancji SAP. ABAP ( Advanced Business A pplication rogramming ) jest językiem P rogramming j ęzykiem programowania systemu SAP. Poza rdzeniem SAP napisanym w C, wszystkie aplikacje, łącznie ze środowiskiem deweloperskim, są napisane w języku ABAP. ABAP Objects jest rozszerzeniem języka ABAP o elementy obiektowości, w szczególności enkapsulację, dziedziczenie, polimorfizm. Ponieważ ABAP rozwijał się od lat dziewięćdziesiątych, aktualnie wspiera równolegle dwa modele programowania: model zorientowany proceduralnie oraz model zorientowany obiektowo. ABAP jest językiem dedykowanym do przetwarzania danych biznesowych działając na relacyjnych bazach danych. Środowisko ABAP Workbench można odnaleźć w drzewku aplikacji SAP Easy Access w węźle Tools. Przed rozpoczęciem pracy każdy programista SAP musi zostać zarejestrowany poprzez SAPNet i otrzymać przypisany do siebie klucz klu cz deweloperski. Najważniejsze moduły środowiska ABAP Workbench to (patrz Rys. 2.1): •

ABAP Editor umożliwiający umożliwiający edycję programów ABAP,

•

ABAP Dictionary

•

dający dostęp do repozytorium obiektów i umożliwiający ich tworzenie (w tym tabel t abel bazodanowych), bazodanowych), Screen Painter – – narzędzie do tworzenia ekranów,

•

Menu Painter – – narzędzie do

•

Function Builder

tworzenia menu na definiowanych ekranach,

– narzędzie do tworzenia elementów strukturalnych programu

ABAP, -6-


•

Class Builder – narzędzie do do tworzenia klas.

Rys. 2.1. Drzewo aplikacji w ramach środowiska ABAP Workbench

Wszystkie powyższe narzędzia są dostępne w drzewie aplikacji środowiska ABAP oraz z poziomu narzędzia Object Navigator , który jest najlepszym punktem startowym. Na Rys. 2.2 przedstawione jest okno narzędzia Object Navigator . Widoczny w oknie lewy panel przedstawia listę obiektów. Wyszukanie obiektu odbywa się poprzez wybór z listy l isty rozwijanej typu obiektu, następnie wpisanie nazwy w polu tekstowym i kliknięcie przycisku z ikoną okularów.

-7-


Rys. 2.2. Okno Object Navigator

Aby utworzyć nowy obiekt należy na odpowiednim elemencie drzewka obiektów wywołać menu kontekstowe, a następnie wybrać opcję CREATE . W ten sposób na elemencie PROGRAMS można utworzyć nowy program. W pierwszym okienku podaje się nazwę programu, która jak nazwa każdego nowego obiektu tworzonego przez programistę powinna zaczynać się od litery Y lub Z. Aby szybko utworzyć szkielet standardowej aplikacji należy odznaczyć opcję With TOP INCL . Na następnym oknie definiuje się atrybuty programu, w szczególności typ programu. Można przyjąć standardowe dane proponowane na oknie i kliknąć przycisk SAVE . Kolejne okno pozwala na przypisanie programu do pakietu, który typowo powinien zostać ustawiony na TEST . Ikonka dyskietki finalnie kończy ustawienia nowego programu. Po utworzeniu programu uruchamiany jest ABAP Editor (Rys. 2.3). Nawigacja między oknami w środowisku ABAP może być dokonywana za pomocą przycisków znajdujących się na górze ekranu, w szczególności przycisk Back (zielone kółko ze strzałką w lewo) oraz przycisk Exit (czerowne kółko z krzyżykiem). Przyciski edytora ABAP znajdują się pod nazwą aplikacji. Najważniejsze z nich to •

•

•

Display<->Change – pozwala przełączać edytor w tryb edycji oraz przeglądania; przycisk ten również występuje występuje w innych aplikacjach; aplikacjach; Activate<->Inactivate – aktywuje lub dezaktywuje obiekt; każdy obiekt musi być aktywowany po wprowadzeniu zmian; stan obiektu znajduje się obok nazwy raportu w oknie edycyjnym; Check – sprawdza poprawność składni programu;

-8-


•

Activate – aktywuje obiekty obi ekty zalogowanego użytkownika;

•

Direct processing – uruchamia program;

Where-used list – wyświetla informacje o wykorzystaniu w ykorzystaniu obiektu; obiektu; Uruchomienie programu jest możliwe poprzez przycisk Direct Processing , ale niesie ryzyko konieczności zamknięcia całego środowiska ABAP w przypadku braku możliwości normalnego zakończenia programu. Dlatego bezpieczniejsze jest uruchamianie aplikacji poprzez menu kontekstowe wywołane na nazwie programu w drzewku obiektów i uruchomienie programu w nowym oknie ( Execute->In new window). •

W menu kontekstowym w opcji Execute możliwe jest również wywołanie debuggera. W dolnej części okienka debuggera znajdują się podstawowe pola systemowe oraz miejsce na podgląd wartości obiektów. Ustawienia breakpoint’ów można wykonać poprzez funkcję Breakepoint at soubroutine i podanie nazwy procedury lub modułu. Również poprzez prawy przycisk w kodzie programu można dodawać dodawać lub usuwać breakpoint’y. Na uwagę zasługuje również pomoc, która jest zawarta w górnym menu umieszczonym na na niebieskim tle po uruchomieniu ABAP Dictionary w pozycji Environment->Examples>ABAP Examples. W miejscu tym można znaleźć zbiór prostych przykładów ukazujących wszystkie najważniejsze aspekty ABAP.

Rys. 2.3. Okno ABAP Editor

-9-


3. Podstawy języka ABAP ABAP jest językiem interpretowanym, sterowanym zdarzeniami. Każdy program jest uruchamiany na tzw. procesorze ABAP zarządzanym przez środowisko uruchomieniowe ABAP runtime environment ). ( ABAP ). Każdy program składa się z kodu źródłowego, elementów tekstowych oraz atrybutów. Atrybuty są ustawiane głównie podczas tworzenia programu i zawierają m.in. typ programu (program wykonywalny, moduł, podprocedura lub kod załączany do innych programów), tytuł, język, pakiet i inne. Elementy tekstowe są tworzone poprzez narzędzie Text Element Maintenance Tool i obejmują nagłówki list i kolumn, tekst wyboru, symbole tekstowe. Symbole tekstowe wykorzystuje się w wyrażeniu WRITE. Umożliwiają one tworzenie wspólnych elementów tekstowych wykorzystywanych w wielu aplikacjach oraz tworzenie aplikacji wielojęzycznych. Program automatycznie wybiera odpowiednią wersję językową w zależności od ustawień konta użytkownika, który go uruchamia. Kod programu składa się ze deklaracji globalnych oraz bloków przetwarzania danych. Globalne deklaracje znajdują się na początku programu. Dalej blok przetwarzania danych jest podzielony na jednostki zwane blokami przetwarzania ( processing blocks). Przetwarzanie w ramach bloku przetwarzania jest sekwencyjne, natomiast kolejność wykonywania bloków przetwarzania jest sterowana sterowana przez środowisko ABAP ABAP na podstawie zdarzeń. zdarzeń. Linia zaczynająca się od znaku * jest traktowana jako komentarz.

3.1. Typy danych W języku ABAP fragmenty pamięci dostępne i interpretowalne z poziomu programu są określane jako obiekt danych ( data object ). ). Każdy obiekt danych musi zostać zadeklarowany w programie ABAP i jest powoływany jedynie na czas wykonywania programu. Zakończenie Zakończenie programu powoduje usunięcie obiektu z pamięci. Obiekt danych posiada określony typ, t yp, tzn. jest fizyczną jednostką danego typu t ypu powołaną na czas wykonywania w ykonywania programu. Operacje na obiekcie danych są zdeterminowane przez typ obiektu. Typ danych nie zajmuje przestrzeni pamięci, a jedynie jedynie określa atrybuty obiektu. obiektu. ABAP zawiera obszerną listę wbudowanych typów prostych i złożonych, przeznaczonych do specyficznych operacji biznesowych. Typy danych tworzą strukturę hierarchiczną, w której typy złożone składają się z typów prostszych. Wszystkie typy danych, nie licząc typów o lokalnym zakresie, są zdefiniowane w słowniku ABAP Dictionary (transakcja SE11). Wszystkie typy danych mogą zostać podzielone na trzy t rzy podstawowe grupy: typy wbudowane, typy referencyjny oraz typ złożone. Programista może definiować własny typ nazwa_typu dostępny lokalnie w programie używając wyrażenia TYPES. Czas życia definicji typu określonego przez wyrażenie TYPES jest ograniczony przez czas życia programu. Typy danych, które są wspólne dla wielu programów mogą zostać zdefiniowane w tzw. słowniku ABAB ( ABAP Dictionary ) w ramach ABAP Workbench. Dzięki temu wszystkie typy danych używane w złożonym programie lub wielu programach mogą być zdefiniowane centralnie. Wówczas zmiana danego typu danych polega jedynie na edycji jego definicji i nie wymaga modyfikacji innych fragmentów kodu programu. Dodatkowo typy definiowane poprzez ABAP Dictionary mogą przechowywać pewną semantykę, semantykę, np. opis deskryptywny, deskryptywny, tekst pomocy, listę wartości. wartości. Podstawowa składnia wyrażenia TYPES: TYPES nazwa_typu(rozmiar) TYPE typ [DECIMALS dec].

- 10 -


Przykład: typ_miasto(30) TYPE c . Typ może być oczywiście typem wcześniej zdefiniowanym w programie. Wówczas nowy typ nazwa_typu dziedziczy wszystkie cechy typu typ.

Do deklaracji obiektu danych służy wyrażenie DATA. Podstawowa składnia wyrażenia jest nastepująca: DATA nazwa(rozmiar) wartość_początkowa.

TYPE

typ

[DECIMALS

dec]

VALUE

Przykład: DATA miasto(30) TYPE c VALUES `Warszawa`. Wyrażenie powoduje utworzenie obiektu danych o nazwie nazwa, typie typ oraz przypisuje mu wartość początkową wartość_początkowa. Obiekty utworzone poprzez wyrażenie DATA nazywamy zmiennymi. Składnia wyrażenia DATA jest bardzo zbliżona do składnie wyrażenia TYPES, dlatego dalej często będziemy podawać składnie dla obu wyrażeń jednocześnie. Typy i obiekty danych mogą być tworzone nie tylko na podstawie zdefiniowanego typu, ale również na podstawie już utworzonego obiektu danych. Wówczas zamiast określenia typu przez słowo kluczowe TYPE definiuje się obiekt, na podobieństwo którego ma powstać nowy obiekt używając składni LIKE obiekt_danych, np. DATA kwota_netto

TYPE p DECIMALS 2.

DATA kwota_brutto LIKE kwota_netto.

Nazwy typów oraz obiektów obiektów danych muszą składać się z maksymalnie 30 znaków – liter, cyfr cyfr lub podkreślenia ‘_’, przy czym muszą zaczynać się od litery i nie mogą pokrywać się ze słowami kluczowymi lub predefiniowanymi obiektami. Przestrzeń nazw typów i obiektów danych są rozdzielne. Do definicji obiektu można więc użyć tej samej nazwy co jego typ.

Typy wbudowane Wbudowane typy danych o stałej długości zostały przedstawione w Tab. 1. Minimalny i maksymalny rozmiar określa ile obiekt danych danego typu będzie zajmować pamięci. Jeżeli rozmiar obiektu nie zostanie określony przy jego definicji to zostanie użyty domyślny rozmiar. Dla typów danych, w których dopuszczalny jest tylko jeden rozmiar, nie powinien on explicite występować w deklaracji obiektu. Wartość początkowa określa wartość przypisaną do obiektu, o ile inna wartość nie została przypisana w momencie jego deklaracji. Mamy do dyspozycji typy numeryczne i, p, f, typy tekstowe c, n, d, t oraz typ bajtowy x. Tab. 1. Wbudowane typy danych o stałej długości

Typ Rozmiar minimalny/maksymalny

Opis

(w bajtach)

Rozmiar Wartość standardowy początkowa (w bajtach)

i

4

4

0

Liczba całkowita

p

1-16

8

0

Liczba spakowana

f

8

8

0

Liczba zmiennoprzecinkowa zmiennoprzecinkowa

c

1-65535

1

′′

Tekst alfanumeryczny

n

1-65535

1

′0…0′

Tekst Tekst numeryczny (złożony

- 11 -


z cyfr) d

8

8

′00000000′

Data

t

6

6

′000000′

Czas

x

1-65535

1

′00 … 00′

Liczba hexadecymalnie

zapisana

Typ c reprezentuje ciąg znaków o stałej długości, jednak puste znaki są pomijane przy konkatenacji ciągów. Obiekty jednoznakowe typu c są wykorzystywane również jako zastępnik typu logicznego, przy czym znak „X” oznacza prawdę, a znak spacji lub predefiniowany obiekt obiekt space reprezentuje fałsz. Typ n można traktować jako typ tekstowy, który może zawierać jedynie liczby. Nie jest on raczej używany do obliczeń, gdyż to wymagałoby konwersji typu do liczby, a raczej do reprezentacji liczb typu kody bankowe, kod pocztowy, itp. Typ ten jest również wygodny przy wprowadzaniu wprowadzaniu danych przez użytkownika do automatycznej automatycznej walidacji. Typ d ma format YYYMMDD, gdzie YYYY oznacza rok, MM miesiąc, a DD dzień. Typ t ma format HHMMSS, gdzie HH jest godziną, MM oznacza minuty, a SS sekundy. W wyrażeniach matematycznych obiekty obu typów są traktowane jako odpowiednio data lub czas, w pozostałych przypadkach jako napisy. Typ x umożliwia operacje bitowe. Oprócz powyższych typów istnieją również dwa typy wbudowane o zmiennej długości. Typ string jest odpowiednikiem typu c, jednak rozmiar alokowanej pamięć zależy od długości przypisanego do obiektu tekstu. Typ xstring jest odpowiednikiem o zmiennej długości typu x.

Typy referencyjne referencyjne Typ referencyjny określa typ obiektu danych który zawiera jedynie referencje do innego obiektu danych. Taki obiekt jest nazywany obiektem referencyjnym. TYPES|DATA

… TYPE REF TO obiekt|klasa obiekt|klasa|interfejs. |interfejs.

Referencja może zostać utworzona do konkretnego obiektu lub klasy obiektów.

Typy złożone Złożone typy danych gromadzą w jednej logicznej jednostce pewną liczbę obiektów danych. Wyróżnione są dwa rodzaje typów złożonych: typy strukturalne ( structured types) oraz typy tabelaryczne ( table-like types). Typy strukturalne grupują zadaną liczbę komponentów zadanych typów tworząc strukturę. TYPES|DATA: BEGIN OF nazwa_strukt nazwa_struktury, ury, komponent1 {TYPE typ|LIKE obiekt} …, … komponentN {TYPE typ|LIKE obiekt} …, END OF nazwa_strukt nazwa_struktury. ury.

Komponent jest typem elementarnym, referencyjnym, strukturalnym lub tabelarycznym. Szczególną, przydatną konstrukcją jest następujący przykład, w którym tworzona jest

- 12 -


struktura odpowiadająca tabeli bazy danych dbtab, tak aby komponenty struktury odpowiadały kolumną tabeli. TYPES|DATA structure TYPE dbtab.

Adresowanie komponentu struktury odbywa się poprzez odwołanie struktura-komponent . Oprócz standardowego zagnieżdżanie struktur, w którym komponent może być strukturą, istnieje możliwość włączania do struktury komponentów innej struktury, tak aby były one widoczne na tym samym poziomie. Wykorzystuje się w tym celu słówko kluczowe INCLUDE, a ewentualne niejednoznaczności niejednoznaczności są rozstrzygane przez dodanie przyrostków. TYPES|DATA BEGIN OF struct1. … INCLUDE TYPE|STRUCTURE struct2 AS nazwa {RENAMING WITH SUFFIX przyrostek]. … TYPES|DATA END OF struct1.

Struktury zawierające elementarny typy danych o stałej długości (tzw. typy danych flat ) są reprezentowane bezpośrednio jako obiekty w pamięci, natomiast dla typów danych reprezentowanych poprzez wskaźnik (w tym elementarnych typów o zmiennej długości) jest przetwarzany wskaźnik wskaźnik do struktury. Typy tabelaryczne są związane z obiektami nazywanymi tabelami wewnętrznymi ( internal tables). Tabela wewnętrzna jest określona przez rodzaj tabeli, typ wiersza oraz klucz tabeli. Podstawowa składnia jest następująca: TYPES|DATA … {TYPE|LIKE} rodzaj_tabeli OF {typ_wersza|wi {typ_wersza|wiersz} ersz} WITH {UNIQUE KEY} klucz.

Rodzaj tabeli określa sposób przechowywania i dostępu do danych i może przyjąć wartość STANDARD TABEL , SORTED TABLE lub HASHED TABLE dla odpowiednio standardowych, sortowanych lub haszujących tabel. W definicji obiektu może zostać podany typ wykorzystywany do reprezentacji pojedynczego wiersza tabeli lub obiekt, którego typ ma zostać zaaplikowany, np. tabela bazy danych. Klucz może składać się z wielu kolumn, które należy podać rozdzielając spacjami. Typowy przykład kod tworzącego tabelę wewnętrzną i zasilającego ją danymi z tabel bazodanowej bazodanowej może być następujący: DATA tabela TYPE SORTED TABLE OF spfli WITH UNIQUE KEY corrid connid. SELECT * FROM spfli INTO TABLE tabela WHERE carrid = ‘LH’.

Ponadto istnieją typy generyczne wymienione w Tab. 2.

- 13 -


Tab. 2. Typy generyczne

typ generyczny

opis

ANY

dowolny typ

ANY TABLE

dowolna tabela

INDEX TABLE

tabele indeksowe

TABLE|STANDARD TABLE

tabele standardowe

SORTED TABLE

tabele posortowane

HASHED TABEL

tabele laszujące

c, n, s, p

typy wbudowane o dowolnej długości

Proste typy danych o stałej długości mogą być wykorzystane do definicji stałych z wykorzystaniem składni CONSTANTS const[(dlugosc)} const[(dlugosc)} {TYPE typ|LIKE obj} [DECIMALS dec] VALUE wartosc.

Wyrażenie PARAMETERS również tworzy zmienne, choć ma inną semantykę. Jest ono związane z definiowanie ekranów i zostanie omówione w dalszej części lekcji. Do tej pory zajmowaliśmy się tworzeniem obiektów nazwanych. W programie mogą istnieć również obiekty anonimowe – literały, obiekty o zadanym typie, wymagające określonej porcji pamięci, ale nie posiadające nazwy. Literały tekstowe to ciąg alfanumerycznych alfanumerycznych znaków ujętych w apostrofy, o długości do 255 znaków, odpowiadający typowi c. Literał może być zapisany w wielu liniach łącząc poszczególne części ujęte apostrofach znakiem „&”, np. WRITE / ‘To jest’ & ‘jeden literał’.

Dwa występujące bezpośrednio po sobie znaki apostrofu nie są traktowane jako znak ograniczający literał, a jako pojedynczy znak apostrofu w nim zawarty. Literały numeryczne powinny być umieszczane bez znaków apostrofu, jeżeli są to liczby bez kropki dziesiętnej. W przypadku liczb dziesiętnych konieczne jest zapisanie literału jako literał tekstowy, co oznacza konieczność konwersji z typu c na właściwy typ numeryczny, a co za tym idzie i dzie możliwość nie dokładnej reprezentacji, np. możliwość zaokrągleń. Predefiniowane obiekt tworzone i aktualizowane przez system, dostępne jako komponenty Dict ionary, nazywa się polami systemowymi obiektu SYST o typie zdefiniowanym w ABAB Dictionary system fields ). Ponieważ w ABAB Dictionary zawarta jest również semantyka komponentów, ( system to najłatwiejszym sposobem ich poznania jest przeglądanie słownika. W każdym programie jest tworzona automatycznie struktura sy typu SYST. Odczyt pól systemowych odbywa się poprzez selektor komponentu w strukturze, np. sy-uname zwraca nazwę użytkownika, uż ytkownika, sydatum, sy-uzelt zwraca bieżącą datę i czas. Ważnym polem systemowym jest pole sysubrc używane do przekazywania kodu zwracanego przez wiele wyrażeń ABAP, gdzie zero oznacza wykonanie zakończone sukcesem.

- 14 -


3.2. Elementarne operacje na obiektach Przypisanie wartości do obiektów odbywa się za pomocą dwóch równoważnych składni MOVE obiekt2 TO obiekt1.

lub Obiekt1 = obiekt2.

Obiekt obiekt2 może oczywiście być obiektem nie nazwanym, czyli literałem. Jeżeli obiekty są różnych typów, ale możliwe jest dokonanie konwersji, to jest ona wykonywana. Brak możliwości konwersji jest zgłaszane jako błąd składni lub podczas wykonywania programu jako błąd wykonania ( runtime error ). ). Błędy konwersji podczas wykonywania programu powodują powodują wyjątek, który może zostać przechwycony przechwycony i obsłużony przez program. Operacja przypisania wywołana na strukturach powoduje przepisanie zawartości ich poszczególnych poszczególnych komponentów. Jeżeli struktury są s ą różnych typów to możliwe jest przepisanie zawartości tylko komponentów odpowiadających sobie nazwami poprzez składnie MOVE-CORRESPONDING MOVE-CORRESPO NDING struktura2 TO struktura1.

Próba przypisana do obiektu typu d daty o niewłaściwym formacie powoduje przypisanie wartości 0. Jeżeli znacznik czasu musi być unikalny można to zagwarantować przypisując wartość za pomocą składni GET TIME STAMP FIELD f.

Odwołania do elementów obiektów możliwe jest poprzez adresowanie f[+off][(dlugosc)]

Jeżeli typ f jest j est ciągiem znaków to zwracany jest podciąg o długości dlugosc począwszy od indeksu off. Poniższy przykład pokazuje jak wyodrębnić z daty poszczególne elementy: rok

= sy-datum(4).

miesiac dzien

= sy-datum+4(2). sy-datum+4(2).

= sy-datum+6(2). sy-datum+6(2).

W każdym momencie można przywrócić wartość początkową zmiennej poprzez wyrażenie w yrażenie CLEAR obiekt.

W przypadku tabeli wewnętrznej oznacza to usunięcie wszystkich wierszy, w przypadku typu referencyjnego ustawienie wartości NULL. Wyznaczanie wyrażeń matematycznych matematycznych odbywa się za pomocą składni [COMPUTE] obiekt2 = wyrażenie matematyczne .

Operatory arytmetyczne +, - *, / mają odpowiadające im słowa kluczowe ADD … TO , SUBSTRACT … FROM , MULTIPLY … BY … , DIVIDE … BY . Pozostałe operatory dwuargumentowe to DIV, MOD i ** oznaczające dzielenie całkowitoliczbowe, resztę z podziału oraz potęgowanie. potęgowanie. W przypadku niejednoznaczności niejednoznaczności w pierwszeństwie wykonywania działań, operacje są wykonywane od lewej do prawej z wyjątkiem potęgowania, które jest wykonywane od prawej do lewej strony. Operatory matematyczne, jak również nawiasy są traktowane jako odrębne słowa, a więc przed nimi i po nich musi występować spacja. ABAP dostarcza następujących wbudowanych wbudowanych funkcji matematycznych: matematycznych: - 15 -


funkcja

opis

abs

wartość bezwzględna

sign

znak argumentu

ceil

najmniejsza wartość nie mniejsza niż argument

floor

największa wartość nie większa niż argument

trunc

część całkowita argumentu

frac

część ułamkowa argumentu

acos, asin, atan, cos, sin, tan

funkcje trygonometryczne

cosh, sinh, tanh,

funkcje hiperboliczne

exp

funkcja wykładnicza o podstawie e

log

logarytm naturalny

log10

logarytm dziesiętny

sqrt

pierwiastek

Wyrażenia logiczne nie mogą być używane po prawej stronie przypisań, a jedynie w warunkach logicznych. W wyrażeniach logicznych mogą występować operatory operator

opis

=, EQ

równy

<>, NE

nie równy

<, LT

mniejszy

<=, LE

mniejszy równy

>, GT

większy

>=, GE

większy równy

AND

logiczny operator i

OR

logiczny operator lub

NOT

logiczny operator zaprzeczenia

IS operator

sprawdzenie obiektu pod kątem operatora

BETWEEN … AND …

obiekt zawarty w przedziale

IN

obiekt zawarty w zbiorze

Operator NOT ma pierwszeństwo wykonywania przez operatorem AND, a AND przed operatorem OR. W przypadku porównywania struktur, porównywane są wszystkie ich komponenty. Struktury są sobie równe, jeżeli wszystkie komponenty są identyczne. W przypadku porównywania tabel wewnętrznych najpierw porównywana jest liczba wierszy – im więcej wierszy tym tablica jest większa. Jeżeli liczba wierszy jest równa porównywane są kolejne wiersze,

- 16 -


komponent po komponencie. Porównywanie jest zatrzymywane w przypadku napotkania pierwszego różniącego różniącego się wiersza, który determinuje determinuje wartość relacji porównania. porównania. Wyrażenie IS może mieć następujące składnie •

IS INITIAL – sprawdzenie, czy obiekt ma wartość początkową,

•

IS ASSIGNED – sprawdzenie, czy tzw. symbol pola ( field symbol ) został przypisany

do obiektu, •

IS {SUPPLIED|REQUESTED} – sprawdzenie, czy obiekt został wypełniony lub

sprawdzony podczas wywołania procedury.

Występująca po operatorze IN tabela jest tzw. tabelą wyboru, która powinna być zdefiniowana poprzez konstrukcje DATA tabela_wyboru LIKE RANGE OF f.

lub SELECT-OPTIONS SELECT-OPTION S table_wyboru FOR f.

Druga składnia jest związana z definicją ekranów wyboru, które zostaną omówione w dalszych punktach. Do porównywania łańcuchów tekstu przeznaczone są odrębne operatory: •

•

•

•

•

•

•

•

s1 CO s2 – zwraca prawdę, jeżeli s1 zawiera tylko znaki występujące w s2; w przypadku fałszu, pole systemowe su-fdpos zawiera indeks pierwszego znaku nie zawartego w s2; s1 CN s2 – zwraca prawdę, jeżeli s1 zawiera nie tylko znaki występujące w s2, w przeciwnym przypadku, pole systemowe su-fdpos zawiera indeks pierwszego znaku nie zawartego w s2; s1 CA s2 – zwraca prawdę, jeżeli s1 zawiera co najmniej jeden występujący w s2; w przeciwnym przypadku, pole systemowe su-fdpos zawiera indeks pierwszego znaku, który jest zawarty również w s2; s1 NA s2 – zwraca prawdę, jeżeli s1 nie zawiera żadnego znaku występującego w s2; w przeciwnym przypadku, pole systemowe su-fdpos zawiera indeks pierwszego znaku, znaku, który również występuje występuje w s2; s1 CS s2 – zwraca prawdę, jeżeli s1 zawiera ciąg s2, a su-fdpos zawiera indeks pierwszego wystąpienia wystąpienia s2 w s1; s1 NS s2 – zwraca prawdę, jeżeli s1 nie zawiera ciąg s2, w przeciwnym przypadku su-fdpos zawiera indeks pierwszego wystąpienia s2 w s1; s1 CP s2 – zwraca prawdę, jeżeli s1 pasuje do wzorca zawartego w s2; wzorzec może zawierać specjalne znaki „*” oraz „+”; w przypadku prawdy su-fdpos zawiera indeks wystąpienia s2 w s1; s1 NP s2 – zwraca prawdę, jeżeli s1 nie pasuje do wzorca zawartego w s2, w przeciwnym przypadku przypadku su-fdpos zawiera indeks wystąpienia s2 w s1;

Operatory CO, CN, CA i NA rozróżniają małe i wielkie litery.

- 17 -


3.3. Kontrola przepływu sterowania Instrukcje warunkowe W języku ABAP występują dwie konstrukcje instrukcji warunkowych. W instrukcji IF/ENDIF występują wyrażenia logiczne warunkujące przekazanie sterowania programem do właściwego bloku instrukcji. Składnia instrukcji inst rukcji IF wyrażenie_lo wyrażenie_logiczne1. giczne1. Blok_instrukcji1 [ELSEIF wyrażenie_logi wyrażenie_logiczne2. czne2. Blok instrukcij2] … [ELSEIF wyrażenie_logi wyrażenie_logiczneN. czneN. Blok instrukcijN] [ELSE.] Blok_instrukcjiN+1 ENDIF.

W instrukcji CASE/ENDCASE wyróżniony obiekt jest porównywany z innymi obiektami. Składnia instrukcji CASE/ENDCASE CASE obiekt. WHEN obiekt1 [OR …]. Blok_instrukcji_1 [WHEN obiekt2 [OR …]. Blok_instrukcji_2] … [WHEN OTHERS. Blok_instrukcjiN ENDCASE.

Przykład CASE sy-datum+4(2). sy-datum+4(2). WHEN ‘12’ OR ‘01’ OR ‘02’. WRITE / ‘Zima’. WHEN ‘06’ OR ‘07’ OR ‘08’. WRITE / ‘Lato’. WHEN OTHERS. WRITE ‘Zla data’. ENDCASE.

Pętle - 18 -


Pętle bezwarunkowe bezwarunkowe DO ma następującą składnie DO [n TIMES]. Blok instrukcji ENDDO.

n określa liczbę iteracji. Jeżeli n jest mniejsze niż 1 lub nie zostało sprecyzowane, pętla może być zakończona jedynie w wyniku wykonania wyrażenie EXIT. Bieżący numer iteracji może zostać odczytany z obiektu sy-index. W przypadku pętli zagnieżdżonej dostęp do numeru iteracji pętli zewnętrznej jest możliwy jedynie z wykorzystaniem dodatkowych zmiennych, gdyż sy-index przechowuje informacje dla bieżącej (zagnieżdżonej) pętli. Pętle warunkowe WHILE powoduje powtórzenie wykonywania bloku wyrażeń tak długo jak podany warunek warunek logiczny jest prawdziwy. prawdziwy. WHILE wyrażenie_logi wyrażenie_logiczne. czne. Blok_wyrażeń ENDWHILE.

Sterowanie pętlą może odbywać się również za pomocą wyrażeń CONTINUE, EXIT oraz CHECK. Wyrażenie CONTINUE powoduje pominięcie dalszych wyrażeń w bieżącej iteracji CHECK pętli i natychmiastowe natychmiastowe rozpoczęcie nowej iteracji. Wyrażenie wyrażenie_logiczne funkcjonuje tak samo jak CONTINUE, ale tylko gdy wyrażenie_logiczne ma wartość false. Wyrażenie EXIT powoduje natychmiastowe opuszczenie pętli.

3.4. Modularność ABAP daje możliwość programowania zgodnie z paradygmatem programowania proceduralnego i/lub paradygmatem programowania obiektowego. Według pierwszego z paradygmatów kod dzielony jest na funkcjonalne moduły zawierające lokalne dane. Każdy program posiada co najmniej blok zdarzeniowy START-OF-SELECTION uruchamiany automatycznie podczas startu programu. Najprostszym sposobem modularyzacji modularyzacji jest wykorzystanie wykorzystanie wyrażenia INCLUDE incl.

gdzie incl jest nazwą programu. Wynik jest taki, jakby kod źródłowy programu incl został umieszczony w miejscu wyrażenia. Również podczas sprawdzana składni program jest traktowany, jakby kod programu incl został włączony zamiast w wyrażenia yrażenia INCLUDE. Inny sposobem modularyzacji są makra. Makro grupuje sekwencje wyrażeń, które mogą być następnie wielokrotnie używane. Składnia makra: DEFINE makro. … END-OF-DEFINITION.

Makra są dostępne jedynie w programie, w którym są zdefiniowane. Użycie makra ma postać makro [p1 … p9]

gdzie wartości p1 do p9 są podstawiane pod wyrażenia w yrażenia &1 … &9 w definicji makra.

- 19 -


Program APAB może być podzielony na podprocedury ( subroutines) widoczne w ramach programu lub z poziomu innych programów. programów. Definicja podprocedury podprocedury wygląda następująco: następująco: FORM nazwa [USING

…

{VALUE(ui)|ui}[TYPE typ|LIKE obiekt] …] [CHANGING

…

{VALUE(ci)|ci}[TYPE typ|LIKE obiekt] …] … ENDFORM.

Lista parametrów ui i ci może być zdefiniowana bez wyspecyfikowanych typów lub wraz z określonymi typami przez wyrażenia TYPE lub LIKE. Określenie typów wyrażeń zapewnia, iż do podprocedury zostaną przekazane tylko obiekty o typach jakie są oczekiwane w podprocedurze. podprocedurze. Typy mogą być wyspecyfikowane jednoznacznie lub nie jednoznacznie, jednoznacznie, np. typ o zmiennej długości bez podania konkretnej długości lub typy generyczne np. INDEX TABLE. TABLE. Występują cztery sposoby przekazywania przekazywania parametrów: 1. USING ui Deklaracja powoduje przekazanie parametru przez referencje. Przekazywany parametr nie powinien być modyfikowany wewnątrz podprocedury, a użyty jedynie do odczytu. 2. USING VALUE(u i) Deklaracja powoduje utworzenie lokalnej zmiennej będącej kopią przekazywanego parametru. Zmiana obiektu wewnątrz podprocedury nie powoduje zmiany zadeklarowanego zadeklarowanego poza podprocedurą i przekazanego przekazanego do niej obiektu. 3. CHANGING c i Deklaracja jest zbieżna z USING ui, jednak przekazywane obiekty mogą być modyfikowane. Jeżeli obiekt zostanie zmieniony to zmiany te będą widoczne również poza podprocedurą, podprocedurą, gdyż obiekty obiekty są przekazane przekazane przez referencje. referencje. 4. CHANGING VALUE(c i) Deklaracja powoduje przekazanie parametrów poprzez utworzenie lokalnej kopii przekazywanych przekazywanych obiektów, tak jak w przypadku USING VALUE(u i). Przy poprawnym zakończeniu procedury (poprzez ENDFORM, CHECK lub EXIT) obiekty lokalne są kopiowane do obiektów przekazywanych do podprocedury. W przypadku niepoprawnego zakończenia podprocedury obiekty na zewnątrz podprocedury pozostają niezmienione. niezmienione. Wywołanie podprocedury odbywa się poprzez wyrażenie PERFORM. Podstawowa składnia ma następującą postać: PERFORM podprocedura [CHANGING

[USING …a j…]

[IN PROGRAM program]. - 20 -

…a i…]


Parametry w wywołaniu podprocedury są przypisywane do obiektów w deklaracji zgodnie z kolejnością ich występowania, w odróżnieniu od modułów funkcjnych i metod, gdzie istotną rolę odgrywa nie kolejność, a nazwy obiektów. Poniższy przykładowy kod źródłowy zwiera przykładowe wywołanie wywołanie i definicję podprocedury podprocedury PERFORM select_data USING p_carrid p_connid CHANGING sflight_tab. FORM select_data USING u_carrid LIKE p_carid u_connid LIKE p_connid CHANGING c_sflight_tab TYPE t_sflight_tab. t_sflight_tab. SELECT * FROM sflight INTO TABLE c_sflight_tab WHERE carrid = u_carrid AND connid = u_connid. ENDFORM.

W ramach podprocedury można używać wyrażeń CHECK i EXIT na podobnej zasadzie jak w pętlach (patrz 3.3). Podprocedury Podprocedury nie nie mogą być zagnieżdżane. zagnieżdżane. Moduły funkcyjne ( functions modules) są zaprojektowane do wywołań zewnętrznych (poza programem zawierającym definicję modułu funkcyjnego) i odgrywają główną rolę w przypadku fragmentów kodu wykorzystywanego przez wiele programów również na wielu instancjach SAP (zdalne wywoływanie modułu funkcyjnego RFC). Choć moduły funkcyjne są definiowane w ramach grupy funkcji, to każdy moduł funkcyjny posiada unikalną nazwę w ramach całego systemu SAP. Grupy funkcji są kontenerami modułów funkcyjnych, ale mogą również posiadać własne globalne obiekty, typy, ekrany przeznaczone do wykorzystania w wielu programach. Grupa jest w rzeczywistości programem ABAP, a moduł funkcyjny blokiem przetwarzania w programie. Grupy funkcji tworzy się w narzędziu Function Bulider (transakcja SE37) w ramach ABAP Workbench. Aby utworzyć grupy funkcyjne najłatwiej ustawić w ABAP Workbench filtr Function group i na drzewie obiektów wywołać menu kontektowe, gdzie w Create jest opcja Function module. Nazwy modułów funkcyjnych tworzonych przez użytkownika muszą zaczynać się od znaków „Y_” lub „Z_” (z podkreśleniem w odróżnieniu od nazw programu). Na kolejnych zakładkach definiuje się m.in. parametry, wyjątki funkcji oraz kod źródłowy. Aby przetestować moduł funkcyjny można z poziomu Function Builder wywołać wywołać opcję Test / Execute. Wywołanie modułu funkcyjnego odbywa się za pomocą CALL FUNCTION o następującej składni: CALL FUNCTION obiekt_zawier obiekt_zawierajacy_nazwe_f ajacy_nazwe_funkcji unkcji [EXPORTING f 1=a1 .. fn=an] [IMPORTING f 1=a1 .. fn=an] [CHANGING f 1=a1 .. fn=an]

- 21 -


[EXCEPTIONS e 1=r1 .. en=rn [ERROR_MESSAGE [ERROR_MESSAG E

= r E]

[OTHERS =r o]].

gdzie f reprezentują formalne parametry występujące w module, a a to obiekty przekazywane przekazywane do modułu, e reprezentują wyjątki, a r to liczby. Nazwa funkcji jest dostarczana jako obiekt, a więc w postaci zmiennej lub literału. Z wyjątkami skojarzone są liczby, zwracana poprzez obiekt systemowy s ystemowy sy-subrc, jeżeli wyjątek wystąpi. Zauważmy, że obiekty lokalne są tworzone w podprocedurach lub modułach funkcyjnych. Obiekty tworzone przed głównym blokiem przetwarzania mają zasięg globalny. Dlatego tylko t ylko niezbędne dane powinny być tworzone w głównym bloku programu, a większa część funkcjonalności powinna być schowana w podprocedurach podprocedurach lub modułach funkcyjnych. Aspekty programowania obiektowego i związane z nim metody modularyzacji zostaną omówione w sekcji 5.

4. Podstawowe konstrukcje języka ABAB 4.1. Przetwarzanie napisów Konkatenacja napisów może zostać dokonana przez wyrażenie CONCATENATE. CONCATENATE n1 … nn INTO n [SEPARATED by sep].

Napisy n1 do nn są złączane, a wynik jest umieszczany w obiekcie n. Jeżeli docelowy napis n jest krótszy niż wynik złączenia napisów n1 do nn, to wynik złączenia jest obcinany do długości obiektu n. Opcjonalnie można zdefiniować separator sep, który będzie występował w złączonym napisie n pomiędzy napisami n1 do nn. s1 = ‘ABAB’ s2 = ‘Objects’ CONCATENATE s1 s2 INTO s3 SEPERATED BY SPACE.

Odwrotna operacja do konkatenacji – dzielenie napisu, jest wykonywana poprzez wyrażenie SPLIT SPLIT n_zrodlowy AT sep INTO n1 … nn.

Napis źródłowy jest dzielony w miejscach przed i po wystąpieniu separatora sep. Wynikowe napisy, po pominięciu separatora, są umieszczane w obiektach n1 do nn. Jeżeli liczba obiektów docelowych jest zbyt mała, to w ostatnim obiekcie jest umieszczana pozostała do podziału część napisu i w szczególności może ona zawierać separator. Innym rozwiązaniem jest dokonanie podziału napisu do obiektu typu tabela wewnętrzna ( internal table) poprzez składnie SPLIT n_zrodlowy AT sep INTO TABLE tabela.

Dla każdego wynikowego napisu powstałego w wyniku dzielenia do tabeli tabela dodawany jest nowy wiersz. DATA: text TYPE string, itab TYPE TABLE OF string. - 22 -


text = ‘Napis złożony ’

&

‘z wielu linii’. SPLIT text AT space INTO TABLE itab. LOOP AT itab INTO text. WRITE / text. ENDLOOP.

Następujące wyrażenie wyrażenie SEARCH pozwala wyszukać podciąg znaków s2 w ciągu znaków s1: SEARCH s1 FOR s2.

W polu systemowym sy-subrc zwracana jest wartość 0 jeżeli podciąg został znaleziony, a pole sy-fdpos zawiera pozycję wystąpienia ciągu s2 w ciągu s1. W ciągu s1 można wykorzystywać znaki wieloznaczne „*” oraz „.”. Podmiana podciągu znaków może być wykonana poprzez wyrażenie w yrażenie REPLACE s1 WITH s2 INTO s3.

W ciągu znaków s3 szukany jest ciąg s1. Pierwsze wystąpienie tego podciągu jest zastępowane poprzez ciąg znaków s2. Inne istotne słowa kluczowe związane z przetwarzaniem napisów: •

strlen – zwraca długość napisu,

•

SHIFT – przesuwa znaki w napisie,

•

CONDENSE – usuwa odstępy,

•

CONVERT TEXT – tworzy format, który może podlegać sortowaniu,

•

OVERLAY – nakłada napisy na siebie.

4.2. Dynamiczny dostęp do obiektów Symbole pól ( field symbols) to symboliczne nazwy dla istniejących obiektów. Ich zadaniem jest stworzenie możliwości oprogramowania oprogramowania działań na obiektach bez ich znajomości (i znajomości ich typów). Obiekty są wiązane z symbolami pól dopiero w trakcie działania programu. Deklaracja symbolu pola odbywa się za pomocą konstrukcji FIELD-SYMBOLS {TYPE typ|LIKE obiekt}.

Statyczne przypisanie obiektu do symbolu odbywa się poprzez wyrażenie ASSIGN f[+off]{(dlugosc)] f[+off]{(dlugosc)] TO .

Statyczne przypisanie polega na przypisaniu konkretnego nazwanego obiektu. Dzięki parametrom off i dlugosc przypisanie może dotyczyć tylko części obiektu. Dynamiczne przypisanie ma miejsce, gdy nazwa obiektu jest znana dopiero podczas wykonywania programu. Jeżeli nazwa obiektu jest przechowywana w zmiennej f to takie przypisanie może odbyć odbyć się poprzez wyrażenie: wyrażenie: ASSIGN (f) TO .

- 23 -


Jeżeli przypisanie nie jest możliwe, polu systemowemu sy-subrc jest przypisywana wartość 4. Usunięcie przypisania odbywa się za pomocą konstrukcji UNASSIGN .

Wyrażenie IS ASSIGNED

ma wartość true, jeżeli symbol jest przypisany. Podczas przypisywania obiektów można dokonać rzutowania dodając słówko kluczowe CASTING. Innym sposobem dynamicznego dostępu do obiektów jest dostęp poprzez referencje, czyli adresy obiektów w pamięci. Dodatkowo poprzez typ referencyjny można dynamicznie tworzyć nowe obiekty, co nie jest możliwe w przypadku symboli pól. Deklaracja obiektu referencyjnego odbywa się w następujący sposób: DATA dref TYPE REF TO obiekt.

Tak zadeklarowana referencja nie wskazuje jeszcze na żaden obiekt. Przypisane referencji do obiektu może odbywać się na trzy sposoby. Referencja do nazwanego obiektu może być przypisana za pomocą pomocą składni GET REFERENCE OF dobj INTO dref.

Referencja może być przepisana z innego obiektu referencyjnego poprzez MOVE lub operator przypisania „=”. Wreszcie, referencja może być przypisana wraz z powołaniem nowego obiektu. Dostęp do obiektu poprzez referencje jest możliwy dzięki operatorowi dereferencji „->*”, np. ASSIGN dref->* TO [CASTING [typ|nazwa]].

Aby dynamicznie utworzyć obiekt wykorzystuje się składnie CREATE DATA dref {TYPE {typ|(nazwa)}|LIKE {typ|(nazwa)}|LIKE obiekt}.

Obiekt utworzony dynamicznie funkcjonuje pamięci programu dopóki jest wskazywany chociaż przez jeden obiekt referencyjny.

4.3. Przetwarzanie tabel wewnętrznych Tabele wewnętrzne ( internal tables) to złożone obiekty przypominające tabele bazodanowe. Są to jednak obiekty powoływane do życia tylko na czas wykonywania programu. Tabela wewnętrzna składa się z wierszy, liczba wierszy może zmieniać się dynamicznie w trakcie wykonywania programu i jest ograniczona przez zasoby komputera. Wiersz jest definiowany przez zbiór typów obiektów, mogą to być zarówno obiekty proste jak i złożone, np. inna tabela wewnętrzna. Choć można dynamicznie tworzyć obiekty i zarządzać nimi poprzez referencje, to jednak ten sposób jest o wiele bardziej złożony i podatny na błędy, niż wykorzystanie tabel wewnętrznych. Dlatego w ogromnej większości przypadków, gdy zachodzi potrzeba przetwarzania danych poprzez dynamicznie alokowane zasoby, tabele wewnętrzne są najlepszym rozwiązaniem. Typ lub obiekt tabeli wewnętrzną definiuje się za pomocą wyrażenia

- 24 -


TYPES|DATA tab {TYPE|LIKE} typ OF {typ_wiersza|w {typ_wiersza|wiersz} iersz} WITH klucz [INITIAL SIZE n].

Typ tabeli może zostać określony poprzez jedno z wyrażeń: •

STANDARD TABLE – tabela z indeksami. Dostęp do wierszy można uzyskać

specyfikując klucz lub poprzez indeks. Nowe wierszą są albo dołączane na końcu, albo wstawiane pomiędzy inne wiersze. Podczas wstawiania lub usuwania linii indeks jest ponownie wyznaczany. wyznaczany. •

SORTED TABLE – jest to tabela o cechach takich jak standardowa tabela, przy czym

wiersze są zawsze ułożone w porządku rosnącym. •

HASHED TABLE – tabela bez indeksu, wiersze tabeli haszującej nie są układane,

natomiast miejsce wiersza w pamięci jest wyznaczane wyznaczane przez funkcje funkcje haszującą. Nie jest możliwy dostęp poprzez poprzez indeks. Do określenia typów tabel używane są jeszcze słowa kluczowe ANY TABLE oraz INDEX TABEL, przy czym nie mogą być one użyte do tworzenia obiektów lub typów, a np. do przekazywania przekazywania argumentów w procedurach. ANY TABLE jest typem generycznym obejmującym wszystkie tabele wewnętrzne, a INDEX TABEL obejmuje typy STANDARD TABLE oraz SORTED TABLE . Wiersz lub typ wiersza tabeli wewnętrznej może być określony przez dowolny obiekt ABAP’a, typowo wykorzystuje się tu struktury. Klucz jest istotny z punktu widzenia dostępu do wierszy i sortowania. Jeżeli wiersz jest strukturą, to każdy element struktury nie będący lub nie zawierający tabeli może być umieszczony w kluczu: [UNIQUE|NON-UNIQUE] [UNIQUE|NON-U NIQUE] KEY obiekt1 obiekt2 …

Kolejność obiektów w kluczu określa ich ważność. Jeżeli wiersz nie jest strukturą można użyć pseudo komponentu komponentu table_line [UNIQUE|NON-UNIQUE] [UNIQUE|NON-U NIQUE] KEY table_line.

Wówczas cały wiersz jest traktowany jako klucz. Zawsze istnieje możliwość ustawienia standardowego klucza poprzez: [UNIQUE|NON-UNIQUE] [UNIQUE|NON-U NIQUE] DEFAULT KEY.

Wówczas klucz tworzony jest z komponentów tabeli nie będących lub nie zawierających tabeli i typów numerycznych: i, f, p. Słowa kluczowe UNIQUE oraz NON-UNIQUE określają unikalność klucza, przy czym tylko tabela standardowa może mieć tylko nieunikalny klucz, a tabela haszująca może mieć tylko unikalny klucz. Po INITIAL SIZE podaje się liczbę wierszy. Informacja ta jest wykorzystywana do początkowej alokacji pamięci. Określanie wielkości początkowej początkowej ma sens, jeżeli znana jest apriori liczba wiersze i w ten sposób można lepiej zarządzać zasobami systemowymi, szczególnie, gdy taka tabela jest zanurzona w inne tabeli.

- 25 -


Ze względów historycznych możliwe jest używanie skrótów podczas tworzenia tabeli, co spowoduje domyślne potraktowanie jako tabeli standardowej z nie unikalnym standardowym kluczem. Wówczas taka definicja sprowadza się do DATA tab TYPE TABLE OF typ_wiersza.

Przy tworzeniu tabeli można na końcu dodać dopisek WITH HEADER LINE . Nie zaleca się używania tego typu tabel, gdyż są one przestarzałe i utrzymywane jedynie dla zgodności wstecznej. Operacje na tabeli z wierszem nagłówkowym nie wymagają specyfikowania obiektu roboczego pozwalających na przechowywanie przechowywanie wierszy, gdyż sama tabela posiada taki obiekt. Obiekt ten nazywa się tak samo jak tabela i jest typu zgodnego z typem wiersza tabeli. Operacje na tabeli tabeli z wierszem nagłówkowym nagłówkowym mogą więc mieć uproszczoną uproszczoną składnie, gdyż gdyż domyślnie używany jest wiersz nagłówkowy. Dla tabel standardowych preferowana forma dostępu jest poprzez index, dla tabel posortowanych poprzez poprzez klucz, a dla tabel haszujących haszujących tylko poprzez klucz. klucz. Wstawianie wierszy odbywa się poprzez wyrażenie INSERT wiersz INTO tab INDEX idx.

Powoduje to wstawienie wiersza przed wierszem o indeksie idx, nowa linia otrzyma indeks idx, a indeksy następnych wierszy zostaną zwiększone o 1. Dla dostępu poprzez klucz składnia jest następująca: INSERT wiersz INTO TABLE tab. Dla tabeli standardowej spowoduje to zawsze wstawienie wiersza jako ostatni, dla tabeli posortowanej w miejscu zależnym od klucza, tak aby zachowany był b ył porządek, a dla tabeli haszującej na podstawie funkcji haszującej. Obiekt wiersz musi być zgodny z definicją tabeli i można go zadeklarować poprzez wyrażenie TYPES|DATA wiersz {TYPE|LIKE} LINE OF {typ_tabeli|tab {typ_tabeli|tabela}. ela}.

Wstawienie wielu wierszy znajdujących się w innej tabeli, ograniczonych przez zakres indeksu odbywa się poprzez dodanie wyrażenia LINES OF tab2 [FORM idx1] [TO idx2].

Dla tabel o nie unikalnym kluczu można również wykorzystać polecenie COLLECT wiersz INTO tab2.

Jeżeli wiersz o podanym kluczu już istnieje, to jest on modyfikowany przez dodanie do pól numerycznych wartości z tabeli tab2. W przypadku polecenia INSERT próba wstawienia wiersza duplikującego klucz do tabeli z unikalnym kluczem powoduje ustawienia pola systemowego sy-surc na cztery. Dołączanie wierszy jest możliwe poprzez składnie APPEND: APPEND wiersz TO tab.

lub APPEND LINES OF tab1 [FROM idx1] [TO idx2] idx2]

TO tab2. tab2.

W przypadku tabeli posortowanej rekordy muszą być dołączane, tak aby posortowanie było zachowane. zachowane. Poniższy przykład pokazuje wykorzystanie wyrażenia APPEND, gdzie t_adres jest strukturą zdefiniowaną poza poza przykładem przykładem DATA adres TYPE t_adres. - 26 -


DATA tabela_adresow TYPE TABLE OF t_adres. … CLEAR tabela_adresow tabela_adresow. . adres-miasto = ‘Warszawa’. adres-ulica = ‘Zlota’. APPEND adres TO tabela_adreso tabela_adresow. w.

Odczyt pojedynczego wiersza z tabeli wewnętrznej odbywa się poprzez wyrażenie READ o następującej składni READ TABLE tab INDEX idx {INTO wiersz|ASSIGNING }.

dla odczytu z wykorzystaniem indeksu lub READ TABLE tab FROM key {INTO wiersz|ASSIGNING }. READ TABLE tab WITH TABLE KEY komp1=f1 … kompn=fn {INTO wa|ASSIGNING }.

dla odczytu z wykorzystaniem klucza, przy czym w pierwszym przypadku key musi być wypełnioną danymi strukturą zgodną z kluczem tabeli, a w drugim warunki na klucz są wyspecyfikowane explicite. Wiersz może być odczytany do obiektu wiersz (oznaczanego często jako wa – working area) lub skojarzony z symbolem pola fs. Obiekt wiersz musi pasować do typu wiersza zdefiniowanego w tabeli wewnętrznej. Wykorzystując dodatkowo słowo kluczowe TRANSPORTING można wskazać które komponenty wiersza mają zostać przepisane do obiektu. W przypadku skojarzenia z symbolem pola nie następuje przepisanie wartości, a jedyne symbol wskazuje na wiersz w pamięci. Tak więc operacje na symbolu s ymbolu pola bezpośrednio zmieniają dane w tabeli wewnętrznej, podczas gdy obiekt wiersz musiałby jawnie zostać przepisany do tabeli. Przypisanie obiektu wiersz do tabeli odbywa się poprzez wyrażenie wyrażenie MODIFY: MODIFY tab FROM wiersz INDEX idx. MODIFY TABLE tab FROM wiersz. MODIFY tab FROM wiersz TRANPORTING komp1 … kompn WHERE wyrazenie_log wyrazenie_logiczne. iczne.

Druga wersja dotycz dostępu poprzez klucz – pierwszy wiersz o kluczu pasującym do obiektu wiersz zostanie zmodyfikowany. Dodając wyrażenie TRANSPORTING można określić, które z komponentów mają zostać zapisane. Możliwa jest również jednoczesna zmiana wielu wierszy spełniających zadane wyrażenie logiczne. Analogiczne składnie mogą zostać wykorzystane do usuwania wierszy. Typowe składnie są następujące: DELETE TABLE tab INDEX idx. DELETE tab FROM key. DELETE TABLE tab WITH TABLE KEY komp1=f1 … kompn=fn.

- 27 -


DELETE tab [FROM idx1] [TO idx2]. DELETE tab WHERE wyrazenie_logiczne.

Ostatnie dwie składnie dotyczą usuwania wielu wierszy. Pierwszym przypadku są to wiersze o indeksie w podanym przedziale, w drugim przypadku wiersze spełniająca podany warunek logiczny określony na komponentach tabeli wewnętrznej. Przetwarzanie tabel wewnętrznych często wiąże się z przetwarzaniem kolejnych wierszy. Wygodnie jest wówczas używać pętli LOOP iterującej po kolejnych wierszach tabeli. Składnia pętli jest następująca: LOOP AT tab {INTO wiersz|ASSIGNING wiersz|ASSIGNING }. … ENDLOOP.

Kolejne wiersza są albo przepisywane do roboczego obiektu wiersz lub są przypisywane do symbolu pola. Kolejność wierszy zależy od typu tabeli. Dla tabeli standardowej zwracane są wiersze w kolejności odpowiadającej indeksowi, dla tabeli posortowanej zgodnie z posortowaniem, dla tabeli haszującej zgodnie z kolejnością, w jakiej wiersze wier sze były b yły dodawane lub zgodnie z sortowaniem o ile takie było wykonane na tabeli. Indeks bieżącego wiersza można odczytać z pola systemowego sy-tabix. Jest on zdefiniowany oczywiście dla tabel typu INDEX TABLE. W składni LOOP, analogicznie do składni poprzednich wrażeń można używać rozszerzeń FROM do określenia zakresu indeksów lub WHERE do kreślenia warunku logicznego. Dodatkowo w bloku przetwarzania pomiędzy LOOP a ENDLOOP mogą zostać wyróżnione następujące bloki AT NEW komp … ENDAT.

oraz AT END OF komp … ENDAT.

Bloki są wykonywane, jeżeli komponent komp przyjmuje nową wartość lub ostatnią wartość w sekwencji wierszy o identycznych wartościach komponentu. Sortowanie wierszy odbywa się za pomocą wyrażenia SORT: SORT tab [ASCENDING|DE [ASCENDING|DESCENDING] SCENDING] [… BY komp1 [ASCENDING|DESCENDING]]. [ASCENDING|DESCENDING]].

Sortowanie może dotyczyć klucza lub jawnie wyspecyfikowanych komponentów. komponentów. Sortowanie tabel haszujących ma sens jedynie przed pętlą LOOP, gdyż tylko tam sortowanie ujawnia się. Sortowanie tabel standardowych zmienia przypisanie indeksów do poszczególnych wierszy. Sortowanie tabel posortowanych nie zmienia ich.

- 28 -


5. Obiektowość w ABAP ABAP historycznie wspiera proceduralny model programowania. Programowanie strukturalne oferuje głównie modularyzacje za pomocą procedur poprzez podział na bloki przetwarzania omówione w rozdziale 3.4. Jednak wraz z pojawieniem się koncepcji obiektowości wprowadzone zostały elementy modelu obiektowego. Podstawowe cechy modelu obiektowego to Abstrakcja – elementy świata rzeczywistego są modelowane jako klasy i powoływane do życia jako obiekty.

•

Enkapsulacja – szczegóły implementacyjne są ukryte za interfejsami.

•

Dziedziczenie – nowe klasy pochodzą od innych klas, dziedzicząc i rozszerzając atrybuty i metody klasy nadrzędnej. n adrzędnej.

•

•

Polimorfizm – różne obiekty mogą wystawiać takie same interfejsy, a dostęp do klas jest ukryty pod interfejsami – użytkownik nie musi znać szczegółów klasy wystawiającej interfejs.

5.1. Klasy Podstawowym elementem modelu obiektowego ABAP są klasy. Klasy globalne, widoczne z dowolnego programu ABAP są tworzone poprzez narzędzie Class Builder w ABAP Workbench. Klasy lokalne są tworzone w programie ABAP i widoczne tylko w jego j ego obszarze. Aby utworzyć klasę należy zdefiniować część definicyjną związaną z deklaracją komponentów klasy oraz część implementacyjną klasy za pomocą wyrażeń: CLASS klasa DEFINITION. PUBLIC SECTION. … PROTECTED SECTION. … PRIVATE SECTION. … ENDCLASS. CLASS klasa IMPLEMENTATI IMPLEMENTATION. ON. … ENDCLASS.

W części definicyjnej mogą pojawić się trzy sekcje związane z zasięgiem komponentów klasy: •

PUBLIC dla obiektów publicznych, dostępnych z dowolnego poziomu,

•

PROTECTED dla obiektów chronionych dostępnych tylko w klasach klas ach pochodnych,

•

PRIVATE dla obiektów dostępnych jedynie w definiowanej klasie.

Na komponenty klasy składają się atrybuty, metody i zdarzenia. Każdy komponent może być statyczny – wówczas jest jedna instancja komponentu dla wszystkich obiektów danej klasy. Co więcej instancja ta jest dostępna, nawet jeśli żaden obiekt klasy nie został utworzony. - 29 -


Jeżeli komponent nie jest statyczny to dla każdego obiektu klasy tworzona jest odrębna instancja komponentu. Atrybuty klasy są klasycznymi obiektami danych ABAP i są definiowane tak jak inne obiekt w ABAP’ie za pomocą wyrażenia DATA, CONSTANTS lub TYPES dla zmiennych, stałych oraz typów odpowiednio. Aby atrybut był traktowany jako statyczny należy słowo kluczowe DATA zastąpić poprzez CLASS-DATA. Dodanie słowa kluczowego READ-ONLY powoduje, iż obiekt może być zmieniany jedynie poprzez metody klasy. klas y. CLASS klasa DEFINITION. PRIVATE SECTION. DATA atrybut1 TYPE i. CLASS-DATA atrybut2 TYPE i. ENDCLASS.

Metody występują zarówno w części deklaracyjnej jak i implementacyjnej klasy. Prosta deklaracja metody ma następującą składnię: METHODS metoda IMPORTING … i i TYPE type … EXPORTING … e i TYPE type … CHANGING … c i TYPE type … EXCEPTIONS … e i …

Elementy składni są zbliżone do elementów składni definiującej moduły funkcyjne i podprocedury przedstawione w sekcji 3.4. Przykład: CLASS klasa DEFINITION. PUBLIC SECTION. METHODS: set_value IMPORTING VALUE(i_value) TYPE i, get_value EXPORTING VALUE(e_value) TYPE i. PRIVATE SECTION. DATA object_value TYPE i. ENDCLASS. CLASS klasa IMPLEMENTATION. IMPLEMENTATION. METHOD set_value. object_value = i_value. ENDMETHOD. METHOD get_value. e_value = object_value. object_value.

- 30 -


ENDMETHOD. ENDCLASS.

Wywołanie metody jest zbieżne ze składnią CALL FUNCTION omówioną w sekcji 3.4, przy czym używa się słów kluczowych CALL METHOD . Istnieje również skrócona forma wywołania metody o składni: CALL METHOD metoda (f 1 = a1 … fn = an).

Dynamiczne wywołanie metody polega na wywołaniu metody, której nazwa jest zawarta w obiekcie, np. jeżeli nazwa metody jest w obiekcie f, to wywołanie może wyglądać następująco: CALL METHOD obiekt->(f).

Metoda o nazwie constructor jest automatycznie wywoływana po utworzeniu każdej nowej instancji obiektu. Metoda o nazwie class_constructor jest wywoływana przy pierwszej próbie dostępu do do klasy. Metody zwracające wartość są deklarowane za pomocą składni METHODS metoda IMPORTING … {VALUE(i i)| ii } {TYPE typ|LIKE obj} [OPTIONAL|DEFAULT [OPTIONAL|DEF AULT def i] … RETURNING VALUE(r) {TYPE typ|LIKE obj}.

Wówczas wywołanie może wyglądać następująco: CALL METHOD obiekt->meto obiekt->metoda da EXPORTING i 1 = a1 … in = an RECEIVING r = a.

W części definicyjne mogą zostać również zdefiniowane zdarzenia ( events). Metody tej klasy lub poza klasą mogą zostać zdefiniowane jako uchwyt dla tych zdarzeń. Wówczas wywołanie zdarzenia w metody tej samej klasy powoduje automatycznie wywołanie metody dedykowanej dedykowanej do obsługi zdarzenia. Aby utworzyć instancję klasy konieczna jest referencja do obiektu o typie zgodnym z klasą. Załóżmy, że został utworzony typ klasy samochod. Wówczas, powołanie instancji klasy i wywołane metody może wyglądać następująco: DATA samochod_ref TYPE REF TO samochod. CREATE OBJECT samochod_ref. CALL METHOD samochod_ref->tankuj.

Utworzenie obiektu może wiązać się z wywołaniem konstruktora. Wówczas przekazanie parametrów do kontraktora odbywa się poprzez rozszerzenie wyrażenia CREATE METHOD o odpowiednie elementy tak jak w wywołaniu w ywołaniu metody: EXPORTING, EXCEPTIONS, … Przykład pokazuje również w jaki sposób adresuje się komponenty klasy. Dla obiektów nie statycznych używa się selektora „->”. Dla obiektów statycznych składnia wygląda następująco klasa=>komponent

- 31 -


przy czym klasa jest nazwą typu a nie obiektu. W obrębie klasy nie jest konieczne używanie selektora. Referencje do obiektu wewnątrz jego samego można uzyskać odwołując się do predefiniowanej referencji me. Obiekt klasy jest usuwany z pamięci, gdy ostatnia referencja z nim związane jest usuwana.

5.2. Dziedziczenie i polimorfizm ABAP implementuje mechanizm pojedynczego dziedziczenia – każda klasa może dziedziczyć tylko z jednej klasy. Składnia umożliwiająca zdefiniowanie klasy potomnej jest następująca: CLASS klasa_potomna DEFINITION INHERITING FORM klasa_nadrzędna. … ENDCLASS.

W klasie potomnej istnieje możliwość redefinicji metody. W części deklaracyjnej musi pojawić się wyrażenie METHODS metoda REDEFINITION.

a w części implementacyjnej metoda musi zostać zdefiniowana ponownie, przy czym zestaw parametrów nie może ulec zmianie w stosunku do definicji w klasie nadrzędnej. Istnieje możliwość wywołania metody w klasie nadrzędnej używając predefiniowanej pseudo referencji super oznaczającej referencje do klasy nadrzędnej. ABAP wspiera również klasy abstrakcyjne. Aby utworzyć klasę abstrakcyjną po słowie kluczowym DEFINITION musi wystąpić słowo kluczowe ABSTRACT. Analogicznie metody mogą być zadeklarowane jako abstrakcyjne poprzez dodanie słowa ABSTRACT . Sytuację odwrotną, w której nie można zmieniać już zdefiniowanej klasy lub metody osiąga się używając słowa kluczowego FINAL w miejscu słowa ABSTRACT. Polimorfizm oznacza, że pewne wywołania metod mogą powodować różne działania w zależności do kontekstu. Polimorfizm może być więc osiągany dzięki dziedziczeniu, gdzie poprzez referencje wskazującą do klasy nadrzędnej faktycznie można wywołać metodę redefiniowaną w pewnej klasy podrzędnej. Innym mechanizmem wspierającym polimorfizm są interfejsy.

5.3. Interfejsy Interfejs opisuje publicznie dostępną sekcję klasy bez jej implementacji. Jeżeli klasa implementuje interfejs, to może być dostępna poprzez ten interfejs. Ponieważ wiele klas może implementować jeden interfejs, a obiekty tych klas są dostępne poprzez jeden obiekt, to mechanizm ten może wspierać polimorfizm. Podobnie jak klasy, interfejsy mogą być lokalne lub globalne. Składnia definicji interfejsu lokalnego jest następująca: INTERFACE interfejs DATA … CLASS-DATA … METHODS … CLASS-METHODS CLASS-METHOD S … EVENTS …

- 32 -


CLASS-EVENTS … ENDINTERFACE.

Interfejs może więc mieć dokładnie takie same komponenty jak klasa, ale wszystkie komponenty są traktowane jako publiczne. Każda klasa może implementować jeden lub wiele interfejsów. W sekcji publiczne definicji klasy musi wystąpić składnia INTERFACES: int1, int2, …

Znak „~” jest selektorem interfejsu. W ramach klasy komponenty interfejsu są adresowane za pomocą składni interfejs~komponent

Interfejsy mogą być komponowane z innych interfejsów poprzez wyrażenie INTEREFACES zawarte pomiędzy INTERFACE … ENDINTERFACE. Wyrażenie DATA interfejs_ref TYPE REF TO interfejs.

tworzy referencję do interfejsu. Poniższy przykład pokazuje definicję interfejsu i klasy implementującej interfejs: INTERFACE raport. METHODS wydrukuj_raport. wydrukuj_raport. ENDINTERFACE CLASS klasa DEFINITION. PUBLIC SECTION. INTERFACES: raport. PRIVATE SECTION. DATA wartosc TYPE i. ENDCLASS. CLASS klasa IMPLEMENTATION IMPLEMENTATION METHOD raport~wydrukuj_raport. raport~wydrukuj_raport. WRITE: / ‘Wartosc: ‘, wartosc. ENDMETHOD. ENDCLASS. DATA klasa_ref

TYPE REF TO klasa.

CREATE OBJECT klasa_ref. CALL METHOD: klasa_ref->raport~wydukuj_r klasa_ref->raport~wydukuj_raport. aport.

- 33 -


5.4. Zdarzenia Zdarzenia (events) są trzecim, obok atrybutów i metod, komponentem klas. Dwa istotne czynniki wyróżniają zdarzenia od metod. Obiekt wywołujący zdarzenie nie zna kodu obsługującego zdarzenie, podczas gdy wywołanie metody wiąże się z jej dokładnym zaadresowaniem. Co więcej, obiekt powodujący zdarzenie nawet nie wie apriori, czy kod obsługujący zdarzenie przyniesie jakiś skutek, np. procedura obsługi zdarzenie może uznać, iż w danym stanie aplikacji, zdarzenie nie skutkuje żadnymi zmianami. Zdarzenia implementują więc luźne powiązania pomiędzy obiektami. Są one związane z koncepcją publikacji i zapisu publish and subscribe) polegającą na tym, iż obiekt publikuje zdarzenie, a inne obiekty mogą ( publish je wywoływać, przy czym obiekt publikujący publikujący zdarzenie nie zna obiektów wywołujących je. Do obsługi zdarzeń wymagane są dwie klasy: klasa wywołująca zdarzenie i klasa implementująca procedurę obsługi zdarzenia ( handler ). ). W klasie wywołującej zdarzenia, wszystkie zdarzenia, jakie mogą zostać wywołane, są deklarowane tak jak pozostałe komponenty klasy za pomocą składni: EVENTS zdarzenie EXPORTING … VALUE(ei) {TYPE typ|LIKE obiekt} [OPTIONAL|DEFAULT [OPTIONAL|DEF AULT def i] …

Zdarzenia statyczne są definiowane za pomocą słowa kluczowego CLASS-EVENTS. W metodach klasy wywołanie zdarzenie odbywa się za pomocą wyrażenia: RAISE EVENT zdarzenie EXPORTING … e i = ai

…

Procedura obsługi zdarzenia może zostać umieszczona w dowolnej klasie za pomocą wariacji składni METHODS lub CLASS_METHODS: METHODS handler FOR EVENT zdarzenie OF {klasa|interfe {klasa|interfejs} js} IMPORTING … e i … [sender].

Metoda handler zostaje przypisana do obsługi zdarzenia zdarzenie podanej klasy lub interfejsu. Powiązanie zdarzenia z metodą obsługująca zdarzenia odbywa się poprzez rejestrację. Rejestracja metody obsługującej zdarzenie może w każdym momencie być odwołana lub zamieniona na inną. Rejestracja odbywa się poprzez składnię: SET HANDLER .. ref_handler i->handleri FOR ref_sender [ACTIVATION act].

gdzie ref_handler oraz ref_sender są referencjami do wskazującymi na obiekt zawierający obsługę zdarzenia oraz obiekt wywołujący zdarzenia.

- 34 -


6. Programowanie ekranów 6.1. Listy Listy są standardowym sposobem organizacji prezentacji danych wynikowych przeznaczonym przeznaczonym głównie do raportowania wyników, w yników, które mogą być bezpośrednio przesłane do systemu zarządzania drukowaniem SAP (spooler SAP). W najprostszym programie na początku wywoływany jest ekran wyboru (patrz 6.3), następnie przekazane przez użytkownika dane są odczytywane i przetwarzane i na zakończenie programu wywoływany jest ekran listy. Listy są jedynym typem ekranów, które nie są zdefiniowane w programie ABAP apriori. Dopiero wypisywanie lub formatowanie danych w trakcie działania programu ABAP powoduje zapis wyników do tzw. bufora list, li st, a następnie ekran listy list y może zostać przywołana 1 z bufora automatycznie lub na żądanie programu . Wówczas uruchamiany jest specjalny program systemowy – procesor procesor listy (list procesor ), ), do którego przekazywane jest sterowanie. Obszar prezentacji wyników na ekranie typu lista jest podzielony na linie i wiersze znaków. Początkowa pozycja kursora jest w lewym górnym rogu. Wypisywanie na ekran pól odbywa się za pomocą polecenia WRITE [AT /pos(len)] pole [opcje …].

Polecenie powoduje wypisanie zawartości pola pole na ekranie używając len znaków, w pozycji określonej przez przesunięcie pos względem bieżącej pozycji kursora. Ukośnik powoduje przejście do nowej linii przed rozpoczęciem wypisywana w ypisywana wyników. Przykładowe opcje to LEFT-JUSTIFIED dla wyrównania do lewej, COLOR dla wyspecyfikowania koloru, INPUT dla pól tekstowych, HOTSPOT dla obiektów klikalnych. W pojedynczym poleceniu WRITE może wystąpić sekwencja argumentów oddzielona przecinkami. Opcje mogą być również włączane lub wyłączane dla wszystkich poleceń WRITE poprzez polecenie FORMAT, np. FORMAT HOTSPOT ON . Drukowanie linii poziomych jest możliwe poprzez komendę ULINE [AT /pos(len)].

lub WRITE [AT /pos(len)]

sy-uline.

lub WRITE [AT /pos(len)] ‘--------------‘. ‘--------------‘.

Analogicznie linie pionowe można drukować używając obiektu sy-vline lub drukując znak ‘|’. W opisie wyrażenia WRITE można znaleźć dodatkowe określenia na różne elementy, np. WRITE line_top_right_corner AS LINE.

powoduje wydrukowania wydrukowania na ekranie ekranie odpowiedniego narożnika. Drukowanie pusty linii umożliwia komenda SKIP [n].

1

Podczas debugowania można podejrzeć bieżące listy w ABAP Debugger wybierając wybierając opcje Display List . - 35 -


gdzie n jest liczbą pusty wierszy. Pozycjonowanie kursora horyzontalne i wertykalne może być dokonane dokonane przez polecenia polecenia – przesunięcie kursora do kolumny col

•

POSITION col.

•

SKIP TO LINE lin.

•

NEW-LINE

– przejście do nowej linii

•

NEW-PAGE

– przejście do nowej nowej strony

– wydrukowanie wydrukowani e lin pustych wierszy

Rozmiar drukowanej strony ustalamy poleceniami REPORT raport LINE-SIZE szerokosc. REPORT raport LINE-COUNT wysokosc.

Tytuł listy można zdefiniować poprzez wyrażenie SET TITLEBAR tytul.

Ekrany listy są wywoływane automatycznie gdy ostatni z bloków przetwarzania zdarzenia jest zakończony. zakończony. Gdy wyświetlane są inne ekrany można wypisywać wyniki jedynie do bufora. Wyświetlenie listy znajdującej znajdującej się w buforze jest jest możliwe poprzez wyrażenie wyrażenie LEAVE TO LIST-PROCESSING [AND RETURN TO SCREEN nr].

Powoduje to wyświetlenie listy na zakoćnczeniu obsługi zdarzenia Process After Input bieżącego ekranu. ekranu. Opuszczenie Opuszczenie listy wykonuje się poprzez poprzez kod LEAVE LIST-PROCESSIN LIST-PROCESSING. G.

Użytkownik może wywoływać akcję na ekranie listy, głównie poprzez zaznaczanie linii dwuklikiem myszki. Akcje użytkownika powodują wywołania zdarzeń w programie ABAP, który wywołał ekran listy. Wyrażenia znajdujące się w procedurze obsługi zdarzenia zapisują wyniki do nowej listy, która jest przywoływana na koniec obsługi zdarzenia jako modalne okno dialogowe. W ten sposób tworzony jest łańcuch ekranów, który jednak musi być ograniczony do 20 ekranów. Informacje związane z akcjami użytkownika mogą być wyświetlane jedynie w obszarach statusu GUI (statusy są omówione w następnym punkcie). Wyrażenie AT LINE-SELECTI LINE-SELECTION. ON.

umożliwia zdefiniowanie bloku zdarzenia związanego z zaznaczeniem linii. Linię można zaznaczyć poprzez dwuklik myszką lub przycisk funkcyjny F2, lub funkcje Choose, która pojawia się w statusie ekranu. Aby odczytać, która linia została zaznaczona można posłużyć się obiektami sy-lilli oraz sy-curow, które dostarczają informacji o bieżącej pozycji kursora. Jednak lepszym sposobem jest skojarzenie z linią ukrytych informacji poprzez wyrażenie HIDE f

Zaznaczenie linii powoduje automatycznie załadowanie ukrytych informacji do zmiennej f. Każde inne zdarzenie można analogicznie obsłużyć używając AT USER-COMMAND i testując obiekt systemowy sy-ucomm zawierający tzw. kod funkcyjny określający przyczynę zdarzenia. W trakcie obsługi zdarzenia można utworzyć nową listę (tzw. detail list ). ). Listy są indeksowane, a numer bieżącej listy jest przetrzymywany w obiekcie sy-lsind. Każde wywołanie zdarzenia powoduje zwiększenie indeksu bieżącej listy, dlatego wyniki wypisywane w zdarzeniu trafiają na nową listę. Obiekt sy-listi przechowuje indeks listy, - 36 -


na której akcja użytkownika spowodowała wywołanie zdarzenia. Jeżeli użytkownik wybierze opcję Back to to bieżąca lista jest usuwana. Lista szczegółowa ( detail list ) może być również wyświetlona jako okno modalne, jeżeli zostanie użyta konstrukcja WINDOW STARTING AT left upper ENDING AT right lower.

Podczas przetwarzania listy można również dokonać zmian poszczególnych linii. Służy do tego celu wyrażenie w yrażenie MODIFY LINE linia [INDEX idx] …

gdzie idx jest indeksem listy (domyślnie bieżąca lista).

6.2. Ekrany ogólne Każdy ekran składa się z rozmieszczenia elementów oraz logiki przepływu ekranu ( screen flow logic). Logika jest podzielona na co najmniej dwa bloki: blok PBO ( P rocess rocess Befor Output ) przetwarzania danych przed ich pokazaniem oraz blok PAI ( P rocess rocess A fter I nput nput ) przetwarzania danych po akcji użytkownika. użytkownika. Każdy ekran jest przypisany statycznie lub dynamicznie do dokładnie jednego programu. Użytkownik może jednak widzieć jednocześnie j ednocześnie wiele ekranów w postaci komponentów lub tzw. podekranów. Po zakończeniu przetwarzania ekranu wywoływany jest następny ekran. Kolejne wywołania ekranów tworzą sekwencje ekranów będącą podstawą aplikacji zorientowanych na dialog. Sekwencje ekranów mogą być zanurzone w innych sekwencjach ekranów, tworząc w ogólnym przypadku pewne potencjalne ścieżki wywołań kolejnych ekranów, tak jak pokazano na Rys. 6.1.

Rys. 6.1. Sekwencja ekranów. Źródło: [4]. [4].

Ekrany ogólne ( general screen) definiuje się za pomocą narzędzia Screen Painter. Aby utworzyć nowy ekrana należy wywołać menu kontekstowe na drzewie programu i wybrać opcję NEW , a następnie SCREEN .

- 37 -


Podczas definiowania ekranu określa się podstawowe atrybuty, takie jak •

•

•

Program – nazwa programu, do którego należy ekran, Screen number – unikalny w obszarze programu, czterocyfrowy identyfikator ekranu, Screen type – typ ekranu określający sposób jego prezentacji: jako okno modalne lub nie, podekran który może być wyświetlony w yświetlony w innym ekranie

Next screen – numer następnego ekranu jaki będzie uruchomiony po zakończeniu zakończeniu obsługi definiowanego ekranu; wartość zero lub brak wartości oznacza, iż jest to ostatni ekran. Rozmieszczenie elementów na ekranie jest możliwe poprzez narzędzie Graphical Screen Painter . Uruchamia się je poprzez przycisk Layout w w narzędziu Screen Painter lub poprzez transakcje o kodzie SE51. W oknie Graphical Screen Painter w w lewym panelu są dostępne elementy, które można rozmieszczać na ekranie techniką drag&drop. Podstawowe elementy to •

•

•

pola tekstowe i ramki – umożliwiają wyświetlanie nieedytowalnych nieedytowalnych danych, danych, pola input/output – umożliwiają wyświetlanie wyświetlanie danych z programu programu lub pobranie danych do programu,

•

przyciski, przyciski typu radio, radio, typu checkbox, checkbox,

•

podekrany – zanużone ekrany, ekrany,

•

zakładki,

•

tabele – umożliwiają wyświetlanie i edycję danych w postaci tabelarycznej,

•

komponenty firm trzecich

Każdy komponent posiada atrybuty. Okienko atrybutów wywołuje się poprzez dwuklik na wybranym komponencie. Warto zwrócić uwagę na atrybut FctCode, który jest kodem funkcyjnym ( function code) komponentu. Wartość kodu jest zwracana do programu ABAP w wyniku akcji użytkownika, np. w momencie kliknięcia przycisku. Atrybuty elementów są również dostępne z poziomu Screen Painter’a w zakładce Element list (patrz (patrz Rys. 6.2).

- 38 -


Rys. 6.2. Lista elementów ekranu w narzędziu Screen Painter

Ostatnim elementem jest zawsze 20 znakowe pole typu OK, któremu zwyczajowo nadaje się nazwę OK_CODE. Pole te jest używane do przekazywania wartości kodu funkcyjnego elementów. Aby w programie można było odczytać zawartość pola, należy zdefiniować obiekt o takiej samej nazwie jak pole typu OK oraz o globalnym systemowym typie syucomm. Wówczas, np. kliknięcie przycisku spowoduje przesłanie wartości jego FctCode do obiektu OK_CODE w programie (o ile taką t aką nazwę nadano dla pola typu OK). Ogólnie, każdy element, który umożliwia wprowadzanie danych jest związany z polem screen field ). ekranu ( screen ). W programie muszą zostać utworzone globalne obiekty o nazwach odpowiadających odpowiadających nazwom elementów na ekranie 2. Wartości pól są automatycznie przesyłane do zmiennych globalnych w programie o tych samych nazwach. Dlatego nazwy elementów ekranu wykorzystywanych do wprowadzania danych muszą być unikalne w obrębie programu. Ekrany mogą być wywoływane w programie ABAP poprzez wyrażenie CALL SCREEN nr.

Wówczas ekran o numerze nr staje się pierwszym ekranem nowej sekwencji. Jeżeli w tej sekwencji zostanie wywołany ekran o numerze 0, to sekwencja kończy swoje działanie, a 2

Obiekty muszą również mieć odpowiedni typ. Zauważmy, ze dla liczb ułamkowych typ f nie może zostać użyty. - 39 -


sterowanie przechodzi do następnego wyrażenia bezpośrednio za wyrażeniem wywołującym sekwencję nr. W każdym przypadku wywołania ekranu poprzez CALL SCREEN bieżąca sekwencja ekranów jest przerywana i następuje uruchomienie nowej sekwencji. W ten sposób tworzy się stos wywołań sekwencji ekranów, który może mieć maksymalny rozmiar 50 wywołań. Jednak ze względu na ekrany uruchamiane przez system (np. ekrany pomocy lub komunikaty o błędach) w praktyce nie powinno się przekraczać 40 zagnieżdżonych zagnieżdżonych wywołań. Należy pamiętać, że zanurzone ekrany będą operować na zmiennych globalnych całego programu, dlatego należy zadbać o to aby istotne dane dane nie zostały nadpisane. nadpisane. W szczególności szczególności tyczy się to kodu OK, który zazwyczaj pojawia się na zagnieżdżonych ekranach. Dlatego w praktyce w module PAI zazwyczaj pierwszym krokiem jest zapamiętanie jego wartości w lokalnej zmiennej, a dopiero następnie przejście do przetwarzania danych. Innym sposobem wywołania ekranu jest uruchomienie transakcji związanej z ekranem. Aby utworzyć transakcje należy w narzędziu Object Nawigator wywołać menu kontekstowe na liści obiektów i wybrać Create->Transaction->Dialog Transaction. Wywołanie transakcji powoduje załadowanie programu i rozpoczęci jego wykonania od początkowego początkowego ekranu wskazanego w transakcji (dokładnie od jego zdarzenia PBO). Typowe zastosowanie wiąże się ze związaniem transakcji z elementami interfejsu użytkownika, np. menu. Jednak transakcja może być również wywołana z poziomu programu poprzez CALL TRANSACTION kod_transakc kod_transakcji ji LEAVE TO TRANSACTION kod_transakcji kod_transakcji

przy czym druga opcja powoduje zakończenie zakończenie bieżącego bieżącego programu i wywołanie wywołanie transakcji. Trzeci sposób wywołania ekranu wiąże się z atrybutem next screen ekranu. Gdy przetwarzanie ekranu zostaje zakończone (po zdarzeniu PAI) automatycznie wywoływany jest następny ekran. Następny ekran jest definiowany w narzędziu Screen Painter , jednak może być również definiowany dynamicznie w programie poprzez wyrażenie (patrz Rys. 6.3) SET SCREEN nr.

Ustawienie numeru ekranu na 0 oznacza zakończenie programu po zakończeniu przetwarzania bieżącego ekranu. Możliwe jest j est również zapętlenie ekranu poprzez ustawienie numeru następnego ekranu jako numer bieżącego ekranu. Numer bieżącego ekranu może być zawsze odczytany poprzez pole systemowe s ystemowe sy-dynnr. Zakończenie przetwarzania ekranu następuje na końcu bloku obsługującego zdarzenie PAI lub w przypadku napotkania polecenia LEAVE SCREEN.

lub LEAVE TO SCREEN nr.

Pierwsze polecenie powoduje przejście do następnego ekranu, drugie polecenie do ekranu o numerze nr.

- 40 -


Rys. 6.3. Dynamiczna sekwencja ekranów. Źródło: [4]. [4].

Logika przypływu sterowania przez ekran ( screen flow logic) jest definiowana przez język programowania zbliżony do ABAP’u , ale składający się jedynie z kilku słów kluczowych. Logikę definiuje się na zakładce Flow Logic w narzędziu Screen Painter . Nie ma tu jawnej deklaracji obiektów, jednak są dostępne pola ekranu. Logika ekranu składa się z bloków przetwarzania, definiowanych przez słowo kluczowe PROCESS. Możliwe jest zdefiniowane czterech bloków: PROCESS BEFORE OUTPUT. … PROCESS AFTER INPUT. … PROCESS ON HELP-REQUEST. … PROCESS ON VALUE-REQUEST VALUE-REQUEST. . …

Po utworzeniu ekranu domyślnie są utworzone pierwsze z dwóch bloków, które są obowiązkowe. Blok PBO (PROCESS BEFORE OUTPUT) jest wykonywany przed wyświetleniem ekranu i służy do przygotowania ekranu do wyświetlenia. Blok PAI (PROCESS AFTER INPUT) jest uruchamiany w wyniku akcji użytkownika na elementach z ustawionym kodem funkcyjnym ( function code) i służy do przetwarzania danych wprowadzonych przez użytkownika. W odróżnieniu od pozostałych bloków przetwarzania, po bloku PAI uruchamiany jest następny ekran. Blok POH (PROCESS ON HELPREQUEST) jest uruchamiany, gdy użytkownik zażąda pomocy związanej z polem (przycisk

- 41 -


F1), a blok POV (PROCESS ON VALUE-REQUEST), gdy użytkownik zażąda pomocy związanej z dopuszczalnymi wartościami (przycisk F4). Każdy z bloków przetwarzania ekranu służy jedynie do kontroli nad przesyłem danych z ekranu do obiektów ABAP oraz do wywołania odpowiednich modułów dialogowych w programie. W tym celu można wykorzystać wąski zbiór słów kluczowych. Najważniejsze z nich to: •

MODULE – powoduje uruchomienie modułu dialogowego w programie ABAP,

•

FIELD – umożliwia kontrolę przysłania danych z pól ekranu do obiektów ABAP,

•

CHAIN/ENDCHAIN – umożliwia grupowanie wywołań modułów dialogowych w

łańcuch przetwarzania, •

CALL SUBSCREEN – powoduje wywołanie podekranu.

Uruchomienie modułu odbywa się poprzez polecenie MODULE mod.

Moduły dialogowe w programie ABAP są definiowane za pomocą następującej składni 3: MODULE pbo_mod OUTPUT … ENDMODULE. MODULE pai_mod INPUT … ENDMODULE.

Moduły zadeklarowane jako OUTPUT mogą być uruchamiane jedynie w zdarzeniu PBO, a moduły INPUT w zdarzeniach PAI, POH, POV. Moduły dialogowe nie powinny raczej zawierać deklaracji danych, gdyż każda taka deklaracja jest deklaracją globalną obiektu. Zaleca się stosowanie modułów jedynie do sprawdzenia danych i wywołania odpowiednich procedur, które mogą operować na obiektach lokalnych. Moduł nie jest sztywno związany z żadnym z ekranów, przy czym zawsze można sprawdzić bieżący ekran używając obiektu systemowego sy-dynnr. Transport danych pomiędzy ekranem, a programem ABAP może odbywać się automatycznie – na podstawie zgodności nazw pól ekranu oraz obiektów globalnych na początku obsługi zdarzenia PAI. Transport danych może odbywać się również w sposób kontrolowany przez programistę. Jeżeli w logice przepływu ekranu ekranu w zdarzeniu PAI wystąpi wyrażenie FIELD pole.

to wartość pola zostanie przesłana do programu ABAP dopiero po napotkaniu tego wyrażenia w yrażenia (inne pola są przesyłane na początku zdarzenia PAI). Wyrażenie to jest przydatne z wykorzystaniem innych wyrażeń warunkowych, np. wyrażenie FIELD pole MODULE modul ON REQUEST.

powoduje uruchomienie modułu modul tylko, jeżeli wartość pola pole została zmieniona przez użytkownika w stosunku do wartości jaką miało po zdarzeniu PBO. Zamiast ON 3

Nie należy mylić składni i znaczenia polecenia MODULE w języku ABAP oraz w logice przepływu ekranu. - 42 -


REQUEST można wykorzystać ON INPUT co oznacza wykonanie modułu, jeżeli pole

zawiera wartość różną od wartości początkowej. Powyższe warunki mogą być grupowane za pomocą wyrażenia wyrażenia CHAIN, np. CHAIN. FIELD: pole1, pole2,… MODULE modul1 ON {CHAIN-INPUT| {CHAIN-INPUT|CHAIN-REQUEST} CHAIN-REQUEST} FIELD: pole3, pole4,… MODULE modul2 ON {CHAIN-INPUT| {CHAIN-INPUT|CHAIN-REQUEST} CHAIN-REQUEST} ... ENDCHAIN.

Moduły są uruchamiane jeżeli choć jedno pole w wyrażeniu FIELD spełnia warunek. Powyższe rozwiązania świetnie nadają się do sprawdzania poprawności danych wprowadzonych w poszczególnych polach lub grupach pól. Jeżeli w wywołanym module zostanie wyświetlony błąd lub ostrzeżenie, to pola stają się ponownie edytowalne dla użytkownika (zdarzenie PAI nie kończy się przejściem do następnego ekranu). Pole typu OK jest używane do wyznaczania kodów funkcyjnych związanych z akacjami użytkownika. Jednak, aby zapewnić jednoznaczność wartości tego pola w następnych ekranach zaleca się na początku modułu PAI zapamiętanie wartości pola i natychmiastowej jego wyczyszczenie. wyczyszczenie. Typowy moduł PAI może wyglądać wyglądać następująco: MODULE user_command_0100 INPUT. save_ok = ok_code. CLEAR ok_code. CASE save_ok. WHEN ‘BACK’ LEAVE TO SCREEN …. WHEN ‘EXIT’ LEAVE PROGRAM. WHEN ‘CANCEL’ LEAVE SCREEN. WHEN ‘PRESS’ CALL METHOD screen_100=>handle_push_bu screen_100=>handle_push_button. tton. ENDCASE. ENDMODULE.

Akcje użytkownika na ekranie wywołują zdarzenie PAI, gdy dotyczą elementów z określonym kodem funkcyjnym (różnego typu przyciski). W szczególności wypełnianie pól tekstowych nie powoduje odpalenia zdarzenia PAI. Jednak J ednak istnieją jeszcze możliwe interakcje na innych elementach ekranu, takich jak menu ( menu bar ), ), belce standardowej, belce aplikacji. Zależnie od typu ekranu są dostępne różne elementy interfejsu. Rys. 6.4 przedstawia rozmieszczenie elementów interfejsu SAP dla typowego ekranu.

- 43 -


Rys. 6.4. Elementy interfejsu SAP. Źródło: [4]. [4].

Elementy te ( GUI statuses) definiuje się poprzez narzędzie Menu Painter (transakcja (transakcja SE41). W aplikacji Object Nawigator należy wywołać menu kontekstowe programu, a następnie wybrać Create->GUI Status. Aby zdefiniować funkcję należy podać kod funkcyjny, tekst funkcji oraz powiązanie z elementem interaktywnym: np. menu, standardowa belka, belka aplikacji oraz klawisze funkcyjne. Na szczególną uwagę zasługuje klawisz funkcyjny F2, który odpowiada dwuklikowi myszki, a więc funkcja przypisana dla klawisza F2 będzie również uruchamiana poprzez dwuklik myszki. m yszki. Po zdefiniowaniu elementów typu GUI status należy je jeszcze powiązać z ekranem w module dialogowym dialogowym uruchamiany w PBO poprzez polecenie polecenie SET PF-STATUS

status.

Powoduje to związanie status z bieżącym ekranem oraz następnymi ekranami w sekwencji, aż do napotkania nowej definicji. Tytuł ekranu określa się poprzez wyrażenie SET TITLEBAR tytul.

6.3. Ekrany wyboru Ekrany wyboru ( selection screens), w odróżnieniu od ogólnych ekranów, są ekranami generowanymi przez środowisko ABAP Workbench. Programista nie projektuje wyglądu ekranu tak jak w narzędziu Screen Painter , ale definiuje komponenty ekranów za pomocą wyrażeń ABAP. Chociaż pełną funkcjonalność można uzyskać stosując ogólne ekrany, to ekrany wyboru mogą być wygodnym narzędziem do szybkiego budowania prostych, historycznie związanych z raportowaniem aplikacji. Programista nie musi używać Screen Painter’a a środowisko wykonuje część pracy, jaką musiałby wykonać programista w przypadku implementacji implementacji ogólnych ekranów. ekranów. Ekrany wyboru są definiowane w części globalnych deklaracji programu. Ekrany wyboru łącznie z deklaracjami pól są widoczne w zakresie całego programu. Każdy program wykonywalny ma predefiniowany ekran wyboru o numerze 1000, a więc żadnemu innemu ekranowi wyboru nie można przypisać tego numeru. Definicje pól poprzez słowa kluczowe PARAMETERS oraz SELECT-OPTIONS nie zawarte jawnie w definicji ekranu dotyczą pól związanych ze standardowym ekranem. Pozostałe ekrany definiuje się za pomocą poleceń - 44 -


SELECTION-SCREEN SELECTION-SCR EEN BEGIN OF SCREEN numer [TITLE nazwa] [AS WINDOW]. … SELECTION-SCREEN SELECTION-SCR EEN END OF SCREEN numer.

Definicja pól musi być zawarta pomiędzy powyższymi poleceniami. Opcja AS WINDOW powoduje utworzenie utworzenie okna modalnego. modalnego. Wyrażenie SELECTION-SCREEN może być również wykorzystywane do formatowania ekranu poprzez podanie po wyrażeniu SELECTIONSCREEN dodatkowych poleceń, z czego najważniejsze to •

ULINE /pos(len) – używane do podkreślania

•

COMMENT /pos(len) como [FOR field f] – wyświetlenie tekstu

•

SKIP n – pusta linie

•

BEGIN OF LINE. … END OF LINE.

umieszczenie elementów w jednej linii •

BEGIN OF BLOCK blok. [WITH FRAME [TITLE tytul]]. … END OF BLOCK blok.

utworzenie logicznego bloku. •

PUSHBUTTON /pos(len} text

utworzenie przycisku. Podstawowe komponenty, komponenty, jakie mogą pojawić się na ekranie wyboru w yboru to: •

•

pola tekstowe i ramki, pola do wprowadzania danych, w tym przyciski radio, checkbox’y, checkbox’y, pola do wprowadzania złożonych danych,

•

przyciski,

•

podekrany (subscreens), (subscreens),

•

zakładki (tabs).

Pojedyncze pole jest definiowane za pomocą wyrażenia PARAMETERS o następującej składni PARAMETERS p [(len)] {TYPE typ|LIKE obiekt} [DECIMALS Dec] [DEFAULT def] [LOWER CASE] [OBLIGATORY]

- 45 -


[VALUE CHECK] [AS CHECKBOX] [RADIOBUTTON GROUP grupa] …

Nazwa parametru nie może być dłuższa niż 8 znaków. Z parametrem związany jest globalny obiekt o tej samej nazwie. Do tego obiektu ładowane są dane wprowadzone przez użytkownika poprzez związane z nim pole. Definicja może zawierać szereg dodatkowych atrybutów. Najczęściej używane to: •

DEFAULT do określenia pierwszej wartości parametru,

•

LOWER CASE aby wymusić rozróżnianie wielkich i małych liter,

•

OBLIGATORY do oznaczanie pola jako wymagane,

•

VALUE CHECK do automatycznego sprawdzania wartości na podstawie definicji obiektu obiekt w w słowniku ABAP,

•

AS CHECKBOX do definiowania checkbox’ów,

•

RADIOBUTTON GROUP do grupowania przycisków radio,

•

USER COMMAND kod .

Ostatni z atrybutów określa kod funkcyjny ( function code) zwracany przy zdarzeniach związanych z polem. Bardzo ważną cechą ekranów wyboru jest możliwość definiowania złożonych pól poprzez wyrażenie: SELECT-OPTIONS SELECT-OPTION S nazwa FOR obiekt

Definicja powoduje utworzenie globalnej tablicy wewnętrznej ( internal table), której typ wiersza jest kopiowany z obiektu obiekt . W wyrażeniu można używać większości atrybutów takich jak w wyrażeniu PARAMETERS. Specyficzne atrybuty NO INTERVAL i NOEXTENSION pozwalają na zawężanie wyboru wartości dla pól podczas gdy program jest uruchomiony. Złożone pola są głównie stosowane do określania warunków dla zbiorów danych jakie mają być raportowane. Typowe zastosowanie wiąże się z wykonaniem zapytania zapytania SELECT wykorzystującego dany podane przez użytkownika. Zazwyczaj w klauzuli WHERE używa się wtedy składni WHERE pole_tabeli IN pole_ekranu.

Wywołanie ekranu odbywa się poprzez wyrażenie CALL SELECTION-SCREEN numer [STARTING AT x1 y1] [ENDING AT x2 y2].

Z punktu widzenia programisty przetwarzanie danych dostarczanych poprzez ekran wyboru jest uproszczone w stosunku do zwykłych ekranów i polega na obsłudze zdarzeń. W rzeczywistości interakcja ekranu z programem opiera się na takich samych zasadach jak w przypadku ogólnych ogólnych ekranów, jednak jednak to środowisko automatyzuje automatyzuje transport danych ekranu ekranu do zmiennych. Pole systemowe sy-dynnr umożliwia rozpoznanie, który ekran wywołał zdarzenie. - 46 -


Bloki obsługujące poszczególne zdarzenia definiuje się za pomocą następujących wyrażeń: •

AT SELECTION-SCREEN OUTPUT

Zdarzenie jest wywoływane w modelu PBO przy każdym wywołaniu ekranu i umożliwia m.in. dynamicznie d ynamicznie modyfikacje modyfikacje ekranu. •

AT SELECTION-SCREEN ON pole

Zdarzenie jest wywoływane w module PAI gdy pole jest przekazywane do programu ABAP. Typowe zastosowanie to sprawdzenie poprawności danych wprowadzonych w polu. •

AT SELECTION-SCREEN ON END OF pole

Zdarzenie to (również poprzednie zdarzenie) jest związane z edycją pól wielokrotnego wyboru poprzez okna dialogowe. •

AT SELECTION-SCREEN ON BLOCK blok

Zdarzenie jest wywoływane gdy wszystkie pole związane z blokiem są przekazywane z ekranu do programu. •

AT SELECTION-SCREEN ON RADIOBUTTON GROUP grupa

Zdarzenie jest związane z przekazywaniem z ekranu wartości pól radio. •

AT SELECTION-SCR SELECTION-SCREEN EEN

Jest to ostatnie zdarzenie wywoływane, gdy wszystkie dane z ekranu zostały przekazane do programu. •

AT SELECTION-SCREEN ON HELP-REQUEST FOR pole AT SELECTION-SCREEN ON VALUE-REQUEST FOR pole

Zdarzenia wywoływane, wywoływane, gdy użytkownik uż ytkownik żąda pomocy lub listy wartości (przyciski F1 i F4). Ze polami dla których określono kod funkcyjny, w bloku obsługującym zdarzenie można go odczytać z tablicy SSCRFIELDS z komponentu UCOMM. Dodatkowo istnieje możliwość zdefiniowania pięciu przycisków w belce narzędziowej okna. Przyciski te mają przypisane kody funkcyjne FC01 do FC05, a napisy pojawiającej się na przyciskach definiuje się poprzez ustawienie komponentów SSCRFIELDS-FUNCTXT_01 do SSCRFIELDS-FUNCTXT_05. Aktywacja przycisków dokonuje się poprzez wyrażenie SELECTION-SCREEN SELECTION-SCR EEN FUNCTION KEY n.

Podgląd wyglądu ekranu wyboru można uzyskać wywołując Screen Painter dla ekranu, jednakże nie można można zmieniać ekranu ekranu wyboru za pomocą Screen Painter’a. Przykładowy program definiujący ekran wyboru oraz blok obsługujący zdarzenie jest przedstawiony na poniższym listingu. W bloku obsługi zdarzenia wykonywane jest zapytanie do bazy z wykorzystaniem parametrów przekazanych przez ekran, a następnie na podstawie wyników może być wyświetlony w yświetlony komunikat. REPORT s_selection_screen_check. s_selection_screen_check.

- 47 -


* dane globalne DATA wa_sflight TYPE sflight. * definicja ekranu wyboru PARAMETERS:

p_carrid TYPE sflight-carrid, sflight-carrid,

p_connid TYPE sflight-connid, sflight-connid, p_fldate TYPE sflight-fldate. sflight-fldate. * blok obsługi zdarzeń AT SELECTION SCREEN ON p_fldate. SELECT SINGLE seatsocc seatsmax FROM sflight INTO (wa_sflight-seatsocc, (wa_sflight-seatsocc, wa_sflight-seatmax) wa_sflight-seatmax) WHERE carrid = p_carrid AND connid = p_connid. IF wa_sflight-seatsocc wa_sflight-seatsocc > wa_sflight-seatsmax. wa_sflight-seatsmax. MESSAGE e888(sabapdocu) WITH text-030. ENDIF.

6.4. Komunikaty Komunikaty są krótkimi jednolinijkowymi wiadomościami tekstowymi dedykowanymi do informowania użytkownika o przepływie programu, błędach i ostrzeżeniach, itp. Komunikaty są przechowywane w tabel systemowej T100 zawierającej m.in. klasę komunikatu, numer komunikatu oraz tekst komunikatu. Komunikaty można tworzyć za pomocą narzędzia Message Maintenance Maint enance (transakcja SE91) wywoływaneg w ywoływanegoo z Object Navigator’a poprzez menu kontekstowe. Wywołanie komunikatu odbywa się poprzez polecenie MESSAGE. Typowe składnie wywołania to: MESSAGE tnnn(id). MESSAGE ID id TYPE t NUMBER n.

gdzie t jest typem komunikatu, nnn numerem, a id klasą komunikatu. Klasa komunikatu może zostać pominięta jeżeli wcześniej w programie została podana domyślna klasa poprzez MESSAGE-ID id. Jeżeli tekst widomości zawiera znaki „&”, to w tym miejscu można żądać wstawienia tekstu podanego w wywołaniu komunikatu z wyrażeniem WITH, WITH, np. wywołanie MESSAGE e888(sabapdocu) WITH text-030.

powoduje wyświetlenie komunikatu typu e, o numerze 888, klasy sabapdocu o tekście „& & & &”. W efekcie wyświetlana jest zawartość pola text-030. Można definiować komunikaty o następujących typach: t ypach: - 48 -


•

•

•

I lub S Używane do informowania o postępach programu. Typ I powoduje wyświetlenie komunikatu w oknie, a typ S w belce statusu ekranu. E lub W Używane do informowania o błędach, nieprawidłowych wartościach pól. A lub X Używane do zakończenia wykonywania programu. Typ A powoduje wyświetlenie komunikatu i jest używany w przypadku kontrolowanego wyjścia z programu, np. w przypadku braku autoryzacji. Typ X jest używany w przypadku błędu wykonywania programu i nie powoduje wyświetlenia komunikatu, ale umieszczenie go w utworzonym zrzucie kontrolnym.

6.5. Menu kontekstowe Podczas działania programu ABAP menu kontekstowe jest wywoływane poprzez prawy przycisk myszy. Standardowo z ekranem programu jest związane domyślne menu kontekstowe. Pola typu input oraz oraz output , pola tekstowe, zakładki, obszary, podekrany mogą posiadać własne menu kontekstowe, jeżeli ich atrybut ON _CTMENU_field zostanie wypełniony. Wartość atrybutu oznacza nazwę procedury, która musi posiadać parametr typu CL_CTMENU, będący referencją do wywoływanego menu kontekstowego. Procedura jest uruchamiana, gdy użytkownik wywoła menu kontekstowe i umożliwia dodanie pozycji w menu poprzez metodę add_function. W poniższym przykładzie do dowolnego obiektu, dla którego atrybut ON_CTMENU_field ma wartość ON_CTMENU_menu_kontekstowe zostanie dodana pozycja menu PRESS. FORM ON_CTMENU_menu_kontekstowe cl_ctmenu.

USING

menu

TYPE

REF

TO

CALL METHOD menu->add_function menu->add_function EXPORTING fcode = ‘PRESS’ text = ‘PRESS’.

7. Zewnętrzne źródła danych 7.1. Współpraca z bazą danych Niezależność od systemu bazodanowego bazodanowego w systemie SAP jest osiągnięta poprzez wprowadzanie dodatkowej warstwy. Dostęp do bazy danych odbywa się poprzez interfejs bazodanowy SAP. Definiowanie tabel Tabele można tworzyć jedynie jed ynie poprzez narzędzie ABAP Dictionary w ABAP Workbench. Gdy tworzona jest tabela, najpierw tworzony jest w ABAP Dictionary typ strukturalny i dopiero na jego podstawie tworzona jest tabela bazodanowa. bazodanowa. Dlatego lista dostępnych tabel i widoków jest widoczna w środowisku ABAP Workbench w słowniku obiektów ( Dictionary Objects), w gałęziach drzewa Database Tables oraz Views odpowiednio. Aby utworzyć tabelę należy na elemencie poddrzewa Database Tables wywołać menu kontekstowe i wybrać opcję Create. Nazwa tabeli, t abeli, tak jak nazwy innych obiektów tworzonych t worzonych przez programistę musi zaczynać się od litery Y lub Z. Dane związane z definicją tabeli są rozmieszczone na zakładkach - 49 -


widocznych na Rys. 7.1. Na pierwszej zakładce należy wypełnić pola Short Description i Delivery Class . Delivery Class Cla ss zazwyczaj ustawia się na typ A co oznacza tabelę na potrzeby aplikacji (application Table). Koniecznie jest również dokonanie ustawień dostępnych pod przyciskiem Technical Settings, w szczególności Data Class i Size Category. Szczególnie istotne jest rozsądne (nie za duże) ustawienie atrybutu Size Category, gdyż system rezerwuje odpowiednie zasoby i łatwo można doprowadzić do ich wyczerpania. wyczerpania.

Rys. 7.1. Ekran ABAP Workbench zawierający definicję tabeli w słowniku obiektów

Kolumny tabeli definiuje się na zakładce Fields. Kolumna Key pozwala na zaznaczenie, które z kolumn mają wejść do klucza głównego. Zaznaczenie atrybutu Initial… powoduje, że pole nie może być puste (odpowiednik NOT NULL w innych i nnych systemach bazodano bazodanowych). wych). Typ pola określa się jako Data element i/albo i/albo DTyp po przełączeniu na wybór typów wbudowanych. Przycisk Bulit-in type/Data element powoduje powoduje przełączanie pomiędzy wprowadzaniem obu pól. Przydatny może być przycisk Graphic (drugi przycisk po lewej stronie przycisku Technical Settings), który uruchamia narzędzie przedstawiające w sposób graficzny tabelę i jej relację z innymi tabelami. tabelami. Klucze obce definiuje się poprzez zaznaczenie pól (które wcześniej musiały zostać zdefiniowane) i uruchomienie przycisku Foregin Keys na zakładce Fields. Zaznaczone kolumny muszą być zdefiniowane poprzez Data Element . W nowo otwartym okienku w polu check table należy podać tabelę, której klucz pojawia się w bieżącej tabeli jako klucz obcy. Następnie można użyć przycisku generate proposal , aby system sam wyszukał pasujących pól, które mogą definiować relację. Aby zobaczyć zawartość tabeli należy wywołać menu kontekstowe na nazwie tabeli w drzewie obiektów i wybrać dispaly table contents.

- 50 -


Przetwarzanie danych zawartych w tabelach Przetwarzanie danych odbywa się za pomocą języka zapytań Open SQL będącego podzbiorem standardu s tandardu SQL w obszarze DML (DataManipulation ( DataManipulation Language) oraz częściowo rozszerzającym standard o nowe warianty wyrażeń. Podstawowa forma zapytania pobierającego dane z jednej bazy ma postać SELECT … FROM tab INTO … WHERE … tab jest nazwą tabeli lub widoku lub, jeżeli jest ujęty w nawiasy, jest obiektem przechowującym przechowującym nazwę tabeli lub widoku. Po INTO mogą wystąpić proste obiekty wymienione w nawiasach, np. INTO (wa_cityfrom, wa_cityto) lub tabela wewnętrzna (internal table), przy czym najłatwiej jest ją zdefiniować odwołując się do typu

związanego z tabelą. W systemie istnieje tabela systemowa spfli. Poniższy listing powoduje odczytanie jej zawartości przy warunkach określonym przez zmienną p_carrid. DATA wa_spfli TYPE spfli. SELECT * FROM spfli INTO wa_spfli WHERE carrid = p_carrid … ENDSELECT.

Inną użyteczną składnią jest INTO CORRESPONDING FIELDS OF wa_spfli , która powoduje wypełnienie tylko pól podanych po słowie SELECT. Jak widać polecenie SELECT w istocie powoduje wykonanie pętli, w której czytane są kolejne wiersze. Jednak, jeżeli zostanie użyte zapytanie pobierające jeden wiersz poprzez SELECT SINGLE, to pętla nie występuje i zapytania nie trzeba kończyć poprzez ENDSELECT. W przypadku tabeli wewnętrznej występującej po INTO można żądać odczytania całej zawartości od razu dodając po INTO słowo kluczowe TABLE. Wówczas również SELECT nie tworzy pętli i nie trzeba go kończyć poprzez ENDSELECT. Zwarty sposób przeczytania wybranych kolumn dla wszystkich wierszy może wyglądać następująco SELECT cityform cityto FROM spfli INTO CORRESPONDING FIELDS OF TABLE wa_spfli WHERE …

Słowo kluczowe INTO można zastąpić poprzez APPENDING, aby dołączyć nowe rekordy do tabeli. W części WHERE mogą być używane operatory porówniania =, <, >, <>, <=, >=, operatory logiczne AND, OR, NOT, operator zawierania IN (np. WHERE miasto IN (‘WARSZAWA’, ‘LONDYN’, ‘BERLIN’) ) oraz BETWEEN (np. WHERE a BETWEEN 10 AND 80) oraz operator LIKE. W operatorze LIKE znak % oznacza dowolny ciąg znaków, a znak _ oznacza dokładnie jeden znak. Bezpośrednio przed WHERE może wystąpić rozszerzenie FOR ALL ENTRIES tab . W tym wypadku tabela wewnętrzna tab służy do określenie warunków dla pobieranych rekordów. Po WHERE mogą również wystąpić podzapytania z wykorzystaniem operatorów IN, EXISTS lub operatorów porównania, np. - 51 -


WHERE EXISTS ( SELECT * FORM …) . Podzapytanie może zwrócić wiele wierszy, wówczas w przypadku operatorów porównania należy użyć jednego z operatorów ALL, ANY lub SOME, np. WHERE seatmax >= ALL (SELECT * FORM…) .

W części FROM mogą wystąpić złączenia tabel za pomocą INNER JOIN , LEFT OUTER JOIN. W części SELECT mogą wystąpić funkcje agregujące MIN, MAX, COUNT, SUM, AVG. Klauzula GROUP BY grupująca wiersze oraz klauzula HAVING definiująca warunki na danych zagregowanych zagregowanych mogą wystąpić po części WHERE. Wreszcie na końcu zapytania może zostać określone sortowanie poprzez klauzule ORDER BY. Modyfikacje danych są dokonywane przez wyrażenia INSERT , UPDATE, MODIFY, DELETE. Wstawienie wielu wierszy jest możliwe za pomocą składni INSERT spfli FROM TABEL spfli_tab.

W przypadku, gdy wiersz w wewnętrznej tabeli spfli_tab ma klucz główny już występujący w tabeli spfli program zostanie przerwany, chyba że w zapytaniu zostanie dodane na końcu wyrażenie ACCEPTING DUPLICATE KEYS . Wówczas wiersze powodujące duplikację klucza nie zostaną dodane. Liczbę dodanych wierszy można odczytać z obiektu systemowego sy-dbcnt. Oprócz klasycznej składni wyrażenia UPDATE możliwe jest zaktualizowanie całego wiersza (wszystkich kolumn) za pomocą składni UPDATE sflight FROM wa_sflight.

lub UPDATE sflight FROM TABLE sflight_tab.

dla wielu wierszy. Wyrażenie MODIFY ma podobną składnie do UPDATE, ale powoduje wstawienie wiersza, jeżeli w tabeli nie ma wiersza o zadanym kluczu, lub aktualizację wiersza jeżeli jest już taki w tabeli. Również wyrażenie wyrażenie DELETE oprócz standardowe st andardowejj składni posiada wersje z podobną składnią jak omówione powyżej, do usuwania jednego lub wielu wierszy na podstawie tabeli wewnętrznej. wewnętrznej.

Spójność danych nit of Spójność danych jest zachowywana dzięki dwóm mechanizmom: LUW ( Logical U nit W ork ork ) oraz blokad. LUW jest fragmentem kodu zmieniającym spójny stan danych w inny spójny stan danych. W trakcie trwania LUW chwilowy stan danych może nie być spójny. Każdy fragment LUW kończy się potwierdzeniem ( commit ) lub wycofaniem wprowadzonych wprowadzonych zmian (rollback ). ). Zarówno commit i i rollback mogą mogą być używane jawnie lub są wykonywane niejawnie. Commit jest jest wykonywany niejawnie gdy: •

•

kończy się pewien krok dialogu, np. otwierane jest j est nowe okno, sterowanie jest przekazywane do modułu wywoływanego zdalnie ( remotely-called function module ).

Rollback jest jest •

wykonywany niejawnie, gdy:

gdy wystąpi błąd w programie, - 52 -


•

gdy program jest kończony poprzez wywołanie MESSAGE typu A lub X.

Jeden LUW może obejmować kilka ekranów (tzw. SAP LUW) jeżeli operacje bazodanowe są umieszczone w funkcji lub procedurze. Moduł funkcyjny musi zostać zaznaczony jako tzw. update module w narzędziu Function Builder . Wówczas wywołanie funkcji wygląda następująco: CALL FUNCTION … IN UPDATE TASK.

Wywołanie procedury związanej z SAP LUW odbywa się w następujący sposób: PERFORM … ON COMMIT.

Kod funkcji lub procedury jest wykonywany gdy nastąpi zatwierdzenie zmian poprzez COMMIT WORK.

lub nie jest wykonywany w przypadku odwołania zmian poprzez ROLLBACK WORK.

7.2. Obsługa plików Z poziomu języka ABAP jest możliwy dostęp do plików zarówno po stronie serwera, jak i po stronie klienta. Aby uniknąć problemów z różnymi konwencjami zapisu ścieżek dostępu można zapamiętać plik jako pewien logiczny obiekt, definiowany poprzez transakcje FILE. Bieżąca ścieżka do tak zdefiniowanego pliku jest dostępna poprzez funkcje FILEGET_NAME. Podstawowe operacje na pliku po stronie serwera: •

Otwarcie pliku OPEN DATASET plik {BINARY|TEXT} MODE.

•

FOR

{OUTPUT|INPUT|APPENDING}

IN

Zamknięcie pliku CLOSE DATASET plik.

•

Zapis TRANSFER a TO plik.

W typowym zastosowaniu a jest wierszem tablicy. •

Odczyt READ DATASET plik INTO a.

W typowym zastosowaniu a jest tablicą •

Usunięcie pliku DELETE DATASET plik.

Do operacji na plikach po stronie klienta (serwera prezentacji) służą funkcje, których wywołanie może wyglądać następująco: CALL FUNCTION ‘WS_DOWNLOAD’ EXPORTING filename

= plik

- 53 -


filetype

= typ

bin_filesize

= rozmiar

TABLES data_tab

= tabela

EXCEPTIONS file_open_error file_open_err or

= 1

file_write_error file_write_er ror

= 2

invalid_filesize invalid_files ize

= 3

invalid_table_width invalid_table _width invalid_type OTHERS

= 4 = 5

= 6.

lub CALL FUNCTION ‘WS_UPLOAD’ EXPORTING filename

= plik

filetype

= typ

TABLES data_tab

= tabela

EXCEPTIONS file_open_error file_open_err or

= 1

file_write_error file_write_er ror

= 2

invalid_filesize invalid_files ize

= 3

invalid_table_width invalid_table _width invalid_type OTHERS

= 4 = 5

= 6.

- 54 -


Bibliografia 1. Adamczewski P., Zintegrowane Systemy Informatyczne w praktyce, wydanie IV rozszerzone, MIKOM, 2004. 2. Kale V., SAP R/3, Helion, 2000. Progra mming SAP Applications, 3. Keller H., Kruger S., ABAP Objects: Introduction to Programming MIKOM, 2002. 4. BC ABAP Programming, dokumentacja techniczna ABAP, SAP, 1999. 5. http://help.sap.com http://help.sap.com,, SAP Help Portal.

- 55 -

Podstawy programowania w ABAP.pdf

Recommend Documents