Best Practice Leitfaden Development - DSAG

Best Practice Leitfaden Development 

Praxistipps rund um das Thema ABAP Development 

Deutschsprachige SAP-Anwendergruppe e.v. 

DSAG-ArbeitSkreiS SAP NetWeAver DeveloPmeNt 

StAND 31. JANuAr 2013

2 

Best Practice Leitfaden development 

Praxistipps rund um das thema aBaP development 

Version 0.11 

stand 31. Januar 2013 

dsaG e. V. 

deutschsprachige saP-anwendergruppe

autoren 

> Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH 

> steffen Pietsch, Vice President, iBsolution GmbH 

> Markus theilen, it-Koordinator, eWe aG 

> Jürgen Wachter, Process Coordinator development, comgroup GmbH 

> Michael Werner, saP anwendungsberater (inhouse), Lts aG andernach 

> andreas Wiegenstein, Managing director und Chief technology officer (Cto), Virtual Forge GmbH 

Weitere informationen zu den autoren finden sie auf seite 57. 

© CoPyriGHt 2013 dsaG e.V. 

HinWeis: 

die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). alle rechte liegen, soweit 

nicht ausdrücklich anders gekennzeichnet bei: 

deutsCHsPraCHiGe saP ® anWenderGruPPe e.V. 

altrottstraße 34 a 

69190 Walldorf 

deutschland 

tel.: 06227 - 35809 58 

Fax: 06227 - 35809 59 

e-Mail: info@dsag.de 

internet: www.dsag.de 

Jedwede unerlaubte Verwendung ist nicht gestattet. dies gilt insbesondere für die Vervielfältigung, 

Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen systemen / digitalen 

Medien. 

3 

Best Practice Leitfaden deveLoPment, 31. Januar 2013, © dsaG e. v.

4 

inHaLtsVerzeiCHnis 

1 einLeitunG 7 

1.1 Motivation 7 

1.2 Positionierung 7 

2 ProGraMMierriCHtLinien 8 

2.1 namenskonvention 8 

2.2 namensraum 8 

2.3 einheitlicher und lesbarer Quellcode: Pretty Printer 9 

2.4 obsolete anweisungen 12 

2.5 syntax-Check und Code inspector 12 

2.6 Feste Codierung: Keine „magic numbers“ 13 

2.7 tipps beim arbeiten mit transporten 13 

2.8 Berechtigungsprüfung im Quellcode 14 

2.9 Programmiermodell: objektorientiert vs. prozedural 14 

2.10 Weitere Quellen (Programmierrichtlinien/aBaP) 14 

3 PerForManCe 15 

3.1 Vermeidungsprinzip 15 

3.2 Vorhandene Werkzeuge nutzen 15 

3.3 Performance-optimierungen nur an kritischen und relevanten stellen 16 

3.4 datenmodell und datenzugriff 16 

3.4.1 datenmodell und indizes 16 

3.4.2 rahmenbedingungen bei datenbankzugriffen 17 

3.4.3 datenbankzugriffe 18 

3.5 interne tabellen und referenzen 19 

3.5.1 Feldsymbole 21 

3.5.2 Parameterübergabe 21 

3.6 Weiterführende Quellen 21 

4 roBustHeit 22 

4.1 Fehlerbehandlung 22 

4.1.1 sy(st)-suBrC-Prüfungen 22 

4.1.2 MessaGe-anweisung 23 

4.1.3 Klassenbasierte ausnahmen 23 

4.1.4 nicht behandelbare ausnahmen 24 

4.2 Korrekte implementierung von datenbank-Änderungen 24 

4.2.1 sperrobjekte 24 

4.2.2 Verbuchungskonzept 24 

4.3 Protokollierung 26 

4.4 Praxisbeispiele 26

4.4.1 unvollständige Fallunterscheidungen 26 

4.4.2 Wichtige sonstige sy(st)-suBrC-Prüfungen 27 


5 aBaP-siCHerHeit und CoMPLianCe 28 

5.1 Prüfungsrelevante sicherheitsmechanismen im saP-standard 28 

5.1.1 Berechtigungsprüfung (a) 28 

5.1.2 Mandantentrennung (B) 28 

5.1.3 nachvollziehbarkeit (C) 29 

5.1.4 dreisystemlandschaft (d) 29 

5.1.5 Kontrollierte ausführung von Betriebssystemkommandos (e) 29 

5.1.6 Kontrollierte ausführung von sQL-Befehlen (F) 29 

5.2 sicherheitsschwachstellen 30 

5.3 Compliance-Probleme durch aBaP 31 

5.4 testwerkzeuge 32 


6 doKuMentation 34 

6.1 dokumentation unabhängig von entwicklungsobjekten 34 

6.2 dokumentation von entwicklungsobjekten 35 

6.3 dokumentation im Quelltext 35 

6.3.1 dokumentation und Kommentierung von anweisungen/anweisungsblöcken 35 

6.3.2 dokumentation von Änderungen 36 

6.3.3 Programmkopf 36 

7 uMsetzBarKeit und durCHsetzBarKeit 38 

7.1 umsetzbarkeit 38 

7.1.1 Motivation für einen Prozess 38 

7.1.2 erstellung und Pflege des Prozesses 39 

7.2 durchsetzbarkeit 40 

7.2.1 Manuelle Prüfungen 40 

7.2.2 automatische Prüfungen 41 

7.2.3 Werkzeuge 42 

7.3 erfahrungen und tipps aus der Praxis 42 

7.3.1 Qualitätssicherung des Quellcodes 42 

7.3.2 zeit und Budget Qa 43 

7.3.3 Probleme 43 

7.3.4 entscheidungsfindung bei Modifikationen 44 

7.3.5 erfahrungsbericht aus der Praxis: Comgroup GmbH 44 

5 


6 

inHaLtsVerzeiCHnis 

8 inFrastruKtur und LiFeCyCLe ManaGeMent 46 

8.1 infrastruktur 46 

8.1.1 sandbox 46 

8.1.2 entwicklungssystem 46 

8.1.3 Qualitätssicherungssystem 46 

8.1.4 Produktion 47 

8.1.5 transportwesen 47 

8.1.6 rückbau von neuentwicklungen 48 

8.1.7 sicherstellung der Konsistenz von neuentwicklungen/erweiterungen 48 

8.2 Change Management 49 

8.3 softwarewartbarkeit 52 

8.4 anpassungen der saP-Funktionalität 52 

8.5 testbarkeit von anwendungen 55 

9 die autoren 57 

10 anHanG: naMensKonVentionen 58 

10.1 allgemeine namenskonventionen 58 

10.2 attribute 59 

10.3 Methoden 60 

10.4 signatur von Methoden 60 

10.5 Funktionsgruppen und -bausteine 60 

10.6 enhancements 61 

10.7 Formulare 61 

10.8 Jobs 61 

10.9 datenelemente 62

1 einLeitunG 

saP-software zeichnet sich als standardsoftware durch ein hohes Maß an Flexibilität und erweiter- 

barkeit aus. in nahezu allen unternehmen, die saP-software einsetzen, finden sich kundenspezifische 

anpassungen und ergänzungen. die saP-software unterliegt damit sowohl auf Hersteller- 

als auch auf Kundenseite der kontinuierlichen anpassung und erweiterung an sich wandelnde 

Kundenbedürfnisse. 

das hohe Maß an Flexibilität und erweiterbarkeit von saP-software bringt Vor- und nachteile mit 

sich: die software kann optimal an kundenspezifische anforderungen angepasst und damit die Wertschöpfung 

durch den einsatz deutlich gesteigert werden. zeitgleich birgt die erweiterbarkeit das 

risiko kundenspezifischer entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind. 

das ziel dieses dokuments ist es, Praxistipps und denkanstöße zu liefern, um kundenspezifische 

entwicklungen wartbar und effizient zu gestalten. 

1.1 MotiVation 

die arbeit der deutschsprachigen saP-anwendergruppe e.V. (dsaG) fußt auf drei säulen – Wissens- 

vorsprung, einflussnahme und netzwerk. das vorliegende dokument wurde von Mitgliedern des 

dsaG-arbeitskreises saP netWeaver development initiiert und adressiert die erste säule und damit 

den Wissensvorsprung für anwender und Partner. 

als autorenteam ist es unser anliegen, das in den unternehmen verteilt und implizit vorliegende 

Wissen zum thema entwicklung in einem kompakten dokument anderen dsaG-Mitgliedern zur 

Verfügung zu stellen. unser Wunsch ist, dass dieses dokument „lebt“ und mit ihrem erfahrungsschatz 

einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf ihr Feedback (am besten 

per e-Mail an handlungsempfehlung@dsag.de)! 

1.2 PositionierunG 

es existieren bereits von der saP und einer ganzen reihe von Fachverlagen sehr gute Publikationen 

zu anwendungsentwicklung und erweiterung der saP-Plattform. insbesondere haben auch 

autoren der saP mit dem Buch „aBaP-Programmierrichtlinien“, saP Press 2009 bereits einen 

Vorstoß in richtung von empfehlungen unternommen, die über reine Beschreibungen der sprache 

aBaP und der zugehörigen Werkzeuge hinausgehen. 

der Mehrwert dieses dokuments liegt in der zusammenfassung bewährter Vorgehensweisen, 

Praxistipps und erprobter regelwerke aus den anwenderunternehmen. diese Guideline soll ihnen 

als anwender, entwickler, entwicklungs-, Projekt- oder it-Leiter anregungen und Hilfestellung 

geben, um „das rad nicht immer wieder neu erfinden zu müssen“, sondern auf die erfahrungen 

anderer aufbauen zu können. dabei erheben die in dieser Guideline vorgestellten empfehlungen 

nicht den anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eine 

auswahl von Praxistipps dar. 

als autorenteam haben wir uns darum bemüht, im spannungsfeld zwischen Überblickswissen und 

detailtiefe den richtigen Mix zu finden. daher verweisen wir an entsprechenden stellen auf weiter- 

führende Quellen, um nicht ausführlich diskutierte themen redundant wiederzugeben. die erste auf- 

lage dieser Guideline ist auf den Bereich aBaP-entwicklung fokussiert. Bei entsprechendem 

Feedback und ihrer aktiven unterstützung kann der Fokus auf die JaVa-entwicklung und weitere 

themen ausgeweitet werden. 

7 


8 

2 ProGraMMierriCHtLinien 

dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für anwendungen, die 

mit Hilfe der Programmiersprache aBaP erstellt werden. es wird beschrieben, wie mit standardsaP-Mitteln 

und disziplin sauber lesbarer und verständlicher aBaP Code entwickelt werden kann. 

dies erleichtert die Wartung des Codes bzw. ermöglicht, dass verschiedene interne und externe 

Personen effizient an der (Weiter-) entwicklung und Wartung eines Programms zusammenarbeiten. 

2.1 naMensKonVention 

namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung von 

softwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur Benennung von objekten im 

Quellcode (z.B. Variablen). 

Wir empfehlen ausdrücklich eine namenskonvention als richtlinie für entwicklungen im saP- 

system vorzugeben. das ziel der Verwendung einer einheitlichen namenskonvention ist die 

deutliche steigerung der Wartbarkeit kundenspezifischer anpassungen und erweiterungen. in der 

Konsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnelleren 

Problemlösung im Fehlerfall. 

die explizit formulierte namenskonvention sollte Bestandteil der internen ausbildung sein, um 

neue Mitarbeiter mit den Grundregeln und unternehmensspezifika vertraut zu machen. zudem hat 

es sich bewährt, diese namenskonvention zum Vertragsgegenstand für externe entwickler und 

Partnerunternehmen zu machen. automatisierte Überprüfungen stellen die einhaltung sicher (vgl. 

Kapitel 7). 

BEST PRACTICE: eine exemplarische namenskonvention als Vorlage finden sie im anhang. 

2.2 naMensrauM 

die trennung von Kundenobjekten und saP-objekten kann über die Präfixe y oder z sowie über 

einen eigenen namensraum erfolgen. die syntax lautet wie folgt: 

z… 

y… 

//… 

der kundeneigene namensraum kann bei saP registriert werden und ist nach Bestätigung 

weltweit eindeutig und für das jeweilige unternehmen zur Verwendung registriert. dieses Vorgehen 

unterstützt bei der konfliktfreien Vergabe von namen für softwareobjekte. 

der Vorteil des kundeneigenen namensraums liegt in der garantierten Überschneidungsfreiheit 

beim import fremder objekte in das eigene saP-system (z.B. beim einsatz von Fremdanwendungen, 

die per transportauftrag eingespielt werden) und bei zusammenführungen von saP 

systemen im rahmen einer Post-Merger integration. durch die reservierung des namensraums 

ist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten system ein softwareobjekt mit 

dem gleichen Präfix erstellt werden kann. 

der nachteil bei der Verwendung des kundeneigenen namensraums liegt darin, dass durch die 

durchgängige Verwendung des Präfixes bereits mehrere zeichen „verbraucht“ werden. dies kann 

insbesondere bei objekten, die nur wenige zeichen zur Benennung bieten, zu schwierigkeiten 

führen. darüber hinaus unterstützen nicht alle objekttypen, z.B. Berechtigungsobjekte, die 

Verwendung von namensräumen.

BEST PRACTICE: Wir empfehlen ausdrücklich die Verwendung eines kundeneigenen namensraums. 

WEITERE QUELLEN: 

1. http://help.sap.com (namensraum einrichten) 

2. Best-Built applications: http://scn.sap.com/community/best-built-applications 

2.3 einHeitLiCHer und LesBarer QueLLCode: Pretty Printer 

Übersichtlicher, leserlicher Code erleichtert jedem entwickler die (erneute) einarbeitung in 

Quellcode. als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zu 

halten, kann der Pretty Printer aus der aBaP-entwicklungsumgebung genutzt werden. Mit einem 

einzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. er bietet verschiedene 

Möglichkeiten, die über die einstellungen der Workbench konfigurierbar sind. Bereits eine 

eingerückte darstellung macht source Code deutlich lesbarer. es wird empfohlen, schlüsselwörter 

groß darzustellen. denn dadurch kann man Quelltext auch in ausgedruckter Form und ohne 

syntaxeinfärbung noch leicht verstehen. der Pretty Printer ermöglicht auf einfachem Weg die 

erstellung von einheitlichem Quellcode trotz unterschiedlicher entwickler. 

um die Lesbarkeit des Quelltextes zu erhöhen, empfehlen wir, auf mehrere anweisungen in einer 

Codezeile zu verzichten. 

Wir empfehlen, die option „standardkommentare einfügen“ zu deaktivieren, da die erzeugten 

Kommentare bei Änderungen nicht automatisch angepasst werden und redundante informationen 

enthalten. 

BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die einstellungen als 

einheitliche Vorgabe zu definieren. 

Modularisierung 

Programme, in denen logische Verarbeitungseinheiten nicht aufgeteilt werden, sind in weiterer 

Folge schwer lesbar und damit schwer wart- und erweiterbar. 

eine Modularisierungseinheit (Form-routine, Methode, Funktionsbaustein) soll logisch zusammengehörende 

anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen 

einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigen 

anweisungen sind jedoch zu vermeiden. 

die Modularisierung dient dazu, trotz Komplexität in der aufgabenstellung, den Programmcode 

übersichtlich zu gestalten. zudem sind Programmabschnitte mit derselben Logik zu vermeiden. 

Für die praktische umsetzung kann es hilfreich sein, vor Beginn des Programmierens die ersten 

Codezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend auszuprogrammieren. 

Wo es möglich und sinnvoll ist, ist es ratsam, vom prozeduralen Programmiermodell auf objekt- 

orientierte Programmierung überzugehen, um zukunftssicher zu entwickeln und objekte zu 

kapseln. insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden. 

im rahmen der einführung von aBaP objects fand eine Bereinigung der sprache und Vereinheitlichung 

der Konstrukte statt. die Verwendung von aBaP objects führt damit zu einer steigerung der 

Wartbarkeit. 

9 


10 


trennung von Präsentations- und anwendungslogik 

in allen Programmen sollte stets eine trennung von Präsentations- und anwendungslogik 

erfolgen. dies erlaubt es, ergebnisse und Funktionen der anwendungslogik durch verschiedene 

