dsag - best practice leitfaden development

8/10/2019 DSAG - Best Practice Leitfaden Development

http://slidepdf.com/reader/full/dsag-best-practice-leitfaden-development 1/64

DSAG-ARBEITSKREIS SAP NETWEAVER DEVELOPMENTSTAND 31. JANUAR 2013

Deutschsprachige SAP-Anwendergruppe e.V.

Best Practice Leitfaden DevelopmentPraxistipps rund um das Thema ABAP Development



4

1 EINLEITUNG 7

1.1 Motivation 7

1.2 Positionierung 7

2 PROGRAMMIERRICHTLINIEN 8

2.1 Namenskonvention 8

2.2 Namensraum 8

2.3 Einheitlicher und lesbarer Quellcode: Pretty Printer 9

2.4 Obsolete Anweisungen 12

2.5 Syntax-Check und Code Inspector 12

2.6 Feste Codierung: Keine „magic numbers“ 13

2.7 Tipps beim Arbeiten mit Transporten 13 2.8 Berechtigungsprüfung im Quellcode 14

2.9 Programmiermodell: objektorientiert vs. prozedural 14

2.10 Weitere Quellen (Programmierrichtlinien/ABAP) 14

3 PERFORMANCE 15

3.1 Vermeidungsprinzip 15

3.2 Vorhandene Werkzeuge nutzen 15

3.3 Performance-Optimierungen nur an kritischen und relevanten Stellen 16

3.4 Datenmodell und Datenzugriff 16 3.4.1 Datenmodell und Indizes 16

3.4.2 Rahmenbedingungen bei Datenbankzugriffen 17

3.4.3 Datenbankzugriffe 18

3.5 Interne Tabellen und Referenzen 19

3.5.1 Feldsymbole 21

3.5.2 Parameterübergabe 21

3.6 Weiterführende Quellen 21

4 ROBUSTHEIT 22

4.1 Fehlerbehandlung 22

4.1.1 SY(ST)-SUBRC-Prüfungen 22

4.1.2 MESSAGE-Anweisung 23

4.1.3 Klassenbasierte Ausnahmen 23

4.1.4 Nicht behandelbare Ausnahmen 24

4.2 Korrekte Implementierung von Datenbank-Änderungen 24

4.2.1 Sperrobjekte 24

4.2.2 Verbuchungskonzept 24

4.3 Protokollierung 26

4.4 Praxisbeispiele 26

INHALTSVERZEICHNIS



5

4.4.1 Unvollständige Fallunterscheidungen 26

4.4.2 Wichtige sonstige SY(ST)-SUBRC-Prüfungen 27


5 ABAP-SICHERHEIT UND COMPLIANCE 28

5.1 Prüfungsrelevante Sicherheitsmechanismen im SAP-Standard 28

5.1.1 Berechtigungsprüfung (A) 28

5.1.2 Mandantentrennung (B) 28

5.1.3 Nachvollziehbarkeit (C) 29

5.1.4 Dreisystemlandschaft (D) 29

5.1.5 Kontrollierte Ausführung von Betriebssystemkommandos (E) 29

5.1.6 Kontrollierte Ausführung von SQL-Befehlen (F) 29

5.2 Sicherheitsschwachstellen 30

5.3 Compliance-Probleme durch ABAP 31

5.4 Testwerkzeuge 32


6 DOKUMENTATION 34

6.1 Dokumentation unabhängig von Entwicklungsobjekten 34

6.2 Dokumentation von Entwicklungsobjekten 35

6.3 Dokumentation im Quelltext 35 6.3.1 Dokumentation und Kommentierung von Anweisungen/Anweisungsblöcken 35

6.3.2 Dokumentation von Änderungen 36

6.3.3 Programmkopf 36

7 UMSETZBARKEIT UND DURCHSETZBARKEIT 38

7.1 Umsetzbarkeit 38

7.1.1 Motivation für einen Prozess 38

7.1.2 Erstellung und Pflege des Prozesses 39

7.2 Durchsetzbarkeit 40

7.2.1 Manuelle Prüfungen 40

7.2.2 Automatische Prüfungen 41

7.2.3 Werkzeuge 42

7.3 Erfahrungen und Tipps aus der Praxis 42

7.3.1 Qualitätssicherung des Quellcodes 42

7.3.2 Zeit und Budget QA 43

7.3.3 Probleme 43

7.3.4 Entscheidungsfindung bei Modifikationen 44

7.3.5 Erfahrungsbericht aus der Praxis: Comgroup GmbH 44

B E S T P R A C T I C E L E I T F A D E N D E V E L O P M E N T , 3 1 . J A N U A R

2 0 1 3 , © D

S A G e . V .



6

INHALTSVERZEICHNIS

8 INFRASTRUKTUR UND LIFECYCLE MANAGEMENT 46

8.1 Infrastruktur 46

8.1.1 Sandbox 46

8.1.2 Entwicklungssystem 46

8.1.3 Qualitätssicherungssystem 46

8.1.4 Produktion 47

8.1.5 Transportwesen 47

8.1.6 Rückbau von Neuentwicklungen 48

8.1.7 Sicherstellung der Konsistenz von Neuentwicklungen/Erweiterungen 48

8.2 Change Management 49

8.3 Softwarewartbarkeit 52

8.4 Anpassungen der SAP-Funktionalität 52

8.5 Testbarkeit von Anwendungen 55

9 DIE AUTOREN 57

10 ANHANG: NAMENSKONVENTIONEN 58

10.1 Allgemeine Namenskonventionen 58

10.2 Attribute 59

10.3 Methoden 60

10.4 Signatur von Methoden 60 10.5 Funktionsgruppen und -bausteine 60

10.6 Enhancements 61

10.7 Formulare 61

10.8 Jobs 61

10.9 Datenelemente 62



7

1 EINLEITUNG

SAP-Software zeichnet sich als Standardsoftware durch ein hohes Maß an Flexibilität und Erweiter-barkeit aus. In nahezu allen Unternehmen, die SAP-Software einsetzen, finden sich kundenspezi-fische Anpassungen und Ergänzungen. Die SAP-Software unterliegt damit sowohl auf Hersteller-

als auch auf Kundenseite der kontinuierlichen Anpassung und Erweiterung an sich wandelndeKundenbedürfnisse. Das hohe Maß an Flexibilität und Erweiterbarkeit von SAP-Software bringt Vor- und Nachteile mitsich: Die Software kann optimal an kundenspezifische Anforderungen angepasst und damit die Wert-schöpfung durch den Einsatz deutlich gesteigert werden. Zeitgleich birgt die Erweiterbarkeit dasRisiko kundenspezifischer Entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind.

Das Ziel dieses Dokuments ist es, Praxistipps und Denkanstöße zu liefern, um kundenspezifischeEntwicklungen wartbar und effizient zu gestalten.

1.1 MOTIVATION

Die Arbeit der Deutschsprachigen SAP-Anwendergruppe e.V. (DSAG) fußt auf drei Säulen – Wissens-vorsprung, Einflussnahme und Netzwerk. Das vorliegende Dokument wurde von Mitgliedern desDSAG-Arbeitskreises SAP NetWeaver Development initiiert und adressiert die erste Säule und damitden Wissensvorsprung für Anwender und Partner.

Als Autorenteam ist es unser Anliegen, das in den Unternehmen verteilt und implizit vorliegendeWissen zum Thema Entwicklung in einem kompakten Dokument anderen DSAG-Mitgliedern zurVerfügung zu stellen. Unser Wunsch ist, dass dieses Dokument „lebt“ und mit Ihrem Erfahrungs-schatz einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf Ihr Feedback (am bestenper E-Mail an [email protected])!

1.2 POSITIONIERUNG

Es existieren bereits von der SAP und einer ganzen Reihe von Fachverlagen sehr gute Publikati-onen zu Anwendungsentwicklung und Erweiterung der SAP-Plattform. Insbesondere haben auchAutoren der SAP mit dem Buch „ABAP-Programmierrichtlinien“, SAP Press 2009 bereits einenVorstoß in Richtung von Empfehlungen unternommen, die über reine Beschreibungen der SpracheABAP 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 Ihnenals Anwender, Entwickler, Entwicklungs-, Projekt- oder IT-Leiter Anregungen und Hilfestellunggeben, um „das Rad nicht immer wieder neu erfinden zu müssen“, sondern auf die Erfahrungenanderer aufbauen zu können. Dabei erheben die in dieser Guideline vorgestellten Empfehlungennicht den Anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eineAuswahl von Praxistipps dar.

Als Autorenteam haben wir uns darum bemüht, im Spannungsfeld zwischen Überblickswissen und

Detailtiefe den richtigen Mix zu finden. Daher verweisen wir an entsprechenden Stellen auf weiter-führende Quellen, um nicht ausführlich diskutierte Themen redundant wiederzugeben. Die erste Auf-lage dieser Guideline ist auf den Bereich ABAP-Entwicklung fokussiert. Bei entsprechendemFeedback und Ihrer aktiven Unterstützung kann der Fokus auf die JAVA-Entwicklung und weitereThemen ausgeweitet werden.


2 0 1 3 , © D

S A G e . V .

mailto:handlungsempfehlung%40dsag.de?subject=

mailto:handlungsempfehlung%40dsag.de?subject=



8

Dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für Anwendungen, diemit Hilfe der Programmiersprache ABAP erstellt werden. Es wird beschrieben, wie mit Standard-SAP-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 externePersonen effizient an der (Weiter-) Entwicklung und Wartung eines Programms zusammenarbeiten.

2.1 NAMENSKONVENTION

Namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung vonSoftwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur Benennung von Objekten imQuellcode (z.B. Variablen).

Wir empfehlen ausdrücklich eine Namenskonvention als Richtlinie für Entwicklungen im SAP-System vorzugeben. Das Ziel der Verwendung einer einheitlichen Namenskonvention ist die

deutliche Steigerung der Wartbarkeit kundenspezifischer Anpassungen und Erweiterungen. In derKonsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnellerenProblemlösung im Fehlerfall.

Die explizit formulierte Namenskonvention sollte Bestandteil der internen Ausbildung sein, umneue Mitarbeiter mit den Grundregeln und Unternehmensspezifika vertraut zu machen. Zudem hates sich bewährt, diese Namenskonvention zum Vertragsgegenstand für externe Entwickler undPartnerunternehmen zu machen. Automatisierte Überprüfungen stellen die Einhaltung sicher (vgl.Kapitel 7).

BEST PRACTICE: Eine exemplarische Namenskonvention als Vorlage finden Sie im Anhang.

2.2 NAMENSRAUM

Die Trennung von Kundenobjekten und SAP-Objekten kann über die Präfixe Y oder Z sowie übereinen eigenen Namensraum erfolgen. Die Syntax lautet wie folgt:

Z…Y…/<kundeneigener Namensraum>/…

Der kundeneigene Namensraum kann bei SAP registriert werden und ist nach Bestätigungweltweit eindeutig und für das jeweilige Unternehmen zur Verwendung registriert. Dieses Vorgehenunterstützt bei der konfliktfreien Vergabe von Namen für Softwareobjekte. Der Vorteil des kundeneigenen Namensraums liegt in der garantierten Überschneidungsfreiheitbeim Import fremder Objekte in das eigene SAP-System (z.B. beim Einsatz von Fremdanwen-dungen, die per Transportauftrag eingespielt werden) und bei Zusammenführungen von SAPSystemen im Rahmen einer Post-Merger Integration. Durch die Reservierung des Namensraumsist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten System ein Softwareobjekt mitdem gleichen Präfix erstellt werden kann.

Der Nachteil bei der Verwendung des kundeneigenen Namensraums liegt darin, dass durch diedurchgängige Verwendung des Präfixes bereits mehrere Zeichen „verbraucht“ werden. Dies kanninsbesondere bei Objekten, die nur wenige Zeichen zur Benennung bieten, zu Schwierigkeitenführen. Darüber hinaus unterstützen nicht alle Objekttypen, z.B. Berechtigungsobjekte, dieVerwendung von Namensräumen.

2 PROGRAMMIERRICHTLINIEN



9

BEST PRACTICE: Wir empfehlen ausdrücklich die Verwendung eines kundeneigenen Namens-raums.

WEITERE QUELLEN:

1. http://help.sap.com (Namensraum einrichten)2. Best-Built Applications: http://scn.sap.com/community/best-built-applications

2.3 EINHEITLICHER UND LESBARER QUELLCODE: PRETTY PRINTER

Übersichtlicher, leserlicher Code erleichtert jedem Entwickler die (erneute) Einarbeitung inQuellcode. Als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zuhalten, kann der Pretty Printer aus der ABAP-Entwicklungsumgebung genutzt werden. Mit einemeinzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. Er bietet verschiedeneMöglichkeiten, die über die Einstellungen der Workbench konfigurierbar sind. Bereits eine

