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

Artículo
10/27/2023

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 que la dirección URL del servicio de API y la dirección URL del identificador de aplicación de Microsoft Entra coincidan. 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.

Captura de pantalla que muestra la configuración de dominio personalizada en 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:

Captura de pantalla en la que se muestra la asignación de dominio personalizada al dominio de Azure API Management.

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

Recorte de pantalla en el que se muestra el registro de aplicaciones para Azure API Management en 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.

Captura de pantalla en la que se muestra cómo detectar la dirección URL de OData en 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.

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 asignada al usuario de SAP con nombre en la puerta de enlace de SAP mediante la propagación de entidades 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.

Captura de pantalla en la que se muestra el flujo de inicio de sesión en Excel para la opción Cuenta de organización.

Importante

La guía anterior se centra en el proceso de obtención de 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.

Diagrama que muestra los registros de aplicaciones de Microsoft Entra implicados en este artículo.

La directiva se basa en una configuración de inicio de sesión único establecida entre Microsoft Entra y la puerta de enlace de SAP (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 de SAP se produce en función del nombre principal de usuario (UPN) como identificador de usuario único.

Recorte de pantalla que muestra el UPN del usuario de demostración en Microsoft Entra ID.

Captura de pantalla en la que se muestra la configuración de SAML2 para la puerta de enlace de SAP con la notificación del UPN.

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

Captura de pantalla en la que se muestra el modo de asignación de correo electrónico en la transacción de SAP SAML2.

Según esta configuración, los usuarios de SAP con nombre 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.

Captura de pantalla del usuario de SAP con nombre en la transacción SU01 con la dirección de correo electrónico asignada.

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.

Captura de pantalla en la que se muestra la respuesta de OData en 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.

Captura de pantalla en la que se muestra el panel del servicio Power BI habilitado para flujos.

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.