Pero, ¿qué pasa con todas esas aplicaciones que ya teníamos en nuestro SP Portal? ¿No vamos a poder usarlas, las perderemos? Porque muchas Web Dynpros estándar no tienen su equivalente en SAP UI5, y luego están las apps propias de cliente, que requerirán un esfuerzo adicional si queremos adaptarlas.
Además, SAP Portal gestiona también el acceso y autenticación, y puede que nos dé miedo tocar esa parte.
¿Tenemos entonces que deshacernos de SAP Portal para pasar a Fiori?
No hace falta, porque siempre podemos optar por una opción intermedia: Usar Fiori Launchpad on SAP Enterprise Portal.
Tengo la impresión de que hablar de SAP Portal es como hablar de algo ya obsoleto, teniendo ya disponibles no sólo Fiori, sino también el SAP Portal en SAP Cloud Platform y el Fiori Cloud Edition. Pero es que muchas empresas lo usan intensivamente y a lo mejor no pueden permitirse irse, olvidarse de su nombre y pegar la vuelta.
Así que vamos a contar un poco en qué consiste Fiori Launchpad on SAP Enterprise Portal.
Por qué puedo necesitar SAP Portal en lugar de Fiori
Lo primero, porque tengas unos niveles de navegación considerablemente complejos. Aparte de los dos niveles superiores (las pestañitas que nos aparecen en la parte superior, que se llaman TLN o Top Level Navigation), podemos tener worksets anidados en worksets y/o carpetas, con una navegación detallada compleja. En ese caso, lo mismo ni siquiera nos interesa implantar Fiori, porque la solución de catálogos se nos puede quedar corta: Los catálogos sólo nos proporcionan el equivalente a un nivel de navegación.
O cambiamos la mentalidad a la hora de pasar de worksets a catálogos, o no podemos hacer nada. Habría que pensar ya en Fiori 2.0 con sus Overview Pages, que ya nos permite añadir un nivel adicional de navegación.
Eso sí, si continuamos con nuestro SAP Portal, aún podríamos usar aplicaciones SAP UI5, pero el portal en sí seguiría siendo puramente de escritorio, sin aportar movilidad real.
También puede que tengamos aún aplicaciones en Web Dynpro Java, que sí o sí, requieren la pila Java. Y es que aún se usa por ahí la UWL, aunque eso no es excusa porque para eso mismo tenemos el My Inbox ;). Podríamos pasar a Fiori, pero las aplicaciones Java seguirían "tirando de portal".
Otro motivo por el que podamos necesitar SAP Portal es porque tengamos varios servidores de back-end y sólo queramos Fiori para uno de ellos y para el resto seguiremos accediendo a SAP Portal, sin querer cambiar la URL de acceso ni liarnos con la autenticación de usuarios.
O quizá queremos migrar poco a poco. Podríamos comenzar usando Fiori Launchpad en SAP Portal y, cuando esté todo convertido, ya pasar a un Fiori Launchpad puro.
Sea lo que sea, podemos tener la necesidad de mantener nuestro SAP Portal pero usar escenarios, ya sean completos o parciales, de Fiori. Así que SAP nos ofrece una alternativa.
Qué se necesita
Para poder utilizar Fiori Launchpad en SAP Portal, necesitaremos una versión modernilla del SAP NetWeaver para SAP Portal. Teniendo en cuenta las mejoras disponibles, menos de un NetWeaver 7.4 SPS10 (o 7.31 SPS15) no sería recomendable. Y cuanto más alto, mejor.
Para saber las opciones disponibles dependiendo de la versión, se puede visitar esta página.
A partir de esta versión (realmente a partir de versiones anteriores, la recomendación anterior es para tener ya buenas opciones de configuración), en SAP Portal tendremos a nuestra disposición los elementos necesarios para poder "simular" nuestro SAP Fiori:
- Un nuevo Framework, que podremos añadir a un Desktop, y que simulará la visualización de un SAP Fiori normal. Al usar ese framework dejaremos de ver la forma tradicional de SAP Portal y veremos los famosos catálogos y mosaicos (tiles).
- Un nuevo tipo de iView que usaremos para acceder a las aplicaciones de tipo SAP UI5 para Fiori. En estas iViews indicaremos la ubicación de la aplicación (el sistema, el nombre de la aplicación y el nombre del componente), así como la ubicación del Fiori Launchpad real (ahora explicaré más adelante por qué hace falta esto); también podemos configurar si la aplicación se podrá usar en móvil, tablet y/o escritorio, el icono que se va a utilizar, en que categorías/catálogos va a estar disponible, etc.
- Una iView de categorías, que es una iView estándar específica donde configuramos los catálogos que van a existir en este pseudofiori. No usaremos la herramienta de diseño de catálogos de Fiori ni los asignaremos por roles de back-end.
- Una nueva herramienta de diseño de temas, el UI Theme Designer, que nos permitirá crear los temas para este nuevo framework.
- Roles de portal, donde asignaremos las iViews que tendrán los usuarios. Esto no es que sea nuevo, lo que cambia es la forma de pensar en como asignar las aplicaciones para Fiori: Si una iView asignada a un rol de portal está "correctamente configurada" para ser vista en el Framework de Fiori, entonces el usuario la verá. Así que en SAP Portal no usamos roles de NetWeaver ABAP para asignar catálogos, seguimos usando roles de SAP Portal con iViews. Luego ya, si eso, nos podemos liar a enlazar el rol de portal a grupos de la UME que estén enlazados con roles ABAP y blablabla.
Y no nos olvidemos del front-end y el back-end
Además de estos nuevos elementos de SAP Portal, necesitaremos tener instalados en alguna parte las aplicaciones SAP UI5 y los servicios oData. En este aspecto, seguiremos necesitando la arquitectura tradicional de Fiori: Un back-end donde ubicar los servicios oData y los datos maestros, y un front-end donde exponer esos servicios oData y mantener la librería de SAP UI5, aplicaciones y el Fiori Launchpad...
Sí, eso es, estáis leyendo bien: Necesitamos usar también el Fiori Launchpad en el front-end. ¿Y por qué, si eso ya lo simula el nuevo Framework que nos trae SAP Portal, os preguntaréis? Porque las aplicaciones SAP UI5 de Fiori no se pueden llamar directamente, ya que no tienen un index.html que podamos cargar alegremente. Para cargar una aplicación para Fiori, tenemos que hacerlo a través del Fiori Launchpad real (que nos hará las veces de index.html). Visualmente, nunca veremos dicho Launchpad, pero técnicamente sí que pasamos por él.
Cuando una aplicación se ejecuta de esta manera, se dice que se está ejecutando en modo standalone. Ojo, que no todas las aplicaciones permiten ejecutarse en este modo, tenemos que investigar si las que queremos se pueden usar así o no.
Sobre los temas de escritorio, nos encontramos con un pequeño problema. Aunque configuremos el tema en SAP Portal, para las aplicaciones SAP UI5 también necesitaremos configurar el tema en el front-end. Esto es un poco frustrante, pero es así :(. La visualización del Fiori Launchpad simulado la configuraríamos en el tema de SAP Portal, y todo lo que se vaya a ver una vez abierta la aplicación SAP UI5 se configuraría en el front-end ABAP.
Respecto a los servidores de front-end y back-end, por supuesto, podemos optar por tener la arquitectura en hub (el front-end y el back-end son servidores distintos) o integrada (embedded, front-end y back-end son la misma máquina).
Resumiendo, con un gráfico
Para entenderlo todo un poco mejor, aquí va un diagrama cutrecillo de ejemplo. Al final, necesitamos dos front-ends, el propio SAP Portal y el front-end ABAP donde están las aplicaciones SAP UI5.
En el siguiente post, veremos los posibles escenarios que podríamos montar, dependiendo de las necesidades, y entraremos más en detalle en temas técnicos. Sin pasarnos, sólo nociones, tampoco vamos a darlo todo hecho :P.
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.