1sap.technique.free.fr/doc/abap object v2.doc · web viewl’abap object est une notion apparue...

CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Abap Object

1. Introduction.........................................................................................22. La programmation orientée objet.....................................................2

2.1. Le concept..............................................................................................22.2. Quelques définitions.............................................................................3

3. Qu’est ce que l’ABAP OBJECT ?.........................................................53.1. Les champs d’applications de l’ABAP OBJECT...................................5

4. Interface Objet....................................................................................64.1. Architecture............................................................................................64.2. Control Framework................................................................................7

5. Les containers.....................................................................................86. Création d’une classe d’objet globale (SE24).................................9

6.1. Création d’un attribut.........................................................................116.2. Création d’une méthode.....................................................................126.3. Création d’un événement...................................................................136.4. Création d’un type interne.................................................................14

7. Création d’une classe d’objet locale..............................................157.1. Déclaration d’une classe locale.........................................................157.2. Déclaration des évènements.............................................................157.3. Déclaration des méthodes.................................................................16

8. Utilisation des composants d’une classe.......................................188.1. Utilisation des attributs......................................................................188.2. Utilisation des événements................................................................188.3. Utilisation des méthodes....................................................................19

9. Les interfaces....................................................................................219.1. Définition..............................................................................................219.2. Déclaration d’une interface...............................................................219.3. Implémentation d’une interface........................................................23

10. Un exemple d’application : les Badi’s............................................2510.1. Définition d’une Business Add-Ins (Badi).........................................2510.2. Déclaration d’une Badi (SE18)..........................................................25

Auteur : Vincent Ferré Capitalisation ABAP OBJECT.doc /33

CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

10.3. Déclaration d’une implémentation (SE19).......................................2610.4. Appel d’une Badi dans un programme.............................................30

11. Annexes.............................................................................................3111.1. Normes et conventions.......................................................................3111.2. Les transactions indispensables........................................................31


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

1. Introduction

Ce document à pour ambitieux objectif de donner une vision globale de l’ABAP OBJECT. Avant d’aborder le vif du sujet, nous nous attarderons le temps d’un premier chapitre sur le concept de la programmation orientée objet commun à tous les Langages Orientés Objet. Après un bref historique de l’ABAP OBJECT, nous envisagerons les champs d’application ainsi que les enjeux de cette technologie appelée « Controls Technolgy ». Puis nous nous intéresserons dans un chapitre plus technique à ses aspects Hardware.

Les containers, pré requis indispensable à la construction d’interface graphique complexe feront l’objet d’une cinquième partie qui précèdera les trois principaux chapitres à savoir la création et l’utilisation d’une classe d’objet.

Enfin, la notion d’interface vous sera essentielle pour comprendre et apprécier l’intérêt des Badis (Business Add-In) qui feront l’objet des deux derniers chapitres.

2. La programmation orientée objet

2.1. Le concept

En terme de programmation, il y a eu plusieurs évolutions successives. Une des principales fut la programmation structurée, dont le principe premier était de diviser un programme en sous-programmes, afin de pouvoir en gérer la complexité. Ce type de programmation tient avant tout compte des traitements et peut être résumé par la question "Que doit faire le programme ?".

Les langages orientés objets sont une nouvelle méthode de programmation qui tend à se rapprocher de notre manière naturelle d'appréhender le monde. Les Langages Orientés Objet se sont surtout posé la question "Sur quoi porte le programme ?". En effet, un programme informatique comporte toujours des traitements, mais aussi et surtout des données. Si la programmation structurée s'intéresse aux traitements puis aux données, la conception objet s'intéresse d'abord aux données, auxquelles elle associe ensuite les traitements. L'expérience a montré que les données sont ce qu'il y a de plus stable dans la vie d'un programme, il est donc intéressant d'architecturer le programme autour de ces données.

La programmation orientée objet consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel (que l'on appelle domaine) en un ensemble d'entités informatiques. Ces entités informatiques sont appelées objet. Il s'agit de données informatiques regroupant les principales caractéristiques des éléments du monde réel (taille, la couleur, ....)

La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d'objets, d'entités ayant une existence matérielle (chien, voiture, ampoule, ...) ou bien virtuelle (sécurité sociale, temps, ...).


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Un objet est caractérisé par plusieurs notions:

Les attributs: Il s'agit des données caractérisant l'objet. Ce sont des variables stockant des informations d'état de l'objet

Les méthodes (appelées parfois fonctions membres): Les méthodes d'un objet caractérisent son comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier

L'identité: L'objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état. On construit généralement cette identité grâce à un identifiant découlant naturellement du problème (par exemple un produit pourra être repéré par un code, une voiture par un numéro de série, ...) => Notion d’instance

2.2. Quelques définitions.

OO : Orientation Objet. La résolution d’un problème dans son contexte objet tend plus vers une représentation de la solution à partir d’objets du monde réel.

Classe : On appelle classe la structure d'un objet, c'est-à-dire la déclaration de l'ensemble des entités qui composeront un objet. Un objet est donc "issu" d'une classe, c'est le produit qui sort d'un moule. En réalité on dit qu'un objet est une instanciation d'une classe, c'est la raison pour laquelle on pourra parler indifféremment d'objet ou d'instance (éventuellement d'occurrence). Une classe est composée de deux parties: Les attributs (parfois appelés données membres): il s'agit des données représentant l'état de l'objet Les méthodes (parfois appelées fonctions membres): il s'agit des opérations applicables aux objets

