www.jaros.in

Z toho, co jsem o ABAPu řekl minule, by se možná mohlo zdát, že programovat v něm dokáže každý, kdo alespoň trochu ovládá angličtinu. Není to tak docela pravda. ABAP je sice docela přístupný programovací jazyk; i neprogramátor v něm zvládne sesmolit nějaký ten report, ale k jeho plnému zvládnutí a využití všech pokročilejších programovacích technik, které nabízí, je přece jen zapotřebí o trochu více fištrónu. Především znalost jiného programovacího jazyka je pro začínajícího abapistu velkou výhodou. Ne snad, že by byl ABAP náročný na pochopení, ale jeho nadměrná rozvláčnost a velké množství příkazů (a jejich variant) by mohly potenciálního adepta od programování spíše odradit.

Já se však musím pochlubit, že mi ABAP přešel do krve poměrně snadno a rychle, protože jsem měl předchozí zkušenosti s Object Pascalem (Delphi), JavaScriptem a částečně také s PHP. Věděl jsem, co od jazyka chtít a znal jsem způsoby, jak toho obecně dosáhnout. Řada věcí je v ABAPu identická se zmíněnými programovacími jazyky, najdou se však i výjimky a není jich zrovna málo.

Interní tabulka jako náhrada za pole (array)

Jedna z věcí, která mě na ABAPu zarazila, je nemožnost deklarovat proměnné typu array, tedy pole. Poznámka pod čarou: S termínem pole je třeba zacházet opatrně, protože v terminologii ABAPu pole nerovná se array, nýbrž field, tzn. „single“ proměnná, která je součástí struktury či tabulky. Pojem pole je tedy v ABAPu chápán spíše v databázovém kontextu, zatímco pole ve významu array v ABAPu vůbec neexistuje. Je to však absence pouze zdánlivá, která trvá jen do chvíle, než si uvědomíte, že místo polí - array - jsou v ABAPu interní tabulky. Že v tom máte tak trochu hokej? Nic si z toho nedělejte, já na tom byl zpočátku úplně stejně.

Interní tabulku lze chápat jako dvourozměrné pole (array), avšak práce s ní je oproti poli (array) poněkud odlišná. Dáme si raději příklad, abychom si v tom udělali trochu jasno:

DATA: BEGIN OF my_table OCCURS 10,
        field_1 TYPE STRING,
        field_2 TYPE STRING,
        field_3 TYPE STRING,
      END OF my_table.

Touto deklarací jsme získali interní tabulku o třech polích a deseti řádcích. Počet řádků v deklaraci interní tabulky téměř nehraje roli, protože se vymezený prostor v paměti přizpůsobuje dynamicky tak, jak řádky přidáváme (INSERT, APPEND) nebo ubíráme (DELETE). Co když však potřebujeme pole (array) vícerozměrné (tedy více než dvourozměrné)? Žádný problém - každé pole (field) v interní tabulce může být zároveň také tabulkou (tuším, že je povoleno asi 12 úrovní zanoření).

Přístup k datům interní tabulky je realizován příkazy LOOP a READ. LOOP je v podstatě cyklus, který umožňuje sekvenční čtení tabulky po jednotlivých řádcích, Příkaz READ potom dovoluje přečíst konkrétní záznam v tabulce, buď přes index řádku, nebo podmínku (WHERE). Aby to však nebylo tak jednoduché, k datům interní tabulky není možné přistupovat přímo, ale pouze přes tzv. hlavičkový řádek (HEADER LINE), neboli pracovní oblast. Tím, že jsme v deklaraci tabulky uvedli dovětek WITH HEADER LINE, jsme docílili toho, že tabulka bude mít automaticky hlavičkový řádek (se stejným názvem, jaký má tabulka sama), do nějž se budou načítat data. Z výše uvedené deklarace vyplývá, že tabulka my_table má automaticky implicitní hlavičkový řádek (syntaxe ABAPu už je prostě taková).

Dejme si opět příklad. Nejprve si naplníme tabulku daty a poté je budeme číst:

