|
|
SAP |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
SAP |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1. Présentation du
système de SAP
SAP R/3
est un logiciel standard et intégré pour les industries indépendantes, il
couvre, intègre, et connecte toutes les fonctions de l’entreprise.
SAP est
l’abréviation de “Systeme, Anwendungen,
Produkte”, qui se traduit par Système d’application de production.
Les
Fonctions de base de cet ERP sont les suivantes :
1.1
Les modules du système R/3
Voici le périmètre de gestion couvert par
chacun de ces modules de SAP :
Figure 6 :
Modules chez SAP
Le module MM
(Material Management) :
C’est le module logistique de SAP. Il gère les achats d’articles et les stocks
d’articles (les mouvements de stocks : entrées et sorties, transferts de
stocks).
MM permet en particulier le calcul des besoins, la gestion des achats et des
réapprovisionnements mais aussi des demandes d’achat et des contrats.
Le module PP
(Production Planning) :
Le module PP (Production
Planning) concerne la gestion de la Production.
Ce module permet de gérer des nomenclatures de produits et des gammes de
produits d’un point de vue du suivi de la production.
Le module SD (Sales and Distribution):
C’est le
module d’administration des ventes.
Ce module gère les appels d'offres, les offres, les contrats, les commandes
clients, les expéditions et livraisons, les remises, la facturation et le
système d'information commercial.
Il s’adapte aux spécificités des produits vendus par les entreprises. Par
exemple, dans le cas d’une entreprise industrielle qui vend des outils, il
permet de gérer différents types de remises. Dans le cas d’une Maison
d’Edition, on peut le paramétrer pour le calcul des droits d’auteur.
Le module QM (Quality
Management) :
C’est le module de gestion de la qualité de SAP. Il permet la planification des
contrôles qualité et la documentation des démarches qualité.
Le module PM (Plant
Maintenance), adapté aux entreprises industrielles, gère :
§
La maintenance préventive et curative de l’usine
§
La description du référentiel technique, des postes techniques et
des équipements
§
Le traitement des ordres de maintenance
§
Les confirmations d'achèvements
§
Les historiques
Le module FI
(Financial) :
Ce module comptable contient toutes les écritures comptables de ventes,
d’achats et d’immobilisations, qui se centralisent dans la comptabilité
générale.
Le module CO
(Costing) traite la comptabilité analytique.
C’est le module de contrôle de gestion de l’entreprise.
Il permet l’analyse des coûts par centre de profits, par catégorie de
produits/services/projets. Il calcule les coûts de production. Il permet
l’édition du compte de résultat, d’états de reporting et d’analyses
financières.
Le module PS (Project
System) concerne la gestion des projets.
Il permet de suivre les budgets prévisionnels et les coûts réels des projets.
Il permet de gérer les plannings des projets. On peut y importer des fichiers
venant de MS Project et d’Excel. Il s’intègre avec les modules PM, PP et CO.
Le module TR Treasury
permet de gérer les flux de trésorerie et les paiements.
Le module IM Investments
Management est dédié à la gestion des Investissements financiers.
CATS (Cross Application
Time Sheet) est une grille de saisie des temps permettant de lier différents
modules (PS, HR, CO...)
Le
module HR de SAP permet de gérer les recrutements, les paies des
employés, les compétences des employés, de suivre les temps de travail et les
évolutions de carrière, de gérer les demandes et les frais de déplacement.
1.2 L’interface « SAPgui »
Fenêtre
de connexion aux serveurs :
Les
entreprises internationales sont souvent décomposées en différentes branches,
selon l’activité de l’usine un serveur est dédié.
Figure 7 : SapGui
connexion
Fenêtre
d’identification utilisateur :
Figure 8 :
Identification SapGui
Index des
transactions SAP :
Figure 9 : SapGui arborescence des transactions
Figure 10 :
Blocage des tables par utilisateurs
Figure 11 :
Planification d’un produit sur ligne de production
1.3 ABAP : un langage propriétaire à SAP
Le
système R/3 inclus une transaction permettant d’accéder à un outil de
développement « WorkBench », il permet d’accéder aux programmes
écrits en ABAP.
Figure 12 : WorkBench
L'acronyme ABAP signifiant à l'origine Allgemeiner BerichtsAufbereitungsProzessor (processeur générique pour la préparation de
rapport) et a par la suite été anglicisé en Advanced Business
Application Programming. L'ABAP est l'un des successeurs du COBOL
et est apparu dans les années 1980 dans la vague des langages de quatrième génération.
L'ABAP permet de réaliser :
Des rapports : Ils sont constitués en général d'un
écran de sélection de données et d'une liste affichant le résultant.
Des transactions :
Elles sont constituées d'une succession d'écrans appelées Dynpro, chaînés entre
eux par un programme contenant la logique de la transaction.
Des fonctions : Il
s'agit de sous-programmes contenant la description d'une fonctionnalité du
système.
Voici un exemple de code ABAP pour
une transaction :
REPORT
Z_XX_TRANSACTION.
*
* -- Declaration
de données
*
TABLES:
TSTC,
"Tables des transactions
TSTCT.
"Tables de leurs descriptions
* Tables internes
pour l'exemple
DATA X_TSTC LIKE TSTC OCCURS 10 WITH
HEADER LINE.
DATA X_TSTCT LIKE TSTCT OCCURS 10 WITH HEADER LINE.
" -- Début de
la déclaration de l'écran de sélection
SELECT-OPTIONS S_TCODE FOR TSTC-TCODE OBLIGATORY.
' -- Début de
l'extraction des données
*
START-OF-SELECT.
*
REFRESH: X_TSTC, X_TSTCT.
SELECT * FROM TSTC INTO TABLE X_TSTC
WHERE TCODE IN S_TCODE.
SELECT * FROM TSTCT INTO TABLE
X_TSTCT
WHERE TCODE IN S_TCODE
AND SPRAS = SY-LANGU.
*
TOP-OF-PAGE.
*
"
-- Haut de page (sur chaque page)
WRITE / 'Programme exemple: liste de
transactions '.
SKIP.
"Saut de ligne
ULINE.
"Ligne continue
*
END-OF-PAGE.
*
"
-- Bas de page (sur chaque page)
ULINE.
END-OF-SELECTION.
" -- Liste principale
LOOP AT
X_TSTC.
"Boucle sur les transactions
" Recherche de la description
READ TABLE X_TSTCT WITH KEY TCODE =
X_TSTC-TCODE.
IF SY-SUBRC NE 0. " Erreur
WRITE : /
"Saut de ligne
SY-VLINE,
"Barre verticale
X_TSTC, SY-VLINE, "Code
puis barre
(25) '-- Pas de description --' "Largeur du texte
spécifiée
SY-VLINE.
"Barre verticale
ELSE.
WRITE : /
"Saut de ligne
SY-VLINE,
"Barre verticale
X_TSTC, SY-VLINE, "Code
puis barre
(25) X_TSTCT-TTEXT,
"Description sur 25 caractères
SY-VLINE.
"Barre verticale
ENDIF.
ENDLOOP.
Cette partie propose une étude
technologique sur le système R/ 3 de l’éditeur SAP.
2. Etude technique :
architecture du système R/3
2.1. Un système multi tiers
Le noyau du système R/3 ainsi que ces services
supports on été développé principalement en C et C++, cependant certaines
parties sont écrites en ABAP.
Toutes
les applications du progiciel ont été écrite en ABAP, et sont exécutées sous le
système R/3. Les programmes en ABAP communiquent avec la RDBMS (database
management system of the central relational database) et l’interface graphique
utilisateur (SAPgui).
On
n’a appelé ce système d’information R/3 car c’est un système multi tiers
client/serveur. C'est-à-dire que chaque
composant logiciel est organisé en tiers ou en fonction.
Voici les différents acteurs du
system R/3 :
Figure 13 : Les différentes couches
- Les utilisateurs et les processus
d’administration :
Le system R/3 est multi-utilisateur,
et chaque utilisateur exécute plusieurs applications indépendantes.
- Les accès a la base de donnée :
Chaque
système R/3 est en liaison avec une base de données qui est constituée de la
DBMS (database managment system) ainsi que le stockage des données. Les applications ne communiquent pas
directement avec la base de données, elles utilisent les services et
applications situés dans la couche application.
- La communication :
Le
système R/3 peut communiquer avec d’autre system R/ 3 et avec des systèmes
qui ne sont pas de SAP. R/3 utilise les protocoles : RFC, CPI/C, TCP/IP.
L’architecture du système R/3 se
décompose donc en 3 couches principales :
Figure 14 : Architecture
système R/3
La Couche base de donnée / « Database Layer » :
C’est
la base de données centrale contenant toutes les données du système R/3. Elle a
elle même deux composants : la DBMS database management et la base de donnée
elle-même. SAP ne vend pas des bases de données mais son système R/3 supporte
toutes les bases de données suivantes :
-
ADABAS
D
-
DB2/400 (on AS/400)
-
DB2/Common Server
-
DB2/MVS
-
INFORMIX
-
Microsoft SQL Server
-
ORACLE
et ORACLE Parallel Server.
La
base de données ne contient pas les données maîtres et les transactions de
l'application. Mais elle contient les contrôles et les données de configuration
qui détermineront comment le système R/3 fonctionnera ainsi que le code des
programmes des applications.
Les
applications sont constituées de codes, définitions, écrans, menus, modules de
fonction, et d’autres composants…
Ces dernières données sont
stockées dans une section spéciale de la base de données, appelez « R/3
Repository » ou « Repository objects ».
La couche
application / « Application Layer » :
Elle
est constituée de un ou plusieurs serveurs d’applications et de serveurs de
message. Chacun de ces deux serveurs a une série de services utilisés pour
démarrer le système d’information.
Théoriquement on a besoin d’un seul serveur d’applications
pour démarrer le système R/3, mais en pratique les services sont distribués
dans plusieurs serveurs d’applications. Cela signifie que tous les serveurs ne
fourniront pas tous les mêmes services.
Le
serveur de message, lui, est responsable de la communication entre les serveurs
d’applications et a aussi des informations concernant les groupes de serveurs
d’applications, ils utilisent ces informations pour choisir par exemple le
serveur sur lequel un utilisateur pour être amener à se connecter.
La couche présentation / « Presentation Layer » :
Elle
contient les composants logiciel qui construisent l’interface graphique
utilisateur, pour SAP c’est le « SAPgui ». Cette exécutable interface
les utilisateurs et le système R/3, il sert à l’affichage et à l’entrée des
données. Tant que SAPgui est lancé l’utilisateur est connecté au système R/3.
§
Les avantages de l’architecture Multi
tiers
Le
flux de données à travers ces 3 couches montre que le système chargé est bien
reparti, cela n’apporte que des performances. Dans les systèmes précédents le
chargement du système et des données était très lourd. L’architecture du system
R/3 dans lequel la couche application et la couche base de données sont
séparées, permet d’installer ces différentes couches sur différents ordinateurs. Cela permet aussi
de séparer l’exécution des taches d’entrée des processus utilisateurs et des
données de sortie. L’exécutable « SAPgui » a été conçu de telle sorte
à ce que la taille totale des données qui sont transportées entre les deux
couches soit très faible. Cela signifie que la couche de présentation peu aussi
être utilisée sur un ôte qui a une connection très lente vers le serveur
d’applications. De plus, lorsqu’il y a une forte demande de données le système
R/3 pourra répondre rapidement.
§
Les conséquences pour la programmation
des applications
Le faite que les couches d’application et
présentation soient séparées, affecte
les programmeurs d’applications. Quand un programme est requis par un
utilisateur le contrôle du programme passe continuellement entre les deux
couches. Quand l’écran est prêt pour l’entrée des données utilisateur, la
couche de présentation est active et le serveur d’application est inactif. Une
fois que les données sont rentrées le programme fait suivre les données à la
couche d’application. Alors la couche de présentation est inactive et elle le
reste tant que le programme d’application
n’a pas appelé un nouvel écran.
2.2 Les serveurs d’applications
La Structure d’un serveur d’applications
Les
programmes d’application sont exécutés sur ce serveur qui utilise le serveur de
message pour communiquer. Il est composé de différents composants :
Figure 15 : Serveur
d’application et ses composants
« Work Process »
Les
processus de travail sont reliés à un espace mémoire contenant les données
actuelles du programme. Le processus a besoin de cette mémoire pour chaque
étape du dialogue.
«Dispatcher »
Il
est relié aux processus de travail et aux utilisateurs connectés au serveur
d’applications. Ces tâches sont de recevoir les requêtes du
« SAPgui » et de les dirigés vers des processus de travail libres.
« Gateway »
Les serveurs d’applications ont des ports de
communication, « Gateway » représente l’interface de communication,
les protocoles (RFC,
CPI/C). Cette interface peut communiquer avec d’autres serveurs d’applications
dans le même système R/3 ou avec des systèmes étrangers à l’éditeur SAP. La
structure du serveur d’applications comme décrit ici montre les performances du
système R/3. En effet, les processus de travail s’exécutent
indépendamment les uns des autres ce qui est convenable pour l’architecture
multi processeurs.
« Shared Memory »
Tous
les processus de travail utilisent une mémoire commune appelée mémoire
partagée, elle sauvegarde ou met les données locales dans un buffer.
Les
ressources que tous les processus de travail utilisent tels un programme ou le
contenu d’une table sont stockées dans cette mémoire. La gestion de la mémoire
dans le système R/3 assure que les processus s’adressent toujours aux bonnes
données.
Le
buffer des données dans la mémoire partagée réduit considérablement le nombre
d’accès aux bases de données. Cela réduit considérablement le temps d’accès pour les autres programmes
d’applications. De plus, afin d’optimiser l’utilisation du buffer, on peut
concentrer les différentes applications dans des groupes de serveurs
d’applications, par exemple, on peut avoir 3
serveurs différents, un pour les données logistique, un autre pour les
données de comptabilité et un dernier pour les ressources humaines.
La Connexion de la base de données
Quand
on démarre le système R/3, chaque serveur d’applications enregistre ces
processus de travail avec la couche base de données, ensuite il reçoit un seul
canal dédié pour communiquer. Tant que le système est démarré chaque processus
de travail est un utilisateur (ou client) de la
base de données (ou serveur). On ne peut pas changer l’enregistrement
des processus tant que le système est en marche. Néanmoins on peut réassigner
un canal de base de données d’un processus
à un autre. On parle alors d’une base de données LUW (single database Logical
Unit of Work), c’est une séquence d’opération de la base de donnée qui est
inséparable, on ne peut la brise, cette séquence a été pré programmé.
Les Etapes du dialogue
Le
nombre d’utilisateurs connecté aux serveurs d’applications est souvent beaucoup
plus grand que le nombre de processus de travail disponible. C’est normal car
il n’y a aucune restriction au niveau de l’architecture et chaque utilisateur
peut démarrer plusieurs applications sur un serveur. Le dispatcher a donc un
rôle important : c’est de distribuer les étapes de dialogue parmi tous les
processus existants.
2.3 Les processus du système R/3
Structure d’un processus
Il
exécute les étapes de dialogue des programmes. Voici un diagramme qui montre un
processus dans l’architecture SAP.
Figure 16 : Processus et base de
données
Chaque processus contient 2
logiciels processeurs ainsi que l’interface a la base de données.
§
Le Processeur écran
Il
exécute le flux logique, il est responsable de la communication entre les
processus et l’exécutable « SapGui », il s’assure que les champs sont
bien transférés de l’écran au flux logique.
§
Le Processeur ABAP
Un
programme est écrit en ABAP, c’est pour cela qu’un processus dédié est
nécessaire. Il s’exécute et communique avec l’interface de la base de données.
Les
images suivantes illustrent bien l’interaction qu’il y a entre l’écran et les
processus ABAP quand un programme est exécuté :
Figure
17 : Interface écran <> processus
L’interface avec la base de données (database
interface)
Il fournit les services suivants :
Le diagramme suivant montre les différents composants de l’interface de
la base de données :
Figure 18 : Composants de la base de
données
Le
diagramme montre bien qu’il y a deux différentes manières d’accéder à la base
de données : Open SQL ou Native SQL.
§
L’open
SQL est un dérivé du SQL standard qui est complètement intégré en ABAP. Il
permet d’accéder aux données de la base de données système. C’est un langage de
manipulation de donnée DML (Data Manipulation Language), en d’autres mots il
permet de lire (select) et de changer (update, insert, delete) les données. Les
tâches du langage de définition des
données DDL (Data Definition Language) et du langage des contrôles des données
DCL (Data Control Language) sont exécutées dans le système R/3 en concordance
avec le dictionnaire des données ABAP et les autorisations système.
Au
delà du Standard SQL, l’open SQL donne la possibilité de simplifier et
accélérer l’accès aux bases de données. Il permet de mettre en
« buffer » certaines tables sur le serveur d’applications. Les
« buffers » sont partiellement
stockés dans la mémoire des processus exécutés et aussi sur la mémoire
partagée pour tous les processus du serveur. Dans le cas ou le système R/3 est distribué à travers plus d’un seul
serveur d’applications, les données de chacun des buffers sont synchronisées à une série d’intervalles
par le buffer principal.
§
Le
Native SQL est approximativement intégré en ABAP, et permet d’accéder à toutes
les fonctions contenues dans l’interface de programmation de chacune des bases de
données. La différence entre l’Open SQL et
le native SQL c’est que les commandes sont directement envoyées à la
base de données système et ne sont pas contrôlées et converties. Les programmes
qui utilisent le native SQL sont spécifiques à la base de données système. On
l’utilise très peu, le plus souvent il est utilisé pour créer ou changer les
définitions de table dans le dictionnaire ABAP.
Le
« database-dependent layer » dans le diagramme au dessus, il sert à
cacher la différence entre la base de données système du reste des interfaces.
Quand on installe le système de base on choisie la couche adéquat. La
différence entre la syntaxe est très faible, cependant la sémantique et le comportement des commandes n’ont pas
été standardisés et les différences
peuvent être très grande.
Les types de processus
On
peut les diviser en plusieurs types, le type déterminera les sortes de tâches
auxquels il sera responsable au sein du serveur d’applications. Chacune de ces
tâches sont distribuées par le « Dispatcher ».
Avant de démarrer, le système R/3, détermine
combien de processus il y aura et quel sera leur type. Le
« Dispatcher » démarre chacun d’eux et leur donne les tâches qui
correspondent à leur type. Cela signifie qu’il peut distribuer les tâches afin
d’optimiser les ressources sur les serveurs d’applications.
Le
diagramme suivant montre une structure d’un serveur d’applications, mais cette
fois, il inclue toutes les sortes de
processus existants :
Figure 19 : Structure d’un serveur
d’applications et processus
Les différents types de
processus :
Dialog
Work Process
Négocie
avec les requêtes
utilisateur pour executer les étapes de dialogue.
Update
Work Process
Mets à jour les requêtes
Background
Work Process
Exécute
les programmes qui n’ont pas besoin d’interaction avec l’utilisateur (job d’arrière
plan)
Enqueue
Work Process
Administre
les blocages
de table dans
le mémoire partagée.
Les blocages de table
contiennent des bases de données bloquées pour le système R/3. Pour un
processus on peut avoir seulement une
table de bloquée à la fois, c’est pourquoi on peu avoir qu’un serveur
d’application avec ce type de processus
sinon il y aura des conflits.
Spool Work Process
Son
rôle est de passer les données aux imprimantes. Chaque serveurs d’applications
en on un seul.
Les
services offerts par un serveur d’applications sont déterminés par ces types de
processus, un serveur d’applications peut bien sur avoir plus d’une fonction.
Par exemple, il peut être un serveur de dialogue et un serveur de file
d’attente.
On
peut utiliser les fonctions d’administration pour contrôler les processus tant
que le système est toujours démarré.