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?
