Функциональная

Практические рекомендации по оптимизации область:

программ на ABAP, анализ написанного кода IT, Basis, ABAP / Managment IT
Ролевое назначение:
SAP Консультант / Consultant

Ключевые слова:
разработка на ABAP / ABAP
Development / ABAP

Олег Точенюк
Точенюк Олег, консультант по 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.

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

Расширенный анализ выдаст предупреждение по поводу переменных L_VALUE и L_FIELD. В

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

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

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

 Избыточные операторы – В данную проверку, попадают блоки операций, которые не

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

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

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

 Предупреждения проверки синтаксиса – ошибки проверки синтаксиса вам обычно скажет

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

Вы получите предупреждение при расширенной проверке, соответствующее Рисунку 26. Как

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

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

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

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

При этом достигать порога в 90% очень не советую, рекомендуется, как минимум оставлять зазор
в 10% на внутренние нужды, как самой системы, так и на свои же дальнейшие корректировки и
исправления этого кода.

Исправление ошибки: Если вы написали в рамках одной программы почти 2 Гб кода, с кучей
переменных, то вы очень плодовитый ABAP-программист и теперь для вас пришло время, когда
пора как-то подумать о том, чтобы правильно структурировать все написанное и привести его в
читабельный вид. Как это сделать? Вынесите часть кода во внешние программы, которые будут
вызваться через SUBMIT, или перенесите некоторую часть кода в группы функций или глобальные
классы.

 Интернационализация – Проверяется корректность работы операции перевода в нижний/верхний

регистр в языковой среде, в которой происходит операция перевода. Фактически на данный
момент правильному вызову перевода в верхний/нижний регистр должна предшествовать команда
SET LOCALE LANGUAGE, после чего уже можно вызвать операцию TRANSLATE data-txt TO
UPPER CASE.

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

 Проблематичные операторы – Мне встречались только сообщения по поводу объявления

переменных в блоке MODULE. Такие переменные фактически являются глобальными, о чем
система вас и предупреждает, Рисунок 27. Но в целом еще проверяется дублирование операции
WHEN в структурах CASE, вызовы операций FREE MEMORY, проверяются написанные вызовы
функциональных модулей, секция EXPORTING, зарезервированные имена, начинающиеся с %_ и
еще много другого, о чем можно или прочитать в справке к операции проверки или же узнать в
ходе проверки своей программы с объяснением причины ошибки.

Рисунок
 SLIN-11
27:
 Исправление ошибки: Постарайтесь избегать объявления переменных в секциях MODULE /
ENDMODULE. Если же такое пришлось сделать по каким-либо причинам, то подавить вывод этого
предупреждения можно используя хинт – "#EC *.

 Расширения структур – Начиная с версии, наверное, ECC 5.0 (точно, что в текущей версии ECC
6.0), при объявлении структур или собственных таблиц в базе данных, система требует при
активации определить категорию расширения создаваемой структуры/таблицы. Так вот если при
создании разрешить расширение структуры, то при использовании переменной типа созданной
структуры система будет выдать ошибку при расширенной проверке, суть которой сводится к тому,
что в случае расширения структуры или таблицы могут возникнуть проблемы с размерами
структур в программе, имеющими тип структуры, созданной в словаре. В общем виде, раньше,
когда программы в системе были не компилированные, такой проблемы быть в принципе не могло.
Сейчас же, по факту дополнения структуры, возможно, придется в ручном режиме
перегенерировать исходные коды, в которых встречается объявления переменных типа
расширенной структуры.

Приме текста сообщения, Рисунок 27.

Рисунок 27:  SLIN-12
Исправление ошибки: При объявлении собственных структур в словаре данных, выбирайте
признак расширения структуры – «Без расширения».

 Направления программирования – предупреждения данного типа не попадались и в справке к

данному типу проверки никакой информации тоже не нашел.
 Устаревшие операторы – наверное, будет содержать самый большой список ошибок и
предупреждений, что логично, так как языку уже много лет… и со временем SAP начинает считать
некоторые конструкции устаревшими. Поддержка таких элементов языка похоже отменяться не
будет, так как кроме нового кода, есть большой груз старых текстов. Лично я, например, все никак
не привыкну перестать использовать такие конструкции как STRUCTURE или LIKE или объявления
таблиц с заголовком и т.д. Кстати, к быстродействию данный раздел проверки тоже имеет прямое
отношение. Например, если нужно прочитать строку внутренней таблицы по индексу, используя
READ TABLE, и при этом значения вы не передаете ни в какую структуру, то SAP рекомендует
использовать расширение команды TRANSPORTING NO FIELDS, чтобы лишний раз не гонять
данные, Рисунок 28.

Рисунок
 SLIN-13
