BTP - External Entities
Was machen eigentlich External Entities in ABAP und wie kannst du damit einfach per SDA Daten aus einer On-Prem Datenbank lesen? Mehr Details in diesem Artikel.
Inhaltsverzeichnis
External Entities sind da. Mit ihnen gibt es die Möglichkeit, Daten aus Remote Datenbanken zu lesen, als wären sie in der lokalen Datenbank vorhanden. Mit einem kleinen Trick geht auch der Zugriff auf on Premise Datenbanken. Das schauen wir uns heute an.
Einleitung
Bereits mit dem Release 2408 hat die SAP die External Entities eingeführt. Damit wird ermöglicht, per SDA (Smart Data Access), auf Tabellen in Remote Datenbanken zuzugreifen. Derzeit sind damit leider noch keine Zugriffe vom ABAP environment auf on Premise Datenbanken möglich, da der hierfür benötigte CloudConnector nicht von der HANA DB des ABAP environments erreichbar ist. Mit einer HANA Cloud Datenbank zwischen dem ABAP environment und dem CloudConnector ist aber auch dieser Zugriff möglich.
Die Architektur für das in diesem Artikel beschriebene Szenario sieht folgendermaßen aus:
Voraussetzungen
Folgende Systeme sind für das Szenario erforderlich:
- ABAP environment
- SAP HANA Cloud Datenbank
- Cloud Connector
- SAP HANA Datenbank (onPremise)
Für die Kommunikation muss der CloudConnector mit dem gleichen BTP-Subaccount verbunden sein, wie die SAP HANA Cloud Datenbank. Im CloudConnector muss die HANA onPremise Datenbank erreichbar und freigeben sein:
SDA HANA Cloud zu HANA onPremise
Bevor wir uns die External Entites für unser Szenario anschauen können, müssen wir die Tabellen, auf die wir zugreifen wollen, per SDA in der HANA Cloud Datenbank als virtuelle Tabellen anlegen. Hierfür benötigen wir für jedes relevante onPremise Datenbank-Schema eine so genannte RemoteSource in der HANA Cloud Datenbank. Diese können wir folgendermaßen anlegen:
CREATE REMOTE SOURCE <remote_source>
ADAPTER hanaodbc
CONFIGURATION
'servernode=<virtual_host>:30041;useHaasSocksProxy=true;sccLocationId=<cloud_connector_location_id'
WITH CREDENTIAL TYPE 'PASSWORD' USING 'user=<User>;password=<Password>';
Jede Tabelle, die über diesen Weg verfügbar sein soll, müssen wir einmalig eine Virtuelle Tabelle in der HANA Cloud Datenbank anlegen:
CREATE VIRTUAL TABLE <virtual_table_name> AT <remote_source>."<NULL>".<schema>.<table_name>;
Für unser Beispiel verwenden wir die folgende onPremise Datenbanktabelle:
External Entity
Jetzt lohnt es sich endlich im ABAP environment eine External Entity anzulegen. Dafür legen wir eine neue DataDefinition an und wählen das Template für ExternalEntities:
Im Editor können wir jetzt die Attribute aufnehmen, die uns interessieren. Vollständig sieht es für die Tabelle so aus:
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'ExternalEntity: App Holiday'
define external entity ZCT_X_AppHoliday external name APP_HOLIDAY
{
key Holiday : abap.datn external name HOLIDAY;
Description : abap.char(50) external name REMARK;
} with federated data
provided at runtime
Wenn wir uns das genauer anschauen, sehen wir, dass die ersten beiden Statements Annotationen sind. Diese berücksichtigen wir in dem Blogeintrag nicht weiter und schenken ihnen hier keine weitere Beachtung.
Mit den Schlüsselwörtern „define external entity“ wird die eigentliche Definition eingeleitet. Im Anschluss daran definieren wir den Namen, unter dem die Tabelle im ABAP environment ansprechbar sein soll. Hinter den Schlüsselwörtern „external name“ müssen wir den Namen der Tabelle auf der HANA Cloud Datenbank angeben.
In der Projektionsliste definieren und typisieren wir die Attribute der Tabelle, die wir im ABAP environment verfügbar machen wollen. Auch hier müssen wir angeben, wie die Attribute in der Remote-Tabelle heißen. Wir müssen nicht alle Attribute der Tabelle aufnehmen.
Zum Abschluss müssen wir noch die Schlüsselwörter „with federated data“ und „provided at runtime“ ergänzen. Der erste Teil gibt an, dass die Daten nicht im eigenen System zu finden sind. Mit dem zweiten Teil definieren wir, dass wir bei dem Zugriff auf die Tabelle mitgeben, wo sie tatsächlich liegt. Hier ist perspektivisch von der SAP geplant, auch zur „designtime“ schon das Ziel der External Entity mitzugeben. Derzeit ist das noch nicht möglich.
Logisches Externes Schema
Für den Zugriff auf die Externe Entität benötigen wir pro Schema auf der HANA Cloud Datenbank ein Logisches Externes Schema. Das legen wir als neues Objekt im ADT an:
Outbound Service
Das logische externe Schema muss in einem Outbound Service verwendet werden. Auch diesen legen wir im ADT an:
Communication Scenario
Als letztes ADT-Objekt benötigen wir ein Communication Scenario. Damit können wir gleich im FLP die Konfiguration für die Verbindung auf die HANA Cloud Datenbank anlegen. Aber ein Schritt nach dem anderen, hier das Communication Scenario:
Im Tabreiter „Outbound“ müssen wir unseren Outbound Service hinzufügen:
Nach dem Sichern müssen wir das Scenario noch veröffentlichen (publishen).
Konfiguration
Wir haben im ADT alles vorbereitet und können jetzt die Konfiguration, also die eigentlichen Verbindungsinformationen hinterlegen.
Communication System
Zuerst legen wir uns ein Communication System an:
Hier müssen wir im Host Namen die URL auf die HANA Cloud Datenbank eingeben. Zusätzlich müssen wir das System für Remote SQL Access konfigurieren und Usernamen und Passwort für die Datenbank mitgeben.
Communication Arrangement
Das jetzt angelegte Communication System verwenden wir in einem neuen Communication Arrangement:
Hier ist die Stelle, an dem wir das Datenbank-Schema angeben müssen, in dem sich unsere Virtuelle Tabelle befindet.
Lesender Zugriff
Jetzt können wir die External Entity verwenden. Das geht sehr einfach mit folgendem Select:
SELECT
FROM ZCT_X_AppHoliday
PROVIDED BY zct_les_hana_cloud
FIELDS *
INTO TABLE @DATA(holidays).
Hinter dem Schlüsselwort “Provided by“ müssen wir das Logische Externe Schema angeben, dass wir angelegt haben. Darüber wird der Outbound Service und damit das Communication Scenario gefunden. Dadurch weiß das ABAP environment, wie es die Verbindung zur HANA Cloud Datenbank aufbauen muss.
Was passiert im Hintergrund
Beim jedem ersten Zugriff nach einer Änderung der External Definition wird vom ABAP environment geprüft, ob es eine entsprechende virtuelle Tabelle in der Datenbank des ABAP environments gibt. Ist das nicht der Fall, wird sie hier vom Standard automatisch angelegt:
In unserem Beispiel wird die virtuelle Tabelle folgendermaßen von der SAP angelegt:
CREATE VIRTUAL TABLE "SAPABAP"."EEDVT#ZCT_X_APPHOLIDAY#ZCT_LES_HANA_CLOUD#100" AT "DD#LESRS#SAPABAP#ZCT_LES_HANA_CLOUD#100"."<NULL>"."<DB_SCHEMA>"."APP_HOLIDAY"
Das Ergebnis der Selektion liefert genau die Daten zurück, die sich in der on-Premise Datenbanktabelle befinden:
Schreibender Zugriff
Neben dem lesenden Zugriff können wir auch schreibend auf die External Entity zugreifen. Dafür müssen wir das Schlüsselwort „writeable“ in unserer Datendefinition ergänzen:
Für schreibende Zugriffe aus dem Coding müssen wir eine Connection mitgeben. Diese bezieht sich auf das logische Externe Schema und wird sowohl beim Schreiben als auch beim Commit benötigt:
DATA(connection) = cl_abap_sql_connection_builder=>write_enabled_4_logical_schema(
i_connection_name = 'R/3*service'
i_logical_schema_name = 'ZCT_LES_HANA_CLOUD'
)->create( ).
DATA(new_holiday) = VALUE ZCT_X_AppHoliday( Holiday = '20250420' Description = 'Ostersonntag' ).
INSERT ZCT_X_AppHoliday
PROVIDED BY zct_les_hana_cloud
CONNECTION @connection
FROM @new_holiday.
COMMIT CONNECTION @connection.
Schauen wir uns das Ergebnis einmal in der Konsole an:
Nächste Schritte
Jetzt da wir auf die Daten lesend und schreibend zugreifen können, stellt sich natürlich die Frage nach möglichen Einsatzgebieten. Denkbar wäre es hier beispielsweise, die External Entity entweder rein lesend in einer CustomEntity oder auch schreibend in einem unmanaged RAP BO per FioriElements zur Verfügung zu stellen.
Laut Dokumentation ist es sogar möglich, Tabellen aus unterschiedlichen Datenbanken mit External Entities zu joinen. Hier ergeben sich je nach vorliegendem Datenmodel neue, spannende Möglichkeiten.
Fazit
Für die Ersteinrichtung der Verbindung sind zwar einige Schritte erforderlich und sowohl die Anlage aller erforderlichen ADT-Objekte als auch die Konfiguration der Verbindung sind etwas aufwändiger. Dafür ist die Verwendung der Remote verfügbaren Tabellen anschließend denkbar einfach. Sobald man mehr als eine Tabelle aus dem gleichen Schema der onPremise HANA Datenbank lesen möchte, kippt das Kosten-Nutzen-Verhältnis spürbar, da die meisten der anzulegenden Objekte nur einmalig pro beteiligtem Datenbankschema angelegt werden müssen.
Alles in allem hat die SAP aus meiner Sicht einen sehr eleganten Weg geschaffen, Tabellen aus externen Datenbanken zu lesen, ohne über andere Technologien (oData, etc.) gehen zu müssen. Erste Tests bei uns im Unternehmen deuten auch auf eine mehr als akzeptable Perfomance hin.
Das in diesem Beitrag geschilderte Szenario wird deutlich einfacher, wenn die Daten im Original in der HANA Cloud Datenbank vorhanden sind und weder die onPremise Datenbank noch der CloudConnector eine Rolle spielen.
Quelle:
SAP Help - External Entities
SAP Help - SAP HANA Smart Data Access
