Best Practice Leitfaden Development - DSAG

Vorteil:
> deutliche steigerung der Flexibilität
> Beispiel 1: eigener aufbau von user exits
durch die statische definition einer abstrakten Klasse inkl. Methodensignatur wird das Grund-
gerüst für einen „user exit“ vorgegeben. anschließend können mehrere konkrete impleme-
tierungen dieser abstrakten Klasse angelegt werden. innerhalb Quellcodes wird z.B. aus einer
Customizing-tabelle der name der zu verwendenden konkreten Klassenimplementierung
gelesen und diese aufgerufen. somit können unterschiedliche implementierungsvarianten
per Customizing aktiviert/deaktiviert werden.
> Beispiel 2: dynamische WHere-Bedingung
nachteil:
zur Laufzeit wird die WHere-Bedingung für eine datenbankoperation, z.B. seLeCt, in einer
string-Variablen erstellt. dadurch können komplizierte Case-abfragen vermieden werden,
die abhängig von den eingaben verschiedene osQL-Befehle ausführen.
> durch die nutzung von dynamischen aufrufen geht der Verwendungsnachweis innerhalb der aBaP-
entwicklungsumgebung verloren. Problematisch sind dann Änderungen an den aufrufzielen. ein
entwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der von
einem Programm dynamisch aufgerufen wird, bemerkt diese Verwendung über den Verwendungs-
nachweis nicht.
> Bei der dynamischen Programmierung ist i.d.r. zur designzeit keine syntaktische Prüfung möglich;
bei fehlerhafter Belegung der variablen inhalte (z.B. fehlerhafte Klammerung innerhalb einer
dynamischen WHere-Klausel, fehlerhafter name einer Klasse) kommt es zu einem ungeplanten
abbruch des Programms (Kurzdump).
> dynamische Programmierung birgt hohe sicherheitsrisiken, insbesondere dann, wenn die dynamischen
inhalte durch ungeschützten zugriff beeinflussbar sind (z.B. wenn der name einer aufzurufenden
Klasse /eines Funktionsbausteins oder einer WHere-Bedingung durch Benutzereingaben beein-
flusst werden kann, stichwort: Code injection).
BEST PRACTICE: dynamische Programmierung sollte nur sehr dosiert und kontrolliert zum einsatz
kommen. Programmcode, der dynamische anteile enthält, sollte nach dem Vier-augen-Prinzip
kontrolliert und dokumentiert werden, denn er stellt ein potenzielles sicherheitsrisiko dar.
im Kapitel 5.2 wird das thema dynamische Programmierung auch im Kontext sicherheit behandelt.
11
Best Practice Leitfaden deveLoPment, 31. Januar 2013, © dsaG e. v.