Lijsten, ALV & gebruikersinterfaces

01Klassieke lijsten met WRITE

De oudste vorm van output: regels rechtstreeks naar het scherm schrijven. In nieuwbouw zie je dit nauwelijks nog, maar in bestaande reports kom je het constant tegen — en voor snelle testoutput is het nog altijd het snelste gereedschap.

WRITE: / 'Materiaal:', lv_matnr,
       / 'Omschrijving:', lv_maktx.

WRITE: /5 lv_veld,            " begin op kolom 5
       20 lv_ander COLOR 3.   " op kolom 20, met kleur

ULINE.                         " horizontale lijn
SKIP 2.                        " twee lege regels
NEW-PAGE.                      " nieuwe pagina

• De / betekent: begin op een nieuwe regel. Zonder / komt de output achter de vorige waarde.
• Getallen achter de slash of los (/5, 20) zijn kolomposities.
• Elk WRITE-report krijgt automatisch een interactieve lijst: dubbelklikken op een regel activeert het event AT LINE-SELECTION, waarmee je "drill-down"-lijsten kunt bouwen. De inhoud van de aangeklikte regel lees je via sy-lisel of eerder verborgen velden met het HIDE-statement.
• TOP-OF-PAGE en END-OF-PAGE (zie report-events) verzorgen kop- en voetregels.

02ALV — de drie generaties

ALV (ABAP List Viewer) is dé standaardmanier om tabeldata te tonen: de gebruiker krijgt gratis sorteren, filteren, subtotalen, layout-varianten opslaan en exporteren naar Excel. Er bestaan drie generaties die je alle drie in bestaande code tegenkomt.

Generatie 1 — REUSE_ALV_GRID_DISPLAY

Het klassieke patroon: je bouwt zelf een fieldcatalog (kolomdefinities: veldnaam, kolomkop, breedte, som-vlag) en geeft die samen met je datatabel aan de functiemodule:

DATA: lt_fieldcat TYPE slis_t_fieldcat_alv,
      ls_layout   TYPE slis_layout_alv.

" fieldcatalog automatisch afleiden van een DDIC-structuur:
CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'
  EXPORTING i_structure_name = 'MARA'
  CHANGING  ct_fieldcat      = lt_fieldcat.

ls_layout-zebra             = 'X'.
ls_layout-colwidth_optimize = 'X'.

CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
  EXPORTING
    is_layout   = ls_layout
    it_fieldcat = lt_fieldcat
  TABLES
    t_outtab    = lt_data.

Generatie 3 — CL_SALV_TABLE (aanbevolen)

De moderne, object-georiënteerde aanpak (zie classes). De fieldcatalog wordt volledig automatisch afgeleid van het tabeltype:

DATA lo_alv TYPE REF TO cl_salv_table.

TRY.
    cl_salv_table=>factory(
      IMPORTING r_salv_table = lo_alv
      CHANGING  t_table      = lt_data ).

    " standaard-toolbar (sorteren, filteren, export) aanzetten:
    lo_alv->get_functions( )->set_all( abap_true ).

    " kolomkop aanpassen:
    lo_alv->get_columns( )->get_column( 'MATNR' )->set_short_text( 'Materiaal' ).

    " zebra-strepen en geoptimaliseerde kolombreedte:
    lo_alv->get_display_settings( )->set_striped_pattern( abap_true ).
    lo_alv->get_columns( )->set_optimize( abap_true ).

    lo_alv->display( ).
  CATCH cx_salv_msg cx_salv_not_found INTO DATA(lx_err).
    MESSAGE lx_err TYPE 'E'.
ENDTRY.

• Events — dubbelklik, hotspot-klik en toolbar-knoppen handel je af door een handler-methode te registreren op lo_alv->get_event( ), zie OO-events.
• Beperking — SALV is in de standaard alleen-lezen. Voor een bewerkbare grid gebruik je CL_GUI_ALV_GRID (generatie 2) of, in S/4HANA-nieuwbouw, een Fiori-app op basis van RAP.
• Varianten — gebruikers kunnen hun eigen kolomindeling opslaan als layout-variant; met lo_alv->get_layout( ) sta je dat toe en geef je een opslagsleutel mee.

Generatie 2 — CL_GUI_ALV_GRID in het kort

Deze variant tekent de grid in een container op een klassiek scherm. Je herkent hem aan CREATE OBJECT lo_container ... EXPORTING container_name = 'CC_ALV' gevolgd door lo_grid->set_table_for_first_display( ). Hij ondersteunt bewerkbare cellen, drag & drop en geneste grids — tegen de prijs van beduidend meer code en een verplicht eigen dynpro.

