BTP - Anbindung On-Premise (Consumption Model v2)
In diesem Artikel wollen wir noch einmal einen Update zur Anbindung von On-Premise Systemen geben und wie dies mit einem Communication Arrangement durchgeführt wird.
Inhaltsverzeichnis
In einem älteren Artikel haben wir die Anbindung eines On-Premise OData über das Consumption Model beschrieben. In diesem Artikel werden wir einmal auf das neue Consumption Model v2 eingehen, was sich mit Release 2311 verändert hat und wir werden die Anbindung über das Communication Arrangement machen, anstatt den Destination Service zu verwenden.
Einleitung
Mit dem letzten Release auf dem ABAP Environment (2311) wurden Anpassungen am generierten Consumption Model für OData Integrationen gemacht. Diese Änderungen wollen wir uns in diesem Artikel einmal genauer anschauen. Zuvor wollen wir uns allerdings noch die Anbindung des On-Premise System über ein Communication Arrangement anschauen.
Consumption Model v2
Die neue Version des Consumption Model unterstützt nun die Generierung von v2 und v4 Consumption Models auf dem ABAP Environment. Damit können diverse Definitionen an OData Services geladen werden, vor allem da die Auswahl an v4 Services immer weiter zunimmt. Es werden nun auch viel weniger Artefakte durch den Wizard generiert. Zuvor wurde neben dem Consumption Model, für jede Entität eine abstrakte CDS Entität generiert, was je nach Anzahl der Entitäten zu vielen zusätzlichen Objekten geführt hat. Nun wird nur noch eine Klasse erzeugt die die einzelnen Entitäten als Typen definiert. Zusätzlich stehen verschiedene Konstantenstrukturen zur Verfügung, die die Entitäten und Funktionen zusammenfassen und für den Aufruf wiederverwendbar machen.
Kommunikation
Die nächste Besonderheit gegenüber der Destination ist die Generierung verschiedener Objekte für die Kommunikation mit dem Backend. Die Objekte werden für die Konfiguration benötigt.
Outbound Service
Der Outbound Service bestimmt das Protokoll der Kommunikation und die Objekte benötigen eine entsprechende Endung im Namen, so müssen HTTP Services mit _REST enden.
Das generierte Objekt besitzt nicht sehr viele Einstellungsmöglichkeiten und muss nicht mehr generiert werden.
Communcation Scenario
Als nächstes benötigen wir ein Communication Scenario, dass wir dann später bei der Einrichtung der Verbindung verwenden werden. In ADT kannst du im Anlagedialog nach dem Objekt "Communication Scenario" suchen, entsprechend geben wir einen Namen und eine Beschreibung.
Das Objekt besitzt einige Einstellungsmöglichkeiten, die wir aber nicht ändern müssen. Im unteren Teil findest du verschiedene Reiter, um die Berechtigungen und die verschiedenen Services hinterlegen zu können.
Wir wechseln nun auf den Reiter "Outbound", da wir aus dem System heraus das On-Premise System aufrufen wollen. Hierbei handelt es sich um eine Outbound Communication (aus der Sicht des ABAP Environment). Den gerade generierten Outbound Service hinterlegen wir, die Authentifizierungsmechanismen Basic (User und Passwort), sowie X.509 (Principal Propagation) sind bereits aktiviert und erlauben damit diese beiden Arten von Kommunikation.
Hinweis: Zum Abschluss muss noch der Button "Publish Locally" betätigt werden, damit das Szenario in der App "Communication Arrangement" erscheint. Ansonsten kann das Szenario später nicht konfiguriert werden.
Verbindung
Im letzten Artikel zu diesem Thema hatten wir den Destination Service verwendet, um auf das On-Premise System zuzugreifen. Dieser wird für die ABAP Szenarien aber mittlerweile als obsolet angesehen und man sollte vor allem auf Communication Arrangements setzen. Für die Konfiguration werden die folgenden beiden Anwendungen benötigt:
Communication Systems
Das Communication System wird in der gleichnamigen App konfiguriert und stellt so etwas wie die Verbindung, vergleichbar der SM59, dar. In diesem Fall verwenden wir den aktivierten Destination Service, um die Verbindung aufzubauen. Im Szenario des Communication System, kann diese Kommunikation weiterverwendet werden, vor allem wenn man die Destinations auch noch für Verbindungen mit CAP oder BAS benötigt, so spart man sich die doppelte Konfiguration.
Communication Arrangements
Über die App erstellen wir über "New" einen neuen Eintrag und suchen nach unserem erzeugten Communication Scenario. Den Namen können wir frei vergeben, haben wir nur eine Kommunikation mit diesem Szenario empfiehlt sich der gleiche Name.
In den Einstellungen hinterlegen wir dann noch das "Communication System", um so über das Szenario die Verbindung zum On-Premise System aufzubauen.
Model anlegen
Nun legen wir uns das Consumption Model an, dazu benötigen wir wieder die Metadaten des On-Premise Services, wie du die erhältst erfährst du im alten Artikel zur Anbindung. Nach dem Starten des Wizard geben wir den Namen und die Beschreibung des Consumption Models an:
Im nächsten Schritt geben wir den Pfad zur Metadata an, hier kannst du die Suchhilfe verwenden, wenn du den Pfad nicht kopiert hast. Hier vergibst du auch den Namen der Klasse, die angelegt wird.
Die nächsten zwei Schritte kannst du bestätigen, hier werden die Entitäten und Typen aufgelistet, sowie mögliche Objekte, die nicht aus dem Service übernommen werden können. Nach Abschluss der Generierung erhältst du das gewohnte Bild des Consumption Models: den Link zur Klasse, die Liste der Entitäten und einen Code-Wizard mit Beispielcodings zur schnellen Implementierung eines Testbeispiels.
In der Klasse stehen nun die jeweiligen Typen (Struktur und Tabelle) zur Verfügung, weiterhin gibt es eine Konstantenstruktur GCS_ENTITY_SET, über die man die einzelnen Entitäten ansprechen kann.
TYPES:
BEGIN OF tys_company_names_type,
company_name TYPE c LENGTH 60,
branch TYPE c LENGTH 50,
company_description TYPE c LENGTH 255,
END OF tys_company_names_type,
tyt_company_names_type TYPE STANDARD TABLE OF tys_company_names_type WITH DEFAULT KEY.
CONSTANTS:
BEGIN OF gcs_entity_set,
company_names TYPE /iwbep/if_cp_runtime_types=>ty_entity_set_name VALUE 'COMPANY_NAMES',
END OF gcs_entity_set.
Hinweis: Nach der Generierung können die Typen und Strukturen umbenannt werden, um möglichen Namenskonventionen gerecht zu werden.
Test
Um nun den Aufruf zu Test implementieren wir einmal das Beispielcoding aus dem Consumption Model. Dabei haben wir das Coding entsprechend angepasst und aufbereitet:
DATA lt_business_data TYPE TABLE OF zcl_bs_demo_rap_onprem_newv2=>tys_company_names_type.
DATA(lo_destination) = cl_http_destination_provider=>create_by_comm_arrangement( comm_scenario = 'ZBS_DEMO_COMM_SCENARIO' ).
DATA(lo_http_client) = cl_web_http_client_manager=>create_by_http_destination( lo_destination ).
DATA(lo_client_proxy) = /iwbep/cl_cp_factory_remote=>create_v2_remote_proxy(
is_proxy_model_key = VALUE #( repository_id = 'DEFAULT'
proxy_model_id = 'ZBS_DEMO_RAP_ONPREM_NEWV2'
proxy_model_version = '0001' )
io_http_client = lo_http_client
iv_relative_service_root = '/sap/opu/odata/sap/ZBS_API_COMPANY_NAME_O2/' ).
DATA(lo_request) = lo_client_proxy->create_resource_for_entity_set(
zcl_bs_demo_rap_onprem_newv2=>gcs_entity_set-company_names )->create_request_for_read( ).
lo_request->set_top( 50 )->set_skip( 0 ).
DATA(lo_response) = lo_request->execute( ).
lo_response->get_business_data( IMPORTING et_business_data = lt_business_data ).
Im ersten Schritt erzeugen wir uns eine Destination über das Konfigurierte Communication Arrangement, Pflichtfeld ist das Communication Scenario für die Erzeugung der Destination. Wenn der Datensatz nicht eindeutig ist, weil zum Beispiel mehr Services zugeordnet wurden, müssen zusätzliche Informationen mitgegeben werden:
- Communication System - Information zum System, welches in der App "Communication Systems" angelegt wurde und dem Szenario zugeordnet ist.
- Service ID - Name des Outbound Service der verwendet wird.
DATA(lo_destination) = cl_http_destination_provider=>create_by_comm_arrangement(
comm_scenario = 'ZBS_DEMO_COMM_SCENARIO'
comm_system_id = '<Comm System Id>'
service_id = '<Service Id>' ).
Für die Definition der Typen können wir die Typen aus der Klasse verwenden:
DATA lt_business_data TYPE TABLE OF zcl_bs_demo_rap_onprem_newv2=>tys_company_names_type.
Ebenso für die Übergabe des Entitätsnamen an die Abfrage:
DATA(lo_request) = lo_client_proxy->create_resource_for_entity_set(
zcl_bs_demo_rap_onprem_newv2=>gcs_entity_set-company_names )->create_request_for_read( ).
Fazit
Das neue Consumption Model bietet viele Vorteile gegenüber dem alten Model, ist aber im aktuellen Status noch nicht perfekt. Im nächsten Jahr wird es weitere Updates geben, um Workarounds zum Aufruf von Actions und Function überflüssig zu machen und in den Standard zu integrieren.
Weitere Informationen:
SAP Blog - Service Consumption Model 2 for OData Client Proxy
