miércoles, 25 de octubre de 2017

Primero de Fiori: Los palabros

En los posts que van apareciendo en este blog como por arte de magia, voy mencionando términos de forma espontánea, creyendo que cualquiera que llega aquí los conoce. Pero claro, a lo mejor hay alguien que no sabe ni papa del tema y todo esto le suena a sindarín.

Por eso voy a hacer en este post un glosario de los términos más comunes con los que nos podemos encontrar relacionados con Fiori, para orientarnos un poco si hace falta. Ojo, explicados a mi manera. Así que estamos en el curso de...


Debemos recordar que tenemos tres posibles escenarios con Fiori: El clásico (Fiori instalado en un front-end ABAP), un SAP Portal con el desktop de Fiori (que, por detrás, atacará realmente al front-end clásico) y Fiori en la nube con el portal de SAP Cloud Platform. Algunos de los términos de este post pueden ser técnicamente diferentes para cada uno de estos entornos, pudiendo incluso no existir en algunos de ellos.



Tipos de servidores y servicios: front-end, back-End, on-premise, cloud (o cloud-based)

Estos palabros los uso a todas horas, incluso para pedir el café, pero puede que alguien no los tenga muy claros.

Así que vamos a ver si los aclaramos con una definición rápida, comenzando por los servidores donde vamos a implantar Fiori:

  • Back-end es el servidor donde vamos a tener los datos de negocio. Por ejemplo, si estamos hablando del servidor de HCM (que raro, yo hablando de HCM), aquí estarán todos los datos de empleados, estructura organizativa, formación, etc. En principio, el usuario que acceda a Fiori no va a hacerlo conectándose al back-end, sino al front-end.

  • Front-end es el servidor donde va a estar la parte web, a la que se conectará el usuario. Fiori Launchpad, la librería de SAP UI5 y la exposición de los servicios oData residen en el front-end. Aquí lo que no hay son datos de negocio, y el front-end se conecta al back-end para poder obtener dichos datos. De esta manera sólo expone los datos que se solicitan, pero no todos.

    Hay que aclarar que a lo mejor el usuario no se conecta directamente al front-end. En medio podría haber, por ejemplo, un balanceador de carga o proxy inverso como el SAP Web Dispatcher. Pero para entendernos y no liarnos, vamos a pensar que sí que nos conectamos directamente al front-end. 

  • Aunque SAP recomienda tener siempre un servidor como front-end y otro (o varios) como back-end, es posible tener front-end y back-end sean la misma máquina. Pero a la hora de hablar de Fiori, siempre aclaramos de qué hablamos, aunque estén en el mismo servidor. Vulgarmente, podríamos decir que back-end son las tablas con los datos y el código ABAP, y front-end la parte SAPUI5 y el Gateway.


Y ahora veamos dónde podemos tener instalados los componentes de Fiori, en on-premise o en cloud:

  • On-premise: Cuando se dice que tenemos Fiori on-premise, es porque lo tenemos instalado en nuestros servidores. Estos servidores pueden estar en nuestra oficina, escondidos en el CPD, debajo de la mesa del de sistemas o en una ubicación remota. Pero el servidor es nuestro y nosotros nos encargamos de trastear con él y gestionar todas las instalaciones de componentes y seguridad.

  • Cloud: Cuando hablamos de Fiori en la nube (cloud-based) o de cualquier otro servicio, como pueden ser los servicios que nos proporciona SAP Cloud Platform, no tenemos acceso físico al servidor en el que está instalado. Puede estar en cualquier parte, en un Data Center ubicado en Rotterdam, Tokyo, Almiruete o Mordor, pero nosotros no nos encargamos de gestionarlo, sino sólo de acceder a los servicios que hemos contratado. Nos quitamos de encima la gestión de la máquina y todo el tema de seguridad. 

  • Por supuesto, no tiene que estar todo en un sitio o en otro. Se puede tener el front-end on cloud y, sin embargo, el back-end on-premise.
Si quieres entrar más en detalle, puedes ir a este post.

Fiori


