SAP R / 3 Architecture
Jessica Blake
⚡ Résumé intelligent
SAP R / 3 ArchiL'architecture est une architecture client-serveur à trois niveaux qui sépare les responsabilités de présentation, d'application et de base de données. Cet article explique chaque niveau, ABAP et Java pile de composants, processus de connexion piloté par le répartiteur et les raisons SAP j'ai choisi ce modèle à plusieurs couches.
SAP R / 3 ArchiLa structure sous-tend presque tous les classiques SAP Déploiement d'un ERP. Les sections suivantes expliquent comment les trois niveaux interagissent et comment ABAP et Java Les piles répartissent le travail entre le répartiteur, le serveur de messages et la base de données.
Qu'est-ce que le SAP R/3 ?
SAP R/3 est un système d'entreprise client-serveur construit sur un architecture à trois niveaux composée de trois couches indépendantes :
- Présentation
- Application
- Base de données
- R qui veut dire En temps réel traitement.
- 3 représente le 3 niveaux Modèle architectural.
PC de l'utilisateur (interface utilisateur) : Les utilisateurs accèdent au SAP système à travers SAP Interface graphique ou navigateur web. Seul le client frontal est installé sur la machine de l'utilisateur ; les serveurs d'application et de base de données fonctionnent séparément sur du matériel dédié.
Serveurs d'applications : Les serveurs d'applications exécutent la logique métier. La charge de travail est répartie sur plusieurs serveurs d'applications afin que les utilisateurs reçoivent des réponses plus rapidement en cas de forte charge. Ces serveurs fonctionnent généralement sur une infrastructure distante plutôt que sur les postes de travail des utilisateurs.
Serveur de base de données : Le serveur de base de données stocke et récupère des données en réponse à SQL requêtes générées par ABAP et Java Les services de base de données et d'application peuvent s'exécuter sur la même machine ou sur des hôtes physiques distincts, selon les besoins en capacité.
Pourquoi SAP R/3 utilise-t-il une architecture à 3 niveaux ?
La séparation de la présentation, de la logique métier et du stockage en trois niveaux indépendants donne SAP R/3 présente quatre avantages pratiques par rapport aux conceptions à un ou deux niveaux :
- Évolutivité indépendante : Chaque couche peut être mise à l'échelle indépendamment. Un goulot d'étranglement dans la logique métier est résolu par l'ajout de serveurs d'applications sans toucher au matériel de la base de données.
- Répartition de la charge de travail : Le serveur de messagerie répartit la charge des sessions entrantes entre les serveurs d'applications, empêchant ainsi un serveur unique de devenir un point de contention.
- Protection de la base de données : Les utilisateurs finaux ne se connectent jamais directement à la base de données. Toutes les opérations de lecture et d'écriture transitent par les processus de travail du serveur d'applications, qui standardisent les contrôles d'autorisation, le verrouillage et la journalisation des transactions.
- Upgrade la flexibilité: Le SAP L'interface graphique peut évoluer (clients de bureau, navigateur ou mobiles via SAPUI5) sans modifier le code de l'application ni celui de la base de données.
C’est aussi cette séparation qui permet SAP pour prendre en charge plusieurs systèmes de bases de données back-end, notamment SAP HANA, Oracle, IBM Db2, et Microsoft SQL Server — avec la même base de code applicatif.
SAP R/2 vs SAP R/3 : Comment le Archistructure évoluée
SAP R/2 fonctionnait sur un ordinateur central et utilisait une architecture à deux niveaux où le terminal utilisateur communiquait directement avec la base de données. R/3, lancé en 1992, a introduit une couche applicative dédiée entre le client et la base de données. Les deux versions côte à côte :
| Aspect | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Architecture | Architecture à deux niveaux (ordinateur central + terminal) | Architecture à 3 niveaux (présentation + application + base de données) |
| Hardware | Ordinateur central centralisé | Unix distribué / Windows Serveurs Linux |
| Évolutivité | Vertical uniquement (ordinateur central plus grand) | Horizontal (ajouter des serveurs d'applications) |
| Accès à la base de données | Directement depuis la session utilisateur | Médiation assurée par les processus de travail du serveur d'applications |
| Modèle de programmation | ABAP/4 uniquement | ABAP et Java Side by Side |
Les sections suivantes expliquent en détail chacune des trois couches R/3.
Comprendre différents SAP poules pondeuses
Figure 1 : Les trois SAP Couches R/3 et le trafic qui circule entre elles.
Couche de présentation
Le Couche de présentation contient les composants logiciels qui composent le SAP L'interface graphique (GUI) est l'interface utilisateur du système R/3. Elle assure la communication entre le système et ses utilisateurs, offrant une présentation intuitive pour la saisie et l'affichage des données.
Cette couche transmet les entrées de l'utilisateur au serveur d'applications et affiche les données reçues en réponse. SAP L'interface graphique est en cours d'exécution et reste liée à la session terminale d'un utilisateur dans le système R/3 pendant toute la durée de cette session.
Couche d'application
Le Couche d'application se compose d'un ou plusieurs serveurs d'applications et d'un serveur de messagesChaque serveur d'applications exécute un ensemble de services qui implémentent la logique métier R/3. En théorie, un seul serveur d'applications suffit ; en pratique, les services sont répartis sur plusieurs serveurs pour des raisons de capacité et de redondance.
Le serveur de messagerie coordonne la communication entre les serveurs d'applications. Il transmet les requêtes. tracLe système de groupes de serveurs d'applications ks attribue un serveur approprié à chaque connexion utilisateur en fonction de la charge actuelle. C'est ce qui rend possible la mise à l'échelle horizontale.
Couche de base de données
Le Couche de base de données Il abrite un système de base de données central qui stocke toutes les données utilisées par le système R/3. L'architecture de la base de données comprend deux composants : le système de gestion de base de données (SGBD) et la base de données elle-même. SAP intègre son propre SGBD, SAP HANA, et prend également en charge toutes les principales bases de données commerciales (Oracle, IBM Db2, Microsoft SQL Server).
Toutes les données R/3 (paramètres de personnalisation, code applicatif, définitions d'écran, menus, modules fonctionnels et données d'exécution) résident dans cette base de données. Le code du programme et les objets de conception se trouvent dans une section spéciale appelée… Dépôt R/3; ces « objets de référentiel » sont ce que l’ABAP Workbench lit, écrit et transporte entre les systèmes.
Comprendre les composants de SAP R/3 3 niveaux Architecture
Figure 2 : ABAP + Java Architecture système montrant comment les deux piles partagent l'infrastructure.
Un moderne SAP Une instance NetWeaver peut héberger à la fois ABAP et Java Les piles. Les composants ci-dessous montrent comment chaque pile gère sa propre répartition tout en partageant la passerelle, l'ICM et le pont JCO pour la communication inter-piles.
| Composant | Stack | Rôle |
|---|---|---|
| Serveur de messagerie (ABAP) | ABAP | Coordonne la communication entre les répartiteurs distribués dans le Système ABAP et répartit la charge entre les instances. |
| File d'attente du répartiteur | ABAP | Buffer qui met en attente les demandes entrantes jusqu'à ce qu'un processus de travail soit disponible. |
| Dispatcher | ABAP | Extrait les requêtes de la file d'attente et attribue chacune au type de processus de travail approprié. |
| Processus de travail ABAP | ABAP | Exécuter des étapes de dialogue dans les applications R/3. Les types incluent Dialogue, Mise à jour, Arrière-plan, Spool et Mise en file d'attente. |
| Réseau | Owned | Permet la communication entre SAP systèmes et entre SAP et les systèmes externes via RFC. |
| Tubes de mémoire | Owned | Transmettre des données entre le gestionnaire de communication Internet (ICM) et les processus de travail ABAP. |
| Serveur de messagerie (Java) | Java | Coordonnées Java répartiteurs et processus serveur ; permet la communication au sein du Java cluster d'exécution. |
| Serveur de mise en file d'attente | Java | Gère les verrous logiques définis par Java Code d'application s'exécutant au sein d'un processus serveur. |
| Services centraux | Java | Une spéciale Java Instance de cluster qui gère le verrouillage et la messagerie inter-processus. Une « instance » est un groupe de ressources (mémoire, processus de travail, etc.). |
| Java Dispatcher | Java | Reçoit les demandes des clients et les transmet à Java processus serveur. |
| SDM | Java | Gestionnaire de déploiement logiciel — installe les composants J2EE sur le Java association. |
| Java Processus serveur | Java | Traiter simultanément un grand nombre de requêtes grâce au multithreading. |
| ICM | Owned | Gestionnaire de communication Internet — permet le trafic HTTP, HTTPS et SMTP. SAP peut être consulté depuis un navigateur. |
| JCO | Pont | Java Connecteur — gère la communication entre les Java Le répartiteur et le répartiteur ABAP lorsque les deux piles fonctionnent côte à côte. |
Figure 3 : Catégories de processus de travail ABAP (Dialogue, Mise à jour, Arrière-plan, Spool, Enfilement).
Comment le SAP Le processus de connexion fonctionne ?
Figure 4 : Déroulement étape par étape de la connexion d'un utilisateur SAP Couches de répartition et de processus de travail R/3.
Étape 1) L'utilisateur clique sur le SAP système de SAP interface graphique ; la requête est transmise à l'interface graphique. répartiteur.
Étape 2) La requête atterrit dans le file d'attente des demandesLe répartiteur suit un premier entré, premier sorti règle et attribue la demande au prochain processus de travail disponible.
Étape 3) Un processus de travail du type approprié est attribué. Un utilisateur qui se connecte reçoit un processus de travail de type « Dialogue » ; un rapport d'arrière-plan reçoit un processus de travail d'arrière-plan ; une instruction UPDATE est transmise à un processus de travail de type « Mise à jour ». L'action détermine le type de processus de travail.
Étape 4) Une fois le processus de travail Dialog attribué, les autorisations et les paramètres actuels de l'utilisateur sont roulé dans à la mémoire partagée afin que le processus de travail puisse agir sur les données de l'utilisateur. Lorsque l'étape de dialogue est terminée, ces données sont déployé pour libérer de la mémoire pour l'utilisateur suivant. Une « étape de dialogue » correspond au passage d'un écran à un autre au sein d'une transaction.
Étape 5) Le processus de travail commence par rechercher les données demandées dans la mémoire tampon. Les trouver à cet endroit est appelé une frapper et évite un aller-retour à la base de données, améliorant ainsi le temps de réponse. Son incapacité à le trouver déclenche une manquer et une lecture de base de données. Un taux de succès/échec élevé est le principal facteur contribuant à SAP la performance.
Étape 6) Les données restantes sont extraites de la base de données, et le résultat combiné est renvoyé à la SAP Interface graphique via le répartiteur.
Étape 7) Les données de session de l'utilisateur sont supprimées de la mémoire partagée lors d'une opération finale. déploiement, libérant ainsi la zone mémoire pour la requête suivante.
Le même cycle répartiteur → file d'attente → processus de travail → tampon → déploiement se répète pour chaque interaction utilisateur, quelle que soit l'origine de la requête. SAP Interface graphique, navigateur via ICM ou système externe via la passerelle.
