Разработка и поддержка обменов данными между различными базами 1С (например, между УПП и Розницей) через COM-соединение часто сопряжена с трудностями при поиске ошибок. Стандартная установка точки останова в конфигураторе часто не дает результата: код выполняется, ошибка вылетает, но отладчик не останавливается. Рассмотрим подробно, как настроить среду для полноценной отладки внешних соединений, и разберем причины, по которым сеансы могут "пролетать" мимо отладчика.
Для начала проанализируем, как работает отладка в режиме COM-соединения. Когда одна база (клиент) создает объект COMConnector для подключения к другой базе (серверу), создается особый тип сеанса — Внешнее соединение. Этот сеанс исполняется на стороне сервера (в клиент-серверном варианте) или в процессе вызывающего приложения. Чтобы конфигуратор смог "подцепиться" к этому невидимому сеансу, платформа должна получить четкую инструкцию: куда именно (на какой IP и порт) передавать данные отладки. Без специального конфигурационного файла comcntrcfg.xml внешнее соединение просто не знает о существовании вашего конфигуратора.
Выясним, где именно должен находиться этот файл. Это критический момент: файл должен располагаться на том компьютере, где создается объект COMConnector. Если обмен запускается фоновым заданием на сервере УПП, то файл должен лежать на сервере УПП. Если вы запускаете обработку обмена в толстом клиенте на своей локальной машине, то файл должен быть на вашем ПК.
Путь к файлу для платформы 1С 8.3 обычно следующий:
C:\Program Files\1cv8\conf\ (общий для всех версий платформы).C:\Program Files\1cv8\8.3.XX.XXXX\bin\conf\ (для конкретной версии сборки).Рекомендуем разместить файл в обе папки для надежности. Содержимое файла comcntrcfg.xml должно быть следующим:
<config xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconnect>
<debuggerURL>tcp://ИМЯ_ВАШЕГО_ПК</debuggerURL>
</debugconnect>
</config>
В параметре debuggerURL обязательно укажите сетевое имя вашего компьютера или его статический IP-адрес. Использование localhost допустимо только в том случае, если и COM-соединение, и конфигуратор запущены на одной и той же физической машине.
Проанализируем сетевые ограничения. Для успешной отладки необходимо выполнить два условия:
Попробуйте временно отключить брандмауэр Windows, чтобы исключить влияние сетевых блокировок при поиске причины проблемы.
Перейдем в Конфигуратор той базы, код которой мы хотим отлаживать (в нашем примере — "Розница"). Выполним следующие действия:
После этих настроек конфигуратор будет пытаться автоматически захватить любой подходящий сеанс внешнего соединения, как только он возникнет.
Если точка останова стоит в расширении и не срабатывает, проверим специфические моменты 1С. Во-первых, убедимся, что код не обернут в инструкции препроцессора, которые исключают его выполнение во внешнем соединении. Рассмотрим пример:
#Если Сервер Или ВнешнееСоединение Тогда
// Этот код будет доступен при COM-обмене
Процедура ПриЗаписи(Отказ)
// Точка останова здесь
КонецПроцедуры
#КонецЕсли
Если код находится внутри блока #Если Клиент, он никогда не будет вызван при COM-подключении, так как COM — это всегда либо серверный контекст, либо контекст внешнего соединения.
Во-вторых, существует проблема "кэширования" расширений для COM-сеансов. Попробуйте в базе "Розница" зайти в список расширений, снять флаг Активно, нажать "Обновить конфигурацию базы данных", а затем вернуть флаг обратно. Это заставит платформу пересобрать связи модулей для всех типов соединений.
Разберем ситуацию, когда отладка все равно не работает. Чтобы выяснить, виновато ли расширение или настройки подключения в целом, поставим точку останова в Модуле внешнего соединения основной конфигурации. Используйте предопределенную процедуру ПриНачалеРаботыСистемы (в некоторых версиях она может не вызываться для COM) или создайте свою экспортную процедуру, которую вызовете из УПП сразу после создания соединения.
Если в основном модуле точка останова срабатывает, а в расширении нет — проблема в области видимости расширения. Проверьте свойства расширения: оно не должно быть в режиме "Безопасный режим", так как это может накладывать ограничения на выполнение определенных действий в сеансе COM.
Если сетевая инфраструктура (сложные VPN, NAT, запреты администраторов) не позволяет пробросить порты для отладки, воспользуемся проверенным методом логирования. Вместо точки останова вставим в подозрительный участок кода запись в журнал регистрации:
ЗаписьЖурналаРегистрации("Отладка_COM",
УровеньЖурналаРегистрации.Ошибка, , ,
"Значение переменной: " + Строка(НужныйПараметр));
Проанализировав журнал в базе "Розница" после запуска обмена, вы увидите все промежуточные данные. Это не заменяет полноценную отладку, но позволяет быстро понять, доходит ли выполнение до нужной точки и какие значения принимают переменные в момент ошибки.
Резюмируем: для успешной отладки COM-соединения обязательны правильный comcntrcfg.xml на стороне инициатора, включенный -debug на сервере назначения, открытые TCP-порты и настроенное "Автоматическое подключение" в конфигураторе.