Dsag Besteht Practice

DSAG-HANDLUNGSEMPFEHLUNG

BEST PRACTICE LEITFADEN DEVELOPMENT –

PRAXISTIPPS RUND UM DAS THEMA ABAP DEVELOPMENT
BEST PRACTICE LEITFADEN DEVELOPMENT
PRAXISTIPPS RUND UM DAS THEMA ABAP DEVELOPMENT
Version:
2.0
Stand:
20. September 2016

Autoren:
Dr. Christian Drumm, Leiter Anwendungsentwicklung & Beratung, Dr. Christian Lechner, Principal IT Consultant, msg systems ag
FACTUR Billing Solutions GmbH
Steffen Pietsch, Head of Backoffice, Haufe-Lexware GmbH & Co.KG
Martin Fischer, Portfolio Unit Manager SAP Database & Technology, BridgingIT GmbH
Daniel Rothmund, IT Business Analyst SAP, Geberit Verwaltungs GmbH
Judith Forner, Senior Consultant Finance & Controlling,
Mundipharma Deutschland GmbH & Co. KG Holger Schäfer, Business Unit Manager, UNIORG Solutions GmbH
Edo von Glan, SAP-Entwickler, Drägerwerk AG & Co. KGaA Denny Schreber, Senior Solution Architect, cbs Corporate Business Solutions
Unternehmensberatung GmbH
Florian Henninger, Senior Consultant SAP Development, FIS GmbH
Andreas Wiegenstein, Managing Director und Chief Technology Officer (CTO), Virtual
Martin Hoffmann, Head of Software Engineering, Miele & Cie. KG Forge GmbH
Valentin Huber, Senior IT Consultant, msg systems ag Bärbel Winkler, Systemanalystin SAP-Basis/Programmierung,
Alfred Kärcher GmbH & Co. KG
Jens Knappik, SAP System Architect, thyssenkrupp Materials Services GmbH
Weitere Informationen zu den Autoren finden Sie in Kapitel „11 Die Autoren“.
DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -2-

UNSER DANK GILT ALLEN BETEILIGTEN
Darüber hinaus gilt besonderer Dank den SAP-Mitarbeitern, die uns durch Reviews,
Diskussionen und konstruktive Vorschläge bei der Erstellung der 2. Auflage des
Leitfadens aktiv unterstützt haben. Insbesondere danken wir Jürgen Adolf, Carine
Tchoutouo Djomo, Olga Dolinskaja, Thomas Fiedler, André Fischer, Dr. Thomas
Gauweiler, Oliver Graeff, Michael Gutfleisch, Martin Huvar, Karl Kessler, Michael
Schneider, Harald Stevens, Christoph Stöck, Dr. Wolfgang Weiss, Wolfgang Wöhrle und
Margot Wollny.

INHALT
1 EINLEITUNG 8 3.4.2 Datenbankzugriffe 27

3.4.3 ABAP Core Data Service (CDS) Views 29
1.1 MOTIVATION & IHR MITWIRKEN 8
3.5 INTERNE TABELLEN UND REFERENZEN 30
1.2 POSITIONIERUNG 8 3.5.1 Feldsymbole 31
3.5.2 Parameterübergabe 31
1.3 ÄNDERUNGEN IN DER 2. AUFLAGE 8
3.6 CODE PUSH DOWN 32
2 PROGRAMMIERRICHTLINIEN 9
4 ROBUSTHEIT UND KORREKTHEIT 33
2.1 NAMENSKONVENTION 10
4.1 FEHLERBEHANDLUNG 33
2.2 NAMENSRAUM 11
4.1.1 SY(ST)-SUBRC-Prüfungen 33
2.3 LESBARKEIT UND MODULARISIERUNG 11 4.1.2 MESSAGE-Anweisung 34
4.1.3 Klassenbasierte Ausnahmen 34
2.4 TRENNUNG VON PRÄSENTATIONS- UND ANWENDUNGSLOGIK 17
4.1.4 Nicht behandelbare Ausnahmen 36
2.5 INTERNATIONALISIERUNG 18
4.2 KORREKTE IMPLEMENTIERUNG VON DATENBANK-ÄNDERUNGEN 36
2.6 DYNAMISCHE PROGRAMMIERUNG UND AUDITIERBARKEIT 19 4.2.1 Sperrobjekte 36
4.2.2 Frameworks für den Datenbankzugriff 37
2.7 NEUE SPRACHELEMENTE 20
4.2.3 Verbuchungskonzept 37
2.8 OBSOLETE ANWEISUNGEN 22
4.3 PROTOKOLLIERUNG 37
2.9 AUTOMATISCHE PRÜFUNGEN DER ENTWICKLUNGSOBJEKTE 22
2.10 HARTE CODIERUNG, MAGIC NUMBERS 23 5 ABAP-SICHERHEIT UND COMPLIANCE 38
2.11 BERECHTIGUNGSPRÜFUNG IM QUELLCODE 24 5.1 PRÜFUNGSRELEVANTE SICHERHEITSTHEMEN IM SAP STANDARD 38
2.12 PROGRAMMIERMODELL: OBJEKTORIENTIERT VS. PROZEDURAL 24 5.1.1 Berechtigungsprüfung 39
5.1.2 Testbarkeit 39
2.13 ENTWICKLUNGSSPRACHE 25 5.1.3 Datenschutz 39
5.1.4 Injection-Schwachstellen 40
3 PERFORMANCE 25 5.1.5 Standard-Schutz 40
5.2 SICHERHEITSEMPFEHLUNGEN 40
3.1 VERMEIDUNGSPRINZIP 25 5.2.1 Sieben allgemeine Regeln für die sichere ABAP-Programmierung 41
3.2 PERFORMANCE-OPTIMIERUNGEN NUR AN RELEVANTEN STELLEN 25 5.2.2 Die kritischsten und häufigsten Risiken in ABAP 42
3.3 VORHANDENE WERKZEUGE NUTZEN 26 5.3 COMPLIANCE-PROBLEME DURCH ABAP 42
3.4 DATENMODELL UND DATENZUGRIFF 27 5.4 TESTWERKZEUGE 43

3.4.1 Datenmodell 27

6 DOKUMENTATION 44 8.1.4 Transportwesen 56
8.1.5 Sicherstellung der Konsistenz
6.1 DOKUMENTATION UNABHÄNGIG VON ENTWICKLUNGSOBJEKTEN 44 von Neuentwicklungen und Erweiterungen 57
8.1.6 Rückbau von Neuentwicklungen 57
6.2 DOKUMENTATION VON ENTWICKLUNGSOBJEKTEN 45
8.2 CHANGE MANAGEMENT 58
6.3 DOKUMENTATION IM QUELLCODE 46
6.3.1 Dokumentationssprache 46 8.3 SOFTWAREWARTBARKEIT 60
6.3.2 Dokumentation von Änderungen 46
8.4 ANPASSUNGEN DER SAP-FUNKTIONALITÄT 60
6.3.3 Programmkopf 46
6.3.4 Kommentare im Quellcode 47 8.5 TESTBARKEIT VON ANWENDUNGEN 63
8.5.1 Testprozessgrundlagen für die Erstellung von Softwareprodukten 63
7 UMSETZBARKEIT UND DURCHSETZBARKEIT 47 8.5.2 Testautomatisierung 65
7.1 UMSETZBARKEIT 47 9 ECLIPSE-ENTWICKLUNGSUMGEBUNG 67

7.1.1 Motivation für einen Prozess 47
7.1.2 Erstellung und Pflege des Prozesses 48 9.1 VORAUSSETZUNGEN UND INSTALLATION 67
7.2 DURCHSETZBARKEIT 49 9.2 NOTWENDIGKEIT 67
7.2.1 Manuelle Prüfungen 49
9.3 VORTEILE 67
7.2.2 Automatische Prüfungen 50
9.4 ZU BEACHTENDE PUNKTE 68
7.3 ERFAHRUNGEN UND TIPPS AUS DER PRAXIS 51
7.3.1 Qualitätssicherung des Quellcodes 51 9.5 PROBLEME UND HILFESTELLUNGEN FÜR DEN UMSTIEG 68
7.3.2 Time and Budget Quality Assurance (QA) 51
9.6 FAZIT 69
7.3.3 Probleme 52
7.3.4 Entscheidungsfindung bei Modifikationen 52 9.7 WEITERE QUELLEN 69
7.3.5 Erfahrungsbericht aus der Praxis: Comgroup GmbH 53
10 USER INTERFACE (UI) 70
8 INFRASTRUKTUR UND LIFECYCLE MANAGEMENT 54
10.1 UI-TECHNOLOGIEN IN DER PRAXIS 70
8.1 INFRASTRUKTUR 54
8.1.1 Klassische 3-Systemlandschaft 54 10.2 SAPUI5 71
8.1.1.1 Entwicklung 54 10.2.1 Anforderungen 71
8.1.1.2 Qualitätssicherung 54 10.2.2 Entwicklung 72
8.1.1.3 Produktion 54 10.2.2.1 Discover 73
8.1.2 5- bzw. 6-Systemlandschaft 54 10.2.2.2 Design 73
8.1.2.1 Entwicklung 54 10.2.2.3 Deliver 74
8.1.2.2 Test 55 10.2.3 Generelle Empfehlungen 76
8.1.2.3 Qualitätssicherung 55 10.2.4 Weitere Quellen 77
8.1.2.4 Wartung 55 10.3 SAP GATEWAY 77
8.1.2.5 Konsolidierung 55 10.3.1 Einsatz von SAP Gateway 77
8.1.2.6 Produktion 55 10.3.2 Entwicklung mit SAP Gateway 78
8.1.2.7 Schematische Darstellung 6-Systemlandschaft 55 10.3.3 Generelle Empfehlungen 80
8.1.3 Sandbox 56 10.3.4 Weitere Quellen 80

11 DIE AUTOREN 81
ANHANG A: NAMENSKONVENTIONEN 83
A.1 NAMENSKONVENTIONEN REPOSITORY-OBJEKTE 84
A.1.1 Pakethierarchie 85
A.1.2 Dictionary Objekte 85
A.1.3 Container für Quelltextobjekte 86
A.2 NAMENSKONVENTIONEN ABAP-QUELLTEXT 88
A.2.1 Klassische Benutzerdialoge (Selektionsbilder / Dynpros) 88
A.2.2 Sichtbarkeit 88
A.2.3 Signaturen 88
A.3 WEITERFÜHRENDE INFORMATIONEN ZU NAMENSKONVENTIONEN 89
A.4 SONSTIGES / LESSONS LEARNED 89
A.4.1 Kundennamensräume 89
A.4.2 Vermeidung überflüssiger Bezeichnerinformationen 89
A.5 FORMULARE 90
A.6 SCHUTZ VON NAMENSKONVENTIONEN IN DER ABAP-WORKBENCH 90
ANHANG B: WEITERFÜHRENDE BEISPIELE 91

B.1 ERWEITERUNG DER ABAP-SCHLÜSSELWORTDOKUMENTATION 91
IMPRESSUM 92

ABBILDUNGEN
Abbildung 1: IKS-Risiken durch unsicheren ABAP-Quellcode 42

Abbildung 2: Schematische Darstellung 6-Systemlandschaft 55
Abbildung 3: Change-Control-Formular (CC) 58
Abbildung 4: W-Modell mit Teststufen 64
Abbildung 5: SAP NetWeaver 7.5 Browser Support PAM 71
Abbildung 6: Phasen des Design Thinkings 72
Abbildung 7: Unterstützte Testphasen in SAPUI5 75
Abbildung 8: SAP Gateway Deployment Optionen 78

1 EINLEITUNG
Die Software der SAP zeichnet sich als Standardsoftware durch ein hohes Maß an www.dsag.de/leitfaden-abap
Flexibilität und Erweiterbarkeit aus. In nahezu allen Unternehmen, die SAP-Software
einsetzen, finden sich kundenspezifische Anpassungen und Erweiterungen. Die
SAP-Software unterliegt damit sowohl auf Hersteller- als auch auf Kundenseite der
1. EINLEITUNG
kontinuierlichen Anpassung und Erweiterung durch sich ändernde Kundenbedürfnisse. Wir freuen uns auf Ihr Feedback!
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. 1.2 POSITIONIERUNG
Zeitgleich birgt die Erweiterbarkeit das Risiko kundenspezifischer Entwicklungen, die
komplex, aufwendig wartbar und fehleranfällig sind. Von der SAP und einer ganzen Reihe von Fachverlagen existieren bereits sehr gute
Publikationen zu Anwendungsentwicklung und Erweiterung der SAP-Plattform. Im
2012 erschien die erste Version des DSAG-Best-Practice-Leitfadens mit dem Ziel, Verlauf dieses Leitfadens weisen wir auf aus unserer Sicht lesenswerte Literatur hin.
Praxistipps und Denkanstöße für die wartbare und effiziente Gestaltung kundenspezi-
fischer Entwicklungen zu liefern. In den Folgejahren wurde er in die englische Sprache Der Mehrwert dieses Dokuments liegt in der Zusammenfassung bewährter Vorgehens-
übersetzt. Aus dem Leserkreis der ersten Version haben wir zahlreiche Rückmeldun- weisen, Praxistipps und erprobter Regelwerke aus den Anwenderunternehmen. Diese
gen erhalten. Zudem hat sich in der SAP-Entwicklung in den letzten Jahren viel Guideline soll Ihnen als Anwender, Entwickler, Entwicklungs-, Projekt- oder IT-Leiter
verändert und es wurden etliche Neuerungen eingeführt. Deshalb stellen wir Ihnen Anregungen und Hilfestellung geben, um „das Rad nicht immer wieder neu erfinden zu
hiermit die zweite, vollständig überarbeitete und aktualisierte Auflage des DSAG-Best- müssen“ und auf die Erfahrungen anderer aufbauen zu können. Dabei erheben die in
Practice-Leitfadens zur Verfügung. dieser Guideline vorgestellten Empfehlungen nicht den Anspruch auf Vollständigkeit
oder absolute Gültigkeit, sondern stellen eine Auswahl von Praxistipps dar.
Als Autorenteam haben wir uns darum bemüht, im Spannungsfeld zwischen Über-
1.1 MOTIVATION & IHR MITWIRKEN blickswissen und Detailtiefe den richtigen Mix zu finden. Daher verweisen wir an
entsprechenden Stellen auf weiterführende Quellen, um bereits ausführlich diskutier-
Die Arbeit der Deutschsprachigen SAP-Anwendergruppe e.V. (DSAG) fußt auf drei te Themen nicht redundant wiederzugeben.
Säulen – Wissensvorsprung, Einflussnahme und Netzwerk. Das vorliegende Dokument
wurde von Mitgliedern des DSAG-Arbeitskreises SAP NetWeaver Development initiiert
und adressiert die erste Säule, Wissensvorsprung für Anwender und Partner.
1.3 ÄNDERUNGEN IN DER 2. AUFLAGE
Als Autorenteam ist es unser Anliegen, das in den Unternehmen verteilt und implizit
vorliegende Wissen zum Thema Entwicklung in einem kompakten Dokument anderen Die zweite Auflage dieses Dokuments orientiert sich an der Struktur der ersten
DSAG-Mitgliedern zur Verfügung zu stellen. Unser Wunsch ist, dass dieses Dokument Auflage aus dem Jahr 2012. Inhaltlich wurde jedes Kapitel grundlegend geprüft und
„lebt“ und mit Ihrem Erfahrungsschatz einer kontinuierlichen Verbesserung unterliegt. überarbeitet. Hierbei wurden einige Empfehlungen der ersten Auflage aufgrund von
Rückmeldungen der DSAG-Mitglieder angepasst und andere umfassend durch das
Wir haben hierzu eine Community-Webseite eingerichtet, über die Sie weitere Informa- Autorenteam erweitert. Darüber hinaus sind die Kapitel „Entwicklungsumgebung“ und
tionen zum Leitfaden erhalten, mit dem Autorenteam und anderen DSAG-Mitgliedern „User Interface“ neu hinzugekommen.
in Kontakt treten und Ihre Rückmeldung mit anderen teilen können:
Auch wenn Sie bereits mit der ersten Auflage dieses Leitfadens vertraut sein sollten,
empfehlen wir Ihnen die Lektüre und Anwendung der Empfehlung dieser vollständig
überarbeiteten, zweiten Auflage.

2 PROGRAMMIERRICHTLINIEN Erweiterung der ABAP-Programmierrichtlinien
Dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für Eine Erweiterung der ABAP-Programmierrichtlinien macht vor allem dann Sinn, wenn
2 PROGRAMMIERRICHTLINIEN
Anwendungen, die mit Hilfe der Programmiersprache ABAP erstellt werden. Es wird Sie Themenbereiche aufnehmen wollen, die die Standard-Regeln momentan nicht
beschrieben, wie mit Standard-SAP-Mitteln und Disziplin lesbarer und verständlicher abdecken. Hierzu gehören Designprinzipien zur Objektkomposition (SOLID4 /GRASP5)
ABAP-Quellcode entwickelt werden kann. Dies erleichtert die Wartung des Quellcodes und architektonische Konzepte wie z.B. das SAP-Paketkonzept oder die Verwendung
und ermöglicht, dass verschiedene interne und externe Personen effizient an der von Frameworks. Denkbar ist auch eine zusätzliche Auflistung der Regeln, die für Ihr
(Weiter-) Entwicklung und Wartung eines Programms zusammenarbeiten. Unternehmen als zentral erachtet werden. Weitere Details, wie Sie die ABAP-Schlüssel
wortdokumentation erweitern können, entnehmen Sie bitte dem Anhang (Kapitel B.1).
Verwendung der offiziellen ABAP-Programmierrichtlinien
Seit NetWeaver 7.31 SP5 sind die offiziellen ABAP-Programmierrichtlinien der SAP
fester Bestandteil der ABAP-Schlüsselwortdokumentation. Sie sind dem Entwickler
über die lokale Systeminstallation (Transaktion ABAPDOCU / F1-Hilfe im ABAP-Editor
/ ADT) oder über das SAP Help Portal1 zugänglich. Neben dem hochwertigen und BEST PRACTICE
umfangreichen Inhalt hat das Dokument gegenüber anderen Entwicklungsrichtlinien • Stellen Sie Ihre Entwicklungsrichtlinien in der Ent-
den Vorteil, dass es direkt in die Entwicklungsumgebung integriert werden kann und wicklungsumgebung zur Verfügung, damit schnell auf
nicht in der Schreibtischschublade verstaubt. Sie finden eine Anleitung für die SAP-Ea-
sie zugegriffen werden kann.
sy-Access-Menü-Integration im SAP-Hinweis 13870862 bzw. für die SE80-Integration
im verlinkten SAP-Community-Network (SCN)-Blog3. • tatten Sie die Entwicklungsrichtlinien mit vielen
S
transparenten und nachvollziehbaren Beispielen aus,
Die ABAP-Programmierrichtlinien der SAP zeichnen sich aus durch die ggf. als Code Snippets wiederverwendet werden
können.
• sehr fundierte und praxisnahe Empfehlungen,
• rientieren Sie sich an den offiziellen ABAP-Pro-
O
• detaillierte Informationen zu jeder Regel mit Beispielen, grammierrichtlinien der SAP. Das sehr umfangreiche
Dokument bietet für ein sehr breites Feld von Aktivi-
• ihre Verfügbarkeit in Deutsch und Englisch,
täten detaillierte Handlungsempfehlungen an.
• die kontinuierliche Weiterentwicklung durch SAP,
• eine interaktive Navigation zu Schlüsselwortdokumentationen, Release-abhängi-

gen Änderungen, Performance- und Sicherheitsthemen, Beispielprogrammen
und Transaktionen,
• die Nutzung aller verfügbaren ABAPDOCU-Funktionen (Export als HTML oder

PDF, Suche, etc.),
• ihren hohen Bekanntheitsgrad und Quasi-Standard,
• individuelle Erweiterungsoptionen.
1 Vgl. SAP Help Portal „ABAP Schlüsselwortdokumentation – NW7.50“
2 Vgl. SAP-Hinweis „1387086 – HTML Viewer Control auf Einstiegsbild von SAP Easy Access“ 4 Vgl. https://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs#SOLID-Prinzipien
3 Vgl. SCN-Artikel „Enhancing the ABAP Workbench with a website containing dev guidelines!“ 5 Vgl. https://de.wikipedia.org/wiki/GRASP

2.1 NAMENSKONVENTION
• assen Sie das Dokument der SAP bei Bedarf in einer

F Namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur
Kurzversion zusammen. Durch seinen Umfang und Benennung von Softwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur
Benennung von Objekten im Quellcode (z.B. Variablen).
den hohen Detaillierungsgrad ist die vollständige
Sichtung der offiziellen ABAP-Programmierrichtlinien Wir empfehlen ausdrücklich, eine Namenskonvention als Richtlinie für Entwicklungen
relativ aufwendig und beinhaltet zum Teil Themenbe- im SAP-System vorzugeben. Das Ziel der Verwendung einer einheitlichen Namenskon-
reiche, die nicht für jede alltägliche Entwicklungsakti- vention ist die deutliche Steigerung der Wartbarkeit kundenspezifischer Anpassungen
vität relevant sind. Falls das Dokument in Ihrer und Erweiterungen. In der Konsequenz führt dies zu geringeren Wartungsaufwänden
Organisationseinheit eingesetzt werden soll, empfeh- bzw. -kosten und einer schnelleren Problemlösung im Fehlerfall.
len wir, ein Team mit der Zusammenfassung des
Die explizit formulierte Namenskonvention sollte Bestandteil der internen Ausbildung
Dokuments zu beauftragen und den Umgang mit dem
sein, um neue Mitarbeiter mit den Grundregeln und Unternehmensspezifika vertraut
Dokument anhand von Schulungsmaßnahmen in die zu machen. Zudem hat es sich bewährt, diese Namenskonvention zum Vertragsgegen-
Organisation auszurollen. Gerade in größeren Organi- stand für externe Entwickler und Partnerunternehmen zu machen. Automatisierte
sationseinheiten macht es Sinn, das Team mit Inter- Überprüfungen stellen die Einhaltung sicher (vgl. Kapitel 2.9 und Anhang A).
essenvertretern aus dem Bereich Qualitätssicherung
und Entwicklung zu besetzen und die einzelnen
Punkte ggf. an die individuellen Bedürfnisse der
Organisation anzupassen.
• ird das Dokument Bestandteil von externen Werk-
W BEST PRACTICE
verträgen sollte der Abnahmeprozess durch die Eine exemplarische Namenskonvention finden Sie im
externen Entwickler in die Aktivierung des Entwick- Anhang A.
lerschlüssels eingebunden und im Dialog für die
Abnahme auf das Dokument verwiesen werden.
WEITERE QUELLEN:
1. Development Guidelines for Greenfield Implementation in sync with SAP Custom

Code Management6
6 Vgl. SCN-Artikel http://scn.sap.com/docs/DOC-56285

2.2 NAMENSRAUM
Die Trennung von Kundenobjekten und SAP-Objekten kann über die Präfixe Y oder Z BEST PRACTICE
sowie über einen eigenen Namensraum erfolgen. Die Syntax lautet wie folgt: Wir empfehlen die Verwendung eines kunden-
eigenen Namensraums.
Z…
Y…
/<kundeneigener Namensraum>/…
Der kundeneigene Namensraum kann bei SAP von SAP-Bestandskunden kostenfrei WEITERE QUELLEN
registriert werden und ist nach Bestätigung weltweit eindeutig und für das jeweilige
Unternehmen zur Verwendung registriert. Dieses Vorgehen unterstützt bei der 1. http://help.sap.com (Namensraum einrichten)
konfliktfreien Vergabe von Namen für Softwareobjekte.
2. Hinweis 105132 – Reservierung von Namensräumen
Der Vorteil des kundeneigenen Namensraums liegt in der garantierten Überschnei-
dungsfreiheit beim Import fremder Objekte in das eigene SAP-System (z.B. beim 3. Hinweis 84282 – Entwicklungs-Namensräume für Kunden und Partner
Einsatz von Fremdanwendungen, die per Transportauftrag eingespielt werden) und bei
Zusammenführungen von SAP-Systemen im Rahmen einer Post-Merger-Integration. 4. SAP Support Portal: http://support.sap.com/namespaces
Durch die Reservierung des Namensraums ist sichergestellt, dass auf keinem frem-
den, d.h. nicht für diesen Namensraum registrierten, System ein Softwareobjekt mit
dem gleichen Präfix erstellt werden kann.
2.3 LESBARKEIT UND MODULARISIERUNG
Der Nachteil bei der Verwendung des kundeneigenen Namensraums liegt darin, dass
durch die durchgängige Verwendung des Präfixes bereits mehrere Zeichen bei der Es ist nicht einfach, einen gut lesbaren und einfach zu verstehenden Quellcode zu
Benennung von Objekten „verbraucht“ werden. Besonders bei Objekten, die nur erzeugen und es erfordert Disziplin und Professionalität. Der Aufwand lohnt sich aber
wenige Zeichen zur Benennung bieten, kann die Vergabe eines sprechenden Namens langfristig, vor allem bei langlebigen Applikationen mit kontinuierlichen Wartungs-
schwierig werden. Darüber hinaus gibt es Objekttypen, wie z.B. Berechtigungsobjekte, und Erweiterungsaktivitäten. Doch was macht gut lesbaren, einfach zu verstehenden
die die Verwendung von Namensräumen nicht unterstützen. Gleiches gilt für Tools und Quellcode aus? Wirft man einen Blick über den ABAP-Tellerrand7, geht es immer um
Frameworks der SAP. Obwohl es sinnvoll und empfehlenswert ist, diese einzusetzen, die Einfachheit des Quellcodes. Um dies zu erreichen, schlagen wir folgende Vorge-
kann es bei der Verwendung zu Problemen kommen, weil die Verwendung eines hensweisen vor:
Namensraums in der Partner- oder Kundenentwicklung nicht durchgängig oder gar
nicht vorgesehen ist. Wir empfehlen daher, dies vor Einsatz eines neuen Tools oder • Einsatz von natürlicher Sprache („sprechende“ Benennung von Variablen,
Frameworks zu überprüfen. Prozeduren usw.)
• Durchgängige Verwendung domänenspezifischer Bezeichnungen
• Vermeidung abstrakter, nicht direkt zu verstehender Begriffe und Abkürzungen
7 Einschlägige Autoren / Bücher zu dem Thema sind:

• Robert C. Martin: Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe,
Heidelberg. MITP, 2009.
• Steve McConnell: Code Complete, 2. Auflage. Unterschleißheim. Microsoft Press, 2005.
• Martin Fowler: Refactoring – Improving the Design of existing Code. Addison-Wesley, 1999

• Einheitliche Quellcodestrukturierung (Einrückung, Schreibstil)
• Aufgabe eines individuellen Programmierstils zugunsten eines gemeinsamen BEST PRACTICE

Standards • Berücksichtigen Sie die oben genannten Vorgehens-