Fiori puede entenderse de dos formas. La primera, su forma "técnica", que viene a ser un portal web con un punto de acceso llamado Fiori Launchpad (que vamos a ver más adelante) y que usa SAPUI5 como librería principal.

Pero también hay que entender lo que realmente se vende, que es el paradigma Fiori: Una filosofía de diseño de aplicaciones para SAP, para que tengamos un portal web molón y coherente, siguiendo para ello cinco principios:


  • Basado en roles, donde cada usuario tendrá acceso sólo a las aplicaciones que realmente necesita en su puesto, ni más ni menos. En mi opinión, esto no cambia mucho respecto a la configuración del antiguo SAP Portal, pero ahora se hace más fácil de gestionar.

  • Responsive (adaptivo), las aplicaciones se adaptan al tamaño del dispositivo. Esto no es automático (o no siempre) y hay que programarlo específicamente para cada aplicación, pero SAP UI5 añade funcionalidad fácil de usar para garantizar este principio. De todas maneras, hay que tener en cuenta que no todas las aplicaciones están pensadas para ser usadas en el móvil (¿una gráfica con infinidad de valores en un móvil, en serio?) así que puede que ciertas tareas no nos interese que sean adaptativas.

  • Simples: Nos tenemos que olvidar de las transacciones en SAP que mostraban miles de millones de campos, para que distintos tipos de usuario las pudiesen usar. Una aplicación para Fiori debe estar pensada para una Persona específica (y por Persona me refiero a tipo de usuario), para un único caso de uso. Además, no debería realizar más de tres navegaciones (tres ventanas). Es lo que llaman la regla del 1-1-3 (1 persona, 1 caso de uso, 3 navegaciones).

  • Coherente: Las aplicaciones tienen que tener la misma lógica de uso y de diseño, de manera que la experiencia sea la misma independientemente de la aplicación utilizada.

  • Experiencia encantadora, deliciosa (delightful, la verdad que la traducción queda horrible). Inicialmente este principio era valor instantáneo, que indicaba que las aplicaciones se instalaban rápidamente y ya se podían comenzar a usar. Luego lo cambiaron por delightful, que significa que el usuario debe poder establecer una relación emocional con la aplicación. Vamos, que le va a molar la aplicación más que a Mortadelo una fiesta de disfraces.

    Supongo que lo de valor instantáneo no siempre era tan cierto como nos gustaría, ya que no sólo vale con instalar la aplicación y activar los servicios, sino que muchas llevan por debajo su parametrización, sus BAdIs y posiblemente varias ampliaciones para adaptarlas al cliente.

Fiori Launchpad


Fiori Launchpad es la parte tangible de Fiori, el punto de acceso del usuario al portal web. Se trata de un shell que nos muestra las barra de menú, las aplicaciones que tenemos disponibles, nos permite navegar a la aplicación que abramos y personalizar nuestro escritorio web de trabajo. Es decir, básicamente es "la página web".

Tiles por doquier

Podemos imaginarnos que el Fiori Launchpad es como el index.html de cualquier página web, que nos muestra los distintos menús disponibles y el contenido de la sección (aplicación) que hayamos elegido.

La página inicial a la que accedemos cuando entramos en Fiori Launchpad se llama Home Page, "página de inicio". Ahí se cargan los mosaicos (tiles), que son los accesos directos de las aplicaciones que más usamos. Cuando pulsamos sobre uno de esos mosaicos, se carga la aplicación correspondiente.

Después, tenemos una sección de Catálogos donde podemos ver todas las aplicaciones que tenemos disponibles, así como configurar cuales queremos ver en nuestra página de inicio.

Para ver un ejemplo parecido, pensemos en un móvil, donde tenemos unas pantalla de inicio y ahí hemos asignado un acceso directo a las aplicaciones que más usamos. Después, tenemos un apartado "Aplicaciones" para ver todas las aplicaciones instaladas en el móvil y desde donde podemos añadirlas a la página de inicio.

