En el post anterior habíamos hablado sobre el
Framework de Fiori para SAP Portal, o lo que viene a llamarse el
Fiori Launchpad on SAP Enterprise Portal.
Ahora vamos a ver las opciones que tenemos si queremos usar Fiori o aplicaciones SAP UI5 en nuestro SAP Portal, y nos encontraremos con tres posibles opciones (no voy a contar nada nuevo, pero bueno):
- Usar SAP Portal con una visualización tipo Fiori. Aquí me explayaré un poco más para entrar más en detalle con los temas técnicos, los nuevos tipos de elementos que tenemos disponibles y cómo usarlos, complementando lo mencionado en el post anterior.
- Usar SAP Portal tradicional con aplicaciones SAP UI5. Básicamente, no queremos Fiori, pero nos interesan algunas aplicaciones SAP UI5 estándar (o propias).
- Múltiples escenarios con distintas visualizaciones, si no queremos llevarnos todo el portal a una visualización tipo Fiori (por ejemplo, que el portal de HR sí se vea en Fiori pero el resto no).
- Dejarnos llevar por la locura (como si fuésemos meros esbirros del gran Cthulhu) e ir directamente a Fiori 2.0... que esto sería compatible con los otros puntos, todo sea dicho.
Usar SAP Portal con una visualización tipo Fiori
El escenario ideal sería tener una visualización de tipo Fiori, accediendo a la URL del portal y viendo los famosos tiles.
 |
| Estoy en SAP Portal, ¿a que no lo parece? |
Realmente, seguiremos trabajando en
SAP Portal, pero con el
nuevo framework
que nos simula Fiori Launchpad.
A efectos visuales, estaremos rodeados
de catálogos y tiles por doquier, en lugar de usar la navegación típica de SAP Portal
y los vulgares enlaces tradicionales.
Técnicamente, estaremos asignando un
desktop que use dicho
framework y un
tema compatible con Fiori.
 |
| Aquí está el Fiori Desktop estándar. Dentro de él, está escondido el Fiori Framework. |
Los
catálogos no se crean mediante el
Launchpad Designer, como en el front-end. En su lugar, se usarán
Categorías, que hacen las veces de catálogos pero funcionan de una forma algo diferente.
Excepto en contadas ocasiones, no necesitamos definir catálogos en el front-end, sino sólo las categorías en SAP
Portal. Me dejo pendiente hacer un post futuro para contar cuando pueden hacer falta los catálogos en SAP Portal.
Las categorías se definen en una iView estándar nueva
, Fiori Framework Categories,
que nos permite crear hasta 20 de ellas (indicando qué posición ocupan en la pantalla, un
identificador y el título con el que se muestra la categoría).
Eso sí, si las 20 categorías se
nos quedan cortas, siempre podemos aplicar la nota 2214932 (¡cuidado, usando las
peligrosas PCD Tools!).
 |
| Aquí definimos las categorías, asignando un ID, la posición y el título que se muestra en el Launchpad |
Y para poder mostrar los tiles, lo que hacemos es... ¡usar iViews! Sí, como no, recordemos que estamos en SAP Portal, ¿qué íbamos a usar si no?
Para las aplicaciones
SAP UI5 en Fiori, usaremos el nuevo tipo
SAP Fiori iView, que es la que nos permite indicar los datos de la aplicación (nombre y componente) y dónde está ubicado el Fiori Launchpad (recuerda, según el post anterior, que nos sigue haciendo falta el Launchpad real para ejecutar las aplicaciones en
modo standalone).
Pero, además, podemos crear tiles enlazando iViews de otros tipo, no sólo Fiori. Al hacerlo, se verán como un tile normal pero luego se abrirá la "tecnología" correspondiente (una URL, una web dynpro...). De esta manera, podemos rescatar las aplicaciones no-SAPUI5, teniendo en cuenta que no serán adaptativas, claro.
Todos (o al menos muchos) de los tipos de
iViews disponen de varias propiedades nuevas para poder usarlas como tiles, que nos permitirán indicar:
- En qué categorías (catálogos) se muestran. Aquí indicaremos los identificadores de las distintas categorías en las que se verán.
- En qué dispositivo se puede usar la aplicación: Gracias a esta propiedad,
podemos definir aplicaciones que sólo se podrán ver en un pc (por
ejemplo, las Web Dynpro) y aquellas que se pueden usar en otros (móviles
y/o tablets). Una iView con este parámetro en blanco nunca se verá en
el framework de Fiori.
- Si se muestra anclada al escritorio por defecto o hay que seleccionarla del catálogo.
- El icono de SAP UI5 con el que se muestran.
- Y otras distintas propiedades menores, que tampoco me voy a liar a contar.
¿Y entonces cómo se determinan los tiles que ve el usuario? ¿Le asignamos las categorías de alguna forma y ya
está?
Pues no, en SAP Portal no va así. Realmente vamos a seguir
trabajando como siempre se ha hecho en SAP Portal, mediante la asignación de grupos y roles de
portal. Una vez asignados los roles, al acceder a la visualización de tipo Fiori Launchpad sólo se mostrarán aquellas iViews que tengan asignado el tipo de
dispositivo correspondiente (desktop, tablet y/o móvil). El resto,
simplemente se ignorarán. Además, se agruparán en categorías (aka catálogos), que las hemos asignado en la propiedad correspondiente de cada iView.
Luego:
Rol de portal determina mis iViews => Propiedad de dispositivo de cada iView determina si se ven en mi dispositivo actual => Propiedad Categoría de cada iView determina cómo se agrupan.
Eso sí, para que una iView se vea, tiene que estar marcada como
visible, y el rol o workset correspondiente debe ser
punto de entrada... vamos, que no cuento nada nuevo para alguien que sepa de SAP Portal ;).
 |
