Abilitare la propagazione dell'entità SAP per i feed OData attivi con Power Query

Articolo
10/27/2023

L'uso di set di dati SAP in Microsoft Excel o Power BI è un requisito comune per i clienti.

Questo articolo descrive le configurazioni e i componenti necessari per abilitare l'utilizzo del set di dati SAP tramite OData con Power Query. L'integrazione dei dati SAP è considerata "dinamica" perché può essere aggiornata dai client, ad esempio Microsoft Excel o Power BI su richiesta, a differenza delle esportazioni di dati (ad esempio esportazioni CSV di SAP List Viewer (ALV) per esempio. Tali esportazioni sono statiche per natura e non hanno alcuna relazione continua con l'origine dati.

L'articolo pone l'accento sul mapping degli utenti end-to-end tra l'identità nota di Microsoft Entra in Power Query e l'utente back-end SAP. Questo meccanismo viene spesso definito propagazione dell'entità SAP.

L'obiettivo della configurazione descritta riguarda le origini Azure Gestione API, SAP Gateway, SAP OAuth 2.0 Server con AS ABAP e OData, ma i concetti usati si applicano a qualsiasi risorsa basata sul Web.

Importante

Nota: la propagazione dell'entità SAP garantisce il mapping utente all'utente con licenza denominato SAP. Per eventuali domande correlate alle licenze SAP, contattare il rappresentante SAP.

Panoramica dei prodotti Microsoft con l'integrazione SAP

Le integrazioni tra prodotti SAP e il portfolio di Microsoft 365 variano da codici personalizzati e componenti aggiuntivi partner a prodotti Office completamente personalizzati. Ecco alcuni esempi:

Il meccanismo descritto in questo articolo usa le funzionalità OData predefinite standard di Power Query e pone l'accento sugli scenari SAP distribuiti in Azure. Gestire gli scenari locali con il gateway self-hosted di Azure Gestione API.

Per altre informazioni sui prodotti Microsoft che supportano Power Query in generale, vedere la documentazione di Power Query.

Considerazioni sull'installazione

Gli utenti finali hanno una scelta tra client desktop locali o basati sul Web (ad esempio Excel o Power BI). L'ambiente di esecuzione client deve essere considerato per il percorso di rete tra l'applicazione client e il carico di lavoro SAP di destinazione. Le soluzioni di accesso alla rete, ad esempio VPN, non rientrano nell'ambito delle app come Excel per il web.

Azure Gestione API riflette le esigenze dell'ambiente locale e basato sul Web con diverse modalità di distribuzione che possono essere applicate agli scenari di Azure (interni o esterni). Internalfa riferimento a istanze completamente limitate a una rete virtuale privata, mentre external mantiene l'accesso pubblico ad Azure Gestione API. Le installazioni locali richiedono una distribuzione ibrida per applicare l'approccio così come avviee con Azure Gestione API gateway self-hosted.

Power Query richiede l'URL del servizio API corrispondente e l'URL dell'ID applicazione Microsoft Entra. Configurare un dominio personalizzato per Azure Gestione API per soddisfare i requisiti.

Sap Gateway deve essere configurato per esporre i servizi OData di destinazione desiderati. Individuare e attivare i servizi disponibili tramite il codice /IWFND/MAINT_SERVICEdi transazione SAP . Per altre informazioni, vedere Configurazione OData di SAP.

Azure Gestione API configurazione del dominio personalizzato

Vedere sotto lo screenshot di una configurazione di esempio in Gestione API usando un dominio personalizzato denominato api.custom-apim.domain.com con un certificato gestito e app Azure dominio del servizio. Per altre opzioni di certificato di dominio, vedere la documentazione di Azure Gestione API.

Screenshot che mostra la configurazione del dominio personalizzato in Azure Gestione API.

Completare la configurazione del dominio personalizzato in base ai requisiti del dominio. Per altre informazioni, vedere la documentazione del dominio personalizzato. Per dimostrare la proprietà del nome di dominio e concedere l'accesso al certificato, aggiungere tali record DNS al dominio custom-apim.domain.com del servizio di app Azure come indicato di seguito:

Screenshot che mostra il mapping del dominio personalizzato al dominio di Azure Gestione API.

La rispettiva registrazione dell'applicazione Microsoft Entra per il tenant di Azure Gestione API sarà simile alla seguente.

Screenshot che mostra la registrazione dell'app per Azure Gestione API in Microsoft Entra ID.

Nota

Se il dominio personalizzato per Azure Gestione API non è un'opzione appropriata, è invece necessario usare un connettore Power Query personalizzato.

Progettazione dei criteri di Azure Gestione API per Power Query

Usare questo criterio di Azure Gestione API per l'API OData di destinazione per supportare il flusso di autenticazione di Power Query. Vedere di seguito un frammento di codice del criterio che evidenzia il meccanismo di autenticazione. Trovare l'ID client usato per Power Query qui.

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

Oltre al supporto del flusso di accesso dell'account aziendale, i criteri supportano la riscrittura della risposta url OData perché il server di destinazione risponde con URL originali. Vedere di seguito un frammento di codice del criterio indicato:

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

Nota

Per altre informazioni sulla protezione dell'accesso SAP dalla progettazione di rete perimetrale Internet e SAP, vedere questa guida. Per quanto riguarda la protezione delle API SAP con Azure, vedere questo articolo.

Autenticazione di SAP OData tramite Power Query in Excel Desktop

Con la configurazione specificata, il meccanismo di autenticazione predefinito di Power Query diventa disponibile per le API OData esposte. Aggiungere una nuova origine OData al foglio di Excel tramite la barra multifunzione Dati (Recupera dati -> Da altre origini -> Da feed OData). Mantenere l'URL del servizio di destinazione. Nell'esempio seguente viene usato il servizio demo sap Gateway GWSAMPLE_BASIC. Individuarlo o attivarlo usando la transazione /IWFND/MAINT_SERVICESAP . Infine, aggiungerlo ad Azure Gestione API usando la guida ufficiale all'importazione OData.

Screenshot che mostra come individuare l'URL OData all'interno di Azure Gestione API.

Recuperare l'URL di base e inserire nell'applicazione di destinazione. L'esempio seguente mostra l'esperienza di integrazione con Excel Desktop.

Impostare il metodo di accesso su Account aziendale e fare clic su Accedi. Specificare l'account Microsoft Entra mappato all'utente SAP denominato nel gateway SAP usando la propagazione dell'entità SAP. Per altre informazioni sulla configurazione, vedere questa esercitazione microsoft. Altre informazioni sulla propagazione delle entità SAP da questo post della community SAP e questa serie di video.

Continuare a scegliere a quale livello devono essere applicate le impostazioni di autenticazione da Power Query in Excel. L'esempio seguente mostra un'impostazione che si applica a tutti i servizi OData ospitati nel sistema SAP di destinazione (non solo al servizio di esempio GWSAMPLE_BASIC).

Nota

L'impostazione dell'ambito di autorizzazione a livello di URL nella schermata sottostante è indipendente dalle autorizzazioni effettive nel back-end SAP. SAP Gateway rimane il validator finale di ogni richiesta e le autorizzazioni associate di un utente SAP mappato.

Screenshot che mostra il flusso di accesso in Excel per l'opzione Account aziendale.

Importante

Il materiale sussidiario precedente è incentrato sul processo di recupero di un token di autenticazione valido da Microsoft Entra ID tramite Power Query. Questo token deve essere ulteriormente elaborato per la propagazione dell'entità SAP.

Configurare la propagazione delle entità SAP con Azure Gestione API

Usare questo secondo criterio di Azure Gestione API per SAP per completare la configurazione per la propagazione delle entità SAP nel livello intermedio. Per altre informazioni sulla configurazione del back-end del gateway SAP, vedere questa esercitazione Microsoft.

Nota

Altre informazioni sulla propagazione delle entità SAP da questo post della community SAP e questa serie di video.

Diagramma che mostra le registrazioni dell'app Microsoft Entra coinvolte in questo articolo.

Il criterio si basa su una configurazione SSO stabilita tra Microsoft Entra ID e SAP Gateway (usare SAP NetWeaver dalla raccolta di Microsoft Entra). Vedere di seguito un esempio con l'utente demo Adele Vance. Il mapping utente tra Microsoft Entra ID e il sistema SAP avviene in base al nome dell'entità utente (UPN) come identificatore utente univoco.

Screenshot che mostra l'UPN dell'utente demo in Microsoft Entra ID.

Screenshot che mostra la configurazione SAML2 per SAP Gateway con attestazione UPN.

Il mapping UPN viene mantenuto nel back-end SAP usando la transazione SAML2.

Screenshot che mostra la modalità di mapping della posta elettronica nella transazione SAP SAML2.

In base a questa configurazione denominata utenti SAP verrà eseguito il mapping al rispettivo utente di Microsoft Entra. Vedere di seguito una configurazione di esempio dal back-end SAP usando il codice di transazione SU01.

Screenshot dell'utente SAP denominato nella transazione SU01 con l'indirizzo di posta elettronica mappato.

Per altre informazioni sulla configurazione di SAP OAuth 2.0 server con AS ABAP , vedere questa esercitazione Microsoft sull'accesso SSO con SAP NetWeaver con OAuth.

Usando i criteri descritti di Azure Gestione API qualsiasi prodotto Microsoft abilitato per Power Query può chiamare i servizi OData ospitati da SAP, rispettando al tempo stesso il mapping utente denominato SAP.

Screenshot che mostra la risposta OData in Excel Desktop.

Accesso SAP OData tramite altre applicazioni e servizi abilitati per Power Query

Nell'esempio precedente viene illustrato il flusso per Excel Desktop, ma l'approccio è applicabile a qualsiasi prodotto Microsoft abilitato per Power Query OData. Per altre informazioni sul connettore OData di Power Query e sui prodotti che lo supportano, vedere la documentazione di Power Query Connectors. Per altre informazioni sui prodotti che supportano Power Query in generale, vedere la documentazione di Power Query.

I consumer più diffusi sono Power BI, Excel per il web, Power Apps (flussi di dati) e Analysis Service.

Affrontare scenari di writeback SAP con Power Automate

L'approccio descritto è applicabile anche agli scenari di writeback. Ad esempio, è possibile usare Power Automate per aggiornare un partner aziendale in SAP usando OData con i connettori abilitati per HTTP (in alternativa usare le RFC o le BAPI). Vedere di seguito un esempio di dashboard servizio Power BI connesso a Power Automate tramite avvisi basati su valori e un pulsante (evidenziato nello screenshot). Altre informazioni sull'attivazione dei flussi dai report di Power BI sono disponibili nella documentazione di Power Automate.

Screenshot che mostra il dashboard di servizio Power BI abilitato per il flusso.

Il pulsante evidenziato attiva un flusso che inoltra la richiesta PATCH OData al gateway SAP per modificare il ruolo del partner aziendale.

Nota

Usare i criteri di Azure Gestione API per SAP per gestire l'autenticazione, aggiornare i token, i token CSRF e la memorizzazione nella cache complessiva dei token all'esterno del flusso.