weisen bei der Auswahl und Ausbildung der Entwick-
• Modularisierung
ler, bei der Zeitplanung von Projekten (Zeitdruck bei
• Nicht zu lange / komplexe Prozeduren der ursprünglichen Entwicklung kann zu schlechter
wartbarem Quellcode und damit zu höheren Folge-
• Vermeidung von globalen Variablen kosten führen) und bei der Planung von Qualitätsmaß-
nahmen (automatische und manuelle Prüfungen).
Welche Besonderheiten gibt es im ABAP-Umfeld?
• Nutzen Sie eine einheitliche, natürliche Sprache,
• Die Vermeidung abstrakter Begriffe ist teilweise schwierig. Vor allem bei älteren deren Begriffe im Quellcode, in den Dokumenten und
Entwicklungen (klassische SAP-Module) trifft man auf eine Vielzahl von deut- in Gesprächen mit Kollegen und Kunden möglichst
schen Abkürzungen und Bezeichnern, die in internationalen Projektteams oder identisch sind. Orientieren Sie sich an der SAP-Termi-
bei Junioren mit wenig SAP-Hintergrundwissen den Einstieg in die Materie nologiedatenbank (Transaktion SAPTERM oder http://
zusätzlich erschweren.
www.sapterm.com/).
• Die Entwicklungsumgebung schränkt den Einsatz von natürlicher Sprache zur • Definieren Sie Vorgaben für den einheitlichen Umgang
Benennung von Repository-Objekten und anderen Bezeichnern zum Teil sehr mit Bezeichnern. Berücksichtigen Sie dafür Ihren
stark ein. Hinzu kommt, dass ABAP im Gegensatz zu anderen Programmier- Bezug zur SAP-Software (Kunde / Produktlieferant),
sprachen einen globalen und keinen paketgebundenen Namensraum verwendet.
die Menge des kundeneigenen Quellcodes, sowie die
In Kombination mit Präfixnamensräumen (/*/) fördern diese Umstände den
Einsatz von schwer lesbaren Abkürzungen und können sich negativ auf die
Aufbau- und Ablauforganisation Ihrer SAP-Entwick-
Produktivität der Entwickler auswirken. lungsabteilung (Generalisten / Spezialisten in nationa-
len / internationalen Teams). Je nach Konstellation
Sieht man von diesen Besonderheiten ab, lassen sich die oben genannten Prinzipien der vorangegangenen Eigenschaften kann die Regu-
gut umsetzen. Hilfreich sind die Refactoring-Werkzeuge der ABAP-Development-Tools lierung für den Umgang mit Bezeichnern (z.B. Variab-
(ADT) für Eclipse (vgl. Kapitel 9). Durch den Einsatz von ADT lassen sich z.B. einzelne lenbezeichnung sales_organization statt vkorg8, oder
Variablen oder ganze Klassen auf einen Schlag in allen gefundenen Verwendern
index statt i) die Wartungs- und Weiterentwicklungs-
umbenennen, wodurch sich der Aufwand (und das Fehlerrisiko) für die Korrektur eines
unpassend gewählten Bezeichners auf ein Minimum reduziert. aktivitäten beeinflussen. Nachfolgende Tabelle soll
Sie bei der Entscheidungsfindung unterstützen.
8 Die fünfstelligen Feldbezeichner aus den klassischen Modulen sind ein Sonderfall. Wenn sie in Strukturen verwendet werden, fällt bei
Umstellung auf sprechende Bezeichner einiger Aufwand (und Fehlerrisiko) für das Mapping in beide Richtungen an. Daher kann die
Beibehaltung (trotz schlechterer Lesbarkeit) sinnvoll sein.

Kleines Große / Einheit- Add-on Softwarestrukturierung mit dem SAP-Paketkonzept
Modul- Viel Wenig
zentra- Dezent- liche Multi- Genera- Ent-
spezia- Custom Custom
les rale Mutter- lingual listen wick-
listen Code Code Mit der Einführung des SAP NetWeaver Application Servers 6.20 wurde das Konzept
Team Teams sprache lung

der Entwicklungsklasse vollständig durch das SAP-Paketkonzept ersetzt und um viele
∙ ∙∙ ∙ ∙∙∙ ∙ ∙∙ ∙∙∙ ∙ ∙∙ Eigenschaften zur besseren Softwarestrukturierung erweitert. Neben der groben
∙ ∙ ∙ Starke Beeinträchtigung der Wartungs- / Weiterentwicklung durch schlechte Lesbar- Dokumentation des Systemaufbaus liegt die wesentliche Aufgabe des Paketkonzeptes
keit / Bezeichnerwahl darin, zusammengehörige Objekte in einen gemeinsamen Rahmen einzubetten, den
∙ Geringe Beeinträchtigung der Wartungs- / Weiterentwicklung durch schlechte Zugriff auf Objekte zu regulieren und die Abhängigkeit zu anderen Paketen zu kontrol-
Lesbarkeit / Bezeichnerwahl lieren. Die Erläuterung der Einzelheiten zum Thema Paketkonzept würde den Umfang
dieses Leitfadens sprengen, weshalb wir auf die vorhandene SAP-Help-Dokumentati-
on9 und auf die sehr ausführlichen SCN-Artikel10 verweisen. Objektiv betrachtet, lassen
Code-Formatierung sich Paketstrukturen auf Basis von fachlichen, technischen und organisatorischen
Kriterien bilden, wobei nachfolgende Liste die gängigsten Kriterien aufführt:
Übersichtlicher, leserlicher Quellcode erleichtert jedem Entwickler die (erneute)
Einarbeitung in den Quellcode. Als einfachste und schnellste Möglichkeit, Quellcode gut • Abhängigkeit zur Softwarekomponente
lesbar zu machen und zu halten, kann der Pretty Printer bzw. der Formatierer aus der
ABAP-Entwicklungsumgebung bzw. den ABAP Development Tools genutzt werden. Mit • Zuordnung zur SAP-Standard-Anwendungshierarchie
einem einzigen Knopfdruck/Shortcut wird der ausgewählte Quellcode einheitlich
formatiert. Er bietet verschiedene Konfigurationsmöglichkeiten. In der klassischen • Wiederverwendbarkeit der Entwicklungsobjekte
Workbench des SAP GUIs sind diese in den Workbencheinstellungen zu finden, in den
ABAP Development Tools müssen die Einstellungen in den projektspezifischen Forma- • Gruppierung einzelner Anwendungen
tierereigenschaften hinterlegt werden. Wir empfehlen, den Quellcode einzurücken,
Schlüsselwörter in Großbuchstaben sowie Bezeichner in Kleinbuchstaben darzustellen. • Stabilität der Entwicklungsobjekte
Dadurch kann man Quellcode auch in ausgedruckter Form und ohne Syntaxeinfärbung
leicht verstehen. Der Pretty Printer / Formatierer ermöglicht somit auf einfachem Weg • Layerspezifische / technische Zugehörigkeit
ein einheitliches Quellcodelayout. Wir empfehlen, die Option „Standardkommentare
einfügen“ zu deaktivieren, da die erzeugten Kommentare bei Änderungen nicht automa- • Organisatorische Zuordnung der enthaltenen Objekte
tisch angepasst werden und redundante Informationen enthalten.
• Übersetzungsrelevanz der Entwicklungsobjekte
BEST PRACTICE
Wir empfehlen, den Pretty Printer / Formatierer zu ver-
wenden und die Einstellungen als einheitliche Vorgabe
zu definieren. Neben den Einstellungen im Pretty Printer
empfehlen wir außerdem, die funktionale Schreibweise
von Methodenaufrufen zu verwenden und auf den Aus-
druck CALL METHOD zu verzichten.
9 Vgl. SAP Help Portal – Suche nach Schlagwort Package Builder

10 Vgl. SCN-Artikel Tobias Trapp „ABAP Package Concept – Pert 1 – 4“

BEST PRACTICE • Gruppieren Sie Repository-Objekte über ein paket
• Nutzen Sie Strukturpakete, um die Abhängigkeit von spezifisches Namensraumpräfix. Orientieren Sie sich
verschiedenen Softwarekomponenten hervorzuhe- dabei an der Anwendungshierarchie oder an einem
ben, umfangreiche Eigenentwicklungen sinnvoll zu Produktkürzel (Beispiel: Alle Objekte in der Pakethier-
gruppieren oder wenn Sie die Paketprüfung verwen- arche zu dem Hauptpaket Z_SALES_SUPPORT erhal-
den möchten. ten das Präfix SAS: Klasse ZCL_SAS_FIELD_WORKER,
• Prüfen Sie im Rahmen Ihrer Entwicklung, ob im Stammdatentabelle ZSASFIELDWORKERS, etc.).
Kundennamensraum bereits ein Hauptpaket für die
passende Top-Level-Anwendungskomponente (SE81)
existiert und legen Sie es anderenfalls an.
Paketschnittstellen und Verwendungserklärungen
• Ordnen Sie Pakete immer der semantisch am besten
passenden Anwendungskomponente zu. Der Paketzugriff lässt sich auf allen Paketebenen über Paketschnittstellen und
• Verwenden Sie Pakethierarchien, um Ihre Soft- Verwendungserklärung definieren. Während die Paketschnittstelle der Bekanntma-
waresysteme zu organisieren. Jedes Softwaresystem chung wiederverwendbarer Komponenten des Pakets dient, lässt sich über die
sollte mindestens über ein Hauptpaket verfügen, das Verwendungserklärung der Zugriff auf die Komponenten kontrollieren. Programmiert
ein Entwickler an der Paketschnittstelle vorbei und greift z.B. auf SAP-Standard-Kom-
seine Teilsysteme zusammenhält und deren wesentli- ponenten zu, die nicht über eine Paketschnittstelle freigegeben sind, kann das einen
che Absicht verdeutlicht. nicht zu unterschätzenden Aufwand auf Kundenseite im Rahmen von Upgrade-Aktivi-
• Setzen Sie Entwicklungspakete ein, um die seman- täten bedeuten. Was bei Nutzung von nicht freigegebenen Komponenten passieren
tisch und technisch zusammenhängenden Reposito- kann, ist exemplarisch im SCN-Blog11 beschrieben.
ry-Objekte an einer zentralen Stelle zu bündeln.
Sie können den Zugriff auf Komponenten anderer Pakete optional über das Konzept der
• Vermeiden Sie gegenseitige Abhängigkeiten zwischen Paketprüfungen steuern. Weitere Details für die Aktivierung der Paketprüfung sind in
zwei oder mehreren Paketen. Lagern Sie die abhängi- dem SAP-Hinweis 64889812 enthalten. Nach der Aktivierung können Sie die Werkzeuge
gen Komponenten in separate Pakete aus, so dass nur des Paketes SPAK_API nutzen und die Paketzugriffe kontrollieren.
noch eine einseitige Abhängigkeit besteht.
• Ordnen Sie Pakete mit einseitiger Abhängigkeit
möglichst weit oben in der Pakethierarchie Ihres
Softwaresystems an. Entsteht Bedarf, die Funktiona-
lität aus mehreren Softwaresystemen zu verwenden,
kann das Paket in ein allgemeines Basispaket ausge-
lagert werden.
11 Vgl. http://scn.sap.com/community/abap/blog/2013/01/28/is-sap-nw-ehp-3-really-non-disruptive
12 Vgl. https://launchpad.support.sap.com/#/notes/648898

Paketnamensräume
BEST PRACTICE Neben den allgemein bekannten Kundennamensräumen Y*, Z* und /namespace/ bietet
• Prüfen Sie vor der Wiederverwendung eines paket- SAP über das Paketkonzept die Bereiche $* und T* an. $TMP dürfte jedem Entwickler
geläufig sein. Aber wissen Sie auch, dass Sie die beiden Namensräume auch für eigene
fremden Repository-Objekts erst, ob das Objekt in
Pakethierarchien im Sinne von lokalen Entwicklungspaketen nutzen können? Der
einer Paketschnittstelle freigegeben wurde. Nur Unterschied zwischen den beiden Namensräumen besteht darin, dass $* nicht
Objekte die über eine Paketschnittstelle freigegeben transportiert werden kann und sich der Entwickler manuell um die Versionierung
sind, gewährleisten eine langfristige Stabilität. Im kümmern muss. Im Gegensatz dazu lässt sich der Inhalt von T* Paketen manuell via
SAP-Standard reduziert die Verwendung solcher Transport von Kopien in alle Systeme, die nicht als Produktivsystem gekennzeichnet
Objekte die Gefahr vor Veränderung bei einem sind, transportieren. Aus Sicht der Softwarestrukturierung ergeben sich daraus
Releasewechsel. folgende Vorteile:
• Stellen Sie den Zugriff auf Objekte eines Paketes über • Die Einarbeitung in neue Pakete ist einfacher, da weniger Overhead für die
die Definition von Paketschnittstellen zur Verfügung. Identifikation von halb fertig entwickelten Test- und produktiv genutzten Kompo-
Nur durch eine stringente Einhaltung der Pa- nenten entsteht.
ketschnittstellen lässt sich gewährleisten, dass die
• Produktivsysteme werden nicht mit unnötiger und evtl. sicherheitskritischer
von Ihnen definierte Paketstruktur eingehalten wird
Funktionalität überfrachtet.
und kein wilder Zugriff auf die Objekte Ihres Paketes
stattfindet. • Wartungs- und Weiterentwicklungskosten lassen sich reduzieren, da notwendige
• Bieten Sie bei Bedarf mehrere Paketschnittstellen an Änderungen zwingend nur in produktiv genutzten Paketen durchgeführt werden
müssen.
und gruppieren Sie die Schnittstellen auf Basis
semantischer Informationen, wie z.B. Datenmanipula-
tion oder Reporting-Werkzeuge, oder nach Verwen-
dungskriterien.
BEST PRACTICE
• Reichen Sie Ihre Paketschnittstellen bei Bedarf in der • Nutzen Sie einen passenden Namensraum für die
Pakethierarchie weiter nach oben. Dort haben Sie die Anlage Ihrer Pakete. Orientieren Sie sich an der
Möglichkeit, die Zugriffe weiter einzuschränken oder Transportrelevanz und dem Verwendungszweck der
die freigegebenen Elemente auch außerhalb Ihres Entwicklung (Testentwicklung lokal / Testentwicklung
Systems zugänglich zu machen. mit abweichendem Transportziel).
• Schränken Sie die Verwendung von kritischen Funkti- • Achten Sie darauf, dass lokale Entwicklungen nicht in
onen ein, indem Sie für diese Objekte separate Pa- das Produktivsystem gelangen.
ketschnittstellen anbieten. Die Nutzungsrechte der
Schnittstellen können Sie über die Definition einer
Einschränkung von Verwenderpaketen ausprägen.

Einsatz des Paketkonzepts Die ABAP Development Tools (siehe Kapitel 9) bieten umfangreiche Möglichkeiten für
das Refactoring an, wie zum Beispiel die automatische Methodenextraktion, mit der
Die vollständige Nutzung aller zur Verfügung stehenden Mittel des Paketkonzeptes ist man den Quellcode nachträglich besser modularisieren kann (natürlich gibt es auch
nicht für jedes Unternehmen gleich geeignet und kann bei falscher Ausprägung nicht hier Grenzen, sodass manuelles Editieren notwendig sein kann).
zu rechtfertigende Mehraufwände bedeuten. Um Ihnen bei der Entscheidungsfindung
zu helfen, stellen wir Ihnen nachfolgende Tabelle zur Verfügung. Vermeidung von globalen Variablen
Die Bewertungskriterien orientieren sich an den Werten (+) = weniger wichtig bis (+++)
= sehr wichtig. Neben der Aufteilung des Programmtextes betrifft die Modularisierung auch die
Sichtbarkeit der Variablen. Diese sollte so gering wie möglich gehalten werden.
Regiona-
Große / Überset-
Kleines le Viel Wenig Add-on- Globale Variablen zerstören die Modularisierung eines Programms. Sie erschweren
Dezent- zungs-
zentrales Spezial- Custom Custom Entwick- das Verständnis und die Wartbarkeit massiv. Fehlerbehebungen und Erweiterungen
rale Aktivitä-
Team entwick- Code Code lung sind oft nur noch in der Art „Versuch und Irrtum“ möglich.
Teams ten
lung
Allg.
Paket- ++ +++ ++ +++ +++ ++ ++
konzept
BEST PRACTICE
Paket
schnitt- ++ +++ +++ + +++ + +++
Vermeiden Sie sämtliche globale Variablen.
stellen
Struktur-
+ ++ + ++ ++ + +++
pakete
Paket- Grenzen der Regel
+ ++ ++ + +++ + +++
prüfung
Bei kleinen Programmen mit nur wenigen, überschaubaren Modularisierungseinheiten
sind globale Variablen meist unschädlich (durch die geringe Größe ist das Programm
Modularisierung normalerweise übersichtlich und „versteckte“ bzw. wenig offensichtliche Nebenwirkun-
gen durch Änderungen an globalen Variablen sind unwahrscheinlich). Globale Variablen
Programme, in denen logische Verarbeitungseinheiten zu lang sind und nicht aufgeteilt lassen sich leider nicht in allen Fällen vermeiden. Insbesondere für die Elemente
werden, sind in weiterer Folge schwer lesbar und damit schwer wart- und erweiterbar. klassischer Dynpros und Selektionsparameter sind sie weiterhin erforderlich.
Eine Modularisierungseinheit (Form-Routine, Methode, Funktionsbaustein) soll logisch Eine weitere Ausnahme sind Druckprogramme unter der Technik SAPSCRIPT, welche
zusammengehörende Anweisungen zusammenfassen. Dabei ist jedoch zu beachten, explizit mit globalen Variablen arbeitet. Hier sollte man aufgrund der Lesbarkeit
dass die einzelnen Einheiten nicht triviale Funktionalitäten abdecken: Modularisie- immer mit Rückgabeparametern arbeiten, welche dann entsprechend in globalen
rungseinheiten mit sehr wenigen Anweisungen sind zu vermeiden, es sei denn, sie Variablen verfügbar gemacht werden.
dienen der besseren Lesbarkeit des Quellcodes und sind damit Teil der Dokumentation
des Quellcodes. Vermeidung von Code-Kopien
Die Modularisierung dient dazu, trotz Komplexität in der Aufgabenstellung, den Doppelter oder mehrfach existierender Quellcode (Klone) erschwert die Fehlerbehe-
Quellcode übersichtlich zu gestalten. Siehe hierzu auch Abschnitt „2.12 Programmier- bung, Funktionsänderung oder -erweiterung, da sichergestellt werden muss, dass alle
modell: Objektorientiert vs. Prozedural“. Kopien gefunden und angepasst werden. Hinzu kommt, dass die Kopien üblicherweise
nicht mehr 100%ig identisch sind und mit viel Mühe herauszufinden ist, ob und wo sie
sich unterscheiden.

Ein Sonderfall sind Kopien des SAP-Standards. Siehe hierzu Kapitel 8.4 Anpassung der 2.4 TRENNUNG VON PRÄSENTATIONS- UND ANWENDUNGSLOGIK
SAP-Funktionalität.
In allen Programmen sollte stets eine Trennung von Präsentations- und Anwendungs-
logik erfolgen. Dies erlaubt es, Ergebnisse und Funktionen der Anwendungslogik
durch verschiedene User Interfaces (UIs) dem Benutzer anzuzeigen sowie über eine
einheitliche Schnittstelle anderen Systemen bereitzustellen. Diese Aussage ist für alle
BEST PRACTICE gängigen UI-Technologien gültig, wobei der Grad der Unterstützung bzw. Einhaltung
Befolgen Sie das DRY-Prinzip: „Don’t repeat yourself“13 dieser logischen Trennung unterschiedlich ist. In einer Floorplan-Manager/Web-Dyn-
und lagern Sie vor der erneuten Verwendung den Quell- pro-ABAP-Realisierung ist schon vom Framework eine Trennung zwischen Modell-
code in eine separate Methode aus. 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 wie bei Floorplan-Manager/Web Dynpro, für den entsprechende Prüfungen im
Code Inspector realisiert sind. Die gleichen Grundsätze gelten natürlich auch bei der
Anmerkungen UI5-Entwicklung (siehe Kapitel 10), bei der die Oberflächentechnologie bereits das
Model-View-Controller-Muster vorsieht und die Applikationslogik vom jeweiligen
Eine etwas großzügigere Formulierung des DRY-Prinzips ist die Dreierregel14, nach Backend zur Verfügung gestellt wird.16
der die erste Kopie noch erlaubt ist.
Ein typisches Beispiel für eine klare Trennung von Anwendungslogik und UI sind
Bei der Suche von Code-Kopien15 sollte generierter Quellcode ausgenommen werden, Plausibilisierungsregeln. Wenn die Plausibilisierung von Eingaben in einer bestimmten
da es sich hier um bewusste Kopien handelt. UI-Technologie (in der Präsentationsschicht) entwickelt wird, müssen diese Prüfungen
bei einem Wechsel auf eine andere UI-Technologie neu entwickelt werden. Um dies zu
Mehrere Anweisungen in einer Zeile, Method Chaining vermeiden, sollten die Funktionen zur Prüfung von Eingaben oder Parametern unab-
hängig von der verwendeten UI erstellt und gepflegt werden.
Um die Lesbarkeit des Quellcodes zu erhöhen, empfehlen wir, auf mehrere Anweisun-
gen in einer Codezeile zu verzichten. Meist ist es darüber hinaus auch sinnvoll, den Quellcode für das Datenmodell bzw. die
Datenbankzugriffe getrennt zu halten, sei es (bei kleinen, nicht auf Wiederverwendung
Eine Ausnahme stellt das Method Chaining dar. Durch die Verkettung von Methoden- zielenden Entwicklungen) über eine separate lokale Klasse, oder über Frameworks
aufrufen können Variablen, die nur zum Halten von Zwischenergebnissen eingeführt wie BOPF (Business Object Processing Framework17). Dies entspricht dem klassischen
würden, vermieden und der Quellcode so lesbarer gestaltet werden. Eine sehr tiefe Model-View-Controller-Muster.
Verkettung von Methoden kann jedoch insbesondere in Kombination mit wenig spre-
chenden Methodennamen die Lesbarkeit reduzieren. Eine pauschale Richtlinie kann
daher nicht gegeben werden.
13 Vgl. https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
14 Vgl. http://en.wikipedia.org/wiki/Rule_of_three_(programming) 16 SAP-Roadmap für die Oberflächenstrategie
15 Zum Beispiel mit dem SAP Clone Finder, Transaktion CCAPPS 17 http://scn.sap.com/community/abap/bopf

2.5 INTERNATIONALISIERUNG Um den Aufwand für Übersetzungen zu reduzieren, sollten bei der Festlegung einer
Übersetzungsstrategie die folgenden Aspekte berücksichtigt werden:
Sprachabhängige Texte in Programmen dürfen nicht „hart codiert“ werden, sondern
müssen in Textelementen (Programmtexte, Klassentexte, Online-Text-Repository • Nutzung der Sprache Englisch als zentrale Originalsprache
[OTR]), Standardtexten oder Nachrichtenklassen hinterlegt werden. Da alle Eigenent-
wicklungen den Anspruch haben sollten, weltweit eingesetzt zu werden, sollten alle • Definition einer Übersetzungstiefe (z.B. nur Oberflächentexte, Oberflächentexte
Texte in die jeweils wichtigsten Sprachen übersetzt werden. und F1-Hilfen, Komplettübersetzung) mit Orientierung am SAP Standard Transla-
tion Level18
Konfigurierbare sprachabhängige Texte werden in eigenen Texttabellen abgelegt. Eine
solche Texttabelle besitzt dieselben Schlüsselattribute wie die zugehörige Customi- • Zuordnung der Pakete zur SAP-Anwendungshierarchie, um für die Verteilung von
zing-Tabelle und verweist auf diese über eine Fremdschlüsselbeziehung. Zusätzlich Toptexten domänenspezifische Textvorschläge nutzen zu können
muss das erste Schlüsselattribut nach dem Mandantenfeld das Sprachenattribut sein
(Datenelement SPRSL oder SPRAS). • Kennzeichnung technischer Texttabellen, die nicht übersetzungsrelevant sind
• Nutzung von Langtextobjekten (z.B. via SO10) statt der Aufteilung von Texten in
mehrere Zeilen
BEST PRACTICE • Verwendung einer einheitliche Terminologie und Schreibweise von Bezeichnern
• Wir empfehlen, den Code Inspector bzw. ATC für die mit Hilfe der Terminologiedatenbank
Suche nach nicht übersetzbaren Texten zu verwen-
den. • Vermeidung anonymer Platzhalter (&) in Nachrichtentexten (stattdessen Nutzung
von &1 &2 &3 &4, da deren Positionierung im Nachrichtentext in verschiedenen
• Um spätere Übersetzungen einfach zu gestalten, Sprachen unterschiedlich sein kann)
sollte die Länge der Feldbezeichner und Textelemen-
te möglichst lang gewählt werden. Als Faustregel für • Arbeiten mit Auffüllsprachen in Systemen ungleich dem Entwicklungssystem für
die Länge von Textelementen hat sich bewährt, die die Auffüllung von Übersetzungslücken in den Zielsprachen Einsatz der Pseudo-
sprache 2Q für technische Oberflächentests19
1,5-fache Länge der nativen Beschreibung vorzusehen.
• Verwendung des SAP-Paketkonzeptes für die Trennung von übersetzungsrele-
vanten von nicht übersetzungsrelevanten Elementen
WEITERE QUELLEN
1. Vortrag „Best Translation Practices in SAP Custom Development Projects“ von

Lindsay Russel (SAP SE)
18 Vgl. https://websmp102.sap-ag.de/~form/handler?_APP=00200682500000002672&_EVENT=DISPLAY&_SCENA-
RIO=01100035870000000122&_HIER_KEY=501100035870000008578&_HIER_KEY=601100035870000248115&
19 http://www.se63.info/pseudo-localization-sap-applications/

2.6 DYNAMISCHE PROGRAMMIERUNG UND AUDITIERBARKEIT Beispiel 2 – Dynamische WHERE-Bedingung
Dynamische Programmierung Zur Laufzeit wird die WHERE-Bedingung für eine Datenbankoperation, z.B. SELECT, in
einer String-Variablen erstellt. Dadurch können komplizierte CASE-Abfragen vermie-

In der „klassischen“, statischen Entwicklung werden Entwicklungsobjekte und den werden, die abhängig von den Eingaben verschiedene Open-SQL-Befehle ausfüh-
Quellcode zur Designzeit definiert und im SAP-System statisch hinterlegt. Zur Laufzeit ren.
wird der vorgegebene Quellcode ausgeführt. Im Gegensatz dazu ermöglicht die
dynamische Programmierung die Flexibilisierung des Quellcodes. Das nachfolgende Beispiel 3 – Ersetzen von sogenanntem Boilerplate Code 20
Beispiel verdeutlicht die dynamische Programmierung:
Dynamische Programmierung kann auch dazu verwendet werden, ähnliche Logik nicht
Im Quellcode wird der Name einer aufzurufenden ABAP-Klasse nicht statisch hinter- immer wieder in nahezu identischen Varianten neu zu implementieren. Ein Beispiel
legt, sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren Name durch wäre eine Datenbankzugriffsschicht: die Tabellen unterscheiden sich zwar, der
den Inhalt einer Variablen oder durch eine Customizingeinstellung definiert ist. Der Algorithmus ist aber immer der gleiche. In diesem Fall lässt sich das Problem mittels
Name und damit die konkret ausgeführte Implementierung kann z.B. aufgrund von dynamischer Programmierung oder Generierung des Quellcodes auflösen. Dies ist mit
Benutzereingaben variieren. einem Mehraufwand verbunden, der sich je nach Szenario aufgrund der besseren
Wartbarkeit wieder amortisiert.
Der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität und ihr Nachteil in der
erhöhten Komplexität. Je nach Art der dynamischen Programmierung können auch Nachteile:
Sicherheitsrisiken damit verbunden sein. Tools zur automatischen Erkennung von
Sicherheitsrisiken funktionieren für dynamischen Quellcode schlechter. • urch die Nutzung von dynamischen Aufrufen geht der Verwendungsnachweis
D
innerhalb der ABAP-Entwicklungsumgebung verloren. Problematisch sind dann
Vorteile: Änderungen an den Aufrufzielen.
• Steigerung der Flexibilität • Bei der dynamischen Programmierung ist in der Regel zur Designzeit keine
syntaktische Prüfung möglich. Dies kann bei fehlerhafter Belegung der
• Steigerung der Wiederverwendbarkeit variablen Inhalte (z.B. fehlerhafte Klammerung innerhalb einer dynamischen
WHERE-Klausel, fehlerhafter Name einer Klasse) einen Abbruch bei der
• Vermeidung von Kopien und damit Verkleinerung der zu wartenden Quellcode-Menge Programmausführung verursachen.
Beispiele zu den Vorteilen: • Die dynamische Programmierung birgt hohe Sicherheitsrisiken, wenn die
dynamischen Inhalte durch ungeschützten Zugriff beeinflussbar sind (z.B. wenn
Beispiel 1 – Eigener Aufbau von User Exits eine WHERE-Bedingung durch Benutzereingaben beeinflusst werden kann;
Stichwort: SQL-Injection).
Durch die statische Definition einer abstrakten Klasse inkl. Methodensignatur wird das
Grundgerüst für einen „User Exit“ vorgegeben. Anschließend können mehrere konkre- • Die Komplexität des Quellcodes erhöht sich.
te Implementierungen der abstrakten Klasse angelegt werden. Zur Laufzeit wird z.B.
aus einer Customizing-Tabelle der Name der zu verwendenden konkreten Klassenim-
plementierung gelesen und diese aufgerufen. Somit können unterschiedliche Imple-
mentierungsvarianten per Customizing aktiviert/deaktiviert werden.
20 https://de.wikipedia.org/wiki/Boilerplate#Programmierung

BEST PRACTICE BEST PRACTICE
• Dynamische Programmierung sollte nur sehr dosiert • Verwenden Sie keine Techniken, um Ihren Quellcode
und kontrolliert zum Einsatz kommen. Quellcode, der zu verstecken, und vereinbaren Sie dies auch in
dynamische Anteile enthält, sollte nach dem Vier-Au- Verträgen mit externen Entwicklern.
gen-Prinzip kontrolliert und dokumentiert werden, • Aufgrund von möglichen Problemen bei Wartungsak-
denn er stellt ein potenzielles Sicherheitsrisiko dar.21 tivitäten durch unterschiedliche Entwickler raten wir
• Für generierten Quellcode sollte nach der Generie- davon ab, das Sperrkennzeichen für die Änderbarkeit
rung eine Syntaxprüfung mit dem Befehl SYNTAX- von Quellcode zu nutzen. Alternativ lässt sich der
CHECK durchgeführt werden. Schutz des Quellcodes durch dessen Auslagerung in
• Für dynamischen oder generierten Quellcode sollten separate Pakete erreichen, wobei die Berechtigung
die Prüfmechanismen der Klasse CL_ABAP_DYN_PRG auf bestimmte Personen über das Berechtigungsob-
genutzt werden, mit denen z.B. Whitelists für dynami- jekt S_DEVELOP und einer expliziten Ausprägung von
sche Tabellenzugriffe verwendet werden können. DEVCLASS eingeschränkt werden kann.
Im Kapitel 5.2 wird das Thema dynamische Programmierung auch im Kontext Sicher- 2.7 NEUE SPRACHELEMENTE
heit behandelt.
Mit NetWeaver 7.40 und 7.50 wurde die ABAP-Syntax stark erweitert.22 Die Neuerun-
Auditierbarkeit von ABAP-Quellcode gen lassen sich grob in zwei Themen aufteilen:
Es muss jederzeit möglich sein, durch manuelle Untersuchungen oder statische 1. E

rmöglichung der in vielen anderen Programmiersprachen üblichen Ausdrucks
Codeanalyse-Tools den selbst geschriebenen ABAP-Quellcode auf Mängel zu untersu- orientierung
chen. Alle Methoden, ABAP-Quellcode unsichtbar zu machen, sind unzulässig. Sie
behindern solche Untersuchungen und können sogar gezielt dafür verwendet werden, Diese ersetzt die bisherige Anweisungsorientierung, die noch aus den ABAP-
Hintertüren in ein System zu schleusen. Verschleierter Quellcode (z.B. Makros) kann Ursprüngen als Makro-Sprache herrührt. Die ABAP-Entwickler sollen sich bei
mit dem Debugger nicht (mehr) untersucht werden, was neben der Auditierbarkeit der Programmierung auf das, was gemacht werden soll, konzentrieren können,
auch die Fehleranalyse erschwert. Es wird an dieser Stelle explizit darauf verzichtet, anstelle auf das wie (siehe die vielen Hilfskonstrukte im alten Quellcode im unten
die Techniken zu erläutern, mit denen Quellcode versteckt werden kann. nachfolgenden Beispiel).
2. Unterstützung des „Code2Data“-Paradigmas
emeint ist die Verlagerung von datenintensiven Operationen vom Anwendungs-

G
server in die Datenbank, was auch als „code pushdown“ bezeichnet wird. Die
zugehörigen Spracherweiterungen sind teilweise datenbankübergreifend
21 Zum Auffinden dynamischen Quellcodes (Vorauswahl für die Vier-Augen-Prüfung) können die Sicherheitsprüfungen des Code 22 http://scn.sap.com/community/abap/blog/2013/07/22/abap-news-for-release-740
Inspectors / ATC verwendet werden. http://scn.sap.com/community/abap/blog/2015/11/27/abap-language-news-for-release-750

(Erweiterungen OpenSQL, Core Data Service -CDS Views23), teilweise HANA- Folgende Spracherweiterungen scheinen uns besonders elementar:
spezifisch (AMDP – ABAP Managed Database Procedures). Für den Einsatz der
HANA-spezifischen Sprachelemente muss zwischen universeller Lauffähigkeit Mit SAP NetWeaver 7.02 eingeführt:
auf allen Datenbanken gegenüber Performanceoptimierung für SAP HANA

abgewogen werden. • Inline-Berechnungen und Inline-Methodenaufrufe
Um einen Eindruck von den neuen Möglichkeiten der Ausdrucksorientierung aus • Zeichenketten-Templates (NW 7.40 Beispiel Zeile 2: Parameter der Display-Methode)
Punkt 1 zu geben, hier ein Beispiel aus dem Blog von Horst Keller (siehe unten):
• Zeichenkettenfunktionen und Reguläre Ausdrücke
Quellcode in NetWeaver 7.0
Mit SAP NetWeaver 7.40:
DATA itab TYPE TABLE OF scarr.
SELECT * FROM scarr INTO TABLE itab. • Inline-Deklarationen (in Zeile 1: DATA(itab))
• Konstruktor-Operatoren VALUE und NEW

DATA wa LIKE LINE OF itab.
READ TABLE itab WITH KEY carrid = ’LH‘ INTO wa. • Tabellenausdrücke (in Zeile 2: itab[ ... ])
DATA output TYPE string. • Neuer Parser für OpenSQL (in Zeile 1: @ als Kennzeichnung für Host-Variablen)
CONCATENATE ’Carrier:‘ wa-carrname INTO output SEPARATED BY space.
• SQL-Ausdrücke
cl_demo_output=>display( output ).
BEST PRACTICE
Entsprechender Quellcode in 7.40 (SP08)
Wir empfehlen, sich mit den neuen Sprachelementen
vertraut zu machen und sie einzusetzen, da die Effektivität
SELECT * FROM scarr INTO TABLE @DATA(itab).
bei der Entwicklung erhöht und die Lesbarkeit des Quell-
cl_demo_output=>display( |Carrier: { itab[ carrid = ’LH‘]-carrname }| ).
codes verbessert werden kann. Hierbei kann die Liste
oben als Einstieg dienen.
23 In NetWeaver 7.40 noch mit Einschränkungen (parametrisierte Views nur auf SAP HANA), ab NetWeaver 7.50 sind die CDS-View-
Funktionalitäten datenbank-agnostisch

In diesem Zusammenhang sind auch die Skills des Teams und die eingesetzten 2.9 AUTOMATISCHE PRÜFUNGEN DER ENTWICKLUNGSOBJEKTE
SAP-Basisversionen in der Systemlandschaft zu berücksichtigen. Ältere SAP-Versio-
nen unterstützen nicht alle neuen Sprachkonstrukte und auch nicht das Code2Da- Für die automatische Überprüfung von Entwicklungsobjekten zur Designzeit bietet SAP
ta-Paradigma. Arbeiten die Entwickler oft in unterschiedlichen Systemen mit unter- verschiedene Werkzeuge an:
schiedlichen SAP-Basisversionen, sollte ggf. deren kleinster gemeinsamer Nenner
verwendet werden, um nachträglichen Mehraufwand bei der Übertragung in ältere • Die einfache Syntaxprüfung wird automatisch bei der Aktivierung ausgeführt und
Systeme zu vermeiden. verhindert die Aktivierung fehlerhafter Entwicklungsobjekte.
Weitere Informationen zu den neuen Sprachelementen finden Sie in der ABAP-Schlüs- • Die erweiterte Programmprüfung kann auf individuellem, bereits aktiviertem
selwort-Dokumentation und den SCN-Blogs von Horst Keller.22 Quellcode (Programmen, globalen Klassen …) ausgeführt werden und berichtet in
drei Prioritäten potenzielle Probleme.
• Der Code Inspector bietet einen umfangreichen Katalog von teilweise konfigurier-
2.8 OBSOLETE ANWEISUNGEN baren Prüfungen, aus denen eine Prüfvariante zusammengestellt werden kann.
Die erweiterte Programmprüfung ist hier enthalten. Es gibt unter anderem auch
SAP vertritt eine strikte Abwärtskompatibilität. Trotzdem muss bei der Verwendung etliche Prüfungen zu den Bereichen Performance und Robustheit. Zusätzlich kön-
von obsoleten Anweisungen, wie z.B. Kopfzeilen in internen Tabellen, berücksichtigt nen eigene Prüfungen programmiert und eingebunden werden.
werden, dass bei der Übernahme von Code in Klassen Probleme auftreten. Für
obsolete Sprachelemente gibt es immer modernere Alternativen. Außer Gewohnheit • Das neueste Werkzeug ist das ABAP Test Cockpit (ATC)24, welches die Prüfvarian-
existieren wenige Gründe für deren Verwendung, deshalb sollten sie vermieden ten des Code Inspectors verwendet und einige Zusatzfunktionen bietet.
werden.
Diese Werkzeuge können von den Entwicklern bereits während der Entwicklung
genutzt werden. Alle sind gut in die ABAP Workbench und die ADT integriert (Ausnah-
me: Die erweiterte Programmprüfung ist von ADT nicht direkt erreichbar).
BEST PRACTICE Zusätzlich kann der Code Inspector oder das ATC über die Transaktion SE03 global
Wir empfehlen den regelmäßigen Einsatz eines statischen angeschaltet werden, um bei der Freigabe von Transportaufträgen frühzeitig Probleme
Codeanalyse-Tools, um obsolete Anweisungen zu ent- oder Schwächen zu erkennen und zu beheben. So kann unnötiger Aufwand für Trans-
decken. Aus den SAP-Bordmitteln eignet sich der Code porte, Test und Fehlersuche eingespart und die Programme performanter, robuster,
Inspector/ATC bzw. die Durchführung des Syntax-Checks. sicherer und besser wartbar gemacht werden.
Um den Zusatzaufwand zu minimieren, sollten die ob- Der Code Inspector oder das ATC werden im SAP-Standard nur bei Freigabe des Trans-
soleten Anweisungen immer dann ersetzt werden, wenn portauftrags ausgeführt. Empfehlenswert (und bei Transportmanagement mit Trans-
porten von Kopien – siehe Abschnitt 8.1.4 – die einzige sinnvolle Möglichkeit) ist die
Entwicklungsobjekte aufgrund anderer Erweiterungen Prüfung bereits bei der Freigabe der jeweiligen Transportaufgabe bzw. bereits bei der
sowieso bearbeitet werden. Dadurch ist auch der zusätzli- Fertigstellung der Entwicklungsobjekte durch den Entwickler. Hierzu muss das BAdI
che Testaufwand in der Regel gering. CTS_REQUEST_CHECK implementiert werden.25
Darüber hinaus existieren sehr gute Analysewerkzeuge
von Drittanbietern.
24 Verfügbar ab NetWeaver 7.4, sowie ab bestimmten SPs von 7.0 und 7.3.
25 Wie dies für den ATC geschehen kann, ist hier beschrieben.

2.10 HARTE CODIERUNG, MAGIC NUMBERS
BEST PRACTICE Unter problematischer Harter Codierung versteht man die Codierung von Daten wie
Viele der in diesem Leitfaden genannten Regeln und Texten, Zahlen, Benutzernamen usw. direkt im Programm, die sich möglicherweise
ändern, z.B. weil sie eigentlich Konfigurationsinformationen (Pfade für Schnittstellen,
Empfehlungen für Entwicklungsobjekte lassen sich durch
…) sind. Harte Codierung spart zunächst Entwicklungszeit, führt aber auf den Gesamt-
die Werkzeuge automatisch prüfen. Die Werkzeuge soll- lebenszyklus der Anwendung bezogen zu höheren Kosten, weil z.B. Konfigurationsän-
ten daher den Entwicklern vertraut sein und frühzeitig im derungen eine Anpassung des Programms erfordern. Wenn der gleiche Wert in
Entwicklungsprozess verwendet werden. Die generelle mehreren Programmen oder Programmteilen hart kodiert wird, ergibt sich zusätzlich
Prüfung mit Code Inspector oder ATC bei Transportfreiga- noch das Problem, dass bei Änderungen alle Stellen angepasst werden müssen (siehe
be sollte konfiguriert werden. Als Voraussetzung hierfür auch „Vermeidung von Code-Kopien“ in Abschnitt 2.3).
muss eine Prüfvariante ausgewählt oder selber konfigu-
Ein verwandtes Thema sind Magic Numbers, also Zahlen, die ohne Erläuterung im
riert werden. Zusätzlich ist festzulegen, wer bei fehlge-
Programm verwendet werden. Das Problem hierbei ist die Verständlichkeit und die
schlagenen Prüfungen Ausnahmen genehmigen darf (z.B. Wartbarkeit des Programms. Auch hier wird also zunächst Aufwand gespart, der aber
Qualitätssicherungs-Beauftragter oder Entwicklungsleiter). bei späteren Anpassungen doch noch aufgewendet werden muss und ggf. sogar höher
ist, falls die Bedeutung der Magic Number erst ermittelt werden muss.
Ein weiterer Aspekt bei der Verwendung von Harter Codierung oder Magic Numbers
Zusätzlich existieren diverse Tools von Drittanbietern, die bereits zur Designzeit den ist, dass dies auch ein Hinweis auf eine Implementierung ohne Berücksichtigung
Quellcode auf Verstöße gegen Entwicklungsrichtlinien überprüfen und dem Entwickler objektorientierter Konzepte sein kann. Ein Beispiel wären CASE Statements über
ein direktes Feedback über bestimmte Eigenschaften der Codequalität liefern. Neben Konstanten, die entweder über die Refactoring Methodik „Replace Code with Subclas-
der Prüfung zur Designzeit bieten die Tools zum Teil auch die Möglichkeit der automa- ses“26 oder via Filter-BAdIs vermieden werden können27.
tischen Korrektur von Fundstellen an.
Kapitel 7, insbesondere Abschnitt 7.2.2 Automatische Prüfungen enthält übergreifende

Empfehlungen zu diesem Themenbereich.
BEST PRACTICE
WEITERE QUELLEN: Problematische Harte Codierung sollte vermieden wer-
den. Magic Numbers sollten durch sprechend benannte
Die Vorgehensweise der Implementierung des BAdIs CTS_REQUEST_CHECK für den Konstanten ersetzt oder mit einem entsprechenden Kom-
Code Inspector ist im Buch „Praxishandbuch SAP Code Inspector“ (SAP Press)
mentar versehen werden.
beschrieben, oder auch in diesem Blog.
Das Buch beschreibt auch die Integration eigener Prüfungen in den Code Inspector /
ATC. Auch hierzu gibt es einen Blog.
Die Benutzung von Konstantennamen, die identisch mit dem Wert sind, sollte unbe-
dingt vermieden werden. Sie führen bei einer Änderung des Wertes zu Fehlinformatio-
nen. (Paradoxerweise ist genau die Änderbarkeit der Hauptgrund für die Verwendung
von Konstanten.)
26 https://sourcemaking.com/refactoring/replace-type-code-with-subclasses
27 siehe dazu auch http://scn.sap.com/docs/DOC-10286

Die Definition von Konstanten sollte als Attribute an einem dediziert dafür vorgesehe- Objektorientierte Entwicklung wurde so konzipiert, dass logisch zusammenhängende
nen Interface oder einer abstrakten, finalen Klasse erfolgen. Von der Verwendung von Aufgaben einheitlich in Objekten zusammengefasst werden können. Dadurch wird
Konstantenincludes raten wir ab. Im Rahmen einer größeren Entwicklung kann es unter anderem auch die Wiederverwendbarkeit von Quellcode erhöht. Insbesondere
sinnvoll sein, nicht alle Konstanten an einem Interface zu hinterlegen, sondern eine können solche Objekte auch von anderen Entwicklern für ihre Zwecke leicht erweitert
fachliche Strukturierung der Interfaces und der enthaltenen Konstanten vorzunehmen. oder verändert werden, ohne dass die grundlegenden Funktionen beeinträchtigt
Dafür bietet es sich an, die Interfaces mit einem Tag-Interface zu versehen (analog werden (Open-Closed-Prinzip). Andererseits können zentrale Funktionalitäten oder
zum BAdI Interface IF_BADI_INTERFACE). So ist die Auffindbarkeit der Interfaces einzelne Variablen auch gezielt vor unerwünschtem Lese- oder Schreibzugriff durch
sichergestellt, die Konstanten beinhalten. aufrufende Programme geschützt werden. Einen ersten Überblick über die Grundprin-
zipien des objektorientierten Designs finden Sie z.B. in Wikipedia29.
Bei der Einführung von Konstanten ist sicherzustellen, dass diese auch von anderen
Entwicklern wiedergefunden werden, da ansonsten identische Konstanten mehrmals Im Rahmen der Einführung der Objektorientierung in ABAP mit ABAP Objects fand
im System hinterlegt werden. Hierfür gibt es leider kein offizielles SAP-Tool, das dies eine Bereinigung der Sprache und Vereinheitlichung der Konstrukte statt. Die Verwen-
automatisch bewerkstelligt. Alternativ kann auf das SAP-Ecosystem zurückgegriffen dung von ABAP Objects führt damit zu einer Steigerung der Wartbarkeit. Die Steige-
und das frei verfügbare Tool ConSea28 verwendet werden. Eine Option wäre die rung der Wartbarkeit kann für kleinere Programme30 bereits durch den Ersatz von
Dokumentation der Konstanten in Interfaces außerhalb des Systems, wobei die FORM-Routinen durch Klassen-Methoden einer lokalen Klasse lcl_main erreicht
Wahrscheinlichkeit hoch ist, dass die Pflege der externen Dokumentation vernachläs- werden, ohne ein striktes objektorientiertes (Re-)Design vorzunehmen.
sigt wird. Ab NetWeaver 7.40 empfiehlt sich die Inline-Dokumentation mittels ABAP-
Doc. Ab NetWeaver 7.50 lässt sich die Dokumentation dann analog zu JavaDoc expor- Die prozedurale Entwicklung in ABAP z.B. mit FORM-Routinen wurde von SAP inzwi-
tieren und so zugänglich machen. Falls die TREX-Suche bereits eingesetzt wird, schen als obsolet eingestuft. Eine prozedurale Entwicklung hat sich im Laufe der Jahre
könnte auch diese zur performanten Suche genutzt werden. auch im Hinblick auf globale Variablen und Includes als sehr unübersichtlich, komplex
und fehleranfällig erwiesen. Das ist ein weiterer Grund, zur objektorientierten Pro-
grammierung zu wechseln.
2.11 BERECHTIGUNGSPRÜFUNG IM QUELLCODE
Beim Zugriff auf Daten sowie bei ihrer Präsentation sind die dafür notwendigen
Berechtigungsobjekte zu prüfen. Bei der Verwendung von Standardobjekten soll die BEST PRACTICE
Prüfung auf die entsprechenden SAP-Standard-Berechtigungsobjekte erfolgen Wir empfehlen Neuentwicklungen möglichst nur noch nach
(vereinfacht die Wartung der notwendigen Rollen). Zur Prüfung kundeneigener
Datenobjekte können in der Regel keine SAP-Standard-Berechtigungsobjekte verwen-
den Prinzipien der Objektorientierung mit ABAP Objects
det werden. Zu diesem Zweck können kundeneigene Berechtigungsobjekte implemen- umzusetzen. Obsolete Sprachkonstrukte des prozeduralen
tiert und geprüft werden. Weitere Informationen finden Sie im Kapitel 5.1.1. ABAP, wie z.B. FORM-Routinen, sollten vermieden und
durch ABAP Objects-Konstrukte ersetzt werden. Diese
Empfehlung deckt sich mit der Vorgabe „ABAP Objects als
Programmiermodell“ der Programmierrichtlinien aus der
2.12 PROGRAMMIERMODELL: OBJEKTORIENTIERT VS. PROZEDURAL ABAP-Schlüsselwortdokumentation.
Es ist ratsam, vom prozeduralen Programmiermodell auf objektorientierte Program-
mierung überzugehen, um zukunftssicher zu entwickeln und Objekte zu kapseln.
Insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden.
29 https://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs
30 Die Obergrenze für „kleine Programme“ in diesem Sinne sehen wir zwischen 200 und 500 Zeilen, je nach Programmierstil
28 Vgl. GitHub und Komplexität der Aufgabe.

Mögliche Gegengründe: 3 PERFORMANCE
• Verfügbare ABAP Objects-Kompetenz im Team sowie der geplante und realistisch In den folgenden Abschnitten empfehlen wir einige Best Practices, die bei der tägli-
erwartete Kompetenzaufbau chen Arbeit in der ABAP-Entwicklung beachtet werden sollten, um für die zu entwi-
ckelnde Anwendung eine gute Performance sicherzustellen. Sofern sich beim Einsatz
3. PERFORMANCE
• Systeme mit älteren Basisreleases, in denen ABAP Objects noch weniger ausge- der SAP-HANA-Datenbank gegenüber anderen Datenbanken Besonderheiten ergeben,
reift war (vor SAP Web Application Server 6.20) bzw. in Systemen/Modulen, in wird hierauf in den jeweiligen Unterkapiteln hingewiesen.
denen auch im SAP-Standard prozedurale Bestandteile dominieren.
WEITERE QUELLEN
3.1 VERMEIDUNGSPRINZIP
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 „Die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und
am leichtesten zu dokumentierenden Teile eines Computersystems sind die, die man
2. Horst Keller and Gerd Kluger, NetWeaver Development Tools ABAP, SAP AG weggelassen hat.“ (Gorden Bell)
3. Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser 1990,

ISBN 3-446-15773-5
4. Wikipedia: Übersicht über Entwurfsmuster BEST PRACTICE

Vermeiden Sie jeglichen unnötigen Quellcode. Dies um-
fasst auch unnötig durchlaufenen Quellcode.
2.13 ENTWICKLUNGSSPRACHE
Alle Entwickler sollten sich mit der gleichen Sprache anmelden und sprachabhängige
Texte in dieser Sprache pflegen. Grundsätzlich sollten sprachabhängige Texte in
übersetzbarer Form angelegt werden.
3.2 PERFORMANCE-OPTIMIERUNGEN NUR AN RELEVANTEN STELLEN
Performance-Optimierungen sollten (insoweit sie Aufwand oder Komplexität erhöhen)

nur an relevanten Stellen erfolgen. Um an diese „Hot Spots“ zu gelangen, muss zuvor
die Performance gemessen werden.

3.3 VORHANDENE WERKZEUGE NUTZEN
BEST PRACTICE Die im SAP-System bereits vorhandenen Werkzeuge bieten eine gute Unterstützung
• Konzentrieren Sie sich zuerst auf die klare und bei der Erstellung von performanten Anwendungen bzw. bei der Analyse von Perfor-
mance-Engpässen.
einfache Implementierung der Sachlogik. Führen Sie
3. PERFORMANCE
dann auf einem System mit genügendem Datenvolu- Die wichtigsten Transaktionen sind
men (meist das Testsystem) Performance-Tests aus,
um – falls das Programm überhaupt langsamer als • ATC/SCI – ABAP-Test-Cockpit / Code Inspector
vom Nutzer gewünscht ist – anschließend an den Statische Analyse von (unter anderem) Performance-Aspekten. Integriert in
relevanten Stellen die Performance zu optimieren. Workbench und ADT, Administration mit Transaktionen ATC und SCI
Eine Ausnahme stellen Programme dar, bei denen
• SAT – Laufzeitanalyse
von vornherein klar ist, dass sie Performance-kri-
Gesamtanalyse zur Laufzeit
tisch sein werden. Für diese sind schon zur Design-
zeit Entscheidungen zu treffen, z.B. Einsatz von • ST05 – Performance-Trace
Parallelisierung. Analyse der in einem Programm ausgeführten SQL-Befehle (und anderer Ereig-
nisse)
• Wir empfehlen, die Suche nach Performance-Eng-
pässen mit dem Einsatz der Laufzeitanalyse (Trans-
aktion SE30/SAT) mit voller Aggregation zu beginnen.
Dadurch sollte deutlich werden, ob die Laufzeit aus Darüber hinaus gibt es einige allgemeine, auch für Performance-Analysen nutzbare
der Interaktion mit der Datenbank oder der Verarbei- Werkzeuge
tung der geladenen Daten im Hauptspeicher resul-
tiert.31 Wichtig ist dabei, dass ein repräsentativer, • SM50/SM66 – Übersicht Workprozesse
praxisnaher Datenbestand verarbeitet wird, um nicht
• Debugger – Schrittweise Ausführung von Quellcode
durch seltene Verarbeitungsmuster einer falschen
Spur zu folgen. Wird mehr als die Hälfte der Laufzeit • ST03 – Systemlastmonitor
im DB-Teil verbraucht, sollte eine genauere Analyse
der SQL-Kommandos mit der Transaktion ST05 • ST22 – Analyse von Laufzeitfehlern (z.B. Speichermangel)
erfolgen. Wird mehr Laufzeit im ABAP-Teil ver-
braucht, erfolgen tiefergehende Analysen mit Hilfe • STAD – Workload-Analyse (Post Runtime)
der Transaktionen SE30/SAT, wobei die Aggregations-
stufen schrittweise verringert werden, um genauere
Aussagen über die kritischen Programmstellen zu Die folgenden Werkzeuge eignen sich für spezielle Performance-bezogene Themen
bekommen. Nach jedem Optimierungsschritt sollten
die Ergebnisse verglichen und dokumentiert werden. • ST04 – DB-Performance-Übersicht
• DB05 – Wertverteilungs-Analyse für Index-Design
31 Ein ersten Überblick über die Verteilung der Laufzeiten zwischen Datenbank und Applikationsserver bekommt man auch mittels der
Transaktion STAD.

• ST10 – Tabellenaufruf-Statistiken zur Prüfung von Tabellenpufferung 3.4 DATENMODELL UND DATENZUGRIFF
• ST12 – Single Transaction Analysis (End-to-End Trace) 3.4.1 DATENMODELL
• S_MEMORY_INSPECTOR – Memory Inspector (auch integriert im SAP GUI Der Aufbau des Datenmodells bildet die Basis performanter Anwendungen. Ein mit
3. PERFORMANCE
Debugger) Augenmaß normalisiertes Datenmodell kann effizienter mit Daten und Indizes arbei-
ten.32 Hierzu finden – unabhängig von der Programmiersprache ABAP – die Normali-
• SQLM/SQLMD – SQL Monitor sierungsregeln Anwendung. Darüber hinaus sollten sich bei der Datenmodellierung im
Aufzeichnung und Analyse aller SQL-Abfragen im Produktivsystem. Data Dictionary die Datenelemente jeweils auf Domänen beziehen. Dieses führt sowohl
Neu seit NetWeaver 7.0/7.4 (Details siehe Hinweis 1885926). zu einer erhöhten Transparenz als auch zu einer verbesserten Wartbarkeit.
• SWLT – Performance Tuning Worklist 3.4.2 DATENBANKZUGRIFFE

Arbeitsvorrat basierend auf ATC- und SQL-Monitor-Ergebnissen.
Neu seit NetWeaver 7.0/7.4 (bestimmte SPs, siehe SAP Dokumentation). Beim Zugriff auf die Datenbank existieren im Wesentlichen fünf Regeln (Quelle: SAP,
siehe Referenz in Abschnitt 3.7), die verwendet werden sollten, um eine performante
Im Kontext der SAP-HANA-Einführung wurden von SAP weitere Tools oder Erweite- Ausführung von Programmen mit Datenbankzugriff sicherzustellen. Die fünf Regeln sind:
rungen bestehender Tools angeboten, um Performance-Probleme frühzeitig zu
identifizieren und ein Vorgehen zu etablieren, das die iterative Optimierung der 1. Die Treffermenge klein halten – Wenn Sie die Menge der selektierten Daten klein
Performance von Anwendungen auf SAP HANA ermöglicht. halten, vermeiden Sie Last sowohl auf dem Datenbanksystem als auch im Bereich
des Netzwerks bei der Übertragung der Daten auf den Applikationsserver.
Die Performance-Analyse in diesem Kontext umfasst eine statische Quellcode-Analyse
durch das ATC mit den drei Prüfvarianten FUNCTIONAL_DB, FUNCTIONAL_DB_ADDI- 2. Die übertragene Datenmenge klein halten – Aufgrund der blockweisen Übertra-
TIONAL und PERFORMANCE_DB. Diese Varianten führen die statische Codeanalyse gung der Daten zwischen Datenbank und Applikationsserver empfiehlt es sich die
unter den Aspekten der Verwendung von SAP HANA als DB durch. Weitere Informatio- zu übertragende Datenmenge klein zu halten und so die Last auf dem Netzwerk
nen sind im Hinweis 1912445 – ABAP Kunden Code Migration für SAP HANA – Empfeh- zu verringern.
lungen und Code-Inspektor-Varianten für eine SAP HANA Migration hinterlegt.
3. Die Zahl der Datenbankzugriffe klein halten – Durch eine Reduktion der Zugriffe
Zusätzlich wurde der ABAP-SQL-Monitor eingeführt. Dieses Tool erlaubt das system- auf das Datenbanksystem können Sie Last vom Datenbanksystem und dem
weite Tracing aller SQL-Abfragen über ein längeres Zeitintervall und mit zusätzlicher Netzwerk reduzieren, da jeder Zugriff Aufwand für die Verwaltung auf dem
Aufzeichnung der „entry points“ (Transaktionen, Reports, usw. in deren Rahmen ein Datenbanksystem mit sich bringt.
SQL-Befehl ausgeführt wurde). Detailliertere Informationen zum SQL-Monitor finden
Sie im SAP Community Network im Dokument „Optimizing Custom ABAP Code for SAP 4. Den Suchaufwand klein halten – Bei der empfohlenen Verwendung von WHERE
HANA – The New ABAP SQL Monitor“. und HAVING-Klauseln können Sie die Performance weiter optimieren, wenn Sie
den Suchaufwand für das Datenbanksystem mittels Verwendung geeigneter
Die Zusammenführung der Laufzeitsicht des SQL-Monitors sowie der statischen Indizes verringern.
Analyse mittels ATC erfolgt über die SQL Performance Tuning Worklist. Diese ermög-
licht den Aufbau eines Arbeitvorrats zur Performance-Optimierung, der nach erfolgter 5. Die (unnötige) Datenbanklast klein halten – Generell sollte unnötige Datenbank
Analyse und Priorisierung abgearbeitet werden kann. Weitere Informationen zum last vermieden werden also z.B. die Durchführung von Berechnung auf der
Vorgehen finden Sie im SAP Community Network im Dokument „Best Practice Guide – Datenbankabfrage, deren Ergebnisse in der Applikation gar nicht benötigt
Considerations for Custom ABAP Code During a Migration to SAP HANA“. werden. Zusätzlich bietet der Application Server ABAP viele Möglichkeiten die
Last der Datenbankressource durch Pufferung klein zu halten.
32 Im S/4HANA-Modell geht man noch einen Schritt weiter und denormalisiert das Datenmodell. Dies ist aufgrund der Art der Datenab-
lage in der In-Memory-DB HANA möglich und führt zu einem vereinfachten Datenmodell sowie zu einem Performancegewinn bei der
Abfrage der Daten.

Die fünf Regeln gelten für jede Art von Datenbanksystem. Im Kontext des Code Push
Downs bzw. des Code-to-Data-Paradigmas mit SAP HANA ist eine geänderte Gewich-
tung der Regeln im Vergleich zu non-HANA Datenbanken zu beachten. Dies ist in Optimale Suchabfrage
Abschnitt 3.6 erläutert. • Versuchen Sie für die Selektion von Daten einen der
vorhandenen Indizes vollständig zu nutzen. Ist dies
3. PERFORMANCE
Unabhängig vom Code Push Down muss bei der Verwendung von SAP HANA als
Datenbank Regel 4 bzgl. der Einführung von Indizes deutlich relativiert werden. In SAP nicht möglich, achten Sie darauf, zumindest die ersten
HANA sollten so wenige Indizes wie möglich angelegt werden. Durch die spaltenba- Elemente eines Index zu verwenden, damit die Daten-
sierte Ablage kann im Prinzip jede Spalte als Index verwendet werden und in der bank den Index bei der Suche nutzen kann.
Theorie werden daher keine Indizes mehr benötigt. Es gibt allerdings speziell im
Zeilenreduzierung
OLTP-Bereich Szenarien bei denen es auch mit SAP HANA sinnvoll ist, Indizes einzu-
führen, da es sonst zu einer schlechten Performance und/oder einem hohem CPU-Ver- • Nutzen Sie die WHERE-Bedingung, um die an das
brauch von SAP HANA kommen kann. Details dazu finden Sie im SAP-Hinweis 1794297 ABAP-System zu übertragenden Daten zu minimie-
– Sekundäre Indizes für die Business Suite auf HANA.33 ren. Verwenden Sie SELECT SINGLE / UP TO n ROWS,
wenn Sie nur einzelne Zeilen benötigen.
Aggregate
• Aggregate (MIN, MAX, …) sind in vielen Fällen (bei
BEST PRACTICES HANA grundsätzlich) sinnvoll, da sie schon auf dem
Spaltenreduzierung Datenbankserver ausgewertet werden, und somit
• Vermeiden Sie an voraussichtlich Performance-kriti- weniger Daten übertragen werden müssen. Beachten
schen Stellen (siehe Abschnitt 3.2), dass unnötige Sie aber, dass eventuell vorhandene Tabellenpuffer in
Spalten, vor allem Large Objects (zum Beispiel diesem Fall vom System nicht genutzt werden, was
Strings), von der Datenbank übertragen werden. einen gegenteiligen Effekt haben kann.
•
Achtung: Entgegen der verbreiteten Meinung stellen Updates
SELECT * und INTO CORRESPONDING FIELDS selbst • Analog zur Spaltenreduzierung beim Lesen kann mit
in diesen Fällen oft kein Problem dar, da das System der Anweisung UPDATE SET die Anzahl der zu schrei-
bereits zur Compile-Zeit die Quell- und Zielfelder benden Spalten reduziert werden. Wenn möglich,
intelligent auswertet. 34 sollte diese Anweisung verwendet werden.
34
33 SAP Hinweis 1794297 – Sekundäre Indizes für die Business Suite auf HANA
34 Vgl. SCN-Artikel „Why ‚INTO CORRESPONDING‘ is much better than its reputation“

Mengenoperationen Bei FOR ALL ENTRIES sollten Sie Folgendes beachten:
• Jede Ausführung eines Open-SQL-Statements ist mit • Ist die interne Tabelle der FOR ALL ENTRIES Anwei-
einem Overhead (Parsen, Abgleich gegen Statement- sung leer, wird die WHERE-Bedingung ignoriert und
3. PERFORMANCE
Puffer im DBMS usw.) verbunden. Daher sollten pro alle Einträge der DB-Tabelle selektiert. Das ist
Statement möglichst viele der benötigten Daten auf meistens nicht gewünscht und kann zu Performance-
einmal übertragen werden. Benötigen Sie z.B. die problemen führen. Sie können das Problem durch
Daten von 50 Aufträgen, sollten Sie diese nicht durch eine Prüfung der Größe der Tabelle vor dem Ausfüh-
50 Einzel-Selects ermitteln, sondern durch eine ren der Abfrage beheben35.
Select-Abfrage. Dies erfolgt durch die Zusätze INTO • Enthält die interne Tabelle der FOR-ALL-ENTRIES-
TABLE bei lesenden bzw. FROM TABLE bei schreiben- Anweisung doppelte Einträge, kann dies dazu führen,
den Zugriffen (Array-Operation). dass Datensätze doppelt von der Datenbank geladen
Vermeidung von MODIFY werden bzw. das SELECT-Statement in der DB
• Setzen Sie MODIFY <DB-Tabelle> nicht ein. Das Schnittstelle unnötig aufgebläht wird. Es empfiehlt
Statement ist aus Performance-Gesichtspunkten sich, ein DELETE ADJACENT DUPLICATES auf der
sehr kritisch: Sogar bei der Verwendung von Array- internen Tabelle vor dem Ausführen der Abfrage
Operationen werden pro Zeile des Arrays zuerst ein auszuführen.
UPDATE und im Fehlerfall im Anschluss ein INSERT • Da bei FOR ALL ENTRIES ein implizites DISTIN-
ausgeführt, was die Performance unnötig verschlech- CT-Select ausgeführt wird, sollten Sie immer alle
tern kann. Schlüsselfelder mit selektieren, da es sonst vorkom-
VIEWS/JOINS men kann, dass nicht alle relevanten Datensätze
• Geschachtelte SELECT-Anweisungen und gelesen werden.
SELECT-Anweisungen in Schleifen sollten vermieden
werden. Stattdessen bieten sich JOINS, Views oder
der Zusatz FOR ALL ENTRIES an.
•
Sehr umfangreiche JOINS (mehr als 5 Tabellen)
sollten vermieden werden, da der DB Optimizer
dadurch behindert werden kann. 3.4.3 ABAP CORE DATA SERVICE (CDS) VIEWS35
ABAP CDS Views sind ein mit NetWeaver 7.40 SP05 eingeführtes DDIC-Artefakt, das im
Gegensatz zu klassischen SE11-Views erweiterte Möglichkeiten für die Definition von
Views bietet. Dies umfasst neben klassischen SQL-Funktionalitäten wie Outer Joins oder
Case-Anweisung auch SQL-Funktionen wie zum Beispiel zur Währungsumrechnung. Des
Weiteren bieten CDS Views die Möglichkeit, Assoziationen zwischen Tabellen zu definie-
ren und so Geschäftsobjekte wiederverwendbar in Form von Views zu definieren.
35 Mit Netweaver 7.40 liefert SAP den Runtime-Check-Monitor, der eine Prüfung zur Laufzeit auf dieses Problem ermöglicht.
Siehe dazu auch Hinweis 1931870 – Downport of transaction SRTCM to SP02 / 03 / 04

Weitere Vorteile sind die Optionen die Views zu parametrisieren (in NetWeaver 7.40
nicht für alle Datenbanken unterstützt) und Annotationen im View bzw. zu View-Fel-
dern zu hinterlegen. Letzteres erlaubt ab NetWeaver 7.50 die einfache Exponierung der BEST PRACTICE
Views mittels OData Service und die Nutzung der Views bzw. der Annotationen zum Wir empfehlen die Beachtung der nachfolgenden Hinweise
automatischen Aufbau von UI5-Oberflächen (z.B. via Smart Templates). Auf SAP HANA
zur Steigerung der Performance von Anwendungen:
3. PERFORMANCE
stehen zusätzlich die CDS Table Functions zur Verfügung, die den Aufruf von SQL-
Script ermöglichen. So stehen alle SAP HANA Features (z.B. Calculation Views) über • Wählen Sie die Tabellenart passend zur späteren
CDS Views zur Verfügung. Weitere Informationen zu ABAP CDS Views finden Sie in der Verwendung. Details hierzu finden Sie in der Schlüs-
ABAP-Schlüsselwertdokumentation zum Netweaver 7.40 36 bzw. NetWeaver 7.50 37 selwortdokumentation unter „Auswahl der Tabellen-
sowie auf der zugehörigen Landingpage im SCN.38 Beachten Sie, dass ABAP CDS Views art“. 39
nur über die ABAP-Development-Tools in Eclipse erstellt werden können.
• Wenn für eine Tabelle vom Typ Sorted oder Hashed
Zugriffe erfolgen, sollten diese immer mit dem
passenden (Teil-)Schlüssel stattfinden.
3.5 INTERNE TABELLEN UND REFERENZEN
Interne Tabellen stellen ein zentrales Konstrukt bei der Entwicklung von Anwendungen
39
mit ABAP dar. Neben Datenbankzugriffen sind sie die zweite Quelle von Performan-
ce-Problemen. Bei kleinen Datenmengen stellen Dinge wie die Wahl der passenden
Tabellenart und eines passenden Schlüssels noch kein Problem dar. Werden größere Ab AS ABAP 7.02 können Sie bei internen Tabellen, die selten geändert aber mit mehr
Datenmengen verarbeitet, können vorher aus Performance-Sicht unkritische Stellen als einem Zugriffmuster gelesen werden, neben dem primären Schlüssel auch weitere
zu erheblichen Laufzeitverlängerungen führen. sekundäre Schlüssel definieren. Der primäre Schlüssel wird dabei wie gehabt definiert
und verwendet. Die Sekundärschlüssel können einen vom Primärschlüssel abwei-
chenden Typ (Sorted, Hashed) haben.
Als Beispiel können Sie damit für eine als Hashed definierte Tabelle mit eindeutigem
Primärschlüssel einen weiteren Schlüssel vom Typ Sorted definieren. Dieser erlaubt
einen performanten Zugriff auf die Daten der Tabelle aus einem anderen Blickwinkel
(nicht eindeutig, Teilschlüssel möglich), ohne die eigentlichen Daten zweimal im
Hauptspeicher anlegen und bei Änderungen manuell für die Konsistenz zwischen den
beiden Tabellen sorgen zu müssen.
36 http://help.sap.com/abapdocu_740/de/index.htm?file=abencds.htm
37 http://help.sap.com/abapdocu_750/de/index.htm?file=abencds.htm 39 Zugriff wie vorne in Kapitel 2 beschrieben. Pfad: ABAP – Referenz → Interne Daten verarbeiten → Interne Tabellen
38 http://scn.sap.com/docs/DOC-70385 → Interne Tabellen-Übersicht

BEST PRACTICE BEST PRACTICE
• Ähnlich wie bei den DB-Zugriffen existieren für Verwenden Sie standardmäßig Feldsymbole für die
interne Tabellen Einzelsatzzugriffe und Massenzu- Zugriffe auf interne Tabellen.
3. PERFORMANCE
griffe. Wenn möglich, sollten immer die Varianten mit

Massenzugriffen gewählt werden, die performanter
arbeiten als mehrere Einzelzugriffe.
• Bei der Verwendung der Anweisung SORT sollten Sie
eine implizite Sortierung vermeiden und aus Gründen 3.5.2 PARAMETERÜBERGABE
der besseren Nachvollziehbarkeit immer die ge-
wünschten Sortierfelder angeben. Die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus
technischen Gründen vorgeschrieben ist (z.B. RFC-Funktionsbausteine, Returning-Pa-
• Vor dem Einsatz der Anweisung DELETE ADJACENT
rameter bei funktionalen Methoden). So werden unnötige Kopierkosten bei der
DUPLICATES sollte immer sichergestellt sein, dass Parameterübergabe gespart. Dies gilt in besonderem Maße bei Parametern mit tiefen
die Tabelle nach den gleichen Feldern sortiert ist, Datentypen wie internen Tabellen oder Strings. Weiterhin sollten so wenig Parameter
damit doppelte Einträge auch wirklich eliminiert wie möglich definiert werden. Dies erhöht auch die Verständlichkeit des Quellcodes.
werden. Die erweiterte Programmprüfung weist auf überflüssige Variablen und Parameter hin,
und unterstützt damit das Aufräumen.
• Reine Existenzprüfungen auf internen Tabellen sollten
immer mit READ TABLE TRANSPORTING NO FIELDS
durchgeführt werden.40
BEST PRACTICE
Verwenden Sie so wenig Parameter wie möglich. Nutzen
40 Sie in der Regel die Referenzübergabe und nur in den tech-
nisch notwendigen Ausnahmefällen die Wertübergabe.
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.
Bedenken Sie beim Einsatz von Feldsymbolen jedoch, dass eine Änderung des Wertes
eines Feldsymbols auch den Wert im referenzierten Datenelement überschreibt.
40 Ab NetWeaver Release 7.40 SP02 ist für diese Art der Überprüfung die Funktion LINE_EXISTS( ) verfügbar. Sie sollte aufgrund der
besseren Lesbarkeit verwendet werden.

3.6 CODE PUSH DOWN
Beim Einsatz von SAP HANA als Datenbanksystem kann die Performance insbesonde- BEST PRACTICE
re von datenintensiven Applikationen massiv gesteigert werden, wenn die dateninten- • Wir raten von der Verwendung von External Views und
siven Operationen auf die Datenbank verlagert werden. Die Verlagerung der Logik aus
Database Procedure Proxies aufgrund der unter-
3. PERFORMANCE
dem Applikationsserver in SAP HANA wird als Code Push Down bezeichnet. Das
verfolgte Ziel des Vorgehens ist es, die Daten nicht mehr zur Applikationschicht zu schiedlichen Lebenszyklus Problematik im AS ABAP
transportieren und dort zu verarbeiten (data-to-code), sondern die Verarbeitungslogik und SAP HANA Stack ab, sofern dies möglich ist.
dort zur Ausführung zu bringen, wo die Daten „leben“ (code-to-data). • Wenn Sie eine Optimierung Ihrer Anwendung mittels
Code Push Down vornehmen wollen, empfehlen wir
Dieses Ziel in Kombination mit der Architektur von SAP HANA hat zur Folge, dass die in
Abschnitt 3.4.1 definierten Regeln im Vergleich zu einer Non-HANA-Datenbank eine zur Selektion des zu optimierenden Codes die SQL
andere Gewichtung erfahren: Die ersten drei Regeln (Minimierung der Treffermenge, Performance Tuning Worklist (Transaktion SWLT), die
der übertragenen Daten und der Anzahl der Datenbankzugriffe) gewinnen im Zuge des auf Basis der Ergebnisse von statischen Codechecks
Code Push Downs an Bedeutung, während die vierte Regel (Optimierung des Suchauf- mittels ATC und Laufzeitinformationen aus dem
wands) aufgrund der spaltenbasierten Ablage der Daten etwas weniger wichtig wird. SQL-Monitor eine priorisierte Liste von Stellen im
Die fünfte Regel lässt sich darauf reduzieren, dass unnötige Last auf der Datenbank Quellcode zur Verfügung stellt. Auch hier sind die in
vermieden werden sollte, da durch das Vorgehen bewusst datenintensive Operationen
Abschnitt 3.3 beschriebenen Empfehlungen zu
auf die Datenbank verlagert und so die Datenbank belastet wird.
beachten.
Der mit SAP NetWeaver 7.40 bzw. 7.50 erweiterte Sprachumfang von ABAP und Open • Wir raten von der Verwendung von Native SQL ab.
SQL ermöglicht den Code Push Down im Wesentlichen auf zwei Wegen:
• Verwendung der Open-SQL-Erweiterungen und der ABAP CDS Views
• Verwendung von ABAP Managed Database Procedures (AMDP) und als letzte WEITERE QUELLEN
Option von Native SQL
1. Einen Einstieg in die Performance-Optimierung bei ABAP bietet der SAP-Kurs
Welche der beiden Optionen in welchem Umfang genutzt werden, hängt stark von der BC490.
Zielsetzung ab. In beiden Fällen muss bestehender Code angepasst werden. Die
Komplexität der Anpassung ist im Falle der Verwendung von Open SQL und ABAP CDS 2. Sehr gute Einführungen in die Performanceanalyse-Tools SAT/SE30 und ATC
Views geringer als bei der Verwendung von AMDPs oder Native SQL. Ist das oberste bieten die Blogposts von Olga Dolinskaja im SAP Community Network
Ziel eine Maximierung der Performance der Anwendung, so wird man mit Open SQL
und ABAP CDS Views an Grenzen stoßen, die nur mittels AMDPs oder Native SQL 3. Das Profiling in Eclipse ist in dem Blogpost von Thomas Fiedler beschrieben
überwunden werden können. Ein weiterer Aspekt ist, dass bei der Verwendung von
AMPDs bzw. Native SQL tiefergehende Kenntnisse von SAP-HANA-Spezifika (z.B. 4. Die 5 Regeln für SQL-Zugriffe finden sich im Original jetzt (7.40) in gestraffter Form
SQLScript) notwendig sind, um optimale Ergebnisse erzielen zu können. Generell ist in der ABAPDOCU/F1-Hilfe, unter ABAP – Referenz / Externe Daten verarbeiten /
zu beachten, dass die Kompatibilität zu anderen Datenbanken nur bei der Verwendung ABAP-Datenbankzugriffe / Open SQL / Performance-Hinweise. Zusätzlich sind dort
von Open SQL und ABAP CDS Views (Ausnahme Table Functions) sichergestellt ist. Bei noch ausführliche Empfehlungen zu Sekundärindizes verlinkt
der Verwendung von AMDPs und Native SQL verliert man die Datenbankunabhängig-
keit.

5. Für Release 7.31 lagen die 5 Regeln, in etwas ausführlicherer Form, noch an 4 ROBUSTHEIT UND KORREKTHEIT
dieser Stelle: Performance-Hinweise 7.31
4. ROBUSTHEIT UND KORREKTHEIT
Unter Robustheit verstehen wir die Fähigkeit eines Programms, selbst unter ungünsti-
6. Siegfried Boes, „Performance-Optimierung von ABAP-Programmen“, gen Umständen nicht abzubrechen sondern trotzdem korrekte Ergebnisse zu liefern.
dpunkt Verlag 2009, ISBN 3898646157 Das bedeutet insbesondere, dass Programme Fehlersituationen erkennen und in einer
Weise darauf reagieren, dass die gewünschte Funktionalität nicht gefährdet wird.
7. Hermann Gahm, „ABAP Performance Tuning“, SAP Press, 2009,
ISBN 978-1-59229-555-5 Andererseits können Fehlersituationen manchmal nicht sinnvoll behandelt werden,
und in vielen Fällen ist die Implementierung einer echten Fehlerbehandlung mit
8. Hermann Gahm, Thorsten Schneider, Eric Westenberger, Christiaan Swanepoel mindestens einer Ausnahme oder Fehlermeldung unangemessen aufwändig, da die
„ABAP-Entwicklung für SAP HANA“, 2015, ISBN 978-3-8362-3661-4 Eintrittswahrscheinlichkeit als sehr gering eingeschätzt wird. In diesen Fällen ist es
wichtig, ein zügiges Auffinden des Fehlers in der Wartungsphase zu ermöglichen,
anstatt die Fehlerursache durch eine ungeschickte Fehlerbehandlungsroutine zu
verschleiern.
In diesem Kapitel gehen wir auf Best Practices ein, die die Robustheit eigenentwickel-
ter Programme fördern.
Viele Aspekte können durch den Code Inspector/ATC automatisch getestet werden,
siehe dazu auch Abschnitt 7.2.2 Automatische Prüfungen.
4.1 FEHLERBEHANDLUNG
Die ABAP-Laufzeitumgebung bietet verschiedene Möglichkeiten, eine Anwendung auf

Fehlersituationen hinzuweisen. Diese Möglichkeiten sind hier aufgeführt und die Best
Practices jeweils erläutert.
4.1.1 SY(ST)-SUBRC-PRÜFUNGEN
Bei einer ganzen Reihe von ABAP-Befehlen setzt der SAP-Kernel nach deren Ausfüh-
rung die globale Variable SY(ST)-SUBRC. In der Regel wird eine erfolgreiche Ausfüh-
rung durch den Wert 0 angezeigt.
Der sy-subrc sollte nach allen Befehlen, die ihn setzen, geprüft werden. Alternativ zu
einer dedizierten Auswertung von sy-subrc kann die Anweisung ASSERT sy-subrc = 0
verwendet werden, wenn der Programmierer der Ansicht ist, dass die Fehlersituation
nicht auftreten oder die Fehlersituation in der Anwendung nicht sinnvoll behandelt
werden kann. Die Verwendung dieser Anweisung führt im Fehlerfall zu einem Pro-
grammabbruch mit dem Laufzeitfehler ASSERTION_FAILED.

Der kurzfristige Mehraufwand macht sich bezahlt, weil Fehlersituationen sofort MESSAGE-Anweisungen können in bestimmten Konstellationen von Meldungsart und
bemerkt und exakt lokalisiert werden können. Dies ist einem „rätselhaften“ System- Betriebsmodus aufgrund eines Bildschirmwechsels in klassischen Dynpros implizite
verhalten vorzuziehen, welches vielleicht lange Zeit nicht bemerkt wird und bei dem COMMITs auslösen und führen innerhalb eines RFC-Aufrufs zu Verbindungsabbrü-
die Ursache („root cause“) oft nur mit viel Detektivarbeit zu ermitteln ist. Die Behand- chen. Verwenden Sie innerhalb des eigentlichen Anwendungskerns klassenbasierte
lung des sy-subrc kann durch den Code Inspector/ATC automatisch geprüft werden. Ausnahmen, um auf Fehlersituationen hinzuweisen. Eine Ausnahme von dieser Regel
ist die Verwendung der Anweisung MESSAGE * INTO zum Setzen der SY(ST)-Felder.
Für Programme z.B. mit Massenverarbeitung, deren Fortsetzung auch bei Fehlern für
einzelne Objekte sichergestellt werden muss, ist eine echte Fehlerbehandlung
notwendig (Fehler protokollieren, diesen Schleifendurchlauf abbrechen, usw.).
4.1.3 KLASSENBASIERTE AUSNAHMEN
Klassenbasierte Ausnahmen sind ein objektorientierter Mechanismus zur Fehlerbe-

handlung. Ein Programm erkennt einen Fehler und löst eine Ausnahme auf. Fängt der
BEST PRACTICE
Aufrufer diese Ausnahme nicht, wird sie so lange im Call Stack nach oben propagiert,
Setzen Sie bei Funktionsbausteinaufrufen explizit den bis sie an anderer Stelle gefangen wird. Wird die Ausnahme an keiner Stelle im Call
speziellen Wert OTHERS, da sich die Liste der Ausnahmen Stack behandelt, führt dies zu einem Dump. Ausnahmen können auch in prozeduralem
ändern könnte, nachdem das rufende Programm fertig Quellcode verwendet werden.
gestellt wurde.
Die klassenbasierte Ausnahmebehandlung hat im Vergleich zur klassischen Fehlerbe-
handlung zwei wesentliche Vorteile:
1. Der Quellcode zur Fehlerbehandlung kann an einigen wenigen Stellen gesammelt

werden, anstatt nach jedem Methodenaufruf u.Ä. wiederholt werden zu müssen.
4.1.2 MESSAGE-ANWEISUNG 2. Ausnahmeobjekte können nicht nur Fehlermeldungen beinhalten, sondern

weitere Attribute wie interne Tabellen etc. Dem Benutzer können so zur Fehle-
Mit der MESSAGE-Anweisung können Status- oder Fehlermeldungen ausgegeben ranalyse mehr Details angezeigt werden.
werden. Dabei unterscheidet sich das Verhalten der MESSAGE-Anweisung je nach
Meldungsart (Status, Information, Fehler, Abbruch) und Betriebsmodus (Dialog oder Es ist wichtig, alle Ausnahmen zu fangen, auf die an der jeweiligen Stelle angemessen
Hintergrund). reagiert werden kann. Ausnahmen, die lokal nicht angemessen verarbeitet werden
können, müssen in der Prozedur (Methode, Funktionsbaustein, Unterprogramm)
deklariert werden, damit für den Aufrufer klar ersichtlich ist, dass solche Ausnahmen
auftreten können41. Wichtig ist die einheitliche Verwendung: Für identische Fehlersitu-
BEST PRACTICE ationen sollten einheitliche Ausnahmeklassen verwendet werden.
Vermeiden Sie MESSAGE-Anweisungen außerhalb von
Zum Fangen von Ausnahmen dienen die ABAP-Befehle TRY…CATCH…ENDTRY.
Modulen, die direkt mit dem Anwender kommunizieren Entsprechend müssen alle Ausnahmen aller gerufenen Prozeduren, die klassenba-
bzw. die in einer definierten Dialogschicht liegen. sierte Ausnahmen erzeugen können, an irgendeiner Stelle des Call Stacks von einem
TRY…CATCH behandelt werden, um einen robusten Ablauf zu gewährleisten.
41 Eine detaillierte Unterscheidung der Ausnahmekategorien und Benutzungsempfehlungen dazu sind in der ABAP-Schlüsselwortdoku-
mentation zu finden, Pfad: ABAP – Programmierrichtlinien → Architektur → Fehlerbehandlung →Ausnahmekategorien

BEST PRACTICE: BEST PRACTICE

• Erlauben Sie keine leeren Ausnahmebehandlungen, Fangen Sie in CATCH-Blöcken grundsätzlich Objekte von
da es dadurch aufrufenden Stellen unmöglich ge- Ausnahmen-Oberklassen ab, da Fehlerbehandlungsrou-
macht wird, angemessen auf Ausnahmesituationen zu tinen in der Regel unabhängig vom konkreten Ursprung
reagieren. In diesen Fällen ist das Propagieren der der Ausnahme arbeiten. Nur in Ausnahmefällen kann es
Ausnahme die richtige Reaktion. Eine Ausnahme von sinnvoll sein, in vorangestellten CATCH-Blöcken gezielt
dieser Regel kann z.B. das Abfangen von Ausnahmen Objekte von Ausnahmen-Unterklassen abzufangen, um un-
in einer Schleife sein. Dann sollte aber in einem terschiedliche Fehlerbehandlungsroutinen durchzuführen.
Kommentar erläutert werden, warum weder Behan-
deln noch Propagieren der Ausnahme notwendig ist.
• Definieren Sie für Neuentwicklungen eine Ausnah-
men-Oberklasse, die von CX_STATIC_CHECK erbt. Für die Verkettung von Ausnahmen gibt es beim Erzeugen einer Ausnahme das Attribut
Definieren Sie pro Anwendungskomponente eine oder PREVIOUS.
mehrere Unterklassen, die sich auf Nachrichtenklas-
Zum Werfen von mehreren Ausnahmen bietet sich folgendes Quellcodemuster an:
sen mit Fehlermeldungen beziehen (automatische
Implementierung des Interfaces IF_T100_MESSAGE). Quellcode
Deklarieren Sie in allen neuen Methoden und Funktions DATA: lx_validaton_exception type zcx_validation_exception.
bausteinen die Ausnahmen-Oberklasse als mögliche IF ….
Ausnahme. Dadurch entsteht zu einem späteren “ Prüfung 1 nicht erfolgreich
Zeitpunkt z.B. beim Hinzufügen von Prüfungen kein lx_validation_exception = new ...
Mehraufwand. ENDIF.
IF ….
Bei Erweiterungen an Nicht-Kundencode kann es unter Umständen unmöglich sein, “ Prüfung 2 nicht erfolgreich
Ausnahmedeklarationen modifikationsfrei zu Methoden oder Funktionsbausteinen lx_validation_exception = new … EXPORTING
hinzuzufügen. In diesem Fall bietet sich die Verwendung von Ausnahmeklassen an, die PREVIOUS = lx_validation_exception. “ Wichtig: Verkettung
von CX_NO_CHECK erben. Dies ermöglicht die Fehlerbehandlung ohne explizite
ENDIF.
Deklaration der Ausnahmeklassen in Methodensignaturen und ohne Programmab-
bruch zur Laufzeit.
… “ weitere Prüfungen
Unterklassen von CX_DYNAMIC_CHECK sollten lediglich in Signaturen von Methoden
deklariert werden, bei denen der Aufrufer durch Übergabe geeigneter Parameter ein
IF lx_validation_exception IS BOUND.
Auftreten der Ausnahme verhindern kann. Dadurch muss an der Aufrufstelle kein
unnötiger TRY-CATCH-Block ergänzt bzw. die Signatur nicht um die Ausnahmeklasse RAISE EXCEPTION lx_validation_exception.
erweitert werden. ENDIF.

Die Sperren sind so genau wie möglich abzusetzen, um nur die relevanten Objekte
innerhalb einer LUW zu sperren. Zudem sind die Sperren nur so lange wie nötig und so
BEST PRACTICE kurz wie möglich zu halten.

Schreiben Sie Fehlerbehandlungsroutinen in CATCH-
Blöcken grundsätzlich so, dass alle verketteten Ausnah- Für die Änderung von SAP-Standard-Datenobjekten direkt auf der Datenbank sind die
meobjekte verarbeitet werden, es sei denn, vorhergehende entsprechenden SAP-Standard-Sperrfunktionen zu verwenden, da diese auch von den
Standard-Transaktionen verwendet werden und so ein konsistentes Verhalten sicher-
Fehlermeldungen sind für die Fehlerbehandlung nicht
stellen.
relevant.
Für kundeneigene Entwicklungen sind entsprechende Sperrobjekte mit den zugehöri-
gen 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
4.1.4 NICHT BEHANDELBARE AUSNAHMEN Scope-Parameter, wenn in diesem Zusammenhang auch Verbuchungsbausteine
verwendet werden.
Es gibt Ausnahmen, die vom ABAP-Quellcode aus nicht behandelt werden können und
dadurch zwangsläufig zu einem Abbruch der Anwendung und einem Dump führen. In Um sicherzustellen, dass gesperrte Objekte auch in Ausnahmesituationen entsperrt
einigen Fällen ist es möglich, proaktiv vor der Ausführung eines Statements, das eine werden, bieten sich in der klassenbasierten Ausnahmebehandlung CLEANUP-Blöcke an.
nicht behandelbare Ausnahme auslöst, die Rahmenbedingungen zu prüfen.
Neben dem pessimistischen Sperrkonzept mit Exklusivsperren kann auch das optimis-
Beispiel: Das Statement OPEN DATASET löst einen Dump aus, wenn der Benutzer tische Sperrkonzept basierend auf dem Vergleich von Zeitstempeln zum Änderungs-
keine ausreichenden Berechtigungen zum Öffnen einer Datei hat. Um dies zu vermei- zeitpunkt verwendet werden. Welches Sperrkonzept bei Neuentwicklungen gewählt
den, sollte die Berechtigung proaktiv mit dem Funktionsbaustein AUTHORITY_CHECK_ wird, ist von Fall zu Fall zu entscheiden.
DATASET geprüft werden.
WEITERE QUELLEN
4.2 KORREKTE IMPLEMENTIERUNG VON DATENBANK-ÄNDERUNGEN
1.
A BAP-Schlüsselwortdokumentation Datenkonsistenz
4.2.1 SPERROBJEKTE
Um Dateninkonsistenzen zu vermeiden, müssen in Anwendungen mit pessimistischem

Sperrkonzept42 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 sind.
Die SAP-Sperre besteht über mehrere Datenbank-LUWs (Logical Unit of Work) hinweg,
sodass für das gesamte zu ändernde Business-Objekt konsistent Änderungen auf der
Datenbank geschrieben werden können.
42 zu den Begriffen pessimistisches/optimistisches Sperren siehe zum Beispiel Introduction to Database Concurrency Control

4.2.2 FRAMEWORKS FÜR DEN DATENBANKZUGRIFF 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.
BEST PRACTICE
Evaluieren Sie vor der manuellen Entwicklung einer Der Zugriff erfolgt über die Funktionsgruppe SBAL, die im System sehr gut dokumen-
tiert ist.
Datenbankzugriffsschicht existierende, von SAP bereit
gestellte Frameworks. Die Verwendung des Business Application Logs hat folgende Vorteile:
1. Zentrale Ablage: Im Business Application Log können Meldungen an zentraler

Stelle verwaltet werden; dies erleichtert den Überblick und die Administration
Zur Implementierung von Datenbankzugriffen bietet SAP u.a. das Business Object der Anwendungen.
Processing Framework (BOPF)43 an. Eine Einarbeitung in dieses oder andere Frame-
works kann den Aufwand mittelfristig deutlich reduzieren, auch weil Frameworks in 2. Wiederverwendbarkeit: Das Business Application Log bzw. die zugehörigen
der Regel für weitere Infrastrukturthemen wie externe Schnittstellen Werkzeuge zur Bausteine/Klassen bieten einen guten Funktionsumfang für das Thema Logging
Verfügung stellen. – dieser muss nicht „neu erfunden“ werden. Zu diesen Möglichkeiten zählen u.a.:
a. Persistenz: Speicherung von Meldungen im Log

b. Hierarchiedarstellung von Meldungen: Zusammenfassung zu Problemklassen
4.2.3 VERBUCHUNGSKONZEPT c. Integration zusätzlicher Felder in die Protokollierungsobjekte
d. Interaktivität: Nachlesen von Informationen bei Aufruf einer Meldung und
Bei Verwendung klassischer Dynpro-Oberflächen oder Remoteaufrufen von Funkti- Anreichern von Informationen
onsbausteinen kann der Fall auftreten, dass auf einem ABAP-Anwendungsserver e. Integration der Protokollanzeige in eigene Anwendungen/UIs: Sub-Screen/
Programmlogik von mehreren Workprozessen hintereinander ausgeführt wird. Jeder Control/Pop-up
Wechsel zwischen Workprozessen ist mit einem impliziten Datenbank-Commit
verknüpft. Falls kein Framework zum Datenbankzugriff verwendet wird, kann es
deshalb notwendig sein, in eigenentwickelten Programmen Maßnahmen zur Bündelung
von Datenbankänderungen einzusetzen. Für mehr Informationen zu diesem Thema BEST PRACTICE
wird auf den Abschnitt Datenkonsistenz der ABAP-Schlüsselwortdokumentation44 Es ist sinnvoll, die SBAL-Funktionen einmalig mit einer
verwiesen. Klasse zu verschalen, damit eine einfache und knappe
Verwendung in der Art
M
ESSAGE i002(zmessage) WITH lv_value_1 INTO
DATA(lv_dummy).
lo_logger->add_msg_from_sy( ).
möglich ist, und gleichzeitig der Verwendungsnachweis
für Nachrichten weiterhin funktioniert.
43 http://scn.sap.com/docs/DOC-45425
44 ABAP Schlüsselwortdokumentation Datenkonsistenz

Der etwas aufwändigere Aufruf der SBAL-Funktionen ist dann in der Klasse verborgen. 5 ABAP-SICHERHEIT UND COMPLIANCE
5. ABAP-SICHERHEIT UND COMPLIANCE
Dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im ABAP negativ

auf die Sicherheit eines Unternehmens auswirken können und welche Gegenmaßnah-
men es gibt. Das Thema Applikationssicherheit betrifft prinzipiell alle Programmier-
BEST PRACTICE sprachen, wurde aber bislang bei ABAP zumeist nicht hinreichend beachtet. Mögliche
Geben Sie beim Anlegen von Business Application Logs ein Risiken, die Unternehmen durch fehlerhafte ABAP-Programme entstehen können,
Verfalldatum mit (BAL_S_LOG-ALDATE_DEL beim Aufruf sind in diesem Zusammenhang:
von BAL_LOG_CREATE) und planen Sie eine regelmäßige
Bereinigung mit der Transaktion SLG2 ein. • Rechtsverstöße (z.B. könnte das Bundesdatenschutzgesetz verletzt werden, wenn
die Programmierfehler zum Diebstahl von Personaldaten führen)
• Verletzung von Compliance-Anforderungen (z.B. SOX oder PCI/DSS)
Eine eigene Protokolltabelle (DB-Tabelle) kann ein sinnvoller Ersatz bzw. eine sinnvolle • Cyber-Angriffe mit dem Ziel der Industriespionage, Sabotage oder Erpressung
Ergänzung zum Business Application Log sein, wenn man laufübergreifend Werte
vergleichen möchte. Dies kann z.B. für tägliche Batchläufe in Frage kommen, die dann • Hintertüren, die Innentätern erweiterten Zugriff auf Daten ermöglichen
„n Datensätze von Typ x verarbeitet“ protokollieren.
• Pressemeldungen, wenn Schwachstellen oder Datendiebstähle bekannt werden
Eine weitere Ergänzung sind die aktivierbaren Log-Points (Befehl LOG-POINT in
Kombination mit Transaktion SAAB, siehe Referenz 3). Diese müssen jedoch zuvor Insbesondere darf selbst geschriebener ABAP-Code die Vertraulichkeit, Integrität und
aktiviert werden und es werden nur jeweils die Anzahl der Vorkommen sowie die Verfügbarkeit der Geschäftsdaten nicht gefährden.
Feldinformationen für das letzte Auftreten aufgezeichnet.
Da dieses Thema sehr komplex ist, können wir im Rahmen dieses Dokuments nur ein
WEITERE QUELLEN paar ausgewählte, zentrale Themen behandeln. Für weitergehende Fragen verweisen
wir auf die Literaturhinweise am Ende dieses Kapitels.
1.
S AP Application Log – Leitfaden für Anwender
2. Beispiele zur Verwendung der BAL-Funktionen in: Thorsten Franz, Tobias Trapp:
ABAP Objects: Application Development from Scratch. SAP Press, 2008. 5.1 PRÜFUNGSRELEVANTE SICHERHEITSTHEMEN IM SAP STANDARD
ISBN 9781592292110
Wir orientieren uns bei unseren Empfehlungen primär an einem Dokument, das beim
3.
A BAP-Schlüsselwortdokumentation zu Checkpoints und Checkpoint-Gruppen Bundesamt für Sicherheit in der Informationstechnik (BSI) als Hilfsmittel veröffentlicht
wurde, den „Top 20 Sicherheitsrisiken in ABAP-Anwendungen“45.
Dieses Dokument basiert auf einer umfassenden statistischen Analyse von Sicher-
heitsfehlern in ABAP-Eigenentwicklungen (Details hierzu siehe beim BSI veröffentlich-
tes Dokument). Auf Basis dieser Statistik konnten die häufigsten Sicherheitsdefekte
identifiziert werden. Diese wurden ergänzt durch einen Satz weniger häufiger aber
dafür besonders kritischer Sicherheitsrisiken. In Kombination ist dies eine wertvolle
45
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Hilfsmittel/Extern/TOP-20_Sicherheitsrisiken-in-ABAP-
Anwendungen.pdf

Orientierungshilfe für alle Unternehmen, die in diesen Bereich einsteigen und zu- wie sich ein Programm zur Laufzeit verhält (sogenannte dynamische Tests) oder der
nächst nur eine begrenzte Menge von Regeln vorgeben wollen. Test basiert auf einer Analyse des Quellcodes (sogenannte statische Tests). Damit ein
Programm testbar ist, muss sichergestellt sein, dass der ABAP-Code sowohl vollstän-
Im Folgenden werden die Risiken zunächst in Bereiche unterteilt und dann Empfehlun- dig ausführbar als auch vollständig einsehbar ist.
gen ausgesprochen.
Sicherheitsprobleme ergeben sich in folgenden Fällen:
• Der Entwickler schreibt Code, der sich auf verschiedenen Systemen unterschied-
5.1.1 BERECHTIGUNGSPRÜFUNG lich verhält, was einen dynamischen Test potentiell gefährlicher Funktionalität
auf einem Qualitätssicherungssystem beeinträchtigen kann.
Rollen und Berechtigungen sind ein zentrales Sicherheitsthema im SAP-Umfeld. Es ist
daher wichtig zu verstehen, dass ABAP ein so genanntes “explizites Berechtigungsmo- • Der Entwickler schreibt Code, der sich auf verschiedenen Mandanten unter-
dell“ verwendet46. Berechtigungsprüfungen sollten grundsätzlich explizit im Quellcode schiedlich verhält, was ebenfalls einen dynamischen Test auf einem Qualitätssi-
programmiert werden, damit die Prüfung für alle Fälle sichergestellt ist. cherungssystem beeinträchtigen kann.
Sicherheitsprobleme ergeben sich häufig in folgenden Fällen: • Der Entwickler versteckt seinen Code und verhindert damit eine Quellcode-Analyse.
• Der Entwickler vergisst, die Berechtigungsprüfung zu programmieren. Während versteckter Code selten anzutreffen ist, kommen hart-codierte Prüfungen auf
Mandant oder System-ID mit einer Wahrscheinlichkeit von über 70 % pro System vor.
• Der Entwickler prüft beim Aufruf einer Transaktion nicht die Transaktions-Start-
berechtigung.
• Der Entwickler prüft keine fachlichen Berechtigungen in RFC-fähigen Funktions- 5.1.3 DATENSCHUTZ
bausteinen.
Ein primärer Zweck von SAP-Systemen ist die Verwaltung von Geschäftsdaten. Darin
• Der Entwickler sichert kritische PAI-Ereignisse nicht ab, die durch direkte enthalten sind unter anderem Geschäftsgeheimnisse, Personaldaten und Finanzdaten.
Eingabe von Funktionscodes ausgelöst werden können, obwohl das entsprechen- Der Schutz dieser Daten ist für Unternehmen elementar wichtig, nicht zuletzt auf
de UI-Element beim PBO abgeschaltet wurde. Grund gesetzlicher Anforderungen. Entsprechend muss auch selbst geschriebener
Code größte Sorge tragen, dass diese Daten nicht unerlaubt aus dem System abgezo-
• Der Entwickler verwendet das falsche Berechtigungsobjekt. gen werden können.
• Der Entwickler verwendet eine proprietäre Berechtigungsprüfung. Sicherheitsprobleme ergeben sich in folgenden Fällen:
• Der Entwickler behandelt den Rückgabewert der Prüfung nicht. • Eigenentwickelte Programme zeigen sensible Daten ohne hinreichende Berechti-
gungsprüfung an, z.B. im SAP GUI oder in HTML-Seiten.
• Eigenentwickelte Programme exportieren sensible Daten ohne hinreichende

5.1.2 TESTBARKEIT Berechtigungsprüfung.
Immer mehr Unternehmen lassen ihre Eigenentwicklungen nicht nur durch interne • Eigenentwickelte Programme übertragen sensible Daten ohne hinreichende
Teams testen, sondern auch durch unabhängige Dritte. Dabei wird entweder getestet, Berechtigungsprüfung.
46 Man kann zwar über S_TCODE viele Fälle implizit berechtigen, aber es verbleiben etliche Lücken (Externe Zugriffe über RFC oder
Services, Verzweigung in andere Programme, unterschiedliche Modi für Anzeige und Änderung innerhalb eines Programms)

5.1.4 INJECTION-SCHWACHSTELLEN 5.1.5 STANDARD-SCHUTZ
Im ABAP-Quellcode werden häufig dynamische Befehle, Strukturen und Bezeichner Der SAP-Standard liefert verschiedene Sicherheitsmechanismen, die SAP-Systeme
verwendet, die aus Benutzereingaben zusammengefügt werden. Wenn hier nicht durch vor Angriffen schützen. Zu diesen Sicherheitsmechanismen gehören unter anderem
Input-Validierung bzw. Output-Encoding verhindert wird, dass Steuerzeichen in den die Mandantentrennung, Logging und das Berechtigungswesen. Entsprechend verlas-
Eingaben die Semantik des dynamischen Befehls verändern können, dann kann der sen sich Unternehmen auf diese Mechanismen, wenn sie ihre Systeme sicher konfigu-
dynamische Befehl zur Laufzeit schadhaft manipuliert werden. riert haben.
Sicherheitsprobleme ergeben sich in folgenden Fällen: Eigenentwicklungen dürfen daher die Funktionalität dieser Mechanismen nicht
unterlaufen.
• Der Entwickler vermischt Input mit dynamischem ABAP oder gefährlichen
Befehlen, wie z.B. die Ausführung von Betriebssystemkommandos oder von Sicherheitsprobleme ergeben sich beispielsweise in folgenden Fällen:
nativem SQL.
• Der Entwickler umgeht die Mandantentrennung.
• Der Entwickler führt eine unzureichende Input-Validierung durch.
• Der Entwickler deaktiviert das Datenbank-Logging.
• Der Entwickler vergisst Output-Encoding, um schadhafte Effekte durch Steuer-
zeichen im Input zu vermeiden. • Eigenentwickelte Programme ändern Geschäftsdaten, ohne Änderungsbelege
anzulegen.
Manche Injection-Schwachstellen treten häufig im eigenen Code auf. So befinden sich
z.B. statistisch betrachtet auf jedem Kunden-System 294 Directory Traversal Schwach- Fehler in diesem Bereich sind insbesondere daher kritisch, weil sie ggf. umfangreiche
stellen, welche jedoch nur begrenzten Schaden verursachen. Es gibt jedoch auch Sicherheitsmaßnahmen des Unternehmens zunichtemachen können.
Injection-Schwachstellen, deren Ausnutzung einem Angreifer vollständigen Zugriff aus
das gesamte SAP-System ermöglicht. Von diesen besonders schwerwiegenden
Schwachstellen gibt es statistisch gesehen 16 pro SAP-System.
5.2 SICHERHEITSEMPFEHLUNGEN
Um Software schreiben zu können, die wirklich sicher ist, bedarf es jahrelanger

Erfahrung. Und selbst dann übersehen auch Experten gelegentlich etwas. Wir be-
schränken uns daher in diesem Leitfaden auf eine ausgewählte Liste von Empfehlun-
gen, die in vielen Fällen das Risiko eines erfolgreichen Angriffs zumindest deutlich
senken können.

5.2.1 SIEBEN ALLGEMEINE REGELN FÜR DIE SICHERE ABAP-PROGRAMMIERUNG
BEST PRACTICE • Prüfen Sie die Gültigkeit der Werte sämtlicher Eingabe
Wir empfehlen bei der ABAP-Programmierung auf folgen- parameter.
de Regeln zu achten: • Insbesondere Injection-Angriffe werden er-
schwert, wenn der Wertebereich von Eingaben
• Schränken Sie die Ausführung jeglicher Geschäftslo- weitgehend eingeschränkt ist. Wenn Sie bei-
gik mittels Berechtigungsprüfungen ein, damit durch spielsweise eine Telefonnummer verarbeiten,
die Berechtigungsadministration der Benutzerkreis sollten nur Ziffern und wenige Sonderzeichen wie
maximal reduziert werden kann. ( ) + - erlaubt sein.
• Selbst wenn sich in Ihren Programmen Sicher- • Verwenden Sie bei Eingabeparametern möglichst
heitsfehler befinden sollten, können diese dann kurze Variablentypen.
zumindest nur von wenigen Angreifern ausge-
nutzt werden. • Selbst wenn Ihre Gültigkeitsprüfung unzurei-
chend sein sollte, werden Angriffe deutlich
• Verlassen Sie sich bei relevanten Prüfungen nie erschwert, wenn dem Angreifer nur wenige
darauf, dass diese bereits an anderer Stelle erfolgt Zeichen zur Verfügung stehen.
sind.
• Verwenden Sie möglichst nur Funktionen aus zentra-
• Wenn für die Sicherheit Ihrer Programmlogik len Bibliotheken für Ihre Sicherheitsprüfungen.
bestimmte Prüfungen erforderlich sind, dann Schreiben Sie niemals eigene.
führen Sie diese durch.
• Funktionen, die Sicherheitsprüfungen ausführen,
• Vermeiden Sie generische Programmierung. sind komplex in der Erstellung und daher fehler-
• Je vielseitiger eine bestimmte Programmlogik anfällig. Die Erstellung und Wartung solcher
ist, desto höher ist die Wahrscheinlichkeit, dass Funktionen sollte von einem zentralen Team im
ein Angreifer einen Weg findet, sie zu missbrau- Unternehmen durchgeführt werden. Dadurch
chen. können potentielle Fehler vermieden bzw. im
• Umgehen Sie keine Sicherheitsmechanismen des Nachgang effizient verbessert werden.
SAP-Standards.
• Wenn SAP für eine bestimmte sicherheitsrele-
vante Funktionalität eine Methodik anbietet oder
vorschreibt, verwenden Sie diese und schreiben
Sie keine „einfachere“ Alternative.

5.2.2 DIE KRITISCHSTEN UND HÄUFIGSTEN RISIKEN IN ABAP 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 relevant47.
BEST PRACTICE Die meisten Unternehmen verfügen über ein Internes Kontrollsystem (IKS), das
Konzentrieren Sie sich bei der Programmierung auf Compliance-Risiken entgegenwirkt. Dies ist beispielsweise in den international
die Vermeidung der folgenden besonders häufigen und anerkannten Referenzmodellen COSO & COBIT beschrieben. In einer typischen
kritischen Sicherheitsrisiken. Damit stellen Sie in Ihren IKS-Struktur sind die „Generellen IT-Kontrollen“ (ITGC-IT General Controls) Voraus-
setzung für das Erreichen aller IKS-Ziele im IT-dominierten Umfeld.
Eigenentwicklungen eine solide Grundabsicherung sicher.
Ein elementarer Baustein der ITGC ist das Änderungswesen (Change Management), zu
dem wiederum Eigenentwicklungen zählen. Sicherheitsdefekte im selbstgeschriebe-
nen ABAP-Quellcode stellen also eine Verletzung der generellen IT-Kontrollen dar.
Die kritischsten ABAP-Risiken und wichtigsten Empfehlungen entnehmen Sie bitte Wenn also in einem IKS der Bereich Change Management bzw. selbstgeschriebener
dem BSI Hilfsmittel „Top 20 Sicherheitsrisiken in ABAP-Anwendungen“. ABAP-Code unzureichend abgedeckt ist, dann helfen auch alle anderen Maßnahmen
nicht, da diese auf ein funktionierendes Change Management aufbauen. Dies führt zu
Eine etwas kompaktere Liste kritischer Risiken liefert der BIZEC APP/11-Standard. einem Compliance-Verstoß.
Hier sind allerdings die Beschreibungen nicht so ausführlich wie beim BSI-Hilfsmittel.
Die folgende Liste enthält eine Übersicht über SAP-Meldungen, die Gegenmaßnahmen
zu einigen der oben beschriebenen Probleme enthalten.
SAP Note Schwachstelle

1520356 SQL Injection
887168, 944279, 822881 Cross-Site Scripting
1497003 Directory Traversal
Tabelle 1: SAP-Hinweise, 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-Standard-Quellcode.
Eine regelmäßige Prüfung der Eigenentwicklungen ist daher zwingend erforderlich.
Abbildung 1: IKS-Risiken durch unsicheren ABAP-Quellcode
47 Weitere Informationen: Maxim Chuprunov , Handbuch SAP-Revision, SAP Press 2011

Dies bedeutet insbesondere, dass Sicherheitsdefekte im ABAP-Quellcode potenziell WEITERE QUELLEN
nicht nur Auswirkungen auf Compliance-Standards haben, sondern auch gesetzliche

Anforderungen verletzen können. 1. Andreas Wiegenstein, Markus Schumacher, Sebastian Schinzel, Frederik Weidemann,
Sichere ABAP-Programmierung, SAP Press 2009
Alle im BSI-Hilfsmittel „Top 20 Sicherheitsrisiken in ABAP-Anwendungen“ dargestell-
ten Sicherheitsrisiken sind daher auch Compliance-relevant. 2. Maxim Chuprunov, Handbuch SAP-Revision, SAP Press 2011
3.
BIZEC – The Business Application Security Initiative
5.4 TESTWERKZEUGE 4.
BSI-Hilfsmittel – Top 20 Sicherheitsrisiken in ABAP-Anwendungen vom 16.10.2014
Für ABAP-Sicherheitstests eignen sich insbesondere sogenannte statische Codeanaly- 5.

The Business Code Quality Benchmark 2016
se-Tools. SAP erweitert mit dem lizenzpflichtigen „SAP NetWeaver Application Server,
Add-on for code vulnerability analysis“ den Code Inspector/ATC um komplexere 6.
P CI / DSS (Payment Card Industry Data Security Standard)
Sicherheitsprüfungen.
Daneben gibt es einige andere kommerzielle Anbieter. Interessant sind folgende

Eigenschaften eines solchen Tools:
• Analyse auch des SAP-Standard-Quellcodes und von Third-Party-Code, entweder

komplett oder Beschränkung auf die von Kundencode aufgerufenen Funktionen.
• Continuous Monitoring, ermöglicht durch sehr hohe Scan-Geschwindigkeiten.
• Globale Daten- und Kontrollflussanalysen, da diese für die meisten Sicherheits-

tests elementar sind.
• Umfangreiche Beschreibungen des jeweiligen Problems mit Lösungsvorschlägen.
• Hinreichende Testabdeckung:
• „ APP/11“-Standard von BIZEC
• „Top 20 Sicherheitsrisiken in ABAP-Anwendungen“, veröffentlicht beim BSI
Eine gute Integration externer Tools in die Entwicklungsumgebung (SE80, Eclipse) und
den Entwicklungsprozess (ChaRM, TMS) fördert deren Akzeptanz und Verwendung.

6 DOKUMENTATION • Welche Abhängigkeiten gibt es zwischen den Modulen?
Die Dokumentation von Software ist in vielen Fällen genauso wichtig wie die Entwick- • Welche Anwendungen werden bei welchen Geschäftsprozessen verwendet?
lung selbst. Fehlt die Dokumentation oder ist sie nicht in ausreichendem Maß vorhan-
den, führt dies spätestens bei der Weiterentwicklung oder dem Wechsel von Entwick- • Welche Hintergrundjobs laufen wann am Tag / im Monat / im Jahr und welche
6. DOKUMENTATION
lern zu erhöhten Aufwänden. In diesem Kapitel werden unterschiedliche Möglichkeiten Entwicklungsobjekte sind davon betroffen?
zur Dokumentation von Entwicklungen in einem SAP-System dargestellt.
Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes
Allgemein ist es bei jeder Dokumentation wichtig, das richtige Maß zu finden und Ablagemedium innerhalb der SAP-Entwicklungsumgebung, das insbesondere Grafiken
umzusetzen. In der Praxis findet man leider immer wieder die beiden Extreme: gut integriert. Wir empfehlen daher, für die Dokumentation dieser übergreifenden
entweder eine sehr umfangreiche oder gar keine Dokumentation. Die umfangreiche Zusammenhänge auf andere Medien zurückzugreifen. Beispiele dafür sind:
Dokumentation ist allerdings inhaltlich oft mangelhaft, weil sie viele redundante/
kopierte Informationen enthält und nicht aktuell gehalten wird. Sind die offiziellen • SAP Solution Manager
Anforderungen an die Dokumentation zu hoch oder zu abstrakt, führt dies manchmal
dazu, dass sie gar nicht erst erstellt wird. • Interne (Produkt-)Wikis
Die Dokumentation sollte während der Entwicklung, unbedingt aber vor der Produktiv- • Dokumente in gepflegten öffentlichen Verzeichnissen (Portalablage, SharePoint,
setzung bzw. Bereitstellung erstellt werden und es sollte keine Produktivsetzung ohne Fileshare …)
fertige Dokumentation geben. Ansonsten ergibt sich in der Regel ein Mehraufwand
oder letztlich eine fehlende Dokumentation. 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 Entwicklungsleitung.
6.1 DOKUMENTATION UNABHÄNGIG VON ENTWICKLUNGSOBJEKTEN Zur Dokumentation der Systemarchitektur inklusive Entwurfsentscheidungen bietet
sich die Verwendung einer Vorlage an, wie z.B. das arc42-Template. Dies kann verhin-
Neben der Beschreibung der vielen Entwicklungsobjekte, die einzelne, sehr spezielle dern, dass wesentliche Aspekte in der Dokumentation vergessen werden und be-
Funktionen im ABAP-System übernehmen, gibt es auch den Bedarf, die größeren schleunigt – bei Verwendung einer Vorlage über mehrere Projekte hinweg – die Suche
Zusammenhänge innerhalb eines Moduls und modulübergreifend darzustellen. Dazu nach spezifischen Informationen. Zudem erleichtert die Festlegung von Vorlagen das
gehören z.B. Antworten auf Fragen wie: Erstellen der Dokumentation parallel zur Entwicklung und die Einhaltung eines
angemessenen Abstraktionsniveaus.
Dokumentenvorlagen wie das arc42-Template müssen nicht immer vollständig

„ausgefüllt“ werden, sondern relevante Teile sollen je nach Art und Umfang des
Entwicklungsprojekts identifiziert und der Rest gelöscht werden.
Darüber hinaus kann eine veraltete Dokumentation irreführend sein. Deshalb sollte in
allen 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.

WEITERE QUELLEN Reports vom ABAP-System automatisch in die Benutzeroberfläche eingebunden. Ein
weiterer Vorteil kann darin bestehen, dass die Dokumentation mehrsprachig geführt
1. Dokumentation SAP Solution Manager 7.1 werden kann.
2.
SCN-Blog „Business process documentation with SAP Solution Manager 7.1“ Auf SAP-Systemen mit SAP_BASIS >= 7.40 können im Quellcode ABAP-Doc-Kommen-
6. DOKUMENTATION
tare verwendet werden. Dies kann als Alternative zur Dokumentation in der
3.
Das arc42-Template zur Architekturdokumentation ABAP-Workbench verwendet werden. Der volle Funktionsumfang von ABAP-Doc-Kom-
mentaren lässt sich derzeit allerdings nur mit den ABAP-Development-Tools für
4. Stefan Zörner: Softwarearchitekturen dokumentieren und kommunizieren. Eclipse ausschöpfen. Bei Verwendung von Core Data Services zur Definition von
Carl Hanser Verlag GmbH Co KG, 2015. ISBN 9783446429246 DDIC-Objekten können wesentlich mehr Entwicklungsobjekte im Quellcode dokumen-
tiert werden und die Notwendigkeit externer Dokumentation entfällt.
Beginnend mit SAP NetWeaver 7.50 lassen sich die ABAP-Doc-Kommentare von
6.2 DOKUMENTATION VON ENTWICKLUNGSOBJEKTEN Klassen und Schnittstellen als HTML-Dateien exportieren48.
Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quellcode

enthalten können, existieren weitere Entwicklungsobjekte im ABAP-System, die keinen
Quellcode besitzen und daher auf anderem Weg dokumentiert werden müssen.
Beispiele dafür sind:
• DDIC-Objekte
• Transaktionen
BEST PRACTICE
Wir empfehlen, für alle Entwicklungsobjekte und unab-
hängig vom Quellcode die Dokumentationsfunktion der
ABAP-Workbench zu nutzen und die Aufgaben und Bedeu-
tungen dieser Objekte im SAP-System zu dokumentieren.
Hierbei sollte ausschließlich der Ist-Stand dokumentiert
werden, gegebenenfalls angereichert um kurze Verweise
auf die Änderungsdokumentation (Transportdokumentati-
on, Defekt-Nummern).
Da die Workbench-Dokumentation auch an das Transportwesen angeschlossen ist,

steht sie in allen Einzelsystemen einer Systemlandschaft zur Verfügung. Weiterhin
kann diese Dokumentation von allen Benutzern eingesehen werden und wird für
48 http://scn.sap.com/community/abap/eclipse/blog/2015/10/21/new-abap-doc-features-with-netweaver-75

6.3 DOKUMENTATION IM QUELLCODE
6.3.1 DOKUMENTATIONSSPRACHE BEST PRACTICE

Nachträgliche Änderungen am Quellcode sollten – von
6. DOKUMENTATION
Kopfkommentaren abgesehen – nur in Ausnahmefällen

direkt im Quellcode dokumentiert werden.
BEST PRACTICE
Als Kommentierungssprache sollte Englisch verwendet
werden.
6.3.3 PROGRAMMKOPF
Entwicklungsteams arbeiten heutzutage überwiegend international zusammen. Auch
wenn Sie derzeit rein deutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit Änderungen in Programmen können zum Beispiel mit Namen oder Namenskürzel des
internationalisiert werden. Der Aufwand, der dann durch Koordinationsprobleme oder Entwicklers, dem Tagesdatum oder Monat und der Änderungsbelegnummer (Change
sogar nachträgliches Übersetzen entsteht, steht in keinem Verhältnis zu dem vielleicht Document, Incident Ticket, …) sowie einer stichwortartigen Beschreibung der Ände-
größeren Aufwand durch englische Dokumentation. rung im Programmkopf dokumentiert werden.
Es hat sich außerdem gezeigt, dass die Lesbarkeit von Quellcode und Kommentaren Beispiel:
durch englischsprachige Kommentare erhöht wird. Denn die ABAP-Befehle selbst sind
*/ Change Log
englisch und im Stil von Sätzen aufgebaut. Der Leser des Quellcodes muss bei engli-
scher Dokumentation also nicht ständig die Sprache wechseln. */ VN/Date ChangeDoc Description
*/ MZ/2012-08-06 CD4712 Add MMSTA in Output
*/ MZ/2012-02-01 CD4711 Import Material number
*/ MM/2009-01-01 CD0815 Added Field ABC in method signature and source
6.3.2 DOKUMENTATION VON ÄNDERUNGEN code in order to support quick search
Ab dem Zeitpunkt der Produktivsetzung eines Programms sollte darauf geachtet

werden, dass Änderungen in Programmen angemessen dokumentiert werden. Hier ist
das richtige Maß wesentlich: Eine vollständige Versionshistorie aller Änderungen und Durch diese Informationen kann später nachvollzogen werden, welche Erweiterung
auskommentierter Quellcode reduzieren die Lesbarkeit des Quellcodes. Trotz dieses oder Fehlerbehebung Auslöser einer Änderung war. Diese Kopfkommentare helfen
Nachteils dokumentieren einige Entwicklungsteams bewusst alle Änderungen im auch dabei zu erkennen, wie oft ein Programm geändert wurde, wer sich wahrschein-
Quellcode, um die Fehlersuche auf Produktiv- oder Testsystemen zu vereinfachen, in lich gut damit auskennt und wie lange die letzte Änderung zurückliegt. Diese Informa-
denen die Versionshistorie nicht zur Verfügung steht. tionen sind hilfreich, schon bevor die nächsten Änderungen in einem Programm
geplant oder eingebaut werden.

6.3.4 KOMMENTARE IM QUELLCODE 7 UMSETZBARKEIT UND DURCHSETZBARKEIT
7. UMSETZBARKEIT UND DURCHSETZBARKEIT
Kommentare im Quellcode sollen dazu dienen, Entwicklern das Verstehen des Quell- Dieses Kapitel beschreibt, wie sich die Best Practices aus dieser Guideline in der
codes zu erleichtern, sofern dies nicht durch geschickte Gestaltung des Quellcodes Praxis verwirklichen lassen. Wir unterscheiden hierbei Umsetzbarkeit und Durchsetz-
allein (Modularisierung, Namenswahl von Methoden und Variablen) erreichbar ist. barkeit der Richtlinien.
Kommentare sind für andere Entwickler und mit zunehmendem zeitlichen Abstand Im Abschnitt „Umsetzbarkeit“ erklären wir, worauf ein Unternehmen achten sollte, das
auch für den ursprünglichen Entwickler gedacht. Sie sollten die Frage beantworten, Programmierrichtlinien einführen möchte. Wir erklären, wie ein Prozess dafür
„Warum“ etwas programmiert wurde und nicht „Was“. Letzteres ergibt sich aus dem aussehen könnte, wie man diesen ins Leben ruft und vor allem, wie man ihn am Leben
Quellcode ohnehin, während die Beweggründe oft nicht klar erkennbar sind. Gerade erhält. Im Abschnitt „Durchsetzbarkeit“ legen wir dar, wie ein Unternehmen die
sie helfen beim Verständnis aber wesentlich weiter. Dabei gilt der Grundsatz: So wenig Vorgaben aus dem Prozess prüfen kann. Hierzu gehören organisatorische Aspekte
Kommentar wie möglich, so viel Kommentar wie nötig. genauso wie Prüfmethoden und Werkzeuge. Wir gehen aber auch auf Grenzen der
Durchsetzbarkeit ein.
Stern-Kommentare sollten nur im Programmkopf oder für das temporäre Auskom-
mentieren von altem Quellcode verwendet werden. Abschließend stellen wir Tipps aus der Praxis vor, die die Autoren bei verschiedenen
Projekten im Umfeld der SAP-Entwicklung gesammelt haben.
Für alle anderen Kommentare empfiehlt SAP, Inline-Kommentare zu verwenden. Diese
sollten jeweils vor dem Quellcode stehen, den sie dokumentieren, und genauso
einger ückt sein wie dieser Quellcode. Letzteres wird (nur) für Inline-Kommentare
auch vom Pretty Printer korrekt durchgeführt. 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 Quell-
WEITERE QUELLEN codequalität bedeutet zunächst eine Investition in Prozesse und Werkzeuge sowie in
die Fortbildung der involvierten Mitarbeiter. Insbesondere muss das Management
1. Horst Keller, Wolf Hagen Thümmel: ABAP-Programmierrichtlinien. SAP Press, 2009. überzeugt sein, dass das Unternehmen durch diese Prozesse langfristig Kosten spart.
ISBN 9783836212861
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 Presse

meldungen hervorgerufen durch Datenlecks, Stillstand der Produktivsysteme.

Compliance • Risiken bei Qualitätsmängeln: Mehraufwand durch Analyse und Nachdokumenta-
tion bei Erweiterung vorhandener Funktionalität, Implementierung von Seitenef-

• Vorteil: Das Unternehmen kann jederzeit nachweisen, dass die entwickelte fekten durch falsche Interpretation des vorhandenen Quellcodes.
Software den Anforderungen relevanter Compliance-Standards und gesetzlicher
Regelungen genügt.
• Risiken bei Qualitätsmängeln: Scheitern der Wirtschaftsprüfung, Verstoß gegen 7.1.2 ERSTELLUNG UND PFLEGE DES PROZESSES
Compliance-Anforderungen oder gesetzliche Regelungen (z.B. Datenschutz).
Für die Umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschrei-
Performance bung eines Prozesses bewährt. Dazu zählen klare Verfahrensanweisungen und
Verantwortlichkeiten. Die genaue Ausprägung des Prozesses ist unternehmensspezi-
• Vorteil: Das Unternehmen stellt sicher, dass die vorhandene Hardware optimal fisch und kann in diesem Leitfaden nicht abgebildet werden; der Verweis auf die
genutzt werden kann und schützt damit die bisherige Investition in Hardware. Notwendigkeit ist jedoch allgemeingültig.
Außerdem steigt die Zufriedenheit der Mitarbeiter, da die Nutzung der Anwen-
dung produktiver wird.
• Risiken bei Qualitätsmängeln: Geringere Akzeptanz von den Anwendern bzw. BEST PRACTICE
zusätzliche Kosten für schnellere Hardware, um die Softwaremängel auszuglei- Definieren Sie den einzuhaltenden Prozess und doku-
chen. mentieren Sie ihn in einer für alle zugänglichen Form.
Robustheit
Definieren Sie auch, wie Änderungen und Verbesserungen
am Prozess stattfinden sollen und wie Anmerkungen und
• Vorteil: Das Unternehmen stellt den kontinuierlichen Betrieb der Geschäftsan- Kritik eingebracht werden können. Dokumentieren Sie alle
wendungen sicher und vermeidet Unproduktivität auf Grund von Systemausfällen. geprüften Regeln ausführlich mit den Kapiteln Hintergrund/
Motivation, schlechte Beispiele, gute Beispiele, Hinweise
• Risiken bei Qualitätsmängeln: Geringere Akzeptanz von den Anwendern und die zum Vorgehen zur Beseitigung der Qualitätsprobleme und
Betriebskosten steigen wegen Unproduktivität der Anwender sowie durch
Literatur bzw. Ansprechpartner im Unternehmen.
Fehleranalysen und Wartungsarbeiten durch Techniker.
Wartbarkeit
• Vorteil: Das Unternehmen erreicht, dass die Applikation nachhaltig und kostenef- Motivation
fizient gewartet werden kann, weil die Programmstruktur leicht verständlich und
gut dokumentiert ist. Ein Prozess für Best Practices bei der Entwicklung hilft, die Qualität von Software
proaktiv und effizient zu verbessern und damit Kosten im Unternehmen langfristig zu
• Risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte senken. Je früher ein Fehler bei der Entwicklung erkannt wird, desto einfacher und
Fehleranfälligkeit der Applikation. kostensparender kann er behoben werden. Je weniger Fehler eine Anwendung enthält,
desto mehr entspricht ihre Nutzung den Erwartungen des Unternehmens. Insbeson-
Erweiterbarkeit dere läuft sie ohne Nebeneffekte, die das Business negativ beeinflussen.
• Vorteil: Durch qualitativ hochwertigen Quellcode und angemessene Dokumentati-

on ist sichergestellt, dass Entwicklungen über den gesamten Lebenszyklus
hinweg mit vertretbarem Aufwand erweitert und angepasst werden können.

Welche Aspekte sind für den Prozess relevant? Bei jeder Regel, die zur nachträglichen Qualitätssicherung herangezogen werden soll,
muss festgelegt werden, wie diese werkzeuggestützt oder manuell überprüft werden
Interne Entwicklung kann. Wenn keine mechanische Überprüfung durch ein Werkzeug möglich ist, wird es
in der Praxis mit organisatorischem Aufwand verbunden sein, auf die konsequente
Für die interne Entwicklung werden Richtlinien als Nachschlagewerk für die tägliche Einhaltung der Regel zu achten.
Arbeit und regelmäßige Trainings für aktuelle Risiken benötigt.
Formale Code-Reviews verursachen erhebliche Aufwände. Sowohl für die Durchfüh-
Externe Entwicklung rung selbst als auch für die Vor- und Nachbereitung einschließlich der Kontrolle von
Korrekturen. Deshalb müssen Sie sich in aller Regel auf wenige nicht maschinell
Bei externer Entwicklung sind klare Qualitätsvorgaben für Ausschreibungen nötig. Vor prüfbare Aspekte kritischer Entwicklungsobjekte beschränken. Wenn z.B. die Einhal-
der Abnahme müssen die Anforderungen auch überprüft werden. tung von Performance-Vorgaben eine hohe Priorität besitzt, sollten in entsprechenden
Code-Reviews nur Entwicklungsobjekte mit Zugriffen auf Datenbanken oder mit
umfangreichen Berechnungen betrachtet werden.
BEST PRACTICE
Die Vorgaben aus dem Prozess müssen möglichst weit-
7.2 DURCHSETZBARKEIT
gehend mit geeigneten Tools überwacht werden. Für alle
Vorgaben, die nicht durch Tools validiert werden können, 7.2.1 MANUELLE PRÜFUNGEN
muss ein manueller, ggf. stichprobenhafter Prüfprozess
eingeführt werden. Hierzu eignen sich z.B. Mechanismen Viele der Prüfungen lassen sich automatisieren. Es gibt jedoch Bereiche, die sich für
wie das Pair-Programming49 oder iterative Code-Audits 50. eine automatische Prüfung nicht eignen, wie beispielsweise Dokumentation, Architek-
Die manuelle Prüfung bezieht sich hauptsächlich auf die tur oder viele funktionale Anforderungen. Die menschliche Sprache ist sehr komplex,
daher muss z.B. der Inhalt von Dokumenten und Dokumentationen manuell geprüft
Bereiche der Softwarestrukturierung / -architektur, Wart-
werden. Nur der menschliche Leser kann beurteilen, ob ein Text sinnvoll, vollständig,
barkeit und Erweiterbarkeit, die bei langlebigen Applikati- verständlich und korrekt ist. Eine automatische Prüfung kann dabei maximal die
onen einen hohen Kostentreiber darstellen können. Daher Existenz in den vorgegebenen Sprachen prüfen. Es empfiehlt sich dennoch ein auto-
empfehlen wir neben der Durchführung von maschinellen matischer Test auf nicht-funktionale Aspekte.
Prüfungen auch die manuellen Stichproben frühzeitig und
iterativ durchzuführen. Dieses Vorgehen bewährt sich Für die manuelle Prüfung ist es empfehlenswert, eine vollständige Prüfung anhand
vor allem bei größeren Projekten, da Fehlentwicklungen der Auswertung von Transportstücklisten vorzunehmen. Dabei ist zu berücksichtigen,
welche unternehmensinternen Richtlinien existieren. Abhängig von der Anzahl der
frühzeitig erkannt und mit Gegenmaßnahmen minimiert
Objekte muss eine vollständige oder zumindest stichprobenartige Prüfung erfolgen.
werden können. Das Prüfergebnis wird dem Zuständigen zur Verbesserung oder Vervollständigung der
Dokumente bzw. 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 aufge-
deckt werden, ist der Prozess entsprechend anzupassen oder ggf. neu zu definieren.
In der Praxis hat sich ein fest eingeplanter zyklischer Review des Prozesses bewährt.
49 Vgl. Dami Meyer Blog „Pair Programming“

50 Vgl. Wikipedia „Code-Audit“

Wann und wie sollte geprüft werden? Als zentrale Schutzinstanz sollten die Prüfungen in das Transportmanagement
integriert und spätestens mit der Freigabe des Transportauftrags (optimalerweise

Die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf Aktualität aber bereits mit der Freigabe der einzelnen Transportaufgaben) implementiert sein.
und Konformität bzgl. der Vorgaben geprüft werden. Die Aktualität ist zusätzlich mit Damit wird sichergestellt, dass keine ungeprüften bzw. nicht den Richtlinien entspre-
einem Upgrade auf ein neues Release (Enhancement Package) zu prüfen. Bzgl. der chenden Entwicklungen in die Folgesysteme und dann auch in das Produktivsystem
Vorgaben ist es durchaus sinnvoll, das Wirtschaftsprüfungsunternehmen hinzuzuzie- transportiert werden.
hen, das das Unternehmen prüft.
Als „letztes Sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsys-
Für extern entwickelten Quellcode müssen diese Prüfungen vor der jeweiligen tem möglich. Dieser sollte in einer lastarmen Zeit mittels eines Hintergrundjobs
Abnahme durchgeführt werden. eingeplant werden. Das Ergebnis wird dem QA-Zuständigen zur Verfügung gestellt,
der dann die weiteren Schritte (ggf. Korrektur) mit hoher Priorität veranlasst.
Für die Akzeptanz der Prüfungen bzw. der Beanstandungen im Zuge der manuellen
Prüfungen ist es sinnvoll, im Rahmen der Entwickler- und Qualitätssicherungstests Bei der Einführung von automatischen Prüfungen ist im Vorfeld zu definieren, wie mit
(4-Augen-Prinzip) die manuell notwendigen Prüfungen durch andere Entwickler altem Quellcode umgegangen wird. Sinnvoll kann es hierfür sein, einen Fahrplan zu
durchführen zu lassen. erstellen, wann und wie die neuen Regeln auf welchen alten Quellcode angewendet
werden.
Dasselbe gilt für Penetrations- und Belastungstests. Da es sich bei Penetrationstests
auch um ein kritisches Sicherheitsthema handelt, kann es notwendig sein, hierfür in Allerdings müssen firmenintern Kosten und Nutzen einer systematischen Überarbei-
regelmäßigen Abständen auch externe Partner hinzuzuziehen. tung von altem Quellcode abgewogen werden. Bei den Kosten muss auch der Testauf-
wand durch den Fachbereich sowie das Risiko neuer Fehler betrachtet werden.
7.2.2 AUTOMATISCHE PRÜFUNGEN
Automatische Prüfungen durch statische Code-Analysen (mit Code Inspector/ATC oder

BEST PRACTICE
Drittanbieter-Tools) decken schnell einen Großteil der notwendigen Tests und Prüfun- Für den Umgang mit altem Quellcode empfehlen wir, die
gen ab. Als Hintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne Prüfergebnisse des alten Quellcodes bei Beginn der re-
zusätzlichen Aufwand möglich. Diese regelmäßig mit gleicher Qualität durchgeführten gelmäßigen Prüfläufe festzuhalten und bei jedem weiteren
Tests ermöglichen so den Entwicklern, ihren Programmierstil zu verbessern. Prüflauf zu überwachen, dass im Vergleich zur initialen
Prüfung keine Verschlechterung der Prüfergebnisse ein-
Wann und wie sollte geprüft werden?
getreten ist.
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.
SAP bietet einige Werkzeuge, mit welchen die automatisierten Prüfungen durchgeführt
Wichtig ist, dass dieselben Tests und Metriken bei der Prüfung durch jeden einzelnen werden können. Eine Übersicht dieser Werkzeuge ist in Abschnitt 2.9 zu finden.
Entwickler und bei der Prüfung durch zentrale QS-Instanzen bzw. bei einer Transport-
freigabe verwendet werden. Sollten für diese Prüfungen unterschiedliche Werkzeuge
oder unterschiedliche Einstellungen verwendet werden, sinkt die Akzeptanz in
Entwicklerkreisen ganz erheblich.

7.3 ERFAHRUNGEN UND TIPPS AUS DER PRAXIS jekte mit manuell angelegten Klassifikationsattributen aus dem Classification Toolset52
stattfindet. Die Ausprägung der Klassifikationsattribute sollte auf Faktoren wie z.B.
7.3.1 QUALITÄTSSICHERUNG DES QUELLCODES erwartete Lebensdauer, Nutzungshäufigkeit, Kritikalität, Umfang, etc. basieren. Als
Resultat ergibt sich ein Szenario, das die zentralen Qualitätsbeauftragten entlastet und
Um eine erfolgreiche Einführung der Qualitätssicherung zu gewährleisten, ist ein die Teilverantwortung an das Entwicklungs- / Projektteam delegiert.
schrittweises und behutsames Vorgehen wichtig. Es empfiehlt sich, einen zweigeteil-
ten Ansatz zu fahren. Zunächst sollte neuer Quellcode „fehlerfrei“ erstellt und dies
geprüft werden. Erst wenn sich dieser Prozess stabilisiert hat, sollte nach und nach
bestehender Quellcode mit in die Checks aufgenommen werden. Ansonsten wird der
zu bewältigende Berg für die Entwickler zu groß und die Motivation sinkt rapide. BEST PRACTICE
Qualitätssicherung über Zwangsprüfungen wie die ATC/
Wenn die automatischen Codeprüfungen nicht auf der „grünen Wiese“ mit einer neuen Code-Inspector-Prüfung bei Transportfreigabe sind eine
Entwicklung eingeführt werden, sollte vorher der Umgang mit „Altlasten“ geklärt wirksame Möglichkeit Qualitätssicherung zu gewährleis-
werden. Auch bei neuen Entwicklungen lassen sich Änderungen an schon bestehenden ten. Allerdings führt dies zu einer gewissen Ineffizienz,
Objekten nicht vermeiden, die dann bei einer eingerichteten Transportprüfung zu
Problemen führen können. Hilfreich ist in solchen Fällen eine Klärung der Verantwort-
da zu diesem Zeitpunkt eventuell bereits fertiger Quell-
lichkeit für Entwicklungsobjekte, die z.B. durch das entsprechende Feld in Paketdefini- code überarbeitet werden muss. Sinnvoller ist es, wenn
tionen dokumentiert werden kann. Diese Verantwortlichen müssen entscheiden, ob Entwickler von vornherein Quellcode mit hoher Qualität
Fehler im bestehenden Quellcode sofort korrigiert werden müssen oder eine Ausnah- liefern. Dies kann zum Beispiel durch die Anwendung von
meregelung möglich ist. Clean-Code-Kriterien53 erfolgen. Wird in einem Team
grundsätzlich nach diesen Kriterien entwickelt, reduziert
Um die beschriebenen Probleme zu vermeiden, ist alternativ ein Konzept denkbar, in
dies den nachträglichen Anpassungsaufwand.
dem für älteres Coding keine Verschlechterung akzeptiert wird, in dem also in einer
automatischen Qualitätsprüfung keine neuen Befunde auftreten dürfen. SAP arbeitet
an einer Umsetzung dieses Konzepts für den ATC. Bis dahin gibt es einen SCN-Blog,
der eine kundenindividuelle Umsetzung beschreibt51. Vorteil ist, dass hierbei auch z.B.
neue Methoden in existierenden Klassen geprüft werden.
Generell ist es in vielen Fällen schon ausreichend, mit Standard-Bordmitteln, wie z.B. 7.3.2 TIME AND BUDGET QUALITY ASSURANCE (QA)
dem ABAP-Test-Cockpit, zu arbeiten, der sich auch um eigene Checks erweitern und
somit an eigene Bedürfnisse anpassen lässt. Um die Zeit und den Aufwand für die QA-Tätigkeiten möglichst gering zu halten, muss
der Entwickler den Quellcode während seiner Entwicklertätigkeit selbstständig auf
Eine weitere Strategie besteht darin, für Neuentwicklungen die Qualitätsanforderun- Fehler hin untersuchen können.
gen in den Prozess der Anforderungsanalyse mit einzubinden und direkt an das zu
erstellende Objekt zu koppeln. Hierdurch lässt sich eine Unterteilung in IT-Governance Tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten
getriebene und anforderungsspezifische Qualitätskriterien erreichen. Während die hingewiesen werden. Tägliche Inspektionen mit einem entsprechenden Werkzeug und
IT-Governance getriebenen Qualitätsanforderungen (z.B. die Sicherheitskriterien) Verteilung der Ergebnisse stellen sicher, dass Fehler frühzeitig erkannt werden und
verpflichtend zu erfüllen sind, ist für die Beurteilung und Ausnahmebestimmung die Entwickler sich noch an ihre Tätigkeiten vom Vortag erinnern, was die Fehlerbehe-
anderer Kriterien der ABAP-versierte Produktverantwortliche zuständig. Technisch bung deutlich vereinfacht. So wird gewährleistet, dass auch Entwickler, die den
lässt sich das Konzept realisieren, indem der Produktverantwortliche in dem Paket manuellen Aufwand scheuen oder unter Zeitdruck stehen, trotzdem die Möglichkeit
hinterlegt wird und eine Versorgung des Pakets bzw. der enthaltenen Quellcode-Ob- erhalten, ihre Fehler im Quellcode zu beheben. Es gilt: Je später die QA einsetzt, desto
52 SAP-Help-Suche „Classification Toolset“

51 http://scn.sap.com/community/abap/blog/2016/05/23/how-to-filter-atc-findings-to-detect-only-new-findings 53 Siehe auch http://clean-code-developer.de/

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.

BEST PRACTICE
Deshalb ist es wichtig, bei Planung und Schätzung eines Projekts die Qualitätssiche- Um bei auftretenden Problemen die Fragen der Entwick-
rung zu berücksichtigen, und zwar nicht nur am Ende, sondern projektbegleitend und
ler beantworten zu können, sollte eine zentrale Stelle
anschließend im kompletten Software-Lifecycle.
geschaffen werden. Außerdem muss es einen Prozess ge-
Nicht zu unterschätzen ist auch der notwendige Schulungsaufwand, um bei den ben, über den in Notfällen auch fehlerbehaftete Transpor-
Entwicklern um Verständnis für den Prozess zu werben. te freigegeben werden können. Gibt es diese Möglichkeit
nicht, sinkt das Verständnis für die durchgeführten Maß-
Bei einem Einsatz von externen Entwicklern müssen die Programmierrichtlinien und nahmen. Es kann zum Beispiel ein Genehmigungsprozess
Namenskonventionen Bestandteil des Vertrags sein. installiert werden, mit dessen Hilfe auch fehlerbehafteter
Quellcode freigegeben oder transportiert werden kann.
Die meisten Tools am Markt (einschließlich SAP Code In-
7.3.3 PROBLEME spector und ABAP-Test-Cockpit) bieten diese Möglichkeit
standardmäßig an.
Bei der Einführung einer Quellcode-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 bestehendem Quellcode
wird die Frage aber immer wieder aufgeworfen: 7.3.4 ENTSCHEIDUNGSFINDUNG BEI MODIFIKATIONEN
„Warum soll ich Quellcode überprüfen, in dem ich nur eine Zeile geändert habe?“ Die Hürde für Modifikationen sollte so hoch wie möglich gelegt werden. Dies ist
besonders wichtig, wenn zeitnah Enhancement Packages der SAP eingespielt werden
vs. sollen (SPAU-Problematik siehe dazu Abschnitt 8.4). Als Ansatzpunkt hierzu kann der
Modifikationsschlüssel dienen. Die Anzahl der Entwickler mit der Berechtigung,
„Warum soll ich Quellcode überprüfen, den ich schon Jahre nicht mehr angefasst habe?“ Modifikationsschlüssel zu generieren, muss möglichst gering sein. So ist es möglich,
steuernd einzugreifen und die Modifikationen über Change Requests und einen
Beide Positionen sind verständlich, deswegen muss eine klare Entscheidung bezüglich zugehörigen Prozess abzuhandeln. Da durch modifikationsfreie Erweiterungen kein
Handhabung von existierendem Quellcode, der auf anderen/keinen Konventionen SAP-Coding geändert wird und dadurch bei Upgrades potenziell weniger Probleme
beruht, getroffen und durchgesetzt werden. Wenn der Ersteller noch verfügbar ist, entstehen, sind sie Modifikationen grundsätzlich vorzuziehen.
empfiehlt sich, dass dieser in die QA miteinbezogen wird.
Die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu
Auch folgender Fall ist problematisch: Im Rahmen der Wartung erfolgt eine kleine beantworten und konsequent umzusetzen. Eine Pauschalantwort auf diese Frage gibt
Änderung an einem Include-Programm. Durch eine automatische Qualitätsprüfung es nicht. In jedem Fall sollte die Entscheidung jedoch auf gleichartigen, im Vorfeld
werden dabei Qualitätsfehler im Rahmenprogramm gefunden (bei mehrfach genutzten definierten und kommunizierten Kriterien basieren.
Include-Programmen evtl. sogar in mehreren Rahmenprogrammen). Die Korrekturen
erfordern – je nach Umfeld – einen aufwändigen zusätzlichen Test dieser Rahmenpro- Zum Thema Alternativen zu Modifikationen siehe Abschnitt 8.4.
gramme durch den Fachbereich.

Fehlende E-Mail-Adressen in Userstämmen führten zu Beginn zu Problemen, da die
Mails nicht zugestellt werden konnten. Solche Mails werden nun an eine zentrale
BEST PRACTICE Adresse versendet. Unvollständige Datensätze können so mit einem geringen Aufwand
Wenn SAP-Coding ergänzt oder geändert werden muss, identifiziert werden. Außerdem werden in diesem System nun keine Entwick-
lungs-User mehr ohne Mailadresse angelegt.
stehen vier Möglichkeiten zur Verfügung: explizite und
implizite Enhancements, Modifikationen und Kopieren Die Mails werden nicht von einem anonymen Batch-User sondern von der Mailadresse
des SAP-Objekts in den kundeneigenen Namensraum. des QA-Verantwortlichen gesendet, um dem Entwickler eine einfache Möglichkeit zu
Die einzelnen Optionen sollten in folgender Reihenfolge in geben, Fragen zu stellen. Zu Beginn entstand hierdurch ein hoher Aufwand, die Anzahl
Erwägung gezogen werden: explizite Enhancements vor der Fragen verringerte sich aber mit der Laufzeit des Projekts. Dies konnte durch
impliziten Enhancements, implizite Enhancements vor Schulungen erreicht werden, durch die die Entwickler effizienter Fehler korrigieren
Modifikationen und Modifikationen vor Kopien. Besonders bzw. diese schon bei der Entwicklung vermeiden können.
kritisch sind Kopien, weil dadurch eventuelle Fehler mit
Die Entwicklungssprache in der Entwicklungslandschaft ist Englisch. Dies wird durch
kopiert werden, der kopierte Quellcode aber nicht mehr einen weiteren Job geprüft und Fehler dem Entwickler gemeldet. SAP bietet im
der SAP-Wartung durch Hinweise und Updates unterliegt. Standard keine Möglichkeit, bei der Anlage eines Entwicklungsobjekts eine vorgegebe-
ne Sprache zu setzen. Deshalb gab es nur die beiden Möglichkeiten, entweder an
passender Stelle eine entsprechende Prüflogik per Modifikation einzubauen oder
damit zu leben, dass Objekte in falscher Sprache angelegt werden und im Nachgang
umgezogen werden müssen.
7.3.5 ERFAHRUNGSBERICHT AUS DER PRAXIS: COMGROUP GMBH
Bei Anlage von Objekten werden zudem per Modifikation Namenskonventionen
Das nachfolgende Beispiel der Comgroup GmbH, dem IT-Dienstleister der Würth überprüft, sodass diese nur gemäß den Konventionen benannt werden können.
Gruppe, zeigt, wie Programmierrichtlinien und Namenskonventionen in einer Soft-
wareentwicklung ein- und durchgesetzt werden können. Um eigene Prüfungen bei der Transportfreigabe durchzuführen (z.B. eigene Namens-
konventionen/mindestens deutsche und englische Übersetzung) wurde eine Imple-
Die Comgroup GmbH startete mit der Quellcode QA im globalen Entwicklungssystem mentierung für das Business Add In CTS_REQUEST_CHECK angelegt und die Methode
einer mehrstufigen Entwicklungslandschaft. Zur automatisierten Unterstützung wurde CHECK_BEFORE_RELEASE genutzt.
der Code Inspector eingesetzt. Da zeitgleich mit der Quellcode-QA auch ein neuer
Namensraum eingeführt wurde, wurden zu Beginn des Projekts nur Objekte aus dem Nachdem sich der Prozess im globalen Entwicklungssystem stabilisiert hatte, wurde
neuen Namensraum geprüft und bestehender Quellcode nicht berücksichtigt. Dies dieser an die nachfolgenden Entwicklungssysteme und Namensräume ausgerollt.
erleichterte die Selektion im Code Inspector, da diese keine Änderungs- oder Erstel- Bestehender Quellcode wird bisher noch nicht gecheckt. Zusätzlich ist geplant, ein
lungsdaten berücksichtigt. Außerdem wurden Performance- und Security-Checks aus externes Tool einzusetzen, das die Qualitätssicherung vereinfacht.
dem Code Inspector vorerst nicht aktiviert, um den Aufwand in einem überschaubaren
Rahmen zu halten.
Mit diesem Tool kann der Entwickler seinen Quellcode während der Entwicklung
selbstständig überprüfen. Zusätzlich wurde ein Nachtlauf eingeplant, der den kom-
pletten zu scannenden Quellcode analysiert und bei gefundenen Fehlern Mails an den
jeweiligen Entwickler sendet.

8 INFRASTRUKTUR UND LIFECYCLE MANAGEMENT Das Qualitätssicherungssystem sollte für z.B. umfangreichere Validierungsaktivitäten
regelmäßig aus dem Produktivsystem kopiert werden. Damit wird die Übereinstim-
In diesem Kapitel stehen die Infrastruktur und die Betrachtung des Lebenszyklus einer mung mit der operativen (Daten-)Umgebung sichergestellt. Im Qualitätssicherungs-
Softwarekomponente im Fokus. Sie stellen neben methodischen Empfehlungen und system erfolgt die Abarbeitung von Testplänen nach Änderungen und Neuentwicklungen.
LIFECYCLE MANAGEMENT
8. INFRASTRUKTUR UND
Werkzeugen bei der Softwareentwicklung im SAP-System wichtige Rahmenbedingun-

gen für erfolgreiches Arbeiten dar. Entwickler und Modulbetreuer haben im Qualitätssicherungssystem weitreichende
Berechtigungen. Einschränkungen müssen individuell festgelegt werden, z.B. für
besonders sensible Daten (HR etc.). In Zusammenhang mit personenbezogenen Daten
ist der Datenschutz zu berücksichtigen55. Es empfiehlt sich, zusätzlich Benutzer mit
8.1 INFRASTRUKTUR produktionsidentischen Berechtigungen zu verwenden, um hier auch den Aspekt
Berechtigung zu testen.
Eine SAP-Systemlandschaft ist i.d.R. mehrstufig aufgebaut. In Abhängigkeit von der
Releasestrategie sind zwei sinnvolle Alternativen zu betrachten. Sofern regelmäßig in
kurzen Zeitabständen kleinere Änderungen, im Sinne von kurzfristigen Releases,
transportiert werden, ist eine klassische 3-Systemlandschaft zu präferieren. Kommt 8.1.1.3 Produktion
hingegen eine Release-Strategie mit langen Release-Zyklen zum Einsatz, spricht dies
für eine 5- bzw. 6-Systemlandschaft. Nachfolgend werden die einzelnen Systeme und Im Produktivsystem herrscht ebenfalls Customizing- und Entwicklungsverbot.
ihre Bedeutung dargestellt. Customizing- und Workbench-Objekte werden ausschließlich per Transportauftrag in
dieses System importiert.
Entwickler und Modulbetreuer haben im Produktivsystem nur eingeschränkte Berech-

8.1.1 KLASSISCHE 3-SYSTEMLANDSCHAFT tigungen. Notfall-Tabellenänderungen (&SAP_EDIT) sind mit Datum, Uhrzeit und
Begründung zu dokumentieren. Hierzu empfiehlt sich die Verwendung eines Tools, um
8.1.1.1 Entwicklung die Meldungen zu standardisieren. Der Umgang mit speziellen Notfall-Benutzern, die
weitergehende Berechtigungen haben, muss technisch und organisatorisch festgelegt
Im Entwicklungssystem wird entwickelt, Customizing geändert und es werden erste werden.
Entwicklertests durchgeführt. Aufgrund einer durch laufende Entwicklungen und
Customizing-Tätigkeiten verursachten Instabilität, ist ein Test durch Dritte (Fachbe-
reich) in diesem System nicht sinnvoll.
8.1.2 5- BZW. 6-SYSTEMLANDSCHAFT
Entwickler und Modulbetreuer haben im Entwicklungssystem sehr weitreichende
Berechtigungen. Meist gibt es nur wenige Testdaten. Wenn lange Release-Zyklen zum Einsatz kommen, ist diese Landschaft sinnvoll. Im
Entwicklungssystem erfolgt die Entwicklung des neuen Releases. Die Wartung bzw.
Fehlerbearbeitung des produktiven Releases erfolgt in zwei separaten Systemen.
8.1.1.2 Qualitätssicherung
Im Qualitätssicherungssystem herrscht Customizing- und Entwicklungsverbot 8.1.2.1 Entwicklung

(Systemeinstellung „nicht änderbar“). Customizing- und Workbench-Objekte werden
ausschließlich über Transporte importiert54. Importe nach Produktion erfolgen Das Entwicklungssystem entspricht in dieser Landschaft dem Entwicklungssystem
grundsätzlich über das Qualitätssicherungssystem. Damit wird eine mit der Produkti- der 3-Systemlandschaft.
on übereinstimmende Systemumgebung sichergestellt.
54 Auch in der 3-Systeme-Landschaft kann mit Transporten von Kopien gearbeitet werden, wie in Abschnitt 8.1.4 Best Pratice beschrieben. 55 Vgl. DSAG-Leitfaden Datenschutz

8.1.2.2 Test 8.1.2.4 Wartung
Im Testsystem herrscht absolutes Customizing- und Entwicklungsverbot. Customizing- Im Wartungssystem erfolgt die Wartung bzw. Betreuung der produktiven Software für
und Workbench-Objekte werden ausschließlich per Transportauftrag importiert. den Zeitraum, in dem im Entwicklungssystem das neue Release entwickelt wird. Die
Übernahme aller Korrekturen aus dem Wartungssystem in das neue Release muss
Importe in dieses System erfolgen im Regelfall durch Transporte von Kopien (siehe sichergestellt werden.
Abschnitt 8.1.4 Best Pratice). So wird gewährleistet, dass bearbeitete Entwicklungsob-
jekte im Entwicklungssystem über den gesamten Release-Zeitraum gesperrt bleiben. Nach einem Produktivgang, d. h. dem Transport eines Releases auf die Produktion,
Der Original-Transportauftrag wird erst zur Produktivsetzung freigegeben. Durch die muss das Wartungssystem wieder konsistent mit der Produktion werden. Dies kann
Transporte von Kopien können Entwicklungen und Customizing schon vorab im auf unterschiedlichen Wegen erfolgen. Ein typisches Vorgehen ist der Import der
Testsystem getestet werden. Damit ist es möglich, viele Entwicklungen und Customi- Releasetransporte auf das Wartungssystem.
zing im Entwicklungssystem zu bündeln und so die Anzahl der Release-Transporte für
das Qualitätssicherungs- und das Produktivsystem zu minimieren. Wenn dieser Vorteil
nicht benötigt wird, kann auf das Testsystem verzichtet werden.
8.1.2.5 Konsolidierung
Das Testsystem wird bei Bedarf aus dem Produktivsystem kopiert. So ist es möglich,
bereits vorab umfangreiche Tests durchzuführen. In diesem System erfolgt der Test der Änderungen aus dem Wartungssystem.
Entwickler und Modulbetreuer haben im Testsystem sehr weitreichende Berechtigun-

gen. Einschränkungen müssen individuell festgelegt werden, z.B. für besonders sensib-
le Daten (HR etc.). Es empfiehlt sich aber auch, Testbenutzer mit produktionsnahen 8.1.2.6 Produktion
Berechtigungen zu verwenden.
Das Produktivsystem entspricht in dieser Landschaft dem Produktivsystem der
3-Systemlandschaft.
8.1.2.3 Qualitätssicherung
Das Qualitätssicherungssystem entspricht in dieser Landschaft dem Qualitätssiche- 8.1.2.7 Schematische Darstellung 6-Systemlandschaft
rungssystem der 3-Systemlandschaft.
Die Versorgung des Qualitätssicherungssystem erfolgt:
• in einer 6-Systemlandschaft nur mit Releasetransporten,
• in einer 5-Systemlandschaft mit den laufenden normalen Transportaufträgen.
Abbildung 2: Schematische Darstellung 6-Systemlandschaft

8.1.3 SANDBOX Die Importe in Test- bzw. Qualitätssicherungssysteme müssen in Abhängigkeit von der
Systemlandschaft organisiert werden. Oft werden Importe in diese Systeme zyklisch
Die Sandbox ist ein reines Test- und „Spielsystem“. In der Sandbox gelten keine und automatisiert durchgeführt, um die Mitarbeiter der Basisabteilung zu entlasten
Einschränkungen in Bezug auf Berechtigungen, das gilt gleichermaßen für Customi- und Wartezeiten für Entwickler und Tester zu reduzieren.
zing- und Workbench-Entwicklungen. Aus der Sandbox erfolgen keine Transporte in

andere Systeme. Komplexe Änderungen können so vor der Durchführung im Entwick- Wenn mehrere Entwickler an einem Entwicklungsobjekt Änderungen vornehmen, kann
lungssystem ausprobiert werden. Der Rückbau komplexer Entwicklungen in der dies unter Umständen zu Problemen führen, wenn die Transportaufträge nicht in der
Entwicklungsumgebung, z.B. wenn eine Neuentwicklung nicht weiter verfolgt wird, richtigen Reihenfolge in die produktiven Systeme transportiert werden oder Objekte
kann so vermieden werden. Zur Bereinigung der prototypischen Entwicklungen im aus anderen Transportaufträgen fehlen.
Sandbox-System sollte es regelmäßig neu aufgesetzt werden, z.B. als Kopie aus dem
Produktivsystem.
BEST PRACTICE
8.1.4 TRANSPORTWESEN Um Probleme mit der Importreihenfolge von freigegebenen
Transporten, die dieselben Entwicklungsobjekte betreffen,
Der Transportweg ist wie folgt festgelegt: zu vermeiden, sollte für die Belieferung der Test- und Qua-
litätssicherungssysteme mit Transport von Kopien gear-
• 3-Systemlandschaft: beitet werden. Die geänderten Entwicklungsobjekte bleiben
bis zur Produktivsetzung durch den eigentlichen Transpor-
Entwicklung → Qualitätssicherungssystem → Produktion (nach Qualitäts
sicherungssystem evtl. mit Transporten von Kopien)
tauftrag im Entwicklungssystem gesperrt. Ein Entwick-
ler wird durch das System darauf hingewiesen, wenn ein
• 5-/6-Systemlandschaft: anderer Entwickler das Objekt bereits bearbeitet, und kann
sich mit diesem Entwickler abstimmen. Nach Abschluss
Entwicklung → Test (in dem Fall immer Transporte von Kopien) des Projekts oder der Änderung wird nur der eigentliche
Transportauftrag über das Qualitätssicherungssystem ins
Entwicklung → Test -> Qualitätssicherungssystem → Produktion
Produktivsystem transportiert.
(Release-Transporte)
Wartung → Konsolidierung → Produktion (Wartung/Betreuung während

Release-Entwicklung)
Das im SAP Solution Manager enthaltene Change and Request Management (ChaRM)
Die Sandbox sollte aus dem Transportweg ausgeschlossen werden. Importe aus dem arbeitet intern mit diesem Verfahren.
Entwicklungssystem in die Sandbox erfolgen nur auf individuelle Anforderung.
Der Import in das Produktivsystem sollte in der Regel durch interne, verantwortliche
Die Freigabe von Transporten im Entwicklungssystem erfolgt üblicherweise durch den Mitarbeiter durchgeführt werden. Voraussetzung ist die formale Freigabe (im Sinne
Entwickler. Bei mehreren mit Transportaufgaben an einem Thema beteiligten Entwick- einer dokumentierten Entscheidung, siehe Abschnitt 8.2 Change Management). Hierfür
lern gibt ein Entwickler in der Rolle des Koordinators den Transportauftrag frei. Es wird ebenfalls die Verwendung eines geeigneten Tools (z.B. Solution Manager ChaRM)
können automatische Qualitätsprüfungen zum Beispiel mit dem ABAP-Test-Cockpit zur Standardisierung bzw. Formalisierung empfohlen.
(siehe Abschnitt 2.9) oder dem Code Inspector (siehe Abschnitt 7.2.2 „Automatische
Prüfungen“) konfiguriert werden, die die Transportfreigabe verhindern können und
Nachbesserungen oder eine Ausnahmegenehmigung erfordern.

8.1.5 SICHERSTELLUNG DER KONSISTENZ 8.1.6 RÜCKBAU VON NEUENTWICKLUNGEN
VON NEUENTWICKLUNGEN UND ERWEITERUNGEN
Wurden im Entwicklungssystem Entwicklungen erstellt, die im produktiven Release
Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. Es kann nicht nutzbar bzw. unzugänglich sein sollen, so existieren verschiedene Möglichkeiten,
zur überschneidenden Verwendung von Objekten kommen, die es im Zielsystem dies zu erreichen:
(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. • Kompletter Rückbau der Änderungen, sofern diese auch in späteren Releases
Neuentwicklungen bzw. Erweiterungen müssen in geeigneten Paketen bzw. Trans- nicht benötigt werden.
portaufträgen gekapselt werden. Es wird empfohlen, die Transportaufträge für ein
Projekt auf je einen Transportauftrag für Workbench, Customizing und Berechti- • Deaktivierung der Entwicklung, so dass der Quellcode im Produktivsystem nicht
gungsrollen einzuschränken. „Vorabtransporte“ sollten nur mit Hilfe von Transport von durchlaufen wird. Dies kann durch unterschiedliche Strategien erreicht werden:
Kopien erlaubt sein.
• Durch Auskommentieren des Quellcodes (bei kleineren Code-Anderungen).
Die endgültige Freigabe und der Transport erfolgt erst zum Projektabschluss. Alle
Projektmitarbeiter verwenden innerhalb eines Projekts nur Aufgaben zu einem jeweils • Durch Einbauen einer Weiche im Quellcode, die sicherstellt, dass der nicht
vorgegebenen Transportauftrag. Es gibt keine „persönlichen“ Transportaufträge für freigegebene Quellcode nicht durchlaufen wird. Die Ausgestaltung der
Projektmitarbeiter. Weiche hängt vom konkreten Fall ab.
Generell erfolgt ein Import nur nach formeller Freigabe (siehe Change-Verfahren) durch • Customizing muss ggf. komplett entfernt oder zurückgebaut werden.
einen Process Owner, die Qualitätssicherung oder ähnliche Instanzen. Die Abfolge sowie
die beteiligten Bereiche müssen unternehmensspezifisch festgelegt werden. Im Falle der Nutzung von TMS Quality Assurance (QA)56 als Genehmigungsworkflow gilt:
• Die Ablehnung durch den Qualitätsverantwortlichen verbietet lediglich den Trans-

port der Funktionalität in nutzbarer bzw. zugänglicher Form ins Produktivsystem.
Der Quellcode kann zwar geliefert werden, aber er darf in keinem Fall durchlau-
fen werden.
• Ein Prozess muss sicherstellen, dass die abgelehnte Entwicklung in allen

relevanten Systemen in einen nicht zugänglichen Stand überführt wird. Wie oben
bereits erwähnt kann dies durch einen vollständigen Rückbau oder eine Deakti-
vierung über Weichen im Quellcode erreicht werden.
• Die zuständigen Entwickler müssen von abgelehnten Transporten erfahren. Die

Pflicht zur Informationsweitergabe liegt bei den Qualitätsverantwortlichen.
Zum Rückbau von „verwaisten“ Entwicklungen ist im SCN ein kleines Z-Programm
vorgestellt worden (Report for Rolling Back Abandoned Developments).
56 https://help.sap.com/saphelp_nw70/helpdata/de/9c/a544c6c57111d2b438006094b9ea64/content.htm

8.2 CHANGE MANAGEMENT Beispiel für ein Change-Control-Formular (CC):
Um eine SAP-Systemlandschaft wartbar und beherrschbar zu gestalten, ist ein CC Nummer: Datum:
formales Change-Verfahren die Voraussetzung für jede Systemänderung. Dabei gilt
von IT ausfüllen
CC Titel:
das grundsätzliche Verfahren gleichermaßen für Änderungen am SAP-Standard und
von IT ausfüllen
für Kundenentwicklungen.
Anforderung
Das Basiswerk zur Einführung eines Change- und Releasemanagements ist die Anforderer: Kostenstelle:
Information Technology Infrastructure Library (ITIL)57. In diesem Referenzleitfaden Abteilung:

sind umfangreiche und allgemeingültige Best Practices beschrieben.
Wuschdatum: Priorität:
niedrig/mittel/hoch
In diesem Kapitel stellen wir ein konkretes Beispiel aus der Entwicklung dar, das Änderungsart:
firmen- bzw. branchenspezifisch adaptiert werden kann. Änderung/Autorisierung
Änderung:
(Kurzbeschreibung)
Wir empfehlen grundsätzlich, die folgenden Aspekte bei der Einführung eines Change-
Control-Verfahrens (auch: Change-Request-Verfahren) zu berücksichtigen:
Ausführliche Beschreibung als Anlage anfügen!
Process Owner: Datum/Unterschrift:
• Fachliche Anforderung
Process Owner Datum/Unterschrift:
Fremd:
• Begründung
Bearbeitung
• Bewertung (Aufwandschätzung) Applikation/Modul: Bearbeiter:
Genehmigt Datum/Unterschrift:
• Genehmigung SAP-Koordination:
Genehmigt Datum/Unterschrift:
SAP-Leitung
• Freigabe der Änderung für das Produktivsystem Bemerkung:
Der Genehmiger- bzw. Freigeberkreis (Process Owner, QS …) ist abhängig vom

Gegenstand der Änderung (betroffener Bereich, betroffene Anwendung, gegebenen-
Freigabe/Produktionsübergabe
falls auch Aufwand).
Geprüft durch
Anforderer: Datum/Unterschrift:
Die Verwendung eines geeigneten Tools (z.B. Solution Manager ChaRM) wird dringend Geprüft
SAP-Koordination: Datum/Unterschrift:
empfohlen. Dabei gilt jedoch: Eine papierbasierte Lösung ist besser als keine! Geprüft IT-Leitung:
Datum/Unterschrift:
Transport/Übergabe
durch Bearbeiter: Datum/Unterschrift:
Abbildung 3: Change-Control-Formular (CC)
57 siehe https://de.wikipedia.org/wiki/IT_Infrastructure_Library

Das abgebildete CC-Formular enthält beispielhaft die wesentlichen Daten, die beglei- • Im Falle der Genehmigung erhält der Bearbeiter das CC zur weiteren Bearbei-
tend zur Abwicklung einer Systemänderung erforderlich sind. tung; eine Änderung zwecks Weitertransport darf von einem Bearbeiter aus-
schließlich mit einem vollständig genehmigten CC durchgeführt werden.
Basisprozess und Rollen:
• Nach Fertigstellung lässt der Bearbeiter die Änderung durch den Anforderer
• Der Anforderer füllt den Teil „Anfordernde Abteilung“ aus und sorgt für die prüfen.
Unterschrift des Process Owners und/oder des Process Owners Fremd
• Entspricht die Umsetzung den Anforderungen, gibt der Anforderer die Änderung
• Der Process Owner ist in der Regel ein Vorgesetzter des Anforderers. Er ist zum Transport frei; der Anforderer bestätigt mit seiner Unterschrift die ord-
verantwortlich für einen bestimmten Teil der Daten bzw. für die Nutzung be- nungsgemäße Umsetzung; ein Transport darf erst nach Freigabe durch den
stimmter Teile der SAP-Software, z.B. der Einkaufsleiter für die SAP-Einkaufsda- Anforderer durchgeführt werden.
ten und -programme
• SAP-Koordinator und IT-Leitung bestätigen die ordnungsgemäße Umsetzung. Die
• Der Process Owner Fremd ist immer dann einzubeziehen, wenn eine Änderung ordnungsgemäße Umsetzung sollte anhand einer Checkliste überprüft und durch
auch Daten oder Programme betrifft, die außerhalb der Zuständigkeit des den Einsatz von Prüfwerkzeugen unterstützt werden (siehe nachfolgende Best
Process Owners liegen. Practice-Empfehlungen). Ein Transportauftrag darf nicht ohne vorangegangene
Beispiel: Der Einkäufer benötigt Berechtigungen aus dem Bereich der Anlagen- Freigabe durch die SAP-Koordination und die IT-Leitung ins Produktivsystem
buchhaltung; hier muss der Process Owner zustimmen, der diesen Teil des importiert werden.
Systems verantwortet (z.B. der Leiter der Anlagenbuchhaltung).
• Der Bearbeiter übergibt den Transport in das Produktivsystem und leitet das CC
• Eine ausführliche Beschreibung der Änderung ist dem CC in jedem Fall als an die SAP-Koordination und die IT-Leitung weiter.
Anlage anzufügen; CCs ohne eine ausführliche Beschreibung werden zurückge-
wiesen. Der Anforderer gibt das CC an die IT weiter. Der Genehmigungs- und Freigabeprozess und damit auch der Inhalt des Formulars
können branchenspezifisch stark variieren. In pharmazeutischen Unternehmen ist
• Der SAP-Koordinator ist derjenige, der die anfallenden Aktivitäten für SAP oder beispielsweise grundsätzlich die QA in das CC-Verfahren eingebunden. Darüber hinaus
einen Teil von SAP koordiniert und den einzelnen Modulbetreuern die Aufgaben ist es in allen Unternehmen üblich, dass bei Überschreitung von bestimmten (ge-
zuweist. Diese Aufgabe kann – in Abhängigkeit von der Größe der Organisation – schätzten) Projektkostenlimits weitere Genehmiger der Umsetzung zustimmen
auch von einem Gruppen- oder Abteilungsleiter innerhalb der IT übernommen müssen. Die Genehmigungsstruktur hängt also auch von der jeweiligen Unternehmens
werden. Die betreffende Person trägt die Applikation bzw. das Modul im Formular organisation ab.
ein und weist das CC einem Bearbeiter zu. Sie kann das CC auch aufgrund
formaler Fehler (z.B. fehlende oder unzureichende Beschreibung, fehlende Das vorgestellte Formular enthält daher lediglich die Minimalanforderungen an ein CC
Unterschrift des Process Owners oder des Process Owner Fremd) zurückweisen. ohne Berücksichtigung branchen- oder organisationsspezifischer Anforderungen.
Der SAP-Koordinator vergibt eine eindeutige CC-Nummer und den CC-Titel; diese
CC-Nummer kann z.B. auch von einem Projektmanagement-Tool übernommen Weitere Genehmigungs- bzw. Freigabeschritte oder zusätzliche Felder mit Bezug zu
werden. anderen Dokumenten (z.B. Validierungsdokumente) sind bei Bedarf individuell zu
ergänzen und der Prozess entsprechend zu erweitern.
• Der IT-Leiter oder der SAP-Leiter genehmigt / lehnt ab / stellt zurück (mit
entsprechender Begründung), nachdem der Koordinator genehmigt hat.

8.3 SOFTWAREWARTBARKEIT
BEST PRACTICE 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 System-
Checkliste vor Freigabe eines Workbench-Transports

zusammenhang von Applikationen durchgeführt werden können58.

durch den SAP-Koordinator und die IT-Leitung zum Trans-
port in das Produktivsystem: Technisch ist ein modularer Aufbau erforderlich (siehe Abschnitt 2.3 Lesbarkeit und
• Automatische Prüfungen des Quellcodes durchlau- Modularisierung). Wiederverwendbarer Quellcode muss in globalen Klassen oder
fen? Der Code Inspector bzw. ATC oder die erweiterte Funktionsbausteinen organisiert werden. Die Identifikation von wiederverwendbaren
Programmprüfung wurden für alle Programme des Objekten lässt sich durch den Einsatz von Paketschnittstellen realisieren.
Transportauftrags durchgeführt. Die Ergebnisliste
darf dabei keine Fehler oder Warnungen enthalten, In Systemumgebungen mit verschiedenen Entwicklungs- und Produktivsystemen
(Transportstrecken) sollte der Grundsatz gelten: Gleicher Objektname (Transaktions-
Informationsmeldungen sind zulässig. Optimalerwei-
code, Programm, Include, Tabelle etc.) bedeutet auch identisches Coding bzw. identi-
se werden die Prüfungen automatisch bei jeder sche Objekteigenschaften.
Transportfreigabe ausgeführt (siehe Abschnitt 2.9).
• Drittanbietertools? Sofern weitere Testtools für Alle Entwicklungen, Änderungen und Korrekturen sind zu dokumentieren (Vgl. Kapitel
6 Dokumentation).
Themenbereiche wie Security, Performance, etc.
vorhanden sind, wurden diese ausgeführt?
• Gegebenenfalls manuelle Prüfungen, eventuell
stichprobenartig. 8.4 ANPASSUNGEN DER SAP-FUNKTIONALITÄT
• Manuelle Vor- oder Nacharbeiten? Es ist zu prüfen, ob Um die Funktionalität eines SAP-Systems an eigene Bedürfnisse anzupassen, gibt es
eine vollständig abgearbeitete Checkliste für manuel- verschiedene Möglichkeiten, die jeweils Vor- und Nachteile mit sich bringen:
le Vor- und Nacharbeiten zum Transport vorliegt.
• Erweiterung (User-Exit, Customer-Exit, BTE, BAdI, Enhancement Points und
• Mehrsprachigkeit? Sofern im Transportauftrag Sections, CDS Extensions)
übersetzungsrelevante Objekte enthalten sind, ist zu
prüfen, ob die Übersetzungen gemäß Übersetzungs- • Implizite Erweiterung
strategie versorgt sind.
• Modifikation
• Abhängigkeiten in den Transporten? Es muss auf
Abhängigkeiten in den Transporten geprüft werden. • Z-Kopie, Kopie im Kundennamensraum
• Systeminterne Dokumentation? Siehe Kapitel 6.2 Von der Verwendung dieser Möglichkeit wird ausdrücklich abgeraten!
Zu den problemlos nutzbaren Techniken zählen User-Exits, Customer-Exits, BTEs und

BAdIs. Wenn sie an geeigneter Stelle und mit geeigneter Schnittstelle vorhanden sind,
sollten sie genutzt werden.
WEITERE QUELLEN
Es folgt eine kurze Beschreibung dieser Techniken.
1. Mathias Friedrich, Torsten Sternberg, Change Request Management mit dem SAP
Solution Manager, SAP Press, 2009 58 Wikipedia „Wartbarkeit“

User-Exit Enhancement Framework
User-Exits sind Unterprogramme, die sich in Includes im SAP-Namensraum Mit dem neuen Enhancement Framework versuchte SAP, die Nachteile der bisheri-
befinden, aber nur einmalig von SAP ausgeliefert werden und deshalb ohne gen Erweiterungstechniken zu beheben. Zum Enhancement Framework zählen:
Probleme „modifiziert“ werden können.

• Explizite Enhancements (Enhancement Points und Enhancement Sections)
Customer-Exit
• „Neue“ BAdIs (wobei Implementierungen der alten BAdI-Technologie
Customer-Exits sind Funktionsbausteine, die zu- und abschaltbar sind und vom automatisch migriert werden können)
Kunden implementiert werden können, um die Standardfunktionalität zu erweitern.
• Implizite Enhancements
Business Transaction Event (BTE)
Enhancement Point
Im FI-Umfeld stellen BTEs eine zusätzliche Möglichkeit der Erweiterung dar.
BTEs sind vergleichbar mit Customer-Exits, beschränken sich jedoch weitestge- Diese bieten die Möglichkeit, an festgelegten Stellen Quellcode einzufügen. Dabei gilt:
hend auf das FI-Modul und stellen eine vordefinierte Schnittstelle zur Verfügung,
an die der Entwickler Erweiterungen anhängen kann. Weitere Informationen • Mehrere aktive Implementierungen sind parallel möglich und
finden sich in der SAP-Standarddokumentation.
• alle aktiven Implementierungen werden ausgeführt.
Business Add-In (BAdI)
Enhancement Section
Mit BAdIs versuchte SAP, die folgenden Nachteile der bisherigen Erweiterungs-
techniken zu umgehen: Diese bietet die Möglichkeit einen definierten Abschnitt eines Programms durch
eigenen Quelltext zu ersetzen. Dabei gilt:
• Zugriff auf alle globalen Variablen (User-Exits)
• Mehrere aktive Implementierungen sind parallel möglich aber
• Nur einfach verwendbar (Customer-Exits)
• nur eine aktive Implementierung wird ausgeführt.
• Keine Dynpro-Erweiterungen (BTEs)
• Es ist nicht klar, welche aktive Implementierung ausgeführt wird.
• Keine Menü-Erweiterungen (BTEs)
Hinweis: Implementierungen von Enhancement Sections können durch das
• Keine Verwaltungsebene (BTEs) Einspielen von SAP Enhancement Packages oder das Aktivieren von Business
Functions durch neue aktive Implementierungen oder neu aktivierte Implemen-
Deshalb können BAdIs mehrfach verwendbar sein und alle Erweiterungsarten tierungen ersetzt werden. Es ist dann sehr schwierig, ersetzte und nicht mehr
(Programm-, Menü- und Dynpro-Exit) zur Verfügung stellen. Sind für einen Erweite- ausgeführte Implementierungen zu identifizieren. Somit kann sich durch Ände-
rungswunsch mehrere Erweiterungstechniken verfügbar, so wird die Verwendung rungen im SAP-Standard das Verhalten der Erweiterung ändern. Dies erhöht den
von BAdIs empfohlen. notwendigen Testaufwand (TCO) massiv und führt leicht zu Disruption bei einem
SAP-Release-Upgrade und EHP. Die Verwendung von Enhancement Sections ist
daher sehr sorgfältig zu prüfen.

ABAP CDS Extensions Modifikation
Diese erlauben die modifikationsfreie Erweiterung von CDS Views. Die Erweite- Modifikation des von der SAP ausgelieferten Quellcodes ist grundsätzlich
rung ermöglicht das Hinzufügen von View-Feldern und Assoziationen. Die problematisch, da
Erweiterung unterliegt Einschränkungen, die in der ABAP-Schlüsselwort-Doku-

mentation des jeweiligen NetWeaver Relaeses beschrieben sind.59 • Modifizierte Entwicklungsobjekte nicht der Wartung der SAP unterliegen und
somit im Rahmen der SAP-Supportticket-Bearbeitung durch den Kunden zurück-
gebaut werden müssen.
Kann mit den bereits genannten Erweiterungstechniken das gewünschte Ergebnis
nicht erreicht werden, gibt es weitere Möglichkeiten, deren Verwendung aber von Fall • Modifikationen spätestens bei jedem Upgrade des SAP-Systems und unter
zu Fall abgewogen werden muss. Umständen auch beim Einbau von SAP-Hinweisen oder Service Packs, auf
Kompatibilität mit dem SAP-Quellcode geprüft und ggf. angepasst werden
Implizite Enhancements müssen.
Jeweils am Anfang und am Ende von Prozeduren kann Code eingefügt oder der Grundsätzlich sollte nur dann modifiziert, wenn:
komplette Code (bei Methoden) ausgetauscht werden.
• Customizing oder Personalisierung Ihre Anforderung nicht umsetzen
Der Unterschied zwischen impliziten und expliziten Enhancements ist groß: können und
Implizite Enhancements ähneln Modifikationen, mit teilweise den gleichen
Nachteilen. Explizite Enhancements ähneln BAdIs. • Keine geeigneten Erweiterungsmöglichkeiten vorgedacht sind.
Bei der Verwendung von impliziten Enhancements ist die SPAU_ENH abzuarbeiten, Im Change-Prozess sollte der Sonderfall Modifikation aus Gründen der Nachvoll-
da diese Enhancements in der regulären SPAU-Transaktion nicht angezeigt werden. ziehbarkeit separat abgebildet werden.
Die Entscheidung, ob implizite Erweiterungsmöglichkeiten genutzt werden Kopien in eigenen Namensraum/Z-Namensraum

sollen, ist nicht nur abhängig vom Realisierungsaufwand, sondern auch von
einem möglichen Folgeaufwand. Kopien von Quellcode aus dem SAP-Standard in den Kundennamensraum sind
sehr pflegeaufwändig. Es wird empfohlen, keine Kopien durchzuführen. Es gibt
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.
59
CDS View SAP NetWeaver 740
CDS View SAP NetWeaver 750

8.5 TESTBARKEIT VON ANWENDUNGEN
BEST PRACTICE 8.5.1 TESTPROZESSGRUNDLAGEN FÜR DIE ERSTELLUNG VON SOFTWARE-

PRODUKTEN
• Priorität hat die Verwendung der von SAP vorgesehenen

Erweiterungsmöglichkeiten (BAdIs, User Exits, Custo-

Das Testen von Anwendungen ist ein Werkzeug der Softwarequalitätsmessung60 und
mer Exits, BTEs, Enhancement Points oder Sections). -verbesserung. Es dient u.a. der Überprüfung von funktionalen und nicht funktionalen
• Grundsätzlich sind Workbench-Modifikationen nur unter Produktanforderungen, der Feststellung von Anomalien im Verbrauch von Systemres-
Verwendung des Modifikationsassistenten erlaubt! sourcen und der Sicherstellung einer korrekten Orchestrierung im Rahmen von
zeitlich voneinander abhängigen Prozessschritten. Dabei gilt: Je früher ein Mangel
• Eine Z-Kopie ist u. U. mit sehr hohem Realisierungs- identifiziert und beseitigt werden kann, desto geringer sind die Kosten.
aufwand bzw. Folgekosten verbunden. Darüber
hinausgehen Weiterentwicklungen im Standard Fehlerkorrekturkosten
unberücksichtigt an der Z-Kopie vorbei, d.h. es
Gut veranschaulicht wird die Korrelation zwischen Fehlerkorrektur und deren Folge-
resultiert ebenfalls ein Aufwand für die Anpassung
kosten in der mittlerweile in die Jahre gekommenen, aber vom Grundsatz weiterhin
bzw. Erstellung einer neuen Z-Kopie. Nach dem gültigen Studie von Barry W. Boehm zum Thema „Relativer Aufwand der Fehlerkorrek-
Einspielen von Enhancement Packages können turen des Entwicklungszyklus“ aus dem Jahr 1981. Nach Boehm ist ein in der War-
verwendete Standard-Includes zu Problemen führen. tungs- bzw. Betriebsphase gefundener Fehler bis zu ein 100faches teurer, als wenn er
• Die Entscheidung Modifikation vs. Z-Kopie vs. implizi- in der Analysephase korrigiert worden wäre. In Anlehnung an Balzert61 soll die
nachfolgende Tabelle als exemplarische Orientierungshilfe dienen und verdeutlichen,
tes Enhancement ist nicht nur abhängig vom Realisie- in welcher Phase des Entwicklungszyklus mit welcher Fehlerhäufigkeit zu rechnen ist
rungsaufwand, sondern auch von einem möglichen und wie wahrscheinlich der Fehler entdeckt wird.
Folgeaufwand.
Implemen- Abnahme- Wartung /
• Keine der Möglichkeiten (Modifikation/Z-Kopie/implizi- Phase Analyse Design
tierung
Systemtest
test Betrieb
tes Enhancement) hat nur Vor- oder nur Nachteile. Es
Relativer
ist von Fall zu Fall zu prüfen, welche Technik im kon Aufwand
0,2 0,5 1 2 5 20
kreten Szenario die wenigsten Nachteile mit sich bringt.
Fiktive
• Für jede Art der Erweiterung sollte eine zentrale, for- Korrek- 1€ 2,5€ 5€ 10€ 25€ 100€
turkosten
malisierte, technische Dokumentation erstellt werden.
Dafür sollten geeignete Templates bereitgestellt werden Einge-
brachte 55% 30% 15%
und eine Pflicht zu deren Verwendung bestehen. Fehler
Gefunde-
5% 10% 40% 45%
ne Fehler
WEITERE QUELLEN
1. SAP-Schulungen BC425 und BC427

60 Vgl. https://de.wikipedia.org/wiki/Softwarequalit%C3%A4t#QS-Schwerpunkt_Softwaretest
61 Vgl. Balzert, Softwaremanagement, Spektrum 2008 S. 484ff

Maßnahmen zur Fehlervermeidung
Die Entdeckung von und der Umgang mit Mängeln lässt sich durch den Einsatz
verschiedener Hilfsmittel unterstützen. Angefangen bei der Definition eines Prozess-
modells (z.B. I2M, ITIL, V-Modell) für die Festlegung der Testebenen und Quality Gates,
der Ausrichtung an einem Qualitätsstandard (z.B. SQuaRE, ISO/IEC 9126) zur Definition
von Prüfkriterien, der Verwendung verschiedener Produktentwicklungsmethoden (z.B.
SAP Agile SE, KANBAN, Scrum) für den Umgang mit Fertigungs- und Abnahmekriteri-
en, bis hin zur Einführung eines effektiven Risikomanagements und der Festlegung von
Schutzbedarfsklassen für Anwendungskategorien, ist das Spektrum für den Umgang
mit Tests breit gestreut und von verschiedenen Faktoren abhängig. Hierzu gehören
u.a. die Branchenzugehörigkeit des Unternehmens, gesetzliche Rahmenbedingungen
und die potenzielle Schadensauswirkung der Anwendung auf den Geschäftsprozess.
Teststufen
Bei der Fertigung von Softwareprodukten lassen sich grundsätzlich drei verschiedene Abbildung 4: W-Modell mit Teststufen 61
Testverfahren voneinander unterscheiden:
Typische Vertreter von White-Box-Tests sind Komponenten- und Integrationstests. Die
• White Box Gemeinsamkeit dieser Tests liegt darin, dass die Struktur, Implementierung oder
Reihenfolge der getesteten Softwareartefakte bekannt ist. Die Tests werden in der
• Grey Box Regel im Rahmen der Entwicklung direkt durch das Entwicklerteam auf dem Entwick-
lungssystem erstellt, durchgeführt und weiterentwickelt.
• Black Box
Das Grey-Box-Testverfahren ist dem Akzeptanztest vorangestellt und wird nach
Fertigstellung des Produkts bzw. eines Produktinkrements in Form von Systemtests
durchgeführt. Meistens findet die Erstellung dieser Tests auf einer Produktivsys-
tem-nahen Umgebung durch ein separates Test-Team statt. Die organisatorische
Aufteilung zwischen Grey- und White-Box-Tests hat den Vorteil, dass sich das Entwick-
lungsteam auf seine Kernaufgaben konzentrieren kann. Das Test-Team validiert die
Anwendung aus einer anderen Perspektive und versucht, mögliche Schwachstellen
oder Mängel und deren Ursachen zu identifizieren.
Das Black-Box-Testverfahren betrachtet das fertiggestellte Produkt ohne Kenntnis der

internen Softwarestruktur. Die Testfälle leiten sich aus der Spezifikation und der darin
geforderten Funktionalität ab und dienen als Akzeptanztest zur Abnahme des erstell-
ten Produkts. Die Durchführung der Black-Box-Tests findet auf einer möglichst
produktivsystemnahen Umgebung durch den Auftraggeber statt.
62 In Anlehnung an http://www.informatik.hs-bremen.de/spillner/ForschungSpillnerWmo.pdf

Es gibt zwei Ansätze:
BEST PRACTICE • Auf Quellcode-Ebene: Unit-Tests mit ABAP-Unit

• Achten Sie darauf, dass die definierte Teststrategie zu

• Auf übergeordneter Ebene: automatisierte Funktionstests mit eCATT oder

Ihrer Aufbau- und Ablauforganisation passt, die
Drittanbieterwerkzeugen
Aufgabenverantwortung klar definiert ist, und dass Sie
die Produktivität des Entwicklungsteams nicht durch Vorteile von automatischen Tests:
unnötige organisatorische Schnittstellen hemmen.
• Die Funktionsfähigkeit der Software kann nach Änderungen praktisch ohne
• Legen Sie die Testintensität und den Testumfang in
Zeitaufwand geprüft werden.
Abhängigkeit der im Fehlerfall zu erwartenden Scha-
denshöhe und dessen Eintrittswahrscheinlichkeit fest. • Unit-Tests helfen schon in der Entwicklungsphase bei der Fehlersuche und
Achten Sie darauf, nur die wirklich notwendigen Test- unterstützen den Entwickler bei einem guten Design (Modularisierung, Einfach-
fälle durchzuführen und vermeiden Sie Redundanzen. heit).
• Involvieren Sie den Auftraggeber frühzeitig in die Nachteile von automatischen Tests:
Definition von Testfällen. Bereits während der Anfor-
derungsdefinition sollte ein grobes Testszenario zur • Nach Änderungen müssen teilweise bestehende Tests inklusive Testdaten
Validierung der Anforderung zusammen mit dem angepasst werden.
Auftraggeber festgehalten werden. Als positiver
Nebeneffekt ergibt sich häufig eine bessere Pro- • Das sollte bei Unit-Tests bei guter Modularisierung eher selten nötig sein.
duktspezifikation. Die zunächst grobe Beschreibung
• Bei automatisierten Funktionstests hängt es davon ab, ob sich die Änderun-
der Testfälle aus der Anforderungsdefinition lässt gen „in der Tiefe“ bis auf die getestete Ebene auswirken. Problematisch sind
sich in den weiteren Entwicklungsphasen verfeinern. meist Änderungen der Oberfläche, da die Tests in der Regel hierüber
angesteuert werden und dann die Ansteuerung angepasst werden muss.
• Initialer Mehraufwand
8.5.2 TESTAUTOMATISIERUNG • Eventuell aufwändige Umsetzung, z.B. bei Unit-Tests, wenn Datenbank-Aufrufe
nicht gekapselt sind.
Eine Testautomatisierung eignet sich für alle Bereiche, in denen regelmäßig eine Folge
von manuellen Arbeitsschritten durchgeführt werden muss, um das korrekte Verhal- Diese Kontexte sprechen besonders für den Einsatz von Unit-Tests:
ten einer Funktionalität zu überprüfen. Die Entscheidung, welche Aktivitäten zu
automatisieren sind, sollte von der Risikokategorie, dem Komplexitätsgrad, der • Häufige Anpassungen der Software sind zu erwarten
Ausführungshäufigkeit und der Relation von manuellen Kosten gegenüber den Auto-
matisierungskosten abhängig sein. Automatisierte, wiederholbare Tests können sehr • Softwareteile, die vermutlich wiederverwendet werden
effizient sein.
• Komplexe Funktionalität
• SAP-NetWeaver-Softwarestand

• Hilfsmittel Test-Doubles ab SAP NetWeaver 7.40 SP9 verfügbar Wenn dieser Anwendungskern z.B. nicht mehr direkt mit der Datenbank kommuniziert,
bietet sich die Möglichkeit, für die Durchführung von Unit-Tests die Datenkonstellationen
• Alternativ gibt es das Open-Source-Werkzeug MockA63, das für zu simulieren. Hierfür sind insbesondere die oben erwähnten Testdoubles sinnvoll.
Releases ab SAP NetWeaver 7.01 verfügbar ist
Auch für automatisierte Funktionstests kann die Trennung der Schichten manchmal
• Hilfsmittel Test-Seams ab SAP NetWeaver 7.50 verfügbar hilfreich sein, der Fokus bei eCATT liegt allerdings auf der Ansteuerung über SAP GUI.
Diese Kontexte sprechen eher gegen den Einsatz von Unit-Tests:
• Klassen, deren Zweck der Datenbankzugriff ist („Datenbankschicht“, „Model“ im BEST PRACTICE
Model-View-Controller-Muster), und die keine komplexe Logik beinhalten. • Nutzen Sie für die Entscheidung, welche Prozesse für
automatisierte Regressionstests in Frage kommen,
• Klassen, deren Zweck die Ansteuerung und Kommunikation mit der Oberfläche
ist („View“ im Model-View-Controller Muster), und die keine komplexe Logik
die im SAP System zur Verfügung stehenden Auf-
beinhalten. rufstatistiken (Transaktionsstatistik via ST03N /
Usage Procedure Logging).
• Existierende Software mit schlechter Modularisierung (vor allem, wenn Test- • Starten Sie bei der Einführung von Unit-Tests bzw.
Seams noch nicht verfügbar sind, siehe oben)
automatisierten Funktionstests mit einem kleinen
engagierten Team. Dessen Erfahrungen und Erfolge
lassen sich als Erfolgsgeschichten bei der weiteren
Einführung des Themas in Ihrer Organisationseinheit
BEST PRACTICE nutzen. Hierbei ist es wichtig, dass das Team von
• Erwägen Sie den Einsatz von automatisierten Tests. seiner Tätigkeit überzeugt ist und anhand von Bei-
• Bauen Sie Kompetenz in diesem Bereich auf. spielen den Nutzen dieser Tätigkeit belegen kann.
Im ABAP-Umfeld ist in vielen Fällen die Integration der Datenbank oder der Oberfläche WEITERE QUELLEN
ein Hindernis, wenn es um die Erstellung von wiederholbaren, automatisierten Tests
geht. Für Unit-Tests liegt die Lösung in der ohnehin sinnvollen Modularisierung. 1. http://www.testbarkeit.de
2. http://de.wikipedia.org/wiki/Testbarkeit
BEST PRACTICE 3. http://www.testbarkeit.de/Publikationen/TAE05_Artikel_jungmayr.pdf

Trennen Sie in Ihren Anwendungen die direkte Interaktion 4.
A BAP-Unit-Tests
mit der Datenbank, der Benutzeroberfläche und entfern-
ten Systemen von dem eigentlichen Anwendungskern. 5. ABAP Test Double Framework
6. A BAP Test Double Framework vs. mockA
63 siehe https://github.com/uweku/mockA 7.
Test-Seams and Injections

9 ECLIPSE-ENTWICKLUNGSUMGEBUNG (z.B. Anlegen von Erweiterungen), werden die SAP GUI-Transaktionen nahtlos in ADT
9. ECLIPSE-ENTWICKLUNGSUMGEBUNG
eingebettet aufgerufen. Mittelfristig wird sich eine Notwendigkeit zum Umstieg auf
In der Vergangenheit fanden Entwicklungen im SAP-Umfeld ausschließlich in den ADT ergeben.
ABAP-Workbench-Werkzeugen statt (SE80). Im Rahmen der neuen Technologien sind
in den letzten Jahren weitere Entwicklungswerkzeuge wie zum Beispiel die SAP Web
IDE (SAP-UI5-Entwicklung im Browser) oder das SAP HANA Studio (Eclipse-basierte
Umgebung für die Administration und native Entwicklung auf/mit HANA)64 entstanden. 9.3 VORTEILE
Für die ABAP-Entwicklung steht mit den ABAP Development Tools (ADT) für Eclipse
seit AS ABAP 7.31 SP4 der Nachfolger zur ABAP-Workbench zur Verfügung. ADT Die Vor- und Nachteile, die sich aus der Verwendung von ADT ergeben, hängen
basiert auf der Entwicklungsumgebung Eclipse erweitert um entsprechende Plug-ins maßgeblich von der individuellen Arbeitsweise als auch vom konkreten Projektumfeld
für die Entwicklung in ABAP. ab. In den folgenden Abschnitten haben wir die aus unserer Sicht wichtigsten Vor- und
Nachteile bei der Arbeit mit ADT aufgeführt. Eine gute Übersicht über die mit ADT
insgesamt verfügbaren Funktionen bietet [1] sowie das FAQ-Dokument zu ADT [7].
9.1 VORAUSSETZUNGEN UND INSTALLATION ADT-Arbeitsplatz
Wie bereits oben erwähnt ist mindestens Release AS ABAP 7.31 SP4 und Kernel 7.21 Bei der Arbeit mit ADT ist man beim Editieren von ABAP-Quellcode nicht mehr an SAP
notwendig, um die ADT für Eclipse einsetzen zu können. Der in ADT verfügbare GUI-Modi gebunden. Das heißt, es können viele Sourcen gleichzeitig geöffnet sein und
Funktionsumfang ist jedoch nicht nur von der verwendeten ADT-Version abhängig diese bleiben auch nach Ab-/Anmeldung in exakt gleicher Form erhalten. ADT-Links
sondern auch von der verwendeten AS-ABAP-Version. Eine ständig aktualisierte ermöglichen es zeilengenau Links zu Stellen im ABAP-Quellcode zu erstellen und zu
teilen (siehe [3]). Weiterhin ermöglicht es das Eclipse-Tool Mylyn, den ADT-Arbeitsplatz
Übersicht über die mit den verschiedenen AS-ABAP-Versionen verfügbaren Funktio- und die geöffneten ABAP-Quellcodes anhand von Aufgaben (z.B. aus einem Ticketsys-
nen ist unter [1] im SCN verfügbar. tem) zu organisieren (siehe [4]).
Im Gegensatz zur ABAP-Workbench ist für ADT eine zusätzliche Installation auf dem Konfigurierbarkeit des ADT-Arbeitsplatzes
Arbeitsplatz des Entwicklers notwendig. Eine aktuelle Installationsanleitung für ADT
ist unter [2] verfügbar. Eclipse und somit auch ADT ermöglicht es, den Arbeitsplatz flexibel zu konfigurieren.
So ist es durch Drag and Drop einfach möglich, Views zu vergrößern oder die Position
Alternativ zu dieser Anleitung ist je nach Firmengröße eine Alternative, ein Grundpaket bestimmter Views zu ändern. Weiterhin ermöglicht das Verknüpfen von Views, dass
(Eclipse IDE + ADT) über den Standardverteilungsmechanismus verfügbar zu machen z.B. im View der ABAP-Dokumentation immer die Dokumentation zum aktuell ausge-
und lokal nur das Update auf die aktuelle Version zu machen (über SAP-Updatesite wählten Schlüsselwort angezeigt wird.
oder hausintern).
Editorfunktionen
Der Editor selbst bietet eine Reihe zusätzlicher Funktionen, die die Entwicklereffizienz
9.2 NOTWENDIGKEIT erhöhen:
ADT für Eclipse ist der von SAP designierte Nachfolger der ABAP-Workbench. Neue • Laufende Syntaxprüfung (nicht erst bei manuellem Aufruf wie in der SE80 per
Objekttypen wie z.B. ABAP Core Data Services (CDS) können mit der ABAP-Workbench Knopfdruck im Editor)
(SE80 oder anderen SAP GUI-Transaktionen) nicht mehr bearbeitet werden, da sich
diese nur noch in der Wartung befindet. Zusätzlich wächst der Funktionsumfang von • Quickfix-Funktionen: das System schlägt Möglichkeiten vor, wie der aktuelle
ADT mit jedem Release. Für verbliebene, noch nicht in ADT implementierte Funktionen Syntaxfehler behoben werden kann (z.B. halbautomatisches Anlegen einer neuen
Methode mit den verwendeten Parametern)
64 Dies stellt keine Empfehlung für das HANA Studio zur Entwicklung nativer HANA-Anwendungen dar.

• Fundstellen zu Syntax- oder ATC-Prüfungen werden im Editorfenster gekenn- 9.4 ZU BEACHTENDE PUNKTE
zeichnet und die zugehörigen Meldungen können per Mouse-Over angezeigt

werden Neben den oben genannten Vorteilen existieren bei der Arbeit mit ADT für Eclipse
jedoch auch einige Nachteile.
• Code Element Information: Pop-ups mit Information zu im Code verwendeten
Entwicklungsobjekten Einstiegs- und Umstiegshürde
• ABAP-Doc als integrierte Dokumentationsmöglichkeit Der Einstieg in jedes neue Werkzeug ist mit einer initialen Ein- bzw. Umgewöhnungs-
phase verbunden. Insbesondere erfordert der Umstieg von der ABAP-Workbench auf
Refactoring-Funktionen ADT auch die Gewöhnung an ein neues Entwicklungsparadigma. Während in der
ABAP-Workbench formularbasierte Editoren überwiegen (z.B. für Klassen und
ADT bietet eine ganze Reihe von automatisieren Refactoring-Funktionen. So ist es Methoden), verwendet ADT überwiegend Quellcode-basierte Editoren. So ist zusätzlich
möglich, eine Variable und alle ihre Verwendungen umzubenennen oder nicht verwen- zu dem neuen Werkzeug auch die Gewöhnung an eine neue Form der Bearbeitung des
dete Variablendeklarationen automatisch zu entfernen. Komplexere Refactoring-Funk- Quellcodes notwendig. Dieser Umstand stellt aus unserer Erfahrung eine nicht zu
tionen erlauben die automatisierte Extraktion einer Methode oder eines Attributs. unterschätzende Einstiegshürde dar.
Verbesserte Laufzeitanalyse Schlussendlich wird man jedoch nach dem Umstieg schnell feststellen, dass ein
Sourcecode-basiertes Arbeiten deutlich effizienter ist.
Die in ADT integrierte Laufzeitanalyse (siehe [5]) ermöglicht es, ABAP-Traces graphisch
zu visualisieren. Diese Visualisierung erlaubt es sehr einfach, performancekritischen Fehlende Spezialtransaktionen
Quellcode zu identifizieren und zu optimieren.
ADT unterstützt nicht alle Spezialtransaktionen, die über die SAP GUI verfügbar sind.
Verbesserte Versionshistorie Obwohl der Funktionsumfang von ADT stetig erweitert wird (z.B. um Modellierungs-
funktionen für BOPF), werden auch in Zukunft nie alle Spezialtransaktionen in ADT
Die in ADT integrierte Versionshistorie kann remote über Systeme hinweg verwendet umgesetzt werden. Diese können zwar über die SAP GUI Integration innerhalb von ADT
werden und hat auch eine lokale (arbeitsplatzbezogene) Historie und ermöglicht so aufgerufen werden. Jedoch ist die Verwendung über die SAP GUI-Integration nicht
eine maximale Flexibilität. immer ideal. So ist zum Beispiel das Arbeiten mit den SAP-CRM-WebUI-Tools in ADT
nicht immer konsistent. Bestimmte Objekte in den SAP-CRM-WebUI-Tools werden zur
SQL-Tools Bearbeitung in der ABAP-Workbench geöffnet, während andere Objekte in den
ADT-Editoren geöffnet werden.
In ADT haben sich auch die klassischen Werkzeuge des Entwicklers im SQL-Bereich
neu erfunden. Zum Beispiel steht eine SQL-Konsole als auch eine integrierte Da-
ta-Preview-Funktion zu Verfügung.
9.5 PROBLEME UND HILFESTELLUNGEN FÜR DEN UMSTIEG
Erweiterbarkeit
Die ersten Tage der Arbeit mit ADT werden aus der Erfahrung heraus etwas holprig.
Da es sich bei Eclipse um eine offene Plattform handelt, ist diese sehr flexibel erwei- Insbesondere die freie Konfigurierbarkeit der Entwicklungsumgebung und das
terbar. So stehen zum einen SAP-Tools zur Verfügung. Zum anderen ist ADT auch mit Quellcode-basierte Entwicklungsparadigma stellen für erfahrene SAP-Entwickler ein
existierenden Tools aus dem Eclipse-Ökosystem erweiterbar. Zusätzlich ist für ADT ein Hindernis dar. Sie werden im ersten Moment nicht als nennenswerter Vorteil wahrge-
SDK (Software Development Toolkit) verfügbar (siehe [6]), das es ermöglicht, ADT um nommen. Vielmehr werden sie als unnötige Veränderung ohne Mehrwert erlebt. Dies
eigene Funktionen zu erweitern. Zusätzlich dazu wird auch eine SAP-Codejam zu ändert sich aber nach Überwindung der Einstiegshürde und die Entwicklungseffizienz
diesem Thema angeboten. nimmt zu.

Trotz der Möglichkeit, alle Tastenkürzel zu ändern, empfehlen wir, sich an die Stan- 9.7 WEITERE QUELLEN
dardkürzel zu gewöhnen. So wird für unterschiedliche Arbeitsplätze und Remote-

Arbeitsumgebungen nicht unnötig „Einstellungsarbeit“ generiert. [1] ABAP in Eclipse Feature Matrix
Auch ist es ein Problem, wenn für mehrere Systeme mit unterschiedlichen Release- [2] ABAP in Eclipse Installationsanleitung
Ständen in ADT entwickelt werden soll. In diesem Fall kann es vorkommen, dass
bestimmte Funktionen nicht in allen Systemen verfügbar sind (vergleiche [1]). [3] How ADT links change the way you work
Falls man eine größere Anzahl an Entwicklern im Unternehmen hat, hat es sich [4] Use mylyn tasks to organize your ABAP in Eclipse workspace
bewährt, die Einführung von ADT mit einer Schulung beziehungsweise mit einer
Vorstellung des Werkzeugs zu beginnen (Begrifflichkeiten und Grundeinstellungen). [5] ABAP Profiling in Eclipse
Alternativ ist in ADT der sogenannte „Feature Explorer“ integriert. Der Feature Explo- [6] First version: SDK for ABAP development tools
rer ist eine Art Lerntutorial für das Selbststudium, der die grundlegende Arbeitsweise
mit ADT erklärt. Hier wird beispielsweise gezeigt, wie man ein Entwicklungssystem in [7] FAQs zu ADT
ADT oder mit Hilfe der Refactoring-Werkzeuge Teile einer Methode extrahieren kann.
[8] BOPF Modelling in ADT
Eine weitere Möglichkeit für den Einstieg ist, an einem SAP-Codejam für ABAP in
Eclipse teilzunehmen.65 [9] ADT Feature Explorer
[10] Get Started with the ABAP-Development-Tools for SAP NetWeaver
9.6 FAZIT
Die Vorteile von ADT überwiegen spätestens seit Release 7.40 die Nachteile. Der
Umstellungsaufwand ist überschaubar (allerdings je nach Lernmotivation und -fähig-
keit verschieden). Insbesondere wird die Umstellung jüngeren Mitarbeiterinnen bzw.
Mitarbeitern, die in Entwicklungsumgebungen außerhalb der ABAP-Workbench
gearbeitet haben, leichter fallen.
BEST PRACTICE
Wir empfehlen aus unserer Erfahrung die Verwendung
von ADT ab AS ABAP Release 7.31 SP6.
65 Vgl. http://scn.sap.com/community/events/codejam

10 USER INTERFACE (UI) UI-Technologie SAP-Roadmap Kommentar
Empfehlung für
Neuentwicklungen
10.1 UI-TECHNOLOGIEN IN DER PRAXIS SAP rät von Neuent-
wicklungen ab.
10. USER INTERFACE (UI)
UI-Technologien spielen eine immer wichtigere Rolle in Entwicklungsprojekten. Aus Geringer Entwick-
diesem Grund möchten wir auch in diesem Kapitel darauf eingehen. lungsaufwand, vor Für kleinere
allem bei einfachen Entwicklungen in
Dynpro (klassisch) nur noch Support
Reports mit gene- vielen Fällen
Der Fokus des UI-Kapitels liegt auf den „neuen“ SAP-UI-Technologien, da wir in den riertem Selektions- weiterhin sinnvoll
SAP-Produkten einen klaren Trend zu SAPUI5 als UI-Framework und SAP Fiori als bild.
zentralen Einstieg in die SAP-Welt sehen. Bei Power-Usern
beliebt.
Dennoch bewerten wir z.B. Web Dynpro oder klassisches Dynpro als wichtige UI-Kom- Business Server Durch Web Dynpro
ponenten in der SAP-Welt. Für diese schon lange etablierten Technologien gibt es bei nur noch Support Nicht sinnvoll
Pages (BSP) abgelöst
vielen SAP-Kunden bereits Empfehlungen und auch ein breites Grundwissen.
Für klassische
Im CRM auf Basis der
CRM-Apps weiterhin
Um sich einen ersten Überblick über die verschiedenen UI-Technologien zu verschaf- BSP-Technologie
WebClient UIF nur noch Support relevant. SAP Hybris
entwickelt und im
fen, empfiehlt sich der EA Explorer66 der SAP. Dort findet man einen guten Einstieg in C4C setzt hier auf
Einsatz
verschiedene Aspekte von User Interfaces. In diesem Leitfaden sind die wichtigsten SAPUI5/SAP Fiori
UI-Technologien in der nachfolgenden Tabelle aufgelistet. Die Tabelle beschränkt sich Sollte nicht mehr
auf einen Überblick sowie einer kurzen Bewertung zum jeweiligen Gebrauch bei (Neu-) Web Dynpro Java nur noch Support Nicht sinnvoll
verwendet werden
Entwicklungen.
In Kombination mit Sinnvoll für größere
Web Dynpro ABAP
Kleinere Erweiterun- Floorplan Manager Neuentwicklungen.
inkl. Floorplan
gen weniger aufwändig Auch SAPUI5 in
Manager
als Standalone. Erwägung ziehen.
Konfiguration und
Scripting (Java-
Script), um existie- Für UI-Überarbeitung
Kleinere Erweiterun- rende Anwendungen existierender
SAP Screen Personas
gen auf Basis klassischer Dynpro-Programme
Dynpros attraktiver sinnvoll.
und besser bedienbar
zu machen
Sinnvoll. Siehe Vor-/
SAPUI5 Strategisch Nachteile im
Folgenden
Derzeit ist SAPUI5 die favorisierte UI-Technologie moderner SAP-Anwendungen.

Nichtsdestotrotz ist ein Abwägen über die zu verwendende UI-Technologie zu Beginn
von Entwicklungsprojekten ratsam. Folgende Gegenüberstellung der Vor- und Nach-
teile soll bei der Entscheidung bzgl. des Einsatzes von SAPUI5 helfen.
66 SAP EA Explorer

Vorteile SAPUI5 Nachteile SAPUI5 10.2 SAPUI5
∙ Umfassende Sammlung von Stan- ∙ JavaScript erforderlich (ABAP nur im
Im Rahmen der SAP-User-Experience-Strategie68 wird mit SAPUI5 ein modernes
dard-GUI-Elementen, die die Implementie- Backend). Daher eventuell Skill-Aufbau
rung stark vereinfachen notwendig. Toolkit für HTML5 basierte Entwicklungen zur Verfügung gestellt. Mit SAPUI5 entwi-
ckelte Anwendungen zeichnen sich dadurch aus, dass sie eine responsive Web-Ober-
∙ Modernstes Aussehen ∙ S AP Gateway erforderlich (bei der empfoh-
fläche sowohl auf dem Desktop-Browser als auch auf mobilen Endgeräten zur Verfü-
lenen separaten Installation zusätzliche
∙ T heoretisch ist alles möglich, was HTML5 in gung stellen.
Kosten)
Verbindung mit JavaScript erlaubt
∙ In Spezialfällen u. U. fehlende Features und
∙ Nutzung auf Tablets und Smartphones Unter dem Namen OpenUI569 wird SAPUI5 auch unter einer Open-Source-Lizenz
schlechtere Performance gegenüber SAP
∙ Kein Client zu installieren GUI / ALV (Apache 2.0) vertrieben. Hierbei sind allerdings einige Komponenten wie Diagramme
und Smart Controls nicht in der Distribution enthalten.
∙ Responsive UI (Automatische Anpassung an ∙ Relativ neue Technologie, daher Probleme
das jeweilige Endgerät) beim Einsatz der Tools und als Endprodukt
möglich Aktuell realisierte Anwendungen sollen dabei nach den SAP Fiori Design Guidelines70
∙ Nutzung der Endgerätfähigkeiten wie z.B.
realisiert werden, um eine optimale Multi Device User Experience zu gewährleisten
Kameras ∙ Komplexe Apps erfordern mehr Aufwand
und sich in das „Look and Feel“ von SAP-Anwendungen zu integrieren. In SAPUI5 sind
∙ Native SAP-Fiori-Launchpad-Integration (Stateless Apps)
aus den Anfängen der Bibliothek noch rein Desktop orientierte Komponenten enthalten
∙ Relativ neue Technologie, daher optimale (sap.ui.commons), die aber nicht mehr verwendet werden sollten (deprecated).
Integration in aktuelle Web-Browser
10.2.1 ANFORDERUNGEN
SAP Fiori bezeichnet die neue User Experience (UX) aktueller Lösungen der SAP, die
auf Basis moderner Design-Prinzipien entstanden sind. Das Thema SAP Fiori werden Für den Einsatz von SAPUI5 wird im Frontend ein unterstütztes Endgerät benötigt, das
wir im Kapitel SAPUI5 nur ansatzweise behandeln, da die darunterliegenden Technolo- von SAP innerhalb der SAP NetWeaver 7.5 Browser Support PAM71 unterstützt wird.
gien in der On-Premise-Welt aktuell SAPUI5 und SAP Gateway sind. Auf das Thema
HANA Cloud Platform (HCP) wird in dem UI-Teil nicht explizit eingegangen, da sich der
SAPUI5 Teil nicht groß von der On-Premise-Welt unterscheidet und sich die Best
Practices von der On-Premise-Welt fast eins zu eins übernehmen lassen.
Auch das Thema Design Thinking bekommt in den letzten Jahren einen immer größe-
ren Stellenwert im Bereich UX und sollte für einen voll umfänglichen End-to-End-Pro-
zess ebenfalls betrachtet werden.
Eng mit dem Design Thinking ist auch das Thema Mock-up verknüpft. Hier gibt es
schon etablierte Tools, in denen es fertige SAP Fiori Design Stencils67 gibt, die das
SAP Fiori UX Pattern abbilden. Ein neues Produkt von SAP in diesem Bereich ist
Splash / BUILD, aber Stand Sommer 2016 ist dieses Produkt noch in der Beta-Phase Abbildung 5: SAP NetWeaver 7.5 Browser Support PAM
und es gibt erst wenige Erfahrungen dazu.
68 SAP-User-Experience-Strategie (UX)
69 OpenUI5-Homepage
70 SAP Fiori Design Guidelines
67 SAP Fiori Design Stencils 71 SAP NetWeaver 7.5 Browser Support PAM

SAPUI5 ist von hoher strategischer Bedeutung und ist Bestandteil innerhalb der
Auslieferung von folgenden SAP-Systemen:
BEST PRACTICE
• SAP NetWeaver AS ABAP (z.B. SAP Business Suite oder SAP Gateway) • Wir empfehlen für die SAPUI5-Entwicklung (Stand
Ab NetWeaver Version 7.40 sind sowohl UI- als auch SAP-Gateway-Komponenten

2016) den Google Chrome Browser zu verwenden.
Bestandteile des SAP NetWeaver. In vorherigen Versionen können sie teilweise
als Add-on nachgerüstet werden. SAP liefert mit dem UI5-Inspector72 (Google Chrome
Extension) ein Tool aus, auf das man nicht mehr
• SAP HANA verzichten möchte. In der SAP Web IDE unterstützt
SAP HANA liefert eine Version des SAPUI5 SDKs passend zum HANA SP aus (XS der Layout-Editor Stand 2016 nur Google Chrome. Der
Classic). Ab SPS 11 und XS Advanced muss derzeit noch das SDK via CDN Endanwender kann die entwickelten Anwendungen
eingebunden werden. mit allen gängigen Browsern und Devices verwenden,
sofern diese laut PAM unterstützt werden.
• SAP HANA Cloud Platform (HCP)
Die SAP HCP bietet die Möglichkeit SAPUI5 und Fiori-Apps zu entwickeln und stellt • Jedes der oben genannten Systeme unterstützt neben
mit der SAP Web IDE eine Entwicklungsumgebung für SAPUI5 zur Verfügung. dem SAPUI5 SDK auch das SAP Fiori Launchpad
(FLP). Über FLP können rollenbasiert SAPUI5-An-
• SAP Enterprise Portal (EP)
wendungen gestartet werden, wenn diese nach den
Die SAP Web IDE ermöglicht das direkte Deployment einer SAPUI5-Anwendung in
das Portal als iView. SAP Fiori Design Guidelines konzipiert wurden und
eine eigenständige Komponente implementieren.
Alle Systeme stellen außerdem ein SAP Fiori Launchpad (FLP) zur Verfügung, aller-
dings in unterschiedlichen Ausbaustufen.
72
10.2.2 ENTWICKLUNG
SAP folgt und unterstützt bei der modernen UX-Entwicklung den Ansatz des Design
Thinkings73, der sich bei der Entwicklung neuer Prozesse und Benutzeroberflächen
nutzen lässt. Design Thinking umfasst die drei Phasen Discover, Design und Deliver.
Abbildung 6: Phasen des Design Thinkings
72 UI5-Inspector (Google Chrome Extension)

73 Wikipedia Definition Design Thinking

10.2.2.1 Discover
Im Rahmen der Discovery-Phase wird versucht, das aktuelle Kundenproblem zu BEST PRACTICE
verstehen und kreativ im Team einen Prozess zur Lösung herauszuarbeiten. Die • Die Anwenderzielgruppe sollte möglichst frühzeitig in
Lösung beschreibt dabei einen konkreten Arbeitsablauf für eine definierte Zielgruppe.
den Prozess des Prototyping involviert werden, da das
Design einer Anwendung genau auf die Anforderung
und Arbeitsweise des Anwenders ausgerichtet wird.
10.2.2.2 Design Auch die Akzeptanz wird so gesteigert, da die Ziel-
gruppe in die Design-Phase integriert wurde und das
Innerhalb der Design-Phase wird mit der Zielgruppe ein Prototyp skizziert, der den Design miterarbeitet hat.
bestmöglichen Arbeitsablauf zur Erreichung der Anforderung aus der Analyse abbil-
den soll. • In gemeinsamen Workshops kommt man immer noch
am schnellsten mit dem Whiteboard zu allgemeinen
Je nach Know-how und Zielgruppe können folgende Tools verwendet werden: Ergebnissen. Der SAPUI5-Explorer77 sowie die SAP
Fiori Demo Cloud78 sind dabei hilfreiche Werkzeuge,
• Papier und Stift um neuen Anwendern das Thema SAPUI5 näherzu-
Immer noch die einfachste Variante, Ideen festzuhalten.
bringen.
• Whiteboards / Whitewalls • Stand 2016 haben Splash und BUILD noch einige
Die exklusive Papier und Stift Variante. Macken, die teilweise eine produktive Verwendung
inkl. der Code-Übernahme verhindern.
• SAP Splash and BUILD
Die SAP stellt mit Splash und BUILD74 ein Browser-basiertes Tool zur Verfügung, • Der openSAP-Kurs „Build Your Own SAP Fiori App in
mit dem via Drag & Drop Prototypen erstellt werden können, die sich an SAPUI5/ the Cloud – 2016 Edition79“ bietet einen umfassenden
SAP Fiori Vorlagen orientieren und auch dessen Widgets enthalten. Ein Einstieg und Überblick für das Thema SAP Fiori UX.
BUILD-Prototyp kann zur weiteren Entwicklung in die SAP Web IDE importiert
werden75.
• SAP Web IDE

Die SAP Web IDE76 ist eigentlich ein Werkzeug für die Entwicklung und das
Deployment von SAPUI5-Anwendungen. Stand 2016 verfügt sie aber mit dem
Layout-Editor auch über die Möglichkeit, UIs via Drag & Drop zu erstellen.
Zusätzlich können hier Mock-up-Daten hinterlegt werden, sodass ein funktional
erweiterter Prototyp inkl. Testdaten online zur Verfügung gestellt werden kann,
ohne dass vorab Daten-Services entwickelt werden müssen.
74 SAP Splash and BUILD (Design Great UX in the Cloud)

75 Kickstart your Fiori Web IDE project with Splash and BUILD
76 SCN – SAP Web IDE – Quickstart

10.2.2.3 Deliver
Wurde im Rahmen des Prototypen-Designs ein entsprechender Prototyp verabschiedet, BEST PRACTICE
kann dieser nun in eine SAPUI5-Anwendung überführt werden. • Die Empfehlung durch den SAP Fiori 2.0 Guide ist,
SAPUI5 User Interfaces mit der SAP Web IDE zu

Werkzeuge
entwickeln und für SAP Backend Services Eclipse
Die SAP unterstützt die SAPUI5-Entwicklung mit den folgenden Werkzeugen: ADT zu verwenden, da für Core Data Services (CDS)
auch kein Support im SAP GUI existiert (Stand 2016).
• SAP Web IDE (in der Cloud)
• Die SAP Web IDE bietet die umfassendsten Tools und
Bei der SAP Web IDE handelt es sich um das favorisierte Tool der SAP, das in der
SAP HCP angeboten wird. Neben einer gratis Testversion (für nicht produktive Möglichkeiten zur SAPUI5-Entwicklung in der Cloud.
Zwecke empfohlen) gibt es Stand 2016 auch eine schmale Einsteigervariante80 für Für das Testen gegen einen OData Service auf dem
5 benannte Entwickler. Die IDE unterstützt den kompletten Vorgang vom Prototy- SAP Gateway (http Destination) und das Deployment
ping inkl. grafischem Layout-Editor bis hin zum Deployment in die Cloud, auf das wird zusätzlich der SAP HANA Cloud Connector
SAP-System (bei Verwendung des SAP HANA Cloud Connector), oder in das benötigt, der über den Internet-Proxy einen Tunnel
SAP-Portal (bei Verwendung des entsprechenden SAP Web IDE Plugins). und damit eine Vertrauensstellung zur SAP Cloud
aufmacht. Im SAP Cloud Connector können dann
• SAP-Development-Tools für Eclipse
Alternativ zur SAP Web IDE kann eine Eclipse-basierte Umgebung genutzt noch freigegebene SAP-Systeme und -Services
werden, bei der sich die benötigte SAPUI5-Funktionalität über die SAP-Develop- autorisiert werden.
ment-Tools für Eclipse81 nachrüsten lassen. Innerhalb von Eclipse wird dann lokal • Ist die Verwendung des Cloud-Connectors nicht
entwickelt und getestet. Die fertige SAPUI5-Anwendung/Komponente kann direkt
möglich, kann die mit der SAP Web IDE entwickelte
auf das SAP-System deployed werden (ab AS ABAP 7.31 mit Team-Provider-Add-on).
Das Plug-in befindet sich derzeit bei der SAP in Wartung, d.h. es findet keine
App exportiert (ZIP Datei) und anschließend via
Weiterentwicklung mehr statt. Kompatibilitäts-Updates werden noch ausgeliefert. Eclipse ADT oder über den Report „/UI5/UI5_REPOSI-
TORY_LOAD“ in das ABAP-System deployed werden.
• Alternativ kann Eclipse mit den entsprechenden Tools
verwendet werden. Man muss dann allerdings auf
graphische Editoren (WYSIWYG Layout-Editor),
Templates und SAP-Fiori-Extension-Support82 ver-
zichten.
Test
Das SAPUI5 SDK stellt Funktionalitäten für den Unit- und Komponententest zur
77 SAPUI5 Explored (UI Explorer) Verfügung, über die die Testfälle weitestgehend automatisiert werden können.
78 SAP Fiori Demo Cloud
79 openSAP Kurs „Build Your Own SAP Fiori App in the Cloud – 2016 Edition“
80 SAP Web IDE Einsteigervariante für 5 Entwickler
81 SAP-Development-Tools für Eclipse 82 SAPUI5 Extension using component configuration

BEST PRACTICE
• Jeder SAPUI5-Entwickler sollte vor einem Projekt
den Developer Guide (Bestandteil des SAPUI5-De-

mo-Kit) durchgearbeitet haben. Insbesondere das
Walkthrough Tutorial demonstriert die grundsätzliche
Anwendung zentraler Funktionalitäten.
• Bei der Entwicklung können oft Code-Beispiele aus
der Explorer-App direkt in das eigene Coding über-
nommen und dort angepasst werden.
• Eine nach den SAP Fiori Guidlines orientierte Ent-
wicklung setzt auf die sap.m Bibliothek auf. Die
Komponenten der sap.ui.commons sind deprecated,
d.h. auf die Verwendung sollte nach Möglichkeit
Abbildung 7: Unterstützte Testphasen in SAPUI5 verzichtet werden. Die hier aufgeführten Controls
sind in neuerer Form weitestgehend in den
sap.m-Komponenten redundant enthalten.
SDK
Alle relevanten Informationen rund um die SAPUI5-Entwicklung finden sich im

SAPUI5-Demo-Kit83. Hierbei handelt es sich um eine von SAP bereitgestellte Samm-
lung von Wissen rund um das Thema SAPUI5. Schnittstellen
Für die Kommunikation der SAPUI5-Anwendung mit einem SAP-Backend-System

(AS ABAP) wird dem SAP Gateway ein Werkzeug zur Verfügung gestellt, das als
Service-Provider sowohl die benötigten OData Rest Services als auch das SAPUI5 SDK
anbietet. Die Service-Implementierung erfolgt dabei mit Hilfe von ABAP Objects.
Innerhalb des SAPUI5-Frameworks erfolgt die Service Kommunikation i.d.R. über ent
sprechende Datenmodelle. Je nach Anwendungszenario existieren hierzu folgende Modelle:
• OData84
Das OData-Model definiert Datentypen und Strukturen und erlaubt einen
REST-basierten Zugriff auf Backend-Systeme. Das SAP Gateway unterstützt
OData über entsprechende Services und ab NW 7.40 über Core Data Services
(CDS). Ab NW 7.50 kann der CDS direkt über eine Annotation als OData Servcie
verfügbar gemacht werden, vorher muss dieser noch manuell in der SEGW
angelegt werden werden.
83 SAPUI5-Demo-Kit 84 OData-REST-Spezifikation

• JSON 10.2.3 GENERELLE EMPFEHLUNGEN
Datenaustausch über Standard-JSON-Strukturen über http(s) Aufrufe. Im
AS-ABAP-System kann hierzu der JSON-RPC-Service genutzt werden, oder ein • Neue Implementierungen sollten sich immer an den SAP Fiori Design Guide-
HTTP-Handler. lines 85 orientieren und die sap.m Library verwenden. Nur hier ist gewährleistet,
dass man nicht auf sogenannte „deprecated“-Komponenten setzt, die nicht mehr
• XML weiterentwickelt werden und irgendwann aus der Library entfernt werden
Datenaustausch über XML-Strukturen. Der AS-ABAP-Server stellt hierzu könnten.
XML-Transformationen zur Verfügung.
• Für das UI-Design sollten ausschließlich XML-Views verwendet werden, da nur
Zusätzlich zu den Modellen, die einen Request-basierten Zugriff auf Backend-Systeme diese von Tools wie dem SAP Web IDE unterstützt werden. Das SAPUI5 Extension
ermöglichen, existiert mit der WebSocket api eine weitere Technologie: Framework unterstützt nur XML-Views im Rahmen der Erweiterung von SAP-Fiori-
Apps.
• WebSocket
Push-Service-Technologie, über die ein Backend-System aktiv Daten an den • Die Bibliothek sap.ui.commons beinhaltet Komponenten, die nicht Bestandteil des
Client pushen kann. Hierzu kann das SAP-spezifische SAP Push Channel Protot- SAP Fiori Design Guidelines sind, und die auf der UI5con als deprecated genannt
col (PCP) verwendet werden. Das SAP Gateway stellt hierzu APC/AMC-Dienste wurden. Sofern möglich, sollte vollständig auf diese Bibliothek verzichtet werden.
zur Verfügung. Viele Kunden haben auf dieser Basis größere Anwendungsszenarien gebaut, die
mittelfristig auf sap.m migriert werden müssen, um Upgrade-fähig zu bleiben.
• Für den Einstieg bietet sich die Verwendung eines SAP-Web-IDE-Templates an.
Leider unterscheiden sich die Templates relativ stark in der Qualität, da sich
BEST PRACTICE diese an den SAPUI5-Möglichkeiten zum Erstellungszeitpunkt orientieren. Am
• Das OData-Model in Version 2 ist das von SAP favori- besten sollte ein passendes Template auf Basis des höchsten Versionstands
sierte Datenaustauschmodell für den Zugriff auf genutzt werden.
Backend-Systeme (Stand Q2/2016). Im SAP Gateway
sind sowohl Version 2 und 4 implementiert • In der SAP Web IDE können Projekte auf Basis der SAP Fiori Reference Apps 86
angelegt werden, die einen Best-Practice-Ansatz für die Themen Shop, Approve
• Nach Möglichkeit sollte die gesamte Kommunikation Purchase Order und Manage Products abbilden.
auf Basis von OData Services erfolgen, wobei eine
Komponente mit nur einem OData Service kommuni- • Vor der Entwicklung relevanter Services bietet sich ein UI-Prototyp mit Mock-up-
zieren sollte (Empfehlung SAP-Fiori-Design und Daten an, da sich die relevanten SAP Annotations 87 in der SAP Web IDE einfacher
gleichzeitig Restriktion der SAP Web IDE). beschreiben und testen lassen als im SAP Gateway Designer.
• In bestimmten Szenarien bietet es sich an, zusätzlich • Der Zugriff auf Business-Daten sollte über OData-Entitäten erfolgen, die vom
die WebSocket-Kommunikation mit in das Anwen- SAP Backend-System (z.B. Gateway) zur Verfügung gestellt werden. Die gesamte
dungsszenario aufzunehmen. Hierdurch kann auf Geschäftslogik wird dadurch im Backend kontrolliert und verwaltet. Die SAPUI5-
Server-seitige asynchrone Prozesse in Realtime Oberfläche mappt dabei nur die relevanten Feldinformationen und steuert
Workflows und Sichtbarkeiten.
reagiert werden.
85 SAP Fiori Design Guidelines

86 SAP Fiori Reference Apps
87 SAP Annotations for OData Version 2.0

• Nach Möglichkeit sollte man versuchen, Smart Controls 88 (zumindest Smart 10.3 SAP GATEWAY
Fields) einzusetzen, damit die Datentypsteuerung durch den OData Service
erfolgen kann. Wenn man keine OData Services basierend auf annotierten CDS Der SAP Gateway dient als Vermittler zwischen Web-Technologien und klassischen
Views verwenden kann (nur ab NW 7.50), lassen sich die benötigten SAP Annota- SAP-Lösungen. Mit dem SAP Gateway werden Daten aus ABAP-basierten Ba-
tions auch manuell im SAP Gateway deklarativ verwenden. ckend-Systemen exponiert.
• SAPUI5 unterstützt derzeit keine kundenspezifischen Namensräume (z.B. „/SAP/

FLIGHT“). Bei der Verwendung von SmartControls sollten die relevanten Gateway
Services im Z-Namensraum liegen. 10.3.1 EINSATZ VON SAP GATEWAY
• Für die Adaption und Erweiterung bestehende Anwendungen und Komponenten Die Funktionalität von Backend-Systemen, die u. U. größeren Änderungen unterliegt,
sollte man das Extensibility-Konzept89 von UI5 anwenden. sollte nicht direkt nach außen exponiert werden. Das Ziel ist, mittels APIs verschie-
densten Konsumenten stabile Zugriffspunkte auf die Systeme anzubieten (siehe API
• Für das Theming wird i.d.R. der UI Theme Designer verwendet, der auf allen Economy 90).
unterstützten Systemen vorhanden ist. I.d.R. basiert ein eigener Theme auf dem
SAP BlueCrystal Theme. Seit SAPUI5 1.38 wird an dem neuen Belize Theme in Das Hauptanwendungsgebiet für den SAP Gateway ist die User-Interface-Integration.
zwei Ausprägungen gearbeitet, der das neue Design von SAP Fiori 2.0 abbilden Typische Konsumenten sind Websites, native Mobile Apps, Web Apps auf Ja-
soll. Der Belize Theme wird mit Version 1.40.x der neue Standard Theme und va-Script-Basis (siehe Fiori und UI5) oder auch Anwendungen einer Cloud-Plattform.
ersetzt BlueCrystal. Während bisher in der SAP-Entwicklung meist RFC-basierte Technologien eingesetzt
wurden, dominieren für die o.g. Anwendungsszenarien RESTful Services, meist
kombiniert mit dem OData-Protokoll.
10.2.4 WEITERE QUELLEN OData
• S AP Fiori Design Guidelines Das OData-Protokoll ist ein Datenaustauschstandard für das Web, der volle CRUDQ-
Funktionalität (Create, Read, Update, Delete, Query) besitzt. Daher wird es auch als
• SAP User Experience Community ODBC für das Web bezeichnet. OData basiert auf dem Entity Data Model, das jede
modellierte Entität (Objekt) sowie deren Beziehungen untereinander darstellt.
• SAP Fiori Cloud Demo
Als Datenformat werden JSON (JavaScript Object Notation) sowie ATOM/XML unter-
• SAPUI5 SDK stützt.
• SCN SAPUI5 Developer Center
• SAP Web IDE
• OpenUI5
• openSAP-Kurse
a. Developing Web Apps with SAPUI5
b. Build Your Own SAP Fiori App in the Cloud – 2016 Edition
88 SAPUI5 Smart Controls

89 Extensibility-Konzept 90 CW: Artikel API Economy

Deployment-Optionen
Der SAP Gateway kann in drei verschiedenen Varianten betrieben werden: BEST PRACTICE
Die Empfehlung ist, die erste Variante (Central Hub Deplo-
yment, Backend Development) zu nutzen. Die Hauptgründe

liegen in der besseren Skalierbarkeit und der besseren
Einbettung in die Netzwerkinfrastruktur (z.B. Gateway
in DMZ). Die Service-Implementierung (Business-Logik)
sollte im Backend erfolgen. Die zweite Variante sollte nur
zum Einsatz kommen, wenn das Backend-System nicht
den notwendigen Release-Stand hat bzw. keine Möglich-
keit besteht, die notwendigen Voraussetzungen (Kompo-
nente IWBEP, NW-Basis-Release < 7.40) zu deployen. Die
Variante des Embedded Deployment kann einen schlanken
Start bieten, sollte in der Variante allerdings nicht als
Dauerlösung betrieben werden.
Abbildung 8: SAP Gateway Deployment Optionen 91
Mit der SAP Fiori Cloud Edition gibt es noch eine vierte
Deployment Option, bei der SAP Gateway Hub in der HANA
Cloud Platform betrieben wird.92
10.3.2 ENTWICKLUNG MIT SAP GATEWAY
RESTful Services sind ein wichtiger Baustein in der Realisierung von stateless Web-
Apps, d.h. SAPUI5-basierten Apps. Hierbei wird im Backend-System kein Zustand der
App bzw. Nutzersession gehalten, sondern es ist immer nur der Zustand der letzten
Kommunikation bekannt. Dies steht im Gegensatz zur klassischen ABAP-Programmie-
rung mit SAP GUI, wo das Backend immer den Zustand der Clients verwaltete (state-
ful-Anwendungen). Das hat Konsequenzen in der Programmierung, da bei Änderungen
von Daten im Umfeld hochfrequentierter, paralleler Zugriffe nicht mehr die klassi-
schen Sperrlogiken verwendet werden können. Weiterhin findet kein Session-Handling
im klassischen Sinne statt, d.h. beim Schließen der Browser-Sitzung ist immer nur der
letzte Zustand nach dem letzten Aufruf eines OData-Services im Backend bekannt.
Wenn Service-Aufrufe idempotent sind, d.h. immer das gleiche Resultat im Backend
hervorrufen (Anlage, Löschen), gibt es keine Probleme. Schwierig wird es bei Ände-
rungen, da Sperren nur solange gesetzt werden sollten, wie der OData-Aufruf im
91
SAP Help: SAP Gateway Deployment Optionen 92
SCN SAP Gateway Deployment Options in a nutshell

Backend erfolgt. Bei erneuter Abfrage besteht daher die Möglichkeit, dass von anderer • Assoziationen: Beziehungen sollten soweit möglich gebildet werden. Einerseits
Seite die Daten in der Zwischenzeit geändert wurden. Hier muss bei der Entwicklung wird die Beziehung der Daten untereinander verdeutlicht als auch die Anzahl der
entschieden werden, ob die Änderung relevant ist oder nicht. Eine nicht relevante Aufrufe verringert.
Änderung wäre z.B. ein Genehmigungsschritt, wo nach der FCFS-Regel der erste
Änderer gewinnt, bei weiteren Aufrufern dann nur ein Refresh der Web-App mit der • Navigationseigenschaften: Sollten bei Relation 1 den Entitätstypen bzw. bei
Änderung erfolgt. Für kritischere Schnittstellen, in denen die Datensynchronisierung Relation N die Entitätsmenge95 verwenden.
zwischen Backend und dem API-Konsumenten eine große Rolle spielt, ist die
ETag-Funktionalität93 des Gateway zu empfehlen. Damit kann die Aktualität der Daten Service-Implementierung
in der Anwendung kontrolliert und entsprechend darauf reagiert werden. Nichtsdesto-
trotz gibt es Möglichkeiten klassische Sperrkonzepte94 weiterhin zu verwenden. Bei der Implementierung sollten die gängigen ABAP Objects-Richtlinien und -Namens-
Hierfür sollte man allerdings einen höheren Entwicklungsaufwand einplanen. Weiter- konventionen angewandt werden.
hin können Konzepte herangezogen werden, wie man sie bspw. aus der IDoc-Eingangs-
verarbeitung kennt. Bei Verwendung des Gateway Service Builders ist zu beachten, dass die generierten
Klassen nur die ersten 20 Zeichen des Gateway-Projektnamens verwenden. Idealer-
Bei der Entwicklung mit dem SAP Gateway werden meist drei Phasen unterschieden. weise sollte der Projektname entweder so gewählt werden, dass die ersten 20 Zeichen
Anhand dieser Phasen werden Vorschläge für Namenskonventionen sowie Best bereits eine korrekte Service-Identifizierung erlauben, oder der Name muss für die zu
Practices dargestellt. Für die Entwicklung von OData-Services bietet SAP den Gateway generierenden Klassen angepasst werden. Ansonsten wird automatisch ein Zähler an
Service Builder an (Transaktion SEGW). die generierten Klassen (Model Provider Class, Data Provider Class) angehängt, was
die Identifizierung der Klassen bei der Entwicklung erschwert.
OData-Modellierung
Service-Konfiguration
In Entwicklungsprojekten kommt dem API-Design eine wichtige Rolle zu. Hier hat man
einen klassischen Zielkonflikt zwischen Wiederverwendbarkeit der APIs und dem Der externe Servicename sollte Rückschluss auf die Funktionalität geben.
schnellen, möglichst effizienten Verfügbarmachen der Daten. Auf keinen Fall sollte Vorschläge zur Namenskonvention:
man einfach das Interface von (Standard-)Funktionsbausteinen 1:1 exponieren. Besser
geeignet ist bspw. die Kapselung der Funktionalität durch Wrapper-Funktionsbaustei- • Technischer Servicename:
ne. Das API-Design sollte von den Anforderungen des API-Konsumenten (z.B. einer
SAPUI5-Web-App) getrieben sein. • Z + <externer Servicename>
Für die OData-Modellierung empfehlen wir daher die folgenden Hinweise zu beachten: • Der _SRV Suffix wird automatisch seitens SAP angehangen.
• Entitätstypen: Entitäten sollten auf den Anwendungsfall zugeschnitten werden • Externer Servicename:
und nicht vom zugrundeliegenden Datenbankmodell getrieben sein. Der Anwen-
dungsfall sollte sich im Entitätsnamen widerspiegeln. • Namespace: /<Kunden Namespace>/ (falls Kundennamesraum verwendet wird,
ansonsten Z*)
• Komplexe Typen: Dienen der Strukturierung von Entitäten.
• Optional: GW_* als Präfix oder Infix erlaubt eine einfache Zuordnung als Gate-
• Entitätsmengen: Gruppe eines Entitätstyps, SAP schlägt Suffix-Set vor, alternativ way-Service
die Mehrzahl einer Entität.
• System-Alias: Da System-Aliase transportiert werden können, ist die Verwen-
dung des Alias-Namen als Landschaftsnamen zu empfehlen.
93 SAP-Help: ETag Handling

94 SCN-Blog: Stateful Sessions 95
SCN-Blog: OData Templates

10.3.3 GENERELLE EMPFEHLUNGEN Sicherheit
Der folgende Abschnitt enthält einige Leitlinien, die in der Entwicklung mit SAP • TLS-Nutzung ist verpflichtend (HTTPS)
Gateway zu beachten sind. Bei einigen Punkten wird entsprechend auf weiterführende
Quellen verwiesen. • Bei Verwendung des SAP Gateway als Hub sollte eine Vertrauensbeziehung99
(Trusted-RFC-Verbindung) zwischen dem Gateway und dem gerufenen Ba-
OData/ Funktionalität ckend-System bestehen.
• Eine gute Übersicht über OData Best Practices96 wird auf SAP-Help angeboten. • Der SAP-NetWeaver-ABAP-Applikationsserver unterstützt unterschiedliche
Authentifizierungsmethoden, die in SAP Gateway genutzt werden können.
• Bei der OData-Service-Entwicklung sollte dem „Separations of Concerns“ Abhängig vom Szenario (Desktop-Anwendungen, Web-Anwendungen, …) werden
Designprinzip gefolgt werden. Business-Logik gehört ins Backend, die Ser- unterschiedliche Methoden empfohlen (Kerberos, SAML 2.0, …) empfohlen.100
vice-Implementierung sollte sich auf „Glue Code“ beschränken.
• Es wird nicht die komplette OData-Syntax angeboten. Der SAP-Hinweis 1574568

enthält eine Übersicht was unterstützt wird, z.B. existieren Einschränkungen für 10.3.4 WEITERE QUELLEN
$filter -Optionen.
• SAP Community Network
• Der UI-Entwicklungsprozess wird durch die Verwendung von OData Annotations97
stark vereinfacht. Insbesondere ab Release-Stand 7.50 ist daher die Verwendung • SAP-Online-Hilfe
von Annotations in OData Services zu empfehlen.
• Bei Verwendung mehrerer Backend-Systeme innerhalb einer SAPUI5 Web App ist
die Multi-Origin-Composition (MOC)-Funktionalität empfehlenswert.
Performance
• Statt vieler paralleler Aufrufe sollten $batch und $expand98 genutzt werden.
• OData bietet mit der $select-Option eine Möglichkeit zum Einschränken der zu
übertragenden Daten. Generell sollten immer nur so wenige Daten wie notwendig
übertragen werden.
96 SAP-Help: OData do’s and dont’s

97 SCN-Blog: Annotations in ABAP 99 SAP-Help: Trusted System
98 SCN-Blog: Perf do’s and dont’s 100
SAP NetWeaver Gateway Authentication and Single Sign-On

11 DIE AUTOREN
Die folgenden Autoren waren maßgeblich an der Erstellung der 2. Auflage des Leitfadens beteiligt:
Dr. Christian Drumm Martin Hoffmann

11. DIE AUTOREN
Leiter Anwendungsentwicklung & Beratung, FACTUR Billing Solutions GmbH Head of Software Engineering, Miele & Cie. KG
Dr. Christian Drumm arbeitet seit 2004 im SAP-Umfeld. Nach seiner Zeit bei SAP-Re- Martin Hoffmann ist seit 1987 im Entwicklungs-nahen Umfeld tätig und konnte
search arbeitet er in verschiedenen Rollen (Entwickler, Projektleiter, Architekt) in der Erfahrungen als Entwickler und in verschiedenen leitenden Positionen im Entwick-
Beratung mit den Schwerpunkten SAP CRM und SAP IS-U. Seit 2013 leitet er die lungsumfeld sammeln. Seit 2007 verantwortet er bei Miele den Bereich Software-En-
Abteilung Anwendungsentwicklung und Beratung der FACTUR Billing Solutions GmbH. gineering.
Martin Fischer Valentin Huber

Portfolio Unit Manager SAP Database & Technology, bridgingIT GmbH Senior IT Consultant, msg systems ag
Martin Fischer ist seit 2001 im SAP-Umfeld tätig. Gestartet ist er als Modulbetreuer im Valentin Huber ist seit 2012 als ABAP-Entwickler und Sofware-Architekt für kundenei-
Bereich SAP FI/CO. Seit 2007 hat er den Schwerpunkt auf Software-Entwicklung und gene Entwicklungen tätig. Zuvor sammelte er Erfahrung in der C++ und Java-Entwick-
-architektur mit Schwerpunkt ABAP gelegt. Nach Stationen bei verschiedenen Bera- lung. Als Certified Professional for Software Architecture (Foundation Level) nach
tungshäusern ist er seit 2011 bei bridgingIT. Dort verantwortet er fachlich den Portfoli- iSAQB und Clean-Code-Development-Verfechter liegen ihm insbesondere die Erwei-
obereich SAP Database & Technology. terbarkeit und Wartbarkeit von Softwaresystemen am Herzen.
Judith Forner Jens Knappik

Senior Consultant Finance & Controlling, Mundipharma Deutschland GmbH & Co. KG SAP System Architect, thyssenkrupp Materials Services GmbH
Judith Forner ist seit 1999 als SAP-Beraterin und ABAP-Entwicklerin tätig. Neben der Jens Knappik ist seit 2004 als ABAP-Entwickler in einem internationalen Projektum-
klassischen Prozessberatung in den Modulen FI, CO und PM liegen ihre Schwerpunkte feld tätig. In seiner Rolle als Lead Developer begleitete er bis 2012 die Produktentwick-
in der anwenderfreundlichen Erweiterung des SAP-Standards und der Integration lung in den Modulen SD-CAS und CS. Seitdem ist er als Berater für die strategischen
externer Systeme. Ausrichtung und Definition von Standards im ABAP-Umfeld für das zentrale Busi-
ness-Area-Template aktiv.
Edo von Glan
SAP-Entwickler, Drägerwerk AG & Co. KGaA Dr. Christian Lechner
Edo von Glan hat als Software-Entwickler für IBM und die Commerzbank, sowie sieben Principal IT Consultant, msg systems ag
Jahre in der Produktentwicklung bei SAP gearbeitet. Seit 2008 arbeitet er in der Dr. Christian Lechner ist seit 2005 im Bereich der SAP-Softwareentwicklung (Standard
SAP-Entwicklungsabteilung bei Dräger, davon sechs Jahre in leitender Position. Der und Custom Development) in verschiedenen Rollen (Entwickler, Projektleiter, Soft-
Verantwortungsbereich umfasst die Applikations- und Schnittstellentwicklung sowie warearchitekt) tätig. Seit 2015 leitet er die Architekturabteilung des Geschäftsbereichs
Custom Code Lifecycle Management und Software-Qualität für die im Unternehmen Development der msg systems ag.
zentral verwalteten SAP-Systeme.
Steffen Pietsch
Florian Henninger Head of Backoffice, Haufe-Lexware GmbH & Co.KG
Senior Consultant SAP Development, FIS GmbH Steffen Pietsch ist seit 2003 in Entwicklungs-nahen SAP-Themenbereichen tätig und
Florian Henninger ist zertifizierter ABAP-Entwickler und seit 2010 im Bereich konnte umfangreiche Praxiserfahrung als Entwickler sowie in verschiedenen leitenden
SAP-ABAP-Entwicklung tätig. Sein fachlicher Schwerpunkt liegt im Bereich Core Positionen im Beratungs- und Entwicklungsumfeld sammeln. Seit 2009 setzt er sich
Development/Enhancements sowie dem Thema Output Management bei ERP-Einfüh- als Sprecher des DSAG-Arbeitskreises Development für die Interessen der Kunden
rungsprojekten und Bestandssystemen. Außerdem ist er Mitglied des Qualitäts und Partner in Zusammenarbeit mit der SAP ein.
Managements, Coach und SAP-Mentor.

Daniel Rothmund
IT Business Analyst SAP, Geberit Verwaltungs GmbH
Daniel Rothmund ist seit 2008 in verschiedenen Bereichen im SAP-Umfeld tätig. Seit
2016 ist er für das zentrale SAP-Development-Team bei Geberit verantwortlich. Seit
2015 setzt er sich als Sprecher der DSAG-Arbeitsgruppe UI Technologie für die
11. DIE AUTOREN
Interessen der Kunden und Partner in Zusammenarbeit mit der SAP ein.
Holger Schäfer
Business Unit Manager, UNIORG Solutions GmbH
Holger Schäfer ist seit 1999 im SAP-Umfeld in den Schwerpunktthemen User Interfa-
ces, Integration, HANA/HCP und E-Commerce tätig. Er engagiert sich in der Arbeits-
gruppe UI-Technologien und in der OpenUI5 Community. Seit 2010 verantwortet er die
strategische Geschäftsfeldentwicklung im Bereich neuer SAP-Technologien.
Denny Schreber
Senior Solution Architect, cbs Corporate Business Solutions Unternehmensberatung
GmbH
Denny Schreber arbeitet seit 2007 in SAP-nahen Technologiethemen. Sein Schwer-
punkt liegt dabei auf Mobile & UI-Technologien sowie Integrationsthemen. Zuvor war
er im Bereich der Java-Software-Entwicklung tätig. Seit 2015 ist er stellvertretender
Sprecher in der DSAG-AG UI-Technologien.
Andreas Wiegenstein
Chief Technology Officer (CTO) und Mitgründer, Virtual Forge GmbH
Andreas Wiegenstein arbeitet seit 2002 im Bereich SAP-Security mit dem Schwer-
punkt Penetrationstests. Er ist Co-Autor des Buches „Sichere ABAP-Programmie-
rung“ (SAP Press) und hält regelmäßig Vorträge zum Thema SAP-Sicherheit auf
internationalen Konferenzen, wie z.B. Troopers, RSA, Black Hat, BIZEC, IT Defense,
Deep Sec, Hack In The Box, SAP TechEd und auf DSAG-Veranstaltungen.
Bärbel Winkler
Systemanalystin SAP-Basis/Programmierung, Alfred Kärcher GmbH & Co. KG
Bärbel Winkler arbeitet seit 2000 im SAP-Umfeld in der ABAP-Programmierung und
Projektarbeit und ist seit 2011 bei der Alfred Kärcher GmbH & Co. KG. in kundeneigene
Entwicklungen und deren Koordination eingebunden. Zu ihren Aufgaben gehört die
regelmäßige Aktualisierung der Entwicklungsrichtlinien, die Beurteilung und Schät-
zung eingehender Entwicklungsanforderungen sowie die Begleitung der Umsetzung
bei extern durchgeführter Programmierung.

ANHANG A: NAMENSKONVENTIONEN • Es entsteht zusätzlicher Aufwand, wenn sich der technische Typ bzw. die Sicht-
barkeit ändert. Ebenso wenn z.B. die Zuordnung zur Anwendungshierarchie /
Beim Thema Namenskonventionen gibt es für ABAP zwei konträre Ansätze. Der Organisationseinheiten Teil des Namens ist und die Objekte in einen anderen
wesentliche Unterschied liegt darin, ob der Datentyp (Struktur, Tabelle, Referenz, Bereich umziehen sollen.
Elementar, ...) mit einem Präfixbuchstaben in den Objektnamen „kodiert“ (English:
encoded) wird oder nicht. • Semantische Informationen können auf Grund von Platzmangel verloren gehen.
ANHANG A
Namenskonventionen, bei denen der Datentyp als Präfix zum Objektnamen vorge- • Das Erlernen, Kontrollieren und Aktualisieren der Konventionen ist mit zusätzli-
schrieben wird, fordern in der Regel auch noch weitere technische, fachliche oder chem Aufwand verbunden.
organisatorische Kategorien, die ebenfalls in den Präfix aufgenommen werden sollen.
Insofern könnte man von „umfassenden“ Namenskonvention sprechen. Es besteht eine Vorteile von minimalen Namenskonventionen
Verwandtschaft zu der bei Microsoft erfundenen Ungarischen Notation101.
• Mehr Platz und Aufmerksamkeit für den sprechenden Namen, sowohl beim
Bei genauer Betrachtung wird die umfassende Namenskonvention in der Regel nur Schreiben als auch beim Lesen.
halbherzig umgesetzt, da die Konvention bei geschachtelten Datentypen nur auf der
ersten Ebene stattfindet (LS_CUSTOMER-PARTNER-HISTORY statt LS_CUSTOMER-S_ • keine redundanten Informationen (Datentyp lässt sich durch Vorwärtsnavigation /
PARTNER-T_HISTORY). F2 (ADT) ermitteln, Herkunftssystem steht im Objektkatalog, die Zuordnung zur
Anwendungshierarchie lässt sich über das Paket ableiten, usw.).
Im Gegensatz dazu steht die „minimale“ Namenskonvention, wo bisweilen nur die
Präfixe zur Unterscheidung von Parametern (I_ für IMPORTING, E_ für EXPORTING, Die erste Version dieses Leitfadens verfolgte eine Variante der umfassenden Namens-
usw.) vorgeschrieben werden, und stattdessen der Fokus auf einem sinnvollen konvention, von der wir uns aufgrund unserer eigenen Erfahrungen, sowie dem
„sprechenden“ Namen liegt. Für diese Art der Namenskonvention sprechen sich unter aktuellen Diskusionsstand in der Fachliteratur und im SCN (siehe Anhang A.3) distan-
anderem die Autoren der „ABAP-Programmierrichtlinien“ (jetzt Teil der F1-Hilfe) aus. zieren.
Vorteile von umfassenden Namenskonventionen Im Folgenden finden Sie ein Beispiel, wie eine eher schlanke Namenskonvention
aussehen kann.
• Beim Lesen des Quellcodes ist der Objekttyp sofort ersichtlich, ohne dass z.B. in
den DDIC navigiert werden muss. Allgemeine Hinweise:
• Ungewollte Verschattungen (z.B. Typen in Methoden gegenüber Typen in der • Objekte im ABAP Dictionary haben unterschiedliche Begrenzungen in der Anzahl
Klasse) können besser vermieden werden. zur Verfügung stehender Zeichen. Bei der Benennung der Objekte ist dies zu
berücksichtigen.
• Objektnamen wirken einheitlich und ordentlich durch den einheitlichen Präfix
(auch wenn der sprechende Teil der Namen vielleicht schlecht gewählt ist). • Nachfolgend wird der Kundennamensraum Y… verwendet. Stattdessen kann, wie
in Kapitel 2 beschrieben, alternativ der Namensraum Z… oder ein kundeneigener
Nachteile Namensraum /…/ verwendet werden.
• eine vollständige und eindeutige Systematik ist umfassend und komplex, siehe
die Diskussion im Buch „ABAP-Programmierrichtlinien“.
• Die Lesegeschwindigkeit von Quelltext sinkt, da technische mit semantischen

Informationen vermischt werden.
101 https://de.wikipedia.org/wiki/Ungarische_Notation

A.1 NAMENSKONVENTIONEN REPOSITORY-OBJEKTE
Bereich Bedeutung Beispiel
Namenskonventionen im ABAP Repository verfolgen das Ziel, Namenskonflikte durch Z = Entwicklung ohne
Kundennamensraum oder Transportschicht
Namensüberlagerung zu vermeiden und die Namen der Objekte durch Anwendung
[ Namensraum ] reservierter Kundennamens-
einer standardisierten Vorgehensweise verständlicher zu machen. Zusätzlich sollen raum. Y = Transportrelevante
sie dem Entwickler Entscheidungen abnehmen, so dass er sich auf die Umsetzung von Entwicklung
ANHANG A
Anforderungen konzentrieren kann und keine Aufwände in eine individuelle Vermei- Technisches Objektkürzel für
dung von Namensüberlagerung investieren muss. Des Weiteren dient die Konvention [ Typinformation ] einen bestimmten Typ. Nicht CL = Globale Klasse
im Quellcode als Hilfestellung für den Einsatz der zu dem Objekt passenden Operato- für jedes Objekt notwendig.
ren (Beispiel INSERT statt APPEND beim Anhängen einer neuen Zeile in eine sortierte Zusammenfassendes
Tabelle). Repository-Objekte unterscheiden sich in den meisten Fällen102 durch ihren Arbeitsgebiet, ein Produkt
Objektkatalogeintrag voneinander, weshalb aus technischer Sicht bei der Namensver- oder die Zuordnung zur
gabe nur sehr wenigen Konflikte entstehen können. Daneben werden für diverse Anwendungshierarchie bzw. Anwendungshierarchie SD:
[ Kontext ]
Objekte, wie z.B. Ausnahmeklassen (Präfix = CX) oder Sperrobjekte (Präfix = E), Softwarekomponente. In der Sales & Distribution
Namenskonventionen durch die Entwicklungsumgebung erzwungen103. Regel wird der Kontext über
ein Struktur- oder Hauptpa-
ket gebildet.
Die nachfolgenden Konventionen erweitern die Vorgaben aus oben genanntem Hinweis.
Das Ziel der Richtlinien ist die Bereitstellung praxistauglicher, pragmatischer Regeln Informationen über ein
die auf Überregulierung weitestgehend verzichten. Hierzu werden nur für konkurrie- Domänenobjekt, dessen
Absicht oder bekannte
rende Objekte Namenskonventionen festgelegt, die sich am SAP-Standard orientieren
[ Semantische Information ] Anwendungsmuster basie- OPEN_ITEMS_LIST
(z.B. Präfixkonventionen für Typinformationen aus dem BOPF-Framework). rend auf einer allgegenwärti-
gen, verständlichen Sprache
Die Namenskonventionen setzen sich aus folgenden Bereichen zusammen und werden (s. Kapitel 2.3).
zum Teil durch Unterstriche voneinander getrennt: Anwendungen:
Ein Muster ist ein optionaler Worklist / Chart / Overview
Teil der semantischen
Information und beschreibt Design:
[ Muster ] eine etablierte Vorgehens- Master / Detail
weise im Rahmen des
Designs / der Programmie- Implementierung103
rung. Factory / Data Access Object /
Gateway
102 Eine Ausnahme sind Tabellen und Strukturen. Diese haben beide den TADIR-Objekttyp TABL. 104 Da im Rahmen der Implementierung häufig mehrere Muster gleichzeitig zum Einsatz kommen, sollten die Details über die eingesetz-
103 Weitere Details zu den betroffenen Objekten sind im SAP-Hinweis 16466 hinterlegt ten Muster besser im Quellcode und nicht im Objejktnamen kommentiert werden.

A.1.1 PAKETHIERARCHIE Unterpakete:
Unterpakete teilen das übergeordnete Paket in spezialisierte
Struktur- / Haupt- / Entwicklungspakete: Arbeitsbereiche auf. Um die Zugehörigkeit der Objekte
Typ
Pakete eignen sich optimal für die Gruppierung mehrerer hervorzuheben empfiehlt es sich, für alle in dem Paket / der
Typ Unterpakethierarchie enthaltene Objekte den gleichen
Entwicklungsobjekte zu einer semantisch zusammenhängen-
den Einheit. Präfixnamensraum zu verwenden.
ANHANG A
Namensbildung [ Einzelnes Substantiv | Zusammengesetzte Substantive ] [ Abkürzung des übergeordneten Paketes ] [ semantische
Namensbildung
Information ]
Anwendungshierarchie / Softwarekomponente:
- Y_COMPUTER_AIDED_SELLINGS (Hauptpaket)
- Y_DEVELOPMENT_FOUNDATION (Strukturpaket)
- Y_CAS_BUSINESS_OBJECTS (Entwicklungspaket)
- Y_ERP_CENTRAL_APPLICATIONS (Strukturpaket)
Beispiele - Y_CAS_COMMON (Entwicklungspaket)
- Y_ACCOUNTING (Strukturpaket)
- Y_CAS_CORE (Entwicklungspaket)
- Y_...
- Y_CAS_CONFIGURATION (Entwicklungspaket)
- Y_LOGISTICS (Strukturpaket)
- Y_LOGISTICS_EXECUTION (Hauptpaket)
Paketschnittstellen:
- Y_PROCUREMENT (Hauptpaket)
Die Bezeichnung von Paketschnittstellen dient der Bekannt-
Beispiele - Y_SALES (Hauptpaket) Typ machung einer Absichtserklärung, wie mit bestimmten, über
-
Y_COMPUTER_AIDED_SELLINGS (Hauptpaket) die Paketschnittstelle propagierten Objekten, umgegangen
werden soll.
- Y_CAS_COMMON (Entwicklungspaket)
[ Paketbezeichnung ] [ [ Sichtbarkeit ] | [ Zugriffsart ] | [
- Y_NETWEAVER_PLATFORM (Strukturpaket) Namensbildung
Konsument ] ]
- Y_SAP_DELIVERABLES (Strukturpaket) - Y_CAS_SALES_ACTIVITY_PUBLIC
- Y_RAPID_DEPLOYMENT_SOLUTIONS (Hauptpaket) Beispiele - Y_CAS_CONFIGURATION_READ
- Y_SAP_BEST_PRACTICES (Hauptpaket) - Y_CAS_CONFIGURATION_WRITE
- Y_SAP_NOTES (Hauptpaket)
- Y_SNOTE_2294645 (Entwicklungspaket)
A.1.2 DICTIONARY OBJEKTE
Elementare Datentypen:
Datenelemente und Domänen beschreiben die technischen
und semantischen Eigenschaften eines Daten- oder Referenz-
Typ
typen. Da sie sich durch ihren Objektkatalogeintrag technisch
voneinander unterscheiden, ist die Verwendung von identi-
schen Namen möglich.
Namensbildung [ Einzelnes Substantiv | Zusammengesetzte Substantive ]
Y_CAS_ACTION_IDENTIFIER (Domäne)
Beispiele
Y_CAS_ACTION_IDENTIFIER (Datenelement)

Strukturtypen: Beispiel:
Mehrdimensionale Datentypen enthalten ein oder mehrere YT_CAS_ACTIONS
Typ
Datentypen als Komponenten. Sie unterteilen sich in
YTH_CAS_ACTIONS (Interne Tabelle mit Hash-Zugriff)
einzeilige und mehrzeilige Strukturtypen.
YTS_CAS_ACTIONS_BY_ACTIVITY (Interne Tabelle sortiert nach dem Feld ACTIVITY)
Namensbildung [ Einzelnes Substantiv | Zusammengesetzte Substantive ]
Core Data Services:
Strukturen: Neu angelegte CDS-Views erzeugen drei Repository-Objekte. Die DDL-Source, ein CDS-View
ANHANG A
Strukturen teilen sich historisch bedingt den gleichen Objektkatalogeintrag mit transparenten und ein CDS-Datenbank-View. Um CDS-Datenbank-Views von normalen Datenbank-Views zu
Tabellen. Daher ist es notwendig, die beiden Typen zwingend per technischem Präfix vonein- unterscheiden, empfehlen wir den SAP Standard Beispielen104 zu folgen und CDS-Daten-
ander zu unterscheiden. bank-Views mit dem Präfix SQL zu kennzeichnen.
Beispiel: Beispiel:
YS_CAS_ACTION YSQL_CAS_MASTER (CDS-Datenbank-View)
YS_CAS_MASTER_LINE
Transparente Tabellen:
In der Regel sollte die Präfixbezeichnung D für Transparente Tabellen ausreichen. Falls eine
weitere Unterteilung notwendig ist, empfehlen wir auf Grund der Längenbeschränkung von 16
A.1.3 CONTAINER FÜR QUELLTEXTOBJEKTE
Zeichen das Präfix um die technische Auslieferungsklasse der Tabelle zu erweitern bzw. T für
die Kennzeichnung von Texttabellen zu verwenden.
Ausführbare Anwendungen
Beispiel: Aus dem Namen einer Anwendung sollte sich direkt ableiten
lassen, was die Anwendung leistet, welches Geschäftsobjekt
YD_CAS_CONFIG
im Fokus steht und ggf. mit welchem Verfahren die Anwen-
YDC_CAS_ACTIONS (Konfigurationstabelle) Typ
dung zu bedienen ist (Worklist, Wizard, …). Wir empfehlen bei
YDT_CAS_ACTIONS (Texttabelle) der Namensvergabe bekannte Bedienverfahren aus dem
Floorplan Manager105 bzw. aus den Fiori Design Guidelines106
YDA_CAS_MASTER (Stamm- und Bewegungsdaten) zu adaptieren.
YDL_CAS_FILEINPT (Temporäre Daten) [ Einzelnes Substantiv | Zusammengesetzte Substantive ]
Namensbildung
Views: [ Muster ]
Falls die Präfixbezeichnung V für Views nicht ausreicht, empfehlen wir eine weitere Untertei- Y_CAS_CUSTOMER_VISIT_PLANNER
lung auf Basis des View-Typen einzuführen.
Beispiele Y_CAS_SALES_ACTIVITY_WORKLIST
Beispiel:
Y_CAS_DATA_MIGRATION_WIZARD
YV_CAS_CONFIG
YVC_CAS_ACTIONS (Pflege-View)
YVH_CAS_ACTIONS (Help-View)
YVD_CAS_MASTER (Datenbank-View)
YVP_CAS_MASTER (Projektions-View)
Tabellentypen:
Ist die Anlage mehrerer Tabellentypen für denselben Zeilentyp notwendig, empfehlen wir die
Zugriffsart in die Präfixbezeichnung aufzunehmen und die semantische Bezeichnung um
Informationen über die Schlüsseldefinition zu ergänzen. Anderenfalls ist die Präfixbezeich-
nung T ausreichend.
105 SAP-Help: ‘Implement the CDS View as Data Model’

106
SAP-Help: ‘Floorplans Concept’
107 Fiori Design Guidelines: ‘Floorplan Overview’

Includes für Rahmenprogramme und Funktionsgruppen Enhancements
Includes sollten nach Möglichkeit nicht mehr als wiederver- Enhancementspots dienen als Container für die über
wendbare Modularisierungstechnik verwendet und in Neuent- BAdI-Definitionen festgelegten Erweiterungen von Objekten
Typ wicklungen durch ABAP Objects abgelöst werden. Ist der Typ
an definierten Stellen. Die Ausprägung kann spezifische
Einsatz dennoch notwendig, sollte die Modularisierung am Erweiterungsimplementierungen mit diversen BAdI-Imple-
Dynpro bzw. dem aktuellen Geschäftsobjekt ausgerichtet mentierungen, Filtern etc. enthalten.
werden.
[ Name des zu erweiternden Objekts ] [ [ Filterinformationen ]
ANHANG A
[ Rahmenprogramm | Abkürzung ] [ Container Typ ] [ Dynpro* Namensbildung

Namensbildung | [ Variante ] ]
| Zähler ]
Y_CAS_SALES_ACTIVITY_WORKLIST (Erweiterungs-Spot)
Y_CAS_SALES_ACTIVITY_WORKLIST (Report)
- Y_CAS_SAWL_DEFAULT_EXTENSION
Y_CAS_SALES_ACTIVITY_WL_TOP (Globaler Deklarations- (Erweiterungsimplementierung)
teil)
- /ABCDEF/CAS_SAWL_EXTENSION
Y_CAS_SALES_ACTIVITY_WL_O0100 (PBO Dynpro 0100) (Erweiterungsimplementierung)
Y_CAS_SALES_ACTIVITY_WL_I0100 (PAI | POH | POV Dynpro - /ZYXWVU/CAS_SAWL_EXTENSION
Beispiele 0100) (Erweiterungsimplementierung)
Beispiele
Y_CAS_SALES_ACTIVITY_WL_F01 (Form Routinen) Y_CAS_SAWL_ADD_VALIDATION (BAdI Definition)
Y_CAS_SALES_ACTIVITY_WL_C01 (Lokale Klassen) - Y_CAS_SAWL_DEFAULT_VALIDATION
Y_CAS_SALES_ACTIVITY_WL_T01 (Unit Tests) (BAdI-Implementierung)
- /ABCDEF/CAS_SAWL_DV_D0100
(BAdI-Implementierung)
- /ZYXWVU/CAS_SAWL_DV_D0200
Funktionsgruppen für Tabellenpflegeviews (BAdI-Implementierung)
Generierte Funktionsgruppen für Tabellenpflegedialoge
Typ
sollten denselben Namen wie der dazugehörige Pflege-View
besitzen.
ABAP Objects
Namensbildung [ Name des Pflege-Views ]
YVC_CAS_ACTIONS (Pflege-View) Wir empfehlen den Vorgaben der SAP für die Benennung von ABAP-Objects-Kompo-
Beispiele nenten108 zu folgen. Davon ausgenommen sind die Vorgaben vom Typ „Empfehlung“ und
YVC_CAS_ACTIONS (Funktionsgruppe für Tabellenpflegeview)
die methodenlokalen Konventionen für Parameter. Für Parameter sollten Sie sich an
die Empfehlungen im Anhang A.2.3 Signaturen halten. Anstelle der Präfixempfehlun-
gen für z.B. Konstanten und lokale Klassen, sollten Sie besser semantisch passende
und gut lesbare Bezeichner verwenden.
108
SAP-Help: „Naming Conventions in ABAP Objects“

Beispiel: Typ Präfix
“ Local class in the local types context of a global class Globale Datenobjekte g_
CLASS sales_activity_constants DEFINITION
CREATE PRIVATE ABSTRACT FINAL. Ausnahme:
PUBLIC SECTION.
ANHANG A
CONSTANTS: Für lokale Deklarationen in Methoden kann unter folgender Bedingung die Präfixkon-
vention l_ verwendet werden:
BEGIN OF partner_function,
key_account_manager TYPE tpar-parvw VALUE ’KA‘, • Die lokale Deklaration verschattet ein statisches Klassenattribut.
...
END OF partner_function. • Die Methode muss auf das statische Klassenattribut zugreifen.
ENDCLASS.
• Der Klassenname ist sehr lang.
• Der Zugriff über den Komponentenselektor (=>) führt zu einer schlechten

Lesbarkeit.
A.2 NAMENSKONVENTIONEN ABAP-QUELLTEXT
Namenskonventionen für Quelltext sollen die Verständlichkeit erhöhen, indem für

besonders wichtige Typinformationen ein Präfix verwendet wird. Ansonsten liegt der A.2.3 SIGNATUREN
Fokus auf einer klaren, verständlichen Namensgebung (siehe Kapitel 2.3).
Wir empfehlen, die Verwendung von Signaturen in den verschiedenen Prozedurtypen
A.2.1 KLASSISCHE BENUTZERDIALOGE (SELEKTIONSBILDER / DYNPROS) (Unterprogramme / Funktionsbausteine / Methoden) zu vereinheitlichen und nachfol-
gende Präfixbezeichner zu verwenden.
Auf Grund der Längenrestriktionen von Komponenten klassischer Benutzerdialoge
empfehlen wir beigefügte Präfixbezeichner einzusetzen: Typ Präfix
Importing / Using / Tables i_
Typ Präfix Exporting / Tables e_
Parameter p_ Changing / Tables c_
Select-Options s_ Returning r_
Tables Dialogstrukturen für Dynpro-Binding ohne
A.2.2 SICHTBARKEIT
Unbeabsichtigte Verschattung lokaler Deklarationen lässt sich durch die Definition von
Präfixbezeichnern für Signaturen und globale Variablen / Typen vermeiden. Aus
technischer Sicht ist die Einführung weiterer Präfixkonventionen nicht notwendig.

A.3 WEITERFÜHRENDE INFORMATIONEN ZU NAMENSKONVENTIONEN A.4 SONSTIGES / LESSONS LEARNED
Für Anhänger und Verfechter einer umfangreichen Namenskonvention verweisen wir A.4.1 KUNDENNAMENSRÄUME
aus Gründen der Einheitlichkeit auf beigefügten de-facto-Standard für umfangreiche
Namenskonventionen aus der SCN-Community: Sollten Sie mehrere Systemlandschaften im Einsatz haben, zwischen denen Entwick-
http://scn.sap.com/people/uwe.schieferstein/blog/2009/08/30/nomen-est-omen-- lungen hin und her transportiert werden, empfiehlt sich die Einbindung der (hoffentlich
ANHANG A
abap-naming-conventions eindeutigen) System-ID in den Präfixnamensraum. Hierdurch ersparen Sie sich evtl.
auftretende Namenskonflikte zwischen den jeweiligen Systemen.
Eine weitere, etwas reduzierte Variante finden Sie hier:
http://scn.sap.com/community/abap/blog/2016/02/05/fanning-the-flames-prefixing- Beispiele für System ID = D01:
variableattribute-names
• YD01*
Die entsprechenden Gegenbewegungen zu dem Thema möchten wir Ihnen natürlich
nicht vorenthalten: • /ZYXD01/*
http://scn.sap.com/community/abap/blog/2013/05/23/abap-code-naming-conventions-
-a-rant
http://scn.sap.com/community/abap/blog/2015/09/22/hungarian-beginners-course- A.4.2 VERMEIDUNG ÜBERFLÜSSIGER BEZEICHNERINFORMATIONEN

-a-polemic-scripture-against-hungarian-notation
Vermeiden Sie überdimensionierte Konventionen für Organisationsbestandteile oder
Besonders empfehlenswert sind die zu den oben aufgeführten Blogs dazugehörigen schnelllebige Informationen im knapp bemessenen Objektnamen. Nutzen Sie stattdes-
Kommentarpassagen. Ergreifen Sie die Gelegenheit und versetzen Sie sich in die Sicht sen Meta-Informationen die z.B. über das Classification Toolset109 definiert werden
der jeweiligen Fraktion und lernen die entsprechend positiven und negativen Facetten können.
kennen.
Anderenfalls entstehen schwer zu interpretierende, kryptische Bezeichner, deren
Letzten Endes müssen Sie die Konventionen festlegen, die Ihnen, Ihrem internen und Interpretation aufwendig ist und sich erst nach einem Langzeitstudium der Konventio-
ggf. externen Teams den besten Nutzen im Hinblick auf die Produktivität, gewünschte nen ergibt.
Qualität und Lebenszykluskosten bringt. Unsere Empfehlung lautet dabei, sich auf
jeden Fall an einem vorhandenen Standard zu orientieren und das Rad nicht neu zu Beispiel:
erfinden. Hierdurch erhöht sich die Chance, dass neue Mitarbeiter den verwendeten
Standard bereits kennen und ohne große Einarbeitungszeit Mehrwert für das Unter- • Name: /NAME/CL_T1_ERP_BC_SYS_DPC_607
nehmen generieren können.
• edeutung: Data Provider Klasse, die im Unternehmenstemplate T1 auf Basis von
B
Abschließend verweisen wir auf die offiziellen ABAP-Programmierrichtlinien, die uns ECC 6 EHP 7 Systeminformationen bereitstellt.
bei der Definition der hier aufgeführten Namenskonventionen als Orientierungshilfe
gedient haben: Beispiele für die im Objektnamen zu vermeidenden Meta-Informationen sind:
http://help.sap.com/abapdocu_750/de/abennaming_guidl.htm
• [ RICEF-ID ] / [ Change Request ID ] / [ Ticket-ID ]
• [ Unternehmenstemplate ] / [ Systemtyp ] / [Version]
• [ Releasestand ]*
109
SAP-Help-Suche „Classification Toolset“

Die Angabe des Release-Standes macht nur für die Produktentwicklung Sinn, die Eine Neuerung für moderne Pakethierarchien wurde mit dem SAP-Hinweis 2297645
tatsächlich für verschiedene Release-Stände entwickelt wird und sich von der verfüg- kurz vor Redaktionsschluss zur Verfügung gestellt und ist in den neusten, seit Mai
baren ABAP-Syntax oder dem Datenmodell voneinander unterscheidet. Die Verwen- 2016 verfügbaren Service Packs der Komponente SAP_BASIS 700 enthalten. Weitere
dung sollte eher die Ausnahme als die Regel darstellen. Details dazu sind im SCN-Blog erläutert.111 Zwar stellt die Neuerung sicher, dass
Elemente mit dem definierten Präfix nur in einem Paket der Pakethierarchie abgelegt
werden dürfen, sie behält aber die bereits aufgeführten Schwächen bei.
ANHANG A
A.5 FORMULARE
Adobe Interactive Forms – Interfaces
Typ Formularschnittstellen sollten sich von den regulären BEST PRACTICE
Formularen durch Hinzufügen eines Suffixes hervorheben.
Auf Grund der eingeschränkten Funktionalität empfehlen
Namensbildung [ Formularname ] [ Interfacekürzel ] wir die Verwendung der Tabellenpflegeviews V_TRESN,
Beispiele Y_CAS_SALES_ACTIVITY_IF bzw. CTSRESNAME sorgfältig zu überdenken und eher
nicht zu verwenden.
A.6 SCHUTZ VON NAMENSKONVENTIONEN IN DER ABAP-WORKBENCH
Namenskonventionen für Repository-Objekte lassen sich über die Bordmittel des

Change and Transportsystems (CTS) verwalten. Hierzu stellt das CTS-Mechanismen
für die Definition sogenannter Präfixkonventionen bereit. Die Konfiguration der
Präfixkonventionen lässt sich durch die Tabellenpflegeviews V_TRESN, bzw. CTSRES-
NAME für reservierte Kundennamensräume, realisieren. Mit den Views ist es möglich,
Namenskonventionen für Repository-Objekte pro Paket festzulegen110.
Die Pflege einzelner Objekttypen pro Paket ist sehr zeitintensiv und mit entsprechend
hohem Änderungsaufwand verbunden. Eine generische Pflege für alle Objekte eines
einzelnen Pakets funktioniert nur bei reservierten Kundennamensräumen und ist
deshalb nicht für alle Kunden relevant. Ein zusätzliches Manko besteht darin, dass die
Konventionen keine „Überlappung“ der Präfixe für verschiedene Pakete und deren
enthaltenen Elemente zulassen. Es ist beispielsweise nicht möglich, das Präfix
/ZYX/123 für das Paket /ZYX/SOME_PACKAGE und parallel das Präfix /ZYX/1234 für
das Paket /ZYX/SOME_OTHER_PACKAGE einzusetzen, da das zweite Präfix eine
Untermenge des ersten Präfix darstellt. Eine Gewährleistung, dass alle im Paket
enthaltene Elemente mit dem definierten Präfix beginnen müssen, ist nicht sicherge-
stellt, da Objekte ohne definiertes V_TRESN-Präfix problemlos dem Paket zugeordnet
werden können.
110 Vgl. Definition von Namenskonventionen (SAP-Bibliothek – Softwarelogistik) 111 SCN-Blog: „News about ABAP Package Concept: Naming Conventions for Package Hierarchies“

ANHANG B: WEITERFÜHRENDE BEISPIELE
B.1 ERWEITERUNG DER ABAP-SCHLÜSSELWORTDOKUMENTATION
Die individuellen Erweiterungsoptionen für die ABAP-Schlüsselwortdokumentation

sind zum heutigen Stand kein offiziell unterstütztes Feature. Zurzeit existieren für die
ANHANG B
Erweiterung der Programmierrichtlinien nur sehr wenige Informationen, weshalb die

nachfolgenden Hinweise auf eigenes Risiko hin verfolgt werden können:
Sie finden die Werkzeuge für die Pflege der Transaktion ABAPDOCU in dem Paket
SABAPDOCU. Dort enthalten ist das Programm ABAP_DOCU_TREE_MAINTAIN, mit
dessen Hilfe Sie die einzelnen Artikel in den Navigationsbaum einhängen und editieren
können. Beim Speichern des Navigationsbaums durchläuft das Programm den
gleichnamigen Funktionsbaustein ABAP_DOCU_TREE_MAINTAIN, in dessen lokaler
Klasse TREE_MAINTAIN eine Methode EDIT_STORE_TO_DATABASE gerufen wird, die
zu Beginn über eine Konstante auf ein zentrales SAP-Dokumentationssystem verprobt.
Am Ende der Methode wird die Speicherung des geänderten Navigationsbaums in

einem Transportauftrag an die Methode UTIL_TRANSPORT_TREE delegiert, welche zu
Beginn eine erneute Validierung des hart hinterlegten SAP-System durchführt.
Nach Umschiffung der beiden Proben können Sie den geänderten Navigationsbaum
speichern und die Änderungen in andere Systeme transportieren.

IMPRESSUM
HINWEIS:
Wir weisen ausdrücklich darauf hin, dass das vorliegende Dokument nicht jeglichen
IMPRESSUM
Regelungsbedarf sämtlicher DSAG-Mitglieder in allen Geschäftsszenarien antizipieren

und abdecken kann. Insofern müssen die angesprochenen Themen und Anregungen
naturgemäß unvollständig bleiben. Die DSAG und die beteiligten Autoren können
bezüglich der Vollständigkeit und Erfolgsgeeignetheit der Anregungen keine Verant-
wortung übernehmen. Sämtliche Überlegungen, Vorgehensweisen und Maßnahmen
hinsichtlich des Verhaltens gegenüber SAP verbleiben in der individuellen Eigenver-
antwortung jedes DSAG-Mitglieds. Insbesondere kann dieser Leitfaden nur allgemeine
Anhaltspunkte zu vertragsrechtlichen Themen geben und keinesfalls eine individuelle
Rechtsberatung bei der Verhandlung und Gestaltung von Verträgen durch IT-rechtliche
Experten ersetzen.
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
Telefon +49 6227 35809-58
Telefax +49 6227 35809-59
E-Mail [email protected]
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.
WEITERE INFORMATIONEN:
Arbeitskreis Development, www.dsag.de/ak-development
© Copyright 2016 DSAG e.V.

Dsag Besteht Practice

Hochgeladen von

Copyright:

Verfügbare Formate

Dsag Besteht Practice

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Dsag Besteht Practice

Hochgeladen von

Copyright:

Verfügbare Formate

DSAG-HANDLUNGSEMPFEHLUNG

BEST PRACTICE LEITFADEN DEVELOPMENT –

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -2-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -3-

1 EINLEITUNG 8 3.4.2 Datenbankzugriffe 27

3.3 VORHANDENE WERKZEUGE NUTZEN 26 5.3 COMPLIANCE-PROBLEME DURCH ABAP 42

3.4 DATENMODELL UND DATENZUGRIFF 27 5.4 TESTWERKZEUGE 43

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -4-

7.1 UMSETZBARKEIT 47 9 ECLIPSE-ENTWICKLUNGSUMGEBUNG 67

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -5-

ANHANG B: WEITERFÜHRENDE BEISPIELE 91

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -6-

Abbildung 1: IKS-Risiken durch unsicheren ABAP-Quellcode 42

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -7-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -8-

• eine interaktive Navigation zu Schlüsselwortdokumentationen, Release-abhängi-

• die Nutzung aller verfügbaren ABAPDOCU-Funktionen (Export als HTML oder

• ihren hohen Bekanntheitsgrad und Quasi-Standard,

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -9-

• assen Sie das Dokument der SAP bei Bedarf in einer

1. Development Guidelines for Greenfield Implementation in sync with SAP Custom

6 Vgl. SCN-Artikel http://scn.sap.com/docs/DOC-56285

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -10-

• Durchgängige Verwendung domänenspezifischer Bezeichnungen

• Vermeidung abstrakter, nicht direkt zu verstehender Begriffe und Abkürzungen

7 Einschlägige Autoren / Bücher zu dem Thema sind:

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -11-

• Aufgabe eines individuellen Programmierstils zugunsten eines gemeinsamen BEST PRACTICE

Standards • Berücksichtigen Sie die oben genannten Vorgehens-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -12-

Team Teams sprache lung

9 Vgl. SAP Help Portal – Suche nach Schlagwort Package Builder

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -13-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -14-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -15-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -16-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -17-

1. Vortrag „Best Translation Practices in SAP Custom Development Projects“ von

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -18-

einer String-Variablen erstellt. Dadurch können komplizierte CASE-Abfragen vermie-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -19-

Es muss jederzeit möglich sein, durch manuelle Untersuchungen oder statische 1. E

2. Unterstützung des „Code2Data“-Paradigmas

emeint ist die Verlagerung von datenintensiven Operationen vom Anwendungs-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -20-

auf allen Datenbanken gegenüber Performanceoptimierung für SAP HANA

• Konstruktor-Operatoren VALUE und NEW

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -21-

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -22-

Kapitel 7, insbesondere Abschnitt 7.2.2 Automatische Prüfungen enthält übergreifende

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -23-

2.11 BERECHTIGUNGSPRÜFUNG IM QUELLCODE

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -24-

3. Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser 1990,

4. Wikipedia: Übersicht über Entwurfsmuster BEST PRACTICE

Performance-Optimierungen sollten (insoweit sie Aufwand oder Komplexität erhöhen)

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -25-

• DB05 – Wertverteilungs-Analyse für Index-Design

DSAG-HANDLUNGSEMPFEHLUNG – BEST PRACTICE LEITFADEN DEVELOPMENT -26-

• Risiken bei Qualitätsmängeln: Sabotage, Industriespionage, unerwünschte Presse