Сотрудники регулярно открывают входящую папку, ищут новые документы и вручную переносят их дальше. В таком процессе легко пропустить поступление, повторно обработать один файл или потерять связь между исходником и результатом.
Автоматизация начинается не с наблюдения за каталогом, а с правил: какой файл считать готовым, как распознать повтор, что проверять и когда фиксировать успешный результат. Ниже — схема требований для локальной или сетевой папки. Она не относится к Google Drive, электронной почте, 1С или корпоративному архиву.
Где начинается и заканчивается обработка входящей папки
Сначала определите границы процесса:
- Кто или какая система помещает файл в каталог.
- Какая папка считается входящей.
- По какому признаку файл готов к чтению.
- Какой подтверждённый результат завершает обработку.
Локальная папка находится на той же машине, где работает процесс. Сетевой ресурс расположен отдельно и должен быть доступен машине или контейнеру с нужными правами. Каталог внутри контейнера — ещё одна файловая среда: путь в контейнере не означает автоматического доступа к одноимённому пути на сервере.
Событие файловой системы сообщает, что объект добавили, изменили или удалили. Оно само по себе не доказывает, что запись завершилась, файл корректен, а следующая система приняла результат. Поэтому обнаружение — начало обработки, а не её успешный итог.
Полезная граница выглядит так: процесс начинается после появления готового файла и заканчивается после подтверждения от принимающей стороны либо после передачи исключения ответственному сотруднику.
Как описать правила приёма файлов
До разработки зафиксируйте:
- разрешённые каталоги и допустимую глубину вложенности;
- ожидаемые расширения и схему имени;
- источник каждого типа файлов;
- обоснованное ограничение размера, если оно нужно;
- порядок работы с временными и частично записанными файлами;
- признак завершения записи.
Признаком готовности может быть атомарное перемещение из промежуточного каталога, отдельный файл-маркер или стабильность согласованных свойств в течение заданного интервала. Ни один вариант не универсален: правило выбирают с учётом того, как источник записывает файлы, а затем проверяют в рабочей среде.
По актуальной документации узел Local File Trigger в n8n может запускать workflow при добавлении, изменении или удалении файла либо папки. Для него задают наблюдаемый путь и тип изменения. Документация подтверждает техническое событие, но не готовность содержимого к обработке.
Фильтры, временной интервал, допустимый размер и правило готовности — требования конкретного будущего решения. Их нельзя выводить только из возможностей узла.
Как прочитать файл и учесть размещение системы
После события процесс должен получить содержимое файла. Узел Read/Write Files from Disk читает и записывает файлы на машине, где запущен n8n. Доступность пути зависит от способа размещения и прав процесса.
При самостоятельном размещении n8n нужно проверить фактический путь, владельца каталога и разрешённые операции. Начиная с n8n 2.0 доступ к файловой системе по умолчанию ограничен каталогом ~/.n8n-files; другие разрешённые каталоги задают в конфигурации среды. Если n8n работает в Docker, путь относится к файловой системе контейнера. Каталог хоста становится доступным после согласованного подключения тома.
Local File Trigger работает только в self-hosted n8n и недоступен в n8n Cloud. С версии 2.0 этот узел по умолчанию отключён из-за существенных рисков в средах с недоверенными пользователями. Простое включение не решает вопрос безопасности: до него нужно определить доверенные источники, разрешённые каталоги, пользователей и права процесса.
Для сетевой папки недостаточно записать адрес в схеме. Во время обследования нужно подтвердить, что машина или контейнер действительно видит ресурс, может читать нужные файлы и не получает доступ за согласованными границами.
Проверка формата и содержимого до рабочего действия
Проверку полезно разделить на два слоя.
| Слой | Что проверяем | Чего проверка не доказывает |
|---|---|---|
| Технический | Файл читается, формат разрешён, структура доступна разбору | Что данные верны по смыслу |
| Бизнес-данные | Обязательные поля заполнены, типы и значения отвечают правилам заказчика | Что документ профессионально или юридически корректен |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Узел Extract From File в n8n преобразует данные бинарного файла в JSON для дальнейшей обработки. Документация перечисляет операции извлечения для CSV, HTML, JSON, ICS, ODS, PDF, RTF, текста, XLS и XLSX.
Наличие операции для формата не гарантирует обработку любой структуры. Повреждённый XLSX, нестандартный PDF или скан могут потребовать отдельных инструментов и правил. Неизвестное значение нельзя подменять догадкой: строку следует остановить или направить сотруднику с понятной причиной.
До запуска подготовьте обезличенные обычные и проблемные образцы. На них нужно проверить разрешённые структуры, обязательные поля и ситуации, в которых решение принимает человек.
Как защитить процесс от повторной обработки
Имя файла — слабый идентификатор. Один документ можно переименовать, заменить другим содержимым или повторно положить в папку под прежним именем.
Для защиты нужен реестр обработки. Его возможная структура:
| Поле | Зачем хранить |
|---|---|
| Идентификатор события | Связать обнаружение с конкретным запуском |
| Путь и имя | Найти исходный объект |
| Контрольные свойства | Сравнить содержимое по согласованному правилу |
| Время обнаружения | Восстановить последовательность событий |
| Статус | Понять, где остановилась обработка |
| Внешний идентификатор | Связать исходник с результатом принимающей системы |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Повторное обнаружение файла и допустимый повтор бизнес-действия — разные события. Процесс может заново прочитать файл после сбоя, но перед внешней записью обязан проверить, не подтверждён ли уже результат для того же логического объекта.
n8n не обеспечивает такую защиту автоматически для любого процесса. Ключ уникальности, срок хранения истории, область поиска дублей и правила перезапуска проектируют отдельно. Подробнее этот вопрос разобран в материале о защите от повторной обработки.
Статусы, ошибки и ручная проверка
Статус должен отвечать на три вопроса: где находится файл, кто действует дальше и можно ли безопасно повторить операцию.
Рабочая модель может включать состояния:
- обнаружен;
- ожидает готовности;
- проверяется;
- требует решения сотрудника;
- передаётся;
- завершён;
- отклонён;
- ошибка.
Названия можно изменить, но не стоит объединять разные причины в одно состояние «не обработан». Ошибка чтения, неподдерживаемая структура, спорное значение и отказ следующей системы требуют разных действий.
Для ручной очереди сохраните исходный файл, причину остановки, извлечённые значения и разрешённые действия сотрудника. Например, сотрудник может подтвердить сопоставление, отклонить файл или исправить данные в системе-источнике. Автоматическое исправление повреждённого или неоднозначного содержимого нельзя считать безопасным вариантом по умолчанию.
Передача в следующий рабочий процесс
После проверки система может переместить файл, записать подтверждённые данные в согласованную систему, создать задачу или передать исключение человеку. Конкретный результат задают в требованиях.
Не присваивайте итоговый статус сразу после отправки запроса. Сначала получите и сохраните подтверждение принимающей стороны. Свяжите одним идентификатором:
- исходный файл;
- версию извлечённых данных;
- запуск обработки;
- внешний идентификатор результата;
- итоговый статус.
Отдельно определите действие при частичном успехе. Например, если принимающая система сохранила часть строк, нельзя без проверки повторить весь файл: это способно создать дубли. Процесс должен знать, какие действия подтверждены, что осталось выполнить и требуется ли решение сотрудника.
Совместимость с конкретной системой проверяют во время обследования: нужны сведения об API или другом механизме обмена, правах, форматах и ограничениях. Наличие файла или n8n само по себе не гарантирует такое подключение.
Синтетический пример: XLSX с перечнем отгрузок
Это условная учебная последовательность, составленная по документации и требованиям процесса. Она не является клиентским кейсом Switch On AI или отчётом о выполненном тесте.
Контрагент помещает XLSX-файл с перечнем отгрузок в сетевую папку. Система замечает событие, но не отправляет данные дальше немедленно. Она действует так:
- Дожидается согласованного признака готовности.
- Фиксирует идентификатор, путь и контрольные свойства.
- Проверяет формат и наличие обязательных столбцов.
- Сверяет файл с реестром ранее подтверждённых результатов.
- Передаёт корректные строки в согласованный процесс, а спорные — сотруднику вместе с причиной.
- После подтверждения принимающей стороны связывает исходник, результат и итоговый статус.
Если реестр показывает, что действие уже подтверждено, система записывает повторное событие, но не выполняет внешнюю операцию ещё раз. Если передача прерывается, следующий запуск сначала проверяет сохранённые подтверждения и повторяет только незавершённую часть. Точные ключи дубля, обязательные столбцы и способ повтора нужно определить и испытать для реального процесса.
Ограничения и выбор способа внедрения
Способ запуска зависит от среды, характера записи файлов, допустимой задержки и последствий ошибки.
| Способ | Когда рассматривать | Что проверить |
|---|---|---|
| Запуск по расписанию | Контролируемый пакетный импорт, где допустима задержка | Интервал, повторное чтение, нагрузку и правила дублей |
| Событие файловой системы | Нужна реакция на изменения доступного каталога | Готовность записи, размещение, пути, права и безопасность |
| Механизм принимающей системы | У системы уже есть штатный импорт или обмен | Формат, подтверждение результата, ограничения и обработку ошибок |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Local File Trigger не работает в n8n Cloud. В self-hosted-среде доступ зависит от путей и прав. Сетевой каталог должен быть фактически доступен процессу, а не только указан в документации проекта.
Автоматизация папки не включает антивирусную проверку, карантин или безопасный разбор недоверенных файлов по умолчанию. Если источник нельзя считать доверенным, изоляцию, сканирование, ограничения размера и допустимые форматы добавляют в архитектуру и сценарии испытаний. Общие вопросы доступа разобраны в руководстве по безопасности данных в n8n.
Приёмку стройте по состояниям и последствиям. Проверьте:
- обнаружение допустимого готового файла;
- игнорирование временного, неподдерживаемого и ещё записываемого файла;
- распознавание повтора;
- связь исходника, запуска и результата;
- выделение спорных данных;
- подтверждение передачи следующей системой;
- недоступность папки и ошибки чтения, извлечения и внешней записи;
- безопасный повтор после сбоя;
- отсутствие доступа за пределами разрешённых каталогов;
- журнал действий и понятное уведомление ответственному.
Фактические пути и права проверяют в выбранном размещении. Успешный запуск workflow ещё не доказывает, что бизнес-результат получен. Подход к проверочным сценариям описан в статье о приёмке автоматизации.
Что подготовить для оценки автоматизации
Для первого разбора соберите:
- несколько обезличенных обычных и проблемных файлов;
- схему каталогов и источник поступлений;
- описание того, как файл появляется и когда считается готовым;
- допустимые форматы и обязательные поля;
- признаки одного логического объекта и повтора;
- ожидаемый результат следующего этапа;
- ответственных за исключения;
- сведения о доступной среде размещения;
- последствия повторного действия или пропуска файла.
Эта задача относится к интеграционной автоматизации с фиксированными правилами. Для стабильного формата ИИ-агент или чат-бот не нужны. ИИ можно рассматривать только как отдельную операцию над неструктурированным содержимым, если её результат проверяют человек или согласованные правила.
Switch On AI помогает разобрать такой процесс и подготовить решение в рамках услуги разработки и внедрения автоматизации. Работа начинается с разбора процесса, затем готовятся ТЗ и предложение. Бесплатный прототип показывает ключевой фрагмент сценария, но не равен полноценному внедрению. После согласования и договора выполняются разработка, приёмка и передача материалов. Стоимость, сроки, сопровождение и расходы внешних сервисов определяются после обследования.
Чтобы обсудить аналогичный процесс, подготовьте описание папки, правила приёма и синтетические либо обезличенные образцы и свяжитесь со Switch On AI.
Вопросы по этой задаче
Можно ли обрабатывать файл сразу после появления в папке?
Не всегда. Событие появления не доказывает, что запись завершена. Нужно согласовать признак готовности файла и проверить его в реальной среде.
Как не обработать один файл дважды?
Нужны устойчивый идентификатор, реестр состояний и проверка подтверждённого результата перед внешним действием. Одного имени файла обычно недостаточно.
Подойдёт ли n8n Cloud для наблюдения за локальной или сетевой папкой?
Нет, Local File Trigger доступен только в self-hosted n8n. Архитектуру выбирают с учётом расположения папки и фактического доступа процесса к ней.
Можно ли извлекать данные из Excel, CSV и PDF?
В n8n есть операции извлечения для этих форматов, но структуру и качество конкретных файлов нужно проверять. Для сканов, повреждённых файлов и сложной разметки могут потребоваться дополнительные средства.
Обеспечивает ли автоматизация папки антивирусную проверку?
Не по умолчанию. Для недоверенных источников сканирование, изоляцию, ограничения доступа и проверку опасных форматов включают в требования и испытания отдельно.