5.1 L'environnement de developpement SAP
Pour comprendre combien le spécifique SAP peut
être a la fois simple et puissant, il faut connaltre son environnement de
déve loppement.
L'architecture SAP est une architecture 3
tiers.
Figure 76 - Architecture 3 tiers de SAP
(Source
SAP)
Chaque serveur d'app lication exécute des
programmes ABAP, et communique avec les autres composants, la base de
données, et avec d'éventue ls autres serveurs d'app lication via
un serveur de messages.
Figure 77 - Les serveurs d'application
(Source
SAP)
|
Le contrôle ATP - du progicie l integre a la
solution specifique
|
|
|
En plus des workprocesses, dont le nombre est
determine au demarrage du serveur, le serveur d'app lication contient un
dispatcher, une passere lle et une memoire partagee. Leur role est le suivant
:
Workprocesses : ce sont des composants capab
les d'executer une application. Chacun est lie a une zone memoire qui contient
le contexte de l'execution (les donnees en cours). Le lien entre les
workprocesses et un utilisateur est assure par le dispatcher.
Dispatcher : c'est le lien entre les
workprocesses et les utilisateurs connectes. Son role est de recevoir des
requetes de dialogue des clients (les SAP Gui) et de leur affecter des
workprocesses disponib les. De la meme maniere il dirige un ecran de sortie
jusqu'a l'utilisateur originaire de la requete.
Passere lle (« Gateway ») : c'est
l'interface pour les protoco les de communication (RFC, CPI/C). Elle peut
communiquer avec d'autres serveurs d'app lication du meme systeme, avec
d'autres systemes SAP, ou avec des systemes externes (non SAP).
Memoire partagee : chaque workprocess dispose
de sa propre zone memoire, mais tous ont ega lement acces a une zone memoire
commune pour sauvegarder les contextes ou pour bufferiser des donnees. Les
ressources des workprocesses (comme les programmes ou le contenu des tables)
sont stockees en memoire partagee. La gestion de la memoire garantit que chaque
workprocess adresse le bon contexte, c'est-h-dire les donnees correspondant a
l'etat du programme en cours d'execution. Ce qui permet de reduire les
copies.
La structure des serveurs d'app lication decrite ici
donne a ABAP sa performance. Le nombre de workprocesses et la repartition des
etapes de dialogue optimisent l'utilisation de la memoire, et l'independance
des workprocesses fait qu'ils sont appropries a une architecture mu
ltiprocesseurs.
La bufferisation des donnees reduit le nombre de
lectures en base de donnees, reduisant considerab lement les temps de reponse
des programmes ABAP.
Pour une utilisation optima le du buffer, on peut aussi
concentrer des applications dans des groupes de serveurs d'app lications
distincts.
|
Le contrô le ATP - du progicie l
intégré a la solution spécifique
|
|
|
ABAP interprete un « Open SQL >> pour
l'acces a la base de données. Le SQL natif est aussi possible mais a
éviter ; pour la portabilité bien sur, mais aussi pour les
performances (pas de log, pas de bufferisation) et a cause de problemes sur
certains types de données (LRAW notamment).
Figure 78 - L'acces a la base de donnees
(Source
SAP)
Notons enfin qu'il est possible d'interfacer ABAP avec
l'incontournab le Eclipse.
Figure 79 - ABAP Eclipse Editor 1.2.4
(Source
Eclipse)
| 
