При разработке новых прикладных решений в 1С часто возникает задача прикрепления к документам внешних файлов. Это могут быть сканы договоров, коммерческие предложения, технические задания или, как в случае с тендерной документацией, целый пакет входящих и исходящих документов. Перед разработчиком встает важная архитектурная дилемма: как организовать хранение этих файлов эффективно, безопасно и без вреда для производительности системы. Разберем эту тему детально.
Рассмотрим три основных подхода к организации файлового хранилища в экосистеме 1С, их достоинства и недостатки.
Вариант А. Хранение непосредственно в СУБД (в самой базе данных)
В этом случае файлы записываются в базу данных в виде двоичных данных через объект ХранилищеЗначения.
Вариант Б. Хранение в томах на диске (сетевых каталогах)
База данных хранит лишь ссылки на файлы и метаданные, а сами файлы физически располагаются в специально выделенном сетевом каталоге.
Вариант В. Использование объектного хранилища (S3-совместимые облака)
Это современный стандарт для крупных систем. Файлы отправляются в облачные или локальные S3-хранилища (MinIO, Yandex Object Storage) через API.
Если в вашей конфигурации установлена Библиотека Стандартных Подсистем (БСП), крайне не рекомендуется изобретать велосипед. Проанализируем по шагам процесс интеграции подсистемы работы с файлами для нового документа (например, Тендер).
_ДемоДокументыПрисоединенныеФайлы (или любой аналогичный из БСП) и переименовываем его в ТендерПрисоединенныеФайлы.ВладелецФайла и меняем его тип на ДокументСсылка.Тендер.ПрисоединенныйФайл и добавляем туда наш новый справочник СправочникСсылка.ТендерПрисоединенныеФайлы.ПрисоединенныйФайлОбъект добавляем СправочникОбъект.ТендерПрисоединенныеФайлы.ВладелецПрисоединенныхФайлов добавляем ссылку на наш документ ДокументСсылка.Тендер.ТендерПрисоединенныеФайлы в качестве источника для подписок БСП:
ПереопределитьПолучаемуюФормуПрисоединенногоФайла (отвечает за интерфейс работы с файлом).УстановитьПометкуУдаленияПрисоединенныхФайловДокументов (чтобы при удалении документа удалялись и файлы).Если мы приняли решение хранить файлы на диске, важно заранее предотвратить несколько серьезных проблем администрирования.
Проблема прав доступа. На серверах под управлением Windows путь к файлам чаще всего указывается в формате UNC (например, \\server-storage\1c_files). Важно помнить: доступ к этой папке на чтение и запись должен быть открыт именно для той учетной записи, от имени которой запущена служба сервера 1С:Предприятие (обычно это локальный пользователь usr1cv8 или доменная учетная запись службы). Доступ обычных пользователей к этой папке напрямую через проводник Windows должен быть закрыт в целях безопасности.
Опасность повреждения данных при создании копий базы (Тест-баз). Это классическая ошибка разработчиков и администраторов. Когда рабочую базу копируют на тестовый сервер для отладки, пути к томам файлов в справочнике ТомаХраненияФайлов остаются рабочими! Если разработчик или тестировщик в тестовой базе добавит, изменит или удалит файл, эти изменения физически произойдут в рабочем каталоге, что приведет к безвозвратной потере или повреждению реальных коммерческих файлов на проде.
Выясним, как решить эту проблему программно. При создании тестовой базы или при ее первом запуске необходимо принудительно очищать или изменять пути к томам на тестовые папки. Реализуем пример кода для обработки запуска базы:
Процедура ПриПервомЗапускеТестовойБазы() Экспорт
// Проверим, что имя сервера соответствует тестовому окружению
ПараметрыСоединения = СтрокаСоединенияИнформационнойБазы();
ИмяСервера = ВРег(ПараметрыСоединения);
Если Найти(ИмяСервера, "TEST-SRV") > 0 Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Тома.Ссылка КАК Ссылка,
| Тома.ПолныйПутьWindows КАК ПолныйПутьWindows,
| Тома.ПолныйПутьLinux КАК ПолныйПутьLinux
|ИЗ
| Справочник.ТомаХраненияФайлов КАК Тома";
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектТома = Выборка.Ссылка.ПолучитьОбъект();
// Подменяем пути на безопасные локальные папки тестового сервера
ОбъектТома.ПолныйПутьWindows = "D:\1C_Files_Test_Volume\" + ОбъектТома.Код + "\";
ОбъектТома.ПолныйПутьLinux = "/opt/1c_files_test_volume/" + ОбъектТома.Код + "/";
Попытка
ОбъектТома.Записать();
ЗаписьЖурналаРегистрации("Файлы.ИзменениеТомов", УровеньЖурналаРегистрации.Информация, , ,
"Путь к тому " + ОбъектТома.Наименование + " успешно изменен на тестовый.");
Исключение
ЗаписьЖурналаРегистрации("Файлы.ИзменениеТомов", УровеньЖурналаРегистрации.Ошибка, , ,
"Ошибка изменения пути к тому: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Если по каким-то причинам в конфигурации нет БСП и приходится разрабатывать механизм с нуля, на форумах часто возникает спор: где хранить метаданные файлов — в справочнике или в регистре сведений? Разберем аргументы в пользу Справочника, так как этот вариант архитектурно гораздо предпочтительнее.
ВерсииФайлов. В регистре сведений ведение версий приведет к перегрузке ключевых полей и ухудшению производительности при выборке актуальных версий.Файлы, предотвращая одновременное изменение файла другим сотрудником. С записями регистра сведений реализовать надежную объектную блокировку стандартными методами платформы невозможно.Также важно учесть практический совет опытных разработчиков: обязательно ограничивайте максимальную длину имени загружаемого файла на уровне интерфейса. Пользователи часто пытаются назвать файл целым абзацем текста, что при записи на диск в тома (где к имени файла добавляется длинный путь каталога) может превысить системное ограничение операционной системы в 260 символов и вызвать критическую ошибку записи.