Best Practice Leitfaden Development

Transkript

1 Best Practice Leitfaden Development Praxistipps rund um das Thema ABAP Development Deutschsprachige SAP-Anwendergruppe e.v. DSAG-Arbeitskreis SAP NetWeaver Development Stand 31. Januar 2013

2 2 Best Practice Leitfaden Development Praxistipps rund um das Thema ABAP Development Version 0.11 Stand 31. Januar 2013 DSAG e. V. Deutschsprachige SAP-Anwendergruppe

3 3 Autoren > Peter Lintner, Senior Consultant, Allgemeines Rechenzentrum GmbH > Steffen Pietsch, Vice President, IBSolution GmbH > Markus Theilen, IT-Koordinator, EWE AG > Jürgen Wachter, Process Coordinator Development, comgroup GmbH > Michael Werner, SAP Anwendungsberater (Inhouse), LTS AG Andernach > Andreas Wiegenstein, Managing Director und Chief Technology Officer (CTO), Virtual Forge GmbH Weitere Informationen zu den Autoren finden Sie auf Seite 57. Copyright 2013 DSAG e.v. HINWEIS: Die vorliegende Publikation ist urheberrechtlich geschützt (Copyright). Alle Rechte liegen, soweit nicht ausdrücklich anders gekennzeichnet bei: DEUTSCHSPRACHIGE SAP ANWENDERGRUPPE E.V. Altrottstraße 34 a Walldorf Deutschland Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. Tel.: Fax: info@dsag.de Internet: Jedwede unerlaubte Verwendung ist nicht gestattet. Dies gilt insbesondere für die Vervielfältigung, Bearbeitung, Verbreitung, Übersetzung oder die Verwendung in elektronischen Systemen / digitalen Medien.

4 4 Inhaltsverzeichnis 1 Einleitung Motivation Positionierung 7 2 Programmierrichtlinien Namenskonvention Namensraum Einheitlicher und lesbarer Quellcode: Pretty Printer Obsolete Anweisungen Syntax-Check und Code Inspector Feste Codierung: Keine magic numbers Tipps beim Arbeiten mit Transporten Berechtigungsprüfung im Quellcode Programmiermodell: objektorientiert vs. prozedural Weitere Quellen (Programmierrichtlinien/ABAP) 14 3 Performance Vermeidungsprinzip Vorhandene Werkzeuge nutzen Performance-Optimierungen nur an kritischen und relevanten Stellen Datenmodell und Datenzugriff Datenmodell und Indizes Rahmenbedingungen bei Datenbankzugriffen Datenbankzugriffe Interne Tabellen und Referenzen Feldsymbole Parameterübergabe Weiterführende Quellen 21 4 Robustheit Fehlerbehandlung SY(ST)-SUBRC-Prüfungen MESSAGE-Anweisung Klassenbasierte Ausnahmen Nicht behandelbare Ausnahmen Korrekte Implementierung von Datenbank-Änderungen Sperrobjekte Verbuchungskonzept Protokollierung Praxisbeispiele 26

5 Unvollständige Fallunterscheidungen Wichtige sonstige SY(ST)-SUBRC-Prüfungen Weiterführende Quellen 27 5 ABAP-Sicherheit und Compliance Prüfungsrelevante Sicherheitsmechanismen im SAP-Standard Berechtigungsprüfung (A) Mandantentrennung (B) Nachvollziehbarkeit (C) Dreisystemlandschaft (D) Kontrollierte Ausführung von Betriebssystemkommandos (E) Kontrollierte Ausführung von SQL-Befehlen (F) Sicherheitsschwachstellen Compliance-Probleme durch ABAP Testwerkzeuge Weiterführende Quellen 33 6 Dokumentation Dokumentation unabhängig von Entwicklungsobjekten Dokumentation von Entwicklungsobjekten Dokumentation im Quelltext Dokumentation und Kommentierung von Anweisungen/Anweisungsblöcken Dokumentation von Änderungen Programmkopf 36 Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. 7 Umsetzbarkeit und Durchsetzbarkeit Umsetzbarkeit Motivation für einen Prozess Erstellung und Pflege des Prozesses Durchsetzbarkeit Manuelle Prüfungen Automatische Prüfungen Werkzeuge Erfahrungen und Tipps aus der Praxis Qualitätssicherung des Quellcodes Zeit und Budget Qa Probleme Entscheidungsfindung bei Modifikationen Erfahrungsbericht aus der Praxis: Comgroup GmbH 44

6 6 Inhaltsverzeichnis 8 Infrastruktur und Lifecycle Management Infrastruktur Sandbox Entwicklungssystem Qualitätssicherungssystem Produktion Transportwesen Rückbau von Neuentwicklungen Sicherstellung der Konsistenz von Neuentwicklungen/Erweiterungen Change Management Softwarewartbarkeit Anpassungen der SAP-Funktionalität Testbarkeit von Anwendungen 55 9 Die Autoren Anhang: Namenskonventionen Allgemeine Namenskonventionen Attribute Methoden Signatur von Methoden Funktionsgruppen und -bausteine Enhancements Formulare Jobs Datenelemente 62

