J’ai eu à modifier un texte dans un SAPscript. C’était la première fois que je le faisais depuis au moins moult années, voire depuis jamais, et donc, ce ne fut pas si simple que cela, merci SAP.

Préambule

Je passe la partie où j’ai ramé pour réussir à souligner un texte mais uniquement jusqu’à une virgule (celle-ci devant, évidemment, être exclue du soulignement), sans pouvoir utiliser le nouvel éditeur – comprendre : une intégration un peu instable de Word – et le tout en étant pile à la fin de la ligne de l’ancien éditeur de texte.
Bref, après toutes ces péripéties, je sauvegarde mon joli formulaire, ce qui me demande de créer un ordre de transport ; je m’exécute.

Un formulaire SAPscript, c’est intermandant ?

Changement de mandant pour tester la modification… et rien ne se passe. C’est-à-dire que je ne vois pas ladite modification dans le texte du formulaire.
J’ai beau ne pas être très familier des SAPscripts, je commence à connaitre SAP – *tousse* seize ans ! *tousse* – et d’instinct je me dis que le SAPscript ne doit pas être intermandant. Qu’à cela ne tienne, je file dans la transaction SCC1 pour importer les modifications depuis le mandant de développement vers celui de test.
Je relance mon test… et tout est OK.

Rien n’est jamais simple avec SAP

L’histoire aurait pu s’arrêter là : passage en Qualité de l’ordre de transport, le Client valide, et on passe en Production. Sauf qu’avec SAP, rien n’est jamais simple.
Donc, libération de l’ordre, OK. Mais ce fut bien la seule chose OK à ce moment là. En effet, la modification du formulaire n’est pas visible en Qualité… et ne l’est plus non plus sur le mandant de test de l’environnement de développement !

Je me renseigne auprès d’un collègue développeur censé mieux s’y connaitre que moi en SAPscript : j’ai sûrement raté une manipulation à faire avant la libération. Mais non, selon lui, rien de spécial à faire.
Je me renseigne auprès d’un collègue basis qui pourrait avoir accès à des logs d’erreur inconnus de moi. Mais non, selon lui, il n’y a pas eu d’erreur.
Conclusion : on teste en refaisant un ordre de transport identique au précédent, en croisant les doigts cette fois – oui ça parait bizarre comme technique, mais j’ai déjà eu des cas où un OT ne passait pas correctement une première fois, mais bien la seconde…

Et là, c’est le drame : à OT identique, comportement identique.

Je continue à creuser, et je finis par tomber sur la liste des versions du formulaire. Je vois que sur le mandant de développement il y a deux versions : une active et une modifiée…
Trève de blabla, à partir de là le lecteur aura compris (et le lecteur avisé avait déjà compris rien qu’à la lecture du titre de cet article…) : il fallait activer le SAPscript pour que la version que j’avais modifiée devienne… active !

Rien n’est jamais simple avec SAP – bis

J’ai eu beau regarder tous les menus directement accessibles depuis la transaction SE71, impossible de trouver comment activer le formulaire.
Heureusement, Google fut mon ami, ainsi qu’un vieux post sur SCN. Il suffisait de taper ==ACTV dans la zone OKCODE pour activer le formulaire SAPscript (+ création si besoin d’un ordre de transport).
Et chose étonnante, une fois ceci fait, non seulement le formulaire était actif mais une nouvelle entrée de menu a fait son apparition pour activer ledit formulaire (je suis sûr à 100% qu’elle n’y était pas avant…).

Merci SAP !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.