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?

La aplicación Web Dynpro ABAP utiliza la BAdI HRESS_PAYSLIP_BADI_DEF, que podemos haber implementado para, por ejemplo, determinar los períodos de nómina que se van a mostrar.

Pero resulta que el servicio oData de nuestra nueva aplicación no usa esa BAdI. ¿Y por qué? Porque la nueva aplicación va más allá y reutiliza... ¡la BAdI de la aplicación en Web Dynpro Java! En este caso, es la XSS_REM_INTERFACE, que es prácticamente igual que la de Web Dynpro ABAP, pero no es la misma... así que toca reimplementarla.

Eso lo podemos descubrir "tirando del hilo", partiendo de la clase "oData", que es la CL_SRA006_DPC_EXT para la versión 1 y la CL_HCM_MY_PAYSTUBS_DPC_EXT para la versión 2. Los métodos usados son GET_ENTITYSET (para recuperar el listado de recibos) y GET_STREAM (para generar el pdf). Buceando más en el código llegaremos a dos módulos de funciones (depende de la versión, será uno u otro) donde podremos ver que la BAdI utilizada es la antigua, XSS_REM_INTERFACE. Sólo tenemos que buscar el CALL FUNCTION 'HR_GET_BUSINESS_ADD_IN'.

Lo más cachondo lo encontramos en la llamada del módulo de funciones que recupera el PDF. Ahí, como comentario a la BAdI utilizada, el programador se pregunta ¿no habría que usar la HRESS_PAYSLIP_BADI_DEF?

Aquí el programador sospecha algo...

Pero ojo, que a lo mejor es que hay un motivo para haber usado esta BAdI. Que lo suyo, cuando pasan estas cosas, es que nos revisemos las notas, a ver si encontramos algo.

En ese caso, podremos toparnos con la nota 2259626 - Payslip Displayed before the payday in Fiori My Paystubs APP, que nos descubre el misterio: La BAdI HRESS_PAYSLIP_BADI_DEF existe desde el EHP6. Pero la aplicación Fiori se puede instalar desde el ECC 6.0 (sin EHP ni ná), así que tiene que valer para cualquier EHP que tengamos, no sólo el 6. ¡Ahí está el culpable!

¿Y si ya tenemos implementada la BAdI HRESS_PAYSLIP_BADI_DEF qué podemos hacer? Pues una de dos, teniendo en cuenta que las dos BAdIs tienen unas interfaces prácticamente iguales:

• Si vamos a dejar de usar la aplicación WD ABAP para usar sólo la de Fiori, podemos implementar XSS_REM_INTERFACE y copiar el código.
• Si van a coexistir ambas aplicaciones (WD ABAP y Fiori), porque vamos a tener escenarios mixtos (por ejemplo, una sociedad usará la WD ABAP y la otra Fiori), nos va a tocar mantener ambas implementaciones. Eso sí, deberíamos encapsular el código en un módulo de funciones o clase común y llamarlo desde cada BAdI o, cuando implementemos XSS_REM_INTERFACE, en cada método podemos instanciar la clase de la BAdI HRESS_PAYSLIP_BADI_DEF y llamar al método correspondiente, mapeando parámetros. Lo suyo es no duplicar el código, que luego nos toca modificar un método y se nos olvida el otro.

Editado: Ojo, que hay segunda parte... ¿y si ya hubiese alguna nota por aplicar?