Часто в практике разработки под 1С возникает ситуация, когда имеется множество информационных баз (например, «1С:Бухгалтерия 3.0»), и в каждой из них дублируется один и тот же программный код. Например, при проведении документов должна выполняться определенная процедура, которая сейчас написана в модуле документа каждой отдельной базы. Возникает логичное желание: вынести этот код в одно место, чтобы менять и обновлять его централизованно, а не переписывать вручную в десятках баз. Разберем эту задачу подробно и проанализируем все возможные способы ее решения.
Рассмотрим самый простой и быстрый в реализации метод. Суть заключается в том, чтобы вынести общий код в модуль объекта внешней обработки.
.epf), в модуле объекта которой прописываем все необходимые экспортные процедуры.ПутьКОбщейОбработке), где храним полный путь к этому файлу.Пример программного вызова:
ПутьКФайлу = Константы.ПутьКОбщейОбработке.Получить();
ОбщаяОбработка = ВнешниеОбработки.Создать(ПутьКФайлу);
ОбщаяОбработка.ВыполнитьДействиеПриПроведении(ТекущийОбъект);
Плюсы: Изменив файл один раз в сетевой папке, мы мгновенно применяем новую логику для всех баз.
Минусы: Необходимо следить за правами доступа к папке, а также за тем, чтобы файл не был заблокирован при попытке его перезаписи.
Посмотрим на более надежный вариант предыдущего способа. Вместо сетевой папки можно загрузить внешнюю обработку напрямую в базу, используя стандартную подсистему БСП (справочник ДополнительныеОтчетыИОбработки).
В этом случае обработка хранится непосредственно в базе. Однако, чтобы не обновлять ее руками везде, вам потребуется написать небольшой скрипт или регламентное задание, которое будет обходить все базы через COM-соединение или HTTP-сервисы и обновлять двоичные данные обработки в справочнике при выходе новой версии. Это потребует чуть больше времени на настройку, но избавит от проблем с доступом к сетевым каталогам.
Разберем архитектурный подход, при котором код физически исполняется только в одной «центральной» базе, а все остальные базы обращаются к ней за результатом.
Ограничение: Как справедливо отмечают специалисты, при проведении документов часто требуется обрабатывать не только примитивные типы данных, но и сложные коллекции (ссылки, наборы записей). Сериализация таких данных для передачи через веб-сервис может оказаться слишком ресурсоемкой и сложной в реализации.
Проанализируем самый правильный путь для современных конфигураций на платформе 1С:Предприятие 8.3 — использование расширений (файлы .cfe).
Вы создаете общий модуль с нужными экспортными процедурами (например, ОбщийМодульПроведения) внутри расширения. Затем это расширение подключается ко всем базам. При этом сами конфигурации баз не снимаются с поддержки.
Если баз много, вам не нужно заходить в конфигуратор каждой из них. Вы можете автоматизировать процесс с помощью скриптов командной строки (пакетный запуск конфигуратора). Скрипт может автоматически пройти по списку баз и обновить расширение одной командой:
1cv8.exe DESIGNER /S "Server\Base" /N "Admin" /P "Pass" /LoadExtension "C:\Path\MyExt.cfe" /UpdateDBCfg
Выясним, как фирма 1С рекомендует управлять общим кодом. На этом принципе построена «Библиотека стандартных подсистем» (БСП). Вы можете вынести общий функционал в отдельную конфигурацию-библиотеку. Далее эта библиотека ставится на поддержку во все ваши рабочие базы.
Когда требуется изменить алгоритм, вы меняете его в библиотеке, выпускаете файл обновления .cfu или .cf и накатываете его на все базы стандартным механизмом обновления.
Также можно использовать Хранилище конфигурации. Если все базы идентичны по структуре, они могут быть подключены к одному хранилищу. Изменяя процедуру в хранилище, вы легко получаете обновления во всех подключенных базах.
Посмотрим на классический, хотя и устаревающий метод. Если все базы находятся в одной локальной сети под управлением ОС Windows, вы можете использовать COM-соединение. Из любой базы можно программно подключиться к одной главной базе и напрямую вызывать функции из ее глобальных или серверных общих модулей.
Коннектор = Новый COMObject("V83.COMConnector");
Соединение = Коннектор.Connect("Srvr=""ServerName"";Ref=""CentralBase"";Usr=""Admin"";Pwd=""123"";");
// Вызов экспортной процедуры из общего модуля центральной базы
Результат = Соединение.МойОбщийМодуль.РассчитатьДанные(Параметр1);
Минусы: Метод работает медленнее HTTP-сервисов, зависит от Windows и требует строгой синхронизации версий платформы 1С на клиенте и сервере.
Рассмотрим продвинутый уровень организации работы. Если разработка ведется активно, код общих модулей или расширений переводится в среду 1C:Enterprise Development Tools (EDT) и хранится в системе контроля версий Git.
С помощью инструментов автоматизации (например, скриптов на OneScript или Jenkins/GitLab CI) настраивается непрерывный конвейер. Как только программист вносит правки в общую процедуру и делает коммит в ветку main, сервер автоматизации самостоятельно собирает файл расширения или конфигурации и раскатывает его по всем целевым базам без участия человека.
Выбор конкретного метода зависит от архитектуры вашей сети и характера передаваемых данных. Если вам нужно передавать сложные объекты, лучше использовать Расширения конфигурации с пакетным обновлением или внешнюю обработку в сетевой папке. Если логика простая и может работать асинхронно, отлично подойдут HTTP-сервисы. Для сложных инфраструктур с десятками баз стоит смотреть в сторону CI/CD и Git.