Encapsulation : L'encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d'une structure en cachant l'implémentation de l'objet, c'est-à-dire en empêchant l'accès aux données par un autre moyen que les services proposés. L'encapsulation permet donc de garantir l'intégrité des données contenues dans l'objet.

Polymorphisme : Le nom de polymorphisme vient du grec et signifie qui peut prendre plusieurs formes. Cette caractéristique essentielle de la programmation orientée objet caractérise la possibilité de définir plusieurs fonctions de même nom mais possédant des paramètres différents (en nombre et/ou en type), si bien que la bonne fonction sera choisie en fonction de ses paramètres lors de l'appel. Le polymorphisme rend possible le choix automatique de la bonne méthode à adopter en fonction du type de donnée passée en paramètre.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Héritage : L'héritage (en anglais inheritance) est un principe propre à la programmation orientée objet, permettant de créer une nouvelle classe à partir d'une classe existante. Le nom d'"héritage" (pouvant parfois être appelé dérivation de classe) provient du fait que la classe dérivée (la classe nouvellement créée) contient les attributs et les méthodes de sa super-classe (la classe dont elle dérive). L'intérêt majeur de l'héritage est de pouvoir définir de nouveaux attributs et de nouvelles méthodes pour la classe dérivée, qui viennent s'ajouter à ceux et celles héritées. Par ce moyen on crée une hiérarchie de classes de plus en plus spécialisées. Cela a comme avantage majeur de ne pas avoir à repartir de zéro lorsque l'on veut spécialiser une classe existante. De cette manière il est possible d'acheter dans le commerce des librairies de classes, qui constituent une base, pouvant être spécialisées à loisir (on comprend encore un peu mieux l'intérêt pour l'entreprise qui vend les classes de protéger les données membres grâce à l'encapsulation...).

Composants : Attributs, méthodes, évènements, interfaces, type internes.

Visibilité : L'utilisateur d'une classe n'a pas forcément à connaître la façon de laquelle sont structurées les données dans l'objet, cela signifie qu'un utilisateur n'a pas à connaître l'implémentation. Ainsi, en interdisant l'utilisateur de modifier directement les attributs, et en l'obligeant à utiliser les fonctions définies pour les modifier (appelées interfaces), on est capable de s'assurer de l'intégrité des données (on pourra par exemple s'assurer que le type de données fournies est conforme à nos attentes ou encore que les données se trouvent bien dans l'intervalle attendu). L'encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité définissent les droits d'accès aux données selon que l'on y accède par une méthode de la classe elle-même, d'une classe héritière, ou bien d'une classe quelconque. Il existe trois niveaux de visibilité

Publique: Les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes d'une classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection des données

Protégée: l'accès aux données est réservé aux fonctions des classes héritières, c'est-à-dire par les fonctions membres de la classe ainsi que des classes dérivées

Privée : l'accès aux données est limité aux méthodes de la classe elle-même. Il s'agit du niveau de protection des données le plus élevé

Instance : Objet de programmation qui hérite des composants d’une classe. Si on définit la classe voiture, les objets Peugeot 406, Renault 18 seront des instanciations de cette classe. Il pourra éventuellement exister plusieurs objets Peugeot 406, différenciés par leur numéro de série. Mieux: deux instanciations de classes pourront avoir tous leurs attributs égaux sans pour autant être un seul et même objet. C'est le cas dans le monde réel, deux T-shirts peuvent être strictement identiques et pourtant ils sont distincts. D'ailleurs en les mélangeant il serait impossible de les distinguer...

Control : Dans le concept écran chaque programmeur peut se contenter de créer des éléments simples comme des radio boutons ou des check box mais avec la technologie objet on peut créer des éléments plus complexes comme une zone d’éditeur ou une grille ALV, ces éléments sont appelés Control. Ce ne sont pas des éléments de l’écran mais des objets à part entière avec leurs attributs et leurs propres fonctions. Dans tous les cas il y’a toujours une interaction entre le control et l’écran lui-même.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

3. Qu’est ce que l’ABAP OBJECT ?

L’ABAP Object est une notion apparue avec le Release 4.0 R/3. Nous pouvons lui prêter deux sens : d’un côté il représente l’environnement de développement ABAP dans son intégralité de l’autre côté il représente l’orientation objet du langage de programmation ABAP. L’Orientation Objet est une part très importante des futures orientations de SAP. Elle permet de créer des programmes, des objets d’autorisation, des objets de blocage, d’encapsuler des fonctions dans différents programmes en définissant des interfaces. Le BOR (Business Object Repository) vous permet de créer des objets pour un usage interne mais également externe (DCOM / CORBA) ce qui auparavant n’était pas supporté par le langage ABAP.

La notion d’objet existe déjà depuis longtemps dans des langages de programmation comme Java et C++, modèle sur lequel a été développé l’ABAP Object qui est d’ailleurs totalement compatible avec ces langages. L’implémentation d’objets dans le noyau du langage ABAP permet d’améliorer les temps de réponse du SAPGUI.

3.1. Les champs d’applications de l’ABAP OBJECT.

