Как использовать собственные правила в обработке «Выгрузка и загрузка данных EnterpriseData» и почему процесс может зависать?

← На главную

При переносе данных между конфигурациями (например, из БП 3.0 в КА 2.4) программисты часто сталкиваются с необходимостью кастомизации правил обмена в формате EnterpriseData. Типовая обработка «Выгрузка и загрузка данных EnterpriseData» предоставляет «Режим разработчика», который теоретически позволяет подключать внешние менеджеры обмена. Однако на практике разработчики натыкаются на две основные проблемы: блокировку загрузки внешней обработки системой безопасности и бесконечное «зависание» процесса загрузки. В этой статье мы подробно разберем, как подготовить менеджер обмена, обойти ограничения платформы и успешно выполнить перенос.

Причина 1: Ошибки безопасности и блокировка внешних обработок

Разберем ситуацию, когда при попытке указать файл в поле «Менеджер загрузки» система выдает ошибку: «Внешняя обработка отладки, загружаемая из файла на диске, не поддерживается». Это происходит из-за ужесточения политики безопасности в современных версиях БСП (Библиотеки стандартных подсистем). Платформа блокирует выполнение метода ВнешниеОбработки.Создать() для файлов, запускаемых в безопасном режиме.

Рассмотрим способы обхода этого ограничения:

Корректировка кода обработки: Проанализируем модуль обработки «Выгрузка и загрузка данных EnterpriseData». В процедуре, отвечающей за создание объекта менеджера, часто жестко прописан параметр БезопасныйРежим = Истина. Если мы изменим его на Ложь, система позволит загрузить файл.
Использование расширения: Чтобы не снимать основную конфигурацию с поддержки, создадим расширение. В нем необходимо перехватить метод создания внешней обработки и подменить параметры безопасности. Это наиболее корректный путь для «боевых» баз.
Регистрация в справочнике: В некоторых случаях помогает предварительная регистрация внешней обработки в справочнике «Дополнительные отчеты и обработки», однако для режима отладки этот путь менее удобен из-за необходимости постоянного обновления файла в базе.

Причина 2: Неправильная структура файла «Менеджера обмена»

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

Важно помнить: текст модуля, скопированный из КД 3.0, необходимо вставлять именно в Модуль объекта внешней обработки. Модуль менеджера самой обработки в данном случае не используется движком EnterpriseData. Проверим наличие в коде обязательных экспортных процедур, которые ожидает основной механизм обмена:


// Пример обязательной процедуры в модуле объекта менеджера
Процедура ИнициализироватьПараметрыКонвертации(ПараметрыКонвертации) Экспорт
    // Здесь устанавливаются версии формата и базовые настройки
КонецПроцедуры

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

Причина 3: Почему загрузка «висит» до бесконечности?

Если процесс начинается, но не завершается даже при малом объеме данных (например, 2 документа), проанализируем внутренние механизмы EnterpriseData. Зависание чаще всего связано с инициализацией окружения, которое в режиме отладки отличается от стандартного сеанса синхронизации.

Проблема поиска соответствий (XDTO):
При загрузке система выполняет сопоставление типов. Если в вашем модуле менеджера прописаны сложные алгоритмы в обработчиках ПередОбработкой или ПриЗагрузке, которые обращаются к неиндексированным таблицам или пытаются выполнить тяжелые запросы, процесс будет выглядеть как зависший.

Отсутствие Узла обмена:
Типовая обработка имитирует работу синхронизации, но делает это «вне» конкретного плана обмена. Если в вашем коде (в правилах) есть обращения к методу ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.ЭтотУзел(), система может войти в бесконечный цикл ожидания или выдать ошибку доступа к неопределенному объекту. Проанализируем код на наличие зависимости от конкретного узла обмена и добавим проверки:


Если ПланОбменаСсылка = Неопределено Тогда
    // Логика для работы без привязки к узлу (режим разработчика)
КонецЕсли;

Методика отладки в режиме разработчика

Чтобы понять, в какой момент происходит сбой, применим следующие инструменты:

Запуск с параметрами: Используем запуск сеанса 1С с параметром /AllowExecuteScheduledJobs -Force. Это критично, так как механизмы EnterpriseData могут инициировать фоновые задания для трансформации данных, которые блокируются в обычном сеансе отладки.
Логирование через Журнал Регистрации: В самом модуле менеджера (в вашей внешней обработке) добавим запись в ЖурналРегистрации в начало ключевых процедур. Это позволит отследить, доходит ли выполнение до ваших алгоритмов.


ЗаписьЖурналаРегистрации("ОтладкаEnterpriseData", УровеньЖурналаРегистрации.Информация, , , "Начало выполнения загрузки...");

Альтернативный путь: Если использование внешней обработки вызывает слишком много проблем с правами и безопасностью, рассмотрим более надежный вариант. Можно временно заменить содержимое общего модуля МенеджерОбменаЧерезУниверсальныйФормат в самой конфигурации (через расширение). Это исключит любые конфликты с файловой системой и SafeMode.

Соответствие версий формата

Проанализируем ситуацию с версиями. Даже небольшое различие в версии формата (например, выгрузка в 1.3, а менеджер ожидает 1.10) может привести к тому, что XDTO-пакет не сможет корректно сопоставить пространства имен. В режиме разработчика механизмы автоматической трансформации БСП могут работать нестабильно. Убедитесь, что заголовок (Header) файла XML полностью соответствует тому, что прописано в процедуре ИнициализироватьПараметрыКонвертации вашего менеджера.

Подводя итог, использование режима разработчика в обработке выгрузки и загрузки — это мощный инструмент, который требует внимательного отношения к политикам безопасности 1С и структуре программного кода менеджера обмена. Правильная настройка безопасного режима и логирование каждого шага помогут избежать «бесконечных» загрузок и успешно выполнить перенос данных.