7 1 einleitung SAP-Software zeichnet sich als Standardsoftware durch ein hohes Maß an Flexibilität und Erweiterbarkeit aus. In nahezu allen Unternehmen, die SAP-Software einsetzen, finden sich kundenspezifische Anpassungen und Ergänzungen. Die SAP-Software unterliegt damit sowohl auf Herstellerals auch auf Kundenseite der kontinuierlichen Anpassung und Erweiterung an sich wandelnde Kundenbedürfnisse. Das hohe Maß an Flexibilität und Erweiterbarkeit von SAP-Software bringt Vor- und Nachteile mit sich: Die Software kann optimal an kundenspezifische Anforderungen angepasst und damit die Wertschöpfung durch den Einsatz deutlich gesteigert werden. Zeitgleich birgt die Erweiterbarkeit das Risiko kundenspezifischer Entwicklungen, die komplex, aufwendig wartbar und fehleranfällig sind. Das Ziel dieses Dokuments ist es, Praxistipps und Denkanstöße zu liefern, um kundenspezifische Entwicklungen wartbar und effizient zu gestalten. 1.1 Motivation Die Arbeit der Deutschsprachigen SAP-Anwendergruppe e.v. (DSAG) fußt auf drei Säulen Wissensvorsprung, Einflussnahme und Netzwerk. Das vorliegende Dokument wurde von Mitgliedern des DSAG-Arbeitskreises SAP NetWeaver Development initiiert und adressiert die erste Säule und damit den Wissensvorsprung für Anwender und Partner. 7 Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. Als Autorenteam ist es unser Anliegen, das in den Unternehmen verteilt und implizit vorliegende Wissen zum Thema Entwicklung in einem kompakten Dokument anderen DSAG-Mitgliedern zur Verfügung zu stellen. Unser Wunsch ist, dass dieses Dokument lebt und mit Ihrem Erfahrungsschatz einer kontinuierlichen Verbesserung unterliegt. Wir freuen uns auf Ihr Feedback (am besten per an handlungsempfehlung@dsag.de)! 1.2 Positionierung Es existieren bereits von der SAP und einer ganzen Reihe von Fachverlagen sehr gute Publikationen zu Anwendungsentwicklung und Erweiterung der SAP-Plattform. Insbesondere haben auch Autoren der SAP mit dem Buch ABAP-Programmierrichtlinien, SAP Press 2009 bereits einen Vorstoß in Richtung von Empfehlungen unternommen, die über reine Beschreibungen der Sprache ABAP und der zugehörigen Werkzeuge hinausgehen. Der Mehrwert dieses Dokuments liegt in der Zusammenfassung bewährter Vorgehensweisen, Praxistipps und erprobter Regelwerke aus den Anwenderunternehmen. Diese Guideline soll Ihnen als Anwender, Entwickler, Entwicklungs-, Projekt- oder IT-Leiter Anregungen und Hilfestellung geben, um das Rad nicht immer wieder neu erfinden zu müssen, sondern auf die Erfahrungen anderer aufbauen zu können. Dabei erheben die in dieser Guideline vorgestellten Empfehlungen nicht den Anspruch auf Vollständigkeit oder absolute Verallgemeinerung, sondern stellen eine Auswahl von Praxistipps dar. Als Autorenteam haben wir uns darum bemüht, im Spannungsfeld zwischen Überblickswissen und Detailtiefe den richtigen Mix zu finden. Daher verweisen wir an entsprechenden Stellen auf weiterführende Quellen, um nicht ausführlich diskutierte Themen redundant wiederzugeben. Die erste Auflage dieser Guideline ist auf den Bereich ABAP-Entwicklung fokussiert. Bei entsprechendem Feedback und Ihrer aktiven Unterstützung kann der Fokus auf die JAVA-Entwicklung und weitere Themen ausgeweitet werden.

8 8 2 Programmierrichtlinien Dieses Kapitel beschreibt erprobte und empfohlene Programmierrichtlinien für Anwendungen, die mit Hilfe der Programmiersprache ABAP erstellt werden. Es wird beschrieben, wie mit Standard- SAP-Mitteln und Disziplin sauber lesbarer und verständlicher ABAP Code entwickelt werden kann. Dies erleichtert die Wartung des Codes bzw. ermöglicht, dass verschiedene interne und externe Personen effizient an der (Weiter-) Entwicklung und Wartung eines Programms zusammenarbeiten. 2.1 Namenskonvention Namenskonventionen beschreiben die einheitliche und verbindliche Vorgabe zur Benennung von Softwareobjekten (z.b. Klassen, Funktionsbausteinen) bzw. zur Benennung von Objekten im Quellcode (z.b. Variablen). Wir empfehlen ausdrücklich eine Namenskonvention als Richtlinie für Entwicklungen im SAP- System vorzugeben. Das Ziel der Verwendung einer einheitlichen Namenskonvention ist die deutliche Steigerung der Wartbarkeit kundenspezifischer Anpassungen und Erweiterungen. In der Konsequenz führt dies zu geringeren Wartungsaufwänden bzw. -kosten und einer schnelleren Problemlösung im Fehlerfall. Die explizit formulierte Namenskonvention sollte Bestandteil der internen Ausbildung sein, um neue Mitarbeiter mit den Grundregeln und Unternehmensspezifika vertraut zu machen. Zudem hat es sich bewährt, diese Namenskonvention zum Vertragsgegenstand für externe Entwickler und Partnerunternehmen zu machen. Automatisierte Überprüfungen stellen die Einhaltung sicher (vgl. Kapitel 7). BEST PRACTICE: Eine exemplarische Namenskonvention als Vorlage finden Sie im Anhang. 2.2 Namensraum Die Trennung von Kundenobjekten und SAP-Objekten kann über die Präfixe Y oder Z sowie über einen eigenen Namensraum erfolgen. Die Syntax lautet wie folgt: Z Y /<kundeneigener Namensraum>/ Der kundeneigene Namensraum kann bei SAP registriert werden und ist nach Bestätigung weltweit eindeutig und für das jeweilige Unternehmen zur Verwendung registriert. Dieses Vorgehen unterstützt bei der konfliktfreien Vergabe von Namen für Softwareobjekte. Der Vorteil des kundeneigenen Namensraums liegt in der garantierten Überschneidungsfreiheit beim Import fremder Objekte in das eigene SAP-System (z.b. beim Einsatz von Fremdanwendungen, die per Transportauftrag eingespielt werden) und bei Zusammenführungen von SAP Systemen im Rahmen einer Post-Merger Integration. Durch die Reservierung des Namensraums ist sichergestellt, dass auf keinem fremden, d.h. nicht registrierten System ein Softwareobjekt mit dem gleichen Präfix erstellt werden kann. Der Nachteil bei der Verwendung des kundeneigenen Namensraums liegt darin, dass durch die durchgängige Verwendung des Präfixes bereits mehrere Zeichen verbraucht werden. Dies kann insbesondere bei Objekten, die nur wenige Zeichen zur Benennung bieten, zu Schwierigkeiten führen. Darüber hinaus unterstützen nicht alle Objekttypen, z.b. Berechtigungsobjekte, die Verwendung von Namensräumen.

