lunes, 30 de octubre de 2017

Lo que nos molan los cursos

El caso es que, preparando otro post que nada tiene que ver con éste, me da por mirar las estadísticas y veo que el post que más visitas ha recibido, ¡acaba de llegar a las 1000! Cifra redonda.

¿Y qué post es ese? Pues con el título del presente post, al menos está claro de qué hablará. Se trata del post Cursos Interesantes, que es de finales de enero. Sólo han pasado nueve meses y parece que ya está anticuado :D.

La verdad es que mola ver las ganas que hay de aprender cosas nuevas en esto que llaman SAP.

En total, hay cinco posts en los que hemos ido viendo distintos cursos que se han publicado relacionados con SAP UX, no sólo en openSAP sino también de MiriadaX (de forma indirecta, ya que no son cursos de SAP pero sí de cosas relacionadas, como HTML5). Puedes verlos pulsando aquí.

La cuestión es que, aunque los cursos tengan un plazo de "ejecución", los puedes seguir haciendo, pero no podrás hacer los exámenes para obtener el certificado correspondiente. ¡Pero lo importante es aprender!

De todas maneras, en openSAP tenemos la opción de pagar para que nos den un período de tiempo adicional, en cursos ya cerrados, durante el cual podemos obtener el certificado correspondiente.

¿Y qué cursos interesantes hay ahora? Pues, la verdad, casi prefiero no saberlo, porque luego los quiero hacer todos. Pero tengo que ponerme al día para ver que cosas interesantes hay y habrá.

Relacionado con SAP UX y HCM si que podemos destacar uno que acaba de comenzar, el de Extender aplicaciones de SuccessFactors con SAP Cloud Platform. Empezó ya el día 25 de octubre, ¡así que ya estamos llegando tarde!

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.


miércoles, 18 de octubre de 2017

ESS: Migrando el recibo de nómina de WD ABAP a Fiori

Hoy os voy a contar una anécdota, una chorradilla sobre una aplicación muy específica: My Paystubs. Mis recibos de nómina, que diríamos en español, la aplicación de Fiori de HCM, con la que podemos ver las monedas de oro que hemos cobrado cada mes. Se trata de una aplicación del Autoservicio del Empleado de SAP (Employee Self-Service o ESS).


El ESS viene de antiguo: Tuvo una versión en Web Dynpro Java, otra en Web Dynpro ABAP (a partir del EHP5) y ahora la tiene en Fiori. Nada nuevo que no sepáis ya, que eso nos lo contó Miguel en tres post muy interesantes (orígenes y Java, Web Dynpro ABAP y HR Renewal y Fiori).

Una de las cosas buenas que tiene cuando migramos del ESS en Web Dynpro ABAP a Fiori, es que se reutiliza gran parte de la parametrización, BAdIs incluidas. Esto ocurre, para poner el ejemplo más común, con la aplicación para solicitud de absentismos, que utiliza la misma tabla para determinar que absentismos y presencias se pueden solicitar desde el portal, entre otras cosas.

Claro, si hemos hecho ampliaciones en las WD, nos va a tocar replicarlas en SAPUI5 y en sus servicios oData. Pero, ¿y lo bonitas que quedan las aplicaciones nuevas aunque nos toque currar un poco más? Así, además, aprovechamos para limpiar código (guiño risita guiño).

Ahora pongámonos en el contexto del ejemplo particular. Tenemos nuestro ESS en Web Dynpro ABAP implementado y estamos migrando a Fiori. Una de las aplicaciones es el socorrido recibo de nómina, que lo pasamos a la versión 1 o la versión 2 del recibo de nómina en Fiori (a estas alturas deberíamos estar ya con la 2). De la versión 3 no puedo decir nada porque aún no la he podido probar.

Pues cuanto nos toca probar las aplicaciones, vemos que la nueva del recibo de nómina no pasa por la BAdI que ya habíamos implementado. Ponemos unos cuantos breakpoint pero nada, nos hace menos caso que Sauron a un par de hobbits. ¿Qué es lo que está ocurriendo?

miércoles, 11 de octubre de 2017

Target mapping sin LPD_CUST

Una de las cosas con las que nos liamos cuando comenzamos a pelearnos con Fiori es cómo saber qué aplicación se ejecuta al pulsar un tile. Podrá ser una aplicación SAPUI5, una Web Dynpro, una transacción o una URL, pero el procedimiento es el mismo, aunque en este post nos centraremos en aplicaciones SAPUI5.

Y es que esto no es "asignar una url y punto, tirando millas". Tenemos que seguir una serie de pasos: Crear el tile que se muestra, crear el target mapping que determina la aplicación y guardar en algún sitio la ubicación de la aplicación a ejecutar. Ojo, que no tiene por qué ser en ese orden, pero lo explico así porque parece más natural, aunque a la hora de hacerlo se haga al revés.