El Fiori Launchpad funciona igual: Tenemos nuestra página de inicio (un "escritorio web") donde podemos mostrar y organizar las aplicaciones que más usemos y ocultar el resto. Luego tenemos una sección de Catálogos donde vemos todos los catálogos disponibles (tendremos asignados aquellos relacionados con nuestro rol en la empresa) y, por tanto, todas las aplicaciones que podemos usar. Desde allí podremos asignar las aplicaciones que nos interesen a la página de inicio.

La diferencia más importante a clarificar entre cómo funciona un móvil y cómo funciona el Fiori Launchpad es que Fiori es un portal web, así que no tenemos que instalarnos aplicaciones en nuestro equipo, ya que estas realmente son "páginas web" que se incrustan en el Fiori Launchpad cuando las abrimos.

SAP UI5


Aquí ya estamos hablando del lenguaje de programación que vamos a usar. Podríamos añadir a nuestro currículum aquello de "yo sé programar en SAP UI5" pero no "yo sé programar en Fiori" (aunque podríamos decir "yo sé programar para Fiori").

Realmente no es un lenguaje en sí propiamente dicho, sino una librería HTML5 que nos proporciona una infinidad de funcionalidades, como crear tiles, botones, textos, formularios, posicionarlos en la página, reaccionar a eventos, hacer los componentes responsive para que se adapten al tamaño del dispositivo... Llamémoslo framework para desarrollar aplicaciones web, para que suene más cool.

El lenguaje de programación que usaremos será Javascript y, como lenguaje de etiquetado, XML.

Servicios oData


Las aplicaciones de SAP Fiori obtienen los datos de SAP mediante servicios oData, un protocolo de comunicación abierto basado en HTTP: Solicitas los datos y los recibes mediante URLs. Harían las veces de Web Services o módulos de funciones remotos que hayamos podido hacer en SAP para otros desarrollos.

Estos servicios oData se crean y gestionan en SAP mediante un componente llamada SAP NetWeaver Gateway y obtienen los datos de negocio mediante clases ABAP.

En resumen, la aplicación web hace una llamada mediante un método HTTP al Gateway de SAP, que ejecuta una clase en ABAP para obtener los datos y devuelve dichos valores como respuesta a la llamada HTTP.

Puedes echar una ojeada a este post para entrar más en detalle.

NetWeaver Gateway


SAP NetWeaver Gateway (o "el Gateway" a secas) es el componente de SAP que se va a encargar de extraer la información que tenemos almacenada en SAP y publicarla para poder ser utilizada en nuestro portal Fiori (o cualquier otra herramienta, que no tiene por qué ser Fiori, por supuesto). Viene por defecto instalado con SAP NetWeaver 7.40.

El Gateway estará instalado en el front-end, donde expone los servicios oData al exterior para que puedan ser consumidos. Por ejemplo, por las aplicaciones SAP UI5 que estaremos desarrollando para Fiori.

La información la obtiene consultando el SAP back-end, donde hay una pequeña parte del Gateway instalada (el componente BEP), que nos permite crear unas clases ABAP (las Data Provider Classes) a partir de las cuales obtendremos la información.


SAP Portal no dispone de Gateway. En este escenario, SAP Portal lo único que hace es "pintar" la parte web. Pero para la obtención de datos siempre necesitará un front-end ABAP al que consultar (que a su vez le solicitará la información al back-end).

Por su lado, SAP Cloud Platform dispone de un servicio llamada oData Provisioning que hace las veces de Gateway en la nube, que consultaría a su vez con el SAP back-end que tenemos.

Puedes ver más detalles del Gateway en este post.

Fiori Launchpad Designer


A la hora de crear Catálogos y Grupos, SAP (en on-premise) nos proporciona una herramienta para crearlos. Es el Fiori Launchpad Designer, la fábrica de los catálogos.

Toca crear catálogos

Es un servicio web al que podemos acceder con la url:

https://<servidor>:<puerto>/sap/bc/ui5_ui5/sap/arsrvc_upb_admn/main.html?sap-client=<tu_mandante>&scope=CONF

Scope hace referencia al tipo de alcance, que puede ser CONF (configuración) y CUST (customizing).


  • El primero (CONF), es común para todos los mandantes. Es donde SAP despliega sus catálogos estándar.



  • El segundo (CUST), es específico para cada mandante. Lo suyo suele ser trabajar en este scope.


Los catálogos disponibles en CONF también lo están en todos los CUST y cualquier modificación en CONF se aplica a CUST, excepto si lo hemos modificado, en cuyo caso deberíamos restablecer la herencia si quisiésemos aplicar los cambios.

Y ojo, quien habla de catálogos, también habla de grupos, que se configuran en la misma herramienta y de forma muy parecida.

Catálogos


El catálogo es el "objeto" que vamos a usar para agrupar las aplicaciones por funcionalidad. Un usuario con un determinado catálogo asignado tendrá acceso a todas las aplicaciones de ese catálogo.

Hay que dejar claro que a los usuarios nunca les vamos a asignar aplicaciones sueltas, sino catálogos. Si un usuario tiene X catálogos con Y aplicaciones, el usuario tendrá acceso a todas esas X * Y aplicaciones.

En este sitio de SAP Cloud Portal, tengo dos catálogos asignados, uno con tres aplicaciones y otro con dos.
Tengo, por tanto, un total de 5 aplicaciones megachulas.

Por ejemplo, en Fiori HCM existe el catálogo "Employee Self-Service", ESS, que contiene las aplicaciones comunes para todos los empleados de la empresa: Solicitar absentismos, ver datos personales, visualizar la estructura organizativa y buscar datos de compañeros, etc. Todos los empleados de la empresa (al menos los internos) tendrían este catálogo asignado.

Por otro lado, existe el catálogo "Manager Self-Service", MSS, que es sólo para aquellos que tienen gente a su cargo (vamos, los jefes): Validar absentismos, ver el calendario de su equipo. etc.

Un empleado común (por ejemplo, Mortadelo) sólo tendría asignado el ESS, mientras que un jefe (Filemón), tendrá el ESS y el MSS.

La forma en la que se crea un catálogo es diferente dependiendo del escenario en el que estemos trabajando:

  • Si nuestro SAP es on-premise, el catálogo lo creamos a través del Fiori Launchpad Designer que hemos mencionado antes. A los usuarios se los asignamos mediante roles PFCG.

    El catálogo define las aplicaciones disponibles mediante dos tipos de elementos: Target-Mappings (que nos dicen cómo cargar la aplicación) y tiles (que nos muestran el recuadro en la pantalla y llaman al target-mapping correspondiente).

  • Si usamos SAP Portal, los catálogos se llaman categorías y se definen como propiedades en una iView única. Después, a cada iView en el portal le asignamos las categorías en las que están incluidas.

    Las iViews se asignan a los usuarios como toda la vida, mediante la asignación de roles de portal. En el desktop de Fiori, se visualizarán aquellas iViews que tengan asignada una o más categorias. Podemos verlo más claro en este post.

  • Si usamos SAP Cloud Platform, los catálogos se asignan a los usuarios mediante funciones o roles. Es muy similar al on-premise, pero no almacenan tiles y target-mappings, sino sólo un tipo de elemento, aplicaciones. Podemos ver más información en este post.

Grupos


Los grupos nos sirven para hacer conjuntos de aplicaciones dentro la página de inicio del Fiori Launchpad.

Pueden ser de dos tipos. Esta definición no existe como tal, sino que la hago yo para que quede claro:

  • En el Fiori Launchpad, un usuario se puede crear un grupo propio y asignar aplicaciones de sus catálogos a ese grupo. Puede darle el nombre que quiera y asignar las aplicaciones que quiera, aunque no tengan relación. También puede borrar el grupo en cualquier momento que él quiera.

  • Por otro lado, el administrador Fiori también puede crear grupos, una configuración similar a la que se hace con los catálogos, mediante el Fiori Launchpad Designer en SAP on-premise. Estos grupos se asignan mediante roles (en la PFCG si estamos en on-premise, como roles de SAP Cloud Platform y como una propiedad de las iViews en SAP Portal).

    Cuando un usuario tiene un grupo asignado de esta forma, dicho grupo le va a aparecer automáticamente en el portal, incluso aunque él no lo haya creado ni asignado. Puede borrar las aplicaciones del grupo y asignar nuevas, pero no puede borrar el grupo, sólo reiniciarlo (con lo que se volverán a ver las aplicaciones asignadas inicialmente).

