Un guide de l'intégration des données SAP

Aujourd'hui, le SDI est utilisé dans toutes les solutions Hana et est devenu une évidence pour les clients. Avec l'étape suivante de l'évolution, je voulais réunir l'intégration des données et des processus d'une manière inédite. La technique était enfin suffisamment avancée pour pouvoir réunir les deux catégories de produits. Mais cela s'est heurté à la structure organisationnelle de SAP et n'a pas été retenu.

Aujourd'hui, le sujet de l'intégration est remonté jusqu'au conseil d'administration et le résultat n'est pas très convaincant. Pire encore, je vois de nombreux clients existants de SAP qui résolvent ce problème d'intégration pour eux-mêmes de manière intelligente, c'est-à-dire qu'ils sont déjà plus avancés que SAP lui-même. La touche finale est apportée à ces clients par la solution open source que ma société met à leur disposition.

Par la suite, j'aimerais vous emmener dans un voyage intellectuel sur les connaissances de ces pionniers et sur les points que nous avons encore améliorés.

Système vs. intégration des données

Si l'on considère le portefeuille de produits de SAP, il existe une séparation nette entre l'intégration de processus et l'intégration de données. Dans un cas, on veut relier le système ERP à une autre application, dans l'autre, on veut transférer des contenus de table de A à B. Si l'on demande à un développeur d'applications, il parle d'"entités" comme le partenaire commercial. Dans l'intégration des données, on descend d'un niveau, celui des tables. Cette séparation n'existe pas dans le monde des Big Data. Là, tous les produits peuvent traiter des objets profondément imbriqués et une table de base de données n'est qu'un objet particulièrement simple. D'où la première conclusion : oublions plutôt les outils de base de données et regardons plutôt du côté des produits Big Data.

Batch vs. temps réel

Ensuite, il y a des outils qui transmettent des données de masse par lots, et d'autres sont conçus pour le temps réel. Cette séparation s'explique par des raisons techniques, mais d'un point de vue purement logique, le temps réel est un super-ensemble des deux. Dans le cadre d'un traitement par lots, il n'est jamais possible de transmettre les données à des intervalles aussi courts que l'on veut. Avec un système en temps réel, le traitement par lots est toutefois possible. Cela donne l'impression qu'il ne se passe rien dans une source pendant des heures et qu'un grand nombre de données sont soudainement générées pour un court intervalle. Mais pour cela, l'outil en temps réel doit pouvoir traiter des données en masse - ce qui nous ramène au portefeuille des Big Data.

Si l'on considère la solution sous l'angle de la question de savoir quels systèmes sont couplés à quels autres, il s'agissait plutôt dans le passé d'une relation un à un. Les données SAP ERP vont dans SAP BW. Les données de la saisie des temps atterrissent sous forme d'écritures dans le module SAP HCM. Et c'est exactement ainsi que sont construits les outils SAP. Si cette hypothèse n'était déjà pas forcément correcte auparavant, de très nombreux systèmes consommateurs sont aujourd'hui connectés à chaque système source - et la tendance est à la hausse. Par exemple, les données ERP vont dans SAP BW, dans un Data Lake, dans Ariba, dans Salesforce et dans d'innombrables autres applications d'entreprise intelligentes.

Ainsi, même avec une orchestration des données, comme c'est le cas avec tous les outils SAP, on ne va pas très loin. Il est plus logique que chaque consommateur puisse se servir des données à sa guise, c'est-à-dire une chorégraphie de données. Dans une telle configuration, ce n'est plus le chef d'orchestre qui indique qui doit faire quoi et quand, mais il existe pour chaque objet un canal dans lequel les systèmes peuvent rendre les modifications publiques et d'autres systèmes peuvent consommer les modifications à leur guise.

Par exemple, à chaque modification d'une entrée de partenaire commercial, l'ERP publierait la dernière version et le BW la consommerait une fois par jour en une seule fois. De son côté, une autre application écoute en permanence les modifications apportées à ce topic et peut les intégrer dans sa propre application avec une latence de l'ordre de la milliseconde.

Apache Kafka

Si l'on rassemble toutes ces idées, on arrive inévitablement à Apache Kafka. Ce n'est pas la seule raison pour laquelle Kafka est désormais utilisé par toutes les grandes entreprises et s'impose de plus en plus comme un standard. Si cela fonctionne pour le monde du Big Data, nous pouvons certainement l'utiliser pour les données opérationnelles, n'est-ce pas ?

Apache Kafka se compose essentiellement de "topics", qui représentent le canal de données. Chacun de ces topics peut être partitionné en lui-même afin de permettre la parallélisation des données de masse. Et chaque message de modification a un schéma avec les données correspondantes. Dans notre exemple, il existe donc un schéma "partenaire commercial" avec les données de base telles que le prénom et le nom et toutes les adresses du client y sont imbriquées. Si l'on considère cela du point de vue de l'intégration des données, il s'agit des tables ERP SAP KNA1 avec les données d'adresse ADRC correspondantes. Dans l'intégration des processus, on utilise la structure imbriquée, par exemple via les IDocs SAP ou Bapis.

