Injecteurs de jobs

Je propose dans cet article deux outils ABAP permettant d’injecter des jobs dans SAP à partir de fichiers Excel.

Injecteur simple

Télécharger le programme ZTREXPI100

Fichier d’entrée : texte avec séparateurs tabulations

Zone Longueur Description
 JOB  32  Nom du job
 USER  12  User de soumission
 TYPE  1  P(Programme) ou S(Script)
 PROG  100  Programme ou Script
 PARAM  100  Variante ou paramètre

Des contrôles sont effectués par le programme avant de créer les jobs au statut Planifié.

Programme ZTREXPI100
injecteurs_jobs-1


Injecteur et planificateur

ZTREXPI200

Ce programme est plus évolué que le premier puisqu’il permet d’injecter et de libérer les jobs selon des critères d’ordonnancement spécifiés dans un fichier texte.

– Fichier contenant les définitions des jobs :

Zone Longueur Description
 JOB  32  Nom du job
 USER  12  User de soumission
 TYPE  1  P(Programme) ou S(Script)
 PROG  100  Programme ou Script
 PARAM  100  Variante ou paramètre

– Fichier contenant les critères de planification :

Zone Longueur Description
 JOB  32  Nom du job
 TARGETSYSTEM  40  Serveur d’exécution (cf SM51)
 TYPE  2  Type de planification : DH (Date/Heure) ou EV (sur évènement)
 SDLSTRTDT  8  Date d’exécution (AAAAMMJJ)
 SDLSTRTTM  6  Heure d’exécution (HHMNSS)
 PRDMONTHS  2  Périodicité en mois
 PRDWEEKS  2  Périodicité en semaines
 PRDDAYS  3  Périodicité en jours
 PRDHOURS  2  Périodicité en heures
 PRDMINS  2  Périodicité en minutes
 CALENDAR_ID  2  Calendrier d’entreprise
 BTC_PROCESS_ALWAYS  1  Exécuter Dimanche et jours fériés (blanc ou X)
 BTC_DONT_PROCESS_ON_HOLIDAY  1  Ne pas exécuter Dimanche et jours fériés (blanc ou X)
 BTC_PROCESS_BEFORE_HOLIDAY  1  Avancer au jour ouvré précedent (blanc ou X)
 BTC_PROCESS_AFTER_HOLIDAY  1  Reporter au jour ouvré suivant
 EVENT_ID  32  Evènement déclencheur
 EVENT_PARAM  64  Paramètre de l’évènement
 EVENT_PERIODIC  Périodique sur évènement

Des fichiers Excel pour la mise en forme des données sont disponibles
ici

Programme ZTREXPI200
injecteurs_jobs-2

Envoyer un POPUP aux utilisateurs connectés

Le programme ZTREXPA800 permet d’envoyer un message sous forme de POPUP Windows à tous ou partie des utilisateurs connectés au système SAP.

Le POPUP apparaît à l’écran même si l’utilisateur n’est pas sur une fenêtre SAP.

Le programme offre la possibilité de sélectionner les utilisateur par identifiant ou par serveur de connexion.

Seuls les utilisateurs de type dialogue peuvent recevoir le message.

Optimisation des flux ALE

Introduction

Les performances des échanges ALE peuvent être optimisées dans les différentes étapes du processus ALE :

A : Création des IDocs dans le système émetteur
B : Transfert des IDocs à la couche de communication
C : Communication entre le système émetteur et le système récepteur
D : Intégration des IDocs dans le système récepteur

Pour chaque étapes, l’optimisation peut porter sur :

Le contrôle des événements déclencheurs
Le traitement en parallèle des IDocs
Le regroupement des IDocs en paquets
L’administration de la communication entre système émetteur et récepteur

Créer et transférer les IDocs à la couche de communication en deux étapes séparées améliore les performance globales du processus ALE.

Création des IDocs dans le système émetteur

Privilégier le mode de création avec pointeurs de modification en arrière plan.

Cette étape peut être exécutée en parallèle par plusieurs processus dialogue uniquement dans le cas où les IDocs sont créés en mode message par plusieurs utilisateurs ou dans le cas d’un envoi en masse (par une BD10 par exemple).

Dans le cas d’une création à partir des pointeurs de modification, le programme RBDMIDOC ne prend qu’un seul processus batch.

