Mais que faire si vous commencez à utiliser un produit non SAP et de préférence OpenSource comme stockage? Chez X5 Retail Group, nous avons choisi GreenPlum. Ceci, bien sûr, résout le problème de coût, mais dans le même temps, des questions surgissent immédiatement qui, lors de l'utilisation de SAP BW, ont été résolues presque par défaut.
En particulier, comment récupérer les données des systèmes sources, qui sont pour la plupart des solutions SAP?
HR Metrics a été le premier projet à résoudre ce problème. Notre objectif était de créer un entrepôt de données RH et de construire des rapports analytiques dans le domaine du travail avec les employés. Dans ce cas, la principale source de données est le système transactionnel SAP HCM, dans lequel toutes les activités liées au personnel, à l'organisation et aux salaires sont menées.
Extraction de données
Il existe des extracteurs de données standard dans SAP BW pour les systèmes SAP. Ces extracteurs peuvent collecter automatiquement les données nécessaires, suivre leur intégrité et déterminer les deltas des modifications. Par exemple, voici une source de données standard pour les attributs des employés 0EMPLOYEE_ATTR:
Résultat de l'extraction des données à partir de celui-ci un employé à la fois:
si nécessaire, un tel extracteur peut être modifié pour répondre à vos propres besoins, ou votre propre extracteur peut être créé.
La première idée est née de la possibilité de leur réutilisation. Malheureusement, cela s'est avéré une tâche impossible. La plupart de la logique est implémentée côté SAP BW et il n'a pas été possible de séparer sans douleur l'extracteur à la source de SAP BW.
Il est devenu évident qu'il serait nécessaire de développer un mécanisme personnalisé pour extraire les données des systèmes SAP.
Structure de stockage des données dans SAP HCM
Pour comprendre les exigences d'un tel mécanisme, vous devez d'abord déterminer le type de données dont nous avons besoin.
La plupart des données de SAP HCM sont stockées dans des tables SQL plates. Sur la base de ces données, les applications SAP visualisent les structures organisationnelles, les employés et d'autres informations RH pour l'utilisateur. Par exemple,
voici à quoi ressemble une structure organisationnelle dans SAP HCM: Physiquement, une telle arborescence est stockée dans deux tables - dans les objets hrp1000 et dans hrp1001 les liens entre ces objets.
Objets "Département 1" et "Bureau 1":
Communication entre objets:
Il peut y avoir un grand nombre de types d'objets et de types de communication entre eux. Il existe à la fois des liens standard entre les objets et des liens personnalisés pour vos propres besoins spécifiques. Par exemple, la relation B012 standard entre une unité organisationnelle et un poste à temps plein indique le chef de service.
Mappage du gestionnaire dans SAP:
Stockage dans la table DB: les
données des employés sont stockées dans les tables pa *. Par exemple, les données sur les activités de dotation d'un employé sont stockées dans la table pa0000.
Nous avons décidé que GreenPlum prendra des données "brutes", c'est-à-dire copiez-les simplement à partir des tables SAP. Et déjà directement dans GreenPlum, ils seront traités et convertis en objets physiques (par exemple, Département ou Employé) et en métriques (par exemple, effectif moyen).
Environ 70 tables ont été définies, dont les données doivent être transférées vers GreenPlum. Après cela, nous avons commencé à trouver un moyen de transférer ces données.
SAP propose un assez grand nombre de mécanismes d'intégration. Mais le moyen le plus simple - l'accès direct à la base de données est interdit en raison des restrictions de licence. Ainsi, tous les flux d'intégration doivent être implémentés au niveau du serveur d'application.
Le problème suivant était le manque de données sur les enregistrements supprimés dans la base de données SAP. Lorsqu'une ligne est supprimée de la base de données, elle est supprimée physiquement. Ceux. la formation d'un delta de changements au cours de la période de changement n'était pas possible.
Bien entendu, SAP HCM dispose de mécanismes pour valider les modifications de données. Par exemple, pour une transmission ultérieure aux systèmes, les destinataires disposent de pointeurs de changement qui enregistrent les changements et sur la base desquels un Idoc est formé (un objet pour la transmission à des systèmes externes).
Exemple d'IDoc pour la modification de l'infotype 0302 pour le salarié avec matricule 1251445:
ou gestion des journaux de modification des données dans la table DBTABLOG.
Un exemple de journal de suppression d'une entrée avec la clé QK53216375 de la table hrp1000:
Mais ces mécanismes ne sont pas disponibles pour toutes les données nécessaires, et leur traitement au niveau du serveur d'application peut consommer beaucoup de ressources. Par conséquent, l'inclusion massive de la journalisation sur toutes les tables nécessaires peut entraîner une dégradation notable des performances du système.
Les tables groupées étaient le prochain problème majeur. L'estimation du temps et les données de paie dans la version SGBDR de SAP HCM sont stockées sous la forme d'un ensemble de tables logiques par employé et par paie. Ces tables logiques sont stockées sous forme de données binaires dans la table pcl2.
Cluster de paie: les
données des tables en cluster ne peuvent pas être lues par une commande SQL, mais nécessitent l'utilisation de macros SAP HCM ou de modules de fonction spéciaux. En conséquence, la vitesse de lecture de ces tableaux sera assez faible. D'un autre côté, ces clusters stockent des données qui ne sont nécessaires qu'une fois par mois - la paie finale et l'estimation du temps. Donc, la vitesse dans ce cas n'est pas si critique.
En évaluant les options avec la formation d'un delta de changement de données, nous avons décidé d'envisager également l'option avec déchargement complet. La possibilité de transférer chaque jour des gigaoctets de données inchangées entre les systèmes ne peut pas être jolie. Cependant, il présente également un certain nombre d'avantages - il n'est pas nécessaire à la fois de mettre en œuvre le delta du côté de la source et de mettre en œuvre l'incorporation de ce delta du côté du récepteur. En conséquence, le coût et le temps de mise en œuvre sont réduits, et la fiabilité d'intégration est augmentée. Dans le même temps, il a été déterminé que presque tous les changements dans SAP HR se produisent à l'horizon de trois mois avant la date actuelle. Ainsi, il a été décidé de s'arrêter à un téléchargement quotidien complet des données de SAP HR N mois avant la date actuelle et à un téléchargement mensuel complet. Le paramètre N dépend du tableau spécifique
et va de 1 à 15.
Le schéma suivant a été proposé pour l'extraction des données:
Un système externe génère une demande et l'envoie à SAP HCM, où cette demande est vérifiée pour l'exhaustivité des données et l'autorisation d'accéder aux tables. Si le contrôle réussit, SAP HCM exécute un programme qui collecte les données nécessaires et les transfère à la solution d'intégration Fuse. Fuse définit le sujet requis dans Kafka et y transmet les données. Ensuite, les données de Kafka sont transférées vers le Stage Area GP.
Dans cette chaîne, nous nous intéressons à la problématique de l'extraction des données de SAP HCM. Attardons-y plus en détail.
Diagramme d'interaction SAP HCM-FUSE.
Le système externe détermine l'heure de la dernière demande réussie à SAP.
Le processus peut être démarré par une minuterie ou un autre événement, y compris un délai d'attente pour une réponse avec des données de SAP et le lancement d'une demande répétée. Ensuite, il génère une requête delta et l'envoie à SAP.
Les données de la demande sont transmises dans le corps au format json.
La méthode http: POST.
Exemple de demande:
le service SAP vérifie l'exhaustivité de la demande, la conformité avec la structure SAP actuelle et la disponibilité de l'autorisation d'accéder à la table demandée.
En cas d'erreur, le service renvoie une réponse avec le code et la description appropriés. Si le contrôle réussit, il crée un processus d'arrière-plan pour générer une sélection, génère et renvoie de manière synchrone un identifiant de session unique.
Le système externe l'enregistrera en cas d'erreur. En cas de réponse réussie, il envoie l'identifiant de session et le nom de la table sur laquelle la demande a été faite.
Le système externe enregistre la session en cours comme ouverte. S'il existe d'autres sessions pour cette table, elles sont fermées avec un avertissement consigné.
Le travail d'arrière-plan SAP génère un curseur en fonction des paramètres spécifiés et un paquet de données de la taille spécifiée. Taille du paquet - le nombre maximal d'enregistrements que le processus lit dans la base de données. Par défaut, il est supposé être 2000. Si l'échantillon de base de données contient plus d'enregistrements que la taille de paquet utilisée, après la transmission du premier paquet, le bloc suivant est formé avec le décalage correspondant et le numéro de paquet incrémenté. Les nombres sont incrémentés de 1 et envoyés de manière strictement séquentielle.
Ensuite, SAP transmet le paquet comme entrée au service Web du système externe. Et c'est le système qui contrôle le paquet entrant. Une session avec l'ID reçu doit être enregistrée dans le système et elle doit être dans un état ouvert. Si le numéro de colis est> 1, le système doit enregistrer la réception réussie du colis précédent (package_id-1).
En cas de contrôle réussi, le système externe analyse et enregistre les données de la table.
De plus, si l'indicateur final est présent dans le package et que la sérialisation a réussi, le module d'intégration est informé de la réussite du traitement de session et le module met à jour l'état de la session.
En cas d'erreur de contrôle / d'analyse, l'erreur est enregistrée et les paquets pour cette session seront rejetés par le système externe.
De même, dans le cas contraire, lorsque le système externe renvoie une erreur, il est journalisé et la transmission des paquets est arrêtée.
Un service d'intégration a été mis en place pour demander des données côté SAP HM. Le service est implémenté sur le framework ICF (SAP Internet Communication Framework - help.sap.com/viewer/6da7259a6c4b1014b7d5e759cc76fd22/7.01.22/en-US/488d6e0ea6ed72d5e10000000a42189c.html ). Il vous permet d'interroger des données du système SAP HCM sur des tables spécifiques. Lors de la formation d'une demande de données, il est possible de spécifier une liste de champs spécifiques et de paramètres de filtrage afin d'obtenir les données nécessaires. Dans le même temps, la mise en œuvre du service n'implique aucune logique métier. Des algorithmes de calcul delta, de paramètres de requête, de contrôle d'intégrité, etc. sont également mis en œuvre du côté du système externe.
Ce mécanisme vous permet de collecter et de transférer toutes les données nécessaires en quelques heures. Cette vitesse est à la limite de l'acceptable, c'est pourquoi nous considérons cette solution comme temporaire, ce qui a permis de couvrir le besoin d'un outil d'extraction sur le projet.
Dans l'image cible pour résoudre le problème d'extraction de données, les options d'utilisation des systèmes CDC tels que Oracle Golden Gate ou des outils ETL tels que SAP DS sont en cours d'élaboration.