Y "ese sitio para guardar la ubicación" no es ni más ni menos que el launchpad del front-end (o rampa de lanzamiento), la transacción LPD_CUST. Ojo, no confundirlo con el Fiori Launchpad porque no tiene nada que ver aunque tenga el mismo nombre. El Launchpad es el "García" de SAP.

La configuración mediante la LPD_CUST


Esta es la configuración tradicional, aquella con la que nos hemos peleado siempre. No entraremos en detalle, porque esto es muy básico y el objetivo es otro, pero hagamos un breve resumen.

Lo primero que tenemos es el tile, con la correspondiente navegación por intención (mediante un objeto semántico y una acción). Esto no nos cambia en ninguna de las dos configuraciones mencionadas en este post.

Después tenemos el target mapping, que está atento a que se solicite esa "navegación por intención" para ver qué aplicación carga.

¿Y cómo determina el target mapping la aplicación? Consultándolo en la LPD_CUST.


Para ello, dentro del target mapping indicamos el launchpad (transacción LPD_CUST) dónde está guardada la información de la aplicación. Así que, básicamente con este método, el target mapping no sabe "qué aplicación se ejecuta" sino que sabe "dónde buscar la aplicación que se ejecuta".

Los parámetros son:

  • Launchpad Role y Launchpad Instance para saber qué entrada de la LPD_CUST tiene que leer.
  • Application Alias para buscar, dentro de ese launchpad, la aplicación que tenga este alias asignado.

Que el Launchpad Role se llame "Role" no tiene nada que ver con autorizaciones...
ya le podían haber puesto otro nombre, que luego uno siempre tiene que estar explicándolo

Con esa información nuestro target mapping ya sabe dónde tiene que buscar:


La configuración sin LPD_CUST


Pero ahora vamos al objetivo del post, que me enrollo más que Deadpool rompiendo la cuarta pared. ¿Por qué narices tenemos que guardar las cosas en la LPD_CUST? ¿No sería más sencillo guardarlo en el propio target maping?

Esto viene de antiguo... ojo, que decir "esto viene de antiguo" de una tecnología de 4 años tiene su tela. Está claro que se necesitaba un sitio donde guardar las apps. Y como la LPD_CUST ya estaba ahí (que ha sido muy útil para el Employee Self-Service y el Manager Self-Service en Web Dynpro ABAP, por mencionar algo), pues supongo que se decidieron a aprovecharla.

Pero, a partir del SAP UI Add-On 2.0 (la librería de SAP UI5 de la 1.30 para arriba), para nuestro Fiori Launchpad ya podemos configurar el target mapping sin necesidad de usar la LPD_CUST.


Simplemente, al crear el target mapping, en el desplegable Application Type elegimos la opción "SAPUI5 Fiori App". Ahora nos olvidamos del launchpad e indicamos los dos siguientes parámetros:

  • URL: Para indicar la url relativa de la aplicación, incluyendo el path que siempre asigna SAP para sus aplicaciones SAP UI5: /sap/bc/ui5_ui5/sap/<nombre_de_la_app>.
  • ID: Para indicar el nombre del componente, que podemos descubrir en el código del Component.js. en el declare (quitándole el .Component del final).


Así que si nos creamos un tile y un target mapping sin pasar por la LPD_CUST... ¿realmente funcionará?

La aplicación Ejemplo 1 no está configurada con la LPD_CUST

Pues sí, parece que funciona.


Ojo, que esto nos vale no sólo para las aplicaciones SAP UI5. También tenemos una entrada para poder configurar Web Dynpros, URLs y transacciones sin tener que recurrir a la LPD_CUST. En estos casos, si el back-end es distinto del front-end, nos tocará crearnos una RFC de tipo H que usaremos después como System Alias. Su nombre será <System_Alias>_HTTP o  <System_Alias>_HTTPS, según corresponda.

miércoles, 4 de octubre de 2017

Configurar SAP Cloud Portal para Fiori: Crear catálogos y asignarlos

Imaginaos que nos hemos creado un sitio web, en pan Fiori, en el portal de SAP Cloud Platform. Es fácil de imaginar si revisamos los post anteriores, cómo activar el servicio de Portal de SAP CP y cómo crear un sitio nuevo.

¿Qué tendríamos que hacer después? Cualquiera que sepa algo de Fiori lo tiene claro: Crear los catálogos y grupos y asignarle los mosaicos (los famosos tiles).

Pues eso es lo que vamos a hacer en este post, para que al final podamos obtener algo como lo siguiente:

Mi Fiori Launchpad con tres tiles