Posibles escenarios con Fiori en SAP Portal

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).

Centro de Control de Nómina: Fin Ejemplo de Uso (Parte 4 de 4)

En este ya que si que si último post del CCN, voy a finalizar con este ejemplo interminable pero incompleto, del proceso que se podría realizar un mes cualquiera en una empresa, que utilizase esta herramienta para lanzar sus procesos de nómina (Links pasados para que os quiero: parte1, parte2 y parte3).

 

Previously en Trasteando con SAP UX nos quedamos viendo un ejemplo de uso en la etapa de lanzamiento del calendario personal de los empleados.

Lo normal sería lanzar una etapa de cliente para la estimación del IRPF pero no me ha dado tiempo así que os la tenéis que imaginar XD.

A continuación el proceso de ejemplo lanzaría la nómina a estos empleados. En los detalles (en el link Véase detalles) de la ejecución de la etapa se pueden visualizar las órdenes de spool que indican como ha ido el lanzamiento de estas nóminas.

Una vez que se realiza este paso, yo he incluido una etapa de lanzamiento de validaciones post-nómina. al igual que dije en el post anterior para mi este tipo de etapas es muy interesante para ayudar a identificar errores y puede aportar una ayuda que no existe en el ECC.

Una vez lanzada esta etapa, se pasa a la siguiente que es de supervisión de los errores.

También insisto en el tema de que SAP ha creado ciertos ejemplos, que en este caso de la verificación de los resultados de nómina, la documentación dice que es necesario tener los datos del clúster de nómina, desclusterizados para poder utilizar estas validaciones estándar.

Por esta razón, recomiendan que si se quieren utilizar estas validaciones sólo se haga si se está utilizando como base de datos HANA para evitar problemas de rendimiento.

En este ejemplo, yo que no tengo HANA y que quería hacer una prueba sencilla, me he creado una validación de cliente en la que leo los datos del clúster de nómina. Es cierto que el rendimiento no es muy espectacular pero a modo de ejemplo me vale (y dejándolo en fondo si fuese necesario, más).

En esta pantalla vemos como ahora volvemos a tener 6 errores pero uno de ellos es relacionado con los resultados de nómina.

Antes de pasar a la etapa siguiente quiero comentar que una opción que me parece interesante es la opción que tiene esta herramienta para visualizar las etapas que se han realizado y la opción que te ofrece para repetir una etapa ya procesada si fuese necesario. Por ejemplo, una vez que se corrigiesen los datos para solucionar los errores post-nómina se podría volver a lanzar la etapa de validaciones.

Una vez hecho esto, se va a lanzar la etapa que genera cierra el registro de gestión, y posteriormente se lanza la etapa que calcula la contabilidad de la nómina.

Si se accede a la transacción PCP0 en el ECC se puede ver el asiento contable que se ha creado:

El siguiente paso que he introducido en el proceso es uno que permite liberar el asiento contable.

Por último, se ha introducido una etapa para la creación de las transferencias bancarias (la primera fase para la generación de las transferencias).

Con este último paso el proceso queda concluido y se podría dar por cerrada todos los pasos de la nómina de abril.

Cuando se accede a la aplicación, este proceso aparece en la pestaña de la derecha como Concluido.

Con esto ya por fin termino el ejemplo de uso y espero que os haya parecido interesante.

Quiero insistir que este es un ejemplo basado en lo que he ido investigando por mi cuenta, sin haber aplicado los últimos cambios y mejoras y sin haber visto lo que ofrece el RDS. Esta herramienta puede dar más de si y necesitaría más tiempo para investigar.

Muchas gracias por leernos y a ver de que escribo próximamente.

Saludos!









 

¿Me tengo que deshacer de SAP Portal para usar Fiori?

Ahora que todo el mundo quiere que las aplicaciones se puedan usar desde el móvil (lógico, todo sea dicho), cuando tenemos SAP Portal nos encontramos con un mogollón de aplicaciones en Web Dynpro que no se adapta al dispositivo (to be responsive, or not to be responsive, that is the question). Entonces nos pasa por la cabeza la idea de pasar a Fiori, ya que sus aplicaciones SAP UI5 si que son adaptativas (al menos muchas de ellas). Además, SAP nos ofrece muchas aplicaciones y encima no se requiere una licencia adicional para Fiori (eso sí, seguiremos necesitando las licencias de usuario).

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.

Centro de Control de Nómina: Cont. Ejemplo de Uso (Parte 3 de 4)

En este tercer post (que no el último) sobre el Centro de Control de Nómina voy a continuar con el ejemplo que os quería enseñar para que vieseis mejor lo que ofrece esta herramienta (os dejo los enlaces al primer y segundo post de la serie).

 

