Aktivieren von SAP Principal Propagation für Live-OData-Feeds mit Power Query
Das Arbeiten mit SAP-Datasets in Microsoft Excel oder Power BI ist eine allgemeine Anforderung für Kunden.
In diesem Artikel werden die Konfigurationen und Komponenten beschrieben, die dafür erforderlich sind, den SAP-Datasetverbrauch über OData mit Power Query zu ermöglichen. Die SAP-Datenintegration gilt als „live“, da sie von Clients wie Microsoft Excel oder Power BI bedarfsorientiert aktualisiert werden kann – im Gegensatz zu für die Instanz durchgeführten Datenexporten (z. B. beim Exportieren von CSV-Dateien mit SAP List Viewer (ALV)). Diese Exporte sind von Natur aus statisch und verfügen nicht über eine kontinuierliche Beziehung mit dem Datenursprung.
In diesem Artikel wird die End-to-End-Benutzerzuordnung zwischen der bekannten Microsoft Entra-Identität in Power Query und dem SAP-Back-End-Benutzer hervorgehoben. Dieser Mechanismus wird häufig als SAP Principal Propagation bezeichnet.
Der Fokus der beschriebenen Konfiguration liegt auf den Quellen von Azure API Management, SAP Gateway, SAP OAuth 2.0 Server mit AS ABAP und den OData-Quellen, aber die verwendeten Konzepte gelten für jede beliebige webbasierte Ressource.
Wichtig
Hinweis: Durch SAP Principal Propagation wird die Benutzerzuordnung zum lizenzierten benannten SAP-Benutzer sichergestellt. Wenden Sie sich an Ihren SAP-Vertreter, um Antworten auf Fragen zu SAP-Lizenzen zu erhalten.
Übersicht über Microsoft-Produkte mit SAP-Integration
Integrationen zwischen SAP-Produkten und dem Microsoft 365-Portfolio reichen von benutzerdefinierten Codes und Partner-Add-Ons bis hin zu vollständig angepassten Office-Produkten. Hier sind einige Beispiele angegeben:
Bei dem in diesem Artikel beschriebenen Mechanismus werden die integrierten OData-Standardfunktionen von Power Query verwendet, und der Schwerpunkt liegt auf in Azure bereitgestellten SAP-Systemen. Die lokalen Systeme werden mit dem selbstgehosteten Gateway von Azure API Management abgedeckt.
Weitere Informationen zu den Microsoft-Produkten, die Power Query im Allgemeinen unterstützen, finden Sie in der Dokumentation zu Power Query.
Überlegungen zum Setup
Endbenutzer haben eine Wahl zwischen lokalen Desktopclients oder webbasierten Clients (z. B. Excel oder Power BI). Die Clientausführungsumgebung muss für den Netzwerkpfad zwischen der Clientanwendung und der SAP-Zielworkload berücksichtigt werden. Netzwerkzugriffslösungen wie VPN sind nicht im Bereich für Apps wie Excel für das Web.
Azure API Management spiegelt lokale und webbasierte Umgebungsanforderungen mit verschiedenen Bereitstellungsmodi wider, die auf Azure-Systemlandschaften (intern oder extern) angewendet werden können. Internal bezieht sich auf Instanzen, die vollständig auf ein privates virtuelles Netzwerk beschränkt sind, während im Modus external der öffentlichen Zugriff auf Azure API Management aufrechterhalten wird. Lokale Installationen erfordern eine Hybridbereitstellung, damit der Ansatz angewendet werden kann. Dasselbe gilt für das selbstgehostete Gateway von Azure API Management.
Power Query erfordert übereinstimmende API-Dienst-URL und Microsoft Entra-Anwendungs-ID-URL. Konfigurieren Sie eine benutzerdefinierte Domäne für Azure API Management, um die Anforderung zu erfüllen.
SAP Gateway muss so konfiguriert werden, dass die gewünschten OData-Zieldienste verfügbar gemacht werden. Entdecken und aktivieren Sie die verfügbaren Dienste über den SAP-Transaktionscode /IWFND/MAINT_SERVICE. Weitere Informationen finden Sie in der OData-Konfiguration von SAP.
Benutzerdefinierte Domänenkonfiguration in Azure API Management
Unten sehen Sie den Screenshot einer Beispielkonfiguration in API Management mithilfe einer benutzerdefinierten Domäne mit der Bezeichnung api.custom-apim.domain.com und einem verwalteten Zertifikat und einer Azure App Service-Domäne. Weitere Domänenzertifikatoptionen finden Sie in der Dokumentation für Azure API Management.
Führen Sie die Einrichtung der benutzerdefinierten Domäne gemäß den Domänenanforderungen durch. Weitere Informationen finden Sie in der Dokumentation zum Thema einer benutzerdefinierten Domäne. Fügen Sie diese DNS-Einträge der Azure App Service-Domäne custom-apim.domain.com wie unten hinzu, um den Besitz des Domänennamens zu bestätigen und Zugriff auf das Zertifikat zu gewähren:
Die entsprechende Microsoft Entra-Anwendungsregistrierung für den Azure API Management-Mandanten würde unten aussehen.
Hinweis
Wenn eine benutzerdefinierte Domäne für Azure API Management keine Option für Sie ist, müssen Sie stattdessen einen benutzerdefinierten Power Query-Connector verwenden.
Azure API Management-Richtliniendesign für Power Query
Verwenden Sie diese Azure API Management-Richtlinie für die OData-Ziel-API, um den Authentifizierungsflow von Power Query zu unterstützen. Unten ist ein Codeausschnitt aus dieser Richtlinie abgebildet, in dem der Authentifizierungsmechanismus hervorgehoben ist. Suchen Sie hier nach der verwendeten Client-ID für Power Query.
<!-- if empty Bearer token supplied assume Power Query sign-in request as described [here:](/power-query/connectorauthentication#supported-workflow) -->
<when condition="@(context.Request.Headers.GetValueOrDefault("Authorization","").Trim().Equals("Bearer"))">
<return-response>
<set-status code="401" reason="Unauthorized" />
<set-header name="WWW-Authenticate" exists-action="override">
<!-- Check the client ID for Power Query [here:](/power-query/connectorauthentication#supported-workflow) -->
<value>Bearer authorization_uri=https://login.microsoftonline.com/{{AADTenantId}}/oauth2/authorize?response_type=code%26client_id=a672d62c-fc7b-4e81-a576-e60dc46e951d</value>
</set-header>
</return-response>
</when>
Zusätzlich zur Unterstützung des Anmeldeflows für das Organisationskonto unterstützt die Richtlinie das Umschreiben von OData-URL-Antworten, da der Zielserver mit ursprünglichen URLs antwortet. Unten ist ein Codeausschnitt aus der erwähnten Richtlinie abgebildet:
<!-- URL rewrite in body only required for GET operations -->
<when condition="@(context.Request.Method == "GET")">
<!-- ensure downstream API metadata matches Azure API Management caller domain in Power Query -->
<find-and-replace from="@(context.Api.ServiceUrl.Host +":"+ context.Api.ServiceUrl.Port + context.Api.ServiceUrl.Path)" to="@(context.Request.OriginalUrl.Host + ":" + context.Request.OriginalUrl.Port + context.Api.Path)" />
</when>
Hinweis
Weitere Informationen zum sicheren SAP-Zugriff über das Internet und zum Design des SAP-Umkreisnetzwerks finden Sie in diesem Leitfaden. Informationen zum Absichern von SAP-APIs mit Azure finden Sie in diesem Artikel.
SAP OData-Authentifizierung über Power Query in der Excel-Desktopversion
Mit der angegebenen Konfiguration wird der integrierte Authentifizierungsmechanismus von Power Query für die bereitgestellten OData-APIs verfügbar. Fügen Sie der Excel-Tabelle über die Menübandoption „Daten“ eine neue OData-Quelle hinzu („Daten importieren“ -> „Aus anderen Quellen“ -> „Aus OData-Feed“). Behalten Sie die Zieldienst-URL bei. Im folgenden Beispiel wird der SAP Gateway-Demodienst GWSAMPLE_BASIC verwendet. Ermitteln oder aktivieren Sie die URL mithilfe der SAP-Transaktion /IWFND/MAINT_SERVICE. Fügen Sie die URL schließlich mithilfe der Informationen aus dem offiziellen OData-Importleitfaden zu Azure API Management hinzu.
Rufen Sie die Basis-URL ab, und fügen Sie sie in die Zielanwendung ein. Im folgenden Beispiel wird die Integration mit der Excel-Desktopversion gezeigt.
Wechseln Sie die Anmeldemethode zu Organisationskonto, und klicken Sie auf „Anmelden“. Geben Sie das Microsoft Entra-Konto an, das dem benannten SAP-Benutzer auf dem SAP-Gateway mithilfe der SAP-Prinzipalverteilung zugeordnet ist. Weitere Informationen zur Konfiguration finden Sie in diesem Microsoft-Tutorial. In diesem SAP-Communitybeitrag und dieser Videoreihe erfahren Sie mehr zum Thema SAP Principal Propagation.
Wählen Sie dann aus, auf welcher Ebene die Authentifizierungseinstellungen von Power Query in Excel angewendet werden sollen. Im folgenden Beispiel wird eine Einstellung gezeigt, die für alle OData-Dienste gelten würde, die auf dem SAP-Zielsystem gehostet werden (nicht nur für den Beispieldienst GWSAMPLE_BASIC).
Hinweis
Die Einstellung des Autorisierungsbereichs auf URL-Ebene im folgenden Bildschirm ist unabhängig von den tatsächlichen Autorisierungen im SAP-Back-End. SAP Gateway bleibt das endgültige Validierungssteuerelement jeder Anforderung und zugeordneter Autorisierungen eines zugeordneten benannten SAP-Benutzers.
Wichtig
Der obige Leitfaden konzentriert sich auf den Prozess des Abrufens eines gültigen Authentifizierungstokens von Microsoft Entra ID über Power Query. Dieses Token muss für SAP Principal Propagation weiter verarbeitet werden.
Konfigurieren von SAP Principal Propagation mit Azure API Management
Verwenden Sie diese zweite Azure API Management-Richtlinie für SAP, um die Konfiguration für SAP Principal Propagation auf der mittleren Ebene abzuschließen. Weitere Informationen zur Konfiguration des SAP Gateway-Back-Ends finden Sie in diesem Microsoft-Tutorial.
Hinweis
In diesem SAP-Communitybeitrag und dieser Videoreihe erfahren Sie mehr zum Thema SAP Principal Propagation.
Die Richtlinie basiert auf einer etablierten SSO-Einrichtung zwischen Microsoft Entra ID und SAP Gateway (verwenden Sie SAP NetWeaver aus dem Microsoft Entra-Katalog). Unten sehen Sie ein Beispiel mit der Demobenutzerin Adele Vance. Die Benutzerzuordnung zwischen Microsoft Entra ID und sap system basiert auf dem Benutzerprinzipalnamen (UPN) als eindeutiger Benutzerbezeichner.
Die UPN-Zuordnung wird im SAP-Back-End mithilfe der Transaktion SAML2 verwaltet.
Gemäß dieser Konfiguration werden SAP-Benutzer dem jeweiligen Microsoft Entra-Benutzer zugeordnet. Unten sehen Sie eine Beispielkonfiguration aus dem SAP-Back-End mithilfe des Transaktionscodes SU01.
Weitere Informationen zur erforderlichen Konfiguration von SAP OAuth 2.0 Server mit AS ABAP finden Sie in diesem Microsoft-Tutorial zu SSO mit SAP NetWeaver unter Verwendung von OAuth.
Mithilfe der beschriebenen Azure API Management-Richtlinien kann jedes für Power Query aktivierte Microsoft-Produkt von SAP gehostete OData-Dienste aufrufen, während die Zuordnung benannter Benutzer von SAP berücksichtigt wird.
SAP OData-Zugriff über andere für Power Query aktivierte Anwendungen und Dienste
Im obigen Beispiel wird der Flow für die Excel-Desktopversion gezeigt, aber der Ansatz gilt für jedes Microsoft-Produkt, das Power Query OData unterstützt. Weitere Informationen zum OData-Connector von Power Query und den Produkten, die ihn unterstützen, finden Sie unter Dokumentation zu Power Query-Connectors. Weitere Informationen zu den Produkten, die Power Query im Allgemeinen unterstützen, finden Sie in der Dokumentation zu Power Query.
Beliebte Consumer sind Power BI, Excel für das Web, Power Apps (Dataflows) und Analysis Service.
Behandeln von SAP-Rückschreibszenarien mit Power Automate
Der beschriebene Ansatz gilt auch für Schreibschutzszenarien. Sie können beispielsweise Power Automate verwenden, um einen Geschäftspartner in SAP mithilfe von OData mit den http-aktivierten Connectors zu aktualisieren (alternativ RFCs oder BAPIs verwenden). Sehen Sie sich unten ein Beispiel für ein Power BI-Dienst-Dashboard an, das über wertbasierte Warnungen und eine Schaltfläche (hervorgehoben im Screenshot) mit Power Automate verbunden ist. Erfahren Sie mehr über das Auslösen von Flows aus Power BI-Berichten in der Power Automate-Dokumentation.
Die hervorgehobene Schaltfläche löst einen Flow aus, der die OData PATCH-Anforderung an das SAP-Gateway weiterleitet, um die Rolle des Geschäftspartners zu ändern.
Hinweis
Verwenden Sie die Azure API Management-Richtlinie für SAP, um die Authentifizierung, Aktualisierungstoken, CSRF-Token und die gesamte Zwischenspeicherung von Token außerhalb des Flows zu behandeln.
Nächste Schritte
Hier erfahren Sie, wo Sie OData mit Power Query verwenden können.
Arbeiten mit SAP-OData-APIs in Azure API Management
Konfigurieren von Azure API Management für SAP-APIs
Tutorial: Analysieren von Umsatzdaten aus Excel und einem OData-Feed
Schützen von APIs mit Application Gateway und API Management
Integrieren von API Management in ein internes virtuelles Netzwerk mit Application Gateway
Grundlegendes zu Azure Application Gateway und Web Application Firewall für SAP
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für