Best Practice Leitfaden Development - Über DSAG

64
DSAG-ARBEITSKREIS SAP NETWEAVER DEVELOPMENT STAND 31. JANUAR 2013 Deutschsprachige SAP-Anwendergruppe e.V. Best Practice Leitfaden Development Praxistipps rund um das Thema ABAP Development

Transcript of Best Practice Leitfaden Development - Über DSAG

Page 1: Best Practice Leitfaden Development - Über DSAG

DSAG-ArbeitSkreiS SAP NetWeAver DeveloPmeNt StAND 31. JANuAr 2013

Deutschsprachige SAP-Anwendergruppe e.v.

Best Practice Leitfaden DevelopmentPraxistipps rund um das Thema ABAP Development

Page 2: Best Practice Leitfaden Development - Über DSAG

2

Version 0.11stand 31. Januar 2013

dsaG e. V.deutschsprachige saP-anwendergruppe

Best Practice Leitfaden developmentPraxistipps rund um das thema aBaP development

Page 3: Best Practice Leitfaden Development - Über DSAG

3

autoren

> Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH > steffen Pietsch, Vice President, iBsolution GmbH > Markus theilen, it-Koordinator, eWe aG > Jürgen Wachter, Process Coordinator development, comgroup GmbH > Michael Werner, saP anwendungsberater (inhouse), Lts aG andernach > andreas Wiegenstein, Managing director und Chief technology officer (Cto), Virtual Forge GmbH

Weitere informationen zu den autoren finden sie auf seite 57.

© CoPyriGHt 2013 dsaG e.V.

HinWeis:die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). alle rechte liegen, soweit nicht ausdrücklich anders gekennzeichnet bei:

deutsCHsPraCHiGe saP® anWenderGruPPe e.V.altrottstraße 34 a69190 Walldorfdeutschland

tel.: 06227 - 35809 58Fax: 06227 - 35809 59e-Mail: [email protected]: www.dsag.de

Jedwede unerlaubte Verwendung ist nicht gestattet. dies gilt insbesondere für die Vervielfältigung, Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen systemen / digitalen Medien.

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 4: Best Practice Leitfaden Development - Über DSAG

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

Page 5: Best Practice Leitfaden Development - Über DSAG

5

4.4.1 unvollständige Fallunterscheidungen 26

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

4.5 Weiterführende Quellen 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

5.5 Weiterführende Quellen 33

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

inHaLtsVerzeiCHnis

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 6: Best Practice Leitfaden Development - Über DSAG

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

Page 7: Best Practice Leitfaden Development - Über DSAG

7

inHaLtsVerzeiCHnis 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 wandelnde Kundenbedürfnisse. das hohe Maß an Flexibilität und erweiterbarkeit von saP-software bringt Vor- und nachteile mit sich: die software kann optimal an kundenspezifische anforderungen angepasst und damit die Wert-schöpfung durch den einsatz deutlich gesteigert werden. zeitgleich birgt die erweiterbarkeit das risiko kundenspezifischer entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind.

das ziel dieses dokuments ist es, Praxistipps und denkanstöße zu liefern, um kundenspezifische entwicklungen wartbar und effizient zu gestalten.

1.1 MotiVation

die arbeit der deutschsprachigen saP-anwendergruppe e.V. (dsaG) fußt auf drei säulen – Wissens- vorsprung, einflussnahme und netzwerk. das vorliegende dokument wurde von Mitgliedern des dsaG-arbeitskreises saP netWeaver development initiiert und adressiert die erste säule und damit den Wissensvorsprung für anwender und Partner.

