NB : A priori cette méthode ne fonctionne que pour les variables globales.

Astuce de l'astuce : Pour déterminer le programme d'origine de la donnée et son accessibilité, il est pratique d'utiliser le debugger : vérifier que la variable contient le contenu désiré en remontant dans la stack d'appel puis vérifier que la variable liée au programme ((PROG)VAR) est disponible dans le programme désiré.

Astuce de l'astuce 2 : Appeler un FORM bidon pour provoquer l'exécution du programme principal et pouvoir ainsi récupérer des variables.

Source

FIELD-SYMBOLS <fs> TYPE ANY.
* Pour une variable quelconque
ASSIGN ('(PROG)VAR') TO <fs>.
* Pour un contenu de table
ASSIGN ('(PROG)TABLE[]') TO <fs>.
* Il est évidemment possible de variabiliser :
DATA : var_name TYPE (30)C.
IF cond1.
  var_name = '(PROGX)VAR1'.
ELSE.
  var_name = '(PROGY)VAR2'.
ENDIF.
ASSIGN (var_name) TO <fs>.

Il arrive que des modules fonction génère des erreurs directement via des MESSAGE EXXX(foo) plutôt que des RAISE EXCEPTION. Dans ce cas, pour ne pas que tout le process soit interrompu (y compris le programme appelant, quand bien même il serait exécuté par un user technique en background), il faut attraper le message. Par chance le moteur ABAP génère une exception ERROR_MESSAGE à l'appel toute l'instruction MESSAGE EXXX(foo). Il s'agit donc simplement d'ajouter EXCEPTIONS error_message = 1. à l'appel du FM récalcitrant ! (ça marche à tous les coups, même si la signature du FM ne contient aucune exception.)

Sauce

Le FM SYSTEM_CALLSTACK permet d'accéder à la callstack au runtime. Très intéressant pour savoir qui a appelé votre prog/FM/method, etc.

Utiliser le FM SAPGUI_PROGRESS_INDICATOR.