Точенюк Олег, консультант по SAPMM. Профессиональный опыт: занимал должности консультанта по SAPММ в различных компаниях с 1997 года. Занимался внедрением модулей: FI-FM(Контроль исполнения бюджета), ММ (Управление материальными потоками), СУС (WMS) (Управление складом); занимал должность консультанта по интеграции MM<->ТОРО, участвовал в разработках расширений системы на языке ABAP. Связаться со мной можно по адресу uukrul@hotmail.com

1.1. SLIN – Расширенная проверка программы

SLIN - простая транзакция, которая позволяет быстро выполнить проверку качества написанного кода для программы. Можно без трудностей проверить простые отчеты, но если нужно проверить что-то «глобальное», то следует использовать транзакцию «Инспектор кода SAP». Создаваемую программу можно проверить или запустив отдельно транзакцию SLIN, или же, находясь в инспекторе кода (например, транзакция SE38 – ABAP редактор), выполнить по меню последовательно: «Программа» – «Проверить» – «Расширенная проверка программы». При этом, если вы находитесь в одном из модулей программы, система начнет проверку с базового модуля. Например, имеем программа по формированию отчета, которая определенным способом выбирает документы резервирований, она включает в себя несколько модулей, по которым разнесена логика её работы. Находясь в редакторе кода, выбираем расширенную проверку программы, Рисунок 15.

Рисунок 15:

SE38-1

Будет запущена транзакция SLIN, куда будет автоматически подставлено имя программы находящейся в редакторе кода в текущий момент. По умолчанию большинство позиций будет отмечено для расширенной проверки, Рисунок 16. Любая расширенная проверка вашей программы, покажет, что с точки зрения системы SAP, вы писать правильно не умете (если вы не следуете правилу - предварительно запускать расширенную проверку для каждого вашего текста).

Рисунок 16:

SLIN-0

Запустим проверку, отметив все галки в блоке «Проверки». Получим таблицу со списком данных проверки. Так как сам по себе проверяемый отчет не слишком большой, то в данном случае совсем уже критических предупреждений сравнительно немного, Рисунок 17. Данные в таблице сгруппированы в три колонки:

Рисунок 17:

SLIN-1

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

Для детального просмотра информации нужно сделать двойной клик мышью в интересующем поле и система перейдет к экрану с детальной информации по проблемам.

• Тестовая среда – Ошибки тестовой среды возникают в случае тестирования стандартных программ SAP, для которых компания разработчик запретила выполнение тестов; например, тестирование программы SAPMM07M – Пул модулей для движений материала - выдает такую ошибку и соответственно далее все тесты пропускаются, что в принципе правильно, иначе при тестировании стандартной SAP-программы может ведь такое обнаружится… (не стоит вводить в искушение неокрепшие умы, а окрепшие умы и так знают, через какое место оно написано местами.)
• PERFORM/FORM-интерфейсы – критические ошибки в данном случае не встречал, а из предупреждений, система предполагает, что если в тексте программы нет явного вызова объявленной подпрограммы, то скорее всего, такая подпрограмма не используется, хотя возможно есть динамический вызов, Рисунок 18.

Рисунок 18:

SLIN-2

Таким образом система предупредила, что прямого вызова нет, но удалять, не разобравшись, данную подпрограмму не следует, так как возможно есть динамический вызов. Далее, если вы не хотите, чтобы расширенная проверка выдавала предупреждение по поводу подпрограммы, в данном случае FORM ALV_PF_STATUS, можно использовать код "#EC CALLED, для отключения выдачи сообщения. Для применения этого кода, добавьте его в таком виде в программу:

Т.е. в строке кода объявления подпрограммы FORM USER_COMMAND, поставьте комментарий "#EC CALLED, после этого расширенная проверка программы больше не будет обрабатывать данную процедуру и выдавать ее в журнал предупреждений. С точки зрения производительности и читаемости кода, в конечном результате наличие подпрограмм, которые не используются, наверняка будет лишним, поэтому перед сдачей больших проектов такая проверка будет не лишней.

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

Сообщение будет оформлено следующим образом, Рисунок 19. В общем виде, если тип не важнее, рекомендуется указать директиву TYPE ANY, хотя в данном случае наверное более правильно было бы указать TYPE matnr, т.е. явно сказать системе, что в данном параметре будет передаваться код материала. В принципе, объявление параметров без явного указания типа, тянется со старых версий. В новых версиях системы, настоятельно рекомендуется указывать типы параметров, что позволит, на этапе компиляции получить ошибки неправильной передачи параметров при вызове такой подпрограммы и избежать проблем в работе.

Рисунок 19:

SLIN-3

Код отключения сообщения для параметра, который вы должны указать в строке, напротив передаваемой переменной,– "#EC *

