GETWA_NOT_ASSIGNED en prélèvement RF EWM : l'autorisation que SU53 ne montre pas

Le correctif est minime. Le trouver a pris du temps, parce que le contrôle en échec n'apparaissait ni dans SU53 ni dans la trace d'autorisations. Cet article décrit comment nous avons lu le dump, ce qui n'a pas fonctionné, et comment nous avons trouvé la cause au débogueur.

Le symptôme

Les magasiniers confirmaient leurs tâches de prélèvement sur des terminaux portables dans /SCWM/RFUI. Pour certaines tâches, la session se terminait par un dump :

Erreur d'exécution : GETWA_NOT_ASSIGNED (field symbol non assigné)
Programme : /SCWM/SAPLL03A, include /SCWM/LL03AFGP, routine STOCK_CHANGE_CONF
Entrée SM21 : message AB0, « Runtime error GETWA_NOT_ASSIGNED occurred »

Trois éléments ont permis de cerner le problème :

Seules les tâches rattachées à une demande magasin de transfert de stock (catégorie de document SPC) étaient concernées.
Seuls certains utilisateurs étaient touchés : des utilisateurs RF avec un rôle restreint. La même tâche se confirmait sans erreur avec un utilisateur disposant d'autres rôles.
La note SAP 3581835 (« Dump during WT confirmation ») semblait liée, mais le dump est revenu à l'identique après son implémentation.

Lire le dump

Le dump désignait l'autorisation dès le départ, mais seulement dans les champs système. STOCK_CHANGE_CONF lit le document de transfert de stock par la requête de livraison, puis prend le premier poste du résultat :

READ TABLE lt_items_to ASSIGNING <item_to> INDEX 1.
" pas de contrôle de SY-SUBRC
... <item_to>-addin-productid ...   " dump ici

Dans chaque dump, la table de postes était vide et SY-SUBRC valait 4. Les champs système contenaient aussi le message /SCDL/AF 061 avec la variable « Display » : « No authorization for warehouse request or delivery and activity Display ».

Voici comment une erreur d'autorisation devient un dump :

La requête de livraison contrôle l'autorisation de l'utilisateur sur le document de transfert de stock, et le contrôle échoue.
Le framework ne lève pas d'exception. Il écrit le refus dans un objet message avec MESSAGE ... INTO, ce qui remplit au passage SY-MSGID et SY-MSGNO.
STOCK_CHANGE_CONF ne récupère que la table de postes, pas l'objet message. Le refus est perdu.
Le READ TABLE ne trouve rien, le field symbol reste non assigné et l'instruction suivante provoque le dump.

L'utilisateur ne voit donc jamais de message d'autorisation. La seule trace de la cause est l'identifiant de message dans les champs système du dump.

Ce qui n'a pas fonctionné

Les outils habituels n'ont rien donné :

Ajouter /SCWM/DLV2. C'est l'objet de demande magasin sous S/4HANA. Nous l'avons d'abord ajouté en affichage (ACTVT 03) pour la catégorie de document de transfert de stock, puis avec * dans tous les champs. Le dump est resté.
SU53. Aucun contrôle en échec pour l'utilisateur.
STAUTHTRACE. Lancée sur tous les serveurs d'application pendant que l'utilisateur reproduisait le dump. Aucun contrôle en échec non plus.
Les listes d'utilisation. La liste d'utilisation du message /SCDL/AF 061 ne renvoyait rien. Le texte du message appartient à la classe d'exception /SCDL/CX_AF_AUTHORITY (ID de texte AC_ACTVT_NO_AUTHORIZATION), mais la liste d'utilisation de cette constante ne trouvait que le code qui lit le message après coup, pas celui qui le lève.

Avec une trace vide et des valeurs complètes dans /SCWM/DLV2, l'autorisation semblait écartée. Elle ne l'était pas.

Trouver la cause au débogueur

Le débogueur a trouvé la cause en une session. Nous avons reproduit le scénario dans un système de test avec l'un des utilisateurs RF concernés :

Point d'arrêt externe pour l'utilisateur RF dans l'include /SCWM/LL03AFGP, sur la ligne qui appelle la requête de livraison dans STOCK_CHANGE_CONF.
Confirmation d'une tâche de transfert de stock sur le terminal par l'utilisateur, jusqu'à l'ouverture du débogueur.
Ajout de trois points d'arrêt :
- Message : ID /SCDL/AF, numéro 061
- Méthode : /SCDL/CX_AF_AUTHORITY, méthode CONSTRUCTOR
- Instruction : AUTHORITY-CHECK
Poursuite avec F8, en lisant la pile d'appels et les variables à chaque arrêt.

C'est le point d'arrêt sur le message qui compte. Il s'arrête exactement là où le framework décide que l'utilisateur n'est pas autorisé, qu'une instruction AUTHORITY-CHECK soit en jeu ou non. À partir de là, la pile d'appels et les variables locales montraient quel objet était évalué.

La cause et le correctif

Le refus venait de /SCWM/DLV, pas de /SCWM/DLV2. Dans ce flux, le système évalue les deux objets, et l'utilisateur a besoin des deux.

Objet	Description	Statut dans SU21	Nécessaire ici
`/SCWM/DLV2`	EWM Warehouse Request with Warehouse Number	Actuel	Oui
`/SCWM/DLV`	(Obsolete) EWM Warehouse Request	Obsolète	Oui

