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.