Open SQL Procedure

Eine Open SQL Procedure ist ein in SAP Datasphere gespeichertes SQL-Programm (eine sogenannte Stored Procedure), das direkt in der Datenbank läuft und Daten dort transformiert. Sie ist der Weg über die Datenbank-Sprache SQLScript (SAP-Dialekt für HANA), wenn eine Transformation zu komplex für die grafischen Werkzeuge in Datasphere wird. Aufrufen lässt sich die Prozedur als Baustein in geplanten Abläufen (Task Chains).

Was ist eine Open SQL Procedure?

Eine Open SQL Procedure liegt in einem Space (der Arbeitsumgebung eines Teams in SAP Datasphere) und dort im Open-SQL-Schema, einem Bereich, den externe SQL-Werkzeuge direkt ansprechen dürfen. Neben Prozeduren enthält dieses Schema auch Tabellen und Sichten (Views, also gespeicherte Abfragen). Die Prozedur wird in HANA-SQLScript geschrieben, also in der SQL-Sprache der zugrundeliegenden Datenbank [SAP HANA Cloud](/insights/glossar/hana-cloud/), und läuft in genau dieser Datenbank, gemeinsam mit den anderen Tabellen und Views des Space.

Der Prozedurcode arbeitet set-basiert. Datasphere und HANA Cloud werten die enthaltenen SQL-Statements als Mengenoperationen aus und drücken sie in die In-Memory-Engine (Column Store) beziehungsweise die Native Storage Extension herunter. Cursor-basierte Zeilen-für-Zeilen-Logik ist zwar möglich, widerspricht aber dem üblichen Einsatzmuster: schwere Transformationen sollen im Datenbank-Layer bleiben, wo die Engine set-basierten Code am effizientesten ausführt.

Registriert wird die Prozedur als Space-Objekt. Damit ist sie in Datasphere sichtbar und wird von den orchestrierenden Mechanismen des Space konsumiert. In einer [Task Chain](/insights/glossar/data-builder/) erscheint sie unter „Others" als aufrufbarer Schritt, so dass sie sich zwischen Replication Flows, Transformation Flows und Views platzieren lässt. Über die Datasphere-Job-API und den HANA Job Scheduler ist auch ein externer oder minutengenauer Aufruf möglich.

Der Begriff „Open SQL" verweist auf den Öffnungs-Charakter des Schemas: die Prozedur folgt der offenen HANA-SQL-Schnittstelle und ist damit auch außerhalb der rein grafischen Datasphere-Werkzeuge editierbar. Klassisches HANA-SQLScript-Wissen aus HDI-Containern und älteren Data-Warehouse-Projekten lässt sich so weiterverwenden, ohne den Space-Kontext und die Governance von Datasphere zu verlassen.

Abgrenzung: Transformation Flow, Data Flow, Views, Open SQL Schema

Die häufigsten Verwechslungen entstehen an vier Stellen: gegenüber dem Transformation Flow als graphisch-deklarativer Alternative, gegenüber dem älteren Data Flow, gegenüber SQL/Graphical Views als reinen Read-Objekten und gegenüber dem Open-SQL-Schema selbst, in dem die Prozedur nur ein Objekt unter mehreren ist.

Die Entscheidung zwischen Transformation Flow und Open SQL Procedure fällt selten pauschal. Der Flow bleibt der Standardweg, weil er Delta-Staging und Nachvollziehbarkeit mitliefert. Die Prozedur wird gewählt, wenn Logik entweder zu verzweigt für ein deklaratives Modell ist oder gezielt am DB-Layer laufen soll, damit sie sich mit anderen SQL-Assets im Space verzahnen lässt.

Beispiel: Nachtfenster-Validierung im Finance-Space

Ein Datasphere-Space „Finance" verarbeitet in einem nächtlichen Task-Chain-Lauf Finanzbelege. Ein Replication Flow lädt die tägliche Beleg-Delta aus einem S/4HANA-System in eine [Local Table](/insights/glossar/local-tables/) FI_GL_Postings_Raw. Als nächster Schritt in derselben Task Chain ruft die Kette eine Open SQL Procedure sp_validate_postings im Open-SQL-Schema des Space auf.

Die Prozedur führt mehrere set-basierte Prüfungen aus: sie gleicht Kontonummern gegen eine Steuertabelle im selben Schema ab, prüft Währungscodes gegen einen Whitelist-View, markiert Belege mit unplausiblen Beträgen und schreibt fehlerhafte Zeilen in eine Fehler-Tabelle FI_GL_Postings_Errors. Die validen Sätze landen in einer Ziel-Local-Table FI_GL_Postings_Valid, die anschließend im Business Builder als Fact-Basis für Analytic Models dient. Der gesamte Ablauf besteht aus einem SQLScript-Block ohne Python-Fallback über einen Data Flow und ohne einen mehrstufigen View-Graph, der die gleiche Logik nur mühsam abbilden würde.

Zweiter typischer Einsatz: eine Prozedur berechnet saisonale Adjustments für Vertriebsdaten in Local Tables des Space und wird vor dem [Business Builder](/insights/glossar/business-builder/)-Konsum aus einer Task Chain aufgerufen. In beiden Fällen bleibt die Prozedur im HANA-Cloud-Speicher desselben Space, verzehrt keine separaten Data Integration Hours für einen zusätzlichen Data Flow und ist über die Datasphere-Governance kontrolliert.