Chaque dveloppeur a sa propre manire de concevoir un programme et il n'y a pas de faon unique de dvelopper un programme pour aboutir un rsultat

t donn. Nanmoins, le dveloppement, quelque soit le langage utilis, doit obir certaines rgles pour qu'un programme soit facilement lisible, comprhensible et modifiable, par une autre personne que le crateur du programme. Ces rgles sont d'autant plus importantes en ABAP car elles peuvent directement influer sur les performances du programme et la cohrence des donnes mises jour ou affiches. Voici quelques rgles qu'il est conseill d'appliquer pour optimiser ses dveloppements ABAP : - en amont de tout dveloppement, il est important de dfinir la faon dont seront nomms les diffrents objets qui vont tre dvelopps, ceci afin de faciliter la recherche et l'identification des objets; si le nom d'un objet spcifique commence toujours par Y ou Z, car ce sont les 2 lettres rserves par SAP aux dveloppements spcifiques aux clients, les caractres suivants doivent pouvoir permettre d'identifier : * le systme cible o l'objet va tre utlis si les dveloppements ont lieu dans un core systme et doivent tre dploys ensuite dans plusieurs systmes cibles, * le module concern ou le caractre inter-modules de l'objet, * le type d'objet (table, structure, lment de donne, domaine, programme, module fonction, transaction, message, idoc, bapi,....), * une description courte du rle ou du contenu de l'objet, - une fois ces rgles dfinies, il est conseill de crer une ou plusieurs classes de dveloppements ou un ou plusieurs packages (selon la version de SAP et le langage ABAP ou ABAP objet) dans lesquelles seront regroups des objets ayant un but ou un rle commun, - l'intrieur de ces classes de dveloppements ou de ces packages, des groupes de fonctions ou des classes d'implmentation peuvent tre cres pour mutualiser les modules fonctions ou les mthodes, de recherche, d'affichage et de mise jour de tables, - ces modules fonctions ou ces mthodes seront ensuite utilises dans des programmes, des user-exit, des badi ou dans d'autres modules fonctions ou d'autres mthodes, - enfin, pour optimiser les programmes, il est conseill de modulariser au maximum, c'est--dire : * sparer, dans diffrents includes, les phases de dclarations de donnes, dclarations de paramtres d'cran de slection, recherche de donnes, mises jour de tables et affichage de rapport d'excution ou de rsultat de mise jour, * mutualiser dans des forms ou modules les tches rptitives du programme, cela aura ainsi pour effet de : * faciliter la lecture du programme, * faciliter la maintenance du programme par d'autres personnes que le crateur, * minimiser les modifications faire. Ces quelques rgles de bases permettent une organisation des dveloppements efficaces, et peuvent s'appliquer d'autres langages que l'ABAP et d'autres progiciels que SAP, pour peu qu'ils aient un environnement de dveloppement adquat.

Il arrive souvent que dans un user-exit ou une BADI on n'ait pas toutes les informations ncessaires disponibles en paramtres d'entre. Dans ces cas-l, plusieurs solutions sont possibles : - dfinir des variables de type 'statics' - utiliser les import/export en mmoire - assigner directement la zone mmoire si elle est connue - dfinir des variables locales ou prives dans la classe d'implmentation. Voici une description et un exemple pour chaque cas. Variable de type 'statics' : Ces variables peuvent tre utilises de la mme faon que des variables de types 'data', elles se dfinissent de la mme manire, mais alors que les 'data' perdent leur valeur la fin du sous-module ou du user-exit, les valeurs des 'statics' sont conserves en mmoire et rutilisables lors du prochain passage dans le sous-module ou le user-exit condition qu'on reste dans le mme processus de traitement. Par exemple, un user-exit est appel dans une boucle loop/endloop, on peut donc dfinir un 'statics', l'initialiser en dbut de user-exit, modifier sa valeur en fin de user-exit, et retrouver cette dernire valeur lors du prochain passage. loop at w_table. call customer-function '001'. endloop. customer-function '001' : statics : s_count type i. if s_count is initial. s_count = 1. else. if w_table[]-champ1 is initial. clear s_count. endif. endif. [suite du code..........] s_count = s_count + 1. endfunction ainsi au prochain passage dans le user-exit s_count aura la valeur 2, puis 3, et ainsi de suite jusqu' la sortie de la boucle. Import/export en mmoire : Il arrive souvent qu'au sein d'un mme programme principal, plusieurs user-exit soient appels, et que dans celui qui nous intresse, il manque une information qui est prsente dans un des user-exit appel prcdemment. Dans ce cas il suffit de faire un export en mmoire de l'information voulue dans le premier user-exit et un import de la mmoire dans le user-exit dans lequel on dveloppe. Attention cependant, cette mthode trs utile peut, lorsque plusieurs gros traitements faisant appels beaucoup d' import/export en mmoire sont lancs simultanment, engendrer des erreurs imprvisibles en mlangeant les valeurs des diffrentes zones conduisant ainsi des rsultats errons. La marge est quand mme importante avant d'arriver de tels extrmes. Par exemple :

Dans le premier user-exit : DATA : BEGIN OF w_vari OCCURS 6. INCLUDE STRUCTURE api_cv. DATA : END OF w_vari. [suite du code..........] EXPORT w_vari TO MEMORY ID 'VARI'. [fin du code..........] Dans le second user-exit : DATA : BEGIN OF w_vari OCCURS 6. INCLUDE STRUCTURE api_cv. DATA : END OF w_vari. [suite du code..........] IMPORT w_vari FROM MEMORY ID 'VARI'. [fin du code..........] Assigner une zone mmoire : Quand on est en mode debug dans un programme ABAP, on peut voir toutes les tapes d'excution de ce programme en cliquant sur 'Appels' ou sur 'Synthse'. On peut ainsi accder au code d'un autre module ou d'une autre sousroutine pour connatre les tables internes utilises et leur contenu. Lors de l'appel du user-exit qui nous intresse, on peut assigner un field-symbol le contenu d'une table interne appele dans une tape prcdente si elle est toujours en mmoire au moment o l'on passe dans le user-exit. Par exemple on a besoin du contenu de la table w_table dans notre user-exit, et cette table n'y est pas utilise, mais elle est utilise dans une autre routine du programme SAPLMM06E qui est appele en amont du user-exit : FIELD-SYMBOLS : <fs> TYPE ANY. DATA : w_table_new LIKE ztable OCCURS 0. ASSIGN ('(SAPMM06E)w_table[]') TO <fs>. IF <fs> IS ASSIGNED. w_table_new[] = <fs>. ENDIF. Dfinir des variables dans une classe d'implmentation : Cette mthode revient au mme que la dfinition de variable de type 'statics' mais s'applique uniquement dans des classes et des mthodes alors que les variables de type 'statics' sont rserves aux user-exit et au routine ou sousroutine classiques. Il suffit de modifier la classe voulue en lui ajoutant : - soit un type local via le menu : Saut\Types locaux de classe\Dfinition locales de classes/types puis en utilisant ce type pour dfinir une ou plusieurs variables dans la mthode - soit une variable d'un type prdfini via le menu : Saut\Section prive. L'utilisation est ensuite la mme que des variables ou des types dfinis dans le code de la mthode. L'avantage de la dfinition locale est que le type ou la variable dfinis sont valables pour toutes les mthodes de la classe et n'auront pas tre dfini dans chaque mthode. De plus, la variable dfinie en section prive garde sa valeur en fin de mthode si elle n'est pas vide (comme une variable de type 'statics').