Nous poursuivons notre série sur l’analyse de code ABAP.

Nous avons vu dans le post précédent ce que vous devez savoir sur la technologie SAP et sur le code ABAP.

Nous allons maintenant lister les questions à poser aux équipes de projet afin de préparer l’extraction du code et l’organisation des analyses dans le tableau de bord Sonar.

Si vous connaissez déjà Sonar parce que vous avez l’habitude de réaliser des analyses, par exemple de code J2EE, mais que vous ne savez rien de SAP, cette partie vous intéressera surement.
Si par contre, vous êtes familiers de la technologie SAP mais ignorez tout de Sonar, les prochains posts consacrés à l’analyse de code ABAP avec Sonar vous intéresseront, bien qu’il vous faudra d’abord organiser la livraison de ce code, ce en quoi ce post peut vous être utile.

Heureusement, nous avons avec nous Walter qui est expert dans ces deux domaines, la qualité des applications SAP avec la plateforme Sonar, et nous fera bénéficier de son expérience et son expertise.

Qui est le client ?

La première question, même si vous n’avez pas besoin de la poser aux équipes SAP car vous pouvez y répondre dés à présent, est de savoir pour qui vous travaillez :

• soit dans le département informatique de votre entreprise, auquel cas vos ‘clients’ sont des équipes de projet ou des stakeholders au sein de différents départements,
• soit dans une société de services et vos clients sont d’autres entreprises auxquels vous rendez des services Qualité et d’analyse de code, ainsi que très probablement les équipes de projet internes à votre société.

Vous allez me dire : qu’est ce que ça peut faire, de toute façon, si dans les deux cas nous allons analyser du code ABAP? La question a son importance, parce que les les extractions de code peuvent se réaliser avec une relative facilité si vous êtes dans le département IT de votre entreprise, et si vous savez quel code downloader depuis quel serveur (Workbench) SAP et obtenir les autorisations nécessaires.

Par contre, si vous travaillez pour un provider, il vous faudra voir avec le service informatique de chaque client s’il peut vous fournir un tel accès et les autorisations correspondantes afin d’extraire le code qu’il vous indiquera (classes, fichiers, etc.). Mais la plupart des clients n’aiment pas donner des accès extérieurs aux applications les plus critiques au coeur de leur métier, ce qu’il signifie que ceux-ci devront mettre ce code à votre disposition, et vous allez devoir gérer ce processus et une certaine traçabilité, comme garder chaque image de livraison pendant un certain temps, afin de pouvoir procéder à des retours arrière ou tout simplement démontrer, en cas de doute, qu’il n’y a pas eu d’erreurs d’analyse et que les résultat dans le tableau de bord portent bien sur la livraison effectuée par le client.

Ensuite, que vous soyez en interne ou non, il y a de bonnes chances que l’on vous demande d’analyser le code fourni par différents providers (90% des applications SAP sont outsourcées). Et donc vous allez probablement devoir gérer le processus d’extraction et d’analyse en autant de fois que vous aurez d’outsourcers, mais également en fonction des cas d’usage.

Cest le cas de notre ami Walter, Directeur Qualité de Vision IT Group, responsable d’un centre de qualité pour différents client, qui analyse toutes les livraisons de code provenant de différents fournisseurs en un processus de Quality Gate, mais effectue également des benchmarks de ces différents providers, très appréciés des clients qui peuvent se baser sur ces analyses pour gérer des SLA (Service Level Agreement ou Accords de Niveau de Service). Sans compter des audits mensuels ou trimestriels de la qualité de code et de son évolution, à destination du management.

Il existe différents cas d’utilisation et différents scénarios qui peuvent se combiner entre eux, et c’est le premier point le plus important à définir avec vos utilisateurs et vos clients. Toujours optimiser les bénéfices pour les utilisateurs, les stakeholders, le management, bref le business.

Nous verrons ces différents cas d’usage avec Walter dans le prochain post, pour réserver cet article aux questions plus techniques.

Version SAP

La première question est simple : quelle est la version SAP utilisée ? Aucune différence au niveau du langage – mais si au niveau du Workbench SAP lui-même, et donc le programme d’extraction de code à mettre en oeuvre ne sera pas le même.

Areas SAP

Nous avons vu dans le post précédent qu’il existe des domaines ou modules SAP différents : FI, CO, HR sont les plus fréquemment rencontrés. Et c’est en fonction de ceux-ci que nous allons organiser nos analyses et les résultats dans le tableau de bord, parce que c’est ainsi que votre client ou toute équipe de projet SAP comprend les applications et souhaite voir celles-ci.

Serveurs SAP

Ces différentes ‘areas’ ou domaines peuvent être répartis sur différents serveurs, chacun avec son Workbench et son code ABAP personnalisé. Vous devez penser à l’organisation de votre processus d’analyse depuis le début, c’est à dire depuis l’étape d’extraction de code, que vous deverz réaliser sur chaque serveur que vous indiquera le client ou l’équipe de projet, pour les différentes ‘areas’ SAP.

Cela dit, cela dépend du ou des cas d’utilisation et / ou du premier point, selon que vous êtes en charge ou non d’effectuer les extractions. Mais de toutes façons, du nombre de serveurs dépend le nombre d’extractions et de celles-ci dépendent le processus d’analyse.

Organisation des équipes

Lá encore, ce point va dépendre des cas d’utilisation à mettre en œuvre. La situation la plus fréquente est lorsque des providers différents travaillent sur le même serveur. Donc si vous devez mettre en place, par exemple, une Quality Gate pour valider la livraison de chaque prestataire, il est nécessaire de savoir qui travaille sur quel serveur et dans quel domaine SAP.

