Quelquepart

Blog d'un consultant SAP

Vous êtes ici : Accueil

Empêcher le lancement de RSA1 sur ECC

Rédigé par Sébastien Hermann dans Général, Fonction - aucun commentaire

RSA1... la transaction magique pour tout consultant BW... Cette transaction est aussi très fourbe. En effet, lorsque vous la lancez, elle crée à votre insu un job nommé BI_WRITE_PROT_TO_APPLLOG, à votre nom, avec une récurrence toutes les 5 minutes !

"Ce job est utile sur BW, donc ce n'est pas un problème", me direz-vous. Oui, mais que ce passe-t-il si vous lancer par erreur RSA1 sur un système ECC ?

La même chose, malheureusement. Même si ce job a une durée généralement inférieure à 1 seconde, il consomme un peu de puissance machine et 1 work process.

Bien sûr, l'auteur de la faute a juste à aller sur SM37 pour supprimer ce job. Mais dans la mesure ou SAP ne l'avertit pas qu'il a créé ce job pour lui, il faut déjà connaître ce mécanisme (ce qui est maintenant le cas de tous mes lecteurs ;) ).

Bien sûr, il est possible de bloquer RSA1 au niveau des autorisations, il suffit de ne pas donner ce TCODE. Mais il peut être compliqué de mettre cela en place, en fonction de la complexité de gestion des autorisations de votre entreprise.

Heureusement, il existe une autre solution, simple et rapide à mettre en place !

Lors du lancement de RSA1, SAP vérifie si le mandant en cours est conforme à celui défini pour l'exécution de BW. Pour bloquer RSA1 sur un système ECC, il suffit donc de définir un mandant "BW" non utilisé !

Comment faire ? Cette information est stockée dans la table RSADMINA, dans le champ BWMANDT. Les 2 vues de gestion permettant de modifier RSADMINA (RSADMINAV et RSADMINAV2) ne donne pas accès à cette zone, de même qu'aucune des transactions RSCUSTxx. Non, non, non, inutile de sortir votre mode debug sur SE16, il existe un module fonction : RSCC_RSADM_ACC.

En exécutant ce module fonction, vous pouvez mettre à jour le champ BWMANDT de la table RSADMINA pour le faire pointer vers un mandant qui n'existe pas sur ECC afin d'y empêcher l'exécution de RSA1.

Ce fonctionnement est décrit dans la note OSS 1949194.

Developer Heroes

Rédigé par Sébastien Hermann dans Général - 5 commentaires

Cela m'est tombé dessus sans que je m'en rende compte. Cette année j'ai été nommé "developer heroes" par la communauté SAP.

Cela commence par un fan qui propose mon nom à SAP. Grâce au système d'alerte de SAP, je suis immédiatement informé. Cela me permet de découvrir cette événement dont je n'avais jamais entendu parler. Pourtant ce n'est pas sa première année. Bref, j'en parle un peu autour de moi, personne ne connait.

Ensuite, durant le mois de vote, d'autres fans "plussoient" ma "candidature" involontaire. Bon j'avoue que quelques amis à qui j'avais parlé de cette aventure ont également participé.

Après, c'est SAP qui délibère pendant un bon mois, et voilà, c'est bouclé, je suis un des héros SAP de l'année.

Alors, la grande question, à quoi cela sert-il ? Ai-je une dotation comme pour les prix Nobel ? Une invitation sur le Tech Ed où sera fait l'annonce ? Peut-être même une tribune pour m'y exprimer publiquement ?

Rien de tout cela. Je me contenterai donc de ma photo faisant le tour du monde ainsi que de la reconnaissance éternelle de mon bien-aimé SAP. Et ça, ça n'a pas de prix !

Mots clés : aucun

Astuce BW : Query sur Info Provider

Rédigé par Sébastien Hermann dans Général - aucun commentaire

Vous avez surement déjà été agacé par le LISTCUBE et ses nombreuses limitations, nous en avons déjà discuté lors de la présentation de ma solution ZLISTCUBE, souvenez-vous. Aujourd'hui, je viens partager une petite astuce de vieux grognard que je ne connaissais pas.

Vous connaissez surement la transaction RSRT, qui permet de tester/debugger les "requêtes Bex" dans BW. Eh bien cette transaction permet également de visualiser le contenu d'un cube ou de n'importe quel Info Provider comme si une requête Bex avait été créé dessus !

Pour faire cela, il faudra suivre scrupuleusement une syntaxe bien particulière (qui se rapproche plus d'un code de piratage de la NSA que d'une inocente query bex). En nom de requête donc, vous tapez : PROVIDER/!PROVIDER (en remplaçant PROVIDER par le nom technique de votre infoprovider) et c'est tout.

En validant l'écran avec la touche entrée, vous aurez alors le message suivant qui apparait en bas de l'écran :

Vous pouvez désormais exécuter votre "query". Enjoy !

Mise à jour d'automne

Rédigé par Sébastien Hermann dans Mise à jour -

Le temps passe, et les différentes demandes de mes clients m'ont conduit à modifier certains des programmes publiés ici. Comme d'habitude, je vous livre donc une mise à jour de ces évolutions.

La principale mise à jour concerne ZAUTODOC, le générateur de doc technique BW, qui passe de la version 3.1 à la version 3.4 et accueille de nouveaux objets, dont les queries BEx !

  • Les queries BEx et les WAD sont maintenant documentées (très légèrement pour les WAD)
  • Les process chain, les Open Hub, les infosets BW et les includes abap (dans les routines) sont maintenant documentés
  • Si un objet BW (DSO, cube...) contient une documentation dans le système, le programme essaie de la récupérer pour l'inclure dans la documentation générée. Ainsi il devient possible d'ajouter de l'intelligence dans cette documentation automatique en uploadant sur l'objet principal d'un flux votre propre documentation.
  • Extraction du code des user-exit ECC si un include/form par datasource existe
  • Ajout d'un paragraphe à la fin du document qui indique comment regénérer cette documentation
  • Gestion des groupes de règles dans les transformations
  • Nombreuses autres modifications mineures

A noter : la version 1.4 de la classe CL_WORD est nécessaire. Elle est incluse dans le package.

En cas de mise à jour depuis une précédente version, pensez à bien récupérer votre personnalisation (variable cs_custo au début du code)

On continue avec ZTOAD - Requêteur Open SQL qui passe de la version 3.0 à la version 4.0 :

  • Gestion d'onglets : vos requêtes et leurs résultats peuvent être gardées en mémoire dans des onglets séparés. Passez ainsi de l'une a l'autre en 1 clic.
  • Import/export des requêtes sauvegardées
  • Gestion du "case" dans la nouvelle syntaxe abap sql

ZSPRO, la boite à outils passe de la version 2.3 à la version 2.5.1 :

  • Gestion de styles sur l'affichage de la documentation ABAP
  • Affichage d'une image de fond dans la partie droite (le logo du programme) pour permettre une plus forte identification de l'application
  • Divers corrections et ajouts mineurs

ZRSPC, le mini ordonanceur passe de la version 1.7.1 à la version 1.10 :

  • CHANGE_DTP_SEL permet de modifier les critères de sélection d'un DTP
  • TRIG_IP, TRIG_DTP et TRIG_CHAIN ont maintenant la possibilité de ne pas lancer plus de X chaines en parallèle
  • Affichage de la documentation du programme sur l'écran de sélection
  • Le mode test affiche désormais l'ALV d'exécution s'il n'y a pas d'erreur (ce qui permt d'interragir avec les différents objets)
  • Diverses corrections mineures

ZAL11, l'explorateur de fichiers subit une mise à jour mineur pour corriger un DUMP potentiel.

Voir le contenu d'un fichier SAPLINK

Rédigé par Sébastien Hermann dans Général - aucun commentaire

Vous avez rêvé de pouvoir vérifier le contenu des programmes mis à disposition sur le site sans avoir à les télécharger/installer. Oui je le sais, un de vous m'a même demandé de fournir un fichier texte contenant le code.

Grâce à Sandra Rossi, le rêve devient réalité ! Dorénavant, vous aurez la possibilité, sur chaque page proposant un programme, de voir le contenu du nugget (le fichier .nugg pour saplink). Le code abap donc, mais pas que ! Textes, définition de table, dynpro, rien ne manque. Ansi, si le cœur vous en dit, vous pouvez même recréer "à la main" un programme, sans passer par saplink.

Un exemple : code source de la classe d'abstraction docx

Merci à Sandra pour l'idée originale et sa transformation xslt, je n'ai fait que recoder le tout en php et mettre un coup de peinture.