Аудит в ландшафте разработки ABAP. Часть 5. Функциональные модули и группы функций

Небольшой периодический аудит в системе разработки, как и периодическое медицинское обследование не бывает лишним. Это может понадобиться, если вы:

 

В данной заметке делается обзор в части аудита групп функций и функциональных модулей.

Соглашение об именовании

Основное требование к именованию:

Это важная общая тема, касается всех разработок, а не только групп функций.

Сам SAP думает, что выделил диапазон имён Z_* для функциональных модулей клиента (знак подчёркивания). Однако большинство клиентов игнорирует это правило, и использует диапазон имён Z* по аналогии с другими объектами разработки.

Последнее проблемой не является, хотя случаются забавные накладки. Например, в одном из наших подпроектов использовался префикс ZGP_*, а потом оказалось есть родной функциональный модуль ZGP_DISPLAY и ещё парочка модулей с ним рядом.

 

Объединение в группы функций

Крайне не рекомендуется образование чрезмерно разнородных и укрупнённых групп функций, например:

Основная проблема чрезмерного объединения – это периодические проблемы при переносе. Например, если класть ведение всех-всех справочников в одну группу функций, то иногда всплывает следующий сценарий:

  1. Создали справочник А (запрос 1)
  2. Перенесли справочник А в тест (запрос 1)
  3. Создали ведение справочника А (запрос 2)
  4. Создали справочник Б (запрос 3)
  5. Создали ведение справочника Б (запрос 2)
  6. Перенос запроса 2 в тест сломает группу функций, так как таблицы Б в тесте ещё не существует

 

Если есть что-то похожее, то лучше при удобном случае раздробить группу функций на несколько мелких.  При переприсвоении функционального модуля в другую группу функций будьте осторожны: группа функций может подразумевать использование общих данных или подпрограмм.

Если исторически так сложилось, но удобного случая не подворачивается – не переживайте, так и оставляйте. То что не сломалось, можно и не чинить.

Анализ использования

Часто можно встретить брошенные функциональные модули, в хорошей системе им не место. Но как же определить, что используется, а что не используется?

Дистанционные функциональные модули

Изнутри системы невозможно определить, что используется, а что нет. Это вопрос корректного межсистемного документирования.

У ответственного должно быть представление и документация, какие модули в какой системе могут использоваться, например:

Дистанционные функции могут использоваться и внутри системы, никто такого не запрещает (типа BAPI).

Прямое использование

Часть функциональных модулей может быть отслежена напрямую при помощи функции “Where is used”. Однако это годится только для статических упоминаний вызова.

Основные источники: программы, классы, средства поиска.

Динамические вызовы

Вызов функционального модуля может делаться в статическом стиле:

call function ‘ZK2_GET_USER’
importing
    ev_ziin = lv_ziin.

Однако функцию можно вызвать и динамически:

lv_funcname = ‘ZK2_GET_USER’.
call function lv_funcname
importing
    ev_ziin = lv_ziin.

Отследить такое использование уже гораздо сложнее.

Как правило такие вызовы всегда связаны с настройкой и расширением стандартной  функциональности, и поэтому упоминание этих ФМ можно найти в соответствующих таблицах настройки:

По именованию и/или по интерфейсу часто можно догадаться об источнике вызова.

В обычной жизни я бы не рекомендовал использовать грубый динамический вызов (Z-from-Z) без осознанной необходимости.

Сгенерированные программы

SAP при прямом тесте ФМ генерирует служебные программы с именами следующего вида:

Z_MY_FUNCTION=================FT

Проблемой это не является. Пусть себе лежат в уголочке.

 

Собственные функции вне Z-области

Практически SAP не запрещает создавать функции за пределами Z-области. Появляется простое надоедливое предупреждение, на которое мало кто читает.

Такое бывает в двух случаях:

Постарайтесь свести использование грубых экзитов к минимуму.

Сгенерированные модули должны существовать, пока существуют связанные объекты. Не путайте системе карты и не лезьте внутрь без явной необходимости.

Фронт работ

Если что-то нашли, то можно что-то и поделать:

Прочая работа над исходниками выходит за рамки данной заметки.

Замечания посткриптум

К особым исключениям можно отнести такие группы функций, которые являются скорее не сборником функциональных модулей, а сборником экранов. Это совсем другая опера, и те же генераторы ведения SM30 – гораздо ближе как раз к этой опере.

Десерт

Программа, которая мне помогает окинуть взглядом эту область: лежит тут.

Аудит использования функциональных модулей

Ах да … И если вы уж дочитали до этого места, то оставьте комментарий или личное сообщение.

Опубликовано 12.12.2014 в 17:08 · Автор ivan · Ссылка
Рубрики: ABAP

2 комментария

Подписаться на комментарии по RSS

  1. Написал(-а) Аноним
    13.12.2014 в 02:51
    Ссылка

    Спс

  2. Написал(-а) Иван
    12.01.2015 в 20:30
    Ссылка

    Спасибо что поделились.
    У нас случай тиража, когда пришло время подчистить огрехи исходного проекта. Думаю может пригодится.
    Об обнаруженных особенностях: сразу заметил, что обрабатывается только случай стандартной области имен Z,Y-функций, а функции из области имен типа «/CLIENT/» не обрабатываются (у них имя программы формируется по-другому).

Подписаться на комментарии по RSS

Написать комментарий