Philosophie

La différence de philosophie entre SAP et Oracle Applications est très bien résumée par cette remarque de Ray Wang, reprise par Olivier Rafal : SAP conçoit un Mac, Oracle assemble un PC.
Autrement dit : SAP veut tout faire de A à Z (interfaces, base, administration...) et verrouille ses interfaces, alors qu’Oracle procède plutôt par agrégat de briques interconnectées, disponibles seules, dont l’utilisateur peut faire un peu ce qu’il veut.

La base

Oracle vend des bases de données avant tout, il a donc bâti son ERP autour de cette base, en exploitant ses spécificités (l’ERP a cependant toujours une génération de retard sur la base et les outils annexes, par conservatisme et par nécessité de migrer et certifier une telle masse de code).
Les tables sont directement accessibles depuis le code source du programme en PL/SQL.

SAP considère que la base de données peut être n’importe quoi : Oracle, SQL Server, DB2, MySQL... Oui, même MySQL (qui existe sous la forme de MaxDB dans le monde SAP) (Correction : En fait, MaxDB n’a rien à voir avec la base MySQL. Ça semblait gros quand même...). SAP rajoute donc sa couche d’administration de la base, impose de passer par une version maison appauvrie du SQL pour interroger la base, et interdit toute modification sous-jacente au niveau SQL.
Ironie de l’histoire : l’essentiel des installations de SAP tourne cependant sous Oracle (par sécurité et panurgisme), et rapportent donc de l’argent au concurrent principal...

Langage : SAP et l’ABAP

SAP est basé sur un langage spécifique, utilisé nulle part ailleurs, qui fleure bon le néolithique de l’informatique, à savoir l’ABAP. Il paraît que cela ressemble au Cobol avec quelques notions simplettes de SQL.

Il est basé sur les notions de « structure » (un enregistrement de base de données en fait, par exemple une ligne de commande), que l’on manipule dans des tables internes, et que l’on synchronise à l’occasion avec les vraies tables de la base de données. Les jointures sont lourdes, et récupérer des données consiste souvent à récupérer un jeu de lignes, le parcourir, et réeffectuer des requêtes pour chaque ligne.

Le langage a tout ce qu’il faut pour être qualifié de langage de programmation, mais il manque beaucoup de « sucre syntaxique » apparu depuis les années 1990. Comme je l’ai déjà évoqué, l’environnement de développement est un éditeur imposé, intégré, basique et sans fioriture qui connaît à peine la coloration syntaxique des commentaires. Programmer en ABAP me fait l’effet de programmer avec un boulet aux pieds.

Langage : Oracle et PL/SQL

Oracle Applications (l’ERP) est basé sur le PL/SQL, le langage intégré à Oracle (la base). On peut aussi utiliser du Java, mais ce n’est pas si courant, du moins sur les modules les moins récents.

Le PL/SQL a l’avantage d’être un véritable langage, sans doute pas aussi souple et riche que du .Net ou du Ruby, mais plutôt un mariage heureux entre le Pascal et le SQL, qui évolue peu à peu et, je pense, dans la bonne direction, sans trop de fioritures inutiles. Un avantage majeur est que l’on interagit directement avec les données sans couche intermédiaire qui freine ou impose ses limites ; on profite de toutes les fonctionnalités d’Oracle (la base)[1]. Les « tables internes » ne servent que dans certains cas précis d’optimisation (mise à jour en masse), puisque la base optimise déjà le commun des requêtes toute seule. La création de « requêtes de feu » de plusieurs pages n’est pas un problème ; le principe est de sous-traiter au maximum à la base de données puisqu’on est très proche d’elle.

Le PL/SQL est conçu pour manipuler des données mais est assez « généraliste », pas réduit à ne travailler qu’avec l’ERP. Exécuter du code d’un autre langage (hors de la base cependant, donc au niveau du système d’exploitation) n’est pas un problème, c’est prévu.

Serveurs d’application et autres monstres

Oracle Application inclut un serveur d’application maison, genre d’objet que je connais très mal par ailleurs. SAP mitonne son équivalent, Netweaver, mais je ne connais pas d’environnement où Netweaver soit utilisé indépendamment de SAP.

À côté de tout ça, chacun a son essaim d’outils annexes, modules optionnels, portails webs, etc.

Sous le capot

Le modèle de données n’a rien à voir, et de ceci que je vais parler la prochaine fois…

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] Et vu le prix de la licence, c’est bien la moindre des choses...