Сбор данных в 1С из удаленно расположенных файлов XLS

· Обновлено: 26.07.2026
#project

Обратился заказчик с проблемой "Как в 1С собирать данные с технологического оборудования которое расположено на разных производственных территориях?" Каждые 10 минут, притом что оборудование каждый день создает новый файл и в него каждые 10 минут дополняет данные.


Исходные условия:

Более десяти удалённых производственных точек с динамическими IP формируют в C:\Export ежедневные файлы вида export_data_ДД_ММ_ГГГГ_ИмяТочки.xls. Файл дополняется примерно каждые 10 минут. Центральный Debian 13 имеет публичный адрес, а Windows Server 2022 запускает сервер 1С.

Цель — доставлять целостные версии файлов, сохранять версии за прошлые дни при сетевых сбоях и предоставлять 1С контролируемый доступ только для чтения.


Реализация:

Решение написать пару powershell и bash скриптов которые запускаются по расписанию и выполняют необходимые действия


Схема решения:


 Производственная точка (Windows)
├─ поиск всех файлов своей точки, а не только текущей даты
├─ проверка стабильности размера и LastWriteTimeUtc
├─ локальная staging-копия + SHA-256
├─ SFTP: уникальный пользователь и ключ, проверенный host key
└─ upload *.part → SFTP rename → *.ready
│ исходящее SSH, TCP 2222
▼
Debian 13
├─ OpenSSH internal-sftp, без shell и forwarding
├─ chroot и incoming-каталог отдельно для каждой точки
├─ publisher: проверка владельца, имени, типа и размера
├─ атомарный rename в /srv/factory-data/export
├─ архив /srv/factory-data/archive/YYYY/MM/DD
└─ Samba: export только для чтения и только с IP сервера импорта
│ SMB TCP 445
▼
Windows Server 2022
├─ отдельная служебная учётная запись импорта
├─ чтение \\debian\export и копирование на локальный диск
└─ 1С обрабатывает локальную входящую папку


Самое интересное:


Поток данных и атомарность:

  1. Клиент сканирует все файлы, имя которых соответствует его точке. Поэтому файл за вчера или более ранний период не теряется после полуночи.
  2. Размер и время изменения сравниваются дважды с паузой. Затем создаётся отдельная staging-копия; передаётся именно она.
  3. Копия получает SHA-256. Клиент пропускает только версии, чей хеш уже успешно отправлялся.
  4. Файл загружается по SFTP с уникальным именем исходное-имя.хеш.part. После успешной загрузки SFTP-команда rename меняет суффикс на .ready.
  5. Publisher принимает только строго допустимый шаблон для каталога конкретной точки. Каноническое имя восстанавливается из проверенного имени.
  6. incoming, export и archive находятся на одной файловой системе. Перемещение в export выполняется через rename(2), поэтому потребитель не видит частичный файл.


Модель отказов:

  1. Нет сети или сервер недоступен: исходные файлы остаются на точке; следующий запуск повторно найдёт неотправленные хеши.
  2. Обрыв загрузки: остаётся только .part, publisher его не читает; устаревшие части удаляются регламентно.
  3. Сбой после rename в ready: publisher обработает файл на следующем запуске.
  4. Сбой publisher: готовые файлы накапливаются изолированно; сигнал мониторинга сообщает об очереди.
  5. Компрометация ключа точки: злоумышленник ограничен chroot-каталогом этой точки; ключ и пользователя можно независимо отключить.
  6. Недоступна Samba: опубликованные и архивные данные сохраняются; локальный импорт повторяется после восстановления.


Эксплуатация и масштабирование:

  1. Запуски точек распределяются по минутам или получают случайную задержку, чтобы исключить пиковую нагрузку.
  2. Планировщик не запускает второй экземпляр задачи; скрипт дополнительно применяет именованный Mutex.
  3. Каждая новая точка получает отдельные Linux-пользователя, chroot, ключ, имя и запись в конфигурации publisher.
  4. Отзыв точки: заблокировать пользователя, удалить/отозвать ключ, сохранить журнал и данные согласно регламенту.
  5. Обновления сначала проверяются на тестовой точке, включая обрыв передачи, смену суток и восстановление из архива.
Поделиться: