Activer la propagation du principal SAP pour les flux OData en direct avec Power Query
L’utilisation de jeux de données SAP dans Microsoft Excel ou Power BI est une exigence courante pour les clients.
Cet article décrit les configurations et composants requis pour activer la consommation de jeux de données SAP via OData avec Power Query. L’intégration des données SAP est considérée comme active, car elle peut être actualisée à partir de clients tels que Microsoft Excel ou Power BI à la demande, contrairement aux exportations de données (comme les exportations CSV de la visionneuse de listes SAP (ALV) par exemple. Ces exportations sont statiques par nature et n’ont aucune relation continue avec l’origine des données.
L’article met l’accent sur le mappage des utilisateurs de bout en bout entre l’identité Microsoft Entra connue dans Power Query et l’utilisateur principal SAP. Ce mécanisme est souvent appelé propagation du principal SAP.
La configuration décrite se concentre sur les sources Azure Gestion des API, SAP Gateway, SAP OAuth 2.0 Server avec AS ABAP et OData, mais les concepts utilisés s’appliquent à n’importe quelle ressource web.
Important
Remarque : La propagation du principal SAP garantit le mappage utilisateur à l’utilisateur SAP nommé sous licence. Pour toute question relative à la licence SAP, contactez votre représentant SAP.
Vue d’ensemble des produits Microsoft avec l’intégration SAP
Les intégrations entre les produits SAP et le portefeuille Microsoft 365 vont du code personnalisé et des modules complémentaires partenaires aux produits Office entièrement personnalisés. Voici quelques exemples :
Macros Excel personnalisées pour interagir avec les back-ends SAP
Exporter à partir de SAP List Viewer (ALV) vers Microsoft Excel
Le mécanisme décrit dans cet article utilise les fonctionnalités OData intégrées standard de Power Query et met l’accent sur les paysages SAP déployés sur Azure. Traitez les paysages locaux avec la passerelle auto-hébergée Azure Gestion des API.
Pour plus d’informations sur les produits Microsoft qui prennent en charge Power Query en général, consultez la documentation de Power Query.
Considérations relatives à la configuration
Les utilisateurs finaux ont le choix entre les clients locaux de bureau ou web (par exemple Excel ou Power BI). L’environnement d’exécution du client doit être pris en compte pour le chemin d’accès réseau entre l’application cliente et la charge de travail SAP cible. Les solutions d’accès réseau telles que le VPN ne sont pas dans l’étendue des applications comme Excel sur le web.
Azure Gestion des API reflète les besoins de l’environnement local et web avec différents modes de déploiement qui peuvent être appliqués aux paysages Azure (internes ou externes). Internal fait référence aux instances qui sont entièrement limitées à un réseau virtuel privé, tandis que external conserve l’accès public à Azure Gestion des API. Les installations locales nécessitent un déploiement hybride pour appliquer l’approche qui utilise la passerelle auto-hébergée Azure Gestion des API.
Power Query nécessite une URL de service d’API correspondante et l’URL d’ID d’application Microsoft Entra. Configurez un domaine personnalisé pour Azure Gestion des API afin de répondre aux exigences.
La passerelle SAP doit être configurée pour exposer les services OData cibles souhaités. Découvrez et activez les services disponibles via le code de transaction SAP /IWFND/MAINT_SERVICE. Pour plus d’informations, consultez la configuration OData de SAP.
Configuration de domaine personnalisé Azure Gestion des API
Consultez la capture d’écran ci-dessous d’un exemple de configuration dans Gestion des API à l’aide d’un domaine personnalisé appelé api.custom-apim.domain.com avec un certificat managé et Azure App Service Domain. Pour plus d’options de certificat de domaine, consultez la documentation d’Azure Gestion des API.
Terminez la configuration de votre domaine personnalisé conformément aux exigences du domaine. Pour plus d’informations, consultez la documentation de domaine personnalisé. Pour prouver la propriété du nom de domaine et accorder l’accès au certificat, ajoutez ces enregistrements DNS à votre domaine custom-apim.domain.com Azure App Service comme indiqué ci-dessous :
L’inscription d’application Microsoft Entra respective pour le locataire Azure Gestion des API se présente comme suit.
Remarque
Si le domaine personnalisé pour Azure Gestion des API n’est pas envisageable pour vous, vous devez utiliser un connecteur Power Query personnalisé à la place.
Conception de stratégie Azure Gestion des API pour Power Query
Utilisez cette stratégie Azure Gestion des API pour votre API OData cible pour prendre en charge le flux d’authentification de Power Query. Consultez ci-dessous un extrait de code de cette stratégie mettant en évidence le mécanisme d’authentification. Recherchez l’ID client utilisé pour Power Query ici.
<!-- 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>
Outre la prise en charge du flux de connexion de compte d’organisation, la stratégie prend en charge la réécriture de réponse d’URL OData, car le serveur cible répond avec des URL d’origine. Consultez ci-dessous un extrait de code de la stratégie mentionnée :
<!-- 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>
Notes
Pour plus d’informations sur la sécurisation de l’accès SAP à partir de la conception du réseau de périmètre SAP et Internet, consultez ce guide. En ce qui concerne la sécurisation des API SAP avec Azure, consultez cet article.
Authentification SAP OData via Power Query sur Excel Desktop
Avec la configuration donnée, le mécanisme d’authentification intégré de Power Query est disponible pour les API OData exposées. Ajoutez une nouvelle source OData à la feuille Excel via le ruban Données (Obtenir des données > À partir d’autres sources > À partir du flux de données OData). Conservez l’URL de votre service cible. L’exemple ci-dessous utilise le service de démonstration SAP Gateway GWSAMPLE_BASIC. Découvrez ou activez-le à l’aide de la transaction SAP /IWFND/MAINT_SERVICE. Enfin, ajoutez-le à Azure Gestion des API à l’aide du guide d’importation OData officiel.
Récupérez l’URL de base et insérez-la dans votre application cible. L’exemple ci-dessous montre l’expérience d’intégration avec Excel Desktop.
Basculez la méthode de connexion vers le compte d’organisation, puis cliquez sur Se connecter. Fournissez le compte Microsoft Entra mappé à l’utilisateur SAP nommé sur la passerelle SAP à l’aide de la propagation du principal SAP. Pour plus d’informations sur la configuration, consultez ce tutoriel Microsoft. En savoir plus sur la propagation du principal SAP à partir de ce billet de la communauté SAP et de cette série de vidéos.
Continuez pour choisir le niveau auquel les paramètres d’authentification doivent être appliqués par Power Query sur Excel. L’exemple ci-dessous montre un paramètre qui s’applique à tous les services OData hébergés sur le système SAP cible (et pas seulement à l’exemple de service GWSAMPLE_BASIC).
Notes
Le paramètre d’étendue d’autorisation au niveau de l’URL dans l’écran ci-dessous est indépendant des autorisations réelles sur le serveur principal SAP. La passerelle SAP reste le validateur final de chaque demande et autorisations associées d’un utilisateur SAP nommé mappé.
Important
Les conseils ci-dessus se concentrent sur le processus d’obtention d’un jeton d’authentification valide auprès de Microsoft Entra ID via Power Query. Ce jeton doit être traité pour la propagation du principal SAP.
Configurer la propagation du principal SAP avec Azure Gestion des API
Utilisez cette deuxième stratégie d’Azure Gestion des API pour SAP afin de terminer la configuration de la propagation du principal SAP sur la couche intermédiaire. Pour plus d’informations sur la configuration du serveur principal de passerelle SAP, consultez ce tutoriel Microsoft.
Notes
En savoir plus sur la propagation du principal SAP à partir de ce billet de la communauté SAP et de cette série de vidéos.
La stratégie s’appuie sur une configuration d’authentification unique établie entre l’ID Microsoft Entra et la passerelle SAP (utilisez SAP NetWeaver à partir de la galerie Microsoft Entra). Consultez ci-dessous un exemple avec l’utilisateur de démonstration Adele Vance. Le mappage utilisateur entre Microsoft Entra ID et le système SAP se produit en fonction du nom d’utilisateur principal (UPN) comme identificateur d’utilisateur unique.
Le mappage UPN est conservé sur le serveur principal SAP à l’aide de la transaction SAML2.
Selon cette configuration , les utilisateurs SAP nommés seront mappés à l’utilisateur Microsoft Entra respectif. Consultez ci-dessous un exemple de configuration à partir du serveur principal SAP à l’aide du code de transaction SU01.
Pour plus d’informations sur le serveur SAP OAuth 2.0 requis avec la configuration AS ABAP, consultez ce tutoriel Microsoft sur l’authentification unique avec SAP NetWeaver à l’aide d’OAuth.
À l’aide des stratégies Azure Gestion des API décrites, n’importe quel produit Power Query Microsoft activé peut appeler les services OData hébergés par SAP, tout en respectant le mappage des utilisateurs nommés par SAP.
Accès SAP OData via d’autres applications et services compatibles Power Query
L’exemple ci-dessus montre le flux pour Excel Desktop, mais l’approche s’applique à n’importe quel produit Microsoft compatible Power Query OData. Pour plus d’informations sur le connecteur OData de Power Query et les produits qui le prennent en charge, consultez la documentation Power Query Connectors. Pour plus d’informations sur les produits Microsoft qui prennent en charge Power Query en général, consultez la documentation de Power Query.
Les consommateurs populaires sont Power BI, Excel sur le Web, Power Apps (flux de données) et Analysis Service.
Se familiariser avec les scénarios d’écriture différée SAP avec Power Automate
L’approche décrite s’applique également aux scénarios d’écriture différée. Par exemple, vous pouvez utiliser Power Automate pour mettre à jour un partenaire commercial dans SAP à l’aide d’OData avec les connecteurs http (vous pouvez également utiliser des RFC ou des BAPI). Consultez l’exemple de tableau de bord de service Power BI connecté à Power Automate via des alertes basées sur des valeurs avec le bouton (mis en surbrillance dans la capture d’écran) ci-dessous. En savoir plus sur le déclenchement de flux à partir de rapports Power BI dans la documentation relative à Power Automate.
Le bouton mis en surbrillance déclenche un flux qui transfère la demande OData PATCH à la passerelle SAP pour modifier le rôle de partenaire commercial.
Notes
Utilisez la stratégie pour SAP Azure API Management afin de gérer l’authentification, les jetons d’actualisation, les jetons CSRF et la mise en cache globale des jetons en dehors du flux.
Étapes suivantes
Apprenez où vous pouvez utiliser OData avec Power Query.
Utiliser les API SAP OData dans Gestion des API Azure
Configurer Azure Gestion des API pour les API SAP
Tutoriel : Analyser des données de vente à partir d’Excel et d’un flux OData
Protéger les API avec Application Gateway et Gestion des API
Intégrer le service Gestion des API dans un réseau virtuel interne avec Application Gateway
Comprendre Azure Application Gateway et Web Application Firewall pour SAP