Il n’y a pas de réel avantage à créer les IDocs en parallèle en mode transactionnel, au contraire cela peut même se révéler dangereux dans la mesure où tous les processus dialogue peuvent être monopolisés.

Avant de créer des IDocs en transactionnel et en mode parallèle, il est conseillé de définir un groupe de serveurs (RZ12).

Le groupe de serveur définit la liste de serveurs d’application dont les processus dialogue peuvent être utilisés pour la création d’IDocs.

Deux processus dialogue restent inutilisés sur chaque serveur d’application dans le groupe de serveur pour éviter la saturation.

Pour créer les IDocs sur un serveur précis, le groupe de serveurs ne doit contenir qu’une seule entrée correspondant au serveur en question.

Transfert des IDocs à la couche ALE du système émetteur

Privilégier le transfert en mode collecté par batch (RSEOUT00).

Plusieurs jobs du RSEOUT00 peuvent être planifiés pour plusieurs destinataires ou types de message afin de transférer les IDocs en parallèle à la couche de communication.

En mode collecté, le RSEOUT00 regroupe les IDocs d’un même partenaire en paquets dont la taille est paramétrée dans les accord d’interchange.

L’écran de sélection du RSEOUT00 permet également de renseigner le nombre d’IDocs à transférer avant le COMMIT WORK soit exécuté et les IDocs débloquées (Attention à ne pas mettre une valeur trop grande pour ne saturer la mémoire et/ou la table de blocage).

SAP recommande entre 10 et 2500 IDocs par paquet selon le nombre de segments dans l’IDoc.

Pour les IDocs volumineux (exemple GLROLL or ALEAUD), le paquet doit contenir entre 1 et 10 IDocs.

Si les IDocs sont intégrés en mode collecté dans le système récepteur, un paquet d’IDocs peut contenir jusqu’à 10 000 enregistrements de données.

Par exemple, pour un IDoc contenant 10 enregistrements, le paquet peur contenir jusqu’à 1000 IDocs.

ATTENTION : Le transfert des IDocs à la couche de communication utilise TOUS les processus dialogue disponibles sur le serveur d’application indépendamment du mode de transfert (immédiat ou regroupé).

S’assurer que le système récepteur dispose d’un nombre suffisant de processus dialogue : le nombre de processus doit être supérieur ou égal au nombre de processus du système émetteur.

Chaque processus dialogue du système émetteur établie une connexion RFCt avec le système récepteur.

Intégration des IDocs dans le système récepteur

Privilégier l’intégration en mode collecté par batch (RBDAPP01)

Mode immédiat :

Attention si les paquets d’IDocs sont intégrés en immédiat dans le système récepteur, TOUS les processus dialogue du serveur récepteur sont utilisés.

Le mode immédiat peut bloquer le serveur récepteur. Les paquets d’IDocs ne peuvent être distribués à travers un groupe de serveur.

Si le paquet comporte plusieurs IDocs et si le module fonction d’intégration ne supporte pas la mise en jour en masse, la couche ALE appelle le module fonction de façon séquentielle dans le même processus pour chaque IDoc du paquet.

Lorsque la table TEDEF est renseignée, (entrée TRFC-IDOC, BATCHJOB), le système utilise les processus batch pour intégrer les IDocs si les dialogue sont saturées en planifiant des jobs avec le programme RBDAPP01 pour chaque IDocs. ATTENTION : ceci peut également saturer les processus batch. (Note 555229)

Mode collecté :

Un serveur d’application appartenant à un groupe de serveur peut être utilisé lors de l’intégration des IDocs en mode batch.

Si aucun groupe de serveurs n’est spécifié, TOUS les processus dialogue du serveur local sont utilisés en parallèle. Ceci peut bloquer le serveur.

Si le groupe de serveur est utilisé, 2 processus dialogue resteront inutilisés

Le RBDAPP01 est capable d’appeler le module fonction d’intégration en masse pour un paquet d’IDocs (si le module fonction supporte le mode de mise à jour collecté)

Traitement en paquets :

Le traitement en paquet réduit le nombre de processus dialogue utilisés et améliore les performance du système

Les paquets peuvent être utilisés lors de la création, du transfert et de l’intégration des IDocs.

Création :

Cf § Création des IDocs dans le système émetteur

Transfert :

Plusieurs IDocs peuvent être regroupés dans un même paquet pour être envoyés dans un même appel RFCt.

Ce procédé comporte plusieurs avantages :

