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

• входите на проект с существующим большим историческим слоем разработок
• принимаете большой объём разработок от подрядчика/субподрядчика
• просто решаетесь на ежегодную генералку или ревизию

 

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

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

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

• Соблюдение внутрипроектных правил (префиксы и прочее)
• Соблюдение мнемонической понятности
• Наличие мета-описания

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

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

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

 

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

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

• Использование одной группы функций при генерации ФМ для объектов из разных модулей или подгрупп
• Смешивание сгенерированных групп функций с обычными
• Смешивание дистанционных функций, функций расширения функциональности, средств поиска и источников для экстракторов

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

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

 

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

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

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

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

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

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

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

• вызов из другой ABAP-системы, например: отдельная инстанция HCM
• вызов из интеграционной платформы XI/PI

Дистанционные функции могут использоваться и внутри системы, никто такого не запрещает (типа 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.

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

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

• правила деривации
• источники данных BW
• события BTE
• события в обработке бизнес-партнёров
• и ещё много-много разных источников

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

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

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

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

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

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

 

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

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

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

• По глупости и недосмотру. В этом случае просто перенесите ФМ в Z-область.
• Грубые экзиты
  • Подпрограммы преобразования
    (CONVERSION_EXIT_xxxxx_INPUT,  CONVERSION_EXIT_xxxxx_OUTPUT)
  • Field-exits
    (FIELD_EXIT_xxxxx_0)

• Сгенерированные модули через связанные объекты:
  • Объекты блокировки
    (ENQUEUE_EZMYOBJECT, DEQUEUE_EZMYOBJECT)
  • Документы изменений
    (ZMYOBJECT_WRITE_DOCUMENT)
  • Ведение таблиц
    (TABLEFRAME_ZMYTABLE, TABLEPROC_ZMYTABLE)

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

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

Фронт работ

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

• Удалять неиспользуемые ФМ и группы функций
• Приводить имена, параметры и описания в порядок
• Реорганизовывать группы функций
• Документировать дистанционные функции

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

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

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

Десерт

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

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