Почему перестали отрабатывать правила бесшовной интеграции между 1С:ДО 3.0 и 1С:КА?

← На главную

При настройке бесшовной интеграции между конфигурациями 1С:Документооборот 3.0 и 1С:Комплексная автоматизация разработчики нередко сталкиваются с ситуацией, когда регламентное задание Обмен данными с 1С:Документооборотом завершается без ошибок, но данные в 1С:КА не обновляются. При этом добавление точек логирования и попытки записать события в журнал регистрации непосредственно из правил интеграции не дают результатов — код правил попросту не вызывается.

Разберем по шагам архитектуру механизма обмена, выясним ключевые причины такого поведения и рассмотрим комплексную методику восстановления работоспособности интеграции.

1. Анализ очереди сообщений и выявление зависаний по таймауту

Проанализируем базовый принцип передачи данных. Когда в 1С:ДО изменяется объект, механизм интеграции регистрирует изменение и формирует пакет сообщения для внешней системы. Во время регламентного обмена 1С:КА обращается к веб-сервису 1С:ДО и запрашивает очередную порцию данных.

Одной из наиболее частых скрытых причин остановки обработки является зависание очереди по таймауту веб-сервиса. Рассмотрим, как это происходит:

В 1С:ДО формируется сообщение, содержащее объект с большим количеством связей (например, согласуемый договор, к которому привязано множество файлов, дополнительных соглашений, процессов и контрагентов).
При попытке упаковать и передать такой объемный пакет веб-сервис 1С:ДО не успевает завершить операцию в рамках отведенного лимита времени (таймаута HTTP- или SOAP-соединения).
Поскольку архитектура обмена Библиотеки интеграции с 1С:Документооборотом (БИД) строго упорядочивает очередь и не пропускает вперед новые сообщения до успешной обработки текущего пакета, весь конвейер синхронизации останавливается. До выполнения пользовательских правил заполнения в 1С:КА очередь попросту не доходит.

Для локализации данной проблемы выполним проверку следующих узлов:

Проверим состояние журнала регистрации на стороне 1С:Документооборот: отфильтруем события по служебному пользователю интеграции и веб-сервисам, чтобы убедиться в отсутствии исключений и таймаутов сериализации данных.
Убедимся, что регламентные задания в 1С:ДО, отвечающие за формирование сообщений для интегрированных систем, активны и завершаются штатно.
Запустим отладку со стороны 1С:КА в процедуре вызова веб-сервиса ДО и проверим, возвращает ли веб-сервис непустой пакет данных при запросе очереди.

2. Проверка настроек реквизитов в правилах интеграции

Если пакеты данных успешно покидают 1С:ДО и принимаются на стороне 1С:КА, но обработка конкретных реквизитов не происходит, выясним настройки самих правил интеграции:

Флаг «Обновлять»: Откроем правило интеграции в 1С:КА и проверим табличную часть сопоставления полей. Если для реквизита снят признак обновления, значение переносится исключительно в момент первичного создания объекта в 1С:КА. При повторных синхронизациях изменение этого поля игнорируется.
Разрешение «Изменение в проведенном документе»: Если целевой объект в 1С:КА уже проведен, подсистема безопасности данных запрещает модификацию его полей из внешних источников. Чтобы реквизит перезаписался, в правиле интеграции для конкретного поля должно быть явно включено разрешение на изменение в проведенных документах.
Условия применения правил: Если для одного типа документов настроено несколько правил, система выбирает подходящее на основании ключевых реквизитов или условий на встроенном языке. Проверим, не изменились ли значения ключевых реквизитов объекта, из-за чего он перестал соответствовать отбору правила.

3. Диагностика связей объектов интегрированных систем

Интеграция опирается на регистр сведений Связи объектов интегрированных систем. Если в процессе перенастройки правил или ручной очистки служебных регистров была нарушена запись, связывающая внутренний документ 1С:ДО и документ 1С:КА, система воспринимает входящие данные как несопоставленный объект.

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

4. Регистрация изменений и особенности ДО 3.0

Посмотрим на сторону источника изменений — конфигурацию 1С:ДО 3.0. Запись изменений в очередь выполняется через подписки на события. Выясним следующие моменты:

Если статусы или реквизиты документов в 1С:ДО менялись групповой обработкой или фоновым скриптом с установленным свойством ОбменДанными.Загрузка = Истина, платформенные события записи не инициируют регистрацию изменений, и пакет для отправки в КА не будет сформирован.
Проверим публикацию информационных баз на веб-сервере. Архитектура интеграции с версией 3.0 предъявляет повышенные требования к двусторонней доступности: веб-сервер должен корректно маршрутизировать вызовы без сброса сессий, а адреса публикации в обеих базах должны быть доступны взаимно.
Проверим права служебного пользователя обмена. Ограничения доступа на уровне записей (RLS) в 1С:ДО могут приводить к тому, что веб-сервис возвращает успешный код ответа, но тело ответа будет пустым, так как у служебной учетной записи нет прав на чтение конкретного вида документа или связанных файлов.

5. Корректная запись в журнал регистрации для отладки

Регламентные задания обмена выполняются в отдельном фоновом сеансе. При попытке логирования через метод ЗаписьЖурналаРегистрации необходимо учитывать контекст выполнения. Если фильтровать журнал регистрации по интерактивному пользователю, фоновые события останутся скрытыми.

Посмотрим на пример гарантированной записи отладочного сообщения в фоновом режиме:


ПараметрыЗаписи = Новый Структура;
ПараметрыЗаписи.Вставить("ИмяСобытия", "Интеграция.ОтладкаПравила");
ПараметрыЗаписи.Вставить("Уровень", УровеньЖурналаРегистрации.Предупреждение);
ПараметрыЗаписи.Вставить("Комментарий", "Правило вызвано для объекта: " + Строка(ОбъектИнтеграции));

ЗаписьЖурналаРегистрации(
    ПараметрыЗаписи.ИмяСобытия,
    ПараметрыЗаписи.Уровень,,,
    ПараметрыЗаписи.Комментарий
);

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