uis (user interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche schnittstelle anderen 

systemen bereitzustellen. diese aussage ist für alle gängigen ui-technologien gültig, wobei der 

Grad der unterstützung bzw. einhaltung dieser logischen trennung unterschiedlich ist. in einer 

Webdynpro aBaP-realisierung ist schon vom Framework eine trennung zwischen Modell- und 

ui-Logik vorgesehen. Bei klassischen dynpros und BsPs wird die trennung nicht in gleicher Weise 

forciert, aber grundsätzlich kann und sollte die trennung auch in diesen umgebungen umgesetzt 

werden. allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu Webdynpro, wo 

entsprechende Prüfungen im Code inspector realisiert sind. 

ein typisches Beispiel für eine klare trennung von anwendungslogik und ui sind Plausibilisierungsregeln. 

Wenn die Plausibilisierung von eingaben in einer bestimmten ui-technologie 

entwickelt wird, müssen diese Prüfungen bei einem Wechsel auf eine andere ui-technologie neu 

entwickelt werden. um dies zu vermeiden, müssen die Funktionen zur Prüfung von eingaben oder 

Parametern unabhängig von der verwendeten ui erstellt und gepflegt werden. 

internationalisierung 

sprachabhängige texte in Programmen dürfen nicht „hart codiert“ werden, sondern müssen in 

textelementen (Programmtexte, Klassentexte, online-text-repository [otr]), standardtexten oder 

nachrichtenklassen hinterlegt werden. da alle eigenentwicklungen den anspruch haben sollten, 

weltweit eingesetzt zu werden, sollten die wichtigsten sprachen übersetzt werden. 

zudem müssen sprachabhängige (customizebare) texte in eigenen texttabellen abgelegt werden. 

diese texttabelle besitzt dieselben schlüsselattribute wie die eigentliche Customizing-tabelle. 

zusätzlich muss das erste schlüsselattribut nach dem Mandantenfeld das sprachenattribut sein 

(datenelement sPrsL oder sPras). zudem muss die Fremdschlüsselbeziehung als jene der 

texttabelle gekennzeichnet werden. 

BEST PRACTICE: Wir empfehlen, den Code inspector für die suche nach nicht übersetzbaren 

texten zu verwenden. 

BEST PRACTICE: um spätere Übersetzungen einfach zu gestalten, sollte die Länge der Feldbezeichner 

und textelemente möglichst lang gewählt werden. als Faustregel für die Länge von 

textelementen hat sich bewährt, die 1,5-fache Länge der nativen Beschreibung vorzusehen. 

dynamische Programmierung 

in der „klassischen“, statischen entwicklung werden entwicklungsobjekte und der Quellcode zur 

designzeit definiert und im saP-system statisch hinterlegt. zur Laufzeit wird der vorgegebene 

Programmcode ausgeführt. im Gegensatz dazu ermöglicht die dynamische Programmierung die 

Flexibilisierung des Quellcodes. Folgendes Beispiel verdeutlicht die dynamische Programmierung: 

im Programmcode wird der name einer aufzurufenden aBaP-Klasse nicht statisch hinterlegt, 

sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren name durch den inhalt einer 

Variablen definiert ist. dieser name kann z.B. aufgrund von Benutzereingaben variieren. 

der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität. der nachteil liegt in der signifikant 

steigenden Komplexität und insbesondere in den damit einhergehenden sicherheitsrisiken.

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 


12 


auditierbarkeit von aBaP Code 

es muss jederzeit möglich sein, durch manuelle untersuchungen oder statische Codeanalyse- 

tools den selbst geschriebenen aBaP Code auf Mängel zu untersuchen. alle Methoden, aBaP- 

Coding unsichtbar zu machen, sind daher unzulässig, da sie solche untersuchungen behindern 

oder gar gezielt dafür verwendet werden könnten, Hintertüren in ein system zu schleusen. 

Verschleierter Code kann auch mit dem debugger nicht mehr untersucht werden. es wird an 

dieser stelle explizit darauf verzichtet, die techniken zu erläutern, mit denen Code versteckt 

werden kann. 

BEST PRACTICE: Verwenden sie insbesondere in der entwicklung im eigenen unternehmen keine 

techniken, um ihren Quellcode zu verstecken. 

2.4 oBsoLete anWeisunGen 

obwohl saP eine strikte abwärtskompatibilität vertritt, muss bei der Verwendung von obsoleten 

anweisungen, wie z.B. Kopfzeilen in internen tabellen, berücksichtigt werden, dass hierbei 

Probleme auftreten, wenn der Code in Klassen übernommen werden soll. Hier ist zu beachten, 

dass es für obsolete sprachelemente immer modernere alternativen gibt. es gibt also eigentlich 

außer Gewohnheit wenige Gründe für deren Verwendung, deshalb sollten sie vermieden werden. 

BEST PRACTICE: Wir empfehlen den regelmäßigen einsatz eines statischen Codeanalyse-tools, 

um obsolete anweisungen zu entdecken. aus den saP-Bordmitteln eignet sich hierzu der Code 

inspector bzw. die durchführung des syntax-Checks. 

darüber hinaus existieren sehr gute analysewerkzeuge von drittanbietern. 

2.5 syntax-CHeCK und Code insPeCtor 

der syntax-Check und der Code inspector ermöglichen die Überprüfung des Programmcodes 

während der designzeit. 

Bei der Freigabe von transporten kann der Code inspector über die se03 global angeschaltet 

werden, um Fehler zu erkennen. Hierdurch kann auch die anzahl der transporte verringert 

werden, da beim erkennen von Fehlern die Freigabe noch abgebrochen werden kann. die 

Behebung kann dann in den bestehenden auftrag aufgenommen werden und es muss kein neuer 

transport erzeugt werden. 

BEST PRACTICE: der Code inspector wird im saP-standard nur bei Freigabe des transportauftrags 

ausgeführt. empfehlenswert ist jedenfalls die Prüfung durch den Code inspector bereits bei 

der Freigabe der jeweiligen transportaufgabe. 


die Vorgehensweise der implementierung des dafür notwendigen Badis ist im Buch „Praxishandbuch 

saP Code inspector“ (saP Press) beschrieben.

2.6 Feste CodierunG: Keine „MaGiC nuMBers“ 

die feste (harte) Codierung von texten, zahlen, user-namen, organisationseinheiten, datum etc. 

sollte im Quelltext ausdrücklich vermieden werden. 

Während der entwicklung kann die direkte Verwendung von hart codierten Werten vermeintlich als 

schnelle Vorgehensweise erscheinen. auf den Gesamtlebenszyklus der anwendung bezogen, führt 

sie jedoch zu deutlich erhöhten Kosten. die Wartbarkeit und testbarkeit der anwendung werden 

langfristig deutlich erschwert. 

BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler stelle definiert 

werden. Für die Konstantendefinition eignen sich z.B. die attribute globaler Klassen bzw. interfaces. 

BEST PRACTICE: alternativ zu harten Codierungen im Quelltext können kundeneigene Customizing-tabellen 

verwendet werden. in diesen tabellen werden die Werte, z.B. zahlen, organisationseinheiten 

etc. als Konfiguration hinterlegt und bei Programmstart in eine Variable gelesen. 

anschließend wird ausschließlich mit dieser Variablen gearbeitet. 

die o.g. Vorgehensweisen steigern bei Mehrfachgebrauch die Konsistenz und effizienz der analyse 

im Fehlerfall bzw. bei regulären Wartungstätigkeiten. Wir empfehlen ausdrücklich die Kommentierung 

der Konstanten und die Bedeutung der Werte an zentraler stelle. 

um neue Mitarbeiter bei der ermittlung von Konstanten zu unterstützen, bietet es sich an, diese 

entweder außerhalb des systems durchsuchbar zu dokumentieren oder ein suchtool (s. „Weitere 

Quellen“) zur Verfügung zu stellen, mit dem innerhalb des systems nach Konstanten gesucht 

werden kann. 

2.7 tiPPs BeiM arBeiten Mit transPorten 

Wenn mehrere entwickler an einem entwicklungsobjekt Änderungen vornehmen, kann dies unter 

umständen zu Problemen führen, wenn die transportaufträge nicht in der richtigen reihenfolge in 

die produktiven systeme transportiert werden oder andere objekte aus anderen transportaufträgen 

fehlen. 

BEST PRACTICE: um dies zu vermeiden, sollte mit transport von Kopien gearbeitet werden. dabei 

werden die geänderten entwicklungsobjekte durch den eigentlichen transportauftrag im 

entwicklungssystem gesperrt und über transport von Kopien werden nur Kopien der objekte in 

das Qualitätssicherungssystem transportiert. ein entwickler bemerkt sofort, dass ein anderer 

entwickler ggf. das objekt bereits bearbeitet, und kann sich mit dem anderen entwickler 

abstimmen. nach abschluss des „Projektes“ wird nur der original-sperrtransport ins Produktivsystem 

transportiert. 

13 


14 


2.8 BereCHtiGunGsPrÜFunG iM QueLLCode 

Bei zugriff auf daten und auch deren Präsentation sind die dafür notwendigen Berechtigungsobjekte 

zu prüfen. Bei der Verwendung von standardobjekten soll jedenfalls die Prüfung auf die 

entsprechenden saP-standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung der 

notwendigen rollen). Für kundeneigene datenobjekte können in der regel keine saP-standard- 

Berechtigungsobjekte zur Prüfung verwendet werden. zu diesem zweck können kundeneigene 

Berechtigungsobjekte implementiert und geprüft werden. 

Weitere informationen finden sich im Kapitel 5.1.1 

2.9 ProGraMMierModeLL: oBJeKtorientiert Vs. ProzeduraL 

die prozedurale entwicklung in aBaP ist inzwischen von saP als obsolet eingestuft worden. 

insbesondere die Befehle ForM…endForM und PerForM sind als obsolete anweisungen 

eingestuft. Prozedurale entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globale 

Variablen und includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen. 

objektorientierte entwicklung wurde so konzipiert, dass logisch zusammenhängende aufgaben 

einheitlich in objekten zusammengefasst werden können. dadurch wird unter anderem auch die 

Wiederverwendbarkeit von Code erhöht. insbesondere können solche objekte auch von anderen 

entwicklern für ihre zwecke leicht erweitert oder verändert werden, ohne dass die grundlegenden 

Funktionen beeinträchtigt werden (open-Close-Prinzip). andererseits können zentrale Funktionalitäten 

oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder schreibzugriff durch 

aufrufende Programme geschützt werden. 

BEST PRACTICE: Wir empfehlen bei neuentwicklungen möglichst nur noch mit Klassen und 

Methoden zu arbeiten und keine ForMs mehr zu verwenden. 


1. Horst Keller und Gerd Kluger, not yet using aBaP objects? eight reasons Why every aBaP 

developer should Give it a second Look, sap Professional Journal 

2. Horst Keller and Gerd Kluger, netWeaver development tools aBaP, saP aG 

3. Bertrand Meyer, objektorientierte softwareentwicklung, Hanser 1990, isBn 3-446-15773-5 

4. Consea-Projekt für suche nach Konstanten auf saP Code exchange: 

https://cw.sdn.sap.com/cw/groups/consea 

2.10 Weitere QueLLen (ProGraMMierriCHtLinien / aBaP) 

1. saP dokumentation saP netWeaver as aBaP release 731 

http://help.sap.com/abapdocu_731/de/index.htm 

in dieser dokumentation ist dem thema Programmierrichtlinien ein eigenes Kapitel gewidmet.

3 PerForManCe 

in den folgenden abschnitten empfehlen wir einige regeln, die bei der täglichen arbeit in der 

aBaP-entwicklung beachtet werden sollten, um von vorneherein Performance-engpässe zu 

vermeiden. Wie an viele anderen stellen der softwareentwicklung hilft es auch im Hinblick auf eine 

ausreichende Performance zu wissen, was gemacht werden soll. solange der sinn und zweck 

eines Code-stückes nicht klar ist, sollte dies zuerst geklärt werden. 

3.1 VerMeidunGsPrinziP 

„die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und am 

leichtesten zu dokumentierenden teile eines Computersystems sind die, die man weggelassen 

hat.“ (Gorden Bell) 

BEST PRACTICE: Vermeiden sie jegliches unnötige Coding. 

Frei nach diesem Motto sollten sie auch genau prüfen, welcher Code wirklich für die Produktion 

gedacht ist, und sämtliche test- und demo-Programme spätestens auf den Q-systemen löschen. 

aber auch innerhalb von produktivem Coding sollte immer der ansatz verfolgt werden, nicht mehr 

zu tun, als für die aufgabe wirklich benötigt wird. ein einleuchtendes Beispiel dafür ist die regel 

zur Vermeidung von *-seLeCts, bei denen der einfachheit halber alle spalten einer tabelle 

selektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige spalten benötigt 

werden. 

anmerkung: diese Vorgehensweise steigert gleichzeitig die robustheit von Programmen. 

das Lesen mit Hilfe von *-seLeCt in eine kundeneigene datenstruktur kann zu Fehlern nach 

einem upgrade führen,wenn die standardtabelle durch saP erweitert wurde. das explizite Lesen 

benötigter spalten schützt vor dieser unschärfe. 

3.2 VorHandene WerKzeuGe nutzen 

die im saP-system bereits vorhandenen Werkzeuge bieten gute unterstützung bei der erstellung 

von performanten anwendungen bzw. bei der analyse von Performance-engpässen. diese 

Werkzeuge sollten frühzeitig und in allen Lebensphasen der software angewendet werden. 

die nachfolgende tabelle bietet einen Überblick zu den zentralen Werkzeugen: 

entwicklung Beschreibung 

Code inspector statische Code-analyse und -Prüfungen 

se30 / sat Laufzeit-traces 

st05 traces für sQL, rFC und enqueues 

dB05 Wertverteilungs-analyse für index-design 

15 


16 

3 PerForManCe 

Laufzeit Beschreibung 

sM50/sM66 Übersicht Workprozesse/applikationsserver 

debugger schrittweises ausführen von Coding 

Memory inspector Vergleich und analyse von speicherabzügen zur 

ermittlung von nicht speicherverbrauch und nicht 

freigegebenen Heap-objekten 

st10 tabellenaufruf-statistiken zur Prüfung von 

tabellenpufferung 

Post Mortem Beschreibung 

st22 analyse von Laufzeitfehlern (z.B. bei speichermangel) 

stad Workload-analyse 

st04 dB-Performance-Übersicht 

BEST PRACTICE: starten sie die Performance-untersuchung mit einem trace in der se30/sat und 

konzentrieren sie sich auf den größeren zeittreiber. Wenn die meiste zeit im aBaP-teil verbraucht 

wird, analysieren sie weiter mit der se30/sat. Liegt die meiste zeit bei den dB-aufrufen, starten 

sie einen sQL-trace mit der st05. 

3.3 PerForManCe-oPtiMierunGen nur an KritisCHen und 

reLeVanten steLLen 

auch wenn man nicht performante Konstrukte bei der softwareentwicklung immer vermeiden 

sollte, sollte man sich gleichzeitig bei der notwendigkeit von umfangreicheren Performance-optimierungen 

auf die teile der software beschränken, die durch Messung nachgewiesenermaßen die 

ursache von langer Laufzeit oder erhöhtem speicherverbrauch sind. auch für Performance-aspekte 

trifft die 80/20-regel zu und es gilt daher, die meistens raren ressourcen für eine umfangreiche 

Verbesserung auf die 20 % des systems zu konzentrieren, die für 80 % der Laufzeit/des 

speicherverbrauchs verantwortlich sind. um an diese stellen zu gelangen, ist der sinnvolle einsatz 

der genannten Werkzeuge essenziell. 

BEST PRACTICE: Wir empfehlen, die suche nach Performance-engpässen mit dem einsatz der 

Laufzeitanalyse se30/sat mit voller aggregation zu beginnen. dadurch sollte deutlich werden, ob 

die Laufzeit aus der interaktion mit der datenbank oder der Verarbeitung der geladenen daten im 

Hauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher datenbestand 

verarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen spur zu folgen. Wird 

mehr als die Hälfte der Laufzeit im dB-teil verbraucht, sollte eine genauere analyse der sQL- 

Kommandos mit der transaktion st05 erfolgen. Wird mehr Laufzeit im aBaP-teil verbraucht, 

erfolgen tiefergehende analysen mit Hilfe der se30/sat, wobei die aggregationsstufen schrittweise 

verringert werden, um genauere aussagen über die kritischen Programmstellen zu bekommen. 

nach jedem optimierungsschritt sollten die ergebnisse verglichen und dokumentiert werden.

3.4 datenModeLL und datenzuGriFF 

3.4.1 datenmodell und indizes 

der aufbau des datenmodells bildet die Basis performanter anwendungen. ein mit augenmaß 

normalisiertes datenmodell kann effizienter mit daten und indizes arbeiten. Hierzu finden – unabhängig 

von der Programmiersprache aBaP – die normalisierungsregeln anwendung. 

Beim einsatz von indizes für tabellen empfehlen wir folgende Punkte: 

> es sollten max. fünf indizes pro tabelle existieren, wenn häufig ändernd auf diese tabellen 

zugegriffen wird. Mit jedem index steigen die Verwaltungskosten, die bei datenänderungen 

anfallen. 

> Fünf Felder pro index sollten als obergrenze eingehalten werden. 

> in einem index sollten nur selektive Felder aufgenommen und in der reihenfolge nach 

absteigender selektivität sortiert werden. 

> auf Feldebene sollten zwischen zwei indizes einer tabelle keine Überlappungen auftreten. 

> Bei mandantenabhängigen tabellen sollte das Feld „Mandant“ als erstes Feld aufgenommen werden, 

insbesondere bei großen tabellen (>1000 einträge). auch wenn dieses Feld nicht sonderlich selektiv 

ist und damit der dritten regel widerspricht, wird bei jeder abfrage dieses Feld in der selektion 

vom saP-system mit übergeben und ausgewertet. Gerade bei tabellen mit stark unterschiedlichen 

eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im index negativ auswirken. 

3.4.2 rahmenbedingungen bei datenbankzugriffen 

Folgende Fragen sollten bei dB-zugriffen gestellt und beantwortet werden: 

> sind indizes in geeigneten rahmen angelegt? 

> s. vorheriges Kapitel (3.4.1) 

> Lesen anweisungen am tabellenpuffer vorbei? 

Hierbei kann die transaktion st10 verwendet werden, um die zugriffshäufigkeiten auf gepuffer- 

ten tabellen zu überprüfen. Mit der transaktion st05 können mit dem kombinierten sQL- und 

Puffer-trace zugriffe ermittelt werden, die wider erwarten den tabellenpuffer nicht verwenden. 

und mit Hilfe des Code inspectors lassen sich viele dieser statements bereits im Vorfeld 

statisch ermitteln. 

> Kann ein dB-index zur sortierung auf der dB mit order By genutzt werden? 

im einfachsten Fall kann dafür der zusatz PriMary Key verwendet werden, wenn die sortierung 

nach dessen Feldern erfolgen soll. sind andere sortierungen erforderlich, kann es helfen, 

einen index anzulegen, der die gewünschten Felder in der korrekten reihenfolge enthält. 

allerdings sollten dabei die Hinweise zur anzahl von indizes pro tabelle beachtet werden. 

erfolgt der zugriff mit order By nur selten, lohnt es sich in der regel nicht, dafür einen 

eigenen index anzulegen. in diesem Fall sollte die sortierung im aBaP erfolgen, sofern dies die 

zu sortierende datenmenge zulässt. 

17 


18 

3 PerForManCe 

Beispiel: die tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nach 

diesem datum ermittelt werden. in diesem Fall würde sich ein index über dieses Feld wahr- 

scheinlich rentieren, weil zum einen dieses Feld in der WHere-Bedingung enthalten ist und 

gleichzeitig der zusatz order By Belegdatum vom vorhandenen index profitiert. 

3.4.3 datenbankzugriffe 

die auf der datenbank selektierte und an die anwendungsschicht zu übergebende datenmenge 

sollte grundsätzlich so gering wie möglich gehalten werden. nachfolgend finden sie Hinweise, wie 

sie dies im konkreten Fall umsetzen können. 

BEST PRACTICE: 

> spaltenreduzierung: 

Vermeiden sie *-selektionen und benennen sie stattdessen die benötigen spaltennamen in der 

selektion. insbesondere das unnötige Laden von spalten des typs string ist teuer. 

die ergebnistabelle sollte mit der selektionsstruktur übereinstimmen, um optimale ergebnisse zu 

erzielen. sollten in der ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschten 

Felder namensgleich angelegt sein, ist auch der zusatz CorresPondinG FieLds möglich und 

führt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die robustheit der software erhöht. 

> optimale suchabfrage 

Versuchen sie für die selektion von daten möglichst nur abfragen zu verwenden, die einen der 

