В процессе разработки на платформе 1С:Предприятие часто возникает ситуация, когда при интерактивной работе пользователя в справочнике всё работает корректно (срабатывают подписки на события ПередЗаписью и ПриЗаписи), но как только данные начинают поступать из внешней системы через COM-соединение, «определенный функционал» просто игнорируется. Проанализируем причины этой проблемы и найдем способы её решения.
Прежде всего, нам необходимо понять, что сеанс обычного пользователя и COM-сеанс — это разные сущности с точки зрения системы. Рассмотрим основные моменты, которые могут приводить к «молчаливому» пропуску вашего кода. Выясним причину, почему события, которые, казалось бы, привязаны к объекту, не отрабатывают при внешнем подключении.
Первое, на что мы должны обратить внимание — это настройки общего модуля, в котором располагается обработчик подписки на событие или вызываемые процедуры. Если ваш функционал вынесен в общий модуль, проверьте установленные флаги в его свойствах.
Для того чтобы код был доступен при COM-подключении, у модуля обязательно должен стоять флаг «Внешнее соединение». Если установлен только флаг «Сервер», код может быть недоступен для вызывающей стороны в контексте COM. Проанализируем ситуацию: если вы вызываете метод объекта извне, система инициализирует окружение, и если модуль не помечен для внешнего соединения, обработчик просто не будет скомпилирован в этом сеансе.
Часто программисты используют инструкции препроцессора для ограничения выполнения кода. Посмотрим на типичную ошибку в коде общего модуля:
#Если Сервер Тогда
// Код, который должен работать везде на сервере
Процедура ОбработкаСобытия(Источник, Отказ) Экспорт
// ... логика ...
КонецПроцедуры
#КонецЕсли
Важно понимать различие между директивами. Код внутри блока #Если Сервер будет работать и в обычном сеансе, и в COM-соединении (если оно серверное). Однако если код обернут в #Если ТолстыйКлиентОбычноеПриложение или #Если ТонкийКлиент, то при COM-соединении он будет полностью проигнорирован. Проверьте, не находится ли ваш обработчик внутри блока, который отсекает внешние подключения.
Это одна из самых распространенных причин. В типовых конфигурациях и профессионально написанных расширениях в начале обработчиков подписок часто стоит проверка:
Процедура ПередЗаписьюЭлемента(Источник, Отказ) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Ваш важный функционал
КонецПроцедуры
Проанализируем логику: при программной записи объекта через COM многие разработчики (или стандартные механизмы обмена) устанавливают ОбменДанными.Загрузка = Истина, чтобы избежать лишних проверок и ускорить запись. Если в подключающейся базе код выглядит так:
НовыйОбъект = COMСоединение.Справочники.Номенклатура.СоздатьЭлемент();
НовыйОбъект.Наименование = "Тестовый товар";
НовыйОбъект.ОбменДанными.Загрузка = Истина; // Вот здесь отключается ваш функционал
НовыйОбъект.Записать();
То ваш «определенный функционал» выполнен не будет. Рекомендуется проверить код в обеих базах и убедиться, что флаг Загрузка устанавливается в Ложь, если выполнение бизнес-логики критично.
Рассмотрим ситуацию, когда ваш функционал обращается к ПараметрыСеанса.ТекущийПользователь или другим глобальным переменным. При COM-соединении стандартные события старта системы, такие как ПриНачалеРаботыСистемы, не вызываются. Это означает, что параметры сеанса могут быть не заполнены.
Если код натыкается на незаполненный параметр сеанса, выполнение процедуры прерывается с ошибкой. В контексте COM эта ошибка часто подавляется или возвращается как общая ошибка «Метод контекста Записать завершился с ошибкой». Чтобы этого избежать, убедитесь, что в модуле сеанса прописана корректная инициализация в процедуре УстановкаПараметровСеанса.
Иногда нам нужно выполнить специфические действия именно при внешнем подключении. Самый надежный способ определить тип клиента — использовать функцию ИмяПриложения(). Рассмотрим пример:
Если ИмяПриложения() = "COMConnection" Тогда
// Мы находимся в контексте внешнего соединения
Лог.Записать("Запись объекта через COM-интерфейс");
КонецЕсли;
Это позволит вам гибко управлять логикой, не затрагивая работу обычных пользователей.
Выясним еще один важный момент: где именно написан ваш функционал? Если код находится в модуле формы (например, в событии ПриЗаписи на форме), он никогда не выполнится при COM-соединении. Внешнее соединение работает напрямую с объектом базы данных, минуя интерфейсный слой. Весь критически важный функционал должен быть перенесен в модуль объекта или в подписки на события.
Если визуальный анализ кода не помогает, воспользуемся инструментами отладки. Мало кто знает, что COM-соединение можно отлаживать так же, как обычный сеанс. Выполним следующие шаги:
Теперь вы сможете поставить точку останова в подписке на событие и увидеть в реальном времени, заходит ли туда система и на какой строке выполнение прерывается или уходит по ветке Возврат.
Проанализируем еще одну причину падения кода. Если в вашем «определенном функционале» есть вызовы интерактивных функций, таких как Предупреждение(), Вопрос() или Сообщить(), обработчик в COM-сессии немедленно прекратит работу с ошибкой. В сеансе внешнего соединения нет интерфейса, и любые попытки диалога с пользователем недопустимы. Замените их на запись в журнал регистрации или используйте проверку #Если Не ВнешнееСоединение Тогда.
Иногда проблема кроется в правах доступа. Пользователь, под которым создается COM-соединение, может не иметь прав на чтение вспомогательных регистров, которые используются в подписке. Попробуем обернуть выполнение функционала в привилегированный режим:
УстановитьПривилегированныйРежим(Истина);
// Выполнение действий, требующих повышенных прав
УстановитьПривилегированныйРежим(Ложь);
Это поможет исключить влияние ограничений прав доступа (RLS) на выполнение вашей технической логики при записи элемента.