Abap OO : collection – utilisation des Maps

En tant qu’abapeurs avisés vous connaissez très probablement les collections avec la classe CL_OBJECT_COLLECTION mais connaissez-vous les maps ? Il s’agit en fait d’un type particulier de collection qui contrairement à la classe CL_OBJECT_COLLECTION vous permettra d’accéder à un élément particulier via sa clé au sein de la map. Vous pourrez ainsi créer vos propres classes collections reprenant le principe de la map en héritant de la classe CL_OBJECT_MAP.

Si vous souhaitez en savoir un peu plus, c’est par là que ça se passe : http://scn.sap.com/community/abap/application-development/objects/blog/2012/01/04/abap-objects-rumble-in-the-jungle–internal-table-against-collection

Publicités

Créer une aide à la recherche RFC

Dans certains cas, on peut être amené à vouloir utiliser une aide à la recherche (SE11) en RFC de façon à pouvoir récupérer les résultats de la recherche depuis un système distant.

Cette fonctionnalité s’avère particulièrement utile pour une utilisation dans le cadre d’une application Web Dynpro. En effet, les best-practices Web Dynpro imposent une interaction (sélection/mise à jour) par le biais d’une connexion distante (RFC), et cela y compris pour les aides à la recherche.

Pour ce faire, on pourra proposer l’utilisation d’un OVS (Object Value Selector) qui lui permet aisément d’exploiter une destination RFC puisque l’on peut librement y coder la sélection de données (par l’intermédiaire d’une bapi appelée en RFC). Cela peut être considéré comme une solution envisageable mais peut aussi faire perdre un temps considérable (en plus d’être redondant) lorsque l’on a déjà à disposition une aide à la recherche que l’on pourrait utiliser.

Prenons par exemple le cas d’une aide à la recherche sur les articles telle que la MAT0M.

Si l’on souhaite l’utiliser dans une application Web Dynpro, nous procéderons de la sorte :

Le matchcode est parfaitement utilisable en l’état mais cela présente l’inconvénient de sélectionner les données sur le même système sur lequel l’application Web Dynpro est exécutée :

Exit d’aide à la recherche « /PLMB/SPI_SHLP_F4IF_GEN_EXIT »

Pour utiliser une aide à la recherche via un appel RFC, nous allons utiliser l’exit d’aide à la recherche standard “/PLMB/SPI_SHLP_F4IF_GEN_EXIT” qui permet d’appeler une aide à la recherche sur un système distant par le biais d’une destination RFC.

Le paramètre qui nous intéresse est donc « IVI_SHLP_RFCDEST ».

Il convient donc dans un premier temps de copier ce module fonction afin d’y implémenter la logique de détermination de la destination RFC à utiliser (par le biais d’une méthode statique outil par exemple, ou autre) :

Création de l’aide à la recherche chapeau

L’exit de recherche ayant été copié et adapté, on peut maintenant procéder à la création de l’aide à la recherche chapeau, qui servira à appeler la véritable aide à la recherche à utiliser.

Pour reprendre notre exemple précédent, disons donc que l’on souhaite utiliser l’aide à la recherche MAT0M. La première étape consiste donc à copier cette aide à la recherche, cela en vue d’en récupérer :

  • Sa description
  • Ses paramètres

Nous complèterons cette aide à la recherche en :

  • Supprimant la méthode de sélection
  • Ajoutant l’exit d’aide à la recherche
  • Ajoutant le paramètre spécifiant la véritable aide à la recherche à utiliser sur le système distant

En testant l’aide à la recherche, on peut se rendre compte que les données proviennent du système distant :

Utilisation de l’aide à la recherche chapeau

L’aide à la recherche chapeau « YMAT0M2 » ayant été créée de façon à appeler en RFC l’aide à la recherche MAT0M2, nous pouvons l’implémenter à l’habitude au sein de notre composant WDA :

L’aide à la recherche est disponible au sein de l’application Web Dynpro et retourne désormais les données du système distant :

Cas particulier des aides à la recherche groupées

Certaines aides à la recherche sont un peu plus complexes puisque celles-ci se présentent sous la forme d’aides à la recherche groupées.

Prenons par exemple le cas de l’aide à la recherche « MAT1 » :

Cette aide  la recherche inclut d’autres aides à la recherche :

Ces aides à la recherche incluent elles-mêmes d’autres aides à la recherche :

On arrive sur l’aide à la recherche finale :

Il convient donc ici de procéder comme expliqué précédemment et d’effectuer les modifications adéquates en cascades de façon à utiliser notre aide à la recherche chapeau.

Cela donnerait donc pour ce cas l’enchainement suivant :

On inclut des copies des aides à la recherche incluses :

En cascade, là encore on inclut les copies des aides à la recherche incluses :

On arrive finalement à l’aide à la recherche finale :

De la même façon que vue précédemment, l’aide à la recherche est utilisable dans le composant Web Dynpro :

L’aide à la recherche groupée apparaît correctement et les sous-aides à la recherche sont librement utilisables :

Les données retournées proviennent du système distant :

Autorisations : mais où ça coince ?

