BTP - External Entity (Performance)

Inhaltsverzeichnis

• Einleitung
• Performance Test
• Anpassung
• Messung
• Auswertung
• ODBC
• Aktuell
• Planung
• Fazit

In diesem Artikel schauen wir uns die Performance der aktuellen Technologien in der BTP an und vergleichen diese mit den External Entities und welches Potential noch in der Technologie steckt.

 

Einleitung

Vor einer Weile hatten wir bereits einen ersten Performance-Check gemacht und dann verschiedene Technologien gegeneinander verglichen. Mit dabei waren der klassische RFC-Funktionsbaustein, ein OData-Service, der Aufruf von Plain-HTTP und die verschiedenen Protokolle in der OData-Version. Mittlerweile kann man auch sehr gut die External Entities und die SQL Services verwenden. Dabei hatten wir vor einer Weile einen Artikel geschrieben, wie wir SQL Services anbinden und diese auch verwenden können.

 

Performance Test

In diesem Kapitel führen wir den Performance Test durch und schauen uns die Leistung der External Entity im Vergleich zu den anderen Technologien an.

 

Anpassung

Dazu implementieren wir eine weitere Methode in unserer Performance-Klasse. Im Großteil übernehmen wir die Logik, die wir bereits im Funktionsbaustein implementiert haben, nämlich die dynamische Ermittlung der Felder, die angefragt werden. Diese Logik müssen wir ebenfalls in die Methode übernehmen. Ansonsten können wir direkt den SELECT von unserer externen Entität machen und alle Parameter am SELECT angeben. Damit ist dies die einfachste Implementierung, wenn es um den Zugriff geht.

DATA(fields_for_select) = ``.
LOOP AT request_data-fields REFERENCE INTO DATA(field_name).
  IF fields_for_select <> ``.
    fields_for_select &&= `, `.
  ENDIF.
  fields_for_select &&= field_name->*.
ENDLOOP.

IF fields_for_select IS INITIAL.
  fields_for_select = `*`.
ENDIF.

SELECT FROM ZBS_X_DemoSQLPerformance
  FIELDS (fields_for_select)
  ORDER BY identifier
  INTO CORRESPONDING FIELDS OF TABLE @result-data_sql
  UP TO @request_data-top ROWS
  OFFSET @request_data-skip.

 

Messung

In diesem Fall führen wir noch einmal alle Test Cases aus. Wir aggregieren allerdings die Ergebnisse und machen jeweils fünf Ausführungen der einzelnen Testläufe und bilden den Durchschnitt dieses Ergebnisses, um eine Zahl für den Vergleich zu erhalten. Sollten größere Abweichungen wieder auftreten, wie damals beim HTTP Fall, dann würden wir diese herausrechnen, um ungefähre Werte für die Technologie zu erhalten und Puffer- oder Framework-Probleme herauszufiltern.

 

Auswertung

Grundsätzlich ergibt sich ein ähnliches Ergebnis wie bereits bei der letzten Performance-Messung, zumindest für die anderen Technologien. In diesem Vergleich schauen wir uns einmal RFC und ODBC an, da diese Technologien relativ nah beieinander sind und den heutigen Vergleich auch ausmachen sollen. Im Grunde kann man sagen, dass RFC immer noch das schnellste Protokoll ist, was die Implementierung angeht. Wir werden uns aber im nächsten Kapitel noch einmal anschauen, wieso aktuell ODBC hinterherhinkt und was vielleicht noch in Zukunft passieren könnte.

Schaut man sich das Ganze in Zahlen an, kann man ungefähr sagen, dass ODBC circa um das Zehnfache hinter RFC liegt, aber ungefähr um das Hundertfache vor den anderen Technologien. Das heißt, grundsätzlich ist ein sehr hohes Potenzial da, performante Schnittstellen und Datenanbindungen über ODBC zu erhalten. Wiederum auffällig sind aber kleinere Ausreißer, die nicht zu den Zahlen passen und zum Beispiel, wie im ersten Testfall, doch sehr weit auseinanderliegen.