Réduction des taches d’administration liés aux performances de l’ALE
RFCt utilise moins de processus dialogue sur le système émetteur
RFCt utilise moins de processus dialogue sur le système récepteur

Intégration :

Deux types de module fonctions sont utilisés pour intégrer les IDocs :

Modules supportant la mise à jour collectée qui intègrent le paquet d’IDocs dans la même LUW
Modules traitant un seul IDoc par appel

Si les IDocs sont intégrés en immédiat, le système émetteur détermine la taille du paquet. En entrée du système récepteur, la couche ALE détermine si le module fonction d’intégration supporte ou non le mode collecté. S’il le supporte, le paquet est transmis tel quel sinon il est divisé en IDocs individuels.

L’intégration en mode collecté réduit la charge DB.

Pour le RBDAPP01, SAP recommande d’utiliser des paquets de 20 à 100 IDocs.

Source : BC619- ALE Technology

Exemples de graphiques SAP

Programme principal : GRDEMO_D
GRBUSG_1 Graph. de présentation, 2D
GRBUSG_2 Graph. de présentation, 3D
GRBUSG_3 Graph. de présentation, matrice 2, 3, 4D
GRBUSG_4 Graph. de présentation, ttes options
GRSTAT_1 Graphique de stat., fonctions trigonométriques
GRSTAT_2 Graphique de stat., repésentation fonctions
GRHIER_1 Graphique en arbre avec menu et dialogue
GRHIER_2 Graphique en arbre avec différents dialogues
GRBMAT_1 Graph.boutons cde av. graph. de présentat
GRBMAT_2 Graph.boutons cde avec menu et dialogue
GRGANT_2 Diagramme de GANTT, planif. interactive
GRHPGL_1 Affichage HPGL
GRPORT_0 Diagramme portfolio

EnjoySAP Demo Center

L’environnement Enjoy Demo Center (Transaction DWDM) vous propose de nombreux programmes et transactions de démonstration, écrits en ABAP et basés sur des techniques de contrôles utilisées depuis la version 4.6.

De nombreuses interfaces utilisateur ont été reconçues pour la version EnjoySAP, notamment l’atelier de développement ABAP Workbench lui-même. Les exemples de démonstration vous montrent comment partager un écran à l’aide des « docking controls » et « splitter controls », comment utiliser les « tree controls » dans les représentations sous forme d’arbre, et ainsi de suite.

En sélectionnant une ligne quelconque de la hiérarchie proposée, vous lancez directement la démonstration. Vous obtenez l’affichage du code source en double cliquant sur les noms des programmes correspondants. Pour demander la documentation relative aux démonstrations, cliquez sur le bouton de commande « i ». Remarque : la hiérarchie de démonstration est gérée par SAP, mais ne peut pas être modifiée.

BADIs : Méthode de recherche

Avant de commencer, lisez l’article BADIs : Introduction.

Il y a différentes façons de rechercher des business add-ins.

  • Recherchez la chaîne de caractères ‘CL_EXITHANDLER’ dans le programme applicatif pertinent.
    Si vous appelez un business add-in à partir du programme, vous devez également appeler la méthode ‘GET_INSTANCE’ de cette classe.
  • Double-cliquez sur la variable de référence et relevez le nom de l’interface utilisée.
  • En utilisant le class Builder (SE24), listez les cas d’emploi de l’interface afin de retrouver la classe de définition du business add-in (CL_EX_BADI).
  • La définition du BADI contient une documentation et un guide pour la mise en oeuvre du business add-in.
  • Vous pouvez également utiliser des outils de recherche.
  • Cependant, vous pouvez aussi utiliser la hiérarchie des applicatons pour limiter la recherche à certaines composantes.
    Lancez le système d’information du Repository, puis sélectionnez Environnement -> Techniques EXIT -> Business Add-Ins pour lancer le programme de recherche pertinent.
  • Vous pouvez également utiliser les entrées pertinentes du guide d’implémentation.

badis_rech-01

BADIS : Introduction

Avant de commencer, lisez l’article ABAP Objects.

Avantages des BADIs

Les business add-ins sont une extension naturelle des techniques d’extension conventionnelles. Ils reprennent la couche d’administration des exits client, associée à la disponibilité des diverses composantes d’extension.

L’implémentation orientée-objet fournit des opportunités nouvelles. Il est par exemple possible d’effectuer une extension de l’objet ‘Document’. Il est également possible de fournir une nouvelle instance de l’extension pour chaque document individuel.

