Transaction SE16N
Depuis quelque temps, la transaction SE16N (et même 'N' ou 'V' avant que SAP ne supprime ces transactions par le biais de la note OSS n°
1115699 ) est bien utile !!
Elle contient notamment une fonctionnalité de gestion des entrées de table qui rend de fiers services lorsque la table n'a pas d'écran de maintenance.
Étrangement, cette transaction est rattachée non pas au module BC (Basis) mais au module CO-OM.
La disparition du &SAP_EDIT ?
Mais voilà, pour des raisons de "sécurité", SAP a décidé de supprimer cette fonctionnalité accessible par le OK code '&SAP_EDIT' (voir note OSS n°
1420281).
La raison invoquée est assez surprenante :
" ... Due to the circulation of this function in the Internet, security breaches have been detected in the customer authorization concepts. ... "
Personnellement, je suis d'avis de dire que le problème de sécurité était déjà présent et qu'il était seulement inconnu du grand public. Cela donne un faux sentiment de sécurité car un individu expert SAP et mal intentionné (y en a-t-il seulement un de cette espèce ? :)) sera en mesure de causer bien plus de dégâts !
Par ailleurs, il y a d'autres fonctions sensibles qui sont protégés par des objets d'autorisation dédiés (par exemple : la fonction de suppression de matricule du programme RPUDELPP et l'objet d'autorisation
P_DEL_PERN).
En effet, c'est illusoire de penser "protéger" l'accès à une fonctionnalité sensible dans un système simplement en n'en disant mot alors que le code source est visible de tous !
Enfin, pourquoi ne pas avoir limiter cette interdiction aux seuls systèmes productifs (cf. programme RPUDELPP à nouveau) et laisser la possibilité au développeur de facilement manipuler les contenus de table en Dév ou en Recette ?
Une solution ?
Pour ceux qui voudraient accéder à cette fonctionnalité (qui n'a pas été complètement éradiquée mais simplement rendu inaccessible en supprimant l'accès par le OK code &SAP_EDIT), il y a des solutions de contournement plus ou moins "persistantes" :
- la transaction UASE16N (diantre, mais pourquoi la note de sécurité n'a pas inclus cette transaction ?!)
Mise à jour 09.06.2012 : c'est désormais le cas avec la note OSS 1473881
- le bon vieux debug : vous pouvez toujours entrer en debug et modifier la valeur des variables gd-sapedit et gd-edit à 'X'.
- utiliser le module fonction standard 'SE16N_INTERFACE' en SE37 car il contient les paramètres d'entrée edit et sap_edit qu'il faut positionner à 'X'. Par contre, pas d'écran de sélection, il vous faudra utiliser les filtres ALV...
(Ceci n'est a priori valable que sur un système avec un SAPKH* assez ancien comme sur les systèmes purement HR car la note indiquée ne concerne que l'include et pas l'Interface. Mais il y a d'autres notes qui 'corrigent' ce comportement pour ce module fonction)
Une solution plus "élégante" est l'utilisation d'un Enhancement au niveau de l'include LSE16NF10 et de la routine fill_picture (qui n'est d'ordinaire utilisée que par SAP !). En rajoutant, en début de routine le code suivant :
PERFORM fill_sap_edit.
RETURN.
vous retrouvez notre fonctionnalité, désormais accessible par &SAP_PICTURE plutôt que par &SAP_EDIT. ;-D
Cette solution peut même être transportée et concerne l'ensemble de la population et pas seulement les développeurs (contrairement au debug et à la transaction SE37).
Le retour du &SAP_EDIT
Mise à jour 09.06.2012 (merci à Christophe B. pour l'info)
Vous pouvez également utiliser la note
OSS 1446530 pour réactiver le &SAP_EDIT avec un objet d'autorisation filtrant les accès (comme quoi...)
Pour terminer, rappelons que les modifications faites via les outils "SE16N" au sens large sont loguées dans les tables SE16N_CD_KEY et SE16N_CD_DATA !
La technologie Flex commence vraiment à faire des émules ! Même SAP s'y est mis en proposant les 