Avec la programmation objet est apparu le terme de SAP Enjoy. SAP Enjoy est une des orientations de SAP qui tend à faire des transactions standards plus visuelles, plus conviviales et avec plus de fonctionnalités. La programmation objet permet notamment d’éviter la multiplication des écrans de saisie en regroupant sur un même écran plusieurs sous écrans. Avec les dernières innovations sont apparues les fonctions d’arborescence ou de grille ALV. Cette nouvelle technologie n’a pas pour but de remplacer les traditionnels écrans SAP mais d’améliorer leur interactivité grâce à des contrôles (cf. définition) de plus en plus aboutis comme les éditeurs de texte, le navigateur web … Au fur et à mesure des montées de versions, il y a fort à parier que les transactions standards utiliseront de plus en plus la technologie objet. Une très bonne illustration de SAP Enjoy est la transaction ME21N qui est la version objet de la transaction ME21 ( à noter tout particulièrement la synthèse des commandes qui permet de créer des commandes à partir de commandes existantes ).

La programmation objet peut s’employer dans un contexte beaucoup plus basique et si le principal intérêt est de pouvoir créer des objets graphiques comme une arborescence, une image, une grille, une fenêtre WEB, l’objet peut être tout à fait virtuel, on peut très bien imaginer une classe d’objet ‘période comptable’ qui possède des attributs n°période, exercice comptable et des méthodes changement de période comptable, conversion date => période … Il existe une multitude d’objets standards appelés objets de gestion visibles via la transaction SWO1. Les Bapis ne sont autres que les méthodes de ces objets de gestion.

Enfin les BADI (Business Add In) sont une techno peu connue et promue à un bel avenir. Les BADI sont une version objet des user exits. Elles sont essentiellement destinées à la modification de standard puisque le code n’est plus contenu dans une fonction comme dans un user exit mais dans une méthode définie dans une interface (voir def plus bas). Une BADI possède tous les avantages de la programmation objet l’encapsulation et surtout le polymorphisme puisque pour une même méthode il est possible de définir plusieurs implémentations. Mais le principal avantage d’une BADI est de pouvoir activer et désactiver une implémentation ce qui permet en cas de bug standard SAP de prouver que le bug n’est pas du à la modification faite dans le standard. De plus les modifications sont moins risquées puisque cela permet de limiter les points


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

de contacts avec le programme standard ( la modification est faite dans la méthode ) donc moins d’impact en cas de montée de version ou de support package.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

4. Interface Objet

4.1. Architecture

D’un point de vue technique, les controls sont des composants logiciels indépendants et réutilisables contrairement aux fonctions qui ne peuvent être utilisés que dans le système cible. Chaque control est en capsulé dans une classe ABAP appelés classe enveloppante. Cette classe est ensuite utilisée pour créer une instance du control. Le système crée ainsi deux objets :Le control lui-même du côté Frontend (Serveur de présentation)L’instance du côté Backend (Serveur d’application).

Néanmoins lorsque vous utilisez un control, certaines méthodes sont exécutées directement du côté Frontend ce qui élimine la communication avec le serveur d’application et améliore les performances

Note :

RFC (Remote Function Call) est un protocole de communication basé sur le protocole CPI-C. Il existe de puis la version 2.2 de SAP et permet la communication synchrone entre deux programmes : un programme « Client » appelant un module de fonction d’une application « Serveur ».

OLE (Object Link and Embedding) est une technologie développée par Microsoft. A l’origine OLE est un mécanisme permettant aux applications de créer et de gérer des documents contenant des données ou des objets de format différents comme des tableaux, des textes ou des images. L’utilisateur a ainsi l’impression de n’utiliser qu’une seule application. Par la suite, Microsoft a standardisé le principe OLE avec la définition de COM (Component Object Model) et DCOM (Distributed COM). Ces normes proposent des méthodes communes d’accès aux services de différents types de logiciel et l’utilisation de serveurs distants.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

4.2. Control Framework

Control Framework est une classe globale définie dans le DDIC appelée CL_GUI_CFW et qui contient toutes les méthodes permettant la communication entre le frontend et le backend. Toutes les classes d’objet sont héritées de cette classe et utilisent ses méthodes pour communiquer.Il existe une hiérarchie selon laquelle toutes les classes de control sont héritées de deux classes standards : CL_GUI_OBJECT et CL_GUI_CONTROL.La classe CL_GUI_OBJECT contient toutes les méthodes pour la gestion ActiveX ou Java Beans.La classe CL_GUI_CONTROL elle permet l’affichage des controls sur les écrans.

Le Control Framework permet la communication des appels de méthode entre frontend (Serveur d’application) et le backend (Serveur de présentation). Lorsqu’un événement est déclenché par un utilisateur sur le serveur de présentation il est transféré au serveur d’application via le SAPGUI. Sur le serveur d’application (backend) le Control Framework transforme cet événement en un événement ABAP OBJECT. La communication entre le serveur d’application et le serveur de présentation ainsi que le SAPGUI utilisé est primordial et détermine en grande partie les performances du programme ABAP.

Le Control Framework supporte la technologie ActiveX pour les systèmes d’exploitation Windows 32 bits et Java Beans pour toutes les autres plates-formes. Lors de l’utilisation d’un control, le système d’exploitation est automatiquement reconnu et réagit en conséquence ( il n’y a pas besoin de faire de différenciation entre les plates-formes lors de la programmation ).


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

5. Les containers

