SAP PRESS Praxishandbuch SAP Code Inspector Bearbeitet von Randolf Eilenberger, Frank Ruggaber, Reinhard Schilcher Neuausgabe 2011. Buch. 466 S. Hardcover ISBN 978 3 8362 1706 4 Format (B x L): 16 x 24 cm Weitere Fachgebiete > EDV, Informatik > Datenbanken, Informationssicherheit, Geschäftssoftware > SAP schnell und portofrei erhältlich bei Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft. Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programm durch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr als 8 Millionen Produkte.
54
Embed
Praxishandbuch SAP Code Inspector - ReadingSample · SAP PRESS Praxishandbuch SAP Code Inspector Bearbeitet von Randolf Eilenberger, Frank Ruggaber, Reinhard Schilcher Neuausgabe
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SAP PRESS
Praxishandbuch SAP Code Inspector
Bearbeitet vonRandolf Eilenberger, Frank Ruggaber, Reinhard Schilcher
Weitere Fachgebiete > EDV, Informatik > Datenbanken, Informationssicherheit,Geschäftssoftware > SAP
schnell und portofrei erhältlich bei
Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft.Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programmdurch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr
Randolf Eilenberger, Frank Ruggaber, Reinhard Schilcher
Praxishandbuch SAP Code Inspector ®
1706-4.book Seite 3 Montag, 4. Juli 2011 3:19 15
Auf einen Blick
1 Einsatz des SAP Code Inspectors ....................................... 29
2 Konfiguration und Funktionen des SAP Code Inspectors ........................................................... 67
3 Automatisierte Prüfungen mit dem SAP Code Inspector ............................................................ 125
4 Programmierung eigener Prüfungen für den SAP Code Inspector ............................................................ 159
5 Standardprüfungen des SAP Code Inspectors .................... 235
A Konstanten des SAP Code Inspectors ................................ 391
B Meldungen der SAP-Standardprüfungen ........................... 405
C Glossar ................................................................................ 449
D Die Autoren ......................................................................... 453
1706-4.book Seite 5 Montag, 4. Juli 2011 3:19 15
9
Inhalt
Geleitwort der SAP AG ............................................................................. 17Geleitwort der inconso AG ....................................................................... 19Einleitung ................................................................................................. 21
Dieses Kapitel enthält einen kurzen Überblick über die verschiedenen SAP-Testwerkzeuge, eine einfach nachzuvollziehende Einführung in die Benutzung des SAP Code Inspectors und eine kleine Übersicht über die vorhandenen SAP-Standardprüfungen. Das Ziel dieses Kapitels ist es, Sie dabei mit den grundlegenden Begriffen und Funktionen des SAP Code Inspectorsvertraut zu machen. 29
1 Einsatz des SAP Code Inspectors ........................................ 29
1.1 Einordnung des SAP Code Inspectors .................................... 291.2 Verwendung des SAP Code Inspectors ................................... 34
1.2.1 Gemeinsamkeiten in verschiedenen Bereichen .......... 351.2.2 Prüfvariante ............................................................. 381.2.3 Objektmenge ........................................................... 431.2.4 Inspektion ............................................................... 55
1.3 Überblick über die SAP-Standardprüfungen ........................... 63
2 Konfiguration und Funktionen des SAP Code Inspectors ........................................................... 67
2.1 Einstellmöglichkeiten des SAP Code Inspectors ...................... 672.1.1 Verwaltung von Tests ............................................... 682.1.2 Verwaltung von Objektkollektoren .......................... 712.1.3 Verwaltung von Meldungsprioritäten ....................... 73
2.2 Objektkollektoren ................................................................. 752.2.1 Programme aus der Laufzeitanalyse .......................... 762.2.2 Verwendungsnachweis für Tabellen ......................... 782.2.3 Objekte aus Umfeldermittlung ................................. 792.2.4 Objekte aus Verwendungsnachweis ......................... 802.2.5 Objekte aus Coverage Analyzer ................................ 812.2.6 Objekte aus Datei-Upload ........................................ 822.2.7 Objekte aus Laufzeitfehlern (ab Release 7.0 EHP2).... 832.2.8 Objekte aus cProjects (ab Release 7.0 EHP2) ............ 842.2.9 Objekte aus eingebetteten Paketen
(ab Release 7.0 EHP2) .............................................. 852.2.10 Programme aus Katalog der Report-Sourcen
(ab Release 7.0 EHP2) .............................................. 862.3 Ergebnismeldungen unterdrücken ......................................... 87
IVZ_lang.fm Seite 9 Dienstag, 5. Juli 2011 10:20 10
Inhalt
10
2.4 Verwendungsnachweis für Prüfvarianten und Objektmengen ....................................................................... 109
2.5 Ergebnisse von Inspektionen vergleichen ............................... 1112.5.1 Vergleich zweier verschiedener Inspektionen ............ 1112.5.2 Vergleich zweier Versionen einer Inspektion ............ 114
2.6 E-Mail versenden ................................................................... 1172.6.1 E-Mail aus der Ergebnisliste einer Transaktion........... 1172.6.2 E-Mail über den Report »rs_ci_email« ...................... 1192.6.3 Fazit ......................................................................... 123
2.7 Hintergrundjob des SAP Code Inspectors ............................... 1232.7.1 Teilaufgabe Löschung ............................................... 1232.7.2 Teilaufgabe Import ................................................... 124
In diesem Kapitel gehen wir auf die Möglichkeiten der automatisierten Nutzung des SAP Code Inspectors ein, beschreiben dessen externe Programmierschnittstelle und vermitteln Ihnen zu diesen Themenstellungen Erfahrungen aus der Praxis. 125
3 Automatisierte Prüfungen mit dem SAP Code Inspector ... 125
3.1 Einsatzszenario für automatisierte Prüfungen ......................... 1253.2 Inspektion als Job einplanen .................................................. 1263.3 Objektprüfungen bei Auftragsfreigabe ................................... 1303.4 Objektprüfungen bei Aufgabenfreigabe ................................ 1353.5 Externe Programmierschnittstelle des
SAP Code Inspectors .............................................................. 1503.5.1 Inspektion eines einzelnen TADIR-Objektes ............. 1513.5.2 Inspektion mit einer bestehenden Objektmenge ....... 1523.5.3 Inspektion von Sourcecode ...................................... 1523.5.4 Inspektion einer Selektion von Objekten .................. 1533.5.5 Inspektion einer Objektliste ..................................... 154
3.6 Erfahrungen aus der Praxis ..................................................... 1543.6.1 Planung eines automatisierten
Code-Inspector-Einsatzes ......................................... 1553.6.2 Integration des SAP Code Inspectors in
eigenen Code ........................................................... 157
4 Programmierung eigener Prüfungen für den SAP Code Inspector ................................................ 159
4.1 Vorüberlegungen für eine eigene Prüfung .............................. 1604.1.1 Generelle Planung .................................................... 1614.1.2 Datensammler des Code-Inspector-Frameworks........ 162
4.2 Grundlagen für eine eigene Prüfung ....................................... 1644.2.1 Hintergrund für die Grundlagen ............................... 1644.2.2 Schritt 1: Erstellung von Einträgen im
SAP-Standardprüfungen ........................................... 2304.6.2 Integration eigener Prüfungen in den
SAP Code Inspector ................................................. 2304.6.3 Fazit ........................................................................ 234
IVZ_lang.fm Seite 11 Dienstag, 5. Juli 2011 10:20 10
Inhalt
12
In diesem Kapitel finden Sie eine Beschreibung aller von SAP ausgelieferten Prüfungen der verschiedenen Kategorien wie Performance, Sicherheit, Metriken etc. Besitzt eine Prüfung Parameter, wird deren Einfluss auf die Ausführung der Prüfung vorgestellt. Zu komplexen Prüfungen finden Sie weitere Details und Hilfestellung bei der Analyse der Meldungen. 235
5 Standardprüfungen des SAP Code Inspectors .................... 235
5.1 Zuverlässigkeit und Relevanz von Prüfungen .......................... 2375.1.1 Zuverlässigkeit ......................................................... 2375.1.2 Laufzeit .................................................................... 238
5.3.1 Anweisungsstatistik .................................................. 2415.3.2 Tabellennamen aus SELECT-Anweisungen ................ 2435.3.3 Statistik der Tabelleneigenschaften .......................... 2445.3.4 ABAP-Token-Statistik ............................................... 245
5.4 Performanceprüfungen .......................................................... 2465.4.1 Analyse der WHERE-Bedingung für SELECT .............. 2495.4.2 Analyse der WHERE-Bedingung für
UPDATE und DELETE .............................................. 2545.4.3 SELECT-Anweisungen, die am Tabellenpuffer
vorbei lesen ............................................................. 2555.4.4 SELECT-Anweisungen mit anschließendem CHECK.... 2605.4.5 SELECT in Schleifen .................................................. 2625.4.6 Ändernde Datenbankzugriffe in Schleifen ................. 2635.4.7 Geschachtelte Schleifen ........................................... 2645.4.8 Kopieren großer Datenobjekte ................................. 2655.4.9 Inperformante Operationen auf internen Tabellen..... 2665.4.10 Inperformante Parameterübergaben ......................... 2695.4.11 Kopieren der aktuellen Tabellenzeile bei
LOOP AT … ............................................................. 2745.4.12 'EXIT' oder keine Anweisung in
SELECT-ENDSELECT-Schleife ................................... 2765.4.13 Invalidierung des SAP-Tabellenpuffers ...................... 2785.4.14 Verwendung von Indizes in der
SELECT-Anweisung .................................................. 2805.4.15 Instanzerzeugung von BAdIs .................................... 2825.4.16 SELECT INTO CORRESPONDING FIELDS bei
gepufferten Tabellen ................................................ 2845.4.17 Prüfung der Tabelleneigenschaften ........................... 2845.4.18 Performanceprüfungen, die es nicht gibt .................. 294
5.7 Robuste Programmierung (ab Release 7.0 EHP2) ................... 3215.7.1 Suche nach APPEND und INSERT ... INDEX
bei SORTED-Tabellen ............................................... 3225.7.2 Komplexe WHERE-Bedingung in
SELECT-Anweisung .................................................. 3235.7.3 Prüfung der SY-SUBRC-Behandlung ......................... 3265.7.4 Suspekte Konvertierungen ....................................... 3265.7.5 Anmerkungen zu SELECT ... FOR ALL ENTRIES
5.15.1 Tests zu ENHANCEMENT-SECTION ......................... 3815.15.2 Test zu CL_ABAP_COMPILER ................................... 3825.15.3 Erkennen von totem Coding ..................................... 3825.15.4 Leerer Test ............................................................... 3835.15.5 Überprüfung der Erweiterbarkeit von Tabellen .......... 383
A Konstanten des SAP Code Inspectors ................................................ 391A.1 Inspektionsverarbeitung ........................................................ 391A.2 Pseudokommentare und Genehmigungsverfahren ................. 393A.3 ABAP-Scan-Engine ................................................................ 397
IVZ_lang.fm Seite 14 Dienstag, 5. Juli 2011 10:20 10
Inhalt
15
B Meldungen der SAP-Standardprüfungen ........................................... 405B.1 Allgemeine Prüfungen ........................................................... 407B.2 Performanceprüfungen .......................................................... 410B.3 Sicherheitsprüfungen ............................................................. 418B.4 Syntaxprüfung/Generierung ................................................... 421B.5 Programmierkonventionen .................................................... 423B.6 Metrik und Statistik ............................................................... 428B.7 Dynamische Tests .................................................................. 431B.8 Oberflächen .......................................................................... 435B.9 Suchfunktionen ..................................................................... 440B.10 Anwendungsprüfungen ......................................................... 441B.11 Interne Performancetests ....................................................... 442B.12 Interne Tests ......................................................................... 444B.13 Proxy-Prüfungen .................................................................... 446B.14 Liste der internen Prüfungen ................................................. 446
C Glossar .............................................................................................. 449D Die Autoren ...................................................................................... 453
IVZ_lang.fm Seite 15 Dienstag, 5. Juli 2011 10:20 10
17
Geleitwort der SAP AG
Bei SAP gibt es seit den Anfängen der ABAP-Programmierung eine Reihe vonWerkzeugen, die Entwicklerinnen und Entwickler dabei unterstützen, effizi-ent zu arbeiten und möglichst fehlerfreien Code zu implementieren. An ers-ter Stelle steht hier der ABAP Editor, der nicht nur den Syntaxcheck anbietet,sondern auch die Übernahme von Aufrufschnittstellen oder Codeauszeich-nung und -strukturierung ermöglicht. Der ABAP Editor ist in ein mächtigesFramework integriert: die ABAP Workbench. Außer vielfältigen Möglichkei-ten für die Navigation zu Entwicklungsobjekten bietet diese unter anderemVerwendungsnachweise, eine Anbindung an das ABAP Dictionary und dieTransport-Workbench sowie die Einbindung von Modellierungstools. DieAnalyse des laufenden Codes wird durch den ABAP Debugger unterstützt;dieser ermöglicht neben den üblichen Funktionen wie der Anzeige von Vari-ablen, Aufrufhierarchien und der Verwaltung von Breakpoints beispiels-weise auch die Analyse des Speicherverbrauchs oder die Ausführung vonSkripten. Als weitere Werkzeuge wären die erweiterte Programmprüfung,die ABAP-Laufzeitanalyse und der Performance-Trace zu nennen.
Im Lauf der Zeit entstand – auch aufgrund des Feedbacks zahlreicher Ent-wickler – die Anforderung, den Quelltext nicht nur bezüglich funktionalerKorrektheit, sondern auch hinsichtlich anderer Produkteigenschaften wiePerformance, Skalierbarkeit, Sicherheit oder Bedienbarkeit prüfen zu kön-nen. Die tägliche Arbeit hatte uns ferner gezeigt, dass ein großer Teil der imlaufenden Betrieb entdeckten Performanceprobleme ähnlichen Musternfolgte. Daraus ergab sich eine Reihe von Ideen für Prüfungen, um »hand-werkliche« Fehler, zum Beispiel beim Zugriff auf Datenbanktabellen, auto-matisch identifizieren zu können.
Zwar gab es bereits Werkzeuge für Untersuchungen von statischen Objekt-definitionen, doch diese erfüllten nicht die von uns gestellten Anforderun-gen – wir wünschten uns für alle Entwickler ein leicht zu bedienendes Tool,das in die Arbeitsumgebung integriert und hinsichtlich der Prüfmenge undder Art der Prüfungen einfach und flexibel konfigurierbar sein sollte. Durchdie Zusammenarbeit der beiden Teams »ABAP Language« und »Performance& Scalability« entstand daraufhin ein neues Werkzeug, der SAP Code Inspec-tor. Innerhalb kurzer Zeit wurde ein umfassendes Framework für die Konfi-
1706-4.book Seite 17 Montag, 4. Juli 2011 3:19 15
Geleitwort der SAP AG
18
guration von Objektmengen und Prüfungen sowie für die Ausführung vonInspektionen in Einzel- und Massentests entwickelt. Der Code Inspectorwurde in die Entwicklungs- und in die Transport-Workbench integriert,sodass die Prüfungen den Entwicklern stets direkt zur Verfügung stehen.
Zu den weiteren Vorteilen dieser engen Integration in die Entwicklungsum-gebung zählt, dass nicht nur statische ABAP-Quelltexte analysiert werdenkönnen, sondern auch Zugriffsmöglichkeiten auf das ABAP Dictionary oderauf die Symboltabellen des ABAP-Compilers bestehen. Dadurch können dieMetadaten der Entwicklungsumgebung und der ABAP-Kompilation zurAnreicherung von Prüfungen herangezogen werden. Das Code-Inspector-Framework hat sich als so flexibel erwiesen, dass damit sogar SQL-Tracesoder andere Objekte, die sich nicht im Objekt-Repository befinden, unter-sucht werden können.
Da das Code-Inspector-Framework durch seine offene Architektur einfacherweiterbar ist, kamen im Lauf der Zeit Prüfungen von verschiedenen Auto-ren hinzu, oft angeregt durch Anfragen von Benutzern. Für besondersbemerkenswert halten wir die Erweiterungen des Code Inspectors durchKunden oder Partner, beispielsweise durch eigene Prüfungen zu speziellenProgrammierrichtlinien oder – wie hier im Buch beschrieben – durch denAufruf des Code Inspectors aus einem BAdI in der Transport-Workbench.Dies zeigt uns, dass das Werkzeug Code Inspector akzeptiert und genutztwird und zu einem wichtigen Bestandteil des Softwareerstellungsprozessesgeworden ist.
Dieses Buch wurde für Sie als SAP-Anwender geschrieben, um Ihnen zu hel-fen, die Qualität Ihres selbst entwickelten ABAP-Codes zu überprüfen und zuverbessern. Das Autorenteam besteht aus zwei Mitarbeitern des SAP-Part-ners inconso AG und einem der Entwickler des Code Inspectors. Wir sinddavon überzeugt, dass durch diese Zusammenarbeit ein echtes Praxishand-buch entstanden ist, das Ihnen viele wichtige Tipps für die Arbeit mit demCode Inspector bietet. Das Streben nach einer hohen Softwarequalität ver-bindet alle engagierten Entwickler, und wir hoffen, dass dieses Buch und derCode Inspector Sie dabei unterstützen werden.
Dr. Andreas Simon Schmitt Dr. Ulrich MarquardDevelopment Architect, SAP AG Senior Vice President, SAP AGTIP Core ABAP Platform & VM Tech (AG) Performance & Scalability
1706-4.book Seite 18 Montag, 4. Juli 2011 3:19 15
19
Geleitwort der inconso AG
Vorbei sind die Zeiten, in denen Softwareentwicklung das Werk eigenbröt-lerischer Genies oder »Programmierkünstler« war. Schon lange hat sich dieSoftwareherstellung zu einem mehr und mehr ingenieurartig durchgeführ-ten Prozess entwickelt. In Zeiten wachsender Komplexität der Systeme, imUmfeld serviceorientierter Ansätze und verteilter Systeme gewinnt dieseingenieurartige Herangehensweise mehr und mehr an Bedeutung.
Dies gilt umso mehr, da Softwareentwicklung heute häufig »verteilt« stattfin-det. Systeme werden von möglicherweise rund um die Welt verteiltenTeams gemeinsam entwickelt. Und ist der Entwicklungsprozess einmal abge-schlossen, muss die Wartung und Pflege der Systeme unter gleichen Bedin-gungen gegebenenfalls von Dritten zuverlässig möglich sein. Dies alles stellthöchste Anforderungen an die Qualität, Fehlerfreiheit, Dokumentation unddamit auch an die Wartbarkeit der Systeme.
Nun sind aber trotz aller Professionalität des Entwicklungsprozesses, trotzumfangreich vorhandener Programmierrichtlinien, Dokumentationsvor-gaben, Styleguides etc. letztlich Menschen am Werk. Menschen, die mithohem Sachverstand, technologischem Know-how und eigener KreativitätLösungen für komplexe Prozesse in Sourcecode gießen. Die dabei ihre Indi-vidualität einbringen; und wo sich zum Beispiel bei hohem Projektdruckauch Fehler, Nichtachtung von Richtlinien, Standards oder Dokumentations-vorgaben einschleichen. Die zunehmende Mächtigkeit und Komplexität dereingesetzten Technologien und Werkzeuge erhöht dieses Risiko zusätzlich.Es ist daher von dramatisch zunehmender Bedeutung, im gesamten Soft-wareherstellungsprozess sicherzustellen, dass die Qualitätsstandards undProgrammierrichtlinien, die Dokumentationserfordernisse und Vorgabenzuverlässig und durchgängig eingehalten werden.
Sicherstellen heißt in diesem Zusammenhang, dass neben der klaren Defini-tion der Vorgaben und Richtlinien deren Einhaltung tatsächlich im Projekt-verlauf kontinuierlich geprüft und kontrolliert werden muss. Dies ist inumfangreichen Entwicklungsprojekten ohne technische Hilfsmittel nichtmehr wirtschaftlich möglich.
1706-4.book Seite 19 Montag, 4. Juli 2011 3:19 15
Geleitwort der inconso AG
20
Ein solches Hilfsmittel zur Qualitätssicherung stellt der SAP Code Inspectordar. Nun ist die Verfügbarkeit eines mächtigen Werkzeugs allein natürlichnoch nicht die Lösung aller Probleme. Es bedarf einer auf den jeweiligen Ein-satzzweck hin ausgerichteten »Bedienungsanleitung«, die es erleichtert, dasWerkzeug effektiv zum Einsatz zu bringen. Und die praktische Erfahrungenberücksichtigt und einfließen lässt.
Frank Ruggaber und Reinhard Schilcher haben auf Basis ihrer langjährigenErfahrung in umfangreichen Softwareentwicklungsprojekten bei der inconsoAG zusammen mit Dr. Randolf Eilenberger, Mitentwickler des SAP CodeInspectors bei der SAP AG, mit dem vorliegenden Buch eine praxisorien-tierte Anleitung zum Einsatz des SAP Code Inspectors im Umfeld der ABAP-Entwicklung erstellt.
Ich freue mich, Ihnen mit diesem Buch ein Hilfsmittel an die Hand geben zukönnen, mit dem Sie von diesen Erfahrungen profitieren können und das Siebei der Erstellung von Software mit höchster Codequalität unterstützt.
Bertram SalzingerVorstandsvorsitzender der inconso AG
1706-4.book Seite 20 Montag, 4. Juli 2011 3:19 15
21
Einleitung
Sicherlich haben Sie es selbst auch schon erlebt: Ob im Internet, in Fachzeit-schriften oder im Buchhandel, bis auf ein paar kurze Artikel zu einfachenInspektionseinstellungen und zu einigen Prüfungen im SAP Code Inspectorsind zu diesem Thema keine genaueren Informationen zu finden. Uns, FrankRuggaber und Reinhard Schilcher, erging es ebenfalls so, als wir für diverseKundenprojekte nähere Informationen zum Code Inspector suchten.Obwohl wir bereits in früheren Projekten etliche Code-Inspector-Standard-prüfungen ausgiebig verwendet hatten, gab es einige Bereiche, wie zum Bei-spiel die Erstellung eigener Prüfungen, die automatisierte Prüfung bei derTransportfreigabe oder das genaue Wissen um die Einsatzmöglichkeitenbestimmter SAP-Standardprüfungen, die wir uns erst im Lauf der Zeit erar-beiten mussten. Nach mehreren Kundenprojekten hatten wir durch Code-analyse und Debugging bereits so viel an Informationen zusammengetragenund in firmeneigenen Dokumentationen niedergeschrieben, dass allmählichdie Idee reifte, dieses umfangreiche Wissen zu einem so wichtigen Themaauch anderen zugänglich zu machen. Und so haben wir im April 2010beschlossen, ein umfassendes Buch zum SAP Code Inspector zu veröffent-lichen.
Um bei diesem Thema auch fachlich eine möglichst kompetente Unterstüt-zung zu erhalten, haben wir bei SAP einen der drei Entwickler des SAP CodeInspectors, Dr. Randolf Eilenberger, um seine Mitwirkung bei unseremBuchprojekt gebeten. Er erklärte sich sofort bereit, uns beim Schreiben desBuches tatkräftig zu unterstützen.
Ein Fachbuch zu einem SAP-Thema, da gibt es nur einen Verlag, der dafürinfrage kommt, nämlich SAP PRESS. Schon bei der ersten Kontaktaufnahmezeigte Stefan Proksch aufseiten des Lektorats ein reges Interesse an einerVeröffentlichung dieses wichtigen Themas und riet uns, das Werk als Praxis-handbuch zu schreiben.
Zielsetzung
Das Ergebnis liegt nun vor Ihnen: Mit diesem Buch halten Sie ein umfassen-des Werk zum Thema SAP Code Inspector in Ihren Händen. Dieses Buch
1706-4.book Seite 21 Montag, 4. Juli 2011 3:19 15
Einleitung
22
behandelt eines der, unserer Meinung nach, wichtigsten Werkzeuge zurQualitätssicherung in der Entwicklung. Die Konstellation der Autoren sorgtdafür, dass zum einen extrem wichtiges Hintergrundwissen und zum ande-ren praxisnahe Erfahrungen aus dem täglichen Projekteinsatz in das Buchmit eingeflossen sind. Im ersten Teil (Kapitel 1 bis 4) finden Sie eine Schritt-für-Schritt-Anleitung zum Einsatz des SAP Code Inspectors als Werkzeugeiner automatisierten Qualitätssicherung. Im zweiten Teil (Kapitel 5) findenSie für den täglichen Gebrauch eine umfassende Referenz aller mit dem SAPCode Inspector ausgelieferten Prüfungen. Und im Gegensatz zu vielenanderen brandneuen Themen können Sie sicher sein, dass dieses Werkzeugauf Ihrem SAP-System inzwischen ausgereift zur Verfügung steht. Denn derSAP Code Inspector wurde bereits mit dem SAP Web Application Server6.10 ausgeliefert (siehe Abschnitt »Systemvoraussetzungen« in dieser Ein-leitung).
Ein weiterer Vorteil dieses Werkzeuges besteht darin, dass Sie es bereits zuAnfang einer Entwicklungsphase einsetzen können. Denn die Erfahrung ausder Praxis zeigt, je früher Werkzeuge zur Qualitätssicherung in der Entwick-lungsphase eingesetzt werden, desto effizienter wird der Entwicklungs-prozess an sich. Letztendlich können dadurch aufwendige Nacharbeiten ver-mieden werden. Außerdem unterstützt ein automatisierter Einsatz vonWerkzeugen zur Qualitätssicherung die Entwickler bei der Einhaltung vonEntwicklungsstandards, was wiederum bei der Wartung und bei späterenProgrammerweiterungen bares Geld und Entwicklernerven sparen hilft.
Wir möchten Ihnen dies an einem Beispielszenario verdeutlichen, wie es inden meisten SAP-Projekten tagtägliche Praxis ist: Auf einem SAP-System ent-wickeln verschiedene Gruppen die unterschiedlichsten Anwendungen. Hier-bei gibt es Entwickler aus dem eigenen Unternehmen sowie externe Ent-wickler von verschiedenen Partnern. In diesem Unternehmen existierenEntwicklungsrichtlinien, in denen zum Beispiel Architekturvorgaben,Namenskonventionen und andere Vorgaben zur SAP-Entwicklung festgehal-ten sind. Nun soll sichergestellt werden, dass die definierten Entwicklungs-richtlinien von allen beteiligten Entwicklern eingehalten werden. Außerdemsollen alle Entwicklungen, bevor sie das Entwicklungssystem verlassen, aufAspekte wie Sicherheit, Performance und Robustheit hin geprüft werden,um dadurch das Produktivsystem zu schützen. Im Rahmen dieses Szenariosgibt es verschiedene Gruppen, die den SAP Code Inspector als Werkzeug zurQualitätssicherung in der Entwicklung nutzen können. Genau für diesehaben wir dieses Buch geschrieben.
1706-4.book Seite 22 Montag, 4. Juli 2011 3:19 15
Einleitung
23
Zielgruppen
An einem typischen SAP-Projekt mit kundeneigenen Entwicklungen sindnormalerweise zwei verschiedene Gruppen mit unterschiedlichen Betrach-tungsweisen beteiligt:
� zum einen die Gruppe der Berater und Entwickler, die die vorgegebenenQualitätsstandards erfüllen sollen
� zum anderen die Gruppe der SAP-Kunden, die die Entwicklungen der ver-schiedenen Berater und Entwickler auf Einhaltung der Qualitätsstandardshin prüfen möchten
An beide Lesergruppen wendet sich unser Buch. An einer SAP-Entwicklungkönnen hierbei folgende Rollen beteiligt sein:
� Qualitätsmanager überprüfen die realisierten SAP-Entwicklungen auf dieEinhaltung von Qualitätsstandards hin, die zum Beispiel in Form von Ent-wicklungsrichtlinien definiert wurden. Denn letztendlich sollten Entwick-lungsrichtlinien kein reiner Selbstzweck sein, sondern dazu dienen, eineperformante, wartungsfähige, robuste und sichere Software entwickeln zuhelfen. Sollten in Ihrem Unternehmen noch keine Entwicklungsricht-linien für die SAP-Entwicklung vorhanden sein, bietet das Buch ABAP-Programmierrichtlinien (SAP PRESS, 2009) einen guten Ausgangspunkt.
� Projektleiter müssen sich im Verlauf eines Projektes immer einen Über-blick über den aktuellen Stand der Entwicklungen verschaffen können.Hierbei stehen zum Beispiel folgende Fragestellungen im Vordergrund:
� Wie viel des gesamten Entwicklungsumfangs wurde bereits program-miert?
� Gibt es besonders inperformante oder sicherheitskritische Entwick-lungen?
� Werden die definierten Qualitätsstandards auch eingehalten?
Der Code Inspector ist das richtige Werkzeug, um all diese Fragen, undnoch mehr, beantworten zu können.
� Entwickler sollen die vorgegebenen Entwicklungsstandards einhalten unddefinierte Best Practices beachten, um bereits von Anfang an Fehler imCoding zu vermeiden. Sie benötigen ein Werkzeug, das möglichst durch-gängig und vollständig in ihre Entwicklungsumgebung integriert ist unddessen Benutzung so wenig Mehraufwand wie möglich erzeugt. Bei derEntwicklung des Code Inspectors durch SAP stand die Rolle des Entwick-lers als Hauptanwender des Werkzeugs im Vordergrund.
1706-4.book Seite 23 Montag, 4. Juli 2011 3:19 15
Einleitung
24
� Administratoren müssen die Infrastruktur rund um die Werkzeuge zurQualitätssicherung bereitstellen und konfigurieren. Ihr Ziel ist letztend-lich, besonders das Produktivsystem gegen alle negativen Auswirkungenvon neuen Entwicklungen zu schützen. Aspekte wie Sicherheit, Perfor-mance und Robustheit der Software stehen hierbei im Vordergrund.
Inhalt und Aufbau
Der SAP Code Inspector ist ein Werkzeug der Qualitätssicherung in der Ent-wicklung, das von den beschriebenen Zielgruppen, die an diesem Prozessbeteiligt sind, hervorragend eingesetzt werden kann. Der Inhalt diesesBuches ist dabei so gegliedert, dass für jede der Zielgruppen der jeweiligeEinstieg in die Nutzung des SAP Code Inspectors mit all seinen Facettenleicht nachvollzogen werden kann.
Das Buch wird von Kapitel zu Kapitel technisch immer anspruchsvoller unddas vorausgesetzte Wissen rund um die SAP-Systemwelt wird dabei immergrößer. Eine Ausnahme hiervon bildet das Kapitel 5, das sich als Referenz fürden täglichen Gebrauch an alle Zielgruppen richtet.
� In Kapitel 1, »Einsatz des SAP Code Inspectors«, finden Sie neben einerEinordnung des SAP Code Inspectors in die wichtigsten Testwerkzeugevon SAP eine Schritt-für-Schritt Anleitung für dessen Verwendung. Durchdie Abbildung zahlreicher Screenshots können Sie den Inhalt dieses Kapi-tels auch ohne direkten Systemzugang unterwegs nachvollziehen. Mit demWissen aus Kapitel 1 sind Sie in der Lage, Inspektionen gemäß Ihren Wün-schen zusammenzustellen und ausführen zu lassen.
� Kapitel 2, »Konfiguration und Funktionen des SAP Code Inspectors«, lie-fert Ihnen verschiedene weiterführende Themen und Werkzeuge rundum den SAP Code Inspector. Administratoren finden hier zum Beispieleinige interessante Einstellmöglichkeiten des SAP Code Inspectors. Darü-ber hinaus wird in diesem Kapitel näher auf die Benutzung von Objektkol-lektoren eingegangen und die verschiedenen Möglichkeiten zur Unter-drückung von Prüfungsmeldungen werden beschrieben. Ein Aspekt, derinsbesondere auch bei größeren Teams zum Einsatz kommen kann, ist dasVersenden der Prüfergebnisse per E-Mail.
� In Kapitel 3, »Automatisierte Prüfungen mit dem SAP Code Inspector«,wenden wir uns dann einem sehr wichtigen Themenblock zu, nämlichdem automatisierten Einsatz des SAP Code Inspectors. Als Vorkenntnissefür dieses Kapitel sollten Sie über ein grundlegendes Verständnis der SAP-Jobsteuerung sowie des SAP-Transportwesens verfügen. Um das in
1706-4.book Seite 24 Montag, 4. Juli 2011 3:19 15
Einleitung
25
Abschnitt 3.4, »Objektprüfungen bei Aufgabenfreigabe«, behandelte Bei-spiel nachvollziehen zu können, sollten Sie sich in der ABAP-Entwicklunggut auskennen. Am Ende des Kapitels zeigen wir Ihnen noch Erfahrungenaus der Praxis, die Ihnen dabei helfen, einen automatisierten Einsatz desCode Inspectors in Ihrem Umfeld zu realisieren.
� Kapitel 4, »Programmierung eigener Prüfungen für den SAP Code Inspec-tor«, enthält die wichtigsten Informationen, um eine eigene Code-Inspec-tor-Prüfung zu entwickeln, sofern Ihnen die von SAP zusammen mit demCode Inspector ausgelieferten Standardprüfungen nicht ausreichen. Die-ses Kapitel richtet sich an erfahrene Entwickler, die kundeneigene Code-Inspector-Prüfungen programmieren möchten. Es zeigt den Weg zum Ein-bau einer eigenen Prüfung in den SAP Code Inspector und liefert eineBeschreibung zu den Tabellen der Scan-Engine, die in einer eigenen Prü-fung als Datengrundlage verwendet werden können. Kapitel 4 hat daheraus Sicht der Entwicklung eher einen Referenzcharakter.
� In Kapitel 5, »Standardprüfungen des SAP Code Inspectors«, beschreibenwir alle von SAP in Release 7.0 des SAP NetWeaver Application Serverszusammen mit dem Code Inspector ausgelieferten Standardprüfungen.Hierbei gehen wir auf die möglichen Prüfungsparameter und die erzeugtenMeldungen näher ein und liefern wichtige Zusatzinformationen, die fürdas entsprechende Umfeld relevant sind. Für den praktischen Gebrauchbewerten wir die Prüfungen nach ihrer Praxisrelevanz und geben Ihnen beijeder Prüfung Empfehlungen für ihren Einsatz. Kapitel 5 ist eine Referenzfür den täglichen Umgang mit den Code-Inspector-Standardprüfungen. Essoll Ihnen insbesondere dabei helfen, die für Sie passenden Prüfungen zuidentifizieren und diese mit den jeweils richtigen Einstellungen für dieQualitätssicherung zu nutzen.
� In Anhang A, »Konstanten des SAP Code Inspectors«, finden Sie allge-meine Referenzen zu verschiedenen Bereichen des Code Inspectors.Anhang B, »Meldungen der SAP-Standardprüfungen«, listet die Meldun-gen der Code-Inspector-Standardprüfungen auf. Wichtige Begriffe, die imRahmen dieses Buches genannt, aber im jeweiligen Text nicht nähererklärt werden, sind in Anhang C, »Glossar«, beschrieben.
Systemvoraussetzungen
Der SAP Code Inspector wurde ursprünglich mit dem SAP Web ApplicationServer zu Release 6.10 SP22 eingeführt. Viele Prüfungen des SAP CodeInspectors wurden aber erst mit dem Release 6.20 ausgeliefert.
1706-4.book Seite 25 Montag, 4. Juli 2011 3:19 15
Einleitung
26
In diesem Buch wird der Stand basierend auf Release 7.0 EHP1 SP7 beschrie-ben. Nach dem Release 6.20 sind nur vereinzelt Prüfungen hinzugekommen,sodass Sie auch auf einem SAP-System mit einem Release-Stand 6.20 die meis-ten der in diesem Buch aufgeführten Beispiele nachvollziehen können sollten.Wenn Sie noch auf Release 6.10 arbeiten, können Sie mithilfe des SAP-Hin-weises 543359, »Code Inspector für SAP R/3 Release 4.6C«, die in Release6.20 verfügbaren Code-Inspector-Prüfungen in Release 6.10 einspielen.
Beispiele zu diesem Buch
Alle Beispiele zu diesem Buch sind im Paket Z_SCI_BOOK zusammengefasst.Dieses Paket mit sämtlichen Entwicklungsobjekten finden Sie in Form vonTransportdateien auf der Bonus-Seite zu diesem Buch. Den Link zur Bonus-Seite finden Sie unter http://www.sap-press.de/2525. Alternativ können Sieauch unter http://www.sap-press.de/bonus-seite den vorne im Buch abge-druckten Zugangscode eingeben.
Diese Beispiele wurden unter Release 7.0 EHP1 entwickelt, sind aber ent-sprechend abwärtskompatibel. Eine Ausnahme hiervon bildet unsere Bei-spielimplementierung einer eigenen Prüfung, die an einer Stelle mit regu-lären Ausdrücken arbeitet, die erst ab Release 7.0 des SAP NetWeaverApplication Servers zur Verfügung stehen.
Zusatzinformationen
Wichtige Hinweise und Zusatzinformationen werden in Form von grau hin-terlegten Kästen gesondert hervorgehoben. Diese Kästen haben unterschied-liche Schwerpunkte und sind mit verschiedenen Symbolen markiert:
� Achtung: Seien Sie bei der Durchführung der Aufgabe oder des Schrittesbesonders vorsichtig, der mit einem Ausrufezeichen markiert ist. EineErklärung, warum hier Vorsicht geboten ist, ist beigefügt.
� Empfehlung: Nützliche Tipps und Shortcuts, die Ihnen die Arbeit erleich-tern, sind mit einem Sternchen gekennzeichnet. Hierunter fallen auchErfahrungswerte, die wir in der Anwendung des Code Inspectors gesam-melt haben.
� Hinweis: Wird das besprochene Thema erläutert und vertieft, macht einPluszeichen Sie darauf aufmerksam.
1706-4.book Seite 26 Montag, 4. Juli 2011 3:19 15
Einleitung
27
Danksagung
Wir bedanken uns bei allen, die an der Entstehung dieses Buches mitgewirkthaben.
Besonderes möchten Frank Ruggaber und Reinhard Schilcher ihrem Arbeit-geber, der Firma inconso AG, dafür danken, dass sie dieses Projekt realisie-ren durften. Namentlich erwähnt seien insbesondere Bettina Haug-Weber,Bertram Salzinger, Robin Rösinger, Alberto Medde, Pietro Cimino, FriedgardWetzel, Britta Lubitz, Patric Mansfeld und Nikola Ruggaber.
Randolf Eilenberger dankt für das Lesen des Manuskriptes besonders Her-mann Gahm und Andreas Simon Schmitt. Letzterem gebührt zusammen mitDana Stegaru auch der Dank für die lehrreiche und interessante Zeit währendder Entwicklung des SAP Code Inspectors. Viele Kolleginnen und Kollegenaus dem Performanceteam haben mit Ideen und Diskussionen zu den einzel-nen Prüfungen beigetragen, stellvertretend erwähnt sei hier Siegfried Boes.
Bei Galileo Press danken wir insbesondere Florian Zimniak und StefanProksch für das uns entgegengebrachte Vertrauen und die professionelleUnterstützung. Zudem danken wir Osseline Fenner für die sprachliche Kor-rektur des Manuskripts sowie Maxi Beithe für die Herstellung dieses Buches.
Die Autoren möchten außerdem ihren Familien danken.
Dr. Randolf EilenbergerEntwickler, Performance & Scalability, SAP AG
Frank RuggaberSeniorberater, SAP Integration, inconso AG
Reinhard SchilcherBerater, SAP Integration, inconso AG
1706-4.book Seite 27 Montag, 4. Juli 2011 3:19 15
67
In diesem Kapitel erhalten Sie weitere Informationen zur Nutzung des SAP Code Inspectors. Hierbei gehen wir auf die Konfiguration, auf weitere Details zu den Objektkollektoren, den Pseudokommenta-ren, dem Genehmigungsverfahren und auf verschiedene Tools zum SAP Code Inspector ein.
2 Konfiguration und Funktionen des SAP Code Inspectors
Nachdem Sie den SAP Code Inspector in seinen Grundzügen kennengelernthaben, besprechen wir in diesem Kapitel weiterführende Aspekte. Zu Beginnbeschreiben wir den Verwaltungsbereich mit seinen Einstellmöglichkeitenzur Prüfvariante, zur Objektmenge und zur Meldungspriorität, gehen danngenauer auf die Objektkollektoren ein, die wir in Kapitel 1, »Einsatz des SAPCode Inspectors«, bereits erwähnt haben, machen Sie danach mit den Pseu-dokommentaren und dem Genehmigungsverfahren vertraut und liefernIhnen Informationen zum Vergleich von Inspektionsergebnissen und zum E-Mail-Versand. Abgerundet wird das Kapitel schließlich mit einer Beschrei-bung des Code-Inspector-Hintergrundjobs.
2.1 Einstellmöglichkeiten des SAP Code Inspectors
In diesem Abschnitt zeigen wir Ihnen die allgemeinen Einstellmöglichkeitendes Code Inspectors. Hierbei geht es nicht darum, Einstellungen für einekonkrete Inspektion vorzunehmen, wie wir sie bereits in Kapitel 1 beschrie-ben haben, sondern um generelle Einstellungen, die für alle Code-Inspector-Prüfvarianten und -Inspektionen gelten.
Im Wesentlichen verbergen sich die Einstellmöglichkeiten des Code Inspec-tors unter dem Menüpunkt Springen � Verwaltung von, der direkt in Trans-aktion SCI zu erreichen ist (siehe Abbildung 2.1). Um die jeweiligen Einstell-möglichkeiten anzupassen, benötigen Sie das Berechtigungsobjekt s_cov_adm
1706-4.book Seite 67 Montag, 4. Juli 2011 3:19 15
Konfiguration und Funktionen des SAP Code Inspectors2
68
mit dem Berechtigungsfeld actvt = '37'. Um die entsprechende Berechti-gung zu erhalten, fragen Sie am besten Ihren SAP-Basis-Administrator.
Abbildung 2.1 Einstellmöglichkeiten des Code Inspectors
2.1.1 Verwaltung von Tests
Über den Menüpunkt Springen � Verwaltung von � Tests können Sie fest-legen, welche Prüfungen (= Tests) bei der Anlage einer Code-Inspector-Prüf-variante im Prüfungsauswahlbaum (siehe Kapitel 1, »Einsatz des SAP CodeInspectors«) überhaupt angezeigt werden sollen.
Alle Prüfungen und deren Prüfkategorien sind mit dem Namen der Klasse, inder die Code-Inspector-Prüfung bzw. die Prüfkategorie realisiert wurde,einer kurzen Beschreibung und dem dafür Verantwortlichen (= erstellenderEntwickler der Klasse) in einer Liste aufgeführt (siehe Abbildung 2.2). Überden Klassennamen können Sie feststellen, ob es sich um eine Prüfkategorieoder eine Prüfung handelt. Testkategorien haben in der Regel den Bezeich-ner CATEGORY im Namen und Prüfungen den Bezeichner TEST. Die SpalteBeschreib. enthält die Bezeichnung aus der Hierarchie der Prüfvarianten(siehe Abschnitt 1.2.2).
1706-4.book Seite 68 Montag, 4. Juli 2011 3:19 15
Einstellmöglichkeiten des SAP Code Inspectors 2.1
69
Abbildung 2.2 Verwaltung von Tests vor SAP NetWeaver 7.0 EHP2
Eine Dokumentation, sofern vorhanden, zur entsprechenden Klasse könnenSie über Transaktion SE61 (Dokumentenpflege) finden, indem Sie dort imFeld Dokumentenklasse den Wert Klassen-Attribut auswählen, im FeldKlassen-Attribut den Namen der Klasse aus der Verwaltungsliste (sieheAbbildung 2.2) sowie im Feld darunter den Wert 0000 eintragen und dannauf den Anzeigen-Button ( ) klicken (siehe Abbildung 2.3).
Abbildung 2.3 Dokumentation zu den Code-Inspector-Prüfungen
1706-4.book Seite 69 Montag, 4. Juli 2011 3:19 15
Konfiguration und Funktionen des SAP Code Inspectors2
70
In SAP NetWeaver 7.0 EHP2 wurde die Liste der Prüfungen um zwei Spaltenerweitert, sodass Sie nun wesentlich einfacher zur Dokumentation der Klassegelangen: Mit einem Doppelklick auf das Info-Symbol ( ) in der Liste der Prü-fungen erhalten Sie, soweit vorhanden, direkt die dazugehörige Dokumentation(siehe Abbildung 2.4). Über die zweite hinzugekommene Spalte können Sie nunschnell erkennen, welcher Prüfkategorie eine Prüfung zugeordnet ist.
Abbildung 2.4 Verwaltung von Tests ab SAP NetWeaver 7.0 EHP2
Durch einen Doppelklick auf den Namen der Klasse wird der SAP Class Buil-der mit der entsprechenden Klasse geöffnet, und Sie können sich den Source-code direkt anschauen. Durch Anklicken der Spaltenköpfe können Sie dieeinzelnen Spalten markieren, die Sie dann über die Sortier-Buttons ( ,
) sortieren oder über den Filter-Button ( ) filtern können.
Doch nun zum eigentlichen Sinn der Liste der Code-Inspector-Prüfungen:Durch das Aktivieren bzw. Deaktivieren der Checkbox vor der jeweiligenZeile in der Ausgabeliste können Sie die Prüfung bzw. die Prüfkategorie imAuswahlbaum der Prüfvarianten (siehe Abschnitt 1.2.2) sichtbar oderunsichtbar schalten. Nachdem Sie alle Einträge wie gewünscht eingestellthaben, müssen Sie Ihre Änderung durch den Speichern-Button ( ) in derButton-Leiste sichern. Beim erstmaligen Speichern mit Ihrem Benutzer-namen werden Sie nach einem Customizing-Transportauftrag gefragt, unterdem Sie die Änderungen sichern möchten. Über diesen Transportauftragkönnen Sie dann die Einstellungen mittels des SAP-Transportwesens aufweitere SAP-Systeme verteilen.
1706-4.book Seite 70 Montag, 4. Juli 2011 3:19 15
Einstellmöglichkeiten des SAP Code Inspectors 2.1
71
Vorsicht ist allerdings beim Deaktivieren von Prüfkategorien geboten, denennoch aktive Code-Inspector-Prüfungen zugeordnet sind. Wenn Sie eine solchePrüfkategorie deaktivieren und zugehörige Prüfungen noch aktiviert sind,erhalten Sie bei Anlage einer Prüfvariante die folgende Fehlermeldung: »Ungül-tige Kategorie-Klasse … in der Prüfvariante«. Nach Bestätigung der Fehlermel-dung bricht die Code-Inspector-Transaktion ab. Ab Release 7.0 EHP2 erscheintin der Verwaltungsliste der Prüfungen bei einer Prüfung das Warn-Symbol( ), falls die dazugehörige Prüfkategorie nicht existiert oder ausgeschaltet ist.
2.1.2 Verwaltung von Objektkollektoren
In der Verwaltung der Objektkollektoren (siehe Kapitel 1, »Einsatz des SAPCode Inspectors«) können Sie die Objektkollektoren markieren, die in derWertehilfe zum Feld Objektkollektor in der Objektmenge angezeigt wer-den sollen (siehe Abschnitt 2.2). Über das Menü Springen � Verwaltung
von � Objektkollektoren in Transaktion SCI gelangen Sie zur Einstellungder Objektkollektoren.
Die Vorgehensweise bei der Verwaltung der Objektkollektoren ist weitge-hend identisch mit der Verwaltung der Tests, wie sie in Abschnitt 2.1.1beschrieben wurde. Wie Sie anhand von Abbildung 2.5 sehen können,befindet sich in der Spalte Objektkollektor der Name der ABAP-Klasse, inder der Objektkollektor implementiert wurde. Über einen Doppelklick aufden Klassennamen wird die Klasse im SAP Class Builder geöffnet, und Siekönnen den dazugehörigen Sourcecode betrachten. Der Text in der SpalteObjektkollektorbeschreibung entspricht dem Text aus der Wertehilfe zumFeld Objektkollektor in Abschnitt 2.2.
Empfehlung
Bei der Verwaltung von Tests (= Prüfungen) sollten Sie besondere Vorsicht bei derDeaktivierung von Prüfkategorien walten lassen. Denn von dieser Prüfkategorieabhängige, eingeschaltete Prüfungen können zum Abbruch des Code Inspectorsbei der Prüfvariantenauswahl führen. Daher sollten Sie die vorgenommenen Ände-rungen immer sofort durch die Anlage einer entsprechenden Prüfvariante (sieheAbschnitt 1.2.2) verifizieren.
Ab Release 7.0 EHP2 können Sie von Prüfkategorien abhängige Prüfeinträge schonin der Verwaltungsliste der Tests (= Prüfungen) einfach über einen Vergleich derSpalte Prüfungs-Kategorie bei Prüfungen mit der Spalte Beschreib. bei Prüfkatego-rien ermitteln.
Darüber hinaus sollten bestimmte Prüfungen und Prüfkategorien nicht markiertwerden. Mehr dazu finden Sie in Kapitel 5, »Standardprüfungen des SAP CodeInspectors«.
1706-4.book Seite 71 Montag, 4. Juli 2011 3:19 15
Konfiguration und Funktionen des SAP Code Inspectors2
72
Abbildung 2.5 Verwaltung von Objektkollektoren vor Release 7.0 EHP2
Wie bei der Verwaltung von Tests ist auch die Dokumentation zum Objekt-kollektor in Transaktion SE61 über den Namen der Klasse erreichbar (sieheauch Abbildung 2.3). Und ebenso wie bei der Verwaltung der Tests ist dieListe zur Verwaltung der Objektkollektoren ab Release 7.0 EHP2 um eineweitere Spalte mit einem direkten Link zur Dokumentation über den Info-Button ( ) erweitert worden (siehe Abbildung 2.6).
Abbildung 2.6 Verwaltung von Objektkollektoren ab Release 7.0 EHP2
Durch Aktivieren bzw. Deaktivieren der Checkbox vor dem Namen derABAP-Klasse in der jeweiligen Zeile der Verwaltungsliste kann der Objekt-kollektor in der Wertehilfe für die Objektkollektoren sichtbar oder unsicht-bar gemacht werden. Änderungen müssen ebenso wie bei der Verwaltungvon Tests über den Speichern-Button ( ) in der Button-Leiste gespeichertund einem Customizing-Transportauftrag zugeordnet werden.
Eine Beschreibung der einzelnen Objektkollektoren finden Sie in Abschnitt2.2.
1706-4.book Seite 72 Montag, 4. Juli 2011 3:19 15
Einstellmöglichkeiten des SAP Code Inspectors 2.1
73
2.1.3 Verwaltung von Meldungsprioritäten
Im Zusammenhang mit dem Ergebnis einer Inspektion haben wir bereits inKapitel 1, »Einsatz des SAP Code Inspectors«, die verschiedenen Meldungs-typen des Code Inspectors beschrieben (siehe auch Abbildung 2.7). Je nachzugeordnetem Meldungstyp erscheinen Problemfälle, die durch die jewei-lige Code-Inspector-Prüfung in den zu prüfenden Objekten festgestellt wer-den, in den entsprechenden Spalten (Fehler, Warnung oder Information) desErgebnisses der Inspektion (siehe Kapitel 1).
Abbildung 2.7 Meldungstypen des Code Inspectors
In der Praxis kann es in bestimmten Fällen sinnvoll sein, die Meldungstypender verschiedenen Code-Inspector-Prüfungen anzupassen. Ein Beispiel hier-für könnte die Prüfung auf sequenzielles Lesen aus internen Tabellen vomTyp STANDARD TABLE sein, die Sie von Fehler auf Warnung umstellen möch-ten. Dies können Sie über den Menüeintrag Springen � Verwaltung von �Meldungsprioritäten aus der Transaktion SCI heraus tun. Einen Ausschnittdes entsprechenden Dialogs sehen Sie in Abbildung 2.8.
Die in der Verwaltung von Tests sichtbar geschalteten Prüfungen (sieheAbschnitt 2.1.1) werden in der Einstellung der Meldungsprioritäten eben-falls in hierarchischer Form angezeigt (siehe Abbildung 2.8). Da die Prüfun-gen meist Teilprüfungen enthalten, gibt es somit oft auch mehr als nur eineeinzige Meldung; diese erscheinen dann als weitere Unterknoten zu den ein-zelnen Prüfungen in der Spalte Code-Inspector-Prüfung. Auf der Ebene dereinzelnen Meldungen können Sie deren Meldungspriorität einstellen, sofernin der Spalte Standardpriorität ein Symbol angezeigt wird. Wird in dieserSpalte kein Symbol angezeigt, ist die entsprechende Meldungspriorität, diebei der Prüfung ausgegeben wird, im Coding zu der jeweiligen Prüfung(siehe Kapitel 4, »Programmierung eigener Prüfungen für den SAP CodeInspector«) hart verdrahtet und kann nur durch Anpassung des Sourcecodesdieser Prüfung geändert werden.
1706-4.book Seite 73 Montag, 4. Juli 2011 3:19 15
Konfiguration und Funktionen des SAP Code Inspectors2
74
Abbildung 2.8 Meldungsprioritäten verwalten
Die Meldungspriorität einer Prüfung können Sie ändern, indem Sie in derSpalte Standardpriorität auf das passende Symbol in der gewünschtenZeile klicken. In Abbildung 2.9 wurde dies für die Meldung »große Tabelle&1: Keine WHERE-Bedingung« in der Zeile oberhalb der Dialogbox getan.Hier sehen Sie an dem grünen Symbol ( ) in der Spalte Aktuelle Priori-
tät, dass die aktuelle Meldungspriorität für diese Meldung auf Information
steht, die Originaleinstellung für diese Meldung finden Sie in der SpalteStandardpriorität. Im Dialog zur Änderung der Meldungspriorität sehenSie im Feld Aktuell die aktuell eingestellte Priorität sowie im Feld Standard
die Standardpriorität. Im Feld Neu können Sie eine neue Priorität für dieMeldung festlegen. Den letzten Änderer und das Änderungsdatum sehen Siein den Feldern Verantwortlicher und Geändert am.
Die Meldungstexte, die Sie in der Spalte Prüfung / Meldungstext angezeigtsehen, sind die Meldungstexte, wie sie in der Ergebnisliste einer Inspektionausgegeben werden. Über das Info-Symbol ( ) in der hierarchischenSpalte Code-Inspector-Prüfungen können Sie, sofern vorhanden, die jewei-lige Dokumentation der entsprechenden Prüfung öffnen.
1706-4.book Seite 74 Montag, 4. Juli 2011 3:19 15
Objektkollektoren 2.2
75
Abbildung 2.9 Ändern einer Meldungspriorität
Sofern in einer Prüfung eine Ausnahme verfügbar ist, können Sie in der letz-ten Spalte Ausnahme den jeweiligen sogenannten Pseudokommentar ab-lesen, mit dem Sie die Meldungsausgabe unterdrücken können. Mehr zudiesem Thema finden Sie in Abschnitt 2.3.1.
2.2 Objektkollektoren
In diesem Abschnitt werden die einzelnen Objektkollektoren genauer vorge-stellt. Die Objektkollektoren dienen zum Sammeln von Objekten, die nichtdirekt aus Entwicklungskomponenten oder aus bereits erzeugten Objekt-mengen, sondern aus anderen Quellen ermittelt werden. So stammen dieseObjekte zum Beispiel aus Prüfergebnissen anderer SAP-Tools, aus Dateienoder aus einer Umfeldermittlung.
Hinweis
An dieser Stelle können Sie weder Meldungstexte noch Pseudokommentareändern; diese werden hier nur angezeigt. Mehr zur Erstellung und Änderung vonMeldungstexten bzw. Pseudokommentaren finden Sie in Kapitel 4, »Programmie-rung eigener Prüfungen für den SAP Code Inspector«.
1706-4.book Seite 75 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
284
5.4.16 SELECT INTO CORRESPONDING FIELDS bei gepufferten Tabellen
� Relevanz:
� Prüfklasse: cl_ci_test_select_correspond
� Objekttypen: 1PRG
� Anmerkung: Diese Prüfung ist in Ihrem System vermutlich nicht im Baumder Prüfungen sichtbar. Um sie verwenden zu können, wählen Sie die Prü-fung mithilfe des Code-Inspector-Menüs Springen � Verwaltung Von �Tests aus, und sichern Sie die Einstellung.
Kurzbeschreibung
Diese Prüfung untersucht, ob ein lesender Zugriff auf eine gepufferte Tabellemit dem Zusatz INTO CORRESPONDING FIELDS erfolgt. Dies ist nicht sonderlichkritisch, kann aber doch einen gewissen Mehraufwand bedeuten.
Details
Sind bei einer SELECT-Anweisung die Struktur der Datenbanktabelle und dieZielstruktur in ABAP nicht identisch, kann mit dem Zusatz INTO CORRESPON-DING FIELDS ein Mapping der Felder vorgenommen werden. Dies ist beiWeitem nicht so teuer, wie oft behauptet wird, und spielt deshalb bei Zugrif-fen auf nicht gepufferte Tabellen praktisch keine Rolle. Selbst bei gepuffertenTabellen halten sich die relativen Mehrkosten in Grenzen. Dennoch solltenSie, wo immer möglich, mit identischen Strukturen in Datenbank und inABAP arbeiten, um die Zuordnungskosten gering zu halten.
Meldungen
Siehe Anhang B, »Meldungen der SAP-Standardprüfungen«.
5.4.17 Prüfung der Tabelleneigenschaften
� Relevanz:
� Prüfklasse: cl_ci_test_ddic_tables
� Objekttypen: TABL, VIEW
Empfehlung
Führen Sie diese Prüfung nur aus, wenn Sie gezielt nach der Verwendung derOption INTO CORRESPONDING FIELDS bei Zugriffen auf gepufferte Tabellen suchenmöchten. Das direkte Einlesen gepufferter Daten in eine kompatible ABAP-Daten-struktur, das ohne diese Option auskommt, ist schneller.
1706-4.book Seite 284 Montag, 4. Juli 2011 3:19 15
Performanceprüfungen 5.4
285
Kurzbeschreibung
Diese Prüfung analysiert die Konsistenz der technischen Einstellungen vonDatenbanktabellen und -Views im ABAP Dictionary, insbesondere die Puffe-reinstellungen und die für diese Objekte angelegten Sekundärindizes.
Parameter
Die ersten beiden Parameter aktivieren die wichtigsten Teilprüfungen, diebeiden anderen Parameter später hinzugekommene Zusatzprüfungen:
� Technische EinstellungenDieser Parameter dient der Überprüfung von technischen Einstellungenwie Auslieferungsklasse, Datenart und Größenkategorie.
� TabellenindizesDieser Parameter dient der Überprüfung einiger einfacher Regeln fürTabellenindizes.
� Pufferung INDX-artige TabelleDiese Option sucht nach gepufferten, INDX-artigen Tabellen. Da auf solcheTabellen in der Regel mit der Anweisung IMPORT FROM DATABASE zugegrif-fen wird, ergibt eine Pufferung selten Sinn.
� View ignoriert MandantenabhängigkeitDiese Einstellung untersucht Datenbank-Views, bei denen mindestenseine der im View vereinigten Tabellen mandantenabhängig ist, aber dasMandantenfeld nicht in der JOIN-Bedingung enthalten oder der Mandantnicht das erste Feld im Datenbank-View ist.
Details
Die Eigenschaften einer Datenbanktabelle bzw. eines Datenbank-Views wer-den in Transaktion SE11 gepflegt. Leider bietet das ABAP Dictionary keinetatkräftige Unterstützung bei der Auswahl von konsistenten und unter Per-formanceaspekten sinnvollen Einstellungen. Die vorliegende Prüfung mahntim Nachhinein unstimmige Parameterkombinationen an, sagt aber nichtimmer ganz genau, wie die Einstellungen sein sollten. Als Hilfe finden Siehier in Abbildung 5.4 eine Übersicht über konsistente Einstellungen für diePufferung in Abhängigkeit von der Auslieferungs- und Datenklasse.
1706-4.book Seite 285 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
286
Abbildung 5.4 Empfohlene Einstellungen für die Tabellenpufferung in Abhängigkeit von der Datenklasse und der Auslieferungsklasse
Im Folgenden gehen wir kurz auf die wichtigsten technischen Eigenschafteneiner Tabelle und deren Bedeutung ein:
� AuslieferungsklasseDieser Parameter wird auf der Registerkarte Auslieferung und Pflege
gepflegt und legt fest, wie sich die Daten einer Tabelle bei Systeminstal-lation und -Upgrade, Mandantenkopie und beim Transport zwischenSystemen verhalten. Die wichtigsten Auslieferungsklassen sind A fürAnwendungsdaten (Stammdaten und transaktionale Daten) sowie C fürKonfigurationsdaten. Daneben gibt es noch die Klassen L, G, E, S und W.Genaueres erfahren Sie in der (F1)-Hilfe für das Feld Auslieferungsklasse.
� DatenklasseDieser Wert wird unter den Technischen Eigenschaften in TransaktionSE11 eingestellt. Für manche der von SAP unterstützten Datenbankplatt-formen legt dieser Wert fest, in welchem physischen Bereich der Daten-bank eine Tabelle abgelegt wird. Die Datenklasse wird vom Code Inspec-tor herangezogen, um eine Tabelle bezüglich der in ihr enthaltenen Dateneinstufen zu können, und wirkt sich auf einige der Prüfergebnisse aus. Siesollten daher korrekt pflegen, ob eine Tabelle der Datenklasse APPL0(Stammdaten), APPL1 (transaktionale Daten) oder APPL2 (Konfigurations-daten) angehört.
Auslieferungsklasse
APPL0Stammdaten
APPL1Transaktionale Daten
APPL2Konfigurationsdaten
SystemSystemdaten
Andere
C
Neutrale Kombination
Unerwünschte Kombination
Tabelle sollte gepuffert werden
Tabelle sollte nicht gepuffert werden
Tabelle sollte nicht gepuffert werden,Ausnahme: kleine Tabellen
P P P P
P P
P
P P
P P P P
P
P P
P* P*
P
G E S W A L
Datenklasse
P
P
P
P*
1706-4.book Seite 286 Montag, 4. Juli 2011 3:19 15
Performanceprüfungen 5.4
287
� GrößenkategorieDie Größenkategorie einer Tabelle wird ebenfalls in den Technischen
Eigenschaften gepflegt und ist dazu gedacht, den initialen Platzbedarf füreine Tabelle abzuleiten und auf der Datenbank zu reservieren. DieseGröße wird vom Code Inspector genutzt, um einen Hinweis auf die Größeeiner Tabelle im produktiven Gebrauch zu erhalten. Das Zählen der Ein-träge in einer Tabelle während einer Prüfung verbietet sich aus Perfor-mancegründen; außerdem kann das Prüfwerkzeug in einem Testsystemlaufen, in dem die Tabelle nur wenige Einträge hat. Da ist die vom Ent-wickler nach bestem Wissen gepflegte Größenkategorie schon aussage-kräftiger.
� Pufferung und PufferungstypTabellen, die im produktiven Betrieb häufig gelesen, aber selten geändertwerden (in der Regel Konfigurationstabellen) sollten gepuffert werden.Bei den Technischen Einstellungen kann hierzu die Pufferung einge-schaltet und die Art der Pufferung definiert werden. Das Einschalten derPufferung kann im Widerspruch zur gewählten Auslieferungs- oderDatenklasse oder auch zur Größenkategorie stehen – sehr große Tabellensollten zum Beispiel nicht gepuffert werden.
� IndizesHäufig ausgeführte Datenbankanweisungen sollten durch einen Daten-bankindex unterstützt werden, der eine schnelle Suche nach den ge-wünschten Datenbanksätzen ermöglicht. Es gibt einige Faustregeln für In-dizes: So sollte es für eine Tabelle nicht zu viele Indizes geben, ein Indexsollte nicht zu viele Felder enthalten, verschiedene Indizes einer Tabellesollten möglichst wenige Felder redundant aufweisen etc. Gerade hier giltaber wie bei allen Performanceregeln: Ein statisches Werkzeug wie derCode Inspector kann nur »Fragen« an den Entwickler stellen. Dieser mussdann den Sachverhalt prüfen und kann zu einem anderen Ergebnis kom-men als das Tool. Manchmal kann zum Beispiel ein zusätzlicher Indexoder ein Index mit »zu vielen« Feldern durchaus berechtigt sein.
Meldungen
� 0001, 0002»Keine Tabellen- oder Auslieferungsklasse ausgewählt«»Keine Datenklasse oder Größenkategorie ausgewählt«
Pflegen Sie diese Einstellungen, da diese vom Code Inspector zum Beispielbei der Analyse von Datenbankzugriffen verwendet werden.
1706-4.book Seite 287 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
288
� 0003, 0004»›Pufferung erlaubt, aber ausgeschaltet‹ ausgewählt«
Diese Einstellung für die Tabellenpufferung ergibt aus Performancesichtkeinen Sinn. Der Entwickler sollte wissen, ob sich eine Tabelle für die Puf-ferung eignet oder nicht – später kann diese Entscheidung kaum nochjemand treffen. Einzig bei Tabellen, die im produktiven Betrieb abhängigvom Kunden sowohl sehr klein als auch sehr groß sein können, kann esangebracht sein, die Pufferung zu erlauben, aber das Ein- bzw. Ausschal-ten von den Gegebenheiten beim Kunden abhängig zu machen. Sonst gilt:Entscheiden Sie sich für oder gegen die Pufferung.
� 0010»Pufferungstyp ist initial, aber Auslieferungsklasse ist ›C‹, ›G‹, ›E‹ oder ›S‹«Die Auslieferungsklasse der gemeldeten Tabelle deutet darauf hin, dass essich um eine Konfigurations- (Auslieferungsklasse C oder G) oder System-tabelle (Auslieferungsklasse E oder S) handelt. Solche Tabellen sind in derRegel klein und werden selten geändert, eignen sich daher zur Pufferung.Für eine konsistente Einstellung sollten diese Tabellen der DatenklasseAPPL2 (Konfigurationsdaten) zugeordnet sein.
Sollte die Tabelle keine Konfigurations- oder Systemdaten enthalten,haben Sie vielleicht eine falsche Auslieferungsklasse gewählt.
� 0011»Pufferung ist aktiviert, aber Auslieferungsklasse ist ›A‹ oder ›L‹«
Die Auslieferungsklasse der gemeldeten Tabelle deutet darauf hin, dass essich um eine Anwendungstabelle (A) mit Stamm- oder Bewegungsdatenoder um eine Tabelle mit temporären Daten (L) handelt. Eine solcheTabelle hat in der Regel viele Daten und wird häufig geändert. Im Allge-meinen sollte eine solche Tabelle nicht gepuffert werden – eine Ausnahmekönnen kleine Stammdatentabellen bilden. Für eine konsistente Einstel-lung sollten diese Tabellen der Datenklasse APPL0 (Stammdaten) oderAPPL1 (Bewegungsdaten) zugeordnet sein.
Enthält die Tabelle nicht die beschriebene Art von Daten, ist vermutlichdie Auslieferungsklasse falsch gewählt.
� 0012»Pufferung ist aktiviert, aber Größenkategorie ist > 2«
Sehr große Tabellen sollten, auch wenn die anderen Bedingungen für einePufferung gegeben sind, nicht gepuffert werden. Dies kann nämlich zurFolge haben, dass zahlreiche kleinere gepufferte Tabellen aus dem Pufferverdrängt werden. Werden in einem Programm immer nur wenige Ein-
1706-4.book Seite 288 Montag, 4. Juli 2011 3:19 15
Performanceprüfungen 5.4
289
träge aus der großen Tabelle benötigt, kann eine Einzelsatzpufferung odereine feingranulare generische Pufferung der Tabelle angemessen sein.
Falls die Tabelle nur wenige Einträge hat und die Pufferung daher ver-nünftig ist, haben Sie wahrscheinlich die Größenkategorie der Tabellefalsch gepflegt.
� 0013, 0014»Pufferung ist initial, aber Datenklasse ist "APPL2"«»Pufferung ist aktiviert, aber Datenklasse ist "APPL0"/"APPL1"«
Datenklasse und Pufferung müssen zusammenpassen. In der Regel solltenTabellen der Datenklasse APPL2, das heißt Konfigurationstabellen, gepuf-fert sein. Tabellen der Datenklassen APPL0 bzw. APPL1, das heißt solchemit Stamm- oder Bewegungsdaten, sollten dagegen nicht gepuffert wer-den. Eine Ausnahme bilden wie gesagt kleine Stammdatentabellen, dieebenfalls gepuffert werden können.
� 0015»Pufferung ist aktiviert, aber kein Pufferungstyp ausgewählt«
Wählen Sie einen geeigneten Pufferungstyp aus. Wenn sich ein Entwick-ler für die Pufferung einer Tabelle entscheidet, dann sollte er auch denTyp der Pufferung (einzelsatz-, generisch, vollständig gepuffert) anhandder beabsichtigten Zugriffe festlegen.
� 0016, 0017»Pufferung ist erlaubt, aber Tabelle ist im DB-View dbview enthalten«»Pufferung ist erlaubt, aber Tabelle kann über DB-View geändert werden«
Zunächst zur zweiten Meldung: Ein Datenbank-View auf eine gepufferteTabelle, mit dem Einträge der Tabelle geändert werden können, warzumindest bis einschließlich Release 6.40 sehr kritisch. Es kam nämlichbei Datenänderungen über den View nicht zu einer Invalidierung desTabellenpuffers, was zu Inkonsistenzen beim Lesen der gepuffertenTabelle führen konnte. Ab Release 7.0 wird auch bei Änderungen derDaten über den Datenbank-View der Puffer invalidiert.
Die Meldung 0016 ist eine der umstrittensten Code-Inspector-Meldun-gen: Was soll schlecht daran sein, einen nicht gepufferten Datenbank-View für eine gepufferte Tabelle zu definieren – und warum gibt es eineMeldung für die Tabelle, und nicht für den Datenbank-View? Die Argu-mente der Prüfung sind: Wenn man sich schon die Mühe macht, Daten imSAP-Tabellenpuffer zu puffern, dann sollten die Daten auch in den aller-meisten Fällen aus dem Puffer gelesen werden und nicht doch von derDatenbank. Die Existenz eines Datenbank-Views auf den Daten zeigt aber
1706-4.book Seite 289 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
290
an, dass der Entwickler auch noch andere Zugriffe beabsichtigt, die nichtdurch einen Puffer optimiert sind (ist der Datenbank-View zu einer gepuf-ferten Tabelle selbst ebenfalls gepuffert, wird keine Meldung erzeugt).Der »Besitzer« der gepufferten Tabelle erhält eine Meldung, da er in derRegel der Verantwortliche für die Daten ist und daher wissen sollte, wennein anderer Entwickler ein eigenes »Datenzugriffskonzept« – den Daten-bank-View eben – für diese Daten implementiert.
� 0020, 0021»Tabelle hat mehr als 100/700 Felder«
Eine Tabelle sollte nicht zu viele Felder aufweisen, einerseits weil es tech-nische Grenzen gibt, hauptsächlich aber der Übersichtlichkeit wegen. FürSAP Business ByDesign gilt hier die strengere Prüfung auf maximal 100Felder hin, sonst gilt die Grenze von 700 Feldern.
� 0022, 0023»Änderungsprotokoll aktiv trotz Datenklasse "APPL0" oder "APPL1"«»Änderungsprotokoll aktiv bei großer Tabelle«
Das Änderungsprotokoll für eine Tabelle wird in den Technischen Eigen-
schaften durch Setzen des Flags Datenänderungen protokollieren
aktiviert. Wurde zusätzlich der Systemparameter rec/client für denMandanten gesetzt, wird für jede Änderung der Tabelle ein Protokollein-trag geschrieben, der mit Transaktion SCU3 angezeigt werden kann. Esversteht sich, dass für Stamm- und Bewegungsdaten (Datenklassen APPL0und APPL1) sowie generell für große Tabellen (Größenkategorie > 2) keinÄnderungsprotokoll geschrieben werden sollte. Hier fallen einfach zuviele Daten an, deren Protokollierung zudem den Produktivbetrieb desSAP-Systems ausbremsen kann.
� 0030»Tabelle hat einen eindeutigen Sekundärindex«
Dies ist eine Informationsmeldung von geringer (Performance-)Relevanz.Jeder Entwickler, der in eine solche Tabelle Daten einfügt, sollte sich aberdes eindeutigen Indizes bewusst sein: Wird versucht, zur Laufzeit Sätze indie Datenbank einzufügen, die bezüglich des Sekundärindizes identischsind, kommt es zu einem Laufzeitfehler »Insert Duplicate Keys«.
� 0031, 0034, 0131, 0134»Tabelle hat mehr als 4 (7) Sekundärindizes, obwohl die Datenklasse "APPL0" ist«
1706-4.book Seite 290 Montag, 4. Juli 2011 3:19 15
Performanceprüfungen 5.4
291
»Tabelle hat mehr als 2 (5) Sekundärindizes, obwohl die Datenklasse "APPL1" ist«
Es sollte pro Datenbanktabelle nicht zu viele Sekundärindizes geben.Denn einerseits erhöht jeder Index die Kosten für Einfüge- und Ände-rungsoperationen für die Datenbanktabelle (Letztere nur, wenn bei einerÄnderung auch Felder des Sekundärindizes betroffen sind). Andererseitskann es sein, dass der kostenbasierte Optimierer der Datenbank, der dieStrategien für einen Datenbankzugriff berechnet, bei zu vielen Indizes denÜberblick verliert.
Abhängig von der Datenklasse, informiert diese Prüfung bei mehr als vierSekundärindizes (APPL0 = Stammdaten) bzw. bei mehr als zwei Sekun-därindizes (APPL1 = Bewegungsdaten). Eine Warnung gibt es bei mehr alssieben (APPL0) bzw. bei mehr als fünf Sekundärindizes (APPL1).
� 0032»Sekundärindex sec_index: mehr als 4 Felder«
»Fasse Dich kurz« gilt auch bei Indizes. Mehr als vier Felder können aus-nahmsweise, zum Beispiel bei einem beabsichtigten Index-only-Zugriff,vernünftig sein. In der Regel sollten Sie aber mit vier oder weniger Fel-dern auskommen. Die Prüfung zählt das Mandantenfeld nicht zu denIndexfeldern hinzu.
� 0033»Tabelle hat nicht-eindeutigen Sekundärindex, ist aber gepuffert«
Hier gilt Ähnliches wie bei einem Datenbank-View auf einer gepuffertenTabelle: Ein Sekundärindex deutet darauf hin, dass neben den gepuffertenZugriffen auch Zugriffe via Sekundärschlüssel beabsichtigt sind. Es musssichergestellt sein, dass der doppelte Aufwand sich lohnt und im Produk-tivbetrieb tatsächlich sowohl Puffer- als auch Indexzugriffe stattfinden.Die Einschränkung auf »nicht eindeutige« Sekundärindizes wurde vorge-nommen, da einige Entwickler einen eindeutigen Sekundärindex verwen-den, um in einer Tabelle Duplikate bezüglich bestimmter Schlüsselfelderauszuschließen.
� 0035»Mindestens 2 Felder ("dbfld_1" und "dbfld_2") sind in zwei Indizes enthalten«
Eine weitere umstrittene Prüfung! Mit ihr sollen Indizes gefunden wer-den, die bloße Permutationen anderer Indizes sind. Zum Beispiel ergibt eskaum Sinn, für eine Tabelle mit einem (Primär- oder Sekundär-)Index A
1706-4.book Seite 291 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
292
für die Felder dbfld_1 dbfld_2 noch einen weiteren Index B mit dbfld_2dbfld_1 zu definieren. Anders sieht es bei einem Index dbfld_1 dbfld_2dbfld_3 aus: Hier kann ein weiterer Index mit den Feldern dbfld_3dbfld_2 unter Umständen berechtigt sein. Eine Prüfung, die wieder denganzen Entwickler fordert!
� 0036»Index "idx_1" ist linksbündig in Index "idx_2" enthalten«
Hier liegt der Fall einfacher als in der vorhergehenden Meldung: Beieinem Index dbfld_1 dbfld_2 dbfld_3 ergibt ein weiterer Index mit denFeldern dbfld_1 dbfld_2 keinen Sinn.
� 0037, 0137»Tabelle dbtab: Feld fld in Primär / Sekundärindex idx ist vom Typ FLOAT«
Beim Lesen von Feldern vom Typ FLOAT von der Datenbank kann es zuRundungsdifferenzen bei der Zuweisung an eine ABAP-Variable kommen.Ein FLOAT-Feld im Primärschlüssel bedeutet damit, dass ein bestimmterTabellenschlüssel unter Umständen aus ABAP heraus nicht mehr ange-sprochen werden kann, und führt daher zu einer Warnung durch denCode Inspector. Mit einem FLOAT-Feld im Sekundärindex lässt sich nurvernünftig arbeiten, wenn in der WHERE-Bedingung des Datenbankzugriffsimmer mit einem Wertebereich und nicht mit Gleichheitsbedingungenauf das Feld zugegriffen wird.
� 0038, 0039»Mandantenabhängige Tabelle dbtab: Sekundärindex idx ohne Mandantenfeld«»... Sekundärindex idx hat Mandant nicht als erstes Feld«
In der Regel sollte bei mandantenabhängigen Tabellen der Mandant alserstes Feld in jedem Sekundärindex enthalten sein. Der Mandant ist zwarkein selektives Feld (und Indizes sollten möglichst selektive Felder enthal-ten), aber er ist beim Zugriff praktisch immer bekannt. Bei Tabellenschlüs-seln, die aus GUIDs (Globally Unique Identifier) bestehen, die auch man-dantenübergreifend garantiert nur einmal existieren, kann auf den Man-danten im Sekundärschlüssel verzichtet werden.
� 0041»INDX-artige Tabelle dbtab ist gepuffert«
Sogenannte INDX-artige Tabellen ähneln in ihrer Struktur der SAP-System-tabelle INDX. Diese Tabellen werden in der Regel nicht durch SELECT-Anweisungen, sondern mit dem Befehl IMPORT FROM DATABASE gelesen.Dieser Befehl nutzt die SAP-Tabellenpufferung nicht; daher ist es seltensinnvoll, eine INDX-artige Tabelle zu puffern.
1706-4.book Seite 292 Montag, 4. Juli 2011 3:19 15
Performanceprüfungen 5.4
293
� 0042, 0043»View dbview: erstes Feld nicht Mandant, obwohl Basistabelle dbtab mandan-tenabhängig ist«»View dbview: Mandantenfeld der Basistabelle(n) dbtabs nicht über Join-Bedingung verknüpft«
Datenbank-Views über mandantenabhängige Tabellen sollten das Man-dantenfeld in der JOIN-Bedingung enthalten, und das erste Feld desDatenbank-Views sollte der Mandant sein. Anderenfalls können mit demDatenbank-View Daten mandantenübergreifend gelesen werden, wasschon aus funktionalen und Sicherheitsgründen suspekt ist. Der Perfor-manceaspekt dabei ist, dass ohne Mandant möglicherweise Indizes derdem Datenbank-View zugrunde liegenden Tabellen (die alle den Mandan-ten als erstes Feld enthalten sollten) nicht verwendet werden können, umden Datenbankzugriff zu optimieren.
� 0050, 0051»Sprachabhängige Tabelle dbtab: Sprache ist nicht erstes Feld (oder zweitesnach dem Mandanten)«»Sprachabhängige Tabelle dbtab ist nicht generisch bezüglich der Sprachegepuffert«
Auf sprachabhängige Tabellen wird in den meisten Fällen mit einerbestimmten Sprache in der WHERE-Bedingung zugegriffen, da der Benutzernur Texte in seiner Anmeldesprache lesen möchte. Daher ist es eine guteIdee, die Sprache als das erste Feld (bzw. als das zweite nach dem Man-danten) zu definieren, um einen Indexzugriff mit Sprache und Schlüsselzu ermöglichen. Meist werden solche Texttabellen Konfigurationstabellensein und daher gepuffert. Aufgrund der Zugriffe mit dem Sprachfeld soll-ten die Tabellen nicht vollständig, sondern generisch bezüglich der Spra-che gepuffert sein.
� 0060»Tabelle dbtab enthält lob_cnt STRING bzw. RAWSTRING Felder«
STRING- oder RAWSTRING-Felder werden in der Datenbank nicht zusammenmit den anderen Feldern einer Tabelle abgelegt, sondern aufgrund ihrerveränderlichen Länge als BLOB oder CLOB (Binary oder Character; LargeObject, LOB). Daher müssen Sie sich jeden Zugriff auf eine Tabelle miteinem LOB wie einen Zugriff auf mehrere Tabellen vorstellen: Für jedenLOB in der Tabellenstruktur muss auf eine extra Tabelle zugegriffen wer-den, was natürlich die Lese- und Einfüge-Zeiten entsprechend erhöht. AlsAbhilfe sollten Sie beim Lesen die (RAW)STRING-Felder nur dann mitlesen,wenn diese unbedingt benötigt werden. Es kann auch vorteilhaft sein,
1706-4.book Seite 293 Montag, 4. Juli 2011 3:19 15
Standardprüfungen des SAP Code Inspectors5
294
mehrere LOB-Felder zu einem einzigen zusammenzufassen und die benö-tigte Information bei Bedarf durch String-Operationen zu extrahieren.
5.4.18 Performanceprüfungen, die es nicht gibt
In vielen Foren stößt man immer wieder auf Gruselmärchen bezüglich derPerformance, bei denen bestimmte ABAP-Anweisungen – insbesondereeinige Varianten der SELECT-Anweisung – zu Unrecht die Rolle der bösenHexe übernehmen müssen. Es gibt sogar Kundenentwicklungen von Code-Inspector-Prüfungen, die nach diesen vermeintlichen Performanceproble-men suchen. Damit Sie nicht ebenfalls beginnen, solche Prüfungen zu imple-mentieren, begründen wir hier, warum es für die folgenden Varianten derSELECT-Anweisung im Code Inspector keine Prüfungen gibt.
� Suche nach SELECT ... ENDSELECTOft wird behauptet, die Verwendung der SELECT-ENDSELECT-Schleife seigenerell zu vermeiden, da hier Einzelsätze von der Datenbank gelesenwürden. Das ist aber falsch: SELECT ... ENDSELECT ist ein Array-Zugriff, eswerden demnach mit einem Roundtrip gleich mehrere Sätze von derDatenbank gelesen. Damit ist die SELECT-ENDSELECT-Schleife für Verarbei-tungen geeignet, bei denen die gelesenen Daten gleich in der Schleife wei-terverarbeitet werden. Sollen die Daten dagegen in eine interne Tabelleeingestellt und später weiterverwendet werden, ist ein Array-Select mitSELECT ... INTO TABLE vorzuziehen.
� Verwendung von SELECT * FROM dbtab … Diese Anweisung liest für jeden Satz in der Treffermenge einer Daten-bankselektion alle Felder von der Datenbanktabelle. Manchmal findetman den Hinweis, dass immer Feldlisten anstelle des * verwendet werdensollten, das heißt die Anweisung SELECT fld_1 fld_2 fld_3 ... FROMdbtab. Eine solche explizite Feldliste lohnt sich aber erst, wenn diese zueiner deutlichen Reduktion der zu übertragenden Datenmenge führt. DieFelder der Feldliste sollten daher einige Hundert Bytes weniger Datenumfassen als die komplette Tabellenzeile.
Einen deutlichen Performancevorteil kann allerdings ein Zugriff erzielen,bei dem nur Felder des zur Suche verwendeten Datenbankindizes gelesenwerden (Index-only-Zugriff). Dann müssen in der Datenbank nurIndexblöcke durchsucht und gelesen werden; teure Absprünge in die
Empfehlung
Da diese Prüfung wichtige Aspekte der Eigenschaften von Datenbanktabellenuntersucht, sollte sie bei allen Performanceuntersuchungen eingeschaltet sein.
1706-4.book Seite 294 Montag, 4. Juli 2011 3:19 15
Sicherheitsprüfungen 5.5
295
Datenblöcke, die mit höherer Wahrscheinlichkeit mit Disk-I/O verbundensind, sind nicht notwendig.
� Verwendung von SELECT … FOR ALL ENTRIES IN itabDiese Anweisung bildet einen Join zwischen einer Datenbanktabelle undeiner internen Tabelle ab. Sie ist zum Beispiel dazu geeignet, einen Daten-bank-Join über zwei Tabellen zu ersetzen, bei dem eine oder beide Tabel-len gepuffert sind.
Beachten Sie, dass die Option FOR ALL ENTRIES bei einzelsatzgepuffertenTabellen zum Umgehen des Tabellenpuffers führt, auch wenn der Primär-schlüssel in der WHERE-Bedingung vollständig gegeben ist. In einem sol-chen Fall kann es angebracht sein, den Aufruf SELECT ... FOR ALL ENTRIESIN itab auf einzelne SELECT SINGLE-Aufrufe innerhalb einer Schleife überdie interne Tabelle itab umzustellen.
Bezüglich der Performanceaspekte der Anweisung FOR ALL ENTRIES möch-ten wir noch erwähnen, dass diese Anweisung nicht zum SQL-Standardgehört und daher abhängig von der jeweiligen Datenbankplattform unter-schiedlich umgesetzt wird. Eine Beschreibung der Profilparameter, die dieArt und Weise dieser Umsetzung regeln, finden Sie in SAP-Hinweis48230. Falsch gewählte Profilparameter können dazu führen, dass dieAnweisung SELECT ... FOR ALL ENTRIES von der Datenbank nicht optimalausgeführt wird.
Ein weiterer kritischer Punkt beim SELECT ... FOR ALL ENTRIES IN itab isteine zur Laufzeit leere interne Tabelle itab. Wir besprechen dieses Pro-blem in Abschnitt 5.7, »Robuste Programmierung (ab Release 7.0 EHP2)«.
5.5 Sicherheitsprüfungen
Wie bei anderen Produktstandards gilt auch für den Sicherheitsstandard,dass statische Prüfungen nur einen Teilaspekt innerhalb eines umfassendenTestkonzeptes sein können. Um die Sicherheit Ihrer ABAP-Anwendungen zuüberprüfen, empfehlen wir Ihnen ein dreistufiges Vorgehen:
� manuelle Design- und Codeanalysen, bei denen als sicherheitskritischerkannte Programme im Zentrum stehen
� automatisierte statische Prüfungen mit dem Code Inspector
� Hacker-Tests, bei denen versucht wird, den ausgeführten Code durchBenutzereingaben so zu manipulieren, dass dadurch unerwünschte,sicherheitskritische Effekte erzielt werden
1706-4.book Seite 295 Montag, 4. Juli 2011 3:19 15
Dokumentation 55, 72Einstellung 55Hinweis 76Name der Klasse 71nur Selektionen sichern 76Objekte aus Coverage Analyzer 81Objekte aus cProjects 84Objekte aus Datei-Upload 82Objekte aus eingebetteten Paketen 85Objekte aus Laufzeitfehlern 83Objekte aus Umfeldermittlung 79Objekte aus Verwendungsnachweis 80Programme aus der Laufzeitanalyse 76Programme aus Katalog der Report-
Sourcen 86, 87Transaktion SE61 72Verwaltung 71Verwendungsnachweis für Tabellen 78Wertehilfe 55
Zugriffe 301, 303Dynpro-Generierung 360Dynpro-Prüfung auf Usability und Acces-
sibility 361Einstellungsmöglichkeit 41Erkennen von totem Coding 382Erweiterte Namenskonventionen für Pro-
gramme 330Erweiterte Programmprüfung 313Fan-out-strukturelle Metrik 341Generieren von ABAP-Programmen 316Geschachtelte Schleifen 264GUI-Usability-Prüfung 355Hinweis 133implizite Prüfung 236Inperformante Operationen auf internen
Tabellen 266Inperformante Parameterübergabe 269Instanzerzeugung von BAdIs 282Invalidierung des SAP-Tabellenpuffers
278Klassen/Interface-Konsistenz 311Kommentarsprache-Metrik 342Komplexe WHERE-Bedingung in SELECT-
Anweisung 323
Kopieren der aktuellen Tabellenzeile bei LOOP AT… 274
Kopieren großer Datenobjekte 265Kritische Anweisungen 297Leerer Test 383Mandantenabhängige Shared-Objects-
Methoden 309Metrik der ausführbaren Anweisungen
335Name der Klasse 68Namenskonvention 328OO-Größenmetrik 345Performanceprüfungen, die es nicht gibt
294Proxy-Prüfungen 385Prozedurale Metrik 337Prüfung der Infotypklassen 370Prüfung der SY-SUBRC-Behandlung 304Prüfung der Tabelleneigenschaften 284Prüfung SQL-Trace 373, 375, 376, 379SAP GUI-Bedienbarkeit 355SAP-Standardprüfung 63selbst erstellen 159SELECT in Schleifen 262SELECT INTO CORRESPONDING
FIELDS bei gepufferten Tabellen 284SELECT-Anweisungen mit anschlie-
ßendem CHECK 260SELECT-Anweisungen, die am Tabellen-
puffer vorbei lesen 255Statistik der Tabelleneigenschaften 244Suche nach APPEND und INSERT ...
INDEX bei SORTED-Tabellen 322Suche nach bestimmten kritischen Anwei-
sungen 300Suche nach unerwünschten Sprachele-
menten 365Suche Oracle Rule Hints 368Suche von ABAP-Anweisungsmustern
364Suche von ABAP-Token 363Suche von WRITE-Anweisungen 367Suspekte Konvertierungen 317Syntaxprüfung 312Syntaxprüfung/Generierung 310Tabellennamen aus SELECT-Anweisung
243Test zu CL_ABAP_COMPILER 382Test zu ENHANCEMENT-SECTION 381
SIX.fm Seite 462 Dienstag, 5. Juli 2011 10:22 10
463
Index
Testkonventionen von ABAP Unit 333Transaktion SE61 69Überprüfung der Erweiterbarkeit von
Tabellen 78, 383Verfahrenstechnische Metrik 337Verwendung der ADBC-Schnittstelle