03Dynpro's — klassieke schermen

Een dynpro (DYNamic PROgram) is een klassiek SAP GUI-scherm: het schermontwerp plus de flow-logica eromheen. Vrijwel elke standaardtransactie in ECC bestaat uit dynpro's. Zelf bouw je ze zelden nog, maar je moet de structuur herkennen om standaardcode en oudere custom transacties te kunnen volgen.

PBO en PAI — de twee helften

Elk dynpro heeft twee event-blokken in de bijbehorende module pool (programmatype SAPMZ..., zie programmatypen):

" in de screen flow logic (schermeditor SE51):
PROCESS BEFORE OUTPUT.
  MODULE status_0100.

PROCESS AFTER INPUT.
  MODULE user_command_0100.

" in de module pool (ABAP):
MODULE user_command_0100 INPUT.
  CASE sy-ucomm.               " de door de gebruiker gekozen functiecode
    WHEN 'SAVE'.  PERFORM opslaan.
    WHEN 'BACK'.  LEAVE TO SCREEN 0.
  ENDCASE.
ENDMODULE.

• sy-ucomm (of het OK-code-veld) bevat de functiecode van de ingedrukte knop.
• Schermvelden zijn gekoppeld aan gelijknamige globale variabelen in het programma — de dataoverdracht scherm ↔ programma gebeurt automatisch op naam.
• CALL SCREEN 0100. start een scherm; LEAVE TO SCREEN 0 keert terug.
• Tabellen op een scherm heten table controls; per zichtbare rij draait een LOOP AT ... WITH CONTROL in zowel PBO als PAI.

Selectieschermen zijn ook dynpro's

Het selectiescherm van een report (PARAMETERS/SELECT-OPTIONS, zie selectieschermen) is technisch dynpro nummer 1000, dat ABAP automatisch voor je genereert. Vandaar dat je het met dezelfde events (AT SELECTION-SCREEN) kunt beïnvloeden.

04Fiori & SAPUI5 — de moderne interface

In S/4HANA is SAP Fiori de standaardinterface: webgebaseerde apps als tegels in de Fiori Launchpad. Als ABAP-ontwikkelaar bouw je meestal niet de frontend zelf, maar wél de services eronder.

• SAPUI5 — SAP's JavaScript-framework (open-sourcevariant: OpenUI5) waarin Fiori-apps gebouwd zijn. Model-View-Controller, met XML-views en JavaScript-controllers.
• OData — het HTTP-protocol waarmee de UI5-frontend met de ABAP-backend praat, zie OData-services.
• Fiori Elements — apps die niet handmatig geprogrammeerd worden maar gegenereerd uit CDS-views met UI-annotaties: de annotaties beschrijven welke velden in de lijst, het filter en het detailscherm komen. De meeste nieuwe standaard-apps van SAP werken zo.
• App-typen — grofweg drie soorten Fiori-apps: transactional (iets aanmaken/wijzigen), analytical (KPI's, grafieken) en fact sheets/object pages (alles over één object bekijken).

05Formulieren: SAPscript, Smart Forms & Adobe Forms

Voor afdrukbare documenten — orderbevestigingen, facturen, pakbonnen, etiketten — kent SAP drie generaties formuliertechnologie. Alle drie draaien ze nog volop in productie.

" typisch Smart Forms-patroon:
DATA lv_fmname TYPE rs38l_fnam.

CALL FUNCTION 'SSF_FUNCTION_MODULE_NAME'
  EXPORTING  formname           = 'ZSF_FACTUUR'
  IMPORTING  fm_name            = lv_fmname
  EXCEPTIONS no_form            = 1
             no_function_module = 2
             OTHERS             = 3.

CALL FUNCTION lv_fmname          " dynamische aanroep!
  EXPORTING is_kop    = ls_kop
  TABLES    it_regels = lt_regels
  EXCEPTIONS OTHERS   = 1.

Waarom die omweg via SSF_FUNCTION_MODULE_NAME? De gegenereerde functiemodulenaam (/1BCDWB/SF00000123) verschilt per systeem — DEV, QAS en PRD genereren elk hun eigen nummer. De opzoekfunctie maakt de aanroep transporteerbaar.

Uitvoerbepaling (output determination)

Welk formulier bij welke bedrijfsgebeurtenis wordt afgedrukt, regelt in ECC de berichtsturing (NAST/condition technique) en in S/4HANA aanvullend Output Management (BRF+). In maatwerk herken je dit aan verwerkingsroutines: FORM-routines (zie subroutines) in een Z-programma die per uitvoersoort in customizing zijn geregistreerd, met de vaste parameters ENT_RETCO en ENT_SCREEN.