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!
Una cucharadita de SAP UI5, unas gotitas de Fiori, un toque de Web Dynpro ABAP y de aderezo un poquito de perejil y SAP HCM bien picadito, para darle sabor.
lunes, 30 de octubre de 2017
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.
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?
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.
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.
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:
¿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 |
Suscribirse a:
Entradas (Atom)