Introducción:

La creación de aplicaciones listas para la empresa nunca antes había sido fácil y gracias a SAP Build Apps, que proporciona una plataforma low-code sin código con excelentes características. Cuando hablamos de aplicaciones listas para la empresa, los dos primeros temas que me llaman la atención son las 2A (autenticación y autorización). Como sabemos, es muy fácil crear estas aplicaciones SAP Build Apps, pero también es importante comprender cómo podemos manejar estas 2A. En nuestro blog intentaremos comprender cómo podemos lograr la propagación de usuarios con SAP Build Apps y S/4HANA Cloud.

Günter Albrecht y yo estábamos discutiendo diferentes posibilidades sobre este tema y decidimos ir con este enfoque y probar la integración e2e.

Para entender esto mejor, consultemos el siguiente flujo en el que un usuario desea acceder a un sistema remoto en la nube a través de una aplicación en la nube alojada con la misma identificación de usuario y autenticación proporcionada por la aplicación en la nube (no el sistema remoto en la nube).

Contexto empresarial:

Construiremos una aplicación S/4HANA Cloud Extension usando SAP Build Apps, que será utilizada por un usuario comercial en el departamento de compras para verificar la lista de órdenes de compra (seamos sencillos, será solo una lista).

El usuario comercial accederá a la aplicación de extensión implementada en BTP. Puede elegir el entorno de tiempo de ejecución que es Kyma / fundición de nubes ya que ambos tiempos de ejecución admiten autenticación y autorización en BTP con una aplicación web implementada. Antes de continuar, verifiquemos nuestros requisitos previos para la creación de usuarios:

1. Usuario empresarial creado en S/4HANA Cloud
2. Usuario comercial creado en SAP BTP (la misma dirección de correo electrónico que se usó en S/4HANA Cloud)

Nota: para crear estos usuarios, necesitará derechos de administrador, para lo cual puede comunicarse con su equipo de TI en caso de que no los tenga.

Usaremos la propagación principal para lograr el flujo descrito anteriormente. Entendamos también qué es propagación principal? El usuario se propaga desde una aplicación en la nube a otro sistema remoto (nube) utilizando una configuración de destino con tipo de autenticación OAuth2SAMLBearerAssertion.

Configuración de S/4HANA Cloud para el usuario de comunicación–

Necesitamos un usuario de comunicación que no sea más que un tipo de usuario técnico que pueda usarse para la comunicación entrante en el sistema. Con esto, necesitamos crear un arreglo de comunicación con un sistema de comunicación. Para configurarlos, siga las GitHub guía y asegúrese de haber anotado los siguientes puntos al final que serán necesarios en los próximos pasos.

Puntos a tener en cuenta –

1. Credenciales de usuario
2. Cuando haya creado el acuerdo de comunicación, seleccione Detalles de OAuth 2.0. Copie y guarde localmente los campos y sus valores. Los necesitará cuando configure el destino en el cockpit de SAP BTP.

El siguiente paso es crear un usuario empresarial con el mismo ID de correo electrónico con el que accederá a la aplicación BTP. Asigne los roles comerciales respectivos, por ejemplo, para órdenes de compra, puede asignar SAP_BR_PURCHASER

Desarrollo de aplicaciones web SAP Build Apps –

No cubriremos todo el proceso de creación de aplicaciones utilizando SAP Build Apps, puede comenzar con desarrollador.sap.com o de mi blog anterior donde se creó una tarjeta simple para SAP Build Work Zone Advanced Edition. Puede implementar esta aplicación en Tiempo de ejecución de Kyma o Tiempo de ejecución de CFla elección es suya de acuerdo con las necesidades de su negocio, apoyamos a ambos.

En cualquier caso, debemos configurar un destino para consumir las API de S/4HANA Cloud para obtener información de órdenes de compra del sistema.

Consulte la siguiente captura de pantalla de un destino creado con los detalles requeridos.

Para probar la conectividad de este destino desde las aplicaciones de compilación, asegúrese de haber habilitado la autenticación BTP y agregarla en SAP Systems como se muestra a continuación:

Ahora seleccione la entidad requerida, en mi caso es A_PurchaseOrder, y pruebe (Examinar datos) si puede conectarse al sistema remoto y extraer los datos en la sección de prueba.

Una conexión exitosa muestra una lista de las órdenes de compra, lo que significa que esta conexión pudo autenticar a mi usuario con la autenticación BTP y reenviar (Afirmar) los detalles a la solicitud de API S/4, donde realmente autorizó a mi usuario contra el rol comercial asignado . También puede verificar la propagación del usuario eliminando el rol comercial de su usuario de la nube de S/4HANA.

demostración –

Agregamos la aplicación web como contenido dentro de la edición SAP Build WorkZone Advanced y tratamos de acceder a ella. También puede hacer lo mismo con SAP Build WorkZone Standard Edition (Launchpad). En esta demostración, verá que la aplicación tomó el IDP predeterminado de la subcuenta para la autenticación y propagó mi usuario al sistema remoto.

Conclusión –

Esto abre muchas oportunidades para que los clientes/socios aprovechen SAP Build Apps para crear extensiones sin preocuparse por nuestras 2 A (autenticación y autorizaciones). Por favor, hágame saber sus pensamientos sobre esto y cuál de los casos de uso cree que se ajusta mejor.

Referencias –

1. Arreglos de comunicación. – Github
2. OAuth2SAMLBearerAsertion – Enlace