Как найти внешнюю обработку в 1С, если она вызывается из кода, но отсутствует на диске

← На главную

Типичная проблема, с которой сталкиваются разработчики и администраторы 1С при поддержке нетиповых или отраслевых конфигураций — это появление ошибок в модулях внешних обработок, которые физически отсутствуют на диске и не зарегистрированы в стандартном справочнике «Дополнительные отчеты и обработки». В коде конфигурации мы видим прямое обращение к объекту, например, через конструкцию ПолучитьФорму("ВнешняяОбработка.ИмпортДанныхУправляемая.Форма"), но сама обработка как будто растворилась в воздухе.

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

Способ 1: Анализ инициализации через глобальный поиск

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


ИмяОбработки = ВнешниеОбработки.Подключить(ПутьИлиАдресХранилища, "ИмпортДанныхУправляемая");

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

Проанализируем последовательность действий для поиска точки подключения:

Откроем конфигурацию в режиме Конфигуратор.
Вызовем окно глобального поиска с помощью комбинации клавиш Ctrl + Shift + F (или через меню Правка -> Глобальный поиск).
В поле поиска введем ключевое слово .Подключить( или ВнешниеОбработки.Подключить.
В области поиска укажем всю конфигурацию и модули.
Запустим поиск и проанализируем результаты.

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

Способ 2: Остановка по ошибке в отладчике и сохранение файла

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

Разберем по шагам, как перехватить управление и сохранить виртуальный модуль:

В Конфигураторе откроем меню Отладка и выберем пункт Остановка по ошибке.
В открывшемся окне установим флаг Использовать остановку по ошибке.
При необходимости добавим условие фильтрации по тексту ошибки (например, содержащему «ОписаниеТипов»), чтобы отладчик не прерывал работу на других некритичных исключениях.
Запустим сеанс отладки (клавиша F5) и воспроизведем действие в пользовательском режиме, которое приводит к сбою.
Платформа автоматически остановит выполнение кода ровно на строке 7408 модуля объекта внешней обработки. При этом конфигуратор откроет временный файл модуля в режиме просмотра.
Для того чтобы сохранить всю обработку целиком на жесткий диск, перейдем в главное меню конфигуратора и выберем Файл -> Сохранить как.... Укажем путь для сохранения файла с расширением .epf.

Теперь в нашем распоряжении есть полноценный файл внешней обработки, который мы можем открыть в конфигураторе как самостоятельный объект, отредактировать и исправить логику работы.

Способ 3: Перехват файла во временном каталоге операционной системы (Temp)

Когда платформа 1С подключает внешнюю обработку (даже если двоичные данные извлекаются динамически из базы данных или макета), операционная система физически распаковывает файл обработки на локальный диск для исполнения кода. Нам достаточно «поймать» этот файл в системной папке до того, как сеанс 1С будет закрыт и временные файлы удалятся.

Выясним особенности размещения временных файлов:

Если проблемный код выполняется на стороне клиента, файл сохраняется во временную папку текущего пользователя Windows. Обычно это путь: C:\Users\<ИмяПользователя>\AppData\Local\Temp\.
Если вызов происходит в серверном контексте (на сервере), то файл распаковывается в Temp-папку пользователя, под которым запущена служба агента сервера «1С:Предприятие» (например, USR1CV8).

Рассмотрим алгоритм перехвата файла:

Максимально очистим временную папку Temp на компьютере (или на сервере), чтобы облегчить последующий поиск.
Запустим сеанс 1С и дойдем до шага, предшествующего ошибке (чтобы обработка гарантированно подключилась и распаковалась).
Перейдем в папку Temp и отсортируем все файлы по дате и времени изменения.
Ищем файлы с расширением .epf или временные файлы без расширения с характерным размером (обычно от 50 Кб до нескольких Мегабайт).
Скопируем найденный подозрительный файл в другую директорию и вручную переименуем его, добавив расширение .epf. Попробуем открыть его в конфигураторе.

Способ 4: Проверка альтернативных и скрытых мест хранения

Если глобальный поиск по конфигурации и каталогам Temp не принес результатов, велика вероятность, что разработчики использовали специализированные механизмы хранения элементов.

Проанализируем основные «тайники» в архитектуре 1С:

Общие макеты конфигурации. Очень часто разработчики создают общий макет с типом Двоичные данные, загружают туда готовую обработку, а в коде извлекают ее методом ПолучитьОбщийМакет(). Проверьте ветку метаданных ОбщиеМакеты на наличие объектов, содержащих в названии ключевые слова «Импорт», «Загрузка» или имя вашей обработки.
Нетиповые справочники и регистры отраслевых решений. В конфигурациях, особенно разработанных на базе отраслевых шаблонов со встроенными системами защиты (например, СЛК от Катран), могут быть созданы собственные справочники (например, Справочник.НастройкиИнтеграции, Справочник.ДополнительныеКомпоненты) или регистры сведений (например, РегистрСведений.ДвоичныеДанныеФайлов). Проверьте эти объекты через «Все функции» (или «Функции для технического специалиста») в режиме предприятия.
Компоненты защиты СЛК. Если конфигурация требует аппаратный или программный ключ защиты, логика внешней обработки может быть зашита внутрь сторонних DLL-библиотек защиты. В этом случае получить файл напрямую не удастся, так как код защищен авторским правом разработчика решения.

Анализ и устранение исходной ошибки «ОписаниеТипов»

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

В конструктор передается массив или строка с описанием типов метаданных, которых физически нет в текущей конфигурации (например, обработка писалась для ERP, а запускается в УНФ, где нет документа «ПриобретениеТоваровУслуг»).
Попытка инициализации типов, к которым у текущего пользователя ограничены права доступа на уровне RLS.
Синтаксические ошибки при передаче строкового параметра в конструктор (лишние пробелы, опечатки в именах объектов метаданных).

Посмотрим на пример правильного и безопасного создания описания типов в модуле обработки:


МассивТипов = Новый Массив;
МассивТипов.Добавить(Тип("СправочникСсылка.Номенклатура"));
МассивТипов.Добавить(Тип("СправочникСсылка.Контрагенты"));

// Безопасная инициализация описания типов
ОписаниеНоменклатурыИКонтрагентов = Новый ОписаниеТипов(МассивТипов);

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