My Home, Employee Self-Service, Other apps,
esos son los grupos que tenemos en nuestra página de inicio.

¿Y para qué nos pueden valer los grupos configurados en Fiori? Para dos cosas:

  • Para proponer las aplicaciones iniciales del Fiori Launchpad. Cuando un usuario accede por primera vez a Fiori, si no tiene grupos asignados, le aparecerá una página de inicio en blanco. Seguro que entonces pone una incidencia diciendo que su portal web no funciona, que no le muestra nada. Posiblemente no se habrá leído el manual básico que se habrá creado para que la gente sepa cómo usar el portal. Si se asignan grupos, tendrán unas aplicaciones iniciales propuestas y luego ya se podrá organizar como quiera.

  • Para evitar la personalización: Un error muy común con SAP Portal era que los usuarios ocultaban enlaces, tablas, botones, en su portal mediante una opción de personalización que aparecía al pulsar el botón derecho sobre un elemento. Esto generaba muchísimas incidencias que no eran tales, en plan "es que no me aparece la tabla... no, no, yo no he tocado nada", pero sí que había tocado algo, lo que pasa que no se acordaba o no se había enterado.

    Aunque hemos dicho que un usuario puede organizar su página de inicio como quiera, se puede elegir desactivar esta opción para evitar esos errores de personalización. El usuario no podría eliminar aplicaciones de su Fiori Launchpad. Pero claro, tampoco podría añadirlas. Así que con los grupos crearíamos una asignación de aplicaciones por defecto en la página de inicio, común para todos e intocable. Esto sería útil para portales que tienen pocas aplicaciones y todas son muy usadas.

A tener en cuenta una cosa muy importante: En el grupo asignamos mosaicos (o aplicaciones) de forma similar a como se hace con los catálogos. No obstante, el grupo no da autorización para ejecutar la aplicación, simplemente nos muestra el mosaico. Si esa aplicación no la tenemos asignada en algún catálogo, no podremos acceder y nos dará error. Así que tendremos que duplicar dicha información: Un catálogo para ver qué aplicaciones tenemos y un grupo para ver lo que se muestra en nuestra página de inicio. Y os preguntaréis, ¿eso no es como duplicar la configuración? Pues sí, la verdad, para qué engañarnos.

En SAP Portal no existen los grupos "de administrador" como tal. En su lugar, las iViews tienen una propiedad, "Default App in Home Page", para hacer que la aplicación se muestre por defecto en la página de inicio, sin necesidad de que el usuario la seleccione.

Mosaicos (tiles)


Los mosaicos o tiles son los recuadros que nos aparecen en Fiori Launchpad y que, cuando pulsamos, carga una aplicación. Básicamente es un link en forma de botón cuadrado grande dentro de nuestro Fiori Launchpad.

Los mosaicos pueden ser estáticos, dinámicos (que muestran un número informativo, por ejemplo el número de solicitudes que tenemos pendientes; de esta manera sólo entramos en la aplicación si vemos que hay algo pendiente) o incluso KPIs (que nos muestran un indicador clave y, si nos interesa ver el detalle, lo pulsamos; esto es más para aplicaciones analíticas).

Los usuarios pueden ordenar los mosaicos dentro de su página de inicio como queramos (a no ser que se haya desactivado la personalización).

Los tiles, en on-premise, los configura el administrador Fiori mediante el Fiori Launchpad Designer, dentro de cada catálogo.Pero esta configuración no guarda la aplicación web que van a ejecutar, sino un objeto semántico y una acción. Si el usuario pulsa ese tile, estará llamando a ese objeto semántico y acción, haciendo una especie de llamada por eventos que se llama navegación por intención.

Así es como luce la configuración de un tile

Este elemento es exclusivo como tal de SAP on-premise. En SAP CP forma parte de las aplicaciones, como una propiedad adicional, pero no como un objeto independiente, mientras que en SAP Portal los mosaicos serán las iViews que hayamos configurado para ser visualizadas en el desktop de Fiori.

