Best Practice Leitfaden Development - DSAG
Best Practice Leitfaden Development - DSAG
Best Practice Leitfaden Development - DSAG
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> <strong>Development</strong><br />
Praxistipps rund um das Thema ABAP <strong>Development</strong><br />
Deutschsprachige SAP-Anwendergruppe e.v.<br />
<strong>DSAG</strong>-ArbeitSkreiS SAP NetWeAver DeveloPmeNt<br />
StAND 31. JANuAr 2013
2<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> development<br />
Praxistipps rund um das thema aBaP development<br />
Version 0.11<br />
stand 31. Januar 2013<br />
dsaG e. V.<br />
deutschsprachige saP-anwendergruppe
autoren<br />
> Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH<br />
> steffen Pietsch, Vice President, iBsolution GmbH<br />
> Markus theilen, it-Koordinator, eWe aG<br />
> Jürgen Wachter, Process Coordinator development, comgroup GmbH<br />
> Michael Werner, saP anwendungsberater (inhouse), Lts aG andernach<br />
> andreas Wiegenstein, Managing director und Chief technology officer (Cto), Virtual Forge GmbH<br />
Weitere informationen zu den autoren finden sie auf seite 57.<br />
© CoPyriGHt 2013 dsaG e.V.<br />
HinWeis:<br />
die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). alle rechte liegen, soweit<br />
nicht ausdrücklich anders gekennzeichnet bei:<br />
deutsCHsPraCHiGe saP ® anWenderGruPPe e.V.<br />
altrottstraße 34 a<br />
69190 Walldorf<br />
deutschland<br />
tel.: 06227 - 35809 58<br />
Fax: 06227 - 35809 59<br />
e-Mail: info@dsag.de<br />
internet: www.dsag.de<br />
Jedwede unerlaubte Verwendung ist nicht gestattet. dies gilt insbesondere für die Vervielfältigung,<br />
Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen systemen / digitalen<br />
Medien.<br />
3<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
4<br />
inHaLtsVerzeiCHnis<br />
1 einLeitunG 7<br />
1.1 Motivation 7<br />
1.2 Positionierung 7<br />
2 ProGraMMierriCHtLinien 8<br />
2.1 namenskonvention 8<br />
2.2 namensraum 8<br />
2.3 einheitlicher und lesbarer Quellcode: Pretty Printer 9<br />
2.4 obsolete anweisungen 12<br />
2.5 syntax-Check und Code inspector 12<br />
2.6 Feste Codierung: Keine „magic numbers“ 13<br />
2.7 tipps beim arbeiten mit transporten 13<br />
2.8 Berechtigungsprüfung im Quellcode 14<br />
2.9 Programmiermodell: objektorientiert vs. prozedural 14<br />
2.10 Weitere Quellen (Programmierrichtlinien/aBaP) 14<br />
3 PerForManCe 15<br />
3.1 Vermeidungsprinzip 15<br />
3.2 Vorhandene Werkzeuge nutzen 15<br />
3.3 Performance-optimierungen nur an kritischen und relevanten stellen 16<br />
3.4 datenmodell und datenzugriff 16<br />
3.4.1 datenmodell und indizes 16<br />
3.4.2 rahmenbedingungen bei datenbankzugriffen 17<br />
3.4.3 datenbankzugriffe 18<br />
3.5 interne tabellen und referenzen 19<br />
3.5.1 Feldsymbole 21<br />
3.5.2 Parameterübergabe 21<br />
3.6 Weiterführende Quellen 21<br />
4 roBustHeit 22<br />
4.1 Fehlerbehandlung 22<br />
4.1.1 sy(st)-suBrC-Prüfungen 22<br />
4.1.2 MessaGe-anweisung 23<br />
4.1.3 Klassenbasierte ausnahmen 23<br />
4.1.4 nicht behandelbare ausnahmen 24<br />
4.2 Korrekte implementierung von datenbank-Änderungen 24<br />
4.2.1 sperrobjekte 24<br />
4.2.2 Verbuchungskonzept 24<br />
4.3 Protokollierung 26<br />
4.4 Praxisbeispiele 26
4.4.1 unvollständige Fallunterscheidungen 26<br />
4.4.2 Wichtige sonstige sy(st)-suBrC-Prüfungen 27<br />
4.5 Weiterführende Quellen 27<br />
5 aBaP-siCHerHeit und CoMPLianCe 28<br />
5.1 Prüfungsrelevante sicherheitsmechanismen im saP-standard 28<br />
5.1.1 Berechtigungsprüfung (a) 28<br />
5.1.2 Mandantentrennung (B) 28<br />
5.1.3 nachvollziehbarkeit (C) 29<br />
5.1.4 dreisystemlandschaft (d) 29<br />
5.1.5 Kontrollierte ausführung von Betriebssystemkommandos (e) 29<br />
5.1.6 Kontrollierte ausführung von sQL-Befehlen (F) 29<br />
5.2 sicherheitsschwachstellen 30<br />
5.3 Compliance-Probleme durch aBaP 31<br />
5.4 testwerkzeuge 32<br />
5.5 Weiterführende Quellen 33<br />
6 doKuMentation 34<br />
6.1 dokumentation unabhängig von entwicklungsobjekten 34<br />
6.2 dokumentation von entwicklungsobjekten 35<br />
6.3 dokumentation im Quelltext 35<br />
6.3.1 dokumentation und Kommentierung von anweisungen/anweisungsblöcken 35<br />
6.3.2 dokumentation von Änderungen 36<br />
6.3.3 Programmkopf 36<br />
7 uMsetzBarKeit und durCHsetzBarKeit 38<br />
7.1 umsetzbarkeit 38<br />
7.1.1 Motivation für einen Prozess 38<br />
7.1.2 erstellung und Pflege des Prozesses 39<br />
7.2 durchsetzbarkeit 40<br />
7.2.1 Manuelle Prüfungen 40<br />
7.2.2 automatische Prüfungen 41<br />
7.2.3 Werkzeuge 42<br />
7.3 erfahrungen und tipps aus der Praxis 42<br />
7.3.1 Qualitätssicherung des Quellcodes 42<br />
7.3.2 zeit und Budget Qa 43<br />
7.3.3 Probleme 43<br />
7.3.4 entscheidungsfindung bei Modifikationen 44<br />
7.3.5 erfahrungsbericht aus der Praxis: Comgroup GmbH 44<br />
5<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
6<br />
inHaLtsVerzeiCHnis<br />
8 inFrastruKtur und LiFeCyCLe ManaGeMent 46<br />
8.1 infrastruktur 46<br />
8.1.1 sandbox 46<br />
8.1.2 entwicklungssystem 46<br />
8.1.3 Qualitätssicherungssystem 46<br />
8.1.4 Produktion 47<br />
8.1.5 transportwesen 47<br />
8.1.6 rückbau von neuentwicklungen 48<br />
8.1.7 sicherstellung der Konsistenz von neuentwicklungen/erweiterungen 48<br />
8.2 Change Management 49<br />
8.3 softwarewartbarkeit 52<br />
8.4 anpassungen der saP-Funktionalität 52<br />
8.5 testbarkeit von anwendungen 55<br />
9 die autoren 57<br />
10 anHanG: naMensKonVentionen 58<br />
10.1 allgemeine namenskonventionen 58<br />
10.2 attribute 59<br />
10.3 Methoden 60<br />
10.4 signatur von Methoden 60<br />
10.5 Funktionsgruppen und -bausteine 60<br />
10.6 enhancements 61<br />
10.7 Formulare 61<br />
10.8 Jobs 61<br />
10.9 datenelemente 62
1 einLeitunG<br />
saP-software zeichnet sich als standardsoftware durch ein hohes Maß an Flexibilität und erweiter-<br />
barkeit aus. in nahezu allen unternehmen, die saP-software einsetzen, finden sich kundenspezifische<br />
anpassungen und ergänzungen. die saP-software unterliegt damit sowohl auf Hersteller-<br />
als auch auf Kundenseite der kontinuierlichen anpassung und erweiterung an sich wandelnde<br />
Kundenbedürfnisse.<br />
das hohe Maß an Flexibilität und erweiterbarkeit von saP-software bringt Vor- und nachteile mit<br />
sich: die software kann optimal an kundenspezifische anforderungen angepasst und damit die Wertschöpfung<br />
durch den einsatz deutlich gesteigert werden. zeitgleich birgt die erweiterbarkeit das<br />
risiko kundenspezifischer entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind.<br />
das ziel dieses dokuments ist es, Praxistipps und denkanstöße zu liefern, um kundenspezifische<br />
entwicklungen wartbar und effizient zu gestalten.<br />
1.1 MotiVation<br />
die arbeit der deutschsprachigen saP-anwendergruppe e.V. (dsaG) fußt auf drei säulen – Wissens-<br />
vorsprung, einflussnahme und netzwerk. das vorliegende dokument wurde von Mitgliedern des<br />
dsaG-arbeitskreises saP netWeaver development initiiert und adressiert die erste säule und damit<br />
den Wissensvorsprung für anwender und Partner.<br />
als autorenteam ist es unser anliegen, das in den unternehmen verteilt und implizit vorliegende<br />
Wissen zum thema entwicklung in einem kompakten dokument anderen dsaG-Mitgliedern zur<br />
Verfügung zu stellen. unser Wunsch ist, dass dieses dokument „lebt“ und mit ihrem erfahrungsschatz<br />
einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf ihr Feedback (am besten<br />
per e-Mail an handlungsempfehlung@dsag.de)!<br />
1.2 PositionierunG<br />
es existieren bereits von der saP und einer ganzen reihe von Fachverlagen sehr gute Publikationen<br />
zu anwendungsentwicklung und erweiterung der saP-Plattform. insbesondere haben auch<br />
autoren der saP mit dem Buch „aBaP-Programmierrichtlinien“, saP Press 2009 bereits einen<br />
Vorstoß in richtung von empfehlungen unternommen, die über reine Beschreibungen der sprache<br />
aBaP und der zugehörigen Werkzeuge hinausgehen.<br />
der Mehrwert dieses dokuments liegt in der zusammenfassung bewährter Vorgehensweisen,<br />
Praxistipps und erprobter regelwerke aus den anwenderunternehmen. diese Guideline soll ihnen<br />
als anwender, entwickler, entwicklungs-, Projekt- oder it-Leiter anregungen und Hilfestellung<br />
geben, um „das rad nicht immer wieder neu erfinden zu müssen“, sondern auf die erfahrungen<br />
anderer aufbauen zu können. dabei erheben die in dieser Guideline vorgestellten empfehlungen<br />
nicht den anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eine<br />
auswahl von Praxistipps dar.<br />
als autorenteam haben wir uns darum bemüht, im spannungsfeld zwischen Überblickswissen und<br />
detailtiefe den richtigen Mix zu finden. daher verweisen wir an entsprechenden stellen auf weiter-<br />
führende Quellen, um nicht ausführlich diskutierte themen redundant wiederzugeben. die erste auf-<br />
lage dieser Guideline ist auf den Bereich aBaP-entwicklung fokussiert. Bei entsprechendem<br />
Feedback und ihrer aktiven unterstützung kann der Fokus auf die JaVa-entwicklung und weitere<br />
themen ausgeweitet werden.<br />
7<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
8<br />
2 ProGraMMierriCHtLinien<br />
dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für anwendungen, die<br />
mit Hilfe der Programmiersprache aBaP erstellt werden. es wird beschrieben, wie mit standardsaP-Mitteln<br />
und disziplin sauber lesbarer und verständlicher aBaP Code entwickelt werden kann.<br />
dies erleichtert die Wartung des Codes bzw. ermöglicht, dass verschiedene interne und externe<br />
Personen effizient an der (Weiter-) entwicklung und Wartung eines Programms zusammenarbeiten.<br />
2.1 naMensKonVention<br />
namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung von<br />
softwareobjekten (z.B. Klassen, Funktionsbausteinen) bzw. zur Benennung von objekten im<br />
Quellcode (z.B. Variablen).<br />
Wir empfehlen ausdrücklich eine namenskonvention als richtlinie für entwicklungen im saP-<br />
system vorzugeben. das ziel der Verwendung einer einheitlichen namenskonvention ist die<br />
deutliche steigerung der Wartbarkeit kundenspezifischer anpassungen und erweiterungen. in der<br />
Konsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnelleren<br />
Problemlösung im Fehlerfall.<br />
die explizit formulierte namenskonvention sollte <strong>Best</strong>andteil der internen ausbildung sein, um<br />
neue Mitarbeiter mit den Grundregeln und unternehmensspezifika vertraut zu machen. zudem hat<br />
es sich bewährt, diese namenskonvention zum Vertragsgegenstand für externe entwickler und<br />
Partnerunternehmen zu machen. automatisierte Überprüfungen stellen die einhaltung sicher (vgl.<br />
Kapitel 7).<br />
BEST PRACTICE: eine exemplarische namenskonvention als Vorlage finden sie im anhang.<br />
2.2 naMensrauM<br />
die trennung von Kundenobjekten und saP-objekten kann über die Präfixe y oder z sowie über<br />
einen eigenen namensraum erfolgen. die syntax lautet wie folgt:<br />
z…<br />
y…<br />
//…<br />
der kundeneigene namensraum kann bei saP registriert werden und ist nach <strong>Best</strong>ätigung<br />
weltweit eindeutig und für das jeweilige unternehmen zur Verwendung registriert. dieses Vorgehen<br />
unterstützt bei der konfliktfreien Vergabe von namen für softwareobjekte.<br />
der Vorteil des kundeneigenen namensraums liegt in der garantierten Überschneidungsfreiheit<br />
beim import fremder objekte in das eigene saP-system (z.B. beim einsatz von Fremdanwendungen,<br />
die per transportauftrag eingespielt werden) und bei zusammenführungen von saP<br />
systemen im rahmen einer Post-Merger integration. durch die reservierung des namensraums<br />
ist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten system ein softwareobjekt mit<br />
dem gleichen Präfix erstellt werden kann.<br />
der nachteil bei der Verwendung des kundeneigenen namensraums liegt darin, dass durch die<br />
durchgängige Verwendung des Präfixes bereits mehrere zeichen „verbraucht“ werden. dies kann<br />
insbesondere bei objekten, die nur wenige zeichen zur Benennung bieten, zu schwierigkeiten<br />
führen. darüber hinaus unterstützen nicht alle objekttypen, z.B. Berechtigungsobjekte, die<br />
Verwendung von namensräumen.
BEST PRACTICE: Wir empfehlen ausdrücklich die Verwendung eines kundeneigenen namensraums.<br />
WEITERE QUELLEN:<br />
1. http://help.sap.com (namensraum einrichten)<br />
2. <strong>Best</strong>-Built applications: http://scn.sap.com/community/best-built-applications<br />
2.3 einHeitLiCHer und LesBarer QueLLCode: Pretty Printer<br />
Übersichtlicher, leserlicher Code erleichtert jedem entwickler die (erneute) einarbeitung in<br />
Quellcode. als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zu<br />
halten, kann der Pretty Printer aus der aBaP-entwicklungsumgebung genutzt werden. Mit einem<br />
einzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. er bietet verschiedene<br />
Möglichkeiten, die über die einstellungen der Workbench konfigurierbar sind. Bereits eine<br />
eingerückte darstellung macht source Code deutlich lesbarer. es wird empfohlen, schlüsselwörter<br />
groß darzustellen. denn dadurch kann man Quelltext auch in ausgedruckter Form und ohne<br />
syntaxeinfärbung noch leicht verstehen. der Pretty Printer ermöglicht auf einfachem Weg die<br />
erstellung von einheitlichem Quellcode trotz unterschiedlicher entwickler.<br />
um die Lesbarkeit des Quelltextes zu erhöhen, empfehlen wir, auf mehrere anweisungen in einer<br />
Codezeile zu verzichten.<br />
Wir empfehlen, die option „standardkommentare einfügen“ zu deaktivieren, da die erzeugten<br />
Kommentare bei Änderungen nicht automatisch angepasst werden und redundante informationen<br />
enthalten.<br />
BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die einstellungen als<br />
einheitliche Vorgabe zu definieren.<br />
Modularisierung<br />
Programme, in denen logische Verarbeitungseinheiten nicht aufgeteilt werden, sind in weiterer<br />
Folge schwer lesbar und damit schwer wart- und erweiterbar.<br />
eine Modularisierungseinheit (Form-routine, Methode, Funktionsbaustein) soll logisch zusammengehörende<br />
anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen<br />
einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigen<br />
anweisungen sind jedoch zu vermeiden.<br />
die Modularisierung dient dazu, trotz Komplexität in der aufgabenstellung, den Programmcode<br />
übersichtlich zu gestalten. zudem sind Programmabschnitte mit derselben Logik zu vermeiden.<br />
Für die praktische umsetzung kann es hilfreich sein, vor Beginn des Programmierens die ersten<br />
Codezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend auszuprogrammieren.<br />
Wo es möglich und sinnvoll ist, ist es ratsam, vom prozeduralen Programmiermodell auf objekt-<br />
orientierte Programmierung überzugehen, um zukunftssicher zu entwickeln und objekte zu<br />
kapseln. insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden.<br />
im rahmen der einführung von aBaP objects fand eine Bereinigung der sprache und Vereinheitlichung<br />
der Konstrukte statt. die Verwendung von aBaP objects führt damit zu einer steigerung der<br />
Wartbarkeit.<br />
9<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
10<br />
2 ProGraMMierriCHtLinien<br />
trennung von Präsentations- und anwendungslogik<br />
in allen Programmen sollte stets eine trennung von Präsentations- und anwendungslogik<br />
erfolgen. dies erlaubt es, ergebnisse und Funktionen der anwendungslogik durch verschiedene<br />
uis (user interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche schnittstelle anderen<br />
systemen bereitzustellen. diese aussage ist für alle gängigen ui-technologien gültig, wobei der<br />
Grad der unterstützung bzw. einhaltung dieser logischen trennung unterschiedlich ist. in einer<br />
Webdynpro aBaP-realisierung ist schon vom Framework eine trennung zwischen Modell- und<br />
ui-Logik vorgesehen. Bei klassischen dynpros und BsPs wird die trennung nicht in gleicher Weise<br />
forciert, aber grundsätzlich kann und sollte die trennung auch in diesen umgebungen umgesetzt<br />
werden. allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu Webdynpro, wo<br />
entsprechende Prüfungen im Code inspector realisiert sind.<br />
ein typisches Beispiel für eine klare trennung von anwendungslogik und ui sind Plausibilisierungsregeln.<br />
Wenn die Plausibilisierung von eingaben in einer bestimmten ui-technologie<br />
entwickelt wird, müssen diese Prüfungen bei einem Wechsel auf eine andere ui-technologie neu<br />
entwickelt werden. um dies zu vermeiden, müssen die Funktionen zur Prüfung von eingaben oder<br />
Parametern unabhängig von der verwendeten ui erstellt und gepflegt werden.<br />
internationalisierung<br />
sprachabhängige texte in Programmen dürfen nicht „hart codiert“ werden, sondern müssen in<br />
textelementen (Programmtexte, Klassentexte, online-text-repository [otr]), standardtexten oder<br />
nachrichtenklassen hinterlegt werden. da alle eigenentwicklungen den anspruch haben sollten,<br />
weltweit eingesetzt zu werden, sollten die wichtigsten sprachen übersetzt werden.<br />
zudem müssen sprachabhängige (customizebare) texte in eigenen texttabellen abgelegt werden.<br />
diese texttabelle besitzt dieselben schlüsselattribute wie die eigentliche Customizing-tabelle.<br />
zusätzlich muss das erste schlüsselattribut nach dem Mandantenfeld das sprachenattribut sein<br />
(datenelement sPrsL oder sPras). zudem muss die Fremdschlüsselbeziehung als jene der<br />
texttabelle gekennzeichnet werden.<br />
BEST PRACTICE: Wir empfehlen, den Code inspector für die suche nach nicht übersetzbaren<br />
texten zu verwenden.<br />
BEST PRACTICE: um spätere Übersetzungen einfach zu gestalten, sollte die Länge der Feldbezeichner<br />
und textelemente möglichst lang gewählt werden. als Faustregel für die Länge von<br />
textelementen hat sich bewährt, die 1,5-fache Länge der nativen Beschreibung vorzusehen.<br />
dynamische Programmierung<br />
in der „klassischen“, statischen entwicklung werden entwicklungsobjekte und der Quellcode zur<br />
designzeit definiert und im saP-system statisch hinterlegt. zur Laufzeit wird der vorgegebene<br />
Programmcode ausgeführt. im Gegensatz dazu ermöglicht die dynamische Programmierung die<br />
Flexibilisierung des Quellcodes. Folgendes Beispiel verdeutlicht die dynamische Programmierung:<br />
im Programmcode wird der name einer aufzurufenden aBaP-Klasse nicht statisch hinterlegt,<br />
sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren name durch den inhalt einer<br />
Variablen definiert ist. dieser name kann z.B. aufgrund von Benutzereingaben variieren.<br />
der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität. der nachteil liegt in der signifikant<br />
steigenden Komplexität und insbesondere in den damit einhergehenden sicherheitsrisiken.
Vorteil:<br />
> deutliche steigerung der Flexibilität<br />
> Beispiel 1: eigener aufbau von user exits<br />
durch die statische definition einer abstrakten Klasse inkl. Methodensignatur wird das Grund-<br />
gerüst für einen „user exit“ vorgegeben. anschließend können mehrere konkrete impleme-<br />
tierungen dieser abstrakten Klasse angelegt werden. innerhalb Quellcodes wird z.B. aus einer<br />
Customizing-tabelle der name der zu verwendenden konkreten Klassenimplementierung<br />
gelesen und diese aufgerufen. somit können unterschiedliche implementierungsvarianten<br />
per Customizing aktiviert/deaktiviert werden.<br />
> Beispiel 2: dynamische WHere-Bedingung<br />
nachteil:<br />
zur Laufzeit wird die WHere-Bedingung für eine datenbankoperation, z.B. seLeCt, in einer<br />
string-Variablen erstellt. dadurch können komplizierte Case-abfragen vermieden werden,<br />
die abhängig von den eingaben verschiedene osQL-Befehle ausführen.<br />
> durch die nutzung von dynamischen aufrufen geht der Verwendungsnachweis innerhalb der aBaP-<br />
entwicklungsumgebung verloren. Problematisch sind dann Änderungen an den aufrufzielen. ein<br />
entwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der von<br />
einem Programm dynamisch aufgerufen wird, bemerkt diese Verwendung über den Verwendungs-<br />
nachweis nicht.<br />
> Bei der dynamischen Programmierung ist i.d.r. zur designzeit keine syntaktische Prüfung möglich;<br />
bei fehlerhafter Belegung der variablen inhalte (z.B. fehlerhafte Klammerung innerhalb einer<br />
dynamischen WHere-Klausel, fehlerhafter name einer Klasse) kommt es zu einem ungeplanten<br />
abbruch des Programms (Kurzdump).<br />
> dynamische Programmierung birgt hohe sicherheitsrisiken, insbesondere dann, wenn die dynamischen<br />
inhalte durch ungeschützten zugriff beeinflussbar sind (z.B. wenn der name einer aufzurufenden<br />
Klasse /eines Funktionsbausteins oder einer WHere-Bedingung durch Benutzereingaben beein-<br />
flusst werden kann, stichwort: Code injection).<br />
BEST PRACTICE: dynamische Programmierung sollte nur sehr dosiert und kontrolliert zum einsatz<br />
kommen. Programmcode, der dynamische anteile enthält, sollte nach dem Vier-augen-Prinzip<br />
kontrolliert und dokumentiert werden, denn er stellt ein potenzielles sicherheitsrisiko dar.<br />
im Kapitel 5.2 wird das thema dynamische Programmierung auch im Kontext sicherheit behandelt.<br />
11<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
12<br />
2 ProGraMMierriCHtLinien<br />
auditierbarkeit von aBaP Code<br />
es muss jederzeit möglich sein, durch manuelle untersuchungen oder statische Codeanalyse-<br />
tools den selbst geschriebenen aBaP Code auf Mängel zu untersuchen. alle Methoden, aBaP-<br />
Coding unsichtbar zu machen, sind daher unzulässig, da sie solche untersuchungen behindern<br />
oder gar gezielt dafür verwendet werden könnten, Hintertüren in ein system zu schleusen.<br />
Verschleierter Code kann auch mit dem debugger nicht mehr untersucht werden. es wird an<br />
dieser stelle explizit darauf verzichtet, die techniken zu erläutern, mit denen Code versteckt<br />
werden kann.<br />
BEST PRACTICE: Verwenden sie insbesondere in der entwicklung im eigenen unternehmen keine<br />
techniken, um ihren Quellcode zu verstecken.<br />
2.4 oBsoLete anWeisunGen<br />
obwohl saP eine strikte abwärtskompatibilität vertritt, muss bei der Verwendung von obsoleten<br />
anweisungen, wie z.B. Kopfzeilen in internen tabellen, berücksichtigt werden, dass hierbei<br />
Probleme auftreten, wenn der Code in Klassen übernommen werden soll. Hier ist zu beachten,<br />
dass es für obsolete sprachelemente immer modernere alternativen gibt. es gibt also eigentlich<br />
außer Gewohnheit wenige Gründe für deren Verwendung, deshalb sollten sie vermieden werden.<br />
BEST PRACTICE: Wir empfehlen den regelmäßigen einsatz eines statischen Codeanalyse-tools,<br />
um obsolete anweisungen zu entdecken. aus den saP-Bordmitteln eignet sich hierzu der Code<br />
inspector bzw. die durchführung des syntax-Checks.<br />
darüber hinaus existieren sehr gute analysewerkzeuge von drittanbietern.<br />
2.5 syntax-CHeCK und Code insPeCtor<br />
der syntax-Check und der Code inspector ermöglichen die Überprüfung des Programmcodes<br />
während der designzeit.<br />
Bei der Freigabe von transporten kann der Code inspector über die se03 global angeschaltet<br />
werden, um Fehler zu erkennen. Hierdurch kann auch die anzahl der transporte verringert<br />
werden, da beim erkennen von Fehlern die Freigabe noch abgebrochen werden kann. die<br />
Behebung kann dann in den bestehenden auftrag aufgenommen werden und es muss kein neuer<br />
transport erzeugt werden.<br />
BEST PRACTICE: der Code inspector wird im saP-standard nur bei Freigabe des transportauftrags<br />
ausgeführt. empfehlenswert ist jedenfalls die Prüfung durch den Code inspector bereits bei<br />
der Freigabe der jeweiligen transportaufgabe.<br />
WEITERE QUELLEN:<br />
die Vorgehensweise der implementierung des dafür notwendigen Badis ist im Buch „Praxishandbuch<br />
saP Code inspector“ (saP Press) beschrieben.
2.6 Feste CodierunG: Keine „MaGiC nuMBers“<br />
die feste (harte) Codierung von texten, zahlen, user-namen, organisationseinheiten, datum etc.<br />
sollte im Quelltext ausdrücklich vermieden werden.<br />
Während der entwicklung kann die direkte Verwendung von hart codierten Werten vermeintlich als<br />
schnelle Vorgehensweise erscheinen. auf den Gesamtlebenszyklus der anwendung bezogen, führt<br />
sie jedoch zu deutlich erhöhten Kosten. die Wartbarkeit und testbarkeit der anwendung werden<br />
langfristig deutlich erschwert.<br />
BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler stelle definiert<br />
werden. Für die Konstantendefinition eignen sich z.B. die attribute globaler Klassen bzw. interfaces.<br />
BEST PRACTICE: alternativ zu harten Codierungen im Quelltext können kundeneigene Customizing-tabellen<br />
verwendet werden. in diesen tabellen werden die Werte, z.B. zahlen, organisationseinheiten<br />
etc. als Konfiguration hinterlegt und bei Programmstart in eine Variable gelesen.<br />
anschließend wird ausschließlich mit dieser Variablen gearbeitet.<br />
die o.g. Vorgehensweisen steigern bei Mehrfachgebrauch die Konsistenz und effizienz der analyse<br />
im Fehlerfall bzw. bei regulären Wartungstätigkeiten. Wir empfehlen ausdrücklich die Kommentierung<br />
der Konstanten und die Bedeutung der Werte an zentraler stelle.<br />
um neue Mitarbeiter bei der ermittlung von Konstanten zu unterstützen, bietet es sich an, diese<br />
entweder außerhalb des systems durchsuchbar zu dokumentieren oder ein suchtool (s. „Weitere<br />
Quellen“) zur Verfügung zu stellen, mit dem innerhalb des systems nach Konstanten gesucht<br />
werden kann.<br />
2.7 tiPPs BeiM arBeiten Mit transPorten<br />
Wenn mehrere entwickler an einem entwicklungsobjekt Änderungen vornehmen, kann dies unter<br />
umständen zu Problemen führen, wenn die transportaufträge nicht in der richtigen reihenfolge in<br />
die produktiven systeme transportiert werden oder andere objekte aus anderen transportaufträgen<br />
fehlen.<br />
BEST PRACTICE: um dies zu vermeiden, sollte mit transport von Kopien gearbeitet werden. dabei<br />
werden die geänderten entwicklungsobjekte durch den eigentlichen transportauftrag im<br />
entwicklungssystem gesperrt und über transport von Kopien werden nur Kopien der objekte in<br />
das Qualitätssicherungssystem transportiert. ein entwickler bemerkt sofort, dass ein anderer<br />
entwickler ggf. das objekt bereits bearbeitet, und kann sich mit dem anderen entwickler<br />
abstimmen. nach abschluss des „Projektes“ wird nur der original-sperrtransport ins Produktivsystem<br />
transportiert.<br />
13<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
14<br />
2 ProGraMMierriCHtLinien<br />
2.8 BereCHtiGunGsPrÜFunG iM QueLLCode<br />
Bei zugriff auf daten und auch deren Präsentation sind die dafür notwendigen Berechtigungsobjekte<br />
zu prüfen. Bei der Verwendung von standardobjekten soll jedenfalls die Prüfung auf die<br />
entsprechenden saP-standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung der<br />
notwendigen rollen). Für kundeneigene datenobjekte können in der regel keine saP-standard-<br />
Berechtigungsobjekte zur Prüfung verwendet werden. zu diesem zweck können kundeneigene<br />
Berechtigungsobjekte implementiert und geprüft werden.<br />
Weitere informationen finden sich im Kapitel 5.1.1<br />
2.9 ProGraMMierModeLL: oBJeKtorientiert Vs. ProzeduraL<br />
die prozedurale entwicklung in aBaP ist inzwischen von saP als obsolet eingestuft worden.<br />
insbesondere die Befehle ForM…endForM und PerForM sind als obsolete anweisungen<br />
eingestuft. Prozedurale entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globale<br />
Variablen und includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen.<br />
objektorientierte entwicklung wurde so konzipiert, dass logisch zusammenhängende aufgaben<br />
einheitlich in objekten zusammengefasst werden können. dadurch wird unter anderem auch die<br />
Wiederverwendbarkeit von Code erhöht. insbesondere können solche objekte auch von anderen<br />
entwicklern für ihre zwecke leicht erweitert oder verändert werden, ohne dass die grundlegenden<br />
Funktionen beeinträchtigt werden (open-Close-Prinzip). andererseits können zentrale Funktionalitäten<br />
oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder schreibzugriff durch<br />
aufrufende Programme geschützt werden.<br />
BEST PRACTICE: Wir empfehlen bei neuentwicklungen möglichst nur noch mit Klassen und<br />
Methoden zu arbeiten und keine ForMs mehr zu verwenden.<br />
WEITERE QUELLEN:<br />
1. Horst Keller und Gerd Kluger, not yet using aBaP objects? eight reasons Why every aBaP<br />
developer should Give it a second Look, sap Professional Journal<br />
2. Horst Keller and Gerd Kluger, netWeaver development tools aBaP, saP aG<br />
3. Bertrand Meyer, objektorientierte softwareentwicklung, Hanser 1990, isBn 3-446-15773-5<br />
4. Consea-Projekt für suche nach Konstanten auf saP Code exchange:<br />
https://cw.sdn.sap.com/cw/groups/consea<br />
2.10 Weitere QueLLen (ProGraMMierriCHtLinien / aBaP)<br />
1. saP dokumentation saP netWeaver as aBaP release 731<br />
http://help.sap.com/abapdocu_731/de/index.htm<br />
in dieser dokumentation ist dem thema Programmierrichtlinien ein eigenes Kapitel gewidmet.
3 PerForManCe<br />
in den folgenden abschnitten empfehlen wir einige regeln, die bei der täglichen arbeit in der<br />
aBaP-entwicklung beachtet werden sollten, um von vorneherein Performance-engpässe zu<br />
vermeiden. Wie an viele anderen stellen der softwareentwicklung hilft es auch im Hinblick auf eine<br />
ausreichende Performance zu wissen, was gemacht werden soll. solange der sinn und zweck<br />
eines Code-stückes nicht klar ist, sollte dies zuerst geklärt werden.<br />
3.1 VerMeidunGsPrinziP<br />
„die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und am<br />
leichtesten zu dokumentierenden teile eines Computersystems sind die, die man weggelassen<br />
hat.“ (Gorden Bell)<br />
BEST PRACTICE: Vermeiden sie jegliches unnötige Coding.<br />
Frei nach diesem Motto sollten sie auch genau prüfen, welcher Code wirklich für die Produktion<br />
gedacht ist, und sämtliche test- und demo-Programme spätestens auf den Q-systemen löschen.<br />
aber auch innerhalb von produktivem Coding sollte immer der ansatz verfolgt werden, nicht mehr<br />
zu tun, als für die aufgabe wirklich benötigt wird. ein einleuchtendes Beispiel dafür ist die regel<br />
zur Vermeidung von *-seLeCts, bei denen der einfachheit halber alle spalten einer tabelle<br />
selektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige spalten benötigt<br />
werden.<br />
anmerkung: diese Vorgehensweise steigert gleichzeitig die robustheit von Programmen.<br />
das Lesen mit Hilfe von *-seLeCt in eine kundeneigene datenstruktur kann zu Fehlern nach<br />
einem upgrade führen,wenn die standardtabelle durch saP erweitert wurde. das explizite Lesen<br />
benötigter spalten schützt vor dieser unschärfe.<br />
3.2 VorHandene WerKzeuGe nutzen<br />
die im saP-system bereits vorhandenen Werkzeuge bieten gute unterstützung bei der erstellung<br />
von performanten anwendungen bzw. bei der analyse von Performance-engpässen. diese<br />
Werkzeuge sollten frühzeitig und in allen Lebensphasen der software angewendet werden.<br />
die nachfolgende tabelle bietet einen Überblick zu den zentralen Werkzeugen:<br />
entwicklung Beschreibung<br />
Code inspector statische Code-analyse und -Prüfungen<br />
se30 / sat Laufzeit-traces<br />
st05 traces für sQL, rFC und enqueues<br />
dB05 Wertverteilungs-analyse für index-design<br />
15<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
16<br />
3 PerForManCe<br />
Laufzeit Beschreibung<br />
sM50/sM66 Übersicht Workprozesse/applikationsserver<br />
debugger schrittweises ausführen von Coding<br />
Memory inspector Vergleich und analyse von speicherabzügen zur<br />
ermittlung von nicht speicherverbrauch und nicht<br />
freigegebenen Heap-objekten<br />
st10 tabellenaufruf-statistiken zur Prüfung von<br />
tabellenpufferung<br />
Post Mortem Beschreibung<br />
st22 analyse von Laufzeitfehlern (z.B. bei speichermangel)<br />
stad Workload-analyse<br />
st04 dB-Performance-Übersicht<br />
BEST PRACTICE: starten sie die Performance-untersuchung mit einem trace in der se30/sat und<br />
konzentrieren sie sich auf den größeren zeittreiber. Wenn die meiste zeit im aBaP-teil verbraucht<br />
wird, analysieren sie weiter mit der se30/sat. Liegt die meiste zeit bei den dB-aufrufen, starten<br />
sie einen sQL-trace mit der st05.<br />
3.3 PerForManCe-oPtiMierunGen nur an KritisCHen und<br />
reLeVanten steLLen<br />
auch wenn man nicht performante Konstrukte bei der softwareentwicklung immer vermeiden<br />
sollte, sollte man sich gleichzeitig bei der notwendigkeit von umfangreicheren Performance-optimierungen<br />
auf die teile der software beschränken, die durch Messung nachgewiesenermaßen die<br />
ursache von langer Laufzeit oder erhöhtem speicherverbrauch sind. auch für Performance-aspekte<br />
trifft die 80/20-regel zu und es gilt daher, die meistens raren ressourcen für eine umfangreiche<br />
Verbesserung auf die 20 % des systems zu konzentrieren, die für 80 % der Laufzeit/des<br />
speicherverbrauchs verantwortlich sind. um an diese stellen zu gelangen, ist der sinnvolle einsatz<br />
der genannten Werkzeuge essenziell.<br />
BEST PRACTICE: Wir empfehlen, die suche nach Performance-engpässen mit dem einsatz der<br />
Laufzeitanalyse se30/sat mit voller aggregation zu beginnen. dadurch sollte deutlich werden, ob<br />
die Laufzeit aus der interaktion mit der datenbank oder der Verarbeitung der geladenen daten im<br />
Hauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher datenbestand<br />
verarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen spur zu folgen. Wird<br />
mehr als die Hälfte der Laufzeit im dB-teil verbraucht, sollte eine genauere analyse der sQL-<br />
Kommandos mit der transaktion st05 erfolgen. Wird mehr Laufzeit im aBaP-teil verbraucht,<br />
erfolgen tiefergehende analysen mit Hilfe der se30/sat, wobei die aggregationsstufen schrittweise<br />
verringert werden, um genauere aussagen über die kritischen Programmstellen zu bekommen.<br />
nach jedem optimierungsschritt sollten die ergebnisse verglichen und dokumentiert werden.
3.4 datenModeLL und datenzuGriFF<br />
3.4.1 datenmodell und indizes<br />
der aufbau des datenmodells bildet die Basis performanter anwendungen. ein mit augenmaß<br />
normalisiertes datenmodell kann effizienter mit daten und indizes arbeiten. Hierzu finden – unabhängig<br />
von der Programmiersprache aBaP – die normalisierungsregeln anwendung.<br />
Beim einsatz von indizes für tabellen empfehlen wir folgende Punkte:<br />
> es sollten max. fünf indizes pro tabelle existieren, wenn häufig ändernd auf diese tabellen<br />
zugegriffen wird. Mit jedem index steigen die Verwaltungskosten, die bei datenänderungen<br />
anfallen.<br />
> Fünf Felder pro index sollten als obergrenze eingehalten werden.<br />
> in einem index sollten nur selektive Felder aufgenommen und in der reihenfolge nach<br />
absteigender selektivität sortiert werden.<br />
> auf Feldebene sollten zwischen zwei indizes einer tabelle keine Überlappungen auftreten.<br />
> Bei mandantenabhängigen tabellen sollte das Feld „Mandant“ als erstes Feld aufgenommen werden,<br />
insbesondere bei großen tabellen (>1000 einträge). auch wenn dieses Feld nicht sonderlich selektiv<br />
ist und damit der dritten regel widerspricht, wird bei jeder abfrage dieses Feld in der selektion<br />
vom saP-system mit übergeben und ausgewertet. Gerade bei tabellen mit stark unterschiedlichen<br />
eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im index negativ auswirken.<br />
3.4.2 rahmenbedingungen bei datenbankzugriffen<br />
Folgende Fragen sollten bei dB-zugriffen gestellt und beantwortet werden:<br />
> sind indizes in geeigneten rahmen angelegt?<br />
> s. vorheriges Kapitel (3.4.1)<br />
> Lesen anweisungen am tabellenpuffer vorbei?<br />
Hierbei kann die transaktion st10 verwendet werden, um die zugriffshäufigkeiten auf gepuffer-<br />
ten tabellen zu überprüfen. Mit der transaktion st05 können mit dem kombinierten sQL- und<br />
Puffer-trace zugriffe ermittelt werden, die wider erwarten den tabellenpuffer nicht verwenden.<br />
und mit Hilfe des Code inspectors lassen sich viele dieser statements bereits im Vorfeld<br />
statisch ermitteln.<br />
> Kann ein dB-index zur sortierung auf der dB mit order By genutzt werden?<br />
im einfachsten Fall kann dafür der zusatz PriMary Key verwendet werden, wenn die sortierung<br />
nach dessen Feldern erfolgen soll. sind andere sortierungen erforderlich, kann es helfen,<br />
einen index anzulegen, der die gewünschten Felder in der korrekten reihenfolge enthält.<br />
allerdings sollten dabei die Hinweise zur anzahl von indizes pro tabelle beachtet werden.<br />
erfolgt der zugriff mit order By nur selten, lohnt es sich in der regel nicht, dafür einen<br />
eigenen index anzulegen. in diesem Fall sollte die sortierung im aBaP erfolgen, sofern dies die<br />
zu sortierende datenmenge zulässt.<br />
17<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
18<br />
3 PerForManCe<br />
Beispiel: die tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nach<br />
diesem datum ermittelt werden. in diesem Fall würde sich ein index über dieses Feld wahr-<br />
scheinlich rentieren, weil zum einen dieses Feld in der WHere-Bedingung enthalten ist und<br />
gleichzeitig der zusatz order By Belegdatum vom vorhandenen index profitiert.<br />
3.4.3 datenbankzugriffe<br />
die auf der datenbank selektierte und an die anwendungsschicht zu übergebende datenmenge<br />
sollte grundsätzlich so gering wie möglich gehalten werden. nachfolgend finden sie Hinweise, wie<br />
sie dies im konkreten Fall umsetzen können.<br />
BEST PRACTICE:<br />
> spaltenreduzierung:<br />
Vermeiden sie *-selektionen und benennen sie stattdessen die benötigen spaltennamen in der<br />
selektion. insbesondere das unnötige Laden von spalten des typs string ist teuer.<br />
die ergebnistabelle sollte mit der selektionsstruktur übereinstimmen, um optimale ergebnisse zu<br />
erzielen. sollten in der ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschten<br />
Felder namensgleich angelegt sein, ist auch der zusatz CorresPondinG FieLds möglich und<br />
führt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die robustheit der software erhöht.<br />
> optimale suchabfrage<br />
Versuchen sie für die selektion von daten möglichst nur abfragen zu verwenden, die einen der<br />
vorhandenen indizes vollständig nutzen. sollte das nicht möglich sein, achten sie möglichst darauf,<br />
zumindest die ersten elemente des index zu verwenden, damit die zeilenweise suche auf eine<br />
möglichst kleine Menge von datensätzen reduziert werden kann.<br />
> zeilenreduzierung<br />
nutzen sie die WHere-Bedingungen, indem sie die selektion beschreiben und die an das<br />
aBaP-system zu übermittelnden daten minimieren.<br />
Verwenden sie seLeCt sinGLe / uP to n roWs, wenn sie nur einzelne zeilen benötigen.<br />
> existenzchecks<br />
die Prüfung, ob datensätze, die einem bestimmten selektionskriterium genügen, existieren,<br />
sollten nicht mit der anweisung Count(*), sondern mit seLeCt sinGLe erfolgen,<br />
wobei das genannte Feld aus dem zur selektion verwendeten index stammen sollte. dies<br />
vermeidet unnötige zugriffe auf die tabellendaten.<br />
> aggregate<br />
aggregate (Min, Max, …) werden immer auf dem datenbankserver ausgewertet. dadurch wird die<br />
tabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem dB-system,<br />
das in vielen installationen von sehr vielen applikationsservern angesprochen wird, sollten<br />
entwickler prüfen, welche datenmenge für das aggregat verwendet werden muss und ob es sich<br />
lohnen kann (sofern diese nicht groß ist), die daten in eine interne tabelle zu laden und das<br />
aggregat dort durchzuführen. allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem<br />
Kenntnisstand insbesondere Hana-basierte datenbankabfragen gerade bei aggregaten ihre<br />
stärken haben und damit deren einsatz für Hana explizit sinnvoll ist.<br />
Beispiel: um den durchschnittlichen Wert über eine große anzahl (>100000) von <strong>Best</strong>ellungen zu<br />
ermitteln, ist es sinnvoll, dieses aggregat auf dem dB-system ermitteln zu lassen, um nur einen<br />
oder wenige Werte statt hunderttausender an die applikationsserver übermitteln zu lassen, um
dort den durchschnittswert im aBaP zu berechnen. dies gilt insbesondere, wenn diese auswertung<br />
nur selten (z.B. einmal pro tag) erfolgt. soll hingegen die summe der <strong>Best</strong>ellpositionen eines<br />
einzelnen auftrags sehr häufig und von allen vorhandenen applikationsservern ermittelt werden,<br />
ist die ermittlung im aBaP wahrscheinlich die für die Gesamtsituation günstigere Variante.<br />
> updates<br />
die anweisung uPdate set ermöglicht das Übertragen von einzelnen zu ändernden Feldern (statt<br />
des gesamten datensatzes). Wenn möglich, sollte diese anweisung bevorzugt verwendet werden.<br />
> ausführungshäufigkeit bei dB-zugriffen<br />
Jede ausführung eines open sQL-statements ist mit einem gewissen overhead (Parsen, abgleich<br />
gegen statement-Puffer im dBMs usw.) verbunden. daher sollten pro statement möglichst viele<br />
der benötigten daten auf einmal übertragen werden. Werden beispielsweise die daten von 50<br />
aufträgen benötigt, sollten diese nicht durch 50 einzelaufrufe ermittelt werden, sondern durch ein<br />
einzelnes statement, das die sog. array-zugriffe unterstützt. diese sind durch die zusätze into<br />
taBLe bei seLeCts bzw. FroM taBLe bei schreibenden zugriffen zu erkennen. Vermeiden sie auf<br />
jeden Fall open sQL-statements innerhalb von schleifen! Bei einem solchen Konstrukt fällt der<br />
overhead für diese statements bei jedem schleifendurchlauf an.<br />
setzen sie ModiFy nicht ein! erstens sollte innerhalb einer applikation klar sein, ob<br />
datensätze neu erstellt wurden oder vorhandene angepasst werden müssen. zweitens ist dieses<br />
statement aus Performance-Gesichtspunkten sehr kritisch: selbst mit dem zusatz FroM taBLe<br />
werden einzelne zugriffe pro zeile der internen tabelle ausgeführt und dabei wird jeweils zuerst<br />
ein uPdate versucht und im Fehlerfall ein insert nachgelegt. d.h., bei vielen neu zu erstellenden<br />
datensätzen erfolgen nicht n einzelzugriffe, sondern 2n mit n=anzahl neue datensätze in der<br />
internen tabelle.<br />
> VieWs/Joins<br />
Geschachtelte seLeCt-anweisungen und seLeCt-anweisungen in schleifen sollten vermieden<br />
werden. stattdessen bieten sich VieWs, Joins oder der zusatz For aLL entries an. Bei For aLL<br />
entries sollte man jedoch auf Folgendes achten:<br />
a. ist die interne tabelle leer, auf der For aLL entries basiert, dann werden alle einträge<br />
geladen.<br />
b. sind in der internen tabelle einträge doppelt vorhanden, kann dies dazu führen, dass die<br />
zugehörigen datensätze auch doppelt von der datenbank geladen werden. es empfiehlt sich daher,<br />
zuvor ein deLete adJaCent duPLiCates aufzurufen.<br />
3.5 interne taBeLLen und reFerenzen<br />
interne tabellen stellen ein zentrales Konstrukt bei der entwicklung von anwendungen mit aBaP<br />
dar. neben datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle von<br />
Performance-Problemen. Bei kleinen datenmengen stellen dinge wie die Wahl der passenden<br />
tabellenart und eines passenden schlüssels noch kein Problem dar. Werden aber größere daten-<br />
mengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht,<br />
können vorher aus Performance-sicht unkritische stellen zu erheblichen Laufzeitverlängerungen<br />
führen.<br />
BEST PRACTICE: Wir empfehlen die Beachtung der nachfolgenden Hinweise zur steigerung der<br />
Performance von anwendungen:<br />
19<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
20<br />
3 PerForManCe<br />
> Wählen sie die tabellenart passend zur späteren Verwendung:<br />
> standard-tabellen eignen sich für daten, die nur selten oder gar nicht nach bestimmten<br />
Kriterien durchsucht werden müssen. Wenn keine suche erfolgen muss, lohnt es sich nicht,<br />
die Kosten für die erstellung und aktualisierung der zusätzlichen schlüsselstrukturen der<br />
anderen tabellenarten zu zahlen. Bei sehr kleinen datenmengen ( sorted-tabellen bieten sich an, wenn die daten häufig nach (teil-)schlüsseln durchsucht<br />
werden müssen, aber keine eindeutigkeit der schlüsselfelder garantiert werden kann.<br />
Gerade zugriffe, die nur mit einem ersten teil der schlüsselfelder stattfinden, können nur<br />
von dieser tabellenart unterstützt werden.<br />
> Hashed-tabellen sind perfekt dafür geeignet, in dictionary-artigen Konstrukten nach ein-<br />
deutigen schlüsseln zu suchen. Wenn die eindeutigkeit der einträge im Hinblick auf die<br />
schlüsselfelder garantiert werden kann und die suchzugriffe immer mit dem vollständigen<br />
schlüssel (=alle Felder des schlüssels werden auf Äquivalenz gegen einen jeweiligen Wert<br />
geprüft) erfolgen, ist diese tabellenart in der regel optimal.<br />
> Wenn für eine tabelle vom typ sorted oder Hashed zugriffe erfolgen, sollten diese immer mit<br />
dem passenden (teil-)schlüssel stattfinden.<br />
dies bedeutet, bei read taBLe den zusatz WitH taBLe Key zu verwenden und bei LooP at<br />
WHere möglichst viele aufeinander folgende Felder des schlüssels mit „=“ zu vergleichen.<br />
dann werden die intern aufgebauten schlüsselstrukturen verwendet, um die passenden<br />
einträge schneller zu ermitteln.<br />
> ab as aBaP 7.02 können sie bei internen tabellen, die selten geändert werden, aber mit mehr<br />
als einem zugriffmuster gelesen werden, neben dem primären schlüssel, der wie gehabt<br />
definiert und verwendet wird, auch weitere sekundäre schlüssel definieren, die auch einen vom<br />
Primärschlüssel abweichenden typ (sorted, Hashed) haben.<br />
als Beispiel können sie damit für eine als Hashed definierte tabelle mit eindeutigem Primär-<br />
schlüssel einen weiteren schlüssel vom typ sorted definieren, der es ermöglicht, performant<br />
auf die daten der tabelle aus einem anderen Blickwinkel (nicht eindeutig, teilschlüssel möglich)<br />
zuzugreifen, ohne die eigentlichen daten zweimal im Hauptspeicher anzulegen und bei<br />
Änderungen manuell für die Konsistenz zwischen beiden tabellen zu sorgen.<br />
> Ähnlich wie bei den dB-zugriffen existieren für interne tabellen einzelsatzzugriffe und<br />
Massenzugriffe.<br />
Wenn möglich, sollten immer die Varianten mit Massenzugriffen gewählt werden, die perfor-<br />
manter arbeiten als mehrere einzelzugriffe. als Beispiel sollten sie beim anhängen von zeilen<br />
einer teilergebnistabelle zur Gesamtergebnistabelle das anweisungsmuster aPPend Lines oF<br />
to verwenden, anstatt die gleiche Funktion über eine schleife LooP at mit einzelnen aPPend<br />
to zu realisieren.<br />
> Bei der Verwendung der anweisung sort sollten sie immer die gewünschten sortierfelder<br />
angeben.<br />
erstens erhöht dies die Lesbarkeit des Codings und zweitens ist bei den wenigsten standard-<br />
tabellentypen ein tabellenschlüssel definiert. Fehlt ein solcher schlüssel, wird die gesamte
zeile der tabelle als schlüssel verwendet und damit bei der sortierung alle Felder der tabelle<br />
geprüft, was zu erheblichen Performance-einbußen führt. soll also z. B. ein tabelle nach den<br />
Feldern Benutzer und datum sortiert werden, verwenden sie die anweisung sort table By<br />
Benutzer datum, auch wenn die tabellenstruktur mit diesen Feldern beginnt und die reihen-<br />
folge des ergebnisses hinsichtlich der geforderten Felder gleich ist.<br />
> Vor dem einsatz der anweisung deLete adJaCent duPLiCates sollte immer sichergestellt<br />
sein, dass die tabelle nach den gleichen Feldern sortiert ist, damit doppelte einträge auch<br />
wirklich eliminiert werden.<br />
Wie die anweisung aussagt, werden nur benachbarte tabellenzeilen verglichen. Wie bei der<br />
sort-anweisung auch sollten immer die Felder angegeben werden, die betrachtet werden<br />
müssen. ansonsten wird auch hier die gesamte zeile feldweise verglichen, auch wenn nur zwei<br />
Felder aus fachlicher sicht dafür ausreichend sind.<br />
> reine existenzprüfungen auf internen tabellen sollten immer mit read taBLe transPortinG<br />
no FieLds durchgeführt werden, wenn auf den daten der ermittelten zeile keine weiteren<br />
operationen stattfinden.<br />
3.5.1 Feldsymbole<br />
Feldsymbole bieten die Möglichkeit, auf existierende daten, z.B. zeilen von internen tabellen, zu<br />
referenzieren. das arbeiten mit referenzen ist deutlich performanter als das Kopieren der daten.<br />
daher sollten, wo möglich, Feldsymbole verwendet werden. nur bei sehr kleinen tabellen gibt es<br />
einen minimalen Vorteil in der Laufzeit zwischen den Kopierkosten bei into und Feldsymbolen.<br />
ansonsten sind Feldsymbole immer schneller, insbesondere dann, wenn die tabelleninhalte<br />
geändert werden sollen. Bedenken sie beim einsatz von Feldsymbolen jedoch, dass eine Änderung<br />
des Wertes eines Feldsymbols auch den Wert im referenzierten datenelement überschreibt.<br />
BEST PRACTICE: Verwenden sie standardmäßig Feldsymbole für die zugriffe auf interne tabellen.<br />
3.5.2 Parameterübergabe<br />
die Wertübergabe von Parametern sollte nur dort eingesetzt werden, wo es aus technischen<br />
Gründen vorgeschrieben ist (z.B. rFC-Funktionsbausteine, returning-Parameter bei funktionalen<br />
Methoden). so werden unnötige Kopierkosten bei der Parameterübergabe gespart. dies gilt in<br />
besonderem Maße bei Parametern mit tiefen datentypen wie internen tabellen oder strings. Wenn<br />
es keine technischen erfordernisse gibt, sollten Parameter immer per referenz übergeben werden.<br />
Weiterhin sollten so wenig Parameter wie möglich definiert werden. optionale Parameter sollten<br />
komplett vermieden werden.<br />
BEST PRACTICE: Verwenden sie so wenig Parameter wie möglich, die per referenz übergeben<br />
werden. nutzen sie die Wertübergabe nur an den technisch notwendigen stellen.<br />
3.6 WeiterFÜHrende QueLLen<br />
> einen guten einstieg in die Performance-optimierung im aBaP bietet der saP-Kurs BC490.<br />
> siegfried Boes, „Performance-optimierung von aBaP-Programmen“, dpunkt Verlag 2009,<br />
isBn 3898646157<br />
21<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
22<br />
4 roBustHeit<br />
dieses Kapitel erläutert, worauf entwickler achten müssen, um robuste aBaP-Programme zu<br />
schreiben. dazu ist es zunächst erforderlich zu definieren, was ein robustes aBaP-Programm<br />
ausmacht.<br />
unter robustheit verstehen wir die Fähigkeit eines Programms, auch unter ungünstigen umständen<br />
weiterzulaufen und korrekte ergebnisse zu liefern. das bedeutet insbesondere, dass<br />
Programme Fehlersituationen erkennen und in einer Weise darauf reagieren, dass die gewünschte<br />
Funktionalität nicht gefährdet wird.<br />
4.1 FeHLerBeHandLunG<br />
die aBaP-Laufzeit hat verschiedene Möglichkeiten, eine anwendung auf Fehlersituationen<br />
hinzuweisen. diese sind hier aufgeführt und die <strong>Best</strong> <strong>Practice</strong>s jeweils erläutert.<br />
4.1.1 sy(st)-suBrC-Prüfungen<br />
Bei einer ganze reihe von aBaP-Befehlen setzt der saP-Kernel nach deren ausführung die<br />
globale Variable sy(st)-suBrC. in der regel wird eine erfolgreiche ausführung durch den Wert 0<br />
angezeigt.<br />
Bei den Befehlen CaLL FunCtion und CaLL MetHod wird sy(st)-suBrC nicht automatisch<br />
gesetzt, wenn es zu Fehlern in dem aufgerufenen Code kommt. sofern die gerufenen Module<br />
sogenannte nicht-klassenbasierte ausnahmen (non-class-based exceptions) verwenden, muss das<br />
aufrufende Programm diese in der exCePtions-sektion beim aufruf korrekt deklarieren und<br />
ihnen einen Wert ungleich 0 zuweisen, damit sy(st)-suBrC gesetzt wird.<br />
BEST PRACTICE: setzen sie explizit den speziellen Wert otHers, da sich die Liste der ausnahmen<br />
systembedingt ändern könnte, nachdem das rufende Programm fertiggestellt wurde. der spezielle<br />
Wert otHers sollte insbesondere beim aufruf von rFC-fähigen Funktionsbausteinen verwendet<br />
werden, da es hier zu verschiedenen speziellen rFC-ausnahmen kommen kann.<br />
die Prüfung von sy(st)-suBrC muss immer unmittelbar nach dem Befehl erfolgen, der diese<br />
globale Variable setzt. Wird die Prüfung erst später durchgeführt, kann der Wert bereits durch<br />
einen anderen aBaP-Befehl überschrieben worden sein.<br />
4.1.2 MessaGe-anweisung<br />
Mit der MessaGe-anweisung können status- oder Fehlermeldungen ausgegeben werden. dabei<br />
unterscheidet sich das Verhalten der MessaGe-anweisung je nach Meldungsart (status,<br />
information, Fehler, abbruch) und ob der auslösende Programmteil im dialog- oder Batchmodus<br />
ausgeführt wird.<br />
BEST PRACTICE: Vermeiden sie MessaGe-anweisungen außerhalb von Modulen, die direkt mit<br />
dem anwender kommunizieren bzw. die in einer definierten dialogschicht liegen. MessaGe-anweisungen<br />
können in bestimmten Konstellationen von Meldungsart und Betriebsmodus implizite<br />
CoMMits aufgrund eines Bildschimwechsels in klassischen dynpros auslösen und führen bei<br />
einem aufruf innerhalb eines rFC-aufrufs zu Verbindungsabbrüchen. Verwenden sie innerhalb des<br />
eigentlichen anwendungskerns klassenbasierte ausnahmen, um auf Fehlersituationen hinzuweisen.
4.1.3 Klassenbasierte ausnahmen<br />
seit einführung von aBaP oo können auch klassenbasierte ausnahmen verwendet werden. diese<br />
arbeiten nach dem Prinzip des „Werfens“ von ausnahmen: ein Programm erkennt einen Fehler und<br />
„wirft“ eine ausnahme in den Call stack. Fängt der aufrufer diese ausnahme nicht, wird sie so lange<br />
weiter im Call stack nach oben propagiert, bis sie an anderer stelle gefangen wird oder zu einem<br />
dump führt.<br />
es ist wichtig, alle ausnahmen zu fangen, auf die in der jeweiligen stelle angemessen reagiert werden<br />
kann, oder ausnahmen in der Methode oder dem Funktionsbaustein zu deklarieren, sodass für den<br />
aufrufer klar ersichtlich ist, dass die Methode bzw. der Funktionsbaustein eine solche ausnahme<br />
aufwerfen könnte. Wichtig ist hierbei die einheitliche Verwendung: Für dieselbe Fehlersituation<br />
sollten einheitliche Fehlerbehandlungen/ausnahmen verwendet werden.<br />
zum Fangen von ausnahmen ist der aBaP-Befehl try…CatCH…endtry gedacht. entsprechend<br />
müssen alle ausnahmen aller Module, die klassenbasierte ausnahmen erzeugen können, von<br />
einem try…CatCH behandelt werden, um einen robusten ablauf zu gewährleisten.<br />
BEST PRACTICE: erlauben sie keine leeren ausnahmebehandlungen.<br />
dadurch wird es aufrufenden stellen unmöglich gemacht, auf ausnahmesituationen angemessen<br />
zu reagieren. Propagieren der ausnahme ist in diesen Fällen die richtige reaktion.<br />
BEST PRACTICE: Vermeiden sie beim Fangen von ausnahmen die globale Basisklassen Cx_root.<br />
im CatCH-Block wird die angabe der exception-Klasse die zu fangende ausnahme spezifiziert, z.B.<br />
Cx_sy_zerodiVide zum abfangen eines Fehlers aufgrund der division durch null. Hierbei gilt es<br />
konkrete ausnahmen abzufangen, um diese spezifisch zu behandeln. das Fangen der allgemeinsten<br />
ausnahme Cx_root sollte nur erfolgen, wenn die ausnahmebehandlung tatsächlich in der<br />
Lage ist, mit unbekannten Fehlersituationen umzugehen.<br />
BEST PRACTICE: Wählen sie die grundlegende art von eigenen ausnahmeklassen durch die<br />
Vererbung von vordefinierten Basisklassen (statiC_CHeCK, dynaMiC_CHeCK, no_CHeCK) mit<br />
Bedacht.<br />
Beim einsatz von statiC_CHeCK wird jeder Verwender durch syntaxfehler gezwungen, für jede<br />
dieser ausnahme zu entscheiden, ob er sie direkt behandeln kann, weiterreicht und damit in seine<br />
deklaration aufnehmen muss oder über das Verketten mit eigenen ausnahmeklassen verpackt.<br />
alle diese Möglichkeiten sind mit aufwand und Änderungen verbunden, die den Vorteil der<br />
klassenbasierten ausnahmen (Propagieren von ausnahmen, die nicht direkt behandelt werden<br />
können) zunichtemachen. Verwenden sie bei der nachträglichen einführung von ausnahmeklassen<br />
daher bevorzugt dynaMiC_CHeCK, um nicht allen ausnahmen die o.g. anpassungen aufzuzwingen.<br />
setzen sie statiC_CHeCK bewusst ein, um aufrufer dazu zu zwingen, sich mit der ausnahmesituation<br />
auseinanderzusetzen.<br />
die ausnahmenklasse no_CHeCK bietet sich für solche Fehlersituationen an, auf die kaum eine<br />
aufrufende stelle angemessen reagieren kann. Beispiele dafür sind das Wegbrechen von sekundären<br />
datenbankverbindungen oder andere dinge, die durch das Coding nicht korrigiert werden können.<br />
23<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
24<br />
4 roBustHeit<br />
4.1.4 nicht behandelbare ausnahmen<br />
es gibt ausnahmen, die vom aBaP Code aus nicht behandelt werden können und dadurch zwangs-<br />
läufig zu einem abbruch der anwendung und einem dump führen. in einigen Fällen ist es möglich,<br />
pro aktiv vor der ausführung eines statements, das eine nicht behandelbare ausnahme auslöst,<br />
die rahmenbedingungen zu prüfen.<br />
Beispiel:<br />
das statement oPen dataset löst einen shortdump aus, wenn der Benutzer keine ausreichenden<br />
Berechtigungen zum Öffnen der datei hat. um dies zu vermeiden, muss die Berechtigung pro aktiv<br />
vom aBaP geprüft werden (FuBa autHority_CHeCK_dataset), damit oPen dataset nicht zu<br />
einem dump führt.<br />
4.2 KorreKte iMPLeMentierunG Von datenBanK-ÄnderunGen<br />
4.2.1 sperrobjekte<br />
um dateninkonsistenzen zu vermeiden, müssen die entsprechenden objekte vor Veränderung auf<br />
der datenbank gesperrt werden. zusammenhängende objekte dürfen erst verändert werden, wenn<br />
alle zugehörigen entitäten erfolgreich gesperrt werden. damit ist keine parallele datenänderung<br />
möglich.<br />
die saP-sperre besteht über mehrere datenbank-LuWs (Logical unit of Work) hinweg, sodass<br />
konsistent Änderungen auf der datenbank für das gesamte zu ändernde Businessobjekt geschrieben<br />
werden können.<br />
die sperren sind so genau wie möglich abzusetzen, um nur die relevanten objekte innerhalb der<br />
LuW zu sperren. zudem sind die sperren so lange wie nötig und so kurz wie möglich zu halten.<br />
Für die Änderung von saP-standard-datenobjekten direkt auf der datenbank sind die entsprechenden<br />
saP-standard-sperrfunktionen zu verwenden, da diese auch von den standard-transaktionen<br />
verwendet werden und so ein konsistentes Verhalten sicherstellen.<br />
Für kundeneigene entwicklungen sind entsprechende sperrobjekte mit den zugehörigen<br />
sperrfunktionen zu implementieren.<br />
die sperren sind nach abschluss des updates auf das objekt aufzuheben. dies erfolgt mittels<br />
aufruf des dequeue-Funktionsbausteins. Beachten sie dabei den wichtigen scope-Parameter,<br />
wenn in diesem zusammenhang auch Verbuchungsbausteine verwendet werden.<br />
WEITERE QUELLEN:<br />
1. http://help.sap.com/saphelp_nW70/helpdata/de/7b/f9813712f7434be10000009b38f8cf/frameset.htm<br />
4.2.2 Verbuchungskonzept<br />
die Verbuchung ist die zentrale technik zur Bündelung von datenbankänderungen in einer einzigen<br />
datenbank-LuW und damit zur definition von saP-LuWs in saP-transaktionen. datenänderungen<br />
sollen nicht mit dML-Kommandos (dataManipulati-onLanguage-Kommandos insert, update,<br />
delete, Modify) aus der applikation, sondern über den Verbucher durchgeführt werden.
dabei stehen folgende Möglichkeiten zur Verfügung:<br />
> asynchrone Verbuchung<br />
> asynchrone Verbuchung in abschnitten<br />
> synchrone Verbuchung<br />
die Verbuchung wird mit eigenen Verbuchungsfunktionsbausteinen durchgeführt. diese sind bei<br />
der anlage entsprechend in den eigenschaften zu kennzeichnen. diese Funktionsbausteine werden<br />
mit dem zusatz „in uPdate tasK“ aufgerufen und unterliegen bei der entwicklung einigen<br />
restriktionen. alle bis zu einem „CoMMit WorK“ gerufenen Verbuchungsfunktionen werden in<br />
einer LuW auf die datenbank geschrieben.<br />
Beim aufruf der sperrfunktionsbausteine ist auf die korrekte Parametrierung (insbesondere<br />
sCoPe-Parameter) zu achten!<br />
Fehlerhafte Verbuchungssätze müssen in der transaktion Verbuchungsaufträge (sM13) administriert<br />
und nachbehandelt werden. aus revisionsgründen ist es empfehlenswert, die nachbearbeitung<br />
der fehlerhaften Verbuchungssätze zu dokumentieren.<br />
WEITERE QUELLEN:<br />
1. saP dokumentation „techniken der Verbuchung“:<br />
http://help.sap.com/saphelp_nw70/helpdata/de/41/7af4cba79e11d1950f0000e82de14a/content.htm<br />
4.2.2.1 asynchrone Verbuchung<br />
die Funktionsbausteine werden in den eigenschaften mit „start sofort“ oder in ausnahmefällen mit<br />
„start sofort – nicht nachverbuchbar“ angelegt. die Verbuchung wird sofort nach abschluss der<br />
LuW gestartet, jedoch asynchron durchgeführt.<br />
4.2.2.2 asynchrone Verbuchung in abschnitten<br />
die Funktionsbausteine werden in den eigenschaften mit „start verzögert“ angelegt. die Verbuchung<br />
wird sofort nach abschluss der LuW gestartet, wird jedoch asynchron in eigenen Prozessen<br />
mit niedriger Priorität durchgeführt. diese art der Verbuchung ist für das schreiben von großen<br />
datenmengen geeignet, wenn die Verbuchung nicht zeitkritisch erfolgen muss (z.B. Ladeprogramme,<br />
Protokollierung ...).<br />
4.2.2.3 synchrone Verbuchung<br />
die Funktionalität und die notwendigen einstellungen sind analog zu jenen im Punkt 4.2.2.1<br />
asynchrone Verbuchung. die LuW muss jedoch mit „CoMMit WorK and Wait“ abgeschlossen<br />
werden.<br />
diese art der Verbuchung wird dann gewählt, wenn die geänderten daten sofort benötigt werden,<br />
z.B. wenn man LuWs koppeln will und eine LuW vom ergebnis der vorherigen LuW abhängt.<br />
25<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
26<br />
4 roBustHeit<br />
4.3 ProtoKoLLierunG<br />
Generell sollten Fehler, ausnahmen und Meldungen ins Business application Log gespeichert<br />
werden, um diese an zentraler stelle (transaktion sLG1) prüfen zu können. Mit der transaktion<br />
sLG0 können darüber hinaus eigene objekte zur Protokollierung definiert werden.<br />
der Vorteil bei der Verwendung des Business application Logs liegt in folgenden aspekten<br />
begründet:<br />
1. zentrale ablage: im Business application Log können Meldungen an zentraler stelle verwaltet<br />
werden; dies erleichtert den Überblick und die administration der anwendungen<br />
2. Wiederverwendbarkeit: das Business application Log bzw. die zugehörigen Bausteine/Klassen<br />
bieten einen guten Funktionsumfang für das thema Logging – dieser muss nicht „neu erfunden“<br />
werden. zu diesen Möglichkeiten zählen u.a.<br />
a. integration zusätzlicher Felder in die Protokollierungsobjekte<br />
b. Hierarchiedarstellung von Meldungen (zusammenfassung zu Problemklassen möglich)<br />
c. interaktivität (nachlesen von informationen bei aufruf einer Meldung und anreichern von<br />
informationen)<br />
d. Persistenz: speicherung von Meldungen im Log möglich<br />
e. integration der Protokollanzeige in eigene anwendungen/uis (sub-screen/Control/Popup)<br />
BEST PRACTICE: Für die Protokollierung sollten die von saP vorgesehenen Funktionsbausteine in<br />
der Funktionsgruppe sBaL verwendet werden. die Beispielprogramme „sBaL_deMo*“ bieten<br />
einen guten einstieg und Überblick.<br />
Bitte beachten sie bei der implementierung die saP-standardhilfe bzgl. der Verwendung der<br />
Funktionsbausteine im jeweiligen release.<br />
WEITERE QUELLEN:<br />
1. saP application Log – <strong>Leitfaden</strong> für anwender<br />
http://help.sap.com/saphelp_nw70ehp2/helpdata/de/3a/c8263712c79958e10000009b38f936/<br />
frameset.htm<br />
2. Beispiele zur Verwendung der BaL Funktionen in:<br />
thorsten Franz, tobias trapp, „anwendungsentwicklung mit aBaP objects, saP Press, isBn-10:<br />
3836210630<br />
4.4 PraxisBeisPieLe<br />
in diesem abschnitt finden sich noch einige robustness-Probleme, die in audits immer wieder<br />
auftauchen.<br />
4.4.1 unvollständige Fallunterscheidungen<br />
Für Case statements wird empfohlen, alle vorhandenen WHen-Blöcke auszuprogrammieren.<br />
außerdem sollte immer ein WHen otHers-Block vorhanden sein, um Fälle zu behandeln, die zur<br />
zeit der entwicklung noch nicht abzusehen waren bzw. unterwartet sind.
Bei iF-abfragen ist darauf zu achten, dass auch die eLse/eLseiF-zweige ausprogrammiert<br />
werden, sofern diese im jeweiligen Kontext sinn machen.<br />
4.4.2 Wichtige sonstige sy(st)-suBrC-Prüfungen<br />
sy-suBrC-Prüfungen sollten möglichst immer stattfinden, wenn aBaP-Befehle rückgabewerte<br />
liefern. das ist wichtig, um die integrität des systems auch im Fehlerfall zu gewährleisten. es wird<br />
daher empfohlen, zumindest im umgang mit dateien und datenbanktabellen Prüfungen auf<br />
sy(st)-suBrC durchzuführen.<br />
im Folgenden sind die relevanten aBaP-Befehle gelistet, für die sy(st)-suBrC aus sicht der<br />
robustheit immer geprüft werden sollte und die in diesem Kapitel noch nicht erwähnt wurden:<br />
> oPen dataset<br />
> read dataset<br />
> deLete dataset<br />
> seLeCt sinGLe<br />
> deLete dbtab<br />
> ModiFy dbtab<br />
> insert dbtab<br />
> uPdate dbtab<br />
4.5 WeiterFÜHrende QueLLen<br />
1. Liste einiger Befehle, die sy-suBrC setzen:<br />
http://wiki.sdn.sap.com/wiki/display/aBaP/sy-subrc<br />
27<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
28<br />
5 aBaP-siCHerHeit und CoMPLianCe<br />
dieses Kapitel beschreibt, in welcher Weise sich Programmierfehler im aBaP negativ auf die<br />
sicherheit eines unternehmens auswirken können. da dieses thema sehr komplex ist, können wir<br />
im rahmen dieses dokuments nur ein paar ausgewählte, zentrale themen behandeln. Für<br />
weitergehende Fragen verweisen wir auf die Literaturhinweise am ende dieses Kapitels. zunächst<br />
müssen wir die Begriffe sicherheit und Compliance in diesem Kontext erklären:<br />
Wir sprechen von einer sicherheitsschwachstelle, wenn ein Programmierfehler einen ungewollten<br />
nebeneffekt verursacht, durch den ein angreifer unbefugt schadhafte aktionen ausführen kann.<br />
Wir sprechen von einem Compliance-Verstoß, wenn ein anwender aufgrund eines Programmierfehlers<br />
einen prüfungsrelevanten sicherheitsmechanismus des saP-standards umgehen kann.<br />
ein wichtiger unterschied ist, dass sicherheitsfehler im Code angriffe durch Hacker (z.B.<br />
industriespionage) ermöglichen, wohingegen Compliance-Verstöße im Code potenziell gesetzliche<br />
auflagen verletzen (z.B. sox) und/oder bei einer Wirtschaftsprüfung moniert werden.<br />
5.1 PrÜFunGsreLeVante siCHerHeitsMeCHanisMen iM<br />
saP standard<br />
Bevor wir näher auf schwachstellen eingehen, ist es wichtig, sich noch einmal ein paar zentrale<br />
schutzmechanismen des saP-standards vor augen zu führen. diese sind Grundvoraussetzung für<br />
den sicheren Betrieb von saP-systemen.<br />
5.1.1 Berechtigungsprüfung (a)<br />
rollen und Berechtigungen sind ein zentrales sicherheitsthema im saP-umfeld. es ist daher<br />
wichtig zu verstehen, dass aBaP ein sogenanntes explizites Berechtigungsmodell verwendet. das<br />
bedeutet, dass Berechtigungsprüfungen explizit im Code programmiert werden müssen, damit sie<br />
auch ausgeführt werden. das beste Berechtigungskonzept nützt nichts, wenn selbstgeschriebener<br />
Code die erforderlichen Berechtigungen nicht (richtig) prüft.<br />
sicherheitsprobleme ergeben sich z.B. in folgenden Fällen:<br />
> der entwickler vergisst, die Berechtigungsprüfung zu programmieren.<br />
> der entwickler verwendet das falsche Berechtigungsobjekt.<br />
> der entwickler verwendet eine proprietäre Berechtigungsprüfung.<br />
> der entwickler behandelt den rückgabewert der Prüfung nicht.<br />
5.1.2 Mandantentrennung (B)<br />
der saP-standard trennt automatisch alle datenbankzugriffe nach Mandanten auf. ein aBaP-<br />
Programm darf immer nur die daten des Mandanten verarbeiten, an dem sich der anwender angemeldet<br />
hat.<br />
sicherheitsprobleme ergeben sich in folgenden Fällen:<br />
> der entwickler umgeht die Mandantentrennung (vorsätzlich) durch technische optionen im<br />
open sQL (CLient sPeCiFied).<br />
> der entwickler verwendet natives sQL, das generell keine implizite Mandantentrennung<br />
durchführt.
5.1.3 nachvollziehbarkeit (C)<br />
die meisten Geschäftstransaktionen müssen nachvollziehbar sein, insbesondere in der Finanzbuchhaltung.<br />
selbstgeschriebener aBaP Code darf anwendern nicht ermöglichen, relevante<br />
aktionen zu verschleiern.<br />
sicherheitsprobleme ergeben sich in folgenden Fällen:<br />
> der entwickler vergisst, für wichtige tabellen Änderungsbelege zu schreiben.<br />
> der entwickler ermöglicht (unbeabsichtigt) einen sogenannten identitätsdiebstahl.<br />
> der entwickler verändert direkt tabelleninhalte, ohne standardfunktionsbausteine zu verwenden<br />
(und damit implizit die Protokollierung zu verwenden).<br />
5.1.4 dreisystemlandschaft (d)<br />
der saP-standard sieht vor, für entwicklung, Qualitätssicherung und Produktion getrennte<br />
systeme (d, Q, P) zu verwenden. dies dient in erster Linie dazu, die Produktivdaten vor unzureichend<br />
getesteten Programmen zu schützen und die umfangreichen rechte der entwickler auf das<br />
entwicklungssystem zu beschränken.<br />
sicherheitsprobleme ergeben sich in folgenden Fällen:<br />
> der Code kann nicht (vollständig) auf dem Q-system getestet werden.<br />
> der entwickler verwendet Befehle, die es anwendern möglich machen, auf dem Produktivsystem<br />
Code zu entwickeln.<br />
5.1.5 Kontrollierte ausführung von Betriebssystemkommandos (e)<br />
aBaP hat die Möglichkeit, auch Betriebssystemkommandos auszuführen. da das potenziell sehr<br />
gefährlich ist, stellt der standard transaktionen (sM49/sM69) zur Verfügung, mit denen man eine<br />
Liste erlaubter Befehle definieren und die erlaubten Befehle auch noch durch spezielle Berechtigungen<br />
zusätzlich schützen kann.<br />
sicherheitsprobleme ergeben sich in folgenden Fällen:<br />
> der entwickler verwendet einen alternativen Weg, um Betriebssystemkommandos auszuführen.<br />
d.h., er umgeht die Liste der erlaubten Befehle und die daran gekoppelten Berechtigungen.<br />
5.1.6 Kontrollierte ausführung von sQL-Befehlen (F)<br />
der open-sQL-standard ermöglicht den zugriff auf die datenbank von aBaP aus nur mit einem<br />
sehr limitierten satz an Befehlen, die zusätzlich alle statisch deklariert werden müssen. dadurch<br />
können gefährliche sQL-Befehle in der datenbank abgeschirmt werden.<br />
sicherheitsprobleme ergeben sich in folgenden Fällen:<br />
> der entwickler verwendet native sQL-Befehle, um mit der datenbank zu kommunizieren.<br />
dadurch können beliebige Befehle ausgeführt werden, die die datenbank beschädigen.<br />
> der entwickler verwendet dynamische optionen von open-sQL-Befehlen und ermöglicht dadurch<br />
injection-angriffe.<br />
29<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
30<br />
5 aBaP-siCHerHeit und CoMPLianCe<br />
5.2 siCHerHeitssCHWaCHsteLLen<br />
applikationssicherheit ist in vielen Programmiersprachen schon seit Jahren ein wichtiges thema.<br />
in aBaP wurde dieses thema jedoch häufig nicht erkannt bzw. falsch eingeschätzt. ein wesentlicher<br />
Grund dafür ist der falsche Glaube, dass man saP-systeme durch rollen und Berechtigungen<br />
absichern kann. dies mag für den saP-standard zutreffen, aber definitiv nicht für selbst-<br />
entwickelten Code. Wie bereits weiter oben erläutert, werden z.B. Berechtigungen nur geprüft,<br />
wenn der aBaP Code eine Prüfung auch explizit durchführt.<br />
Folgende arten von schwachstellen sind im aBaP besonders häufig zu beobachten:<br />
> Fehlende bzw. falsche Berechtigungsprüfungen<br />
der aBaP Code führt operationen aus, für die ein Berechtigungsprüfung erforderlich ist,<br />
überprüft aber die Berechtigung des Benutzers nicht bzw. nicht richtig.<br />
> injection-Probleme<br />
der aBaP Code verwendet dynamische Befehle, die aus Benutzereingaben zusammengefügt<br />
werden. Wenn hier nicht durch input-Validierung bzw. output-encoding verhindert wird, dass<br />
steuerzeichen in den eingaben die semantik des dynamischen Befehls verändern können, dann<br />
kann der dynamische Befehl zur Laufzeit schadhaft verändert werden.<br />
> aushebelung von sicherheitsmechanismen des standards<br />
aBaP Code darf einen bestehenden sicherheitsmechanismus nicht gezielt umgehen. Beispiele<br />
sind proprietäre Berechtigungsprüfungen (basierend auf sy-unaMe), mandantenübergreifende<br />
datenbankzugriffe, ausführung von Betriebssystemkommandos über Kernelfunktionen.<br />
Folgende schwachstellen sind im aBaP besonders häufig zu beobachten. die spalte „std“ zeigt<br />
dabei an, welcher sicherheitsmechanismus des saP-standard dabei beeinträchtigt wird.<br />
id schwachstelle Beschreibung std<br />
aPP-01 aBaP Command injection ausführung von beliebigem<br />
aBaP Code<br />
aPP-02 os Command injection ausführung beliebiger<br />
Betriebssystem-Kommandos<br />
aPP-03 native sQL injection ausführung beliebiger nativer<br />
sQL-Kommandos<br />
aPP-04 improper authorization<br />
(Missing, Broken, Proprietary,<br />
Generic)<br />
Fehlende oder fehlerhafte<br />
Berechtigungsprüfung<br />
aPP-05 directory traversal unerlaubter schreib-/<br />
Lesezugriff auf dateien (saP<br />
server)<br />
aPP-06 direct database Modifications unberechtigter schreibzugriff<br />
auf tabellen<br />
d<br />
e<br />
F<br />
a<br />
C
id schwachstelle Beschreibung std<br />
aPP-07 Cross-Client database access Mandantenübergreifender<br />
zugriff auf Geschäftsdaten<br />
aPP-08 open sQL injection schadhafte Manipulation von<br />
datenbankbefehlen<br />
aPP-09 Generic Module execution unerlaubte ausführung von<br />
Modulen (reports, FuBas etc.)<br />
aPP-10 Cross-site scripting Manipulation des Browser ui,<br />
diebstahl von Berechtigungen<br />
aPP-11 obscure aBaP Code einschränkte auditierbarkeit<br />
durch Verschleierung von Code<br />
abbildung 1: BizeC aPP/11 – die derzeit verbreitetsten sicherheitsprobleme in aBaP-Code<br />
QUELLE: http://www.bizec.org/wiki/BizeC_aPP11<br />
dieses Kapitel kann bei Weitem nicht die notwendigen details liefern, um sicheren aBaP-Code zu<br />
programmieren. Wir verweisen hier auf die Literaturempfehlung #1 am ende des Kapitels.<br />
die folgende Liste enthält eine Übersicht über saP-Meldungen, die Gegenmaßnahmen zu einigen<br />
der oben beschriebenen Probleme beschreiben.<br />
saP note schwachstelle<br />
1520356 sQL injection<br />
887168, 944279, 822881 Cross-site scripting<br />
1497003 directory traversal<br />
abbildung 2: saP oss notes, die Gegenmaßnahmen beschreiben<br />
selbstverständlich empfiehlt es sich, saP-sicherheitshinweise zeitnah zu prüfen und einzuspielen.<br />
diese lösen allerdings nur sicherheitsdefekte im saP-standardcode. eine regelmäßige Prüfung<br />
der eigenentwicklungen ist daher zwingend erforderlich.<br />
5.3 CoMPLianCe-ProBLeMe durCH aBaP<br />
das thema applikationssicherheit wurde in der Vergangenheit selten mit Compliance in Verbindung<br />
gebracht, ist aber für Wirtschaftsprüfungen durchaus relevant (siehe Literaturempfehlung #2).<br />
die meisten unternehmen verfügen über ein internes Kontrollsystem (iKs), das Compliancerisiken<br />
entgegenwirkt. dies ist beispielsweise in den international anerkannten referenzmodellen<br />
Coso & CoBit beschrieben. in einer typischen iKs-struktur sind die „Generellen it-Kontrollen“<br />
(itGC-it General Controls) Voraussetzung für das erreichen aller iKs-ziele im it-dominierten umfeld.<br />
B<br />
F<br />
a<br />
C<br />
d<br />
31<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
32<br />
5 aBaP-siCHerHeit und CoMPLianCe<br />
ein elementarer Baustein der itGC ist das Änderungswesen (Change Management), zu dem<br />
wiederum eigenentwicklungen zählen. sicherheitsdefekte im selbstgeschriebenen aBaP-Code<br />
stellen eine Verletzung der generellen it-Kontrollen dar und erschüttern damit die Grundmauern<br />
jedes internen Kontrollsystems.<br />
abbildung 3: iKs-risiken durch unsicheren aBaP-Code<br />
dies bedeutet insbesondere, dass sicherheitsdefekte im aBaP-Code potenziell nicht nur<br />
auswirkungen auf Compliance-standards haben, sondern auch gesetzliche anforderungen<br />
verletzen können.<br />
alle in abbildung 1 dargestellten sicherheitsdefekte sind daher auch Compliance-relevant.<br />
5.4 testWerKzeuGe<br />
Für aBaP-sicherheitstests eigenen sich insbesondere sogenannte statische Codeanalyse-tools.<br />
es gibt hier verschiedene kommerzielle anbieter, die in wesentlichen Bereichen die Möglichkeiten<br />
des Code inspectors erweitern:<br />
> analyse des saP-standard-Codings, insbesondere von aPi-aufrufen<br />
> sehr hohe scan-Geschwindigkeiten für Continuous Monitoring<br />
> Globale daten- und Kontrollflussanalysen, da diese für die meisten sicherheitstests elementar<br />
sind.<br />
> umfangreiche Beschreibungen des Problems mit Lösungsvorschlägen<br />
> Hinreichende testabdeckung (oWasP top 10 und sans 25 reichen nicht, da überwiegend<br />
Web-spezifisch und auf aBaP kaum anwendbar)<br />
> 4-augen-Prinzip bei ausnahmen
natürlich muss so ein tool hinreichend in se80, tMs und CharM integriert sein, damit die<br />
entwickler damit arbeiten können und wollen.<br />
5.5 WeiterFÜHrende QueLLen:<br />
1. andreas Wiegenstein, Markus schumacher, sebastian schinzel, Frederik Weidemann, sichere<br />
aBaP Programmierung, saP Press 2009<br />
2. Maxim Chuprunov , Handbuch saP-revision, saP Press 2011<br />
3. BizeC - the Business application initiative (http://bizec.org)<br />
33<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
34<br />
6 doKuMentation<br />
die dokumentation von software ist in vielen Fällen genauso wichtig wie die entwicklung selbst.<br />
Fehlt die dokumentation oder ist diese nicht in ausreichendem Maß vorhanden, führt dies<br />
spätestens bei der Weiterentwicklung oder dem Wechsel von entwicklern zu erhöhten aufwänden.<br />
in diesem Kapitel werden unterschiedliche Möglichkeiten zur dokumentation von entwicklungsobjekten<br />
im saP system dargestellt.<br />
6.1 doKuMentation unaBHÄnGiG Von entWiCKLunGsoBJeKten<br />
neben der Beschreibung der vielen entwicklungsobjekte, die einzelne, sehr spezielle Funktionen<br />
im aBaP-system übernehmen, gibt es auch den Bedarf, die größeren zusammenhänge innerhalb<br />
und zwischen Modulen darzustellen. dazu gehören z.B. antworten auf Fragen wie:<br />
> Welche abhängigkeiten gibt es zwischen n Modulen?<br />
> Wie werden Prozesse auf reports abgebildet?<br />
> Welche Läufe finden wann am tag / im Monat / Jahr statt und welche entwicklungsobjekte sind<br />
davon betroffen?<br />
Für die Beantwortung dieser Fragen findet sich unserer Meinung nach kein geeignetes ablagemedium<br />
innerhalb des saP-entwicklungssystems, das insbesondere Grafiken gut integriert. Wir<br />
empfehlen daher, für die dokumentation dieser übergreifenden zusammenhänge auf andere<br />
Medien außerhalb des saP-systems zurückzugreifen. Beispiele dafür sind:<br />
> interne (Produkt-)Wikis<br />
> dokumente in gepflegten öffentlichen Verzeichnissen (Portalablage, sharepoint, Fileshare …)<br />
die erfahrung zeigt, dass die Herausforderung in diesem Bereich primär in der Frage der disziplin<br />
liegt. diese Herausforderung kann kein tool lösen, sondern nur das entwicklungsteam und die<br />
zugehörige -leitung.<br />
darüber hinaus sei angemerkt, dass veraltete dokumentation irreführend sein kann. insofern<br />
sollte in dokumenten der stand und eine Versionierung enthalten sein, um die aktualität bewerten<br />
zu können.<br />
innerhalb einer saP-systemlandschaft bietet der saP solution Manager Möglichkeiten zur<br />
Projektdokumentation. die nachfolgenden Links bieten weitere informationen dazu.<br />
WEITERE QUELLEN:<br />
1. Help.sap.com dokumentation saP solution Manager 7.1:<br />
http://help.sap.com/saphelp_sm71_sp05/helpdata/en/3d/d05893e6ba4dfab7c0d66de8d52420/<br />
frameset.htm<br />
2. sCn Blog: „Business process documentation with saP solution Manager 7.1”<br />
http://scn.sap.com/blogs/ben.schneider/2011/11/04/business-process-documentation-with-<br />
sap-solution-manager-71
6.2 doKuMentation Von entWiCKLunGsoBJeKten<br />
neben Methoden, Funktionsbausteinen und reports, die dokumentation im Quelltext enthalten<br />
können, existieren weitere entwicklungsobjekte im aBaP-system, die keinen Quelltext beinhalten<br />
und daher auf anderem Weg dokumentiert werden müssen. Beispiele dafür sind:<br />
> interfaces<br />
> ddiC-objekte<br />
> transaktionen<br />
BEST PRACTICE: Wir empfehlen, für alle entwicklungsobjekte, unabhängig von Quelltexten, die<br />
Möglichkeiten zur dokumentation der aBaP Workbench zu nutzen und die aufgaben und<br />
Bedeutungen dieser objekte im saP-system zu dokumentieren. im Vergleich zur dokumentation<br />
im Quelltext ist hier der Änderungsverlauf nicht im Vordergrund, sondern der ist-stand sollte hier<br />
dargelegt werden.<br />
da die dokumentation auch an das transportwesen angeschlossen ist, steht diese dokumentation<br />
in allen stages einer systemlandschaft zur Verfügung. Weiterhin kann die dokumentation von allen<br />
Benutzern eingesehen werden und wird in einigen Fällen (reports) vom aBaP-system automatisch<br />
in die Benutzungsoberfläche eingebunden. ein weiterer Vorteil besteht darin, dass diese dokumentation<br />
übersetzbar ist.<br />
6.3 doKuMentation iM QueLLtext<br />
6.3.1 dokumentation und Kommentierung von anweisungen/anweisungsblöcken<br />
Generell sollten anweisungsblöcke im Quelltext (kurz) kommentiert werden, damit ein schnelles<br />
zurechtfinden in fremden Programmen ermöglicht wird. dabei soll in einer Kommentarzeile kurz<br />
beschrieben werden, welche aufgabe der nächste anweisungsblock hat. dokumentieren sie<br />
insbesondere, warum sie etwas machen, nicht wie. dabei gilt der Grundsatz: so wenig Kommentar<br />
wie möglich, so viel Kommentar wie nötig. Vermeiden sie daher redundante informationen (wie<br />
name des dokumentierten Moduls, den letzten Änderer etc).<br />
BEST PRACTICE: als Kommentierungssprache sollte englisch verwendet werden. entwicklungsteams<br />
arbeiten heutzutage überwiegend international zusammen. auch wenn sie derzeit rein<br />
deutschsprachig entwickeln, kann ihr Projekt im Laufe der zeit internationalisiert werden. der<br />
aufwand, der dann durch Koordinationsprobleme oder sogar nachträgliches Übersetzen entsteht,<br />
steht in keinem Verhältnis zu dem vielleicht größeren aufwand durch englische dokumentation.<br />
es hat sich außerdem gezeigt, dass die Lesbarkeit von Code und Kommentaren besser ist, wenn<br />
die Kommentare englisch sind. denn die aBaP-Befehle selbst sind englisch und im stil von sätzen<br />
aufgebaut. der Leser muss bei englischer dokumentation also nicht ständig beim Lesen des<br />
Quelltextes die sprache wechseln.<br />
35<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
36<br />
6 doKuMentation<br />
6.3.2 dokumentation von Änderungen<br />
ab dem zeitpunkt der Produktivsetzung eines Programms müssen Änderungen in Programmen<br />
dokumentiert werden.<br />
6.3.3 Programmkopf<br />
Änderungen in Programmen werden mit einem namenskürzel (z.B. Vorname + nachname), dem<br />
tagesdatum und dem Change document der Änderung im Programmkopf dokumentiert. dabei<br />
soll zumindest im Programmkopf auch die erläuterung des namenskürzels stehen, hilfreich ist es<br />
jedoch auch, die Beschreibung direkt bei der Änderung einzufügen. Hierdurch kann auf einen Blick<br />
der Grund der Änderung im Code erfasst werden.<br />
Beispiel:<br />
*/ Change Log<br />
*/ Vn/date<br />
Changedoc description<br />
*/ Mz/2012-08-06 Cd4712 add MMsta in output, Max Mustermann<br />
*/ Mz/2012-02-01 Cd4711 import Material number, Max Mustermann<br />
*/ MM/2009-01-01 Cd0815 added Field aBC in method signature and source code in<br />
order to support quick search, Max Mustermann<br />
in der Beschreibung der Änderung sollte die Frage „Wer hat Was, Warum und Wie geändert“<br />
beantwortet werden.<br />
Werden für die Koordination der Weiterentwicklung Change-Management- oder Bug-trackingsysteme<br />
eingesetzt, sollten in diesem Kommentar Verweise auf die Vorgänge/issues enthalten<br />
sein. damit lässt sich später auch im Quelltext nachvollziehen, welche erweiterung/Fehlerbehebung<br />
auslöser für eine Änderung war.<br />
BEST PRACTICE: der Kommentar ist nicht für den Verfasser, sondern für andere entwickler<br />
gedacht. Führen sie sich das bei der erstellung von Kommentaren bzw. deren review immer<br />
wieder vor augen.<br />
Programmzeilen – optional<br />
die geänderten Programmzeilen können mit der Kombination namenskürzel und tagesdatum der<br />
Änderung dokumentiert werden. Hinter dem datum kann ein Punkt gesetzt werden, sodass der<br />
Pretty Printer die Kommentierung automatisch nach rechts ausrichtet.<br />
alte dokumentationen von Änderungen, die nicht mehr benötigt werden, sollten aus Gründen der Les-<br />
barkeit wieder entfernt werden. oberstes ziel sollte stets die gute Lesbarkeit von Quelltexten sein.
einfache Änderung<br />
*Write: lw_mara-matnr. „ Mz/2012-08-06 Cd4712 Cd4711 add MMsta in output<br />
Write: lw_mara-matnr, lw_mara-mssta.<br />
Blockänderung – Löschen von anweisungen<br />
„--> Mz/2012-02-01 Cd4711 import Material number<br />
*ConCatenate wa_import-aufnr wa_import-vornr<br />
* into str seParated By ‚ ‚.<br />
„--> Mz-2012-02-01. deLete<br />
Blockänderung – einfügen von anweisungen<br />
„--> Mz/2012-02-01 Cd4711 import Material number<br />
ConCatenate wa_import-aufnr wa_import-vornr wa_import-matnr<br />
into str seParated By ‚ ‚.<br />
„--> Mz/2012-02-01. insert<br />
Verweis auf stern bzw. anführungszeichen als Kommentar<br />
stern-Kommentare sollten nur im Programmkopf oder für das auskommentieren von altem Code<br />
verwendet werden.<br />
Für alle anderen Kommentare empfiehlt die saP inline-Kommentare zu verwenden. diese sollten<br />
jeweils vor dem Code stehen, den sie dokumentieren, und auch so eingerückt sein wie dieser Code.<br />
WEITERE QUELLEN:<br />
Keller, thümmel, aBaP-Programmierrichtlinien, saP Press 2009<br />
37<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
38<br />
7 uMsetzBarKeit und durCHsetzBarKeit<br />
dieses Kapitel beschreibt, wie sich die <strong>Best</strong> <strong>Practice</strong>s aus dieser Guideline in der Praxis verwirklichen<br />
lassen. Wir unterscheiden hierbei umsetzbarkeit und durchsetzbarkeit der richtlinien.<br />
im abschnitt „umsetzbarkeit“ erklären wir, worauf ein unternehmen achten sollte, das Programmierrichtlinien<br />
einführen möchte. Wir erklären, wie ein Prozess dafür aussehen könnte, wie man<br />
diesen ins Leben ruft und vor allem, wie man ihn am Leben erhält. im abschnitt „durchsetzbarkeit“<br />
legen wir dar, wie ein unternehmen die Vorgaben aus dem Prozess prüfen kann. Hierzu<br />
gehören organisatorische aspekte genauso wie Prüfmethoden und Werkzeuge. Wir gehen aber<br />
auch auf Grenzen der durchsetzbarkeit ein.<br />
abschließend stellen wir tipps aus der Praxis vor, die die autoren bei verschiedenen Projekten im<br />
umfeld der saP-entwicklung gesammelt haben.<br />
7.1 uMsetzBarKeit<br />
Wer erfolgreich Programmierrichtlinien in einem unternehmen einführen möchte, muss zunächst<br />
das Management dafür gewinnen. denn die Verbesserung der Codequalität bedeutet zunächst eine<br />
investition in Prozesse und Werkzeuge sowie in die Fortbildung der involvierten Mitarbeiter.<br />
insbesondere muss das Management überzeugt sein, dass das unternehmen durch diese<br />
Prozesse langfristig Kosten spart.<br />
7.1.1 Motivation für einen Prozess<br />
nachfolgend finden sie anhaltspunkte, welche Qualitätsaspekte bei der einführung eines<br />
Prozesses zur Qualitätssicherung adressiert werden und welche Vorteile dies für unternehmen<br />
hat:<br />
sicherheit<br />
Vorteil: das unternehmen verhindert, dass anwender unbefugt an kritische daten gelangen bzw.<br />
unbefugt kritische daten verändern können.<br />
risiken bei Qualitätsmängeln: sabotage, industriespionage, unerwünschte Pressemeldungen<br />
hervorgerufen durch datenlecks, stillstand der Produktivsysteme.<br />
Compliance<br />
Vorteil: das unternehmen kann jederzeit nachweisen, dass die entwickelte software den<br />
anforderungen relevanter Compliance-standards und gesetzlichen regelungen genügt.<br />
risiken bei Qualitätsmängeln: die Wirtschaftsprüfung scheitert, Verstoß gegen Compliance-anforderungen<br />
oder gesetzliche regelungen (z.B. datenschutz).<br />
Performance<br />
Vorteil: das unternehmen stellt sicher, dass die vorhandene Hardware optimal genutzt werden<br />
kann, und schützt damit die bisherige investition in Hardware. außerdem steigt die zufriedenheit<br />
der Mitarbeiter, da die nutzung der anwendung produktiver wird.<br />
risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt bzw. es entstehen Kosten für<br />
schnellere Hardware, um die softwaremängel auszugleichen.
obustheit<br />
Vorteil: das unternehmen stellt den kontinuierlichen Betrieb der Geschäftsanwendungen sicher<br />
und vermeidet unproduktivität auf Grund von systemausfällen.<br />
risiken bei Qualitätsmängeln: die akzeptanz der anwender sinkt und die Betriebskosten steigen<br />
wegen unproduktivität der anwender sowie durch Fehleranalysen und Wartungsarbeiten durch<br />
techniker.<br />
Wartbarkeit<br />
Vorteil: das unternehmen erreicht, dass die applikation nachhaltig und kosteneffizient gewartet<br />
werden kann, weil die Programmstruktur leicht verständlich und gut dokumentiert ist.<br />
risiken bei Qualitätsmängeln: Hohe Wartungskosten und generell erhöhte Fehleranfälligkeit der<br />
applikation.<br />
7.1.2 erstellung und Pflege des Prozesses<br />
Für die umsetzung dieser Verfahren in der Praxis hat sich die formalisierte Beschreibung eines<br />
Prozesses bewährt. dazu zählen klare Verfahrensanweisungen und Verantwortlichkeiten. die<br />
genaue ausprägung des Prozesses ist unternehmensspezifisch und kann in dieser Guideline nicht<br />
abgebildet werden; der Verweis auf die notwendigkeit ist jedoch allgemeingültig.<br />
BEST PRACTICE: definieren sie den einzuhaltenden Prozess und dokumentieren sie ihn in einer<br />
für alle zugänglichen Form. definieren sie, wie Änderungen und Verbesserungen am Prozess<br />
stattfinden sollen und wie anmerkungen und Kritik eingebracht werden können. dokumentieren<br />
sie alle geprüften regeln ausführlich mit den Kapiteln Hintergrund/Motivation, schlechte<br />
Beispiele, gute Beispiele, Hinweise zum Vorgehen zur Beseitigung und Literatur bzw. ansprechpartner<br />
im unternehmen.<br />
Motivation<br />
ein Prozess für <strong>Best</strong> <strong>Practice</strong>s bei der entwicklung hilft, die Qualität von software pro aktiv und<br />
effizient zu verbessern und damit Kosten im unternehmen langfristig zu senken. Je früher ein<br />
Fehler bei der entwicklung erkannt wird, desto einfacher und kostensparender kann er behoben<br />
werden. Je weniger Fehler eine anwendung enthält, desto mehr entspricht ihre nutzung den<br />
erwartungen des unternehmens. insbesondere läuft sie ohne nebeneffekte, die das Business<br />
negativ beeinflussen.<br />
Welche aspekte sind für den Prozess relevant?<br />
interne entwicklung<br />
Für die interne entwicklung werden richtlinien als nachschlagewerk für die tägliche arbeit und<br />
regelmäßige trainings für aktuelle risiken benötigt.<br />
externe entwicklung<br />
Bei externer entwicklung sind klare Qualitätsvorgaben für ausschreibungen nötig. Vor der<br />
abnahme müssen die anforderungen auch überprüft werden.<br />
Übergreifend<br />
die Vorgaben aus dem Prozess müssen möglichst weitgehend mit geeigneten tools überprüft<br />
werden. eine manuelle Prüfung ist nur in seltenen Fällen flächendeckend möglich.<br />
39<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
40<br />
7 uMsetzBarKeit und durCHsetzBarKeit<br />
BEST PRACTICE: Vorgaben ohne werkzeuggestützte Überprüfungsmöglichkeit sind nicht<br />
umsetzbar und sollten daher nicht definiert und vorgegeben werden.<br />
Bei jeder regel, die zur nachträglichen Qs herangezogen werden soll, muss festgelegt werden, wie<br />
diese werkzeuggestützt überprüft werden kann. Wenn keine mechanische Überprüfung durch ein<br />
Werkzeug möglich ist, wird es in der Praxis nahezu unmöglich werden, auf die konsequente<br />
einhaltung der regel zu achten. die Konzentration auf maschinell überprüfbare regeln erspart<br />
denjenigen, die Qualitätssicherung betreiben sollen, eine Vielzahl an Frustrationsquellen.<br />
nichtsdestotrotz gibt es etliche aspekte, die sich einer maschinellen Prüfung entziehen. diese<br />
aspekte können sinnvollerweise nur mit regelmäßig durchgeführten Code reviews abgedeckt<br />
werden. da gut durchgeführte Code reviews erhebliche aufwände in der durchführung, aber auch<br />
der Vor- und nachbereitung bzw. Kontrolle von Korrekturen erfordern, müssen diese sich auf<br />
wenige, aber unter den nicht maschinell prüfbaren aspekten kritischen entwicklungsobjekten<br />
beschränken. Wenn z.B. die einhaltung von Performance-Vorgaben eine hohe Priorität besitzt,<br />
sollten in entsprechenden Code reviews nur entwicklungsobjekte mit zugriffen auf datenbanken<br />
oder umfangreichen Berechnungen beschränkt werden.<br />
der Prozess muss daher eine Qualitätskontrolle vorsehen, durch die sämtliche entwicklungen<br />
geprüft werden, bevor sie in den Produktivbetrieb gehen. es muss auch definiert sein, wie mit<br />
Fehlern verfahren werden soll. der Prozess muss selbstverständlich regelmäßig aktualisiert<br />
werden, um neue aspekte berücksichtigen zu können.<br />
7.2 durCHsetzBarKeit<br />
7.2.1 Manuelle Prüfungen<br />
Viele der Prüfungen lassen sich automatisieren. es gibt jedoch Bereiche, die sich für eine<br />
automatische Prüfung nicht eignen, wie beispielsweise dokumentation, architektur oder viele<br />
funktionale anforderungen. die menschliche sprache ist sehr komplex, daher muss z.B. der inhalt<br />
von dokumenten und dokumentationen manuell geprüft werden. nur der menschliche Leser kann<br />
beurteilen, ob ein text sinnvoll, vollständig, verständlich und korrekt ist. eine automatische<br />
Prüfung kann dabei maximal die existenz in den vorgegebenen sprachen prüfen. es empfiehlt sich<br />
dennoch ein automatischer test auf nicht-funktionale aspekte.<br />
Für die manuelle Prüfung ist es wünschenswert, eine vollständige Prüfung anhand der auswertung<br />
von transportstücklisten vorzunehmen. dabei ist zu berücksichtigen, welche unternehmensinternen<br />
richtlinien existieren. abhängig von der anzahl der objekte muss eine vollständige oder<br />
zumindest stichprobenartige Prüfung erfolgen. das Prüfergebnis wird dem entwickler/zuständigen<br />
zur Verbesserung/Vervollständigung der dokumente/dokumentationen übermittelt.<br />
ob ein Prozess alle Vorgaben erfüllt, kann nur mittels einer manuellen periodischen Prüfung<br />
ermittelt werden. Falls sich Vorgaben ändern bzw. Mängel im Prozess aufgedeckt werden, ist der<br />
Prozess entsprechend anzupassen oder ggfs. neu zu definieren.<br />
in der Praxis hat sich ein fest eingeplanter zyklischer review des Prozesses bewährt.
Wann und wie sollte geprüft werden?<br />
die den Prüfungen zugrunde liegenden Konzepte müssen regelmäßig auf aktualität und Konformität<br />
bzgl. der Vorgaben geprüft werden. die aktualität ist jedenfalls mit einem upgrade auf ein neues<br />
release (enhancement Package) zu prüfen. Bzgl. der Vorgaben ist es durchaus sinnvoll, das<br />
Wirtschaftsprüfungsunternehmen, welches das unternehmen prüft, hinzuzuziehen. Für extern<br />
entwickelten Code gilt, dass eine Prüfung vor abnahme stattfinden muss.<br />
Für die akzeptanz der Prüfungen bzw. der Beanstandung im zuge der manuellen Prüfungen ist es<br />
sinnvoll, im rahmen der entwickler- und Qa-tests (4-augen-Prinzip) die manuell notwendigen<br />
Prüfungen durch andere entwickler durchführen zu lassen.<br />
dasselbe gilt für Penetrationstests und Belastungstests. da es sich bei Penetrationstests auch um<br />
ein kritisches sicherheitsthema handelt, kann es notwendig sein, hierfür in regelmäßigen<br />
abständen auch externe Partner hinzuzuziehen.<br />
7.2.2 automatische Prüfungen<br />
automatische tests decken schnell einen Großteil der notwendigen tests und Prüfungen ab. als<br />
Hintergrundjob eingeplant, ist eine regelmäßige Wiederholung ohne zusätzlichen aufwand<br />
möglich. diese regelmäßig mit gleicher Qualität durchgeführten tests ermöglichen so den<br />
entwicklern, ihren Programmierstil zu verbessern.<br />
Wann und wie sollte geprüft werden?<br />
die entwickler sollen ein möglichst zeitnahes Feedback bzgl. der Konformität der entwicklungen<br />
mit den richtlinien erhalten. dazu dienen täglich eingeplante Prüfungen im entwicklungssystem,<br />
deren ergebnis dem entwickler zur Verfügung gestellt wird. Wichtig ist, dass dieselben tests und<br />
Metriken bei der Prüfung durch jeden einzelnen entwickler und bei der Prüfung durch zentrale<br />
Qs-instanzen bzw. bei einer transportfreigabe verwendet werden. sollten für diese Prüfungen<br />
unterschiedliche Werkzeuge oder unterschiedliche einstellungen verwendet werden, sinkt die<br />
akzeptanz in entwicklerkreisen ganz erheblich.<br />
als zentrale schutzinstanz müssen die Prüfungen in das tMs und da spätestens mit der Freigabe<br />
des transportauftrags (besser der einzelnen transportaufgaben) implementiert sein. damit wird<br />
sichergestellt, dass keine ungeprüften bzw. nicht den richtlinien entsprechenden entwicklungen in<br />
die Folgesysteme und dann auch in das Produktivsystem transportiert werden.<br />
als „letztes sicherheitsnetz“ ist ein regelmäßiger Prüflauf (Fullscan) im Produktivsystem<br />
vorzusehen. dieser sollte in einer lastarmen zeit mittels Hintergrundjob eingeplant werden. das<br />
ergebnis wird dem Qa-zuständigen zur Verfügung gestellt, der dann die weiteren schritte (ggfs.<br />
Korrektur) mit hoher Priorität veranlasst.<br />
Bei allen automatischen Prüfungen ist im Vorfeld zu definieren, wie mit altem Code umgegangen<br />
wird. sinnvoll scheint es hierfür auch, einen Fahrplan zu erstellen, wann und wie die neuen regeln<br />
auf alten Code angewendet werden.<br />
41<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
42<br />
7 uMsetzBarKeit und durCHsetzBarKeit<br />
7.2.3 Werkzeuge<br />
nachstehend werden einige tools aufgelistet, mit welchen die automatisierten Prüfungen<br />
durchgeführt werden können.<br />
saP Code inspector<br />
der saP-Code inspector wird seitens saP im standard ausgeliefert und ist entsprechend in die<br />
entwicklungsumgebung hoch integriert. saP sieht ein erweiterungskonzept vor, welches<br />
ermöglicht, kundenspezifische Prüfungen selbst zu implementieren. Hierfür sind ggfs. Programmierarbeiten<br />
notwendig. die seitens saP ausgelieferten Prüfungen können teilweise weitgehend<br />
parametrisiert werden. inspektionen auch von großen objektmengen können sowohl online als<br />
auch im Batchbetrieb erfolgen und ergebnismengen von vorangegangenen inspektionen können<br />
wieder als objektmenge verwendet werden, um die Kontrolle von Korrekturen auf die vorher<br />
fehlerbehafteten objekte zu beschränken. Weiterhin können ergebnisse auch automatisch per<br />
e-Mail an die verantwortlichen entwickler verteilt werden.<br />
Werkzeuge von drittherstellern<br />
neben dem saP Code inspector gibt es am Markt sehr gute kommerzielle tools, die Prüfungen auf<br />
Code-ebene vornehmen. eine Beschreibung dieser tools soll aus neutralitätsgründen an dieser<br />
stelle unterbleiben.<br />
7.3 erFaHrunGen und tiPPs aus der Praxis<br />
7.3.1 Qualitätssicherung des Quellcodes<br />
um eine erfolgreiche einführung zu gewährleisten, ist es wichtig, Qualitätssicherung schrittweise<br />
und behutsam einzuführen. Hierbei empfiehlt es sich, einen zweigeteilten ansatz zu fahren.<br />
zunächst sollte neuer Code „fehlerfrei“ erstellt und dies geprüft werden. erst wenn sich dieser<br />
Prozess stabilisiert hat, sollte nach und nach <strong>Best</strong>andscode mit in die Checks aufgenommen<br />
werden, sonst wird der zu bewältigende Berg für den entwickler zu groß und die Motivation sinkt<br />
rapide.<br />
Wenn nicht auf der „grünen Wiese“ mit einer neuen entwicklung begonnen wird, wenn automatische<br />
Codeprüfungen eingeführt werden, ist es wichtig, vorher den umgang mit „altlasten“ zu<br />
klären. auch bei neuen entwicklungen lassen sich Änderungen an schon bestehenden objekten<br />
nicht vermeiden, die dann bei einer eingerichteten transportprüfung zu Problemen führen.<br />
Hilfreich ist in solchen Fällen eine Klärung der Verantwortlichkeit für entwicklungsobjekte, die z.B.<br />
durch das entsprechende Feld in Paketdefinitionen dokumentiert werden kann. diese Verantwortlichen<br />
müssen entscheiden, ob Fehler im <strong>Best</strong>andscoding sofort korrigiert werden müssen oder<br />
eine ausnahmeregelung möglich ist.<br />
in vielen Fällen ist es schon ausreichend, mit standard-Bordmitteln, wie z.B. Code inspector, zu<br />
arbeiten, der sich auch um eigene Checks erweitern und somit an eigene Bedürfnisse anpassen<br />
lässt. im netWeaver 7.02 sind einige neue Prüfungen in der auslieferung enthalten wie suche nach<br />
bestimmten kritischen anweisungen, Verwendung der adBC-schnittstelle, mandenatenabhängige<br />
shared-objects-Methoden, robuste Programmierung und aBaP-Webdynpro-Metrik.
7.3.2 zeit und Budget Qa<br />
um die zeit und den aufwand für die Qa-tätigkeiten möglichst gering zu halten, muss der<br />
entwickler die Möglichkeit haben, den Code während seiner entwicklertätigkeit selbstständig auf<br />
Fehler hin untersuchen zu können.<br />
tut er dies nicht, muss er automatisiert auf Fehler oder Verbesserungsmöglichkeiten hingewiesen<br />
werden. tägliche inspektionen mit einem entsprechenden Werkzeug und Verteilung der ergebnisse<br />
stellen sicher, dass Fehler frühzeitig erkannt werden und die entwickler sich noch an ihre<br />
tätigkeiten vom Vortrag erinnern, was die Fehlerbehebung deutlich vereinfacht. so wird gewährleistet,<br />
dass auch entwickler, die den manuellen aufwand scheuen oder unter zeitdruck stehen,<br />
trotzdem die Möglichkeit erhalten, ihre Fehler im Code zu beheben. Hier ist zu bemerken, je später<br />
die Qa einsetzt, desto höher ist der aufwand für die Fehlerbehebung. dieser zusätzliche aufwand<br />
entsteht z.B. durch zusätzliche transporte, wenn der originaltransport bereits freigegeben wurde.<br />
deshalb ist es wichtig, bei Planung und schätzung eines Projektes die Qualitätssicherung zu<br />
berücksichtigen, und zwar nicht nur am ende, sondern projektbegleitend und anschließend im<br />
kompletten software-Lifecycle.<br />
nicht zu unterschätzen ist auch der schulungsaufwand, der benötigt wird, um bei den entwicklern<br />
um Verständnis für den Prozess zu werben.<br />
Bei einem einsatz von externen entwicklern müssen die Programmierrichtlinien und namenskonventionen<br />
<strong>Best</strong>andteil des Vertrages sein.<br />
7.3.3 Probleme<br />
Bei der einführung einer Code Qa treten eine reihe von Problemen auf, auf die hier kurz<br />
eingegangen wird.<br />
ein reibungspunkt ergibt sich durch die Frage, wer für die Qa zuständig ist, ersteller oder Änderer.<br />
Bei neuen sourcen ist dies kein Problem, bei <strong>Best</strong>andscode aber wird die Frage immer wieder<br />
aufgeworfen:<br />
„Warum soll ich Code überprüfen, in dem ich nur eine zeile geändert haben?“<br />
vs.<br />
„Warum soll ich Code überprüfen, den ich schon Jahre nicht mehr angefasst habe?“<br />
Beide Positionen sind natürlich verständlich, deswegen muss eine klare entscheidung bezüglich<br />
Handhabung von kopiertem Code, der auf anderen/keinen Konventionen beruht, getroffen und<br />
durchgesetzt werden.<br />
BEST PRACTICE: um bei auftretenden Problemen die Fragen der entwickler zu beantworten, ist es<br />
wichtig, dafür eine zentrale stelle zu schaffen. außerdem muss es einen Prozess geben, um in<br />
notfällen auch fehlerbehaftete transporte freizugeben. Gibt es diese Möglichkeit nicht, sinkt das<br />
Verständnis für die durchgeführten Maßnahmen. eine Möglichkeit ist es hierbei, einen Genehmigungsprozess<br />
zu installieren, mit dessen Hilfe auch fehlerbehafteter Code freigegeben oder<br />
transportiert werden kann. die meisten tools am Markt bieten diese Möglichkeit standardmäßig an.<br />
43<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
44<br />
7 uMsetzBarKeit und durCHsetzBarKeit<br />
7.3.4 entscheidungsfindung bei Modifikationen<br />
Wichtig ist es, die Hürde für Modifikationen so hoch wie möglich zu legen. dies ist besonders wichtig,<br />
wenn man sich dazu entscheidet, zeitnah enhancement Packages der saP einzuspielen (sPau-<br />
Problematik). ansatzpunkt hierzu ist der Modifikationsschlüssel. die anzahl der entwickler, die die<br />
Berechtigung haben, Modifikationsschlüssel zu generieren, muss möglichst gering sein. so ist es<br />
möglich, steuernd einzugreifen und diese über Change requests und einen zugehörigen Prozess<br />
abzuhandeln.<br />
die Frage, wodurch sich eine Modifikation rechtfertigt, ist unternehmensindividuell zu beantworten<br />
und konsequent umzusetzen. eine Pauschalantwort auf diese Frage gibt es nicht. in jedem Fall<br />
sollte die entscheidung jedoch auf gleichartigen, im Vorfeld definierten und kommunizierten<br />
Kriterien basieren.<br />
7.3.5 erfahrungsbericht aus der Praxis: Comgroup GmbH<br />
das nachfolgende Beispiel der Comgroup GmbH, dem it-dienstleister der Würth Gruppe, zeigt wie<br />
Programmierrichtlinien und namenskonventionen in einer softwareentwicklung ein- und<br />
durchgesetzt werden können.<br />
die Comgroup GmbH startete mit der Code Qa im globalen entwicklungssystem einer mehrstufigen<br />
entwicklungslandschaft. zur automatisierten unterstützung wurde der Code inspector<br />
eingesetzt. da die Code-Qa-einführung mit der einführung eines neuen namensraumes<br />
zusammenfiel, wurden zu Beginn des Projekts nur objekte aus dem neuen namensraum geprüft<br />
und <strong>Best</strong>andscode nicht berücksichtigt. dies erleichterte die selektion im Code inspector, da<br />
dieser keine Änderungs- oder erstellungsdaten bei der selektion berücksichtigt. außerdem<br />
wurden Performance- und security-Checks aus dem Code inspector vorerst nicht aktiviert, um den<br />
aufwand in einem überschaubaren rahmen zu halten.<br />
Hierdurch hat der entwickler die Möglichkeit, seinen Code während seiner entwicklertätigkeit<br />
selbstständig zu checken. zusätzlich wurde ein nachtlauf eingeplant, der den kompletten zu<br />
scannenden Code analysiert und bei gefundenen Fehlern Mails an den jeweiligen entwickler<br />
sendet. Probleme bereitete hierbei, dass es viele user im system gab, die keine zugeordnete<br />
Mailadresse hatten, was dazu führte, dass zu Beginn Mails ihren empfänger nicht erreichten.<br />
Mails an entwickler ohne Mailadresse werden an eine zentrale adresse versendet und somit<br />
können die unvollständigen datensätze mit einem geringen aufwand identifiziert werden. deshalb<br />
werden nun keine entwicklungs-user mehr im system ohne Mailadresse angelegt.<br />
die Mails wurden nicht von einem anonymen Batch-user sondern von der Mailadresse des<br />
Qa-Verantwortlichen gesendet, um dem entwickler einfach die Möglichkeit zu geben, Fragen zu<br />
stellen. zu Beginn entstand hierdurch ein hoher aufwand, die anzahl der Fragen verringerte sich<br />
aber mit der Laufzeit des Projekts. dies konnte erreicht werden, da schulungen durchgeführt<br />
wurden und so die entwickler effizienter die Fehler korrigieren konnten oder diese schon bei der<br />
entwicklung vermieden.
die entwicklungssprache in der entwicklungslandschaft ist englisch. dies wird durch einen<br />
weiteren Job geprüft und bei Fehlern dem entwickler gemeldet. saP bietet keine Möglichkeit im<br />
standard, bei der anlage die richtige sprache zu setzen. deshalb bot sich nur die Möglichkeit, an<br />
passender stelle eine entsprechende Prüflogik per Modifikation einzubauen oder damit zu leben,<br />
dass objekte in falscher sprache angelegt werden und danach umgezogen werden mussten.<br />
Bei anlage von objekten wurden namenskonventionen für die objekte gecheckt, sodass diese nur<br />
nach Konventionen benannt werden konnten (ebenfalls per Modifikation).<br />
um eigene Checks bei der transportfreigabe durchzuführen (z.B. eigene namenskonventionen/<br />
mind. deutsche und englische Übersetzung) wurde eine implementierung für das Business add in<br />
Cts_reQuest_CHeCK angelegt und die Methode CHeCK_BeFore_reLease genutzt.<br />
nachdem der Prozess sich im globalen entwicklungssystem stabilisiert hatte, wurde dieser an die<br />
nachfolgenden entwicklungssysteme und namensräume ausgerollt. <strong>Best</strong>andscode wird bisher<br />
noch nicht gecheckt. zusätzlich ist geplant, ein externes tool einzusetzen, das die Qualitätssicherung<br />
vereinfacht.<br />
45<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
46<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
neben methodischen empfehlungen und Werkzeugen zur unterstützung bei der softwareentwicklung<br />
im saP-system stellen die infrastruktur und die Betrachtung des Lebenszyklus einer<br />
softwarekomponente eine wichtige rahmenbedingung für erfolgreiches arbeiten dar. in diesem<br />
Kapitel liegt auf diesen beiden aspekten der Fokus.<br />
8.1 inFrastruKtur<br />
eine saP-systemlandschaft ist i.d.r. mehrstufig aufgebaut. nachfolgend werden die einzelnen<br />
systeme und ihre Bedeutung dargestellt:<br />
8.1.1 sandbox<br />
die sandbox ist ein reines test- und „spielsystem“. in der sandbox gelten keine einschränkungen<br />
in Bezug auf Berechtigungen, das gilt gleichermaßen für Customizing- und Workbench-entwicklungen.<br />
aus der sandbox sind keine transporte in andere systeme erlaubt. Änderungen können<br />
ausprobiert werden, bevor sie im entwicklungssystem durchgeführt werden. damit kann der<br />
rückbau komplexer entwicklungen in der entwicklungsumgebung vermieden werden, wenn z.B.<br />
eine neuentwicklung nicht weiter verfolgt werden soll.<br />
8.1.2 entwicklungssystem<br />
ein kombiniertes entwicklungs-/testsystem (z.B. entwicklungsmandant 010, testmandant 110)<br />
bietet sich als einfache und praktikable Lösung an. es ist beispielsweise kein transport von<br />
Workbench-objekten erforderlich, um neuentwicklungen zu testen.<br />
im testmandanten herrscht dabei absolutes Customizing-Verbot. Customizing dieses Mandanten<br />
wird ausschließlich durch Mandantenkopie aktualisiert (sCC1). entwickler/Modulbetreuer haben<br />
im testsystem sehr weitreichende Berechtigungen. einschränkungen müssen individuell festgelegt<br />
werden, z.B. für besonders sensible daten (Hr etc.).<br />
Berechtigungen/rollen werden grundsätzlich im entwicklungssystem erstellt und transportiert.<br />
Generell werden alle zu transportierenden Änderungen in einem Mandanten im e-system<br />
vorgenommen.<br />
8.1.3 Qualitätssicherungssystem<br />
im Qa-system herrscht absolutes Customizing- und entwicklungsverbot. Customizing- und<br />
Workbench-objekte werden ausschließlich per ta importiert. importe nach Produktion erfolgen<br />
grundsätzlich über das Qa-system. damit wird die Übereinstimmung einer mit Produktion<br />
übereinstimmenden systemumgebung sichergestellt.<br />
das Qa-system wird bei Bedarf z.B. für umfangreichere Validierungsaktivitäten aus dem<br />
Produktionssystem kopiert. damit wird auch die Übereinstimmung mit der operativen (daten-)<br />
umgebung sichergestellt. im Qa-system erfolgt die durchführung von testplänen nach Änderungen<br />
und neuentwicklungen. entwickler/Modulbetreuer haben im Qa-system sehr weit-<br />
reichende Berechtigungen. einschränkungen müssen individuell festgelegt werden, z.B. für<br />
besonders sensible daten (Hr etc.). es empfiehlt sich aber auch, testbenutzer mit produktionsnahen<br />
Berechtigungen zu verwenden.
8.1.4 Produktion<br />
im Produktionssystem herrscht absolutes Customizing- und entwicklungsverbot. Customizing-<br />
und Workbench-objekte werden ausschließlich per transportauftrag in dieses system importiert.<br />
entwickler/Modulbetreuer haben im Produktionssystem nur eingeschränkte Berechtigungen;<br />
emergency-tabellenänderungen (&saP_edit) sind zu dokumentieren mit datum/uhrzeit und<br />
Begründung. Hierzu empfiehlt sich die Verwendung eines tools, um die Meldungen zu standardisieren.<br />
der umgang mit notfall-usern muss technisch und organisatorisch festgelegt werden.<br />
8.1.5 transportwesen<br />
Wir empfehlen, die technische Freigabe von transporten grundsätzlich durch interne, verantwortliche<br />
Bearbeiter durchführen zu lassen, nicht von externen Beratern. Hierbei ist generell die<br />
formale Freigabe vorausgesetzt (siehe Change-Verfahren). importe werden generell zentral von der<br />
saP-Basis durchgeführt, ausgenommen die Mandantenkopie innerhalb des test-/entwicklungs-<br />
systems.<br />
der transportweg ist wie folgt festgelegt:<br />
entwicklung -> Qa -> Produktion<br />
die sandbox sollte aus dem transportweg ausgeschlossen werden. importe in die sandbox<br />
erfolgen nur auf individuelle anforderung. dabei ist der transportweg immer entwicklung -><br />
sandbox, nicht umgekehrt!<br />
die importe in das Qa-system müssen in abhängigkeit der systemlandschaft organisiert werden.<br />
Falls möglich, können importe in Qa zyklisch und automatisiert durchgeführt werden, um die<br />
Mitarbeiter der Basisabteilung zu entlasten.<br />
importe in das Produktivsystem sind explizit unter angabe der ta-nr. freizugeben. Hierfür wird<br />
ebenfalls die Verwendung eines geeigneten tools (z.B. solution Manager) zur standardisierung/<br />
Formalisierung empfohlen.<br />
BEST PRACTICE: Checkliste vor ausführung eines Workbench-transports:<br />
1. tests erfolgt? sämtliche Funktionen wurden erfolgreich getestet und (kundenseitig) abgenommen<br />
2. Code geprüft? der Code inspector/erweiterte Programmprüfung wurde für alle Programme<br />
des transportauftrags durchgeführt: die ergebnisliste darf dabei keine Fehler oder<br />
Warnungen enthalten, informationsmeldungen sind zulässig<br />
3. drittanbietertools? sofern weitere testtools für themenbereiche wie security, Performance, …<br />
vorhanden sind, wurden diese eingeplant<br />
4. Manuelle Vor-/nacharbeiten? es ist zu prüfen, ob eine vollständige Checkliste für manuelle<br />
Vor-/nacharbeiten zum transport vorliegt<br />
5. Mehrsprachigkeit? sofern mehrsprachige objekte im transportauftrag enthalten sind, ist zu<br />
prüfen, ob die Übersetzungen vorhanden sind<br />
47<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
48<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
6. abhängigkeiten in den transporten? Falls ein Vorabtransport durchgeführt wurde, muss auf<br />
abhängigkeiten in den transporten geprüft werden<br />
7. namenskonventionen? erstellen einer Liste der transportobjekte und Prüfung der einhaltung<br />
der namenskonvention anhand der objektliste<br />
8. dokumentation (systemintern)?<br />
a. systemintern: Prüfung aller objekte hinsichtlich erstellter/aktualisierter saP-dokumentation,<br />
z.B.<br />
- reportdokumentation (Beschreibung und in aBaP-Coding)<br />
- FuBa-dokumentation komplett (Parameter, ausnahmen etc.)<br />
- datenelemente, strukturen, tabellen (Beschreibung, Überschriften etc.)<br />
Vorgehensweise: erstellen einer Liste der transportobjekte und Prüfung anhand der<br />
objektliste<br />
b. außerhalb des systems: dokumentation vorhanden/vollständig/abgenommen?<br />
8.1.6 rückbau von neuentwicklungen<br />
Wenn entwicklungen im entwicklungssystem erstellt, aber nicht weitertransportiert worden sind<br />
bzw. nur ins Qs-system importiert wurden, sind die Änderungen im entwicklungssystem zurück-<br />
zubauen. im Falle der nutzung von Quality assurance (Qa) als Genehmigungsworkflow gilt:<br />
> die ablehnung verhindert lediglich den Weitertransport ins Produktionssystem. die abgelehnte<br />
entwicklung/Customizing ist aber im entwicklungs- und im Qualitätssicherungssystem noch<br />
vorhanden. daraus ergibt sich ein „schiefstand“ zwischen den einstellungen einerseits des<br />
entwicklungs-/Qualitätssicherungssystems sowie andererseits des Produktionssystems.<br />
> um den schiefstand zu beseitigen, muss die abgelehnte entwicklung im entwicklungssystem<br />
zurückgenommen, dort in einen transportauftrag aufgenommen und ins Qualitätssystem<br />
transportiert werden.<br />
> der transportauftrag, der die rücknahme enthält, soll im Qualitätssystem ebenfalls abgelehnt<br />
werden. damit wird die Übereinstimmung der einstellungen zwischen den systemen wieder-<br />
hergestellt.<br />
> die zuständigen entwickler müssen von abgelehnten transporten erfahren. die Pflicht zur<br />
informationsweitergabe soll bei den für die Qa-Genehmigungen zuständigen Personen liegen.<br />
8.1.7 sicherstellung der Konsistenz von neuentwicklungen/erweiterungen<br />
Bei parallel laufenden Projekten besteht die Gefahr von Überschneidungen. es kann zur überschneidenden<br />
Verwendung von objekten kommen, die es im zielsystem (noch) nicht gibt. dies führt<br />
zum Fehler beim import. Hieraus ergibt sich die Pflicht zur Prüfung der von dritten (non-saP)<br />
erstellten objekte bei deren Verwendung. neuentwicklungen/erweiterungen müssen in geeigneten<br />
Paketen bzw. transportaufträgen gekapselt werden. es wird empfohlen, die transportaufträge für<br />
ein Projekt auf je 1 ta für Workbench, Customizing und Berechtigungsrollen einzuschränken.
‚Vorabtransporte’ sollten nur mit Hilfe von „Kopientransporten“ erlaubt sein.<br />
die endgültige Freigabe und der transport erfolgt erst zum Projektabschluss. alle Projektmitarbeiter<br />
verwenden innerhalb eines Projekts nur aufgaben zu einem jeweils vorgegebenen ta. es gibt keine<br />
‚persönlichen’ transportaufträge für Projektmitarbeiter.<br />
Generell erfolgt ein import nur nach formeller Freigabe (siehe Change-Verfahren) durch einen<br />
Process owner, Qs o.ä. instanzen. die abfolge sowie die beteiligten Bereiche müssen unternehmensspezifisch<br />
festgelegt werden.<br />
8.2 CHanGe ManaGeMent<br />
um eine saP-systemlandschaft wartbar und beherrschbar zu gestalten, ist ein formales Change-<br />
Verfahren die Voraussetzung für jede systemänderung. dabei ist das grundsätzliche Verfahren<br />
unabhängig davon, ob es sich um Änderungen am saP-standard oder an Kundenentwicklungen<br />
handelt.<br />
das Basiswerk zur einführung eines Change- und releasemanagements ist die information<br />
technology infrastructure Library (itiL). in diesem referenzleitfaden sind umfangreiche und<br />
allgemeingültige <strong>Best</strong> <strong>Practice</strong>s beschrieben.<br />
in diesem Kapitel stellen wir einen konkret realisierten Praxisfall aus der entwicklung dar, der<br />
firmen- bzw. branchenspezifisch adaptiert werden kann.<br />
Wir empfehlen grundsätzlich, die folgenden aspekte bei der einführung eines Change-Control-<br />
(auch: Change-request-)Verfahrens zu berücksichtigen:<br />
> Fachliche anforderung<br />
> Begründung<br />
> Bewertung (aufwandschätzung)<br />
> Genehmigung<br />
> Freigabe der Änderung für das Produktionssystem<br />
der Genehmiger-/Freigeberkreis (Process owner, Qs …) ist abhängig vom Gegenstand der<br />
Änderung (betroffener Bereich, betroffene anwendung, gegebenenfalls auch aufwand).<br />
die Verwendung eines geeigneten tools (z.B. solution Manager) wird dringend empfohlen. dabei<br />
gilt jedoch: eine papierbasierte Lösung ist besser als keine!<br />
49<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
50<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
Beispiel für ein Change-Control-Formular (CC):<br />
abbildung 4: Change-Control-Formular<br />
das abgebildete CC-Formular enthält beispielhaft die wesentlichen daten, die begleitend zur<br />
abwicklung einer systemänderung erforderlich sind.<br />
Basisprozess und rollen:<br />
> der anforderer füllt den teil ‚anfordernde abteilung’ aus und sorgt für die unterschrift des<br />
Process owners/des Process owners fremd<br />
> der Process owner ist in der regel ein Vorgesetzter des anforderers, er ist verantwortlich für<br />
einen bestimmten teil der daten bzw. für die nutzung bestimmter teile der saP-software, z.B.<br />
der einkaufsleiter für die saP-einkaufsdaten und -programme<br />
> der Process owner fremd ist immer dann einzubeziehen, wenn eine Änderung auch teile<br />
betrifft, die außerhalb der eigentlichen zuständigkeit des Process owners liegen
Beispiel: der einkäufer benötigt Berechtigungen aus dem Bereich der anlagenbuchhaltung; hier<br />
muss der Process owner zustimmen, der diesen teil des systems verantwortet (z.B. der Leiter<br />
der anlagenbuchhaltung).<br />
> eine ausführliche Beschreibung der Änderung ist in jedem Fall dem CC als anlage anzufügen;<br />
CCs ohne eine ausführliche Beschreibung werden zurückgewiesen.<br />
> der anforderer gibt das CC an die it weiter.<br />
> der saP-Koordinator ist derjenige, der die anfallenden aktivitäten für saP oder einen teil von<br />
saP koordiniert und den einzelnen Modulbetreuern die aufgaben zuweist.<br />
diese aufgabe kann – in abhängigkeit der Größe der organisation – auch von einem Gruppen-<br />
oder abteilungsleiter innerhalb der it übernommen werden. die betreffende Person trägt die<br />
applikation/das Modul im Formular ein und weist das CC einem Bearbeiter zu; sie kann das CC<br />
auch aufgrund formaler Fehler (fehlende/unzureichende Beschreibung oder fehlende unter-<br />
schrift des Process owners/Process owner fremd) zurückweisen. der saP-Koordinator vergibt<br />
eine eindeutige CC-nummer und den CC-titel; die nummer kann z.B. auch von einem<br />
Projektverfolgungs-/-dokumentationstool übernommen werden.<br />
> der it-Leiter/Leiter saP genehmigt / lehnt ab / stellt zurück (mit entsprechender Begründung),<br />
nachdem der Koordinator genehmigt hat.<br />
> im Falle der Genehmigung erhält der Bearbeiter das CC zur weiteren Bearbeitung; eine<br />
Änderung zwecks Weitertransport darf von einem Bearbeiter nicht ohne ein vollständig<br />
genehmigtes CC durchgeführt werden.<br />
> nach Fertigstellung lässt der Bearbeiter die Änderung durch den anforderer prüfen.<br />
> entspricht die umsetzung den anforderungen, gibt der anforderer die Änderung zum transport<br />
frei; der anforderer bestätigt mit seiner unterschrift die ordnungsgemäße umsetzung;<br />
ein transport darf nicht ohne vorangegangene Freigabe durch den anforderer durchgeführt werden.<br />
> saP-Koordinator und it-Leitung bestätigen die ordnungsgemäße umsetzung; ein transport darf<br />
nicht ohne vorangegangene Freigabe durch die saP-Koordination und die it-Leitung durchge-<br />
führt werden.<br />
> der Bearbeiter übergibt den transport in das Produktionssystem und leitet das CC an die saP-<br />
Koordination und die it-Leitung weiter.<br />
der Genehmigungs- und Freigabeprozess und damit auch der inhalt des Formulars kann branchen-<br />
spezifisch stark variieren. in pharmazeutischen unternehmen ist beispielsweise grundsätzlich die<br />
Qa in das CC-Verfahren eingebunden. darüber hinaus ist es in allen unternehmen üblich, dass bei<br />
Überschreiten bestimmter (geschätzter) Projektkostenlimits weitere Genehmiger der umsetzung<br />
einer Änderungsanforderung zustimmen müssen. die Genehmigungsstruktur hängt also im<br />
Wesentlichen von der jeweiligen unternehmensorganisation ab.<br />
das Formular enthält daher lediglich die Minimalanforderungen an ein CC ohne Berücksichtigung<br />
branchen- oder organisationsspezifischer anforderungen.<br />
51<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
52<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
Weitere Genehmigungs- oder Freigabeschritte, aber auch zusätzliche Felder mit Bezug zu anderen<br />
dokumenten (z.B. Validierungsdokumente) sind bei Bedarf individuell zu ergänzen und der Prozess<br />
entsprechend zu erweitern.<br />
WEITERE QUELLEN:<br />
1. Mathias Friedrich, torsten sternberg, Change request Management mit dem saP solution<br />
Manager, saP Press, 2009<br />
2. information technology infrastructure Library (itiL)<br />
8.3 soFtWareWartBarKeit<br />
die Wartbarkeit von software ist ein Kriterium bei der entwicklung von software und zeigt an, mit<br />
welcher energie und mit welchem aufwand Änderungen in einem systemzusammenhang von<br />
applikationen durchgeführt werden können. (Quelle: Wikipedia)<br />
technisch ist ein modularer aufbau von objekten entsprechend saP-Praxis, d.h. include-struktur<br />
in allen Programmen erforderlich. dies umfasst auch die Verwendung von Funktionsbibliotheken,<br />
die auch anderen entwicklern zugänglich sein müssen und von ihnen leicht aufgefunden werden<br />
können.<br />
in systemumgebungen mit verschiedenen entwicklungs- und Produktionssystemen (transportstrecken)<br />
muss der Grundsatz gelten: gleicher objektname (t-Code, Programm, include, tabelle<br />
etc.) bedeutet auch identische Funktionalität.<br />
unterschiedliche Funktionalität bedingt entweder ein eigenes objekt oder – falls möglich – eine<br />
entsprechende Customizing-Funktion.<br />
alle entwicklungen/Änderungen/Korrekturen sind sauber zu dokumentieren.<br />
8.4 anPassunGen der saP-FunKtionaLitÄt<br />
um die Funktionalität eines saP-systems an eigene Bedürfnisse anzupassen, gibt es verschiedene<br />
Möglichkeiten, die jeweils Vor- und nachteile mit sich bringen:<br />
> Modifikation<br />
> z-Kopie, Kopie in Kundennamensraum<br />
> erweiterungen (user-exit, Customer-exit, Badi, enhancement, Bte)<br />
zu den problemlos nutzbaren techniken zählen user-exits, Customer-exits, Btes und Badis.<br />
deshalb ist es zu empfehlen, diese zu verwenden, sofern diese vorhanden sind und ihre schnittstelle<br />
alle nötigen daten zur Verfügung stellt. Hier eine kurze Beschreibung dieser techniken:
user-exit<br />
user-exits sind unterprogramme, die sich in includes im saP-namensraum befinden, aber nur<br />
einmalig von saP ausgeliefert werden und deshalb ohne Probleme „modifiziert“ werden können.<br />
Customer-exit<br />
Customer-exits sind Funktionsbausteine, die zu- und abschaltbar sind und vom Kunden implementiert<br />
werden können, um standardfunktionalität zu erweitern.<br />
Business transaction events (Bte)<br />
im Fi-umfeld stellen Btes eine zusätzliche Möglichkeit der erweiterung dar. Btes sind vergleichbar<br />
mit Customer-exits, beschränken sich jedoch auf das Fi Modul und stellen eine vordefinierte<br />
schnittstelle zur Verfügung an die der entwickler erweiterungen anhängen kann.<br />
Weitere informationen finden sich in der saP-standarddokumentation.<br />
Badi<br />
Mit Badis versuchte saP die nachteile anderer/bisheriger erweiterungstechniken zu umgehen:<br />
> nur einfach verwendbar (Customer-exits)<br />
> keine dynpro-erweiterungen (Btes)<br />
> keine Menü-erweiterungen (Btes)<br />
> keine Verwaltungsebene (Btes)<br />
deshalb sind Badis mehrfach verwendbar, stellen alle erweiterungsarten (Programm- / Menü- /<br />
dynpro-exit) zur Verfügung und sind objektorientiert ausgeführt.<br />
Kann mit den bereits genannten erweiterungen das gewünschte ergebnis nicht erreicht werden,<br />
gibt es weitere Möglichkeiten, deren Verwendung aber von Fall zu Fall abgewogen werden muss.<br />
enhancement Point / enhancement section<br />
enhancement Point:<br />
Bietet die Möglichkeit, an festgelegten stellen (implizit oder explizit) Code einzufügen.<br />
> mehrere aktive implementierungen<br />
> alle aktiven implementierungen werden ausgeführt<br />
enhancement section:<br />
> mehrere aktive implementierungen möglich<br />
> nur eine aktive implementierung wird ausgeführt<br />
> nicht klar, welche aktive implementierung ausgeführt wird<br />
53<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
54<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
Hinweis: implementierungen von enhancement sections können durch das einspielen von saP<br />
enhancement Packages oder das aktivieren von Business Functions durch neue aktive implementierungen<br />
oder neu aktivierte implementierungen ersetzt werden. es ist hierbei sehr schwierig,<br />
ersetzte und nicht mehr ausgeführte implementierungen zu identifizieren. somit kann sich durch<br />
Änderungen im saP standard das Verhalten der erweiterung ändern. dies erhöht den notwendigen<br />
testaufwand (tCo!) massiv und führt leicht zu disruption bei einem saP releaseupgrade und eHP.<br />
die Verwendung von enhancement sections ist daher sehr sorgfältig zu prüfen.<br />
Bei der Verwendung von enhancements ist die sPau_enH zu abarbeiten, da die enhancements in<br />
der regulären sPau-transaktion nicht angezeigt werden.<br />
die entscheidung, ob enhancements als erweiterungskonzept genutzt werden sollen, ist also nicht<br />
nur abhängig vom realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.<br />
Modifikation<br />
Grundsätzlich sollte nur dann modifiziert, wenn:<br />
> Customizing oder Personalisierung ihre anforderung nicht umsetzen können<br />
> geeignete erweiterungen oder user-exits nicht vorgedacht sind<br />
> das Kopieren des saP-objekts in den Kundennamensraum nicht sinnvoll ist<br />
Für Modifikation/exits/Badis wird – zusätzlich zum Change Verfahren – ein separates Genehmigungsverfahren<br />
empfohlen. Hierzu gehören antrag -> Begründung -> Genehmigung. die<br />
entscheidung muss von dem/den jeweiligen systemverantwortlichen (it-Leitung) getroffen werden.<br />
Vorteil hierbei ist, dass der entwickler einen Modifikationsschlüssel eingeben und dieser zentral<br />
vergeben werden kann. es kann also relativ einfach verhindert werden, dass ungewollte Modifika-<br />
tionen ins system eingebaut werden.<br />
Kopien in eigenen namensraum/z-namensraum<br />
Kopien von saP-standardcode in den Kundennamensraum sind sehr pflegeaufwändig. Bislang gibt<br />
es kein automatisiertes Verfahren und keine manuelle regelung, wie ein späterer abgleich (bspw.<br />
nach support-Packages oder Hinweiseinbau) zwischen original und z-Kopie erfolgen kann. eine<br />
allgemeine empfehlung kann an dieser stelle nicht gegeben werden, da Vor- oder nachteile<br />
jeweils im unterschiedlichen Kontext abgewogen werden müssen.<br />
BEST PRACTICE für die durchführung von Modifikationen:<br />
> Grundsätzlich sind Workbench-Modifikationen nur unter Verwendung des Modifikations-<br />
assistenten erlaubt!<br />
> eine z-Kopie ist nicht immer die erste Wahl, da dies u. u. mit sehr hohem realisierungsauf-<br />
wand verbunden ist. darüber hinaus gehen Weiterentwicklungen im standard unberücksichtigt<br />
an der z-Kopie vorbei, d.h., es resultiert ebenfalls ein aufwand für die anpassung bzw.<br />
erstellung einer neuen z-Kopie. nach dem einspielen von enhancement Packages können<br />
verwendete standard-includes zu Problemen führen.
die entscheidung Modifikation vs. z-Kopie vs. enhancement ist also nicht nur abhängig vom<br />
realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.<br />
> Keine der Möglichkeiten Modifikation/z-Kopie/enhancement hat nur Vor- oder nur nachteile,<br />
es ist hier von Fall zu Fall zu prüfen, welche technik die wenigsten nachteile im speziellen Fall<br />
mit sich bringt.<br />
> es wird empfohlen, eine zentrale, formalisierte, technische dokumentation aller Modifikationen<br />
einzurichten. Für Kopien und erweiterungen sollten geeignete templates bereitgestellt und es<br />
sollte eine Pflicht zu deren Verwendung bestehen.<br />
WEITERE QUELLEN:<br />
saP schulungen BC425 und BC427<br />
8.5 testBarKeit Von anWendunGen<br />
um die testbarkeit von anwendungen zu gewährleisten, müssen die testanforderungen zu einem<br />
sehr frühen zeitpunkt in der entwicklung festgelegt werden. Gewachsenes Coding nachträglich<br />
testbar zu machen, ist meistens mit sehr hohem aufwand verbunden, der keine neue Funktionalität<br />
bietet und daher in der Praxis sehr niedrig priorisiert wird.<br />
um wirtschaftlich sinnvoll mit tests umzugehen, müssen tests automatisiert werden. dazu ist es<br />
notwendig, die durchführung von tests wiederholbar zu machen. Versuchen sie, den Code so zu<br />
schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werden<br />
kann. das bedeutet, insbesondere auf dynamische anweisungen zu verzichten, da deren semantische<br />
Bedeutung erst zur Laufzeit bekannt ist und von einem statischen tool nicht hinreichend<br />
analysiert werden kann.<br />
BEST PRACTICE: Verwenden sie von anfang an automatisierte tests (aBaP unit, eCatt), um die<br />
automatisierung von tests zu einem „normalen“ <strong>Best</strong>andteil der entwicklung zu machen.<br />
BEST PRACTICE: saP unterstützt mit der test-Workbench testgetriebene entwicklungen durch<br />
Modultests. testklassen werden als lokale Klassen angelegt und durch den zusatz „For testinG“<br />
als solche kenntlich gemacht. der dort implementierte Programmcode wird lediglich ausgeführt,<br />
wenn die anwendung über den Menüpunkt „Modultest“ in der aBaP-Workbench aufgerufen wird.<br />
sogenannte risk-Levels geben die Kritikalität eines tests im Falle des scheiterns an und<br />
systemeinstellungen verhindern gegebenenfalls, dass ein systemtest einer höheren risikostufe<br />
ausgeführt wird.<br />
im aBaP-umfeld ist in vielen Fällen die gelungene integration der datenbank ein Hindernis, wenn<br />
es um die erstellung von wiederholbaren, automatisierten tests geht. im Vorfeld des tests müssen<br />
die betroffenen einträge auf der dB in die Form gebracht werden, die für die jeweilige testausführung<br />
erwartet wird, und Änderungen an der dB durch die testausführung müssen wieder beseitigt<br />
werden, um andere tests nicht zu behindern.<br />
55<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
56<br />
8 inFrastruKtur und LiFeCyCLe<br />
ManaGeMent<br />
BEST PRACTICE: trennen sie in ihren anwendungen die direkte interaktion mit der dB und<br />
entfernten systemen, deren Laufzeitverhalten nicht kontrolliert werden kann, von dem eigentlichen<br />
anwendungskern. Wenn dieser anwendungskern nicht mehr direkt mit der dB und den entfernten<br />
systeme kommuniziert, bieten die dafür benötigten schnittstellen die Möglichkeit, für die<br />
durchführung von automatisierten tests die datenkonstellationen zu simulieren.<br />
Werden z.B. alle dB-zugriffe (seLeCt, insert, uPdate, deLete) in einer dB-schicht gekapselt,<br />
bietet diese Kapselung den ansatzpunkt, um bei der testausführung mit simulierten daten zu<br />
arbeiten, die bei jeder testausführung in einem konsistenten und bekannten zustand sind.<br />
Weitere LinKs:<br />
www.testbarkeit.de<br />
http://de.wikipedia.org/wiki/testbarkeit<br />
http://www.testbarkeit.de/Publikationen/tae05_artikel_jungmayr.pdf
9 die autoren<br />
die folgenden autoren waren maßgeblich an der erstellung der vorliegenden Fassung des<br />
<strong>Leitfaden</strong>s beteiligt:<br />
Peter Lintner, senior Consultant, allgemeines rechenzentrum GmbH<br />
Herr Lintner ist zertifizierter Projektmanager (iPMa-Level C) und seit 1998 im Bereich saP aBaP<br />
entwicklung tätig. seine schwerpunkte liegen in den Bereichen applikations- und WorkFlow-entwicklung,<br />
Change- und requestmanagement.<br />
steffen Pietsch, Vice President, iBsolution GmbH<br />
Herr Pietsch ist seit 2003 im entwicklungsnahen umfeld tätig und konnte erfahrungen als<br />
entwickler sowie in verschiedenen leitenden Positionen im entwicklungsumfeld sammeln. seit<br />
2009 setzt er sich als sprecher des dsaG-arbeitskreises saP netWeaver development für die<br />
interessen der Kunden und Partner in zusammenarbeit mit der saP ein.<br />
Markus theilen, it-Koordinator, eWe aG<br />
Herr theilen ist seit 2001 als entwickler, software- und unternehmensarchitekt tätig und konnte in<br />
diesen rollen tiefgreifende erfahrungen in komplexen saP-erP-implementierungen sammeln.<br />
seit 2012 steuert er als it-Koordinator im eWe-Konzern die entwicklungstätigkeiten ausgewählter<br />
anwendungen. daneben arbeitet er als stellvertretender sprecher des dsaG-arbeitskreises saP<br />
netWeaver development in der dsaG e.V. mit.<br />
Jürgen Wachter, Process Coordinator development, comgroup GmbH<br />
Herr Wachter arbeitet seit 2002 im Bereich saP entwicklung. sein fachlicher schwerpunkt liegt im<br />
Bereich Core development/enhancements.<br />
Michael Werner, saP anwendungsberater (inhouse), Lts aG andernach<br />
Herr Werner sammelte von 1988 bis 1999 erfahrungen im Bereich saP r/2 mit den schwerpunkten<br />
saP Basis, Logistik und Programmierung (aBaP und assembler). seit 1999 ist er als saP r/3<br />
anwendungsberater für die Module MM, WM und PM tätig und führt aBaP-entwicklung von add<br />
ons, schnittstellen und erweiterungen durch.<br />
andreas Wiegenstein, Managing director und Chief technology officer (Cto), Virtual Forge GmbH<br />
Herr Wiegenstein arbeitet seit 2002 im Bereich saP security. er ist Co-autor des Buches „sichere<br />
aBaP-Programmierung“ (saP Press) und hält regelmäßig Vorträge zum thema saP/aBaP<br />
sicherheit und Compliance auf internationalen Konferenzen, wie z.B. rsa, Black-Hat, Hack in the<br />
Box, troopers, saP teched und auf dsaG-Veranstaltungen.<br />
darüber hinaus haben folgende Personen durch die Bereitstellung von unterlagen, reviewtätigkeiten<br />
und zahlreiche diskussionen maßgeblich zum aktuellen stand beigetragen:<br />
Michael Cendon, thorsten Franz, Pascal Mannherz, thomas Prang, Markus tradt, tobias trapp,<br />
Peter Weigel, Marc zimmek<br />
Besonderer dank gilt der saP, insb. Horst Keller und dr. Wolfgang Weiss, die mit konstruktiven<br />
Vorschlägen und reviews die arbeit an diesem dokument unterstützt haben.<br />
57<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
58<br />
10 anHanG: naMensKonVentionen<br />
im Folgenden finden sie ein Beispiel, wie namenskonventionen im Bereich der aBaP-entwicklung<br />
aufgebaut werden können. dieses Beispiel kann als anhaltspunkt für den aufbau einer eigenen<br />
namenskonvention verwendet werden und ist dahingehend branchen- und unternehmensspezifisch<br />
anzupassen.<br />
allgemeiner Hinweis: objekte im aBaP dictionary haben unterschiedliche Begrenzungen in der<br />
anzahl zur Verfügung stehender zeichen. Bei der Benennung der objekte ist dies zu berücksichtigen.<br />
nachfolgend wird der Kundennamensraum y… verwendet. stattdessen kann, wie in Kapitel 2<br />
beschrieben, alternativ der namensraum z… oder ein kundeneigener namensraum /…/ verwendet<br />
werden.<br />
abkürzungen<br />
abkürzungen Bedeutung<br />
Mm Modul bzw. Projekt<br />
die abkürzung mm repräsentiert ein saP-Modul (z.B. PP MM) oder<br />
ein kundenspezifisches Projekt.<br />
uu arbeitsgebiet<br />
ein arbeitsgebiet erlaubt optional eine feinere unterteilung eines<br />
Moduls oder eines Projekts. das arbeitsgebiet wird vom Projektleiter<br />
definiert und kommuniziert.<br />
K Konstante<br />
C alphanumerisches zeichen<br />
n numerisches zeichen<br />
… Beliebige Länge<br />
10.1 aLLGeMeine naMensKonVentionen<br />
strukturierende elemente<br />
typ Konvention Beispiel<br />
entwicklungspakete ymmuu… yPPrueCK<br />
reports ymmuu… ymmuu…<br />
Modulpools saPMyuu saPMyCauB<br />
includes tymmuuccc..._(a)* MyCauB_toP<br />
transaktionen ymm.. yMM01<br />
nachrichtenklasse ymm.. yPPrueCK<br />
Webdynpro aBaP ymm…** yPKs_adMin_1<br />
anmerkungen:<br />
*das include beginnt mit dem namen des Modulpools ohne den Präfix „saP“. zum schluss wird
die art(a) des includes angegeben:<br />
> toP top include<br />
> PBo Process Before output include<br />
> Pai Process after input include<br />
> ForMs include für unterprogramme<br />
> CLass include für lokale Klassen<br />
** die Verwendung des Webdynpro editors (z.B. in der se80) führt zur automatischen erzeugung<br />
von Quellcode. dies macht die umsetzbarkeit eigener namenkonventionen im einzelfall schwer.<br />
data-dictionary-objekte<br />
typ Konvention Beispiel<br />
tabellen ymmuu…(t) yPPorder<br />
Views ymmuu…_V yPPorder_V<br />
tabellentypen ymmuu…_tt yCadoCuMent_tt<br />
struktur ymmuu…_s yCadoCuMent_s<br />
datenelement und<br />
domäne<br />
ymmuu… yCaFtdatuV<br />
suchhilfe ymmuu…. yPPProJe<br />
sperrobjekte ey_ ey_ysdMinFo<br />
typgruppen ymmcc yCa02<br />
Klassen & interfaces<br />
typ Konvention Beispiel<br />
Klassen yCL_mm_... yCL_sd_FaKtura<br />
interfaces yiF_mm.. yiF_sd_BooKinG<br />
10.2 attriBute<br />
Lokale Variablen und attribute einer Klasse sollten im normalfall als private deklariert werden.<br />
der zugriff auf die attribute sollte über get- und set-Methoden erfolgen.<br />
LV_... attribut Variable (local value …)<br />
Ls_... attribut struktur (local structure …)<br />
Lt_... attribut tabelle (local table…)<br />
59<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
60<br />
10 anHanG: naMensKonVentionen<br />
10.3 MetHoden<br />
Methoden sollten einen kurzen, sprechenden, englischen namen besitzen. Folgende Präfixe<br />
deuten auf die aufgabe der Methode:<br />
set_... setzen von Werten<br />
get_... Laden von Werten<br />
send_... senden von informationen<br />
save_... sichern der daten auf die datenbank<br />
etc.<br />
die genaue Funktion sollte in der Beschreibung der Methode stehen. reicht der Platz (60 zeichen)<br />
nicht aus, so sollte die ausführliche dokumentation der Methode in der Klassendokumentation<br />
erfolgen.<br />
10.4 siGnatur Von MetHoden<br />
die Parameter einer Methode werden wie folgt bezeichnet.<br />
nr. Parameterart Präfix<br />
0 importing i_...<br />
1 exporting e_...<br />
2 Changing C_...<br />
3 returning r_...<br />
10.5 FunKtionsGruPPen und -Bausteine<br />
typ Konvention Beispiel<br />
Funktionsgruppen ymm_ccc_… yCa_KonFiGuration<br />
Funktionsbausteine ymm_... ysd_FaKtura_zu_We<br />
die schnittstellen von Funktionsbausteinen orientieren sich an denen der objektorientierten<br />
Programmierung (vgl. 10.4).<br />
BEST PRACTICE: tabellen können auch als import, export oder Changing Parameter übergeben<br />
werden, sodass stets Klarheit herrscht, welche tabellen im Funktionsbaustein geändert werden<br />
und welche nicht. des Weiteren stellt der syntax-Check im aBaP sicher, dass importparameter<br />
nicht verändert werden dürfen.
10.6 enHanCeMents<br />
typ Konvention Beispiel<br />
enhancement<br />
spot<br />
enhancement<br />
definition<br />
enhancement<br />
implementation<br />
10.7 ForMuLare<br />
yes_... yes_MV45a<br />
yed_... yed_ MV45a<br />
yei_... yei_ MV45a<br />
typ Konvention Beispiel<br />
adobe Forms – Formular ymm.. yPP_VBK1<br />
adobe Forms – schnittstelle ymm.._iF yPP_VKB_iF<br />
smart Forms / sapscript – Formular ymm.. yPP_VBK1<br />
smart Forms / sapscript – stil ymm.. yPP_VBK1<br />
smart Forms / sapscript – textbaustein ymm.. yPP_VBK1<br />
10.8 JoBs<br />
suchhilfe ymmuu…. yPPProJe<br />
sperrobjekte ey_ ey_ysdMinFo<br />
typgruppen ymmcc yCa02<br />
typ Konvention Beispiel<br />
Jobs yMM___ ysd_1_1000_<br />
= Priorität, einstellige zahl, = Buchungskreis<br />
61<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
62<br />
10 anHanG: naMensKonVentionen<br />
10.9 dateneLeMente<br />
datentyp Präfixbestandteil<br />
elementare typen / Variablen v<br />
strukturen s<br />
tabellen t<br />
datenreferenz r<br />
Klassenreferenz o<br />
interfacereferenz i<br />
Badi-referenz b<br />
ausnahmeklasse-referenz x<br />
diese Präfixbestandteile bilden die typenabhängigen anteile der im Folgenden aufgeführten,<br />
kontextabhängigen Präfixe. [t] ist hierbei jeweils durch den passenden typenabhängigen Präfixbestandteil<br />
zu ersetzen.<br />
art der deklaration namenskonvention<br />
Lokale Variable l[t]_*<br />
Globale Variable g[t]_*<br />
statische Variable s[t]_*<br />
Lokales Feldsymbol <br />
Globales Feldsymbol <br />
Lokale Konstante lc[t]_*<br />
Globale Konstante gc[t]_*<br />
select-option s_*<br />
Parameter p_<br />
Funktionsbausteinparameter i[t]_* für importing<br />
e[t]_* für exporting s[t]_*<br />
c[t]_* für Changing <br />
t[t]_* für tables <br />
ForM Parameter p[t]_* für using<br />
c[t]_* für Changing l[t]_*<br />
t[t]_* für tables g[t]_*<br />
tabellentyp tt_*<br />
strukturtyp t_*
objektorientierte Programmierung:<br />
entität namenskonvention<br />
Lokale Klasse lcl_*<br />
Globale Klasse cl_*<br />
Lokales interface lif_*<br />
Globales interface if_*<br />
instanzattribut m[t]_*<br />
statisches attribut g[t]_*<br />
Konstanten c[t]_*<br />
Methodenparameter i[t]_* für importing<br />
e[t]_* für exporting p_<br />
c[t]_* für Changing i[t]_* für importing<br />
r[t]_* für returning s[t]_*<br />
ereignisparameter i[t]_*<br />
63<br />
<strong>Best</strong> <strong>Practice</strong> <strong>Leitfaden</strong> deveLoPment, 31. Januar 2013, © dsaG e. v.
© <strong>DSAG</strong> e. V.