Исправление ошибки: Удалите из кода все подпрограммы, которые не используются. Переменные параметров в подпрограммах объявите, используя ссылки на типы системы. Такие объявления помогут на этапе компилирования выявить возможные проблемы неправильной передачи параметров, особенно для подпрограмм, которые используются много раз по тексту разработки.

• CALL FUNCTION – интерфейсы – Выполняется проверка вызовов функциональных модулей. Критические ошибки не попадались, так как обычно я использую вставку вызова функционального модуля через шаблоны, поэтому остаются только предупреждения связанные с отсутствием обработки SY-SUBRC кода после вызова функции, других предупреждений мне не попадалось, Рисунок 20.

Рисунок 20:

SLIN-4

Код отключения сообщения для параметра – "#EC *, который нужно поставить за именем функционального модуля, например так: CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' "#EC *.

Сообщение будет подавлено. Наверное, хорошим тоном будет, все - таки обработка ошибок работы функционального модуля, если разработчик предполагает, возврат ошибок работы функции.

Исправление ошибки: Вставьте блок анализа не нулевого значения кода возврата системной переменной SY-SUBRC после вызова любого функционального модуля, если модуль предполагает возврат ошибок через эту системную переменную.

• Внешние программные интерфейсы – выполняются проверки на правильные имена при вызове; например, имена внешних транзакции, диалоговых модулей, вызова других программ, используя команду SUBMIT и т.д. Проверяются параметры вызовов на синтаксический ошибки. В принципе, если вы тестируете то. что пишите, такие ошибки сгенерируют дамп времени выполнения программы во время выполнения вашей программы.
• Непротиворечивость экранов – Проверяется правильность созданных экранов в программе. Из полезного, проверяется наименование полей и наличие их же или в словаре или вашей программе. Мне представляется, что это наиболее частая ошибка при работе с экранами; так как передача заполнения полей экрана выполняется по имени переменной, то имя переменной экрана должно быть так же названо и в вашей программе, иначе ошибок зафиксировано не будет, но и значения, введенные с экрана, не попадут в соответствующие переменные программы.
• Полномочия – Проверяются объекты полномочий на их наличие в системе, смысла в этом особого не вижу, так как я обычно вставляю объект полномочий в программу через кнопку «Модель» и соответственно ошибки в имени вставляемого объекта быть не должно.
• GUI-статус и TITLEBAR – Проверяется, есть ли вызываемые GUI-статусы и заголовки экранов в пуле программы. Возможно, кому-то это и нужно при больших разрабатываемых программах с десятками статусов и заголовков.
• Ид. SET/GET-параметров – Проверяет, создан ли в системе используемый SET/GET параметр.
• MESSAGE (сообщение) – Проверяются номер и класс сообщения на существование в системе. Так же проверяется количество формальных параметров, передаваемых при вызове номера сообщения из программы с их количеством при объявлении номера сообщения. Дополнительно проверяются длинные тексты к сообщениями, если они созданы.
• Цепочки знаков – данная проверка считает ошибкой использование прямых текстовых цепочек знаков в коде программы, т.е. например, такой код считается ошибочным: fieldcat_ln-seltext_m = '№ Позциии', т.е. когда текст явно задан. Рекомендуется использовать текстовые переменные вида TEXT–xxx, ведение текстов к программе выполняется через меню: «Перейти» – «Текстовые элементы» – «СимволыТекстПеременн», Рисунок 21.

Рисунок 21:

SLIN-5

Код отключения сообщения для параметра – "#EC NOTEXT, который нужно поставить после текстовой цепочки.

Предупреждения в данном поле возникают в том случае, если в программе объявлены текстовые переменные, которые нигде не используются, Рисунок 22. Скрыть такие сообщения нельзя (SAP настоятельно рекомендует удалять неиспользуемые текстовые переменные), в данном случае это - код TEXT-303. Причина такого требования в том, что все текстовые переменные грузятся в память при первом запуске программы и находятся постоянно в памяти. Если учесть, что текстовые переменные находятся в каждом пуле функций и т.д., то результатом объявления большого числа неиспользуемых текстовых переменных во всех этих программах будет занятая бесполезными данными память.

Рисунок 22:

SLIN-6

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

Информационные сообщения этого блока расширенной проверки, будут включать в себя сообщения для тех переменных селекционных экранов выбора, для которых в программе не заведены текстовые метки описания. Для таких переменных при запуске программы на экране, будет выведено в качестве метки имя переменной.

Исправление ошибки: Перенесите все тексты в область ведения текстов программы и далее используйте ссылки на тексты вида TEXT-xxx. Как максимум, это возможно упростит перевод программы в случае ее локализации на другие языки, и как минимум, для Украины перевод бывает иногда очень актуален. 

