Aktivera SAP-huvudspridning för aktiva OData-feeds med Power Query

Artikel
10/27/2023

Att arbeta med SAP-datauppsättningar i Microsoft Excel eller Power BI är ett vanligt krav för kunderna.

Den här artikeln beskriver de konfigurationer och komponenter som krävs för att aktivera förbrukning av SAP-datamängder via OData med Power Query. SAP-dataintegrering betraktas som "live" eftersom den kan uppdateras från klienter som Microsoft Excel eller Power BI på begäran, till skillnad från dataexporter (till exempel CSV-exporter för SAP List Viewer (ALV ). Dessa exporter är statiska av naturen och har ingen kontinuerlig relation till data ursprunget.

I artikeln betonas mappning från slutpunkt till slutpunkt mellan den kända Microsoft Entra-identiteten i Power Query och SAP-serverdelsanvändaren. Den här mekanismen kallas ofta för SAP Principal Propagation.

Fokus för den beskrivna konfigurationen ligger på Azure API Management, SAP Gateway, SAP OAuth 2.0 Server med AS ABAP- och OData-källor, men de begrepp som används gäller för alla webbaserade resurser.

Viktigt!

Obs! SAP Principal Propagation säkerställer användarmappning till den licensierade namngivna SAP-användaren. Om du har frågor om SAP-licenser kontaktar du din SAP-representant.

Översikt över Microsoft-produkter med SAP-integrering

Integreringar mellan SAP-produkter och Microsoft 365-portföljen sträcker sig från anpassade koder och partnertillägg till helt anpassade Office-produkter. Här är några exempel:

Den mekanism som beskrivs i den här artikeln använder de inbyggda OData-standardfunktionerna i Power Query och lägger vikt vid SAP-landskap som distribueras i Azure. Hantera lokala landskap med en lokalt installerad Azure API Management-gateway.

Mer information om vilka Microsoft-produkter som stöder Power Query i allmänhet finns i Power Query-dokumentationen.

Konfigurationsöverväganden

Slutanvändare kan välja mellan lokala eller webbaserade klienter (till exempel Excel eller Power BI). Klientkörningsmiljön måste beaktas för nätverkssökvägen mellan klientprogrammet och SAP-målarbetsbelastningen. Nätverksåtkomstlösningar som VPN finns inte i omfånget för appar som Excel för webben.

Azure API Management återspeglar lokala och webbaserade miljöbehov med olika distributionslägen som kan tillämpas på Azure-landskap (interna eller externa). Internal refererar till instanser som är helt begränsade till ett privat virtuellt nätverk medan external behåller offentlig åtkomst till Azure API Management. Lokala installationer kräver en hybriddistribution för att tillämpa metoden på samma sätt som med hjälp av den lokala Azure API Management-gatewayen.

Power Query kräver matchande API-tjänst-URL och Url för Microsoft Entra-program-ID. Konfigurera en anpassad domän för Azure API Management för att uppfylla kravet.

SAP Gateway måste konfigureras för att exponera önskade OData-måltjänster. Identifiera och aktivera tillgängliga tjänster via SAP-transaktionskoden /IWFND/MAINT_SERVICE. Mer information finns i SAP:s OData-konfiguration.

Anpassad domänkonfiguration för Azure API Management

Se skärmbilden nedan av en exempelkonfiguration i API Management med hjälp av en anpassad domän som heter api.custom-apim.domain.com med ett hanterat certifikat och Azure App Service-domän. Fler alternativ för domäncertifikat finns i dokumentationen för Azure API Management.

Skärmbild som visar den anpassade domänkonfigurationen i Azure API Management.

Slutför konfigurationen av din anpassade domän enligt domänkraven. Mer information finns i dokumentationen för anpassade domäner. Om du vill bevisa domännamnsägarskap och bevilja åtkomst till certifikatet lägger du till dessa DNS-poster i Din Azure App Service-domän custom-apim.domain.com enligt nedan:

Skärmbild som visar anpassad domänmappning till Azure API Management-domän.

Respektive Microsoft Entra-programregistrering för Azure API Management-klientorganisationen skulle se ut så här nedan.

Skärmbild som visar appregistreringen för Azure API Management i Microsoft Entra-ID.

Kommentar

Om anpassad domän för Azure API Management inte är ett alternativ för dig måste du använda en anpassad Power Query Connector i stället.

Principdesign för Azure API Management för Power Query

Använd den här Azure API Management-principen för ditt OData-mål-API för att stödja Power Querys autentiseringsflöde. Se nedan ett kodfragment från den principen som belyser autentiseringsmekanismen. Hitta det använda klient-ID:t för Power Query här.

<!-- 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>

Förutom stödet för inloggningsflödet för organisationskontot stöder principen omskrivning av OData-URL-svar eftersom målservern svarar med ursprungliga URL:er. Se nedan ett kodfragment från den nämnda principen:

<!-- 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>

Kommentar

Mer information om säker SAP-åtkomst från internet- och SAP-perimeternätverksdesign finns i den här guiden. Information om hur du skyddar SAP-API:er med Azure finns i den här artikeln.

SAP OData-autentisering via Power Query på Excel Desktop

Med den angivna konfigurationen blir den inbyggda autentiseringsmekanismen i Power Query tillgänglig för OData-API:er som exponeras. Lägg till en ny OData-källa i Excel-bladet via menyfliksområdet Data (Hämta data –> från andra källor –> från OData-feed). Behåll måltjänst-URL:en. I exemplet nedan används SAP Gateway-demotjänsten GWSAMPLE_BASIC. Identifiera eller aktivera den med hjälp av SAP-transaktion /IWFND/MAINT_SERVICE. Lägg slutligen till den i Azure API Management med hjälp av den officiella OData-importguiden.

Skärmbild som visar hur du identifierar OData-URL:en i Azure API Management.

Hämta bas-URL:en och infoga i målprogrammet. I exemplet nedan visas integreringsupplevelsen med Excel Desktop.

Växla inloggningsmetoden till Organisationskonto och klicka på Logga in. Ange det Microsoft Entra-konto som är mappat till den namngivna SAP-användaren på SAP Gateway med hjälp av SAP Principal Propagation. Mer information om konfigurationen finns i den här Microsoft-självstudien. Läs mer om SAP Principal Propagation från det här SAP-communityinlägget och den här videoserien.

Fortsätt att välja på vilken nivå autentiseringsinställningarna ska tillämpas av Power Query i Excel. Nedan visas en inställning som skulle gälla för alla OData-tjänster som finns i sap-målsystemet (inte bara för exempeltjänsten GWSAMPLE_BASIC).

Kommentar

Inställningen för auktoriseringsomfång på URL-nivå på skärmen nedan är oberoende av de faktiska auktoriseringarna på SAP-serverdelen. SAP Gateway är fortfarande den sista valideraren för varje begäran och associerade auktoriseringar för en mappad namngiven SAP-användare.

Skärmbild som visar inloggningsflödet i Excel för alternativet Organisationskonto.

Viktigt!

Ovanstående vägledning fokuserar på processen för att hämta en giltig autentiseringstoken från Microsoft Entra-ID via Power Query. Den här token måste bearbetas ytterligare för SAP Principal Propagation.

Konfigurera SAP-huvudspridning med Azure API Management

Använd den här andra Azure API Management-principen för SAP för att slutföra konfigurationen för SAP Principal Propagation på mellanlagret. Mer information om konfigurationen av SAP Gateway-serverdelen finns i den här Microsoft-självstudien.

Kommentar

Läs mer om SAP Principal Propagation från det här SAP-communityinlägget och den här videoserien.

Diagram som visar de Microsoft Entra-appregistreringar som ingår i den här artikeln.

Principen förlitar sig på en etablerad SSO-konfiguration mellan Microsoft Entra ID och SAP Gateway (använd SAP NetWeaver från Microsoft Entra-galleriet). Se nedan ett exempel med demoanvändaren Adele Vance. Användarmappning mellan Microsoft Entra-ID och SAP-systemet sker baserat på användarens huvudnamn (UPN) som unik användaridentifierare.

Skärmbild som visar UPN för demoanvändaren i Microsoft Entra-ID.

Skärmbild som visar SAML2-konfigurationen för SAP Gateway med UPN-anspråk.

UPN-mappningen underhålls på SAP-serverdelen med hjälp av transaktions-SAML2.

Skärmbild som visar läget för e-postmappning i SAP SAML2-transaktionen.

Enligt den här konfigurationen kommer SAP-användare att mappas till respektive Microsoft Entra-användare. Se nedan en exempelkonfiguration från SAP-serverdelen med hjälp av transaktionskoden SU01.

Skärmbild av den namngivna SAP-användaren i transaktionen SU01 med mappad e-postadress.

Mer information om den nödvändiga SAP OAuth 2.0-servern med AS ABAP-konfiguration finns i den här Microsoft-självstudien om enkel inloggning med SAP NetWeaver med OAuth.

Med hjälp av de beskrivna Azure API Management-principerna kan alla Power Query-aktiverade Microsoft-produkter anropa SAP-värdbaserade OData-tjänster, samtidigt som SAP-namngivna användarmappningar respekteras.

Skärmbild som visar OData-svaret i Excel Desktop.

SAP OData-åtkomst via andra Power Query-aktiverade program och tjänster

Ovanstående exempel visar flödet för Excel Desktop, men metoden gäller för alla Power Query OData-aktiverade Microsoft-produkter. Mer information om OData-anslutningsappen för Power Query och vilka produkter som stöder det finns i dokumentationen om Power Query Connectors. Mer information om vilka produkter som stöder Power Query i allmänhet finns i Power Query-dokumentationen.

Populära konsumenter är Power BI, Excel för webben, Power Apps (dataflöden) och Analysis Service.

Hantera SAP-tillbakaskrivningsscenarier med Power Automate

Den beskrivna metoden gäller även för tillbakaskrivningsscenarier. Du kan till exempel använda Power Automate för att uppdatera en affärspartner i SAP med hjälp av OData med http-aktiverade anslutningsappar (du kan också använda RFC:er eller BAPI:er). Se nedan ett exempel på en Power BI-tjänst instrumentpanel som är ansluten till Power Automate via värdebaserade aviseringar och en knapp (markerad på skärmbilden). Läs mer om att utlösa flöden från Power BI-rapporter i Power Automate-dokumentationen.

Skärmbild som visar den flödesaktiverade Power BI-tjänst instrumentpanelen.

Den markerade knappen utlöser ett flöde som vidarebefordrar OData PATCH-begäran till SAP Gateway för att ändra rollen som affärspartner.

Kommentar

Använd Azure API Management-principen för SAP för att hantera autentisering, uppdateringstoken, CSRF-token och övergripande cachelagring av token utanför flödet.