Target mappings


El target mapping es el que se encarga de determinar dónde está la aplicación a la que se navega. Se define gracias a la combinación de dos elementos, un objeto semántico y una acción.

Este elemento hace las veces de "escuchador de eventos". Si alguien llama a ese objeto semántico y acción, el target mapping se entera y determina la aplicación a la que se navega.

El administrador de Fiori los crea en cada catálogo mediante el Fiori Launchpad Designer.

Este elemento es exclusivo de SAP on-premise y no existe como tal ni en SAP CP ni en SAP Portal.

Y ahora toca crearnos el target mapping.

Aplicaciones


Las aplicaciones son los elementos específicos que hemos instalado en nuestro SAP on-premise o que hemos configurado en SAP CP: Crear una solicitud de viajes, ver nuestro inbox de tareas, hacer un pedido de compras, etc.

Son un componente SAP UI5 que realmente no necesita un index.html porque serán cargadas dentro del Fiori Launchpad.

No tenemos que instalarnos nada en nuestro ordenador o en nuestro móvil, pero sí tenemos que hacerlo en SAP on-premise.

Podemos ver las aplicaciones Fiori estándar en la librería de Fiori.

Pero además de eso, dentro de un sitio de SAP CP las aplicaciones son un objeto dónde indicamos qué aplicación específica se ejecuta, a qué catálogos y grupos está asignada, cómo está configurado el mosaico que se va a mostrar en el portal y qué objeto semántico y acción estará escuchando. Aquí podemos ver cómo configurarlas.

Configurando aplicaciones para nuestro sitio en SAP CP.
En este escenario, el mosaico es un tipo de propiedad.

Objeto semántico, acción y navegación por intención.


Cuando asignamos aplicaciones en Fiori on-premise, les tenemos que asignar un mosaico y un target-mapping (o definir la aplicación en SAP Cloud Portal). Estos dos elementos se asocian, a su vez, por algo similar a "eventos: La navegación por intención (intent navigation).

Esta navegación, a su vez, se compone de dos elementos, objeto semántico y acción.

Lo que tenemos es una especie de navegación "por escucha de eventos". Es más o menos lo mismo. El target mapping guarda la información de dónde está la aplicación que se va a ejecutar, así como un objeto semántico y una acción (siempre vienen en parejas, como los droides de Star Wars).

Después, a los mosaicos les asignamos también un objeto semántico y acción, pero no la aplicación.

Cuando el usuario pulsa en el portal un tile, lo que está haciendo es "invocar" esa navegación por intención. Después, se comprueban los distintos target mappings y se ejecuta aquel que tiene asignada esa navegación.

Técnicamente, esta operación la realiza el servicio oData INTEROP, que es uno de los servicios básicos que hay que activar para que funcione Fiori.

Los que hayan montado sus portales en SAP Portal y en NetWeaver Business Client (que sería la versión SAP Portal puramente en ABAP, sin depender de una pila Java), puede que se hayan encontrado con el concepto de OBN (Object-based Navigation, navegación basada en objetos). La navegación por intención, a la hora de la verdad, viene a ser lo mismo.

¿Y dónde se definen los objetos semánticos y las acciones?

Los objetos semánticos, para on-premise, existen en dos tablas: Una estándar de SAP (que no deberíamos tocar), que es la /UI2/V_SEMOBJ, y una para cliente, /UI2/V_SEMOBJC, donde podemos crearnos nuevos objetos semánticos.

Las acciones no se tienen que definir en ninguna parte y pondremos la que nos dé la gana en cada target-mapping (pudiendo reutilizar el mismo objeto semántico para múltiples target-mappings). SAP recomienda definirlas con formato camel (esteEsUnEjemploDeAccion).

Launchpad en el ECC


Cuidado, que ya no estamos hablando del Fiori Launchpad, sino de la rampa de lanzamiento o Launchpad que está dentro de SAP. Se ejecuta con la transacción LPD_CUST.