9 9 BEST PRACTICE: Wir empfehlen ausdrücklich die Verwendung eines kundeneigenen Namensraums. WEITERE QUELLEN: 1. (Namensraum einrichten) 2. Best-Built Applications: Einheitlicher und lesbarer Quellcode: Pretty Printer Übersichtlicher, leserlicher Code erleichtert jedem Entwickler die (erneute) Einarbeitung in Quellcode. Als einfachste und schnellste Möglichkeit, um Code gut lesbar zu machen und zu halten, kann der Pretty Printer aus der ABAP-Entwicklungsumgebung genutzt werden. Mit einem einzigen Knopfdruck wird der ausgewählte Quelltext einheitlich formatiert. Er bietet verschiedene Möglichkeiten, die über die Einstellungen der Workbench konfigurierbar sind. Bereits eine eingerückte Darstellung macht Source Code deutlich lesbarer. Es wird empfohlen, Schlüsselwörter groß darzustellen. Denn dadurch kann man Quelltext auch in ausgedruckter Form und ohne Syntaxeinfärbung noch leicht verstehen. Der Pretty Printer ermöglicht auf einfachem Weg die Erstellung von einheitlichem Quellcode trotz unterschiedlicher Entwickler. Um die Lesbarkeit des Quelltextes zu erhöhen, empfehlen wir, auf mehrere Anweisungen in einer Codezeile zu verzichten. Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. Wir empfehlen, die Option Standardkommentare einfügen zu deaktivieren, da die erzeugten Kommentare bei Änderungen nicht automatisch angepasst werden und redundante Informationen enthalten. BEST PRACTICE: Wir empfehlen, den Pretty Printer zu verwenden und die Einstellungen als einheitliche Vorgabe zu definieren. Modularisierung Programme, in denen logische Verarbeitungseinheiten nicht aufgeteilt werden, sind in weiterer Folge schwer lesbar und damit schwer wart- und erweiterbar. Eine Modularisierungseinheit (Form-Routine, Methode, Funktionsbaustein) soll logisch zusammengehörende Anweisungen zusammenfassen, dabei ist jedoch zu beachten, dass die einzelnen Einheiten nicht triviale Funktionalitäten abdecken. Modularisierungseinheiten mit sehr wenigen Anweisungen sind jedoch zu vermeiden. Die Modularisierung dient dazu, trotz Komplexität in der Aufgabenstellung, den Programmcode übersichtlich zu gestalten. Zudem sind Programmabschnitte mit derselben Logik zu vermeiden. Für die praktische Umsetzung kann es hilfreich sein, vor Beginn des Programmierens die ersten Codezeilen mittels Kommentaren in logische Blöcke aufzuteilen und erst anschließend auszuprogrammieren. Wo es möglich und sinnvoll ist, ist es ratsam, vom prozeduralen Programmiermodell auf objektorientierte Programmierung überzugehen, um zukunftssicher zu entwickeln und Objekte zu kapseln. Insbesondere bei neuen Projekten sollte nur noch objektorientiert entwickelt werden. Im Rahmen der Einführung von ABAP Objects fand eine Bereinigung der Sprache und Vereinheitlichung der Konstrukte statt. Die Verwendung von ABAP Objects führt damit zu einer Steigerung der Wartbarkeit.

10 10 2 Programmierrichtlinien Trennung von Präsentations- und Anwendungslogik In allen Programmen sollte stets eine Trennung von Präsentations- und Anwendungslogik erfolgen. Dies erlaubt es, Ergebnisse und Funktionen der Anwendungslogik durch verschiedene UIs (User Interfaces) dem Benutzer anzuzeigen sowie über eine einheitliche Schnittstelle anderen Systemen bereitzustellen. Diese Aussage ist für alle gängigen UI-Technologien gültig, wobei der Grad der Unterstützung bzw. Einhaltung dieser logischen Trennung unterschiedlich ist. In einer WebDynpro ABAP-Realisierung ist schon vom Framework eine Trennung zwischen Modell- und UI-Logik vorgesehen. Bei klassischen Dynpros und BSPs wird die Trennung nicht in gleicher Weise forciert, aber grundsätzlich kann und sollte die Trennung auch in diesen Umgebungen umgesetzt werden. Allerdings gibt es hierfür keine technische Prüfung im Gegensatz zu WebDynpro, wo entsprechende Prüfungen im Code Inspector realisiert sind. Ein typisches Beispiel für eine klare Trennung von Anwendungslogik und UI sind Plausibilisierungsregeln. Wenn die Plausibilisierung von Eingaben in einer bestimmten UI-Technologie entwickelt wird, müssen diese Prüfungen bei einem Wechsel auf eine andere UI-Technologie neu entwickelt werden. Um dies zu vermeiden, müssen die Funktionen zur Prüfung von Eingaben oder Parametern unabhängig von der verwendeten UI erstellt und gepflegt werden. Internationalisierung Sprachabhängige Texte in Programmen dürfen nicht hart codiert werden, sondern müssen in Textelementen (Programmtexte, Klassentexte, Online-Text-Repository [OTR]), Standardtexten oder Nachrichtenklassen hinterlegt werden. Da alle Eigenentwicklungen den Anspruch haben sollten, weltweit eingesetzt zu werden, sollten die wichtigsten Sprachen übersetzt werden. Zudem müssen sprachabhängige (customizebare) Texte in eigenen Texttabellen abgelegt werden. Diese Texttabelle besitzt dieselben Schlüsselattribute wie die eigentliche Customizing-Tabelle. Zusätzlich muss das erste Schlüsselattribut nach dem Mandantenfeld das Sprachenattribut sein (Datenelement SPRSL oder SPRAS). Zudem muss die Fremdschlüsselbeziehung als jene der Texttabelle gekennzeichnet werden. BEST PRACTICE: Wir empfehlen, den Code Inspector für die Suche nach nicht übersetzbaren Texten zu verwenden. BEST PRACTICE: Um spätere Übersetzungen einfach zu gestalten, sollte die Länge der Feldbezeichner und Textelemente möglichst lang gewählt werden. Als Faustregel für die Länge von Textelementen hat sich bewährt, die 1,5-fache Länge der nativen Beschreibung vorzusehen. Dynamische Programmierung In der klassischen, statischen Entwicklung werden Entwicklungsobjekte und der Quellcode zur Designzeit definiert und im SAP-System statisch hinterlegt. Zur Laufzeit wird der vorgegebene Programmcode ausgeführt. Im Gegensatz dazu ermöglicht die dynamische Programmierung die Flexibilisierung des Quellcodes. Folgendes Beispiel verdeutlicht die dynamische Programmierung: Im Programmcode wird der Name einer aufzurufenden ABAP-Klasse nicht statisch hinterlegt, sondern es wird zur Laufzeit die Klasseninstanz aufgerufen, deren Name durch den Inhalt einer Variablen definiert ist. Dieser Name kann z.b. aufgrund von Benutzereingaben variieren. Der Vorteil dieser Methodik liegt in der gesteigerten Flexibilität. Der Nachteil liegt in der signifikant steigenden Komplexität und insbesondere in den damit einhergehenden Sicherheitsrisiken.

