Best Practice Leitfaden Development

Transcription

Praxistipps rund um das Thema ABAP Development
Deutschsprachige SAP-Anwendergruppe e.V.
DSAG-Arbeitskreis SAP NetWeaver Development
Stand 31. Januar 2013
2
Praxistipps rund um das Thema ABAP Development
Version 0.11
Stand 31. Januar 2013
DSAG e. V.
Deutschsprachige SAP-Anwendergruppe
Autoren
> Peter Lintner, Senior Consultant, Allgemeines Rechenzentrum GmbH
Steffen Pietsch, Vice President, IBSolution GmbH
>
> Markus Theilen, IT-Koordinator, EWE AG
> Jürgen Wachter, Process Coordinator Development, comgroup GmbH
> Michael Werner, SAP Anwendungsberater (Inhouse), LTS AG Andernach
>Andreas Wiegenstein, Managing Director und Chief Technology Officer (CTO), Virtual Forge GmbH
Weitere Informationen zu den Autoren finden Sie auf Seite 57.
© Copyright 2013 DSAG e.V.
HINWEIS:
Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit
nicht ausdrücklich anders gekennzeichnet bei:
DEUTSCHSPRACHIGE SAP® ANWENDERGRUPPE E.V.
Altrottstraße 34 a
69190 Walldorf
Deutschland
Tel.:06227 - 35809 58
Fax:06227 - 35809 59
E-Mail: info@dsag.de
Internet: www.dsag.de
Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere für die Vervielfältigung,
Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen Systemen / digitalen
Medien.
Best Practice Leitfaden Development, 31. Januar 2013, © DSAG e. V.
3
4
Inhaltsverzeichnis
1Einleitung
7
1.1Motivation
7
1.2Positionierung
7
2Programmierrichtlinien
8
2.1Namenskonvention
8
2.2Namensraum
8
2.3Einheitlicher und lesbarer Quellcode: Pretty Printer
2.4Obsolete Anweisungen
12
9
2.5Syntax-Check und Code Inspector
12
2.6 Feste Codierung: Keine „magic numbers“
13
2.7Tipps beim Arbeiten mit Transporten
13
2.8 Berechtigungsprüfung im Quellcode
14
2.9 Programmiermodell: objektorientiert vs. prozedural
14
2.10 Weitere Quellen (Programmierrichtlinien/ABAP)
14
3Performance
15
3.1Vermeidungsprinzip
15
3.2 Vorhandene Werkzeuge nutzen
15
3.3 Performance-Optimierungen nur an kritischen und relevanten Stellen
16
3.4Datenmodell und Datenzugriff
16
3.4.1Datenmodell und Indizes
16
3.4.2Rahmenbedingungen bei Datenbankzugriffen
17
3.4.3Datenbankzugriffe
18
3.5Interne Tabellen und Referenzen
19
3.5.1Feldsymbole
21
3.5.2Parameterübergabe
21
3.6 Weiterführende Quellen
21
4Robustheit
22
4.1Fehlerbehandlung
22
4.1.1SY(ST)-SUBRC-Prüfungen
22
4.1.2MESSAGE-Anweisung
23
4.1.3Klassenbasierte Ausnahmen
23
4.1.4Nicht behandelbare Ausnahmen
24
4.2 Korrekte Implementierung von Datenbank-Änderungen
24
4.2.1Sperrobjekte
24
4.2.2Verbuchungskonzept
24
4.3Protokollierung
26
4.4Praxisbeispiele
26
4.4.1Unvollständige Fallunterscheidungen
26
4.4.2Wichtige sonstige SY(ST)-SUBRC-Prüfungen
27
27
5ABAP-Sicherheit und Compliance
28
28
5.1 Prüfungsrelevante Sicherheitsmechanismen im SAP-Standard
5.1.1Berechtigungsprüfung (A)
28
5.1.2Mandantentrennung (B)
28
5.1.3Nachvollziehbarkeit (C)
29
5.1.4Dreisystemlandschaft (D)
29
5.1.5Kontrollierte Ausführung von Betriebssystemkommandos (E)
29
5.1.6Kontrollierte Ausführung von SQL-Befehlen (F)
29
5.2Sicherheitsschwachstellen
30
31
5.3 Compliance-Probleme durch ABAP
5.4Testwerkzeuge
32
33
6Dokumentation
34
6.1Dokumentation unabhängig von Entwicklungsobjekten
34
6.2Dokumentation von Entwicklungsobjekten
35
6.3Dokumentation im Quelltext
35
6.3.1Dokumentation und Kommentierung von Anweisungen/Anweisungsblöcken
35
6.3.2Dokumentation von Änderungen
36
6.3.3Programmkopf
36
7Umsetzbarkeit und Durchsetzbarkeit
38
7.1Umsetzbarkeit
38
7.1.1Motivation für einen Prozess
38
7.1.2Erstellung und Pflege des Prozesses
39
7.2Durchsetzbarkeit
40
7.2.1Manuelle Prüfungen
40
7.2.2Automatische Prüfungen
41
7.2.3Werkzeuge
42
7.3Erfahrungen und Tipps aus der Praxis
42
7.3.1Qualitätssicherung des Quellcodes
42
7.3.2Zeit und Budget QA
43
7.3.3Probleme
43
7.3.4Entscheidungsfindung bei Modifikationen
44
7.3.5Erfahrungsbericht aus der Praxis: Comgroup GmbH
44
5
6
Inhaltsverzeichnis
8Infrastruktur und Lifecycle Management
46
8.1Infrastruktur
46
8.1.1Sandbox
46
8.1.2Entwicklungssystem
46
8.1.3Qualitätssicherungssystem
46
8.1.4Produktion
47
8.1.5Transportwesen
47
8.1.6Rückbau von Neuentwicklungen
48
8.1.7Sicherstellung der Konsistenz von Neuentwicklungen/Erweiterungen
48
8.2 Change Management
49
8.3Softwarewartbarkeit
52
8.4Anpassungen der SAP-Funktionalität
52
8.5Testbarkeit von Anwendungen
55
9Die Autoren
57
10Anhang: Namenskonventionen
58
10.1Allgemeine Namenskonventionen
58
10.2Attribute
59
10.3Methoden
60
10.4Signatur von Methoden
60
10.5Funktionsgruppen und -bausteine
60
10.6Enhancements
61
10.7Formulare
61
10.8Jobs
61
10.9Datenelemente
62
7
SAP-Software zeichnet sich als Standardsoftware durch ein hohes Maß an Flexibilität und Erweiterbarkeit aus. In nahezu allen Unternehmen, die SAP-Software einsetzen, finden sich kundenspezifische Anpassungen und Ergänzungen. Die SAP-Software unterliegt damit sowohl auf Herstellerals auch auf Kundenseite der kontinuierlichen Anpassung und Erweiterung an sich wandelnde
Kundenbedürfnisse.
Das hohe Maß an Flexibilität und Erweiterbarkeit von SAP-Software bringt Vor- und Nachteile mit
sich: Die Software kann optimal an kundenspezifische Anforderungen angepasst und damit die Wertschöpfung durch den Einsatz deutlich gesteigert werden. Zeitgleich birgt die Erweiterbarkeit das
Risiko kundenspezifischer Entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind.
Das Ziel dieses Dokuments ist es, Praxistipps und Denkanstöße zu liefern, um kundenspezifische
Entwicklungen wartbar und effizient zu gestalten.
1.1Motivation
Die Arbeit der Deutschsprachigen SAP-Anwendergruppe e.V. (DSAG) fußt auf drei 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 und damit
den Wissensvorsprung für Anwender und Partner.
Als Autorenteam ist es unser Anliegen, das in den Unternehmen verteilt und implizit vorliegende
Wissen zum Thema Entwicklung in einem kompakten Dokument anderen DSAG-Mitgliedern zur
Verfügung zu stellen. Unser Wunsch ist, dass dieses Dokument „lebt“ und mit Ihrem Erfahrungsschatz einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf Ihr Feedback (am besten
per E-Mail an handlungsempfehlung@dsag.de)!
1.2Positionierung
Es existieren bereits von der SAP und einer ganzen Reihe von Fachverlagen sehr gute Publikationen zu Anwendungsentwicklung und Erweiterung der SAP-Plattform. Insbesondere haben auch
Autoren der SAP mit dem Buch „ABAP-Programmierrichtlinien“, SAP Press 2009 bereits einen
Vorstoß in Richtung von Empfehlungen unternommen, die über reine Beschreibungen der Sprache
ABAP und der zugehörigen Werkzeuge hinausgehen.
Der Mehrwert dieses Dokuments liegt in der Zusammenfassung bewährter Vorgehensweisen,
Praxistipps und erprobter Regelwerke aus den Anwenderunternehmen. Diese Guideline soll Ihnen
als Anwender, Entwickler, Entwicklungs-, Projekt- oder IT-Leiter Anregungen und Hilfestellung
geben, um „das Rad nicht immer wieder neu erfinden zu müssen“, sondern auf die Erfahrungen
anderer aufbauen zu können. Dabei erheben die in dieser Guideline vorgestellten Empfehlungen
nicht den Anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eine
Auswahl von Praxistipps dar.
Als Autorenteam haben wir uns darum bemüht, im Spannungsfeld zwischen Überblickswissen und
Detailtiefe den richtigen Mix zu finden. Daher verweisen wir an entsprechenden Stellen auf weiterführende Quellen, um nicht ausführlich diskutierte Themen redundant wiederzugeben. Die erste Auflage dieser Guideline ist auf den Bereich ABAP-Entwicklung fokussiert. Bei entsprechendem
Feedback und Ihrer aktiven Unterstützung kann der Fokus auf die JAVA-Entwicklung und weitere
Themen ausgeweitet werden.
1einleitung
8
Dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für Anwendungen, die
mit Hilfe der Programmiersprache ABAP erstellt werden. Es wird beschrieben, wie mit StandardSAP-Mitteln und Disziplin sauber lesbarer und verständlicher ABAP Code entwickelt werden kann.
Dies erleichtert die Wartung des Codes bzw. ermöglicht, dass verschiedene interne und externe
Personen effizient an der (Weiter-) Entwicklung und Wartung eines Programms zusammenarbeiten.
2.1Namenskonvention
Namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung von
Softwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur Benennung von Objekten im
Quellcode (z.B. Variablen).
Wir empfehlen ausdrücklich eine Namenskonvention als Richtlinie für Entwicklungen im SAPSystem vorzugeben. Das Ziel der Verwendung einer einheitlichen Namenskonvention ist die
deutliche Steigerung der Wartbarkeit kundenspezifischer Anpassungen und Erweiterungen. In der
Konsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnelleren
Problemlösung im Fehlerfall.
Die explizit formulierte Namenskonvention sollte Bestandteil der internen Ausbildung sein, um
neue Mitarbeiter mit den Grundregeln und Unternehmensspezifika vertraut zu machen. Zudem hat
es sich bewährt, diese Namenskonvention zum Vertragsgegenstand für externe Entwickler und
Partnerunternehmen zu machen. Automatisierte Überprüfungen stellen die Einhaltung sicher (vgl.
Kapitel 7).
BEST PRACTICE: Eine exemplarische Namenskonvention als Vorlage finden Sie im Anhang.
2.2Namensraum
Die Trennung von Kundenobjekten und SAP-Objekten kann über die Präfixe Y oder Z sowie über
einen eigenen Namensraum erfolgen. Die Syntax lautet wie folgt:
Z…
Y…
/<kundeneigener Namensraum>/…
Der kundeneigene Namensraum kann bei SAP registriert werden und ist nach Bestätigung
weltweit eindeutig und für das jeweilige Unternehmen zur Verwendung registriert. Dieses Vorgehen
unterstützt bei der konfliktfreien Vergabe von Namen für Softwareobjekte.
Der Vorteil des kundeneigenen Namensraums liegt in der garantierten Überschneidungsfreiheit
beim Import fremder Objekte in das eigene SAP-System (z.B. beim Einsatz von Fremdanwendungen, die per Transportauftrag eingespielt werden) und bei Zusammenführungen von SAP
Systemen im Rahmen einer Post-Merger Integration. Durch die Reservierung des Namensraums
ist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten System ein Softwareobjekt mit
dem gleichen Präfix erstellt werden kann.
Der Nachteil bei der Verwendung des kundeneigenen Namensraums liegt darin, dass durch die
durchgängige Verwendung des Präfixes bereits mehrere Zeichen „verbraucht“ werden. Dies kann
insbesondere bei Objekten, die nur wenige Zeichen zur Benennung bieten, zu Schwierigkeiten
führen. Darüber hinaus unterstützen nicht alle Objekttypen, z.B. Berechtigungsobjekte, die
Verwendung von Namensräumen.
BEST PRACTICE: Wir empfehlen ausdrücklich die Verwendung eines kundeneigenen Namensraums.
WEITERE QUELLEN:
1. http://help.sap.com (Namensraum einrichten)
2. Best-Built Applications: http://scn.sap.com/community/best-built-applications
2.3Einheitlicher und lesbarer Quellcode: Pretty Printer
Übersichtlicher, leserlicher Code erleichtert jedem Entwickler die (erneute) Einarbeitung in
Quellcode. Als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zu
halten, kann der Pretty Printer aus der ABAP-Entwicklungsumgebung genutzt werden. Mit einem
einzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. Er bietet verschiedene
Möglichkeiten, die über die Einstellungen der Workbench konfigurierbar sind. Bereits eine
eingerückte Darstellung macht Source Code deutlich lesbarer. Es wird empfohlen, Schlüsselwörter
groß darzustellen. Denn dadurch kann man Quelltext auch in ausgedruckter Form und ohne
Syntaxeinfärbung noch leicht verstehen. Der Pretty Printer ermöglicht auf einfachem Weg die
Erstellung von einheitlichem Quellcode trotz unterschiedlicher Entwickler.
Um die Lesbarkeit des Quelltextes zu erhöhen, empfehlen wir, auf mehrere Anweisungen in einer
Codezeile zu verzichten.
Wir empfehlen, die Option „Standardkommentare einfügen“ zu deaktivieren, da die erzeugten
Kommentare bei Änderungen nicht automatisch angepasst werden und redundante Informationen
enthalten.
BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die Einstellungen als
einheitliche Vorgabe zu definieren.
Modularisierung
Programme, in denen logische Verarbeitungseinheiten nicht aufgeteilt werden, sind in weiterer
Folge schwer lesbar und damit schwer wart- und erweiterbar.
Eine Modularisierungseinheit (Form-Routine, Methode, Funktionsbaustein) soll logisch zusammengehörende Anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen
Einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigen
Anweisungen sind jedoch zu vermeiden.
Die Modularisierung dient dazu, trotz Komplexität in der Aufgabenstellung, den Programmcode
übersichtlich zu gestalten. Zudem sind Programmabschnitte mit derselben Logik zu vermeiden.
Für die praktische Umsetzung kann es hilfreich sein, vor Beginn des Programmierens die ersten
Codezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend auszuprogrammieren.
Wo es möglich und sinnvoll ist, ist es ratsam, vom prozeduralen Programmiermodell auf objektorientierte Programmierung überzugehen, um zukunftssicher zu entwickeln und Objekte zu
kapseln. Insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden.
Im Rahmen der Einführung von ABAP Objects fand eine Bereinigung der Sprache und Vereinheitlichung der Konstrukte statt. Die Verwendung von ABAP Objects führt damit zu einer Steigerung der
Wartbarkeit.
9
10
Trennung von Präsentations- und Anwendungslogik
In allen Programmen sollte stets eine Trennung von Präsentations- und Anwendungslogik
erfolgen. Dies erlaubt es, Ergebnisse und Funktionen der Anwendungslogik durch verschiedene
UIs (User Interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche Schnittstelle anderen
Systemen bereitzustellen. Diese Aussage ist für alle gängigen UI-Technologien gültig, wobei der
Grad der Unterstützung bzw. Einhaltung dieser logischen Trennung unterschiedlich ist. In einer
WebDynpro ABAP-Realisierung ist schon vom Framework eine Trennung zwischen Modell- und
UI-Logik vorgesehen. Bei klassischen Dynpros und BSPs wird die Trennung nicht in gleicher Weise
forciert, aber grundsätzlich kann und sollte die Trennung auch in diesen Umgebungen umgesetzt
werden. Allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu WebDynpro, wo
entsprechende Prüfungen im Code Inspector realisiert sind.
Ein typisches Beispiel für eine klare Trennung von Anwendungslogik und UI sind Plausibilisierungsregeln. Wenn die Plausibilisierung von Eingaben in einer bestimmten UI-Technologie
entwickelt wird, müssen diese Prüfungen bei einem Wechsel auf eine andere UI-Technologie neu
entwickelt werden. Um dies zu vermeiden, müssen die Funktionen zur Prüfung von Eingaben oder
Parametern unabhängig von der verwendeten UI erstellt und gepflegt werden.
Internationalisierung
Sprachabhängige Texte in Programmen dürfen nicht „hart codiert“ werden, sondern müssen in
Textelementen (Programmtexte, Klassentexte, Online-Text-Repository [OTR]), Standardtexten oder
Nachrichtenklassen hinterlegt werden. Da alle Eigenentwicklungen den Anspruch haben sollten,
weltweit eingesetzt zu werden, sollten die wichtigsten Sprachen übersetzt werden.
Zudem müssen sprachabhängige (customizebare) Texte in eigenen Texttabellen abgelegt werden.
Diese Texttabelle besitzt dieselben Schlüsselattribute wie die eigentliche Customizing-Tabelle.
Zusätzlich muss das erste Schlüsselattribut nach dem Mandantenfeld das Sprachenattribut sein
(Datenelement SPRSL oder SPRAS). Zudem muss die Fremdschlüsselbeziehung als jene der
Texttabelle gekennzeichnet werden.
BEST PRACTICE: Wir empfehlen, den Code Inspector für die Suche nach nicht übersetzbaren
Texten zu verwenden.
BEST PRACTICE: Um spätere Übersetzungen einfach zu gestalten, sollte die Länge der Feldbezeichner und Textelemente möglichst lang gewählt werden. Als Faustregel für die Länge von
Textelementen hat sich bewährt, die 1,5-fache Länge der nativen Beschreibung vorzusehen.
Dynamische Programmierung
In der „klassischen“, statischen Entwicklung werden Entwicklungsobjekte und der Quellcode zur
Designzeit definiert und im SAP-System statisch hinterlegt. Zur Laufzeit wird der vorgegebene
Programmcode ausgeführt. Im Gegensatz dazu ermöglicht die dynamische Programmierung die
Flexibilisierung des Quellcodes. Folgendes Beispiel verdeutlicht die dynamische Programmierung:
Im Programmcode wird der Name einer aufzurufenden ABAP-Klasse nicht statisch hinterlegt,
sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren Name durch den Inhalt einer
Variablen definiert ist. Dieser Name kann z.B. aufgrund von Benutzereingaben variieren.
Der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität. Der Nachteil liegt in der signifikant
steigenden Komplexität und insbesondere in den damit einhergehenden Sicherheitsrisiken.
Vorteil:
>Deutliche Steigerung der Flexibilität
>
Beispiel 1: Eigener Aufbau von User Exits
Durch die statische Definition einer abstrakten Klasse inkl. Methodensignatur wird das Grund
gerüst für einen „User Exit“ vorgegeben. Anschließend können mehrere konkrete Impleme
tierungen dieser abstrakten Klasse angelegt werden. Innerhalb Quellcodes wird z.B. a
us einer
Customizing-Tabelle der Name der zu verwendenden konkreten Klassenimplementierung
gelesen und diese aufgerufen. Somit können unterschiedliche Implementierungsvarianten per Customizing aktiviert/deaktiviert werden.
>
Beispiel 2: Dynamische WHERE-Bedingung
Zur Laufzeit wird die WHERE-Bedingung für eine Datenbankoperation, z.B. SELECT, in einer String-Variablen erstellt. Dadurch können komplizierte CASE-Abfragen vermieden werden,
die abhängig von den Eingaben verschiedene OSQL-Befehle ausführen.
Nachteil:
>Durch die Nutzung von dynamischen Aufrufen geht der Verwendungsnachweis innerhalb der ABAP- Entwicklungsumgebung verloren. Problematisch sind dann Änderungen an den Aufrufzielen. Ein Entwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der von einem Programm dynamisch aufgerufen wird, bemerkt diese Verwendung über den Verwendungs-
nachweis nicht.
> Bei der dynamischen Programmierung ist i.d.R. zur Designzeit keine syntaktische Prüfung möglich; bei fehlerhafter Belegung der variablen Inhalte (z.B. fehlerhafte Klammerung innerhalb einer dynamischen WHERE-Klausel, fehlerhafter Name einer Klasse) kommt es zu einem ungeplanten Abbruch des Programms (Kurzdump).
>Dynamische Programmierung birgt hohe Sicherheitsrisiken, insbesondere dann, wenn die dynamischen
Inhalte durch ungeschützten Zugriff beeinflussbar sind (z.B. wenn der Name einer a
ufzurufenden
Klasse /eines Funktionsbausteins oder einer WHERE-Bedingung durch Benutzereingaben beein flusst werden kann, Stichwort: Code Injection).
BEST PRACTICE: Dynamische Programmierung sollte nur sehr dosiert und kontrolliert zum Einsatz
kommen. Programmcode, der dynamische Anteile enthält, sollte nach dem Vier-Augen-Prinzip
kontrolliert und dokumentiert werden, denn er stellt ein potenzielles Sicherheitsrisiko dar.
Im Kapitel 5.2 wird das Thema dynamische Programmierung auch im Kontext Sicherheit behandelt.
11
12
Auditierbarkeit von ABAP Code
Es muss jederzeit möglich sein, durch manuelle Untersuchungen oder statische CodeanalyseTools den selbst geschriebenen ABAP Code auf Mängel zu untersuchen. Alle Methoden, ABAPCoding unsichtbar zu machen, sind daher unzulässig, da sie solche Untersuchungen behindern
oder gar gezielt dafür verwendet werden könnten, Hintertüren in ein System zu schleusen.
Verschleierter Code kann auch mit dem Debugger nicht mehr untersucht werden. Es wird an
dieser Stelle explizit darauf verzichtet, die Techniken zu erläutern, mit denen Code versteckt
werden kann.
BEST PRACTICE: Verwenden Sie insbesondere in der Entwicklung im eigenen Unternehmen keine
Techniken, um Ihren Quellcode zu verstecken.
2.4Obsolete Anweisungen
Obwohl SAP eine strikte Abwärtskompatibilität vertritt, muss bei der Verwendung von obsoleten
Anweisungen, wie z.B. Kopfzeilen in internen Tabellen, berücksichtigt werden, dass hierbei
Probleme auftreten, wenn der Code in Klassen übernommen werden soll. Hier ist zu beachten,
dass es für obsolete Sprachelemente immer modernere Alternativen gibt. Es gibt also eigentlich
außer Gewohnheit wenige Gründe für deren Verwendung, deshalb sollten sie vermieden werden.
BEST PRACTICE: Wir empfehlen den regelmäßigen Einsatz eines statischen Codeanalyse-Tools,
um obsolete Anweisungen zu entdecken. Aus den SAP-Bordmitteln eignet sich hierzu der Code
Inspector bzw. die Durchführung des Syntax-Checks.
Darüber hinaus existieren sehr gute Analysewerkzeuge von Drittanbietern.
2.5Syntax-Check und Code Inspector
Der Syntax-Check und der Code Inspector ermöglichen die Überprüfung des Programmcodes
während der Designzeit.
Bei der Freigabe von Transporten kann der Code Inspector über die SE03 global angeschaltet
werden, um Fehler zu erkennen. Hierdurch kann auch die Anzahl der Transporte verringert
werden, da beim Erkennen von Fehlern die Freigabe noch abgebrochen werden kann. Die
Behebung kann dann in den bestehenden Auftrag aufgenommen werden und es muss kein neuer
Transport erzeugt werden.
BEST PRACTICE: Der Code Inspector wird im SAP-Standard nur bei Freigabe des Transportauftrags ausgeführt. Empfehlenswert ist jedenfalls die Prüfung durch den Code Inspector bereits bei
der Freigabe der jeweiligen Transportaufgabe.
WEITERE QUELLEN:
Die Vorgehensweise der Implementierung des dafür notwendigen BAdIs ist im Buch „Praxishandbuch SAP Code Inspector“ (SAP Press) beschrieben.
2.6
Feste Codierung: Keine „Magic Numbers“
Die feste (harte) Codierung von Texten, Zahlen, User-Namen, Organisationseinheiten, Datum etc.
sollte im Quelltext ausdrücklich vermieden werden.
Während der Entwicklung kann die direkte Verwendung von hart codierten Werten vermeintlich als
schnelle Vorgehensweise erscheinen. Auf den Gesamtlebenszyklus der Anwendung bezogen, führt
sie jedoch zu deutlich erhöhten Kosten. Die Wartbarkeit und Testbarkeit der Anwendung werden
langfristig deutlich erschwert.
BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler Stelle definiert
werden. Für die Konstantendefinition eignen sich z.B. die Attribute globaler Klassen bzw. Interfaces.
BEST PRACTICE: Alternativ zu harten Codierungen im Quelltext können kundeneigene Customizing-Tabellen verwendet werden. In diesen Tabellen werden die Werte, z.B. Zahlen, Organisationseinheiten etc. als Konfiguration hinterlegt und bei Programmstart in eine Variable gelesen.
Anschließend wird ausschließlich mit dieser Variablen gearbeitet.
Die o.g. Vorgehensweisen steigern bei Mehrfachgebrauch die Konsistenz und Effizienz der Analyse
im Fehlerfall bzw. bei regulären Wartungstätigkeiten. Wir empfehlen ausdrücklich die Kommentierung der Konstanten und die Bedeutung der Werte an zentraler Stelle.
Um neue Mitarbeiter bei der Ermittlung von Konstanten zu unterstützen, bietet es sich an, diese
entweder außerhalb des Systems durchsuchbar zu dokumentieren oder ein Suchtool (s. „Weitere
Quellen“) zur Verfügung zu stellen, mit dem innerhalb des Systems nach Konstanten gesucht
werden kann.
2.7Tipps beim Arbeiten mit Transporten
Wenn mehrere Entwickler an einem Entwicklungsobjekt Änderungen vornehmen, kann dies unter
Umständen zu Problemen führen, wenn die Transportaufträge nicht in der richtigen Reihenfolge in
die produktiven Systeme transportiert werden oder andere Objekte aus anderen Transportaufträgen
fehlen.
BEST PRACTICE: Um dies zu vermeiden, sollte mit Transport von Kopien gearbeitet werden. Dabei
werden die geänderten Entwicklungsobjekte durch den eigentlichen Transportauftrag im
Entwicklungssystem gesperrt und über Transport von Kopien werden nur Kopien der Objekte in
das Qualitätssicherungssystem transportiert. Ein Entwickler bemerkt sofort, dass ein anderer
Entwickler ggf. das Objekt bereits bearbeitet, und kann sich mit dem anderen Entwickler
abstimmen. Nach Abschluss des „Projektes“ wird nur der Original-Sperrtransport ins Produktivsystem transportiert.
13
14
2.8 Berechtigungsprüfung im Quellcode
Bei Zugriff auf Daten und auch deren Präsentation sind die dafür notwendigen Berechtigungsobjekte zu prüfen. Bei der Verwendung von Standardobjekten soll jedenfalls die Prüfung auf die
entsprechenden SAP-Standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung der
notwendigen Rollen). Für kundeneigene Datenobjekte können in der Regel keine SAP-StandardBerechtigungsobjekte zur Prüfung verwendet werden. Zu diesem Zweck können kundeneigene
Berechtigungsobjekte implementiert und geprüft werden.
Weitere Informationen finden sich im Kapitel 5.1.1
2.9 Programmiermodell: Objektorientiert vs. Prozedural
Die prozedurale Entwicklung in ABAP ist inzwischen von SAP als obsolet eingestuft worden.
Insbesondere die Befehle FORM…ENDFORM und PERFORM sind als obsolete Anweisungen
eingestuft. Prozedurale Entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globale
Variablen und Includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen.
Objektorientierte Entwicklung wurde so konzipiert, dass logisch zusammenhängende Aufgaben
einheitlich in Objekten zusammengefasst werden können. Dadurch wird unter anderem auch die
Wiederverwendbarkeit von Code erhöht. Insbesondere können solche Objekte auch von anderen
Entwicklern für ihre Zwecke leicht erweitert oder verändert werden, ohne dass die grundlegenden
Funktionen beeinträchtigt werden (Open-Close-Prinzip). Andererseits können zentrale Funktionalitäten oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder Schreibzugriff durch
aufrufende Programme geschützt werden.
BEST PRACTICE: Wir empfehlen bei Neuentwicklungen möglichst nur noch mit Klassen und
Methoden zu arbeiten und keine FORMs mehr zu verwenden.
WEITERE QUELLEN:
1. Horst Keller und Gerd Kluger, Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look, Sap Professional Journal
2. Horst Keller and Gerd Kluger, NetWeaver Development Tools ABAP, SAP AG
3. Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser 1990, ISBN 3-446-15773-5
4. ConSea-Projekt für Suche nach Konstanten auf SAP Code Exchange:
https://cw.sdn.sap.com/cw/groups/consea
2.10 Weitere Quellen (Programmierrichtlinien / ABAP)
1.SAP Dokumentation SAP NetWeaver AS ABAP Release 731
http://help.sap.com/abapdocu_731/de/index.htm
In dieser Dokumentation ist dem Thema Programmierrichtlinien ein eigenes Kapitel gewidmet.
15
In den folgenden Abschnitten empfehlen wir einige Regeln, die bei der täglichen Arbeit in der
ABAP-Entwicklung beachtet werden sollten, um von vorneherein Performance-Engpässe zu
vermeiden. Wie an viele anderen Stellen der Softwareentwicklung hilft es auch im Hinblick auf eine
ausreichende Performance zu wissen, was gemacht werden soll. Solange der Sinn und Zweck
eines Code-Stückes nicht klar ist, sollte dies zuerst geklärt werden.
3.1Vermeidungsprinzip
„Die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und am
leichtesten zu dokumentierenden Teile eines Computersystems sind die, die man weggelassen
hat.“ (Gorden Bell)
BEST PRACTICE: Vermeiden Sie jegliches unnötige Coding.
Frei nach diesem Motto sollten Sie auch genau prüfen, welcher Code wirklich für die Produktion
gedacht ist, und sämtliche Test- und Demo-Programme spätestens auf den Q-Systemen löschen.
Aber auch innerhalb von produktivem Coding sollte immer der Ansatz verfolgt werden, nicht mehr
zu tun, als für die Aufgabe wirklich benötigt wird. Ein einleuchtendes Beispiel dafür ist die Regel
zur Vermeidung von *-SELECTs, bei denen der Einfachheit halber alle Spalten einer Tabelle
selektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige Spalten benötigt
werden.
Anmerkung: Diese Vorgehensweise steigert gleichzeitig die Robustheit von Programmen.
Das Lesen mit Hilfe von *-SELECT in eine kundeneigene Datenstruktur kann zu Fehlern nach
einem Upgrade führen,wenn die Standardtabelle durch SAP erweitert wurde. Das explizite Lesen
benötigter Spalten schützt vor dieser Unschärfe.
3.2 Vorhandene Werkzeuge nutzen
Die im SAP-System bereits vorhandenen Werkzeuge bieten gute Unterstützung bei der Erstellung
von performanten Anwendungen bzw. bei der Analyse von Performance-Engpässen. Diese
Werkzeuge sollten frühzeitig und in allen Lebensphasen der Software angewendet werden.
Die nachfolgende Tabelle bietet einen Überblick zu den zentralen Werkzeugen:
Entwicklung
Beschreibung
Code Inspector
Statische Code-Analyse und -Prüfungen
SE30 / SAT
Laufzeit-Traces
ST05
Traces für SQL, RFC und Enqueues
DB05
Wertverteilungs-Analyse für Index-Design
3Performance
16
3Performance
Laufzeit
Beschreibung
SM50/SM66
Übersicht Workprozesse/Applikationsserver
Debugger
Schrittweises Ausführen von Coding
Memory Inspector
Vergleich und Analyse von Speicherabzügen zur
Ermittlung von nicht Speicherverbrauch und nicht
freigegebenen Heap-Objekten
ST10
Tabellenaufruf-Statistiken zur Prüfung von
Tabellenpufferung
Post Mortem
Beschreibung
ST22
Analyse von Laufzeitfehlern (z.B. bei Speichermangel)
STAD
Workload-Analyse
ST04
DB-Performance-Übersicht
BEST PRACTICE: Starten Sie die Performance-Untersuchung mit einem Trace in der SE30/SAT und
konzentrieren Sie sich auf den größeren Zeittreiber. Wenn die meiste Zeit im ABAP-Teil verbraucht
wird, analysieren Sie weiter mit der SE30/SAT. Liegt die meiste Zeit bei den DB-Aufrufen, starten
Sie einen SQL-Trace mit der ST05.
3.3
Performance-Optimierungen nur an kritischen und relevanten Stellen
Auch wenn man nicht performante Konstrukte bei der Softwareentwicklung immer vermeiden
sollte, sollte man sich gleichzeitig bei der Notwendigkeit von umfangreicheren Performance-Optimierungen auf die Teile der Software beschränken, die durch Messung nachgewiesenermaßen die
Ursache von langer Laufzeit oder erhöhtem Speicherverbrauch sind. Auch für Performance-Aspekte trifft die 80/20-Regel zu und es gilt daher, die meistens raren Ressourcen für eine umfangreiche Verbesserung auf die 20 % des Systems zu konzentrieren, die für 80 % der Laufzeit/des
Speicherverbrauchs verantwortlich sind. Um an diese Stellen zu gelangen, ist der sinnvolle Einsatz
der genannten Werkzeuge essenziell.
BEST PRACTICE: Wir empfehlen, die Suche nach Performance-Engpässen mit dem Einsatz der
Laufzeitanalyse SE30/SAT mit voller Aggregation zu beginnen. Dadurch sollte deutlich werden, ob
die Laufzeit aus der Interaktion mit der Datenbank oder der Verarbeitung der geladenen Daten im
Hauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher Datenbestand
verarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen Spur zu folgen. Wird
mehr als die Hälfte der Laufzeit im DB-Teil verbraucht, sollte eine genauere Analyse der SQLKommandos mit der Transaktion ST05 erfolgen. Wird mehr Laufzeit im ABAP-Teil verbraucht,
erfolgen tiefergehende Analysen mit Hilfe der SE30/SAT, wobei die Aggregationsstufen schrittweise
verringert werden, um genauere Aussagen über die kritischen Programmstellen zu bekommen.
Nach jedem Optimierungsschritt sollten die Ergebnisse verglichen und dokumentiert werden.
3.4Datenmodell und Datenzugriff 3.4.1Datenmodell und Indizes
Der Aufbau des Datenmodells bildet die Basis performanter Anwendungen. Ein mit Augenmaß
normalisiertes Datenmodell kann effizienter mit Daten und Indizes arbeiten. Hierzu finden – unabhängig von der Programmiersprache ABAP – die Normalisierungsregeln Anwendung.
Beim Einsatz von Indizes für Tabellen empfehlen wir folgende Punkte:
>Es sollten max. fünf Indizes pro Tabelle existieren, wenn häufig ändernd auf diese Tabellen zugegriffen wird. Mit jedem Index steigen die Verwaltungskosten, die bei Datenänderungen anfallen.
> Fünf Felder pro Index sollten als Obergrenze eingehalten werden.
>In einem Index sollten nur selektive Felder aufgenommen und in der Reihenfolge nach absteigender Selektivität sortiert werden.
>Auf Feldebene sollten zwischen zwei Indizes einer Tabelle keine Überlappungen auftreten.
> Bei mandantenabhängigen Tabellen sollte das Feld „Mandant“ als erstes Feld aufgenommen werden,
insbesondere bei großen Tabellen (>1000 Einträge). Auch wenn dieses Feld nicht sonderlich selektiv
ist und damit der dritten Regel widerspricht, wird bei jeder Abfrage dieses Feld in der Selektion
vom SAP-System mit übergeben und ausgewertet. Gerade bei Tabellen mit stark unterschiedlichen
Eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im Index negativ auswirken.
3.4.2Rahmenbedingungen bei Datenbankzugriffen
Folgende Fragen sollten bei DB-Zugriffen gestellt und beantwortet werden:
>Sind Indizes in geeigneten Rahmen angelegt?
>
s. vorheriges Kapitel (3.4.1)
> Lesen Anweisungen am Tabellenpuffer vorbei?
Hierbei kann die Transaktion ST10 verwendet werden, um die Zugriffshäufigkeiten auf gepuffer-
ten Tabellen zu überprüfen. Mit der Transaktion ST05 können mit dem kombinierten SQL- und Puffer-Trace Zugriffe ermittelt werden, die wider Erwarten den Tabellenpuffer nicht verwenden. Und mit Hilfe des Code Inspectors lassen sich viele dieser Statements bereits im Vorfeld statisch ermitteln.
> Kann ein DB-Index zur Sortierung auf der DB mit ORDER BY genutzt werden?
Im einfachsten Fall kann dafür der Zusatz PRIMARY KEY verwendet werden, wenn die Sortierung nach dessen Feldern erfolgen soll. Sind andere Sortierungen erforderlich, kann es helfen, einen Index anzulegen, der die gewünschten Felder in der korrekten Reihenfolge enthält. Allerdings sollten dabei die Hinweise zur Anzahl von Indizes pro Tabelle beachtet werden. Erfolgt der Zugriff mit ORDER BY nur selten, lohnt es sich in der Regel nicht, dafür einen eigenen Index anzulegen. In diesem Fall sollte die Sortierung im ABAP erfolgen, sofern dies die zu sortierende Datenmenge zulässt.
17
18
3Performance
Beispiel: Die Tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nach diesem Datum ermittelt werden. In diesem Fall würde sich ein Index über dieses Feld wahr-
scheinlich rentieren, weil zum einen dieses Feld in der WHERE-Bedingung enthalten ist und gleichzeitig der Zusatz ORDER BY Belegdatum vom vorhandenen Index profitiert.
3.4.3Datenbankzugriffe
Die auf der Datenbank selektierte und an die Anwendungsschicht zu übergebende Datenmenge
sollte grundsätzlich so gering wie möglich gehalten werden. Nachfolgend finden Sie Hinweise, wie
Sie dies im konkreten Fall umsetzen können.
BEST PRACTICE:
>Spaltenreduzierung:
Vermeiden Sie *-Selektionen und benennen Sie stattdessen die benötigen Spaltennamen in der
Selektion. Insbesondere das unnötige Laden von Spalten des Typs String ist teuer.
Die Ergebnistabelle sollte mit der Selektionsstruktur übereinstimmen, um optimale Ergebnisse zu
erzielen. Sollten in der Ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschten
Felder namensgleich angelegt sein, ist auch der Zusatz CORRESPONDING FIELDS möglich und
führt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die Robustheit der Software erhöht.
>Optimale Suchabfrage
Versuchen Sie für die Selektion von Daten möglichst nur Abfragen zu verwenden, die einen der
vorhandenen Indizes vollständig nutzen. Sollte das nicht möglich sein, achten Sie möglichst darauf,
zumindest die ersten Elemente des Index zu verwenden, damit die zeilenweise Suche auf eine
möglichst kleine Menge von Datensätzen reduziert werden kann.
>Zeilenreduzierung
Nutzen Sie die WHERE-Bedingungen, indem Sie die Selektion beschreiben und die an das
ABAP-System zu übermittelnden Daten minimieren.
Verwenden Sie SELECT SINGLE / UP TO n ROWS, wenn Sie nur einzelne Zeilen benötigen.
>Existenzchecks
Die Prüfung, ob Datensätze, die einem bestimmten Selektionskriterium genügen, existieren,
sollten nicht mit der Anweisung COUNT(*), sondern mit SELECT SINGLE <Feldname> erfolgen,
wobei das genannte Feld aus dem zur Selektion verwendeten Index stammen sollte. Dies
vermeidet unnötige Zugriffe auf die Tabellendaten.
>Aggregate
Aggregate (MIN, MAX, …) werden immer auf dem Datenbankserver ausgewertet. Dadurch wird die
Tabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem DB-System, das in vielen Installationen von sehr vielen Applikationsservern angesprochen wird, sollten
Entwickler prüfen, welche Datenmenge für das Aggregat verwendet werden muss und ob es sich
lohnen kann (sofern diese nicht groß ist), die Daten in eine interne Tabelle zu laden und das
Aggregat dort durchzuführen. Allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem
Kenntnisstand insbesondere HANA-basierte Datenbankabfragen gerade bei Aggregaten ihre
Stärken haben und damit deren Einsatz für HANA explizit sinnvoll ist.
Beispiel: Um den durchschnittlichen Wert über eine große Anzahl (>100000) von Bestellungen zu
ermitteln, ist es sinnvoll, dieses Aggregat auf dem DB-System ermitteln zu lassen, um nur einen
oder wenige Werte statt hunderttausender an die Applikationsserver übermitteln zu lassen, um
dort den Durchschnittswert im ABAP zu berechnen. Dies gilt insbesondere, wenn diese Auswertung nur selten (z.B. einmal pro Tag) erfolgt. Soll hingegen die Summe der Bestellpositionen eines
einzelnen Auftrags sehr häufig und von allen vorhandenen Applikationsservern ermittelt werden,
ist die Ermittlung im ABAP wahrscheinlich die für die Gesamtsituation günstigere Variante.
>Updates
Die Anweisung UPDATE SET ermöglicht das Übertragen von einzelnen zu ändernden Feldern (statt
des gesamten Datensatzes). Wenn möglich, sollte diese Anweisung bevorzugt verwendet werden.
>Ausführungshäufigkeit bei DB-Zugriffen
Jede Ausführung eines Open SQL-Statements ist mit einem gewissen Overhead (Parsen, Abgleich
gegen Statement-Puffer im DBMS usw.) verbunden. Daher sollten pro Statement möglichst viele
der benötigten Daten auf einmal übertragen werden. Werden beispielsweise die Daten von 50
Aufträgen benötigt, sollten diese nicht durch 50 Einzelaufrufe ermittelt werden, sondern durch ein
einzelnes Statement, das die sog. Array-Zugriffe unterstützt. Diese sind durch die Zusätze INTO
TABLE bei SELECTS bzw. FROM TABLE bei schreibenden Zugriffen zu erkennen. Vermeiden Sie auf
jeden Fall Open SQL-Statements innerhalb von Schleifen! Bei einem solchen Konstrukt fällt der
Overhead für diese Statements bei jedem Schleifendurchlauf an.
Setzen Sie MODIFY <DB-Tabelle> nicht ein! Erstens sollte innerhalb einer Applikation klar sein, ob
Datensätze neu erstellt wurden oder vorhandene angepasst werden müssen. Zweitens ist dieses
Statement aus Performance-Gesichtspunkten sehr kritisch: Selbst mit dem Zusatz FROM TABLE
werden einzelne Zugriffe pro Zeile der internen Tabelle ausgeführt und dabei wird jeweils zuerst
ein UPDATE versucht und im Fehlerfall ein INSERT nachgelegt. D.h., bei vielen neu zu erstellenden
Datensätzen erfolgen nicht n Einzelzugriffe, sondern 2n mit n=Anzahl neue Datensätze in der
internen Tabelle.
>VIEWS/JOINS
Geschachtelte SELECT-Anweisungen und SELECT-Anweisungen in Schleifen sollten vermieden
werden. Stattdessen bieten sich VIEWS, JOINS oder der Zusatz FOR ALL ENTRIES an. Bei FOR ALL
ENTRIES sollte man jedoch auf Folgendes achten:
a. Ist die interne Tabelle leer, auf der FOR ALL ENTRIES basiert, dann werden alle Einträge
geladen.
b. Sind in der internen Tabelle Einträge doppelt vorhanden, kann dies dazu führen, dass die
zugehörigen Datensätze auch doppelt von der Datenbank geladen werden. Es empfiehlt sich daher,
zuvor ein DELETE ADJACENT DUPLICATES aufzurufen.
3.5Interne Tabellen und Referenzen Interne Tabellen stellen ein zentrales Konstrukt bei der Entwicklung von Anwendungen mit ABAP
dar. Neben Datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle von
Performance-Problemen. Bei kleinen Datenmengen stellen Dinge wie die Wahl der passenden
Tabellenart und eines passenden Schlüssels noch kein Problem dar. Werden aber größere Datenmengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht,
können vorher aus Performance-Sicht unkritische Stellen zu erheblichen Laufzeitverlängerungen
führen.
BEST PRACTICE: Wir empfehlen die Beachtung der nachfolgenden Hinweise zur Steigerung der
Performance von Anwendungen:
19
20
3Performance
> Wählen Sie die Tabellenart passend zur späteren Verwendung:
>Standard-Tabellen eignen sich für Daten, die nur selten oder gar nicht nach bestimmten Kriterien durchsucht werden müssen. Wenn keine Suche erfolgen muss, lohnt es sich nicht, die Kosten für die Erstellung und Aktualisierung der zusätzlichen Schlüsselstrukturen der anderen Tabellenarten zu zahlen. Bei sehr kleinen Datenmengen (<100 Zeilen) kann je nach Häufigkeit der Suchanfragen und Breite der Tabelle ein Verzicht auf einen expliziten Schlüssel geeignet sein.
>Sorted-Tabellen bieten sich an, wenn die Daten häufig nach (Teil-)Schlüsseln durchsucht werden müssen, aber keine Eindeutigkeit der Schlüsselfelder garantiert werden kann.
Gerade Zugriffe, die nur mit einem ersten Teil der Schlüsselfelder stattfinden, können nur von dieser Tabellenart unterstützt werden.
>
Hashed-Tabellen sind perfekt dafür geeignet, in Dictionary-artigen Konstrukten nach ein
deutigen Schlüsseln zu suchen. Wenn die Eindeutigkeit der Einträge im Hinblick auf die Schlüsselfelder garantiert werden kann und die Suchzugriffe immer mit dem vollständigen Schlüssel (=alle Felder des Schlüssels werden auf Äquivalenz gegen einen jeweiligen Wert geprüft) erfolgen, ist diese Tabellenart in der Regel optimal.
> Wenn für eine Tabelle vom Typ Sorted oder Hashed Zugriffe erfolgen, sollten diese immer mit dem passenden (Teil-)Schlüssel stattfinden.
Dies bedeutet, bei READ TABLE den Zusatz WITH TABLE KEY zu verwenden und bei LOOP AT WHERE möglichst viele aufeinander folgende Felder des Schlüssels mit „=“ zu vergleichen. Dann werden die intern aufgebauten Schlüsselstrukturen verwendet, um die passenden Einträge schneller zu ermitteln.
>Ab AS ABAP 7.02 können Sie bei internen Tabellen, die selten geändert werden, aber mit mehr als einem Zugriffmuster gelesen werden, neben dem primären Schlüssel, der wie gehabt definiert und verwendet wird, auch weitere sekundäre Schlüssel definieren, die auch einen vom Primärschlüssel abweichenden Typ (Sorted, Hashed) haben.
Als Beispiel können Sie damit für eine als Hashed definierte Tabelle mit eindeutigem Primär-
schlüssel einen weiteren Schlüssel vom Typ Sorted definieren, der es ermöglicht, performant auf die Daten der Tabelle aus einem anderen Blickwinkel (nicht eindeutig, Teilschlüssel möglich) zuzugreifen, ohne die eigentlichen Daten zweimal im Hauptspeicher anzulegen und bei Änderungen manuell für die Konsistenz zwischen beiden Tabellen zu sorgen.
> Ähnlich wie bei den DB-Zugriffen existieren für interne Tabellen Einzelsatzzugriffe und Massenzugriffe.
Wenn möglich, sollten immer die Varianten mit Massenzugriffen gewählt werden, die perfor-
manter arbeiten als mehrere Einzelzugriffe. Als Beispiel sollten Sie beim Anhängen von Zeilen einer Teilergebnistabelle zur Gesamtergebnistabelle das Anweisungsmuster APPEND LINES OF TO verwenden, anstatt die gleiche Funktion über eine Schleife LOOP AT mit einzelnen APPEND TO zu realisieren.
> Bei der Verwendung der Anweisung SORT sollten Sie immer die gewünschten Sortierfelder angeben.
Erstens erhöht dies die Lesbarkeit des Codings und zweitens ist bei den wenigsten Standard-
Tabellentypen ein Tabellenschlüssel definiert. Fehlt ein solcher Schlüssel, wird die gesamte Zeile der Tabelle als Schlüssel verwendet und damit bei der Sortierung alle Felder der Tabelle geprüft, was zu erheblichen Performance-Einbußen führt. Soll also z. B. ein Tabelle nach den Feldern Benutzer und Datum sortiert werden, verwenden Sie die Anweisung SORT table BY Benutzer Datum, auch wenn die Tabellenstruktur mit diesen Feldern beginnt und die Reihen-
folge des Ergebnisses hinsichtlich der geforderten Felder gleich ist.
> Vor dem Einsatz der Anweisung DELETE ADJACENT DUPLICATES sollte immer sichergestellt sein, dass die Tabelle nach den gleichen Feldern sortiert ist, damit doppelte Einträge auch wirklich eliminiert werden.
Wie die Anweisung aussagt, werden nur benachbarte Tabellenzeilen verglichen. Wie bei der SORT-Anweisung auch sollten immer die Felder angegeben werden, die betrachtet werden müssen. Ansonsten wird auch hier die gesamte Zeile feldweise verglichen, auch wenn nur zwei Felder aus fachlicher Sicht dafür ausreichend sind.
>Reine Existenzprüfungen auf internen Tabellen sollten immer mit READ TABLE TRANSPORTING NO FIELDS durchgeführt werden, wenn auf den Daten der ermittelten Zeile keine weiteren Operationen stattfinden.
3.5.1Feldsymbole
Feldsymbole bieten die Möglichkeit, auf existierende Daten, z.B. Zeilen von internen Tabellen, zu
referenzieren. Das Arbeiten mit Referenzen ist deutlich performanter als das Kopieren der Daten.
Daher sollten, wo möglich, Feldsymbole verwendet werden. Nur bei sehr kleinen Tabellen gibt es
einen minimalen Vorteil in der Laufzeit zwischen den Kopierkosten bei INTO <WA> und Feldsymbolen. Ansonsten sind Feldsymbole immer schneller, insbesondere dann, wenn die Tabelleninhalte
geändert werden sollen. Bedenken Sie beim Einsatz von Feldsymbolen jedoch, dass eine Änderung
des Wertes eines Feldsymbols auch den Wert im referenzierten Datenelement überschreibt.
BEST PRACTICE: Verwenden Sie standardmäßig Feldsymbole für die Zugriffe auf interne Tabellen.
3.5.2Parameterübergabe
Die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus technischen
Gründen vorgeschrieben ist (z.B. RFC-Funktionsbausteine, Returning-Parameter bei funktionalen
Methoden). So werden unnötige Kopierkosten bei der Parameterübergabe gespart. Dies gilt in
besonderem Maße bei Parametern mit tiefen Datentypen wie internen Tabellen oder Strings. Wenn
es keine technischen Erfordernisse gibt, sollten Parameter immer per Referenz übergeben werden.
Weiterhin sollten so wenig Parameter wie möglich definiert werden. Optionale Parameter sollten
komplett vermieden werden.
BEST PRACTICE: Verwenden Sie so wenig Parameter wie möglich, die per Referenz übergeben
werden. Nutzen Sie die Wertübergabe nur an den technisch notwendigen Stellen.
3.6
Weiterführende Quellen >Einen guten Einstieg in die Performance-Optimierung im ABAP bietet der SAP-Kurs BC490.
>Siegfried Boes, „Performance-Optimierung von ABAP-Programmen“, dpunkt Verlag 2009,
ISBN 3898646157
21
22
4Robustheit
Dieses Kapitel erläutert, worauf Entwickler achten müssen, um robuste ABAP-Programme zu
schreiben. Dazu ist es zunächst erforderlich zu definieren, was ein robustes ABAP-Programm
ausmacht.
Unter Robustheit verstehen wir die Fähigkeit eines Programms, auch unter ungünstigen Umständen weiterzulaufen und korrekte Ergebnisse zu liefern. Das bedeutet insbesondere, dass
Programme Fehlersituationen erkennen und in einer Weise darauf reagieren, dass die gewünschte
Funktionalität nicht gefährdet wird.
4.1
Fehlerbehandlung Die ABAP-Laufzeit hat verschiedene Möglichkeiten, eine Anwendung auf Fehlersituationen
hinzuweisen. Diese sind hier aufgeführt und die Best Practices jeweils erläutert.
4.1.1SY(ST)-SUBRC-Prüfungen
Bei einer ganze Reihe von ABAP-Befehlen setzt der SAP-Kernel nach deren Ausführung die
globale Variable SY(ST)-SUBRC. In der Regel wird eine erfolgreiche Ausführung durch den Wert 0
angezeigt.
Bei den Befehlen CALL FUNCTION und CALL METHOD wird SY(ST)-SUBRC nicht automatisch
gesetzt, wenn es zu Fehlern in dem aufgerufenen Code kommt. Sofern die gerufenen Module
sogenannte nicht-klassenbasierte Ausnahmen (non-class-based Exceptions) verwenden, muss das
aufrufende Programm diese in der EXCEPTIONS-Sektion beim Aufruf korrekt deklarieren und
ihnen einen Wert ungleich 0 zuweisen, damit SY(ST)-SUBRC gesetzt wird.
BEST PRACTICE: Setzen Sie explizit den speziellen Wert OTHERS, da sich die Liste der Ausnahmen
systembedingt ändern könnte, nachdem das rufende Programm fertiggestellt wurde. Der spezielle
Wert OTHERS sollte insbesondere beim Aufruf von RFC-fähigen Funktionsbausteinen verwendet
werden, da es hier zu verschiedenen speziellen RFC-Ausnahmen kommen kann.
Die Prüfung von SY(ST)-SUBRC muss immer unmittelbar nach dem Befehl erfolgen, der diese
globale Variable setzt. Wird die Prüfung erst später durchgeführt, kann der Wert bereits durch
einen anderen ABAP-Befehl überschrieben worden sein.
4.1.2MESSAGE-Anweisung
Mit der MESSAGE-Anweisung können Status- oder Fehlermeldungen ausgegeben werden. Dabei
unterscheidet sich das Verhalten der MESSAGE-Anweisung je nach Meldungsart (Status,
Information, Fehler, Abbruch) und ob der auslösende Programmteil im Dialog- oder Batchmodus
ausgeführt wird.
BEST PRACTICE: Vermeiden Sie MESSAGE-Anweisungen außerhalb von Modulen, die direkt mit
dem Anwender kommunizieren bzw. die in einer definierten Dialogschicht liegen. MESSAGE-Anweisungen können in bestimmten Konstellationen von Meldungsart und Betriebsmodus implizite
COMMITs aufgrund eines Bildschimwechsels in klassischen Dynpros auslösen und führen bei
einem Aufruf innerhalb eines RFC-Aufrufs zu Verbindungsabbrüchen. Verwenden Sie innerhalb des
eigentlichen Anwendungskerns klassenbasierte Ausnahmen, um auf Fehlersituationen hinzuweisen.
4.1.3
Klassenbasierte Ausnahmen
Seit Einführung von ABAP OO können auch klassenbasierte Ausnahmen verwendet werden. Diese
arbeiten nach dem Prinzip des „Werfens“ von Ausnahmen: Ein Programm erkennt einen Fehler und
„wirft“ eine Ausnahme in den Call Stack. Fängt der Aufrufer diese Ausnahme nicht, wird sie so lange
weiter im Call Stack nach oben propagiert, bis sie an anderer Stelle gefangen wird oder zu einem
Dump führt.
Es ist wichtig, alle Ausnahmen zu fangen, auf die in der jeweiligen Stelle angemessen reagiert werden
kann, oder Ausnahmen in der Methode oder dem Funktionsbaustein zu deklarieren, sodass für den
Aufrufer klar ersichtlich ist, dass die Methode bzw. der Funktionsbaustein eine solche Ausnahme
aufwerfen könnte. Wichtig ist hierbei die einheitliche Verwendung: Für dieselbe Fehlersituation
sollten einheitliche Fehlerbehandlungen/Ausnahmen verwendet werden.
Zum Fangen von Ausnahmen ist der ABAP-Befehl TRY…CATCH…ENDTRY gedacht. Entsprechend
müssen alle Ausnahmen aller Module, die klassenbasierte Ausnahmen erzeugen können, von
einem TRY…CATCH behandelt werden, um einen robusten Ablauf zu gewährleisten.
BEST PRACTICE: Erlauben Sie keine leeren Ausnahmebehandlungen.
Dadurch wird es aufrufenden Stellen unmöglich gemacht, auf Ausnahmesituationen angemessen
zu reagieren. Propagieren der Ausnahme ist in diesen Fällen die richtige Reaktion.
BEST PRACTICE: Vermeiden Sie beim Fangen von Ausnahmen die globale Basisklassen CX_ROOT.
Im CATCH-Block wird die Angabe der Exception-Klasse die zu fangende Ausnahme spezifiziert, z.B.
CX_SY_ZERODIVIDE zum Abfangen eines Fehlers aufgrund der Division durch Null. Hierbei gilt es
konkrete Ausnahmen abzufangen, um diese spezifisch zu behandeln. Das Fangen der allgemeinsten Ausnahme CX_ROOT sollte nur erfolgen, wenn die Ausnahmebehandlung tatsächlich in der
Lage ist, mit unbekannten Fehlersituationen umzugehen.
BEST PRACTICE: Wählen Sie die grundlegende Art von eigenen Ausnahmeklassen durch die
Vererbung von vordefinierten Basisklassen (STATIC_CHECK, DYNAMIC_CHECK, NO_CHECK) mit
Bedacht.
Beim Einsatz von STATIC_CHECK wird jeder Verwender durch Syntaxfehler gezwungen, für jede
dieser Ausnahme zu entscheiden, ob er sie direkt behandeln kann, weiterreicht und damit in seine
Deklaration aufnehmen muss oder über das Verketten mit eigenen Ausnahmeklassen verpackt.
Alle diese Möglichkeiten sind mit Aufwand und Änderungen verbunden, die den Vorteil der
klassenbasierten Ausnahmen (Propagieren von Ausnahmen, die nicht direkt behandelt werden
können) zunichtemachen. Verwenden Sie bei der nachträglichen Einführung von Ausnahmeklassen
daher bevorzugt DYNAMIC_CHECK, um nicht allen Ausnahmen die o.g. Anpassungen aufzuzwingen. Setzen Sie STATIC_CHECK bewusst ein, um Aufrufer dazu zu zwingen, sich mit der Ausnahmesituation auseinanderzusetzen.
Die Ausnahmenklasse NO_CHECK bietet sich für solche Fehlersituationen an, auf die kaum eine
aufrufende Stelle angemessen reagieren kann. Beispiele dafür sind das Wegbrechen von sekundären
Datenbankverbindungen oder andere Dinge, die durch das Coding nicht korrigiert werden können.
23
24
4Robustheit
4.1.4Nicht behandelbare Ausnahmen
Es gibt Ausnahmen, die vom ABAP Code aus nicht behandelt werden können und dadurch zwangsläufig zu einem Abbruch der Anwendung und einem Dump führen. In einigen Fällen ist es möglich,
pro aktiv vor der Ausführung eines Statements, das eine nicht behandelbare Ausnahme auslöst,
die Rahmenbedingungen zu prüfen.
Beispiel:
Das Statement OPEN DATASET löst einen Shortdump aus, wenn der Benutzer keine ausreichenden
Berechtigungen zum Öffnen der Datei hat. Um dies zu vermeiden, muss die Berechtigung pro aktiv
vom ABAP geprüft werden (FuBa AUTHORITY_CHECK_DATASET), damit OPEN DATASET nicht zu
einem Dump führt.
4.2
Korrekte Implementierung von Datenbank-Änderungen
4.2.1Sperrobjekte
Um Dateninkonsistenzen zu vermeiden, müssen die entsprechenden Objekte vor Veränderung auf
der Datenbank gesperrt werden. Zusammenhängende Objekte dürfen erst verändert werden, wenn
alle zugehörigen Entitäten erfolgreich gesperrt werden. Damit ist keine parallele Datenänderung
möglich.
Die SAP-Sperre besteht über mehrere Datenbank-LUWs (Logical Unit of Work) hinweg, sodass
konsistent Änderungen auf der Datenbank für das gesamte zu ändernde Businessobjekt geschrieben
werden können.
Die Sperren sind so genau wie möglich abzusetzen, um nur die relevanten Objekte innerhalb der
LUW zu sperren. Zudem sind die Sperren so lange wie nötig und so kurz wie möglich zu halten.
Für die Änderung von SAP-Standard-Datenobjekten direkt auf der Datenbank sind die entsprechenden SAP-Standard-Sperrfunktionen zu verwenden, da diese auch von den Standard-Transaktionen verwendet werden und so ein konsistentes Verhalten sicherstellen.
Für kundeneigene Entwicklungen sind entsprechende Sperrobjekte mit den zugehörigen
Sperrfunktionen zu implementieren.
Die Sperren sind nach Abschluss des Updates auf das Objekt aufzuheben. Dies erfolgt mittels
Aufruf des Dequeue-Funktionsbausteins. Beachten Sie dabei den wichtigen Scope-Parameter,
wenn in diesem Zusammenhang auch Verbuchungsbausteine verwendet werden.
WEITERE QUELLEN:
1. http://help.sap.com/saphelp_NW70/helpdata/de/7b/f9813712f7434be10000009b38f8cf/frameset.htm
4.2.2Verbuchungskonzept
Die Verbuchung ist die zentrale Technik zur Bündelung von Datenbankänderungen in einer einzigen
Datenbank-LUW und damit zur Definition von SAP-LUWs in SAP-Transaktionen. Datenänderungen
sollen nicht mit DML-Kommandos (DataManipulati-onLanguage-Kommandos Insert, Update,
Delete, Modify) aus der Applikation, sondern über den Verbucher durchgeführt werden.
Dabei stehen folgende Möglichkeiten zur Verfügung:
>Asynchrone Verbuchung
>Asynchrone Verbuchung in Abschnitten
>Synchrone Verbuchung
Die Verbuchung wird mit eigenen Verbuchungsfunktionsbausteinen durchgeführt. Diese sind bei
der Anlage entsprechend in den Eigenschaften zu kennzeichnen. Diese Funktionsbausteine werden
mit dem Zusatz „IN UPDATE TASK“ aufgerufen und unterliegen bei der Entwicklung einigen
Restriktionen. Alle bis zu einem „COMMIT WORK“ gerufenen Verbuchungsfunktionen werden in
einer LUW auf die Datenbank geschrieben.
Beim Aufruf der Sperrfunktionsbausteine ist auf die korrekte Parametrierung (insbesondere
SCOPE-Parameter) zu achten!
Fehlerhafte Verbuchungssätze müssen in der Transaktion Verbuchungsaufträge (SM13) administriert und nachbehandelt werden. Aus Revisionsgründen ist es empfehlenswert, die Nachbearbeitung der fehlerhaften Verbuchungssätze zu dokumentieren.
WEITERE QUELLEN:
1.SAP Dokumentation „Techniken der Verbuchung“:
http://help.sap.com/saphelp_nw70/helpdata/de/41/7af4cba79e11d1950f0000e82de14a/content.htm
4.2.2.1Asynchrone Verbuchung
Die Funktionsbausteine werden in den Eigenschaften mit „Start sofort“ oder in Ausnahmefällen mit
„Start sofort – nicht nachverbuchbar“ angelegt. Die Verbuchung wird sofort nach Abschluss der
LUW gestartet, jedoch asynchron durchgeführt.
4.2.2.2Asynchrone Verbuchung in Abschnitten
Die Funktionsbausteine werden in den Eigenschaften mit „Start verzögert“ angelegt. Die Verbuchung wird sofort nach Abschluss der LUW gestartet, wird jedoch asynchron in eigenen Prozessen
mit niedriger Priorität durchgeführt. Diese Art der Verbuchung ist für das Schreiben von großen
Datenmengen geeignet, wenn die Verbuchung nicht zeitkritisch erfolgen muss (z.B. Ladeprogramme, Protokollierung ...).
4.2.2.3Synchrone Verbuchung
Die Funktionalität und die notwendigen Einstellungen sind analog zu jenen im Punkt 4.2.2.1
Asynchrone Verbuchung. Die LUW muss jedoch mit „COMMIT WORK AND WAIT“ abgeschlossen
werden.
Diese Art der Verbuchung wird dann gewählt, wenn die geänderten Daten sofort benötigt werden,
z.B. wenn man LUWs koppeln will und eine LUW vom Ergebnis der vorherigen LUW abhängt.
25
26
4Robustheit
4.3Protokollierung
Generell sollten Fehler, Ausnahmen und Meldungen ins Business Application Log gespeichert
werden, um diese an zentraler Stelle (Transaktion SLG1) prüfen zu können. Mit der Transaktion
SLG0 können darüber hinaus eigene Objekte zur Protokollierung definiert werden.
Der Vorteil bei der Verwendung des Business Application Logs liegt in folgenden Aspekten
begründet:
1.Zentrale Ablage: Im Business Application Log können Meldungen an zentraler Stelle verwaltet werden; dies erleichtert den Überblick und die Administration der Anwendungen
2. Wiederverwendbarkeit: Das Business Application Log bzw. die zugehörigen Bausteine/Klassen bieten einen guten Funktionsumfang für das Thema Logging – dieser muss nicht „neu erfunden“ werden. Zu diesen Möglichkeiten zählen u.a.
a.Integration zusätzlicher Felder in die Protokollierungsobjekte
b. Hierarchiedarstellung von Meldungen (Zusammenfassung zu Problemklassen möglich)
c.Interaktivität (Nachlesen von Informationen bei Aufruf einer Meldung und Anreichern von Informationen)
d. Persistenz: Speicherung von Meldungen im Log möglich
e.Integration der Protokollanzeige in eigene Anwendungen/UIs (Sub-screen/Control/Popup)
BEST PRACTICE: Für die Protokollierung sollten die von SAP vorgesehenen Funktionsbausteine in
der Funktionsgruppe SBAL verwendet werden. Die Beispielprogramme „SBAL_DEMO*“ bieten
einen guten Einstieg und Überblick.
Bitte beachten Sie bei der Implementierung die SAP-Standardhilfe bzgl. der Verwendung der
Funktionsbausteine im jeweiligen Release.
WEITERE QUELLEN:
1.SAP Application Log – Leitfaden für Anwender
http://help.sap.com/saphelp_nw70ehp2/helpdata/de/3a/c8263712c79958e10000009b38f936/
frameset.htm
2. Beispiele zur Verwendung der BAL Funktionen in:
Thorsten Franz, Tobias Trapp, „Anwendungsentwicklung mit ABAP Objects, SAP Press, ISBN-10:
3836210630
4.4Praxisbeispiele
In diesem Abschnitt finden sich noch einige Robustness-Probleme, die in Audits immer wieder
auftauchen.
4.4.1Unvollständige Fallunterscheidungen
Für CASE Statements wird empfohlen, alle vorhandenen WHEN-Blöcke auszuprogrammieren.
Außerdem sollte immer ein WHEN OTHERS-Block vorhanden sein, um Fälle zu behandeln, die zur
Zeit der Entwicklung noch nicht abzusehen waren bzw. unterwartet sind.
Bei IF-Abfragen ist darauf zu achten, dass auch die ELSE/ELSEIF-Zweige ausprogrammiert
werden, sofern diese im jeweiligen Kontext Sinn machen.
4.4.2
Wichtige sonstige SY(ST)-SUBRC-Prüfungen
SY-SUBRC-Prüfungen sollten möglichst immer stattfinden, wenn ABAP-Befehle Rückgabewerte
liefern. Das ist wichtig, um die Integrität des Systems auch im Fehlerfall zu gewährleisten. Es wird
daher empfohlen, zumindest im Umgang mit Dateien und Datenbanktabellen Prüfungen auf
SY(ST)-SUBRC durchzuführen.
Im Folgenden sind die relevanten ABAP-Befehle gelistet, für die SY(ST)-SUBRC aus Sicht der
Robustheit immer geprüft werden sollte und die in diesem Kapitel noch nicht erwähnt wurden:
>OPEN DATASET
>READ DATASET
>DELETE DATASET
>SELECT SINGLE
>DELETE dbtab
> MODIFY dbtab
>INSERT dbtab
>UPDATE dbtab
4.5
Weiterführende Quellen
1. Liste einiger Befehle, die SY-SUBRC setzen:
http://wiki.sdn.sap.com/wiki/display/ABAP/Sy-Subrc
27
28
Dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im ABAP negativ auf die
Sicherheit eines Unternehmens auswirken können. Da dieses Thema sehr komplex ist, können wir
im Rahmen dieses Dokuments nur ein paar ausgewählte, zentrale Themen behandeln. Für
weitergehende Fragen verweisen wir auf die Literaturhinweise am Ende dieses Kapitels. Zunächst
müssen wir die Begriffe Sicherheit und Compliance in diesem Kontext erklären:
Wir sprechen von einer Sicherheitsschwachstelle, wenn ein Programmierfehler einen ungewollten
Nebeneffekt verursacht, durch den ein Angreifer unbefugt schadhafte Aktionen ausführen kann.
Wir sprechen von einem Compliance-Verstoß, wenn ein Anwender aufgrund eines Programmierfehlers einen prüfungsrelevanten Sicherheitsmechanismus des SAP-Standards umgehen kann.
Ein wichtiger Unterschied ist, dass Sicherheitsfehler im Code Angriffe durch Hacker (z.B.
Industriespionage) ermöglichen, wohingegen Compliance-Verstöße im Code potenziell gesetzliche
Auflagen verletzen (z.B. SOX) und/oder bei einer Wirtschaftsprüfung moniert werden.
5.1 Prüfungsrelevante Sicherheitsmechanismen im
SAP Standard
Bevor wir näher auf Schwachstellen eingehen, ist es wichtig, sich noch einmal ein paar zentrale
Schutzmechanismen des SAP-Standards vor Augen zu führen. Diese sind Grundvoraussetzung für
den sicheren Betrieb von SAP-Systemen.
5.1.1
Berechtigungsprüfung (A)
Rollen und Berechtigungen sind ein zentrales Sicherheitsthema im SAP-Umfeld. Es ist daher
wichtig zu verstehen, dass ABAP ein sogenanntes explizites Berechtigungsmodell verwendet. Das
bedeutet, dass Berechtigungsprüfungen explizit im Code programmiert werden müssen, damit sie
auch ausgeführt werden. Das beste Berechtigungskonzept nützt nichts, wenn selbstgeschriebener
Code die erforderlichen Berechtigungen nicht (richtig) prüft.
Sicherheitsprobleme ergeben sich z.B. in folgenden Fällen:
>Der Entwickler vergisst, die Berechtigungsprüfung zu programmieren.
>Der Entwickler verwendet das falsche Berechtigungsobjekt.
>Der Entwickler verwendet eine proprietäre Berechtigungsprüfung.
>Der Entwickler behandelt den Rückgabewert der Prüfung nicht.
5.1.2
Mandantentrennung (B)
Der SAP-Standard trennt automatisch alle Datenbankzugriffe nach Mandanten auf. Ein ABAPProgramm darf immer nur die Daten des Mandanten verarbeiten, an dem sich der Anwender angemeldet hat.
Sicherheitsprobleme ergeben sich in folgenden Fällen:
>Der Entwickler umgeht die Mandantentrennung (vorsätzlich) durch technische Optionen im
Open SQL (CLIENT SPECIFIED).
>Der Entwickler verwendet natives SQL, das generell keine implizite Mandantentrennung
durchführt.
5.1.3Nachvollziehbarkeit (C)
Die meisten Geschäftstransaktionen müssen nachvollziehbar sein, insbesondere in der Finanzbuchhaltung. Selbstgeschriebener ABAP Code darf Anwendern nicht ermöglichen, relevante
Aktionen zu verschleiern.
>Der Entwickler vergisst, für wichtige Tabellen Änderungsbelege zu schreiben.
>Der Entwickler ermöglicht (unbeabsichtigt) einen sogenannten Identitätsdiebstahl.
>Der Entwickler verändert direkt Tabelleninhalte, ohne Standardfunktionsbausteine zu verwenden (und damit implizit die Protokollierung zu verwenden).
5.1.4Dreisystemlandschaft (D)
Der SAP-Standard sieht vor, für Entwicklung, Qualitätssicherung und Produktion getrennte
Systeme (D, Q, P) zu verwenden. Dies dient in erster Linie dazu, die Produktivdaten vor unzureichend getesteten Programmen zu schützen und die umfangreichen Rechte der Entwickler auf das
Entwicklungssystem zu beschränken.
>Der Code kann nicht (vollständig) auf dem Q-System getestet werden.
>Der Entwickler verwendet Befehle, die es Anwendern möglich machen, auf dem Produktivsystem Code zu entwickeln.
5.1.5
Kontrollierte Ausführung von Betriebssystemkommandos (E)
ABAP hat die Möglichkeit, auch Betriebssystemkommandos auszuführen. Da das potenziell sehr
gefährlich ist, stellt der Standard Transaktionen (SM49/SM69) zur Verfügung, mit denen man eine
Liste erlaubter Befehle definieren und die erlaubten Befehle auch noch durch spezielle Berechtigungen zusätzlich schützen kann.
>Der Entwickler verwendet einen alternativen Weg, um Betriebssystemkommandos auszuführen. D.h., er umgeht die Liste der erlaubten Befehle und die daran gekoppelten Berechtigungen.
5.1.6
Kontrollierte Ausführung von SQL-Befehlen (F)
Der Open-SQL-Standard ermöglicht den Zugriff auf die Datenbank von ABAP aus nur mit einem
sehr limitierten Satz an Befehlen, die zusätzlich alle statisch deklariert werden müssen. Dadurch
können gefährliche SQL-Befehle in der Datenbank abgeschirmt werden.
>Der Entwickler verwendet native SQL-Befehle, um mit der Datenbank zu kommunizieren. Dadurch können beliebige Befehle ausgeführt werden, die die Datenbank beschädigen.
>Der Entwickler verwendet dynamische Optionen von Open-SQL-Befehlen und ermöglicht dadurch Injection-Angriffe.
29
30
5.2Sicherheitsschwachstellen
Applikationssicherheit ist in vielen Programmiersprachen schon seit Jahren ein wichtiges Thema.
In ABAP wurde dieses Thema jedoch häufig nicht erkannt bzw. falsch eingeschätzt. Ein wesentlicher Grund dafür ist der falsche Glaube, dass man SAP-Systeme durch Rollen und Berechtigungen absichern kann. Dies mag für den SAP-Standard zutreffen, aber definitiv nicht für selbstentwickelten Code. Wie bereits weiter oben erläutert, werden z.B. Berechtigungen nur geprüft,
wenn der ABAP Code eine Prüfung auch explizit durchführt.
Folgende Arten von Schwachstellen sind im ABAP besonders häufig zu beobachten:
> Fehlende bzw. falsche Berechtigungsprüfungen
Der ABAP Code führt Operationen aus, für die ein Berechtigungsprüfung erforderlich ist, überprüft aber die Berechtigung des Benutzers nicht bzw. nicht richtig.
>Injection-Probleme
Der ABAP Code verwendet dynamische Befehle, die aus Benutzereingaben zusammengefügt werden. Wenn hier nicht durch Input-Validierung bzw. Output-Encoding verhindert wird, dass Steuerzeichen in den Eingaben die Semantik des dynamischen Befehls verändern können, dann kann der dynamische Befehl zur Laufzeit schadhaft verändert werden.
>Aushebelung von Sicherheitsmechanismen des Standards
ABAP Code darf einen bestehenden Sicherheitsmechanismus nicht gezielt umgehen. Beispiele sind proprietäre Berechtigungsprüfungen (basierend auf SY-UNAME), mandantenübergreifende Datenbankzugriffe, Ausführung von Betriebssystemkommandos über Kernelfunktionen.
Folgende Schwachstellen sind im ABAP besonders häufig zu beobachten. Die Spalte „Std“ zeigt dabei an, welcher Sicherheitsmechanismus des SAP-Standard dabei beeinträchtigt wird.
ID
Schwachstelle
Beschreibung
Std
APP-01
ABAP Command Injection
Ausführung von beliebigem
ABAP Code
D
APP-02
OS Command Injection
Ausführung beliebiger
Betriebssystem-Kommandos
E
APP-03
Native SQL Injection
Ausführung beliebiger nativer
SQL-Kommandos
F
APP-04
Improper Authorization
(Missing, Broken, Proprietary,
Generic)
Fehlende oder fehlerhafte
Berechtigungsprüfung
A
APP-05
Directory Traversal
Unerlaubter Schreib-/
Lesezugriff auf Dateien (SAP
Server)
APP-06
Direct Database Modifications
Unberechtigter Schreibzugriff
auf Tabellen
C
ID
Schwachstelle
Beschreibung
Std
APP-07
Cross-Client Database Access
Mandantenübergreifender
Zugriff auf Geschäftsdaten
B
APP-08
Open SQL Injection
Schadhafte Manipulation von
Datenbankbefehlen
F
APP-09
Generic Module Execution
Unerlaubte Ausführung von
Modulen (Reports, FuBas etc.)
A
APP-10
Cross-Site Scripting
Manipulation des Browser UI,
Diebstahl von Berechtigungen
C
APP-11
Obscure ABAP Code
Einschränkte Auditierbarkeit
durch Verschleierung von Code
D
Abbildung 1: BIZEC APP/11 – Die derzeit verbreitetsten Sicherheitsprobleme in ABAP-Code
QUELLE: http://www.bizec.org/wiki/BIZEC_APP11
Dieses Kapitel kann bei Weitem nicht die notwendigen Details liefern, um sicheren ABAP-Code zu
programmieren. Wir verweisen hier auf die Literaturempfehlung #1 am Ende des Kapitels.
Die folgende Liste enthält eine Übersicht über SAP-Meldungen, die Gegenmaßnahmen zu einigen
der oben beschriebenen Probleme beschreiben.
SAP Note
Schwachstelle
1520356
SQL Injection
887168, 944279, 822881
Cross-Site Scripting
1497003
Directory Traversal
Abbildung 2: SAP OSS Notes, die Gegenmaßnahmen beschreiben
Selbstverständlich empfiehlt es sich, SAP-Sicherheitshinweise zeitnah zu prüfen und einzuspielen.
Diese lösen allerdings nur Sicherheitsdefekte im SAP-Standardcode. Eine regelmäßige Prüfung
der Eigenentwicklungen ist daher zwingend erforderlich.
5.3
Compliance-Probleme durch ABAP
Das Thema Applikationssicherheit wurde in der Vergangenheit selten mit Compliance in Verbindung
gebracht, ist aber für Wirtschaftsprüfungen durchaus relevant (siehe Literaturempfehlung #2).
Die meisten Unternehmen verfügen über ein internes Kontrollsystem (IKS), das ComplianceRisiken entgegenwirkt. Dies ist beispielsweise in den international anerkannten Referenzmodellen
COSO & COBIT beschrieben. In einer typischen IKS-Struktur sind die „Generellen IT-Kontrollen“
(ITGC-IT General Controls) Voraussetzung für das Erreichen aller IKS-Ziele im IT-dominierten Umfeld.
31
32
Ein elementarer Baustein der ITGC ist das Änderungswesen (Change Management), zu dem
wiederum Eigenentwicklungen zählen. Sicherheitsdefekte im selbstgeschriebenen ABAP-Code
stellen eine Verletzung der generellen IT-Kontrollen dar und erschüttern damit die Grundmauern
jedes internen Kontrollsystems.
Abbildung 3: IKS-Risiken durch unsicheren ABAP-Code
Dies bedeutet insbesondere, dass Sicherheitsdefekte im ABAP-Code potenziell nicht nur
Auswirkungen auf Compliance-Standards haben, sondern auch gesetzliche Anforderungen
verletzen können.
Alle in Abbildung 1 dargestellten Sicherheitsdefekte sind daher auch Compliance-relevant.
5.4Testwerkzeuge
Für ABAP-Sicherheitstests eigenen sich insbesondere sogenannte statische Codeanalyse-Tools.
Es gibt hier verschiedene kommerzielle Anbieter, die in wesentlichen Bereichen die Möglichkeiten
des Code Inspectors erweitern:
>Analyse des SAP-Standard-Codings, insbesondere von API-Aufrufen
>Sehr hohe Scan-Geschwindigkeiten für Continuous Monitoring
> Globale Daten- und Kontrollflussanalysen, da diese für die meisten Sicherheitstests elementar sind.
>Umfangreiche Beschreibungen des Problems mit Lösungsvorschlägen
> Hinreichende Testabdeckung (OWASP Top 10 und SANS 25 reichen nicht, da überwiegend Web-spezifisch und auf ABAP kaum anwendbar)
> 4-Augen-Prinzip bei Ausnahmen
Natürlich muss so ein Tool hinreichend in SE80, TMS und ChaRM integriert sein, damit die
Entwickler damit arbeiten können und wollen.
5.5
Weiterführende Quellen:
1.Andreas Wiegenstein, Markus Schumacher, Sebastian Schinzel, Frederik Weidemann, Sichere ABAP Programmierung, SAP Press 2009
2. Maxim Chuprunov , Handbuch SAP-Revision, SAP Press 2011
3. BIZEC - The Business Application Initiative (http://bizec.org)
33
34
6Dokumentation
Die Dokumentation von Software ist in vielen Fällen genauso wichtig wie die Entwicklung selbst.
Fehlt die Dokumentation oder ist diese nicht in ausreichendem Maß vorhanden, führt dies
spätestens bei der Weiterentwicklung oder dem Wechsel von Entwicklern zu erhöhten Aufwänden.
In diesem Kapitel werden unterschiedliche Möglichkeiten zur Dokumentation von Entwicklungsobjekten im SAP System dargestellt.
6.1Dokumentation unabhängig von Entwicklungsobjekten
Neben der Beschreibung der vielen Entwicklungsobjekte, die einzelne, sehr spezielle Funktionen
im ABAP-System übernehmen, gibt es auch den Bedarf, die größeren Zusammenhänge innerhalb
und zwischen Modulen darzustellen. Dazu gehören z.B. Antworten auf Fragen wie:
> Welche Abhängigkeiten gibt es zwischen n Modulen?
> Wie werden Prozesse auf Reports abgebildet?
> Welche Läufe finden wann am Tag / im Monat / Jahr statt und welche Entwicklungsobjekte sind davon betroffen?
Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes Ablagemedium innerhalb des SAP-Entwicklungssystems, das insbesondere Grafiken gut integriert. Wir
empfehlen daher, für die Dokumentation dieser übergreifenden Zusammenhänge auf andere
Medien außerhalb des SAP-Systems zurückzugreifen. Beispiele dafür sind:
>Interne (Produkt-)Wikis
>Dokumente in gepflegten öffentlichen Verzeichnissen (Portalablage, Sharepoint, Fileshare …)
Die Erfahrung zeigt, dass die Herausforderung in diesem Bereich primär in der Frage der Disziplin
liegt. Diese Herausforderung kann kein Tool lösen, sondern nur das Entwicklungsteam und die
zugehörige -leitung.
Darüber hinaus sei angemerkt, dass veraltete Dokumentation irreführend sein kann. Insofern
sollte in Dokumenten der Stand und eine Versionierung enthalten sein, um die Aktualität bewerten
zu können.
Innerhalb einer SAP-Systemlandschaft bietet der SAP Solution Manager Möglichkeiten zur
Projektdokumentation. Die nachfolgenden Links bieten weitere Informationen dazu.
WEITERE QUELLEN:
1. Help.sap.com Dokumentation SAP Solution Manager 7.1:
http://help.sap.com/saphelp_sm71_sp05/helpdata/en/3d/d05893e6ba4dfab7c0d66de8d52420/
frameset.htm
2.SCN Blog: „Business process documentation with SAP Solution Manager 7.1”
http://scn.sap.com/blogs/ben.schneider/2011/11/04/business-process-documentation-with-
sap-solution-manager-71
6.2Dokumentation von Entwicklungsobjekten
Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quelltext enthalten
können, existieren weitere Entwicklungsobjekte im ABAP-System, die keinen Quelltext beinhalten
und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind:
>Interfaces
>DDIC-Objekte
>Transaktionen
BEST PRACTICE: Wir empfehlen, für alle Entwicklungsobjekte, unabhängig von Quelltexten, die
Möglichkeiten zur Dokumentation der ABAP Workbench zu nutzen und die Aufgaben und
Bedeutungen dieser Objekte im SAP-System zu dokumentieren. Im Vergleich zur Dokumentation
im Quelltext ist hier der Änderungsverlauf nicht im Vordergrund, sondern der IST-Stand sollte hier
dargelegt werden.
Da die Dokumentation auch an das Transportwesen angeschlossen ist, steht diese Dokumentation
in allen Stages einer Systemlandschaft zur Verfügung. Weiterhin kann die Dokumentation von allen
Benutzern eingesehen werden und wird in einigen Fällen (Reports) vom ABAP-System automatisch
in die Benutzungsoberfläche eingebunden. Ein weiterer Vorteil besteht darin, dass diese Dokumentation übersetzbar ist.
6.3Dokumentation im Quelltext
6.3.1Dokumentation und Kommentierung von Anweisungen/Anweisungsblöcken
Generell sollten Anweisungsblöcke im Quelltext (kurz) kommentiert werden, damit ein schnelles
Zurechtfinden in fremden Programmen ermöglicht wird. Dabei soll in einer Kommentarzeile kurz
beschrieben werden, welche Aufgabe der nächste Anweisungsblock hat. Dokumentieren Sie
insbesondere, warum Sie etwas machen, nicht wie. Dabei gilt der Grundsatz: So wenig Kommentar
wie möglich, so viel Kommentar wie nötig. Vermeiden Sie daher redundante Informationen (wie
Name des dokumentierten Moduls, den letzten Änderer etc).
BEST PRACTICE: Als Kommentierungssprache sollte Englisch verwendet werden. Entwicklungsteams arbeiten heutzutage überwiegend international zusammen. Auch wenn Sie derzeit rein
deutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit internationalisiert werden. Der
Aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht,
steht in keinem Verhältnis zu dem vielleicht größeren Aufwand durch englische Dokumentation.
Es hat sich außerdem gezeigt, dass die Lesbarkeit von Code und Kommentaren besser ist, wenn
die Kommentare englisch sind. Denn die ABAP-Befehle selbst sind englisch und im Stil von Sätzen
aufgebaut. Der Leser muss bei englischer Dokumentation also nicht ständig beim Lesen des
Quelltextes die Sprache wechseln.
35
36
6Dokumentation
6.3.2Dokumentation von Änderungen
Ab dem Zeitpunkt der Produktivsetzung eines Programms müssen Änderungen in Programmen
dokumentiert werden.
6.3.3Programmkopf
Änderungen in Programmen werden mit einem Namenskürzel (z.B. Vorname + Nachname), dem
Tagesdatum und dem Change Document der Änderung im Programmkopf dokumentiert. Dabei
soll zumindest im Programmkopf auch die Erläuterung des Namenskürzels stehen, hilfreich ist es
jedoch auch, die Beschreibung direkt bei der Änderung einzufügen. Hierdurch kann auf einen Blick
der Grund der Änderung im Code erfasst werden.
Beispiel:
*/ Change Log
*/ VN/Date
ChangeDoc Description
*/ MZ/2012-08-06 CD4712 Add MMSTA in Output, Max Mustermann
*/ MZ/2012-02-01 CD4711
Import Material number, Max Mustermann
*/ MM/2009-01-01 CD0815 Added Field ABC in method signature and source code in order to support quick search, Max Mustermann
In der Beschreibung der Änderung sollte die Frage „Wer hat Was, Warum und Wie geändert“
beantwortet werden.
Werden für die Koordination der Weiterentwicklung Change-Management- oder Bug-trackingSysteme eingesetzt, sollten in diesem Kommentar Verweise auf die Vorgänge/Issues enthalten
sein. Damit lässt sich später auch im Quelltext nachvollziehen, welche Erweiterung/Fehlerbehebung Auslöser für eine Änderung war.
BEST PRACTICE: Der Kommentar ist nicht für den Verfasser, sondern für andere Entwickler
gedacht. Führen Sie sich das bei der Erstellung von Kommentaren bzw. deren Review immer
wieder vor Augen.
Programmzeilen – optional
Die geänderten Programmzeilen können mit der Kombination Namenskürzel und Tagesdatum der
Änderung dokumentiert werden. Hinter dem Datum kann ein Punkt gesetzt werden, sodass der
Pretty Printer die Kommentierung automatisch nach rechts ausrichtet.
Alte Dokumentationen von Änderungen, die nicht mehr benötigt werden, sollten aus Gründen der Lesbarkeit wieder entfernt werden. Oberstes Ziel sollte stets die gute Lesbarkeit von Quelltexten sein.
Einfache Änderung
*WRITE: lw_mara-matnr. „ MZ/2012-08-06 CD4712 CD4711 Add MMSTA in Output
WRITE: lw_mara-matnr, lw_mara-mssta.
Blockänderung – Löschen von Anweisungen
„--> MZ/2012-02-01 CD4711 Import Material number
*CONCATENATE wa_import-aufnr wa_import-vornr
*
INTO str SEPARATED BY ‚ ‚.
„--> MZ-2012-02-01. DELETE
Blockänderung – Einfügen von Anweisungen
„--> MZ/2012-02-01 CD4711 Import Material number
CONCATENATE wa_import-aufnr wa_import-vornr wa_import-matnr
INTO str SEPARATED BY ‚ ‚.
„--> MZ/2012-02-01. INSERT
Verweis auf Stern bzw. Anführungszeichen als Kommentar
Stern-Kommentare sollten nur im Programmkopf oder für das Auskommentieren von altem Code
verwendet werden.
Für alle anderen Kommentare empfiehlt die SAP Inline-Kommentare zu verwenden. Diese sollten
jeweils vor dem Code stehen, den sie dokumentieren, und auch so eingerückt sein wie dieser Code.
WEITERE QUELLEN:
Keller, Thümmel, ABAP-Programmierrichtlinien, SAP Press 2009
37
38
Dieses Kapitel beschreibt, wie sich die Best Practices aus dieser Guideline in der Praxis verwirklichen lassen. Wir unterscheiden hierbei Umsetzbarkeit und Durchsetzbarkeit der Richtlinien.
Im Abschnitt „Umsetzbarkeit“ erklären wir, worauf ein Unternehmen achten sollte, das Programmierrichtlinien einführen möchte. Wir erklären, wie ein Prozess dafür aussehen könnte, wie man
diesen ins Leben ruft und vor allem, wie man ihn am Leben erhält. Im Abschnitt „Durchsetzbarkeit“ legen wir dar, wie ein Unternehmen die Vorgaben aus dem Prozess prüfen kann. Hierzu
gehören organisatorische Aspekte genauso wie Prüfmethoden und Werkzeuge. Wir gehen aber
auch auf Grenzen der Durchsetzbarkeit ein.
Abschließend stellen wir Tipps aus der Praxis vor, die die Autoren bei verschiedenen Projekten im
Umfeld der SAP-Entwicklung gesammelt haben.
7.1Umsetzbarkeit
Wer erfolgreich Programmierrichtlinien in einem Unternehmen einführen möchte, muss zunächst
das Management dafür gewinnen. Denn die Verbesserung der Codequalität bedeutet zunächst eine
Investition in Prozesse und Werkzeuge sowie in die Fortbildung der involvierten Mitarbeiter.
Insbesondere muss das Management überzeugt sein, dass das Unternehmen durch diese
Prozesse langfristig Kosten spart.
7.1.1
Motivation für einen Prozess
Nachfolgend finden Sie Anhaltspunkte, welche Qualitätsaspekte bei der Einführung eines
Prozesses zur Qualitätssicherung adressiert werden und welche Vorteile dies für Unternehmen
hat:
Sicherheit
Vorteil: Das Unternehmen verhindert, dass Anwender unbefugt an kritische Daten gelangen bzw.
unbefugt kritische Daten verändern können.
Risiken bei Qualitätsmängeln: Sabotage, Industriespionage, unerwünschte Pressemeldungen
hervorgerufen durch Datenlecks, Stillstand der Produktivsysteme.
Compliance
Vorteil: Das Unternehmen kann jederzeit nachweisen, dass die entwickelte Software den
Anforderungen relevanter Compliance-Standards und gesetzlichen Regelungen genügt.
Risiken bei Qualitätsmängeln: Die Wirtschaftsprüfung scheitert, Verstoß gegen Compliance-Anforderungen oder gesetzliche Regelungen (z.B. Datenschutz).
Performance
Vorteil: Das Unternehmen stellt sicher, dass die vorhandene Hardware optimal genutzt werden
kann, und schützt damit die bisherige Investition in Hardware. Außerdem steigt die Zufriedenheit
der Mitarbeiter, da die Nutzung der Anwendung produktiver wird.
Risiken bei Qualitätsmängeln: Die Akzeptanz der Anwender sinkt bzw. es entstehen Kosten für
schnellere Hardware, um die Softwaremängel auszugleichen.
Robustheit
Vorteil: Das Unternehmen stellt den kontinuierlichen Betrieb der Geschäftsanwendungen sicher
und vermeidet Unproduktivität auf Grund von Systemausfällen.
Risiken bei Qualitätsmängeln: Die Akzeptanz der Anwender sinkt und die Betriebskosten steigen
wegen Unproduktivität der Anwender sowie durch Fehleranalysen und Wartungsarbeiten durch
Techniker.
Wartbarkeit
Vorteil: Das Unternehmen erreicht, dass die Applikation nachhaltig und kosteneffizient gewartet
werden kann, weil die Programmstruktur leicht verständlich und gut dokumentiert ist.
Risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte Fehleranfälligkeit der
Applikation.
7.1.2Erstellung und Pflege des Prozesses
Für die Umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschreibung eines
Prozesses bewährt. Dazu zählen klare Verfahrensanweisungen und Verantwortlichkeiten. Die
genaue Ausprägung des Prozesses ist unternehmensspezifisch und kann in dieser Guideline nicht
abgebildet werden; der Verweis auf die Notwendigkeit ist jedoch allgemeingültig.
BEST PRACTICE: Definieren Sie den einzuhaltenden Prozess und dokumentieren Sie ihn in einer
für alle zugänglichen Form. Definieren Sie, wie Änderungen und Verbesserungen am Prozess
stattfinden sollen und wie Anmerkungen und Kritik eingebracht werden können. Dokumentieren
Sie alle geprüften Regeln ausführlich mit den Kapiteln Hintergrund/Motivation, schlechte
Beispiele, gute Beispiele, Hinweise zum Vorgehen zur Beseitigung und Literatur bzw. Ansprechpartner im Unternehmen.
Motivation
Ein Prozess für Best Practices bei der Entwicklung hilft, die Qualität von Software pro aktiv und
effizient zu verbessern und damit Kosten im Unternehmen langfristig zu senken. Je früher ein
Fehler bei der Entwicklung erkannt wird, desto einfacher und kostensparender kann er behoben
werden. Je weniger Fehler eine Anwendung enthält, desto mehr entspricht ihre Nutzung den
Erwartungen des Unternehmens. Insbesondere läuft sie ohne Nebeneffekte, die das Business
negativ beeinflussen.
Welche Aspekte sind für den Prozess relevant?
Interne Entwicklung
Für die interne Entwicklung werden Richtlinien als Nachschlagewerk für die tägliche Arbeit und
regelmäßige Trainings für aktuelle Risiken benötigt.
Externe Entwicklung
Bei externer Entwicklung sind klare Qualitätsvorgaben für Ausschreibungen nötig. Vor der
Abnahme müssen die Anforderungen auch überprüft werden.
Übergreifend
Die Vorgaben aus dem Prozess müssen möglichst weitgehend mit geeigneten Tools überprüft
werden. Eine manuelle Prüfung ist nur in seltenen Fällen flächendeckend möglich.
39
40
BEST PRACTICE: Vorgaben ohne werkzeuggestützte Überprüfungsmöglichkeit sind nicht
umsetzbar und sollten daher nicht definiert und vorgegeben werden.
Bei jeder Regel, die zur nachträglichen QS herangezogen werden soll, muss festgelegt werden, wie
diese werkzeuggestützt überprüft werden kann. Wenn keine mechanische Überprüfung durch ein
Werkzeug möglich ist, wird es in der Praxis nahezu unmöglich werden, auf die konsequente
Einhaltung der Regel zu achten. Die Konzentration auf maschinell überprüfbare Regeln erspart
denjenigen, die Qualitätssicherung betreiben sollen, eine Vielzahl an Frustrationsquellen.
Nichtsdestotrotz gibt es etliche Aspekte, die sich einer maschinellen Prüfung entziehen. Diese
Aspekte können sinnvollerweise nur mit regelmäßig durchgeführten Code Reviews abgedeckt
werden. Da gut durchgeführte Code Reviews erhebliche Aufwände in der Durchführung, aber auch
der Vor- und Nachbereitung bzw. Kontrolle von Korrekturen erfordern, müssen diese sich auf
wenige, aber unter den nicht maschinell prüfbaren Aspekten kritischen Entwicklungsobjekten
beschränken. Wenn z.B. die Einhaltung von Performance-Vorgaben eine hohe Priorität besitzt,
sollten in entsprechenden Code Reviews nur Entwicklungsobjekte mit Zugriffen auf Datenbanken
oder umfangreichen Berechnungen beschränkt werden.
Der Prozess muss daher eine Qualitätskontrolle vorsehen, durch die sämtliche Entwicklungen
geprüft werden, bevor sie in den Produktivbetrieb gehen. Es muss auch definiert sein, wie mit
Fehlern verfahren werden soll. Der Prozess muss selbstverständlich regelmäßig aktualisiert
werden, um neue Aspekte berücksichtigen zu können.
7.2Durchsetzbarkeit
7.2.1
Manuelle Prüfungen
Viele der Prüfungen lassen sich automatisieren. Es gibt jedoch Bereiche, die sich für eine
automatische Prüfung nicht eignen, wie beispielsweise Dokumentation, Architektur oder viele
funktionale Anforderungen. Die menschliche Sprache ist sehr komplex, daher muss z.B. der Inhalt
von Dokumenten und Dokumentationen manuell geprüft werden. Nur der menschliche Leser kann
beurteilen, ob ein Text sinnvoll, vollständig, verständlich und korrekt ist. Eine automatische
Prüfung kann dabei maximal die Existenz in den vorgegebenen Sprachen prüfen. Es empfiehlt sich
dennoch ein automatischer Test auf nicht-funktionale Aspekte.
Für die manuelle Prüfung ist es wünschenswert, eine vollständige Prüfung anhand der Auswertung von Transportstücklisten vorzunehmen. Dabei ist zu berücksichtigen, welche unternehmensinternen Richtlinien existieren. Abhängig von der Anzahl der Objekte muss eine vollständige oder
zumindest stichprobenartige Prüfung erfolgen. Das Prüfergebnis wird dem Entwickler/Zuständigen
zur Verbesserung/Vervollständigung der Dokumente/Dokumentationen übermittelt.
Ob ein Prozess alle Vorgaben erfüllt, kann nur mittels einer manuellen periodischen Prüfung
ermittelt werden. Falls sich Vorgaben ändern bzw. Mängel im Prozess aufgedeckt werden, ist der
Prozess entsprechend anzupassen oder ggfs. neu zu definieren.
In der Praxis hat sich ein fest eingeplanter zyklischer Review des Prozesses bewährt.
Wann und wie sollte geprüft werden?
Die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf Aktualität und Konformität
bzgl. der Vorgaben geprüft werden. Die Aktualität ist jedenfalls mit einem Upgrade auf ein neues
Release (Enhancement Package) zu prüfen. Bzgl. der Vorgaben ist es durchaus sinnvoll, das
Wirtschaftsprüfungsunternehmen, welches das Unternehmen prüft, hinzuzuziehen. Für extern
entwickelten Code gilt, dass eine Prüfung vor Abnahme stattfinden muss.
Für die Akzeptanz der Prüfungen bzw. der Beanstandung im Zuge der manuellen Prüfungen ist es
sinnvoll, im Rahmen der Entwickler- und QA-Tests (4-Augen-Prinzip) die manuell notwendigen
Prüfungen durch andere Entwickler durchführen zu lassen.
Dasselbe gilt für Penetrationstests und Belastungstests. Da es sich bei Penetrationstests auch um
ein kritisches Sicherheitsthema handelt, kann es notwendig sein, hierfür in regelmäßigen
Abständen auch externe Partner hinzuzuziehen.
7.2.2Automatische Prüfungen
Automatische Tests decken schnell einen Großteil der notwendigen Tests und Prüfungen ab. Als
Hintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne zusätzlichen Aufwand
möglich. Diese regelmäßig mit gleicher Qualität durchgeführten Tests ermöglichen so den
Entwicklern, ihren Programmierstil zu verbessern.
Wann und wie sollte geprüft werden?
Die Entwickler sollen ein möglichst zeitnahes Feedback bzgl. der Konformität der Entwicklungen
mit den Richtlinien erhalten. Dazu dienen täglich eingeplante Prüfungen im Entwicklungssystem,
deren Ergebnis dem Entwickler zur Verfügung gestellt wird. Wichtig ist, dass dieselben Tests und
Metriken bei der Prüfung durch jeden einzelnen Entwickler und bei der Prüfung durch zentrale
QS-Instanzen bzw. bei einer Transportfreigabe verwendet werden. Sollten für diese Prüfungen
unterschiedliche Werkzeuge oder unterschiedliche Einstellungen verwendet werden, sinkt die
Akzeptanz in Entwicklerkreisen ganz erheblich.
Als zentrale Schutzinstanz müssen die Prüfungen in das TMS und da spätestens mit der Freigabe
des Transportauftrags (besser der einzelnen Transportaufgaben) implementiert sein. Damit wird
sichergestellt, dass keine ungeprüften bzw. nicht den Richtlinien entsprechenden Entwicklungen in
die Folgesysteme und dann auch in das Produktivsystem transportiert werden.
Als „letztes Sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsystem
vorzusehen. Dieser sollte in einer lastarmen Zeit mittels Hintergrundjob eingeplant werden. Das
Ergebnis wird dem QA-Zuständigen zur Verfügung gestellt, der dann die weiteren Schritte (ggfs.
Korrektur) mit hoher Priorität veranlasst.
Bei allen automatischen Prüfungen ist im Vorfeld zu definieren, wie mit altem Code umgegangen
wird. Sinnvoll scheint es hierfür auch, einen Fahrplan zu erstellen, wann und wie die neuen Regeln
auf alten Code angewendet werden.
41
42
7.2.3Werkzeuge
Nachstehend werden einige Tools aufgelistet, mit welchen die automatisierten Prüfungen
durchgeführt werden können.
SAP Code Inspector
Der SAP-Code Inspector wird seitens SAP im Standard ausgeliefert und ist entsprechend in die
Entwicklungsumgebung hoch integriert. SAP sieht ein Erweiterungskonzept vor, welches
ermöglicht, kundenspezifische Prüfungen selbst zu implementieren. Hierfür sind ggfs. Programmierarbeiten notwendig. Die seitens SAP ausgelieferten Prüfungen können teilweise weitgehend
parametrisiert werden. Inspektionen auch von großen Objektmengen können sowohl online als
auch im Batchbetrieb erfolgen und Ergebnismengen von vorangegangenen Inspektionen können
wieder als Objektmenge verwendet werden, um die Kontrolle von Korrekturen auf die vorher
fehlerbehafteten Objekte zu beschränken. Weiterhin können Ergebnisse auch automatisch per
E-Mail an die verantwortlichen Entwickler verteilt werden.
Werkzeuge von Drittherstellern
Neben dem SAP Code Inspector gibt es am Markt sehr gute kommerzielle Tools, die Prüfungen auf
Code-Ebene vornehmen. Eine Beschreibung dieser Tools soll aus Neutralitätsgründen an dieser
Stelle unterbleiben.
7.3Erfahrungen und Tipps aus der Praxis
7.3.1
Qualitätssicherung des Quellcodes
Um eine erfolgreiche Einführung zu gewährleisten, ist es wichtig, Qualitätssicherung schrittweise
und behutsam einzuführen. Hierbei empfiehlt es sich, einen zweigeteilten Ansatz zu fahren.
Zunächst sollte neuer Code „fehlerfrei“ erstellt und dies geprüft werden. Erst wenn sich dieser
Prozess stabilisiert hat, sollte nach und nach Bestandscode mit in die Checks aufgenommen
werden, sonst wird der zu bewältigende Berg für den Entwickler zu groß und die Motivation sinkt
rapide.
Wenn nicht auf der „grünen Wiese“ mit einer neuen Entwicklung begonnen wird, wenn automatische Codeprüfungen eingeführt werden, ist es wichtig, vorher den Umgang mit „Altlasten“ zu
klären. Auch bei neuen Entwicklungen lassen sich Änderungen an schon bestehenden Objekten
nicht vermeiden, die dann bei einer eingerichteten Transportprüfung zu Problemen führen.
Hilfreich ist in solchen Fällen eine Klärung der Verantwortlichkeit für Entwicklungsobjekte, die z.B.
durch das entsprechende Feld in Paketdefinitionen dokumentiert werden kann. Diese Verantwortlichen müssen entscheiden, ob Fehler im Bestandscoding sofort korrigiert werden müssen oder
eine Ausnahmeregelung möglich ist.
In vielen Fällen ist es schon ausreichend, mit Standard-Bordmitteln, wie z.B. Code Inspector, zu
arbeiten, der sich auch um eigene Checks erweitern und somit an eigene Bedürfnisse anpassen
lässt. Im NetWeaver 7.02 sind einige neue Prüfungen in der Auslieferung enthalten wie Suche nach
bestimmten kritischen Anweisungen, Verwendung der ADBC-Schnittstelle, mandenatenabhängige
Shared-Objects-Methoden, Robuste Programmierung und ABAP-WebDynpro-Metrik.
7.3.2Zeit und Budget QA
Um die Zeit und den Aufwand für die QA-Tätigkeiten möglichst gering zu halten, muss der
Entwickler die Möglichkeit haben, den Code während seiner Entwicklertätigkeit selbstständig auf
Fehler hin untersuchen zu können.
Tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten hingewiesen
werden. Tägliche Inspektionen mit einem entsprechenden Werkzeug und Verteilung der Ergebnisse stellen sicher, dass Fehler frühzeitig erkannt werden und die Entwickler sich noch an ihre
Tätigkeiten vom Vortrag erinnern, was die Fehlerbehebung deutlich vereinfacht. So wird gewährleistet, dass auch Entwickler, die den manuellen Aufwand scheuen oder unter Zeitdruck stehen,
trotzdem die Möglichkeit erhalten, ihre Fehler im Code zu beheben. Hier ist zu bemerken, je später
die QA einsetzt, desto höher ist der Aufwand für die Fehlerbehebung. Dieser zusätzliche Aufwand
entsteht z.B. durch zusätzliche Transporte, wenn der Originaltransport bereits freigegeben wurde.
Deshalb ist es wichtig, bei Planung und Schätzung eines Projektes die Qualitätssicherung zu
berücksichtigen, und zwar nicht nur am Ende, sondern projektbegleitend und anschließend im
kompletten Software-Lifecycle.
Nicht zu unterschätzen ist auch der Schulungsaufwand, der benötigt wird, um bei den Entwicklern
um Verständnis für den Prozess zu werben.
Bei einem Einsatz von externen Entwicklern müssen die Programmierrichtlinien und Namenskonventionen Bestandteil des Vertrages sein.
7.3.3Probleme
Bei der Einführung einer Code QA treten eine Reihe von Problemen auf, auf die hier kurz
eingegangen wird.
Ein Reibungspunkt ergibt sich durch die Frage, wer für die QA zuständig ist, Ersteller oder Änderer.
Bei neuen Sourcen ist dies kein Problem, bei Bestandscode aber wird die Frage immer wieder
aufgeworfen:
„Warum soll ich Code überprüfen, in dem ich nur eine Zeile geändert haben?“
vs.
„Warum soll ich Code überprüfen, den ich schon Jahre nicht mehr angefasst habe?“
Beide Positionen sind natürlich verständlich, deswegen muss eine klare Entscheidung bezüglich
Handhabung von kopiertem Code, der auf anderen/keinen Konventionen beruht, getroffen und
durchgesetzt werden.
BEST PRACTICE: Um bei auftretenden Problemen die Fragen der Entwickler zu beantworten, ist es
wichtig, dafür eine zentrale Stelle zu schaffen. Außerdem muss es einen Prozess geben, um in
Notfällen auch fehlerbehaftete Transporte freizugeben. Gibt es diese Möglichkeit nicht, sinkt das
Verständnis für die durchgeführten Maßnahmen. Eine Möglichkeit ist es hierbei, einen Genehmigungsprozess zu installieren, mit dessen Hilfe auch fehlerbehafteter Code freigegeben oder
transportiert werden kann. Die meisten Tools am Markt bieten diese Möglichkeit standardmäßig an.
43
44
7.3.4Entscheidungsfindung bei Modifikationen
Wichtig ist es, die Hürde für Modifikationen so hoch wie möglich zu legen. Dies ist besonders wichtig,
wenn man sich dazu entscheidet, zeitnah Enhancement Packages der SAP einzuspielen (SPAUProblematik). Ansatzpunkt hierzu ist der Modifikationsschlüssel. Die Anzahl der Entwickler, die die
Berechtigung haben, Modifikationsschlüssel zu generieren, muss möglichst gering sein. So ist es
möglich, steuernd einzugreifen und diese über Change Requests und einen zugehörigen Prozess
abzuhandeln.
Die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu beantworten
und konsequent umzusetzen. Eine Pauschalantwort auf diese Frage gibt es nicht. In jedem Fall
sollte die Entscheidung jedoch auf gleichartigen, im Vorfeld definierten und kommunizierten
Kriterien basieren.
7.3.5Erfahrungsbericht aus der Praxis: Comgroup GmbH
Das nachfolgende Beispiel der Comgroup GmbH, dem IT-Dienstleister der Würth Gruppe, zeigt wie
Programmierrichtlinien und Namenskonventionen in einer Softwareentwicklung ein- und
durchgesetzt werden können.
Die Comgroup GmbH startete mit der Code QA im globalen Entwicklungssystem einer mehrstufigen Entwicklungslandschaft. Zur automatisierten Unterstützung wurde der Code Inspector
eingesetzt. Da die Code-QA-Einführung mit der Einführung eines neuen Namensraumes
zusammenfiel, wurden zu Beginn des Projekts nur Objekte aus dem neuen Namensraum geprüft
und Bestandscode nicht berücksichtigt. Dies erleichterte die Selektion im Code Inspector, da
dieser keine Änderungs- oder Erstellungsdaten bei der Selektion berücksichtigt. Außerdem
wurden Performance- und Security-Checks aus dem Code Inspector vorerst nicht aktiviert, um den
Aufwand in einem überschaubaren Rahmen zu halten.
Hierdurch hat der Entwickler die Möglichkeit, seinen Code während seiner Entwicklertätigkeit
selbstständig zu checken. Zusätzlich wurde ein Nachtlauf eingeplant, der den kompletten zu
scannenden Code analysiert und bei gefundenen Fehlern Mails an den jeweiligen Entwickler
sendet. Probleme bereitete hierbei, dass es viele User im System gab, die keine zugeordnete
Mailadresse hatten, was dazu führte, dass zu Beginn Mails ihren Empfänger nicht erreichten.
Mails an Entwickler ohne Mailadresse werden an eine zentrale Adresse versendet und somit
können die unvollständigen Datensätze mit einem geringen Aufwand identifiziert werden. Deshalb
werden nun keine Entwicklungs-User mehr im System ohne Mailadresse angelegt.
Die Mails wurden nicht von einem anonymen Batch-User sondern von der Mailadresse des
QA-Verantwortlichen gesendet, um dem Entwickler einfach die Möglichkeit zu geben, Fragen zu
stellen. Zu Beginn entstand hierdurch ein hoher Aufwand, die Anzahl der Fragen verringerte sich
aber mit der Laufzeit des Projekts. Dies konnte erreicht werden, da Schulungen durchgeführt
wurden und so die Entwickler effizienter die Fehler korrigieren konnten oder diese schon bei der
Entwicklung vermieden.
Die Entwicklungssprache in der Entwicklungslandschaft ist Englisch. Dies wird durch einen
weiteren Job geprüft und bei Fehlern dem Entwickler gemeldet. SAP bietet keine Möglichkeit im
Standard, bei der Anlage die richtige Sprache zu setzen. Deshalb bot sich nur die Möglichkeit, an
passender Stelle eine entsprechende Prüflogik per Modifikation einzubauen oder damit zu leben,
dass Objekte in falscher Sprache angelegt werden und danach umgezogen werden mussten.
Bei Anlage von Objekten wurden Namenskonventionen für die Objekte gecheckt, sodass diese nur
nach Konventionen benannt werden konnten (ebenfalls per Modifikation).
Um eigene Checks bei der Transportfreigabe durchzuführen (z.B. eigene Namenskonventionen/
mind. deutsche und englische Übersetzung) wurde eine Implementierung für das Business Add In
CTS_REQUEST_CHECK angelegt und die Methode CHECK_BEFORE_RELEASE genutzt.
Nachdem der Prozess sich im globalen Entwicklungssystem stabilisiert hatte, wurde dieser an die
nachfolgenden Entwicklungssysteme und Namensräume ausgerollt. Bestandscode wird bisher
noch nicht gecheckt. Zusätzlich ist geplant, ein externes Tool einzusetzen, das die Qualitätssicherung vereinfacht.
45
46
8Infrastruktur und Lifecycle
Management
Neben methodischen Empfehlungen und Werkzeugen zur Unterstützung bei der Softwareentwicklung im SAP-System stellen die Infrastruktur und die Betrachtung des Lebenszyklus einer
Softwarekomponente eine wichtige Rahmenbedingung für erfolgreiches Arbeiten dar. In diesem
Kapitel liegt auf diesen beiden Aspekten der Fokus.
8.1Infrastruktur
Eine SAP-Systemlandschaft ist i.d.R. mehrstufig aufgebaut. Nachfolgend werden die einzelnen
Systeme und ihre Bedeutung dargestellt:
8.1.1Sandbox
Die Sandbox ist ein reines Test- und „Spielsystem“. In der Sandbox gelten keine Einschränkungen
in Bezug auf Berechtigungen, das gilt gleichermaßen für Customizing- und Workbench-Entwicklungen. Aus der Sandbox sind keine Transporte in andere Systeme erlaubt. Änderungen können
ausprobiert werden, bevor sie im Entwicklungssystem durchgeführt werden. Damit kann der
Rückbau komplexer Entwicklungen in der Entwicklungsumgebung vermieden werden, wenn z.B.
eine Neuentwicklung nicht weiter verfolgt werden soll.
8.1.2Entwicklungssystem
Ein kombiniertes Entwicklungs-/Testsystem (z.B. Entwicklungsmandant 010, Testmandant 110)
bietet sich als einfache und praktikable Lösung an. Es ist beispielsweise kein Transport von
Workbench-Objekten erforderlich, um Neuentwicklungen zu testen.
Im Testmandanten herrscht dabei absolutes Customizing-Verbot. Customizing dieses Mandanten
wird ausschließlich durch Mandantenkopie aktualisiert (SCC1). Entwickler/Modulbetreuer haben
im Testsystem sehr weitreichende Berechtigungen. Einschränkungen müssen individuell festgelegt
werden, z.B. für besonders sensible Daten (HR etc.).
Berechtigungen/Rollen werden grundsätzlich im Entwicklungssystem erstellt und transportiert.
Generell werden alle zu transportierenden Änderungen in einem Mandanten im E-System
vorgenommen.
8.1.3Qualitätssicherungssystem
Im QA-System herrscht absolutes Customizing- und Entwicklungsverbot. Customizing- und
Workbench-Objekte werden ausschließlich per TA importiert. Importe nach Produktion erfolgen
grundsätzlich über das QA-System. Damit wird die Übereinstimmung einer mit Produktion
übereinstimmenden Systemumgebung sichergestellt.
Das QA-System wird bei Bedarf z.B. für umfangreichere Validierungsaktivitäten aus dem
Produktionssystem kopiert. Damit wird auch die Übereinstimmung mit der operativen (Daten-)
Umgebung sichergestellt. Im QA-System erfolgt die Durchführung von Testplänen nach Änderungen und Neuentwicklungen. Entwickler/Modulbetreuer haben im QA-System sehr weitreichende Berechtigungen. Einschränkungen müssen individuell festgelegt werden, z.B. für
besonders sensible Daten (HR etc.). Es empfiehlt sich aber auch, Testbenutzer mit produktionsnahen Berechtigungen zu verwenden.
8.1.4Produktion
Im Produktionssystem herrscht absolutes Customizing- und Entwicklungsverbot. Customizingund Workbench-Objekte werden ausschließlich per Transportauftrag in dieses System importiert.
Entwickler/Modulbetreuer haben im Produktionssystem nur eingeschränkte Berechtigungen;
Emergency-Tabellenänderungen (&SAP_EDIT) sind zu dokumentieren mit Datum/Uhrzeit und
Begründung. Hierzu empfiehlt sich die Verwendung eines Tools, um die Meldungen zu standardisieren. Der Umgang mit Notfall-Usern muss technisch und organisatorisch festgelegt werden.
8.1.5Transportwesen
Wir empfehlen, die technische Freigabe von Transporten grundsätzlich durch interne, verantwortliche Bearbeiter durchführen zu lassen, nicht von externen Beratern. Hierbei ist generell die
formale Freigabe vorausgesetzt (siehe Change-Verfahren). Importe werden generell zentral von der
SAP-Basis durchgeführt, ausgenommen die Mandantenkopie innerhalb des Test-/Entwicklungssystems.
Der Transportweg ist wie folgt festgelegt:
Entwicklung -> QA -> Produktion
Die Sandbox sollte aus dem Transportweg ausgeschlossen werden. Importe in die Sandbox
erfolgen nur auf individuelle Anforderung. Dabei ist der Transportweg immer Entwicklung ->
Sandbox, nicht umgekehrt!
Die Importe in das QA-System müssen in Abhängigkeit der Systemlandschaft organisiert werden.
Falls möglich, können Importe in QA zyklisch und automatisiert durchgeführt werden, um die
Mitarbeiter der Basisabteilung zu entlasten.
Importe in das Produktivsystem sind explizit unter Angabe der TA-Nr. freizugeben. Hierfür wird
ebenfalls die Verwendung eines geeigneten Tools (z.B. Solution Manager) zur Standardisierung/
Formalisierung empfohlen.
BEST PRACTICE: Checkliste vor Ausführung eines Workbench-Transports:
1. Tests erfolgt? Sämtliche Funktionen wurden erfolgreich getestet und (kundenseitig) abgenommen
2. Code geprüft? Der Code Inspector/Erweiterte Programmprüfung wurde für alle Programme des Transportauftrags durchgeführt: Die Ergebnisliste darf dabei keine Fehler oder Warnungen enthalten, Informationsmeldungen sind zulässig
3. Drittanbietertools? Sofern weitere Testtools für Themenbereiche wie Security, Performance, … vorhanden sind, wurden diese eingeplant
4. Manuelle Vor-/Nacharbeiten? Es ist zu prüfen, ob eine vollständige Checkliste für manuelle Vor-/Nacharbeiten zum Transport vorliegt
5. Mehrsprachigkeit? Sofern mehrsprachige Objekte im Transportauftrag enthalten sind, ist zu prüfen, ob die Übersetzungen vorhanden sind
47
48
Management
6. Abhängigkeiten in den Transporten? Falls ein Vorabtransport durchgeführt wurde, muss auf Abhängigkeiten in den Transporten geprüft werden
7. Namenskonventionen? Erstellen einer Liste der Transportobjekte und Prüfung der Einhaltung der Namenskonvention anhand der Objektliste
8. Dokumentation (systemintern)?
a.Systemintern: Prüfung aller Objekte hinsichtlich erstellter/aktualisierter SAP-Dokumenta
tion, z.B.
- Reportdokumentation (Beschreibung und in ABAP-Coding)
- FuBa-Dokumentation komplett (Parameter, Ausnahmen etc.)
- Datenelemente, Strukturen, Tabellen (Beschreibung, Überschriften etc.)
Vorgehensweise: Erstellen einer Liste der Transportobjekte und Prüfung anhand der Objektliste
b.Außerhalb des Systems: Dokumentation vorhanden/vollständig/abgenommen?
8.1.6Rückbau von Neuentwicklungen
Wenn Entwicklungen im Entwicklungssystem erstellt, aber nicht weitertransportiert worden sind
bzw. nur ins QS-System importiert wurden, sind die Änderungen im Entwicklungssystem zurückzubauen. Im Falle der Nutzung von Quality Assurance (QA) als Genehmigungsworkflow gilt:
>Die Ablehnung verhindert lediglich den Weitertransport ins Produktionssystem. Die abgelehnte Entwicklung/Customizing ist aber im Entwicklungs- und im Qualitätssicherungssystem noch vorhanden. Daraus ergibt sich ein „Schiefstand“ zwischen den Einstellungen einerseits des Entwicklungs-/Qualitätssicherungssystems sowie andererseits des Produktionssystems.
>Um den Schiefstand zu beseitigen, muss die abgelehnte Entwicklung im Entwicklungssystem zurückgenommen, dort in einen Transportauftrag aufgenommen und ins Qualitätssystem transportiert werden.
>Der Transportauftrag, der die Rücknahme enthält, soll im Qualitätssystem ebenfalls abgelehnt werden. Damit wird die Übereinstimmung der Einstellungen zwischen den Systemen wiederhergestellt.
>Die zuständigen Entwickler müssen von abgelehnten Transporten erfahren. Die Pflicht zur Informationsweitergabe soll bei den für die QA-Genehmigungen zuständigen Personen liegen.
8.1.7Sicherstellung der Konsistenz von Neuentwicklungen/Erweiterungen
Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. Es kann zur überschneidenden Verwendung von Objekten kommen, die es im Zielsystem (noch) nicht gibt. Dies führt
zum Fehler beim Import. Hieraus ergibt sich die Pflicht zur Prüfung der von Dritten (Non-SAP)
erstellten Objekte bei deren Verwendung. Neuentwicklungen/Erweiterungen müssen in geeigneten
Paketen bzw. Transportaufträgen gekapselt werden. Es wird empfohlen, die Transportaufträge für
ein Projekt auf je 1 TA für Workbench, Customizing und Berechtigungsrollen einzuschränken.
‚Vorabtransporte’ sollten nur mit Hilfe von „Kopientransporten“ erlaubt sein.
Die endgültige Freigabe und der Transport erfolgt erst zum Projektabschluss. Alle Projektmitarbeiter
verwenden innerhalb eines Projekts nur Aufgaben zu einem jeweils vorgegebenen TA. Es gibt keine
‚persönlichen’ Transportaufträge für Projektmitarbeiter.
Generell erfolgt ein Import nur nach formeller Freigabe (siehe Change-Verfahren) durch einen
Process Owner, QS o.ä. Instanzen. Die Abfolge sowie die beteiligten Bereiche müssen unternehmensspezifisch festgelegt werden.
8.2
Change Management
Um eine SAP-Systemlandschaft wartbar und beherrschbar zu gestalten, ist ein formales ChangeVerfahren die Voraussetzung für jede Systemänderung. Dabei ist das grundsätzliche Verfahren
unabhängig davon, ob es sich um Änderungen am SAP-Standard oder an Kundenentwicklungen
handelt.
Das Basiswerk zur Einführung eines Change- und Releasemanagements ist die Information
Technology Infrastructure Library (ITIL). In diesem Referenzleitfaden sind umfangreiche und
allgemeingültige Best Practices beschrieben.
In diesem Kapitel stellen wir einen konkret realisierten Praxisfall aus der Entwicklung dar, der
firmen- bzw. branchenspezifisch adaptiert werden kann.
Wir empfehlen grundsätzlich, die folgenden Aspekte bei der Einführung eines Change-Control(auch: Change-Request-)Verfahrens zu berücksichtigen:
> Fachliche Anforderung
>Begründung
> Bewertung (Aufwandschätzung)
>Genehmigung
> Freigabe der Änderung für das Produktionssystem
Der Genehmiger-/Freigeberkreis (Process Owner, QS …) ist abhängig vom Gegenstand der
Änderung (betroffener Bereich, betroffene Anwendung, gegebenenfalls auch Aufwand).
Die Verwendung eines geeigneten Tools (z.B. Solution Manager) wird dringend empfohlen. Dabei
gilt jedoch: Eine papierbasierte Lösung ist besser als keine!
49
50
Management
Beispiel für ein Change-Control-Formular (CC):
Abbildung 4: Change-Control-Formular
Das abgebildete CC-Formular enthält beispielhaft die wesentlichen Daten, die begleitend zur
Abwicklung einer Systemänderung erforderlich sind.
Basisprozess und Rollen:
> der Anforderer füllt den Teil ‚Anfordernde Abteilung’ aus und sorgt für die Unterschrift des Process Owners/des Process Owners fremd
> der Process Owner ist in der Regel ein Vorgesetzter des Anforderers, er ist verantwortlich für einen bestimmten Teil der Daten bzw. für die Nutzung bestimmter Teile der SAP-Software, z.B. der Einkaufsleiter für die SAP-Einkaufsdaten und -programme
> der Process Owner fremd ist immer dann einzubeziehen, wenn eine Änderung auch Teile betrifft, die außerhalb der eigentlichen Zuständigkeit des Process Owners liegen
Beispiel: Der Einkäufer benötigt Berechtigungen aus dem Bereich der Anlagenbuchhaltung; hier muss der Process Owner zustimmen, der diesen Teil des Systems verantwortet (z.B. der Leiter der Anlagenbuchhaltung).
>Eine ausführliche Beschreibung der Änderung ist in jedem Fall dem CC als Anlage anzufügen; CCs ohne eine ausführliche Beschreibung werden zurückgewiesen.
>Der Anforderer gibt das CC an die IT weiter.
>Der SAP-Koordinator ist derjenige, der die anfallenden Aktivitäten für SAP oder einen Teil von SAP koordiniert und den einzelnen Modulbetreuern die Aufgaben zuweist.
Diese Aufgabe kann – in Abhängigkeit der Größe der Organisation – auch von einem Gruppen- oder Abteilungsleiter innerhalb der IT übernommen werden. Die betreffende Person trägt die Applikation/das Modul im Formular ein und weist das CC einem Bearbeiter zu; sie kann das CC auch aufgrund formaler Fehler (fehlende/unzureichende Beschreibung oder fehlende Unter-
schrift des Process Owners/Process Owner fremd) zurückweisen. Der SAP-Koordinator vergibt eine eindeutige CC-Nummer und den CC-Titel; die Nummer kann z.B. auch von einem Projektverfolgungs-/-dokumentationstool übernommen werden.
>Der IT-Leiter/Leiter SAP genehmigt / lehnt ab / stellt zurück (mit entsprechender Begründung),
nachdem der Koordinator genehmigt hat.
>Im Falle der Genehmigung erhält der Bearbeiter das CC zur weiteren Bearbeitung; eine Änderung zwecks Weitertransport darf von einem Bearbeiter nicht ohne ein vollständig genehmigtes CC durchgeführt werden.
>Nach Fertigstellung lässt der Bearbeiter die Änderung durch den Anforderer prüfen.
>Entspricht die Umsetzung den Anforderungen, gibt der Anforderer die Änderung zum Transport frei; der Anforderer bestätigt mit seiner Unterschrift die ordnungsgemäße Umsetzung;
ein Transport darf nicht ohne vorangegangene Freigabe durch den Anforderer durchgeführt werden.
>SAP-Koordinator und IT-Leitung bestätigen die ordnungsgemäße Umsetzung; ein Transport darf nicht ohne vorangegangene Freigabe durch die SAP-Koordination und die IT-Leitung durchge-
führt werden.
>Der Bearbeiter übergibt den Transport in das Produktionssystem und leitet das CC an die SAP Koordination und die IT-Leitung weiter.
Der Genehmigungs- und Freigabeprozess und damit auch der Inhalt des Formulars kann branchenspezifisch stark variieren. In pharmazeutischen Unternehmen ist beispielsweise grundsätzlich die
QA in das CC-Verfahren eingebunden. Darüber hinaus ist es in allen Unternehmen üblich, dass bei
Überschreiten bestimmter (geschätzter) Projektkostenlimits weitere Genehmiger der Umsetzung
einer Änderungsanforderung zustimmen müssen. Die Genehmigungsstruktur hängt also im
Wesentlichen von der jeweiligen Unternehmensorganisation ab.
Das Formular enthält daher lediglich die Minimalanforderungen an ein CC ohne Berücksichtigung
branchen- oder organisationsspezifischer Anforderungen.
51
52
Management
Weitere Genehmigungs- oder Freigabeschritte, aber auch zusätzliche Felder mit Bezug zu anderen
Dokumenten (z.B. Validierungsdokumente) sind bei Bedarf individuell zu ergänzen und der Prozess
entsprechend zu erweitern.
WEITERE QUELLEN:
1. Mathias Friedrich, Torsten Sternberg, Change Request Management mit dem SAP Solution Manager, SAP Press, 2009
2.Information Technology Infrastructure Library (ITIL)
8.3Softwarewartbarkeit
Die Wartbarkeit von Software ist ein Kriterium bei der Entwicklung von Software und zeigt an, mit
welcher Energie und mit welchem Aufwand Änderungen in einem Systemzusammenhang von
Applikationen durchgeführt werden können. (Quelle: Wikipedia)
Technisch ist ein modularer Aufbau von Objekten entsprechend SAP-Praxis, d.h. Include-Struktur
in allen Programmen erforderlich. Dies umfasst auch die Verwendung von Funktionsbibliotheken,
die auch anderen Entwicklern zugänglich sein müssen und von ihnen leicht aufgefunden werden
können.
In Systemumgebungen mit verschiedenen Entwicklungs- und Produktionssystemen (Transportstrecken) muss der Grundsatz gelten: gleicher Objektname (T-Code, Programm, Include, Tabelle
etc.) bedeutet auch identische Funktionalität.
Unterschiedliche Funktionalität bedingt entweder ein eigenes Objekt oder – falls möglich – eine
entsprechende Customizing-Funktion.
Alle Entwicklungen/Änderungen/Korrekturen sind sauber zu dokumentieren.
8.4Anpassungen der SAP-Funktionalität
Um die Funktionalität eines SAP-Systems an eigene Bedürfnisse anzupassen, gibt es verschiedene
Möglichkeiten, die jeweils Vor- und Nachteile mit sich bringen:
>Modifikation
>Z-Kopie, Kopie in Kundennamensraum
>Erweiterungen (User-Exit, Customer-Exit, BAdI, Enhancement, BTE)
Zu den problemlos nutzbaren Techniken zählen User-Exits, Customer-Exits, BTEs und BAdIs.
Deshalb ist es zu empfehlen, diese zu verwenden, sofern diese vorhanden sind und ihre Schnittstelle
alle nötigen Daten zur Verfügung stellt. Hier eine kurze Beschreibung dieser Techniken:
User-Exit
User-Exits sind Unterprogramme, die sich in Includes im SAP-Namensraum befinden, aber nur
einmalig von SAP ausgeliefert werden und deshalb ohne Probleme „modifiziert“ werden können.
Customer-Exit
Customer-Exits sind Funktionsbausteine, die zu- und abschaltbar sind und vom Kunden implementiert werden können, um Standardfunktionalität zu erweitern.
Business Transaction Events (BTE)
Im FI-Umfeld stellen BTEs eine zusätzliche Möglichkeit der Erweiterung dar. BTEs sind vergleichbar mit Customer-Exits, beschränken sich jedoch auf das FI Modul und stellen eine vordefinierte
Schnittstelle zur Verfügung an die der Entwickler Erweiterungen anhängen kann.
Weitere Informationen finden sich in der SAP-Standarddokumentation.
BAdI
Mit BAdIs versuchte SAP die Nachteile anderer/bisheriger Erweiterungstechniken zu umgehen:
> nur einfach verwendbar (Customer-Exits)
> keine Dynpro-Erweiterungen (BTEs)
> keine Menü-Erweiterungen (BTEs)
> keine Verwaltungsebene (BTEs)
Deshalb sind BAdIs mehrfach verwendbar, stellen alle Erweiterungsarten (Programm- / Menü- /
Dynpro-Exit) zur Verfügung und sind objektorientiert ausgeführt.
Kann mit den bereits genannten Erweiterungen das gewünschte Ergebnis nicht erreicht werden,
gibt es weitere Möglichkeiten, deren Verwendung aber von Fall zu Fall abgewogen werden muss.
Enhancement Point / Enhancement Section
Enhancement Point:
Bietet die Möglichkeit, an festgelegten Stellen (implizit oder explizit) Code einzufügen.
> mehrere aktive Implementierungen
> alle aktiven Implementierungen werden ausgeführt
Enhancement Section:
> mehrere aktive Implementierungen möglich
> nur eine aktive Implementierung wird ausgeführt
> nicht klar, welche aktive Implementierung ausgeführt wird
53
54
Management
Hinweis: Implementierungen von Enhancement Sections können durch das Einspielen von SAP
Enhancement Packages oder das Aktivieren von Business Functions durch neue aktive Implementierungen oder neu aktivierte Implementierungen ersetzt werden. Es ist hierbei sehr schwierig,
ersetzte und nicht mehr ausgeführte Implementierungen zu identifizieren. Somit kann sich durch
Änderungen im SAP Standard das Verhalten der Erweiterung ändern. Dies erhöht den notwendigen
Testaufwand (TCO!) massiv und führt leicht zu Disruption bei einem SAP Releaseupgrade und EHP.
Die Verwendung von Enhancement Sections ist daher sehr sorgfältig zu prüfen.
Bei der Verwendung von Enhancements ist die SPAU_ENH zu abarbeiten, da die Enhancements in
der regulären SPAU-Transaktion nicht angezeigt werden.
Die Entscheidung, ob Enhancements als Erweiterungskonzept genutzt werden sollen, ist also nicht
nur abhängig vom Realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.
Modifikation
Grundsätzlich sollte nur dann modifiziert, wenn:
> Customizing oder Personalisierung Ihre Anforderung nicht umsetzen können
> geeignete Erweiterungen oder User-Exits nicht vorgedacht sind
> das Kopieren des SAP-Objekts in den Kundennamensraum nicht sinnvoll ist
Für Modifikation/Exits/BADIs wird – zusätzlich zum Change Verfahren – ein separates Genehmigungsverfahren empfohlen. Hierzu gehören Antrag -> Begründung -> Genehmigung. Die
Entscheidung muss von dem/den jeweiligen Systemverantwortlichen (IT-Leitung) getroffen werden.
Vorteil hierbei ist, dass der Entwickler einen Modifikationsschlüssel eingeben und dieser zentral
vergeben werden kann. Es kann also relativ einfach verhindert werden, dass ungewollte Modifikationen ins System eingebaut werden.
Kopien in eigenen Namensraum/Z-Namensraum
Kopien von SAP-Standardcode in den Kundennamensraum sind sehr pflegeaufwändig. Bislang gibt
es kein automatisiertes Verfahren und keine manuelle Regelung, wie ein späterer Abgleich (bspw.
nach Support-Packages oder Hinweiseinbau) zwischen Original und Z-Kopie erfolgen kann. Eine
allgemeine Empfehlung kann an dieser Stelle nicht gegeben werden, da Vor- oder Nachteile
jeweils im unterschiedlichen Kontext abgewogen werden müssen.
BEST PRACTICE für die Durchführung von Modifikationen:
> Grundsätzlich sind Workbench-Modifikationen nur unter Verwendung des Modifikations assistenten erlaubt!
>Eine Z-Kopie ist nicht immer die erste Wahl, da dies u. U. mit sehr hohem Realisierungsauf-
wand verbunden ist. Darüber hinaus gehen Weiterentwicklungen im Standard unberücksichtigt an der Z-Kopie vorbei, d.h., es resultiert ebenfalls ein Aufwand für die Anpassung bzw.
Erstellung einer neuen Z-Kopie. Nach dem Einspielen von Enhancement Packages können
verwendete Standard-Includes zu Problemen führen.
>Die Entscheidung Modifikation vs. Z-Kopie vs. Enhancement ist also nicht nur abhängig vom Realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.
> Keine der Möglichkeiten Modifikation/Z-Kopie/Enhancement hat nur Vor- oder nur Nachteile, es ist hier von Fall zu Fall zu prüfen, welche Technik die wenigsten Nachteile im speziellen Fall mit sich bringt.
>Es wird empfohlen, eine zentrale, formalisierte, technische Dokumentation aller Modifikationen
einzurichten. Für Kopien und Erweiterungen sollten geeignete Templates bereitgestellt und es
sollte eine Pflicht zu deren Verwendung bestehen.
WEITERE QUELLEN:
SAP Schulungen BC425 und BC427
8.5Testbarkeit von Anwendungen
Um die Testbarkeit von Anwendungen zu gewährleisten, müssen die Testanforderungen zu einem
sehr frühen Zeitpunkt in der Entwicklung festgelegt werden. Gewachsenes Coding nachträglich
testbar zu machen, ist meistens mit sehr hohem Aufwand verbunden, der keine neue Funktionalität bietet und daher in der Praxis sehr niedrig priorisiert wird.
Um wirtschaftlich sinnvoll mit Tests umzugehen, müssen Tests automatisiert werden. Dazu ist es
notwendig, die Durchführung von Tests wiederholbar zu machen. Versuchen Sie, den Code so zu
schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werden
kann. Das bedeutet, insbesondere auf dynamische Anweisungen zu verzichten, da deren semantische Bedeutung erst zur Laufzeit bekannt ist und von einem statischen Tool nicht hinreichend
analysiert werden kann.
BEST PRACTICE: Verwenden Sie von Anfang an automatisierte Tests (ABAP Unit, eCATT), um die
Automatisierung von Tests zu einem „normalen“ Bestandteil der Entwicklung zu machen.
BEST PRACTICE: SAP unterstützt mit der Test-Workbench testgetriebene Entwicklungen durch
Modultests. Testklassen werden als lokale Klassen angelegt und durch den Zusatz „FOR TESTING“
als solche kenntlich gemacht. Der dort implementierte Programmcode wird lediglich ausgeführt,
wenn die Anwendung über den Menüpunkt „Modultest“ in der ABAP-Workbench aufgerufen wird.
Sogenannte Risk-Levels geben die Kritikalität eines Tests im Falle des Scheiterns an und
Systemeinstellungen verhindern gegebenenfalls, dass ein Systemtest einer höheren Risikostufe
ausgeführt wird.
Im ABAP-Umfeld ist in vielen Fällen die gelungene Integration der Datenbank ein Hindernis, wenn
es um die Erstellung von wiederholbaren, automatisierten Tests geht. Im Vorfeld des Tests müssen
die betroffenen Einträge auf der DB in die Form gebracht werden, die für die jeweilige Testausführung erwartet wird, und Änderungen an der DB durch die Testausführung müssen wieder beseitigt
werden, um andere Tests nicht zu behindern.
55
56
Management
BEST PRACTICE: Trennen Sie in Ihren Anwendungen die direkte Interaktion mit der DB und
entfernten Systemen, deren Laufzeitverhalten nicht kontrolliert werden kann, von dem eigentlichen
Anwendungskern. Wenn dieser Anwendungskern nicht mehr direkt mit der DB und den entfernten
Systeme kommuniziert, bieten die dafür benötigten Schnittstellen die Möglichkeit, für die
Durchführung von automatisierten Tests die Datenkonstellationen zu simulieren.
Werden z.B. alle DB-Zugriffe (SELECT, INSERT, UPDATE, DELETE) in einer DB-Schicht gekapselt,
bietet diese Kapselung den Ansatzpunkt, um bei der Testausführung mit simulierten Daten zu
arbeiten, die bei jeder Testausführung in einem konsistenten und bekannten Zustand sind.
WEITERE LINKS:
www.testbarkeit.de
http://de.wikipedia.org/wiki/Testbarkeit
http://www.testbarkeit.de/Publikationen/TAE05_Artikel_jungmayr.pdf
57
Die folgenden Autoren waren maßgeblich an der Erstellung der vorliegenden Fassung des
Leitfadens beteiligt:
Peter Lintner, Senior Consultant, Allgemeines Rechenzentrum GmbH
Herr Lintner ist zertifizierter Projektmanager (IPMA-Level C) und seit 1998 im Bereich SAP ABAP
Entwicklung tätig. Seine Schwerpunkte liegen in den Bereichen Applikations- und WorkFlow-Entwicklung, Change- und Requestmanagement.
Steffen Pietsch, Vice President, IBSolution GmbH
Herr Pietsch ist seit 2003 im entwicklungsnahen Umfeld tätig und konnte Erfahrungen als
Entwickler sowie in verschiedenen leitenden Positionen im Entwicklungsumfeld sammeln. Seit
2009 setzt er sich als Sprecher des DSAG-Arbeitskreises SAP NetWeaver Development für die
Interessen der Kunden und Partner in Zusammenarbeit mit der SAP ein.
Markus Theilen, IT-Koordinator, EWE AG
Herr Theilen ist seit 2001 als Entwickler, Software- und Unternehmensarchitekt tätig und konnte in
diesen Rollen tiefgreifende Erfahrungen in komplexen SAP-ERP-Implementierungen sammeln.
Seit 2012 steuert er als IT-Koordinator im EWE-Konzern die Entwicklungstätigkeiten ausgewählter
Anwendungen. Daneben arbeitet er als stellvertretender Sprecher des DSAG-Arbeitskreises SAP
NetWeaver Development in der DSAG e.V. mit.
Jürgen Wachter, Process Coordinator Development, comgroup GmbH
Herr Wachter arbeitet seit 2002 im Bereich SAP Entwicklung. Sein fachlicher Schwerpunkt liegt im
Bereich Core Development/Enhancements.
Michael Werner, SAP Anwendungsberater (Inhouse), LTS AG Andernach
Herr Werner sammelte von 1988 bis 1999 Erfahrungen im Bereich SAP R/2 mit den Schwerpunkten
SAP Basis, Logistik und Programmierung (ABAP und Assembler). Seit 1999 ist er als SAP R/3
Anwendungsberater für die Module MM, WM und PM tätig und führt ABAP-Entwicklung von ADD
ONs, Schnittstellen und Erweiterungen durch.
Andreas Wiegenstein, Managing Director und Chief Technology Officer (CTO), Virtual Forge GmbH
Herr Wiegenstein arbeitet seit 2002 im Bereich SAP Security. Er ist Co-Autor des Buches „Sichere
ABAP-Programmierung“ (SAP Press) und hält regelmäßig Vorträge zum Thema SAP/ABAP
Sicherheit und Compliance auf internationalen Konferenzen, wie z.B. RSA, Black-Hat, Hack In The
Box, Troopers, SAP TechEd und auf DSAG-Veranstaltungen.
Darüber hinaus haben folgende Personen durch die Bereitstellung von Unterlagen, Reviewtätigkeiten und zahlreiche Diskussionen maßgeblich zum aktuellen Stand beigetragen:
Michael Cendon, Thorsten Franz, Pascal Mannherz, Thomas Prang, Markus Tradt, Tobias Trapp,
Peter Weigel, Marc Zimmek
Besonderer Dank gilt der SAP, insb. Horst Keller und Dr. Wolfgang Weiss, die mit konstruktiven
Vorschlägen und Reviews die Arbeit an diesem Dokument unterstützt haben.
9Die Autoren
58
Im Folgenden finden Sie ein Beispiel, wie Namenskonventionen im Bereich der ABAP-Entwicklung
aufgebaut werden können. Dieses Beispiel kann als Anhaltspunkt für den Aufbau einer eigenen
Namenskonvention verwendet werden und ist dahingehend branchen- und unternehmensspezifisch anzupassen.
Allgemeiner Hinweis: Objekte im ABAP Dictionary haben unterschiedliche Begrenzungen in der
Anzahl zur Verfügung stehender Zeichen. Bei der Benennung der Objekte ist dies zu berücksichtigen.
Nachfolgend wird der Kundennamensraum Y… verwendet. Stattdessen kann, wie in Kapitel 2
beschrieben, alternativ der Namensraum Z… oder ein kundeneigener Namensraum /…/ verwendet
werden.
Abkürzungen
Abkürzungen
Bedeutung
Mm
Modul bzw. Projekt
Die Abkürzung mm repräsentiert ein SAP-Modul (z.B. PP MM) oder
ein kundenspezifisches Projekt.
Uu
Arbeitsgebiet
Ein Arbeitsgebiet erlaubt optional eine feinere Unterteilung eines
Moduls oder eines Projekts. Das Arbeitsgebiet wird vom Projektleiter definiert und kommuniziert.
K
Konstante
C
Alphanumerisches Zeichen
N
Numerisches Zeichen
…
Beliebige Länge
10.1Allgemeine Namenskonventionen
Strukturierende Elemente
Typ
Konvention
Beispiel
Entwicklungspakete
Ymmuu…
YPPRUECK
Reports
Ymmuu…
Ymmuu…
Modulpools
SAPMYuu
SAPMYCAUB
Includes
TYmmuuccc..._(A)*
MYCAUB_TOP
Transaktionen
Ymm..
YMM01
Nachrichtenklasse
Ymm..
YPPRUECK
WebDynpro ABAP
Ymm…**
YPKS_ADMIN_1
Anmerkungen:
*Das Include beginnt mit dem Namen des Modulpools ohne den Präfix „SAP“. Zum Schluss wird
die Art(A) des Includes angegeben:
>TOP
> PBO
> PAI
> FORMS
> CLASS
Top Include
Process Before Output Include
Process After Input Include
Include für Unterprogramme
Include für lokale Klassen
** Die Verwendung des WebDynpro Editors (z.B. in der se80) führt zur automatischen Erzeugung
von Quellcode. Dies macht die Umsetzbarkeit eigener Namenkonventionen im Einzelfall schwer.
Data-Dictionary-Objekte
Typ
Konvention
Beispiel
Tabellen
Ymmuu…(t)
YPPORDER
Views
Ymmuu…_V
YPPORDER_V
Tabellentypen
Ymmuu…_TT
YCADOCUMENT_TT
Struktur
Ymmuu…_S
YCADOCUMENT_S
Datenelement und
Ymmuu…
YCAFTDATUV
Domäne
Suchhilfe
Ymmuu….
YPPPROJE
Sperrobjekte
EY_<Tabelle>
EY_YSDMINFO
Typgruppen
Ymmcc
YCA02
Typ
Konvention
Beispiel
Klassen
YCL_mm_...
YCL_SD_FAKTURA
Interfaces
YIF_mm..
YIF_SD_BOOKING
Klassen & Interfaces
10.2Attribute
Lokale Variablen und Attribute einer Klasse sollten im Normalfall als private deklariert werden.
Der Zugriff auf die Attribute sollte über get- und set-Methoden erfolgen.
LV_...Attribut Variable (local value …)
LS_...Attribut Struktur (local structure …)
LT_... Attribut Tabelle (local table…)
59
60
10.3Methoden
Methoden sollten einen kurzen, sprechenden, englischen Namen besitzen. Folgende Präfixe
deuten auf die Aufgabe der Methode:
set_...Setzen von Werten
get_...
send_... Senden von Informationen
save_...Sichern der Daten auf die Datenbank
Laden von Werten
etc.
Die genaue Funktion sollte in der Beschreibung der Methode stehen. Reicht der Platz (60 Zeichen)
nicht aus, so sollte die ausführliche Dokumentation der Methode in der Klassendokumentation
erfolgen.
10.4Signatur von Methoden
Die Parameter einer Methode werden wie folgt bezeichnet.
Nr.
Parameterart
Präfix
0
Importing
I_...
1
Exporting
E_...
2
Changing
C_...
3
Returning
R_...
10.5 Funktionsgruppen und -bausteine
Typ
Konvention
Beispiel
Funktionsgruppen
Ymm_ccc_…
YCA_KONFIGURATION
Funktionsbausteine
Ymm_...
YSD_FAKTURA_ZU_WE
Die Schnittstellen von Funktionsbausteinen orientieren sich an denen der objektorientierten
Programmierung (vgl. 10.4).
BEST PRACTICE: Tabellen können auch als Import, Export oder Changing Parameter übergeben
werden, sodass stets Klarheit herrscht, welche Tabellen im Funktionsbaustein geändert werden
und welche nicht. Des Weiteren stellt der Syntax-Check im ABAP sicher, dass Importparameter
nicht verändert werden dürfen.
10.6Enhancements
Typ
Konvention
Beispiel
Enhancement
YES_...
YES_MV45A
YED_...
YED_ MV45A
YEI_...
YEI_ MV45A
Spot
Enhancement
Definition
Enhancement
Implementation
10.7Formulare
Typ
Konvention
Beispiel
Adobe Forms – Formular
Ymm..
YPP_VBK1
Adobe Forms – Schnittstelle
Ymm.._IF
YPP_VKB_IF
Smart Forms / SapScript – Formular
Ymm..
YPP_VBK1
Smart Forms / SapScript – Stil
Ymm..
YPP_VBK1
Smart Forms / SapScript – Textbaustein
Ymm..
YPP_VBK1
Suchhilfe
Ymmuu….
YPPPROJE
Sperrobjekte
EY_<Tabelle>
EY_YSDMINFO
Typgruppen
Ymmcc
YCA02
10.8Jobs
Typ
Konvention
Beispiel
Jobs
YMM_<Prio>_<BUKRS>_<DESC>
YSD_1_1000_
<Prio> = Priorität, einstellige Zahl, <BUKRS> = Buchungskreis
61
62
10.9Datenelemente
Datentyp
Präfixbestandteil
Elementare Typen / Variablen
v
Strukturen
s
Tabellen
t
Datenreferenz
r
Klassenreferenz
o
Interfacereferenz
i
BADI-Referenz
b
Ausnahmeklasse-Referenz
x
Diese Präfixbestandteile bilden die typenabhängigen Anteile der im Folgenden aufgeführten,
kontextabhängigen Präfixe. [t] ist hierbei jeweils durch den passenden typenabhängigen Präfixbestandteil zu ersetzen.
Art der Deklaration
Namenskonvention
Lokale Variable
l[t]_*
Globale Variable
g[t]_*
Statische Variable
s[t]_*
Lokales Feldsymbol
<l[t]_*>
Globales Feldsymbol
<g[t]_*>
Lokale Konstante
lc[t]_*
Globale Konstante
gc[t]_*
Select-Option
s_*
Parameter
p_
Funktionsbausteinparameter
i[t]_* für Importing
e[t]_* für Exporting
s[t]_*
c[t]_* für Changing
<l[t]_*>
t[t]_* für Tables
<g[t]_*>
FORM Parameter
p[t]_* für Using
l[t]_*
t[t]_* für Tables
g[t]_*
Tabellentyp
tt_*
Strukturtyp
t_*
Objektorientierte Programmierung:
Entität
Namenskonvention
Lokale Klasse
lcl_*
Globale Klasse
cl_*
Lokales Interface
lif_*
Globales Interface
if_*
Instanzattribut
m[t]_*
Statisches Attribut
g[t]_*
Konstanten
c[t]_*
Methodenparameter
e[t]_* für Exporting
p_
r[t]_* für Returning
s[t]_*
Ereignisparameter
i[t]_*
63
© DSAG e. V.

Best Practice Leitfaden Development

Transcription

Similar documents

Cockpit zur Änderung der Bewertungsklasse im SAP ERP

C R M

sap, emc und vmware – wertsteigerung für den kunden durch

Präsentation Analysis for Office

SAP Productivity Pak by RWD Adapter for SAP Solution

SAP - CENIT AG

realisierten Projekten

Software-Entwickler gesucht?

Kurze AbschlÃ¤ge bewirken Gutes: ChariTEE

Storage simplified

SAP Mehrwertdienste bei der Akquisition und Abwicklung von

qualitätsmanagement mit sap® erp

Leitfaden Parkraumbewirtschaftung

Leitfaden fÃ¼r die Gestaltung wissenschaftlicher Arbeiten

des Leitfadens als PDF

gewalt gegen Kinder und jugendliche

08/2013 - KaffeeKlatsch

GMP-Engineering Leitfaden zur Durchführung von

MANUAL DIPLOMARBEIT Leitfaden für die Erstellung der Disposition für die Diplomarbeit

MANUAL DIPLOMARBEIT Leitfäden für die Erstellung der 1 Disposition

SAP R/3 Icons - SAP User Experience Community

Katastrophenmedizin - Bundesamt für Bevölkerungsschutz und