Compartir a través de


Habilitación de la propagación de entidades de seguridad de SAP para fuentes de OData activas con Power Query

Trabajar con conjuntos de datos de SAP en Microsoft Excel o Power BI es un requisito común para los clientes.

En este artículo se describen las configuraciones y los componentes necesarios para habilitar el consumo de conjuntos de datos de SAP a través de OData con Power Query. La integración de datos de SAP se considera "activa" porque se puede actualizar desde clientes como Microsoft Excel o Power BI a petición, a diferencia de las exportaciones de datos (como las exportaciones CSV del Visor de listas de SAP (ALV)), por ejemplo. Esas exportaciones son estáticas por naturaleza y no tienen ninguna relación continua con el origen de datos.

En el artículo se pone énfasis en la asignación de usuarios de un extremo a otro entre la identidad conocida de Microsoft Entra en Power Query y el usuario back-end de SAP. Este mecanismo se conoce a menudo como propagación de entidades de seguridad de SAP.

El foco de la configuración descrita está en los orígenes de Azure API Management, la puerta de enlace SAP, el servidor SAP OAuth 2.0 con AS ABAP y OData, pero los conceptos usados se aplican a cualquier recurso basado en web.

Importante

Nota: La propagación de entidades de seguridad de SAP garantiza la asignación de usuarios al usuario de SAP con licencia. Para cualquier pregunta relacionada con las licencias de SAP, póngase en contacto con su representante de SAP.

Introducción a los productos de Microsoft con la integración de SAP

Las integraciones entre productos de SAP y la cartera de Microsoft 365 van desde códigos personalizados y complementos de asociados hasta productos de Office totalmente personalizados. Estos son algunos ejemplos:

El mecanismo descrito en este artículo usa las funcionalidades estándar de OData integradas de Power Query y pone énfasis en los paisajes de SAP implementados en Azure. Direccione los paisajes locales con la puerta de enlace autohospedada de Azure API Management.

Para obtener más información sobre qué productos de Microsoft admiten Power Query en general, consulte la documentación de Power Query.

Consideraciones sobre la configuración

Los usuarios finales tienen una opción entre los clientes de escritorio local o basados en web (por ejemplo, Excel o Power BI). El entorno de ejecución de cliente debe tenerse en cuenta para la ruta de acceso de red entre la aplicación cliente y la carga de trabajo de SAP de destino. Las soluciones de acceso a la red, como VPN, no están en el ámbito de las aplicaciones como Excel para la web.

Azure API Management refleja las necesidades del entorno local y basado en web con diferentes modos de implementación que se pueden aplicar a los paisajes de Azure (internos o externos). Internal hace referencia a instancias que están totalmente restringidas a una red virtual privada, mientras que external conserva el acceso público a Azure API Management. Las instalaciones locales requieren una implementación híbrida para aplicar el enfoque tal y como lo usa la puerta de enlace autohospedada de Azure API Management.

Power Query requiere la coincidencia de la dirección URL del servicio de API y la dirección URL del identificador de aplicación de Microsoft Entra. Configure un dominio personalizado para Azure API Management para cumplir los requisitos.

La puerta de enlace de SAP debe configurarse para exponer los servicios de OData de destino deseados. Detecte y active los servicios disponibles a través del código de transacción de SAP /IWFND/MAINT_SERVICE. Para más información, consulte Configuración de OData de SAP.

Configuración de dominio personalizado de Azure API Management

Vea la captura de pantalla siguiente de una configuración de ejemplo en API Management mediante un dominio personalizado denominado api.custom-apim.domain.com con un certificado administrado y un dominio de Azure App Service. Para más opciones de certificado de dominio, consulte la documentación de Azure API Management.

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

Complete la configuración del dominio personalizado según los requisitos de dominio. Para más información, consulte la documentación de un dominio personalizado. Para demostrar la propiedad del nombre de dominio y conceder acceso al certificado, agregue esos registros DNS al dominio de Azure App Service custom-apim.domain.com como se indica a continuación:

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

El registro de aplicación de Microsoft Entra correspondiente para el inquilino de Azure API Management tendría el aspecto siguiente.

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

Nota:

Si el dominio personalizado para Azure API Management no es una opción, debe usar un conector de Power Query personalizado en su lugar.

Diseño de directivas de Azure API Management para Power Query

Use esta directiva de Azure API Management para la API de OData de destino para admitir el flujo de autenticación de Power Query. Vea a continuación un fragmento de código de esa directiva que resalta el mecanismo de autenticación. Busque el identificador de cliente usado para Power Query aquí.

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

Además de la compatibilidad con el flujo de inicio de sesión de la cuenta de organización, la directiva admite la reescritura de respuesta de la dirección URL de OData porque el servidor de destino responde con direcciones URL originales. Vea a continuación un fragmento de código de la directiva 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 más información sobre el acceso seguro de SAP desde Internet y el diseño de red perimetral de SAP, consulte esta guía. Con respecto a la protección de las API de SAP con Azure, consulte este artículo.

Autenticación de OData de SAP a través de Power Query en Excel para escritorio

Con la configuración especificada, el mecanismo de autenticación integrado de Power Query está disponible para las API de OData expuestas. Agregue un nuevo origen de OData a la hoja de Excel a través de la cinta de opciones Datos (Obtener datos -> De otros orígenes -> Desde fuente de OData). Mantenga la dirección URL del servicio de destino. En el ejemplo siguiente se usa el servicio de demostración de puerta de enlace de SAP GWSAMPLE_BASIC. Detéctelo o actívelo mediante la transacción de SAP /IWFND/MAINT_SERVICE. Por último, agréguelo a Azure API Management mediante la guía oficial de importación de OData.

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