eingerückte Darstellung macht Source Code deutlich lesbarer. Es wird empfohlen, Schlüsselwörtergroß darzustellen. Denn dadurch kann man Quelltext auch in ausgedruckter Form und ohneSyntaxeinfärbung noch leicht verstehen. Der Pretty Printer ermöglicht auf einfachem Weg dieErstellung von einheitlichem Quellcode trotz unterschiedlicher Entwickler.

Um die Lesbarkeit des Quelltextes zu erhöhen, empfehlen wir, auf mehrere Anweisungen in einerCodezeile zu verzichten.

Wir empfehlen, die Option „Standardkommentare einfügen“ zu deaktivieren, da die erzeugtenKommentare bei Änderungen nicht automatisch angepasst werden und redundante Informationen

enthalten.

BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die Einstellungen alseinheitliche Vorgabe zu definieren.

ModularisierungProgramme, in denen logische Verarbeitungseinheiten nicht aufgeteilt werden, sind in weitererFolge schwer lesbar und damit schwer wart- und erweiterbar.

Eine Modularisierungseinheit (Form-Routine, Methode, Funktionsbaustein) soll logisch zusam-mengehörende Anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen

Einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigenAnweisungen 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 erstenCodezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend auszupro-grammieren.

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

orientierte Programmierung überzugehen, um zukunftssicher zu entwickeln und Objekte zukapseln. Insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden.

Im Rahmen der Einführung von ABAP Objects fand eine Bereinigung der Sprache und Vereinheitli-chung der Konstrukte statt. Die Verwendung von ABAP Objects führt damit zu einer Steigerung derWartbarkeit.


2 0 1 3 , © D

S A G e . V .



10

Trennung von Präsentations- und AnwendungslogikIn allen Programmen sollte stets eine Trennung von Präsentations- und Anwendungslogikerfolgen. Dies erlaubt es, Ergebnisse und Funktionen der Anwendungslogik durch verschiedeneUIs (User Interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche Schnittstelle anderenSystemen bereitzustellen. Diese Aussage ist für alle gängigen UI-Technologien gültig, wobei derGrad der Unterstützung bzw. Einhaltung dieser logischen Trennung unterschiedlich ist. In einerWebDynpro ABAP-Realisierung ist schon vom Framework eine Trennung zwischen Modell- undUI-Logik vorgesehen. Bei klassischen Dynpros und BSPs wird die Trennung nicht in gleicher Weiseforciert, aber grundsätzlich kann und sollte die Trennung auch in diesen Umgebungen umgesetztwerden. Allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu WebDynpro, woentsprechende Prüfungen im Code Inspector realisiert sind.

Ein typisches Beispiel für eine klare Trennung von Anwendungslogik und UI sind Plausibilisie-rungsregeln. 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 neuentwickelt werden. Um dies zu vermeiden, müssen die Funktionen zur Prüfung von Eingaben oderParametern unabhängig von der verwendeten UI erstellt und gepflegt werden.

InternationalisierungSprachabhängige Texte in Programmen dürfen nicht „hart codiert“ werden, sondern müssen inTextelementen (Programmtexte, Klassentexte, Online-Text-Repository [OTR]), Standardtexten oderNachrichtenklassen 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 derTexttabelle gekennzeichnet werden.

BEST PRACTICE: Wir empfehlen, den Code Inspector für die Suche nach nicht übersetzbarenTexten zu verwenden.

BEST PRACTICE: Um spätere Übersetzungen einfach zu gestalten, sollte die Länge der Feldbe-zeichner 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 ProgrammierungIn der „klassischen“, statischen Entwicklung werden Entwicklungsobjekte und der Quellcode zurDesignzeit definiert und im SAP-System statisch hinterlegt. Zur Laufzeit wird der vorgegebeneProgrammcode ausgeführt. Im Gegensatz dazu ermöglicht die dynamische Programmierung dieFlexibilisierung 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 signifikantsteigenden Komplexität und insbesondere in den damit einhergehenden Sicherheitsrisiken.




11

Vorteil:

> Deutliche Steigerung der Flexibilität

> Beispiel 1: Eigener Aufbau von User Exits

Durch die statische Definition einer abstrakten Klasse inkl. Methodensignatur wird das Grund-gerüst für einen „User Exit“ vorgegeben. Anschließend können mehrere konkrete Impleme-tierungen dieser abstrakten Klasse angelegt werden. Innerhalb Quellcodes wird z.B. aus einerCustomizing-Tabelle der Name der zu verwendenden konkreten Klassenimplementierunggelesen und diese aufgerufen. Somit können unterschiedliche Implementierungsvariantenper Customizing aktiviert/deaktiviert werden.

> Beispiel 2: Dynamische WHERE-Bedingung

Zur Laufzeit wird die WHERE-Bedingung für eine Datenbankoperation, z.B. SELECT, in einerString-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. EinEntwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der voneinem 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 einerdynamischen WHERE-Klausel, fehlerhafter Name einer Klasse) kommt es zu einem ungeplantenAbbruch des Programms (Kurzdump).

> Dynamische Programmierung birgt hohe Sicherheitsrisiken, insbesondere dann, wenn die dynamischenInhalte durch ungeschützten Zugriff beeinflussbar sind (z.B. wenn der Name einer aufzurufendenKlasse /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 Einsatzkommen. Programmcode, der dynamische Anteile enthält, sollte nach dem Vier-Augen-Prinzipkontrolliert und dokumentiert werden, denn er stellt ein potenzielles Sicherheitsrisiko dar.

Im Kapitel 5.2 wird das Thema dynamische Programmierung auch im Kontext Sicherheit behandelt.


2 0 1 3 , © D

S A G e . V .



12

Auditierbarkeit von ABAP CodeEs muss jederzeit möglich sein, durch manuelle Untersuchungen oder statische Codeanalyse-Tools den selbst geschriebenen ABAP Code auf Mängel zu untersuchen. Alle Methoden, ABAP-Coding unsichtbar zu machen, sind daher unzulässig, da sie solche Untersuchungen behindernoder 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 andieser Stelle explizit darauf verzichtet, die Techniken zu erläutern, mit denen Code verstecktwerden kann.

BEST PRACTICE: Verwenden Sie insbesondere in der Entwicklung im eigenen Unternehmen keineTechniken, um Ihren Quellcode zu verstecken.

2.4 OBSOLETE ANWEISUNGEN

Obwohl SAP eine strikte Abwärtskompatibilität vertritt, muss bei der Verwendung von obsoletenAnweisungen, wie z.B. Kopfzeilen in internen Tabellen, berücksichtigt werden, dass hierbeiProbleme 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 eigentlichauß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 CodeInspector bzw. die Durchführung des Syntax-Checks.

Darüber hinaus existieren sehr gute Analysewerkzeuge von Drittanbietern.

2.5 SYNTAX-CHECK UND CODE INSPECTOR

Der Syntax-Check und der Code Inspector ermöglichen die Überprüfung des Programmcodeswährend der Designzeit. Bei der Freigabe von Transporten kann der Code Inspector über die SE03 global angeschaltetwerden, um Fehler zu erkennen. Hierdurch kann auch die Anzahl der Transporte verringertwerden, da beim Erkennen von Fehlern die Freigabe noch abgebrochen werden kann. DieBehebung kann dann in den bestehenden Auftrag aufgenommen werden und es muss kein neuerTransport erzeugt werden.

BEST PRACTICE: Der Code Inspector wird im SAP-Standard nur bei Freigabe des Transportauf-trags ausgeführt. Empfehlenswert ist jedenfalls die Prüfung durch den Code Inspector bereits beider Freigabe der jeweiligen Transportaufgabe.

WEITERE QUELLEN:

Die Vorgehensweise der Implementierung des dafür notwendigen BAdIs ist im Buch „Praxishand-buch SAP Code Inspector“ (SAP Press) beschrieben.




13

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 alsschnelle Vorgehensweise erscheinen. Auf den Gesamtlebenszyklus der Anwendung bezogen, führtsie jedoch zu deutlich erhöhten Kosten. Die Wartbarkeit und Testbarkeit der Anwendung werdenlangfristig deutlich erschwert.

BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler Stelle definiertwerden. 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 Customi-

zing-Tabellen verwendet werden. In diesen Tabellen werden die Werte, z.B. Zahlen, Organisations-einheiten 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 Analyseim Fehlerfall bzw. bei regulären Wartungstätigkeiten. Wir empfehlen ausdrücklich die Kommentie-rung 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, dieseentweder 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 gesuchtwerden kann.

2.7 TIPPS BEIM ARBEITEN MIT TRANSPORTEN

Wenn mehrere Entwickler an einem Entwicklungsobjekt Änderungen vornehmen, kann dies unterUmständen zu Problemen führen, wenn die Transportaufträge nicht in der richtigen Reihenfolge indie produktiven Systeme transportiert werden oder andere Objekte aus anderen Transportaufträgenfehlen.

BEST PRACTICE: Um dies zu vermeiden, sollte mit Transport von Kopien gearbeitet werden. Dabeiwerden die geänderten Entwicklungsobjekte durch den eigentlichen Transportauftrag imEntwicklungssystem gesperrt und über Transport von Kopien werden nur Kopien der Objekte indas Qualitätssicherungssystem transportiert. Ein Entwickler bemerkt sofort, dass ein andererEntwickler ggf. das Objekt bereits bearbeitet, und kann sich mit dem anderen Entwicklerabstimmen. Nach Abschluss des „Projektes“ wird nur der Original-Sperrtransport ins Produktiv-system transportiert.


2 0 1 3 , © D

S A G e . V .



14

2.8 BERECHTIGUNGSPRÜFUNG IM QUELLCODE

Bei Zugriff auf Daten und auch deren Präsentation sind die dafür notwendigen Berechtigungsob-

jekte zu prüfen. Bei der Verwendung von Standardobjekten soll jedenfalls die Prüfung auf dieentsprechenden SAP-Standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung dernotwendigen Rollen). Für kundeneigene Datenobjekte können in der Regel keine SAP-Standard-Berechtigungsobjekte zur Prüfung verwendet werden. Zu diesem Zweck können kundeneigeneBerechtigungsobjekte 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 Anweisungeneingestuft. Prozedurale Entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globaleVariablen und Includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen.

Objektorientierte Entwicklung wurde so konzipiert, dass logisch zusammenhängende Aufgabeneinheitlich in Objekten zusammengefasst werden können. Dadurch wird unter anderem auch dieWiederverwendbarkeit von Code erhöht. Insbesondere können solche Objekte auch von anderenEntwicklern für ihre Zwecke leicht erweitert oder verändert werden, ohne dass die grundlegendenFunktionen beeinträchtigt werden (Open-Close-Prinzip). Andererseits können zentrale Funktionali-täten oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder Schreibzugriff durchaufrufende Programme geschützt werden.

BEST PRACTICE: Wir empfehlen bei Neuentwicklungen möglichst nur noch mit Klassen undMethoden 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 ABAPDeveloper Should Give It a Second Look, Sap Professional Journal

2. Horst Keller and Gerd Kluger, NetWeaver Development Tools ABAP, SAP AG3. 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 731http://help.sap.com/abapdocu_731/de/index.htm In dieser Dokumentation ist dem Thema Programmierrichtlinien ein eigenes Kapitel gewidmet.


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

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

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

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



15

In den folgenden Abschnitten empfehlen wir einige Regeln, die bei der täglichen Arbeit in derABAP-Entwicklung beachtet werden sollten, um von vorneherein Performance-Engpässe zuvermeiden. Wie an viele anderen Stellen der Softwareentwicklung hilft es auch im Hinblick auf eineausreichende Performance zu wissen, was gemacht werden soll. Solange der Sinn und Zweckeines Code-Stückes nicht klar ist, sollte dies zuerst geklärt werden.

3.1 VERMEIDUNGSPRINZIP

