User et Screen Exits

On SAP Help.

• Lorsqu'un nouvel user-exit est implémenté, il faut :
  • L'activer dans cmod ou smod.
  • Relancer le programme (sortir - rerentrer)
  • Il peut être également nécessaire de se délogger puis de se relogger.
• Un message d'erreur peut cacher un user-exit. En utilisant OCHS, on peut changer le type d'un message (par ex., le passer à E). Pour déterminer si c'est utile, rechercher le nom du message et le composant utilisé ou le user-exit concerné (ex. : LB031 BAPI_GOODSMVT_CREATE / MBCFC010 remonte la note 526850).
• Pour déterminer si on passe dans un user-exit sans l'implémenter, il suffit de se rendre sur l'extension (SMOD, passer sur le composant désiré, remonter sur le module fonction EXIT_SAP*, faire un cas d'emploi dessus et placer des points d'arrêts sur chaque appel).
• Le sous-écran s'exécute dans un programme différent du programme standard et les données transférées sont souvent trop limitées. Pour récupérer une variable globale du programme standard, passer par un field symbol.

En principe si le transport s'est bien passé, l'activation est automatique. Quelques points à vérifier en cas de non-activation.

comment_implementer_un_user-exit_rf.odt

Si l'on souhaite positionner des variable d'environnement ITS depuis un écran (par exemple pour être utilisé par du js dans la page), il est possible de le faire en employant la syntaxe suivante :

*&---------------------------------------------------------------------*
*&      Module  SET_SCREEN_FORMAT_MIN  OUTPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE set_screen_format_min OUTPUT.
 
  field-set '~argosScreenFormat' 1 '16x20MIN'.
  field-transport.
 
ENDMODULE.                 " SET_SCREEN_FORMAT_MIN  OUTPUT

D'autre part, il est possible de charger des CSS ou des scripts directement depuis le sous-écran en utilisant le modèle SUBSCREEN/BEGIN (ou END) du Service Internet utilisé par le générateur correspondant pour injecter les fichiers à l'exécution de la page :

<!-- subscreen begin -->
 
<script type="text/javascript">
// Hack to load the MIN format CSS from a (custom) subscreen.
var $ = document; // shortcut
var cssId = '16x20min';  // you could encode the css path itself to generate id..
if (!$.getElementById(cssId))
{
    var head  = $.getElementsByTagName('head')[0];
    var link  = $.createElement('link');
	link.id   = cssId;
    link.rel  = 'stylesheet';
    link.type = 'text/css';
    link.href = '`mimeURL(~service=~current_service, ~theme=~theme, ~language="", ~name="styles/all/argos_16x20min.css")`';
    link.media = 'all';
    head.appendChild(link);
}
</script>
 
<div class="MobileSubScreen">

Dans le cadre de la customisation d'écran de transaction RF, les éléments à manipuler sont :

• la table interne tap_ltap qui contient l'état de la transaction (champs de confirmation : emplacement, article, etc) pour chaque poste d'OT
• la table interne applic_tab qui contient les postes à confirmer : dans l'écran source, ceux qui vont être à revalider dans l'écran destination ; dans l'écran destination, ceux qui vont être confirmés dans le système (to_confirm)
• la table interne verification_type qui contient les conditions de validation (elle peut être remplie à l'aide du FM SET_VERIFICATION_FIELD)

ATTENTION: Comme les screen exits résident dans le groupe de fonctions XLRF (contrairement aux programmes RF contenus dans LMOB), il faut re-remplir au moins certaines variables et tables lors du premier appel de sous-écran, puis faire attention qu'au fil des appels, ces données restent globalement synchronisées avec les données du programme standard !

En cas d'ajout/suppression d'un champs de validation (ex. : le lot), tout le workflow des écrans est à adapter :

• Unordered List Item