Teniendo en cuenta que, a corto o medio plazo, todos los procesos de SAP estarán “Fiorizados”, así como la creciente necesidad de trabajar desde un dispositivo móvil para realizar tareas concretas por parte de los usuarios finales, resulta muy recomendable comenzar a poner atención en esta tecnología y empezar a extender las aplicaciones a SAP Fiori para ajustarse a procesos de negocio customizados y adaptar las interfaces de trabajo a la lógica particular de cada empresa.
A la hora de realizar una implantación de SAP, una de las fases que más llama la atención es la de incluir interfaces que permitan acceder a la información desde cualquier dispositivo (móvil, tablet, desktop, wearables, etc.). Dentro del área de User eXperience, SAP pone al alcance de los usuarios más de 500 aplicaciones estándar, paquetizadas dentro de un producto denominado SAP Fiori.
Estas aplicaciones, que sirven para movilizar los principales procesos de negocio ya existentes en el ERP, están diseñadas con tecnología híbrida UI5, que no requiere migraciones y, si se cuenta con usuarios profesionales, no llevan licencia añadida.
UI5 ofrece la posibilidad de ejecutar los procesos desde cualquier dispositivo moderno, y Gateway permite integrar cualquier sistema moderno (tanto SAP como no SAP por medio de web services restful) para comunicarse con UI5 a través de OData.
Los addons de cada una de ellas se pueden descargar del market para montarlos sobre SAP NetWeaver 7.4 + SAP Gateway 2.0. El reto llega cuando la lógica de negocio que existe en un sistema no es la estándar. En muchas ocasiones existen campos nuevos que tiran de tablas custom y que se manejan con bapis “Z”; algo que resulta bastante típico.
En este sentido, generalmente existen tres posibles escenarios de implantación.
Por un lado, el estándar, el ideal. En este escenario, el proceso que se va a “Fiorizar” no ha sido alterado para adaptarse a ninguna casuística especial dentro de una empresa; en ese supuesto, la aplicación SAP Fiori funcionará directamente sin requerir más personalización (out of the box).
Cualquier aplicación UI5 se puede desplegar como aplicación funcionalmente completa que se puede ejecutar en un navegador
En un término medio nos encontramos con el extended. Básicamente estamos hablando de un proceso del backend que ha sido ampliado sobre el estándar para añadir personalizaciones a los procesos de negocio específicos de una empresa. En este caso, SAP Fiori permite extender las aplicaciones utilizando las BADI (ABAP) / Extension Points (UI5) de cada una, detallados en la documentación de las aplicaciones.
Los pasos generales en este caso serían instalar el addon de la aplicación, modificar su servicio OData para adaptarse al contenido nuevo y modificar las vistas y controladores para acomodarse al servicio recién ampliado.
El código de las aplicaciones es abierto y completamente editable; SAP propone una serie de buenas prácticas que pueden ser aplicadas en determinadas secciones, de forma que, cuando libere nuevas versiones, las aplicaciones extendidas sigan estando soportadas y no se sobrescriba código.
El tercer caso posible es el custom y responde a la necesidad de hacer una aplicación desde cero, cuando el proceso de negocio está completamente customizado y resulta más conveniente implementarla según los requisitos establecidos.
Cualquier aplicación UI5 se puede desplegar en el Gateway como una business server page (BSP), una aplicación funcionalmente completa que se puede ejecutar en un navegador web y que es accesible vía Url o puede publicarse en el Launchpad.
En este caso, hay que tener en cuenta que es necesario desarrollar un trabajo tanto de front-end como de back-end, ya que requerirá crear un web service (o varios) del que beban las interfaces para “pintar” la información.
Aunque este servicio web puede venir de cualquier base de datos moderna, SAP recomienda implementarlo con el service modeler de Gateway, que ofrece la posibilidad de reutilizar RFC (remote function calls) ya existentes en el back-end SAP para construir un servicio OData.
En este servicio van representados los datos maestros a través de “entidades”, con sus propiedades y sus métodos, que pueden ser invocados a través de llamadas http y devuelven los resultados en formato json / xml (y son, por lo tanto, interpretables por cualquier navegador embebido en dispositivos móviles o PC). De este modo se consigue que la parte frontal de la aplicación en UI5 pueda trabajar con la información de las bapis de manera sencilla.
Además, gracias a OData es posible realizar function imports desde el servicio Gateway, que permite realizar llamadas a operaciones específicas cuando los métodos CRUD (create, read, update y delete) no contemplan toda la funcionalidad.
Integración con SAP Mobile Platform
También hay situaciones en las que se necesita que una aplicación utilice funcionalidad nativa de un dispositivo móvil, como, por ejemplo, almacenar datos offline de manera persistente, leer un código QR con la cámara, enviar certificados por https, etc. Para esto, SAP ha liberado una serie de plugins Kapsel que funcionan con tecnología Adobe sobre la plataforma SMP.
A pesar de la eterna discusión sobre si es recomendable o no utilizar almacenamiento offline, es cierto que para determinados perfiles de empleado resulta interesante poder trabajar sin conectividad para sincronizar la información más adelante, cuando haya disponibilidad de red.
Lo primero que hay que tener en cuenta es que ya no accederemos a la aplicación vía url, de modo que habrá que paquetizarla con Kapsel para instalar el ejecutable en un dispositivo móvil.
Los plugins de Kapsel permiten trabajar contra una base de datos UltraLite desde JavaScript sin necesidad de programar en código nativo (Java para Android, Objective C para iOS, etc.). De esta forma se evita tener que rehacer el almacenamiento para distintas versiones de sistemas operativos y se facilitan las tareas de mantenimiento significativamente; el API usa únicamente código híbrido.
El plugin soporta el trabajo multiusuario y permite realizar las operaciones básicas (GET, POST, PUT, DELETE) sobre las “entidades” del servicio OData. Todas las llamadas se realizan de la misma forma, tanto con conectividad como sin ella, y permite filtrar los contenidos de la base de datos local al realizar la sincronización.
Se puede detectar, de manera transparente para el usuario, si hay conectividad y cambiar entre funcionamiento online/offline sin perder información. También almacena un log de errores para monitorizar posibles fallos que ocurran durante la comunicación con el servidor, por ejemplo al refrescar los datos.
Ejemplos sobre procesos comunes
Un escenario interesante para movilizar utilizando capacidad offline sería el de entrada de pedidos. En ocasiones, la fuerza de venta de una compañía se desplaza hasta el cliente con su aplicación en una tablet, pero no disponen de conectividad para leer datos o enviar los pedidos a SAP.
En ese caso resulta indispensable poder seguir trabajando con un modelo de datos que almacene la información y se sincronice al encontrar conectividad de nuevo.
Algo tan común como una aprobación también puede realizarse de forma offline; al final, se está actualizando el valor del campo status dentro de una tabla, de manera que puede grabarse internamente y enviarse más adelante, en un formato totalmente transparente al usuario.
