Guide sap normes de developpement abap

SAP NORMES DE DEVELOPPEMENT Version 1
_____________________________________________________________________________________
NORMES_1.DOC 1 / 15
Titre : Normes de développement pour le spécifique SAP
Résumé : Ce document fournit des recommandations concernant les normes de
développement du spécifique SAP.

_____________________________________________________________________________________
NORMES_1.DOC © 2 / 15
SOMMAIRE
1. NORMES DE DEVELOPPEMENT POUR LE SPECIFIQUE SAPERROR! BOOKMARK NOT DEFIN
1.1. Convention D’APPELLATION 3
1.1.1. Règles générales 3
1.1.2. Classe de développement 3
1.1.3. Transaction 3
1.1.4. Programme spécifique 3
1.1.5. Table / Structure 3
1.1.6. Elément de données 3
1.1.7. Domaine 4
1.1.8. Vue 4
1.1.9. Objet Matchcode 4
1.1.10. Groupe Fonction 4
1.1.11. Module Fonction 4
2. RECOMMANDATIONS POUR LES PROGRAMMES ABAP 6
2.1. Protection 6
2.2. Qualité 6
2.3. Performances 6
2.4. Maintenance 8
2.5. Notes 9
3. TRANSPORTS 10
3.1. Fonctionnement 10
3.2. Réinitialisation des buffers 10
3.3. Redémarrage du système, sauvegardes 'offline' 10
3.4. Développement 10
4. MODIFICATION DU STANDARD SAP 12
4.1. modification directe de l'objet standard SAP 12
4.2. usage d'un "user-exit", s'il existe, dans le programme 12
4.3. usage d'un "user-exit", s'il existe, dans les extensions ailleurs 14
4.4. copie de l'objet standard, et puis modification de la copie 15

_____________________________________________________________________________________
1.1. CONVENTION D’APPELLATION
1.1.1. Règles générales
L'ensemble des objets de développement doit impérativement respecter la contrainte SAP qui
impose d'utiliser comme première lettre du nom la lettre Y ou Z.
Avant la mise en application de ce standard, SAP a créé un certain nombre d'objets qui ne
respectent pas cette règle. Les noms de ces objets sont référencés dans la table TDKZ; ces noms ne
doivent pas être réutilisés.
1.1.2. Classe de développement
4 car. Z d
Y d
1.1.3. Transaction
4 car. Z d
Y d
1.1.4. Programme spécifique
8 car. Z
Y
1.1.5. Table / Structure
10 car. Z d
Y d
1.1.6. Elément de données
10 car. Z d
Y d

_____________________________________________________________________________________
1.1.7. Domaine
10 car. Z d
Y d
Rappel: Un élément de données est rattaché à un domaine. Ce domaine fait référence à:
- une table de valeurs
- et/ou des constantes dont les valeurs sont répertoriées dans une table, DD07L
Cette table DD07L permet d'afficher, pour un domaine donné, la liste des valeurs constantes définies pour
le domaine. Ces valeurs sont donc définies pour un tuple Domaine/Table DD07L. La table DD07T
permet d'afficher les libellés associés à ces valeurs.
1.1.8. Vue
10 car. Z d
Y d
1.1.9. Objet Matchcode
4 car. Z d
Y d
Lors de la création par un utilisateur d'un objet matchcode, son identifiant (ID) se
compose d'un seul caractère, qui doit impérativement être un chiffre entre '0' et '9'.
Les matchcodes fournis en standard par SAP utilisent aussi les lettres entre 'a' et 'z' et
peuvent être codés sur deux caractères..
On peut aussi définir un index pour le matchcode, censé améliorer les performances de
recherche, (cf. BC430 'ABAPDictionary', page 6-21)
1.1.10. Groupe Fonction
4 car. Z d
Y d
1.1.11. Module Fonction
27 car. Z _ d ......
Y d ......
A noter que pour les module fonctions, la contrainte d’appellation imposée par SAP
est que le nom commence par 'Z_' ou 'Y'

_____________________________________________________________________________________
d - Domaine applicatif - défini pour le projet en cours (?)
Exemple: V - Ventes

_____________________________________________________________________________________
2. RECOMMANDATIONS POUR LES PROGRAMMES ABAP
2.1. PROTECTION
 Affecter un groupe d'autorisations à un programme ABAPpour le protéger.