Cela implique certes un surcroît de travail pour le producteur unique ( !), mais la tâche est beaucoup plus facile pour les nombreux consommateurs. Dans un monde où il y a beaucoup de consommateurs pour chaque domaine, c'est globalement la solution la plus économique.

Mais il ne suffit pas de confier par exemple chaque IDoc à Kafka - et derrière moi le déluge. S'il le faut, il faut mobiliser tout le potentiel. L'une de ces opportunités concerne les changements de structure - la mort de toute solution d'intégration actuelle. Il n'est pas possible d'adapter tous les producteurs et consommateurs de manière synchrone, et il n'est pas non plus judicieux de conserver plusieurs versions de la structure en même temps. C'est pourquoi j'adhère au concept d'évolution des schémas, c'est-à-dire à la capacité d'étendre un schéma sans rien casser.

Le cas le plus simple est facile à expliquer : supposons qu'il y ait deux producteurs et dix consommateurs pour les données de base des partenaires commerciaux. L'un des producteurs, le système SAP, a reçu aujourd'hui un champ Z supplémentaire. Le producteur SAP l'insère dans le schéma officiel et lui donne une valeur par défaut . Désormais, le système SAP peut également envoyer ce champ.

L'autre producteur continue à utiliser la version précédente du schéma pendant les 20 minutes suivantes, jusqu'à ce qu'il se resynchronise. Le passage au nouveau schéma ne le désorganise cependant pas, car ce champ n'existe pas pour lui, il ne le remplit donc pas, il reste donc à . Il n'y a rien à modifier dans ce Producer, il continue simplement à fonctionner comme avant.

Si les consommateurs reçoivent pour la première fois la nouvelle variante de schéma, celle-ci sera désormais utilisée pour lire tous les messages. Ainsi, le champ supplémentaire est toujours présent. Si un ancien message est lu via le nouveau schéma, le champ Z n'est pas dans les données et donc . Dans ce cas également, il n'y a donc pas de complications.

Les consommateurs peuvent à leur tour décider eux-mêmes de la manière dont ils utilisent le nouveau champ. De toute façon, un consommateur d'application n'extrait du schéma que les champs dont il a réellement besoin et le champ Z n'a pour l'instant aucune correspondance dans l'application cible. Un consommateur du Data Lake étend probablement automatiquement la structure cible avec ce champ supplémentaire afin de ne jamais perdre d'informations.

L'évolution des schémas permet donc d'adapter successivement le schéma officiel au fil du temps. Ensuite, il y a les cas où le producteur souhaite envoyer des informations techniques. Pour cela, chaque schéma a une zone d'extension réservée.

En fait, le schéma contient encore quelques informations supplémentaires qui peuvent être intéressantes par la suite : Quel est le système source du message ? À quelles transformations les données ont-elles été soumises ? Comment peut-on évaluer la qualité des données de l'enregistrement ?

Message Queue vs. Kafka Transaction Log

Le cas où un consommateur a vu le champ supplémentaire, mais n'a pas pu l'utiliser, met en évidence un autre problème non résolu : Comment obtenir à nouveau les données déjà chargées ? Avant l'époque de Kafka, on aurait utilisé des files de messages et la seule façon de récupérer toutes les données est de les faire produire à nouveau par la source. Mais elles passent alors par tous les consommateurs, même ceux qui n'y ont aucun intérêt. Si le consommateur suivant est adapté, toutes les données doivent à nouveau être produites. Quelle horreur ! C'est pourquoi les files d'attente de messages ne se sont jamais imposées comme on l'attendait au départ.

La prémisse de notre solution était toutefois que le consommateur puisse décider de ce qu'il lit et quand. Dans ce cas, il devrait également avoir la possibilité de lire à nouveau les données déjà lues. En pratique, on modifierait ce consommateur comme on le souhaite et, au redémarrage, on lui dirait de relire les données des sept derniers jours. Contrairement aux files d'attente de messages, Kafka ne jette pas immédiatement les données, mais est conçu comme un outil de big data pour conserver les messages de modification pendant un certain temps, voire pour toujours.

Cette option est un immense avantage pour de nombreuses autres situations. Par exemple, le développeur peut répéter les mêmes tests autant de fois qu'il le souhaite et obtenir les mêmes données de modification. Ou encore, un nouveau consommateur ne commence pas sans données, mais reçoit dès le premier appel une grande quantité de données.

Si vous êtes également à la recherche d'une solution avantageuse, ouverte et orientée vers l'avenir pour l'intégration de vos différentes applications, vous pouvez vous laisser inspirer sur mon site.