11 11 Vorteil: > Deutliche Steigerung der Flexibilität > Beispiel 1: Eigener Aufbau von User Exits durch die statische Definition einer abstrakten Klasse inkl. Methodensignatur wird das Grundgerüst für einen User Exit vorgegeben. Anschließend können mehrere konkrete Implemetierungen dieser abstrakten Klasse angelegt werden. Innerhalb Quellcodes wird z.b. aus einer Customizing-Tabelle der Name der zu verwendenden konkreten Klassenimplementierung gelesen und diese aufgerufen. Somit können unterschiedliche Implementierungsvarianten per Customizing aktiviert/deaktiviert werden. > Beispiel 2: Dynamische WHERE-Bedingung Nachteil: zur Laufzeit wird die WHERE-Bedingung für eine Datenbankoperation, z.b. SELECT, in einer string-variablen erstellt. Dadurch können komplizierte CASE-Abfragen vermieden werden, die abhängig von den Eingaben verschiedene OSQL-Befehle ausführen. Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. > Durch die Nutzung von dynamischen Aufrufen geht der Verwendungsnachweis innerhalb der ABAP- Entwicklungsumgebung verloren. Problematisch sind dann Änderungen an den Aufrufzielen. Ein Entwickler, der beispielsweise die Übergabeparameter eines Funktionsbausteins ändert, der von einem Programm dynamisch aufgerufen wird, bemerkt diese Verwendung über den Verwendungsnachweis nicht. > Bei der dynamischen Programmierung ist i.d.r. zur Designzeit keine syntaktische Prüfung möglich; bei fehlerhafter Belegung der variablen Inhalte (z.b. fehlerhafte Klammerung innerhalb einer dynamischen WHERE-Klausel, fehlerhafter Name einer Klasse) kommt es zu einem ungeplanten Abbruch des Programms (Kurzdump). > Dynamische Programmierung birgt hohe Sicherheitsrisiken, insbesondere dann, wenn die dynamischen Inhalte durch ungeschützten Zugriff beeinflussbar sind (z.b. wenn der Name einer aufzurufenden Klasse /eines Funktionsbausteins oder einer WHERE-Bedingung durch Benutzereingaben beeinflusst werden kann, Stichwort: Code Injection). BEST PRACTICE: Dynamische Programmierung sollte nur sehr dosiert und kontrolliert zum Einsatz kommen. Programmcode, der dynamische Anteile enthält, sollte nach dem Vier-Augen-Prinzip kontrolliert und dokumentiert werden, denn er stellt ein potenzielles Sicherheitsrisiko dar. Im Kapitel 5.2 wird das Thema dynamische Programmierung auch im Kontext Sicherheit behandelt.

12 12 2 Programmierrichtlinien Auditierbarkeit von ABAP Code Es muss jederzeit möglich sein, durch manuelle Untersuchungen oder statische Codeanalyse- Tools den selbst geschriebenen ABAP Code auf Mängel zu untersuchen. Alle Methoden, ABAP- Coding unsichtbar zu machen, sind daher unzulässig, da sie solche Untersuchungen behindern oder gar gezielt dafür verwendet werden könnten, Hintertüren in ein System zu schleusen. Verschleierter Code kann auch mit dem Debugger nicht mehr untersucht werden. Es wird an dieser Stelle explizit darauf verzichtet, die Techniken zu erläutern, mit denen Code versteckt werden kann. BEST PRACTICE: Verwenden Sie insbesondere in der Entwicklung im eigenen Unternehmen keine Techniken, um Ihren Quellcode zu verstecken. 2.4 Obsolete Anweisungen Obwohl SAP eine strikte Abwärtskompatibilität vertritt, muss bei der Verwendung von obsoleten Anweisungen, wie z.b. Kopfzeilen in internen Tabellen, berücksichtigt werden, dass hierbei Probleme auftreten, wenn der Code in Klassen übernommen werden soll. Hier ist zu beachten, dass es für obsolete Sprachelemente immer modernere Alternativen gibt. Es gibt also eigentlich außer Gewohnheit wenige Gründe für deren Verwendung, deshalb sollten sie vermieden werden. BEST PRACTICE: Wir empfehlen den regelmäßigen Einsatz eines statischen Codeanalyse-Tools, um obsolete Anweisungen zu entdecken. Aus den SAP-Bordmitteln eignet sich hierzu der Code Inspector bzw. die Durchführung des Syntax-Checks. Darüber hinaus existieren sehr gute Analysewerkzeuge von Drittanbietern. 2.5 Syntax-Check und Code Inspector Der Syntax-Check und der Code Inspector ermöglichen die Überprüfung des Programmcodes während der Designzeit. Bei der Freigabe von Transporten kann der Code Inspector über die SE03 global angeschaltet werden, um Fehler zu erkennen. Hierdurch kann auch die Anzahl der Transporte verringert werden, da beim Erkennen von Fehlern die Freigabe noch abgebrochen werden kann. Die Behebung kann dann in den bestehenden Auftrag aufgenommen werden und es muss kein neuer Transport erzeugt werden. BEST PRACTICE: Der Code Inspector wird im SAP-Standard nur bei Freigabe des Transportauftrags ausgeführt. Empfehlenswert ist jedenfalls die Prüfung durch den Code Inspector bereits bei der Freigabe der jeweiligen Transportaufgabe. WEITERE QUELLEN: Die Vorgehensweise der Implementierung des dafür notwendigen BAdIs ist im Buch Praxishandbuch SAP Code Inspector (SAP Press) beschrieben.

