← На главную

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

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

Выясним причину сбоя правил обмена после обновления

Конфигурация Конвертация данных 2.0 создает правила, жестко привязанные к физическим именам реквизитов, табличных частей и объектов метаданных. В процессе развития типовых конфигураций разработчики фирмы «1С» регулярно проводят рефакторинг:

1. Переименование или удаление реквизитов. Служебные поля или реквизиты документов могут переноситься в дополнительные свойства, регистры сведений или табличные части.
2. Изменение сигнатур процедур и функций. Если в обработчиках событий правил конвертации (например, ПередВыгрузкой или ПриЗагрузке) используются прямые вызовы процедур общих модулей БСП или типовой конфигурации, они могут быть удалены, переименованы или объявлены устаревшими.
3. Отложенное обновление данных. В современных конфигурациях на базе БСП обработчики обновления выполняются в фоновом режиме. Если запустить перенос данных до завершения фонового обновления, часть реквизитов может находиться в неконсистентном состоянии.

Способ 1. Быстрая актуализация правил в Конвертации данных

Создавать правила с нуля при каждом обновлении нет необходимости. Проанализируем стандартный регламент восстановления работоспособности правил:

1. Локализуем ошибку по журналу регистрации. При падении обмена открываем журнал регистрации в базе-приемнике или файл отчета об ошибке. Находим имя реквизита или объекта метаданных, на котором произошел сбой (например, исключение вида «Поле объекта не обнаружено»).
2. Выгружаем обновленную структуру метаданных. С помощью внешней обработки MD83Exp.epf выгружаем структуру метаданных из обновленной базы в файл XML.
3. Загружаем метаданные в конфигурацию «Конвертация данных». Открываем конфигурацию конвертации, переходим к структуре метаданных соответствующей конфигурации и загружаем новый файл XML в режиме замещения существующих объектов.
4. Корректируем правила конвертации свойств (ПКС). Находим проблемный объект и реквизит. Если реквизит был переименован в типовой конфигурации, выбираем новое имя из обновленного списка метаданных. Если реквизит устарел и больше не нужен — просто отключаем его передачу в правилах.
5. Выгружаем готовые правила. Сохраняем итоговый файл правил обмена и загружаем его обратно в настройку обмена. Весь процесс обычно занимает не более 10–15 минут.

Способ 2. Минимизация состава переносимых реквизитов

Чтобы правила требовали меньше внимания при последующих обновлениях, рекомендуется соблюдать ряд правил при их проектировании:

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

Способ 3. Использование универсальной обработки «Выгрузка и загрузка данных XML»

Если обмен происходит между абсолютно идентичными конфигурациями одинакового релиза, использование механизмов КД 2.0 часто бывает избыточным. Для таких задач на ИТС предоставляется внешняя обработка ВыгрузкаЗагрузкаДанныхXML.epf.

Она выгружает данные в формате XML напрямую по структуре метаданных без написания правил обмена. Однако у стандартной версии этой обработки есть неудобство — в пользовательском режиме не сохраняются флажки выбранных для переноса объектов.

Решим эту проблему доработкой обработки:

1. Откроем обработку в режиме Конфигуратор.
2. В дереве реквизитов обработки найдем реквизит ДеревоМетаданных. В свойствах реквизита установим свойство Сохраняемые данные (флаг сохранения значений).
3. Либо добавим программное сохранение отмеченных веток в системное хранилище настроек при закрытии формы и их восстановление при открытии.

Обратите внимание: данный способ требует строго одинаковых релизов баз. Если одна из баз будет обновлена раньше другой, перенос данных через эту обработку завершится ошибкой несоответствия типов XML.

Способ 4. Переход на штатные архитектурные решения платформы

Если требуется регулярный регламентный обмен между базами, рассмотрим более отказоустойчивые решения:

1. Распределенная информационная база (РИБ). Если конфигурации идентичны, создание РИБ снимает проблему несовместимости структуры. Центральный узел передает изменения конфигурации в подчиненные базы вместе с данными, и обмен не запустится до тех пор, пока подчиненный узел не применит обновление.
2. Синхронизация через универсальный формат (EnterpriseData / КД 3.0). Обмен через формат EnterpriseData абстрагирован от физической структуры базы. Разработчики «1С» при выпуске новых версий типовых конфигураций сами обновляют внутренние обработчики выгрузки под формат XDTO, благодаря чему изменения названий внутренних реквизитов не нарушают обмен.