Ativar a propagação principal do SAP para feeds OData em tempo real 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 permitir o consumo do conjunto de dados SAP através do OData com o Power Query. A integração de dados SAP é considerada "ao vivo" porque pode ser atualizada de clientes como o Microsoft Excel ou o Power BI sob demanda, ao contrário das exportações de dados (como exportações CSV do SAP List Viewer (ALV), por exemplo). Essas exportações são estáticas por natureza e não têm uma relação contínua com a origem dos dados.
O artigo enfatiza o mapeamento de usuário de ponta a ponta entre a identidade conhecida do Microsoft Entra no Power Query e o usuário de back-end SAP. Esse mecanismo é frequentemente chamado de SAP Principal Propagation.
O foco da configuração descrita está no Gerenciamento de API do Azure, SAP Gateway, SAP OAuth 2.0 Server com fontes AS ABAP e OData, mas os conceitos usados se aplicam a qualquer recurso baseado na Web.
Importante
Nota: O 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 do Microsoft 365 variam de códigos personalizados e complementos de parceiros a produtos do Office totalmente personalizados. Eis 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 em geral, consulte a documentação do Power Query.
Considerações sobre a configuração
Os utilizadores finais podem escolher entre ambiente 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. Soluções de acesso à rede, como VPN, não estão no escopo de aplicativos como o Excel para a 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 (internos ou externos). Internal refere-se a instâncias que são 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 URL de serviço de API correspondente e URL de ID de aplicativo do 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 através do código /IWFND/MAINT_SERVICEde transação SAP. Para obter mais informações, consulte Configuração OData do SAP.
Configuração de domínio personalizada do Azure API Management
Veja abaixo a captura de tela de um exemplo de configuração no Gerenciamento de API usando um domínio personalizado chamado api.custom-apim.domain.com com um certificado gerenciado e o Domínio do Serviço de Aplicativo do Azure. Para obter mais opções de certificado de domínio, consulte a documentação de 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 do 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 custom-apim.domain.com do Serviço de Aplicativo do Azure conforme abaixo:
O respetivo registro de aplicativo Microsoft Entra para o locatário do Azure API Management ficaria como abaixo.
Nota
Se o domínio personalizado para o Gerenciamento de API do Azure não for uma opção para você, você precisará usar um Power Query Connector personalizado.
Design de política de Gerenciamento de API do Azure para o Power Query
Utilize esta política de Gestão de API do Azure para a API OData de destino para suportar o fluxo de autenticação do Power Query. Veja abaixo um trecho dessa política destacando o mecanismo de autenticação. Encontre o ID de cliente utilizado 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 ao fluxo de login da Conta Organizacional, a política oferece suporte à reconfiguração da 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>
Nota
Para obter mais informações sobre o acesso seguro SAP a partir da Internet e o design da rede de perímetro SAP, consulte este guia. Em relação à proteção de APIs SAP com o Azure, consulte este artigo.
Autenticação SAP OData através do Power Query no Excel Desktop
Com a configuração fornecida, o mecanismo de autenticação incorporado do Power Query fica disponível para as APIs OData expostas. Adicione uma nova fonte OData à planilha do Excel por meio da faixa de opções Dados (Obter dados -> de outras fontes -> do feed OData). Mantenha o URL do 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 /IWFND/MAINT_SERVICESAP. Por fim, adicione-o ao Gerenciamento de API do Azure usando o guia de importação oficial do 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.
Mude o método de login para Conta organizacional e clique em Entrar . Forneça a conta do Microsoft Entra mapeada para o usuário SAP nomeado no SAP Gateway usando o SAP Principal Propagation. Para obter mais informações sobre a configuração, consulte este tutorial da Microsoft. Saiba mais sobre o SAP Principal Propagation neste post da comunidade SAP e nesta série de vídeos.
Continue a escolher em que nível as definiçõ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 exemplo GWSAMPLE_BASIC).
Nota
A configuração do escopo de autorização no nível de URL na tela abaixo é independente das autorizações reais no back-end 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
As orientações acima centram-se no processo de obtenção de um token de autenticação válido do Microsoft Entra ID através do Power Query. Esse token precisa ser processado para o SAP Principal Propagation.
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 do SAP Principal Propagation na camada intermediária. Para obter mais informações sobre a configuração do back-end do SAP Gateway, consulte este tutorial da Microsoft.
Nota
Saiba mais sobre o SAP Principal Propagation neste post da comunidade SAP e nesta 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 o SAP NetWeaver da galeria do Microsoft Entra). Veja abaixo um exemplo com a usuária demo 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 de usuário exclusivo.
O mapeamento UPN é mantido no back-end SAP usando a transação SAML2.
De acordo com essa configuração , os usuários do SAP serão mapeados para o respetivo usuário do 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 o SAP OAuth 2.0 Server necessário com configuração 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 SAP.
Acesso ao 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 quais os produtos que o suportam, consulte a documentação dos Conectores do Power Query. Para obter mais informações sobre quais os produtos que suportam o Power Query em geral, consulte a documentação do Power Query.
Os consumidores populares são o Power BI, o Excel para a Web, o Power Apps (Fluxos de Dados) e o Analysis Service.
Enfrente cenários de write-back SAP com o Power Automate
A abordagem descrita também é aplicável a cenários de write-back. Por exemplo, você pode usar o Power Automate para atualizar um parceiro de negócios no SAP usando OData com os conectores habilitados para http (alternativamente use 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 (destacado na captura de tela). Saiba mais sobre como acionar fluxos de relatórios do Power BI na documentação do Power Automatic.
O botão realçado dispara um fluxo que encaminha a solicitação OData PATCH para o SAP Gateway para alterar a função de parceiro de negócios.
Nota
Use a política de Gerenciamento de API do Azure para SAP para manipular a autenticação, atualizar tokens, tokens CSRF e cache geral de tokens fora do fluxo.
Próximos passos
Saiba onde pode utilizar o OData com o Power Query
Trabalhar com APIs do SAP OData no Gerenciamento de API do Azure
Configurar o Gerenciamento de API do Azure para APIs SAP
Tutorial: Analisar dados de vendas do Excel e um feed OData
Proteja APIs com o Application Gateway e o Gerenciamento de API
Integre o gerenciamento de API em uma rede virtual interna com o Application Gateway
Compreender o Azure Application Gateway e o Web Application Firewall for SAP