Actualización del entorno de pruebas SAP SuccessFactors ECP/EC

Este mes, hemos estado trabajando en PostNL para actualizar su entorno de prueba Employee Central Payroll (ECP)/Employee Central (EC). Tienen casi 200.000 registros de "persona central", con más de un cuarto de millón de registros de empleados vinculados a ellos; algunos de los cuales sólo están en ECP, pero la mayoría también están en EC.

El EC Instance Refresh es un servicio proporcionado por SAP SuccessFactors, que normalmente forma parte de su contrato, y actualiza todos los datos y la configuración de la instancia de producción en QA o Test. El reto que conlleva es cómo gestionar el sistema de nóminas vinculado. Una copia completa del sistema puede ser increíblemente perjudicial para el post-procesamiento necesario, y significa que se necesita todo el espacio en disco del sistema de producción para el sistema de pruebas. Pero sin esto, habrá una desalineación entre la instancia de EC recién actualizada y los datos más antiguos en ECP. Aquí es donde interviene EPI-USE Labs. Sin embargo, hay opciones sobre cómo aprovechar múltiples tecnologías para resolver el problema.

La última vez que realizamos el proceso fue hace unos cuatro años, y aprovechamos el motor complementario Object Sync™ de Data Sync Manager™ (DSM) para SuccessFactors, lo que significa que importamos simultáneamente los datos de ECP y enmascaramos los datos de SuccessFactors al mismo tiempo.

En esta ocasión hemos adoptado un enfoque diferente, utilizando el motor Client Sync™ (que también forma parte de DSM Suite) en lugar de Object Sync y, a continuación, el complemento DSM Data Secure™ para SuccessFactors. Client Sync suele ser más una función del equipo de Basis, pensada para cambios a gran escala en los sistemas en lugar de "datos bajo demanda", y suele utilizarse en lugar de una copia del sistema.

Había dos razones para querer hacerlo de otra manera:

1. Cuando se trata de grandes volúmenes de datos, el motor Client Sync es la mejor solución en la pila ABAP. Object Sync puede utilizarse para grandes volúmenes, pero como selecciona un registro en PA0003 y luego busca todos los registros relacionados en todas las demás tablas antes de pasar a la siguiente, nunca puede ser tan rápido como Client Sync, que procesa tabla por tabla. Todavía se puede ser "selectivo", pero sólo en el sentido de no tomar el historial completo de los datos del clúster (algo que era esencial en este proyecto dada la cantidad de historial de nóminas).

2. SuccessFactors ha sido 'instance refreshed' por lo que la gran mayoría de las entidades son exactamente como las necesitamos. Con Object Sync, se enviaba el modelo OData completo, empezando por el usuario y enlazando EmpEmployment, PerPerson, PerPersonal, etc. La gran mayoría de los datos se sustituían a sí mismos. Por supuesto, esto no impide que la API OData ejecute reglas de negocio y otras validaciones. La última vez, pasamos mucho tiempo trabajando alrededor de estas cosas para asegurarnos de que los datos codificados se estaban insertando correctamente. Aunque la validación no sea un problema, el rendimiento sí lo es. El 95% del tiempo de procesamiento corresponde a las llamadas a la API de OData, por lo que reducir su número sólo mejorará el tiempo de ejecución.

Todavía hay que tener en cuenta un buen número de pasos de preparación, al igual que para actualizar la instancia, pero el objetivo es que este enfoque sea mucho más fácil de repetir. Tras una implementación y definición del proceso por parte de nuestro equipo de consultoría, podría ser algo llevado a cabo por nuestros propios clientes, o alternativamente podemos ofrecer un servicio gestionado para ello.

Proceso técnico: actualización de datos

Programamos una exportación de Client Sync para que se ejecutara exactamente al mismo tiempo que SAP SuccessFactors tomaba la imagen de actualización de la instancia de SuccessFactors de producción. Existe un perfil específico "sólo HCM" en el producto Client Sync que permite actualizar únicamente los datos de HCM, sin afectar a los datos de otras áreas de SAP. Opcionalmente, se puede incluir personalización relacionada con HCM, pero en este caso de uso no queremos hacerlo, porque el sistema de gestión del transporte se ha utilizado eficazmente en ECP.

En este proyecto, era fundamental aprovechar la capacidad de "troceado temporal" de Client Sync para tomar únicamente los dos últimos años de datos del clúster de nóminas. Sin ello, el volumen de datos habría sido excesivo para el sistema de control de calidad existente.

(Esto es muy importante en las bases de datos tradicionales, pero con el paso de Employee Central Payroll a S/4HANA en breve, será mucho más importante, ya que el coste de los dispositivos de tamaño de producción en sistemas que no son de producción es mucho mayor. )

Una vez completada esta exportación, comenzamos la importación en la instancia ECP de QA. Lo ideal sería que el equipo de operaciones de SAP desactivara los registros de rehacer de la base de datos, pero si esto no es posible, podemos estrangular Client Sync utilizando un número menor de procesos. Lo intentamos con cuatro procesos, pero hubo un punto en el que claramente llenamos los registros de la base de datos; pero afortunadamente se recuperó sin ayuda. En el peor de los casos, se habría producido un retraso a la espera de que el equipo de operaciones de SAP borrara algunos registros, pero el rendimiento sería mejor si se desactivaran. Esta es una de nuestras recomendaciones de siempre cuando se trata de Client Sync, pero este es un caso de uso en el que puede ser más flexible, si es necesario, porque los datos de HCM, preferiblemente filtrados sólo en el último par de años de transacciones, suelen ser mucho más pequeños.