Attention: ceci appelle une question très habituelle et qu’il vaut mieux préciser et étudier avec votre client le plus tôt possible. Le code ABAP, comme beaucoup d’applications Cobol, peut être assez voire très ancien. Et vous faites une analyse de ce code pour une Quality Gate et rencontrez un nombre élevé de défauts graves ou critiques, et le plus souvent le responsable de ces défauts ne sera pas le dernier développeur qui a effectué les dernières modifications, sinon tous les programmeurs qui l’ont précédé. Donc, vous ne pouvez pas dire à l’équipe de projet ou au sous-traitant que vous allez rejeter cette livraison et qu’ils doivent corriger des défauts, puisqu’ils ne sont pas responsables de ceux-ci.

Le seul moyen de savoir qui a ajouté de nouveaux défauts serait d’analyser tout le code existant pour fournir une ‘baseline’ et voir alors apparaître les nouveaux défauts dans les modifications de code de cette ‘baseline’. Mais cela voudrait dire que vous allez débuter votre processus par l’analyse de millions ou de dizaines de millions de lignes de code afin de créer cette image ‘de base’ du portefeuille d’applications SAP. Sonar est un outil très puissant quand il s’agit de l’analyse du code, mais cela représenterait un effort très élevé, pour un bénéfice qui va beaucoup dépendre des cas d’utilisation, mais aussi des relations que votre client souhaite avoir avec ses équipes de projet et ses providers. C’est de toutes façons un point à aborder dés la première réunion.

Organisation du code

Certains clients organisent leur code (personnalisé) dans des classes (nous avons vu dans le post précédent qu’il s’agit de modules et non pas de classes Objet comme en J2EE). Fondamentalement, une classe est un répertoire dans lequel vous trouverez des programmes différents à analyser. Pas un problème pour Sonar, quel que soit le nombre de programmes et le nombre de répertoires dans le répertoire racine (root) de l’analyse.

Mais vous devez demander à votre client s’ils organisent son code en classes ou non, car ce n’est pas le cas de tous. Cela aura également des incidences en matière d’extraction / de livraison du code à analyser, puisque dans certains cas elles porteront sur des classes SAP qui constitueront autant de répertoires, ou au contraire sur différentes fichiers assemblés dans un unique dossier. Et dans le premier cas, vous aurez un tableau de bord à 2 niveaux: le domaine (FI, CO, etc.) puis les classes avec chacune son code, et un seul niveau dans le second cas: chaque domaine avec les fichiers directements sous ceux-ci.

En fonction du cas d’utilisation, vous pouvez décider d’autres niveaux (dates, numéro de livraison, version applicative, etc.).

Conventions de nommage

Nous ne voulons pas analyser le code du noyau SAP, mais seulement le code développé pour personnaliser le noyau SAP. Par conséquent, il est habituel de reconnaître ce code avec des conventions de nommage assez bien normalisées (je veux dire, vous les retrouverez à peu prés partout).

Si vous voyez une classe qui commence par Z ou Y ou YY ou ZZ ou XX, il s’agit de code personnalisé que vous pouvez analyser. Il doit en être de même au niveau du programme, mais ici, les règles peuvent changer en fonction du type de celui-ci. Par exemple, vous pouvez voir un nom de programme commencer avec la lettre «L» pour indiquer un ‘load-module’.

Voici un exemple assez habituel de nomenclature: Z [Id] _ [t]_*, avec :

• ‘Id’ : identifiant de la classe ou du projet
• ‘T’ : type d’objet, R pour un programme de type rapport, I pour un Include, etc.
• * : une chaîne décrivant ce que fait le code.

Avec cette règle, vous trouverez des fichiers comme ‘ZUC_R_CHECK_FISCAL_CODE.abap’, par exemple.

Normes SAP

Dernière question, pas spécifique à SAP (toujours poser cette question dans quelque cas que ce soit) : existe-t-il des normes de programmation ? On en rencontre plus souvent dans le monde SAP qu’avec d’autres technologies, et il est donc intéressant de vérifier si vous pouvez mettre la main sur un document qui décrive ces bonnes pratiques. Cela nous aidera aussi dans la mise en oeuvre des cas d’utilisation.

Walter: vois-tu d’autres questions à aborder, lorsque tu entames un processus d’analyse de code ABAP avec un nouveau client?

J’essaie de savoir quel est le volume de code à analyser.

Cette volumétrie peut se mesurer en lignes de code (LOC ou Line Of Code), même si cette métrique est parfois décriée au profit des points de fonction (FP ou Function Points). Mais pour ce que nous souhaitons faire en l’occurence, elle sera suffisante. De plus, en cas de version SAP ECC 6.0, nous avons un programme ABAP qui nous permet de mesurer ce nombre de lignes.

Ceci nous permet de nous faire une idée du temps nécessaire pour réaliser une analyse et délivrer le service à un client, et donc en connaissant l’effort à réaliser, d’estimer le ROI de ce service.

Oui, il est vrai que j’avais oublié ce point. Autre chose ?

L’intégration éventuelle d’autres technologies. Parfois un client va souhaiter également effectuer des analyses pour du code Java ou PL/SQL. Dans ce cas, la composition de l’équipe technique peut varier.

Merci Walter. Il y a beaucoup d’autres points à aborder, en relation avec les cas d’utilisation, mais comme ce post est déjà trop long, nous réserverons ces questions pour le prochain article. On se revoit la semaine prochaine pour en parler.