Développement ABAP – Guillaume Zacchello

DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
1. Présentation de l’ESN CGI
1.1 Vue globale
Le groupe CGI pour « Conseillers en Gestion et Informatique » en version francophone et «
Consultants to Government and Industry » pour les anglophones, est une entreprise
canadienne de services en informatique, spécialisée dans le conseil, l'intégration de systèmes
et l'outsourcing. Il se classe parmi les cinq plus grands groupes mondiaux dans son secteur.
CGI et ses filiales emploient plus de 68 000 professionnels, répartis dans 400 bureaux et 40
pays.
1.2 Historique
CGI est né en 1976 et est devenue l’une des 10 plus grandes SSII mondiale depuis le rachat en
2012 de Logica. Elle a aussi racheté 5 autres SSII majeures.
Image 1 Acquisitions CGI
1.3 Services, activités et chiffres
L’offre globale de CGI est organisée en Business Units* dont les domaines combinés
couvrent l’ensemble des besoins des entreprises de toutes tailles dans tous les secteurs
d’activité.
Ses domaines couvrent les conseils stratégiques en informatique et en management, les
services d’intégration de systèmes, le développement et sa mise en œuvre, la maintenance et
l’amélioration des applications, des services d’infrastructures ainsi que des solutions
progicielles de plus de 180 solutions informatiques et d’affaires exclusives.
8
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Ses activités sont entre autres la santé, les services financiers, les services publics, le
commerce de détail et les services aux consommateurs …
Quelques statistiques :

5e plus importante entreprise indépendante de services en TI et en gestion des
processus d’affaires au monde,

Capacités mondiales de prestation de services grâce à des centres situés sur 5
continents,

CA 2014 : 10,5 milliards $,