| ¡Este rol está listo para ser usado en Fiori! |
Usar SAP Portal tradicional con aplicaciones SAP UI5
Otra posibilidad es
utilizar el framework tradicional de SAP Portal (el clásico o el modo
Ajax) e integrar las aplicaciones de tipo Fiori (o las aplicaciones SAP UI5 que tengan un punto de entrada -index.html o similar-, ya sea como URL o
desplegándolas en SAP Portal... nivel Dios, ojo).
Con esto lo único que
conseguimos realmente es aprovechar las nuevas aplicaciones (adaptativas) que nos da SAP y
las que hayamos creado con el Web IDE. Pero eso no
hará que el propio portal sea responsive, así que queda un poco chapucilla en ese sentido. Tampoco nos libramos de tener que usar otro front-end a no ser que la despleguemos en el propio SAP Portal.
Eso sí, al
menos está bien saber que podemos integrar una aplicación SAP UI5 en SAP
Portal y que no nos obligue a visualizar el Fiori Launchpad.
A tener en cuenta para los más valientes, que si queremos abrir la aplicación integrada en el portal (no como una ventana aparte), éste tiene que ser en modo estándar, así que habría que usar el
framework de tipo Ajax.
Múltiples escenarios, distintas visualizaciones
Esta opción es la que nos permite usar el framework de Fiori sólo en unos casos, manteniendo el framework clásico (tradicional o tipo Ajax) en otros.
¿Y por qué
puede ser esto necesario? Pues porque se esté migrando por
departamentos/sociedades, poco a poco, o porque el portal esté apuntando
a varios servidores (por ejemplo, si migramos a Fiori HCM pero no lo
hacemos en CRM).
En ese caso, podemos usar las triquiñuelas propias de SAP Portal para determinar que desktop (y, por tanto, framework) se va a utilizar. En este caso la triquiñuela se llama
Master Rule Collection.
Ese pequeño elemento no es más que una especie de "CASE" (llámese case, if-else-elseif, switch) que determina
que desktop vamos a usar en cada situación.
 |
| En la Master Rule Collection asignamos las reglas para determinar el Desktop a usar |
Con ello podríamos tener opciones como las siguientes:
- Si accedes al servidor con la url http(s)://mi_servidor:puerto/irj/portal/fiori, accedes a la visualización de Fiori.
- Si tu usuario de SAP Portal está asignado al grupo de portal "Fiori", accedes a la visualización de Fiori.
- Si tu usuario de SAP Portal tiene asignado el rol de portal "Fiori_ESS", accedes a la visualización de Fiori.
- Si tu usuario es Pepito, accedes a la visualización de Fiori.
- En cualquier otro caso, accedes a la visualización tradicional.
Este ejemplo cutrecillo nos vale para podernos hacer una idea de
la potencia de este elemento: Podríamos elegir que con la url por defecto (irj/portal) se acceda a
Fiori y mediante distintos alias (irj/portal/antiguo, irj/portal/crm, etc.) se navegaría al portal tradicional.
O podríamos ir migrando por departamentos/sociedades poco a
poco, haciéndolo transparente a los usuarios (le asignaríamos el grupo "Fiori" a los usuarios que tienen que acceder al framework nuevo y no se lo asignaríamos al resto).
O lo que os podáis imaginar. No me voy a poner a dar aquí ideas como un loco, que cada uno se dé a sus propias locuras.
SAP Fiori 2.0 en SAP Portal
Pues sí, los catálogos nos limitan mucho si tenemos una navegación compleja en SAP Portal, ya que sólo hay un "nivel" de agrupación y con SAP Portal podemos liarnos a crear worksets, carpetas, iViews de tipo mapa de servicios y crear una estructura "como de carpetas".
Pero bueno, para eso está SAP Fiori 2.0, ¿no? Porque a partir del SAP NetWeaver 7.5 para portal, si no hemos dado el salto a Fiori por culpa de los niveles de navegación, quizá ya podamos plantearnos dar el pasito al 2.0.
De aquí poco más puedo contar que lo que he leído, así que para mentir, mejor
os pongo un enlace para que vosotros le echéis un vistazo.
Porque técnicamente todo no es tan sencillo...
Como último detalle, contar que no todo es tan fácil. No, no, no, no quiero decir que es complicadísimo, ni de lejos. Pero, como os podéis imaginar, siempre van saliendo problemillas técnicos al montar Fiori en portal. Pero es que de eso vivimos, oye, de resolver cosas.
Problemas con la caché del navegador al subir versiones nuevas de aplicaciones, tener que configurar el tema para Fiori en el front-end y en portal, crear catálogos para las aplicaciones accesibles desde otra aplicación, los líos de trabajar con modo Quirk y modo Standard (¡malditos navegadores modernos!), protecciones anti-clickjacking y de navegación entre distintos dominios, querer ocultar los roles de Fiori en la vista tradicional (para que no se vea en el TLN)... vamos, que no os vais a aburrir.
Pero todo se va solucionando. Intentaré contar algunas cosillas en post futuros, por si a alguien les sirve (y si no, ya me servirá como mínimo a mí, entro de un tiempo, cuando se me hayan olvidado las cosas que ya he hecho y tenga que volver a hacerlas).
