← На главную

Переход на технологию обмена через универсальный формат (EnterpriseData) и использование «Конвертации данных 3.0» (КД 3.0) часто вызывает вопросы у разработчиков, привыкших к классической КД 2.0. Основные сложности возникают на этапе сопряжения версий формата и «легализации» программного кода правил внутри конфигурации. В этой статье мы подробно разберем, как преодолеть эти препятствия, внедрим кастомный план обмена и выясним, что делать с ошибками нехватки памяти при настройке синхронизации.

Совместимость разных версий XDTO-пакетов EnterpriseData

Рассмотрим ситуацию, когда в одной базе (например, Управление торговлей 11.2) доступен пакет EnterpriseData_1_3_4, а в другой (Бухгалтерия предприятия 3.0) — EnterpriseData_1_3_20. На первый взгляд кажется, что обмен невозможен без приведения конфигураций к единому знаменателю. Однако технология EnterpriseData спроектирована с учетом обратной совместимости.

Разберем, как системы взаимодействуют в этом случае. При установке соединения информационные базы обмениваются списком поддерживаемых версий. Синхронизация будет происходить по наивысшей версии формата, которую поддерживают обе конфигурации. Если одна база умеет работать только с 1.3, а вторая с 1.3–1.6, то обмен автоматически «спустится» на версию 1.3.

Проанализируем действия в КД 3.0:

1. Для настройки правил выгрузки из УТ загрузим в конфигурацию КД 3.0 XDTO-пакет именно той версии, которая является целевой для обмена (например, 1.3).
2. Не стоит пытаться найти «абсолютно одинаковые» пакеты в обеих базах, если разница только в минорных версиях. Главное — чтобы пакет в КД 3.0 соответствовал или был ниже версии, поддерживаемой обеими сторонами.
3. Изменения формата между версиями 1.3.4 и 1.3.20 могут быть некритичны для вашего состава данных. Если же требуется передать реквизит, появившийся только в 1.6, придется обновлять БСП или внедрять расширение с новым XDTO-пакетом в «отстающую» базу.

Регистрация кастомного плана обмена и модуля менеджера

Когда правила (модуль менеджера обмена) получены из КД 3.0, их нужно внедрить в конфигурацию. Просто скопировать код в МенеджерОбменаЧерезУниверсальныйФормат недостаточно, если мы хотим создать изолированный, не зависящий от типовых обновлений обмен. Выясним, как правильно зарегистрировать свой план обмена, используя механизмы БСП.

Рассмотрим пошаговый алгоритм действий:

1. Создание Плана обмена: Скопируем типовой план обмена, например, СинхронизацияДанныхЧерезУниверсальныйОбмен, и назовем его по-своему (например, _МояСинхронизацияДанных).
2. Настройка модулей Плана обмена: В МодулеМенеджера и МодулеОбъекта нового плана обмена необходимо заменить все вхождения имени старого плана обмена на _МояСинхронизацияДанных.
3. Подключение через БСП: Чтобы система увидела новый план обмена в списке доступных синхронизаций, найдем общий модуль ОбменДаннымиПереопределяемый. В процедуре ПолучитьПланыОбмена добавим строку:
   Скопировать код

   
   Процедура ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт
       ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена._МояСинхронизацияДанных);
   КонецПроцедуры
   

4. Создание общего модуля менеджера: Создадим новый общий модуль (например, _МенеджерОбменаСБухгалтерией). Установим свойства: Сервер, Внешнее соединение, Вызов сервера. В этот модуль вставим код, сгенерированный в Конвертации данных 3.0.
5. Связка версии формата и модуля: Теперь нужно указать системе, что для версии формата 1.3 нужно использовать именно наш модуль. Это делается в МодулеМенеджера нашего нового плана обмена _МояСинхронизацияДанных:
   Скопировать код

   
   // В процедуре ПриПолученииНастроек указываем соответствие версий
   Процедура ПриПолученииНастроек(Настройки) Экспорт
       Настройки.ВерсииФормата.Вставить("1.3", "_МенеджерОбменаСБухгалтерией");
   КонецПроцедуры
   

Таким образом, мы создали независимую ветку обмена, которая не затирается при обновлении типовых правил 1С, но при этом использует всю мощь стандартной библиотеки БСП.

Решение проблемы с нехваткой памяти (ошибка POST /e1cib/logForm)

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

Для решения этой проблемы выполним следующие действия:

1. Очистка регистрации: Перед тем как менять дату старта обмена, вручную очистим регистрацию изменений для узла. Если в базе скопились сотни тысяч объектов, помеченных к выгрузке, попытка пересчитать их по новой дате вызывает коллапс. Используйте типовую обработку Регистрация изменений для обмена.
2. Использование 64-битного клиента: Если работа ведется в файловом варианте, запуск тяжелых операций через 64-битный клиент 1cv8.exe поможет обойти лимит в 2-4 ГБ памяти.
3. Тестирование и исправление: Выполните очистку пустых записей в таблицах регистрации через конфигуратор.

Особенности отладки в КД 3.0

В отличие от КД 2.0, где логика была скрыта в XML-файле правил и требовала выгрузки в модуль для отладки, в КД 3.0 всё прозрачно. Поскольку все правила — это обычный код на языке 1С в общем модуле, мы можем:

• Установить точку останова в процедуре ПКО_ПередВыгрузкой_... нашего модуля.
• Пошагово отследить, как заполняются поля XDTODataObject.
• Видеть структуру входящих и исходящих данных непосредственно в табло переменных.

Это делает КД 3.0 гораздо более удобным инструментом для сложных внедрений, несмотря на более высокий порог вхождения и необходимость понимания структуры EnterpriseData.