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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первым делом — необходимо настроить настроечную таблицу для хранения настроек, которую может настроить впоследствии разработчик, чтобы хранить там настраиваемый объект настройки для консультанта, который хочет настраивать настройки без него. Понятно?

Таблица ZCA_OPTIONS_CUST — атрибуты настройки

Классическая таблица с генератором ведения, решил что стоит выделить пакет отдельно, так как всё равно будет требоваться некоторый name convention, который всё равно будет выполнен в стиле:
ключ-объекта = пакет-префикс + имя-настройки.

DEVCLASS — Пакет
NAME — Наименование настройки
DESCRIPTION — Описание настройки
DATATYPE — Имя объекта ABAP-словаря
CUSTOMIZING — Настройка (флаг)
OBLIGATORY — Обязательно (флаг)
ACTIVE — Активно (флаг)

Таблица ZCA_OPTIONS — хранилище настроек

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

В качестве эксперимента я выбрал JSON.

MANDT — Мандант
DEVCLASS — Пакет
NAME — Наименование настройки
VALUE — Значение настройки (JSON-string)
CPUDT — Дата ввода
CPUTM — Время ввода
UNAME — Имя пользователя

API для доступа

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

Под капотом у этого метода очень простая десериализация:

Осталось самое вкусное, надо написать транзакцию по управлению настройками. На текущий момент она выглядит вот так:

Такс, я ушёл устанавливать abapGit, подключать GitHub. А вы, дорогие мои, пишите. А если я ушёл надолго, тем более пишите.