Como sabes, SAP ofrece unha gama completa de software tanto para manter datos transaccionais como para procesar estes datos en sistemas de análise e informes. En particular, a plataforma SAP Business Warehouse (SAP BW) é un conxunto de ferramentas para almacenar e analizar datos con amplas capacidades técnicas. Con todas as súas vantaxes obxectivas, o sistema SAP BW ten un inconveniente importante. Este é un alto custo de almacenamento e procesamento de datos, especialmente notable cando se usa SAP BW baseado na nube en Hana.
E se comezas a usar algún produto que non sexa SAP e preferiblemente un produto OpenSource como almacenamento? Nós en X5 Retail Group escollemos GreenPlum. Isto, por suposto, resolve o problema do custo, pero ao mesmo tempo, inmediatamente xorden problemas que se resolveron case por defecto ao usar SAP BW.
En particular, como recuperar datos dos sistemas fonte, que son principalmente solucións SAP?
HR Metrics foi o primeiro proxecto no que foi necesario resolver este problema. O noso obxectivo era crear un repositorio de datos de RRHH e crear informes analíticos na área de traballo cos empregados. Neste caso, a principal fonte de datos é o sistema transaccional SAP HCM, no que se realizan todas as actividades de persoal, organización e salario.
Extracción de datos
En SAP BW existen extractores de datos estándar para sistemas SAP. Estes extractores poden recoller automaticamente os datos necesarios, supervisar a súa integridade e determinar os deltas de cambios. Aquí, por exemplo, está a fonte de datos estándar para os atributos dos empregados 0EMPLOYEE_ATTR:
O resultado da extracción de datos dun empregado:
Se é necesario, este extractor pódese modificar para adaptarse aos seus propios requisitos ou crear o seu propio extractor.
A primeira idea que xurdiu foi a posibilidade de reutilizalos. Desafortunadamente, isto resultou ser unha tarefa imposible. A maior parte da lóxica está implementada no lado de SAP BW e non foi posible separar sen dor o extractor na orixe de SAP BW.
Fíxose obvio que necesitaríamos desenvolver o noso propio mecanismo para extraer datos dos sistemas SAP.
Estrutura de almacenamento de datos en SAP HCM
Para comprender os requisitos para tal mecanismo, primeiro necesitamos determinar que datos necesitamos.
A maioría dos datos en SAP HCM almacénanse en táboas SQL planas. En base a estes datos, as aplicacións SAP visualizan estruturas organizativas, empregados e outra información de recursos humanos para o usuario. Por exemplo, este é o aspecto da estrutura organizativa en SAP HCM:
Fisicamente, tal árbore almacénase en dúas táboas: en obxectos hrp1000 e en hrp1001 as conexións entre estes obxectos.
Obxectos “Departamento 1” e “Oficina 1”:
Relación entre obxectos:
Pode haber un gran número de ambos tipos de obxectos e tipos de conexións entre eles. Hai conexións estándar entre obxectos e outras personalizadas para as túas necesidades específicas. Por exemplo, a relación estándar B012 entre unha unidade organizativa e un posto a tempo completo indica o xefe dun departamento.
Visualización do xestor en SAP:
Almacenamento nunha táboa de base de datos:
Os datos dos empregados gárdanse en táboas de pa*. Por exemplo, os datos sobre eventos de persoal dun empregado gárdanse na táboa pa0000
Decidimos que GreenPlum tomará datos "en bruto", é dicir. só cópiaos das táboas SAP. E directamente en GreenPlum procesaranse e converteranse en obxectos físicos (por exemplo, Departamento ou Empregado) e métricas (por exemplo, o persoal medio).
Definíronse unhas 70 táboas, dos que hai que trasladar os datos a GreenPlum. Despois, comezamos a elaborar un método para transmitir estes datos.
SAP ofrece un número bastante grande de mecanismos de integración. Pero o xeito máis sinxelo é que o acceso directo á base de datos está prohibido debido ás restricións de licenza. Así, todos os fluxos de integración deben implementarse a nivel de servidor de aplicacións.
O seguinte problema foi a falta de datos sobre os rexistros eliminados na base de datos SAP. Cando elimina unha fila da base de datos, elimínase fisicamente. Eses. non foi posible a formación dun delta de cambio baseado no momento do cambio.
Por suposto, SAP HCM ten mecanismos para rexistrar os cambios de datos. Por exemplo, para a transferencia posterior a sistemas receptores, hai punteiros de cambio que rexistran calquera cambio e en base aos cales se forma un Idoc (obxecto para transferir a sistemas externos).
Exemplo de IDoc para cambiar o infotipo 0302 para un empregado con número de persoal 1251445:
Ou manter rexistros de cambios de datos na táboa DBTABLOG.
Un exemplo de rexistro para eliminar un rexistro coa clave QK53216375 da táboa hrp1000:
Pero estes mecanismos non están dispoñibles para todos os datos necesarios e o seu procesamento a nivel de servidor de aplicacións pode consumir bastantes recursos. Polo tanto, habilitar masivamente o rexistro en todas as táboas necesarias pode levar a unha degradación notable do rendemento do sistema.
O seguinte gran problema foron as táboas agrupadas. A estimación do tempo e os datos de nómina na versión RDBMS de SAP HCM gárdanse como un conxunto de táboas lóxicas para cada empregado para cada cálculo. Estas táboas lóxicas almacénanse como datos binarios na táboa pcl2.
Clúster de nóminas:
Os datos das táboas agrupadas non se poden considerar un comando SQL, pero require o uso de macros SAP HCM ou módulos de funcións especiais. En consecuencia, a velocidade de lectura destas táboas será bastante baixa. Por outra banda, estes clústeres almacenan datos que só se necesitan unha vez ao mes: nómina final e estimación do tempo. Polo que a velocidade neste caso non é tan crítica.
Avaliando as opcións para formar un delta de cambios de datos, decidimos considerar tamén a opción da descarga total. A opción de transferir gigabytes de datos sen cambios entre sistemas todos os días pode non parecer boa. Non obstante, tamén ten unha serie de vantaxes: non hai necesidade de implementar o delta no lado fonte e implementar a incorporación deste delta no lado do receptor. En consecuencia, o custo e o tempo de implementación redúcense e aumenta a fiabilidade da integración. Ao mesmo tempo, determinouse que case todos os cambios en SAP HR ocorren nun horizonte de tres meses antes da data actual. Así, decidiuse optar por unha descarga completa diaria de datos de SAP HR N meses antes da data actual e unha descarga completa mensual. O parámetro N depende da táboa específica
e oscila entre 1 e 15.
Propúxose o seguinte esquema para a extracción de datos:
O sistema externo xera unha solicitude e envíaa a SAP HCM, onde se verifica a integridade dos datos e os permisos para acceder ás táboas desta solicitude. Se a comprobación ten éxito, SAP HCM executa un programa que recolle os datos necesarios e os transfire á solución de integración Fuse. Fuse determina o tema necesario en Kafka e transfire os datos alí. A continuación, os datos de Kafka transfírense a Stage Area GP.
Nesta cadea, interésanos o tema da extracción de datos de SAP HCM. Vexámolo con máis detalle.
Diagrama de interacción SAP HCM-FUSE.
O sistema externo determina a hora da última solicitude exitosa a SAP.
O proceso pódese iniciar mediante un temporizador ou outro evento, incluíndo establecer un tempo de espera para esperar unha resposta con datos de SAP e iniciar unha solicitude de repetición. Despois xera unha solicitude delta e envíaa a SAP.
Os datos da solicitude envíanse ao corpo en formato json.
Método http: POST.
Exemplo de solicitude:
O servizo SAP supervisa a solicitude de integridade, cumprimento da estrutura SAP actual e dispoñibilidade de permisos de acceso á táboa solicitada.
En caso de erros, o servizo devolve unha resposta co código e descrición adecuados. Se o control ten éxito, crea un proceso en segundo plano para xerar unha mostra, xera e devolve de forma sincronizada un ID de sesión único.
En caso de erro, o sistema externo rexistrao no rexistro. En caso de resposta satisfactoria, transmite a identificación da sesión e o nome da táboa para a que se fixo a solicitude.
O sistema externo rexistra a sesión actual como aberta. Se hai outras sesións para esta táboa, pechanse cun aviso rexistrado.
O traballo en segundo plano de SAP xera un cursor baseado nos parámetros especificados e nun paquete de datos do tamaño especificado. O tamaño do lote é o número máximo de rexistros que un proceso le da base de datos. Por defecto, asúmese que é igual a 2000. Se hai máis rexistros na mostra da base de datos que o tamaño do paquete utilizado, despois de transmitir o primeiro paquete, fórmase o seguinte bloque co número de paquete incrementado e compensado correspondente. Os números increméntanse en 1 e envían de forma estrictamente secuencial.
A continuación, SAP pasa o paquete como entrada ao servizo web do sistema externo. E o sistema realiza controis sobre o paquete entrante. Unha sesión co identificador recibido debe estar rexistrada no sistema e debe estar en estado aberta. Se o número de paquete > 1, o sistema debería rexistrar a recepción correcta do paquete anterior (package_id-1).
Se o control ten éxito, o sistema externo analiza e garda os datos da táboa.
Ademais, se a marca final está presente no paquete e a serialización foi exitosa, o módulo de integración é notificado sobre a finalización exitosa do procesamento da sesión e o módulo actualiza o estado da sesión.
No caso de producirse un erro de control/análise, o erro rexístrase e os paquetes desta sesión serán rexeitados polo sistema externo.
Así mesmo, no caso contrario, cando o sistema externo devolve un erro, este rexístrase e detense a transmisión de paquetes.
Para solicitar datos do lado de SAP HСM, implantouse un servizo de integración. O servizo está implementado no marco ICF (SAP Internet Communication Framework - ). Permítelle consultar datos do sistema SAP HCM mediante táboas específicas. Ao crear unha solicitude de datos, é posible especificar unha lista de campos específicos e parámetros de filtrado para obter os datos necesarios. Ao mesmo tempo, a implantación do servizo non implica ningunha lóxica empresarial. No lado do sistema externo tamén se implementan algoritmos para calcular delta, parámetros de consulta, vixilancia da integridade, etc.
Este mecanismo permítelle recoller e transmitir todos os datos necesarios en poucas horas. Esta velocidade está a piques de ser aceptable, polo que consideramos esta solución como temporal, que permitiu cubrir a necesidade dunha ferramenta de extracción no proxecto.
Na imaxe de destino, para resolver o problema da extracción de datos, estanse explorando opcións para usar sistemas CDC como Oracle Golden Gate ou ferramentas ETL como SAP DS.
Fonte: www.habr.com