Com sabeu, SAP ofereix una gamma completa de programari tant per mantenir les dades transaccionals com per processar aquestes dades en sistemes d'anàlisi i informes. En particular, la plataforma SAP Business Warehouse (SAP BW) és un conjunt d'eines per emmagatzemar i analitzar dades amb àmplies capacitats tècniques. Malgrat tots els seus avantatges objectius, el sistema SAP BW té un inconvenient important. Aquest és un cost elevat d'emmagatzematge i processament de dades, especialment notable quan s'utilitza SAP BW basat en núvol a Hana.
Què passa si comenceu a utilitzar com a emmagatzematge algun producte que no sigui SAP i preferiblement un producte OpenSource? A X5 Retail Group vam triar GreenPlum. Això, per descomptat, resol el problema del cost, però al mateix temps sorgeixen problemes immediatament que es van resoldre gairebé per defecte quan s'utilitzava SAP BW.
En particular, com recuperar dades dels sistemes font, que són majoritàriament solucions SAP?
HR Metrics va ser el primer projecte en què va ser necessari resoldre aquest problema. El nostre objectiu era crear un dipòsit de dades de recursos humans i crear informes analítics en l'àrea de treball amb els empleats. En aquest cas, la principal font de dades és el sistema transaccional SAP HCM, en el qual es duen a terme totes les activitats de personal, organitzatives i salarials.
Extracció de dades
A SAP BW hi ha extractors de dades estàndard per als sistemes SAP. Aquests extractors poden recollir automàticament les dades necessàries, controlar-ne la integritat i determinar els deltes de canvi. Aquí, per exemple, hi ha la font de dades estàndard per als atributs dels empleats 0EMPLOYEE_ATTR:
El resultat d'extreure'n dades per a un empleat:
Si cal, aquest extractor es pot modificar per adaptar-se als vostres requisits o es pot crear el vostre propi extractor.
La primera idea que va sorgir va ser la possibilitat de reutilitzar-los. Malauradament, això va resultar ser una tasca impossible. La major part de la lògica s'implementa al costat de SAP BW i no va ser possible separar sense dolor l'extractor a la font de SAP BW.
Es va fer evident que hauríem de desenvolupar el nostre propi mecanisme per extreure dades dels sistemes SAP.
Estructura d'emmagatzematge de dades a SAP HCM
Per entendre els requisits d'aquest mecanisme, primer hem de determinar quines dades necessitem.
La majoria de les dades de SAP HCM s'emmagatzemen en taules SQL planes. A partir d'aquestes dades, les aplicacions SAP visualitzen a l'usuari estructures organitzatives, empleats i altra informació de recursos humans. Per exemple, així és com es veu l'estructura organitzativa a SAP HCM:
Físicament, aquest arbre s'emmagatzema en dues taules: en objectes hrp1000 i en hrp1001 les connexions entre aquests objectes.
Objectes “Departament 1” i “Oficina 1”:
Relació entre objectes:
Hi pot haver un gran nombre d'objectes i tipus de connexions entre ells. Hi ha connexions estàndard entre objectes i connexions personalitzades per a les vostres necessitats específiques. Per exemple, la relació estàndard B012 entre una unitat organitzativa i una posició a temps complet indica el cap d'un departament.
Visualització del gestor a SAP:
Emmagatzematge en una taula de base de dades:
Les dades dels empleats s'emmagatzemen en taules de pa*. Per exemple, les dades sobre esdeveniments de personal d'un empleat s'emmagatzemen a la taula pa0000
Vam decidir que GreenPlum prendrà dades "crues", és a dir. només cal copiar-los de les taules SAP. I directament a GreenPlum es processaran i es convertiran en objectes físics (per exemple, Departament o Empleat) i mètriques (per exemple, recompte mitjà).
Es van definir unes 70 taules, les dades de les quals s'han de transferir a GreenPlum. Després d'això, vam començar a elaborar un mètode per transmetre aquestes dades.
SAP ofereix un nombre bastant gran de mecanismes d'integració. Però la manera més senzilla és que l'accés directe a la base de dades estigui prohibit a causa de les restriccions de llicència. Per tant, tots els fluxos d'integració s'han d'implementar a nivell de servidor d'aplicacions.
El següent problema va ser la manca de dades sobre els registres suprimits a la base de dades SAP. Quan suprimiu una fila de la base de dades, s'elimina físicament. Aquells. la formació d'un delta de canvi basat en el temps de canvi no va ser possible.
Per descomptat, SAP HCM té mecanismes per registrar els canvis de dades. Per exemple, per a la transferència posterior a sistemes receptors, hi ha punters de canvi que registren qualsevol canvi i sobre la base dels quals es forma un Idoc (un objecte per a la transferència a sistemes externs).
Exemple d'IDoc per canviar l'infotipus 0302 per a un empleat amb número de personal 1251445:
O mantenir registres dels canvis de dades a la taula DBTABLOG.
Un exemple de registre per suprimir un registre amb la clau QK53216375 de la taula hrp1000:
Però aquests mecanismes no estan disponibles per a totes les dades necessàries i el seu processament a nivell de servidor d'aplicacions pot consumir molts recursos. Per tant, habilitar massivament el registre a totes les taules necessàries pot provocar una degradació notable del rendiment del sistema.
El següent gran problema van ser les taules agrupades. Les dades d'estimació de temps i nòmines a la versió RDBMS de SAP HCM s'emmagatzemen com un conjunt de taules lògiques per a cada empleat per a cada càlcul. Aquestes taules lògiques s'emmagatzemen com a dades binàries a la taula pcl2.
Clúster de nòmines:
Les dades de les taules agrupades no es poden considerar com una ordre SQL, però requereixen l'ús de macros SAP HCM o mòduls de funcions especials. En conseqüència, la velocitat de lectura d'aquestes taules serà força baixa. D'altra banda, aquests clústers emmagatzemen dades que només es necessiten un cop al mes: la nòmina final i l'estimació del temps. Així que la velocitat en aquest cas no és tan crítica.
Avaluant les opcions per formar un delta de canvis de dades, vam decidir considerar també l'opció de descàrrega completa. L'opció de transferir gigabytes de dades sense canvis entre sistemes cada dia pot no semblar bé. Tanmateix, també té una sèrie d'avantatges: no cal implementar el delta al costat de la font i implementar la incrustació d'aquest delta al costat del receptor. En conseqüència, el cost i el temps d'implementació es redueixen i la fiabilitat de la integració augmenta. Al mateix temps, es va determinar que gairebé tots els canvis en SAP HR es produeixen en un horitzó de tres mesos abans de la data actual. Així, es va decidir optar per una descàrrega completa diària de dades de SAP HR N mesos abans de la data actual i una descàrrega completa mensual. El paràmetre N depèn de la taula específica
i oscil·la entre 1 i 15.
Es va proposar el següent esquema per a l'extracció de dades:
El sistema extern genera una sol·licitud i l'envia a SAP HCM, on es comprova la integritat de les dades i els permisos d'accés a les taules d'aquesta sol·licitud. Si la comprovació té èxit, SAP HCM executa un programa que recull les dades necessàries i les transfereix a la solució d'integració de Fuse. Fuse determina el tema requerit a Kafka i hi transfereix les dades. A continuació, les dades de Kafka es transfereixen a Stage Area GP.
En aquesta cadena, ens interessa el tema de l'extracció de dades de SAP HCM. Vegem-ho amb més detall.
Diagrama d'interacció SAP HCM-FUSE.
El sistema extern determina l'hora de la darrera sol·licitud satisfactòria a SAP.
El procés es pot iniciar mitjançant un temporitzador o un altre esdeveniment, inclòs establir un temps d'espera per esperar una resposta amb dades de SAP i iniciar una sol·licitud repetida. A continuació, genera una sol·licitud delta i l'envia a SAP.
Les dades de la sol·licitud s'envien al cos en format json.
Mètode http: POST.
Exemple de sol·licitud:
El servei SAP supervisa la sol·licitud d'exhaustivitat, compliment de l'estructura SAP actual i disponibilitat del permís d'accés a la taula sol·licitada.
En cas d'error, el servei retorna una resposta amb el codi i la descripció corresponents. Si el control té èxit, crea un procés en segon pla per generar una mostra, genera i retorna de manera sincrònica un identificador de sessió únic.
En cas d'error, el sistema extern el registra al registre. En cas de resposta satisfactòria, transmet l'identificador de sessió i el nom de la taula per a la qual s'ha fet la sol·licitud.
El sistema extern registra la sessió actual com a oberta. Si hi ha altres sessions per a aquesta taula, es tanquen amb un avís registrat.
El treball de fons SAP genera un cursor basat en els paràmetres especificats i un paquet de dades de la mida especificada. La mida del lot és el nombre màxim de registres que un procés llegeix de la base de dades. Per defecte, s'assumeix que és igual a 2000. Si hi ha més registres a la mostra de la base de dades que la mida del paquet utilitzat, després de transmetre el primer paquet, es forma el següent bloc amb el nombre de paquet incrementat i desplaçament corresponent. Els números s'incrementen en 1 i s'envien de manera estrictament seqüencial.
A continuació, SAP passa el paquet com a entrada al servei web del sistema extern. I el sistema realitza controls sobre el paquet entrant. Una sessió amb l'identificador rebut ha d'estar registrada al sistema i ha d'estar en estat obert. Si el número de paquet > 1, el sistema hauria d'enregistrar la recepció correcta del paquet anterior (package_id-1).
Si el control té èxit, el sistema extern analitza i desa les dades de la taula.
A més, si la marca final està present al paquet i la serialització ha tingut èxit, el mòdul d'integració s'avisa sobre la finalització correcta del processament de la sessió i el mòdul actualitza l'estat de la sessió.
En cas d'error de control/anàlisi, l'error es registra i els paquets d'aquesta sessió seran rebutjats pel sistema extern.
Així mateix, en el cas contrari, quan el sistema extern retorna un error, es registra i s'atura la transmissió de paquets.
Per sol·licitar dades del costat de SAP HСM, es va implementar un servei d'integració. El servei s'implementa en el framework ICF (SAP Internet Communication Framework - ). Permet consultar dades del sistema SAP HCM mitjançant taules específiques. Quan es crea una sol·licitud de dades, és possible especificar una llista de camps específics i paràmetres de filtratge per tal d'obtenir les dades necessàries. Al mateix temps, la implantació del servei no implica cap lògica empresarial. Al costat del sistema extern també s'implementen algorismes per al càlcul delta, paràmetres de consulta, monitorització d'integritat, etc.
Aquest mecanisme permet recollir i transmetre totes les dades necessàries en poques hores. Aquesta velocitat està a punt de ser acceptable, per la qual cosa considerem aquesta solució com a temporal, que va permetre cobrir la necessitat d'una eina d'extracció en el projecte.
A la imatge objectiu, per resoldre el problema de l'extracció de dades, s'estan explorant opcions per utilitzar sistemes CDC com Oracle Golden Gate o eines ETL com SAP DS.
Font: www.habr.com