Discussion :

[ricobye]

Bonjour à tous

Mon client souhaiterait attaquer directement par le PL/SQL les tables oracle générées lors de l'installation de SAP pour extraire des données faisant ainsi l'économie de développements ABAP.
Pourriez vous m'expliquer les avantages et inconvénients d'un tel choix? JE pense pour ma part que c'est pas tres judicieux mais n'est helas pas d'argument convaincant.

Merci d'avance pour vos conseils.

Cordialement

[ludovic.fernandez]

Non, en effet, l'argument n'est pas tres judicieux puisqu'il sera tres difficile de maintenir des donnees consistentes sur la base de donnees. Le schema relationnel des tables SAP est loin de permettre de telles manipulations.

De plus, le gros interet de SAP est de permettre une abstraction des couches base de donnees afin de se concentrer essentiellement sur la logique applicative : la manipulation d'index, la creation des vues sont generalement fournient par SAP. Enfin lors de l'installation, les tables les plus importantes sont vides puisque le systeme n'a pas encore ete peuple de donnees metiers.

Bref, je ne comprend pas pourquoi aller dans cette direction.
L.

[ricobye]

Bonjour

Merci JohnDoeBrother pour ce post. Le client voudrait faire des économie et a donc eu cette illumination merveilleuse. Comment le convaincre de son erreur?
Les tables à l'installation de SAP sont bien vide mais une fois le progiciel implementé, elles contiennent bien des données. Je prend l'exemple de la MARA:
Par code abap j'ai bien des données en faisant un select * from mara
En attaquant la base oracle directement avec un editeur basic comme TOAD, l'instruction select * from mara me retourne les memes données.

Comment expliquer au client qu'il faut payer des Abapeur pour le select en ABAP alors que ces internes peuvent le faire a partir de procédure stockées PL/SQL?

Pas facile tous ca...

Merci d'avance pour vos arguments, j'en ai vraiment besoin pour ne pas qu'il fasse une bétise.

Cordialement

Eric

[ludovic.fernandez]

Je ne comprend pas : si SAP est implemente, cela signifie qu'a un moment donne, quelqu'un a fait quelquechose en ABAP, des BAPIs, IDocs ou autres reports afin de permettre l'utilisation du progiciel. Si ton client sait implementer un SET_DATA, il doit pouvoir faire de meme d'un GET_DATA.

Le principal probleme que je vois a directement taper dans les bases reside a la fois dans la non connaissance du schema relationnel de la base et dans le principe de gestion de la base completement supervisee par une couche SAP-DB invisbile pour l'utilisateur. C'est cette couche qui permet de gerer en l'occurence la problematique de multi-instances, de clustering, de buffering ou autre. Sous DB-Oracle, elle met directement en relation les work processes ABAP avec les shadow processes d'Oracle, elle gere les COMMIT en real-time et en tache differee. Elle regle le probleme de range order par des mecanismes propres : encore une fois, je parle d'une base de donnee evoluee comme Oracle ou DB2, pour les autres comme MS SQL, c'est une veritable catastrophe de se passer de Open SQL!!! Il serait plus rapide de former les developpeurs PL-SQL a l'environement SAP.

Il y a bien d'autres manieres d'economiser sur un projet informatique bien plus judicieuses que d'imposer des contraintes techniques aussi pointues. Et apres, qui maintiendra ce bordel de PL/SQL non conforme a SAP lors d'une upgrade ?

L.

[ricobye]

Il y a bien d'autres manieres d'economiser sur un projet informatique bien plus judicieuses que d'imposer des contraintes techniques aussi pointues. Et apres, qui maintiendra ce bordel de PL/SQL non conforme a SAP lors d'une upgrade ?

L.

Eh oui je partage cette idée mais bon le client est décideur. Il me faut donner des argument forts...

Un nouvelle question s'il vous plait: Est ce vrai que SAP maintient un model de donnée logique qui fait que certaines tables au sens fonctionnel sont reparties sur différentes tables physiques?

Cordialement
Eric

[ludovic.fernandez]

Oui tout depend de la solution mais c'est generalement le cas aussi.
A titre d'exemple, regardez la documentation sur les pool / cluster tables.

Personnellement, je ne travaille qu'avec des solutions qui utilisent des couches d'abstraction afin de permettre d'optimiser l'acces aux tables. Parfois meme, certaines tables n'existent pas (cas ST-A/PI) : elles sont juste un hachage de l'information contenu dans une table plus generique.

L.

[ricobye]

... Parfois meme, certaines tables n'existent pas (cas ST-A/PI) : elles sont juste un hachage de l'information contenu dans une table plus generique.

L.

Est ce a dire que certaines tables présentent dans le dictionnaire de donnée SAP n'existent pas dans la base de donnée Oracle?

[ludovic.fernandez]

Oui.

[ukrainien]

Bonjour,

Si ton client veut passer par le PL/SQL, cela veut dire qu'il veut transférer les données vers une autre application, non SAP. C'est possible, mais toutes les réponses précédentes sont correctes.
Le format des données stockées n'est pas forcément le même que celui qui est présenté à l'utilisateur. Il va devoir refaire toutes les routines de conversion, ce qui va demander du temps, et il va devoir le maintenir, sans garanties, si ce n'est la sienne. Autrement dit, cela va coûter beaucoup de temps, donc de l'argent et au moindre problème, il engagera sa responsabilité.
La perennité de ce travail est douteux.

Le problème est qu'il a argumenté en ne regardant que le transfert d'une table. avec des tables liées, où le format de données va poser un problème, je n'aimerai pas être à sa place.