Transport, debugger & analysetools

01Het systeemlandschap & transporten

Custom ontwikkeling ontstaat nooit rechtstreeks in productie. Alles beweegt via transportrequests door een landschap van gescheiden systemen.

Het drie-systemen-landschap

DEV (ontwikkeling)  ──transport──►  QAS (test/kwaliteit)  ──transport──►  PRD (productie)

• DEV — hier wordt gebouwd en unit-getest. Alleen hier is de "systeemwijzigbaarheid" open.
• QAS — hier testen key-users met representatieve data; niets wordt hier handmatig gewijzigd.
• PRD — live. Wijzigingen komen uitsluitend binnen via geïmporteerde transporten.
• Grotere organisaties voegen systemen toe (sandbox, pre-productie); het principe blijft gelijk.

Transportrequests — SE09/SE10

• Een workbench request bevat repository-objecten (programma's, classes, tabeldefinities) en is client-onafhankelijk; een customizing request bevat instellingen en is client-afhankelijk.
• Een request bestaat uit één of meer taken (per ontwikkelaar). Volgorde: taak vrijgeven → request vrijgeven → basis/beheer importeert in het volgende systeem (transactie STMS).
• Na vrijgave is een request onveranderlijk — een vergeten object betekent een nieuw (vervolg)transport. Importvolgorde is belangrijk: een later request met dezelfde objecten overschrijft een eerder.
• Zolang een object in een openstaande taak zit, is het gelockt voor andere ontwikkelaars.

Packages, naamruimte & herkenning van maatwerk

• Alle klantobjecten beginnen met Z of Y: ZCL_... (class), ZTABEL, Z_FUNCTIE. Grote partners/klanten hebben soms een eigen geregistreerde naamruimte zoals /FIRMA/.
• Elk object hoort bij een package (ontwikkelklasse), meestal per team of functioneel domein; het package bepaalt via zijn transportlaag waarheen getransporteerd wordt.
• Package $TMP = lokale objecten: die worden nooit getransporteerd — prima voor wegwerp-testprogramma's, fout voor echte ontwikkeling.

02De ABAP-debugger

Het belangrijkste gereedschap om te begrijpen wat code écht doet. De nieuwe (two-process) debugger opent in een apart venster en kan alles inspecteren wat leeft: variabelen, interne tabellen, objecten, de call stack.

Starten

Navigeren

• Variabelen — dubbelklik een variabelenaam of typ hem in het variabelenpaneel; structuren en interne tabellen opent de tabelweergave. Waarden zijn wijzigbaar (potlood-icoon) — nuttig bij testen, gevaarlijk in productie.
• Watchpoint — stopt automatisch zodra een variabele wijzigt of een voorwaarde waar wordt (bijv. lv_matnr = '4711'). Onmisbaar bij de vraag "wie zet dit veld?"
• Breakpoint at statement — stoppen bij elk MESSAGE, COMMIT WORK of SELECT, waar dan ook. Zo vind je bijvoorbeeld welk stuk code een foutmelding geeft.
• Call stack — het tabblad met de aanroepketen: hoe ben ik hier beland? Klikken springt naar dat niveau, inclusief de variabelen daar.
• sy-subrc en sy-tabix live volgen na elke SELECT/READ/ASSIGN — zie systeemvelden.
• Debuggen van achtergrondjobs — in SM37: job selecteren en JDBG in het commandoveld typt de job na afloop opnieuw in de debugger; een lopende job vang je via SM50 → Beheer → Programma → Debuggen.

03ST22 — runtime-dumps lezen

Crasht een programma, dan ontstaat een short dump. Transactie ST22 toont ze; leren dump-lezen bespaart uren debuggen.

Een dump is opgebouwd uit vaste secties — de nuttigste:

• Categorie & runtime-fout — de foutklasse, bijv. CX_SY_ITAB_LINE_NOT_FOUND (tabelexpressie vond geen rij) of CX_SY_ZERODIVIDE.
• Korte tekst / Wat is er gebeurd — leesbare samenvatting.
• Hoe te corrigeren — vaak verrassend concrete aanwijzingen, inclusief het advies een TRY/CATCH toe te voegen (zie exceptions).
• Broncode-uittreksel — de exacte regel waar het misging, gemarkeerd met >>>>>.
• Inhoud van systeemvelden & variabelen — de waarden op het moment van de crash.
• Actieve aanroepen/stack — de call stack, net als in de debugger.

04ST05 — SQL-trace

De performance trace registreert elke database-aanroep van een gebruiker: welk statement, op welke tabel, hoe vaak en hoe lang. Hét gereedschap voor "waarom is dit traag?" én voor "welke tabel zit achter dit scherm?"

1. ST05 → trace aanzetten (evt. gefilterd op gebruiker).
2. De trage transactie/het programma uitvoeren.
3. Trace uitzetten en weergeven.

In het resultaat let je op:

• Identieke SELECT's die honderden keren voorkomen — een SELECT binnen een LOOP; oplossing: één set-georiënteerde SELECT met FOR ALL ENTRIES of een join, zie SQL-performance.
• Lange uitvoeringstijden per statement — vaak een ontbrekende index of een WHERE zonder sleutelvelden; de knop "Explain" toont het toegangsplan van de database.
• De aanroepende coderegel — dubbelklik springt rechtstreeks naar het ABAP-statement.

SAT — runtime-analyse

Waar ST05 alleen database-tijd meet, meet SAT (opvolger van SE30) alles: welke methods en FORM's hoeveel tijd kosten, inclusief aanroephiërarchie. Vuistregel: is in SAT het aandeel "database" hoog, ga dan naar ST05; is "ABAP" hoog, zoek dan naar dure lussen (bijv. geneste loops over grote interne tabellen — daar helpt een SORTED/HASHED-key).

05Codekwaliteit: syntaxcheck, Code Inspector & ATC

Drie lagen van geautomatiseerde controle, van licht naar zwaar.

Bij S/4HANA-migraties draait ATC met speciale checkvarianten die incompatibele code vinden (vervallen tabellen, gewijzigde veldlengtes) — zie ook ABAP Cloud, waar ATC bepaalt welke API's je überhaupt mag gebruiken. In veel organisaties is een schone ATC-run een harde voorwaarde voor transportvrijgave.

ABAP Unit — geautomatiseerde tests

Unittests schrijf je als lokale testclasses bij een class; ze draaien met Ctrl+Shift+F10 en in centrale ATC-runs mee. Zie ABAP Unit voor de opbouw met FOR TESTING en CL_ABAP_UNIT_ASSERT.

06Versiebeheer & vergelijken

ABAP heeft ingebouwd versiebeheer per object — geen git, maar wel volledig.

• Versiehistorie — in de editor: Hulpmiddelen → Versies → Versiebeheer. Elke transportvrijgave bevriest een versie; je kunt elke twee versies regel-voor-regel vergelijken en oudere versies terughalen.
• Vergelijken tussen systemen — dezelfde vergelijking werkt remote: DEV-versie naast PRD-versie, dé manier om "in productie staat iets anders"-vermoedens te bevestigen.
• Wie heeft dit gewijzigd? — de versielijst toont per versie gebruiker, datum en transportnummer; via SE09 zie je vervolgens wat er verder in dat transport zat.
• abapGit — open-sourcebrug tussen de ABAP-repository en git; steeds gangbaarder voor gedeelde bibliotheken en ABAP-Cloud-ontwikkeling.

Eclipse / ADT

De ABAP Development Tools in Eclipse zijn de moderne ontwikkelomgeving: snellere navigatie (Ctrl+klik), refactoring (hernoemen, method extraheren), quick fixes, en de enige plek waar je CDS-views en RAP-objecten kunt bewerken. SE80/SE38 in de GUI blijven bestaan, maar nieuwbouw gebeurt in toenemende mate in ADT.