vorhandenen indizes vollständig nutzen. sollte das nicht möglich sein, achten sie möglichst darauf, 

zumindest die ersten elemente des index zu verwenden, damit die zeilenweise suche auf eine 

möglichst kleine Menge von datensätzen reduziert werden kann. 

> zeilenreduzierung 

nutzen sie die WHere-Bedingungen, indem sie die selektion beschreiben und die an das 

aBaP-system zu übermittelnden daten minimieren. 

Verwenden sie seLeCt sinGLe / uP to n roWs, wenn sie nur einzelne zeilen benötigen. 

> existenzchecks 

die Prüfung, ob datensätze, die einem bestimmten selektionskriterium genügen, existieren, 

sollten nicht mit der anweisung Count(*), sondern mit seLeCt sinGLe erfolgen, 

wobei das genannte Feld aus dem zur selektion verwendeten index stammen sollte. dies 

vermeidet unnötige zugriffe auf die tabellendaten. 

> aggregate 

aggregate (Min, Max, …) werden immer auf dem datenbankserver ausgewertet. dadurch wird die 

tabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem dB-system, 

das in vielen installationen von sehr vielen applikationsservern angesprochen wird, sollten 

entwickler prüfen, welche datenmenge für das aggregat verwendet werden muss und ob es sich 

lohnen kann (sofern diese nicht groß ist), die daten in eine interne tabelle zu laden und das 

aggregat dort durchzuführen. allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem 

Kenntnisstand insbesondere Hana-basierte datenbankabfragen gerade bei aggregaten ihre 

stärken haben und damit deren einsatz für Hana explizit sinnvoll ist. 

Beispiel: um den durchschnittlichen Wert über eine große anzahl (>100000) von Bestellungen zu 

ermitteln, ist es sinnvoll, dieses aggregat auf dem dB-system ermitteln zu lassen, um nur einen 

oder wenige Werte statt hunderttausender an die applikationsserver übermitteln zu lassen, um

dort den durchschnittswert im aBaP zu berechnen. dies gilt insbesondere, wenn diese auswertung 

nur selten (z.B. einmal pro tag) erfolgt. soll hingegen die summe der Bestellpositionen eines 

einzelnen auftrags sehr häufig und von allen vorhandenen applikationsservern ermittelt werden, 

ist die ermittlung im aBaP wahrscheinlich die für die Gesamtsituation günstigere Variante. 

> updates 

die anweisung uPdate set ermöglicht das Übertragen von einzelnen zu ändernden Feldern (statt 

des gesamten datensatzes). Wenn möglich, sollte diese anweisung bevorzugt verwendet werden. 

> ausführungshäufigkeit bei dB-zugriffen 

Jede ausführung eines open sQL-statements ist mit einem gewissen overhead (Parsen, abgleich 

gegen statement-Puffer im dBMs usw.) verbunden. daher sollten pro statement möglichst viele 

der benötigten daten auf einmal übertragen werden. Werden beispielsweise die daten von 50 

aufträgen benötigt, sollten diese nicht durch 50 einzelaufrufe ermittelt werden, sondern durch ein 

einzelnes statement, das die sog. array-zugriffe unterstützt. diese sind durch die zusätze into 

taBLe bei seLeCts bzw. FroM taBLe bei schreibenden zugriffen zu erkennen. Vermeiden sie auf 

jeden Fall open sQL-statements innerhalb von schleifen! Bei einem solchen Konstrukt fällt der 

overhead für diese statements bei jedem schleifendurchlauf an. 

setzen sie ModiFy nicht ein! erstens sollte innerhalb einer applikation klar sein, ob 

datensätze neu erstellt wurden oder vorhandene angepasst werden müssen. zweitens ist dieses 

statement aus Performance-Gesichtspunkten sehr kritisch: selbst mit dem zusatz FroM taBLe 

werden einzelne zugriffe pro zeile der internen tabelle ausgeführt und dabei wird jeweils zuerst 

ein uPdate versucht und im Fehlerfall ein insert nachgelegt. d.h., bei vielen neu zu erstellenden 

datensätzen erfolgen nicht n einzelzugriffe, sondern 2n mit n=anzahl neue datensätze in der 

internen tabelle. 

> VieWs/Joins 

Geschachtelte seLeCt-anweisungen und seLeCt-anweisungen in schleifen sollten vermieden 

werden. stattdessen bieten sich VieWs, Joins oder der zusatz For aLL entries an. Bei For aLL 

entries sollte man jedoch auf Folgendes achten: 

a. ist die interne tabelle leer, auf der For aLL entries basiert, dann werden alle einträge 

geladen. 

b. sind in der internen tabelle einträge doppelt vorhanden, kann dies dazu führen, dass die 

zugehörigen datensätze auch doppelt von der datenbank geladen werden. es empfiehlt sich daher, 

zuvor ein deLete adJaCent duPLiCates aufzurufen. 

3.5 interne taBeLLen und reFerenzen 

interne tabellen stellen ein zentrales Konstrukt bei der entwicklung von anwendungen mit aBaP 

dar. neben datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle von 

Performance-Problemen. Bei kleinen datenmengen stellen dinge wie die Wahl der passenden 

tabellenart und eines passenden schlüssels noch kein Problem dar. Werden aber größere daten- 

mengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht, 

können vorher aus Performance-sicht unkritische stellen zu erheblichen Laufzeitverlängerungen 

führen. 

BEST PRACTICE: Wir empfehlen die Beachtung der nachfolgenden Hinweise zur steigerung der 

Performance von anwendungen: 

19 


20 

3 PerForManCe 

> Wählen sie die tabellenart passend zur späteren Verwendung: 

> standard-tabellen eignen sich für daten, die nur selten oder gar nicht nach bestimmten 

Kriterien durchsucht werden müssen. Wenn keine suche erfolgen muss, lohnt es sich nicht, 

die Kosten für die erstellung und aktualisierung der zusätzlichen schlüsselstrukturen der 