Un container SAP est un objet dans lequel vous pouvez placer d’autres objets comme une grille, une image ou un éditeur de texte. Un container défini une zone d’écran pour laquelle on va définir des dimensions ainsi que sa position. On dit que le container est le parent du control qu’il contient.Il existe 5 types de containers tous hérités de la classe CL_GUI_CONTAINER:

Custom Container : Ce type de container est utilisé lorsque vous avez besoin de définir une zone de travail très précise dans un écran ou un sous écran. Cette zone est définie via le Screen Painter (CL_GUI_CUSTOM_CONTAINER).

Dialog Box Container : Ce type de container est utilisé pour les boîtes de dialogues ou les fenêtres plein écran (CL_GUI_DIALOGBOX_CONTAINER).

Docking Container : Ce type de container est utilisé pour créer des zones de travail redimensionnables de chaque côté de l’écran (haut, bas, gauche, droite) (CL_GUI_DOCKING_CONTAINER).

Splitter Container : Ce type de container est utilisé lorsque vous voulez diviser une zone de travail en plusieurs autres zones contenant chacun un control (CL_GUI_SPLITTER_CONTAINER).

Easy Splitter Container : Ce type de container est utilisé lorsque vous voulez diviser une zone de travail en deux zones (verticalement ou horizontalement) chacune contenant un control indépendant (CL_GUI_EASY_SPLITTER_CONTAINER).

Les containers sont des objets eux-mêmes et peuvent être imbriqués les uns les autres.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

6. Création d’une classe d’objet globale (SE24).

Il est possible de créer ses propres classes d’objet, néanmoins une classe d’objet est la plupart du temps héritée d’une classe existante. La transaction permettant de créer une classe est : SE24. Lors de la création une option permet de préciser de quelle classe hérite l’objet crée. La classe ainsi créée reprendra alors les attributs les méthodes et les évènements qui lui sont associés. L’intérêt de créer sa propre classe d’objet est de pouvoir ajouter, créer ou modifier ses propres attributs, méthodes ou événements, ce qui n’est pas possible en utilisant les classes standards.

Une classe d’objet peut être déclarée soit de manière globale soit de manière locale. Cependant qu’elle soit globale ou locale, l’instance de cette classe utilisera exactement les mêmes instructions pour appeler les méthodes, déclencher des événements ou modifier les attributs.

Classe globale

Les classes globales sont les classes définies au niveau du DDIC grâce à la transaction SE24. Elles sont centralisées dans un pool de classe dans une libraire du Repository et sont accessibles à partir de n’importe quel programme ABAP.

Classe locale

Une classe locale est définie dans un programme ABAP et par conséquent n’est accessible qu’à partir du programme dans lequel elle est définie. Cela présente un intérêt par rapport à une classe globale qui peut être utilisée par n’importe qui. Lorsque vous déclarez une classe dans un programme ABAP, le système regarde d’abord si le nom correspond à une classe locale existante, si aucune classe ne correspond, il cherche une classe globale. Il n’y a aucune différence entre une classe globale et une classe locale si ce n’est la question de la visibilité. Il est possible de définir des attributs, des méthodes, des événements des types internes pour une classe locale tout comme pour une classe globale.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Héritage de la classe créer par rapport à une classe déjà existante (ici la classe cl_gui_alv_grid)


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

6.1. Création d’un attribut

Les attributs sont des données internes à la classe qui peuvent avoir n’importe quel type. Ils définissent l’état de l’objet, permettent de créer et d’adresser les objets hérités de la classe.Pour créer un attribut dans une classe plusieurs éléments doivent être renseignés.

Attribut : Nom unique donné à l’attribut (cf. normes ABAP OBJECT)Type : Déclarer un attribut peut être assimiler à déclarer une variable. Vous pouvez déclarer soit une constante, soit une instance soit un static (partagé par toutes les instances de la classe)Visibilité : cf. définitionStatut : ?Read Only : Spécifie si l’utilisateur peut modifier la valeur de l’attribut.Référence type : spécifie le type de l’attribut (char 1, num 2…)Description : sans commentaireValeur initiale : Obligatoire pour les constantes

Une fois l’attribut crée, le système génère automatiquement le code ABAP correspondant dans la définition de la classe excepté pour les attributs dont le statut est égal à ‘Modéliser’. Si vous modifié un attribut de type static, vous le modifier pour toute la classe. Si vous modifiez un attribut de type instance, vous le modifiez uniquement pour une instance de la classe.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

6.2. Création d’une méthode

Les méthodes sont des procédures internes qui permettent de définir les comportements d’un objet. Elles peuvent utiliser tous les attributs de la classe et même modifier leur valeur. Elles ont des paramètres d’entrée et de sortie tout comme une fonction. Il y a deux types de méthodes :- Les méthodes d’instance qui se réfèrent toujours à une instance donnée de la classe.- Les méthodes statiques qui interagissent sur toutes les instances de la classe.

Méthode : Nom unique donné à la méthode (cf. normes ABAP OBJECT)Type : spécifie si c’est une méthode d’instance ou statique (voir ci dessus)Visibilité : cf. définitionType de méthode : précise s’il s’agit d’une méthode normale, CONSTRUCTOR DESTRUCTOR GET ou SET.Description : sans commentaireAjout de paramètres :L’ajout de paramètre se fait en cliquant sur le bouton ‘Paramètres’ de la méthode. La déclaration des paramètres se fait de la même manière que dans une fonction.Paramètre : nom uniqueCatégorie : Import, Export ou changingType : CHAR, NUM, Structure…

