(Caveat : Des notions de maniement de bases de données ne nuiront pas à la compréhension de ce qui suit. - Addendum : Je parle plus en détail et en théorie des différences entre clés fonctionnelles et arbitraires dans ce billet)
Oracle Applications
Le schéma de données est à peu près normalisé ; les noms de table sont en anglais, à peu près explicites. Chaque ligne porte un identifiant numérique, distinct de celui vu par l’être humain sur un écran ou un rapport. Bref, une conception comme on l’enseigne aux étudiants de première année d’informatique.
Par exemple, la table des en-têtes de commande OE_ORDER_HEADERS a comme
clé primaire un identifiant numérique ORDER_HEADER_ID, et un numéro de commande utilisateur ORDER_NUMBER.
Cet ORDER_HEADER_ID sert de clé externe pour une jointure sur la table des lignes de commandes, OE_ORDER_LINES, dont la clé est ORDER_LINE_ID.
Pour être compréhensible par un humain, une ligne (un enregistrement dans la table), possède les champs LINE_NUMBER (valeur démarrant à 1) et SHIPMENT_NUMBER (idem).
Ce sont ces deux dernières valeurs qui s’affichent sur un écran ou un rapport, les clés réelles ne sont utiles qu’aux développeurs.
Exemple : par le ORDER_HEADER_ID 175321, je peux joindre les deux tables
et récupérer les identifiants apparents de la commande, par exemple ORDER_NUMBER = 1000
et LINE_NUMBER = 1 et SHIPMENT_NUMBER = 1.
Un ORDER_NUMBER possède ses contraintes de numérotation (telle plage pour tel type de business par exemple) mais l’ORDER_HEADER_ID, identifiant unique de l’enregistrement, est unique et peut valoir ce qu’il veut. En général c’est une valeur abstraite mais « compréhensible » par un humain, genre 175321. Idem pour l’ORDER_LINE_ID, par exemple 321000.
À première vue, doublonner les identifiants numériques et les identifiants visibles semble inutile et ne facilite pas le travail du développeur ; mais au contraire cela offre une souplesse complète, les identifiants numériques pouvant être manipulés à volonté sans conséquence visible pour l’utilisateur[1]. De plus, chacune des tables principales n’a ainsi qu’une seule colonne en clé primaire, ce qui simplifie bien des choses[2].
Petit bonus également pour le développeur : avec un peu d’habitude d’une base précise, il sait qu’un ORDER_HEADER_ID tourne autour de 170-180000, un ORDER_LINE_ID de 320000, et les reconnaît au premier coup d’oeil.
De la même manière, il sait vite que la colonne ORDER_TYPE_ID des en-têtes de commande pointe vers OE_ORDER_TYPES, et que la valeur 74 correspond par exemple au type de commande « Petit électroménager » dans telle installation de tel revendeur d’électroménager.
Le seul inconvénient que je connaisse est que la mise en place sur différentes bases du même paramétrage (par exemple création d’un nouveau type de commande sur les bases de développement, recette et production) mène à des différences d’identifiants numériques (sauf coup de bol). Ce n’est pas censé être un problème si on programme proprement (ne jamais mettre ces identifiants « en dur » dans un programme), et si on rafraîchit suffisamment souvent ses bases de développement et recette[3].
Donc au final un schéma très propre, forcément touffu vu le nombre de tables impliquées, qui a cependant la mauvaise habitude de devenir de plus en plus tordu avec le temps et les nouvelles fonctionnalités. La pire aberration que j’ai rencontrée provient de lots de données qui migrent de table en table suivant l’état du statut au sein du flux logistique. Il y a peut-être une raison profonde mais cela jure avec la cohérence du reste.
SAP R/3
Le modèle de données de R/3 est à la fois plus simple et plus cauchemardesque.
Comme dit dans un précédent billet, R/3 (l’ERP « classique ») utilise surtout des tables dont les noms inspirés de l’allemand ont quatre lettres, du genre MARA, VBAK, LIKP, T001...
Dans ces tables il n’y a pas d’identifiant numérique comme sous Oracle. La clé primaire est fonctionnelle. Pour VBAK (les en-têtes de commande), cette clé est composée des champs MANDT (le mandant, qui en quelque sorte identifie la base de travail[4]) et de VBELN, le document commercial visible par l’utilisateur !
Évidemment, dans VBAP, correspondant aux postes (lignes de commandes), ce même VBELN sera répercuté pour identifier ce qui correspond à une commande donnée. Et la clé primaire de cette table des postes est un triplet MANDT, VBELN, POSNR.
De même, la table TVAK des types de commande contient la valeur de type directement
dans sa clé.
En conséquence, renommer un objet sous SAP revient à renommer sa clé primaire ! Ça ne se fait pas à la légère, sous peine de corrompre les données. Donc, sous SAP, on ne modifie jamais rien directement dans les tables[5] ! Le système fait d’ailleurs de son mieux pour l’interdire au développeur, et il faut utiliser les fonctions, BAPIs, BADIs, IDOCs, user exits, programmes d’import... livrés avec le système.
Pire : la clé « fonctionnelle » utilisée ici n’est plus un moyen de vérifer l’unicité ou la destruction d’un enregistrement. Supposons une ligne de commande (clé : VBELN+POSNR) créée, puis détruite (pas logiquement, mais physiquement et totalement), puis récréée avec le même numéro de poste (ligne)[6]. Un programme extérieur[7] ne peut savoir si une ligne qu’il a mémorisée (par sa clé VBELN+POSNR) est la même ou pas.
Sous Oracle, le ORDER_LINE_ID aurait totalement disparu, et un nouveau aurait été recréé, même si l’utilisateur a choisi de conserver les mêmes LINE_NUMBER et SHIPMENT_NUMBER.
Il y a plus vicieux. L’utilisateur verra à l’écran un document de vente numéroté 18500, alors que la base stockera en réalité dans VBELN la chaîne 0000018500 (dix caractères). Forcer la taille de la chaîne a un intérêt en terme de classement (sans cela, 1869 serait entre 18500 et 18695), mais pour le développeur c’est un petit cauchemar : chaque variable est susceptible de contenir la chaîne avec ou sans ses zéros initiaux et il faut convertir à gogo (sachant que le moindre appel de fonction en ABAP fait cinq lignes et qu’elles ne peuvent pas être imbriquées les unes dans les autres sur la même ligne comme dans la plupart des langages de programmation).
Encore plus drôle : les nouveaux modules, en premier lieu le CRM mais aussi des morceaux de R/3, ont décidé de prendre en compte les avancées du dernier quart du siècle dernier en matière de bases de données, et de passer aux identifiants numériques !
Mais dans une optique d’universalité (sans doute pour faciliter la fusion de bases SAP différentes), ces identifiants sont des GUID (global identifier), en hexadécimal, du genre de 447072A2FB800063000000000A1F352F.
Allez déboguer des programmes où la moitié des variables sont des identifiants de ce genre...
Le plus drôle c’est que ces GUID apparaissent parfois à l’utilisateur (abomination peut-être liée au paramétrage là où je travaille).
Enfin, pour compliquer la tâche, SAP interdisant tout accès à Oracle (la base, qui en général tourne derrière) et imposant ses propres outils de développement, une bonne partie des outils de contrôle d’Oracle sont inaccessibles. Adieu les bonnes grosses requêtes de contrôle du bon déroulement d’un programme qui impliquaient dix tables...[8]
Verdict
Travailler avec Oracle avait ses bons côtés ; j’ai beaucoup de mal à apprécier SAP pour le développement. Autant SAP est en avance par son interface perfectible mais fonctionnelle, et l’effroyable panel de possibilités, autant Oracle permet au développeur de faire ce qu’il veut pour intervenir sur les données ou rajouter des programmes, sans lui mettre de bâtons dans les roues. Mais on demande rarement son avis au développeur lors du choix d’un ERP...
Partie 1 : Des interfaces hideuses
Partie 2 : Deux gros patchworks
Partie 3 : Des interfaces très particulières
Partie 4 : Philosophies opposées
Partie 5 : Schémas de données
Notes
[1] Encore un niveau en dessous, Oracle identifie l’enregistrement sur le disque dur par un autre identifiant, le ROWID, qui suit le même principe, et est susceptible de modification à tout moment, en cas de réorganisation des données. L’utilisateur de la base de donneés (le développeur) n’a en général pas à se préoccuper de ce ROWID.
[2] Les tables de correspondance notamment peuvent avoir des clés composées, et rien n’interdit de rajouter des index à volonté sur les autres colonnes (au contraire).
[3] Et là on s’aperçoit que c’est une opération lourde ; je travaille actuellement avec une base de développement vieille d’un an au bas mot, et mon client précédent attendait souvent six mois pour rafraîchir son Oracle.
[4] Je simplifie. Un mandant indique une vision du monde, et on peut ainsi collectioner les mandants dans une même base de données SAP : mandant de paramétrage, mandant de développement ne comportant que des programmes, mandant de test comportant des données. Lourd mais pratique. Chaque clé primaire de table commence par le mandant.
[5] Exception pour les tables ajoutées par l’utilisateur que SAP à proprement parler ignore.
[6] Je suis d’accord que ça ne devrait pas pouvoir se faire, mais l’utilisateur peut le faire, et il le fera.
[7] Comme celui que je suis en train d’écrire au moment où je rédige ceci.
[8] De plus se pose le problème des droits d’accès à la base, forcément restreints dans ce contexte...
19 réactions
1 De giao - 05/09/2006, 18:47
merci pour ce début de commencement d'explication sur les différences intrinsèques entre Oracle et SAP. Je travaille sur OAP depuis 1999 et je trouve ton exposé très pertinent. Malheureusement, ma connaissance de SAP est nulle mais l'étude comparée permet d'en concevoir quelques aspects. bien cordialement.
2 De Le webmestre - 05/09/2006, 20:44
Et bien giao, profite d’Oracle tant que tout le monde n’est pas encore passé sous SAP :o)
3 De JELMANS - 23/10/2006, 21:34
bonjour..pourriez vous m'avoir les codes et types de mouvements pour sap r/3 de magasinage du stock... out-ind-mix-ensachage produits ect.....merci a+++
4 De Raspberry92 - 09/11/2006, 17:40
Bonjour,
savez vous si il est possible de récupérer les datamodels de ces deux ERP ?
Cordialement,
5 De Le webmestre - 09/11/2006, 17:54
Raspberry92 > Les modèles de données complets comportent des milliers de table. Et cela dépend du nombre de modules installés. Dans le cas d’Oracle, on peut se débrouiller un peu avec les nom, mais le modèle de SAP R/3 est vraiment cryptique, avec ses noms de tables de 4 lettres, acronymes de mots en allemand. C’est pour quelle utilisation ?
Soit dit en passant, toutes les docs que j’ai vues sur le sujet indiquent que l’information est confidentielle (non que ce soit vraiment un joyau, mais la chose doit ).
6 De UKRAINIEN - 12/02/2007, 13:17
Bonjour,
Le principe de SAP se résume en 3 mots : intégrité, portabilité, scalabilité. Pour ce qui concerne l'intégrité, je ne répondrai que sur la partie développement, c'est mon métier et il y a déjà beaucoup à dire.
Si vous allez intégrer directement dans les tables, c'est tout à faite possible, mais vous ne respecterez pas les règles métiers définies par le consultant fonctionnel. Les réintégrer dans un programme est refaire le travail du consultant fonctionnel, ou de SAP.
Les problèmes que vous présentez dans la gestion des données concerne un problème de réplication, avec des données modifiées. Cela se gère très bien dans SAP, en passant par les fonctions adéquates, ou même dans un programme spéficique, à la condition de connaitre les bonnes zones.
Il est vrai qu'il n'est pas toujours facile de travailler avec SAP, et on peut parfois s'arracher les cheveux. Mais si SAP est numéro 1, ce n'est pas pour rien. Il a aussi de nombreux avantages.
Vous aurez en juillet/aout prochain un livre en français sur l'ABAP, qui présentera les concepts SAP. J'en suis l'auteur. Aux editions ENI.
7 De Le webmestre - 12/02/2007, 20:47
@UKRAINIEN : Il faut distinguer deux choses dans le développement : la logique interne, et la facilité de le faire avec des outils correct. Pour la première, c’est un choix ; la seconde en découle cependant directement même si ce n’est que de la « technique » ; une erreur de design et un programme marche, mais en claudiquant.
SAP a choisi de ne pas tenir compte de décennies de recherche sur les bases de données (car fondamentalement c'en est une, avec des tables bien rangées), et de s'en tenir à un modèle de données antédiluvien (développé il y a longtemps) ou démentiellement moderne (CRM) ; idem pour le langage qui a des limites et une rigidité qui ne se sont plus de ce siècle, et rendent le développement très pénible pour qui est attaché à un minimum d’élégance et de compacité ; les outils sont plus ou moins imposés et représentent un patchwork de générations différentes, et ce ne sont pas les plus récents les mieux conçus (j’ai une haine particulière pour le pourtant récent Smartforms) ; la base sous-jacente est sous-exploitée (le SQL de l’ABAP n’arrive pas à la cheville de celui de la base Oracle sous-jacente ) ; l’interface est le type même de ce qu’il ne faut pas faire en ergonomie. Il est clair qu’une masse énorme de travail permet à la chose de tenir debout, mais c'est d'abord à sa richesse fonctionnelle qu’elle le doit (et là, chapeau). Je ne nie pas que quelques gadgets embellissent parfois la vie (je regretterai les matchcodes), mais si peu... La doc ne manque pas mais elle est boursouflée et très lourde. Les interfaces de programmation (fonctions, BAPIs, user exits...) se sont empilées au fil des modes et leur maniement est parfois délicat ou abscons. Dernier et très gros reproche, les standards sont totalement méprisés sur à peu près tous les plans (SAP se veut le standard).
En tant que développeur, ce fut un calvaire, mais comme je l’ai dit, je ne suis pas la cible et la facilité de développement n’est pas l’argument de vente.
8 De cleopatre - 25/02/2007, 22:35
bonjour, je recherche un livre en francais pour Abap.Merci d'avance j'en ai vraiment besoin.à bientôt.
9 De Le webmestre - 26/02/2007, 19:14
@cleopatre: En français ??? Heu... Désolé, j'en connais pas. De toute façon dans ce métier faut savoir acheter en anglais voire ici en allemand...
10 De Heptaeon - 08/05/2007, 21:52
Je suis a 100% de ton avis. SAP a la même politique que IBM avec ses mainframes. On sais comment ça a terminé.
De mon coté je cherche l'ERP qui remuera les hautes sphères. Un ERP saint et clair (de conception), Ergonomique et Accessible, avec des technologie d'avenir, qui ne font pas de protectionisme sur l'information, et qui ont une politique commercial du win/win plutôt que de la sangsue.
ps: Pour ceux qui diront que SAP ne disparaitra jamais, je leur dirais que certaine société sont toujours sur mainframe.
11 De urainien - 25/06/2007, 11:09
Bonjour,
Pour cléopatre et les autres, allez sur www.fnac.com, mon livre est en prévente. Méthode de formation sur l'ABAP, en français. Méthode éprouvée depuis 3 ans, et avec les remerciements d'une grande SSII.
Le titre est SAP et ABAP, aux éditions ENI. Un accès est sur mon site.
Pour ceux qui le souhaitent, j'ai mis en place des forums sur l'ABAP, une base de connaissance sur l'ABAP, le tout en accès libre.
Cordialement,
Yann SZWEC
PS : mon objectif n'est pas de convertir le webmestre à l'ABAP (:))
12 De FrédéricLN - 25/01/2009, 19:10
Bonsoir et… merci. Formé aux SGBD il y a plus d’une décennie, j’avais entrepris de me remettre à jour avec des bouquins, mais on en apprend bien plus et bien plus vite sur ce blog ;-)
(PS - je sais bien que pour former un développeur, ce blog ne suffirait pas tout à fait, mais mon ambition est plus modeste, niveau utilisateur éclairé, focalisé sur les données elles-mêmes).
13 De Le webmestre - 27/01/2009, 15:12
@FrédéricLN : Focalisé sur les données ? On va souvent être d’accord alors, j’ai une vision des choses très orientée « SQL über alles ». Voir notamment le tag « SQL » à gauche.
14 De renommeur - 13/06/2009, 11:00
J'ai passé mes deux dernières années de ma vie à renommer environ 16000 comptes utilisateurs SAP sur 70 systèmes et 220 mandants. Car le nom d'utilisateur est en même temps sa clé. Il y a environ une quarantaine d'objets liées à cette clé, dont un bon nombre en 1:1 (et non pas 1:n ce qui rendrait la tâche plus simple). J'ai donc développé une solution en ABAP qui gère le processus de renommer un utilisateur, y compris la génération et l'envoi d'email de son nouveau compte et mot de passe avec un message en la langue de l'utilisateur.... je migre les favoris, variantes ALV, variantes programmes, parametrage du workbench, L'infotype 0105/0001, le business partner (à travers la central person), planstellen, autorisations etc. etc. Donc j'ai du boulot grâce à SAP! Mais je suis d'accord que tout cela aurait était trivial si SAP avait un identificateur technique distincte du nom d'utilisateur... si vous voulez renommer vos utilisateurs et en passant faire de l'ordre dans ces comptes - contactez moi...
15 De Le webmestre - 13/06/2009, 20:26
@renommeur : Condoléances. Perdre 2 ans de vie à ce genre de choses, j’aurais pas supporté. J’espère que ton système est réutilisé ailleurs...
16 De loockheed - 17/02/2010, 11:59
Oui SAP est destiné au business et pas au developpeur. Au moins avec SAP on se retrouve pas avec une montagne de dev specificique buggé et inexploitable.
17 De Le webmestre - 18/02/2010, 18:58
@lookcheed : C'est une blague ? L'amoncellement de spécifiques est un défaut propre à l'organisation et non au logiciel. J'ai connu des clients qui avaient tellement patché SAP qu'ils étaient incapables de migrer aux nouvelles versions, il a déjà fallu remigrer à la version classique.
Quand au spécifique buggé, c'est pire sous SAP à cause de ce langage de merde qu'est l'ABAP (y a plusieurs billets sur le sujet).
18 De Arialia - 15/06/2010, 11:40
Merci beaucoup pour cet article très intéressant.
Je comprends enfin ce qu'est SAP et plains tout ceux qui ont à migrer des 'ERP' maisons vers SAP, mon mari est dans ce cas et je comprends maintenant son désarroi et celui de ses collègues utilisateurs habitués depuis 2000 à de jolies interfaces fonctionnelles et réalisées en fonction de leurs besoins, tout ça parce qu'un commercial à réussi à vendre SAP à un haut dirigeant qui n'a même pas vu le produit ...
Il m'a parlé des limitations d'interrogation de Sap où tout doît être prévu à l'avance, quelle régression face à la solution SGBDR/application spécifique/Infocentre (Bi-Query ou Bussinessobject avant son rachat)
Si au moins SAP fournissait quelque chose clés en mains du genre les logiciels de Ciel qui aurait permis de se passer des programmeurs , mais c'est apparemment loin d'être le cas ...
Bref quel intérêt de prendre SAP?
19 De Le webmestre - 15/06/2010, 19:18
@Arialia : Ah, SAP n'a pas le mérite de la souplesse, et surtout veut que tout passe par lui, et à sa sauce. Quant à s'intégrer à l'ergonomie du XXIè siècle… ils savent pas faire.
Au passage, il y a un inconvénient aux jolies interfaces fonctionnelles à façon : elles sont souvent spécifiques, donc soit à maintenir en interne, soit faites par un plus ou moins petit éditeur qui, lui, a forcément d'autres failles, le premier étant le manque de ressources disponibles sur le marché sur son produit (alors que du personnel SAP, chaque SSII en a).
Quant à Ciel ou autres, j'ai lu assez de messages d'horreur à leur sujet, mais je ne connais pas de première main. Ce n'est pas le même marché. Ce qui n'est pas une excuse pour SAP, l'ergonomie est universelle (ou devrait l'être). Mais l'investissement ne se justifie pas puisqu'on vend à des gens qui jugent les fonctionnalités, pas l'utilisation quotidienne (le contraire du particulier ou du petit entrepreneur).
Ah oui : se passer des programmeurs est possible même avec SAP. Mais il faut décider de se limiter à ce que sait faire le produit. Et il faut quand même le paramétrer. Éternel débat entre prêt-à-porter et sur mesure :-) (Réponse rapide : prendre du standard quand ce n'est pas le cœur de métier, faire du spécifique quand on a de bonnes compétences ou que c'est un point qui permettra de se différencier de la concurrence.)