Где и как вы храните настройки сервисных обработок?
Всем привет! Вопрос, наверное, в первую очередь у тем кто дорабатывает созданные с нуля или типовые базы под нужды предприятия. К примеру, у нас есть много различных выгрузок\загрузок\интеграции с различными сервисами. Для каждого из этих сервисов нужно где-то хранить настройки: параметры подключения, логины, пароли, токены, имена серверов, порты итд и итп. И тут возникает вопрос: где это всё хранить?
Возникает несколько вариантов:
1. Захардкодить - такой вариант имеет кучу недостатков в виде полной потери возможности настройки и изменения со стороны пользователя, а также опасность получить другую ссылку на элемент, если у неё поменялся код или наименование, в случае если она ищется по коду или наименованию. Плюс только в том, что быстро и не надо задумываться, где хранить;
2. Хранить в константах - плюсом, наверное, будет являться то, что такие параметры удобно получать, минусы - плодиться очень много различных констант в дереве, нужно описывать каждую константу отдельно (спорный минус);
3. ПВХ с предопределенными элементами и РС для хранения значений - кажется, что хороший вариант, если грамотно написать унифицированный механизм добавления и установки параметров, то видится отличным решением.
4. Хранилище настроек - плюсы: не надо описывать метаданные, но нужно писать формы и механизмы для сохранения и чтения параметров из хранилища. Минусы: кто-то может случайно очистить хранилище, и владелец механизма может об этом не сразу узнать (если конечно не сделать дополнительные проверки), "не ощущается надежность хранения".
Коллеги, какие у вас мысли на этот счет. Какой вариант вы бы выбрали и почему или предложите другой вариант и поделитесь своим опытом.
Возникает несколько вариантов:
1. Захардкодить - такой вариант имеет кучу недостатков в виде полной потери возможности настройки и изменения со стороны пользователя, а также опасность получить другую ссылку на элемент, если у неё поменялся код или наименование, в случае если она ищется по коду или наименованию. Плюс только в том, что быстро и не надо задумываться, где хранить;
2. Хранить в константах - плюсом, наверное, будет являться то, что такие параметры удобно получать, минусы - плодиться очень много различных констант в дереве, нужно описывать каждую константу отдельно (спорный минус);
3. ПВХ с предопределенными элементами и РС для хранения значений - кажется, что хороший вариант, если грамотно написать унифицированный механизм добавления и установки параметров, то видится отличным решением.
4. Хранилище настроек - плюсы: не надо описывать метаданные, но нужно писать формы и механизмы для сохранения и чтения параметров из хранилища. Минусы: кто-то может случайно очистить хранилище, и владелец механизма может об этом не сразу узнать (если конечно не сделать дополнительные проверки), "не ощущается надежность хранения".
Коллеги, какие у вас мысли на этот счет. Какой вариант вы бы выбрали и почему или предложите другой вариант и поделитесь своим опытом.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
а у нас все варианты, часть настроек храниться в константах. тупо потому что баз по одной конфигурации несколько, а подключаться они иногда должны к друг другу или веселее к доп базам, но каждая к своей.
Есть справочники настроек, обычно это внешние сервисы, к которым надо иногда менять настройки, но там не только подключения, но и специфика разная, типа настройки по складам группам и тд тп.
Есть в хранилище. один из программистов решил что так круче, но это на 8.3 и очень ограниченный набор обработок.
Встречала настройки и в РС. но они уже не юзаются, ну просто тот сервис отвалился, а такой механизм больше не используется.
По первому скажу плюс в том, что пишешь одну обработку на несколько баз, а так как структура конфигураций одинакова, а данных различна, то константы просто рай. Быстро. но меняем мы их редко. Очень редко (зато весело вспоминать когда админ решил сервера переименовать) .
а у нас все варианты, часть настроек храниться в константах. тупо потому что баз по одной конфигурации несколько, а подключаться они иногда должны к друг другу или веселее к доп базам, но каждая к своей.
Есть справочники настроек, обычно это внешние сервисы, к которым надо иногда менять настройки, но там не только подключения, но и специфика разная, типа настройки по складам группам и тд тп.
Есть в хранилище. один из программистов решил что так круче, но это на 8.3 и очень ограниченный набор обработок.
Встречала настройки и в РС. но они уже не юзаются, ну просто тот сервис отвалился, а такой механизм больше не используется.
По первому скажу плюс в том, что пишешь одну обработку на несколько баз, а так как структура конфигураций одинакова, а данных различна, то константы просто рай. Быстро. но меняем мы их редко. Очень редко (зато весело вспоминать когда админ решил сервера переименовать) .
(5)
Можете подробнее описать структуру справочника? Значения у вас там предопределенные все?
Есть справочники настроек, обычно это внешние сервисы, к которым надо иногда менять настройки, но там не только подключения, но и специфика разная, типа настройки по складам группам и тд тп.
Можете подробнее описать структуру справочника? Значения у вас там предопределенные все?
(7)
всмысле предопределенные? а смысл тогда в справочнике.?
Ну вот есть выгрузка в систему автоматического расчета потребности товарного запаса. Там под каждый склад своя настройка. Есть данные по подключению, они только для роли администратора доступны, просто строка так как данные на фтп скидываются. А дальше данные по настройкам самой выгрузки, склады, типы цен, группы номенклатуры, подразделения и тд.
Есть более сложный справочник на несколько обменов. Там только адреса подключения и организация указывается, а обработке просто прописывается уже предопределенный элемент справочника, хотя в последний раз создали уже внутри системы и поиск по коду. Ну и ограничение к таким справочникам по ролям "Разработчик"
жете подробнее описать структуру справочника? Значения у вас там предопределенные вс
всмысле предопределенные? а смысл тогда в справочнике.?
Ну вот есть выгрузка в систему автоматического расчета потребности товарного запаса. Там под каждый склад своя настройка. Есть данные по подключению, они только для роли администратора доступны, просто строка так как данные на фтп скидываются. А дальше данные по настройкам самой выгрузки, склады, типы цен, группы номенклатуры, подразделения и тд.
Есть более сложный справочник на несколько обменов. Там только адреса подключения и организация указывается, а обработке просто прописывается уже предопределенный элемент справочника, хотя в последний раз создали уже внутри системы и поиск по коду. Ну и ограничение к таким справочникам по ролям "Разработчик"
(8) Ну допустим мы храним в справочнике различные параметры различных типов, например логин, пароль, адрес фтп сервера, это три элемента справочника параметры, потом нам нужно отбор по подразделению или складу в какой-то обработке. Что я должен написать в коде чтобы получать эти параметры? ИСкать по наименованию, коду? Ещё как-то. Если они будут предопределенные, я могу ссылаться на них в коде и получать их значения
Зависит от характера настроек.
Настройки всяких там подключений - в справочнике.
Всякое сильно специфичное обычно делаю так: отдельная закладка с настройками в обработке, которая первоначально заполняется по захардкоженным элементам (если нет возможности их сделать предопределенными), а потом - штатно сохраняются/восстанавливаются через хранилище настроек. То есть пользователь в любой момент может зайти в настройки, что-то там поменять и продолжать работу с уже новыми настройками.
Настройки всяких там подключений - в справочнике.
Всякое сильно специфичное обычно делаю так: отдельная закладка с настройками в обработке, которая первоначально заполняется по захардкоженным элементам (если нет возможности их сделать предопределенными), а потом - штатно сохраняются/восстанавливаются через хранилище настроек. То есть пользователь в любой момент может зайти в настройки, что-то там поменять и продолжать работу с уже новыми настройками.
Храню в данных формы обработки, так как не требуется программная обработка сохранения и загрузки при интерактивной работе. При не интерактивной работе беру эти данные из ХранилищеСистемныхНастроек. С озвученными минусами согласен.
Отбор = Новый Структура;
Отбор.Вставить("Пользователь", ИмяПользователя());
Отбор.Вставить("КлючОбъекта", "ВнешняяОбработка.ЗагрузкаДанныхИзУТвБП.Форма.Форма/ТекущиеДанные");
Выборка = ХранилищеСистемныхНастроек.Выбрать(Отбор);
Если Не Выборка.Следующий() Тогда
Возврат
КонецЕсли;
ИсточникиДанных = Выборка.Настройки["ИсточникиДанных"]; Показать
Если использовать типовой механизм БСП и добавлять обработки в справочник, то можно использовать БСПшный механизм хранения настроек в самом объекте ДополнительныеОтчетыИОбработки, в реквизите ХранилищеНастроек (тип ХранилищеЗначения).
Пример использования:
Остаётся только сделать свою форму по сохранению настроек.
Если коротко, то на форме делается обязательный параметр ДополнительнаяОбработкаСсылка, в который БСП помещает ссылку на обработку, а дальше всё в ваших руках.
Пример использования:
Процедура ВыполнитьКоманду(ИдентификаторКоманды, ПараметрыВыполнения) Экспорт
МойПараметр = ОбщегоНазначенияКлиентСервер.СвойствоСтруктуры(ПараметрыВыполнения, "МойПараметр");
КонецПроцедурыОстаётся только сделать свою форму по сохранению настроек.
Если коротко, то на форме делается обязательный параметр ДополнительнаяОбработкаСсылка, в который БСП помещает ссылку на обработку, а дальше всё в ваших руках.
(11) там бсп только для создания кнопок и регламентнных заданий ( это вобще такой универсальный комбайн для всего )
думаю можно просто вытащить оттуда код формы и сохранения параметров если хранилише значения устраивает
если такой вариант не нравится и есть возможность править конфигурацию то можно сделать связку справочник + пвх , в справочнике изначально сделать несколько предопределенных значений
это удобно например где то в запросе использовать
см рис
если такое тоже не подходит ( например настройки расширения как то хранить ) думаю можно сделать на регистре сведений + частично захардкодить через программное перечисление
см рис
думаю можно просто вытащить оттуда код формы и сохранения параметров если хранилише значения устраивает
если такой вариант не нравится и есть возможность править конфигурацию то можно сделать связку справочник + пвх , в справочнике изначально сделать несколько предопределенных значений
это удобно например где то в запросе использовать
см рис
если такое тоже не подходит ( например настройки расширения как то хранить ) думаю можно сделать на регистре сведений + частично захардкодить через программное перечисление
см рис
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот