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

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

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

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

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

Вторым уровнем может возникнуть классическая настроечная таблица + сгенерированное ведение в транзакции 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. А вы, дорогие мои, пишите. А если я ушёл надолго, тем более пишите.