Syntax für das Select Statement in OpenSQL
Ist Ihnen aufgefallen, wie die empfohlene Syntax des OpenSQL-SELECT-Statements in der SAP Help aussieht, die für Sie und Ihre Mitarbeiter relevant ist? Dabei stachen mir einige Elemente besonders hervor. In diesem Beitrag möchte ich Ihnen einen Überblick über diese Regeln geben und ein paar Hinweise für Clean Coding geben.
Das Wichtigste auf einen Blick
- Seit NW 7.4 SPS 05 Listen im OpenSQL-SELECT durch Kommas statt Leerzeichen trennen und ABAP-Hostvariablen mit @ markieren.
- Bei LEFT OUTER JOINs Bedingungen in die ON-Klausel verlagern, um alle linken Zeilen zu erhalten, und @ für Hostvariablen nutzen.
- Clean Code: Neue Zeile pro Klausel/Bedingung, Inline @DATA, Kommata und ADT-Syntax-Checker einsetzen.
- In ABAP Cloud CDS-Views und RAP priorisieren; OpenSQL nur für Legacy-Code und Migrationen verwenden.
Eingebetteter Editor in der Dokumentation von SAP.
Integration von ABAP Source Code
Innerhalb des SAP Help Portals zu Open SQL und Inner Joins beim Select Statement bin ich zuerst durch die oben abgebildete interaktive Code-Testumgebung aufmerksam geworden.
Durch diese Integration kann der ABAP Code in den ABAP Development Tools (ADT) geöffnet, getestet und analysiert werden. Vor allem die Funktion zum Debuggen erleichtert Entwicklern das Verständnis bei komplizierteren Beispielen. Das Ergebnis der Ausführung wird für ein besseres Verständnis entsprechend aufbereitet und übersichtlich formatiert.
Ergebnis der Ausführung in der Dokumentation
Erarbeiten Sie gemeinsam mit uns in einem Workshop Ihre individuelle Core Data Service Architektur. Profitieren Sie dabei von unserer Projekterfahrung.
Syntax des Select Statements
Welche Punkte sind Ihnen in der ersten Abbildung aufgefallen? Was sieht ungewohnt aus?
- Seit SAP NetWeaver 7.4 Support Package Stack 05 ist die Trennung in Listen in der OpenSQL Syntax mit Leerzeichen obsolet und wird durch die Trennung via Komma abgelöst. Dadurch ist zumindest klarer erkennbar, wann eine neue Spalte des Ergebnisses beginnt.
- In den Ausdrücken von SQL sollen ABAP Host Variablen (im ABAP Programm deklarierte lokale oder globale Datenobjekte) mit dem Fluchtsymbol @ markiert werden. In den strikten Syntaxprüfungen ist dies sogar verpflichtend. Die Fluchtsymbole sind Standard.
- Warum? Seit 7.40 SPO5 ist es nicht mehr erforderlich, dass bei allen Bedingungen im ON Teil eines Joins auf der rechten Seite eine Spalte steht. Daraus folgt, dass nun innerhalb der Bedingungen des Joins auch Vergleiche mit ABAP Hostvariablen gemacht werden können. Somit ergibt eine Kennzeichnung mit dem Fluchtsymbol @ auch für Clean Coding Sinn. Die Abbildung 3 zeigt ein Code Beispiel.
- Wer sich jetzt fragt, warum er Bedingungen von der WHERE Klausel auslagern sollte, dem hilft die folgende Notiz. Bei einem LEFT OUTER JOIN sollten diese auf der rechten Tabelle in die ON-Bedingungen des Joins verlagert werden, damit alle linken Zeilen erhalten bleiben.
Auszug aus der Dokumentation von SAP.
OpenSQL-Entwicklungen seit ABAP 7.50
Seit ABAP 7.50 und insbesondere ABAP 7.56 (S/4HANA-Standard) hat sich OpenSQL weiter zu einem vollwertigen, performanten SQL-Dialekt entwickelt. ARRAY-Fetching mit FOR ALL ENTRIES IN, UNION, Subqueries und nahtlose CDS-Integration sind nun Standard in S/4HANA On-Premise und Cloud. FOR ALL ENTRIES ist weiterhin verfügbar, gilt jedoch heute eher als Übergangslösung – bevorzugt sollten JOINs, Subqueries oder moderne IN @itab-Ausdrücke verwendet werden. Funktionen wie COALESCE, CASE, CAST, arithmetische Operatoren (+, -, *, /), ABS und ROUND – bereits seit 7.40 verfügbar – sind in RAP/CDS-Entwicklungen obligatorisch und optimieren komplexe Abfragen erheblich. Der strikte Modus mit @ für Hostvariablen ist in ADT standardmäßig aktiviert und empfohlen, um Code-Robustheit zu gewährleisten.
Vorschlag für Clean Code
Wie ein SELECT Statement mit der Standardsyntax aussehen könnte, sehen Sie in der folgenden Abbildung. Ich persönlich nutze seit einiger Zeit die Vorgehensweise, dass ich in dem Statement von OpenSQL immer eine neue Zeile pro Schlüsselwort, eine neue Zeile pro Bedingung, Kommata in den Listen und die Fluchtsymbole benutze. Dies verschafft meiner Meinung nach eine große Übersichtlichkeit und folgt dem SAP Standard.
Zudem habe ich die bewährte “Neue Zeile pro Klausel”-Regel beibehalten und um Inline-Deklaration (@DATA), FOR ALL ENTRIES mit @ und eine einfache Rechnung im SELECT erweitert. So bleibt alles übersichtlich und folgt dem aktuellen SAP-Standard.
Eigener Vorschlag für die Formatierung des Select Statements.
Fazit
Regelmäßiges Prüfen der Release Notes, wie SAP Note 3225461 für OpenSQL-Updates oder das S/4HANA 2025 Feature Enablement Package, hilft Ihnen in der Entwicklung das Maximum der Möglichkeiten auszuschöpfen und Best Practices zu festigen.
In ABAP Cloud ist klassisches Open SQL gegen Tabellen stark eingeschränkt; der Fokus liegt auf released APIs und CDS Views. Open SQL wird dort primär für Migrationen und Legacy Code genutzt, nicht für neue Cloud Entwicklungen.
Tipp für Neuentwicklungen: Priorisieren Sie CDS Views und RAP statt klassischem OpenSQL – OpenSQL bleibt ideal für Legacy-Code oder Migrationen. Nutzen Sie den ADT Syntax-Checker und den interaktiven Editor (seit ABAP 7.50 Standard), um Syntax direkt zu validieren.
Auch wenn die hier vorgestellten Regeln zumeist eher kosmetischer Natur sind, lohnt es sich, diese Standardsyntax konsequent anzuwenden. Wie nutzen Sie solche Syntaxregeln? Wie gehen Sie in Zukunft mit Release Notes um? Wenn Ihnen mein Artikel gefallen hat oder Sie Fragen haben, hinterlassen Sie gerne einen Kommentar oder melden Sie sich per E-Mail.
Dieser Artikel wurde bereits im Juli 2016 veröffentlicht und am 13. Mai 2026 mit leichten Anpassungen aktualisiert.
FAQ
1) Welche Syntaxänderung gilt seit NW 7.4 SPS 05 für Listen?
Seit SAP NetWeaver 7.4 Support Package Stack 05 werden Listen in OpenSQL durch Kommas statt Leerzeichen getrennt, um Spalten klarer zu markieren.
2) Warum sind @-Fluchtsymbole für Hostvariablen zwingend?
ABAP-Hostvariablen müssen mit @ markiert werden, insbesondere im strikten Modus, da seit 7.40 SPS 05 Vergleiche in ON-Bedingungen von JOINs möglich sind.
3) Wie ON-Klausel bei LEFT OUTER JOINs richtig nutzen?
Bedingungen aus der WHERE-Klausel in die ON-Klausel der rechten Tabelle verlagern, um alle linken Zeilen zu erhalten.