badis_intro-01

Le principal avantage de ce concept est la possibilité de réutilisation. Une fois mis en oeuvre, un business add-in peut faire l’objet d’une nouvelle implémentation.
Par ailleurs, une implémentation peut également fournir ses propres add-ins.

Composantes
badis_intro-02

Un business add-in contient toutes les composantes d’une extension. Actuellement, chaque business add-in peut contenir les éléments suivants :

  • Extensions de programme
  • Extensions de menu

Dans les futures versions, les autres composantes comprises dans les exits client sont également disponibles comme composantes add-ins.

Lorsque vous définissez un business add-in, vous pouvez créer plusieurs composantes :

  • Interface
  • Classe générée (adaptateur add-in)

La classe générée effectue les tâches suivantes :

  • Filtrage : lorsque vous mettez en oeuvre un business add-in dépendant d’un filtre, la classe d’adaptation vous garantit que seules les implémentations pertinentes sont appelées
  • Contrôle : la classe d’adaptation appelle les implémentations actives.

Processus
badis_intro-03

Ce graphique illustre le processus suivi par un programme contenant un appel de business add-in. Non affiché : vous devez déclarer une variable de référence à l’endroit approprié.

Dans la première étape, une classe de service existante, CL_EXITHANDLER, crée une référence d’objet. La syntaxe utilisée est étudiée plus loin. Une fois cette étape effectuée, l’extension de programme peut être utilisée.

Lorsque vous définissez un business add-in, le système crée une classe d’adaptation qui met en oeuvre l’interface. Lors de l’appel (2), la méthode d’interface de la classe d’adaptation est appelée. Cette classe recherche toutes les implémentations des business add-ins et appelle les méthodes mises en oeuvre.

badis_intro-04

Ce graphique montre la syntaxe que vous utilisez pour appeler un business add-in. Les numéros encerclés correspondent aux appels de la page précédente.

Vous devez tout d’abord définir une variable de référence en référence à l’interface du business add-in. Le nom de la variable de référence ne contient pas nécessairement le nom du business add-in.

Lors de la première étape (1), une référence d’objet est créée. Ceci crée une instance de la classe d’adaptation générée, limitée aux méthodes des interfaces (distribution étroite).

Vous pouvez utiliser cette référence d’objet pour appeler les méthodes requises (2).

Définition d’un business add-in
badis_intro-05

Pour créer un BADI, utilisez le BAdI Builder (Outils -> ABAP Workbench -> Utilitaires -> Business add-ins -> Définition) (Transaction SE18).

Attributs
badis_intro-06

Vous devez définir deux attributs importants pour les business add-ins :

  • Réutilisable
  • Dépendant du filtre

Si vous souhaitez que le business add-in prenne en charge plusieurs implémentations parallèles, sélectionnez Réutilisable. La séquence de traitement des implémentations n’est pas définie. Même si le business add-in ne prend pas en charge plusieurs utilisations, vous pouvez toujours lui affecter plusieurs implémentations.

Si vous définissez l’attribut dépendant du filtre pour un business add-in, vous faites dépendre les appels vers ce business add-in de certaines conditions. Vous devez spécifier le type de filtre sous forme d’un élément de données. La table des valeurs du domaine utilisé par l’élément de données contient les valeurs valides pour l’implémentation.

Lorsque la méthode d’extension est appelée, une valeur de filtre doit être transmise à l’interface.

Méthodes d’interface
badis_intro-08

Le système propose un nom pour l’interface et la classe générée. Vous pouvez, en principe, modifier le nom de l’interface comme vous l’entendez. Cependant, votre business add-in sera plus facile à gérer si vous retenez le nom proposé.

Le nom de la classe générée est construit de la façon suivante :

Préfixe de l’espace nom Z ou Y
CL_ (pour indiquer une classe en général)
EX_ (pour ‘exit’)
Nom du business add-in

Si vous double-cliquez sur le nom de l’interface, le système passe au Class Builder (SE24), dans lequel vous pouvez définir des méthodes d’interface.
Une interface BADI peut avoir plusieurs méthodes d’interface.

badis_intro-08

Vous pouvez utiliser toutes les fonctions standard du Class Builder. Vous pouvez par exemple :

  • définir des méthodes d’interface
  • définir des paramètres d’interface pour les méthodes
  • déclarer les attributs de l’interface