„Die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und amleichtesten zu dokumentierenden Teile eines Computersystems sind die, die man weggelassenhat.“ (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 Produktiongedacht 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 mehrzu tun, als für die Aufgabe wirklich benötigt wird. Ein einleuchtendes Beispiel dafür ist die Regelzur Vermeidung von *-SELECTs, bei denen der Einfachheit halber alle Spalten einer Tabelleselektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige Spalten benötigtwerden.

Anmerkung: Diese Vorgehensweise steigert gleichzeitig die Robustheit von Programmen.

Das Lesen mit Hilfe von *-SELECT in eine kundeneigene Datenstruktur kann zu Fehlern nacheinem Upgrade führen,wenn die Standardtabelle durch SAP erweitert wurde. Das explizite Lesenbenö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 Erstellungvon performanten Anwendungen bzw. bei der Analyse von Performance-Engpässen. DieseWerkzeuge 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

3 PERFORMANCE


2 0 1 3 , © D

S A G e . V .



16

Laufzeit Beschreibung

SM50/SM66 Übersicht Workprozesse/Applikationsserver

Debugger Schrittweises Ausführen von Coding

Memory Inspector Vergleich und Analyse von Speicherabzügen zurErmittlung von nicht Speicherverbrauch und nicht

freigegebenen Heap-Objekten

ST10 Tabellenaufruf-Statistiken zur Prüfung vonTabellenpufferung

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 undkonzentrieren Sie sich auf den größeren Zeittreiber. Wenn die meiste Zeit im ABAP-Teil verbrauchtwird, analysieren Sie weiter mit der SE30/SAT. Liegt die meiste Zeit bei den DB-Aufrufen, startenSie einen SQL-Trace mit der ST05.

3.3 PERFORMANCE-OPTIMIERUNGEN NUR AN KRITISCHEN UNDRELEVANTEN STELLEN

Auch wenn man nicht performante Konstrukte bei der Softwareentwicklung immer vermeidensollte, sollte man sich gleichzeitig bei der Notwendigkeit von umfangreicheren Performance-Opti-mierungen auf die Teile der Software beschränken, die durch Messung nachgewiesenermaßen dieUrsache von langer Laufzeit oder erhöhtem Speicherverbrauch sind. Auch für Performance-As-pekte trifft die 80/20-Regel zu und es gilt daher, die meistens raren Ressourcen für eine umfang-reiche Verbesserung auf die 20 % des Systems zu konzentrieren, die für 80 % der Laufzeit/desSpeicherverbrauchs 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 derLaufzeitanalyse SE30/SAT mit voller Aggregation zu beginnen. Dadurch sollte deutlich werden, obdie Laufzeit aus der Interaktion mit der Datenbank oder der Verarbeitung der geladenen Daten imHauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher Datenbestandverarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen Spur zu folgen. Wirdmehr als die Hälfte der Laufzeit im DB-Teil verbraucht, sollte eine genauere Analyse der SQL-Kommandos mit der Transaktion ST05 erfolgen. Wird mehr Laufzeit im ABAP-Teil verbraucht,erfolgen tiefergehende Analysen mit Hilfe der SE30/SAT, wobei die Aggregationsstufen schrittweise

verringert werden, um genauere Aussagen über die kritischen Programmstellen zu bekommen.Nach jedem Optimierungsschritt sollten die Ergebnisse verglichen und dokumentiert werden.

3 PERFORMANCE



17

3.4 DATENMODELL UND DATENZUGRIFF

3.4.1 Datenmodell und Indizes

Der Aufbau des Datenmodells bildet die Basis performanter Anwendungen. Ein mit Augenmaßnormalisiertes Datenmodell kann effizienter mit Daten und Indizes arbeiten. Hierzu finden – unab-hä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 Tabellenzugegriffen wird. Mit jedem Index steigen die Verwaltungskosten, die bei Datenänderungenanfallen.

> Fünf Felder pro Index sollten als Obergrenze eingehalten werden.

> In einem Index sollten nur selektive Felder aufgenommen und in der Reihenfolge nachabsteigender 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 selektivist und damit der dritten Regel widerspricht, wird bei jeder Abfrage dieses Feld in der Selektion

vom SAP-System mit übergeben und ausgewertet. Gerade bei Tabellen mit stark unterschiedlichen

Eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im Index negativ auswirken.

3.4.2 Rahmenbedingungen bei Datenbankzugriffen

Folgende Fragen sollten bei DB-Zugriffen gestellt und beantwortet werden:

> Sind Indizes in geeigneten Rahmen angelegt? > s. vorheriges Kapitel (3.4.1)

> Lesen Anweisungen am Tabellenpuffer vorbei?

Hierbei kann die Transaktion ST10 verwendet werden, um die Zugriffshäufigkeiten auf gepuffer-ten Tabellen zu überprüfen. Mit der Transaktion ST05 können mit dem kombinierten SQL- undPuffer-Trace Zugriffe ermittelt werden, die wider Erwarten den Tabellenpuffer nicht verwenden.Und mit Hilfe des Code Inspectors lassen sich viele dieser Statements bereits im Vorfeldstatisch 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 Sortierungnach 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 eineneigenen Index anzulegen. In diesem Fall sollte die Sortierung im ABAP erfolgen, sofern dies diezu sortierende Datenmenge zulässt.


2 0 1 3 , © D

S A G e . V .



18

Beispiel: Die Tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nachdiesem 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 undgleichzeitig der Zusatz ORDER BY Belegdatum vom vorhandenen Index profitiert.

3.4.3 Datenbankzugriffe

Die auf der Datenbank selektierte und an die Anwendungsschicht zu übergebende Datenmengesollte grundsätzlich so gering wie möglich gehalten werden. Nachfolgend finden Sie Hinweise, wieSie dies im konkreten Fall umsetzen können.

BEST PRACTICE:

> Spaltenreduzierung:

Vermeiden Sie *-Selektionen und benennen Sie stattdessen die benötigen Spaltennamen in derSelektion. Insbesondere das unnötige Laden von Spalten des Typs String ist teuer.Die Ergebnistabelle sollte mit der Selektionsstruktur übereinstimmen, um optimale Ergebnisse zuerzielen. Sollten in der Ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschtenFelder namensgleich angelegt sein, ist auch der Zusatz CORRESPONDING FIELDS möglich undführt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die Robustheit der Software erhöht.

> Optimale SuchabfrageVersuchen Sie für die Selektion von Daten möglichst nur Abfragen zu verwenden, die einen dervorhandenen 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 einemöglichst kleine Menge von Datensätzen reduziert werden kann.

> ZeilenreduzierungNutzen Sie die WHERE-Bedingungen, indem Sie die Selektion beschreiben und die an dasABAP-System zu übermittelnden Daten minimieren.Verwenden Sie SELECT SINGLE / UP TO n ROWS, wenn Sie nur einzelne Zeilen benötigen.

> ExistenzchecksDie 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. Diesvermeidet unnötige Zugriffe auf die Tabellendaten.

> AggregateAggregate (MIN, MAX, …) werden immer auf dem Datenbankserver ausgewertet. Dadurch wird dieTabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem DB-Sys-tem, das in vielen Installationen von sehr vielen Applikationsservern angesprochen wird, solltenEntwickler prüfen, welche Datenmenge für das Aggregat verwendet werden muss und ob es sichlohnen kann (sofern diese nicht groß ist), die Daten in eine interne Tabelle zu laden und dasAggregat dort durchzuführen. Allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem

Kenntnisstand insbesondere HANA-basierte Datenbankabfragen gerade bei Aggregaten ihreStä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 zuermitteln, ist es sinnvoll, dieses Aggregat auf dem DB-System ermitteln zu lassen, um nur einenoder wenige Werte statt hunderttausender an die Applikationsserver übermitteln zu lassen, um

3 PERFORMANCE



19

dort den Durchschnittswert im ABAP zu berechnen. Dies gilt insbesondere, wenn diese Auswer-tung nur selten (z.B. einmal pro Tag) erfolgt. Soll hingegen die Summe der Bestellpositionen eineseinzelnen 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.

> UpdatesDie Anweisung UPDATE SET ermöglicht das Übertragen von einzelnen zu ändernden Feldern (stattdes gesamten Datensatzes). Wenn möglich, sollte diese Anweisung bevorzugt verwendet werden.

> Ausführungshäufigkeit bei DB-ZugriffenJede Ausführung eines Open SQL-Statements ist mit einem gewissen Overhead (Parsen, Abgleichgegen Statement-Puffer im DBMS usw.) verbunden. Daher sollten pro Statement möglichst vieleder benötigten Daten auf einmal übertragen werden. Werden beispielsweise die Daten von 50Aufträ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 INTOTABLE 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 derOverhead für diese Statements bei jedem Schleifendurchlauf an.

Setzen Sie MODIFY <DB-Tabelle> nicht ein! Erstens sollte innerhalb einer Applikation klar sein, obDatensätze neu erstellt wurden oder vorhandene angepasst werden müssen. Zweitens ist diesesStatement aus Performance-Gesichtspunkten sehr kritisch: Selbst mit dem Zusatz FROM TABLEwerden einzelne Zugriffe pro Zeile der internen Tabelle ausgeführt und dabei wird jeweils zuerstein UPDATE versucht und im Fehlerfall ein INSERT nachgelegt. D.h., bei vielen neu zu erstellendenDatensätzen erfolgen nicht n Einzelzugriffe, sondern 2n mit n=Anzahl neue Datensätze in derinternen Tabelle.

> VIEWS/JOINSGeschachtelte SELECT-Anweisungen und SELECT-Anweisungen in Schleifen sollten vermiedenwerden. Stattdessen bieten sich VIEWS, JOINS oder der Zusatz FOR ALL ENTRIES an. Bei FOR ALLENTRIES sollte man jedoch auf Folgendes achten:

a. Ist die interne Tabelle leer, auf der FOR ALL ENTRIES basiert, dann werden alle Einträgegeladen.

b. Sind in der internen Tabelle Einträge doppelt vorhanden, kann dies dazu führen, dass diezugehörigen Datensätze auch doppelt von der Datenbank geladen werden. Es empfiehlt sich daher,zuvor ein DELETE ADJACENT DUPLICATES aufzurufen.

3.5 INTERNE TABELLEN UND REFERENZEN

Interne Tabellen stellen ein zentrales Konstrukt bei der Entwicklung von Anwendungen mit ABAPdar. Neben Datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle vonPerformance-Problemen. Bei kleinen Datenmengen stellen Dinge wie die Wahl der passendenTabellenart und eines passenden Schlüssels noch kein Problem dar. Werden aber größere Daten-

mengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht,können vorher aus Performance-Sicht unkritische Stellen zu erheblichen Laufzeitverlängerungenführen.

BEST PRACTICE: Wir empfehlen die Beachtung der nachfolgenden Hinweise zur Steigerung derPerformance von Anwendungen:


2 0 1 3 , © D

S A G e . V .



21

Zeile der Tabelle als Schlüssel verwendet und damit bei der Sortierung alle Felder der Tabellegeprüft, was zu erheblichen Performance-Einbußen führt. Soll also z. B. ein Tabelle nach denFeldern Benutzer und Datum sortiert werden, verwenden Sie die Anweisung SORT table BYBenutzer 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 sichergestelltsein, dass die Tabelle nach den gleichen Feldern sortiert ist, damit doppelte Einträge auchwirklich eliminiert werden.

Wie die Anweisung aussagt, werden nur benachbarte Tabellenzeilen verglichen. Wie bei derSORT-Anweisung auch sollten immer die Felder angegeben werden, die betrachtet werdenmüssen. Ansonsten wird auch hier die gesamte Zeile feldweise verglichen, auch wenn nur zweiFelder aus fachlicher Sicht dafür ausreichend sind.

> Reine Existenzprüfungen auf internen Tabellen sollten immer mit READ TABLE TRANSPORTINGNO FIELDS durchgeführt werden, wenn auf den Daten der ermittelten Zeile keine weiterenOperationen stattfinden.

3.5.1 Feldsymbole

Feldsymbole bieten die Möglichkeit, auf existierende Daten, z.B. Zeilen von internen Tabellen, zureferenzieren. 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 eseinen minimalen Vorteil in der Laufzeit zwischen den Kopierkosten bei INTO <WA> und Feldsym-bolen. Ansonsten sind Feldsymbole immer schneller, insbesondere dann, wenn die Tabelleninhaltegeändert werden sollen. Bedenken Sie beim Einsatz von Feldsymbolen jedoch, dass eine Änderungdes Wertes eines Feldsymbols auch den Wert im referenzierten Datenelement überschreibt.

BEST PRACTICE: Verwenden Sie standardmäßig Feldsymbole für die Zugriffe auf interne Tabellen.

3.5.2 Parameterübergabe

Die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus technischenGründen vorgeschrieben ist (z.B. RFC-Funktionsbausteine, Returning-Parameter bei funktionalen

Methoden). So werden unnötige Kopierkosten bei der Parameterübergabe gespart. Dies gilt inbesonderem Maße bei Parametern mit tiefen Datentypen wie internen Tabellen oder Strings. Wennes keine technischen Erfordernisse gibt, sollten Parameter immer per Referenz übergeben werden.

Weiterhin sollten so wenig Parameter wie möglich definiert werden. Optionale Parameter solltenkomplett vermieden werden.

BEST PRACTICE: Verwenden Sie so wenig Parameter wie möglich, die per Referenz übergebenwerden. 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


2 0 1 3 , © D

S A G e . V .



23

4.1.3 Klassenbasierte Ausnahmen

Seit Einführung von ABAP OO können auch klassenbasierte Ausnahmen verwendet werden. Diesearbeiten 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 langeweiter im Call Stack nach oben propagiert, bis sie an anderer Stelle gefangen wird oder zu einemDump führt.

Es ist wichtig, alle Ausnahmen zu fangen, auf die in der jeweiligen Stelle angemessen reagiert werdenkann, oder Ausnahmen in der Methode oder dem Funktionsbaustein zu deklarieren, sodass für denAufrufer klar ersichtlich ist, dass die Methode bzw. der Funktionsbaustein eine solche Ausnahmeaufwerfen könnte. Wichtig ist hierbei die einheitliche Verwendung: Für dieselbe Fehlersituationsollten einheitliche Fehlerbehandlungen/Ausnahmen verwendet werden.

Zum Fangen von Ausnahmen ist der ABAP-Befehl TRY…CATCH…ENDTRY gedacht. Entsprechendmüssen alle Ausnahmen aller Module, die klassenbasierte Ausnahmen erzeugen können, voneinem 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 angemessenzu 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 eskonkrete Ausnahmen abzufangen, um diese spezifisch zu behandeln. Das Fangen der allgemeins-ten Ausnahme CX_ROOT sollte nur erfolgen, wenn die Ausnahmebehandlung tatsächlich in derLage ist, mit unbekannten Fehlersituationen umzugehen.

BEST PRACTICE: Wählen Sie die grundlegende Art von eigenen Ausnahmeklassen durch dieVererbung von vordefinierten Basisklassen (STATIC_CHECK, DYNAMIC_CHECK, NO_CHECK) mitBedacht.

Beim Einsatz von STATIC_CHECK wird jeder Verwender durch Syntaxfehler gezwungen, für jededieser Ausnahme zu entscheiden, ob er sie direkt behandeln kann, weiterreicht und damit in seineDeklaration aufnehmen muss oder über das Verketten mit eigenen Ausnahmeklassen verpackt.Alle diese Möglichkeiten sind mit Aufwand und Änderungen verbunden, die den Vorteil derklassenbasierten Ausnahmen (Propagieren von Ausnahmen, die nicht direkt behandelt werdenkönnen) zunichtemachen. Verwenden Sie bei der nachträglichen Einführung von Ausnahmeklassendaher bevorzugt DYNAMIC_CHECK, um nicht allen Ausnahmen die o.g. Anpassungen aufzuzwin-gen. Setzen Sie STATIC_CHECK bewusst ein, um Aufrufer dazu zu zwingen, sich mit der Ausnah-mesituation auseinanderzusetzen.

Die Ausnahmenklasse NO_CHECK bietet sich für solche Fehlersituationen an, auf die kaum eineaufrufende Stelle angemessen reagieren kann. Beispiele dafür sind das Wegbrechen von sekundärenDatenbankverbindungen oder andere Dinge, die durch das Coding nicht korrigiert werden können.


2 0 1 3 , © D

S A G e . V .



24

4.1.4 Nicht behandelbare Ausnahmen

Es gibt Ausnahmen, die vom ABAP Code aus nicht behandelt werden können und dadurch zwangs-läufig zu einem Abbruch der Anwendung und einem Dump führen. In einigen Fällen ist es möglich,pro aktiv vor der Ausführung eines Statements, das eine nicht behandelbare Ausnahme auslöst,die Rahmenbedingungen zu prüfen.

Beispiel:Das Statement OPEN DATASET löst einen Shortdump aus, wenn der Benutzer keine ausreichendenBerechtigungen zum Öffnen der Datei hat. Um dies zu vermeiden, muss die Berechtigung pro aktivvom ABAP geprüft werden (FuBa AUTHORITY_CHECK_DATASET), damit OPEN DATASET nicht zueinem Dump führt.

4.2 KORREKTE IMPLEMENTIERUNG VON DATENBANK-ÄNDERUNGEN

4.2.1 Sperrobjekte

Um Dateninkonsistenzen zu vermeiden, müssen die entsprechenden Objekte vor Veränderung aufder Datenbank gesperrt werden. Zusammenhängende Objekte dürfen erst verändert werden, wennalle zugehörigen Entitäten erfolgreich gesperrt werden. Damit ist keine parallele Datenänderungmöglich.

Die SAP-Sperre besteht über mehrere Datenbank-LUWs (Logical Unit of Work) hinweg, sodasskonsistent Ä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 derLUW 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 entspre-chenden SAP-Standard-Sperrfunktionen zu verwenden, da diese auch von den Standard-Transakti-onen verwendet werden und so ein konsistentes Verhalten sicherstellen.

Für kundeneigene Entwicklungen sind entsprechende Sperrobjekte mit den zugehörigenSperrfunktionen zu implementieren.

Die Sperren sind nach Abschluss des Updates auf das Objekt aufzuheben. Dies erfolgt mittelsAufruf 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.2 Verbuchungskonzept

Die Verbuchung ist die zentrale Technik zur Bündelung von Datenbankänderungen in einer einzigen

Datenbank-LUW und damit zur Definition von SAP-LUWs in SAP-Transaktionen. Datenänderungensollen nicht mit DML-Kommandos (DataManipulati-onLanguage-Kommandos Insert, Update,Delete, Modify) aus der Applikation, sondern über den Verbucher durchgeführt werden.

4 ROBUSTHEIT

http://help.sap.com/saphelp_NW70/helpdata/de/7b/f9813712f7434be10000009b38f8cf/frameset.htm%0D

http://help.sap.com/saphelp_NW70/helpdata/de/7b/f9813712f7434be10000009b38f8cf/frameset.htm%0D



25

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 beider Anlage entsprechend in den Eigenschaften zu kennzeichnen. Diese Funktionsbausteine werdenmit dem Zusatz „IN UPDATE TASK“ aufgerufen und unterliegen bei der Entwicklung einigenRestriktionen. Alle bis zu einem „COMMIT WORK“ gerufenen Verbuchungsfunktionen werden ineiner LUW auf die Datenbank geschrieben.

Beim Aufruf der Sperrfunktionsbausteine ist auf die korrekte Parametrierung (insbesondereSCOPE-Parameter) zu achten!

Fehlerhafte Verbuchungssätze müssen in der Transaktion Verbuchungsaufträge (SM13) admini-striert und nachbehandelt werden. Aus Revisionsgründen ist es empfehlenswert, die Nachbearbei-tung 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.1 Asynchrone Verbuchung

Die Funktionsbausteine werden in den Eigenschaften mit „Start sofort“ oder in Ausnahmefällen mit„Start sofort – nicht nachverbuchbar“ angelegt. Die Verbuchung wird sofort nach Abschluss derLUW gestartet, jedoch asynchron durchgeführt.

4.2.2.2 Asynchrone Verbuchung in Abschnitten

Die Funktionsbausteine werden in den Eigenschaften mit „Start verzögert“ angelegt. Die Verbu-chung wird sofort nach Abschluss der LUW gestartet, wird jedoch asynchron in eigenen Prozessenmit niedriger Priorität durchgeführt. Diese Art der Verbuchung ist für das Schreiben von großenDatenmengen geeignet, wenn die Verbuchung nicht zeitkritisch erfolgen muss (z.B. Ladepro-gramme, Protokollierung ...).

4.2.2.3 Synchrone Verbuchung

Die Funktionalität und die notwendigen Einstellungen sind analog zu jenen im Punkt 4.2.2.1Asynchrone Verbuchung. Die LUW muss jedoch mit „COMMIT WORK AND WAIT“ abgeschlossenwerden. 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.


2 0 1 3 , © D

S A G e . V .

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

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



26

4.3 PROTOKOLLIERUNG

Generell sollten Fehler, Ausnahmen und Meldungen ins Business Application Log gespeichert

werden, um diese an zentraler Stelle (Transaktion SLG1) prüfen zu können. Mit der TransaktionSLG0 können darüber hinaus eigene Objekte zur Protokollierung definiert werden.

Der Vorteil bei der Verwendung des Business Application Logs liegt in folgenden Aspektenbegründet:

1. Zentrale Ablage: Im Business Application Log können Meldungen an zentraler Stelle verwaltetwerden; dies erleichtert den Überblick und die Administration der Anwendungen

2. Wiederverwendbarkeit: Das Business Application Log bzw. die zugehörigen Bausteine/Klassenbieten 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*“ bieteneinen guten Einstieg und Überblick.

Bitte beachten Sie bei der Implementierung die SAP-Standardhilfe bzgl. der Verwendung derFunktionsbausteine im jeweiligen Release.

WEITERE QUELLEN:

1. SAP Application Log – Leitfaden für Anwenderhttp://help.sap.com/saphelp_nw70ehp2/helpdata/de/3a/c8263712c79958e10000009b38f936/frameset.htm

2. Beispiele zur Verwendung der BAL Funktionen in:

Thorsten Franz, Tobias Trapp, „Anwendungsentwicklung mit ABAP Objects, SAP Press, ISBN-10:3836210630

4.4 PRAXISBEISPIELE

In diesem Abschnitt finden sich noch einige Robustness-Probleme, die in Audits immer wiederauftauchen.

4.4.1 Unvollständige Fallunterscheidungen

Für CASE Statements wird empfohlen, alle vorhandenen WHEN-Blöcke auszuprogrammieren.Außerdem sollte immer ein WHEN OTHERS-Block vorhanden sein, um Fälle zu behandeln, die zurZeit der Entwicklung noch nicht abzusehen waren bzw. unterwartet sind.

4 ROBUSTHEIT

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






28

Dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im ABAP negativ auf dieSicherheit eines Unternehmens auswirken können. Da dieses Thema sehr komplex ist, können wirim Rahmen dieses Dokuments nur ein paar ausgewählte, zentrale Themen behandeln. Fürweitergehende Fragen verweisen wir auf die Literaturhinweise am Ende dieses Kapitels. Zunächstmüssen wir die Begriffe Sicherheit und Compliance in diesem Kontext erklären:

Wir sprechen von einer Sicherheitsschwachstelle, wenn ein Programmierfehler einen ungewolltenNebeneffekt verursacht, durch den ein Angreifer unbefugt schadhafte Aktionen ausführen kann. Wir sprechen von einem Compliance-Verstoß, wenn ein Anwender aufgrund eines Programmier-fehlers 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 IMSAP STANDARD

Bevor wir näher auf Schwachstellen eingehen, ist es wichtig, sich noch einmal ein paar zentraleSchutzmechanismen des SAP-Standards vor Augen zu führen. Diese sind Grundvoraussetzung fürden sicheren Betrieb von SAP-Systemen.

5.1.1 Berechtigungsprüfung (A)

Rollen und Berechtigungen sind ein zentrales Sicherheitsthema im SAP-Umfeld. Es ist daherwichtig zu verstehen, dass ABAP ein sogenanntes explizites Berechtigungsmodell verwendet. Dasbedeutet, dass Berechtigungsprüfungen explizit im Code programmiert werden müssen, damit sieauch ausgeführt werden. Das beste Berechtigungskonzept nützt nichts, wenn selbstgeschriebenerCode die erforderlichen Berechtigungen nicht (richtig) prüft.

Sicherheitsprobleme ergeben sich z.B. in folgenden Fällen:> Der Entwickler vergisst, die Berechtigungsprüfung zu programmieren.> Der Entwickler verwendet das falsche Berechtigungsobjekt.> Der Entwickler verwendet eine proprietäre Berechtigungsprüfung.> Der Entwickler behandelt den Rückgabewert der Prüfung nicht.

5.1.2 Mandantentrennung (B)

Der SAP-Standard trennt automatisch alle Datenbankzugriffe nach Mandanten auf. Ein ABAP-Programm darf immer nur die Daten des Mandanten verarbeiten, an dem sich der Anwender ange-meldet 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 ABAP-SICHERHEIT UND COMPLIANCE



29

5.1.3 Nachvollziehbarkeit (C)

Die meisten Geschäftstransaktionen müssen nachvollziehbar sein, insbesondere in der Finanz-buchhaltung. Selbstgeschriebener ABAP Code darf Anwendern nicht ermöglichen, relevanteAktionen zu verschleiern.

Sicherheitsprobleme ergeben sich in folgenden Fällen:> Der Entwickler vergisst, für wichtige Tabellen Änderungsbelege zu schreiben.> Der Entwickler ermöglicht (unbeabsichtigt) einen sogenannten Identitätsdiebstahl.> Der Entwickler verändert direkt Tabelleninhalte, ohne Standardfunktionsbausteine zu verwenden

(und damit implizit die Protokollierung zu verwenden).

5.1.4 Dreisystemlandschaft (D)

Der SAP-Standard sieht vor, für Entwicklung, Qualitätssicherung und Produktion getrennteSysteme (D, Q, P) zu verwenden. Dies dient in erster Linie dazu, die Produktivdaten vor unzurei-chend getesteten Programmen zu schützen und die umfangreichen Rechte der Entwickler auf dasEntwicklungssystem zu beschränken.

Sicherheitsprobleme ergeben sich in folgenden Fällen:> 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 sehrgefährlich ist, stellt der Standard Transaktionen (SM49/SM69) zur Verfügung, mit denen man eineListe erlaubter Befehle definieren und die erlaubten Befehle auch noch durch spezielle Berechti-gungen zusätzlich schützen kann.

Sicherheitsprobleme ergeben sich in folgenden Fällen:> 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 einemsehr limitierten Satz an Befehlen, die zusätzlich alle statisch deklariert werden müssen. Dadurchkönnen gefährliche SQL-Befehle in der Datenbank abgeschirmt werden.

Sicherheitsprobleme ergeben sich in folgenden Fällen:> 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.


2 0 1 3 , © D

S A G e . V .



31

ID Schwachstelle Beschreibung Std

APP-07 Cross-Client Database Access Mandantenübergreifender

Zugriff auf Geschäftsdaten

B

APP-08 Open SQL Injection Schadhafte Manipulation vonDatenbankbefehlen

F

APP-09 Generic Module Execution Unerlaubte Ausführung vonModulen (Reports, FuBas etc.)

A

APP-10 Cross-Site Scripting Manipulation des Browser UI,Diebstahl von Berechtigungen

C

APP-11 Obscure ABAP Code Einschränkte Auditierbarkeitdurch Verschleierung von Code

D

Abbildung 1: BIZEC APP/11 – Die derzeit verbreitetsten Sicherheitsprobleme in ABAP-CodeQUELLE: http://www.bizec.org/wiki/BIZEC_APP11

Dieses Kapitel kann bei Weitem nicht die notwendigen Details liefern, um sicheren ABAP-Code zuprogrammieren. 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 einigender oben beschriebenen Probleme beschreiben.

SAP Note Schwachstelle1520356 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 Verbindunggebracht, ist aber für Wirtschaftsprüfungen durchaus relevant (siehe Literaturempfehlung #2).

Die meisten Unternehmen verfügen über ein internes Kontrollsystem (IKS), das Compliance-Risiken entgegenwirkt. Dies ist beispielsweise in den international anerkannten ReferenzmodellenCOSO & 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.


2 0 1 3 , © D

S A G e . V .

http://www.bizec.org/wiki/BIZEC_APP11

http://www.bizec.org/wiki/BIZEC_APP11



32

Ein elementarer Baustein der ITGC ist das Änderungswesen (Change Management), zu demwiederum Eigenentwicklungen zählen. Sicherheitsdefekte im selbstgeschriebenen ABAP-Codestellen 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 nurAuswirkungen auf Compliance-Standards haben, sondern auch gesetzliche Anforderungenverletzen können.

Alle in Abbildung 1 dargestellten Sicherheitsdefekte sind daher auch Compliance-relevant.

5.4 TESTWERKZEUGE

Für ABAP-Sicherheitstests eigenen sich insbesondere sogenannte statische Codeanalyse-Tools.Es gibt hier verschiedene kommerzielle Anbieter, die in wesentlichen Bereichen die Möglichkeitendes 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 überwiegendWeb-spezifisch und auf ABAP kaum anwendbar)> 4-Augen-Prinzip bei Ausnahmen

5 ABAP-SICHERHEIT UND COMPLIANCE



33

Natürlich muss so ein Tool hinreichend in SE80, TMS und ChaRM integriert sein, damit dieEntwickler 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 20092. Maxim Chuprunov , Handbuch SAP-Revision, SAP Press 20113. BIZEC - The Business Application Initiative (http://bizec.org)


2 0 1 3 , © D

S A G e . V .



34

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 diesspätestens bei der Weiterentwicklung oder dem Wechsel von Entwicklern zu erhöhten Aufwänden.In diesem Kapitel werden unterschiedliche Möglichkeiten zur Dokumentation von Entwicklungsob-

jekten im SAP System dargestellt.

6.1 DOKUMENTATION UNABHÄNGIG VON ENTWICKLUNGSOBJEKTEN

Neben der Beschreibung der vielen Entwicklungsobjekte, die einzelne, sehr spezielle Funktionenim ABAP-System übernehmen, gibt es auch den Bedarf, die größeren Zusammenhänge innerhalbund 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 sinddavon betroffen?

Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes Ablageme-dium innerhalb des SAP-Entwicklungssystems, das insbesondere Grafiken gut integriert. Wirempfehlen daher, für die Dokumentation dieser übergreifenden Zusammenhänge auf andereMedien 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 Disziplinliegt. Diese Herausforderung kann kein Tool lösen, sondern nur das Entwicklungsteam und diezugehörige -leitung. Darüber hinaus sei angemerkt, dass veraltete Dokumentation irreführend sein kann. Insofernsollte in Dokumenten der Stand und eine Versionierung enthalten sein, um die Aktualität bewertenzu können.

Innerhalb einer SAP-Systemlandschaft bietet der SAP Solution Manager Möglichkeiten zurProjektdokumentation. 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 DOKUMENTATION

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



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









35

6.2 DOKUMENTATION VON ENTWICKLUNGSOBJEKTEN

Neben Methoden, Funktionsbausteinen und Reports, die Dokumentation im Quelltext enthalten

können, existieren weitere Entwicklungsobjekte im ABAP-System, die keinen Quelltext beinhaltenund 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, dieMöglichkeiten zur Dokumentation der ABAP Workbench zu nutzen und die Aufgaben undBedeutungen dieser Objekte im SAP-System zu dokumentieren. Im Vergleich zur Dokumentationim 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 Dokumentationin allen Stages einer Systemlandschaft zur Verfügung. Weiterhin kann die Dokumentation von allenBenutzern eingesehen werden und wird in einigen Fällen (Reports) vom ABAP-System automatischin die Benutzungsoberfläche eingebunden. Ein weiterer Vorteil besteht darin, dass diese Dokumen-tation übersetzbar ist.

6.3 DOKUMENTATION IM QUELLTEXT

6.3.1 Dokumentation und Kommentierung von Anweisungen/Anweisungsblöcken

Generell sollten Anweisungsblöcke im Quelltext (kurz) kommentiert werden, damit ein schnellesZurechtfinden in fremden Programmen ermöglicht wird. Dabei soll in einer Kommentarzeile kurzbeschrieben werden, welche Aufgabe der nächste Anweisungsblock hat. Dokumentieren Sieinsbesondere, warum Sie etwas machen, nicht wie. Dabei gilt der Grundsatz: So wenig Kommentarwie möglich, so viel Kommentar wie nötig. Vermeiden Sie daher redundante Informationen (wieName des dokumentierten Moduls, den letzten Änderer etc).

BEST PRACTICE: Als Kommentierungssprache sollte Englisch verwendet werden. Entwicklungs-teams arbeiten heutzutage überwiegend international zusammen. Auch wenn Sie derzeit reindeutschsprachig entwickeln, kann Ihr Projekt im Laufe der Zeit internationalisiert werden. DerAufwand, 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, wenndie Kommentare englisch sind. Denn die ABAP-Befehle selbst sind englisch und im Stil von Sätzenaufgebaut. Der Leser muss bei englischer Dokumentation also nicht ständig beim Lesen desQuelltextes die Sprache wechseln.


2 0 1 3 , © D

S A G e . V .



36

6.3.2 Dokumentation von Änderungen

Ab dem Zeitpunkt der Produktivsetzung eines Programms müssen Änderungen in Programmendokumentiert werden.

6.3.3 Programmkopf

Änderungen in Programmen werden mit einem Namenskürzel (z.B. Vorname + Nachname), demTagesdatum und dem Change Document der Änderung im Programmkopf dokumentiert. Dabeisoll 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 Blickder Grund der Änderung im Code erfasst werden.

Beispiel:

*/ Change Log

*/ VN/DateChangeDoc 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-tracking-Systeme eingesetzt, sollten in diesem Kommentar Verweise auf die Vorgänge/Issues enthaltensein. Damit lässt sich später auch im Quelltext nachvollziehen, welche Erweiterung/Fehlerbehe-bung Auslöser für eine Änderung war.

BEST PRACTICE: Der Kommentar ist nicht für den Verfasser, sondern für andere Entwicklergedacht. Führen Sie sich das bei der Erstellung von Kommentaren bzw. deren Review immerwieder 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 derPretty Printer die Kommentierung automatisch nach rechts ausrichtet.

Alte Dokumentationen von Änderungen, die nicht mehr benötigt werden, sollten aus Gründen der Les-barkeit wieder entfernt werden. Oberstes Ziel sollte stets die gute Lesbarkeit von Quelltexten sein.

6 DOKUMENTATION



37

Einfache Änderung

*WRITE: lw_mara-matnr. „ MZ/2012-08-06 CD4712 CD4711 Add MMSTA in OutputWRITE: 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 Codeverwendet 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


2 0 1 3 , © D

S A G e . V .



38

Dieses Kapitel beschreibt, wie sich die Best Practices aus dieser Guideline in der Praxis verwirkli-chen lassen. Wir unterscheiden hierbei Umsetzbarkeit und Durchsetzbarkeit der Richtlinien.

Im Abschnitt „Umsetzbarkeit“ erklären wir, worauf ein Unternehmen achten sollte, das Program-mierrichtlinien einführen möchte. Wir erklären, wie ein Prozess dafür aussehen könnte, wie mandiesen ins Leben ruft und vor allem, wie man ihn am Leben erhält. Im Abschnitt „Durchsetzbar-keit“ legen wir dar, wie ein Unternehmen die Vorgaben aus dem Prozess prüfen kann. Hierzugehören organisatorische Aspekte genauso wie Prüfmethoden und Werkzeuge. Wir gehen aberauch auf Grenzen der Durchsetzbarkeit ein.

Abschließend stellen wir Tipps aus der Praxis vor, die die Autoren bei verschiedenen Projekten imUmfeld der SAP-Entwicklung gesammelt haben.

7.1 UMSETZBARKEIT

Wer erfolgreich Programmierrichtlinien in einem Unternehmen einführen möchte, muss zunächstdas Management dafür gewinnen. Denn die Verbesserung der Codequalität bedeutet zunächst eineInvestition in Prozesse und Werkzeuge sowie in die Fortbildung der involvierten Mitarbeiter.Insbesondere muss das Management überzeugt sein, dass das Unternehmen durch dieseProzesse 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 Unternehmenhat:

SicherheitVorteil: 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 Pressemeldungenhervorgerufen durch Datenlecks, Stillstand der Produktivsysteme.

ComplianceVorteil: 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-Anfor-derungen oder gesetzliche Regelungen (z.B. Datenschutz).

PerformanceVorteil: Das Unternehmen stellt sicher, dass die vorhandene Hardware optimal genutzt werdenkann, und schützt damit die bisherige Investition in Hardware. Außerdem steigt die Zufriedenheitder Mitarbeiter, da die Nutzung der Anwendung produktiver wird.Risiken bei Qualitätsmängeln: Die Akzeptanz der Anwender sinkt bzw. es entstehen Kosten fürschnellere Hardware, um die Softwaremängel auszugleichen.

7 UMSETZBARKEIT UND DURCHSETZBARKEIT



39

RobustheitVorteil: Das Unternehmen stellt den kontinuierlichen Betrieb der Geschäftsanwendungen sicherund vermeidet Unproduktivität auf Grund von Systemausfällen.Risiken bei Qualitätsmängeln: Die Akzeptanz der Anwender sinkt und die Betriebskosten steigenwegen Unproduktivität der Anwender sowie durch Fehleranalysen und Wartungsarbeiten durchTechniker.

WartbarkeitVorteil: Das Unternehmen erreicht, dass die Applikation nachhaltig und kosteneffizient gewartetwerden kann, weil die Programmstruktur leicht verständlich und gut dokumentiert ist.Risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte Fehleranfälligkeit derApplikation.

7.1.2 Erstellung und Pflege des Prozesses

Für die Umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschreibung einesProzesses bewährt. Dazu zählen klare Verfahrensanweisungen und Verantwortlichkeiten. Diegenaue Ausprägung des Prozesses ist unternehmensspezifisch und kann in dieser Guideline nichtabgebildet werden; der Verweis auf die Notwendigkeit ist jedoch allgemeingültig.

BEST PRACTICE: Definieren Sie den einzuhaltenden Prozess und dokumentieren Sie ihn in einerfür alle zugänglichen Form. Definieren Sie, wie Änderungen und Verbesserungen am Prozessstattfinden sollen und wie Anmerkungen und Kritik eingebracht werden können. DokumentierenSie alle geprüften Regeln ausführlich mit den Kapiteln Hintergrund/Motivation, schlechteBeispiele, gute Beispiele, Hinweise zum Vorgehen zur Beseitigung und Literatur bzw. Ansprech-partner im Unternehmen.

MotivationEin Prozess für Best Practices bei der Entwicklung hilft, die Qualität von Software pro aktiv undeffizient zu verbessern und damit Kosten im Unternehmen langfristig zu senken. Je früher einFehler bei der Entwicklung erkannt wird, desto einfacher und kostensparender kann er behobenwerden. Je weniger Fehler eine Anwendung enthält, desto mehr entspricht ihre Nutzung denErwartungen des Unternehmens. Insbesondere läuft sie ohne Nebeneffekte, die das Businessnegativ beeinflussen.

Welche Aspekte sind für den Prozess relevant?

Interne EntwicklungFür die interne Entwicklung werden Richtlinien als Nachschlagewerk für die tägliche Arbeit undregelmäßige Trainings für aktuelle Risiken benötigt.

Externe EntwicklungBei externer Entwicklung sind klare Qualitätsvorgaben für Ausschreibungen nötig. Vor derAbnahme müssen die Anforderungen auch überprüft werden.

ÜbergreifendDie Vorgaben aus dem Prozess müssen möglichst weitgehend mit geeigneten Tools überprüftwerden. Eine manuelle Prüfung ist nur in seltenen Fällen flächendeckend möglich.


2 0 1 3 , © D

S A G e . V .



40

BEST PRACTICE: Vorgaben ohne werkzeuggestützte Überprüfungsmöglichkeit sind nichtumsetzbar und sollten daher nicht definiert und vorgegeben werden. Bei jeder Regel, die zur nachträglichen QS herangezogen werden soll, muss festgelegt werden, wiediese werkzeuggestützt überprüft werden kann. Wenn keine mechanische Überprüfung durch einWerkzeug möglich ist, wird es in der Praxis nahezu unmöglich werden, auf die konsequenteEinhaltung der Regel zu achten. Die Konzentration auf maschinell überprüfbare Regeln erspartdenjenigen, die Qualitätssicherung betreiben sollen, eine Vielzahl an Frustrationsquellen.

Nichtsdestotrotz gibt es etliche Aspekte, die sich einer maschinellen Prüfung entziehen. DieseAspekte können sinnvollerweise nur mit regelmäßig durchgeführten Code Reviews abgedecktwerden. Da gut durchgeführte Code Reviews erhebliche Aufwände in der Durchführung, aber auchder Vor- und Nachbereitung bzw. Kontrolle von Korrekturen erfordern, müssen diese sich aufwenige, 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 Datenbankenoder umfangreichen Berechnungen beschränkt werden.

Der Prozess muss daher eine Qualitätskontrolle vorsehen, durch die sämtliche Entwicklungengeprüft werden, bevor sie in den Produktivbetrieb gehen. Es muss auch definiert sein, wie mitFehlern verfahren werden soll. Der Prozess muss selbstverständlich regelmäßig aktualisiertwerden, um neue Aspekte berücksichtigen zu können.

7.2 DURCHSETZBARKEIT

7.2.1 Manuelle Prüfungen

Viele der Prüfungen lassen sich automatisieren. Es gibt jedoch Bereiche, die sich für eineautomatische Prüfung nicht eignen, wie beispielsweise Dokumentation, Architektur oder vielefunktionale Anforderungen. Die menschliche Sprache ist sehr komplex, daher muss z.B. der Inhaltvon Dokumenten und Dokumentationen manuell geprüft werden. Nur der menschliche Leser kannbeurteilen, ob ein Text sinnvoll, vollständig, verständlich und korrekt ist. Eine automatischePrüfung kann dabei maximal die Existenz in den vorgegebenen Sprachen prüfen. Es empfiehlt sichdennoch ein automatischer Test auf nicht-funktionale Aspekte.

Für die manuelle Prüfung ist es wünschenswert, eine vollständige Prüfung anhand der Auswer-tung von Transportstücklisten vorzunehmen. Dabei ist zu berücksichtigen, welche unternehmens-internen Richtlinien existieren. Abhängig von der Anzahl der Objekte muss eine vollständige oderzumindest stichprobenartige Prüfung erfolgen. Das Prüfergebnis wird dem Entwickler/Zuständigenzur Verbesserung/Vervollständigung der Dokumente/Dokumentationen übermittelt.

Ob ein Prozess alle Vorgaben erfüllt, kann nur mittels einer manuellen periodischen Prüfungermittelt werden. Falls sich Vorgaben ändern bzw. Mängel im Prozess aufgedeckt werden, ist derProzess entsprechend anzupassen oder ggfs. neu zu definieren.

In der Praxis hat sich ein fest eingeplanter zyklischer Review des Prozesses bewährt.




41

Wann und wie sollte geprüft werden?

Die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf Aktualität und Konformitätbzgl. der Vorgaben geprüft werden. Die Aktualität ist jedenfalls mit einem Upgrade auf ein neuesRelease (Enhancement Package) zu prüfen. Bzgl. der Vorgaben ist es durchaus sinnvoll, dasWirtschaftsprüfungsunternehmen, welches das Unternehmen prüft, hinzuzuziehen. Für externentwickelten 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 essinnvoll, im Rahmen der Entwickler- und QA-Tests (4-Augen-Prinzip) die manuell notwendigenPrüfungen durch andere Entwickler durchführen zu lassen.

Dasselbe gilt für Penetrationstests und Belastungstests. Da es sich bei Penetrationstests auch umein kritisches Sicherheitsthema handelt, kann es notwendig sein, hierfür in regelmäßigen

Abständen auch externe Partner hinzuzuziehen.

7.2.2 Automatische Prüfungen

Automatische Tests decken schnell einen Großteil der notwendigen Tests und Prüfungen ab. AlsHintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne zusätzlichen Aufwandmöglich. Diese regelmäßig mit gleicher Qualität durchgeführten Tests ermöglichen so denEntwicklern, ihren Programmierstil zu verbessern.

Wann und wie sollte geprüft werden?

Die Entwickler sollen ein möglichst zeitnahes Feedback bzgl. der Konformität der Entwicklungenmit 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 undMetriken bei der Prüfung durch jeden einzelnen Entwickler und bei der Prüfung durch zentraleQS-Instanzen bzw. bei einer Transportfreigabe verwendet werden. Sollten für diese Prüfungenunterschiedliche Werkzeuge oder unterschiedliche Einstellungen verwendet werden, sinkt dieAkzeptanz in Entwicklerkreisen ganz erheblich.

Als zentrale Schutzinstanz müssen die Prüfungen in das TMS und da spätestens mit der Freigabedes Transportauftrags (besser der einzelnen Transportaufgaben) implementiert sein. Damit wird

sichergestellt, dass keine ungeprüften bzw. nicht den Richtlinien entsprechenden Entwicklungen indie Folgesysteme und dann auch in das Produktivsystem transportiert werden.

Als „letztes Sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsystemvorzusehen. Dieser sollte in einer lastarmen Zeit mittels Hintergrundjob eingeplant werden. DasErgebnis 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 umgegangenwird. Sinnvoll scheint es hierfür auch, einen Fahrplan zu erstellen, wann und wie die neuen Regeln

auf alten Code angewendet werden.


2 0 1 3 , © D

S A G e . V .



42

7.2.3 Werkzeuge

Nachstehend werden einige Tools aufgelistet, mit welchen die automatisierten Prüfungendurchgeführt werden können.

SAP Code Inspector

Der SAP-Code Inspector wird seitens SAP im Standard ausgeliefert und ist entsprechend in dieEntwicklungsumgebung hoch integriert. SAP sieht ein Erweiterungskonzept vor, welchesermöglicht, kundenspezifische Prüfungen selbst zu implementieren. Hierfür sind ggfs. Program-mierarbeiten notwendig. Die seitens SAP ausgelieferten Prüfungen können teilweise weitgehendparametrisiert werden. Inspektionen auch von großen Objektmengen können sowohl online alsauch im Batchbetrieb erfolgen und Ergebnismengen von vorangegangenen Inspektionen könnenwieder als Objektmenge verwendet werden, um die Kontrolle von Korrekturen auf die vorher

fehlerbehafteten Objekte zu beschränken. Weiterhin können Ergebnisse auch automatisch perE-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 aufCode-Ebene vornehmen. Eine Beschreibung dieser Tools soll aus Neutralitätsgründen an dieserStelle unterbleiben.

7.3 ERFAHRUNGEN UND TIPPS AUS DER PRAXIS

7.3.1 Qualitätssicherung des Quellcodes

Um eine erfolgreiche Einführung zu gewährleisten, ist es wichtig, Qualitätssicherung schrittweiseund 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 dieserProzess stabilisiert hat, sollte nach und nach Bestandscode mit in die Checks aufgenommenwerden, sonst wird der zu bewältigende Berg für den Entwickler zu groß und die Motivation sinktrapide.

Wenn nicht auf der „grünen Wiese“ mit einer neuen Entwicklung begonnen wird, wenn automa-tische Codeprüfungen eingeführt werden, ist es wichtig, vorher den Umgang mit „Altlasten“ zuklären. Auch bei neuen Entwicklungen lassen sich Änderungen an schon bestehenden Objektennicht 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 Verantwort-lichen müssen entscheiden, ob Fehler im Bestandscoding sofort korrigiert werden müssen odereine Ausnahmeregelung möglich ist.

In vielen Fällen ist es schon ausreichend, mit Standard-Bordmitteln, wie z.B. Code Inspector, zuarbeiten, 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 nachbestimmten kritischen Anweisungen, Verwendung der ADBC-Schnittstelle, mandenatenabhängigeShared-Objects-Methoden, Robuste Programmierung und ABAP-WebDynpro-Metrik.




43

7.3.2 Zeit und Budget QA

Um die Zeit und den Aufwand für die QA-Tätigkeiten möglichst gering zu halten, muss derEntwickler die Möglichkeit haben, den Code während seiner Entwicklertätigkeit selbstständig aufFehler hin untersuchen zu können.

Tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten hingewiesenwerden. Tägliche Inspektionen mit einem entsprechenden Werkzeug und Verteilung der Ergeb-nisse stellen sicher, dass Fehler frühzeitig erkannt werden und die Entwickler sich noch an ihreTätigkeiten vom Vortrag erinnern, was die Fehlerbehebung deutlich vereinfacht. So wird gewähr-leistet, 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äterdie QA einsetzt, desto höher ist der Aufwand für die Fehlerbehebung. Dieser zusätzliche Aufwandentsteht 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 zuberücksichtigen, und zwar nicht nur am Ende, sondern projektbegleitend und anschließend imkompletten Software-Lifecycle.

Nicht zu unterschätzen ist auch der Schulungsaufwand, der benötigt wird, um bei den Entwicklernum Verständnis für den Prozess zu werben.

Bei einem Einsatz von externen Entwicklern müssen die Programmierrichtlinien und Namenskon-ventionen Bestandteil des Vertrages sein.

7.3.3 Probleme

Bei der Einführung einer Code QA treten eine Reihe von Problemen auf, auf die hier kurzeingegangen 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 wiederaufgeworfen:

„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üglichHandhabung von kopiertem Code, der auf anderen/keinen Konventionen beruht, getroffen unddurchgesetzt werden.

BEST PRACTICE: Um bei auftretenden Problemen die Fragen der Entwickler zu beantworten, ist eswichtig, dafür eine zentrale Stelle zu schaffen. Außerdem muss es einen Prozess geben, um inNotfä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 Genehmi-gungsprozess zu installieren, mit dessen Hilfe auch fehlerbehafteter Code freigegeben odertransportiert werden kann. Die meisten Tools am Markt bieten diese Möglichkeit standardmäßig an.


2 0 1 3 , © D

S A G e . V .



44

7.3.4 Entscheidungsfindung bei Modifikationen

Wichtig ist es, die Hürde für Modifikationen so hoch wie möglich zu legen. Dies ist besonders wichtig,wenn man sich dazu entscheidet, zeitnah Enhancement Packages der SAP einzuspielen (SPAU-Problematik). Ansatzpunkt hierzu ist der Modifikationsschlüssel. Die Anzahl der Entwickler, die dieBerechtigung haben, Modifikationsschlüssel zu generieren, muss möglichst gering sein. So ist esmöglich, steuernd einzugreifen und diese über Change Requests und einen zugehörigen Prozessabzuhandeln.

Die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu beantwortenund konsequent umzusetzen. Eine Pauschalantwort auf diese Frage gibt es nicht. In jedem Fallsollte die Entscheidung jedoch auf gleichartigen, im Vorfeld definierten und kommuniziertenKriterien basieren.

7.3.5 Erfahrungsbericht aus der Praxis: Comgroup GmbH

Das nachfolgende Beispiel der Comgroup GmbH, dem IT-Dienstleister der Würth Gruppe, zeigt wieProgrammierrichtlinien und Namenskonventionen in einer Softwareentwicklung ein- unddurchgesetzt werden können. Die Comgroup GmbH startete mit der Code QA im globalen Entwicklungssystem einer mehrstu-figen Entwicklungslandschaft. Zur automatisierten Unterstützung wurde der Code Inspectoreingesetzt. Da die Code-QA-Einführung mit der Einführung eines neuen Namensraumeszusammenfiel, 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, dadieser keine Änderungs- oder Erstellungsdaten bei der Selektion berücksichtigt. Außerdemwurden Performance- und Security-Checks aus dem Code Inspector vorerst nicht aktiviert, um denAufwand in einem überschaubaren Rahmen zu halten.

Hierdurch hat der Entwickler die Möglichkeit, seinen Code während seiner Entwicklertätigkeitselbstständig zu checken. Zusätzlich wurde ein Nachtlauf eingeplant, der den kompletten zuscannenden Code analysiert und bei gefundenen Fehlern Mails an den jeweiligen Entwicklersendet. Probleme bereitete hierbei, dass es viele User im System gab, die keine zugeordneteMailadresse 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 somitkönnen die unvollständigen Datensätze mit einem geringen Aufwand identifiziert werden. Deshalbwerden nun keine Entwicklungs-User mehr im System ohne Mailadresse angelegt.

Die Mails wurden nicht von einem anonymen Batch-User sondern von der Mailadresse desQA-Verantwortlichen gesendet, um dem Entwickler einfach die Möglichkeit zu geben, Fragen zustellen. Zu Beginn entstand hierdurch ein hoher Aufwand, die Anzahl der Fragen verringerte sichaber mit der Laufzeit des Projekts. Dies konnte erreicht werden, da Schulungen durchgeführtwurden und so die Entwickler effizienter die Fehler korrigieren konnten oder diese schon bei derEntwicklung vermieden.




45

Die Entwicklungssprache in der Entwicklungslandschaft ist Englisch. Dies wird durch einenweiteren Job geprüft und bei Fehlern dem Entwickler gemeldet. SAP bietet keine Möglichkeit imStandard, bei der Anlage die richtige Sprache zu setzen. Deshalb bot sich nur die Möglichkeit, anpassender 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 nurnach 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 InCTS_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 bishernoch nicht gecheckt. Zusätzlich ist geplant, ein externes Tool einzusetzen, das die Qualitätssiche-rung vereinfacht.


2 0 1 3 , © D

S A G e . V .



46

Neben methodischen Empfehlungen und Werkzeugen zur Unterstützung bei der Softwareentwick-lung im SAP-System stellen die Infrastruktur und die Betrachtung des Lebenszyklus einerSoftwarekomponente eine wichtige Rahmenbedingung für erfolgreiches Arbeiten dar. In diesemKapitel liegt auf diesen beiden Aspekten der Fokus.

8.1 INFRASTRUKTUR

Eine SAP-Systemlandschaft ist i.d.R. mehrstufig aufgebaut. Nachfolgend werden die einzelnenSysteme und ihre Bedeutung dargestellt:

8.1.1 Sandbox

Die Sandbox ist ein reines Test- und „Spielsystem“. In der Sandbox gelten keine Einschränkungenin Bezug auf Berechtigungen, das gilt gleichermaßen für Customizing- und Workbench-Entwick-

lungen. Aus der Sandbox sind keine Transporte in andere Systeme erlaubt. Änderungen könnenausprobiert werden, bevor sie im Entwicklungssystem durchgeführt werden. Damit kann derRückbau komplexer Entwicklungen in der Entwicklungsumgebung vermieden werden, wenn z.B.eine Neuentwicklung nicht weiter verfolgt werden soll.

8.1.2 Entwicklungssystem

Ein kombiniertes Entwicklungs-/Testsystem (z.B. Entwicklungsmandant 010, Testmandant 110)bietet sich als einfache und praktikable Lösung an. Es ist beispielsweise kein Transport vonWorkbench-Objekten erforderlich, um Neuentwicklungen zu testen.

Im Testmandanten herrscht dabei absolutes Customizing-Verbot. Customizing dieses Mandantenwird ausschließlich durch Mandantenkopie aktualisiert (SCC1). Entwickler/Modulbetreuer habenim Testsystem sehr weitreichende Berechtigungen. Einschränkungen müssen individuell festgelegtwerden, 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-Systemvorgenommen.

8.1.3 Qualitätssicherungssystem

Im QA-System herrscht absolutes Customizing- und Entwicklungsverbot. Customizing- undWorkbench-Objekte werden ausschließlich per TA importiert. Importe nach Produktion erfolgengrundsä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 demProduktionssystem kopiert. Damit wird auch die Übereinstimmung mit der operativen (Daten-)Umgebung sichergestellt. Im QA-System erfolgt die Durchführung von Testplänen nach Ände-rungen und Neuentwicklungen. Entwickler/Modulbetreuer haben im QA-System sehr weit-

reichende Berechtigungen. Einschränkungen müssen individuell festgelegt werden, z.B. fürbesonders sensible Daten (HR etc.). Es empfiehlt sich aber auch, Testbenutzer mit produktions-nahen Berechtigungen zu verwenden.

8 INFRASTRUKTUR UND LIFECYCLE MANAGEMENT



47

8.1.4 Produktion

Im Produktionssystem herrscht absolutes Customizing- und Entwicklungsverbot. Customizing-und Workbench-Objekte werden ausschließlich per Transportauftrag in dieses System importiert.

Entwickler/Modulbetreuer haben im Produktionssystem nur eingeschränkte Berechtigungen;Emergency-Tabellenänderungen (&SAP_EDIT) sind zu dokumentieren mit Datum/Uhrzeit undBegründung. Hierzu empfiehlt sich die Verwendung eines Tools, um die Meldungen zu standardi-sieren. Der Umgang mit Notfall-Usern muss technisch und organisatorisch festgelegt werden.

8.1.5 Transportwesen

Wir empfehlen, die technische Freigabe von Transporten grundsätzlich durch interne, verantwort-liche Bearbeiter durchführen zu lassen, nicht von externen Beratern. Hierbei ist generell die

formale Freigabe vorausgesetzt (siehe Change-Verfahren). Importe werden generell zentral von derSAP-Basis durchgeführt, ausgenommen die Mandantenkopie innerhalb des Test-/Entwicklungs-systems.

Der Transportweg ist wie folgt festgelegt:Entwicklung -> QA -> Produktion

Die Sandbox sollte aus dem Transportweg ausgeschlossen werden. Importe in die Sandboxerfolgen 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 dieMitarbeiter der Basisabteilung zu entlasten.

Importe in das Produktivsystem sind explizit unter Angabe der TA-Nr. freizugeben. Hierfür wirdebenfalls 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 Programmedes Transportauftrags durchgeführt: Die Ergebnisliste darf dabei keine Fehler oderWarnungen 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


2 0 1 3 , © D

S A G e . V .



48

6. Abhängigkeiten in den Transporten? Falls ein Vorabtransport durchgeführt wurde, muss aufAbhängigkeiten in den Transporten geprüft werden

7. Namenskonventionen? Erstellen einer Liste der Transportobjekte und Prüfung der Einhaltungder Namenskonvention anhand der Objektliste

8. Dokumentation (systemintern)? a. Systemintern: Prüfung aller Objekte hinsichtlich erstellter/aktualisierter SAP-Dokumen-

ta-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.6 Rückbau von Neuentwicklungen

Wenn Entwicklungen im Entwicklungssystem erstellt, aber nicht weitertransportiert worden sindbzw. nur ins QS-System importiert wurden, sind die Änderungen im Entwicklungssystem zurück-zubauen. Im Falle der Nutzung von Quality Assurance (QA) als Genehmigungsworkflow gilt:

> Die Ablehnung verhindert lediglich den Weitertransport ins Produktionssystem. Die abgelehnteEntwicklung/Customizing ist aber im Entwicklungs- und im Qualitätssicherungssystem nochvorhanden. Daraus ergibt sich ein „Schiefstand“ zwischen den Einstellungen einerseits desEntwicklungs-/Qualitätssicherungssystems sowie andererseits des Produktionssystems.

> Um den Schiefstand zu beseitigen, muss die abgelehnte Entwicklung im Entwicklungssystemzurückgenommen, dort in einen Transportauftrag aufgenommen und ins Qualitätssystemtransportiert werden.

> Der Transportauftrag, der die Rücknahme enthält, soll im Qualitätssystem ebenfalls abgelehntwerden. Damit wird die Übereinstimmung der Einstellungen zwischen den Systemen wieder-hergestellt.

> Die zuständigen Entwickler müssen von abgelehnten Transporten erfahren. Die Pflicht zurInformationsweitergabe soll bei den für die QA-Genehmigungen zuständigen Personen liegen.

8.1.7 Sicherstellung der Konsistenz von Neuentwicklungen/Erweiterungen

Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. Es kann zur über-schneidenden Verwendung von Objekten kommen, die es im Zielsystem (noch) nicht gibt. Dies führtzum 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ürein Projekt auf je 1 TA für Workbench, Customizing und Berechtigungsrollen einzuschränken.




49

‚Vorabtransporte’ sollten nur mit Hilfe von „Kopientransporten“ erlaubt sein.Die endgültige Freigabe und der Transport erfolgt erst zum Projektabschluss. Alle Projektmitarbeiterverwenden 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 einenProcess Owner, QS o.ä. Instanzen. Die Abfolge sowie die beteiligten Bereiche müssen unterneh-mensspezifisch festgelegt werden.

8.2 CHANGE MANAGEMENT

Um eine SAP-Systemlandschaft wartbar und beherrschbar zu gestalten, ist ein formales Change-Verfahren die Voraussetzung für jede Systemänderung. Dabei ist das grundsätzliche Verfahrenunabhä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 InformationTechnology Infrastructure Library (ITIL). In diesem Referenzleitfaden sind umfangreiche undallgemeingültige Best Practices beschrieben.

In diesem Kapitel stellen wir einen konkret realisierten Praxisfall aus der Entwicklung dar, derfirmen- 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. Dabeigilt jedoch: Eine papierbasierte Lösung ist besser als keine!


2 0 1 3 , © D

S A G e . V .



50

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 zurAbwicklung einer Systemänderung erforderlich sind.

Basisprozess und Rollen:

> der Anforderer füllt den Teil ‚Anfordernde Abteilung’ aus und sorgt für die Unterschrift desProcess Owners/des Process Owners fremd

> der Process Owner ist in der Regel ein Vorgesetzter des Anforderers, er ist verantwortlich füreinen 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 Teilebetrifft, die außerhalb der eigentlichen Zuständigkeit des Process Owners liegen




51

Beispiel: Der Einkäufer benötigt Berechtigungen aus dem Bereich der Anlagenbuchhaltung; hiermuss der Process Owner zustimmen, der diesen Teil des Systems verantwortet (z.B. der Leiterder 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 vonSAP 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 dieApplikation/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 vergibteine eindeutige CC-Nummer und den CC-Titel; die Nummer kann z.B. auch von einemProjektverfolgungs-/-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ändiggenehmigtes 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 Transportfrei; 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 darfnicht ohne vorangegangene Freigabe durch die SAP-Koordination und die IT-Leitung durchge-führt werden.

> Der Bearbeiter übergibt den Transport in das Produktionssystem und leitet das CC an die SAP-Koordination und die IT-Leitung weiter.

Der Genehmigungs- und Freigabeprozess und damit auch der Inhalt des Formulars kann branchen-spezifisch stark variieren. In pharmazeutischen Unternehmen ist beispielsweise grundsätzlich dieQA in das CC-Verfahren eingebunden. Darüber hinaus ist es in allen Unternehmen üblich, dass beiÜberschreiten bestimmter (geschätzter) Projektkostenlimits weitere Genehmiger der Umsetzungeiner Änderungsanforderung zustimmen müssen. Die Genehmigungsstruktur hängt also imWesentlichen von der jeweiligen Unternehmensorganisation ab.

Das Formular enthält daher lediglich die Minimalanforderungen an ein CC ohne Berücksichtigungbranchen- oder organisationsspezifischer Anforderungen.


2 0 1 3 , © D

S A G e . V .



52

Weitere Genehmigungs- oder Freigabeschritte, aber auch zusätzliche Felder mit Bezug zu anderenDokumenten (z.B. Validierungsdokumente) sind bei Bedarf individuell zu ergänzen und der Prozessentsprechend zu erweitern.

WEITERE QUELLEN:

1. Mathias Friedrich, Torsten Sternberg, Change Request Management mit dem SAP SolutionManager, SAP Press, 2009

2. Information Technology Infrastructure Library (ITIL)

8.3 SOFTWAREWARTBARKEIT

Die Wartbarkeit von Software ist ein Kriterium bei der Entwicklung von Software und zeigt an, mitwelcher Energie und mit welchem Aufwand Änderungen in einem Systemzusammenhang vonApplikationen durchgeführt werden können. (Quelle: Wikipedia)

Technisch ist ein modularer Aufbau von Objekten entsprechend SAP-Praxis, d.h. Include-Strukturin allen Programmen erforderlich. Dies umfasst auch die Verwendung von Funktionsbibliotheken,die auch anderen Entwicklern zugänglich sein müssen und von ihnen leicht aufgefunden werdenkönnen.

In Systemumgebungen mit verschiedenen Entwicklungs- und Produktionssystemen (Transport-strecken) muss der Grundsatz gelten: gleicher Objektname (T-Code, Programm, Include, Tabelleetc.) bedeutet auch identische Funktionalität.

Unterschiedliche Funktionalität bedingt entweder ein eigenes Objekt oder – falls möglich – eineentsprechende Customizing-Funktion.

Alle Entwicklungen/Änderungen/Korrekturen sind sauber zu dokumentieren.

8.4 ANPASSUNGEN DER SAP-FUNKTIONALITÄT

Um die Funktionalität eines SAP-Systems an eigene Bedürfnisse anzupassen, gibt es verschiedeneMö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 Schnittstellealle nötigen Daten zur Verfügung stellt. Hier eine kurze Beschreibung dieser Techniken:




53

User-Exit

User-Exits sind Unterprogramme, die sich in Includes im SAP-Namensraum befinden, aber nureinmalig 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 imple-mentiert 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 vergleich-bar 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


2 0 1 3 , © D

S A G e . V .



54

Hinweis: Implementierungen von Enhancement Sections können durch das Einspielen von SAPEnhancement Packages oder das Aktivieren von Business Functions durch neue aktive Implemen-tierungen 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 notwendigenTestaufwand (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 inder regulären SPAU-Transaktion nicht angezeigt werden. Die Entscheidung, ob Enhancements als Erweiterungskonzept genutzt werden sollen, ist also nichtnur 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 Genehmi-gungsverfahren empfohlen. Hierzu gehören Antrag -> Begründung -> Genehmigung. DieEntscheidung muss von dem/den jeweiligen Systemverantwortlichen (IT-Leitung) getroffen werden.Vorteil hierbei ist, dass der Entwickler einen Modifikationsschlüssel eingeben und dieser zentralvergeben werden kann. Es kann also relativ einfach verhindert werden, dass ungewollte Modifika-tionen ins System eingebaut werden.

Kopien in eigenen Namensraum/Z-Namensraum

Kopien von SAP-Standardcode in den Kundennamensraum sind sehr pflegeaufwändig. Bislang gibtes 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. Eineallgemeine 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ücksichtigtan 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önnenverwendete Standard-Includes zu Problemen führen.




55

> Die Entscheidung Modifikation vs. Z-Kopie vs. Enhancement ist also nicht nur abhängig vomRealisierungsaufwand, 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 Fallmit sich bringt.

> Es wird empfohlen, eine zentrale, formalisierte, technische Dokumentation aller Modifikationeneinzurichten. Für Kopien und Erweiterungen sollten geeignete Templates bereitgestellt und essollte eine Pflicht zu deren Verwendung bestehen.

WEITERE QUELLEN: SAP Schulungen BC425 und BC427

8.5 TESTBARKEIT VON ANWENDUNGEN

Um die Testbarkeit von Anwendungen zu gewährleisten, müssen die Testanforderungen zu einemsehr frühen Zeitpunkt in der Entwicklung festgelegt werden. Gewachsenes Coding nachträglichtestbar zu machen, ist meistens mit sehr hohem Aufwand verbunden, der keine neue Funktionali-tät bietet und daher in der Praxis sehr niedrig priorisiert wird.

Um wirtschaftlich sinnvoll mit Tests umzugehen, müssen Tests automatisiert werden. Dazu ist esnotwendig, die Durchführung von Tests wiederholbar zu machen. Versuchen Sie, den Code so zu

schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werdenkann. Das bedeutet, insbesondere auf dynamische Anweisungen zu verzichten, da deren seman-tische Bedeutung erst zur Laufzeit bekannt ist und von einem statischen Tool nicht hinreichendanalysiert werden kann.

BEST PRACTICE: Verwenden Sie von Anfang an automatisierte Tests (ABAP Unit, eCATT), um dieAutomatisierung von Tests zu einem „normalen“ Bestandteil der Entwicklung zu machen.

BEST PRACTICE: SAP unterstützt mit der Test-Workbench testgetriebene Entwicklungen durchModultests. 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 undSystemeinstellungen verhindern gegebenenfalls, dass ein Systemtest einer höheren Risikostufeausgeführt wird. Im ABAP-Umfeld ist in vielen Fällen die gelungene Integration der Datenbank ein Hindernis, wennes um die Erstellung von wiederholbaren, automatisierten Tests geht. Im Vorfeld des Tests müssendie betroffenen Einträge auf der DB in die Form gebracht werden, die für die jeweilige Testausfüh-rung erwartet wird, und Änderungen an der DB durch die Testausführung müssen wieder beseitigt

werden, um andere Tests nicht zu behindern.


2 0 1 3 , © D

S A G e . V .



56

BEST PRACTICE: Trennen Sie in Ihren Anwendungen die direkte Interaktion mit der DB undentfernten Systemen, deren Laufzeitverhalten nicht kontrolliert werden kann, von dem eigentlichenAnwendungskern. Wenn dieser Anwendungskern nicht mehr direkt mit der DB und den entferntenSysteme kommuniziert, bieten die dafür benötigten Schnittstellen die Möglichkeit, für dieDurchfü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 zuarbeiten, die bei jeder Testausführung in einem konsistenten und bekannten Zustand sind.

WEITERE LINKS:www.testbarkeit.dehttp://de.wikipedia.org/wiki/Testbarkeit

http://www.testbarkeit.de/Publikationen/TAE05_Artikel_jungmayr.pdf


http://www.testbarkeit.de/

http://de.wikipedia.org/wiki/Testbarkeit



http://de.wikipedia.org/wiki/Testbarkeit

http://www.testbarkeit.de/



57

Die folgenden Autoren waren maßgeblich an der Erstellung der vorliegenden Fassung desLeitfadens beteiligt:

Peter Lintner, Senior Consultant, Allgemeines Rechenzentrum GmbH

Herr Lintner ist zertifizierter Projektmanager (IPMA-Level C) und seit 1998 im Bereich SAP ABAPEntwicklung tätig. Seine Schwerpunkte liegen in den Bereichen Applikations- und WorkFlow-Ent-wicklung, Change- und Requestmanagement.

Steffen Pietsch, Vice President, IBSolution GmbH

Herr Pietsch ist seit 2003 im entwicklungsnahen Umfeld tätig und konnte Erfahrungen alsEntwickler sowie in verschiedenen leitenden Positionen im Entwicklungsumfeld sammeln. Seit2009 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 indiesen Rollen tiefgreifende Erfahrungen in komplexen SAP-ERP-Implementierungen sammeln.Seit 2012 steuert er als IT-Koordinator im EWE-Konzern die Entwicklungstätigkeiten ausgewählterAnwendungen. Daneben arbeitet er als stellvertretender Sprecher des DSAG-Arbeitskreises SAPNetWeaver 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 imBereich 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 SchwerpunktenSAP Basis, Logistik und Programmierung (ABAP und Assembler). Seit 1999 ist er als SAP R/3Anwendungsberater für die Module MM, WM und PM tätig und führt ABAP-Entwicklung von ADDONs, 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 „SichereABAP-Programmierung“ (SAP Press) und hält regelmäßig Vorträge zum Thema SAP/ABAPSicherheit und Compliance auf internationalen Konferenzen, wie z.B. RSA, Black-Hat, Hack In TheBox, 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 konstruktivenVorschlägen und Reviews die Arbeit an diesem Dokument unterstützt haben.

9 DIE AUTOREN


2 0 1 3 , © D

S A G e . V .



59

die Art(A) des Includes angegeben:

> TOP Top Include> PBO Process Before Output Include> PAI Process After Input Include> FORMS Include für Unterprogramme> CLASS Include für lokale Klassen

** Die Verwendung des WebDynpro Editors (z.B. in der se80) führt zur automatischen Erzeugungvon Quellcode. Dies macht die Umsetzbarkeit eigener Namenkonventionen im Einzelfall schwer.

Data-Dictionary-Objekte

Typ Konvention BeispielTabellen Ymmuu…(t) YPPORDER

Views Ymmuu…_V YPPORDER_V

Tabellentypen Ymmuu…_TT YCADOCUMENT_TT

Struktur Ymmuu…_S YCADOCUMENT_S

Datenelement und

Domäne

Ymmuu… YCAFTDATUV

Suchhilfe Ymmuu…. YPPPROJE

Sperrobjekte EY_<Tabelle> EY_YSDMINFO

Typgruppen Ymmcc YCA02

Klassen & Interfaces

Typ Konvention Beispiel

Klassen YCL_mm_... YCL_SD_FAKTURA

Interfaces YIF_mm.. YIF_SD_BOOKING

10.2 ATTRIBUTE

Lokale Variablen und Attribute einer Klasse sollten im Normalfall als private deklariert werden.Der Zugriff auf die Attribute sollte über get- und set-Methoden erfolgen.

LV_... Attribut Variable (local value …)

LS_... Attribut Struktur (local structure …)

LT_... Attribut Tabelle (local table…)


2 0 1 3 , © D

S A G e . V .



60

10.3 METHODEN

Methoden sollten einen kurzen, sprechenden, englischen Namen besitzen. Folgende Präfixe

deuten auf die Aufgabe der Methode:

set_... Setzen von Werten

get_... Laden von Werten

send_... Senden von Informationen

save_... Sichern der Daten auf die Datenbank

etc.

Die genaue Funktion sollte in der Beschreibung der Methode stehen. Reicht der Platz (60 Zeichen)nicht aus, so sollte die ausführliche Dokumentation der Methode in der Klassendokumentationerfolgen.

10.4 SIGNATUR VON METHODEN

Die Parameter einer Methode werden wie folgt bezeichnet.

Nr. Parameterart Präfix

0 Importing I_...

1 Exporting E_...

2 Changing C_...

3 Returning R_...

10.5 FUNKTIONSGRUPPEN UND -BAUSTEINE

Typ Konvention BeispielFunktionsgruppen Ymm_ccc_… YCA_KONFIGURATION

Funktionsbausteine Ymm_... YSD_FAKTURA_ZU_WE

Die Schnittstellen von Funktionsbausteinen orientieren sich an denen der objektorientiertenProgrammierung (vgl. 10.4).

BEST PRACTICE: Tabellen können auch als Import, Export oder Changing Parameter übergebenwerden, sodass stets Klarheit herrscht, welche Tabellen im Funktionsbaustein geändert werdenund welche nicht. Des Weiteren stellt der Syntax-Check im ABAP sicher, dass Importparameter

nicht verändert werden dürfen.

10 ANHANG: NAMENSKONVENTIONEN



61

10.6 ENHANCEMENTS


Enhancement

Spot

YES_... YES_MV45A

Enhancement

Definition

YED_... YED_ MV45A

Enhancement

Implementation

YEI_... YEI_ MV45A

10.7 FORMULARE


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.8 JOBS


Jobs YMM_<Prio>_<BUKRS>_<DESC> YSD_1_1000_

<Prio> = Priorität, einstellige Zahl, <BUKRS> = Buchungskreis


2 0 1 3 , © D

S A G e . V .



62

10.9 DATENELEMENTE

Datentyp Präfixbestandteil

Elementare Typen / Variablen v

Strukturen s

Tabellen t

Datenreferenz r

Klassenreferenz o

Interfacereferenz i

BADI-Referenz b

Ausnahmeklasse-Referenz x

Diese Präfixbestandteile bilden die typenabhängigen Anteile der im Folgenden aufgeführten,kontextabhängigen Präfixe. [t] ist hierbei jeweils durch den passenden typenabhängigen Präfixbe-standteil 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

c[t]_* für Changing l[t]_*

t[t]_* für Tables g[t]_*

Tabellentyp tt_*

Strukturtyp t_*

10 ANHANG: NAMENSKONVENTIONEN



63

Objektorientierte Programmierung:

Entität Namenskonvention

Lokale Klasse lcl_*

Globale Klasse cl_*

Lokales Interface lif_*

Globales Interface if_*

Instanzattribut m[t]_*

Statisches Attribut g[t]_*

Konstanten c[t]_*

Methodenparameter i[t]_* für Importing

e[t]_* für Exporting p_

c[t]_* für Changing i[t]_* für Importing

r[t]_* für Returning s[t]_*

Ereignisparameter i[t]_* B E S T P R A C T I C E L E I T F A D E N D E V E L O P M E N T , 3 1 . J A N U A R

2 0 1 3 , © D

S A G e . V .

dsag - best practice leitfaden development

Documents