2.2. QUALITE
 Mettre <END OF REPORT> à la fin de l'édition d'une liste dans un programme ABAP.
 Décrire dans la sortie d'un programme les traitements faits. ex:
895 enregistrements lus du fichier /tmp/devr3/italia/vendor.dat
738 enregistrements insérés dans la table SAP ZCVG1
 Traiter tous les codes retour. On peut utiliser l'instruction CASE pour le faire:
READ DATASET VENDOR1 INTO RECORD
CASE SY-SUBRC
WHEN 00.
ADD 1 TO REC-COUNTER.
WHEN 04.
EXIT.
WHEN 08.
MESSAGE ID 'ZV' TYPE 'E' NUMBER '005' WITH VENDOR1.
ENDCASE
 Pour traiter le cas où les codes retour SAP changent dans une release supérieure, ne pas
oublier de traiter les codes 'others':
WHEN 00.
...
WHEN 04.
...
WHEN OTHERS.
...
2.3. PERFORMANCES
 Utiliser l'instruction FREE pour relâcher la mémoire réservée pour une table interne qui
n'est plus utilisée. (Pas la peine à la fin d'un programme)
 Dans les instructions IF et CASE, traiter les cas les plus probables d'abord. I.E. Dans le
cas où on traite SY-SUBRC, traiter '00' (aucune erreur) d'abord - il est plus probable que
l'instruction réussisse.
 Utiliser une KEY ou un INDEX pour accélérer la lecture des tables internes.
 S'il n'est pas nécessaire de trier une table interne, ou si elle est triée plus tard, utiliser plutôt
APPEND qu'INSERT pour ajouter les enregistrements.
 Au lieu d'utiliser l'instruction MOVE-CORRESPONDING, utiliser plusieurs instructions
MOVE, surtout si les tables internes ont des structures très différentes.

_____________________________________________________________________________________
 Version 3.0c. La transaction SE30 détermine les performances des différentes intructions
ABAP. (chemin: Outils => ABAPWorkbench => Test => Analyse durée d’exécution.)

_____________________________________________________________________________________
2.4. MAINTENANCE
 Utiliser les éléments de texte (Titres, intitulés, etc.) pour séparer les textes du programme,
et pour permettre la traduction.
 Ecrire les commentaires en minuscules pour améliorer la lisibilité, et ainsi, éviter ceci:
* OUVRIR LE FICHIER VENDOR
OPEN DATASET VENDOR.
 Mettre beaucoup de commentaires, surtout à la définition des champs pour expliquer
comment ils sont utilisés, et pour décrire la logique du code avec des conditions. Les
commentaires sont aussi importants pour la maintenance du code par le client.
 Eviter de mettre beaucoup de code à l'intérieur d'une boucle ou d'une instruction IF.
Utiliser plutôt un sous-programme, et rendre le code plus lisible:
DO.
READ DATASET VENDOR1 INTO RECORD.
...
PERFORM TRAITER-RECORD.
ENDDO.
 Décaler le code d'un programme ABAPpour le rendre plus lisible:
IF SY-SUBRC = 0.
WRITE :/ 'OK'.
ELSE
IF SY-SUBRC = 4.
WRITE :/ 'ERREUR'.
ENDIF.
ENDIF.
Au lieu de
IF SY-SUBRC = 0.
WRITE :/ 'OK'.
ELSE
IF SY-SUBRC = 4.
WRITE :/ 'ERREUR'.
ENDIF.
ENDIF.
Si nécessaire, ceci peut se faire automatiquement, a l'aide du 'Pretty Printer' (Programme >
Pretty Printer)

_____________________________________________________________________________________
2.5. NOTES
 Dans un programme ABAP, mettre les INCLUDE au début, après le titre:
Ceci est important dans le cas d' <ICON> et de <SYMBOL> - s'ils ne sont pas au début du
programme, les instructions telles que:
WRITE :/ ICON_CHECKED AS ICON.
ne marchent pas!
 Dans le Menu Painter, lors de la création d'un menu, n'oubliez pas de:
1. Affecter des noms à des touches fonction, tels que:
BACK END CANC
  X
2. Activer les fonctions (Fonction Activation  Fonctions actives)
3. Générer le menu.
report SAPMZ04A.
include:
MZ04ATOP,
<ICON>,
<SYMBOL>.

_____________________________________________________________________________________
3. TRANSPORTS
3.1. FONCTIONNEMENT
Quand on utilise le programme 'tp' (ordre UNIX) pour faire le transport de nouveaux objets
d'un système d'intégration vers un système de production, deux choses se passent en
arrière-plan:
 chaque entrée dans le buffer de programmes est invalidée, c'est-à-dire que
