
Autores: Amina MABROUK, María Trinidad MARTÍNEZ GEA, Eduardo Neveux, Krisztian Papai, Quinto Smith.
Este blog es parte del Serie de blogs de SA Repair hemos publicado un caso de uso comercial sobre el tema «Transforme sus procesos comerciales con SAP Signavio y SAP Build». el primer blog SA Repair: Transforme sus procesos comerciales con SAP Signavio y SAP Build introdujo la importancia de la Automatización de Procesos; hablamos de cómo Analizar un proceso con SAP Signavio en nuestro segundo blog Reparación de SA: analice y explore con SAP Signavio y en nuestro tercer blog Reparación de SA: Automatice con SAP Build Process Automation nos enfocamos en cómo automatizar algunos de los procesos manuales. en este blog Reparación de SA: activación con SAP BTP Graph y Build Apps nos enfocaremos en la implementación de la aplicación que consumirán los usuarios para desencadenar el proceso.
Para desarrollar nuestra aplicación, utilizaremos SAP Build Apps. Pero antes de explorar SAP Build Apps, permítanme brindar algunos detalles sobre SAP BTP Graph Service.
Como ha visto en la descripción del caso de uso, nos conectaremos a dos sistemas back-end diferentes para recuperar y actualizar los datos requeridos por nuestra solución:
Como cada sistema back-end tiene su propio conjunto de API, podemos conectarnos directamente a cada sistema y consumir sus API desde nuestra aplicación. Para simplificar el uso y la configuración de las APIs de los diferentes sistemas utilizaremos un Servicio SAP BTP llamado Graph.
Grafico es un servicio de SAP Business Technology Platform (BTP) que ofrece una API unificada para la empresa inteligente y, como tal, brinda a los desarrolladores una vista única conectada y unificada de todos sus datos comerciales. Graph consolida los modelos de datos de fuentes de datos como SAP S/4HANA, SAP Sales Cloud y SAP SuccessFactors en un modelo de datos unificado y conectado, que representa todos los datos en un panorama. Las API de oData personalizadas también se pueden configurar para acceder a través de Graph.
Puede configurar su propio Business Data Graph en su subcuenta, donde se puede establecer la identidad, la confianza y la conectividad entre sus propias aplicaciones, extensiones e integraciones y su entorno. Una ventaja de Graph es que los administradores de TI se encargan de Business Data Graph, así como de la configuración del destino, mientras que los desarrolladores solo consumen las entidades a través de Graph, independientemente de con qué inquilinos específicos estén trabajando.
En nuestra arquitectura de casos de uso, la aplicación SAP Build Apps consume las entidades SAP S/4 HANA Cloud y SAP Success Factors a través de Graph. La identidad del usuario se propaga desde SAP Build Apps a Graph, y Graph distribuirá la identidad a cada inquilino de back-end específico para verificar la autenticación y autorización del usuario final.
Los desarrolladores solo se conectan al destino de Graph configurado por los administradores de TI sin tener que preocuparse por los cambios en la configuración de los servidores backend específicos.
Como se presentó anteriormente, la siguiente figura muestra cómo Graph accede a las API configuradas en los sistemas back-end a través del servicio de destino.
La siguiente imagen muestra un fragmento de nuestro archivo de configuración de Graph donde los destinos consumidos por nuestro Business Data Graph se enumeran como Fuentes de datos:
Un conjunto de Políticas de ubicación permite la selección de la fuente de datos principal en los casos en que el gráfico expone más de un arrendatario del mismo tipo, ya sea para espacios de nombres completos como, por ejemplo, «sap.graph» o solo para entidades específicas como, por ejemplo, «sap .graph.Product” que se muestra en la siguiente imagen:
Ahora que entendemos cómo Business Data Graph puede ayudarnos a configurar el acceso a nuestros sistemas back-end, veamos cómo podemos consumir Graph desde nuestra aplicación de interfaz de usuario creada con SAP Build Apps.
Para construir la interfaz de usuario final, usaremos SAP Build Apps.
Aplicaciones de compilación de SAP es una solución profesional de desarrollo de aplicaciones que proporciona un entorno de desarrollo intuitivo sin código para permitir a los usuarios comerciales y desarrolladores crear aplicaciones de forma rápida y visual.
Las capacidades clave de SAP Build Apps son:
En nuestro caso de uso, los empleados utilizan la aplicación SAP Build Apps en dos pasos diferentes de nuestro flujo:
Comenzaremos configurando el método de autenticación de nuestra aplicación. Como queremos que nuestros usuarios finales sean autenticados por BTP, seleccionaremos el método de autenticación BTP. Con la autenticación BTP, los usuarios pueden consumir directamente los destinos y servicios BTP requeridos por nuestra aplicación sin necesidad de una autenticación adicional.
Para acceder a los datos de los diferentes inquilinos, SAP Build Apps consume directamente entidades de Graph configurando un destino BTP que apunta a nuestra instancia de Graph. En la siguiente imagen puede ver que el Destino BTP “sa_graph” ofrece acceso a la entidad Producto entre otros. Luego, podemos usar esta entidad para acceder a todas las entidades de Graph requeridas que se conectarán al arrendatario de back-end específico según la configuración de Graph.
Una vez que los productos y los detalles de los empleados se recuperan a través de Graph, el siguiente paso es llamar a los flujos de SAP Process Automation, para hacerlo, SAP Build Apps también usa SAP BTP Destinations. Se configura una integración API REST en SAP Build Apps apuntando a un destino BTP llamado “SAPBuildProcessAutomation” en nuestro caso específico. Los encabezados requeridos y el cuerpo de la solicitud que se enviará a nuestro flujo que contiene todos los detalles requeridos sobre el empleado que realiza el pedido, así como los productos que se ordenarán, también se configuran en nuestra configuración de API REST de SAP Build Apps.
Ahora que la implementación está completa, echemos un vistazo a la demostración de la solución final implementada por nuestro caso de uso de reparación de SA:
Este blog es parte de una serie que repasa el caso de uso de «Reparación SA», revíselos todos para tener una imagen clara y completa:
Para obtener más detalles sobre los diferentes temas cubiertos por este caso de uso, así como demostraciones completas y ejercicios paso a paso sobre cada función implementada, puede consultar un conjunto de sesiones que entregamos como parte de nuestro Bootcamp práctico: Transforme los procesos comerciales con SAP Signavio y SAP Build.
Espero que hayas disfrutado este blog y la serie completa, ¡por favor déjanos un comentario!
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073