El Launchpad se usa como contenedor de aplicaciones, guardando la información de qué tipo de aplicación es (URL, transacción, Web Dynpro ABAP) y dónde está ubicada.

No es algo específico de Fiori, viene ya de antiguo. Por ejemplo, el Autoservicio del Empleado (ESS) de HCM en Web Dynpro ABAP usaba el Launchpad para determinar qué aplicaciones se mostrarán en el portal.

En la LPD_CUST vemos una serie de launchpads organizados por rol e instancia.
Al abrir uno de ellos, vemos las aplicaciones de las que almacena su información.

Los target-mappings estándar, por defecto, determinan la aplicación que se ejecuta leyendo una entrada dentro del LPD_CUST. Se les pasa tres parámetros: El rol e instancia del launchpad donde está la aplicación, y el alias de dicha aplicación (que es una propiedad de las aplicaciones).

Esto ya ha cambiado y no es necesario usar el Launchpad en las versiones más modernas (lo puedes rememorar en este post). 

Cada launchpad, que agrupa aplicaciones por funcionalidad, tiene un nombre compuesto por dos valores: Rol e instancia. Es decir, para identificar una rampa de lanzamiento específica tienes que indicar estos dos valores.

Después, dentro del launchpad, habrá una organización de carpetas y aplicaciones. Cada una de estas aplicaciones contiene la información de cómo ejecutarla: Si es una URL (por ejemplo, para aplicaciones SAP UI5), si es una Web Dynpro, si es una transacción, etc.

Tema


El tema (theme) es la combinación de colores, imágenes, fuentes y hojas de estilos que permiten definir cómo se va a visualizar el portal. Existen varios temas por defecto, pero lo suyo es crearse un tema específico para la empresa, para poder así aplicar los colores corporativos. Para crearlo siempre partiremos de uno estándar.

Los temas se crean mediante el UI Theme Designer, herramienta que está disponible tanto en SAP on-premise (mediante la transacción /UI5/THEME_DESIGNER) como en SAP Portal (dentro del Content Administration) y en SAP CP (como servicio del portal).



Para transportarlos, hay que usar una herramienta adicional: la transacción /UI5/THEME_TOOL en on-premise, el método genérico de transporte en SAP Portal (en System Administration) o la propia herramienta de diseño en SAP CP.

Por último, en SAP on-premise el tema utilizado por defecto está definido en la tabla /UI2/NWBC_CFGV, con los valores filter = SAP_FLP y parameter name = THEME. Pero si queremos cambiarlo, lo debemos hacer en la tabla de cliente /UI2/NWBC_CFGV.

El tema actual estándar para Fiori 2.0 es el Belize, mientras que para Fiori es BlueCrystal. Se pueden ver los distintos temas estándar en esta página.

Fiori 2.0


Se trata de un paso adicional en la filosofía de diseño de Fiori, añadiendo nuevos componentes técnicos adicionales: Un nuevo tema llamado Belize, un área de notificación de mensajes, un tipo de componente (Overview Page), etc.

Para poder usar Fiori 2.0 necesitaremos instalar una versión bastante reciente de SAP UI5 en nuestro front-end, no nos vale cualquiera (el Fiori Front-End server 3.0 (que es el SAP_UI 7.51).


Overview Page


El Overview Page es un componente que viene con Fiori 2.0. Como bien indica su nombre, es un tipo de "página".

Este componente se puede usar para crear aplicaciones en las que agrupar, en una misma página, toda la información relacionada con una línea de negocio o funcionalidad en una misma página. Por tanto, nos podemos crear una aplicación que use este componente y que se abra desde la página de inicio, tras pulsar un mosaico, como cualquier aplicación normal.

La información que se muestra lo hace agrupada en tarjetas (recuadros con listas y/o gráficos), que además nos permiten navegar a una aplicación específica.

De esta manera, no sólo agrupamos la información, sino que añadimos un nivel adicional de navegación en Fiori, ya que hasta ahora sólo se podía tener un listado de tiles en nuestra página inicial y de ahí navegar a una aplicación específica, no a otro grupo de aplicaciones.


No hay comentarios:

Publicar un comentario