my_table-field_1 = ‘Ahoj’.
my_table-field_2 = ‘Nazdar’.
my_table-field_3 = ‘Čau’.
APPEND my_table TO my_table.

LOOP AT my_table INTO my_table.
  WRITE: / my_table-field_1, ‘,’, my_table-field_2, ‘,’, my_table-field_3.
ENDLOOP.

READ TABLE my_table INTO my_table INDEX 1.

READ TABLE my_table INTO my_table WHERE field_1 = ‘Ahoj’ OR field_2 = ‘Nazdar’.

Jelikož překladač ví, že tabulka má hlavičkový řádek je možné (a výhodné) používat zkrácenou syntaxi příkazů:

APPEND my_table.

LOOP AT my_table.
  …
ENDLOOP.

READ TABLE my_table INDEX 1.
…

Stinnou stránkou uvedeného zápisu je to, že v něm začátečníci často tápají a bývá pro ně (vzhledem ke shodným názvům) obtížné uvědomit si rozdíl mezi interní tabulkou a jejím hlavičkovým řádkem.

V některých případech však potřebujeme překladač upozornit na to, že má pracovat s interní tabulkou a ne s jejím hlavičkovým řádkem. Ukažme si to na příkladu - mějme druhou interní tabulku se stejnou strukturou, jakou má tabulka my_table:

DATA: second_table LIKE my_table OCCURS 10 WITH HEADER LINE.

Pozor! Povšimněte si, že zde už je nutné v deklaraci výslovně úvést dovětek WITH HEADER LINE, jinak by překladač při čtení tabulky nemilosrdně ohlásil syntax error!

Nyní chceme přiřadit obsah interní tabulky my_table tabulce second_table. Jak toho docílit, aniž by se zkopíroval pouze obsah hlavičkového řádku? Jednoduše, stačí za název interní tabulky doplnit hranaté závorky [] a překladač už bude vědět:

second_table[] = my_table[].

Nebo ekvivalentně, více po abapovsku:

MOVE my_table[] TO second_table[].

Aby byl výklad o interních tabulkách úplný, je třeba ještě zmínit, že hlavičkový řádek nemusí být vždy definován pomocí deklarace WITH HEADER LINE, ale může též v programu existovat jako samostatná struktura (tedy jednorozměrné pole - array), zcela nezávisle na interní tabulce, třeba nějak takhle:

DATA: my_line LIKE my_table.

Pak ovšem přijdeme o možnost zkráceného zápisu, a musíme hlavičkový řádek vždy explicitně uvádět:

LOOP AT my_table INTO my_line.
  WRITE: / my_line-field_1, ‘,’, my_line-field_2, ‘,’, my_line-field_3.
ENDLOOP.

Na druhou stranu z výše uvedeného zápisu je pro začátečníka mnohem snáze pochopitelné, co se v programu děje. Já jsem si však zvykl na implicitní hlavičkové řádky, a pokud můžu, tak je používám. SAP vývojáři se však se zavedením objektově orientovaného přístupu rozhodli, že implicitní hlavičkové řádky už nebudou nadále podporovat, a tudíž je není možné používat v OO kontextu.

Tak to bychom pro dnešek měli. Myslím si, že jako úvod do interních tabulek je to více než dostačující. Samozřejmě je tu ještě spousta věcí, které jsem o interních tabulkách neprozradil (např. jak se pracuje se setříděnými a hashovacími tabulkami, jaký význam mají unikátní a neunikátní klíče, jak funguje binární prohledávání interních tabulek apod.), ale není možné v jednom článku postihnout vše. Více informací lze ostatně dohledat v SAP nápovědě.

Přiznám se, že jsem teď tak trochu na rozpacích, zda mám v dalším článku pokračovat ve výkladu ABAPu nebo se vrátit zpět k odlehčenému stylu, ve kterém jsem tento seriál započal. Asi bude nejrozumnější, když se zaměřím pouze na některé zajímavé rysy ABAPu, protože kdybych měl vysvětlit všechno, tak by se zamýšlený seriál brzy proměnil v brazilskou telenovelu.

Související

• Jak jsem začínal se SAPem - 1. část
• Jak jsem začínal se SAPem - 3. část