28:
Исправление ошибки: Наверное, вдумчиво пересмотреть используемые наборы команд системы
и перейти на одобренные лучшими «Абаповодами» новые правила языка ABAP.
 Пакетная проверка – насколько я понимаю, проверяются ссылки на структуры ABAP-словаря:
являются ли эти ссылки существующими в системы и являются ли они активными.
 Общие для программ тесты – Проверятся циклы LOOP.. ASSIGNING , на предмет
переопределения ссылки или ее деинициализации через UNASSIGN внутри цикла. Проверяются
операторы, приводящие к вызову COMMIT WORK внутри цикла выбора данных, используя
операции SELECT. Так же проверяется изменение параметров подпрограммы объявленных через
USING, при вызове которых передаются константы, например, такой код, вызовет ошибку проверки
синтаксиса:

Хотя на верхний уровень (на работоспособности в целом) изменение параметра, объявленного

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

1.2. SCI / SCII – SAP Code Inspector

Транзакция расширенной проверки программы SLIN неплохо справляется в случае проверки одной
программы, даже возможно и большой, но если в разработке участвуют несколько человек,
которые пишут не одну программу, а на пример это группа программ включающая в себя как
диалоговые модули так и различные отчеты, то использовать отдельно для каждой программы
расширенную проверку по отдельности не очень удобно. Поэтому SAP разработал отдельный
расширенный анализатор кода, транзакция «SCI – SAP инспектор кода», который позволяет
выполнить проверку группы разработок, имеет возможность настроить точные параметры
проверки в группе и т.д. Центральный экран транзакции SCI показан на Рисунке 29. Данная
транзакция доступна с версии 6.0, для более ранних версий ее можно загрузить отдельно,
используя ноту 543359.
Рисунке 29: SCI-1
В общем виде требуется создать вариант проверки программ, включающий в себя список
объектов, которые будут проверяться и вариант параметров проверки. Все это объединяется под
общим именем инспекции, но если нужно быстро проверить какой-то объект, то можно и не
создавать инспекцию для проверки, поэтому рассмотрим оба варианта работы транзакции.

Простой метод, не вводим в блоке «инспекция» никакого имени, а сразу нажимаем кнопку
создания проверки, другой вариант быстрого перехода к проверке это использование транзакции
SCII – Инспектор кода: инспекция, результат будет такой же, мы попадем на экран задания
объекта и параметров проверки кода.

Рисунок 30: SCI-2
Система перейдет к следующему экрану, где запросит у вас имя объекта для проверки параметров
выполнения, т.е. собственно говоря, спросит, как будем проверять. Фактически, данное дерево
проверки, содержит данные транзакции SLIN, но содержит дополнительные параметры по
управлению анализом кода. Стандартно некоторые ветки в дереве уже будут отмечены, однако
если галка стоит на более высоком уровне дерева, это не значит, что все ответвления ниже также
отмечены для варианта обработки, Рисунок 31.
Рисунок 31: SCI-3
Примечание: Параметры проверки, выполняемые в транзакции SLIN, находятся в данном дереве
отдельным пунктом по пути: «Проверка синт./Генерация» – «Расшир. проверка программы», там
же можно задать галки аналогичные транзакции SLIN.

На данном экране можно: или выбрать уже созданный вариант набора объектов; указать объекты,
находящиеся в общем запросе, или указать непосредственно программу или группу функций для
проверки; тип объекта выбирается из выпадающего списка. Далее можно выбрать уже созданный
ранее вариант параметров проверки или выбрать вариант временного определения и задать
нужные галки непосредственно в дереве ниже. Затем, когда мы определили объект проверки и
правила проверки, можно запустить саму проверку, Рисунок 32.
Рисунок 32: SCI-4
Результат проверки будет представлен в виде дерева, по аналогии с информацией транзакции
SLIN, например, в данном случае, как видим, критическим с точки зрения системы является
задание текстов непосредственно в тексте программы, без использования текстовых элементов,
Рисунок 33.

Рисунок 33: SCI-5
Фактически получаем те же данные, что и для транзакции SLIN, однако в отличие от нее, данная
транзакция может быть преднастроена на то, какие ошибки считать критическими, какие
предупреждением, а что считать информацией. К сожалению, не все сообщения можно
настраивать, но что-то в реакции системы можно регулировать. Для этого на первом экране
транзакции SCI нужно перейти по меню «Перейти к» – «Управление» – «Приоритеты сообщений»,
Рисунок 34. Например, если для таблицы в операции SELECT не заданы ограничения выбора в
WHERE, то система, по умолчанию, выдает сообщение класса – предупреждение.

Рисунок 34: SCI-12
Для изменения реакции, соответствующей выбранному действию, можно просто кликнуть мышью
на значёк предупреждения, в данном случае это - желтый треугольник, и в появившемся окне
система предложит вам выбрать новую реакцию на данный код. Например, можем задать, чтобы
выдавалось сообщение об ошибке, Рисунок 35. В колонке рядом, «Актуальный приоритет»,
система покажет, что текущая настройка отсутствия команды WHERE при использовании
оператора SELECT – критическая ошибка.

