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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Comment (1)

  1. Добрый день!
    в AQO данные также хранятся в JSON (с ним проще работать в sapui5)
    настройки создаются на основе аттрибутов класса или полей структур (так проще для небольших локальных настроек)
    В редакторе (старом и новом) есть поддержка сложных структрур данных
    т.е. в таблицах могут быть строки, range и вложенные таблицы (для которых также можно указать ключ)
    Также есть возможность просмотра предыдущих значений, экспорт и импорт, поиск кода где используется настройка, проверка значений введенных пользователем (когда не достаточно проверочной таблицы указанной в ТАБЛИЦА-ПОЛЕ)
    подробнее написано в документации

Добавить комментарий

Ваш e-mail не будет опубликован.