als autorenteam ist es unser anliegen, das in den unternehmen verteilt und implizit vorliegende Wissen zum thema entwicklung in einem kompakten dokument anderen dsaG-Mitgliedern zur Verfügung zu stellen. unser Wunsch ist, dass dieses dokument „lebt“ und mit ihrem erfahrungs-schatz einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf ihr Feedback (am besten per 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 auch autoren der saP mit dem Buch „aBaP-Programmierrichtlinien“, saP Press 2009 bereits einen Vorstoß in richtung von empfehlungen unternommen, die über reine Beschreibungen der sprache aBaP und der zugehörigen Werkzeuge hinausgehen.

der Mehrwert dieses dokuments liegt in der zusammenfassung bewährter Vorgehensweisen, Praxistipps und erprobter regelwerke aus den anwenderunternehmen. diese Guideline soll ihnen als anwender, entwickler, entwicklungs-, Projekt- oder it-Leiter anregungen und Hilfestellung geben, um „das rad nicht immer wieder neu erfinden zu müssen“, sondern auf die erfahrungen anderer aufbauen zu können. dabei erheben die in dieser Guideline vorgestellten empfehlungen nicht den anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eine auswahl von Praxistipps dar.

als autorenteam haben wir uns darum bemüht, im spannungsfeld zwischen Überblickswissen und detailtiefe den richtigen Mix zu finden. daher verweisen wir an entsprechenden stellen auf weiter- führende Quellen, um nicht ausführlich diskutierte themen redundant wiederzugeben. die erste auf- lage dieser Guideline ist auf den Bereich aBaP-entwicklung fokussiert. Bei entsprechendem Feedback und ihrer aktiven unterstützung kann der Fokus auf die JaVa-entwicklung und weitere themen ausgeweitet werden.

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 8: Best Practice Leitfaden Development - Über DSAG

8

dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für anwendungen, die mit 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 externe Personen effizient an der (Weiter-) entwicklung und Wartung eines Programms zusammenarbeiten.

2.1 naMensKonVention

namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung von softwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur Benennung von objekten im Quellcode (z.B. Variablen).

Wir empfehlen ausdrücklich eine namenskonvention als richtlinie für entwicklungen im saP- system vorzugeben. das ziel der Verwendung einer einheitlichen namenskonvention ist die deutliche steigerung der Wartbarkeit kundenspezifischer anpassungen und erweiterungen. in der Konsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnelleren Problemlösung im Fehlerfall.

die explizit formulierte namenskonvention sollte Bestandteil der internen ausbildung sein, um neue Mitarbeiter mit den Grundregeln und unternehmensspezifika vertraut zu machen. zudem hat es sich bewährt, diese namenskonvention zum Vertragsgegenstand für externe entwickler und Partnerunternehmen zu machen. automatisierte Überprüfungen stellen die einhaltung sicher (vgl. Kapitel 7).

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

2.2 naMensrauM

die trennung von Kundenobjekten und saP-objekten kann über die Präfixe y oder z sowie über einen eigenen namensraum erfolgen. die syntax lautet wie folgt:

z…y…/<kundeneigener namensraum>/…

der kundeneigene namensraum kann bei saP registriert werden und ist nach Bestätigung weltweit eindeutig und für das jeweilige unternehmen zur Verwendung registriert. dieses Vorgehen unterstützt bei der konfliktfreien Vergabe von namen für softwareobjekte. der Vorteil des kundeneigenen namensraums liegt in der garantierten Überschneidungsfreiheit beim import fremder objekte in das eigene saP-system (z.B. beim einsatz von Fremdanwen-dungen, die per transportauftrag eingespielt werden) und bei zusammenführungen von saP systemen im rahmen einer Post-Merger integration. durch die reservierung des namensraums ist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten system ein softwareobjekt mit dem gleichen Präfix erstellt werden kann. der nachteil bei der Verwendung des kundeneigenen namensraums liegt darin, dass durch die durchgängige Verwendung des Präfixes bereits mehrere zeichen „verbraucht“ werden. dies kann insbesondere bei objekten, die nur wenige zeichen zur Benennung bieten, zu schwierigkeiten führen. darüber hinaus unterstützen nicht alle objekttypen, z.B. Berechtigungsobjekte, die Verwendung von namensräumen.

2 ProGraMMierriCHtLinien

Page 9: Best Practice Leitfaden Development - Über DSAG

9

2 ProGraMMierriCHtLinien

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 in Quellcode. als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zu halten, kann der Pretty Printer aus der aBaP-entwicklungsumgebung genutzt werden. Mit einem einzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. er bietet verschiedene Möglichkeiten, die über die einstellungen der Workbench konfigurierbar sind. Bereits eine eingerückte darstellung macht source Code deutlich lesbarer. es wird empfohlen, schlüsselwörter groß darzustellen. denn dadurch kann man Quelltext auch in ausgedruckter Form und ohne syntaxeinfärbung noch leicht verstehen. der Pretty Printer ermöglicht auf einfachem Weg die erstellung von einheitlichem Quellcode trotz unterschiedlicher entwickler.

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

Wir empfehlen, die option „standardkommentare einfügen“ zu deaktivieren, da die erzeugten Kommentare bei Änderungen nicht automatisch angepasst werden und redundante informationen enthalten.

BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die einstellungen als einheitliche Vorgabe zu definieren.

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

eine Modularisierungseinheit (Form-routine, Methode, Funktionsbaustein) soll logisch zusam-mengehörende anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigen anweisungen sind jedoch zu vermeiden.

die Modularisierung dient dazu, trotz Komplexität in der aufgabenstellung, den Programmcode übersichtlich zu gestalten. zudem sind Programmabschnitte mit derselben Logik zu vermeiden.Für die praktische umsetzung kann es hilfreich sein, vor Beginn des Programmierens die ersten Codezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend 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 zu kapseln. insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden.

im rahmen der einführung von aBaP objects fand eine Bereinigung der sprache und Vereinheitli-chung der Konstrukte statt. die Verwendung von aBaP objects führt damit zu einer steigerung der Wartbarkeit.

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 10: Best Practice Leitfaden Development - Über DSAG

10

trennung von Präsentations- und anwendungslogikin allen Programmen sollte stets eine trennung von Präsentations- und anwendungslogik erfolgen. dies erlaubt es, ergebnisse und Funktionen der anwendungslogik durch verschiedene uis (user interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche schnittstelle anderen systemen bereitzustellen. diese aussage ist für alle gängigen ui-technologien gültig, wobei der Grad der unterstützung bzw. einhaltung dieser logischen trennung unterschiedlich ist. in einer Webdynpro aBaP-realisierung ist schon vom Framework eine trennung zwischen Modell- und ui-Logik vorgesehen. Bei klassischen dynpros und BsPs wird die trennung nicht in gleicher Weise forciert, aber grundsätzlich kann und sollte die trennung auch in diesen umgebungen umgesetzt werden. allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu Webdynpro, wo entsprechende Prüfungen im Code inspector realisiert sind.

ein typisches Beispiel für eine klare trennung von anwendungslogik und ui sind 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 neu entwickelt werden. um dies zu vermeiden, müssen die Funktionen zur Prüfung von eingaben oder Parametern unabhängig von der verwendeten ui erstellt und gepflegt werden.

internationalisierungsprachabhängige texte in Programmen dürfen nicht „hart codiert“ werden, sondern müssen in textelementen (Programmtexte, Klassentexte, online-text-repository [otr]), standardtexten oder nachrichtenklassen hinterlegt werden. da alle eigenentwicklungen den anspruch haben sollten, weltweit eingesetzt zu werden, sollten die wichtigsten sprachen übersetzt werden. zudem müssen sprachabhängige (customizebare) texte in eigenen texttabellen abgelegt werden. diese texttabelle besitzt dieselben schlüsselattribute wie die eigentliche Customizing-tabelle. zusätzlich muss das erste schlüsselattribut nach dem Mandantenfeld das sprachenattribut sein (datenelement sPrsL oder sPras). zudem muss die Fremdschlüsselbeziehung als jene der texttabelle gekennzeichnet werden.

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

BEST PRACTICE: um spätere Übersetzungen einfach zu gestalten, sollte die Länge der 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 zur designzeit definiert und im saP-system statisch hinterlegt. zur Laufzeit wird der vorgegebene Programmcode ausgeführt. im Gegensatz dazu ermöglicht die dynamische Programmierung die Flexibilisierung des Quellcodes. Folgendes Beispiel verdeutlicht die dynamische Programmierung:

im Programmcode wird der name einer aufzurufenden aBaP-Klasse nicht statisch hinterlegt, sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren name durch den inhalt einer Variablen definiert ist. dieser name kann z.B. aufgrund von Benutzereingaben variieren. der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität. der nachteil liegt in der signifikant steigenden Komplexität und insbesondere in den damit einhergehenden sicherheitsrisiken.

2 ProGraMMierriCHtLinien

Page 11: Best Practice Leitfaden Development - Über DSAG

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 einer Customizing-tabelle der name der zu verwendenden konkreten Klassenimplementierung gelesen und diese aufgerufen. somit können unterschiedliche implementierungsvarianten per Customizing aktiviert/deaktiviert werden.

> Beispiel 2: dynamische WHere-Bedingung

zur Laufzeit wird die WHere-Bedingung für eine datenbankoperation, z.B. seLeCt, in einer string-Variablen erstellt. dadurch können komplizierte Case-abfragen vermieden werden, die abhängig von den eingaben verschiedene osQL-Befehle ausführen.

nachteil:

> durch die nutzung von dynamischen aufrufen geht der Verwendungsnachweis innerhalb der aBaP- entwicklungsumgebung verloren. Problematisch sind dann Änderungen an den aufrufzielen. ein entwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der von einem Programm dynamisch aufgerufen wird, bemerkt diese Verwendung über den Verwendungs- nachweis nicht.

> Bei der dynamischen Programmierung ist i.d.r. zur designzeit keine syntaktische Prüfung möglich; bei fehlerhafter Belegung der variablen inhalte (z.B. fehlerhafte Klammerung innerhalb einer dynamischen WHere-Klausel, fehlerhafter name einer Klasse) kommt es zu einem ungeplanten abbruch des Programms (Kurzdump).

> dynamische Programmierung birgt hohe sicherheitsrisiken, insbesondere dann, wenn die dynamischen inhalte durch ungeschützten zugriff beeinflussbar sind (z.B. wenn der name einer aufzurufenden Klasse /eines Funktionsbausteins oder einer WHere-Bedingung durch Benutzereingaben beein- flusst werden kann, stichwort: Code injection).

BEST PRACTICE: dynamische Programmierung sollte nur sehr dosiert und kontrolliert zum einsatz kommen. Programmcode, der dynamische anteile enthält, sollte nach dem Vier-augen-Prinzip kontrolliert und dokumentiert werden, denn er stellt ein potenzielles sicherheitsrisiko dar.

im Kapitel 5.2 wird das thema dynamische Programmierung auch im Kontext sicherheit behandelt.

2 ProGraMMierriCHtLinien

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 12: Best Practice Leitfaden Development - Über DSAG

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 behindern oder gar gezielt dafür verwendet werden könnten, Hintertüren in ein system zu schleusen. Verschleierter Code kann auch mit dem debugger nicht mehr untersucht werden. es wird an dieser stelle explizit darauf verzichtet, die techniken zu erläutern, mit denen Code versteckt werden kann.

BEST PRACTICE: Verwenden sie insbesondere in der entwicklung im eigenen unternehmen keine techniken, um ihren Quellcode zu verstecken.

2.4 oBsoLete anWeisunGen

obwohl saP eine strikte abwärtskompatibilität vertritt, muss bei der Verwendung von obsoleten anweisungen, wie z.B. Kopfzeilen in internen tabellen, berücksichtigt werden, dass hierbei Probleme auftreten, wenn der Code in Klassen übernommen werden soll. Hier ist zu beachten, dass es für obsolete sprachelemente immer modernere alternativen gibt. es gibt also eigentlich außer Gewohnheit wenige Gründe für deren Verwendung, deshalb sollten sie vermieden werden.

BEST PRACTICE: Wir empfehlen den regelmäßigen einsatz eines statischen Codeanalyse-tools, um obsolete anweisungen zu entdecken. aus den saP-Bordmitteln eignet sich hierzu der Code inspector bzw. die durchführung des syntax-Checks. darüber hinaus existieren sehr gute analysewerkzeuge von drittanbietern.

2.5 syntax-CHeCK und Code insPeCtor

der syntax-Check und der Code inspector ermöglichen die Überprüfung des Programmcodes während der designzeit. Bei der Freigabe von transporten kann der Code inspector über die se03 global angeschaltet werden, um Fehler zu erkennen. Hierdurch kann auch die anzahl der transporte verringert werden, da beim erkennen von Fehlern die Freigabe noch abgebrochen werden kann. die Behebung kann dann in den bestehenden auftrag aufgenommen werden und es muss kein neuer transport erzeugt werden.

BEST PRACTICE: der Code inspector wird im saP-standard nur bei Freigabe des transportauf-trags ausgeführt. empfehlenswert ist jedenfalls die Prüfung durch den Code inspector bereits bei der Freigabe der jeweiligen transportaufgabe.

WEITERE QUELLEN:die Vorgehensweise der implementierung des dafür notwendigen Badis ist im Buch „Praxishand-buch saP Code inspector“ (saP Press) beschrieben.

2 ProGraMMierriCHtLinien

Page 13: Best Practice Leitfaden Development - Über DSAG

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 als schnelle Vorgehensweise erscheinen. auf den Gesamtlebenszyklus der anwendung bezogen, führt sie jedoch zu deutlich erhöhten Kosten. die Wartbarkeit und testbarkeit der anwendung werden langfristig deutlich erschwert.

BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler stelle definiert werden. Für die Konstantendefinition eignen sich z.B. die attribute globaler Klassen bzw. interfaces.

BEST PRACTICE: alternativ zu harten Codierungen im Quelltext können kundeneigene 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 analyse im 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, diese entweder außerhalb des systems durchsuchbar zu dokumentieren oder ein suchtool (s. „Weitere Quellen“) zur Verfügung zu stellen, mit dem innerhalb des systems nach Konstanten gesucht werden kann.

2.7 tiPPs BeiM arBeiten Mit transPorten

Wenn mehrere entwickler an einem entwicklungsobjekt Änderungen vornehmen, kann dies unter umständen zu Problemen führen, wenn die transportaufträge nicht in der richtigen reihenfolge in die produktiven systeme transportiert werden oder andere objekte aus anderen transportaufträgen fehlen.

BEST PRACTICE: um dies zu vermeiden, sollte mit transport von Kopien gearbeitet werden. dabei werden die geänderten entwicklungsobjekte durch den eigentlichen transportauftrag im entwicklungssystem gesperrt und über transport von Kopien werden nur Kopien der objekte in das Qualitätssicherungssystem transportiert. ein entwickler bemerkt sofort, dass ein anderer entwickler ggf. das objekt bereits bearbeitet, und kann sich mit dem anderen entwickler abstimmen. nach abschluss des „Projektes“ wird nur der original-sperrtransport ins Produktiv-system transportiert.

2 ProGraMMierriCHtLinien

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 14: Best Practice Leitfaden Development - Über DSAG

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 die entsprechenden saP-standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung der notwendigen rollen). Für kundeneigene datenobjekte können in der regel keine saP-standard-Berechtigungsobjekte zur Prüfung verwendet werden. zu diesem zweck können kundeneigene Berechtigungsobjekte implementiert und geprüft werden.

Weitere informationen finden sich im Kapitel 5.1.1

2.9 ProGraMMierModeLL: oBJeKtorientiert Vs. ProzeduraL

die prozedurale entwicklung in aBaP ist inzwischen von saP als obsolet eingestuft worden. insbesondere die Befehle ForM…endForM und PerForM sind als obsolete anweisungen eingestuft. Prozedurale entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globale Variablen und includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen.

objektorientierte entwicklung wurde so konzipiert, dass logisch zusammenhängende aufgaben einheitlich in objekten zusammengefasst werden können. dadurch wird unter anderem auch die Wiederverwendbarkeit von Code erhöht. insbesondere können solche objekte auch von anderen entwicklern für ihre zwecke leicht erweitert oder verändert werden, ohne dass die grundlegenden Funktionen beeinträchtigt werden (open-Close-Prinzip). andererseits können zentrale Funktionali-täten oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder schreibzugriff durch aufrufende Programme geschützt werden.

BEST PRACTICE: Wir empfehlen bei neuentwicklungen möglichst nur noch mit Klassen und Methoden zu arbeiten und keine ForMs mehr zu verwenden.

WEITERE QUELLEN:1. Horst Keller und Gerd Kluger, not yet using aBaP objects? eight reasons Why every aBaP developer should Give it a second Look, sap Professional Journal2. Horst Keller and Gerd Kluger, netWeaver development tools aBaP, saP aG 3. Bertrand Meyer, objektorientierte softwareentwicklung, Hanser 1990, isBn 3-446-15773-54. Consea-Projekt für suche nach Konstanten auf saP Code exchange: https://cw.sdn.sap.com/cw/groups/consea

2.10 Weitere QueLLen (ProGraMMierriCHtLinien / aBaP)

1. saP dokumentation saP netWeaver as aBaP release 731 http://help.sap.com/abapdocu_731/de/index.htm in dieser dokumentation ist dem thema Programmierrichtlinien ein eigenes Kapitel gewidmet.

2 ProGraMMierriCHtLinien

Page 15: Best Practice Leitfaden Development - Über DSAG

15

in den folgenden abschnitten empfehlen wir einige regeln, die bei der täglichen arbeit in der aBaP-entwicklung beachtet werden sollten, um von vorneherein Performance-engpässe zu vermeiden. Wie an viele anderen stellen der softwareentwicklung hilft es auch im Hinblick auf eine ausreichende Performance zu wissen, was gemacht werden soll. solange der sinn und zweck eines Code-stückes nicht klar ist, sollte dies zuerst geklärt werden.

3.1 VerMeidunGsPrinziP

„die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und am leichtesten zu dokumentierenden teile eines Computersystems sind die, die man weggelassen hat.“ (Gorden Bell)

BEST PRACTICE: Vermeiden sie jegliches unnötige Coding.

Frei nach diesem Motto sollten sie auch genau prüfen, welcher Code wirklich für die Produktion gedacht ist, und sämtliche test- und demo-Programme spätestens auf den Q-systemen löschen.

aber auch innerhalb von produktivem Coding sollte immer der ansatz verfolgt werden, nicht mehr zu tun, als für die aufgabe wirklich benötigt wird. ein einleuchtendes Beispiel dafür ist die regel zur Vermeidung von *-seLeCts, bei denen der einfachheit halber alle spalten einer tabelle selektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige spalten benötigt werden.

anmerkung: diese Vorgehensweise steigert gleichzeitig die robustheit von Programmen. das Lesen mit Hilfe von *-seLeCt in eine kundeneigene datenstruktur kann zu Fehlern nach einem upgrade führen,wenn die standardtabelle durch saP erweitert wurde. das explizite Lesen benötigter spalten schützt vor dieser unschärfe.

3.2 VorHandene WerKzeuGe nutzen

die im saP-system bereits vorhandenen Werkzeuge bieten gute unterstützung bei der erstellung von performanten anwendungen bzw. bei der analyse von Performance-engpässen. diese Werkzeuge sollten frühzeitig und in allen Lebensphasen der software angewendet werden.die nachfolgende tabelle bietet einen Überblick zu den zentralen Werkzeugen:

entwicklung BeschreibungCode 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 PerForManCe2 ProGraMMierriCHtLinien

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 16: Best Practice Leitfaden Development - Über DSAG

16

Laufzeit BeschreibungsM50/sM66 Übersicht Workprozesse/applikationsserver

debugger schrittweises ausführen von Coding

Memory inspector Vergleich und analyse von speicherabzügen zur ermittlung von nicht speicherverbrauch und nicht

freigegebenen Heap-objekten

st10 tabellenaufruf-statistiken zur Prüfung von tabellenpufferung

Post Mortem Beschreibungst22 analyse von Laufzeitfehlern (z.B. bei speichermangel)

stad Workload-analyse

st04 dB-Performance-Übersicht

BEST PRACTICE: starten sie die Performance-untersuchung mit einem trace in der se30/sat und konzentrieren sie sich auf den größeren zeittreiber. Wenn die meiste zeit im aBaP-teil verbraucht wird, analysieren sie weiter mit der se30/sat. Liegt die meiste zeit bei den dB-aufrufen, starten sie einen sQL-trace mit der st05.

3.3 PerForManCe-oPtiMierunGen nur an KritisCHen und reLeVanten steLLen

auch wenn man nicht performante Konstrukte bei der softwareentwicklung immer vermeiden sollte, sollte man sich gleichzeitig bei der notwendigkeit von umfangreicheren Performance-opti-mierungen auf die teile der software beschränken, die durch Messung nachgewiesenermaßen die ursache von langer Laufzeit oder erhöhtem speicherverbrauch sind. auch für Performance-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/des speicherverbrauchs verantwortlich sind. um an diese stellen zu gelangen, ist der sinnvolle einsatz der genannten Werkzeuge essenziell.

BEST PRACTICE: Wir empfehlen, die suche nach Performance-engpässen mit dem einsatz der Laufzeitanalyse se30/sat mit voller aggregation zu beginnen. dadurch sollte deutlich werden, ob die Laufzeit aus der interaktion mit der datenbank oder der Verarbeitung der geladenen daten im Hauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher datenbestand verarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen spur zu folgen. Wird mehr als die Hälfte der Laufzeit im dB-teil verbraucht, sollte eine genauere analyse der sQL-Kommandos mit der transaktion st05 erfolgen. Wird mehr Laufzeit im aBaP-teil verbraucht, erfolgen tiefergehende analysen mit Hilfe der se30/sat, wobei die aggregationsstufen schrittweise verringert werden, um genauere aussagen über die kritischen Programmstellen zu bekommen. nach jedem optimierungsschritt sollten die ergebnisse verglichen und dokumentiert werden.

3 PerForManCe

Page 17: Best Practice Leitfaden Development - Über DSAG

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 tabellen zugegriffen wird. Mit jedem index steigen die Verwaltungskosten, die bei datenänderungen anfallen.

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

> in einem index sollten nur selektive Felder aufgenommen und in der reihenfolge nach absteigender selektivität sortiert werden.

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

> Bei mandantenabhängigen tabellen sollte das Feld „Mandant“ als erstes Feld aufgenommen werden, insbesondere bei großen tabellen (>1000 einträge). auch wenn dieses Feld nicht sonderlich selektiv ist und damit der dritten regel widerspricht, wird bei jeder abfrage dieses Feld in der selektion vom saP-system mit übergeben und ausgewertet. Gerade bei tabellen mit stark unterschiedlichen eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im index negativ auswirken.

3.4.2 rahmenbedingungen bei datenbankzugriffen

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

> sind indizes in geeigneten rahmen angelegt? > s. vorheriges Kapitel (3.4.1)

> Lesen anweisungen am tabellenpuffer vorbei?

Hierbei kann die transaktion st10 verwendet werden, um die zugriffshäufigkeiten auf gepuffer- ten tabellen zu überprüfen. Mit der transaktion st05 können mit dem kombinierten sQL- und Puffer-trace zugriffe ermittelt werden, die wider erwarten den tabellenpuffer nicht verwenden. und mit Hilfe des Code inspectors lassen sich viele dieser statements bereits im Vorfeld statisch ermitteln.

> Kann ein dB-index zur sortierung auf der dB mit order By genutzt werden? im einfachsten Fall kann dafür der zusatz PriMary Key verwendet werden, wenn die sortierung nach dessen Feldern erfolgen soll. sind andere sortierungen erforderlich, kann es helfen, einen index anzulegen, der die gewünschten Felder in der korrekten reihenfolge enthält. allerdings sollten dabei die Hinweise zur anzahl von indizes pro tabelle beachtet werden. erfolgt der zugriff mit order By nur selten, lohnt es sich in der regel nicht, dafür einen eigenen index anzulegen. in diesem Fall sollte die sortierung im aBaP erfolgen, sofern dies die zu sortierende datenmenge zulässt.

3 PerForManCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 18: Best Practice Leitfaden Development - Über DSAG

18

Beispiel: die tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nach diesem datum ermittelt werden. in diesem Fall würde sich ein index über dieses Feld wahr- scheinlich rentieren, weil zum einen dieses Feld in der WHere-Bedingung enthalten ist und gleichzeitig der zusatz order By Belegdatum vom vorhandenen index profitiert.

3.4.3 datenbankzugriffe

die auf der datenbank selektierte und an die anwendungsschicht zu übergebende datenmenge sollte grundsätzlich so gering wie möglich gehalten werden. nachfolgend finden sie Hinweise, wie sie dies im konkreten Fall umsetzen können.

BEST PRACTICE:

> spaltenreduzierung: Vermeiden sie *-selektionen und benennen sie stattdessen die benötigen spaltennamen in der selektion. insbesondere das unnötige Laden von spalten des typs string ist teuer.die ergebnistabelle sollte mit der selektionsstruktur übereinstimmen, um optimale ergebnisse zu erzielen. sollten in der ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschten Felder namensgleich angelegt sein, ist auch der zusatz CorresPondinG FieLds möglich und führt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die robustheit der software erhöht.

> optimale suchabfrageVersuchen sie für die selektion von daten möglichst nur abfragen zu verwenden, die einen der vorhandenen indizes vollständig nutzen. sollte das nicht möglich sein, achten sie möglichst darauf, zumindest die ersten elemente des index zu verwenden, damit die zeilenweise suche auf eine möglichst kleine Menge von datensätzen reduziert werden kann.

> zeilenreduzierungnutzen sie die WHere-Bedingungen, indem sie die selektion beschreiben und die an das aBaP-system zu übermittelnden daten minimieren. Verwenden sie seLeCt sinGLe / uP to n roWs, wenn sie nur einzelne zeilen benötigen.

> 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. dies vermeidet unnötige zugriffe auf die tabellendaten.

> aggregateaggregate (Min, Max, …) werden immer auf dem datenbankserver ausgewertet. dadurch wird die tabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem dB-sys-tem, das in vielen installationen von sehr vielen applikationsservern angesprochen wird, sollten entwickler prüfen, welche datenmenge für das aggregat verwendet werden muss und ob es sich lohnen kann (sofern diese nicht groß ist), die daten in eine interne tabelle zu laden und das aggregat dort durchzuführen. allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem Kenntnisstand insbesondere Hana-basierte datenbankabfragen gerade bei aggregaten ihre stärken haben und damit deren einsatz für Hana explizit sinnvoll ist.

Beispiel: um den durchschnittlichen Wert über eine große anzahl (>100000) von Bestellungen zu ermitteln, ist es sinnvoll, dieses aggregat auf dem dB-system ermitteln zu lassen, um nur einen oder wenige Werte statt hunderttausender an die applikationsserver übermitteln zu lassen, um

3 PerForManCe

Page 19: Best Practice Leitfaden Development - Über DSAG

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 eines einzelnen auftrags sehr häufig und von allen vorhandenen applikationsservern ermittelt werden, ist die ermittlung im aBaP wahrscheinlich die für die Gesamtsituation günstigere Variante.

> updatesdie anweisung uPdate set ermöglicht das Übertragen von einzelnen zu ändernden Feldern (statt des gesamten datensatzes). Wenn möglich, sollte diese anweisung bevorzugt verwendet werden.

> ausführungshäufigkeit bei dB-zugriffenJede ausführung eines open sQL-statements ist mit einem gewissen overhead (Parsen, abgleich gegen statement-Puffer im dBMs usw.) verbunden. daher sollten pro statement möglichst viele der benötigten daten auf einmal übertragen werden. Werden beispielsweise die daten von 50 aufträgen benötigt, sollten diese nicht durch 50 einzelaufrufe ermittelt werden, sondern durch ein einzelnes statement, das die sog. array-zugriffe unterstützt. diese sind durch die zusätze into taBLe bei seLeCts bzw. FroM taBLe bei schreibenden zugriffen zu erkennen. Vermeiden sie auf jeden Fall open sQL-statements innerhalb von schleifen! Bei einem solchen Konstrukt fällt der overhead für diese statements bei jedem schleifendurchlauf an.

setzen sie ModiFy <dB-tabelle> nicht ein! erstens sollte innerhalb einer applikation klar sein, ob datensätze neu erstellt wurden oder vorhandene angepasst werden müssen. zweitens ist dieses statement aus Performance-Gesichtspunkten sehr kritisch: selbst mit dem zusatz FroM taBLe werden einzelne zugriffe pro zeile der internen tabelle ausgeführt und dabei wird jeweils zuerst ein uPdate versucht und im Fehlerfall ein insert nachgelegt. d.h., bei vielen neu zu erstellenden datensätzen erfolgen nicht n einzelzugriffe, sondern 2n mit n=anzahl neue datensätze in der internen tabelle.

> VieWs/JoinsGeschachtelte seLeCt-anweisungen und seLeCt-anweisungen in schleifen sollten vermieden werden. stattdessen bieten sich VieWs, Joins oder der zusatz For aLL entries an. Bei For aLL entries sollte man jedoch auf Folgendes achten:

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

b. sind in der internen tabelle einträge doppelt vorhanden, kann dies dazu führen, dass die zugehörigen datensätze auch doppelt von der datenbank geladen werden. es empfiehlt sich daher, zuvor ein deLete adJaCent duPLiCates aufzurufen.

3.5 interne taBeLLen und reFerenzen

interne tabellen stellen ein zentrales Konstrukt bei der entwicklung von anwendungen mit aBaP dar. neben datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle von Performance-Problemen. Bei kleinen datenmengen stellen dinge wie die Wahl der passenden tabellenart und eines passenden schlüssels noch kein Problem dar. Werden aber größere daten- mengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht, können vorher aus Performance-sicht unkritische stellen zu erheblichen Laufzeitverlängerungen führen.

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

3 PerForManCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 20: Best Practice Leitfaden Development - Über DSAG

20

> Wählen sie die tabellenart passend zur späteren Verwendung: > standard-tabellen eignen sich für daten, die nur selten oder gar nicht nach bestimmten Kriterien durchsucht werden müssen. Wenn keine suche erfolgen muss, lohnt es sich nicht, die Kosten für die erstellung und aktualisierung der zusätzlichen schlüsselstrukturen der anderen tabellenarten zu zahlen. Bei sehr kleinen datenmengen (<100 zeilen) kann je nach Häufigkeit der suchanfragen und Breite der tabelle ein Verzicht auf einen expliziten schlüssel geeignet sein.

> sorted-tabellen bieten sich an, wenn die daten häufig nach (teil-)schlüsseln durchsucht werden müssen, aber keine eindeutigkeit der schlüsselfelder garantiert werden kann. Gerade zugriffe, die nur mit einem ersten teil der schlüsselfelder stattfinden, können nur von dieser tabellenart unterstützt werden.

> Hashed-tabellen sind perfekt dafür geeignet, in dictionary-artigen Konstrukten nach ein- deutigen schlüsseln zu suchen. Wenn die eindeutigkeit der einträge im Hinblick auf die schlüsselfelder garantiert werden kann und die suchzugriffe immer mit dem vollständigen schlüssel (=alle Felder des schlüssels werden auf Äquivalenz gegen einen jeweiligen Wert geprüft) erfolgen, ist diese tabellenart in der regel optimal.

> Wenn für eine tabelle vom typ sorted oder Hashed zugriffe erfolgen, sollten diese immer mit dem passenden (teil-)schlüssel stattfinden.

dies bedeutet, bei read taBLe den zusatz WitH taBLe Key zu verwenden und bei LooP at WHere möglichst viele aufeinander folgende Felder des schlüssels mit „=“ zu vergleichen. dann werden die intern aufgebauten schlüsselstrukturen verwendet, um die passenden einträge schneller zu ermitteln.

> ab as aBaP 7.02 können sie bei internen tabellen, die selten geändert werden, aber mit mehr als einem zugriffmuster gelesen werden, neben dem primären schlüssel, der wie gehabt definiert und verwendet wird, auch weitere sekundäre schlüssel definieren, die auch einen vom Primärschlüssel abweichenden typ (sorted, Hashed) haben.

als Beispiel können sie damit für eine als Hashed definierte tabelle mit eindeutigem Primär- schlüssel einen weiteren schlüssel vom typ sorted definieren, der es ermöglicht, performant auf die daten der tabelle aus einem anderen Blickwinkel (nicht eindeutig, teilschlüssel möglich) zuzugreifen, ohne die eigentlichen daten zweimal im Hauptspeicher anzulegen und bei Änderungen manuell für die Konsistenz zwischen beiden tabellen zu sorgen.

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

Wenn möglich, sollten immer die Varianten mit Massenzugriffen gewählt werden, die perfor- manter arbeiten als mehrere einzelzugriffe. als Beispiel sollten sie beim anhängen von zeilen einer teilergebnistabelle zur Gesamtergebnistabelle das anweisungsmuster aPPend Lines oF to verwenden, anstatt die gleiche Funktion über eine schleife LooP at mit einzelnen aPPend to zu realisieren.

> Bei der Verwendung der anweisung sort sollten sie immer die gewünschten sortierfelder angeben. erstens erhöht dies die Lesbarkeit des Codings und zweitens ist bei den wenigsten standard- tabellentypen ein tabellenschlüssel definiert. Fehlt ein solcher schlüssel, wird die gesamte

3 PerForManCe

Page 21: Best Practice Leitfaden Development - Über DSAG

21

zeile der tabelle als schlüssel verwendet und damit bei der sortierung alle Felder der tabelle geprüft, was zu erheblichen Performance-einbußen führt. soll also z. B. ein tabelle nach den Feldern Benutzer und datum sortiert werden, verwenden sie die anweisung sort table By Benutzer datum, auch wenn die tabellenstruktur mit diesen Feldern beginnt und die reihen- folge des ergebnisses hinsichtlich der geforderten Felder gleich ist.

> Vor dem einsatz der anweisung deLete adJaCent duPLiCates sollte immer sichergestellt sein, dass die tabelle nach den gleichen Feldern sortiert ist, damit doppelte einträge auch wirklich eliminiert werden.

Wie die anweisung aussagt, werden nur benachbarte tabellenzeilen verglichen. Wie bei der sort-anweisung auch sollten immer die Felder angegeben werden, die betrachtet werden müssen. ansonsten wird auch hier die gesamte zeile feldweise verglichen, auch wenn nur zwei Felder aus fachlicher sicht dafür ausreichend sind.

> reine existenzprüfungen auf internen tabellen sollten immer mit read taBLe transPortinG no FieLds durchgeführt werden, wenn auf den daten der ermittelten zeile keine weiteren operationen stattfinden.

3.5.1 Feldsymbole

Feldsymbole bieten die Möglichkeit, auf existierende daten, z.B. zeilen von internen tabellen, zu referenzieren. das arbeiten mit referenzen ist deutlich performanter als das Kopieren der daten. daher sollten, wo möglich, Feldsymbole verwendet werden. nur bei sehr kleinen tabellen gibt es einen minimalen Vorteil in der Laufzeit zwischen den Kopierkosten bei into <Wa> und Feldsym-bolen. ansonsten sind Feldsymbole immer schneller, insbesondere dann, wenn die tabelleninhalte geändert werden sollen. Bedenken sie beim einsatz von Feldsymbolen jedoch, dass eine Änderung des Wertes eines Feldsymbols auch den Wert im referenzierten datenelement überschreibt.

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

3.5.2 Parameterübergabe

die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus technischen Gründen vorgeschrieben ist (z.B. rFC-Funktionsbausteine, returning-Parameter bei funktionalen Methoden). so werden unnötige Kopierkosten bei der Parameterübergabe gespart. dies gilt in besonderem Maße bei Parametern mit tiefen datentypen wie internen tabellen oder strings. Wenn es keine technischen erfordernisse gibt, sollten Parameter immer per referenz übergeben werden.

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

BEST PRACTICE: Verwenden sie so wenig Parameter wie möglich, die per referenz übergeben werden. nutzen sie die Wertübergabe nur an den technisch notwendigen stellen.

3.6 WeiterFÜHrende QueLLen

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

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

3 PerForManCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 22: Best Practice Leitfaden Development - Über DSAG

22

dieses Kapitel erläutert, worauf entwickler achten müssen, um robuste aBaP-Programme zu schreiben. dazu ist es zunächst erforderlich zu definieren, was ein robustes aBaP-Programm ausmacht.

unter robustheit verstehen wir die Fähigkeit eines Programms, auch unter ungünstigen umstän-den weiterzulaufen und korrekte ergebnisse zu liefern. das bedeutet insbesondere, dass Programme Fehlersituationen erkennen und in einer Weise darauf reagieren, dass die gewünschte Funktionalität nicht gefährdet wird.

4.1 FeHLerBeHandLunG

die aBaP-Laufzeit hat verschiedene Möglichkeiten, eine anwendung auf Fehlersituationen hinzuweisen. diese sind hier aufgeführt und die Best Practices jeweils erläutert.

4.1.1 sy(st)-suBrC-Prüfungen

Bei einer ganze reihe von aBaP-Befehlen setzt der saP-Kernel nach deren ausführung die globale Variable sy(st)-suBrC. in der regel wird eine erfolgreiche ausführung durch den Wert 0 angezeigt.

Bei den Befehlen CaLL FunCtion und CaLL MetHod wird sy(st)-suBrC nicht automatisch gesetzt, wenn es zu Fehlern in dem aufgerufenen Code kommt. sofern die gerufenen Module sogenannte nicht-klassenbasierte ausnahmen (non-class-based exceptions) verwenden, muss das aufrufende Programm diese in der exCePtions-sektion beim aufruf korrekt deklarieren und ihnen einen Wert ungleich 0 zuweisen, damit sy(st)-suBrC gesetzt wird.

BEST PRACTICE: setzen sie explizit den speziellen Wert otHers, da sich die Liste der ausnahmen systembedingt ändern könnte, nachdem das rufende Programm fertiggestellt wurde. der spezielle Wert otHers sollte insbesondere beim aufruf von rFC-fähigen Funktionsbausteinen verwendet werden, da es hier zu verschiedenen speziellen rFC-ausnahmen kommen kann.

die Prüfung von sy(st)-suBrC muss immer unmittelbar nach dem Befehl erfolgen, der diese globale Variable setzt. Wird die Prüfung erst später durchgeführt, kann der Wert bereits durch einen anderen aBaP-Befehl überschrieben worden sein.

4.1.2 MessaGe-anweisung

Mit der MessaGe-anweisung können status- oder Fehlermeldungen ausgegeben werden. dabei unterscheidet sich das Verhalten der MessaGe-anweisung je nach Meldungsart (status, information, Fehler, abbruch) und ob der auslösende Programmteil im dialog- oder Batchmodus ausgeführt wird.

BEST PRACTICE: Vermeiden sie MessaGe-anweisungen außerhalb von Modulen, die direkt mit dem anwender kommunizieren bzw. die in einer definierten dialogschicht liegen. MessaGe-an-weisungen können in bestimmten Konstellationen von Meldungsart und Betriebsmodus implizite CoMMits aufgrund eines Bildschimwechsels in klassischen dynpros auslösen und führen bei einem aufruf innerhalb eines rFC-aufrufs zu Verbindungsabbrüchen. Verwenden sie innerhalb des eigentlichen anwendungskerns klassenbasierte ausnahmen, um auf Fehlersituationen hinzuweisen.

4 roBustHeit

Page 23: Best Practice Leitfaden Development - Über DSAG

23

4.1.3 Klassenbasierte ausnahmen

seit einführung von aBaP oo können auch klassenbasierte ausnahmen verwendet werden. diese arbeiten nach dem Prinzip des „Werfens“ von ausnahmen: ein Programm erkennt einen Fehler und „wirft“ eine ausnahme in den Call stack. Fängt der aufrufer diese ausnahme nicht, wird sie so lange weiter im Call stack nach oben propagiert, bis sie an anderer stelle gefangen wird oder zu einem dump führt.

es ist wichtig, alle ausnahmen zu fangen, auf die in der jeweiligen stelle angemessen reagiert werden kann, oder ausnahmen in der Methode oder dem Funktionsbaustein zu deklarieren, sodass für den aufrufer klar ersichtlich ist, dass die Methode bzw. der Funktionsbaustein eine solche ausnahme aufwerfen könnte. Wichtig ist hierbei die einheitliche Verwendung: Für dieselbe Fehlersituation sollten einheitliche Fehlerbehandlungen/ausnahmen verwendet werden.

zum Fangen von ausnahmen ist der aBaP-Befehl try…CatCH…endtry gedacht. entsprechend müssen alle ausnahmen aller Module, die klassenbasierte ausnahmen erzeugen können, von einem try…CatCH behandelt werden, um einen robusten ablauf zu gewährleisten.

BEST PRACTICE: erlauben sie keine leeren ausnahmebehandlungen.

dadurch wird es aufrufenden stellen unmöglich gemacht, auf ausnahmesituationen angemessen zu reagieren. Propagieren der ausnahme ist in diesen Fällen die richtige reaktion.

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

im CatCH-Block wird die angabe der exception-Klasse die zu fangende ausnahme spezifiziert, z.B. Cx_sy_zerodiVide zum abfangen eines Fehlers aufgrund der division durch null. Hierbei gilt es konkrete ausnahmen abzufangen, um diese spezifisch zu behandeln. das Fangen der allgemeins-ten ausnahme Cx_root sollte nur erfolgen, wenn die ausnahmebehandlung tatsächlich in der Lage ist, mit unbekannten Fehlersituationen umzugehen.

BEST PRACTICE: Wählen sie die grundlegende art von eigenen ausnahmeklassen durch die Vererbung von vordefinierten Basisklassen (statiC_CHeCK, dynaMiC_CHeCK, no_CHeCK) mit Bedacht.

Beim einsatz von statiC_CHeCK wird jeder Verwender durch syntaxfehler gezwungen, für jede dieser ausnahme zu entscheiden, ob er sie direkt behandeln kann, weiterreicht und damit in seine deklaration aufnehmen muss oder über das Verketten mit eigenen ausnahmeklassen verpackt. alle diese Möglichkeiten sind mit aufwand und Änderungen verbunden, die den Vorteil der klassenbasierten ausnahmen (Propagieren von ausnahmen, die nicht direkt behandelt werden können) zunichtemachen. Verwenden sie bei der nachträglichen einführung von ausnahmeklassen daher bevorzugt dynaMiC_CHeCK, um nicht allen ausnahmen die o.g. anpassungen 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 eine aufrufende stelle angemessen reagieren kann. Beispiele dafür sind das Wegbrechen von sekundären datenbankverbindungen oder andere dinge, die durch das Coding nicht korrigiert werden können.

4 roBustHeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 24: Best Practice Leitfaden Development - Über DSAG

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 ausreichenden Berechtigungen zum Öffnen der datei hat. um dies zu vermeiden, muss die Berechtigung pro aktiv vom aBaP geprüft werden (FuBa autHority_CHeCK_dataset), damit oPen dataset nicht zu einem dump führt.

4.2 KorreKte iMPLeMentierunG Von datenBanK-ÄnderunGen

4.2.1 sperrobjekte

um dateninkonsistenzen zu vermeiden, müssen die entsprechenden objekte vor Veränderung auf der datenbank gesperrt werden. zusammenhängende objekte dürfen erst verändert werden, wenn alle zugehörigen entitäten erfolgreich gesperrt werden. damit ist keine parallele datenänderung möglich.

die saP-sperre besteht über mehrere datenbank-LuWs (Logical unit of Work) hinweg, sodass konsistent Änderungen auf der datenbank für das gesamte zu ändernde Businessobjekt geschrieben werden können.

die sperren sind so genau wie möglich abzusetzen, um nur die relevanten objekte innerhalb der LuW zu sperren. zudem sind die sperren so lange wie nötig und so kurz wie möglich zu halten.Für die Änderung von saP-standard-datenobjekten direkt auf der datenbank sind die 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örigen sperrfunktionen zu implementieren.

die sperren sind nach abschluss des updates auf das objekt aufzuheben. dies erfolgt mittels aufruf des dequeue-Funktionsbausteins. Beachten sie dabei den wichtigen scope-Parameter, wenn in diesem zusammenhang auch Verbuchungsbausteine verwendet werden.

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

4.2.2 Verbuchungskonzept

die Verbuchung ist die zentrale technik zur Bündelung von datenbankänderungen in einer einzigen datenbank-LuW und damit zur definition von saP-LuWs in saP-transaktionen. datenänderungen sollen nicht mit dML-Kommandos (dataManipulati-onLanguage-Kommandos insert, update, delete, Modify) aus der applikation, sondern über den Verbucher durchgeführt werden.

4 roBustHeit

Page 25: Best Practice Leitfaden Development - Über DSAG

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 bei der anlage entsprechend in den eigenschaften zu kennzeichnen. diese Funktionsbausteine werden mit dem zusatz „in uPdate tasK“ aufgerufen und unterliegen bei der entwicklung einigen restriktionen. alle bis zu einem „CoMMit WorK“ gerufenen Verbuchungsfunktionen werden in einer LuW auf die datenbank geschrieben.

Beim aufruf der sperrfunktionsbausteine ist auf die korrekte Parametrierung (insbesondere sCoPe-Parameter) zu achten!

Fehlerhafte Verbuchungssätze müssen in der transaktion Verbuchungsaufträge (sM13) 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 der LuW gestartet, jedoch asynchron durchgeführt.

4.2.2.2 asynchrone Verbuchung in abschnitten

die Funktionsbausteine werden in den eigenschaften mit „start verzögert“ angelegt. die Verbu-chung wird sofort nach abschluss der LuW gestartet, wird jedoch asynchron in eigenen Prozessen mit niedriger Priorität durchgeführt. diese art der Verbuchung ist für das schreiben von großen datenmengen geeignet, wenn die Verbuchung nicht zeitkritisch erfolgen muss (z.B. 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.1 asynchrone Verbuchung. die LuW muss jedoch mit „CoMMit WorK and Wait“ abgeschlossen werden. diese art der Verbuchung wird dann gewählt, wenn die geänderten daten sofort benötigt werden, z.B. wenn man LuWs koppeln will und eine LuW vom ergebnis der vorherigen LuW abhängt.

4 roBustHeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 26: Best Practice Leitfaden Development - Über DSAG

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 transaktion sLG0 können darüber hinaus eigene objekte zur Protokollierung definiert werden.

der Vorteil bei der Verwendung des Business application Logs liegt in folgenden aspekten begründet:

1. zentrale ablage: im Business application Log können Meldungen an zentraler stelle verwaltet werden; dies erleichtert den Überblick und die administration der anwendungen

2. Wiederverwendbarkeit: das Business application Log bzw. die zugehörigen Bausteine/Klassen bieten einen guten Funktionsumfang für das thema Logging – dieser muss nicht „neu erfunden“ werden. zu diesen Möglichkeiten zählen u.a.

a. integration zusätzlicher Felder in die Protokollierungsobjekte b. Hierarchiedarstellung von Meldungen (zusammenfassung zu Problemklassen möglich) c. interaktivität (nachlesen von informationen bei aufruf einer Meldung und anreichern von informationen) d. Persistenz: speicherung von Meldungen im Log möglich e. integration der Protokollanzeige in eigene anwendungen/uis (sub-screen/Control/Popup)

BEST PRACTICE: Für die Protokollierung sollten die von saP vorgesehenen Funktionsbausteine in der Funktionsgruppe sBaL verwendet werden. die Beispielprogramme „sBaL_deMo*“ bieten einen guten einstieg und Überblick.

Bitte beachten sie bei der implementierung die saP-standardhilfe bzgl. der Verwendung der Funktionsbausteine im jeweiligen release.

WEITERE QUELLEN:1. saP application Log – Leitfaden für 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 wieder auftauchen.

4.4.1 unvollständige Fallunterscheidungen

Für Case statements wird empfohlen, alle vorhandenen WHen-Blöcke auszuprogrammieren. außerdem sollte immer ein WHen otHers-Block vorhanden sein, um Fälle zu behandeln, die zur zeit der entwicklung noch nicht abzusehen waren bzw. unterwartet sind.

4 roBustHeit

Page 27: Best Practice Leitfaden Development - Über DSAG

27

Bei iF-abfragen ist darauf zu achten, dass auch die eLse/eLseiF-zweige ausprogrammiert werden, sofern diese im jeweiligen Kontext sinn machen.

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

sy-suBrC-Prüfungen sollten möglichst immer stattfinden, wenn aBaP-Befehle rückgabewerte liefern. das ist wichtig, um die integrität des systems auch im Fehlerfall zu gewährleisten. es wird daher empfohlen, zumindest im umgang mit dateien und datenbanktabellen Prüfungen auf sy(st)-suBrC durchzuführen.

im Folgenden sind die relevanten aBaP-Befehle gelistet, für die sy(st)-suBrC aus sicht der robustheit immer geprüft werden sollte und die in diesem Kapitel noch nicht erwähnt wurden:

> oPen dataset > read dataset > deLete dataset> seLeCt sinGLe> deLete dbtab > ModiFy dbtab > insert dbtab > uPdate dbtab

4.5 WeiterFÜHrende QueLLen

1. Liste einiger Befehle, die sy-suBrC setzen: http://wiki.sdn.sap.com/wiki/display/aBaP/sy-subrc

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 28: Best Practice Leitfaden Development - Über DSAG

28

dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im aBaP negativ auf die sicherheit eines unternehmens auswirken können. da dieses thema sehr komplex ist, können wir im rahmen dieses dokuments nur ein paar ausgewählte, zentrale themen behandeln. Für weitergehende Fragen verweisen wir auf die Literaturhinweise am ende dieses Kapitels. zunächst müssen wir die Begriffe sicherheit und Compliance in diesem Kontext erklären:

Wir sprechen von einer sicherheitsschwachstelle, wenn ein Programmierfehler einen ungewollten nebeneffekt verursacht, durch den ein angreifer unbefugt schadhafte aktionen ausführen kann. Wir sprechen von einem Compliance-Verstoß, wenn ein anwender aufgrund eines 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 iM saP standard

Bevor wir näher auf schwachstellen eingehen, ist es wichtig, sich noch einmal ein paar zentrale schutzmechanismen des saP-standards vor augen zu führen. diese sind Grundvoraussetzung für den sicheren Betrieb von saP-systemen.

5.1.1 Berechtigungsprüfung (a)

rollen und Berechtigungen sind ein zentrales sicherheitsthema im saP-umfeld. es ist daher wichtig zu verstehen, dass aBaP ein sogenanntes explizites Berechtigungsmodell verwendet. das bedeutet, dass Berechtigungsprüfungen explizit im Code programmiert werden müssen, damit sie auch ausgeführt werden. das beste Berechtigungskonzept nützt nichts, wenn selbstgeschriebener Code die erforderlichen Berechtigungen nicht (richtig) prüft.

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

5.1.2 Mandantentrennung (B)

der saP-standard trennt automatisch alle datenbankzugriffe nach Mandanten auf. ein aBaP-Programm darf immer nur die daten des Mandanten verarbeiten, an dem sich der anwender 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

Page 29: Best Practice Leitfaden Development - Über DSAG

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, relevante aktionen 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 getrennte systeme (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 das entwicklungssystem 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 sehr gefährlich ist, stellt der standard transaktionen (sM49/sM69) zur Verfügung, mit denen man eine Liste erlaubter Befehle definieren und die erlaubten Befehle auch noch durch spezielle 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 einem sehr limitierten satz an Befehlen, die zusätzlich alle statisch deklariert werden müssen. dadurch können gefährliche sQL-Befehle in der datenbank abgeschirmt werden.

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.

5 aBaP-siCHerHeit und CoMPLianCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 30: Best Practice Leitfaden Development - Über DSAG

30

5.2 siCHerHeitssCHWaCHsteLLen

applikationssicherheit ist in vielen Programmiersprachen schon seit Jahren ein wichtiges thema. in aBaP wurde dieses thema jedoch häufig nicht erkannt bzw. falsch eingeschätzt. ein wesent-licher Grund dafür ist der falsche Glaube, dass man saP-systeme durch rollen und Berechti-gungen absichern kann. dies mag für den saP-standard zutreffen, aber definitiv nicht für selbst- entwickelten Code. Wie bereits weiter oben erläutert, werden z.B. Berechtigungen nur geprüft, wenn der aBaP Code eine Prüfung auch explizit durchführt.

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

> Fehlende bzw. falsche Berechtigungsprüfungen

der aBaP Code führt operationen aus, für die ein Berechtigungsprüfung erforderlich ist, überprüft aber die Berechtigung des Benutzers nicht bzw. nicht richtig.

> injection-Probleme

der aBaP Code verwendet dynamische Befehle, die aus Benutzereingaben zusammengefügt werden. Wenn hier nicht durch input-Validierung bzw. output-encoding verhindert wird, dass steuerzeichen in den eingaben die semantik des dynamischen Befehls verändern können, dann kann der dynamische Befehl zur Laufzeit schadhaft verändert werden.

> aushebelung von sicherheitsmechanismen des standards aBaP Code darf einen bestehenden sicherheitsmechanismus nicht gezielt umgehen. Beispiele sind proprietäre Berechtigungsprüfungen (basierend auf sy-unaMe), mandantenübergreifende datenbankzugriffe, ausführung von Betriebssystemkommandos über Kernelfunktionen. Folgende schwachstellen sind im aBaP besonders häufig zu beobachten. die spalte „std“ zeigt dabei an, welcher sicherheitsmechanismus des saP-standard dabei beeinträchtigt wird.

id schwachstelle Beschreibung stdaPP-01 aBaP Command injection ausführung von beliebigem

aBaP Coded

aPP-02 os Command injection ausführung beliebiger Betriebssystem-Kommandos

e

aPP-03 native sQL injection ausführung beliebiger nativer sQL-Kommandos

F

aPP-04 improper authorization (Missing, Broken, Proprietary,

Generic)

Fehlende oder fehlerhafte Berechtigungsprüfung

a

aPP-05 directory traversal unerlaubter schreib-/Lesezugriff auf dateien (saP

server)

aPP-06 direct database Modifications unberechtigter schreibzugriff auf tabellen

C

5 aBaP-siCHerHeit und CoMPLianCe

Page 31: Best Practice Leitfaden Development - Über DSAG

31

id schwachstelle Beschreibung stdaPP-07 Cross-Client database access Mandantenübergreifender

zugriff auf GeschäftsdatenB

aPP-08 open sQL injection schadhafte Manipulation von datenbankbefehlen

F

aPP-09 Generic Module execution unerlaubte ausführung von Modulen (reports, FuBas etc.)

a

aPP-10 Cross-site scripting Manipulation des Browser ui, diebstahl von Berechtigungen

C

aPP-11 obscure aBaP Code einschränkte auditierbarkeit durch Verschleierung von Code

d

abbildung 1: BizeC aPP/11 – die derzeit verbreitetsten sicherheitsprobleme in aBaP-CodeQUELLE: http://www.bizec.org/wiki/BizeC_aPP11

dieses Kapitel kann bei Weitem nicht die notwendigen details liefern, um sicheren aBaP-Code zu programmieren. Wir verweisen hier auf die Literaturempfehlung #1 am ende des Kapitels.die folgende Liste enthält eine Übersicht über saP-Meldungen, die Gegenmaßnahmen zu einigen der oben beschriebenen Probleme beschreiben.

saP note 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 Verbindung gebracht, 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 referenzmodellen Coso & CoBit beschrieben. in einer typischen iKs-struktur sind die „Generellen it-Kontrollen“ (itGC-it General Controls) Voraussetzung für das erreichen aller iKs-ziele im it-dominierten umfeld.

5 aBaP-siCHerHeit und CoMPLianCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 32: Best Practice Leitfaden Development - Über DSAG

32

ein elementarer Baustein der itGC ist das Änderungswesen (Change Management), zu dem wiederum eigenentwicklungen zählen. sicherheitsdefekte im selbstgeschriebenen aBaP-Code stellen eine Verletzung der generellen it-Kontrollen dar und erschüttern damit die Grundmauern jedes internen Kontrollsystems.

abbildung 3: iKs-risiken durch unsicheren aBaP-Code

dies bedeutet insbesondere, dass sicherheitsdefekte im aBaP-Code potenziell nicht nur auswirkungen auf Compliance-standards haben, sondern auch gesetzliche anforderungen verletzen können.

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

5.4 testWerKzeuGe

Für aBaP-sicherheitstests eigenen sich insbesondere sogenannte statische Codeanalyse-tools. es gibt hier verschiedene kommerzielle anbieter, die in wesentlichen Bereichen die Möglichkeiten des Code inspectors erweitern:

> analyse des saP-standard-Codings, insbesondere von aPi-aufrufen> sehr hohe scan-Geschwindigkeiten für Continuous Monitoring> Globale daten- und Kontrollflussanalysen, da diese für die meisten sicherheitstests elementar sind.> umfangreiche Beschreibungen des Problems mit Lösungsvorschlägen> Hinreichende testabdeckung (oWasP top 10 und sans 25 reichen nicht, da überwiegend Web-spezifisch und auf aBaP kaum anwendbar)> 4-augen-Prinzip bei ausnahmen

5 aBaP-siCHerHeit und CoMPLianCe

Page 33: Best Practice Leitfaden Development - Über DSAG

33

natürlich muss so ein tool hinreichend in se80, tMs und CharM integriert sein, damit die entwickler damit arbeiten können und wollen.

5.5 WeiterFÜHrende QueLLen:

1. andreas Wiegenstein, Markus schumacher, sebastian schinzel, Frederik Weidemann, sichere aBaP Programmierung, saP Press 20092. Maxim Chuprunov , Handbuch saP-revision, saP Press 20113. BizeC - the Business application initiative (http://bizec.org)

5 aBaP-siCHerHeit und CoMPLianCe

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 34: Best Practice Leitfaden Development - Über DSAG

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 dies spätestens bei der Weiterentwicklung oder dem Wechsel von entwicklern zu erhöhten aufwänden. in diesem Kapitel werden unterschiedliche Möglichkeiten zur dokumentation von entwicklungsob-jekten im saP system dargestellt.

6.1 doKuMentation unaBHÄnGiG Von entWiCKLunGsoBJeKten

neben der Beschreibung der vielen entwicklungsobjekte, die einzelne, sehr spezielle Funktionen im aBaP-system übernehmen, gibt es auch den Bedarf, die größeren zusammenhänge innerhalb und zwischen Modulen darzustellen. dazu gehören z.B. antworten auf Fragen wie:

> Welche abhängigkeiten gibt es zwischen n Modulen?

> Wie werden Prozesse auf reports abgebildet?

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

Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes ablageme-dium innerhalb des saP-entwicklungssystems, das insbesondere Grafiken gut integriert. Wir empfehlen daher, für die dokumentation dieser übergreifenden zusammenhänge auf andere Medien außerhalb des saP-systems zurückzugreifen. Beispiele dafür sind:

> interne (Produkt-)Wikis

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

die erfahrung zeigt, dass die Herausforderung in diesem Bereich primär in der Frage der disziplin liegt. diese Herausforderung kann kein tool lösen, sondern nur das entwicklungsteam und die zugehörige -leitung. darüber hinaus sei angemerkt, dass veraltete dokumentation irreführend sein kann. insofern sollte in dokumenten der stand und eine Versionierung enthalten sein, um die aktualität bewerten zu können.

innerhalb einer saP-systemlandschaft bietet der saP solution Manager Möglichkeiten zur Projektdokumentation. die nachfolgenden Links bieten weitere informationen dazu.

WEITERE QUELLEN: 1. Help.sap.com dokumentation saP solution Manager 7.1: http://help.sap.com/saphelp_sm71_sp05/helpdata/en/3d/d05893e6ba4dfab7c0d66de8d52420/ frameset.htm2. 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

Page 35: Best Practice Leitfaden Development - Über DSAG

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 beinhalten und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind:

> interfaces> ddiC-objekte> transaktionen

BEST PRACTICE: Wir empfehlen, für alle entwicklungsobjekte, unabhängig von Quelltexten, die Möglichkeiten zur dokumentation der aBaP Workbench zu nutzen und die aufgaben und Bedeutungen dieser objekte im saP-system zu dokumentieren. im Vergleich zur dokumentation im Quelltext ist hier der Änderungsverlauf nicht im Vordergrund, sondern der ist-stand sollte hier dargelegt werden.

da die dokumentation auch an das transportwesen angeschlossen ist, steht diese dokumentation in allen stages einer systemlandschaft zur Verfügung. Weiterhin kann die dokumentation von allen Benutzern eingesehen werden und wird in einigen Fällen (reports) vom aBaP-system automatisch in die Benutzungsoberfläche eingebunden. ein weiterer Vorteil besteht darin, dass diese 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 schnelles zurechtfinden in fremden Programmen ermöglicht wird. dabei soll in einer Kommentarzeile kurz beschrieben werden, welche aufgabe der nächste anweisungsblock hat. dokumentieren sie insbesondere, warum sie etwas machen, nicht wie. dabei gilt der Grundsatz: so wenig Kommentar wie möglich, so viel Kommentar wie nötig. Vermeiden sie daher redundante informationen (wie name des dokumentierten Moduls, den letzten Änderer etc).

BEST PRACTICE: als Kommentierungssprache sollte englisch verwendet werden. entwicklungs-teams arbeiten heutzutage überwiegend international zusammen. auch wenn sie derzeit rein deutschsprachig entwickeln, kann ihr Projekt im Laufe der zeit internationalisiert werden. der aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht, steht in keinem Verhältnis zu dem vielleicht größeren aufwand durch englische dokumentation.

es hat sich außerdem gezeigt, dass die Lesbarkeit von Code und Kommentaren besser ist, wenn die Kommentare englisch sind. denn die aBaP-Befehle selbst sind englisch und im stil von sätzen aufgebaut. der Leser muss bei englischer dokumentation also nicht ständig beim Lesen des Quelltextes die sprache wechseln.

6 doKuMentation

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 36: Best Practice Leitfaden Development - Über DSAG

36

6.3.2 dokumentation von Änderungen

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

6.3.3 Programmkopf

Änderungen in Programmen werden mit einem namenskürzel (z.B. Vorname + nachname), dem tagesdatum und dem Change document der Änderung im Programmkopf dokumentiert. dabei soll zumindest im Programmkopf auch die erläuterung des namenskürzels stehen, hilfreich ist es jedoch auch, die Beschreibung direkt bei der Änderung einzufügen. Hierdurch kann auf einen Blick der Grund der Änderung im Code erfasst werden.

Beispiel:

*/ Change Log

*/ Vn/date Changedoc description

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

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

*/ MM/2009-01-01 Cd0815 added Field aBC in method signature and source code in order to support quick search, Max Mustermann

in der Beschreibung der Änderung sollte die Frage „Wer hat Was, Warum und Wie geändert“ beantwortet werden. Werden für die Koordination der Weiterentwicklung Change-Management- oder Bug-tracking-systeme eingesetzt, sollten in diesem Kommentar Verweise auf die Vorgänge/issues enthalten sein. damit lässt sich später auch im Quelltext nachvollziehen, welche erweiterung/Fehlerbehe-bung auslöser für eine Änderung war.

BEST PRACTICE: der Kommentar ist nicht für den Verfasser, sondern für andere entwickler gedacht. Führen sie sich das bei der erstellung von Kommentaren bzw. deren review immer wieder vor augen.

Programmzeilen – optional

die geänderten Programmzeilen können mit der Kombination namenskürzel und tagesdatum der Änderung dokumentiert werden. Hinter dem datum kann ein Punkt gesetzt werden, sodass der Pretty Printer die Kommentierung automatisch nach rechts ausrichtet.

alte dokumentationen von Änderungen, die nicht mehr benötigt werden, sollten aus Gründen der Les- barkeit wieder entfernt werden. oberstes ziel sollte stets die gute Lesbarkeit von Quelltexten sein.

6 doKuMentation

Page 37: Best Practice Leitfaden Development - Über DSAG

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 Code verwendet werden.

Für alle anderen Kommentare empfiehlt die saP inline-Kommentare zu verwenden. diese sollten jeweils vor dem Code stehen, den sie dokumentieren, und auch so eingerückt sein wie dieser Code.

WEITERE QUELLEN: Keller, thümmel, aBaP-Programmierrichtlinien, saP Press 2009

6 doKuMentation

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 38: Best Practice Leitfaden Development - Über DSAG

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 man diesen 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. Hierzu gehören organisatorische aspekte genauso wie Prüfmethoden und Werkzeuge. Wir gehen aber auch auf Grenzen der durchsetzbarkeit ein.

abschließend stellen wir tipps aus der Praxis vor, die die autoren bei verschiedenen Projekten im umfeld der saP-entwicklung gesammelt haben.

7.1 uMsetzBarKeit

Wer erfolgreich Programmierrichtlinien in einem unternehmen einführen möchte, muss zunächst das Management dafür gewinnen. denn die Verbesserung der Codequalität bedeutet zunächst eine investition in Prozesse und Werkzeuge sowie in die Fortbildung der involvierten Mitarbeiter. insbesondere muss das Management überzeugt sein, dass das unternehmen durch diese Prozesse langfristig Kosten spart.

7.1.1 Motivation für einen Prozess

nachfolgend finden sie anhaltspunkte, welche Qualitätsaspekte bei der einführung eines Prozesses zur Qualitätssicherung adressiert werden und welche Vorteile dies für unternehmen hat:

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 Pressemeldungen hervorgerufen 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 werden kann, und schützt damit die bisherige investition in Hardware. außerdem steigt die zufriedenheit der Mitarbeiter, da die nutzung der anwendung produktiver wird. risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt bzw. es entstehen Kosten für schnellere Hardware, um die softwaremängel auszugleichen.

7 uMsetzBarKeit und durCHsetzBarKeit

Page 39: Best Practice Leitfaden Development - Über DSAG

39

robustheitVorteil: das unternehmen stellt den kontinuierlichen Betrieb der Geschäftsanwendungen sicher und vermeidet unproduktivität auf Grund von systemausfällen.risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt und die Betriebskosten steigen wegen unproduktivität der anwender sowie durch Fehleranalysen und Wartungsarbeiten durch techniker.

WartbarkeitVorteil: das unternehmen erreicht, dass die applikation nachhaltig und kosteneffizient gewartet werden kann, weil die Programmstruktur leicht verständlich und gut dokumentiert ist.risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte Fehleranfälligkeit der applikation.

7.1.2 erstellung und Pflege des Prozesses

Für die umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschreibung eines Prozesses bewährt. dazu zählen klare Verfahrensanweisungen und Verantwortlichkeiten. die genaue ausprägung des Prozesses ist unternehmensspezifisch und kann in dieser Guideline nicht abgebildet werden; der Verweis auf die notwendigkeit ist jedoch allgemeingültig.

BEST PRACTICE: definieren sie den einzuhaltenden Prozess und dokumentieren sie ihn in einer für alle zugänglichen Form. definieren sie, wie Änderungen und Verbesserungen am Prozess stattfinden sollen und wie anmerkungen und Kritik eingebracht werden können. dokumentieren sie alle geprüften regeln ausführlich mit den Kapiteln Hintergrund/Motivation, schlechte Beispiele, gute Beispiele, Hinweise zum Vorgehen zur Beseitigung und Literatur bzw. ansprech-partner im unternehmen.

Motivationein Prozess für Best Practices bei der entwicklung hilft, die Qualität von software pro aktiv und effizient zu verbessern und damit Kosten im unternehmen langfristig zu senken. Je früher ein Fehler bei der entwicklung erkannt wird, desto einfacher und kostensparender kann er behoben werden. Je weniger Fehler eine anwendung enthält, desto mehr entspricht ihre nutzung den erwartungen des unternehmens. insbesondere läuft sie ohne nebeneffekte, die das Business negativ beeinflussen.

Welche aspekte sind für den Prozess relevant?

interne entwicklungFür die interne entwicklung werden richtlinien als nachschlagewerk für die tägliche arbeit und regelmäßige trainings für aktuelle risiken benötigt.

externe entwicklungBei externer entwicklung sind klare Qualitätsvorgaben für ausschreibungen nötig. Vor der abnahme müssen die anforderungen auch überprüft werden.

Übergreifenddie Vorgaben aus dem Prozess müssen möglichst weitgehend mit geeigneten tools überprüft werden. eine manuelle Prüfung ist nur in seltenen Fällen flächendeckend möglich.

7 uMsetzBarKeit und durCHsetzBarKeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 40: Best Practice Leitfaden Development - Über DSAG

40

BEST PRACTICE: Vorgaben ohne werkzeuggestützte Überprüfungsmöglichkeit sind nicht umsetzbar und sollten daher nicht definiert und vorgegeben werden. Bei jeder regel, die zur nachträglichen Qs herangezogen werden soll, muss festgelegt werden, wie diese werkzeuggestützt überprüft werden kann. Wenn keine mechanische Überprüfung durch ein Werkzeug möglich ist, wird es in der Praxis nahezu unmöglich werden, auf die konsequente einhaltung der regel zu achten. die Konzentration auf maschinell überprüfbare regeln erspart denjenigen, die Qualitätssicherung betreiben sollen, eine Vielzahl an Frustrationsquellen.

nichtsdestotrotz gibt es etliche aspekte, die sich einer maschinellen Prüfung entziehen. diese aspekte können sinnvollerweise nur mit regelmäßig durchgeführten Code reviews abgedeckt werden. da gut durchgeführte Code reviews erhebliche aufwände in der durchführung, aber auch der Vor- und nachbereitung bzw. Kontrolle von Korrekturen erfordern, müssen diese sich auf wenige, aber unter den nicht maschinell prüfbaren aspekten kritischen entwicklungsobjekten beschränken. Wenn z.B. die einhaltung von Performance-Vorgaben eine hohe Priorität besitzt, sollten in entsprechenden Code reviews nur entwicklungsobjekte mit zugriffen auf datenbanken oder umfangreichen Berechnungen beschränkt werden.

der Prozess muss daher eine Qualitätskontrolle vorsehen, durch die sämtliche entwicklungen geprüft werden, bevor sie in den Produktivbetrieb gehen. es muss auch definiert sein, wie mit Fehlern verfahren werden soll. der Prozess muss selbstverständlich regelmäßig aktualisiert werden, um neue aspekte berücksichtigen zu können.

7.2 durCHsetzBarKeit

7.2.1 Manuelle Prüfungen

Viele der Prüfungen lassen sich automatisieren. es gibt jedoch Bereiche, die sich für eine automatische Prüfung nicht eignen, wie beispielsweise dokumentation, architektur oder viele funktionale anforderungen. die menschliche sprache ist sehr komplex, daher muss z.B. der inhalt von dokumenten und dokumentationen manuell geprüft werden. nur der menschliche Leser kann beurteilen, ob ein text sinnvoll, vollständig, verständlich und korrekt ist. eine automatische Prüfung kann dabei maximal die existenz in den vorgegebenen sprachen prüfen. es empfiehlt sich dennoch ein automatischer test auf nicht-funktionale aspekte.

Für die manuelle Prüfung ist es wünschenswert, eine vollständige Prüfung anhand der 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 oder zumindest stichprobenartige Prüfung erfolgen. das Prüfergebnis wird dem entwickler/zuständigen zur Verbesserung/Vervollständigung der dokumente/dokumentationen übermittelt.

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

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

7 uMsetzBarKeit und durCHsetzBarKeit

Page 41: Best Practice Leitfaden Development - Über DSAG

41

Wann und wie sollte geprüft werden?

die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf aktualität und Konformität bzgl. der Vorgaben geprüft werden. die aktualität ist jedenfalls mit einem upgrade auf ein neues release (enhancement Package) zu prüfen. Bzgl. der Vorgaben ist es durchaus sinnvoll, das Wirtschaftsprüfungsunternehmen, welches das unternehmen prüft, hinzuzuziehen. Für extern entwickelten Code gilt, dass eine Prüfung vor abnahme stattfinden muss.

Für die akzeptanz der Prüfungen bzw. der Beanstandung im zuge der manuellen Prüfungen ist es sinnvoll, im rahmen der entwickler- und Qa-tests (4-augen-Prinzip) die manuell notwendigen Prüfungen durch andere entwickler durchführen zu lassen.

dasselbe gilt für Penetrationstests und Belastungstests. da es sich bei Penetrationstests auch um ein kritisches sicherheitsthema handelt, kann es notwendig sein, hierfür in regelmäßigen abständen auch externe Partner hinzuzuziehen.

7.2.2 automatische Prüfungen

automatische tests decken schnell einen Großteil der notwendigen tests und Prüfungen ab. als Hintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne zusätzlichen aufwand möglich. diese regelmäßig mit gleicher Qualität durchgeführten tests ermöglichen so den entwicklern, ihren Programmierstil zu verbessern.

Wann und wie sollte geprüft werden?

die entwickler sollen ein möglichst zeitnahes Feedback bzgl. der Konformität der entwicklungen mit den richtlinien erhalten. dazu dienen täglich eingeplante Prüfungen im entwicklungssystem, deren ergebnis dem entwickler zur Verfügung gestellt wird. Wichtig ist, dass dieselben tests und Metriken bei der Prüfung durch jeden einzelnen entwickler und bei der Prüfung durch zentrale Qs-instanzen bzw. bei einer transportfreigabe verwendet werden. sollten für diese Prüfungen unterschiedliche Werkzeuge oder unterschiedliche einstellungen verwendet werden, sinkt die akzeptanz in entwicklerkreisen ganz erheblich.

als zentrale schutzinstanz müssen die Prüfungen in das tMs und da spätestens mit der Freigabe des transportauftrags (besser der einzelnen transportaufgaben) implementiert sein. damit wird sichergestellt, dass keine ungeprüften bzw. nicht den richtlinien entsprechenden entwicklungen in die Folgesysteme und dann auch in das Produktivsystem transportiert werden.

als „letztes sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsystem vorzusehen. dieser sollte in einer lastarmen zeit mittels Hintergrundjob eingeplant werden. das ergebnis wird dem Qa-zuständigen zur Verfügung gestellt, der dann die weiteren schritte (ggfs. Korrektur) mit hoher Priorität veranlasst.

Bei allen automatischen Prüfungen ist im Vorfeld zu definieren, wie mit altem Code umgegangen wird. sinnvoll scheint es hierfür auch, einen Fahrplan zu erstellen, wann und wie die neuen regeln auf alten Code angewendet werden.

7 uMsetzBarKeit und durCHsetzBarKeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 42: Best Practice Leitfaden Development - Über DSAG

42

7.2.3 Werkzeuge

nachstehend werden einige tools aufgelistet, mit welchen die automatisierten Prüfungen durchgeführt werden können.

saP Code inspector

der saP-Code inspector wird seitens saP im standard ausgeliefert und ist entsprechend in die entwicklungsumgebung hoch integriert. saP sieht ein erweiterungskonzept vor, welches ermöglicht, kundenspezifische Prüfungen selbst zu implementieren. Hierfür sind ggfs. Program-mierarbeiten notwendig. die seitens saP ausgelieferten Prüfungen können teilweise weitgehend parametrisiert werden. inspektionen auch von großen objektmengen können sowohl online als auch im Batchbetrieb erfolgen und ergebnismengen von vorangegangenen inspektionen können wieder als objektmenge verwendet werden, um die Kontrolle von Korrekturen auf die vorher fehlerbehafteten objekte zu beschränken. Weiterhin können ergebnisse auch automatisch per e-Mail an die verantwortlichen entwickler verteilt werden.

Werkzeuge von drittherstellern

neben dem saP Code inspector gibt es am Markt sehr gute kommerzielle tools, die Prüfungen auf Code-ebene vornehmen. eine Beschreibung dieser tools soll aus neutralitätsgründen an dieser stelle unterbleiben.

7.3 erFaHrunGen und tiPPs aus der Praxis

7.3.1 Qualitätssicherung des Quellcodes

um eine erfolgreiche einführung zu gewährleisten, ist es wichtig, Qualitätssicherung schrittweise und behutsam einzuführen. Hierbei empfiehlt es sich, einen zweigeteilten ansatz zu fahren. zunächst sollte neuer Code „fehlerfrei“ erstellt und dies geprüft werden. erst wenn sich dieser Prozess stabilisiert hat, sollte nach und nach Bestandscode mit in die Checks aufgenommen werden, sonst wird der zu bewältigende Berg für den entwickler zu groß und die Motivation sinkt rapide.

Wenn nicht auf der „grünen Wiese“ mit einer neuen entwicklung begonnen wird, wenn automa-tische Codeprüfungen eingeführt werden, ist es wichtig, vorher den umgang mit „altlasten“ zu klären. auch bei neuen entwicklungen lassen sich Änderungen an schon bestehenden objekten nicht vermeiden, die dann bei einer eingerichteten transportprüfung zu Problemen führen. Hilfreich ist in solchen Fällen eine Klärung der Verantwortlichkeit für entwicklungsobjekte, die z.B. durch das entsprechende Feld in Paketdefinitionen dokumentiert werden kann. diese Verantwort-lichen müssen entscheiden, ob Fehler im Bestandscoding sofort korrigiert werden müssen oder eine ausnahmeregelung möglich ist.

in vielen Fällen ist es schon ausreichend, mit standard-Bordmitteln, wie z.B. Code inspector, zu arbeiten, der sich auch um eigene Checks erweitern und somit an eigene Bedürfnisse anpassen lässt. im netWeaver 7.02 sind einige neue Prüfungen in der auslieferung enthalten wie suche nach bestimmten kritischen anweisungen, Verwendung der adBC-schnittstelle, mandenatenabhängige shared-objects-Methoden, robuste Programmierung und aBaP-Webdynpro-Metrik.

7 uMsetzBarKeit und durCHsetzBarKeit

Page 43: Best Practice Leitfaden Development - Über DSAG

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 der entwickler die Möglichkeit haben, den Code während seiner entwicklertätigkeit selbstständig auf Fehler hin untersuchen zu können.

tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten hingewiesen werden. tägliche inspektionen mit einem entsprechenden Werkzeug und Verteilung der ergeb-nisse stellen sicher, dass Fehler frühzeitig erkannt werden und die entwickler sich noch an ihre tätigkeiten vom Vortrag erinnern, was die Fehlerbehebung deutlich vereinfacht. so wird gewä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äter die Qa einsetzt, desto höher ist der aufwand für die Fehlerbehebung. dieser zusätzliche aufwand entsteht z.B. durch zusätzliche transporte, wenn der originaltransport bereits freigegeben wurde.

deshalb ist es wichtig, bei Planung und schätzung eines Projektes die Qualitätssicherung zu berücksichtigen, und zwar nicht nur am ende, sondern projektbegleitend und anschließend im kompletten software-Lifecycle.

nicht zu unterschätzen ist auch der schulungsaufwand, der benötigt wird, um bei den entwicklern um Verständnis für den Prozess zu werben.

Bei einem einsatz von externen entwicklern müssen die Programmierrichtlinien und 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 kurz eingegangen wird.

ein reibungspunkt ergibt sich durch die Frage, wer für die Qa zuständig ist, ersteller oder Änderer. Bei neuen sourcen ist dies kein Problem, bei Bestandscode aber wird die Frage immer wieder aufgeworfen:

„Warum soll ich Code überprüfen, in dem ich nur eine zeile geändert haben?“ vs.„Warum soll ich Code überprüfen, den ich schon Jahre nicht mehr angefasst habe?“

Beide Positionen sind natürlich verständlich, deswegen muss eine klare entscheidung bezüglich Handhabung von kopiertem Code, der auf anderen/keinen Konventionen beruht, getroffen und durchgesetzt werden.

BEST PRACTICE: um bei auftretenden Problemen die Fragen der entwickler zu beantworten, ist es wichtig, dafür eine zentrale stelle zu schaffen. außerdem muss es einen Prozess geben, um in notfällen auch fehlerbehaftete transporte freizugeben. Gibt es diese Möglichkeit nicht, sinkt das Verständnis für die durchgeführten Maßnahmen. eine Möglichkeit ist es hierbei, einen Genehmi-gungsprozess zu installieren, mit dessen Hilfe auch fehlerbehafteter Code freigegeben oder transportiert werden kann. die meisten tools am Markt bieten diese Möglichkeit standardmäßig an.

7 uMsetzBarKeit und durCHsetzBarKeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 44: Best Practice Leitfaden Development - Über DSAG

44

7.3.4 entscheidungsfindung bei Modifikationen

Wichtig ist es, die Hürde für Modifikationen so hoch wie möglich zu legen. dies ist besonders wichtig, wenn man sich dazu entscheidet, zeitnah enhancement Packages der saP einzuspielen (sPau-Problematik). ansatzpunkt hierzu ist der Modifikationsschlüssel. die anzahl der entwickler, die die Berechtigung haben, Modifikationsschlüssel zu generieren, muss möglichst gering sein. so ist es möglich, steuernd einzugreifen und diese über Change requests und einen zugehörigen Prozess abzuhandeln.

die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu beantworten und konsequent umzusetzen. eine Pauschalantwort auf diese Frage gibt es nicht. in jedem Fall sollte die entscheidung jedoch auf gleichartigen, im Vorfeld definierten und kommunizierten Kriterien basieren.

7.3.5 erfahrungsbericht aus der Praxis: Comgroup GmbH

das nachfolgende Beispiel der Comgroup GmbH, dem it-dienstleister der Würth Gruppe, zeigt wie Programmierrichtlinien und namenskonventionen in einer softwareentwicklung ein- und durchgesetzt werden können. die Comgroup GmbH startete mit der Code Qa im globalen entwicklungssystem einer mehrstu-figen entwicklungslandschaft. zur automatisierten unterstützung wurde der Code inspector eingesetzt. da die Code-Qa-einführung mit der einführung eines neuen namensraumes zusammenfiel, wurden zu Beginn des Projekts nur objekte aus dem neuen namensraum geprüft und Bestandscode nicht berücksichtigt. dies erleichterte die selektion im Code inspector, da dieser keine Änderungs- oder erstellungsdaten bei der selektion berücksichtigt. außerdem wurden Performance- und security-Checks aus dem Code inspector vorerst nicht aktiviert, um den aufwand in einem überschaubaren rahmen zu halten.

Hierdurch hat der entwickler die Möglichkeit, seinen Code während seiner entwicklertätigkeit selbstständig zu checken. zusätzlich wurde ein nachtlauf eingeplant, der den kompletten zu scannenden Code analysiert und bei gefundenen Fehlern Mails an den jeweiligen entwickler sendet. Probleme bereitete hierbei, dass es viele user im system gab, die keine zugeordnete Mailadresse hatten, was dazu führte, dass zu Beginn Mails ihren empfänger nicht erreichten. Mails an entwickler ohne Mailadresse werden an eine zentrale adresse versendet und somit können die unvollständigen datensätze mit einem geringen aufwand identifiziert werden. deshalb werden nun keine entwicklungs-user mehr im system ohne Mailadresse angelegt.

die Mails wurden nicht von einem anonymen Batch-user sondern von der Mailadresse des Qa-Verantwortlichen gesendet, um dem entwickler einfach die Möglichkeit zu geben, Fragen zu stellen. zu Beginn entstand hierdurch ein hoher aufwand, die anzahl der Fragen verringerte sich aber mit der Laufzeit des Projekts. dies konnte erreicht werden, da schulungen durchgeführt wurden und so die entwickler effizienter die Fehler korrigieren konnten oder diese schon bei der entwicklung vermieden.

7 uMsetzBarKeit und durCHsetzBarKeit

Page 45: Best Practice Leitfaden Development - Über DSAG

45

die entwicklungssprache in der entwicklungslandschaft ist englisch. dies wird durch einen weiteren Job geprüft und bei Fehlern dem entwickler gemeldet. saP bietet keine Möglichkeit im standard, bei der anlage die richtige sprache zu setzen. deshalb bot sich nur die Möglichkeit, an passender stelle eine entsprechende Prüflogik per Modifikation einzubauen oder damit zu leben, dass objekte in falscher sprache angelegt werden und danach umgezogen werden mussten.

Bei anlage von objekten wurden namenskonventionen für die objekte gecheckt, sodass diese nur nach Konventionen benannt werden konnten (ebenfalls per Modifikation).

um eigene Checks bei der transportfreigabe durchzuführen (z.B. eigene namenskonventionen/mind. deutsche und englische Übersetzung) wurde eine implementierung für das Business add in Cts_reQuest_CHeCK angelegt und die Methode CHeCK_BeFore_reLease genutzt.

nachdem der Prozess sich im globalen entwicklungssystem stabilisiert hatte, wurde dieser an die nachfolgenden entwicklungssysteme und namensräume ausgerollt. Bestandscode wird bisher noch nicht gecheckt. zusätzlich ist geplant, ein externes tool einzusetzen, das die Qualitätssiche-rung vereinfacht.

7 uMsetzBarKeit und durCHsetzBarKeit

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 46: Best Practice Leitfaden Development - Über DSAG

46

neben methodischen empfehlungen und Werkzeugen zur unterstützung bei der softwareentwick-lung im saP-system stellen die infrastruktur und die Betrachtung des Lebenszyklus einer softwarekomponente eine wichtige rahmenbedingung für erfolgreiches arbeiten dar. in diesem Kapitel liegt auf diesen beiden aspekten der Fokus.

8.1 inFrastruKtur

eine saP-systemlandschaft ist i.d.r. mehrstufig aufgebaut. nachfolgend werden die einzelnen systeme und ihre Bedeutung dargestellt:

8.1.1 sandbox

die sandbox ist ein reines test- und „spielsystem“. in der sandbox gelten keine einschränkungen in Bezug auf Berechtigungen, das gilt gleichermaßen für Customizing- und Workbench-entwick-lungen. aus der sandbox sind keine transporte in andere systeme erlaubt. Änderungen können ausprobiert werden, bevor sie im entwicklungssystem durchgeführt werden. damit kann der rückbau komplexer entwicklungen in der entwicklungsumgebung vermieden werden, wenn z.B. eine neuentwicklung nicht weiter verfolgt werden soll.

8.1.2 entwicklungssystem

ein kombiniertes entwicklungs-/testsystem (z.B. entwicklungsmandant 010, testmandant 110) bietet sich als einfache und praktikable Lösung an. es ist beispielsweise kein transport von Workbench-objekten erforderlich, um neuentwicklungen zu testen.

im testmandanten herrscht dabei absolutes Customizing-Verbot. Customizing dieses Mandanten wird ausschließlich durch Mandantenkopie aktualisiert (sCC1). entwickler/Modulbetreuer haben im testsystem sehr weitreichende Berechtigungen. einschränkungen müssen individuell festgelegt werden, z.B. für besonders sensible daten (Hr etc.).

Berechtigungen/rollen werden grundsätzlich im entwicklungssystem erstellt und transportiert. Generell werden alle zu transportierenden Änderungen in einem Mandanten im e-system vorgenommen.

8.1.3 Qualitätssicherungssystem

im Qa-system herrscht absolutes Customizing- und entwicklungsverbot. Customizing- und Workbench-objekte werden ausschließlich per ta importiert. importe nach Produktion erfolgen grundsätzlich über das Qa-system. damit wird die Übereinstimmung einer mit Produktion übereinstimmenden systemumgebung sichergestellt.

das Qa-system wird bei Bedarf z.B. für umfangreichere Validierungsaktivitäten aus dem Produktionssystem kopiert. damit wird auch die Übereinstimmung mit der operativen (daten-)umgebung sichergestellt. im Qa-system erfolgt die durchführung von testplänen nach Ände-rungen und neuentwicklungen. entwickler/Modulbetreuer haben im Qa-system sehr weit- reichende Berechtigungen. einschränkungen müssen individuell festgelegt werden, z.B. für besonders sensible daten (Hr etc.). es empfiehlt sich aber auch, testbenutzer mit produktions-nahen Berechtigungen zu verwenden.

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 47: Best Practice Leitfaden Development - Über DSAG

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 und Begrü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 der saP-Basis durchgeführt, ausgenommen die Mandantenkopie innerhalb des test-/entwicklungs- systems.

der transportweg ist wie folgt festgelegt:entwicklung -> Qa -> Produktion

die sandbox sollte aus dem transportweg ausgeschlossen werden. importe in die sandbox erfolgen nur auf individuelle anforderung. dabei ist der transportweg immer entwicklung -> sandbox, nicht umgekehrt!

die importe in das Qa-system müssen in abhängigkeit der systemlandschaft organisiert werden. Falls möglich, können importe in Qa zyklisch und automatisiert durchgeführt werden, um die Mitarbeiter der Basisabteilung zu entlasten.

importe in das Produktivsystem sind explizit unter angabe der ta-nr. freizugeben. Hierfür wird ebenfalls die Verwendung eines geeigneten tools (z.B. solution Manager) zur standardisierung/Formalisierung empfohlen.

BEST PRACTICE: Checkliste vor ausführung eines Workbench-transports:

1. tests erfolgt? sämtliche Funktionen wurden erfolgreich getestet und (kundenseitig) abgenommen

2. Code geprüft? der Code inspector/erweiterte Programmprüfung wurde für alle Programme des transportauftrags durchgeführt: die ergebnisliste darf dabei keine Fehler oder Warnungen enthalten, informationsmeldungen sind zulässig

3. drittanbietertools? sofern weitere testtools für themenbereiche wie security, Performance, … vorhanden sind, wurden diese eingeplant

4. Manuelle Vor-/nacharbeiten? es ist zu prüfen, ob eine vollständige Checkliste für manuelle Vor-/nacharbeiten zum transport vorliegt 5. Mehrsprachigkeit? sofern mehrsprachige objekte im transportauftrag enthalten sind, ist zu prüfen, ob die Übersetzungen vorhanden sind

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 48: Best Practice Leitfaden Development - Über DSAG

48

6. abhängigkeiten in den transporten? Falls ein Vorabtransport durchgeführt wurde, muss auf abhängigkeiten in den transporten geprüft werden

7. namenskonventionen? erstellen einer Liste der transportobjekte und Prüfung der einhaltung der namenskonvention anhand der objektliste

8. dokumentation (systemintern)? a. systemintern: Prüfung aller objekte hinsichtlich erstellter/aktualisierter saP-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 sind bzw. nur ins Qs-system importiert wurden, sind die Änderungen im entwicklungssystem zurück- zubauen. im Falle der nutzung von Quality assurance (Qa) als Genehmigungsworkflow gilt:

> die ablehnung verhindert lediglich den Weitertransport ins Produktionssystem. die abgelehnte entwicklung/Customizing ist aber im entwicklungs- und im Qualitätssicherungssystem noch vorhanden. daraus ergibt sich ein „schiefstand“ zwischen den einstellungen einerseits des entwicklungs-/Qualitätssicherungssystems sowie andererseits des Produktionssystems.

> um den schiefstand zu beseitigen, muss die abgelehnte entwicklung im entwicklungssystem zurückgenommen, dort in einen transportauftrag aufgenommen und ins Qualitätssystem transportiert werden.

> der transportauftrag, der die rücknahme enthält, soll im Qualitätssystem ebenfalls abgelehnt werden. damit wird die Übereinstimmung der einstellungen zwischen den systemen wieder- hergestellt.

> die zuständigen entwickler müssen von abgelehnten transporten erfahren. die Pflicht zur informationsweitergabe soll bei den für die Qa-Genehmigungen zuständigen Personen liegen.

8.1.7 sicherstellung der Konsistenz von neuentwicklungen/erweiterungen

Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. es kann zur über-schneidenden Verwendung von objekten kommen, die es im zielsystem (noch) nicht gibt. dies führt zum Fehler beim import. Hieraus ergibt sich die Pflicht zur Prüfung der von dritten (non-saP) erstellten objekte bei deren Verwendung. neuentwicklungen/erweiterungen müssen in geeigneten Paketen bzw. transportaufträgen gekapselt werden. es wird empfohlen, die transportaufträge für ein Projekt auf je 1 ta für Workbench, Customizing und Berechtigungsrollen einzuschränken.

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 49: Best Practice Leitfaden Development - Über DSAG

49

‚Vorabtransporte’ sollten nur mit Hilfe von „Kopientransporten“ erlaubt sein. die endgültige Freigabe und der transport erfolgt erst zum Projektabschluss. alle Projektmitarbeiter verwenden innerhalb eines Projekts nur aufgaben zu einem jeweils vorgegebenen ta. es gibt keine ‚persönlichen’ transportaufträge für Projektmitarbeiter.

Generell erfolgt ein import nur nach formeller Freigabe (siehe Change-Verfahren) durch einen Process owner, Qs o.ä. instanzen. die abfolge sowie die beteiligten Bereiche müssen 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 Verfahren unabhängig davon, ob es sich um Änderungen am saP-standard oder an Kundenentwicklungen handelt.

das Basiswerk zur einführung eines Change- und releasemanagements ist die information technology infrastructure Library (itiL). in diesem referenzleitfaden sind umfangreiche und allgemeingültige Best Practices beschrieben.

in diesem Kapitel stellen wir einen konkret realisierten Praxisfall aus der entwicklung dar, der firmen- bzw. branchenspezifisch adaptiert werden kann.

Wir empfehlen grundsätzlich, die folgenden aspekte bei der einführung eines Change-Control- (auch: Change-request-)Verfahrens zu berücksichtigen:

> Fachliche anforderung

> Begründung

> Bewertung (aufwandschätzung)

> Genehmigung

> Freigabe der Änderung für das Produktionssystem

der Genehmiger-/Freigeberkreis (Process owner, Qs …) ist abhängig vom Gegenstand der Änderung (betroffener Bereich, betroffene anwendung, gegebenenfalls auch aufwand).

die Verwendung eines geeigneten tools (z.B. solution Manager) wird dringend empfohlen. dabei gilt jedoch: eine papierbasierte Lösung ist besser als keine!

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 50: Best Practice Leitfaden Development - Über DSAG

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 zur abwicklung einer systemänderung erforderlich sind.

Basisprozess und rollen:

> der anforderer füllt den teil ‚anfordernde abteilung’ aus und sorgt für die unterschrift des Process owners/des Process owners fremd

> der Process owner ist in der regel ein Vorgesetzter des anforderers, er ist verantwortlich für einen bestimmten teil der daten bzw. für die nutzung bestimmter teile der saP-software, z.B. der einkaufsleiter für die saP-einkaufsdaten und -programme

> der Process owner fremd ist immer dann einzubeziehen, wenn eine Änderung auch teile betrifft, die außerhalb der eigentlichen zuständigkeit des Process owners liegen

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 51: Best Practice Leitfaden Development - Über DSAG

51

Beispiel: der einkäufer benötigt Berechtigungen aus dem Bereich der anlagenbuchhaltung; hier muss der Process owner zustimmen, der diesen teil des systems verantwortet (z.B. der Leiter der anlagenbuchhaltung).

> eine ausführliche Beschreibung der Änderung ist in jedem Fall dem CC als anlage anzufügen; CCs ohne eine ausführliche Beschreibung werden zurückgewiesen.

> der anforderer gibt das CC an die it weiter.

> der saP-Koordinator ist derjenige, der die anfallenden aktivitäten für saP oder einen teil von saP koordiniert und den einzelnen Modulbetreuern die aufgaben zuweist. diese aufgabe kann – in abhängigkeit der Größe der organisation – auch von einem Gruppen- oder abteilungsleiter innerhalb der it übernommen werden. die betreffende Person trägt die applikation/das Modul im Formular ein und weist das CC einem Bearbeiter zu; sie kann das CC auch aufgrund formaler Fehler (fehlende/unzureichende Beschreibung oder fehlende unter- schrift des Process owners/Process owner fremd) zurückweisen. der saP-Koordinator vergibt eine eindeutige CC-nummer und den CC-titel; die nummer kann z.B. auch von einem Projektverfolgungs-/-dokumentationstool übernommen werden.

> der it-Leiter/Leiter saP genehmigt / lehnt ab / stellt zurück (mit entsprechender Begründung), nachdem der Koordinator genehmigt hat.

> im Falle der Genehmigung erhält der Bearbeiter das CC zur weiteren Bearbeitung; eine Änderung zwecks Weitertransport darf von einem Bearbeiter nicht ohne ein vollständig genehmigtes CC durchgeführt werden.

> nach Fertigstellung lässt der Bearbeiter die Änderung durch den anforderer prüfen.

> entspricht die umsetzung den anforderungen, gibt der anforderer die Änderung zum transport frei; der anforderer bestätigt mit seiner unterschrift die ordnungsgemäße umsetzung; ein transport darf nicht ohne vorangegangene Freigabe durch den anforderer durchgeführt werden.

> saP-Koordinator und it-Leitung bestätigen die ordnungsgemäße umsetzung; ein transport darf nicht ohne vorangegangene Freigabe durch die saP-Koordination und die it-Leitung durchge- führt werden.

> der Bearbeiter übergibt den transport in das Produktionssystem und leitet das CC an die saP- Koordination und die it-Leitung weiter.

der Genehmigungs- und Freigabeprozess und damit auch der inhalt des Formulars kann branchen- spezifisch stark variieren. in pharmazeutischen unternehmen ist beispielsweise grundsätzlich die Qa in das CC-Verfahren eingebunden. darüber hinaus ist es in allen unternehmen üblich, dass bei Überschreiten bestimmter (geschätzter) Projektkostenlimits weitere Genehmiger der umsetzung einer Änderungsanforderung zustimmen müssen. die Genehmigungsstruktur hängt also im Wesentlichen von der jeweiligen unternehmensorganisation ab.

das Formular enthält daher lediglich die Minimalanforderungen an ein CC ohne Berücksichtigung branchen- oder organisationsspezifischer anforderungen.

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 52: Best Practice Leitfaden Development - Über DSAG

52

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

WEITERE QUELLEN: 1. Mathias Friedrich, torsten sternberg, Change request Management mit dem saP solution Manager, saP Press, 20092. information technology infrastructure Library (itiL)

8.3 soFtWareWartBarKeit

die Wartbarkeit von software ist ein Kriterium bei der entwicklung von software und zeigt an, mit welcher energie und mit welchem aufwand Änderungen in einem systemzusammenhang von applikationen durchgeführt werden können. (Quelle: Wikipedia)

technisch ist ein modularer aufbau von objekten entsprechend saP-Praxis, d.h. include-struktur in allen Programmen erforderlich. dies umfasst auch die Verwendung von Funktionsbibliotheken, die auch anderen entwicklern zugänglich sein müssen und von ihnen leicht aufgefunden werden können.

in systemumgebungen mit verschiedenen entwicklungs- und Produktionssystemen (transport-strecken) muss der Grundsatz gelten: gleicher objektname (t-Code, Programm, include, tabelle etc.) bedeutet auch identische Funktionalität.

unterschiedliche Funktionalität bedingt entweder ein eigenes objekt oder – falls möglich – eine entsprechende Customizing-Funktion.

alle entwicklungen/Änderungen/Korrekturen sind sauber zu dokumentieren.

8.4 anPassunGen der saP-FunKtionaLitÄt

um die Funktionalität eines saP-systems an eigene Bedürfnisse anzupassen, gibt es verschiedene Möglichkeiten, die jeweils Vor- und nachteile mit sich bringen: > Modifikation

> z-Kopie, Kopie in Kundennamensraum

> erweiterungen (user-exit, Customer-exit, Badi, enhancement, Bte)

zu den problemlos nutzbaren techniken zählen user-exits, Customer-exits, Btes und Badis. deshalb ist es zu empfehlen, diese zu verwenden, sofern diese vorhanden sind und ihre schnittstelle alle nötigen daten zur Verfügung stellt. Hier eine kurze Beschreibung dieser techniken:

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 53: Best Practice Leitfaden Development - Über DSAG

53

user-exit

user-exits sind unterprogramme, die sich in includes im saP-namensraum befinden, aber nur einmalig von saP ausgeliefert werden und deshalb ohne Probleme „modifiziert“ werden können.

Customer-exit

Customer-exits sind Funktionsbausteine, die zu- und abschaltbar sind und vom Kunden 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

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 54: Best Practice Leitfaden Development - Über DSAG

54

Hinweis: implementierungen von enhancement sections können durch das einspielen von saP enhancement 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 notwendigen testaufwand (tCo!) massiv und führt leicht zu disruption bei einem saP releaseupgrade und eHP. die Verwendung von enhancement sections ist daher sehr sorgfältig zu prüfen.

Bei der Verwendung von enhancements ist die sPau_enH zu abarbeiten, da die enhancements in der regulären sPau-transaktion nicht angezeigt werden. die entscheidung, ob enhancements als erweiterungskonzept genutzt werden sollen, ist also nicht nur abhängig vom realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.

Modifikation

Grundsätzlich sollte nur dann modifiziert, wenn:

> Customizing oder Personalisierung ihre anforderung nicht umsetzen können

> geeignete erweiterungen oder user-exits nicht vorgedacht sind

> das Kopieren des saP-objekts in den Kundennamensraum nicht sinnvoll ist

Für Modifikation/exits/Badis wird – zusätzlich zum Change Verfahren – ein separates Genehmi-gungsverfahren empfohlen. Hierzu gehören antrag -> Begründung -> Genehmigung. die entscheidung muss von dem/den jeweiligen systemverantwortlichen (it-Leitung) getroffen werden. Vorteil hierbei ist, dass der entwickler einen Modifikationsschlüssel eingeben und dieser zentral vergeben werden kann. es kann also relativ einfach verhindert werden, dass ungewollte Modifika- tionen ins system eingebaut werden.

Kopien in eigenen namensraum/z-namensraum

Kopien von saP-standardcode in den Kundennamensraum sind sehr pflegeaufwändig. Bislang gibt es kein automatisiertes Verfahren und keine manuelle regelung, wie ein späterer abgleich (bspw. nach support-Packages oder Hinweiseinbau) zwischen original und z-Kopie erfolgen kann. eine allgemeine empfehlung kann an dieser stelle nicht gegeben werden, da Vor- oder nachteile jeweils im unterschiedlichen Kontext abgewogen werden müssen.

BEST PRACTICE für die durchführung von Modifikationen:

> Grundsätzlich sind Workbench-Modifikationen nur unter Verwendung des Modifikations- assistenten erlaubt!

> eine z-Kopie ist nicht immer die erste Wahl, da dies u. u. mit sehr hohem realisierungsauf- wand verbunden ist. darüber hinaus gehen Weiterentwicklungen im standard unberücksichtigt an der z-Kopie vorbei, d.h., es resultiert ebenfalls ein aufwand für die anpassung bzw. erstellung einer neuen z-Kopie. nach dem einspielen von enhancement Packages können verwendete standard-includes zu Problemen führen.

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 55: Best Practice Leitfaden Development - Über DSAG

55

> die entscheidung Modifikation vs. z-Kopie vs. enhancement ist also nicht nur abhängig vom realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.

> Keine der Möglichkeiten Modifikation/z-Kopie/enhancement hat nur Vor- oder nur nachteile, es ist hier von Fall zu Fall zu prüfen, welche technik die wenigsten nachteile im speziellen Fall mit sich bringt.

> es wird empfohlen, eine zentrale, formalisierte, technische dokumentation aller Modifikationen einzurichten. Für Kopien und erweiterungen sollten geeignete templates bereitgestellt und es sollte eine Pflicht zu deren Verwendung bestehen.

WEITERE QUELLEN: saP schulungen BC425 und BC427

8.5 testBarKeit Von anWendunGen

um die testbarkeit von anwendungen zu gewährleisten, müssen die testanforderungen zu einem sehr frühen zeitpunkt in der entwicklung festgelegt werden. Gewachsenes Coding nachträglich testbar zu machen, ist meistens mit sehr hohem aufwand verbunden, der keine neue 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 es notwendig, die durchführung von tests wiederholbar zu machen. Versuchen sie, den Code so zu schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werden kann. das bedeutet, insbesondere auf dynamische anweisungen zu verzichten, da deren seman-tische Bedeutung erst zur Laufzeit bekannt ist und von einem statischen tool nicht hinreichend analysiert werden kann.

BEST PRACTICE: Verwenden sie von anfang an automatisierte tests (aBaP unit, eCatt), um die automatisierung von tests zu einem „normalen“ Bestandteil der entwicklung zu machen.

BEST PRACTICE: saP unterstützt mit der test-Workbench testgetriebene entwicklungen durch Modultests. testklassen werden als lokale Klassen angelegt und durch den zusatz „For testinG“ als solche kenntlich gemacht. der dort implementierte Programmcode wird lediglich ausgeführt, wenn die anwendung über den Menüpunkt „Modultest“ in der aBaP-Workbench aufgerufen wird. sogenannte risk-Levels geben die Kritikalität eines tests im Falle des scheiterns an und systemeinstellungen verhindern gegebenenfalls, dass ein systemtest einer höheren risikostufe ausgeführt wird. im aBaP-umfeld ist in vielen Fällen die gelungene integration der datenbank ein Hindernis, wenn es um die erstellung von wiederholbaren, automatisierten tests geht. im Vorfeld des tests müssen die betroffenen einträge auf der dB in die Form gebracht werden, die für die jeweilige testausfüh-rung erwartet wird, und Änderungen an der dB durch die testausführung müssen wieder beseitigt werden, um andere tests nicht zu behindern.

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 56: Best Practice Leitfaden Development - Über DSAG

56

BEST PRACTICE: trennen sie in ihren anwendungen die direkte interaktion mit der dB und entfernten systemen, deren Laufzeitverhalten nicht kontrolliert werden kann, von dem eigentlichen anwendungskern. Wenn dieser anwendungskern nicht mehr direkt mit der dB und den entfernten systeme kommuniziert, bieten die dafür benötigten schnittstellen die Möglichkeit, für die durchführung von automatisierten tests die datenkonstellationen zu simulieren.

Werden z.B. alle dB-zugriffe (seLeCt, insert, uPdate, deLete) in einer dB-schicht gekapselt, bietet diese Kapselung den ansatzpunkt, um bei der testausführung mit simulierten daten zu arbeiten, die bei jeder testausführung in einem konsistenten und bekannten zustand sind.

Weitere LinKs:www.testbarkeit.dehttp://de.wikipedia.org/wiki/testbarkeithttp://www.testbarkeit.de/Publikationen/tae05_artikel_jungmayr.pdf

8 inFrastruKtur und LiFeCyCLe ManaGeMent

Page 57: Best Practice Leitfaden Development - Über DSAG

57

die folgenden autoren waren maßgeblich an der erstellung der vorliegenden Fassung des Leitfadens beteiligt:

Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH

Herr Lintner ist zertifizierter Projektmanager (iPMa-Level C) und seit 1998 im Bereich saP aBaP entwicklung tätig. seine schwerpunkte liegen in den Bereichen applikations- und WorkFlow-ent-wicklung, Change- und requestmanagement.

steffen Pietsch, Vice President, iBsolution GmbH

Herr Pietsch ist seit 2003 im entwicklungsnahen umfeld tätig und konnte erfahrungen als entwickler sowie in verschiedenen leitenden Positionen im entwicklungsumfeld sammeln. seit 2009 setzt er sich als sprecher des dsaG-arbeitskreises saP netWeaver development für die interessen der Kunden und Partner in zusammenarbeit mit der saP ein.

Markus theilen, it-Koordinator, eWe aG

Herr theilen ist seit 2001 als entwickler, software- und unternehmensarchitekt tätig und konnte in diesen rollen tiefgreifende erfahrungen in komplexen saP-erP-implementierungen sammeln. seit 2012 steuert er als it-Koordinator im eWe-Konzern die entwicklungstätigkeiten ausgewählter anwendungen. daneben arbeitet er als stellvertretender sprecher des dsaG-arbeitskreises saP netWeaver development in der dsaG e.V. mit.

Jürgen Wachter, Process Coordinator development, comgroup GmbH

Herr Wachter arbeitet seit 2002 im Bereich saP entwicklung. sein fachlicher schwerpunkt liegt im Bereich Core development/enhancements.

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

Herr Werner sammelte von 1988 bis 1999 erfahrungen im Bereich saP r/2 mit den schwerpunkten saP Basis, Logistik und Programmierung (aBaP und assembler). seit 1999 ist er als saP r/3 anwendungsberater für die Module MM, WM und PM tätig und führt aBaP-entwicklung von add ons, schnittstellen und erweiterungen durch.

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

Herr Wiegenstein arbeitet seit 2002 im Bereich saP security. er ist Co-autor des Buches „sichere aBaP-Programmierung“ (saP Press) und hält regelmäßig Vorträge zum thema saP/aBaP sicherheit und Compliance auf internationalen Konferenzen, wie z.B. rsa, Black-Hat, Hack in the Box, troopers, saP teched und auf dsaG-Veranstaltungen.

darüber hinaus haben folgende Personen durch die Bereitstellung von unterlagen, reviewtä-tigkeiten und zahlreiche diskussionen maßgeblich zum aktuellen stand beigetragen:

Michael Cendon, thorsten Franz, Pascal Mannherz, thomas Prang, Markus tradt, tobias trapp, Peter Weigel, Marc zimmek

Besonderer dank gilt der saP, insb. Horst Keller und dr. Wolfgang Weiss, die mit konstruktiven Vorschlägen und reviews die arbeit an diesem dokument unterstützt haben.

9 die autoren

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 58: Best Practice Leitfaden Development - Über DSAG

58

im Folgenden finden sie ein Beispiel, wie namenskonventionen im Bereich der aBaP-entwicklung aufgebaut werden können. dieses Beispiel kann als anhaltspunkt für den aufbau einer eigenen namenskonvention verwendet werden und ist dahingehend branchen- und unternehmensspezi-fisch anzupassen.

allgemeiner Hinweis: objekte im aBaP dictionary haben unterschiedliche Begrenzungen in der anzahl zur Verfügung stehender zeichen. Bei der Benennung der objekte ist dies zu berücksichtigen.

nachfolgend wird der Kundennamensraum y… verwendet. stattdessen kann, wie in Kapitel 2 beschrieben, alternativ der namensraum z… oder ein kundeneigener namensraum /…/ verwendet werden.

abkürzungen

abkürzungen BedeutungMm Modul bzw. Projekt

die abkürzung mm repräsentiert ein saP-Modul (z.B. PP MM) oder ein kundenspezifisches Projekt.

uu arbeitsgebiet

ein arbeitsgebiet erlaubt optional eine feinere unterteilung eines Moduls oder eines Projekts. das arbeitsgebiet wird vom Projekt-

leiter definiert und kommuniziert.

K Konstante

C alphanumerisches zeichen

n numerisches zeichen

… Beliebige Länge

10.1 aLLGeMeine naMensKonVentionen

strukturierende elemente

typ Konvention Beispielentwicklungspakete ymmuu… yPPrueCK

reports ymmuu… ymmuu…

Modulpools saPMyuu saPMyCauB

includes tymmuuccc..._(a)* MyCauB_toP

transaktionen ymm.. yMM01

nachrichtenklasse ymm.. yPPrueCK

Webdynpro aBaP ymm…** yPKs_adMin_1

anmerkungen:*das include beginnt mit dem namen des Modulpools ohne den Präfix „saP“. zum schluss wird

10 anHanG: naMensKonVentionen

Page 59: Best Practice Leitfaden Development - Über DSAG

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 erzeugung von 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 BeispielKlassen 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…)

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 60: Best Practice Leitfaden Development - Über DSAG

60

10.3 MetHoden

Methoden sollten einen kurzen, sprechenden, englischen namen besitzen. Folgende Präfixe deuten auf die aufgabe der Methode:

set_... setzen von Werten

get_... Laden von Werten

send_... senden von informationen

save_... sichern der daten auf die datenbank

etc.

die genaue Funktion sollte in der Beschreibung der Methode stehen. reicht der Platz (60 zeichen) nicht aus, so sollte die ausführliche dokumentation der Methode in der Klassendokumentation erfolgen.

10.4 siGnatur Von MetHoden

die Parameter einer Methode werden wie folgt bezeichnet.

nr. Parameterart Präfix0 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 objektorientierten Programmierung (vgl. 10.4).

BEST PRACTICE: tabellen können auch als import, export oder Changing Parameter übergeben werden, sodass stets Klarheit herrscht, welche tabellen im Funktionsbaustein geändert werden und welche nicht. des Weiteren stellt der syntax-Check im aBaP sicher, dass importparameter nicht verändert werden dürfen.

10 anHanG: naMensKonVentionen

Page 61: Best Practice Leitfaden Development - Über DSAG

61

10.6 enHanCeMents

typ Konvention Beispielenhancement

spot

yes_... yes_MV45a

enhancement

definition

yed_... yed_ MV45a

enhancement

implementation

yei_... yei_ MV45a

10.7 ForMuLare

typ Konvention Beispieladobe 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

typ Konvention BeispielJobs yMM_<Prio>_<BuKrs>_<desC> ysd_1_1000_

<Prio> = Priorität, einstellige zahl, <BuKrs> = Buchungskreis

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 62: Best Practice Leitfaden Development - Über DSAG

62

10.9 dateneLeMente

datentyp Präfixbestandteilelementare 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 namenskonventionLokale 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

Page 63: Best Practice Leitfaden Development - Über DSAG

63

objektorientierte Programmierung:

entität namenskonventionLokale 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]_*

Bes

t P

rac

tic

e Le

itfa

den

dev

eLo

Pm

ent,

31.

Jan

uar

201

3, ©

dsa

G e

. v.

Page 64: Best Practice Leitfaden Development - Über DSAG

© DSAG e. V.