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

На первом уровне это хардкод внутри программы:

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

Хардкод вполне оправдан, если:

• в течении всего жизненного цикла эти настройки не будут меняться;
• не будет кейсов, когда именение настройки может быть сделано без изменения связанного исходного кода.

Вторым уровнем может возникнуть классическая настроечная таблица + сгенерированное ведение в транзакции SM30. Впрочем тут тоже можно сделать шаг вправо и влево:

• кучу таблиц можно объединить в кластер SM34;
• ведение можно привязать к коду транзакции;
• ведение можно добавить в SPRO;
• таблицы могут быть зависимые/независимые от манданта;
• таблицы могут быть частью настройки или вестить непосредственно в продуктивной системе.

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

Доходит иногда до смешного, даже в стандарте можно наблюдать целые настроечные таблицы в виде одной колонки («Активировать»), соответственно в таблице только одна строка со значеним — флажок стоит или нет.

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

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

• глобальные переменные STVARV;
• рабочие списки (OB55 и похожие);
• версии баланса (почему бы и не);
• деривация (ну если уж так);
• кастомные атрибуты объектов, если позволено.

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

• ZSPRO (https://quelquepart.biz/article5/zspro-parametrage-specifique)
• ABAP quick options (https://github.com/bizhuka/aqo)

Добро пожаловать под кат, представляю вам свой велосипед, там есть пара занятных моментов. Почему свой? Да потому что у остальных есть фатальный недостаток, очевидно. (далее…)

Устав от простыней в стиле:

я решил обкатать новый подход.

Первым делом декларативное определение, например:

Применение на практике сводится к следующему:

Пробую пока покатать-проверить, насколько такой подход применим в условиях, приближенным к боевым. Нужно больше мест применения, чтобы определить какой подход даст лучшую читаемость, компактность и проверяемость. И потихотньку можно добавить мяса.

(далее…)

Простая иллюстрация подхода при передаче параметра  в виде ссылки:

Чего можно таким добиться?

Например: это маленькое ухищрение позволяет однократно указывать обрабатываемую таблицу. Это делает код чуть менее многословным. Альтернатива:

Насколько это красиво? Чисто и просто… Впрочем, есть тут некоторая неочевидность. Мы запускаем метод в классе без указния локальной переменной в качестве параметра, а эта локальная переменная меняется.

Если собирать ошибки внутри вспомогательного класса, а потом их получать вместе, то становится сложнее прекратить обработку немедленно. Выглядит как-то корявенько:

Пример реализации:

(далее…)

Как это часто бывает, есть много разных способов решить одну и ту же задачу. И на этот счет тоже есть варианты:

• Разбирать текст руками или регулярными выражениями:  плохой подход сходу, не обсуждается
• CL_XML_DOCUMENT: классический подход, но несколько муторный на мой вкус
• CALL TRANSFORMATION: стандартный подход, но меня всегда смущает небходимость наличия отдельного артефакта. Кроме того, если работать с этим раз в год, то синтаксис трансформаций выпадает из памяти и необходимо снова обращаться к примерам и/или документации

Новый для меня способ — использовать функциональный модуль SMUM_XML_PARSE, у которого очень простой синтаксис: (далее…)

Дано: есть вывод отчета в ALV, в котором стандартными средствами включен расчет среднего значения.

Итоговое среднее значение стандартно расчитывается так:

( 30 + 40 + 50 + 0 ) / 4 = 30

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

Соответственно от заказчика есть задание: требуется выводить среднее значение, не учитывающее пустые (нулевые) значения:

Один из способов решения задачи — грязно вторгнуться во внутреннюю кухню ALV. Приступим?

(далее…)

Обнаружил за последнее время несколько вещиц разной степени полезности.

RTCM

Транзакция SRTCM — Runtime Check Monitor.

Тут можно активировать пару проверок, которые можно упустить в статических проверках ATC (ABAP Test Cockpit). Одна из них — пустая таблица в FOR ALL ENTRIES.

Пишут, что оверхед не такой большой и можно оставить на несколько недель в продуктивной среде.

Мало ли, вдруг иногда бывает, но никто не знает. А быть такого не должно в обычной жизни.

UPL

Usage & Procedure Logging. Такая штука, которая должна по-хорошему работать через Solution Manager и SAP Custom Code Management. Там много данных и без BW-обвеса, который связан с SM, данные непросто анализировать, особенно не нагружая продуктивную систему.

Однако, при некотором желании его можно подёргать напрямую в системе. Но только в тестовых церях на свой страх и риск. Для этого необходимо запустить программу  /SDF/UPL_CONTROL. Транзакции, видимо, не предусмотрено в виду означенных выше обстоятельств.

Затем требуется подождать какое-то время и вам выпадет ошеломляющее количество инфромации:

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

SQLM

Насчет мониторинга SQL-запросов тоже есть полезные штуки. Прямо так и называется транзакция SQLM, то есть SQL Monitor, легко запомнить.

И если её оставить на какое-то время, то можно получить много полезной информации:

SFW5

В переключателях бизнес-функций SFW5 можно найти кроме всего прочего:

• /SDF/WS_MON (Web Service Monitoring) — может и полезно будет когда-нибудь, но пока не буду активировать, ибо отключить потом нельзя, так как Non-Reversible
• SRIS_SOURCE_SEARCH (ABAP Source Search) — пишут, что активирует построение полнотекстового индекса для исходного кода, однако работает только на HANA. Кроме того, запускать в рабочее время нежелательно, так что на заметку берём, но пока хватит старых инструментов.

PS.

SWLT

SQL Performance Tuning Worklist. А это уже маленькая вишенка на торте, в которой пытаются свести все концы с концами, а именно сопоставляют данные ATC и SQLM. Поэтому новых тайных знаний вы там не найдете, но есть небольшой шанс подхватить инсайт при сопоставлении.

Навеяно предыдущей записью. Не все ещё места хранения файлов исследованы. Например, вполне возможно хранить Excel-файлы в так называемом Business Workplace (транзакция SBWP, доступная всем с главного экрана).

Сохранённый файл можно прочитать из программы примерно таким кодом: (далее…)

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

Есть такой cпособ представления двоичного контента в виде текста: Base64.

Следовательно, любой файл можно представить в виде длинной константы типа string.  Чем больше файл, тем длиннее будет строка символов.

Вот только файл размером 10кб займёт примерно 200 строк текста.

Когда такое может пригодиться?

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

В моём случае инсайт пришёл при работе с Excel-файлом в моём предыдущем посте «Ещё один способ прочитать содержимое Excel-файла». Не всегда есть смысл изобретать какое-то особое место хранения файла, если можно положить файл напрямую в код.