Le contrôle sur /SCWM/DLV ne passait pas par une instruction AUTHORITY-CHECK. C'est pourquoi il n'apparaissait ni dans SU53 ni dans la trace.

Le correctif a consisté à ajouter /SCWM/DLV en affichage (ACTVT 03) au rôle RF, à côté de /SCWM/DLV2. Après une nouvelle connexion, les utilisateurs ont confirmé les tâches de transfert de stock sans dump. Si vous ouvrez les deux objets à * pendant les tests, restreignez-les ensuite aux valeurs dont les utilisateurs ont réellement besoin.

À retenir

Lisez les champs système du dump. Un message d'autorisation dans SY-MSGID peut être la vraie cause, même quand le dump est une erreur de field symbol.
Un SU53 ou une trace vide n'exclut pas l'autorisation. Certains contrôles des livraisons EWM n'utilisent pas AUTHORITY-CHECK et n'y laissent aucune trace.
Obsolète ne veut pas dire inutilisé. Gardez /SCWM/DLV dans les rôles EWM à côté de /SCWM/DLV2, et regardez ce que propose SU24 avant de le retirer.
Quand les outils ne montrent rien, déboguez sur le message. Un point d'arrêt sur l'ID et le numéro du message s'arrête là où la décision est prise, quel que soit le style de programmation.

Le dump lui-même vient d'un contrôle de SY-SUBRC absent dans le code SAP. Un vrai message d'autorisation aurait fait gagner beaucoup de temps : cela mérite aussi d'être signalé à SAP.

Comment MTC intervient

Conception des autorisations sur S/4HANA et EWM intégré, rôles RF et magasin compris.
Maintenance SU24, pour que des objets comme /SCWM/DLV soient proposés là où le code les contrôle encore.
Dépannage des erreurs d'autorisation que SU53 et la trace ne montrent pas.
Revue des rôles avant la mise en production, pour que ce type de problème apparaisse en test plutôt qu'en entrepôt.

Sur les grands programmes, nous travaillons aux côtés de cabinets internationaux de premier plan en audit, risques et conseil technologique, avec une équipe senior basée en Suisse responsable du volet sécurité.

Références

3581835 : Dump during WT confirmation. Semblait liée, n'a pas corrigé ce cas.
/SCDL/AF 061 : No authorization for warehouse request or delivery and activity &1.
/SCDL/CX_AF_AUTHORITY : classe d'exception portant le message, ID de texte AC_ACTVT_NO_AUTHORIZATION.
/SCWM/DLV2 et /SCWM/DLV : objets d'autorisation de demande magasin EWM (SU21).

Questions fréquentes

Qu'est-ce qui provoque GETWA_NOT_ASSIGNED dans /SCWM/SAPLL03A à la confirmation d'une tâche magasin ?

Dans le cas décrit ici, une autorisation manquante. La routine STOCK_CHANGE_CONF de l'include /SCWM/LL03AFGP lit la demande magasin de transfert de stock par la requête de livraison, puis prend le premier poste du résultat sans contrôler SY-SUBRC. Si l'utilisateur n'est pas autorisé pour la demande magasin, la requête renvoie une table de postes vide, le field symbol reste non assigné et l'instruction suivante provoque le dump. Le refus d'autorisation n'apparaît que sous la forme du message /SCDL/AF 061 dans les champs système du dump.

L'objet d'autorisation /SCWM/DLV est-il encore nécessaire dans EWM sous S/4HANA ?

Oui, dans certains flux. SU21 marque /SCWM/DLV comme obsolète et /SCWM/DLV2 (EWM Warehouse Request with Warehouse Number) lui succède, mais la confirmation de tâches magasin liées à une demande magasin de transfert de stock (catégorie de document SPC) dans EWM intégré à S/4HANA contrôlait les deux. Les utilisateurs RF avaient besoin de /SCWM/DLV en affichage (ACTVT 03) en plus de /SCWM/DLV2.

Pourquoi une autorisation EWM manquante n'apparaît-elle ni dans SU53 ni dans STAUTHTRACE ?

SU53 et la trace d'autorisations enregistrent les instructions AUTHORITY-CHECK. Le contrôle sur /SCWM/DLV dans ce flux ne passait pas par une instruction AUTHORITY-CHECK : il n'a laissé aucune entrée dans l'un ou l'autre outil, même avec la trace active sur tous les serveurs d'application pendant que l'utilisateur reproduisait le dump. Un SU53 ou une trace vide n'exclut donc pas une cause d'autorisation dans le traitement des livraisons EWM.

Comment trouver un contrôle d'autorisation que SU53 et la trace ne montrent pas ?

En déboguant sur le message. Posez un point d'arrêt externe pour l'utilisateur concerné avant l'appel qui échoue, puis ajoutez un point d'arrêt sur le message /SCDL/AF numéro 061, un sur le CONSTRUCTOR de la classe d'exception /SCDL/CX_AF_AUTHORITY et un sur l'instruction AUTHORITY-CHECK. Le point d'arrêt sur le message s'arrête là où le framework décide que l'utilisateur n'est pas autorisé, quel que soit le style de programmation, et la pile d'appels et les variables locales montrent quel objet a été évalué.

La note SAP 3581835 corrige-t-elle le dump GETWA_NOT_ASSIGNED à la confirmation de tâche magasin ?

Pas dans ce cas. La note 3581835 (Dump during WT confirmation) semblait liée, mais le dump est revenu à l'identique après son implémentation : la cause était l'autorisation manquante sur /SCWM/DLV, pas le code que la note corrige.