Recupere la dirección URL base e insértela en la aplicación de destino. En el ejemplo siguiente se muestra la experiencia de integración con Excel para escritorio.

Screenshot that shows the OData configuration wizard in Excel Desktop.

Cambie el método de inicio de sesión a cuenta organizativa y haga clic en Iniciar sesión. Proporcione la cuenta de Microsoft Entra que se asigna al usuario de SAP con nombre en la puerta de enlace de SAP mediante la propagación de la entidad de seguridad de SAP. Para obtener más información sobre la configuración, consulte este tutorial de Microsoft. Obtenga más información sobre la propagación de entidades de seguridad de SAP en esta publicación de la comunidad de SAP y esta serie de vídeos.

Continúe eligiendo en qué nivel Power Query debe aplicar la configuración de autenticación en Excel. En el ejemplo siguiente se muestra una configuración que se aplicaría a todos los servicios de OData hospedados en el sistema SAP de destino (no solo al servicio de ejemplo GWSAMPLE_BASIC).

Nota:

La configuración del ámbito de autorización en el nivel de la dirección URL en la pantalla siguiente es independiente de las autorizaciones reales en el back-end de SAP. La puerta de enlace de SAP sigue siendo el validador final de cada solicitud y las autorizaciones asociadas de un usuario de SAP con nombre asignado.

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

Importante

La guía anterior se centra en el proceso de obtener un token de autenticación válido de Microsoft Entra ID a través de Power Query. Este token debe procesarse aún más para la propagación de entidades de seguridad de SAP.

Configuración de la propagación de entidades de seguridad de SAP con Azure API Management

Use esta segunda directiva de Azure API Management para SAP para completar la configuración de propagación de entidades de seguridad de SAP en la capa central. Para obtener más información sobre la configuración del back-end de la puerta de enlace de SAP, consulte este tutorial de Microsoft.

Nota:

Obtenga más información sobre la propagación de entidades de seguridad de SAP en esta publicación de la comunidad de SAP y esta serie de vídeos.

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

La directiva se basa en una configuración de SSO establecida entre Microsoft Entra ID y SAP Gateway (use SAP NetWeaver desde la galería de Microsoft Entra). Vea a continuación un ejemplo con el usuario de demostración Adele Vance. La asignación de usuarios entre microsoft Entra ID y el sistema SAP se basa en el nombre principal de usuario (UPN) como identificador de usuario único.

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.

La asignación del UPN se mantiene en el back-end de SAP mediante la transacción SAML2.

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

De acuerdo con esta configuración , los usuarios de SAP se asignarán al usuario de Microsoft Entra correspondiente. Vea a continuación una configuración de ejemplo del back-end de SAP mediante el código de transacción SU01.

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

Para obtener más información sobre el servidor SAP OAuth 2.0 necesario con la configuración de AS ABAP, consulte este tutorial de Microsoft sobre el inicio de sesión único con SAP NetWeaver mediante OAuth.

Con las directivas de Azure API Management descritas, cualquier producto de Microsoft habilitado para Power Query puede llamar a los servicios de OData hospedados de SAP, al tiempo que respeta la asignación de usuarios con nombre de SAP.

Screenshot that shows the OData response in Excel Desktop.

Acceso a OData de SAP a través de otras aplicaciones y servicios habilitados para Power Query

En el ejemplo anterior se muestra el flujo de Excel para escritorio, pero el enfoque es aplicable a cualquier producto de Microsoft habilitado para OData de Power Query. Para obtener más información sobre el conector de OData de Power Query y qué productos lo admiten, consulte la documentación de conectores de Power Query. Para obtener más información sobre qué productos admiten Power Query en general, consulte la documentación de Power Query.

Los consumidores más conocidos son Power BI, Excel para la Web, Power Apps (flujos de datos) y Analysis Service.

Abordar escenarios de escritura diferida de SAP con Power Automate

El enfoque descrito también se aplica a escenarios de escritura diferida. Por ejemplo, puede usar Power Automate para actualizar un socio de negocio en SAP mediante OData con los conectores habilitados para HTTP (alternativamente, use RFC o BAPI). A continuación, consulte un ejemplo de un panel del servicio Power BI que está conectado a Power Automate a través de alertas basadas en valores y un botón (resaltado en la captura de pantalla). Obtenga más información sobre cómo desencadenar flujos de informes de Power BI en la documentación de Power Automate.

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

El botón resaltado desencadena un flujo que reenvía la solicitud PATCH de OData a la puerta de enlace de SAP para cambiar el rol de socio de negocio.

Nota

Use la directiva de Azure API Management para SAP a fin de controlar la autenticación, los tokens de actualización, los tokens CSRF y el almacenamiento en caché general de tokens fuera del flujo.

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

Pasos siguientes

Obtenga información sobre dónde puede usar OData con Power Query

Trabajar con las API de OData de SAP en Azure API Management

Configuración de Azure API Management para las API de SAP

Tutorial: Análisis de datos de ventas de Excel y una fuente de OData

Protección de las API con Application Gateway y API Management

Integración de API Management en una red virtual interna con Application Gateway

Comprender Azure Application Gateway y Web Application Firewall para SAP

Automatizar implementaciones de API con APIOps