Implémentation de la méthode :L’implémentation de la méthode se fait en cliquant sur l’icône :


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

6.3. Création d’un événement

Vous pouvez définir dans les classes et les interfaces des événements qui permettront d’appeler des méthodes. L’instruction RAISE EVENT vous permet de déclencher cet événement avec les paramètres d’importation correspondants alors que l’instruction SET HANDLER permet d’affecter une méthode d’une classe à une instance de cette même classe. Lorsque l’évènement est déclenché, le système appelle toutes les méthodes qui lui sont associées.

Event : nom unique identifiant l’événement.Type : Evènement d’instance ou statique.Visibilité : cf. définitionDescription : sans commentaire

Ajout de paramètres :L’ajout de paramètre se fait en cliquant sur le bouton ‘Paramètres’ de la méthode. La déclaration des paramètres se fait de la même manière que dans une fonction.Paramètre : nom uniqueCatégorie : Import, Export ou changingType : CHAR, NUM, Structure…


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

6.4. Création d’un type interne

Une classe peut contenir des types internes réutilisables par la suite dans les programmes qui l’utilise. Définir un type interne dans une classe interne vous dispense ainsi de le déclarer à chaque fois dans le programme. La définition du type interne se fait en cliquant sur le select option.

Exemple de déclaration d’un type interne :

***** Déclaration du typeTYPES : BEGIN OF ty_node_table. INCLUDE STRUCTURE treev_node, posarb LIKE zmds03-posarb, pos LIKE zmds03-pos.TYPES: END OF ty_node_table.

***** Déclaration d’une table avec la structure du typeDATA tbl_node TYPE TABLE OF ty_node_table.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

7. Création d’une classe d’objet locale.

7.1. Déclaration d’une classe locale

La déclaration d’une classe locale se décompose en deux parties : la définition et l’implémentation.Dans la définition, vous déclarez tous les composants auquel vous pouvez affecter une visibilité.CLASS <Nom de la classe> DEFINITION.PUBLIC SECTION .…PROTECTED SECTION .…PRIVATE SECTION .…ENDCLASS.

Remarque : pour définir une classe héritée d’une super classe vous devez utiliser l’instruction :CLASS <sous classe> DEFINITION INHERITING FROM <super classe>

Exemple de déclaration :

CLASS lcl_application DEFINITION.

PRIVATE SECTION.***** Déclaration des données DATA: node_key TYPE tv_nodekey, relatkey TYPE tv_nodekey.

ENDCLASS.

7.2. Déclaration des évènements

En Abap Objet il est possible d’associer des méthodes à des évènements. Cela signifie que une méthode peut être exécutée lors du déclenchement d’un événement.

La déclaration d’une instance d’événement se fait selon la syntaxe suivante :EVENTS <événement>EXPORTING VALUE <Paramètres> TYPE <Type> (facultatif)La déclaration d’un événement statique se fait selon la syntaxe suivante :CLASS-EVENTS <événement>EXPORTING VALUE <Paramètres> TYPE <Type> (facultatif)

Lorsque vous déclarez une instance d’événement elle hérite des paramètres d’exportation définis pour le paramètre déclaré dans la classe

Exemple de déclaration d ‘évènement :

CLASS lcl_application DEFINITION. PUBLIC SECTION.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

EVENTS node_context_menu_request EXPORTING VALUE node_key TYPE tv_nodekey VALUE menu TYPE cl_menu

ENDCLASS.

7.3. Déclaration des méthodes

Déclaration

Instruction :METHODS : <Nom de la méthode> FOR EVENT <Nom de l’événement déclenchant la méthode>FOR <Nom de la classe comportant l’évènement> IMPORTING … TYPE (facultatif)EXPORTING … TYPE (facultatif)CHANGING … TYPE (facultatif)RETURNING … VALUE <Variable> (facultatif)EXCEPTION <Exception> (facultatif).

Exemple de déclaration de méthodes :

CLASS lcl_application DEFINITION.

PUBLIC SECTION.* Déclaration des méthodes publiques METHODS: simple_clic FOR EVENT context_menu_request OF zcl_gui_alv_grid_mds IMPORTING e_object.

* Déclaration d’une méthode statique CLASS-METHODS handle_node_context_menu_req FOR EVENT node_context_menu_request OF cl_gui_list_tree IMPORTING node_key menu.

ENDCLASS.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Implémentation

Si vous déclarez des méthodes vous devez définir leur implémentation (le code de la méthode). Tout comme dans une fonction vous pouvez définir des exceptions pour les situations d’erreur (EXCEPTIONS). L’implémentation se fait de la manière suivante.

CLASS <Nom de la classe> IMPLEMENTATION.METHODE <nom de la méthode>.

CodingENDMETHODE.

ENDCLASS.

Exemple d’implémentation :

CLASS lcl_application IMPLEMENTATION.

METHOD simple_clic.IF e_object is initial.

RAISE EVENT node_context_menu_requestENDIF. ENDMETHOD.

METHOD handle_node_context_menu_req. MESSAGE e001(zccm) WITH ‘L’objet est vide !!’. ENDMETHOD.

ENDCLASS.

Dans cet exemple la méthode « simple_clic » déclenche un l’événement « node_context_menu_request » si le paramètre d’importation « e_object » est vide. L’événement « node_context_menu_request » va déclencher l’appel de la méthode « handle_node_context_menu_req » qui va afficher un message d’erreur.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