13 Feste Codierung: Keine Magic Numbers Die feste (harte) Codierung von Texten, Zahlen, User-Namen, Organisationseinheiten, Datum etc. sollte im Quelltext ausdrücklich vermieden werden. Während der Entwicklung kann die direkte Verwendung von hart codierten Werten vermeintlich als schnelle Vorgehensweise erscheinen. Auf den Gesamtlebenszyklus der Anwendung bezogen, führt sie jedoch zu deutlich erhöhten Kosten. Die Wartbarkeit und Testbarkeit der Anwendung werden langfristig deutlich erschwert. BEST PRACTICE: Wir empfehlen die Verwendung von Konstanten, die an zentraler Stelle definiert werden. Für die Konstantendefinition eignen sich z.b. die Attribute globaler Klassen bzw. Interfaces. BEST PRACTICE: Alternativ zu harten Codierungen im Quelltext können kundeneigene Customizing-Tabellen verwendet werden. In diesen Tabellen werden die Werte, z.b. Zahlen, Organisationseinheiten etc. als Konfiguration hinterlegt und bei Programmstart in eine Variable gelesen. Anschließend wird ausschließlich mit dieser Variablen gearbeitet. Die o.g. Vorgehensweisen steigern bei Mehrfachgebrauch die Konsistenz und Effizienz der Analyse im Fehlerfall bzw. bei regulären Wartungstätigkeiten. Wir empfehlen ausdrücklich die Kommentierung der Konstanten und die Bedeutung der Werte an zentraler Stelle. Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. Um neue Mitarbeiter bei der Ermittlung von Konstanten zu unterstützen, bietet es sich an, diese entweder außerhalb des Systems durchsuchbar zu dokumentieren oder ein Suchtool (s. Weitere Quellen ) zur Verfügung zu stellen, mit dem innerhalb des Systems nach Konstanten gesucht werden kann. 2.7 Tipps beim Arbeiten mit Transporten Wenn mehrere Entwickler an einem Entwicklungsobjekt Änderungen vornehmen, kann dies unter Umständen zu Problemen führen, wenn die Transportaufträge nicht in der richtigen Reihenfolge in die produktiven Systeme transportiert werden oder andere Objekte aus anderen Transportaufträgen fehlen. BEST PRACTICE: Um dies zu vermeiden, sollte mit Transport von Kopien gearbeitet werden. Dabei werden die geänderten Entwicklungsobjekte durch den eigentlichen Transportauftrag im Entwicklungssystem gesperrt und über Transport von Kopien werden nur Kopien der Objekte in das Qualitätssicherungssystem transportiert. Ein Entwickler bemerkt sofort, dass ein anderer Entwickler ggf. das Objekt bereits bearbeitet, und kann sich mit dem anderen Entwickler abstimmen. Nach Abschluss des Projektes wird nur der Original-Sperrtransport ins Produktivsystem transportiert.

14 14 2 Programmierrichtlinien 2.8 Berechtigungsprüfung im Quellcode Bei Zugriff auf Daten und auch deren Präsentation sind die dafür notwendigen Berechtigungsobjekte zu prüfen. Bei der Verwendung von Standardobjekten soll jedenfalls die Prüfung auf die entsprechenden SAP-Standard-Berechtigungsobjekte erfolgen (vereinfacht die Wartung der notwendigen Rollen). Für kundeneigene Datenobjekte können in der Regel keine SAP-Standard- Berechtigungsobjekte zur Prüfung verwendet werden. Zu diesem Zweck können kundeneigene Berechtigungsobjekte implementiert und geprüft werden. Weitere Informationen finden sich im Kapitel Programmiermodell: Objektorientiert vs. Prozedural Die prozedurale Entwicklung in ABAP ist inzwischen von SAP als obsolet eingestuft worden. Insbesondere die Befehle FORM ENDFORM und PERFORM sind als obsolete Anweisungen eingestuft. Prozedurale Entwicklung hat sich im Laufe der Jahre auch im Hinblick auf globale Variablen und Includes als sehr unübersichtlich, komplex und fehleranfällig erwiesen. Objektorientierte Entwicklung wurde so konzipiert, dass logisch zusammenhängende Aufgaben einheitlich in Objekten zusammengefasst werden können. Dadurch wird unter anderem auch die Wiederverwendbarkeit von Code erhöht. Insbesondere können solche Objekte auch von anderen Entwicklern für ihre Zwecke leicht erweitert oder verändert werden, ohne dass die grundlegenden Funktionen beeinträchtigt werden (Open-Close-Prinzip). Andererseits können zentrale Funktionalitäten oder einzelne Variablen auch gezielt vor ungewünschtem Lese- oder Schreibzugriff durch aufrufende Programme geschützt werden. BEST PRACTICE: Wir empfehlen bei Neuentwicklungen möglichst nur noch mit Klassen und Methoden zu arbeiten und keine FORMs mehr zu verwenden. WEITERE QUELLEN: 1. Horst Keller und Gerd Kluger, Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look, Sap Professional Journal 2. Horst Keller and Gerd Kluger, NetWeaver Development Tools ABAP, SAP AG 3. Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser 1990, ISBN ConSea-Projekt für Suche nach Konstanten auf SAP Code Exchange: Weitere Quellen (Programmierrichtlinien / ABAP) 1. SAP Dokumentation SAP NetWeaver AS ABAP Release In dieser Dokumentation ist dem Thema Programmierrichtlinien ein eigenes Kapitel gewidmet.

