При администрировании и поддержке большого количества однотипных информационных баз (например, 100 баз 1С:Бухгалтерия предприятия 3.0 в локальной сети) часто возникает задача централизованного управления программным кодом. Переписывать одну и ту же процедуру вручную во всех базах при каждом изменении законодательства или внутренних бизнес-процессов — задача нереальная и приводящая к ошибкам.
Нам необходимо добиться того, чтобы общий код правился в одном месте, а изменения автоматически или полуавтоматически распространялись по всем рабочим базам, даже если сами эти базы имеют локальные отличия. Рассмотрим подробнее несколько эффективных способов решения этой задачи — от классических механизмов платформы 1С до современных DevOps-практик.
Это один из самых надежных и архитектурно правильных способов в экосистеме 1С. Платформа 1С:Предприятие 8 позволяет ставить конфигурацию на поддержку сразу от нескольких поставщиков. При этом типовая конфигурация (например, БП 3.0) остается на поддержке фирмы «1С», а ваши доработки находятся на поддержке вашего собственного «поставщика».
Разберем этот процесс по шагам:
ОбщийМодульИнтеграцияССервисами)..cf). Платформа предложит поставить конфигурацию на поддержку второго поставщика..cfu или .cf) и накатываем его на все 100 баз.Преимущества: Полный контроль над метаданными, стабильность работы, корректная поддержка синтаксического контроля при разработке, стандартный механизм трехстороннего сравнения при обновлениях от фирмы «1С».
Механизм расширений конфигурации (файлы .cfe) идеально подходит для изоляции кастомного кода от типовой конфигурации. Мы можем вынести все общие процедуры в одно расширение.
Главная сложность здесь — как быстро и безболезненно обновить расширение во всех 100 базах. Править вручную в 100 конфигураторах не придется, если автоматизировать этот процесс.
Для автоматизации можно использовать запуск платформы 1С из командной строки. Напишем скрипт автоматического обновления расширения. Команда для пакетной загрузки расширения выглядит следующим образом:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "ПутьКБазе" /N "Администратор" /P "Пароль" /UpdateExtension -Extension "ИмяРасширения" -File "C:\Distr\OurExtension.cfe" /UpdateDBCfg
Проанализируем параметры этой команды:
DESIGNER — запуск в режиме конфигуратора./UpdateExtension — ключ, указывающий на необходимость обновить конкретное расширение.-Extension — имя расширения в метаданных базы.-File — путь к новому файлу расширения (.cfe), который лежит на общем сетевом ресурсе./UpdateDBCfg — обновление конфигурации базы данных.Для массового запуска этого процесса по всем базам отлично подойдет утилита «Обновлятор-1С». В ней есть встроенная возможность пакетного управления расширениями: вы указываете один актуальный файл расширения, список баз, и утилита сама поочередно подключается к базам, завершает сеансы пользователей, делает резервные копии, обновляет расширение и запускает базы обратно.
Если мы не хотим трогать конфигурацию баз и не хотим использовать расширения, которые требуют монопольного доступа для обновления некоторых структур, можно использовать механизм внешних обработок (.epf).
В типовых конфигурациях на базе БСП (Библиотеки Стандартных Подсистем) есть справочник ДополнительныеОтчетыИОбработки. Мы можем хранить наш общий код в процедурах внешней обработки, но как доставлять её обновления в базы?
Рассмотрим вариант автоматического обновления двоичных данных обработки внутри баз при их запуске:
CommonLogic.epf) в общую сетевую папку, доступную всем базам.ДополнительныеОтчетыИОбработки, заменяя хранящиеся там двоичные данные.Пример кода для программного обновления внешней обработки в базе:
СсылкаНаОбработку = Справочники.ДополнительныеОтчетыИОбработки.НайтиПоРеквизиту("ИмяОбъекта", "ОбщиеПроцедурыОбмена");
Если ЗначениеЗаполнено(СсылкаНаОбработку) Тогда
ОбъектОбработки = СсылкаНаОбработку.ПолучитьОбъект();
ДвоичныеДанныеФайла = Новый ДвоичныеДанные("\\server\share\CommonLogic.epf");
ОбъектОбработки.ХранилищеОбработки = Новый ХранилищеЗначения(ДвоичныеДанныеФайла, Новый СжатиеДанных(9));
ОбъектОбработки.Записать();
КонецЕсли;
При таком подходе пользователи даже не заметят процесса обновления, им не придется выходить из системы, а новые алгоритмы начнут работать сразу после перезаписи элемента справочника.
Если в локальной сети есть возможность поднять внутренний веб-сервер, можно применить подход с динамическим получением кода. Это продвинутый аналог схемы «из текстового файла», которая использовалась в 1С 7.7.
Прямой запуск кода «на лету» в 1С 8.3 возможен с использованием функции Выполнить(). Мы можем хранить весь общий алгоритм в виде текстового файла на веб-сервере или в одной «мастер-базе» и получать его по HTTP.
Посмотрим на пример реализации в клиент-серверном коде:
Функция ПолучитьИВыполнитьОбщийКод(ПараметрыАлгоритма) Экспорт
Соединение = Новый HTTPСоединение("192.168.1.100", 80, "User", "Password");
Запрос = Новый HTTPЗапрос("/api/get_code?name=ProcessExcel");
Попытка
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ТекстКода = Ответ.ПолучитьТелоКакСтроку();
// В переменной ТекстКода находится BSL-код
Выполнить(ТекстКода);
Иначе
ВызватьИсключение "Ошибка получения общего кода с сервера!";
КонецЕсли;
Исключение
ЗаписатьЛогОшибки(ОписаниеОшибки());
КонецПопытки;
КонецФункции
Важно: Данный метод следует использовать с осторожностью, так как использование Выполнить() усложняет отладку программного кода и накладывает ограничения на использование локальных переменных (все параметры нужно передавать через структуру или объявлять их глобально внутри контекста исполнения).
Если базы сильно отличаются друг от друга на уровне метаданных, но выполняют схожие операции (например, загрузка файлов Excel разной структуры, их валидация и формирование документов), имеет смысл вообще убрать сложную бизнес-логику из 100 локальных баз.
Вместо распространения кода мы можем создать одну мастер-базу (или центральный сервис), которая будет предоставлять HTTP-сервисы для остальных баз.
Схема взаимодействия выглядит так:
Этот подход полностью решает проблему версионирования кода. Локальные базы становятся «тонкими клиентами» для ваших общих алгоритмов, а вся логика централизуется на одном сервере.
Выбор конкретного метода зависит от квалификации команды разработки и инфраструктурных возможностей вашей сети: