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 habilitar o consumo do conjunto de dados SAP via 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 questão relacionada com a licença SAP, contacte o 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.

Screenshot that shows the custom domain configuration in Azure API Management.

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:

Screenshot that shows custom domain mapping to Azure API Management domain.

O respetivo registro de aplicativo Microsoft Entra para o locatário do Azure API Management ficaria como abaixo.

Screenshot that shows the app registration for Azure API Management in Microsoft Entra ID.

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. Finalmente, adicione-o ao Gerenciamento de API do Azure usando o guia de importação oficial do OData.

Screenshot that shows how to discover the OData URL within Azure API Management.

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.

Screenshot that shows the OData configuration wizard in 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.

Screenshot that shows the login flow within Excel for the Organizational Account option.

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.

Diagram that shows the Microsoft Entra app registrations involved in this article.

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.

Screenshot that shows the UPN of the demo user in Microsoft Entra ID.

Screenshot that shows the SAML2 configuration for SAP Gateway with UPN claim.

O mapeamento UPN é mantido no back-end SAP usando a transação SAML2.

Screenshot that shows the email mapping mode in SAP SAML2 transaction.

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.

Screenshot of named SAP user in transaction SU01 with mapped email address.

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 do SAP.

Screenshot that shows the OData response in Excel Desktop.

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 habilitadospara 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.

Screenshot that shows the flow-enabled Power BI service dashboard.

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.

Screenshot that shows the flow on Power Automate requesting the business partner change on the SAP back end.

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

Automatize implantações de API com APIOps