15 3 Performance In den folgenden Abschnitten empfehlen wir einige Regeln, die bei der täglichen Arbeit in der ABAP-Entwicklung beachtet werden sollten, um von vorneherein Performance-Engpässe zu vermeiden. Wie an viele anderen Stellen der Softwareentwicklung hilft es auch im Hinblick auf eine ausreichende Performance zu wissen, was gemacht werden soll. Solange der Sinn und Zweck eines Code-Stückes nicht klar ist, sollte dies zuerst geklärt werden. 3.1 Vermeidungsprinzip Die sichersten, schnellsten, präzisesten, billigsten, wartbarsten, zuverlässigsten und am leichtesten zu dokumentierenden Teile eines Computersystems sind die, die man weggelassen hat. (Gorden Bell) BEST PRACTICE: Vermeiden Sie jegliches unnötige Coding. Frei nach diesem Motto sollten Sie auch genau prüfen, welcher Code wirklich für die Produktion gedacht ist, und sämtliche Test- und Demo-Programme spätestens auf den Q-Systemen löschen. Aber auch innerhalb von produktivem Coding sollte immer der Ansatz verfolgt werden, nicht mehr zu tun, als für die Aufgabe wirklich benötigt wird. Ein einleuchtendes Beispiel dafür ist die Regel zur Vermeidung von *-SELECTs, bei denen der Einfachheit halber alle Spalten einer Tabelle selektiert werden, obwohl für die folgende Verarbeitung im Prozess nur wenige Spalten benötigt werden. 15 Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. Anmerkung: Diese Vorgehensweise steigert gleichzeitig die Robustheit von Programmen. Das Lesen mit Hilfe von *-SELECT in eine kundeneigene Datenstruktur kann zu Fehlern nach einem Upgrade führen,wenn die Standardtabelle durch SAP erweitert wurde. Das explizite Lesen benötigter Spalten schützt vor dieser Unschärfe. 3.2 Vorhandene Werkzeuge nutzen Die im SAP-System bereits vorhandenen Werkzeuge bieten gute Unterstützung bei der Erstellung von performanten Anwendungen bzw. bei der Analyse von Performance-Engpässen. Diese Werkzeuge sollten frühzeitig und in allen Lebensphasen der Software angewendet werden. Die nachfolgende Tabelle bietet einen Überblick zu den zentralen Werkzeugen: Entwicklung Code Inspector SE30 / SAT ST05 DB05 Beschreibung Statische Code-Analyse und -Prüfungen Laufzeit-Traces Traces für SQL, RFC und Enqueues Wertverteilungs-Analyse für Index-Design

16 16 3 Performance Laufzeit SM50/SM66 Debugger Memory Inspector ST10 Beschreibung Übersicht Workprozesse/Applikationsserver Schrittweises Ausführen von Coding Vergleich und Analyse von Speicherabzügen zur Ermittlung von nicht Speicherverbrauch und nicht freigegebenen Heap-Objekten Tabellenaufruf-Statistiken zur Prüfung von Tabellenpufferung Post Mortem ST22 STAD ST04 Beschreibung Analyse von Laufzeitfehlern (z.b. bei Speichermangel) Workload-Analyse DB-Performance-Übersicht BEST PRACTICE: Starten Sie die Performance-Untersuchung mit einem Trace in der SE30/SAT und konzentrieren Sie sich auf den größeren Zeittreiber. Wenn die meiste Zeit im ABAP-Teil verbraucht wird, analysieren Sie weiter mit der SE30/SAT. Liegt die meiste Zeit bei den DB-Aufrufen, starten Sie einen SQL-Trace mit der ST Performance-Optimierungen nur an kritischen und relevanten Stellen Auch wenn man nicht performante Konstrukte bei der Softwareentwicklung immer vermeiden sollte, sollte man sich gleichzeitig bei der Notwendigkeit von umfangreicheren Performance-Optimierungen auf die Teile der Software beschränken, die durch Messung nachgewiesenermaßen die Ursache von langer Laufzeit oder erhöhtem Speicherverbrauch sind. Auch für Performance-Aspekte trifft die 80/20-Regel zu und es gilt daher, die meistens raren Ressourcen für eine umfangreiche Verbesserung auf die 20 % des Systems zu konzentrieren, die für 80 % der Laufzeit/des Speicherverbrauchs verantwortlich sind. Um an diese Stellen zu gelangen, ist der sinnvolle Einsatz der genannten Werkzeuge essenziell. BEST PRACTICE: Wir empfehlen, die Suche nach Performance-Engpässen mit dem Einsatz der Laufzeitanalyse SE30/SAT mit voller Aggregation zu beginnen. Dadurch sollte deutlich werden, ob die Laufzeit aus der Interaktion mit der Datenbank oder der Verarbeitung der geladenen Daten im Hauptspeicher resultiert. Wichtig ist dabei, dass ein repräsentativer, praxisnaher Datenbestand verarbeitet wird, um nicht durch seltene Verarbeitungsmuster einer falschen Spur zu folgen. Wird mehr als die Hälfte der Laufzeit im DB-Teil verbraucht, sollte eine genauere Analyse der SQL- Kommandos mit der Transaktion ST05 erfolgen. Wird mehr Laufzeit im ABAP-Teil verbraucht, erfolgen tiefergehende Analysen mit Hilfe der SE30/SAT, wobei die Aggregationsstufen schrittweise verringert werden, um genauere Aussagen über die kritischen Programmstellen zu bekommen. Nach jedem Optimierungsschritt sollten die Ergebnisse verglichen und dokumentiert werden.

17 Datenmodell und Datenzugriff Datenmodell und Indizes Der Aufbau des Datenmodells bildet die Basis performanter Anwendungen. Ein mit Augenmaß normalisiertes Datenmodell kann effizienter mit Daten und Indizes arbeiten. Hierzu finden unabhängig von der Programmiersprache ABAP die Normalisierungsregeln Anwendung. Beim Einsatz von Indizes für Tabellen empfehlen wir folgende Punkte: > Es sollten max. fünf Indizes pro Tabelle existieren, wenn häufig ändernd auf diese Tabellen zugegriffen wird. Mit jedem Index steigen die Verwaltungskosten, die bei Datenänderungen anfallen. > Fünf Felder pro Index sollten als Obergrenze eingehalten werden. > In einem Index sollten nur selektive Felder aufgenommen und in der Reihenfolge nach absteigender Selektivität sortiert werden. > Auf Feldebene sollten zwischen zwei Indizes einer Tabelle keine Überlappungen auftreten. > Bei mandantenabhängigen Tabellen sollte das Feld Mandant als erstes Feld aufgenommen werden, insbesondere bei großen Tabellen (>1000 Einträge). Auch wenn dieses Feld nicht sonderlich selektiv ist und damit der dritten Regel widerspricht, wird bei jeder Abfrage dieses Feld in der Selektion vom SAP-System mit übergeben und ausgewertet. Gerade bei Tabellen mit stark unterschiedlichen Eintragszahlen pro Mandant kann sich ein Fehlen des Feldes im Index negativ auswirken. Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V Rahmenbedingungen bei Datenbankzugriffen Folgende Fragen sollten bei DB-Zugriffen gestellt und beantwortet werden: > Sind Indizes in geeigneten Rahmen angelegt? > s. vorheriges Kapitel (3.4.1) > Lesen Anweisungen am Tabellenpuffer vorbei? Hierbei kann die Transaktion ST10 verwendet werden, um die Zugriffshäufigkeiten auf gepufferten Tabellen zu überprüfen. Mit der Transaktion ST05 können mit dem kombinierten SQL- und Puffer-Trace Zugriffe ermittelt werden, die wider Erwarten den Tabellenpuffer nicht verwenden. Und mit Hilfe des Code Inspectors lassen sich viele dieser Statements bereits im Vorfeld statisch ermitteln. > Kann ein DB-Index zur Sortierung auf der DB mit ORDER BY genutzt werden? Im einfachsten Fall kann dafür der Zusatz PRIMARY KEY verwendet werden, wenn die Sortierung nach dessen Feldern erfolgen soll. Sind andere Sortierungen erforderlich, kann es helfen, einen Index anzulegen, der die gewünschten Felder in der korrekten Reihenfolge enthält. Allerdings sollten dabei die Hinweise zur Anzahl von Indizes pro Tabelle beachtet werden. Erfolgt der Zugriff mit ORDER BY nur selten, lohnt es sich in der Regel nicht, dafür einen eigenen Index anzulegen. In diesem Fall sollte die Sortierung im ABAP erfolgen, sofern dies die zu sortierende Datenmenge zulässt.

