При настройке синхронизации данных между старой доброй Управлением торговлей 10.3 и современной Бухгалтерией предприятия 3.0 многие разработчики сталкиваются с досадной ситуацией: правила конвертации вроде бы настроены верно, обработчики в «Конвертации данных 2.0» прописаны, но при загрузке данных в БП 3.0 код в событии После загрузки просто игнорируется. В этой статье мы разберем причины такого поведения системы, выясним, где на самом деле «живут» исполняемые правила, и рассмотрим современные альтернативы устаревшему обмену на правилах КД 2.0.
Проанализируем типичную ситуацию. Программист вносит изменения в правила обмена в конфигурации-источнике (УТ 10.3). Он ожидает, что при выгрузке правила упаковываются в файл обмена, и база-приемник (БП 3.0) выполнит все прописанные в них алгоритмы. Однако на практике этого не происходит. Даже простейшая проверка, такая как:
Объект.Комментарий = "Тест";
не дает никакого результата в базе приемника. Почему так происходит? Ответ кроется в архитектуре Библиотеки стандартных подсистем (БСП), на которой построена БП 3.0. В целях безопасности, особенно для облачных решений (например, 1С:Фреш), современные конфигурации игнорируют исполняемый код (обработчики), приходящий из внешнего файла правил вместе с данными. Вместо этого БП 3.0 использует внутренний комплект правил, который хранится в самой информационной базе или в составе макетов конфигурации.
Таким образом, когда мы правим правила в УТ 10.3, мы меняем только логику выгрузки. Логика загрузки в БП 3.0 остается прежней, пока мы не обновим правила непосредственно в самой Бухгалтерии.
Выясним, как правильно внести изменения в процесс загрузки. Для того чтобы ваши правки в коде «После загрузки» вступили в силу, необходимо выполнить следующие действия в базе-приемнике (БП 3.0):
Рассмотрим подробнее: теперь при старте обмена БП 3.0 будет использовать не те правила, что «прилетели» в XML-пакете, а те, что были загружены в её внутреннюю память. Это гарантирует выполнение ваших алгоритмов ПослеЗагрузки.
Иногда даже после правильной загрузки правил кажется, что код не работает. Проанализируем ситуацию: синхронизация в БП 3.0 чаще всего выполняется в фоновом режиме. Если вы используете метод Сообщить() для отладки, вы ничего не увидите, так как фоновое задание не имеет графического интерфейса.
Для надежной проверки рекомендуется использовать Журнал регистрации. Попробуйте написать в обработчике следующий код:
ЗаписьЖурналаРегистрации("ОбменДанными.Отладка",
УровеньЖурналаРегистрации.Информация,
,
,
"Обработчик 'После загрузки' сработал для объекта: " + Строка(Объект));
После завершения обмена загляните в Журнал регистрации (Администрирование — Обслуживание). Если запись появилась, значит, проблема не в правилах, а в логике самого кода или в том, что объект не записывается (например, из-за ошибок проведения).
Разберем совет опытных разработчиков. Поддержка обмена на КД 2.0 между старой УТ 10.3 и постоянно обновляемой БП 3.0 — это трудозатратный процесс. Каждое обновление БП может менять структуру метаданных, что заставляет вас снова и снова перелопачивать правила.
Существует более современный стандарт — Enterprise Data. Несмотря на то что УТ 10.3 считается устаревшей, в последних релизах (или через внедрение модулей из УПП 1.3 / КА 1.1) появилась возможность использовать обмен через формат EnterpriseData.
Преимущества Enterprise Data:
Проанализируем ситуацию: если ваша УТ 10.3 сильно доработана, возможно, стоит один раз потратить время на внедрение подсистемы обмена через Enterprise Data, чтобы навсегда забыть о «слетающих» обработчиках при каждом обновлении Бухгалтерии.
Подведем итоги нашего исследования. Если вы столкнулись с тем, что код в правилах обмена игнорируется, помните следующие важные моменты:
ПередЗаписью или ПриЗаписи, чем править правила обмена. Это позволит сохранить логику даже при полной замене правил обмена типовыми при обновлении.Используя эти методы, мы сможем построить надежную и предсказуемую систему синхронизации данных, которая не будет ломаться при каждом визите обновлений от фирмы 1С.