Valeur estimée du carnet de commandes : 20,0 milliards $.
Image 2 Répartition du CA (2012)
1.4 CGI en Aquitaine
La Business Unit Grand Ouest dont fait
partie CGI Aquitaine possède 10 agences.
Ses clients sont issus de secteurs diversifiés, et
répartis soit en grands comptes soit dans un
réseau de moyennes entreprises.
Grand Ouest possède plus de 1700 salariés.
Le président de la BU d’aquitaine est Olivier
FOIX
Image 3 Organisation CGI Grand Ouest
9
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
La BU de CGI en Aquitaine se nomme SOL
(Sud Ouest Languedoc) et possède 4 sites.
Image 4 Sites Grand Ouest
CGI en Aquitaine : ce sont 720 collaborateurs au Haillan (Bordeaux) regroupés en 3 entités
distinctes. Mais aussi 25 membres SOL/AQT sur le site de PAU.
Image 5 Entités CGI Aquitaine
Image 7 Entrée de SOL
Image 6 Organisation SOL
10
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Pour ce qui est de SAP chez SOL, ses clients sont entre autre : EDF, Turbomeca (Safran),
Herakles (Safran), IMA (assitance), Stelia (Airbus), l’AIA (Atelier Industriel de
l'Aéronautique de Bordeaux), France Telecom …
1.5 CGI en Interne
Un processus complet d’accueil est activé pour chaque nouvel arrivant, rythmé par des temps
formels et informels d’échange entre le nouvel arrivant et son manager ou son « référent ».
Tout nouvel arrivant doit suivre sur le site du internet CGI quatre formations sur la sécurité et
compléter les questionnaires.
Image 7 Processus d'intégration
Il existe 4 sites internes à CGI :
- My Site utilisé par les employés afin de
suivre les formations, modifier son compte
bancaire, se faire rembourser les frais de
transport …
Buzz : est un réseau social interne à
l’entreprise,
CynerGi : une plate-forme d’échange de
documents
Le portail CGI : présentation de la SSII et
affichage des offres d’emploi.
Image 8 Sites Internet de CGI
11
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
2. Analyse
2.1 Analyse du sujet et de son contexte
2.1.1 Présentation de la mission
Actuellement, les consultants SAP de CGI utilisent un fichier Excel afin de noter
manuellement les présences, date de création, mandant … de tous les OT* et sur chaque
environnement* d’un projet en cours. Il peut exister des erreurs dans ces fichiers Excel
comme des mauvaises dates. Le but de la mission est de développer un outil interne à CGI
afin d’automatiser un rapport qui affiche les mêmes informations que le fichier Excel lorsque
celui-ci est exécuté.
2.1.2 Analyse de l’existant
Un extrait du fichier Excel de la présence des OT sur le projet EDF (cf. Image 9)
Image 8 Fichier Excel du suivi des OT
12
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Les informations présentes dans le fichier Excel (cf. Image 9) géré manuellement sont : le
nom de l’OT, son libellé, son projet, sa version, le mandant, son type. Il y a aussi sa présence
codifiée par un « X » ou non dans un système et sa date de passage dans un environnement s'il
est présent.
2.1.3 L’outil STMS
Sur SAP, il existe la transaction STMS permettant de voir les OT disponibles ainsi que leurs
codes retour dans chaque environnement.
On clique sur l’icone « Synthèse d’import » (cf.
Image 10)
Notre environnement actuel est DCD.
Image 9 Accueil STMS
Aperçu des environnements disponibles (cf.
Image 11).
On sélectionne l’un des environnements.
Image 10 Synthèse des imports d’environnements
Image 11 Liste des OT sur DCQ
Les OT (Ordre), utilisateur et code retour* en format graphique(St) sont bien présents mais on
ne voit pas les OT non disponibles (qui sont dans d’autres systèmes). La date de création des
OT n’est pas référencée. De part tous ces manques, il faut développer un programme.
13
DÉVELOPPEMENT ABAP
2.2
–
GUILLAUME ZACCHELLO
Analyse des besoins fonctionnels
2.2.1 Le besoin général
Il faut afficher les informations présentes dans le fichier Excel (cf. 2.1.2). De plus il faut
rajouter le code retour* de chaque environnement afin de savoir s’il a été importé
correctement dans chaque environnement. Ce code retour ne sera pas affiché dans le 1er
système de développement car celui-ci est automatiquement importé avec succès.
L’affichage du tableau des OT diffère de celui d’Excel, chaque système doit avoir sa date de
passage à côté et son code retour. Il faut aussi faire apparaitre le compte du titulaire.
Ordre de
transport
Libelle
Mandant
Titulaire
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
xxxxxxx
Env 1
Date de
passage
Env1
xxxxxxx xxxxxxx
xxxxxxx xxxxxxx
Env 2
Date de
passage
Env2
xxxxxxx xxxxxxx
xxxxxxx xxxxxxx
Code
retour
Env 2
xxxxxxx
xxxxxxx
Les environnements qui devront être affichés pourront être choisis lors de l’installation du
programme.
2.2.2 Qu’est-ce qu’un ordre de transport
Un ordre de transport (ou un OT), est une collection de changements qui ont été réalisés dans
l’environnement de développement et qui peuvent déployés dans un autre système.
Chaque OT est généré par SAP avec un identifiant unique. Il peut contenir entre autre un
libellé, l’utilisateur SAP qui a réalisé cette modification, le mandant sur lequel la modification
est faite, la date et heure de création de l’OT …
La création d’un OT se fait via le code de transport SE10 et peut-être visualisé dans SE01 (cf.
Image 13).
Image 12 OT DCDK907448
14
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Un ordre de transport est toujours du format standard : <SID>K<Number>



SID – nom de l’environnement,
K – est une lettre fixe,
Number – commence par 900001et augmenté aléatoirement suivant le nombre de
tâches.
Exemple: DEVK900030
La tâche utilise la même convention de dénomination que l’OT, il peut y en avoir plusieurs
dans l’OT avec un minimum de un. Un numéro aléatoire s’incrémente avec celui de l’OT.
Exemple sur l’image (cf. Image 13) : l’OT DCDK907448 possède 4 tâches.
Ces tâches ne devront pas être affichées dans le rapport car on ne souhaite voir que les OT
auxquels appartiennent ces tâches.
2.2.3 Extraction des OT
Il n’y a pas de table globale recensant tous les OT qui ont été créés dans chaque système et
basculés dans les autres systèmes. Il existe plusieurs moyens permettant de collecter les
informations sur les OT dans les différents systèmes mais chacun avec des inconvénients.
Il est possible de recueillir les informations des différents OT via :

Lecture dans le système actuel via la table E070, possibilité d’avoir tous les OT
disponibles et toutes les informations disponibles.

Lecture des fichiers UNIX de SAP sur le serveur actuel afin de récupérer les OT de
tous les systèmes. C’est la méthode la plus importante car elle donne les informations
de tous les systèmes.
Inconvénient : Si un serveur est hors ligne, il ne peut plus lire les logs et cela
impactera la récupération d’informations des OT sur d’autres environnements (cf.
4.2).

Lecture de la table E070 des autres environnements via des connexions RFC (CF
3.1.3).
Inconvénient : une connexion RFC doit être créée dans SAP pour chaque
environnement et certains clients n’autorisent pas systématiquement la connexion à
leurs environnements notamment ceux de production. Cette table sert uniquement si
un serveur est hors ligne afin de pouvoir lire la présence d’OT d’un environnement
particulier (cf. 4.2) . Cette table ne renvoie pas le code retour.

Lecture de la table TMSBUFFER des autres environnements via des connexions RFC.
Pour chaque environnement cette table peut lire les OT d’autres environnements.
Inconvénient : une connexion RFC doit être créée dans SAP pour chaque
environnement et certains clients n’autorisent pas systématiquement la connexion à
leurs environnements notamment ceux de production. Cette table sert uniquement si
un serveur est hors ligne afin de pouvoir lire la présence d’OT dans plusieurs autres
environnements. Cette table ne renvoie pas la date de création d’OT.
15
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
2.2.4 Déroulement du programme
Le programme devra dans un 1er temps extraire les OT via les différentes fonctions, les
analyser et les afficher. Pour ce faire, on utilise tous les moyens pour extraire des informations
sur les OT (cf. 2.2.3) pour chaque environnement. Ces OT seront ensuite comparés avec ceux
présents dans le système de développement et seront représentés par une LED rouge si nonprésent et vert si présent complété par la date de transfert dans le système et le code retour (cf.
Image 14 et 15). Cet affichage sera une table ABAP.
Image 13 Diagramme d’activité
Image 14 Diagramme d’état transition
16
DÉVELOPPEMENT ABAP
2.3
–
GUILLAUME ZACCHELLO
Analyse des besoins non fonctionnels
2.3.1 Ergonomie
L’affichage se fait via la fonction ALV de SAP.
L’ALV (SAP List Viewer) est un outil générique de SAP qui délivre des données sous forme
des tableaux (lignes et colonnes), avec des fonctions intégrées pour manipuler les sorties (tri
sur les nombres, tri sur l'ordre des colonnes, filtres des données, etc.) et une fonction d’export
le tableau (format CSV Excel).
Image 15 Démo ALV
2.3.2 Contrainte de normalisation des variables
Afin qu’un autre développeur puisse reprendre le code, il faut respecter les règles de
normalisation du code interne à CGI. Chaque type de variable à sa norme :
type
type de table
Local
Global
Structure
Table
Constantes
Field-symbol
Parameter input
Parameter output
Select option
Parameter
ty_*
ty_t_*
l_*
g_*
(l|g)s_*
(l|g)t_*
c_*
<fs_*>
pi_*
po_*
so_*
p_*
17
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
2.3.3 Normalisation du programme
Chaque programme doit aussi être normalisé sur le modèle suivant :
Image 16 Code source: normalization





Un cartouche de création/modification avec au moins l’auteur,
3 fichiers INCLUDE, un TOP où sont référencés tous les types et constantes que le
programme utilisera, un SEL pour tout ce qui est graphique (bouton, champs …) et un
FORM pour le programme qui utilise les données issues des autres INCLUDE,
Adapter les noms des INCLUDE avec le nom du programme,
START-OF-SELECTION est un événement qui se produit avant que les SELECTIONSCREEN ne se produisent (bouton, champs …),
PERFORM f_at_start_of_selection pointe sur le FORM.
2.3.4 Contrainte sur la méthode d’affichage de l’ALV
Il existe 2 méthodes afin d’afficher les données d’une table interne dans l’ALV :
Image 17 Code source: méthode d’affichage
18
DÉVELOPPEMENT ABAP
(1)
(2)
–
GUILLAUME ZACCHELLO
Cette méthode modifie l’ALV suivant la ligne en cour « sy-tabix »
Cette méthode utilise les pointeurs Field-Symbols, et en tant que telle, ne nécessite
pas de copie de données en mémoire, ce sont les curseurs dans la mémoire qui se
déplacent. Un MODIFY n’est pas nécessaire.
La solution (2) a de meilleurs résultats en matière de performance et de gestion de l’espace
mémoire. Elle a donc été choisie.
2.3.5 Contrainte nommage des tables et programmes
Sous SAP toutes les tables, programmes, fonctions créées par l’utilisateur doivent commencer
par Z. S’il n’est pas le cas SAP n’est plus responsable pour le support du programme, cela
permet de faire la différence entre des programmes sous SAP et ceux réalisés par les
utilisateurs.
19
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3 Rapport technique
3.1 L’environnement SAP
3.1.1 L’IDE SAP
L’IDE SAP est accessible via les codes de transaction SE38 et SE80. Le langage utilisé est
l’ABAP*
Image 18 Environnement de développement SAP
Quelques fonctionnalités utiles de l’IDE :
Permet de voir nos programmes externes inclus.
Permet d’exécuter le programme
Affiche l’aide en ligne SAP
Permet la mise en forme de l'agencement du code
Permet de tester le programme avant de l’exécuter
Permet de modifier le programme si celui-ci et en mode affichage
Permet de mettre un point d’arrêt d’exécution et de passer en mode débogage
20
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.1.2 Le dictionnaire de données
Le dictionnaire de données sert d'interface avec la base de données. Les tables du dictionnaire
de données sont une représentation des tables de la base de données. Les tables du
dictionnaire SAP sont incluses avec celles créées par les utilisateurs. La définition des
données se fait graphiquement, le code SQL est généré par l’interface graphique.
Une table dans le dictionnaire des données :
Image 19 Dictionnaire de données de ZOT_ALV
1. Table transparente : table contenant des données. Une table cluster est une table
regroupant plusieurs tables transparentes à des fins de visibilité,
2. Nom de la table,
3. Domaine : caractéristique d’une zone (char, num, longueur, table de valeur, …). Un
domaine ne peut pas être affiché en ABAP. Il faut lui attribuer un élément de donnée,
4. Précise si clé primaire,
5. Indique si l’élément de données peut être NULL,
6. L’élément de données permet d’associer à un domaine un sens applicatif (on lui
associe de la documentation, un domaine de valeurs …),
7. Le type du domaine : (CHAR, INT, FLOAT …),
8. Longueur maximum de l’élément de données,
9. La description littérale de l’élément de données.
Transactions utiles :
- La transaction SE11 permet d’accéder au dictionnaire de données et de créer/modifier des
tables,
- La transaction SE16 permet d’accéder aux données des tables transparentes,
- La transaction SM30 permet de remplir les tables.
21
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.1.3 Qu’est que le RFC ?
Une fonction RFC (Remote Function Call ) est un
appel à un module de fonction dans un système
différent de celui de l'appelant . La configuration
d’une connexion RFC entre 2 systèmes est possible
via la transaction SM59 lancée sur l’environnement
qui demande la connexion.
Image 20 Schema RFC
Toutes les fonctions ne sont pas accessibles à
distance (limite des possibilités d’appel à partir d’un
autre environnement). Pour vérifier lesquels sont autorisés, on peut les rechercher la fonction
via la transaction SE37. Si la case « Module accessible à distance » est cochée, elle peut être
appelée et donnera des informations sur son environnement.
Image 21 Une fonction accessible via RFC et une non accessible
Aussi certaines fonctions accessibles à distance ont besoin d’une connexion RFC avec un nom
d’utilisateur et mot de passe valides comme la fonction ‘RFC_READ_TABLE’ (permettant
de lire des tables sur un autre système) alors que d’autres n’ont besoin que du
TRACEROUTE (cf. 3.2.1) automatiquement créé lorsque on joint les environnements entre
eux comme la fonction ‘TMS_TM_GET_TRLIST’.
3.1.4 SAP-directories
Le SAP-directories (accessible via AL11)
contient les fichiers et dossiers du serveur
UNIX de SAP.
Image 22 Repertoires SAP sous UNIX
22
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.2 Conception
3.2.1 Environnement dans lequel le programme va être développé
Un serveur a été attribué ainsi qu’un login personnel, mot de passe et un environnement pour
développer le programme. Le programme devra être exportable.
Image 23 Connexion sur SAP
Le serveur ici est « noeyy4lj.noe.edf.fr », et l’environnement « DCD ».
Ce serveur appartient à EDF et le système utilisé est un environnement de développement où
l’on peut développer et faire des modifications sans affecter d’autres environnements comme
celui de production.
Afin de visualiser la configuration des environnements entre eux qui seront utilisés pour le
développement, on utilise le bouton TRACEROUTE dans STMS.
Image 24 TRACEROUTE de EDF
Sept Environnements sont présents. Ils sont préfixés par les lettres « DC » qui sont choisies
par le développeur et valables pour tous les autres environnements.
-
DCD : pour l’environnement de développement,
DCR : pour l’environnement de recette,
DCQ : pour l’environnement de qualité,
DCI : pour l’environnement d’intégration,
DCP : pour l’environnement de production,
DCC : pour l’environnement de correction,
DCF : pour l’environnement de formation.
Les TRACEROUTE entre plusieurs environnements sont créés par la transaction SM59, qui
nécessite une configuration de connexion RFC (cf. 3.1.3).
23
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Image 25 User TMSADM et TRACEROUTE
Les 7 domaines sont présents. Ces connexions doivent être créées par l’utilisateur TMSADM
avec le mandant 000. Ces connexions RFC pourront être utilisées par toutes les fonctions SAP
qui ne requierent pas de connexion RFC particulières comme les fonctions commencent par
« TMS ».
3.2.2 Trouver les OT
Les OT se trouvent dans 2 endroits : les logs et les tables.
Les OT se trouvent dans les logs UNIX (CF
3.1.4) de chaque environnement, dans le
dossier /usr/sap/trans/<s-id>,
<s-id> étant l’environnement actuel.
Image 27 Le répertoire des logs des OT sur DCD
Image 26 Répertoire des OT de DCD
Image 28 Log de DCDK907336
24
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Les OT se trouvent dans les tables E070 de chaque environnement. On peut accéder à toutes
les informations de celui-ci : date de création, libellé, auteur…
Image 29 Table e070v sur environnement DCD
Pour accéder à ces environnements depuis celui du développement, il est possible de faire
appel aux fonctions RFC (cf. 3.1.3). Les tables E070 ne renvoient pas le code retour. La table
TMSBUFFER sera utilisée pour récupérer ce code retour.
La table TMSBUFFER permet de montrer le code retour d’un OT dans SAP ainsi que la
présence des OT de son propre système sauf sur celui de développement car il ne possède pas
de code retour (c’est l’environnement de création des OT). La table ne renvoie pas la date de
création de l’OT. La table E070V sera utilisée pour la récupérer.
La table TMSBUFFER renvoie aussi la présence d’OT et le code retour des autres systèmes si
celui-ci renvoie un code retour non nul.
Exemple sur un OT dans notre environnement de développement :
Image 30 OT DCDK907838 dans TMSBUFFER
Sur l’image (cf. Image 27), on aperçoit six environnements. DCD n’est pas présent car
TMSBUFFER ne renvoie pas les environnements de développement.
MAXRC est le code retour. DCI, DCP, DCQ et DCR sont présents car le code retour est non
nul (il y a une valeur), alors que DCC et DCF ne renvoient rien : ils ne sont donc pas présents.
25
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.2.3 La fonction TMS_TM_GET_TRLIST
Afin d’extraire les OT nous allons utiliser 2 fonctions : l’une pour lire les OT dans les logs de
tous les environnements et l’autre pour lire les Tables (E070V et TMSBUFFER) dans tous les
environnements (CF 3.1.4).
La fonction permettant de lire et extraire les informations des logs des OT est
TMS_TM_GET_TRLIST.
Image 31 Code source: fonction TMS_TM_GET_TRLIST
Cette fonction a besoin pour fonctionner :
 d’un environnement dans iv_system : exemple 'DCQ' pour lire les logs des OT de
DCQ dans son environnement,
 iv_startdate
iv_enddate iv_starttime iv_endtime Respectivement une
date de début, une date de fin, une heure de début et une heure de fin, afin de lire les
logs compris entre la date de début et de fin et l’heure de début et de fin.
 iv_imports iv_exports doivent recevoir 'X' la valeur afin de pouvoir importer et
exporter les données dans des tables.
 irt_requests est une table que l’on exporte dans les autres environnements. Cette
table contient les OT présent dans notre environnement.
 et_tmstpalog est le nom de la table TMSTPALOG importée depuis un autre
environnement et que l’on va pouvoir utiliser. Cette table est une table de SAP qui
possède les caractéristiques suivantes :
26
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Image 32 Table TMSTPALOG
Cette table retourne entre autre les OT, code de retour, libelle, date de création … dans les
logs de l’environnement iv_system en paramètre.
La fonction TMS_TM_GET_TRLIST utilise une connexion RFC afin de lire les logs des autres
environnements. Cette fonction fait partie d’un groupe de fonctions commençant par TMS et
elle utilise automatiquement toutes les connexions RFC créées par l’utilisateur TMSADM (cf.
3.2.1).
3.2.4 La fonction RFC_READ_TABLE
La fonction permet de lire et d’extraire les informations des tables des autres environnements.
Image 33 Code source: function RFC_READ_TABLE
27
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
Cette fonction a besoin pour fonctionner :
 Fournir une destination, remplacer XXX par le nom d’une connexion RFC.
 query_table est la table à exporter du système cible,
 Delimiter permet de mettre une valeur comme un espace entre chaque donnée
exploitée pour la table TAB512,
 no_data permet de mettre une valeur comme un espace pour une valeur NULL pour
la table TAB512,
 OPTIONS est exporté sur notre environnement et contient la table RFC_DB_OPT qui
importe la description des domaines de l’environnement cible,
 Fields permet d’importer dans l’environnement cible la table RFC_DB_FLD qui
contient les éléments de données que l’on souhaite importer dans TAB512,
 Data est la table qui est exportée, elle fait référence à la table TAB512 qui n’a qu’un
élément de donnée.
Image 34 la table TAB512
La table TAB512 ne possède qu’un seul élément de donnée appelé WA, similaire un tableau
de type CHAR. C’est dans cette structure que seront renvoyées les données extraites.
Pour extraire ces donnés il faudra traiter la longueur variable des éléments.
IMPORTANT : Pour fournir une destination à la fonction RFC_READ_TABLE, il faut un
nom de connexion RFC créée par un utilisateur autre que TMSADM. On ne peut pas utiliser
les connections RFC du TRACEROUTE.
3.2.5 Quel méthode choisir ?
Les 2 méthodes d’extraction seront choisies car elles ont des avantages et inconvénients :

La fonction TMS_TM_GET_TRLIST extrait toutes les données des logs des OT
suivant les connexions RFC du TRACEROUTE (créé par l’utilisateur TMSADM). Si
un des serveurs d’un environnement est hors ligne alors on ne peut lire les logs. Ce cas
peut arriver (cf. 4.2). De plus, certains environnements même en ligne ne seront
référencés que partiellement ! (cf. 4.2).

La fonction RFC_READ_TABLE extrait les données paramétrées des tables (on
souhaite récupérer les tables E070 et TMSBUFFER). Si un serveur est hors ligne alors
grâce à la table TMSBUFFER on peut récupérer au moins la disponibilité des OT les
plus récentes et leurs codes retour (cf. 4.2) car cette table référence tous les autres
environnements.
28
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.3 Paramétrage
3.3.1 Paramétrage des chemins RFC pour RFC_READ_TABLE
Pour utiliser la fonction RFC_READ_TABLE, il faut lui créer une connexion RFC avec un
utilisateur autre que TMSADM (le TRACEROUTE).
Deux utilisateurs ont été fournis par le client EDF afin de se connecter sur DCR et DCQ avec
le seul droit d’affichage.
DCI était sur un serveur hors ligne (cf. 4.4.2). Les autres systèmes comme celui de
production trop sensible n’ont pas été donnés.
La configuration d’une RFC (transaction sm59) requiert en plus d’un login et d’un mot de
passe, un nom, l’adresse du serveur de l’environnement (si cette adresse n’est pas précisée ,
l’environnement celui serveur actuel) et un mandant de connexion.
Image 35 Configuration RFC DCQ_OT
Pour l’environnement DCQ (cf. Image 36), la case serveur est non remplie car DCQ est sur le
serveur de DCD. Le nom de la connexion RFC est DCQ_OT et son mandant 600.
29
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.3.2 Création de la base de données
Afin d’afficher les environnements que l’on souhaite dans le rapport, une table est créée. Elle
se nomme ZOT_ALV.
Image 36 La table ZOT_ALV
Elle contient 4 éléments de données :
 Le mandant qui permet d’utiliser la table sur n’importe quel mandant,
 Le nom de la connexion RFC si elle existe,
 Le nom de l’environnement,
 La position que l’on souhaite afficher dans le rapport. L’environnement de
développement doit être affiché en 1ère position.
Les environnements que l’on souhaite voir sur le fichier Excel (cf. 2.1.2) sont DCD, DCR,
DCQ, DCI et DCP. Le remplissage de la table se fera comme-suit (cf. Image 38) :
Image 37 Donnée de la table ZOT_ALV
DCQ et DCR possèdent des connexions RFC qui pourront être utilisées par la fonction
RFC_READ_TABLE.
DCI et DCP n’en possèdent pas (cf. 3.3.1).
30
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.4 Le Code ABAP
3.4.1 Le programme principal
Image 38 Code source: programme principal
Le titre du programme est zprojet_transaction. La normalisation du programme est
respectée (cf. 2.3.3). Le cartouche est présent ainsi que les 3 fichiers inclus.
Le Z_AFFICHAGE_OT_SYSTEME_SEL est vide car il n’y a pas d’interface graphique comme un
bouton ou un formulaire.
31
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.5.2 Z_AFFICHAGE_OT_SYSTEME_TOP
Image 39 Code source: Z_AFFICHAGE_OT_SYSTEME_TOP
Dans le fichier TOP sont référencés les TYPE-POOLS équivalents aux INCLUDES pour utiliser
des bibliothèques. Il y a 4 types de tables avec chacune leur type de type de table qui sera
utilisé dans le fichier FORM.
Ces 4 types de tables sont :




qui sera affichée dans l’ALV : elle peut contenir jusqu’à 7 environnements,
ty_zot_alv est la table créée (cf. 3.3.2) : elle contient les environnements à afficher,
ty_tmsbuffer contient des éléments de données d’une partie de la table
TMSBUFFER utiles pour le programme.
ty_RFC_E070_data la table qui recevra les données de la fonction
RFC_READ_TABLE.
ty_e070V
32
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.5.3 Les déclarations
Image 40 Code source: Les déclarations
Dans le FROM, les variables sont déclarées au début et seront utilisées tout au long du
programme. Les variables lt_ (local table) sont des références à des types de tables situées
dans le TOP qui contiendront les tables. Les variables en lv_ (local variable) sont locales et
sont de type boolean. Les variables ls_ (local structure) servent à lire une table locale (lt_) sur
une ligne. Enfin les FIELD-SYMBOLS permettent d’afficher une table dans un ALV (cf.
2.3.4).
3.5.4 Les Sélections
Image 41 Code source: sélection
33
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
FORM permet de découper un programme afin de le rendre plus lisible comme une
procédure. L’appel du FORM Sql_e070v s’effecture par un PERFORM . Dans l’exemple, 3
valeurs en paramètres correspondant à 3 tables locales.
Pour lt_to_alv et lt_tmsbuffer : elles sont initialisées entièrement par les tables
ZOT_ALV et TMSBUFFER.
Pour lt_e070V, seules les données des OT pour notre environnement de développement sont
sélectionnées.
3.5.5 Découpage du programme
Image 42 Code principal : decoupage du programme
L’image (cf. Image 43) a un extrait de programme via
en annexe (cf. annexes p.46).
34
.
Le code complet est disponible
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
La table lt_zot_alv est parcourue (contient la listes des environnements), deux PERFORM
renvoient à des fonctions d’extraction de données (RFC_READ_TABLE et
TMS_TM_GET_TRLIST.
La table lt_e070V (les OT de l’environnement de développement) est parcourue, via
plusieurs PERFORM qui comparent ces OT avec ceux extraits via 3 PERFORM . Enfin l’ALV est
affiché avec le PERFORM f_report_e070V. Chacune des procédures (PERFORM ) fonctionne
indépendamment les unes des autres et peuvent être testées seules. Le résumé du découpage
de programme peut être vu par le diagramme d’activité (cf. Image 44)
Image 43 Diagramme d’activité
35
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.5.6 f_rfc_read_table_e070v
Image 44 Code source : fonction RFC_READ_TABLE
Le code source entier du PERFORM f_rfc_read_table_e070v est visible en entier à l’annexe
(cf. annexes p.54)
Sur l’extrait de code (cf. Image 45), la fonction lit la table TMSBUFFER via le chemin RFC
passé en destination « pi_ls_zot_alv-rfc » , élément de donnée RFC extrait de la table
ZOT-ALV.
La table lt_fields prend en paramètre les noms des éléments des données à extraire. Dans
l’exemple : l’OT (TRKORR), le code retour (MAXRC) et le nom de l’environnement
(SYSNAM).
La table lt_data reçoit les données extraites et les données sont ensuite recopiées dans la
table lt_tmsbuffer.
36
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.5.7 f_tms_tm_get_trlist_e070v
Image 45 Code source : fonction TMS_TM_GET_TRLIST
Le code source entier du PERFORM f_tms_tm_get_trlist_e070v est visible en entier à
l’annexe (cf. annexes p.55).
Cette fonction n’utilise pas de destination car celle-ci utilise celle créée par l’utilisateur
TMSADM (cf. 3.2.2).
u_tmssysnam est le système à exporter passé en paramètre,
iv_startdate permet de rechercher tous les OT dans la data commence par 2015,
iv_enddate prend en paramètre sy-datum qui est la date actuelle,
La table lt_log reçoit les informations extraites de cette fonction qui sont ajoutées à la table
lt_tmstpalog.
3.5.8 Affichage de l’ALV
Chaque donnée extraite est lue sur les OT de l’environnement de développement grâce aux
trois procédures PERFORM f_e070v_e070v (cf annexes p.53) PERFORM f_tmsbuffer_e070v
(cf. annexes p.53) et PERFORM f_rfc_read_table_e070v (cf annexes p.54).
La table lt_E70V est modifiée avec PERFORM f_modification_alv_e070V
L’ALV est généré à partir de la table lt_E070V via la procédure F_REPORT_E070 (cf.
annexes p.59) avec la méthode CALL METHOD cl_salv_table=>factory (cf. annexes p.60)
37
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.6 Résultats et perspectives
3.6.1 Examen des résultats obtenus par rapport aux objectifs initiaux.
Image 46 Une partie de l’affichage de l’ALV
On a bien les données des OT des 5 systèmes souhaités comme sur le fichier Excel (cf. 2.1.2)
avec la date de création et le code retour. Les données souhaitées sont bien présentes.
Il est aussi possible de rajouter les 2 autres environnements non présents DCC et DCF.
38
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
3.6.2 Suites possibles de développement.



Créer un fichier d’installation qui créera la base de données ZOT_ALV ainsi que les
connexions RFC afin d’éviter le paramétrage,
Créer une fonction qui permet de savoir si tous les environnements sont en ligne afin
d’utiliser que la méthode d’extraction des OT dans les logs pour gagner du temps
d’exécution,
Créer un tableau de bord permettant entre autres de sélectionner les OT par utilisateur,
par date de création …
39
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
4 Rapport d’activité
4.1 Mauvais départ
Avant d’utiliser les deux fonctions RFC_READ_TABLE et TMS_TM_GET_TRLIST, j’ai
commencé avec d’autres fonctions et méthodes qui fonctionnaient mal et m’ont ralenti, voici
en quelques unes :
4.1.1 Reprendre des programmes
J’ai essayé de reprendre et paramétrer des programmes qui avaient déjà été développés la
communauté SAP. Ces programmes permettaient d’afficher aussi dans un ALV les OT
disponibles par environnement. Mais après installation, soit ils ne fonctionnaient pas soit ne
remontaient tous les OT disponibles.
4.1.2 Les fichiers logiques
Pour chercher dans les logs avant d’avoir trouvé la fonction qui cherche les OT
automatiquement, j’ai cherché dans les LOGS en utilisant la fonction OPEN DSET et READ
FILE.
Image 47 fichiers logiques
Pour faire ceci, j’avais créé des fichiers logiques qui sont des fichiers dans des chemins
physiques qui ont juste quelques différences de chemins.
Pour créer ces fichiers (cf. Image 48), il faut utiliser la transaction FILE puis donner un titre
au chemin logique et lui adresser un chemin physique :
/usr/sap/trans/<SYSID>/log/<FILENAME>
Tous les logs des environnements se situent dans ce chemin.
<SYSID> est le nom de l’environnement et <FILENAME> les fichiers logs des OT
disponibles.
4.1.3 La table ALOG
La table ALOG référence tous les LOGS des OT de l’environnement mais celle-ci n’était pas
exploitable du fait qu’il n’y avait aucune logique de stockage des données dans la table.
40
DÉVELOPPEMENT ABAP
–
GUILLAUME ZACCHELLO
4.1.4 Vitesse d’exécution
L’algorithme de mon programme a été différent de ce qu’il est maintenant. Lorsque je l’avais
terminé il mettait 15 secondes contre 5 actuellement. Pour chaque extraction, chaque
comparaison et enfin pour l’affichage, je rebouclais sur les environnements (table ZOT_ALV)
et les OT (table E070V), j’ai changé pour que cela ne boucle plus.
4.2 Serveur DCI hors ligne
Quatorze jours avant la fin du stage, le serveur où était situé l’environnement DCI, était hors
ligne. La fonction TMS_TM_GET_TRLIST ne donnait pas les informations de DCI et seuls
quelques OT (5 – 10) de l’environnement DCQ étaient référencés (Pourquoi ?? peut être que
des logs des OT de DCQ étaient présents sur l’environnement DCI ?), bien que DCQ ne soit
pas sur le serveur de DCI.
C’est pour cette raison que j’ai développé la fonction RFC_READ_TABLE pour lire les
tables E070V sur DCQ et TMSBUFFER sur tous les systèmes pour avoir sur DCI la présence
de l’OT et le code retour, seule la date de création des OT manquait.
Le programme réalisé donne maintenant un maximum d’informations sur les OT même si un
des serveurs vient à être hors ligne.
4.3 Forum SCN
Afin de me renseigner sur les fonctions et les tables particulières dont j’avais besoin, j’ai été
actif sur le forum SAP appelé SCN (6-7 sujets créés). Les personnes consultantes de SAP du
monde entier répondent aux questions (en anglais) posées par la communauté.
Image 48 Question posée sur SCN
41