18 18 3 Performance Beispiel: Die Tabelle enthält ein Belegdatum und es sollen die letzten n Belege sortiert nach diesem Datum ermittelt werden. In diesem Fall würde sich ein Index über dieses Feld wahrscheinlich rentieren, weil zum einen dieses Feld in der WHERE-Bedingung enthalten ist und gleichzeitig der Zusatz ORDER BY Belegdatum vom vorhandenen Index profitiert Datenbankzugriffe Die auf der Datenbank selektierte und an die Anwendungsschicht zu übergebende Datenmenge sollte grundsätzlich so gering wie möglich gehalten werden. Nachfolgend finden Sie Hinweise, wie Sie dies im konkreten Fall umsetzen können. BEST PRACTICE: > Spaltenreduzierung: Vermeiden Sie *-Selektionen und benennen Sie stattdessen die benötigen Spaltennamen in der Selektion. Insbesondere das unnötige Laden von Spalten des Typs String ist teuer. Die Ergebnistabelle sollte mit der Selektionsstruktur übereinstimmen, um optimale Ergebnisse zu erzielen. Sollten in der Ergebnistabelle noch mehr Felder enthalten sein, aber die gewünschten Felder namensgleich angelegt sein, ist auch der Zusatz CORRESPONDING FIELDS möglich und führt nicht zu zusätzlicher Laufzeit. Gleichzeitig wird die Robustheit der Software erhöht. > Optimale Suchabfrage Versuchen Sie für die Selektion von Daten möglichst nur Abfragen zu verwenden, die einen der vorhandenen Indizes vollständig nutzen. Sollte das nicht möglich sein, achten Sie möglichst darauf, zumindest die ersten Elemente des Index zu verwenden, damit die zeilenweise Suche auf eine möglichst kleine Menge von Datensätzen reduziert werden kann. > Zeilenreduzierung Nutzen Sie die WHERE-Bedingungen, indem Sie die Selektion beschreiben und die an das ABAP-System zu übermittelnden Daten minimieren. Verwenden Sie SELECT SINGLE / UP TO n ROWS, wenn Sie nur einzelne Zeilen benötigen. > Existenzchecks Die Prüfung, ob Datensätze, die einem bestimmten Selektionskriterium genügen, existieren, sollten nicht mit der Anweisung COUNT(*), sondern mit SELECT SINGLE <Feldname> erfolgen, wobei das genannte Feld aus dem zur Selektion verwendeten Index stammen sollte. Dies vermeidet unnötige Zugriffe auf die Tabellendaten. > Aggregate Aggregate (MIN, MAX, ) werden immer auf dem Datenbankserver ausgewertet. Dadurch wird die Tabellenpufferung umgangen. Wegen der daraus potenziell entstehenden Last auf dem DB-System, das in vielen Installationen von sehr vielen Applikationsservern angesprochen wird, sollten Entwickler prüfen, welche Datenmenge für das Aggregat verwendet werden muss und ob es sich lohnen kann (sofern diese nicht groß ist), die Daten in eine interne Tabelle zu laden und das Aggregat dort durchzuführen. Allerdings weisen wir schon jetzt darauf hin, dass nach aktuellem Kenntnisstand insbesondere HANA-basierte Datenbankabfragen gerade bei Aggregaten ihre Stärken haben und damit deren Einsatz für HANA explizit sinnvoll ist. Beispiel: Um den durchschnittlichen Wert über eine große Anzahl (>100000) von Bestellungen zu ermitteln, ist es sinnvoll, dieses Aggregat auf dem DB-System ermitteln zu lassen, um nur einen oder wenige Werte statt hunderttausender an die Applikationsserver übermitteln zu lassen, um

