Немного NoSQL или что-то взамен SM30

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LOOP AT SCREEN, работа с экраном – новая идея

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

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

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

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

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

(далее…)

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

Раннее утро. Птички чирикают.

Сижу, никого не трогаю, читаю утреннюю газету.

SAP вещает:

сморите как всё было плохо, какое всё разное, инконсистенси, то да сё,  фу-фу-фу

вот мы вам сделаем Fiori 3, там будет всё такое консистентное, прям ух-ты-красота

современные технологии, двадцать первый век, а о цене давайте не будем говорить

И неожиданно нахлынуло чувство какой-то органичной целостности этого мира.
(далее…)

Телега впереди лошади

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

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

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

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

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

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

(далее…)

Достигая невозможного, пьеса

Все события и герои вымышлены. Любые совпадения с реальными личностями случайны.

Акт первый

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

Старый фрилансер: Ну дело житейское, разработчика своего попросите.

Консультант: Мы спрашивали, но он сказал, что это невозможно.

Старый фрилансер: Поверь мне, милая, если разработчик говорит, что нечто невозможно, то это значит, что он ленивая жопа.

Консультант: Посмотри, пожалуйста!

Старый фрилансер: Не вопрос, но задачку-то поставь. (далее…)

Быстрый способ получить данные из XML-файла

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

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

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

Грязные трюки при работе с ALV

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

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

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

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

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

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

(далее…)

RTCM, UPL, SQLM и всё такое про мониторинг ABAP-систем

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

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. Поэтому новых тайных знаний вы там не найдете, но есть небольшой шанс подхватить инсайт при сопоставлении.

Ещё одно место для хранения файлов – SBWP

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

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

Ещё один способ работы с файлами – теперь Base64

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

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

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

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

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

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

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