Habilitar a Propagação de Entidade de Segurança do SAP para feeds OData ao vivo com o Power Query
Trabalhar com conjuntos de dados SAP no Microsoft Excel ou Power BI é um requisito comum para os clientes.
Este artigo descreve as configurações e os componentes necessários para habilitar o consumo do conjunto de dados SAP via OData com Power Query. A integração de dados SAP é considerada "ao vivo" porque pode ser atualizada de clientes como Microsoft Excel ou Power BI sob demanda, ao contrário de exportações de dados (como SAP List Viewer (ALV) Exportações CSV), por exemplo. Essas exportações são estáticas por natureza e não têm nenhuma relação contínua com a origem dos dados.
O artigo enfatiza o mapeamento de usuários de ponta a ponta entre a identidade conhecida do Microsoft Entra no Power Query e o usuário de backend do SAP. Esse mecanismo geralmente é chamado de Propagação de Entidade de Segurança do SAP.
O foco da configuração descrita está nas fontes Azure API Management, SAP Gateway, SAP OAuth 2.0 Server com AS ABAP e OData, mas os conceitos usados se aplicam a qualquer recurso baseado na web.
Importante
Nota: SAP Principal Propagation garante o mapeamento do usuário para o usuário SAP nomeado licenciado. Para qualquer dúvida relacionada à licença SAP, entre em contato com seu representante SAP.
Visão geral dos produtos Microsoft com integração SAP
As integrações entre os produtos SAP e o portfólio Microsoft 365 variam de códigos personalizados e complementos de parceiros a produtos Office totalmente personalizados. Aqui estão alguns exemplos:
O mecanismo descrito neste artigo usa os recursos OData internos padrão do Power Query e enfatiza os cenários SAP implantados no Azure. Aborde cenários locais com o Gateway auto-hospedado do Azure API Management.
Para obter mais informações sobre quais produtos da Microsoft oferecem suporte ao Power Query no geral, consulte a documentação do Power Query.
Considerações sobre a instalação
Os usuários finais podem escolher entre a área de trabalho local ou clientes baseados na Web (por exemplo, Excel ou Power BI). O ambiente de execução do cliente precisa ser considerado para o caminho de rede entre o aplicativo cliente e a carga de trabalho SAP de destino. As soluções de acesso à rede, como VPN, não estão no escopo de aplicativos como Excel na Web.
O Gerenciamento de API do Azure reflete as necessidades do ambiente local e baseado na Web com diferentes modos de implantação que podem ser aplicados a cenários do Azure (interno ou externo). Internal refere-se a instâncias totalmente restritas a uma rede virtual privada, enquanto external mantém o acesso público ao Gerenciamento de API do Azure. As instalações locais exigem uma implantação híbrida para aplicar a abordagem, como está usando o Gateway auto-hospedado do Gerenciamento de API do Azure.
O Power Query requer a correspondência da URL do serviço de API e da URL do ID do aplicativo Microsoft Entra. Configure um domínio personalizado para o Gerenciamento de API do Azure para atender ao requisito.
O SAP Gateway precisa ser configurado para expor os serviços OData de destino desejados. Descubra e ative os serviços disponíveis por meio do código de transação SAP /IWFND/MAINT_SERVICE. Para obter mais informações, consulte a configuração de OData da SAP.
Configuração de domínio personalizado do Azure API Management
Veja abaixo a captura de tela de uma configuração de exemplo no Gerenciamento de API usando um domínio personalizado chamado api.custom-apim.domain.com com um certificado gerenciado e Domínio do serviço de aplicativo do Azure. Para obter mais opções de certificado de domínio, consulte a documentação do Gerenciamento de API do Azure.
Conclua a configuração do seu domínio personalizado de acordo com os requisitos do domínio. Para obter mais informações, consulte a documentação de domínio personalizado. Para provar a propriedade do nome de domínio e conceder acesso ao certificado, adicione esses registros DNS ao seu Domínio do Serviço de Aplicativo do Azure custom-apim.domain.com conforme abaixo:
O respectivo registro do aplicativo Microsoft Entra para o locatário do Azure API Management ficaria assim.
Observação
Se o domínio personalizado para o Gerenciamento de API do Azure não for uma opção para você, você precisará usar um conector do Power Query personalizado.
Design de política de gerenciamento de API do Azure para Power Query
Use esta política de gerenciamento de API do Azure para sua API OData de destino para dar suporte ao fluxo de autenticação do Power Query. Veja abaixo um trecho dessa política destacando o mecanismo de autenticação. Encontre o ID do cliente usado para o Power Query aqui.
<!-- 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>
Além do suporte do fluxo de login da conta organizacional, a política oferece suporte à reescrita de resposta de URL OData porque o servidor de destino responde com URLs originais. Veja abaixo um trecho da política mencionada:
<!-- 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>
Observação
Para obter mais informações sobre o acesso SAP seguro da Internet e o projeto de rede de perímetro SAP, consulte este guia. Sobre a proteção de APIs SAP com o Azure, consulte este artigo.
Autenticação SAP OData via Power Query no Excel Desktop
Com a configuração fornecida, o mecanismo de autenticação interno do Power Query fica disponível para as APIs OData expostas. Adicione uma nova fonte OData à planilha do Excel por meio da faixa de dados (Get Data -> From Other Sources -> From OData Feed). Mantenha sua URL de serviço de destino. O exemplo abaixo usa o serviço de demonstração do SAP Gateway GWSAMPLE_BASIC. Descubra ou ative-o usando a transação SAP /IWFND/MAINT_SERVICE. Por fim, adicione-o ao Gerenciamento de API do Azure usando o guia oficial de importação OData.
Recupere a URL Base e insira em seu aplicativo de destino. O exemplo abaixo mostra a experiência de integração com o Excel Desktop.
Alterne o método de login para Conta organizacional e clique em Fazer login. Forneça a conta do Microsoft Entra que é mapeada para o usuário SAP nomeado no SAP Gateway usando a Propagação Principal do SAP. Para obter mais informações sobre a configuração, consulte este tutorial da Microsoft. Saiba mais sobre SAP Principal Propagation neste post da comunidade SAP e esta série de vídeos.
Continue a escolher em qual nível as configurações de autenticação devem ser aplicadas pelo Power Query no Excel. O exemplo abaixo mostra uma configuração que se aplicaria a todos os serviços OData hospedados no sistema SAP de destino (não apenas ao serviço de amostra GWSAMPLE_BASIC).
Observação
A configuração do escopo de autorização no nível de URL na tela abaixo é independente das autorizações reais no backend SAP. O SAP Gateway continua sendo o validador final de cada solicitação e autorizações associadas de um usuário SAP nomeado mapeado.
Importante
A orientação acima se concentra no processo de obtenção de um token de autenticação válido do Microsoft Entra ID via Power Query. Esse token precisa ser processado para Propagação Principal SAP.
Configurar a propagação principal do SAP com o gerenciamento de API do Azure
Use esta segunda política de Gerenciamento de API do Azure para SAP para concluir a configuração da Propagação Principal SAP na camada intermediária. Para obter mais informações sobre a configuração do back-end do SAP Gateway, consulte este tutorial da Microsoft.
Observação
Saiba mais sobre SAP Principal Propagation neste post da comunidade SAP e esta série de vídeos.
A política depende de uma configuração de SSO estabelecida entre o Microsoft Entra ID e o SAP Gateway (use SAP NetWeaver da galeria do Microsoft Entra). Veja abaixo um exemplo com a usuária de demonstração Adele Vance. O mapeamento de usuários entre o Microsoft Entra ID e o sistema SAP acontece com base no nome principal do usuário (UPN) como identificador exclusivo do usuário.
O mapeamento UPN é mantido no back-end SAP usando a transação SAML2.
De acordo com essa configuração, usuários SAP nomeados serão mapeados para o respectivo usuário Microsoft Entra. Veja abaixo um exemplo de configuração do back-end SAP usando o código de transação SU01.
Para obter mais informações sobre a configuração necessária do SAP OAuth 2.0 Server com AS ABAP, consulte este tutorial da Microsoft sobre SSO com SAP NetWeaver usando OAuth.
Usando as políticas de gerenciamento de API do Azure descritas, qualquer produto Microsoft habilitado para Power Query pode chamar serviços OData hospedados pela SAP, respeitando o mapeamento de usuário nomeado pela SAP.
Acesso SAP OData por meio de outros aplicativos e serviços habilitados para Power Query
O exemplo acima mostra o fluxo para o Excel Desktop, mas a abordagem é aplicável a qualquer produto Microsoft habilitado para Power Query OData. Para obter mais informações sobre o conector OData do Power Query e sobre quais produtos dão suporte a ele, consulte a documentação do Power Query Connectors. Para obter mais informações sobre quais produtos oferecem suporte ao Power Query no geral, consulte a documentação do Power Query.
Os consumidores populares são Power BI, Excel para a Web, Power Apps (Fluxos de dados) e Analysis Service.
Abordar cenários de write-back do SAP com o Power Automate
A abordagem descrita também é aplicável a cenários de write-back. Por exemplo, use o Power Automate para atualizar um parceiro de negócios no SAP usando o OData com os conectores habilitados para http (como alternativa, usar RFCs ou BAPIs). Veja abaixo um exemplo de um painel de serviço do Power BI conectado ao Power Automate por meio de alertas baseados em valor e um botão (realçado na captura de tela). Saiba mais sobre como disparar fluxos de relatórios do Power BI na documentação do Power Automate.
O botão realçado dispara um fluxo que encaminha a solicitação PATCH do OData para o Gateway do SAP para alterar a função de parceiro de negócios.
Observação
Use a política de Gerenciamento de API do Azure para SAP para manipular a autenticação, atualizar tokens, tokens de CSRF e o cache geral de tokens fora do fluxo.
Próximas etapas
Saiba de onde você pode usar OData com o Power Query
Trabalhar com APIs SAP OData no Gerenciamento de API do Azure
Configurar o Gerenciamento de API do Azure para APIs SAP
Tutorial: Analisar dados de vendas no Excel e um feed OData
Proteger APIs com o Gateway de Aplicativo e o Gerenciamento de API
Como integrar o Gerenciamento de API em uma rede virtual interna com o gateway de aplicativo
Entender o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web para SAP