• Вывод CURR/QUAN-полей – в системе SAP количество дробных знаков для полей типа сумма определяется в настройке, поэтому, например, при выводе такого поля на экран, система требует, чтобы был указан код валюты, который и определит, как выводить число. Кстати, именно поэтому при создании, например, собственной таблицы в базе данных, если вы объявляете поле сумма или количество, то не можете активировать таблицу, пока не укажете для таких полей ссылочное поле, которое будет содержать тип единицы измерения. Более подробно как система работает с данными типа CURR можно прочитать по ссылке: http://www.sapland.ru/qa/problema-ogranicheniya-kolichestva-znakov-v-stoimosti-zakaza-moduli-mm-i-sd.html. Вывод строки суммы или количества без указания ссылочной величины считается ошибкой и требует исправления. Текст, примера ошибки, показан на Рисунке 23.

Рисунке 23:

SLIN-7

Данную проверку можно отключать, для этого нужно использовать хинт: "#EC UOM_IN_MES, который следует указать в строке, где используется, например, вывод количества, без ссылки на единицу измерения.

Исправление ошибки: Код, который вызвал данную ошибку расширенного анализа, например, такой:

Для исправления строку вывода количество следовало бы оформить следующим образом.

Ну а для полей типа сумма следует указывать дополнение CURRENCY <код валюты>.

• Свойства полей – Ошибочные ситуации я не встречал, а вот предупреждения в большинстве случаев относятся к переменным, которые объявлены в коде, но не используются нигде в тексте программы. В 99% случаев так оно и есть, так как вы просто забыли про объявленную переменную или перестали ее использовать, и 1% остаётся на переменные, доступ к которым, выполняется неявно, например, через переменные типа FIELD-SYMBOLS. Текст сообщения выгляди следующим образом, Рисунок 24.

Рисунок 24

SLIN-8

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

Расширенный анализ выдаст предупреждение по поводу переменных L_VALUE и L_FIELD. В данном случае, нам нужна только позиция курсора, а вот переменные имени поля и значения используются только потому, что команда языка GET CURSOR FIELD требует наличия переменных, куда будет помещено имя поля и ключа. Поэтому переменные мы объявили, система вернет в них значения, но далее эти переменные нигде не используются, поэтому рекомендуется использовать хинт – "#EC NEEDED, который скрывает такие предупреждения из расширенного анализа. Хинт как обычно указываем в строке объявления переменных, после чего система больше не выводит предупреждения по таким переменным.

Исправление ошибки: Переменные, которые действительно не используются в коде, просто удалите или как минимум закомментируйте. Переменные, доступ к которым выполняется неявно, пометьте хинтом – "#EC NEEDED, чтобы скрыть данное предупреждение. В общем виде суть данной проверки - избавиться в коде от не- используемых переменных, что в большой программе позволяет экономить память и улучшает читаемость и анализ кода.

• Избыточные операторы – В данную проверку, попадают блоки операций, которые не используются в программе, например это макросы которые нигде не используются или, объявленные подпрограммы, которые не содержат вообще никакого кода внутри себя, Рисунок 25.

Рисунок 25:

SLIN-9

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

Исправление ошибки: Удалите неиспользуемые макросы из текста программы, если это возможно, или задайте хинт – "#EC NEEDED для скрытия предупреждения. Пустые подпрограммы также удалите, если их реализация не предполагается. Как и в предыдущем случае улучшается читаемость кода и его размер.

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

Вы получите предупреждение при расширенной проверке, соответствующее Рисунку 26. Как видно из текста предупреждения, оно выдается только при запуске расширенной проверки программы, т.е. при стандартной компиляции этого предупреждения нет.

Рисунок 26:

SLIN-10

Проблема заключается в том, что ключ группы объявлен как 001. Не знаю, почему этого нельзя делать, может у SAP есть какие-то виды на то каким должно быть имя группы.

Исправление ошибки: Используйте буквенные имена групп или хотя бы начинайте имя группы с буквы, например – P01 вместо имени – 001, это снимет проблему или используйте хинт, отключения данного предупреждения – "#EC *.

• Проверка размеров загрузки – Встретить такие проблемы, наверное сложно, если конечно вы не пишите очередной IS (индастир солюшен) в своей области, но ограничения в программах бывают разные, поэтому вы должны знать, что размер выполняемого кода, количество переменных, констант и т.д. объявленных в вашей программе имеет определенный предел. Система, анализирует размеры вашего кода и при достижении границы в 90% выдается информационное сообщение, на границе 95% выдается предупреждение, при достижении 98% будет выдаваться ошибка. Общие ограничения в системе следующие:

1. Общий используемый размер адресации программы не должен превышать – 2 097 152 байт, при этом не забываем, что комментарии по тексту программ, тоже входят в эти байты.
2. Количество констант в программе – 16 384 штук.
3. Количество переменных в