anderen tabellenarten zu zahlen. Bei sehr kleinen datenmengen ( sorted-tabellen bieten sich an, wenn die daten häufig nach (teil-)schlüsseln durchsucht 

werden müssen, aber keine eindeutigkeit der schlüsselfelder garantiert werden kann. 

Gerade zugriffe, die nur mit einem ersten teil der schlüsselfelder stattfinden, können nur 

von dieser tabellenart unterstützt werden. 

> Hashed-tabellen sind perfekt dafür geeignet, in dictionary-artigen Konstrukten nach ein- 

deutigen schlüsseln zu suchen. Wenn die eindeutigkeit der einträge im Hinblick auf die 

schlüsselfelder garantiert werden kann und die suchzugriffe immer mit dem vollständigen 

schlüssel (=alle Felder des schlüssels werden auf Äquivalenz gegen einen jeweiligen Wert 

geprüft) erfolgen, ist diese tabellenart in der regel optimal. 

> Wenn für eine tabelle vom typ sorted oder Hashed zugriffe erfolgen, sollten diese immer mit 

dem passenden (teil-)schlüssel stattfinden. 

dies bedeutet, bei read taBLe den zusatz WitH taBLe Key zu verwenden und bei LooP at 

WHere möglichst viele aufeinander folgende Felder des schlüssels mit „=“ zu vergleichen. 

dann werden die intern aufgebauten schlüsselstrukturen verwendet, um die passenden 

einträge schneller zu ermitteln. 

> ab as aBaP 7.02 können sie bei internen tabellen, die selten geändert werden, aber mit mehr 

als einem zugriffmuster gelesen werden, neben dem primären schlüssel, der wie gehabt 

definiert und verwendet wird, auch weitere sekundäre schlüssel definieren, die auch einen vom 

Primärschlüssel abweichenden typ (sorted, Hashed) haben. 

als Beispiel können sie damit für eine als Hashed definierte tabelle mit eindeutigem Primär- 

schlüssel einen weiteren schlüssel vom typ sorted definieren, der es ermöglicht, performant 

auf die daten der tabelle aus einem anderen Blickwinkel (nicht eindeutig, teilschlüssel möglich) 

zuzugreifen, ohne die eigentlichen daten zweimal im Hauptspeicher anzulegen und bei 

Änderungen manuell für die Konsistenz zwischen beiden tabellen zu sorgen. 

> Ähnlich wie bei den dB-zugriffen existieren für interne tabellen einzelsatzzugriffe und 

Massenzugriffe. 

Wenn möglich, sollten immer die Varianten mit Massenzugriffen gewählt werden, die perfor- 

manter arbeiten als mehrere einzelzugriffe. als Beispiel sollten sie beim anhängen von zeilen 

einer teilergebnistabelle zur Gesamtergebnistabelle das anweisungsmuster aPPend Lines oF 

to verwenden, anstatt die gleiche Funktion über eine schleife LooP at mit einzelnen aPPend 

to zu realisieren. 

> Bei der Verwendung der anweisung sort sollten sie immer die gewünschten sortierfelder 

angeben. 

erstens erhöht dies die Lesbarkeit des Codings und zweitens ist bei den wenigsten standard- 

tabellentypen ein tabellenschlüssel definiert. Fehlt ein solcher schlüssel, wird die gesamte

zeile der tabelle als schlüssel verwendet und damit bei der sortierung alle Felder der tabelle 

geprüft, was zu erheblichen Performance-einbußen führt. soll also z. B. ein tabelle nach den 

Feldern Benutzer und datum sortiert werden, verwenden sie die anweisung sort table By 

Benutzer datum, auch wenn die tabellenstruktur mit diesen Feldern beginnt und die reihen- 

folge des ergebnisses hinsichtlich der geforderten Felder gleich ist. 

> Vor dem einsatz der anweisung deLete adJaCent duPLiCates sollte immer sichergestellt 

sein, dass die tabelle nach den gleichen Feldern sortiert ist, damit doppelte einträge auch 

wirklich eliminiert werden. 

Wie die anweisung aussagt, werden nur benachbarte tabellenzeilen verglichen. Wie bei der 

sort-anweisung auch sollten immer die Felder angegeben werden, die betrachtet werden 

müssen. ansonsten wird auch hier die gesamte zeile feldweise verglichen, auch wenn nur zwei 

Felder aus fachlicher sicht dafür ausreichend sind. 

> reine existenzprüfungen auf internen tabellen sollten immer mit read taBLe transPortinG 

no FieLds durchgeführt werden, wenn auf den daten der ermittelten zeile keine weiteren 

operationen stattfinden. 

3.5.1 Feldsymbole 

Feldsymbole bieten die Möglichkeit, auf existierende daten, z.B. zeilen von internen tabellen, zu 

referenzieren. das arbeiten mit referenzen ist deutlich performanter als das Kopieren der daten. 

daher sollten, wo möglich, Feldsymbole verwendet werden. nur bei sehr kleinen tabellen gibt es 

einen minimalen Vorteil in der Laufzeit zwischen den Kopierkosten bei into und Feldsymbolen. 

ansonsten sind Feldsymbole immer schneller, insbesondere dann, wenn die tabelleninhalte 

geändert werden sollen. Bedenken sie beim einsatz von Feldsymbolen jedoch, dass eine Änderung 

des Wertes eines Feldsymbols auch den Wert im referenzierten datenelement überschreibt. 

BEST PRACTICE: Verwenden sie standardmäßig Feldsymbole für die zugriffe auf interne tabellen. 

3.5.2 Parameterübergabe 

die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus technischen 

Gründen vorgeschrieben ist (z.B. rFC-Funktionsbausteine, returning-Parameter bei funktionalen 

Methoden). so werden unnötige Kopierkosten bei der Parameterübergabe gespart. dies gilt in 

besonderem Maße bei Parametern mit tiefen datentypen wie internen tabellen oder strings. Wenn 

es keine technischen erfordernisse gibt, sollten Parameter immer per referenz übergeben werden. 

Weiterhin sollten so wenig Parameter wie möglich definiert werden. optionale Parameter sollten 

komplett vermieden werden. 

BEST PRACTICE: Verwenden sie so wenig Parameter wie möglich, die per referenz übergeben 

werden. nutzen sie die Wertübergabe nur an den technisch notwendigen stellen. 

3.6 WeiterFÜHrende QueLLen 

> einen guten einstieg in die Performance-optimierung im aBaP bietet der saP-Kurs BC490. 

> siegfried Boes, „Performance-optimierung von aBaP-Programmen“, dpunkt Verlag 2009, 

isBn 3898646157 

21 


22 

4 roBustHeit 

dieses Kapitel erläutert, worauf entwickler achten müssen, um robuste aBaP-Programme zu 

schreiben. dazu ist es zunächst erforderlich zu definieren, was ein robustes aBaP-Programm 

ausmacht. 

unter robustheit verstehen wir die Fähigkeit eines Programms, auch unter ungünstigen umständen 

weiterzulaufen und korrekte ergebnisse zu liefern. das bedeutet insbesondere, dass 

Programme Fehlersituationen erkennen und in einer Weise darauf reagieren, dass die gewünschte 

Funktionalität nicht gefährdet wird. 

4.1 FeHLerBeHandLunG 

die aBaP-Laufzeit hat verschiedene Möglichkeiten, eine anwendung auf Fehlersituationen 

hinzuweisen. diese sind hier aufgeführt und die Best Practices jeweils erläutert. 

4.1.1 sy(st)-suBrC-Prüfungen 

Bei einer ganze reihe von aBaP-Befehlen setzt der saP-Kernel nach deren ausführung die 

globale Variable sy(st)-suBrC. in der regel wird eine erfolgreiche ausführung durch den Wert 0 

angezeigt. 

Bei den Befehlen CaLL FunCtion und CaLL MetHod wird sy(st)-suBrC nicht automatisch 

gesetzt, wenn es zu Fehlern in dem aufgerufenen Code kommt. sofern die gerufenen Module 

sogenannte nicht-klassenbasierte ausnahmen (non-class-based exceptions) verwenden, muss das 

aufrufende Programm diese in der exCePtions-sektion beim aufruf korrekt deklarieren und 

ihnen einen Wert ungleich 0 zuweisen, damit sy(st)-suBrC gesetzt wird. 

BEST PRACTICE: setzen sie explizit den speziellen Wert otHers, da sich die Liste der ausnahmen 

systembedingt ändern könnte, nachdem das rufende Programm fertiggestellt wurde. der spezielle 

Wert otHers sollte insbesondere beim aufruf von rFC-fähigen Funktionsbausteinen verwendet 

werden, da es hier zu verschiedenen speziellen rFC-ausnahmen kommen kann. 

die Prüfung von sy(st)-suBrC muss immer unmittelbar nach dem Befehl erfolgen, der diese 

globale Variable setzt. Wird die Prüfung erst später durchgeführt, kann der Wert bereits durch 

einen anderen aBaP-Befehl überschrieben worden sein. 

4.1.2 MessaGe-anweisung 

Mit der MessaGe-anweisung können status- oder Fehlermeldungen ausgegeben werden. dabei 

unterscheidet sich das Verhalten der MessaGe-anweisung je nach Meldungsart (status, 

information, Fehler, abbruch) und ob der auslösende Programmteil im dialog- oder Batchmodus 

ausgeführt wird. 

BEST PRACTICE: Vermeiden sie MessaGe-anweisungen außerhalb von Modulen, die direkt mit 

dem anwender kommunizieren bzw. die in einer definierten dialogschicht liegen. MessaGe-anweisungen 

können in bestimmten Konstellationen von Meldungsart und Betriebsmodus implizite 

CoMMits aufgrund eines Bildschimwechsels in klassischen dynpros auslösen und führen bei 

einem aufruf innerhalb eines rFC-aufrufs zu Verbindungsabbrüchen. Verwenden sie innerhalb des 

eigentlichen anwendungskerns klassenbasierte ausnahmen, um auf Fehlersituationen hinzuweisen.

4.1.3 Klassenbasierte ausnahmen 

seit einführung von aBaP oo können auch klassenbasierte ausnahmen verwendet werden. diese 

arbeiten nach dem Prinzip des „Werfens“ von ausnahmen: ein Programm erkennt einen Fehler und 

„wirft“ eine ausnahme in den Call stack. Fängt der aufrufer diese ausnahme nicht, wird sie so lange 

weiter im Call stack nach oben propagiert, bis sie an anderer stelle gefangen wird oder zu einem 

dump führt. 

es ist wichtig, alle ausnahmen zu fangen, auf die in der jeweiligen stelle angemessen reagiert werden 

kann, oder ausnahmen in der Methode oder dem Funktionsbaustein zu deklarieren, sodass für den 

aufrufer klar ersichtlich ist, dass die Methode bzw. der Funktionsbaustein eine solche ausnahme 

aufwerfen könnte. Wichtig ist hierbei die einheitliche Verwendung: Für dieselbe Fehlersituation 

sollten einheitliche Fehlerbehandlungen/ausnahmen verwendet werden. 

zum Fangen von ausnahmen ist der aBaP-Befehl try…CatCH…endtry gedacht. entsprechend 

müssen alle ausnahmen aller Module, die klassenbasierte ausnahmen erzeugen können, von 

einem try…CatCH behandelt werden, um einen robusten ablauf zu gewährleisten. 

BEST PRACTICE: erlauben sie keine leeren ausnahmebehandlungen. 

dadurch wird es aufrufenden stellen unmöglich gemacht, auf ausnahmesituationen angemessen 

zu reagieren. Propagieren der ausnahme ist in diesen Fällen die richtige reaktion. 

BEST PRACTICE: Vermeiden sie beim Fangen von ausnahmen die globale Basisklassen Cx_root. 

im CatCH-Block wird die angabe der exception-Klasse die zu fangende ausnahme spezifiziert, z.B. 

Cx_sy_zerodiVide zum abfangen eines Fehlers aufgrund der division durch null. Hierbei gilt es 

konkrete ausnahmen abzufangen, um diese spezifisch zu behandeln. das Fangen der allgemeinsten 

ausnahme Cx_root sollte nur erfolgen, wenn die ausnahmebehandlung tatsächlich in der 

Lage ist, mit unbekannten Fehlersituationen umzugehen. 

BEST PRACTICE: Wählen sie die grundlegende art von eigenen ausnahmeklassen durch die 

Vererbung von vordefinierten Basisklassen (statiC_CHeCK, dynaMiC_CHeCK, no_CHeCK) mit 

Bedacht. 

Beim einsatz von statiC_CHeCK wird jeder Verwender durch syntaxfehler gezwungen, für jede 

dieser ausnahme zu entscheiden, ob er sie direkt behandeln kann, weiterreicht und damit in seine 

deklaration aufnehmen muss oder über das Verketten mit eigenen ausnahmeklassen verpackt. 

alle diese Möglichkeiten sind mit aufwand und Änderungen verbunden, die den Vorteil der 

klassenbasierten ausnahmen (Propagieren von ausnahmen, die nicht direkt behandelt werden 

können) zunichtemachen. Verwenden sie bei der nachträglichen einführung von ausnahmeklassen 

daher bevorzugt dynaMiC_CHeCK, um nicht allen ausnahmen die o.g. anpassungen aufzuzwingen. 

setzen sie statiC_CHeCK bewusst ein, um aufrufer dazu zu zwingen, sich mit der ausnahmesituation 

auseinanderzusetzen. 

die ausnahmenklasse no_CHeCK bietet sich für solche Fehlersituationen an, auf die kaum eine 

aufrufende stelle angemessen reagieren kann. Beispiele dafür sind das Wegbrechen von sekundären 

datenbankverbindungen oder andere dinge, die durch das Coding nicht korrigiert werden können. 

23 


24 

4 roBustHeit 

4.1.4 nicht behandelbare ausnahmen 

es gibt ausnahmen, die vom aBaP Code aus nicht behandelt werden können und dadurch zwangs- 

läufig zu einem abbruch der anwendung und einem dump führen. in einigen Fällen ist es möglich, 

pro aktiv vor der ausführung eines statements, das eine nicht behandelbare ausnahme auslöst, 

die rahmenbedingungen zu prüfen. 

Beispiel: 

das statement oPen dataset löst einen shortdump aus, wenn der Benutzer keine ausreichenden 

Berechtigungen zum Öffnen der datei hat. um dies zu vermeiden, muss die Berechtigung pro aktiv 

vom aBaP geprüft werden (FuBa autHority_CHeCK_dataset), damit oPen dataset nicht zu 

einem dump führt. 

4.2 KorreKte iMPLeMentierunG Von datenBanK-ÄnderunGen 

4.2.1 sperrobjekte 

um dateninkonsistenzen zu vermeiden, müssen die entsprechenden objekte vor Veränderung auf 

der datenbank gesperrt werden. zusammenhängende objekte dürfen erst verändert werden, wenn 

alle zugehörigen entitäten erfolgreich gesperrt werden. damit ist keine parallele datenänderung 

möglich. 

die saP-sperre besteht über mehrere datenbank-LuWs (Logical unit of Work) hinweg, sodass 

konsistent Änderungen auf der datenbank für das gesamte zu ändernde Businessobjekt geschrieben 

werden können. 

die sperren sind so genau wie möglich abzusetzen, um nur die relevanten objekte innerhalb der 

LuW zu sperren. zudem sind die sperren so lange wie nötig und so kurz wie möglich zu halten. 

Für die Änderung von saP-standard-datenobjekten direkt auf der datenbank sind die entsprechenden 

saP-standard-sperrfunktionen zu verwenden, da diese auch von den standard-transaktionen 

verwendet werden und so ein konsistentes Verhalten sicherstellen. 

Für kundeneigene entwicklungen sind entsprechende sperrobjekte mit den zugehörigen 

sperrfunktionen zu implementieren. 

die sperren sind nach abschluss des updates auf das objekt aufzuheben. dies erfolgt mittels 

aufruf des dequeue-Funktionsbausteins. Beachten sie dabei den wichtigen scope-Parameter, 

wenn in diesem zusammenhang auch Verbuchungsbausteine verwendet werden. 


1. http://help.sap.com/saphelp_nW70/helpdata/de/7b/f9813712f7434be10000009b38f8cf/frameset.htm 

4.2.2 Verbuchungskonzept 

die Verbuchung ist die zentrale technik zur Bündelung von datenbankänderungen in einer einzigen 

datenbank-LuW und damit zur definition von saP-LuWs in saP-transaktionen. datenänderungen 

sollen nicht mit dML-Kommandos (dataManipulati-onLanguage-Kommandos insert, update, 

delete, Modify) aus der applikation, sondern über den Verbucher durchgeführt werden.

dabei stehen folgende Möglichkeiten zur Verfügung: 

> asynchrone Verbuchung 

> asynchrone Verbuchung in abschnitten 

> synchrone Verbuchung 

die Verbuchung wird mit eigenen Verbuchungsfunktionsbausteinen durchgeführt. diese sind bei 

der anlage entsprechend in den eigenschaften zu kennzeichnen. diese Funktionsbausteine werden 

mit dem zusatz „in uPdate tasK“ aufgerufen und unterliegen bei der entwicklung einigen 

restriktionen. alle bis zu einem „CoMMit WorK“ gerufenen Verbuchungsfunktionen werden in 

einer LuW auf die datenbank geschrieben. 

Beim aufruf der sperrfunktionsbausteine ist auf die korrekte Parametrierung (insbesondere 

sCoPe-Parameter) zu achten! 

Fehlerhafte Verbuchungssätze müssen in der transaktion Verbuchungsaufträge (sM13) administriert 

und nachbehandelt werden. aus revisionsgründen ist es empfehlenswert, die nachbearbeitung 

der fehlerhaften Verbuchungssätze zu dokumentieren. 


1. saP dokumentation „techniken der Verbuchung“: 

http://help.sap.com/saphelp_nw70/helpdata/de/41/7af4cba79e11d1950f0000e82de14a/content.htm 

4.2.2.1 asynchrone Verbuchung 

die Funktionsbausteine werden in den eigenschaften mit „start sofort“ oder in ausnahmefällen mit 

„start sofort – nicht nachverbuchbar“ angelegt. die Verbuchung wird sofort nach abschluss der 

LuW gestartet, jedoch asynchron durchgeführt. 

4.2.2.2 asynchrone Verbuchung in abschnitten 

die Funktionsbausteine werden in den eigenschaften mit „start verzögert“ angelegt. die Verbuchung 

wird sofort nach abschluss der LuW gestartet, wird jedoch asynchron in eigenen Prozessen 

mit niedriger Priorität durchgeführt. diese art der Verbuchung ist für das schreiben von großen 

datenmengen geeignet, wenn die Verbuchung nicht zeitkritisch erfolgen muss (z.B. Ladeprogramme, 

Protokollierung ...). 

4.2.2.3 synchrone Verbuchung 

die Funktionalität und die notwendigen einstellungen sind analog zu jenen im Punkt 4.2.2.1 

asynchrone Verbuchung. die LuW muss jedoch mit „CoMMit WorK and Wait“ abgeschlossen 

werden. 

diese art der Verbuchung wird dann gewählt, wenn die geänderten daten sofort benötigt werden, 

z.B. wenn man LuWs koppeln will und eine LuW vom ergebnis der vorherigen LuW abhängt. 

25 


26 

4 roBustHeit 

4.3 ProtoKoLLierunG 

Generell sollten Fehler, ausnahmen und Meldungen ins Business application Log gespeichert 

werden, um diese an zentraler stelle (transaktion sLG1) prüfen zu können. Mit der transaktion 

sLG0 können darüber hinaus eigene objekte zur Protokollierung definiert werden. 

der Vorteil bei der Verwendung des Business application Logs liegt in folgenden aspekten 

begründet: 

1. zentrale ablage: im Business application Log können Meldungen an zentraler stelle verwaltet 

werden; dies erleichtert den Überblick und die administration der anwendungen 

2. Wiederverwendbarkeit: das Business application Log bzw. die zugehörigen Bausteine/Klassen 

bieten einen guten Funktionsumfang für das thema Logging – dieser muss nicht „neu erfunden“ 

werden. zu diesen Möglichkeiten zählen u.a. 

a. integration zusätzlicher Felder in die Protokollierungsobjekte 

b. Hierarchiedarstellung von Meldungen (zusammenfassung zu Problemklassen möglich) 

c. interaktivität (nachlesen von informationen bei aufruf einer Meldung und anreichern von 

informationen) 

d. Persistenz: speicherung von Meldungen im Log möglich 

e. integration der Protokollanzeige in eigene anwendungen/uis (sub-screen/Control/Popup) 

BEST PRACTICE: Für die Protokollierung sollten die von saP vorgesehenen Funktionsbausteine in 

der Funktionsgruppe sBaL verwendet werden. die Beispielprogramme „sBaL_deMo*“ bieten 

einen guten einstieg und Überblick. 

Bitte beachten sie bei der implementierung die saP-standardhilfe bzgl. der Verwendung der 

Funktionsbausteine im jeweiligen release. 


1. saP application Log – Leitfaden für anwender 

http://help.sap.com/saphelp_nw70ehp2/helpdata/de/3a/c8263712c79958e10000009b38f936/ 

frameset.htm 

2. Beispiele zur Verwendung der BaL Funktionen in: 

thorsten Franz, tobias trapp, „anwendungsentwicklung mit aBaP objects, saP Press, isBn-10: 

3836210630 

4.4 PraxisBeisPieLe 

in diesem abschnitt finden sich noch einige robustness-Probleme, die in audits immer wieder 

auftauchen. 

4.4.1 unvollständige Fallunterscheidungen 

Für Case statements wird empfohlen, alle vorhandenen WHen-Blöcke auszuprogrammieren. 

außerdem sollte immer ein WHen otHers-Block vorhanden sein, um Fälle zu behandeln, die zur 

zeit der entwicklung noch nicht abzusehen waren bzw. unterwartet sind.

Bei iF-abfragen ist darauf zu achten, dass auch die eLse/eLseiF-zweige ausprogrammiert 

werden, sofern diese im jeweiligen Kontext sinn machen. 

4.4.2 Wichtige sonstige sy(st)-suBrC-Prüfungen 

sy-suBrC-Prüfungen sollten möglichst immer stattfinden, wenn aBaP-Befehle rückgabewerte 

liefern. das ist wichtig, um die integrität des systems auch im Fehlerfall zu gewährleisten. es wird 

daher empfohlen, zumindest im umgang mit dateien und datenbanktabellen Prüfungen auf 

sy(st)-suBrC durchzuführen. 

im Folgenden sind die relevanten aBaP-Befehle gelistet, für die sy(st)-suBrC aus sicht der 

robustheit immer geprüft werden sollte und die in diesem Kapitel noch nicht erwähnt wurden: 

> oPen dataset 

> read dataset 

> deLete dataset 

> seLeCt sinGLe 

> deLete dbtab 

> ModiFy dbtab 

> insert dbtab 

> uPdate dbtab 

4.5 WeiterFÜHrende QueLLen 

1. Liste einiger Befehle, die sy-suBrC setzen: 

http://wiki.sdn.sap.com/wiki/display/aBaP/sy-subrc 

27 


28 

5 aBaP-siCHerHeit und CoMPLianCe 

dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im aBaP negativ auf die 

sicherheit eines unternehmens auswirken können. da dieses thema sehr komplex ist, können wir 

im rahmen dieses dokuments nur ein paar ausgewählte, zentrale themen behandeln. Für 

weitergehende Fragen verweisen wir auf die Literaturhinweise am ende dieses Kapitels. zunächst 

müssen wir die Begriffe sicherheit und Compliance in diesem Kontext erklären: 

Wir sprechen von einer sicherheitsschwachstelle, wenn ein Programmierfehler einen ungewollten 

nebeneffekt verursacht, durch den ein angreifer unbefugt schadhafte aktionen ausführen kann. 

Wir sprechen von einem Compliance-Verstoß, wenn ein anwender aufgrund eines Programmierfehlers 

einen prüfungsrelevanten sicherheitsmechanismus des saP-standards umgehen kann. 

ein wichtiger unterschied ist, dass sicherheitsfehler im Code angriffe durch Hacker (z.B. 

industriespionage) ermöglichen, wohingegen Compliance-Verstöße im Code potenziell gesetzliche 

auflagen verletzen (z.B. sox) und/oder bei einer Wirtschaftsprüfung moniert werden. 

5.1 PrÜFunGsreLeVante siCHerHeitsMeCHanisMen iM 

saP standard 

Bevor wir näher auf schwachstellen eingehen, ist es wichtig, sich noch einmal ein paar zentrale 

schutzmechanismen des saP-standards vor augen zu führen. diese sind Grundvoraussetzung für 

den sicheren Betrieb von saP-systemen. 

5.1.1 Berechtigungsprüfung (a) 

rollen und Berechtigungen sind ein zentrales sicherheitsthema im saP-umfeld. es ist daher 

wichtig zu verstehen, dass aBaP ein sogenanntes explizites Berechtigungsmodell verwendet. das 

bedeutet, dass Berechtigungsprüfungen explizit im Code programmiert werden müssen, damit sie 

auch ausgeführt werden. das beste Berechtigungskonzept nützt nichts, wenn selbstgeschriebener 

Code die erforderlichen Berechtigungen nicht (richtig) prüft. 

sicherheitsprobleme ergeben sich z.B. in folgenden Fällen: 

> der entwickler vergisst, die Berechtigungsprüfung zu programmieren. 

> der entwickler verwendet das falsche Berechtigungsobjekt. 

> der entwickler verwendet eine proprietäre Berechtigungsprüfung. 

> der entwickler behandelt den rückgabewert der Prüfung nicht. 

5.1.2 Mandantentrennung (B) 

der saP-standard trennt automatisch alle datenbankzugriffe nach Mandanten auf. ein aBaP- 

Programm darf immer nur die daten des Mandanten verarbeiten, an dem sich der anwender angemeldet 

hat. 

sicherheitsprobleme ergeben sich in folgenden Fällen: 

> der entwickler umgeht die Mandantentrennung (vorsätzlich) durch technische optionen im 

open sQL (CLient sPeCiFied). 

> der entwickler verwendet natives sQL, das generell keine implizite Mandantentrennung 

durchführt.

5.1.3 nachvollziehbarkeit (C) 

die meisten Geschäftstransaktionen müssen nachvollziehbar sein, insbesondere in der Finanzbuchhaltung. 

selbstgeschriebener aBaP Code darf anwendern nicht ermöglichen, relevante 

aktionen zu verschleiern. 


> der entwickler vergisst, für wichtige tabellen Änderungsbelege zu schreiben. 

> der entwickler ermöglicht (unbeabsichtigt) einen sogenannten identitätsdiebstahl. 

> der entwickler verändert direkt tabelleninhalte, ohne standardfunktionsbausteine zu verwenden 

(und damit implizit die Protokollierung zu verwenden). 

5.1.4 dreisystemlandschaft (d) 

der saP-standard sieht vor, für entwicklung, Qualitätssicherung und Produktion getrennte 

systeme (d, Q, P) zu verwenden. dies dient in erster Linie dazu, die Produktivdaten vor unzureichend 

getesteten Programmen zu schützen und die umfangreichen rechte der entwickler auf das 

entwicklungssystem zu beschränken. 


> der Code kann nicht (vollständig) auf dem Q-system getestet werden. 

> der entwickler verwendet Befehle, die es anwendern möglich machen, auf dem Produktivsystem 

Code zu entwickeln. 

5.1.5 Kontrollierte ausführung von Betriebssystemkommandos (e) 

aBaP hat die Möglichkeit, auch Betriebssystemkommandos auszuführen. da das potenziell sehr 

gefährlich ist, stellt der standard transaktionen (sM49/sM69) zur Verfügung, mit denen man eine 

Liste erlaubter Befehle definieren und die erlaubten Befehle auch noch durch spezielle Berechtigungen 

zusätzlich schützen kann. 


> der entwickler verwendet einen alternativen Weg, um Betriebssystemkommandos auszuführen. 

d.h., er umgeht die Liste der erlaubten Befehle und die daran gekoppelten Berechtigungen. 

5.1.6 Kontrollierte ausführung von sQL-Befehlen (F) 

der open-sQL-standard ermöglicht den zugriff auf die datenbank von aBaP aus nur mit einem 

sehr limitierten satz an Befehlen, die zusätzlich alle statisch deklariert werden müssen. dadurch 

können gefährliche sQL-Befehle in der datenbank abgeschirmt werden. 


> der entwickler verwendet native sQL-Befehle, um mit der datenbank zu kommunizieren. 

dadurch können beliebige Befehle ausgeführt werden, die die datenbank beschädigen. 

> der entwickler verwendet dynamische optionen von open-sQL-Befehlen und ermöglicht dadurch 

injection-angriffe. 

29 


30 


5.2 siCHerHeitssCHWaCHsteLLen 

applikationssicherheit ist in vielen Programmiersprachen schon seit Jahren ein wichtiges thema. 

in aBaP wurde dieses thema jedoch häufig nicht erkannt bzw. falsch eingeschätzt. ein wesentlicher 

Grund dafür ist der falsche Glaube, dass man saP-systeme durch rollen und Berechtigungen 

absichern kann. dies mag für den saP-standard zutreffen, aber definitiv nicht für selbst- 

entwickelten Code. Wie bereits weiter oben erläutert, werden z.B. Berechtigungen nur geprüft, 

wenn der aBaP Code eine Prüfung auch explizit durchführt. 

Folgende arten von schwachstellen sind im aBaP besonders häufig zu beobachten: 

> Fehlende bzw. falsche Berechtigungsprüfungen 

der aBaP Code führt operationen aus, für die ein Berechtigungsprüfung erforderlich ist, 

überprüft aber die Berechtigung des Benutzers nicht bzw. nicht richtig. 

> injection-Probleme 

der aBaP Code verwendet dynamische Befehle, die aus Benutzereingaben zusammengefügt 

werden. Wenn hier nicht durch input-Validierung bzw. output-encoding verhindert wird, dass 

steuerzeichen in den eingaben die semantik des dynamischen Befehls verändern können, dann 

kann der dynamische Befehl zur Laufzeit schadhaft verändert werden. 

> aushebelung von sicherheitsmechanismen des standards 

aBaP Code darf einen bestehenden sicherheitsmechanismus nicht gezielt umgehen. Beispiele 

sind proprietäre Berechtigungsprüfungen (basierend auf sy-unaMe), mandantenübergreifende 

datenbankzugriffe, ausführung von Betriebssystemkommandos über Kernelfunktionen. 

Folgende schwachstellen sind im aBaP besonders häufig zu beobachten. die spalte „std“ zeigt 

dabei an, welcher sicherheitsmechanismus des saP-standard dabei beeinträchtigt wird. 

id schwachstelle Beschreibung std 

aPP-01 aBaP Command injection ausführung von beliebigem 

aBaP Code 

aPP-02 os Command injection ausführung beliebiger 

Betriebssystem-Kommandos 

aPP-03 native sQL injection ausführung beliebiger nativer 

sQL-Kommandos 

aPP-04 improper authorization 

(Missing, Broken, Proprietary, 

Generic) 

Fehlende oder fehlerhafte 

Berechtigungsprüfung 

aPP-05 directory traversal unerlaubter schreib-/ 

Lesezugriff auf dateien (saP 

server) 

aPP-06 direct database Modifications unberechtigter schreibzugriff 

auf tabellen 

d 

e 

F 

a 

C

id schwachstelle Beschreibung std 

aPP-07 Cross-Client database access Mandantenübergreifender 

zugriff auf Geschäftsdaten 

aPP-08 open sQL injection schadhafte Manipulation von 

datenbankbefehlen 

aPP-09 Generic Module execution unerlaubte ausführung von 

Modulen (reports, FuBas etc.) 

aPP-10 Cross-site scripting Manipulation des Browser ui, 

diebstahl von Berechtigungen 

aPP-11 obscure aBaP Code einschränkte auditierbarkeit 

durch Verschleierung von Code 

abbildung 1: BizeC aPP/11 – die derzeit verbreitetsten sicherheitsprobleme in aBaP-Code 

QUELLE: http://www.bizec.org/wiki/BizeC_aPP11 

dieses Kapitel kann bei Weitem nicht die notwendigen details liefern, um sicheren aBaP-Code zu 

programmieren. Wir verweisen hier auf die Literaturempfehlung #1 am ende des Kapitels. 

die folgende Liste enthält eine Übersicht über saP-Meldungen, die Gegenmaßnahmen zu einigen 

der oben beschriebenen Probleme beschreiben. 

saP note schwachstelle 

1520356 sQL injection 

887168, 944279, 822881 Cross-site scripting 

1497003 directory traversal 

abbildung 2: saP oss notes, die Gegenmaßnahmen beschreiben 

selbstverständlich empfiehlt es sich, saP-sicherheitshinweise zeitnah zu prüfen und einzuspielen. 

diese lösen allerdings nur sicherheitsdefekte im saP-standardcode. eine regelmäßige Prüfung 

der eigenentwicklungen ist daher zwingend erforderlich. 

5.3 CoMPLianCe-ProBLeMe durCH aBaP 

das thema applikationssicherheit wurde in der Vergangenheit selten mit Compliance in Verbindung 

gebracht, ist aber für Wirtschaftsprüfungen durchaus relevant (siehe Literaturempfehlung #2). 

die meisten unternehmen verfügen über ein internes Kontrollsystem (iKs), das Compliancerisiken 

entgegenwirkt. dies ist beispielsweise in den international anerkannten referenzmodellen 

Coso & CoBit beschrieben. in einer typischen iKs-struktur sind die „Generellen it-Kontrollen“ 

(itGC-it General Controls) Voraussetzung für das erreichen aller iKs-ziele im it-dominierten umfeld. 

B 

F 

a 

C 

d 

31 


32 


ein elementarer Baustein der itGC ist das Änderungswesen (Change Management), zu dem 

wiederum eigenentwicklungen zählen. sicherheitsdefekte im selbstgeschriebenen aBaP-Code 

stellen eine Verletzung der generellen it-Kontrollen dar und erschüttern damit die Grundmauern 

jedes internen Kontrollsystems. 

abbildung 3: iKs-risiken durch unsicheren aBaP-Code 

dies bedeutet insbesondere, dass sicherheitsdefekte im aBaP-Code potenziell nicht nur 

auswirkungen auf Compliance-standards haben, sondern auch gesetzliche anforderungen 

verletzen können. 

alle in abbildung 1 dargestellten sicherheitsdefekte sind daher auch Compliance-relevant. 

5.4 testWerKzeuGe 

Für aBaP-sicherheitstests eigenen sich insbesondere sogenannte statische Codeanalyse-tools. 

es gibt hier verschiedene kommerzielle anbieter, die in wesentlichen Bereichen die Möglichkeiten 

des Code inspectors erweitern: 

> analyse des saP-standard-Codings, insbesondere von aPi-aufrufen 

> sehr hohe scan-Geschwindigkeiten für Continuous Monitoring 

> Globale daten- und Kontrollflussanalysen, da diese für die meisten sicherheitstests elementar 

sind. 

> umfangreiche Beschreibungen des Problems mit Lösungsvorschlägen 

> Hinreichende testabdeckung (oWasP top 10 und sans 25 reichen nicht, da überwiegend 

Web-spezifisch und auf aBaP kaum anwendbar) 

> 4-augen-Prinzip bei ausnahmen

natürlich muss so ein tool hinreichend in se80, tMs und CharM integriert sein, damit die 

entwickler damit arbeiten können und wollen. 

5.5 WeiterFÜHrende QueLLen: 

1. andreas Wiegenstein, Markus schumacher, sebastian schinzel, Frederik Weidemann, sichere 

aBaP Programmierung, saP Press 2009 

2. Maxim Chuprunov , Handbuch saP-revision, saP Press 2011 

3. BizeC - the Business application initiative (http://bizec.org) 

33 


34 

6 doKuMentation 

die dokumentation von software ist in vielen Fällen genauso wichtig wie die entwicklung selbst. 

Fehlt die dokumentation oder ist diese nicht in ausreichendem Maß vorhanden, führt dies 

spätestens bei der Weiterentwicklung oder dem Wechsel von entwicklern zu erhöhten aufwänden. 

in diesem Kapitel werden unterschiedliche Möglichkeiten zur dokumentation von entwicklungsobjekten 

im saP system dargestellt. 

6.1 doKuMentation unaBHÄnGiG Von entWiCKLunGsoBJeKten 

neben der Beschreibung der vielen entwicklungsobjekte, die einzelne, sehr spezielle Funktionen 

im aBaP-system übernehmen, gibt es auch den Bedarf, die größeren zusammenhänge innerhalb 

und zwischen Modulen darzustellen. dazu gehören z.B. antworten auf Fragen wie: 

> Welche abhängigkeiten gibt es zwischen n Modulen? 

> Wie werden Prozesse auf reports abgebildet? 

> Welche Läufe finden wann am tag / im Monat / Jahr statt und welche entwicklungsobjekte sind 

davon betroffen? 

Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes ablagemedium 

innerhalb des saP-entwicklungssystems, das insbesondere Grafiken gut integriert. Wir 

empfehlen daher, für die dokumentation dieser übergreifenden zusammenhänge auf andere 

Medien außerhalb des saP-systems zurückzugreifen. Beispiele dafür sind: 

> interne (Produkt-)Wikis 

> dokumente in gepflegten öffentlichen Verzeichnissen (Portalablage, sharepoint, Fileshare …) 

die erfahrung zeigt, dass die Herausforderung in diesem Bereich primär in der Frage der disziplin 

liegt. diese Herausforderung kann kein tool lösen, sondern nur das entwicklungsteam und die 

zugehörige -leitung. 

darüber hinaus sei angemerkt, dass veraltete dokumentation irreführend sein kann. insofern 

sollte in dokumenten der stand und eine Versionierung enthalten sein, um die aktualität bewerten 

zu können. 

innerhalb einer saP-systemlandschaft bietet der saP solution Manager Möglichkeiten zur 

Projektdokumentation. die nachfolgenden Links bieten weitere informationen dazu. 


1. Help.sap.com dokumentation saP solution Manager 7.1: 

http://help.sap.com/saphelp_sm71_sp05/helpdata/en/3d/d05893e6ba4dfab7c0d66de8d52420/ 

frameset.htm 

2. sCn Blog: „Business process documentation with saP solution Manager 7.1” 

http://scn.sap.com/blogs/ben.schneider/2011/11/04/business-process-documentation-with- 

sap-solution-manager-71

6.2 doKuMentation Von entWiCKLunGsoBJeKten 

neben Methoden, Funktionsbausteinen und reports, die dokumentation im Quelltext enthalten 

können, existieren weitere entwicklungsobjekte im aBaP-system, die keinen Quelltext beinhalten 

und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind: 

> interfaces 

> ddiC-objekte 

> transaktionen 

BEST PRACTICE: Wir empfehlen, für alle entwicklungsobjekte, unabhängig von Quelltexten, die 

Möglichkeiten zur dokumentation der aBaP Workbench zu nutzen und die aufgaben und 

Bedeutungen dieser objekte im saP-system zu dokumentieren. im Vergleich zur dokumentation 

im Quelltext ist hier der Änderungsverlauf nicht im Vordergrund, sondern der ist-stand sollte hier 

dargelegt werden. 

da die dokumentation auch an das transportwesen angeschlossen ist, steht diese dokumentation 

in allen stages einer systemlandschaft zur Verfügung. Weiterhin kann die dokumentation von allen 

Benutzern eingesehen werden und wird in einigen Fällen (reports) vom aBaP-system automatisch 

in die Benutzungsoberfläche eingebunden. ein weiterer Vorteil besteht darin, dass diese dokumentation 

übersetzbar ist. 

6.3 doKuMentation iM QueLLtext 

6.3.1 dokumentation und Kommentierung von anweisungen/anweisungsblöcken 

Generell sollten anweisungsblöcke im Quelltext (kurz) kommentiert werden, damit ein schnelles 

zurechtfinden in fremden Programmen ermöglicht wird. dabei soll in einer Kommentarzeile kurz 

beschrieben werden, welche aufgabe der nächste anweisungsblock hat. dokumentieren sie 

insbesondere, warum sie etwas machen, nicht wie. dabei gilt der Grundsatz: so wenig Kommentar 

wie möglich, so viel Kommentar wie nötig. Vermeiden sie daher redundante informationen (wie 

name des dokumentierten Moduls, den letzten Änderer etc). 

BEST PRACTICE: als Kommentierungssprache sollte englisch verwendet werden. entwicklungsteams 

arbeiten heutzutage überwiegend international zusammen. auch wenn sie derzeit rein 

deutschsprachig entwickeln, kann ihr Projekt im Laufe der zeit internationalisiert werden. der 

aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht, 

steht in keinem Verhältnis zu dem vielleicht größeren aufwand durch englische dokumentation. 

es hat sich außerdem gezeigt, dass die Lesbarkeit von Code und Kommentaren besser ist, wenn 

die Kommentare englisch sind. denn die aBaP-Befehle selbst sind englisch und im stil von sätzen 

aufgebaut. der Leser muss bei englischer dokumentation also nicht ständig beim Lesen des 

Quelltextes die sprache wechseln. 

35 


36 

6 doKuMentation 

6.3.2 dokumentation von Änderungen 

ab dem zeitpunkt der Produktivsetzung eines Programms müssen Änderungen in Programmen 

dokumentiert werden. 

6.3.3 Programmkopf 

Änderungen in Programmen werden mit einem namenskürzel (z.B. Vorname + nachname), dem 

tagesdatum und dem Change document der Änderung im Programmkopf dokumentiert. dabei 

soll zumindest im Programmkopf auch die erläuterung des namenskürzels stehen, hilfreich ist es 

jedoch auch, die Beschreibung direkt bei der Änderung einzufügen. Hierdurch kann auf einen Blick 

der Grund der Änderung im Code erfasst werden. 

Beispiel: 

*/ Change Log 

*/ Vn/date 

Changedoc description 

*/ Mz/2012-08-06 Cd4712 add MMsta in output, Max Mustermann 

*/ Mz/2012-02-01 Cd4711 import Material number, Max Mustermann 

*/ MM/2009-01-01 Cd0815 added Field aBC in method signature and source code in 

order to support quick search, Max Mustermann 

in der Beschreibung der Änderung sollte die Frage „Wer hat Was, Warum und Wie geändert“ 

beantwortet werden. 

Werden für die Koordination der Weiterentwicklung Change-Management- oder Bug-trackingsysteme 

eingesetzt, sollten in diesem Kommentar Verweise auf die Vorgänge/issues enthalten 

sein. damit lässt sich später auch im Quelltext nachvollziehen, welche erweiterung/Fehlerbehebung 

auslöser für eine Änderung war. 

BEST PRACTICE: der Kommentar ist nicht für den Verfasser, sondern für andere entwickler 

gedacht. Führen sie sich das bei der erstellung von Kommentaren bzw. deren review immer 

wieder vor augen. 

Programmzeilen – optional 

die geänderten Programmzeilen können mit der Kombination namenskürzel und tagesdatum der 

Änderung dokumentiert werden. Hinter dem datum kann ein Punkt gesetzt werden, sodass der 

Pretty Printer die Kommentierung automatisch nach rechts ausrichtet. 

alte dokumentationen von Änderungen, die nicht mehr benötigt werden, sollten aus Gründen der Les- 

barkeit wieder entfernt werden. oberstes ziel sollte stets die gute Lesbarkeit von Quelltexten sein.

einfache Änderung 

*Write: lw_mara-matnr. „ Mz/2012-08-06 Cd4712 Cd4711 add MMsta in output 

Write: lw_mara-matnr, lw_mara-mssta. 

Blockänderung – Löschen von anweisungen 

„--> Mz/2012-02-01 Cd4711 import Material number 

*ConCatenate wa_import-aufnr wa_import-vornr 

* into str seParated By ‚ ‚. 

„--> Mz-2012-02-01. deLete 

Blockänderung – einfügen von anweisungen 

„--> Mz/2012-02-01 Cd4711 import Material number 

ConCatenate wa_import-aufnr wa_import-vornr wa_import-matnr 

into str seParated By ‚ ‚. 

„--> Mz/2012-02-01. insert 

Verweis auf stern bzw. anführungszeichen als Kommentar 

stern-Kommentare sollten nur im Programmkopf oder für das auskommentieren von altem Code 

verwendet werden. 

Für alle anderen Kommentare empfiehlt die saP inline-Kommentare zu verwenden. diese sollten 

jeweils vor dem Code stehen, den sie dokumentieren, und auch so eingerückt sein wie dieser Code. 


Keller, thümmel, aBaP-Programmierrichtlinien, saP Press 2009 

37 


38 

7 uMsetzBarKeit und durCHsetzBarKeit 

dieses Kapitel beschreibt, wie sich die Best Practices aus dieser Guideline in der Praxis verwirklichen 

lassen. Wir unterscheiden hierbei umsetzbarkeit und durchsetzbarkeit der richtlinien. 

im abschnitt „umsetzbarkeit“ erklären wir, worauf ein unternehmen achten sollte, das Programmierrichtlinien 

einführen möchte. Wir erklären, wie ein Prozess dafür aussehen könnte, wie man 

diesen ins Leben ruft und vor allem, wie man ihn am Leben erhält. im abschnitt „durchsetzbarkeit“ 

legen wir dar, wie ein unternehmen die Vorgaben aus dem Prozess prüfen kann. Hierzu 

gehören organisatorische aspekte genauso wie Prüfmethoden und Werkzeuge. Wir gehen aber 

auch auf Grenzen der durchsetzbarkeit ein. 

abschließend stellen wir tipps aus der Praxis vor, die die autoren bei verschiedenen Projekten im 

umfeld der saP-entwicklung gesammelt haben. 

7.1 uMsetzBarKeit 

Wer erfolgreich Programmierrichtlinien in einem unternehmen einführen möchte, muss zunächst 

das Management dafür gewinnen. denn die Verbesserung der Codequalität bedeutet zunächst eine 

investition in Prozesse und Werkzeuge sowie in die Fortbildung der involvierten Mitarbeiter. 

insbesondere muss das Management überzeugt sein, dass das unternehmen durch diese 

Prozesse langfristig Kosten spart. 

7.1.1 Motivation für einen Prozess 

nachfolgend finden sie anhaltspunkte, welche Qualitätsaspekte bei der einführung eines 

Prozesses zur Qualitätssicherung adressiert werden und welche Vorteile dies für unternehmen 

hat: 

sicherheit 

Vorteil: das unternehmen verhindert, dass anwender unbefugt an kritische daten gelangen bzw. 

unbefugt kritische daten verändern können. 

risiken bei Qualitätsmängeln: sabotage, industriespionage, unerwünschte Pressemeldungen 

hervorgerufen durch datenlecks, stillstand der Produktivsysteme. 

Compliance 

Vorteil: das unternehmen kann jederzeit nachweisen, dass die entwickelte software den 

anforderungen relevanter Compliance-standards und gesetzlichen regelungen genügt. 

risiken bei Qualitätsmängeln: die Wirtschaftsprüfung scheitert, Verstoß gegen Compliance-anforderungen 

oder gesetzliche regelungen (z.B. datenschutz). 

Performance 

Vorteil: das unternehmen stellt sicher, dass die vorhandene Hardware optimal genutzt werden 

kann, und schützt damit die bisherige investition in Hardware. außerdem steigt die zufriedenheit 

der Mitarbeiter, da die nutzung der anwendung produktiver wird. 

risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt bzw. es entstehen Kosten für 

schnellere Hardware, um die softwaremängel auszugleichen.

obustheit 

Vorteil: das unternehmen stellt den kontinuierlichen Betrieb der Geschäftsanwendungen sicher 

und vermeidet unproduktivität auf Grund von systemausfällen. 

risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt und die Betriebskosten steigen 

wegen unproduktivität der anwender sowie durch Fehleranalysen und Wartungsarbeiten durch 

techniker. 

Wartbarkeit 

Vorteil: das unternehmen erreicht, dass die applikation nachhaltig und kosteneffizient gewartet 

werden kann, weil die Programmstruktur leicht verständlich und gut dokumentiert ist. 

risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte Fehleranfälligkeit der 

applikation. 

7.1.2 erstellung und Pflege des Prozesses 

Für die umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschreibung eines 

Prozesses bewährt. dazu zählen klare Verfahrensanweisungen und Verantwortlichkeiten. die 

genaue ausprägung des Prozesses ist unternehmensspezifisch und kann in dieser Guideline nicht 

abgebildet werden; der Verweis auf die notwendigkeit ist jedoch allgemeingültig. 

BEST PRACTICE: definieren sie den einzuhaltenden Prozess und dokumentieren sie ihn in einer 

für alle zugänglichen Form. definieren sie, wie Änderungen und Verbesserungen am Prozess 

stattfinden sollen und wie anmerkungen und Kritik eingebracht werden können. dokumentieren 

sie alle geprüften regeln ausführlich mit den Kapiteln Hintergrund/Motivation, schlechte 

Beispiele, gute Beispiele, Hinweise zum Vorgehen zur Beseitigung und Literatur bzw. ansprechpartner 

im unternehmen. 

Motivation 

ein Prozess für Best Practices bei der entwicklung hilft, die Qualität von software pro aktiv und 

effizient zu verbessern und damit Kosten im unternehmen langfristig zu senken. Je früher ein 

Fehler bei der entwicklung erkannt wird, desto einfacher und kostensparender kann er behoben 

werden. Je weniger Fehler eine anwendung enthält, desto mehr entspricht ihre nutzung den 

erwartungen des unternehmens. insbesondere läuft sie ohne nebeneffekte, die das Business 

negativ beeinflussen. 

Welche aspekte sind für den Prozess relevant? 

interne entwicklung 

Für die interne entwicklung werden richtlinien als nachschlagewerk für die tägliche arbeit und 

regelmäßige trainings für aktuelle risiken benötigt. 

externe entwicklung 

Bei externer entwicklung sind klare Qualitätsvorgaben für ausschreibungen nötig. Vor der 

abnahme müssen die anforderungen auch überprüft werden. 

Übergreifend 

die Vorgaben aus dem Prozess müssen möglichst weitgehend mit geeigneten tools überprüft 

werden. eine manuelle Prüfung ist nur in seltenen Fällen flächendeckend möglich. 

39 


40 


BEST PRACTICE: Vorgaben ohne werkzeuggestützte Überprüfungsmöglichkeit sind nicht 

umsetzbar und sollten daher nicht definiert und vorgegeben werden. 

Bei jeder regel, die zur nachträglichen Qs herangezogen werden soll, muss festgelegt werden, wie 

diese werkzeuggestützt überprüft werden kann. Wenn keine mechanische Überprüfung durch ein 

Werkzeug möglich ist, wird es in der Praxis nahezu unmöglich werden, auf die konsequente 

einhaltung der regel zu achten. die Konzentration auf maschinell überprüfbare regeln erspart 

denjenigen, die Qualitätssicherung betreiben sollen, eine Vielzahl an Frustrationsquellen. 

nichtsdestotrotz gibt es etliche aspekte, die sich einer maschinellen Prüfung entziehen. diese 

aspekte können sinnvollerweise nur mit regelmäßig durchgeführten Code reviews abgedeckt 

werden. da gut durchgeführte Code reviews erhebliche aufwände in der durchführung, aber auch 

der Vor- und nachbereitung bzw. Kontrolle von Korrekturen erfordern, müssen diese sich auf 

wenige, aber unter den nicht maschinell prüfbaren aspekten kritischen entwicklungsobjekten 

beschränken. Wenn z.B. die einhaltung von Performance-Vorgaben eine hohe Priorität besitzt, 

sollten in entsprechenden Code reviews nur entwicklungsobjekte mit zugriffen auf datenbanken 

oder umfangreichen Berechnungen beschränkt werden. 

der Prozess muss daher eine Qualitätskontrolle vorsehen, durch die sämtliche entwicklungen 

geprüft werden, bevor sie in den Produktivbetrieb gehen. es muss auch definiert sein, wie mit 

Fehlern verfahren werden soll. der Prozess muss selbstverständlich regelmäßig aktualisiert 

werden, um neue aspekte berücksichtigen zu können. 

7.2 durCHsetzBarKeit 

7.2.1 Manuelle Prüfungen 

Viele der Prüfungen lassen sich automatisieren. es gibt jedoch Bereiche, die sich für eine 

automatische Prüfung nicht eignen, wie beispielsweise dokumentation, architektur oder viele 

funktionale anforderungen. die menschliche sprache ist sehr komplex, daher muss z.B. der inhalt 

von dokumenten und dokumentationen manuell geprüft werden. nur der menschliche Leser kann 

beurteilen, ob ein text sinnvoll, vollständig, verständlich und korrekt ist. eine automatische 

Prüfung kann dabei maximal die existenz in den vorgegebenen sprachen prüfen. es empfiehlt sich 

dennoch ein automatischer test auf nicht-funktionale aspekte. 

Für die manuelle Prüfung ist es wünschenswert, eine vollständige Prüfung anhand der auswertung 

von transportstücklisten vorzunehmen. dabei ist zu berücksichtigen, welche unternehmensinternen 

richtlinien existieren. abhängig von der anzahl der objekte muss eine vollständige oder 

zumindest stichprobenartige Prüfung erfolgen. das Prüfergebnis wird dem entwickler/zuständigen 

zur Verbesserung/Vervollständigung der dokumente/dokumentationen übermittelt. 

ob ein Prozess alle Vorgaben erfüllt, kann nur mittels einer manuellen periodischen Prüfung 

ermittelt werden. Falls sich Vorgaben ändern bzw. Mängel im Prozess aufgedeckt werden, ist der 

Prozess entsprechend anzupassen oder ggfs. neu zu definieren. 

in der Praxis hat sich ein fest eingeplanter zyklischer review des Prozesses bewährt.

Wann und wie sollte geprüft werden? 

die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf aktualität und Konformität 

bzgl. der Vorgaben geprüft werden. die aktualität ist jedenfalls mit einem upgrade auf ein neues 

release (enhancement Package) zu prüfen. Bzgl. der Vorgaben ist es durchaus sinnvoll, das 

Wirtschaftsprüfungsunternehmen, welches das unternehmen prüft, hinzuzuziehen. Für extern 

entwickelten Code gilt, dass eine Prüfung vor abnahme stattfinden muss. 

Für die akzeptanz der Prüfungen bzw. der Beanstandung im zuge der manuellen Prüfungen ist es 

sinnvoll, im rahmen der entwickler- und Qa-tests (4-augen-Prinzip) die manuell notwendigen 

Prüfungen durch andere entwickler durchführen zu lassen. 

dasselbe gilt für Penetrationstests und Belastungstests. da es sich bei Penetrationstests auch um 

ein kritisches sicherheitsthema handelt, kann es notwendig sein, hierfür in regelmäßigen 

abständen auch externe Partner hinzuzuziehen. 

7.2.2 automatische Prüfungen 

automatische tests decken schnell einen Großteil der notwendigen tests und Prüfungen ab. als 

Hintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne zusätzlichen aufwand 

möglich. diese regelmäßig mit gleicher Qualität durchgeführten tests ermöglichen so den 

entwicklern, ihren Programmierstil zu verbessern. 

Wann und wie sollte geprüft werden? 

die entwickler sollen ein möglichst zeitnahes Feedback bzgl. der Konformität der entwicklungen 

mit den richtlinien erhalten. dazu dienen täglich eingeplante Prüfungen im entwicklungssystem, 

deren ergebnis dem entwickler zur Verfügung gestellt wird. Wichtig ist, dass dieselben tests und 

Metriken bei der Prüfung durch jeden einzelnen entwickler und bei der Prüfung durch zentrale 

Qs-instanzen bzw. bei einer transportfreigabe verwendet werden. sollten für diese Prüfungen 

unterschiedliche Werkzeuge oder unterschiedliche einstellungen verwendet werden, sinkt die 

akzeptanz in entwicklerkreisen ganz erheblich. 

als zentrale schutzinstanz müssen die Prüfungen in das tMs und da spätestens mit der Freigabe 

des transportauftrags (besser der einzelnen transportaufgaben) implementiert sein. damit wird 

sichergestellt, dass keine ungeprüften bzw. nicht den richtlinien entsprechenden entwicklungen in 

die Folgesysteme und dann auch in das Produktivsystem transportiert werden. 

als „letztes sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsystem 

vorzusehen. dieser sollte in einer lastarmen zeit mittels Hintergrundjob eingeplant werden. das 

ergebnis wird dem Qa-zuständigen zur Verfügung gestellt, der dann die weiteren schritte (ggfs. 

Korrektur) mit hoher Priorität veranlasst. 

Bei allen automatischen Prüfungen ist im Vorfeld zu definieren, wie mit altem Code umgegangen 

wird. sinnvoll scheint es hierfür auch, einen Fahrplan zu erstellen, wann und wie die neuen regeln 

auf alten Code angewendet werden. 

41 


42 


7.2.3 Werkzeuge 

nachstehend werden einige tools aufgelistet, mit welchen die automatisierten Prüfungen 

durchgeführt werden können. 

saP Code inspector 

der saP-Code inspector wird seitens saP im standard ausgeliefert und ist entsprechend in die 

entwicklungsumgebung hoch integriert. saP sieht ein erweiterungskonzept vor, welches 

ermöglicht, kundenspezifische Prüfungen selbst zu implementieren. Hierfür sind ggfs. Programmierarbeiten 

notwendig. die seitens saP ausgelieferten Prüfungen können teilweise weitgehend 

parametrisiert werden. inspektionen auch von großen objektmengen können sowohl online als 

auch im Batchbetrieb erfolgen und ergebnismengen von vorangegangenen inspektionen können 

wieder als objektmenge verwendet werden, um die Kontrolle von Korrekturen auf die vorher 

fehlerbehafteten objekte zu beschränken. Weiterhin können ergebnisse auch automatisch per 

e-Mail an die verantwortlichen entwickler verteilt werden. 

Werkzeuge von drittherstellern 

neben dem saP Code inspector gibt es am Markt sehr gute kommerzielle tools, die Prüfungen auf 

Code-ebene vornehmen. eine Beschreibung dieser tools soll aus neutralitätsgründen an dieser 

stelle unterbleiben. 

7.3 erFaHrunGen und tiPPs aus der Praxis 

7.3.1 Qualitätssicherung des Quellcodes 

um eine erfolgreiche einführung zu gewährleisten, ist es wichtig, Qualitätssicherung schrittweise 

und behutsam einzuführen. Hierbei empfiehlt es sich, einen zweigeteilten ansatz zu fahren. 

zunächst sollte neuer Code „fehlerfrei“ erstellt und dies geprüft werden. erst wenn sich dieser 

Prozess stabilisiert hat, sollte nach und nach Bestandscode mit in die Checks aufgenommen 

werden, sonst wird der zu bewältigende Berg für den entwickler zu groß und die Motivation sinkt 

rapide. 

Wenn nicht auf der „grünen Wiese“ mit einer neuen entwicklung begonnen wird, wenn automatische 

Codeprüfungen eingeführt werden, ist es wichtig, vorher den umgang mit „altlasten“ zu 

klären. auch bei neuen entwicklungen lassen sich Änderungen an schon bestehenden objekten 

nicht vermeiden, die dann bei einer eingerichteten transportprüfung zu Problemen führen. 

Hilfreich ist in solchen Fällen eine Klärung der Verantwortlichkeit für entwicklungsobjekte, die z.B. 

durch das entsprechende Feld in Paketdefinitionen dokumentiert werden kann. diese Verantwortlichen 

müssen entscheiden, ob Fehler im Bestandscoding sofort korrigiert werden müssen oder 

eine ausnahmeregelung möglich ist. 

in vielen Fällen ist es schon ausreichend, mit standard-Bordmitteln, wie z.B. Code inspector, zu 

arbeiten, der sich auch um eigene Checks erweitern und somit an eigene Bedürfnisse anpassen 

lässt. im netWeaver 7.02 sind einige neue Prüfungen in der auslieferung enthalten wie suche nach 

bestimmten kritischen anweisungen, Verwendung der adBC-schnittstelle, mandenatenabhängige 

shared-objects-Methoden, robuste Programmierung und aBaP-Webdynpro-Metrik.

7.3.2 zeit und Budget Qa 

um die zeit und den aufwand für die Qa-tätigkeiten möglichst gering zu halten, muss der 

entwickler die Möglichkeit haben, den Code während seiner entwicklertätigkeit selbstständig auf 

Fehler hin untersuchen zu können. 

tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten hingewiesen 

werden. tägliche inspektionen mit einem entsprechenden Werkzeug und Verteilung der ergebnisse 

stellen sicher, dass Fehler frühzeitig erkannt werden und die entwickler sich noch an ihre 

tätigkeiten vom Vortrag erinnern, was die Fehlerbehebung deutlich vereinfacht. so wird gewährleistet, 

dass auch entwickler, die den manuellen aufwand scheuen oder unter zeitdruck stehen, 

trotzdem die Möglichkeit erhalten, ihre Fehler im Code zu beheben. Hier ist zu bemerken, je später 

die Qa einsetzt, desto höher ist der aufwand für die Fehlerbehebung. dieser zusätzliche aufwand 

entsteht z.B. durch zusätzliche transporte, wenn der originaltransport bereits freigegeben wurde. 

deshalb ist es wichtig, bei Planung und schätzung eines Projektes die Qualitätssicherung zu 

berücksichtigen, und zwar nicht nur am ende, sondern projektbegleitend und anschließend im 

kompletten software-Lifecycle. 

nicht zu unterschätzen ist auch der schulungsaufwand, der benötigt wird, um bei den entwicklern 

um Verständnis für den Prozess zu werben. 

Bei einem einsatz von externen entwicklern müssen die Programmierrichtlinien und namenskonventionen 

Bestandteil des Vertrages sein. 

7.3.3 Probleme 

Bei der einführung einer Code Qa treten eine reihe von Problemen auf, auf die hier kurz 

eingegangen wird. 

ein reibungspunkt ergibt sich durch die Frage, wer für die Qa zuständig ist, ersteller oder Änderer. 

Bei neuen sourcen ist dies kein Problem, bei Bestandscode aber wird die Frage immer wieder 

aufgeworfen: 

„Warum soll ich Code überprüfen, in dem ich nur eine zeile geändert haben?“ 

vs. 

„Warum soll ich Code überprüfen, den ich schon Jahre nicht mehr angefasst habe?“ 

Beide Positionen sind natürlich verständlich, deswegen muss eine klare entscheidung bezüglich 

Handhabung von kopiertem Code, der auf anderen/keinen Konventionen beruht, getroffen und 

durchgesetzt werden. 

BEST PRACTICE: um bei auftretenden Problemen die Fragen der entwickler zu beantworten, ist es 

wichtig, dafür eine zentrale stelle zu schaffen. außerdem muss es einen Prozess geben, um in 

notfällen auch fehlerbehaftete transporte freizugeben. Gibt es diese Möglichkeit nicht, sinkt das 

Verständnis für die durchgeführten Maßnahmen. eine Möglichkeit ist es hierbei, einen Genehmigungsprozess 

zu installieren, mit dessen Hilfe auch fehlerbehafteter Code freigegeben oder 

transportiert werden kann. die meisten tools am Markt bieten diese Möglichkeit standardmäßig an. 

43 


44 


7.3.4 entscheidungsfindung bei Modifikationen 

Wichtig ist es, die Hürde für Modifikationen so hoch wie möglich zu legen. dies ist besonders wichtig, 

wenn man sich dazu entscheidet, zeitnah enhancement Packages der saP einzuspielen (sPau- 

Problematik). ansatzpunkt hierzu ist der Modifikationsschlüssel. die anzahl der entwickler, die die 

Berechtigung haben, Modifikationsschlüssel zu generieren, muss möglichst gering sein. so ist es 

möglich, steuernd einzugreifen und diese über Change requests und einen zugehörigen Prozess 

abzuhandeln. 

die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu beantworten 

und konsequent umzusetzen. eine Pauschalantwort auf diese Frage gibt es nicht. in jedem Fall 

sollte die entscheidung jedoch auf gleichartigen, im Vorfeld definierten und kommunizierten 

Kriterien basieren. 

7.3.5 erfahrungsbericht aus der Praxis: Comgroup GmbH 

das nachfolgende Beispiel der Comgroup GmbH, dem it-dienstleister der Würth Gruppe, zeigt wie 

Programmierrichtlinien und namenskonventionen in einer softwareentwicklung ein- und 

durchgesetzt werden können. 

die Comgroup GmbH startete mit der Code Qa im globalen entwicklungssystem einer mehrstufigen 

entwicklungslandschaft. zur automatisierten unterstützung wurde der Code inspector 

eingesetzt. da die Code-Qa-einführung mit der einführung eines neuen namensraumes 

zusammenfiel, wurden zu Beginn des Projekts nur objekte aus dem neuen namensraum geprüft 

und Bestandscode nicht berücksichtigt. dies erleichterte die selektion im Code inspector, da 

dieser keine Änderungs- oder erstellungsdaten bei der selektion berücksichtigt. außerdem 

wurden Performance- und security-Checks aus dem Code inspector vorerst nicht aktiviert, um den 

aufwand in einem überschaubaren rahmen zu halten. 

Hierdurch hat der entwickler die Möglichkeit, seinen Code während seiner entwicklertätigkeit 

selbstständig zu checken. zusätzlich wurde ein nachtlauf eingeplant, der den kompletten zu 

scannenden Code analysiert und bei gefundenen Fehlern Mails an den jeweiligen entwickler 

sendet. Probleme bereitete hierbei, dass es viele user im system gab, die keine zugeordnete 

Mailadresse hatten, was dazu führte, dass zu Beginn Mails ihren empfänger nicht erreichten. 

Mails an entwickler ohne Mailadresse werden an eine zentrale adresse versendet und somit 

können die unvollständigen datensätze mit einem geringen aufwand identifiziert werden. deshalb 

werden nun keine entwicklungs-user mehr im system ohne Mailadresse angelegt. 

die Mails wurden nicht von einem anonymen Batch-user sondern von der Mailadresse des 

Qa-Verantwortlichen gesendet, um dem entwickler einfach die Möglichkeit zu geben, Fragen zu 

stellen. zu Beginn entstand hierdurch ein hoher aufwand, die anzahl der Fragen verringerte sich 

aber mit der Laufzeit des Projekts. dies konnte erreicht werden, da schulungen durchgeführt 

wurden und so die entwickler effizienter die Fehler korrigieren konnten oder diese schon bei der 

entwicklung vermieden.

die entwicklungssprache in der entwicklungslandschaft ist englisch. dies wird durch einen 

weiteren Job geprüft und bei Fehlern dem entwickler gemeldet. saP bietet keine Möglichkeit im 

standard, bei der anlage die richtige sprache zu setzen. deshalb bot sich nur die Möglichkeit, an 

passender stelle eine entsprechende Prüflogik per Modifikation einzubauen oder damit zu leben, 

dass objekte in falscher sprache angelegt werden und danach umgezogen werden mussten. 

Bei anlage von objekten wurden namenskonventionen für die objekte gecheckt, sodass diese nur 

nach Konventionen benannt werden konnten (ebenfalls per Modifikation). 

um eigene Checks bei der transportfreigabe durchzuführen (z.B. eigene namenskonventionen/ 

mind. deutsche und englische Übersetzung) wurde eine implementierung für das Business add in 

Cts_reQuest_CHeCK angelegt und die Methode CHeCK_BeFore_reLease genutzt. 

nachdem der Prozess sich im globalen entwicklungssystem stabilisiert hatte, wurde dieser an die 

nachfolgenden entwicklungssysteme und namensräume ausgerollt. Bestandscode wird bisher 

noch nicht gecheckt. zusätzlich ist geplant, ein externes tool einzusetzen, das die Qualitätssicherung 

vereinfacht. 

45 


46 

8 inFrastruKtur und LiFeCyCLe 

ManaGeMent 

neben methodischen empfehlungen und Werkzeugen zur unterstützung bei der softwareentwicklung 

im saP-system stellen die infrastruktur und die Betrachtung des Lebenszyklus einer 

softwarekomponente eine wichtige rahmenbedingung für erfolgreiches arbeiten dar. in diesem 

Kapitel liegt auf diesen beiden aspekten der Fokus. 

8.1 inFrastruKtur 

eine saP-systemlandschaft ist i.d.r. mehrstufig aufgebaut. nachfolgend werden die einzelnen 

systeme und ihre Bedeutung dargestellt: 

8.1.1 sandbox 

die sandbox ist ein reines test- und „spielsystem“. in der sandbox gelten keine einschränkungen 

in Bezug auf Berechtigungen, das gilt gleichermaßen für Customizing- und Workbench-entwicklungen. 

aus der sandbox sind keine transporte in andere systeme erlaubt. Änderungen können 

ausprobiert werden, bevor sie im entwicklungssystem durchgeführt werden. damit kann der 

rückbau komplexer entwicklungen in der entwicklungsumgebung vermieden werden, wenn z.B. 

eine neuentwicklung nicht weiter verfolgt werden soll. 

8.1.2 entwicklungssystem 

ein kombiniertes entwicklungs-/testsystem (z.B. entwicklungsmandant 010, testmandant 110) 

bietet sich als einfache und praktikable Lösung an. es ist beispielsweise kein transport von 

Workbench-objekten erforderlich, um neuentwicklungen zu testen. 

im testmandanten herrscht dabei absolutes Customizing-Verbot. Customizing dieses Mandanten 

wird ausschließlich durch Mandantenkopie aktualisiert (sCC1). entwickler/Modulbetreuer haben 

im testsystem sehr weitreichende Berechtigungen. einschränkungen müssen individuell festgelegt 

werden, z.B. für besonders sensible daten (Hr etc.). 

Berechtigungen/rollen werden grundsätzlich im entwicklungssystem erstellt und transportiert. 

Generell werden alle zu transportierenden Änderungen in einem Mandanten im e-system 

vorgenommen. 

8.1.3 Qualitätssicherungssystem 

im Qa-system herrscht absolutes Customizing- und entwicklungsverbot. Customizing- und 

Workbench-objekte werden ausschließlich per ta importiert. importe nach Produktion erfolgen 

grundsätzlich über das Qa-system. damit wird die Übereinstimmung einer mit Produktion 

übereinstimmenden systemumgebung sichergestellt. 

das Qa-system wird bei Bedarf z.B. für umfangreichere Validierungsaktivitäten aus dem 

Produktionssystem kopiert. damit wird auch die Übereinstimmung mit der operativen (daten-) 

umgebung sichergestellt. im Qa-system erfolgt die durchführung von testplänen nach Änderungen 

und neuentwicklungen. entwickler/Modulbetreuer haben im Qa-system sehr weit- 

reichende Berechtigungen. einschränkungen müssen individuell festgelegt werden, z.B. für 

besonders sensible daten (Hr etc.). es empfiehlt sich aber auch, testbenutzer mit produktionsnahen 

Berechtigungen zu verwenden.

8.1.4 Produktion 

im Produktionssystem herrscht absolutes Customizing- und entwicklungsverbot. Customizing- 

und Workbench-objekte werden ausschließlich per transportauftrag in dieses system importiert. 

entwickler/Modulbetreuer haben im Produktionssystem nur eingeschränkte Berechtigungen; 

emergency-tabellenänderungen (&saP_edit) sind zu dokumentieren mit datum/uhrzeit und 

Begründung. Hierzu empfiehlt sich die Verwendung eines tools, um die Meldungen zu standardisieren. 

der umgang mit notfall-usern muss technisch und organisatorisch festgelegt werden. 

8.1.5 transportwesen 

Wir empfehlen, die technische Freigabe von transporten grundsätzlich durch interne, verantwortliche 

Bearbeiter durchführen zu lassen, nicht von externen Beratern. Hierbei ist generell die 

formale Freigabe vorausgesetzt (siehe Change-Verfahren). importe werden generell zentral von der 

saP-Basis durchgeführt, ausgenommen die Mandantenkopie innerhalb des test-/entwicklungs- 

systems. 

der transportweg ist wie folgt festgelegt: 

entwicklung -> Qa -> Produktion 

die sandbox sollte aus dem transportweg ausgeschlossen werden. importe in die sandbox 

erfolgen nur auf individuelle anforderung. dabei ist der transportweg immer entwicklung -> 

sandbox, nicht umgekehrt! 

die importe in das Qa-system müssen in abhängigkeit der systemlandschaft organisiert werden. 

Falls möglich, können importe in Qa zyklisch und automatisiert durchgeführt werden, um die 

Mitarbeiter der Basisabteilung zu entlasten. 

importe in das Produktivsystem sind explizit unter angabe der ta-nr. freizugeben. Hierfür wird 

ebenfalls die Verwendung eines geeigneten tools (z.B. solution Manager) zur standardisierung/ 

Formalisierung empfohlen. 

BEST PRACTICE: Checkliste vor ausführung eines Workbench-transports: 

1. tests erfolgt? sämtliche Funktionen wurden erfolgreich getestet und (kundenseitig) abgenommen 

2. Code geprüft? der Code inspector/erweiterte Programmprüfung wurde für alle Programme 

des transportauftrags durchgeführt: die ergebnisliste darf dabei keine Fehler oder 

Warnungen enthalten, informationsmeldungen sind zulässig 

3. drittanbietertools? sofern weitere testtools für themenbereiche wie security, Performance, … 

vorhanden sind, wurden diese eingeplant 

4. Manuelle Vor-/nacharbeiten? es ist zu prüfen, ob eine vollständige Checkliste für manuelle 

Vor-/nacharbeiten zum transport vorliegt 

5. Mehrsprachigkeit? sofern mehrsprachige objekte im transportauftrag enthalten sind, ist zu 

prüfen, ob die Übersetzungen vorhanden sind 

47 


48 


ManaGeMent 

6. abhängigkeiten in den transporten? Falls ein Vorabtransport durchgeführt wurde, muss auf 

abhängigkeiten in den transporten geprüft werden 

7. namenskonventionen? erstellen einer Liste der transportobjekte und Prüfung der einhaltung 

der namenskonvention anhand der objektliste 

8. dokumentation (systemintern)? 

a. systemintern: Prüfung aller objekte hinsichtlich erstellter/aktualisierter saP-dokumentation, 

z.B. 

- reportdokumentation (Beschreibung und in aBaP-Coding) 

- FuBa-dokumentation komplett (Parameter, ausnahmen etc.) 

- datenelemente, strukturen, tabellen (Beschreibung, Überschriften etc.) 

Vorgehensweise: erstellen einer Liste der transportobjekte und Prüfung anhand der 

objektliste 

b. außerhalb des systems: dokumentation vorhanden/vollständig/abgenommen? 

8.1.6 rückbau von neuentwicklungen 

Wenn entwicklungen im entwicklungssystem erstellt, aber nicht weitertransportiert worden sind 

bzw. nur ins Qs-system importiert wurden, sind die Änderungen im entwicklungssystem zurück- 

zubauen. im Falle der nutzung von Quality assurance (Qa) als Genehmigungsworkflow gilt: 

> die ablehnung verhindert lediglich den Weitertransport ins Produktionssystem. die abgelehnte 

entwicklung/Customizing ist aber im entwicklungs- und im Qualitätssicherungssystem noch 

vorhanden. daraus ergibt sich ein „schiefstand“ zwischen den einstellungen einerseits des 

entwicklungs-/Qualitätssicherungssystems sowie andererseits des Produktionssystems. 

> um den schiefstand zu beseitigen, muss die abgelehnte entwicklung im entwicklungssystem 

zurückgenommen, dort in einen transportauftrag aufgenommen und ins Qualitätssystem 

transportiert werden. 

> der transportauftrag, der die rücknahme enthält, soll im Qualitätssystem ebenfalls abgelehnt 

werden. damit wird die Übereinstimmung der einstellungen zwischen den systemen wieder- 

hergestellt. 

> die zuständigen entwickler müssen von abgelehnten transporten erfahren. die Pflicht zur 

informationsweitergabe soll bei den für die Qa-Genehmigungen zuständigen Personen liegen. 

8.1.7 sicherstellung der Konsistenz von neuentwicklungen/erweiterungen 

Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. es kann zur überschneidenden 

Verwendung von objekten kommen, die es im zielsystem (noch) nicht gibt. dies führt 

zum Fehler beim import. Hieraus ergibt sich die Pflicht zur Prüfung der von dritten (non-saP) 

erstellten objekte bei deren Verwendung. neuentwicklungen/erweiterungen müssen in geeigneten 

Paketen bzw. transportaufträgen gekapselt werden. es wird empfohlen, die transportaufträge für 

ein Projekt auf je 1 ta für Workbench, Customizing und Berechtigungsrollen einzuschränken.

‚Vorabtransporte’ sollten nur mit Hilfe von „Kopientransporten“ erlaubt sein. 

die endgültige Freigabe und der transport erfolgt erst zum Projektabschluss. alle Projektmitarbeiter 

verwenden innerhalb eines Projekts nur aufgaben zu einem jeweils vorgegebenen ta. es gibt keine 

‚persönlichen’ transportaufträge für Projektmitarbeiter. 

Generell erfolgt ein import nur nach formeller Freigabe (siehe Change-Verfahren) durch einen 

Process owner, Qs o.ä. instanzen. die abfolge sowie die beteiligten Bereiche müssen unternehmensspezifisch 

festgelegt werden. 

8.2 CHanGe ManaGeMent 

um eine saP-systemlandschaft wartbar und beherrschbar zu gestalten, ist ein formales Change- 

Verfahren die Voraussetzung für jede systemänderung. dabei ist das grundsätzliche Verfahren 

unabhängig davon, ob es sich um Änderungen am saP-standard oder an Kundenentwicklungen 

handelt. 

das Basiswerk zur einführung eines Change- und releasemanagements ist die information 

technology infrastructure Library (itiL). in diesem referenzleitfaden sind umfangreiche und 

allgemeingültige Best Practices beschrieben. 

in diesem Kapitel stellen wir einen konkret realisierten Praxisfall aus der entwicklung dar, der 

firmen- bzw. branchenspezifisch adaptiert werden kann. 

Wir empfehlen grundsätzlich, die folgenden aspekte bei der einführung eines Change-Control- 

(auch: Change-request-)Verfahrens zu berücksichtigen: 

> Fachliche anforderung 

> Begründung 

> Bewertung (aufwandschätzung) 

> Genehmigung 

> Freigabe der Änderung für das Produktionssystem 

der Genehmiger-/Freigeberkreis (Process owner, Qs …) ist abhängig vom Gegenstand der 

Änderung (betroffener Bereich, betroffene anwendung, gegebenenfalls auch aufwand). 

die Verwendung eines geeigneten tools (z.B. solution Manager) wird dringend empfohlen. dabei 

gilt jedoch: eine papierbasierte Lösung ist besser als keine! 

49 


50 


ManaGeMent 

Beispiel für ein Change-Control-Formular (CC): 

abbildung 4: Change-Control-Formular 

das abgebildete CC-Formular enthält beispielhaft die wesentlichen daten, die begleitend zur 

abwicklung einer systemänderung erforderlich sind. 

Basisprozess und rollen: 

> der anforderer füllt den teil ‚anfordernde abteilung’ aus und sorgt für die unterschrift des 

Process owners/des Process owners fremd 

> der Process owner ist in der regel ein Vorgesetzter des anforderers, er ist verantwortlich für 

einen bestimmten teil der daten bzw. für die nutzung bestimmter teile der saP-software, z.B. 

der einkaufsleiter für die saP-einkaufsdaten und -programme 

> der Process owner fremd ist immer dann einzubeziehen, wenn eine Änderung auch teile 

betrifft, die außerhalb der eigentlichen zuständigkeit des Process owners liegen

Beispiel: der einkäufer benötigt Berechtigungen aus dem Bereich der anlagenbuchhaltung; hier 

muss der Process owner zustimmen, der diesen teil des systems verantwortet (z.B. der Leiter 

der anlagenbuchhaltung). 

> eine ausführliche Beschreibung der Änderung ist in jedem Fall dem CC als anlage anzufügen; 

CCs ohne eine ausführliche Beschreibung werden zurückgewiesen. 

> der anforderer gibt das CC an die it weiter. 

> der saP-Koordinator ist derjenige, der die anfallenden aktivitäten für saP oder einen teil von 

saP koordiniert und den einzelnen Modulbetreuern die aufgaben zuweist. 

diese aufgabe kann – in abhängigkeit der Größe der organisation – auch von einem Gruppen- 

oder abteilungsleiter innerhalb der it übernommen werden. die betreffende Person trägt die 

applikation/das Modul im Formular ein und weist das CC einem Bearbeiter zu; sie kann das CC 

auch aufgrund formaler Fehler (fehlende/unzureichende Beschreibung oder fehlende unter- 

schrift des Process owners/Process owner fremd) zurückweisen. der saP-Koordinator vergibt 

eine eindeutige CC-nummer und den CC-titel; die nummer kann z.B. auch von einem 

Projektverfolgungs-/-dokumentationstool übernommen werden. 

> der it-Leiter/Leiter saP genehmigt / lehnt ab / stellt zurück (mit entsprechender Begründung), 

nachdem der Koordinator genehmigt hat. 

> im Falle der Genehmigung erhält der Bearbeiter das CC zur weiteren Bearbeitung; eine 

Änderung zwecks Weitertransport darf von einem Bearbeiter nicht ohne ein vollständig 

genehmigtes CC durchgeführt werden. 

> nach Fertigstellung lässt der Bearbeiter die Änderung durch den anforderer prüfen. 

> entspricht die umsetzung den anforderungen, gibt der anforderer die Änderung zum transport 

frei; der anforderer bestätigt mit seiner unterschrift die ordnungsgemäße umsetzung; 

ein transport darf nicht ohne vorangegangene Freigabe durch den anforderer durchgeführt werden. 

> saP-Koordinator und it-Leitung bestätigen die ordnungsgemäße umsetzung; ein transport darf 

nicht ohne vorangegangene Freigabe durch die saP-Koordination und die it-Leitung durchge- 

führt werden. 

> der Bearbeiter übergibt den transport in das Produktionssystem und leitet das CC an die saP- 

Koordination und die it-Leitung weiter. 

der Genehmigungs- und Freigabeprozess und damit auch der inhalt des Formulars kann branchen- 

spezifisch stark variieren. in pharmazeutischen unternehmen ist beispielsweise grundsätzlich die 

Qa in das CC-Verfahren eingebunden. darüber hinaus ist es in allen unternehmen üblich, dass bei 

Überschreiten bestimmter (geschätzter) Projektkostenlimits weitere Genehmiger der umsetzung 

einer Änderungsanforderung zustimmen müssen. die Genehmigungsstruktur hängt also im 

Wesentlichen von der jeweiligen unternehmensorganisation ab. 

das Formular enthält daher lediglich die Minimalanforderungen an ein CC ohne Berücksichtigung 

branchen- oder organisationsspezifischer anforderungen. 

51 


52 


ManaGeMent 

Weitere Genehmigungs- oder Freigabeschritte, aber auch zusätzliche Felder mit Bezug zu anderen 

dokumenten (z.B. Validierungsdokumente) sind bei Bedarf individuell zu ergänzen und der Prozess 

entsprechend zu erweitern. 


1. Mathias Friedrich, torsten sternberg, Change request Management mit dem saP solution 

Manager, saP Press, 2009 

2. information technology infrastructure Library (itiL) 

8.3 soFtWareWartBarKeit 

die Wartbarkeit von software ist ein Kriterium bei der entwicklung von software und zeigt an, mit 

welcher energie und mit welchem aufwand Änderungen in einem systemzusammenhang von 

applikationen durchgeführt werden können. (Quelle: Wikipedia) 

technisch ist ein modularer aufbau von objekten entsprechend saP-Praxis, d.h. include-struktur 

in allen Programmen erforderlich. dies umfasst auch die Verwendung von Funktionsbibliotheken, 

die auch anderen entwicklern zugänglich sein müssen und von ihnen leicht aufgefunden werden 

können. 

in systemumgebungen mit verschiedenen entwicklungs- und Produktionssystemen (transportstrecken) 

muss der Grundsatz gelten: gleicher objektname (t-Code, Programm, include, tabelle 

etc.) bedeutet auch identische Funktionalität. 

unterschiedliche Funktionalität bedingt entweder ein eigenes objekt oder – falls möglich – eine 

entsprechende Customizing-Funktion. 

alle entwicklungen/Änderungen/Korrekturen sind sauber zu dokumentieren. 

8.4 anPassunGen der saP-FunKtionaLitÄt 

um die Funktionalität eines saP-systems an eigene Bedürfnisse anzupassen, gibt es verschiedene 

Möglichkeiten, die jeweils Vor- und nachteile mit sich bringen: 

> Modifikation 

> z-Kopie, Kopie in Kundennamensraum 

> erweiterungen (user-exit, Customer-exit, Badi, enhancement, Bte) 

zu den problemlos nutzbaren techniken zählen user-exits, Customer-exits, Btes und Badis. 

deshalb ist es zu empfehlen, diese zu verwenden, sofern diese vorhanden sind und ihre schnittstelle 

alle nötigen daten zur Verfügung stellt. Hier eine kurze Beschreibung dieser techniken:

user-exit 

user-exits sind unterprogramme, die sich in includes im saP-namensraum befinden, aber nur 

einmalig von saP ausgeliefert werden und deshalb ohne Probleme „modifiziert“ werden können. 

Customer-exit 

Customer-exits sind Funktionsbausteine, die zu- und abschaltbar sind und vom Kunden implementiert 

werden können, um standardfunktionalität zu erweitern. 

Business transaction events (Bte) 

im Fi-umfeld stellen Btes eine zusätzliche Möglichkeit der erweiterung dar. Btes sind vergleichbar 

mit Customer-exits, beschränken sich jedoch auf das Fi Modul und stellen eine vordefinierte 

schnittstelle zur Verfügung an die der entwickler erweiterungen anhängen kann. 

Weitere informationen finden sich in der saP-standarddokumentation. 

Badi 

Mit Badis versuchte saP die nachteile anderer/bisheriger erweiterungstechniken zu umgehen: 

> nur einfach verwendbar (Customer-exits) 

> keine dynpro-erweiterungen (Btes) 

> keine Menü-erweiterungen (Btes) 

> keine Verwaltungsebene (Btes) 

deshalb sind Badis mehrfach verwendbar, stellen alle erweiterungsarten (Programm- / Menü- / 

dynpro-exit) zur Verfügung und sind objektorientiert ausgeführt. 

Kann mit den bereits genannten erweiterungen das gewünschte ergebnis nicht erreicht werden, 

gibt es weitere Möglichkeiten, deren Verwendung aber von Fall zu Fall abgewogen werden muss. 

enhancement Point / enhancement section 

enhancement Point: 

Bietet die Möglichkeit, an festgelegten stellen (implizit oder explizit) Code einzufügen. 

> mehrere aktive implementierungen 

> alle aktiven implementierungen werden ausgeführt 

enhancement section: 

> mehrere aktive implementierungen möglich 

> nur eine aktive implementierung wird ausgeführt 

> nicht klar, welche aktive implementierung ausgeführt wird 

53 


54 


ManaGeMent 

Hinweis: implementierungen von enhancement sections können durch das einspielen von saP 

enhancement Packages oder das aktivieren von Business Functions durch neue aktive implementierungen 

oder neu aktivierte implementierungen ersetzt werden. es ist hierbei sehr schwierig, 

ersetzte und nicht mehr ausgeführte implementierungen zu identifizieren. somit kann sich durch 

Änderungen im saP standard das Verhalten der erweiterung ändern. dies erhöht den notwendigen 

testaufwand (tCo!) massiv und führt leicht zu disruption bei einem saP releaseupgrade und eHP. 

die Verwendung von enhancement sections ist daher sehr sorgfältig zu prüfen. 

Bei der Verwendung von enhancements ist die sPau_enH zu abarbeiten, da die enhancements in 

der regulären sPau-transaktion nicht angezeigt werden. 

die entscheidung, ob enhancements als erweiterungskonzept genutzt werden sollen, ist also nicht 

nur abhängig vom realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand. 

Modifikation 

Grundsätzlich sollte nur dann modifiziert, wenn: 

> Customizing oder Personalisierung ihre anforderung nicht umsetzen können 

> geeignete erweiterungen oder user-exits nicht vorgedacht sind 

> das Kopieren des saP-objekts in den Kundennamensraum nicht sinnvoll ist 

Für Modifikation/exits/Badis wird – zusätzlich zum Change Verfahren – ein separates Genehmigungsverfahren 

empfohlen. Hierzu gehören antrag -> Begründung -> Genehmigung. die 

entscheidung muss von dem/den jeweiligen systemverantwortlichen (it-Leitung) getroffen werden. 

Vorteil hierbei ist, dass der entwickler einen Modifikationsschlüssel eingeben und dieser zentral 

vergeben werden kann. es kann also relativ einfach verhindert werden, dass ungewollte Modifika- 

tionen ins system eingebaut werden. 

Kopien in eigenen namensraum/z-namensraum 

Kopien von saP-standardcode in den Kundennamensraum sind sehr pflegeaufwändig. Bislang gibt 

es kein automatisiertes Verfahren und keine manuelle regelung, wie ein späterer abgleich (bspw. 

nach support-Packages oder Hinweiseinbau) zwischen original und z-Kopie erfolgen kann. eine 

allgemeine empfehlung kann an dieser stelle nicht gegeben werden, da Vor- oder nachteile 

jeweils im unterschiedlichen Kontext abgewogen werden müssen. 

BEST PRACTICE für die durchführung von Modifikationen: 

> Grundsätzlich sind Workbench-Modifikationen nur unter Verwendung des Modifikations- 

assistenten erlaubt! 

> eine z-Kopie ist nicht immer die erste Wahl, da dies u. u. mit sehr hohem realisierungsauf- 

wand verbunden ist. darüber hinaus gehen Weiterentwicklungen im standard unberücksichtigt 

an der z-Kopie vorbei, d.h., es resultiert ebenfalls ein aufwand für die anpassung bzw. 

erstellung einer neuen z-Kopie. nach dem einspielen von enhancement Packages können 

verwendete standard-includes zu Problemen führen.

die entscheidung Modifikation vs. z-Kopie vs. enhancement ist also nicht nur abhängig vom 

realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand. 

> Keine der Möglichkeiten Modifikation/z-Kopie/enhancement hat nur Vor- oder nur nachteile, 

es ist hier von Fall zu Fall zu prüfen, welche technik die wenigsten nachteile im speziellen Fall 

mit sich bringt. 

> es wird empfohlen, eine zentrale, formalisierte, technische dokumentation aller Modifikationen 

einzurichten. Für Kopien und erweiterungen sollten geeignete templates bereitgestellt und es 

sollte eine Pflicht zu deren Verwendung bestehen. 


saP schulungen BC425 und BC427 

8.5 testBarKeit Von anWendunGen 

um die testbarkeit von anwendungen zu gewährleisten, müssen die testanforderungen zu einem 

sehr frühen zeitpunkt in der entwicklung festgelegt werden. Gewachsenes Coding nachträglich 

testbar zu machen, ist meistens mit sehr hohem aufwand verbunden, der keine neue Funktionalität 

bietet und daher in der Praxis sehr niedrig priorisiert wird. 

um wirtschaftlich sinnvoll mit tests umzugehen, müssen tests automatisiert werden. dazu ist es 

notwendig, die durchführung von tests wiederholbar zu machen. Versuchen sie, den Code so zu 

schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werden 

kann. das bedeutet, insbesondere auf dynamische anweisungen zu verzichten, da deren semantische 

Bedeutung erst zur Laufzeit bekannt ist und von einem statischen tool nicht hinreichend 

analysiert werden kann. 

BEST PRACTICE: Verwenden sie von anfang an automatisierte tests (aBaP unit, eCatt), um die 

automatisierung von tests zu einem „normalen“ Bestandteil der entwicklung zu machen. 

BEST PRACTICE: saP unterstützt mit der test-Workbench testgetriebene entwicklungen durch 

Modultests. testklassen werden als lokale Klassen angelegt und durch den zusatz „For testinG“ 

als solche kenntlich gemacht. der dort implementierte Programmcode wird lediglich ausgeführt, 

wenn die anwendung über den Menüpunkt „Modultest“ in der aBaP-Workbench aufgerufen wird. 

sogenannte risk-Levels geben die Kritikalität eines tests im Falle des scheiterns an und 

systemeinstellungen verhindern gegebenenfalls, dass ein systemtest einer höheren risikostufe 

ausgeführt wird. 

im aBaP-umfeld ist in vielen Fällen die gelungene integration der datenbank ein Hindernis, wenn 

es um die erstellung von wiederholbaren, automatisierten tests geht. im Vorfeld des tests müssen 

die betroffenen einträge auf der dB in die Form gebracht werden, die für die jeweilige testausführung 

erwartet wird, und Änderungen an der dB durch die testausführung müssen wieder beseitigt 

werden, um andere tests nicht zu behindern. 

55 


56 


ManaGeMent 

BEST PRACTICE: trennen sie in ihren anwendungen die direkte interaktion mit der dB und 

entfernten systemen, deren Laufzeitverhalten nicht kontrolliert werden kann, von dem eigentlichen 

anwendungskern. Wenn dieser anwendungskern nicht mehr direkt mit der dB und den entfernten 

systeme kommuniziert, bieten die dafür benötigten schnittstellen die Möglichkeit, für die 

durchführung von automatisierten tests die datenkonstellationen zu simulieren. 

Werden z.B. alle dB-zugriffe (seLeCt, insert, uPdate, deLete) in einer dB-schicht gekapselt, 

bietet diese Kapselung den ansatzpunkt, um bei der testausführung mit simulierten daten zu 

arbeiten, die bei jeder testausführung in einem konsistenten und bekannten zustand sind. 

Weitere LinKs: 

www.testbarkeit.de 

http://de.wikipedia.org/wiki/testbarkeit 

http://www.testbarkeit.de/Publikationen/tae05_artikel_jungmayr.pdf

9 die autoren 

die folgenden autoren waren maßgeblich an der erstellung der vorliegenden Fassung des 

Leitfadens beteiligt: 

Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH 

Herr Lintner ist zertifizierter Projektmanager (iPMa-Level C) und seit 1998 im Bereich saP aBaP 

entwicklung tätig. seine schwerpunkte liegen in den Bereichen applikations- und WorkFlow-entwicklung, 

Change- und requestmanagement. 

steffen Pietsch, Vice President, iBsolution GmbH 

Herr Pietsch ist seit 2003 im entwicklungsnahen umfeld tätig und konnte erfahrungen als 

entwickler sowie in verschiedenen leitenden Positionen im entwicklungsumfeld sammeln. seit 

2009 setzt er sich als sprecher des dsaG-arbeitskreises saP netWeaver development für die 

interessen der Kunden und Partner in zusammenarbeit mit der saP ein. 

Markus theilen, it-Koordinator, eWe aG 

Herr theilen ist seit 2001 als entwickler, software- und unternehmensarchitekt tätig und konnte in 

diesen rollen tiefgreifende erfahrungen in komplexen saP-erP-implementierungen sammeln. 

seit 2012 steuert er als it-Koordinator im eWe-Konzern die entwicklungstätigkeiten ausgewählter 

anwendungen. daneben arbeitet er als stellvertretender sprecher des dsaG-arbeitskreises saP 

netWeaver development in der dsaG e.V. mit. 

Jürgen Wachter, Process Coordinator development, comgroup GmbH 

Herr Wachter arbeitet seit 2002 im Bereich saP entwicklung. sein fachlicher schwerpunkt liegt im 

Bereich Core development/enhancements. 

Michael Werner, saP anwendungsberater (inhouse), Lts aG andernach 

Herr Werner sammelte von 1988 bis 1999 erfahrungen im Bereich saP r/2 mit den schwerpunkten 

saP Basis, Logistik und Programmierung (aBaP und assembler). seit 1999 ist er als saP r/3 

anwendungsberater für die Module MM, WM und PM tätig und führt aBaP-entwicklung von add 

ons, schnittstellen und erweiterungen durch. 

andreas Wiegenstein, Managing director und Chief technology officer (Cto), Virtual Forge GmbH 

Herr Wiegenstein arbeitet seit 2002 im Bereich saP security. er ist Co-autor des Buches „sichere 

aBaP-Programmierung“ (saP Press) und hält regelmäßig Vorträge zum thema saP/aBaP 

sicherheit und Compliance auf internationalen Konferenzen, wie z.B. rsa, Black-Hat, Hack in the 

Box, troopers, saP teched und auf dsaG-Veranstaltungen. 

darüber hinaus haben folgende Personen durch die Bereitstellung von unterlagen, reviewtätigkeiten 

und zahlreiche diskussionen maßgeblich zum aktuellen stand beigetragen: 

Michael Cendon, thorsten Franz, Pascal Mannherz, thomas Prang, Markus tradt, tobias trapp, 

Peter Weigel, Marc zimmek 

Besonderer dank gilt der saP, insb. Horst Keller und dr. Wolfgang Weiss, die mit konstruktiven 

Vorschlägen und reviews die arbeit an diesem dokument unterstützt haben. 

57 


58 

10 anHanG: naMensKonVentionen 

im Folgenden finden sie ein Beispiel, wie namenskonventionen im Bereich der aBaP-entwicklung 

aufgebaut werden können. dieses Beispiel kann als anhaltspunkt für den aufbau einer eigenen 

namenskonvention verwendet werden und ist dahingehend branchen- und unternehmensspezifisch 

anzupassen. 

allgemeiner Hinweis: objekte im aBaP dictionary haben unterschiedliche Begrenzungen in der 

anzahl zur Verfügung stehender zeichen. Bei der Benennung der objekte ist dies zu berücksichtigen. 

nachfolgend wird der Kundennamensraum y… verwendet. stattdessen kann, wie in Kapitel 2 

beschrieben, alternativ der namensraum z… oder ein kundeneigener namensraum /…/ verwendet 

werden. 

abkürzungen 

abkürzungen Bedeutung 

Mm Modul bzw. Projekt 

die abkürzung mm repräsentiert ein saP-Modul (z.B. PP MM) oder 

ein kundenspezifisches Projekt. 

uu arbeitsgebiet 

ein arbeitsgebiet erlaubt optional eine feinere unterteilung eines 

Moduls oder eines Projekts. das arbeitsgebiet wird vom Projektleiter 

definiert und kommuniziert. 

K Konstante 

C alphanumerisches zeichen 

n numerisches zeichen 

… Beliebige Länge 

10.1 aLLGeMeine naMensKonVentionen 

strukturierende elemente 

typ Konvention Beispiel 

entwicklungspakete ymmuu… yPPrueCK 

reports ymmuu… ymmuu… 

Modulpools saPMyuu saPMyCauB 

includes tymmuuccc..._(a)* MyCauB_toP 

transaktionen ymm.. yMM01 

nachrichtenklasse ymm.. yPPrueCK 

Webdynpro aBaP ymm…** yPKs_adMin_1 

anmerkungen: 

*das include beginnt mit dem namen des Modulpools ohne den Präfix „saP“. zum schluss wird

die art(a) des includes angegeben: 

> toP top include 

> PBo Process Before output include 

> Pai Process after input include 

> ForMs include für unterprogramme 

> CLass include für lokale Klassen 

** die Verwendung des Webdynpro editors (z.B. in der se80) führt zur automatischen erzeugung 

von Quellcode. dies macht die umsetzbarkeit eigener namenkonventionen im einzelfall schwer. 

data-dictionary-objekte 


tabellen ymmuu…(t) yPPorder 

Views ymmuu…_V yPPorder_V 

tabellentypen ymmuu…_tt yCadoCuMent_tt 

struktur ymmuu…_s yCadoCuMent_s 

datenelement und 

domäne 

ymmuu… yCaFtdatuV 

suchhilfe ymmuu…. yPPProJe 

sperrobjekte ey_ ey_ysdMinFo 

typgruppen ymmcc yCa02 

Klassen & interfaces 


Klassen yCL_mm_... yCL_sd_FaKtura 

interfaces yiF_mm.. yiF_sd_BooKinG 

10.2 attriBute 

Lokale Variablen und attribute einer Klasse sollten im normalfall als private deklariert werden. 

der zugriff auf die attribute sollte über get- und set-Methoden erfolgen. 

LV_... attribut Variable (local value …) 

Ls_... attribut struktur (local structure …) 

Lt_... attribut tabelle (local table…) 

59 


60 


10.3 MetHoden 

Methoden sollten einen kurzen, sprechenden, englischen namen besitzen. Folgende Präfixe 

deuten auf die aufgabe der Methode: 

set_... setzen von Werten 

get_... Laden von Werten 

send_... senden von informationen 

save_... sichern der daten auf die datenbank 

etc. 

die genaue Funktion sollte in der Beschreibung der Methode stehen. reicht der Platz (60 zeichen) 

nicht aus, so sollte die ausführliche dokumentation der Methode in der Klassendokumentation 

erfolgen. 

10.4 siGnatur Von MetHoden 

die Parameter einer Methode werden wie folgt bezeichnet. 

nr. Parameterart Präfix 

0 importing i_... 

1 exporting e_... 

2 Changing C_... 

3 returning r_... 

10.5 FunKtionsGruPPen und -Bausteine 


Funktionsgruppen ymm_ccc_… yCa_KonFiGuration 

Funktionsbausteine ymm_... ysd_FaKtura_zu_We 

die schnittstellen von Funktionsbausteinen orientieren sich an denen der objektorientierten 

Programmierung (vgl. 10.4). 

BEST PRACTICE: tabellen können auch als import, export oder Changing Parameter übergeben 

werden, sodass stets Klarheit herrscht, welche tabellen im Funktionsbaustein geändert werden 

und welche nicht. des Weiteren stellt der syntax-Check im aBaP sicher, dass importparameter 

nicht verändert werden dürfen.

10.6 enHanCeMents 


enhancement 

spot 

enhancement 

definition 

enhancement 

implementation 

10.7 ForMuLare 

yes_... yes_MV45a 

yed_... yed_ MV45a 

yei_... yei_ MV45a 


adobe Forms – Formular ymm.. yPP_VBK1 

adobe Forms – schnittstelle ymm.._iF yPP_VKB_iF 

smart Forms / sapscript – Formular ymm.. yPP_VBK1 

smart Forms / sapscript – stil ymm.. yPP_VBK1 

smart Forms / sapscript – textbaustein ymm.. yPP_VBK1 

10.8 JoBs 

suchhilfe ymmuu…. yPPProJe 

sperrobjekte ey_ ey_ysdMinFo 

typgruppen ymmcc yCa02 


Jobs yMM___ ysd_1_1000_ 

= Priorität, einstellige zahl, = Buchungskreis 

61 


62 


10.9 dateneLeMente 

datentyp Präfixbestandteil 

elementare typen / Variablen v 

strukturen s 

tabellen t 

datenreferenz r 

Klassenreferenz o 

interfacereferenz i 

Badi-referenz b 

ausnahmeklasse-referenz x 

diese Präfixbestandteile bilden die typenabhängigen anteile der im Folgenden aufgeführten, 

kontextabhängigen Präfixe. [t] ist hierbei jeweils durch den passenden typenabhängigen Präfixbestandteil 

zu ersetzen. 

art der deklaration namenskonvention 

Lokale Variable l[t]_* 

Globale Variable g[t]_* 

statische Variable s[t]_* 

Lokales Feldsymbol 

Globales Feldsymbol 

Lokale Konstante lc[t]_* 

Globale Konstante gc[t]_* 

select-option s_* 

Parameter p_ 

Funktionsbausteinparameter i[t]_* für importing 

e[t]_* für exporting s[t]_* 

c[t]_* für Changing 

t[t]_* für tables 

ForM Parameter p[t]_* für using 

c[t]_* für Changing l[t]_* 

t[t]_* für tables g[t]_* 

tabellentyp tt_* 

strukturtyp t_*

objektorientierte Programmierung: 

entität namenskonvention 

Lokale Klasse lcl_* 

Globale Klasse cl_* 

Lokales interface lif_* 

Globales interface if_* 

instanzattribut m[t]_* 

statisches attribut g[t]_* 

Konstanten c[t]_* 

Methodenparameter i[t]_* für importing 

e[t]_* für exporting p_ 

c[t]_* für Changing i[t]_* für importing 

r[t]_* für returning s[t]_* 

ereignisparameter i[t]_* 

63 


© DSAG e. V.

Best Practice Leitfaden Development - DSAG

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?