8. Utilisation des composants d’une classe

8.1. Déclaration d’un objet

La déclaration d’un objet se fait de la même manière qu’une déclaration de variable.Ex : data g_arbre TYPE REF TO cl_gui_simple_tree (Déclaration d’un objet arbre qui va hériter de la classe cl_gui_simple_tree).Ensuite il faut utiliser l’instruction Create pour créer l’objet. Des paramètres sont souvent obligatoires. Comme le nom du container dans lequel il faut créer l’objet ainsi que des paramètres visuels, des paramètres de modification. La création d’un objet hérité d’une classe appelle automatiquement une méthode spéciale appelée : ‘CONSTRUCTOR’ ou ‘CLASS_CONSTRUCTOR’ lorsque c’est la première fois que vous accéder aux composants de la classe.Syntaxe : DATA <Nom de la variable> TYPE REF TO <Nom de la classe>

CREATE OBJECT <Nom de la variable> EXPORTING <Nom du paramètre>Exemple : Déclaration d’un container (zone d’un écran) et d’un objet de type image.Création de l’image dans la zone d’écran déclarée

Data : g_container1 TYPE REF TO cl_gui_docking_container, g_picture TYPE REF TO cl_gui_picture,

***** Création du container gauche CREATE OBJECT g_container1 EXPORTING repid = g_repid dynnr = '100' extension = 300 side = cl_gui_docking_container=>dock_at_left.

***** Création d'un objet image CREATE OBJECT g_picture EXPORTING parent = g_container1.

Ici la variable g_picture est une instance de la classe cl_gui_picture on dit également que c’est une variable référence.

8.2. Utilisation des attributs

Les attributs d’une classe peuvent être appelés dans le programme selon la syntaxe :<Nom de l’objet>=><Nom de l’attribut>Ex : w_effect = cl_dragdrop=>copy + cl_dragdrop=>move.Ici la variable w_effect est la somme de deux attributs de la classe cl_dragdrop ‘copy’ et ‘move’. Lorsque l’on regarde dans la classe cl_dragdrop, l’attribut ‘copy’ a pour valeur 1 et l’attribut ‘move’ a pour valeur 2. La variable w_effect prend bien la valeur 3.Un attribut s’il n’est pas déclaré comme constante peut être modifié dans l’implémentation d’une méthode.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

8.3. Utilisation des événements

Déclenchement d’un événement

Pour déclencher un événement :RAISE EVENT <Evénement> EXPORTING <Paramètre d’exportation> = <Valeur>Exemple : RAISE EVENT before_user_command EXPORTING e_ucomm = i_ucomm.

Remarque : une instance d’événement peut être déclencher par n’importe quelle méthode de la classe alors qu’un événement statique ne peut être déclencher que par une méthode statique.

Enregistrement un évènement

Pour les événements définis dans les classes globales, il est indispensable d’enregistrer les événements pour l’instance de la classe. Une méthode permet d’effectuer cette opération : ‘SET_REGISTERED_EVENTS’.Exemple :

***** Déclaration des structures et des tables pour la méthode DATA : tbl_events TYPE cntl_simple_events, str_event TYPE cntl_simple_event, g_tree TYPE REF TO cl_gui_list_tree.

***** Enregistrement de l’événement menu contextuel str_event-eventid = cl_gui_list_tree=>eventid_node_context_menu_req. str_event-appl_event = ' '. APPEND str_event TO tbl_events.

***** Affectation des événements à l'objet arbre CALL METHOD g_tree->set_registered_events EXPORTING events = tbl_events EXCEPTIONS cntl_error = 1 cntl_system_error = 2 illegal_event_combination = 3.

8.4. Utilisation des méthodes

Affectation d’une méthode à une instance

Pour que la méthode que vous allez définir puis implémenter soit appelée lors du déclenchement d’un événement il est indispensable d’affecter cette méthode à une instance de la classe comportant l’évènement. Cela se fait grâce à l’instruction :SET HANDLER (Instance de la classe contenant la méthode)->(Nom de la méthode) FOR (Instance de la classe contenant l’événement)


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Exemple : Affectation d’une méthode ‘contextmenuselected’ définie dans la classe lcl_application à une instance de la classe cl_gui_picture

Data : g_application TYPE REF TO lcl_application.DATA : g_picture TYPE REF TO cl_gui_picture.CREATE OBJECT g_application.CREATE OBJECT g_picture.SET HANDLER g_application->contextmenuselected FOR g_picture.

Astuce : l’addition de ‘FOR ALL INSTANCES’ permet d’affecter la méthode à toutes les instances déclarées.

Appel d’une méthode contenue dans une classe globaleUne fois déclarée l’instance de la classe globale vous pouvez appeler les méthodes grâce à l’instruction CALL METHOD.CALL METHOD (Nom de l’instance)->(Nom de la méthode)IMPORTING f1 = f2EXPORTING f1 = f2CHANGING f1 = f2RETURNING f1 = f2EXCEPTION f1 = f2.

Exemple d’appels de méthodes :

***** Déclaration des objets menu contextuels et image DATA : w_menu TYPE REF TO cl_ctmenu, g_picture TYPE REF TO cl_gui_picture,

***** Création d’un objet menu CREATE OBJECT w_menu .

***** Création d'un objet image CREATE OBJECT g_picture EXPORTING parent = g_container1.

