Introduction

Sur de nombreuses plateformes comme JAVA ou .net le découplage du code est une vieille pratique (issu du langage C) et combien même on découple parfois trop sur ces plateformes, dans le monde SAP,  force est de constater qu'on découple peu parfois moins que les célèbres 3 couches (données, métier, présentation). Ceci n'empeche pas aux développeurs ABAP de fournir des codes souvent robustes mais au prix de la perte de plusieurs avantages :

• La réutilisation facile d'un code existant
• Une maintenabilité plus aisée
• et la mise en place de VERITABLE test unitaire (avec ABAP unit par exemple)

Mais découpler ne suffit pas. Il est nécessaire aussi de gérer son code de manière cohérente et hiérarchisée. D'ou la notion de package ou plutot d'arborescence de packages. C'est exactement ce que fait SAP déja avec son découpage en module (FI, SD, MM, etc...) et sous modules (par exemple FI-AA) . Le but est donc de créer une arborescence reprenant ses codes Z (spécifiques) soit la base d'un modèle copié sur SAP soit sur la base de l'organisation même de la société. Toutefois ma préférence va à la première solution.

Hiérarchie des packages

Avec la transaction SE80 il est possible de créer des packages et d'ajouter des packages enfants dans un package jusqu'à obtenir un arbre de package.

Pour cela il suffit de créer un premier package et de cliquer sur l'onglet "Package Included". Puis add...

Ainsi dans le projet ZZCUBE j'ai créé l'ensemble de ses packages enfants, visibles aussi dans le "repository browser".

La structuration de ses sources en packages permet de hiérarchiser ses sources (l'ensemble des objets SAP) mais aussi de gérer plus facilement les transports en les réalisant par package.

C'est une pratique courante dans le monde Java et .net mais encore pas assez développée sur SAP. L'objectif est d'avoir un modèle hiérarchisé de l'ensemble de ses sources maisons (techniques et spécifiques métier). Par exemple il est possible de créer un package ZSOCIETE (avec le nom de la société) et dedans des packages FRAMEWORK, FI, SD, MM, etc... et ainsi de suite.

Découplage orienté service

Quand on écrit une application le mieux est d'avoir une approche service. Sans entrer trop dans le détail (l'approche SOA mériterait un article complet, en attendant lisez http://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services) l'important est de comprendre que l'approche service consiste avant tout à écrire une première fonction (une Zfonction) qui exécute une action métier (et non pas technique) non spécifique à SAP mais générique : on parlera de numéro de matériel et non de MATNR.

Par exemple si on prend le schémas UML suivant :

Si on étudie les fonctions nécessaires pour créer une facture on va devoir écrire les fonctions pour récupérer les matériels en fonction de certains critères ou encore le nom du client etc... Et au moment de créer la facture vous allez devoir vérifier les données avant l'envoi.

L'approche SOA consiste donc à créer une fonction Z unique qui créée la facture. Dans cette fonction vous allez faire les différents taches nécessaires dont la vérification par exemple. Les fonctions d'alimentations de l'écran ne seront pas forcément des services (pour le choix du client oui mais sinon ...)

La fonction "Service" ainsi créée sera non seulement réutilisable (y compris depuis l'extérieur). En fait cela ressemble fortement aux BAPIs.

On a donc :

• Un évènement sur l'interface utilisateur invoque un service (créer une facture par exemple)
• Un service appelle une ou plusieurs fonctions SAP, BAPI, RFC ou Z.
• La(les) fonction(s) appelle(nt) des requètes SQL ou autres.

Ce qui distingue un service c'est que c'est un contrat orienté métier. Dès qu'on le publie, on peut l'améliorer, mais on ne peut changer ses inputs ou outputs (ou alors avec des valeurs optionnelles). C'est le USER CASE UML qui vous aide à déterminer ce qu'est un service.

Découplage des BAPIs (et encapsulation).

Les BAPI ont été pensées depuis toujours comme des services. Certaines sont complexes à utiliser et dans l'appel qu'on en fait on doit parfois passer des paramètres hardcodés. De plus un véritable service doit être au maximum débarrassé de ses spécificités backend. Ainsi si on appelle un service sur SAP, normalement on ne doit pas reconnaitre qu'on est sur SAP, le service mappant des structures de données génériques avec le spécifique SAP (sémantique séparée du backend).

Dans tous les cas il me parait préférable de ne jamais consommer une BAPI en direct, mais toujours l'encapsuler dans une fonction Z. Si la BAPI se suffit à elle même la ZFunction sera un service sinon le service appellera la Zfunction qui appelera la BAPI.

cette abstraction permet d'abord de mapper depuis un service une BAPI puis la remplacer facilement quand on a une BAPI classée obsolète.

Utilisation d'une table de paramètre

On peut alors implémenter une ztable contenant des paramètres spécifique de la BAPI ou de ZFonctions en fonction de l'application appelante, du mandant, du user, voir de la date. Ainsi les données normalement hardcodées seront maintenable facilement (via SM30).

Découplage de l'écran avec le backend (services)

 L'objectif de ce découplage est de ne plus lié le backend à l'écran. il devient alors beaucoup plus facile de tester ses écrans et de les maintenir individuellement.Il s'agit là bien sur d'une approche uniquement valable pour des développements d'écrans complexes et non pas basés sur des selections screens.

Pour cela on créée un DTO c.à.d un Data Transfert Object, en fait une structure contenant l'ensemble des éléments nécessaires à l'écran (données affichées). A cela s'ajoute des sous-routines (perform/form/endform) chargé d'ajouter de modifier ou supprimer des données.

Impact en ABAP

• Concrètement en ABAP on créée une structure reprenant l'ensemble des types données de SAP, puis des sous routines qui la modifie (delete/add/udapte).
• On mappe Les évenements d'édition de l'écran avec les méthodes du DTO via les PAI (Process After input) et les PBO (Process Before Output). La présence même des PAI et PBO tend à me convaincre que SAP avait en tête déja ce genre de pratique.
• On mappe les boutons de publication avec le back end vers une sous routines qui va lire le contenu du DTO et l'envoyer vers les bons services.

Cette approche que je dois absolument illustrer concrètement avec des sources permet d'améliorer les tests la maintenabilité mais est un sacré changement dans la tête de certains développeurs (je pense à un bourricot très bon codeur mais old-school que je nommerais pas).

Conclusion

Décupler son code sur SAP est totalement faisable, essentiellement car SAP a été développé en C/C++ et reprend énormément de comportement de ce langage. Il est préférable de faire de l'ABAP OO, mais c'est tout à fait réalisable en ABAP standard. Au delà de l'apprentissage, ce changement d'architecture d'application implique un cout en terme de temps (+20% en moyenne), par contre en terme de réutilisation de code et de maintenabilité, cette approche devient totalement rentable.

 Cet article est un brouillon, vos commentaires sont attendus...