Grundsätzlich steckt diese Technologie noch in den Kinderschuhen. Das heißt, hier können Fehler auftreten oder falsche Zugriffspläne verwendet werden. Grundsätzlich werden aber die richtigen Daten geliefert. Hier wird SAP sicherlich die nächsten Jahre weiter an der Technologie optimieren, um bessere Integrationsszenarien zu ermöglichen und auch die Performance zu steigern.

 

ODBC

Wieso eigentlich ODBC? Die Technologie hat aktuell mehrere Facetten, wenn man sie anschaut: Sie wird implementiert über External Entities, wir verwenden SQL-Services, um auf der anderen Seite zuzugreifen, und auch der Name SDA schwebte im Raum. Schauen wir aber einmal in die Verbindung hinein, so werden ODBC-Treiber verwendet, um den Zugriff zu ermöglichen.

 

Aktuell

Wieso sehen wir also noch so viel Potenzial in der Technologie? Schauen wir uns einmal ein Übersichtsbild an, wie die aktuelle Einrichtung und die Zugriffswege in unserem Szenario sind.

So haben wir auf der linken Seite das ABAP-Environment, wo wir die External Entity mit dem Communication Arrangement eingerichtet haben. Dieses Communication Arrangement kommuniziert per HANA-ODBC-Treiber mit der virtuellen Tabelle auf der HANA Cloud. Die HANA Cloud wiederum führt eine Authentifizierung über den Cloud Connector gegen das SAP-System durch über einen ABAP-ODBC-Treiber. Dabei verwenden wir einen SQL-Service und einen Core Data Service auf der anderen Seite. Das heißt, im Moment haben wir hier zwei verschiedene Treiber und eine HANA Cloud, die wir eigentlich nicht benötigen. Aktuell wird das Szenario mit dem direkten Zugriff nicht unterstützt, hier gibt es gewisse technische Voraussetzungen, die erst geschaffen werden müssen, damit das funktioniert.

 

Aktuell wird auch das Thema Principal Propagation nicht unterstützt, das heißt, wir haben immer eine Basic Authentication (oder Zertifikat) zwischen der Kommunikation, was wiederum das Thema Access Control nicht sauber unterstützt. Wo sollte der Vorteil eigentlich daran liegen? Wir greifen auf einen Standard Core Data Service zu, nutzen das Access Control und erhalten nur die Daten, für die wir berechtigt sind. Damit müssen wir in der Übergangslösung auch ein Berechtigungskonzept implementieren.

 

Planung

Das heißt, im Moment haben wir eine Zwischenlösung, die schon sehr performant läuft, aber wiederum Performance benötigt, um zuzugreifen. In Zukunft soll das Ganze so funktionieren, dass das Communication Arrangement direkt über den Cloud Connector mit dem SQL-Service spricht und wir nur noch den ABAP-ODBC-Treiber verwenden. Damit können wir uns die HANA Cloud sparen, die virtuelle Tabelle, den Hop und den HANA-ODBC-Treiber. Das heißt, hier ist grundsätzlich ein hohes Performance-Potenzial vorhanden.

 

Das heißt, wenn in Zukunft einmal die Zwischenlösung abgeschaltet ist und wir per Principal Propagation zugreifen, haben wir ein gewisses Potenzial, erstens Objekte zu sparen. Wir können das Access Control im System direkt nutzen und wir haben ein hohes Potenzial für mehr Performance beim Zugriff, was die Modellierung und Nutzung noch einmal um ein Vielfaches erhöht.

 

Fazit

Die Technologie ist bereits vorhanden und verspricht hohes Potenzial bei der Nutzung sowie beim Thema Performance, um Side-by-Side-Szenarien performant bauen zu können. Das bedeutet aber wiederum nicht, dass wir sie aktuell nicht nutzen sollten, sondern sie bewusst einsetzen können, um gewisse Szenarien umsetzen zu können. Die Technologie sollte auf jeden Fall im Auge behalten werden, da hier das größte Potenzial besteht, effizient mehr Side-by-Side-Szenarien auch in Zukunft umsetzen zu können.