Una vez finalizada la importación, pedimos al cliente que activara y validara la replicación. Llegados a este punto, sabíamos que la "copia de seguridad" se había realizado correctamente, y ahora sólo teníamos que pasar a asegurarnos de que ningún dato personal sensible estaría disponible en un entorno de pruebas. ¿Sabías que el Acuerdo de Procesamiento de Datos de SAP establece explícitamente que los datos reales no deben estar presentes en un sistema de pruebas? Paul escribió un blog sobre esto hace un tiempo. En SuccessFactors existe cierta capacidad de enmascaramiento, pero no cubre datos complejos en ECP, como los datos de clúster, por lo que necesitábamos otra parte de DSM para ello.

Proceso técnico: codificación de datos

La capacidad DSM Data Secure™ for SuccessFactors Add-on llegó más recientemente (unos años después de Object Sync Success Factors) y amplía el motor de codificación Data Secure de la pila ABAP para poder leer y devolver valores anonimizados a EC a través de la API OData. Así que esta es la primera vez que lo hemos aprovechado para este proceso. A partir del cliente actualizado, creamos una lista de trabajo de números de persona centrales. El enmascaramiento se realiza a partir de esta lista para garantizar que, si hay varios registros de empleo (varios números de una persona), se procesen juntos y obtengan los mismos valores.

Empezamos a probar nuestra política de enmascaramiento con un puñado de empleados para asegurarnos de que estábamos satisfechos con el resultado antes de procesar demasiados. El enmascaramiento actualiza simultáneamente los datos del PCE, no sólo los infotipos, sino que también aplica los nombres, direcciones, etc. modificados a los resultados de las nóminas agrupadas y ahora desagrupadas. Otra ventaja de tomar sólo los dos últimos años del historial de nóminas es que hay menos datos que enmascarar. El trabajo puede dividirse en varios procesos en segundo plano y reanudarse si se producen errores HTTPS en la interfaz OData. En este ejemplo, agrupar los datos en 5000 o 10.000 grupos parecía ser lo óptimo, con 4-6 procesos para cada ejecución.

Invariablemente, se producen errores con la API OData y se puede acabar con datos que han sido codificados en ECP pero no completamente en EC, a menudo incluyendo el nombre. Data Secure utiliza una lógica de "si es igual, se mantiene igual", lo que significa que una vez que algo no está alineado, el enmascaramiento hará que siga sin estarlo.

Para contrarrestar esta situación, adoptamos un enfoque que desarrollamos en el proyecto anterior, consistente en codificar a los empleados con un valor fijo, como John Doe, para alinear los datos, y luego volver a procesarlos con la opción de generación aleatoria de nombres. También hemos desarrollado una utilidad que ayuda a identificar todos los registros afectados y que muy pronto se convertirá en una utilidad estándar de DSM.

Los extras

La última vez que hicimos esto, también creamos algunas utilidades para arreglar otras cosas que quedaron después de la actualización de la instancia. Los enlaces a documentos son un ejemplo importante. Los propios documentos se sustituyen por un documento ficticio, pero el título del documento persiste. El uso del código de la biblioteca de EPI-USE Labs para crear solicitudes OData permitió la eliminación selectiva de los tipos de archivos adjuntos que podían almacenar datos confidenciales en el nombre del documento, como "la nota del médico de Jane Doe", o documentos disciplinarios.

También necesitábamos una utilidad de eliminación de fotos porque un puñado de empleados había ido más allá de una simple foto de perfil (que SAP elimina opcionalmente como parte de la actualización de la instancia) y había puesto todo su fondo como foto personal suya. Es algo generacional...

Luego, mi extra favorito: antes de que iniciáramos la primera actualización, la organización mantenía un área especial de nóminas que contenía algunos datos de la carga de datos original que se habían adaptado y seguido manteniendo para proporcionar un conjunto de pruebas fácilmente diferenciable. Como se construyó a partir de claves parcialmente reales, los datos chocaban con los datos reales que estábamos bajando con Object Sync. En lugar de intentar conservar los datos, creamos una conversión personalizada que puede tomar cualquier empleado y trasladarlo a esta área especializada en nóminas para formar un conjunto de pruebas segregado. Y, por supuesto, en cualquier momento se pueden volver a copiar desde Producción, con la misma política de enmascaramiento utilizada con Data Secure, para sacarlos de esa área de nóminas y devolverlos a la real.

Esta era nuestra historia. ¿Cómo se hace?

Si tiene EC y ECP, o incluso una nómina local vinculada a EC, ¿cómo hace para actualizar el sistema ABAP cuando actualiza una instancia en EC? Supongo que para organizaciones más pequeñas con unos pocos miles de empleados, la copia de cliente SAP podría funcionar. Si su nómina se encuentra en un sistema con datos FI/LO completos, entonces podría tener que recurrir a una copia completa del sistema.

Con DSM, podríamos evitar una copia del sistema, traer sólo los datos relevantes de HCM e incluso filtrar la nómina y el historial para traer sólo los dos últimos años de datos. Sin embargo, una vez que se dispone de los datos, ¿qué ocurre con la privacidad de los mismos? ¿O se mantienen permisos similares a los de producción en los sistemas de prueba en todo momento?