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.

Lancement de la 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.

RSA1 est bloquée

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

Si vous avez un message type X lors de l'ouverture d'un infopackage, il est probable que la gestion du delta soit en cause. Dans le log du dump vous pouvez trouver ces critères :
MESSAGE_TYPE_X, SAPLRSS1, LRSS1F11, RSM1_CHECK_FOR_DELTAUPD, RSAWBN_START.

Dès lors, impossible de rentrer dans l'infopackage pour corriger. La création d'un nouvel infopackage ne résoud rien car il dump immédiatement.

La solution est tout simple, il suffit de lancer le programme RSSM_OLTP_INIT_DELTA_UPDATE pour reparer le delta en cours (en cochant ALWAYS).
Si jamais cela ne fonctionne pas, il faut essayer de lancer directement la fonction : RSC1_QUEUE_DELETE_ALL.

Si cela resiste encore... supprimer les entrées d'inits résiduts dans les tables suivantes:

• ROOSPRMSC
• ROOSPRMSF

La référence de la demande de mise à jour à supprimer est indiqué dans le dump (L_T_RSSDLINIT_OLTPDEL-RNR ou L_REQ_TO_KILL suivant la version de BW).

Dans toutes les tables relatives aux chargements (listées dans un billet à venir), vous trouverez un ID unique sur 29 caractères de la forme REQU_xxxx. Mais en affichage dans BW, il est souvent fait référence à un numéro court (nombre incrémenté de 1 pour chaque nouveau chargement).

Request ID affiché dans la gestion d’infoprovider

Request Number affiché dans le monitor

Lors d’une erreur à l’activation, BW indique généralement l’ID de requête erroné.

Passer facilement de l’un à l’autre est enfantin… une fois que l’on connait la signification de ces 2 objets : Le request ID est en fait le SID du Request number (parfois appelé lui même request ID, suivant les écrans...) Il suffit donc d’aller lire la table /BI0/SREQUID pour obtenir l’un à partir de l’autre.

Correspondance entre ID et Number via SE16

Il arrive que malgré tous vos efforts, BW ne vous laisse pas modifier une entrée de PSA lors d’un chargement en erreur. Tout est pourtant bon au niveau des autorisations… Mais qu’en est-il du statut de chargement ?

- Il est rouge ! Me rétorquerez-vous probablement énervé par cette question, semble-t-il, idiote.

Sauf que le feu tricolore n’est qu’un résumé simpliste des différents statuts possibles d’un chargement. Pour BW il existe 25 statuts différents, et certains d’entre eux ne permettent pas de modification de la table PSA. Ce statut est stocké dans le champ AUFRUFER de la table RSMONICDP.

Voici la liste des statuts en question :

Si jamais vous êtes dans une situation semblable et que bidouiller la couleur du feu n'y change rien, vous avez juste à modifier le contenu de RSMONICDP (en y mettant le statut 66 par exemple). Comme par magie, la maintenance de PSA redevient possible. N'oubliez pas de remettre les statuts d'origine après modification de la PSA.

Une solution moins brutale consiste a supprimer des cibles toutes les demandes qui sont dans un des statuts bloquants. La PSA redeviendra modifiable, et ensuite vous pourrez "pousser" les données vers les cibles non mises à jour.

Lassé de créer un écran ne contenant qu'un custom control, avec PBO et PAI rachitiques uniquement pour afficher votre grid ALV objet ? La classe cl_gui_container contient nativement des attributs qui permettent de s'en passer ! Encore faut-il le savoir, ce qui est maintenant votre cas ;-)
En effet, au lieu de créer tout d'abord un objet container puis d'indiquer cet objet en parent de l'objet alv, utilisez directement cl_gui_container=>screen0 comme parent pour votre ALV !

PROGRAM test.
DATA : o_alv      TYPE REF TO cl_gui_alv_grid,
       t_sflight  TYPE TABLE OF sflight.

* Definition d'un écran de sélection vide
SELECTION-SCREEN : BEGIN OF SCREEN 1001,
                   END OF SCREEN 1001.

* Remplissage de la table de données pour l'ALV
SELECT * FROM sflight INTO TABLE t_sflight.

* Creation de l'objet alv directement rattaché au premier screen
CREATE OBJECT o_alv
  EXPORTING
    i_parent = cl_gui_container=>screen0.

* Passage des données a l'ALV
CALL METHOD o_alv->set_table_for_first_display
  EXPORTING
    i_structure_name = 'SFLIGHT'
  CHANGING
    it_outtab        = t_sflight.

* Affichage de l'écran, l'ALV apparait !
CALL SELECTION-SCREEN 1001.

Cette astuce améliore au passage la portabilité de votre code (pas de screen/status/title à gérer).