***** Ajout d’une fonction dans le menu contextuel CALL METHOD w_menu->add_function EXPORTING text = ‘Fonction n°1’ fcode = 'INSAV'.

***** Ajout d’un séparateur CALL METHOD w_menu->add_separator.

***** Ajout d’une fonction dans le menu contextuel CALL METHOD w_menu->add_function EXPORTING text = ‘Fonction n°2’ fcode = 'INSDED'.

***** Appel du menu contextuel CALL METHOD g_picture->display_context_menu EXPORTING context_menu = w_menu EXCEPTIONS error = 1.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

9. Les interfaces.

9.1. Définition

Les classes d’objet vous permettent déjà de modeler des objets de gestion tels que des clients, des comptes ou des articles et de concevoir des applications de manière structurée. Cependant il est courant que des classes semblables utilisent des méthodes similaires mais ayant des implémentations différentes. C’est à dire que pour un même point de contact : la méthode, on a besoin de fonctionnalités différentes.

Exemple :Imaginons deux classes : une classe Compte d’Epargne et une classe Plan d’Epargne Logement. Ces deux classes ont toutes les deux besoin d’une méthode de calcul du taux de rétribution en fin d’année mais le calcul est différent pour chacune des deux classes. Au lieu de créer deux méthodes différentes (une pour chaque classe), il est possible de créer une interface comprenant une méthode utilisée par les deux classes mais dont l’implémentation (la fonctionnalité) elle sera définie au niveau de la classe (les deux classes pourront appeler la même méthode mais le code sera différent pour les deux classes). Ceci a pour avantage de limiter les points de contact avec l’utilisateur qui n’aura pas à se soucier du type de compte => Notion de polymorphisme.

9.2. Déclaration d’une interface

9.2.1. Déclaration dans le DDIC La création d’une interface se fait exactement de la même manière que celle d’une classe d’objet.Transaction SE24 :


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

9.2.2.

Tout comme une classe, on peut définir des attributs, des évènements, des types internes ou des méthodes. Les différences sont que l’on ne peut pas implémenter les méthodes puisque l’implémentation se fait dans la classe qui appelle cette méthode. De même vous ne pouvez pas définir de visibilité pour les attributs puisque la notion d’héritage n’existe pas et que les attributs doivent forcément être visibles pour les classes utilisant l’interface. Pour pouvoir utiliser les méthodes d’une interface, il faut déclarer l’interface au niveau de la classe elle-même.

9.2.3. Déclaration d’une interface locale.

Il est également possible de définir une interface locale de la même manière que l’on définit une classe locale. Cette déclaration se fait selon la syntaxe suivante :

INTERFACE < Nom de l’interface >. ...

ENDINTERFACE.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Les instructions pour déclarer des attributs, des méthodes ou des évènements sont les mêmes que dans une classe locale.

9.3. Implémentation d’une interface

Comme vu précédemment, l’implémentation d’une méthode définie dans une interface est faite dans la classe qui l’utilise. L’implémentation se fait via l’instruction suivante :

METHOD <Nom de l’interface~Nom de la méthode>…

ENDMETHOD.

Exemple d’utilisation d’une interface.

****** Déclaration d’une interface « Status » avec une méthode « Write »INTERFACE status. METHODS write.ENDINTERFACE.

****** Déclaration d’une classe « Ship » utilisant l’interface « StatusCLASS ship DEFINITION INHERITING FROM vessel. PUBLIC SECTION. INTERFACES status.ENDCLASS.

CLASS ship IMPLEMENTATION.

***** Implémentation de méthode “Write” pour la classe “Ship” METHOD status~write. DATA id. id = me->get_id( ). WRITE: / name, 'is vessel', id, 'and has speed', speed. ENDMETHOD.ENDCLASS.

****** Déclaration d’une classe « Coast_guard» utilisant également l’interface « StatusCLASS coast_guard DEFINITION. PUBLIC SECTION. INTERFACES status. ALIASES write FOR status~write. PRIVATE SECTION. DATA caller TYPE string.ENDCLASS.

***** Implémentation de méthode “Write” pour la classe “coast_guard ”CLASS coast_guard IMPLEMENTATION. METHOD status~write. IF caller IS INITIAL.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

WRITE: / 'Coast guard received no call'. ELSE. WRITE: / 'Coast guard received a call from', caller. ENDIF. ENDMETHOD.ENDCLASS.

Dans cet exemple on voit nettement que les deux classes « Ship » et “coast_guard ” utilisent la même méthode et pourtant l’implémentation de la méthode est différente pour chacune des classes.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

10. Un exemple d’application : les Badi’s

10.1.Définition d’une Business Add-Ins (Badi)

Les Badis tout comme les user exits sont des points d’entrée laissés par SAP afin de pouvoir personnaliser les programmes standard SAP et les adapter aux besoins spécifiques du métier. Néanmoins le code source qui interagit sur le programme standard est externalisé puisqu’il est contenu dans une méthode d’interface. Les Badis peuvent être insérées dans le standard SAP pour satisfaire un besoin trop spécifique pour être fourni par le standard. Les Badis sont un petit peu la version objet des user exits comme ils sont définis dans la transaction SMOD.

SAP garantie la compatibilité et la non-régression de ses Badis en cas de montée de version. De plus la modification d’une Badi standard ne nécessite pas de s’enregistrer auprès du SSCR (SAP Software Change Registration).