Il vous est probablement déjà arrivé de vous retrouver bloqué du fait d’un problème d’autorisation :

Oui… Mais comment savoir de quoi il s’agit ?

ST01 – Trace System

Si vous pensez rencontrer un problème d’autorisation, vous pouvez alors lancer une trace système via la transaction ST01 sur tous les contrôles d’autorisations :

Il est conseillé de créer un filtre sur votre user :

Vous pouvez enfin activer la trace :

Refaites à nouveau l’action pour laquelle vous pensez rencontrer un problème d’autorisation :

Puis désactiver votre trace :

Enfin, afficher le compte-rendu de l’analyse :

Vous pourrez ainsi facilement repérer les contrôles d’autorisations pour lesquels un code retour eu erreur aura été obtenu :

Il est même possible de connaitre en détail la ligne de code ABAP ayant effectuée le contrôle :

SE16N : La fin du &SAP_EDIT ? Oui… mais pas complètement !

Vous avez besoin de faire une petite modification rapidement dans une table, vous vous rendez donc en SE16N, vous faites votre petit « &SAP_EDIT » et là… rien ne se passe ! Mais… Qu’est-ce que…  Où sont passées les fonctions d’éditions o.O ?

Et oui, il se trouve que la transaction SE16N est une fonctionnalité du composant SAP_APPL (Logistique et gestion comptable) et non du composant SAP_BASIS (Composante de base SAP). Or, depuis les Support Package 17 et 18 du composant SAP_APPL (release 600), la fonction d’édition de la SE16N a été désactivée (note OSS 1420281).

Désactivée, mais pas complètement…

Il existe une technique permettant de réactiver la fonction d’édition. Pour cela, un coup de débug s’impose :

Initialisez les variables globales « gd-sapedit » et « gd-edit » à « X » :

La toolbar d’édition est de retour 😉

Note OSS 1420281 :

Gestion des clés de blocages

Lors d’un développement spécifique il est parfois demandé de manipuler en modification des objets standards (commande, facture, article…). Pour cela, il est impératif de poser une clé de blocage sur l’objet en question afin que celui-ci soit verrouillé et qu’il ne puisse pas être modifié par un autre programme au même moment.

Les objets de blocages

Dès lors que l’on entre en modification sur un objet standard, une clé de blocage est immédiatement posée :

On peut alors observer la clé de blocage ainsi que le nom de la table concernée en transaction SM12 :

Une fois le nom de la table bloquée déterminé, il nous faut désormais trouver l’objet de blocage correspondant. Pour cela, il faut aller interroger la table DD25L « En-tête d’agrégat (vues, objets matchcode, objets blocage) » :

Maintenant que l’on connait le nom de l’objet de blocage, on peut en voir le détail en SE11 :

On peut alors connaitre les noms des modules fonctions de blocages et déblocages de l’objet :

SAP Business Workplace : notifications de l’arrivée de nouveaux messages par e-mail

Le SAP Business Workplace est un environnement de travail fournit par SAP auquel chaque utilisateur a accès via la transaction SBWP et lui permettant de gérer son activité ainsi que sa communication au sein de l’organisation via l’échange de messages internes.

S’il va sans dire que l’échange de messages internes qu’offre cet environnement représente une fonctionnalité plus qu’intéressante au sein d’une organisation, les utilisateurs n’ont pas toujours le réflexe de consulter leur boite de réception…

SO13 : Retransmission automatique des messages

La transaction SO13 permet la gestion des suppléants SAPOffice. Ainsi, il est possible via celle-ci de paramétrer une règle de retransmission automatique afin d’envoyer une notification par e-mail dès lors que l’utilisateur reçoit un message dans sa boite de réception, comme par exemple pour l’arrivée de nouveaux Workflows.

On peut alors préciser l’adresse e-mail vers laquelle la notification doit être envoyée pour une période donnée :

Ainsi, dès lors que l’utilisateur reçoit un message dans sa Business Workplace, un mail lui est également envoyé :

XXL_FULL_API : Génération de tableaux croisés

Qui dit ALV dit bien souvent téléchargement de celle-ci sous Excel. S’il est assez simple de prendre en charge l’export tableur de façon quasi-automatique, le résultat n’est pas toujours à la hauteur de ce que peut attendre un utilisateur.

La bapi « XXL_FULL_API »

La bapi « XXL_FULL_API » est une bapi standard permettant l’export de tables internes sous la forme de tableaux Excel croisés ou plus classiques, celle-ci n’est cependant pas disponible par défaut lors de la mise en place d’une ALV et il est alors nécessaire de l’implémenter.

Génération de tableaux classiques

Lors de son exécution, la bapi affiche une popup à l’utilisateur demandant le nombre de colonnes clés de la table :

On peut alors préciser le type de tableau à générer ainsi que le tableur à utiliser :

Le fichier se charge alors directement à l’écran :

Génération de tableaux croisés

Il est également possible de construire des tableaux croisés :

Tout comme pour la génération de tableaux classiques, la table croisée apparaît automatiquement à l’écran :

Programme d’exemple :

par jrobaire Posté dans Tips Tagué