En el post anterior finalizamos el ejemplo viendo como esta herramienta permite manipular el registro de gestión sin necesidad de entrar en el ECC por la transacción PA03.

 

En esa primera etapa del proceso que había propuesto se inicializaba el registro para el mes de abril pero me lo dejaba listo para el cálculo de la nómina. Por esa razón, la siguiente etapa que propongo es que se abra el registro para modificación de datos maestros.

 

Esta etapa se procesa inmediatamente y no tiene mucha historia. A lo mejor existe otra forma pero se podría crear una etapa que directamente pasase el registro de gestión al mes siguiente y que lo dejase en este status.

Preparándome las tareas

La Semana Santa es tiempo de descanso, vacaciones, procesiones y comer torrijas. Cada uno que elija lo que más le guste. A algunos puede que les toque arrancar y tal, pero yo necesitaba un tiempo de relax.

Así que esta semana el único que ha mostrado un poco de fuerza de voluntad es Miguel, hablándonos del Centro de Control de Nómina. Ojo, ahí es nada, y encima ya tiene programada la del lunes que viene. Yo de más mayor quiero ser como Miguel.

Por mi parte, estoy con unos cuantos post medio preparados o medio pensados pero, por motivos personales, no he podido cerrar ninguno en las últimas semanas. Si alguno he puesto, es porque ya estaba programado de antes o era poca cosa.

Pero bueno, espero volverme a poner en marcha y poder dedicarle más tiempo. Tengo en mente una serie relacionada con Fiori en SAP Portal (llamadme anticuado); otra sobre asociaciones para servicios oData (así podemos aprender a relacionar "tablas" entre sí, y lo haremos mediante una aplicación SAP UI5 sencillita, como es la norma); y a ver si consigo preparar un post para configurar el Gateway en la nube, a ver si así podemos montar un SAP CP Portal puro en el cloud sin tener que montarnos nuestro propio Front-End on-premise, aunque no prometo nada :P.

Voy a tener más frentes abiertos que Andrés Palomino en sus Crónicas PSN, espero dar la talla y conseguir fiorizar a más gente.

Para los que puedan disfrutar de ella, que tengan buena Semana Santa.

Centro de Control de Nómina: Ejemplo de uso (Parte 2 de 3)

Hola de nuevo! En este segundo post sobre el Centro de Control de Nómina os quiero enseñar la primera parte de un ejemplo de como la usaría yo (para los curiosos, os dejo un link al primer post).

 

Quiero que conste en acta que nunca he implementado esta herramienta en un cliente, es lo que tienen las cosas que han salido hace poco, y por lo tanto pueden haber formas mejores y desconocidas para mi. Se que esto es como tirar una piedra en el escaparate de vuestra inocencia, pero es así jejeje.

 

A nivel de proceso de nómina, y sin saber todo lo que sabe un usuario de Recursos Humanos, un ejemplo de proceso de nómina española sencillito podría ser:

• Se abre el registro de gestión para modificación de datos maestros.
• Validación de datos maestros.
• Generación del calendario personal.
• Estimación del IRPF.
• Se libera el registro de gestión para cálculo de la nómina.
• Cálculo de la nómina.
• Validación de los resultados de nómina calculados.
• Se cierra el registro de gestión.
• Contabilización de la nómina.
• Lanzamiento de las transferencias bancarias.

Esto podría ser mucho más detallado pero sirve para hacerse una idea aproximada.

Web IDE: Ver los datos de un servicio oData al crear una nueva aplicación

Con las novedades de Marzo de 2017 del Web IDE, una de ellas me había llamado la atención y, al ir a investigarla, he descubierto la de cosas que se van añadiendo y de las que uno no es consciente hasta que un día tiene tiempo para trastear un poco con ellas.

En este caso, la novedad hace referencia a una mejora a la hora de elegir el servicio oData, cuando estás creando una aplicación SAP UI5 nueva: Poder ver los datos reales.

Pero claro, ya puestos a ver cómo funcionaba, pues he estado revisando lo que ya se podía hacer y que, mísero de mí, desconocía.

Centro de Control de Nómina: El concepto es el concepto (Parte 1 de 3)

Estreno una nueva serie de posts cual si fuese Netflix para contaros sobre un tema muy interesante relacionado con la nómina. Es el ya famoso Centro de Control de Nómina: SAP Payroll Control Center.

¿Que es el Centro de Control de Nómina?

Es una herramienta web basada en SAPUI5 y está enfocada a cubrir las necesidades de los responsables de nómina (usuarios del departamento de RRHH y equipo de mantenimiento de la nómina).

Esta herramienta te proporciona las siguientes funcionalidades:

• La creación de un calendario de nómina con los procesos que se tengan que ejecutar, personalizado para tu empresa, lo que facilita la realización, el seguimiento y el análisis de lo que se haya producido durante el mes (acceso del manager).