Подсистема работы с файлами в нетиповой конфигурации 1С

Файлы в прикладном решении 1С быстро перестают быть обычным реквизитом документа. К карточке клиента, заказу, договору или обращению приходится прикреплять несколько версий документов, изображения, сканы и результаты обмена с внешними системами. В нетиповой конфигурации такую возможность лучше проектировать как отдельную подсистему, не связывая хранение данных с конкретным объектом.

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

Архитектура решения

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

В нетиповой конфигурации обычно создают общий модуль сервера для операций с файлами и общий модуль клиентского приложения для интерактивных действий. В серверном модуле размещают проверку прав, сохранение, удаление, получение содержимого и журналирование. Клиентский код не должен самостоятельно определять доступ или напрямую управлять внутренним хранилищем.

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

Модель данных и связи

Чаще всего создают справочник «Файлы» с реквизитами «Наименование», «Расширение», «Размер», «ДатаЗагрузки», «Автор», «КонтрольнаяСумма», «Версия» и «Состояние». Двоичные данные можно хранить в реквизите типа «ХранилищеЗначения», а при большом объеме — вынести во внешний каталог или файловое хранилище.

Связь с прикладными объектами реализуют несколькими способами. Для небольшого решения подойдет регистр сведений с измерениями «Владелец» и «Файл». Если один файл может относиться к нескольким объектам, лучше использовать отдельный регистр связи. В качестве владельца можно хранить составной идентификатор или универсальную ссылку, но второй вариант требует аккуратной обработки разных типов объектов.

Версии не стоит перезаписывать без необходимости. Новая загрузка должна создавать отдельную запись либо новую версию файла с указанием автора и даты. Это позволяет восстановить предыдущий вариант и определить, какой документ использовался при проведении операции.

Загрузка через клиентское приложение

В управляемом приложении пользователь выбирает файл на клиенте, после чего данные передаются на сервер через временное хранилище. Для этого применяют штатные процедуры работы с файлами, включая выбор файла, помещение во временное хранилище и последующее чтение серверной процедурой. Такой подход безопаснее прямого обращения серверного кода к локальному диску пользователя.

До записи следует проверить расширение, фактический размер, имя и допустимый MIME-тип. Нельзя полагаться только на расширение: файл с именем изображения может содержать исполняемый код. Для офисных форматов и архивов желательно применять антивирусную проверку, особенно если файлы поступают от внешних пользователей или через веб-сервис.

На форме документа удобно разместить динамический список вложений с командами «Добавить», «Открыть», «Скачать», «Изменить описание» и «Удалить». Для крупных файлов стоит показывать состояние операции и не блокировать интерфейс на длительное время. При ошибке передачи пользователь должен получить понятное сообщение, а временное содержимое — быть удалено.

Хранение и производительность

ХранилищеЗначения удобно для первых версий продукта и умеренного количества вложений. Оно упрощает резервное копирование и перенос информационной базы, но увеличивает размер базы, нагрузку на СУБД и время резервного копирования. Массовая загрузка сканов, фотографий или архивов быстро выявляет эти ограничения.

Внешнее файловое хранилище снижает объем базы, однако требует отдельной стратегии резервного копирования, контроля доступности каталога и защиты сетевых ресурсов. В базе при этом сохраняют путь, уникальный идентификатор или ключ объекта, а не произвольное имя файла. Для распределенных сценариев предпочтительнее объектное хранилище с API и контролем прав.

Открытие вложения не должно каждый раз передавать весь набор данных формы. Список следует получать постранично или ограничивать отбором, а содержимое загружать только по команде пользователя. Индексы регистра связи должны соответствовать основным запросам: по владельцу, файлу и дате добавления.

Права и надежность

Разрешения на вложения должны опираться на права владельца. Пользователь, имеющий доступ к документу, не всегда должен автоматически получать возможность удалить или заменить файл. Для этого выделяют отдельные роли: просмотр, добавление, редактирование, удаление и управление версиями.

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

Операции загрузки нужно выполнять с обработкой исключений и контролем транзакций. Если метаданные записались, а двоичное содержимое не сохранилось, система не должна оставлять «пустое» вложение. Для каждого файла полезно рассчитывать контрольную сумму: она помогает обнаруживать повреждения и не загружать повторно одинаковые данные.

Интеграция и проверка решения

Если подсистема участвует в обмене с сайтом, CRM или системой электронного документооборота, заранее определяют формат передачи: Base64, multipart-запрос или ссылка на объектное хранилище. В обмене передают идентификатор, имя, размер, контрольную сумму и версию. Ограничения веб-сервиса должны учитывать тайм-ауты и повторную отправку после сетевой ошибки.

Перед выпуском проверяют сценарии нескольких пользователей, одновременную загрузку, недоступность хранилища, повторную отправку и восстановление из резервной копии. Отдельно тестируют права на просмотр и удаление, файлы с одинаковыми именами, запрещенные расширения, нулевой размер и превышение лимита.

Реализацию лучше выполнять поэтапно: сначала определить модель данных и правила доступа, затем сделать серверный API, после этого подключить формы и обмены. Такой порядок уменьшает количество переделок и позволяет безопасно встроить подсистему в существующую нетиповую конфигурацию.

Используйте обсуждения профессионального сообщества 1С, публикации по разработке и примеры интеграций, чтобы сравнить варианты хранения и выбрать подходящую архитектуру. Практические наработки можно адаптировать под конкретную конфигурацию, а учетные и бизнес-процессы дополнить средствами KUBiK.