Como sabe, SAP ofrece una gama completa de software tanto para mantener datos transaccionales como para procesar estos datos en sistemas de análisis y generación de informes. En particular, la plataforma SAP Business Warehouse (SAP BW) es un conjunto de herramientas para almacenar y analizar datos con amplias capacidades técnicas. A pesar de todas sus ventajas objetivas, el sistema SAP BW tiene un inconveniente importante. Este es un alto costo de almacenamiento y procesamiento de datos, especialmente notable cuando se utiliza SAP BW basado en la nube en Hana.
¿Qué pasa si comienza a utilizar algún producto que no sea de SAP y preferiblemente un producto OpenSource como almacenamiento? Nosotros en X5 Retail Group elegimos GreenPlum. Esto, por supuesto, resuelve el problema del costo, pero al mismo tiempo surgen inmediatamente problemas que se resolvieron casi de forma predeterminada cuando se utiliza SAP BW.
En particular, ¿cómo recuperar datos de los sistemas de origen, que en su mayoría son soluciones de SAP?
HR Metrics fue el primer proyecto en el que fue necesario solucionar este problema. Nuestro objetivo era crear un depósito de datos de recursos humanos y crear informes analíticos en el área de trabajo con los empleados. En este caso, la principal fuente de datos es el sistema transaccional SAP HCM, en el que se llevan a cabo todas las actividades de personal, organizativas y salariales.
Extracción de datos
En SAP BW existen extractores de datos estándar para sistemas SAP. Estos extractores pueden recopilar automáticamente los datos necesarios, monitorear su integridad y determinar deltas de cambio. Aquí, por ejemplo, está la fuente de datos estándar para los atributos de empleado 0EMPLOYEE_ATTR:
El resultado de extraer datos para un empleado:
Si es necesario, dicho extractor se puede modificar para adaptarlo a sus propias necesidades o se puede crear su propio extractor.
La primera idea que surgió fue la posibilidad de reutilizarlos. Desafortunadamente, esto resultó ser una tarea imposible. La mayor parte de la lógica se implementa en el lado de SAP BW y no fue posible separar fácilmente el extractor en la fuente de SAP BW.
Se hizo obvio que necesitaríamos desarrollar nuestro propio mecanismo para extraer datos de los sistemas SAP.
Estructura de almacenamiento de datos en SAP HCM
Para comprender los requisitos de dicho mecanismo, primero debemos determinar qué datos necesitamos.
La mayoría de los datos en SAP HCM se almacenan en tablas SQL planas. A partir de estos datos, las aplicaciones SAP visualizan al usuario las estructuras organizativas, los empleados y otra información de recursos humanos. Por ejemplo, así es como se ve la estructura organizativa en SAP HCM:
Físicamente, dicho árbol se almacena en dos tablas: en los objetos hrp1000 y en hrp1001 las conexiones entre estos objetos.
Objetos “Departamento 1” y “Oficina 1”:
Relación entre objetos:
Puede haber una gran cantidad de ambos tipos de objetos y tipos de conexiones entre ellos. Hay conexiones estándar entre objetos y conexiones personalizadas para sus necesidades específicas. Por ejemplo, la relación estándar B012 entre una unidad organizativa y un puesto de tiempo completo indica el jefe de un departamento.
Visualización del administrador en SAP:
Almacenamiento en una tabla de base de datos:
Los datos de los empleados se almacenan en tablas pa*. Por ejemplo, los datos sobre eventos de personal de un empleado se almacenan en la tabla pa0000
Decidimos que GreenPlum tomará datos "sin procesar", es decir. simplemente cópielos de las tablas de SAP. Y directamente en GreenPlum se procesarán y convertirán en objetos físicos (por ejemplo, Departamento o Empleado) y métricas (por ejemplo, plantilla media).
Se definieron unas 70 tablas, cuyos datos deben transferirse a GreenPlum. Después de lo cual comenzamos a idear un método para transmitir estos datos.
SAP ofrece una cantidad bastante grande de mecanismos de integración. Pero la forma más sencilla es prohibir el acceso directo a la base de datos debido a restricciones de licencia. Por tanto, todos los flujos de integración deben implementarse a nivel del servidor de aplicaciones.
El siguiente problema fue la falta de datos sobre los registros eliminados en la base de datos de SAP. Cuando elimina una fila en la base de datos, se elimina físicamente. Aquellos. la formación de un delta de cambio basado en el momento del cambio no fue posible.
Por supuesto, SAP HCM tiene mecanismos para registrar cambios de datos. Por ejemplo, para la transferencia posterior a los sistemas destinatarios, existen indicadores de cambio que registran cualquier cambio y sobre cuya base se forma un Idoc (un objeto para transferir a sistemas externos).
IDOC de ejemplo para cambiar el infotipo 0302 para un empleado con número de personal 1251445:
O mantener registros de cambios de datos en la tabla DBTABLOG.
Un ejemplo de un registro para eliminar un registro con la clave QK53216375 de la tabla hrp1000:
Pero estos mecanismos no están disponibles para todos los datos necesarios y su procesamiento a nivel del servidor de aplicaciones puede consumir muchos recursos. Por lo tanto, habilitar masivamente el registro en todas las tablas necesarias puede provocar una degradación notable del rendimiento del sistema.
El siguiente gran problema fueron las tablas agrupadas. Los datos de estimación de tiempo y nómina en la versión RDBMS de SAP HCM se almacenan como un conjunto de tablas lógicas para cada empleado para cada cálculo. Estas tablas lógicas se almacenan como datos binarios en la tabla pcl2.
Clúster de nómina:
Los datos de tablas agrupadas no pueden considerarse como un comando SQL, pero requieren el uso de macros de SAP HCM o módulos funcionales especiales. En consecuencia, la velocidad de lectura de dichas tablas será bastante baja. Por otro lado, estos grupos almacenan datos que sólo se necesitan una vez al mes: nómina final y estimación de tiempo. Entonces la velocidad en este caso no es tan crítica.
Al evaluar las opciones para formar un delta de cambios de datos, decidimos considerar también la opción de la descarga completa. La opción de transferir gigabytes de datos sin cambios entre sistemas todos los días puede no parecer buena. Sin embargo, también tiene una serie de ventajas: no es necesario implementar el delta en el lado de la fuente e implementar la incorporación de este delta en el lado del receptor. En consecuencia, se reducen el coste y el tiempo de implementación y aumenta la fiabilidad de la integración. Al mismo tiempo, se determinó que casi todos los cambios en SAP HR ocurren en un horizonte de tres meses antes de la fecha actual. Así, se decidió optar por una descarga completa diaria de datos de SAP HR N meses antes de la fecha actual y una descarga completa mensual. El parámetro N depende de la tabla específica.
y oscila entre 1 y 15.
Se propuso el siguiente esquema para la extracción de datos:
El sistema externo genera una solicitud y la envía a SAP HCM, donde se verifica que esta solicitud esté completa y tenga permisos para acceder a las tablas. Si la verificación es exitosa, SAP HCM ejecuta un programa que recopila los datos necesarios y los transfiere a la solución de integración Fuse. Fuse determina el tema requerido en Kafka y transfiere los datos allí. A continuación, los datos de Kafka se transfieren al Stage Area GP.
En esta cadena nos interesa el tema de la extracción de datos de SAP HCM. Veámoslo con más detalle.
Diagrama de interacción SAP HCM-FUSE.
El sistema externo determina la hora de la última solicitud exitosa a SAP.
El proceso puede iniciarse mediante un temporizador u otro evento, incluida la configuración de un tiempo de espera para esperar una respuesta con datos de SAP e iniciar una solicitud repetida. Luego genera una solicitud delta y la envía a SAP.
Los datos de la solicitud se envían al cuerpo en formato json.
Método http: POST.
Solicitud de ejemplo:
El servicio SAP supervisa la integridad de la solicitud, el cumplimiento de la estructura actual de SAP y la disponibilidad del permiso de acceso a la tabla solicitada.
En caso de errores, el servicio devuelve una respuesta con el código y la descripción adecuados. Si el control tiene éxito, crea un proceso en segundo plano para generar una muestra, genera y devuelve sincrónicamente una identificación de sesión única.
En caso de error, el sistema externo lo registra en el log. En caso de una respuesta exitosa, transmite la identificación de la sesión y el nombre de la tabla para la cual se realizó la solicitud.
El sistema externo registra la sesión actual como abierta. Si hay otras sesiones para esta tabla, se cierran y se registra una advertencia.
El trabajo en segundo plano de SAP genera un cursor basado en los parámetros especificados y un paquete de datos del tamaño especificado. El tamaño del lote es la cantidad máxima de registros que un proceso lee de la base de datos. De forma predeterminada, se supone que es igual a 2000. Si hay más registros en la muestra de la base de datos que el tamaño del paquete utilizado, después de transmitir el primer paquete, se forma el siguiente bloque con el desplazamiento correspondiente y el número de paquete incrementado. Los números se incrementan en 1 y se envían de forma estrictamente secuencial.
Luego, SAP pasa el paquete como entrada al servicio web del sistema externo. Y el sistema realiza controles sobre el paquete entrante. Una sesión con la identificación recibida debe estar registrada en el sistema y debe estar en estado abierto. Si el número de paquete > 1, el sistema debe registrar la recepción exitosa del paquete anterior (package_id-1).
Si el control tiene éxito, el sistema externo analiza y guarda los datos de la tabla.
Además, si el indicador final está presente en el paquete y la serialización fue exitosa, se notifica al módulo de integración sobre la finalización exitosa del procesamiento de la sesión y el módulo actualiza el estado de la sesión.
En caso de un error de control/análisis, el error se registra y el sistema externo rechazará los paquetes para esta sesión.
Asimismo, en el caso contrario, cuando el sistema externo devuelve un error, se registra y se detiene la transmisión de paquetes.
Para solicitar datos por el lado de SAP HСM, se implementó un servicio de integración. El servicio se implementa en el marco ICF (SAP Internet Communication Framework - ). Le permite consultar datos del sistema SAP HCM utilizando tablas específicas. Al crear una solicitud de datos, es posible especificar una lista de campos específicos y parámetros de filtrado para obtener los datos necesarios. Al mismo tiempo, la implementación del servicio no implica ninguna lógica empresarial. Los algoritmos para calcular delta, parámetros de consulta, monitoreo de integridad, etc. también se implementan en el lado del sistema externo.
Este mecanismo le permite recopilar y transmitir todos los datos necesarios en unas pocas horas. Esta velocidad está a punto de ser aceptable, por lo que consideramos esta solución como temporal, lo que permitió cubrir la necesidad de una herramienta de extracción en el proyecto.
En la imagen de destino, para resolver el problema de la extracción de datos, se están explorando opciones para utilizar sistemas CDC como Oracle Golden Gate o herramientas ETL como SAP DS.
Fuente: habr.com