19 19 dort den Durchschnittswert im ABAP zu berechnen. Dies gilt insbesondere, wenn diese Auswertung nur selten (z.b. einmal pro Tag) erfolgt. Soll hingegen die Summe der Bestellpositionen eines einzelnen Auftrags sehr häufig und von allen vorhandenen Applikationsservern ermittelt werden, ist die Ermittlung im ABAP wahrscheinlich die für die Gesamtsituation günstigere Variante. > Updates Die Anweisung UPDATE SET ermöglicht das Übertragen von einzelnen zu ändernden Feldern (statt des gesamten Datensatzes). Wenn möglich, sollte diese Anweisung bevorzugt verwendet werden. > Ausführungshäufigkeit bei DB-Zugriffen Jede Ausführung eines Open SQL-Statements ist mit einem gewissen Overhead (Parsen, Abgleich gegen Statement-Puffer im DBMS usw.) verbunden. Daher sollten pro Statement möglichst viele der benötigten Daten auf einmal übertragen werden. Werden beispielsweise die Daten von 50 Aufträgen benötigt, sollten diese nicht durch 50 Einzelaufrufe ermittelt werden, sondern durch ein einzelnes Statement, das die sog. Array-Zugriffe unterstützt. Diese sind durch die Zusätze INTO TABLE bei SELECTS bzw. FROM TABLE bei schreibenden Zugriffen zu erkennen. Vermeiden Sie auf jeden Fall Open SQL-Statements innerhalb von Schleifen! Bei einem solchen Konstrukt fällt der Overhead für diese Statements bei jedem Schleifendurchlauf an. Setzen Sie MODIFY <DB-Tabelle> nicht ein! Erstens sollte innerhalb einer Applikation klar sein, ob Datensätze neu erstellt wurden oder vorhandene angepasst werden müssen. Zweitens ist dieses Statement aus Performance-Gesichtspunkten sehr kritisch: Selbst mit dem Zusatz FROM TABLE werden einzelne Zugriffe pro Zeile der internen Tabelle ausgeführt und dabei wird jeweils zuerst ein UPDATE versucht und im Fehlerfall ein INSERT nachgelegt. D.h., bei vielen neu zu erstellenden Datensätzen erfolgen nicht n Einzelzugriffe, sondern 2n mit n=anzahl neue Datensätze in der internen Tabelle. Best Practice Leitfaden Development, 31. Januar 2013, DSAG e. V. > VIEWS/JOINS Geschachtelte SELECT-Anweisungen und SELECT-Anweisungen in Schleifen sollten vermieden werden. Stattdessen bieten sich VIEWS, JOINS oder der Zusatz FOR ALL ENTRIES an. Bei FOR ALL ENTRIES sollte man jedoch auf Folgendes achten: a. Ist die interne Tabelle leer, auf der FOR ALL ENTRIES basiert, dann werden alle Einträge geladen. b. Sind in der internen Tabelle Einträge doppelt vorhanden, kann dies dazu führen, dass die zugehörigen Datensätze auch doppelt von der Datenbank geladen werden. Es empfiehlt sich daher, zuvor ein DELETE ADJACENT DUPLICATES aufzurufen. 3.5 Interne Tabellen und Referenzen Interne Tabellen stellen ein zentrales Konstrukt bei der Entwicklung von Anwendungen mit ABAP dar. Neben Datenbankzugriffen sind sie aber auch gleichzeitig eine prominente Quelle von Performance-Problemen. Bei kleinen Datenmengen stellen Dinge wie die Wahl der passenden Tabellenart und eines passenden Schlüssels noch kein Problem dar. Werden aber größere Datenmengen verarbeitet, wie es z. B. nach einem Wechsel auf ein Konsolidierungssystemgeschieht, können vorher aus Performance-Sicht unkritische Stellen zu erheblichen Laufzeitverlängerungen führen. BEST PRACTICE: Wir empfehlen die Beachtung der nachfolgenden Hinweise zur Steigerung der Performance von Anwendungen:

20 20 3 Performance > Wählen Sie die Tabellenart passend zur späteren Verwendung: > Standard-Tabellen eignen sich für Daten, die nur selten oder gar nicht nach bestimmten Kriterien durchsucht werden müssen. Wenn keine Suche erfolgen muss, lohnt es sich nicht, die Kosten für die Erstellung und Aktualisierung der zusätzlichen Schlüsselstrukturen der anderen Tabellenarten zu zahlen. Bei sehr kleinen Datenmengen (<100 Zeilen) kann je nach Häufigkeit der Suchanfragen und Breite der Tabelle ein Verzicht auf einen expliziten schlüssel geeignet sein. > Sorted-Tabellen bieten sich an, wenn die Daten häufig nach (Teil-)Schlüsseln durchsucht werden müssen, aber keine Eindeutigkeit der Schlüsselfelder garantiert werden kann. Gerade Zugriffe, die nur mit einem ersten Teil der Schlüsselfelder stattfinden, können nur von dieser Tabellenart unterstützt werden. > Hashed-Tabellen sind perfekt dafür geeignet, in Dictionary-artigen Konstrukten nach eindeutigen Schlüsseln zu suchen. Wenn die Eindeutigkeit der Einträge im Hinblick auf die schlüsselfelder garantiert werden kann und die Suchzugriffe immer mit dem vollständigen schlüssel (=alle Felder des Schlüssels werden auf Äquivalenz gegen einen jeweiligen Wert geprüft) erfolgen, ist diese Tabellenart in der Regel optimal. > Wenn für eine Tabelle vom Typ Sorted oder Hashed Zugriffe erfolgen, sollten diese immer mit dem passenden (Teil-)Schlüssel stattfinden. Dies bedeutet, bei READ TABLE den Zusatz WITH TABLE KEY zu verwenden und bei LOOP AT WHERE möglichst viele aufeinander folgende Felder des Schlüssels mit = zu vergleichen. Dann werden die intern aufgebauten Schlüsselstrukturen verwendet, um die passenden Einträge schneller zu ermitteln. > Ab AS ABAP 7.02 können Sie bei internen Tabellen, die selten geändert werden, aber mit mehr als einem Zugriffmuster gelesen werden, neben dem primären Schlüssel, der wie gehabt definiert und verwendet wird, auch weitere sekundäre Schlüssel definieren, die auch einen vom Primärschlüssel abweichenden Typ (Sorted, Hashed) haben. Als Beispiel können Sie damit für eine als Hashed definierte Tabelle mit eindeutigem Primärschlüssel einen weiteren Schlüssel vom Typ Sorted definieren, der es ermöglicht, performant auf die Daten der Tabelle aus einem anderen Blickwinkel (nicht eindeutig, Teilschlüssel möglich) zuzugreifen, ohne die eigentlichen Daten zweimal im Hauptspeicher anzulegen und bei Änderungen manuell für die Konsistenz zwischen beiden Tabellen zu sorgen. > Ähnlich wie bei den DB-Zugriffen existieren für interne Tabellen Einzelsatzzugriffe und Massenzugriffe. Wenn möglich, sollten immer die Varianten mit Massenzugriffen gewählt werden, die performanter arbeiten als mehrere Einzelzugriffe. Als Beispiel sollten Sie beim Anhängen von Zeilen einer Teilergebnistabelle zur Gesamtergebnistabelle das Anweisungsmuster APPEND LINES OF TO verwenden, anstatt die gleiche Funktion über eine Schleife LOOP AT mit einzelnen APPEND TO zu realisieren. > Bei der Verwendung der Anweisung SORT sollten Sie immer die gewünschten Sortierfelder angeben. Erstens erhöht dies die Lesbarkeit des Codings und zweitens ist bei den wenigsten Standard- Tabellentypen ein Tabellenschlüssel definiert. Fehlt ein solcher Schlüssel, wird die gesamte