10.2.Déclaration d’une Badi (SE18)

Avant d’effectuer la modification de standard vous devez définir une Badi via la transaction SE18.

Lorsque vous définissez une Badi le système génère automatiquement une interface selon la norme : ZIF_EX_<Nom de la Badi>. C’est dans cette interface qu’il faut définir les attributs, les méthodes ou les évènements que vous allez utiliser dans le programme standard.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Remarque : vous avez la possibilité de définir un filtre pour l’exécution de la Badi avec l’option ‘Filtre’. Pour cela vous devez définir un élément de donnée qui possède soit une plage de valeur soit une aide à la recherche soit une table de valeur. Une fois le filtre défini, un paramètre correspondant est automatiquement ajouté dans toutes les méthodes définies dans l’interface.

10.3.Déclaration d’une implémentation (SE19)

Une fois la Badi et l’interface créée via la transaction SE18, il faut définir une implémentation. C’est à dire une version du code utilisée par les méthodes définies dans l’interface générée (l’interface vous permet juste de créer les attributs, les méthodes avec leurs paramètres ou les évènements mais ce que font les méthodes se définit dans l’implémentation). Vous pouvez créer plusieurs implémentation pour une même Badi mais vous ne pouvez en activer qu’une seule à la fois. C’est un avantage considérable par rapport aux user exits défini en CMOD/SMOD puisque vous pouvez faire plusieurs versions pour vos méthodes et tester le comportant de chacune simplement en activant l’une ou l’autre implémentation. Vous pouvez même désactiver toutes les implémentations et ainsi retrouver le comportement initial du programme appelant la méthode.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

Pour créer une implémentation : Transaction SE19.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

En double cliquant sur les méthodes, vous pouvez insérer votre code comme vous le feriez dans une fonction en SE37.

: Activation d’une Implémentation : Désactivation d’une Implémentation.

Remarque :L’ajout d’un filtre dans une Badi permet d’activer plusieurs implémentations simultanément. Dans l’exemple ci dessous, nous avons défini un filtre sur le nom d’utilisateur. Pour l’utilisateur ‘FERRE’ ce sera l’implémentation ‘ZZ_EXEMPLE’ qui sera prise en compte alors que pour les utilisateurs ‘POLO’ et ‘TOTO’ se sera l’implémentation ‘ZZ_EXEMPLE2’. Si aucun filtre n’est défini vous ne pouvez activer qu’une seule implémentation à la fois.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

L’implémentation ZZ_EXEMPLE est active pour l’utilisateur ‘FERRE’

L’implémentation ZZ_EXEMPLE2 est active pour l’utilisateur ‘POLO’ et ‘TOTO’.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

10.4.Appel d’une Badi dans un programme

Une fois la Badi créée et son implémentation activée, il faut appeler la méthode ainsi définie dans le programme source. Cet appel se fait en trois étapes :

Déclaration d’une variable du type de l’interface Création d’une instance de l’interface grâce à cette variable Appel de la méthode via l’instance créée.

Exemple d’utilisation d’une Badi.

REPORT BUSINESSADDIN.

***** Déclaration de la classe qui va permettre de créer une instance de l’interfaceclass cl_exithandler definition load.

***** Déclaration d’une variable du type de l’interfacedata exit type ref to if_ex_zz_exemple. START-OF-SELECTION.

***** Création d’une instance de l’interface call method cl_exithandler=>get_instance changing instance = exit.

END-OF-SELECTION.

***** Appel de la méthode définie dans l’interface call method exit->TEST_METHODE.

L’implémentation de l’interface pourrait être définie de cette manière

method ZIF_EX_Z_EXEMPLE~TEST_METHODE. write : 'Ceci est un exemple d utilisation de Badi'.endmethod.


CCSA

P

Capitalisation ABAP

OBJECT

Version 1.0 Le 01/10/02

11. Annexes

11.1. Normes et conventions

Conventions pour les objets Classes : CL_<Nom de la classe>Interfaces : IF_<Nom de l’interface>Classes locales : LCL_<Nom de la classe locale>Interfaces locales : LIF_<Nom de l’interface locale>

Conventions pour les composantsMéthode : GET_<attribut> pour les méthodes où l’on récupère des valeursSET_<attribut> pour les méthodes où l’on modifie des valeurs CREATE_<objet> lorsque vous créer quelque choseON_<évènement> lorsque c’est une méthode spécifique à un événementIS_<adjectif> pour une méthode retournant nu booléenCHECK_<objectif> pour vérifier une valeurEvénements : <Nom>_<Participe> ex : BUTTON_PUSH, DOUBLE_CLICK…Types internes : TY_<Nom du type interne>Constantes : CO_<Nom de la constante>

Convention pour les classes locales.Paramètres : IM_<Nom> pour les paramètres d’importEX_<Nom> pour les paramètres d’exportCH_<Nom> pour les paramètres changeantRE_<Nom> pour le retour d’une valeur

11.2.Les transactions indispensables

SE80 : Navigateur OBJECTSE24 : Gestionnaire de classeSE18 : Gestionnaire de BadisSE19 : Gestionnaire d’implémentationSE83 : Exemples de programmes utilisant l’ABAP OBJECTDWDM : Exemples d’applications SAP ENJOYSWO1 : Gestionnaire des objets de gestion


1sap.technique.free.fr/doc/abap object v2.doc · web viewl’abap object est une notion apparue...

Documents