Рисунок 35: SCI-13
Что в этой настройке неудобно, так это то, что настройка реакции выполняется глобально и не
зависит от варианта, т.е в данном случае система будет для всех тестов выдавать критическую
ошибку, при отсутствии ограничений для оператора SELECT.

Более интересным и, наверное, правильным вариантом проверки, будет являться создание

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

Вариант проверки: Вводим имя варианта и нажимаем создать вариант, система перейдет к
дереву, в котором нужно задать те проверки, которые мы считаем правильными для своей
разработки. После отметок нужных текстов сохраним вариант, Рисунок 36. В отличии от
транзакции SLIN, при формировании параметров проверки в транзакции SCI, можно более гибко
управлять параметрами проверки данных.
Рисунок 36: SCI-7
Например, стандартно система считает, что переменные параметров для оператора PERFROM
должны начинаться с префикса P_, а это значит, что если у вас параметры будут начинаться с
другого префикса, то система будет выдавать информационное предупреждение о не
согласованности в именах переменных. Я предпочитаю чуть изменить такое соглашение.
Например, начинать параметры для простых переменных, с префикса – P_, параметры структур –
PS_, параметры таблиц – PT_. Теперь нужно объяснить системе наши соглашения по именам. Для
этого нужно перейти к атрибутам проверки и ввести свои параметры соглашений, напротив
каждого теста, есть колонка «Атрибуты» и кнопка перехода к ведению атрибутов, Рисунок 37.

Рисунок 37: SCI-10
Нажав данную кнопку, получим большой список соглашений по всем параметрам, находим блок,
относящийся к параметрам вызова подпрограмм, Рисунок 38. Как видим, предпочтения по именам
делятся в разрезе USING / CHANGING / TABLES. В данном случае, можем добавить в параметры
USING / CHANGING свой тип PS_*, а значение в TABLES-параметра заменить на PT_*, ну и если
имеются какие-то предпочтения по именам подпрограмм, то можно заполнить поле FORM, т.е.
фактически мы говорим какие соглашения по именам считать правильными.
Рисунок 38: SCI-11
Таким образом, можно настроить инспектор кода под правила разработки, которые существуют в
вашей компании, ну если конечно они существуют.

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

Рисунок 39: SCI-7
Создав вариант включения объектов, сохраним его, аналогично варианту проверки данных, и
теперь можно объединить вариант проверки с вариантов набора объектов, создав инспекцию
проверки данных.

Инспекция проверки: Инспекция проверки, как говорилось ранее, состоит из объединения

варианта проверки и набора объектов. Поэтому введем имя инспекции, после чего выберем кнопку
создания. На следующем экране система уже не будет предлагать нам ручной вариант настройки
варианта проверки, хотя внести в ручном режиме набор объектов можно. Выберем из списка
созданный ранее набор объектов и вариант проверки в соответствующие поля на экране, Рисунок
40.
Рисунок 40: SCI-8
Теперь можно или выполнить вариант инспекции или сохранить вариант, например, чтобы
запускать проверку периодически. Вариантов выполнения есть два, выполнить в диалоге или в
фоновом режиме. Если разработки большие или проверка выполняется периодически, например,
каждые выходные, чтобы наутро иметь результаты обработки, то можно настроить периодическое
фоновое задание для запуска данной инспекции. Результаты проверки будут сохранены в логе
созданной инспекции. Кстати, красная лампочка рядом с именем инспекции показывает, что
проверка не выполнялась, после выполнения проверки лампочка станет зеленой и появится
кнопка перехода к просмотру данных проверки, Рисунок 41.

Рисунок 41: SCI-9
Параметры вывода результатов проверки будут представлены деревом. Просмотреть результат
можно в любой момент, нужно только ввести имя варианта инспекции и нажать кнопку просмотра
«Результаты». Также можно создать новый вариант запуска анализатора или удалить старые
варианты, Рисунок 42. Двойной клик мышью на тексте сообщения позволяет перейти к просмотру
текста программы, которая сгенерировала это сообщение. Кнопка информации выдает краткую
справку о причинах реакции системы и небольшие разъяснения о причинах, и как можно исправить
и отключить данное сообщение. Не все сообщения можно отключать.
Рисунок 42: SCI-14
Примечание: Транзакции SLIN и SCI анализируют написанный код. Кроме функции приведения
кода к общему стандартному виду, что само по себе немаловажно, данные транзакции позволяют
предварительно определить критические с точки зрения производительности места в программах,
без их непосредственного выполнения (фактически это потенциально критические места).
Фактические узкие места, в работе программ, анализируются другими методами, например,
включением трассировки выполнения программы и т.д.