Si le business add-in est dépendant du filtre, vous devez définir un paramètre d’import FLT_VAL pour chaque méthode. Sinon, vous définissez les paramètres d’interface dont vous avez besoin pour l’extension.

Activation de l’interface
badis_intro-09

Lorsque vous avez terminé de travailler sur votre interface, vous devez l’activer. Vous générez ainsi la classe d’adaptation du business add-in. Cette classe est automatiquement régénérée à chaque modification de l’interface.

Vous pouvez également générer explicitement la classe d’adaptation à tout moment, en sélectionnant Utilitaires -> Régénérer dans l’écran initial de la transaction de gestion du business add-in.

Programme d’appel
badis_intro-10

Pour appeler une méthode de business add-in dans un programme applicatif, vous devez inclure trois instructions dans le programme :

  1. Déclarez une variable de référence en référence à l’interface du business add-in (dans notre exemple, exit_ref).
  2. Appelez la méthode statique GET_INSTANCE de la classe de service CL_EXITHANDLER. Le système vous renvoie une instance de l’objet requis. Ceci implique une distribution étroite implicite, de façon à ce que seules les méthodes d’interface de l’objet ayant la variable de référence exit_ref soient accessibles.
  3. Vous pouvez maintenant appeler toutes les méthodes du business add-in. Assurez-vous de spécifier correctement les paramètres des méthodes. Si le business add-in est dépendant d’un filtre, vous devez transmettre une valeur appropriée pour le paramètre FLT_VAL. Si le business add-in possède plusieurs implémentations actives, ces dernières seront appelées dans l’ordre alphabétique.

Implémentation d’un business add-in

Convention d’appellation

BADI : ‘BADI’
Interface : IF_EX_’BADI’
Méthodes : Choix libre
Classe générée du BADI (non modifiable) : CL_EX_’BADI’
Nom d’implémentation : Z’libre’
Classe d’implémentation : ZCL_IM_’libre’

Implémentation : écran initial
badis_intro-11

Pour l’implémentation de business add-ins, utilisez la transaction SE19 (Outils -> ABAP Workbench -> Utilitaires -> Business Add-Ins -> Implémentation).

Entrez le nom de l’implémentation et sélectionnez Créer. Une boîte de dialogue s’affiche. Entrez le nom du business add-in. L’écran de gestion correspondant s’affiche.

Vous pouvez également utiliser la transaction de définition de business add-ins pour accéder à ses implémentations. Le menu contient une entrée Implémentation, que vous pouvez utiliser pour avoir une vue d’ensemble des implémentations existantes. Vous pouvez également créer de nouvelles implémentations à ce niveau.

Méthodes
badis_intro-12

Vous pouvez affecter le nom de votre choix à la classe d’implémentation. Cependant, il est conseillé de respecter la convention d’appellation proposée. Le nom proposé est construit de la façon suivante :

Préfixe de l’espace nom, Y ou Z
CL_ (pour classe)
IM_ (pour implémentation)
Nom de l’implémentation

Pour mettre en oeuvre la méthode, double-cliquez sur son nom. Le système lance alors l’éditeur Class Builder.
Lorsque vous avez terminé, vous devez activer vos objets.

Méthodes privées
badis_intro-13

La classe d’implémentation vous permet de créer vos propres méthodes, que vous appelez à partir de la méthode de l’interface.

Activation
badis_intro-14

Utilisez l’icône Activer pour activer l’implémentation d’un business add-in. Désormais, les méthodes de l’implémentation seront exécutées en même temps que le programme appelant.

Si vous désactivez l’implémentation, les méthodes ne seront plus appelées. Toutefois, les appels correspondants dans le programme applicatif sont toujours traités. La différence réside dans le fait que l’instance de la classe d’adaptation ne trouvera plus d’implémentations actives. Contrairement à l’appel CALL CUSTOMER-FUNCTION, l’appel CALL METHOD CL_EXITHANDLER=>GET_INSTANCE est toujours exécuté même s’il n’y a plus d’implémentations.

Ce principe est également valable pour l’instruction appelant la méthode de la classe d’adaptation.
Vous pouvez uniquement activer ou désactiver une implémentation dans son système d’origine. Tout changement autre que dans le système d’origine constitue une modification. L’activation ou la désactivation doit être transmise aux systèmes ultérieurs.

Un business add-in ne peut avoir qu’une seule définition, mais plusieurs implémentations peuvent exister dans le même système.