Как найти путь настройки через IMG-Activity

Действия IMG поддерживаются с помощью довольно громоздкой транзакции S_CUS_IMG_ACTIVITY. Эта транзакция предоставляет функцию использования:

Отслеживание этой функции ведет через функциональные модули S_CUS_IMG_ACTIVITY_XREF и S_CUS_IMG_ENTRY_VIA_ACTIVITY к функциональному модулю с именем STREE_GET_NODES_FOR_GIVEN_REF, который идентифицирует узлы (для подготовки проверьте его вызывающую сторону). Чтение этих функциональных модулей дает вам много информации о структурах и функциональных модулях, которые будут использоваться.

Для ваших целей STREE_GET_NODES_FOR_GIVEN_REF может быть интересным. В списке ссылок укажите идентификатор активности как NODE_ID с типом COBJ. Это даст вам список узлов, включая их родительские идентификаторы, которые вы затем можете передать в STREE_GET_PARENTS_OF_NODE (идентификатор структуры — это идентификатор дерева из набора результатов). Чтобы получить текст узла, вы должны использовать STREE_NODE_READ.

Вот еще один подход к поиску пути IMG, основанный на таблице.

В e071k у нас есть технические идентификаторы действий IMG. Вы также можете включить их в SPRO через «Дополнительная информация» -> «Дополнительная информация» -> «Ключ отображения» -> «Активность IMG», поэтому они будут отображаться следующим образом:

Но в таблице TNODEIMG у нас есть идентификаторы GUID, которые не совпадают с техническими. Таблица отношений, которую вы можете использовать для их связи, — это TNODEIMGR, она содержит как GUID, так и технический идентификатор каждого узла. Соединяя родительский узел, идентификатор узла и текст узла из таблиц TNODEIMGR, TNODEIMG и TNODEIMGT, мы можем построить полный путь IMG для каждого узла:

REPORT z_img.

DATA: lv_final_path TYPE string,
      exit_root     TYPE abap_bool,
      out           TYPE string.

* picking random activity from requests
SELECT SINGLE *
  FROM e071k
  INTO @DATA(lv_e071k).

* finding correspondent GUID ID for tech ID
SELECT gr~node_id, ach~text, img~parent_id
  FROM tnodeimgr AS gr
  JOIN cus_imgact AS ach
    ON ach~activity = gr~ref_object
  JOIN tnodeimg AS img
    ON img~node_id = gr~node_id
   AND spras = @sy-langu
  INTO TABLE @DATA(lt_node)
 WHERE ref_object = @lv_e071k-activity.

LOOP AT lt_node ASSIGNING FIELD-SYMBOL(<fs_tnode>).
  CLEAR: lv_final_path.

* writing bottom node text
  lv_final_path = lv_final_path && <fs_tnode>-text.
  DATA(lv_node_id) = <fs_tnode>-parent_id.

  DO 15 TIMES.
* fetching parent node text
    SELECT SINGLE g~parent_id, text
      INTO @DATA(lv_node)
      FROM tnodeimg AS g
      LEFT JOIN tnodeimgt AS t
        ON t~tree_id = g~tree_id
       AND t~extension = g~extension
       AND t~node_id = g~node_id
       AND t~ext_key = g~ext_key
       AND t~spras = @sy-langu
     WHERE g~node_id = @lv_node_id.

* checking if parent exists
    IF sy-subrc <> 0.
      exit_root = abap_true.
      EXIT.
    ELSE.
      exit_root = abap_false.
    ENDIF.

    lv_final_path = |{ lv_final_path } \n { repeat( val = |\t| occ = sy-index + 1 ) } --> { lv_node-text }|.
    lv_node_id = lv_node-parent_id.

    IF lv_node-parent_id IS INITIAL.
      EXIT.
    ENDIF.

  ENDDO.

  CHECK exit_root = abap_false.
* building the path
  lv_final_path = | IMG  path no. { sy-tabix } is \n\n { lv_final_path } \n\n |.
  out = out && lv_final_path.

ENDLOOP.

cl_demo_output=>display( out ).

Однако при таком подходе самый корневой узел IMG недоступен.