chaque entrée n'est pas supprimée, mais marquée comme non utilisable.
 tous les autres buffers sont vidés.
Le buffer de programmes contient déjà des entrées. Chaque nouveau programme doit se loger
dans une zone déjà existante et suffisamment grande du buffer. qui est d'au moins la taille
du programme. Ainsi, le buffer est rapidement fragmenté, et comprend des petits espaces,
qui ne peuvent être utilisés, comme le décrit l'image:
Donc, il est important de faire aussi peu de transports que possible.
3.2. REINITIALISATION DES BUFFERS
La réinitialisation des buffers nécessite un bon nombre d'accès à la base de données, et peut
facilement encombrer le système. Il faut donc seulement réinitialiser les buffers si les
données du système changent.
La réinitialisation des buffers de table se fait à l'aide de l'instruction $TAB, et on peut
réinitialiser tous les buffers du système à l'aide de l'instruction $SYNC. A noter que ces
deux instructions peuvent prendre jusqu'à une heure.
3.3. REDEMARRAGE DU SYSTEME, SAUVEGARDES 'OFFLINE'
Ces deux actions nécessitent l'arrêt et redémarrage complet du système. Tous les buffers sont
réinitialisés. Ceci prend également beaucoup de temps.
3.4. DEVELOPPEMENT

_____________________________________________________________________________________
Pendant la phase de développement, les programmes sont changés et re-générés plusieurs fois,
et ainsi, les buffers de programme deviennent très fragmentés, comme décrit ci-dessus. Le
développement ne doit pas être fait dans le système de production. Dans le système de
développement, il faut des buffers de programme très grands.

_____________________________________________________________________________________
4. MODIFICATION DU STANDARD SAP
Il est parfois nécessaire de modifier les programmes standards qui ne répondent pas complètement
aux besoins spécifiés par le client et il faut choisir la méthode pour le faire:
4.1. MODIFICATION DIRECTE DE L'OBJET STANDARD SAP
Déconseillé. Afin de minimiser les modifications du standard faites par les clients, et aussi
pour pouvoir prévenir les clients quand leurs modifications seront affectées par les montées de version,
SAP a introduit un système de 'clés de modification' : chaque fois qu'on veut changer un objet standard
SAP, le système demande une clé de réparation, qu'on obtient à partir de SAP. (OSS)
4.2. USAGE D'UN "USER-EXIT", S'IL EXISTE, DANS LE PROGRAMME
Conseillé par SAP. Les "user-exits" sont des appels à des programmes spécifiques, à des
endroits prédefinis dans un programme. Ainsi, les programmes SAP ne sont pas changés - et à priori,
une montée de version ne va pas changer les fonctionnalités du spécifique. On peut voir un
programme SAP qui prévoit des user-exit : transaction SE38 (Outils > ABAPWorkbench > Editeur
ABAP), puis afficher le programme standard SAPMV45A. Malheureusement, il n'y a pas des user-
exits partout où on les voudrait.

_____________________________________________________________________________________

_____________________________________________________________________________________
4.3. USAGE D'UN "USER-EXIT", S'IL EXISTE, DANS LES EXTENSIONS AILLEURS
Conseillé par SAP. La encore, il n'y a pas les "user-exits" partout. Pour avoir une liste
exhaustive des extensions SAP, il suffit de lancer la transaction SMOD (Outils > ABAPWorkbench >
Environnement > Extensions > Définition), puis choisir Utilitaires > Rechercher.

_____________________________________________________________________________________
4.4. COPIE DE L'OBJET STANDARD, ET PUIS MODIFICATION DE LA COPIE
Ainsi, modifications des objets standards SAP est évitée, mais lors d'une montée de
versions, il faut tester les programmes modifiés par rapport aux nouveaux programmes SAP pour voir si
les modifications sont encore nécessaires : il se peut que la nouvelle version de SAP propose soit les
fonctionnalités voulues, soit des user-exit.

Guide sap normes de developpement abap

Recommandé

Recommandé

Contenu connexe

Similaire à Guide sap normes de developpement abap

Similaire à Guide sap normes de developpement abap (20)

Plus de MICKAEL QUESNOT

Plus de MICKAEL QUESNOT (20)

Dernier

Dernier (20)

Guide sap normes de developpement abap