Контролируемый обмен данными - это механизм построения многоузловой базы из нескольких информационных баз на платформе "1С:Предприятие" с быстрой репликацией всех изменений или их части с поддержкой ссылочной целостности. Главные отличия от РИБ:
- Конфигурации узлов не обязаны совпадать
- Вместо таблиц регистрации изменений используются отметки времени
- Нет квитирования (КОД полагается на гарантированную доставку изменений)
- Изменения передаются не одним большим сообщением, а множеством маленьких, что удобно для обмена через шины вроде Kafka или RabbitMQ
- Есть встроенный механизм контроля ссылочной целостности
- Используется не XML, а JSON
Многоузловая база состоит из центрального узла и подчиненных узлов. Сведения о них хранятся в иерархическом справочнике УзлыКОД с предопределенным элементом ЭтотУзел.
Данные, участвующие в обмене, включены в подсистему КОД и подписки подсистемы ОтметкиВремени и при записи получают отметки времени, хранящиеся в специализированных регистрах. Отметки используются как для определения изменений, подлежащих отправке, так и для контроля коллизий.
Регулярная отправка и получение данных выполняются регламентными заданиями "Диспетчер отправки КОД" и "Диспетчер получения КОД", работающими независимо. Код разделен на общие модули КОДПолучение и КОДОтправка, с общими процедурами и функциями в модулях КОДСервер и КОДСлужебный.
Отметка времени - это строка, хранящая универсальную дату в миллисекундах в формате "YYYYMMDDHHmmssuuu". Отметки времени ссылочных данных хранятся в разрезе ссылок. Удаление объекта - это наличие отметки без самого объекта по ссылке. Отметки времени наборов записей регистров хранятся в разрезе ключей. Ключ - это строка JSON, содержащая значения основных отборов набора записей. Внутри это массив JSON из пар "свойство - значение", где имя свойства определяет тип значения измерения, а значение представляет само значение:
[{"dateTime":"2020-07-27T16:03:05"},{"390c64d9-1ef8-11e9-8a62-0050569f6126":"714c9c28-cffd-11ea-80e7-0050569f6c88"},{"390c648a-1ef8-11e9-8a62-0050569f6126":"aa00559e-ad84-4494-88fd-f0826edc46f0"}]
Примитивные типы описываются именами соответствующих им типов в XML ("string", "dateTime", ...), ссылочные - УИДами идентификаторов объектов метаданных, поэтому ключ одного и того же набора в разных узлах будет отличаться. Значения перечислений сериализуются как их идентификаторы, хранящиеся в РС ИдентификаторыЗначенийПеречислений.
КОД - не единственный потребитель подсистемы ОтметкиВремени.
Сообщение - это файл JSON вида:
<Отправитель>to<Адресат>at<Отметка времени>-<Номер сообщения>.json
- Отправитель - код узла-отправителя
- Получатель - код узла-адресата
- Отметка времени - отметка времени начала сеанса отправки
- Номер сообщения - номер сообщения в сеансе отправки
Сообщение содержит единственный объект message со свойствами header и body. Заголовок (header) содержит коды отправителя и получателя и версию обмена (сейчас всегда 1). Тело (body) содержит массив объектов object со свойствами #ns (пространство имен, для текущей версии "http://v8.1c.ru/doc8/CDE/1"), #type (тип формата "Справочник.Контрагенты") и #value (собственно данные, чья структура определяется XDTO-пакетом).
Отправитель объединяет в одно сообщение данные, связанные ссылками, а получатель записывает каждое сообщение в своей транзакции, чтобы обеспечить ссылочную целостность. Сообщения с одной отметкой времени, но с разными номерами, принимаются параллельно. Сообщения с последовательными отметками принимаются последовательно.
XDTO-пакет КОД_1 содержит описание всех данных, участвующих в обмене. Сериализация и десериализация выполняются полностью автоматически, если:
- Существует объект XDTO с полным именем объекта метаданных ("Справочник.Контрагенты", "РегистрСведений.ТекущиеСостоянияДокументов").
- Его структура и свойства совпадают со структурой и свойствами объекта метаданных: например, реквизитам соответствуют одноименные свойства объекта, табличным частям - одноименные списки и т.д. Объекты XDTO для наборов записей регистров должны содержать:
- Свойство Отбор с подчиненными свойствами для значений измерений из основного отбора;
- Список Записи с ресурсами, реквизитами и измерениями вне основного отбора.
Примитивные типы передаются типами из пространства XML ("decimal", "string", "dateTime", "boolean"). Для ссылок в XDTO-пакете КОД_1 предусмотрен тип Ссылка. Для составных типов, которые могут содержать значение Неопределено, следует установить флаг "Возможно пустое". Для составных типов, содержащих и ссылочные, и примитивные типы, используется тип XML anyType.
Менеджеры объектов могут переопределить сериализацию и десериализацию (процедуры ПриЗаписиВСообщениеКОД, ПриЧтенииИзСообщенияКОД модулей менеджеров), чтобы включить в состав объекта XDTO данные, хранящиеся вне объекта метаданных (например, так передаются пароли учетных записей почты и реквизиты писем, хранящиеся в отдельных регистрах), или не передавать часть данных (например, в составе справочника Пользователи не передается идентификатор пользователя ИБ). В этом случае объект XDTO может не соответствовать метаданным.
Встроенный контроль (КОДСервер.ПроверитьСоответствиеМетаданныхПакетуОбмена) выполняется при каждом обновлении ИБ. Исключения, вроде упомянутых выше, описываются переопределением процедуры ПриОпределенииИсключенийКОД модуля менеджера.
Обработка ОписаниеМетаданныхДляКОД автоматически создает XSD-схему по метаданным, которую можно загрузить в пакет обмена, но не учитывает переопределение в менеджерах. Результирующую XSD-схему нужно исправлять вручную, или реализовать учет переопределений в обработке.
Цикл регулярной отправки состоит из выборки изменений, их рассмотрения с определением адресатов и отправки с предварительным делением на потоки. Выборка изменений с рассмотрением начинаются, не дожидаясь завершения отправки: таким образом, когда сеанс отправки завершится, для следующего сеанса уже будет готова порция выбранных и рассмотренных изменений.
Регламентное задание "Диспетчер отправки КОД":
- Выбирает порцию данных, непрерывную по отметкам, от текущей границы рассмотрения изменений;
- Рассматривает их, определяя узлы-адресаты для каждого измененного элемента данных;
- Делит рассмотренные изменения на потоки отправки;
- Запускает фоновые задания отправки, формирующие сообщения с общей отметкой начала сеанса отправки, но разными номерами;
- Записывает сведения об отправке и рассмотрении и сдвигает границу рассмотрения изменений.
Текущая граница рассмотрения (отметка) хранится в константе ГраницаРассмотренияКОД. Выброрка изменений выбирает ограниченную порцию изменений (захардкодено) так, чтобы выбранные изменения ссылочных данных и наборов записей не превышали по объему эту порцию и были непрерывны от текущей границы. Изменения, которые будут зафиксированы длящимися в этот момент транзакциями, выбирают и отправляют отдельные задания "Отправка пропущенных изменений КОД".
Рассмотрение распределяет каждый элемент выбранных изменений по узлам-адресатам, куда эти данные следует отправить. Правила рассмотрения:
- Данные из подчиненного узла, участвующие в обмене, полностью отправляются в центральный узел.
- НСИ (точнее, данные, включенные в подсистему КОД.НСИ) полностью отправляется во все узлы.
- Данные, не относящиеся к НСИ, делятся на зависимые и самостоятельные переопределением процедуры модуля менеджера ПриОпределенииПоляВладельцаДанных (данные без владельца - самостоятельные). После чего: 3.1. Самостоятельные данные (например, документы) отправляются в узлы пользователей, имеющих права на них. 3.2. Зависимые данные (например, файлы документов) отправляются в узлы вместе с самостоятельными данными.
- Данные, однажды отправлявшиеся в узел, будут отправляться в него повторно, даже если текущее состояние прав доступа этого не требует, чтобы в узлах не накапливались неактуальные версии данных.
Паралеллизмом отправки управляет константа МаксимальноеЧислоПотоковОтправкиКОД. Ее значение определяет максимальное число фоновых заданий отправки, которые будут запущены после рассмотрения. При установке в 0 отправка прекращается. Правила деления на потоки:
- В потоке не может быть данных меньше, чем МинимумОбъектовДляФоновогоЗадания().
- Зависимые данные, относящиеся к одному элементу самостоятельных данных (например, файлы документа), и эти самостоятельные данные попадают в один поток. Это резко снижает вероятность того, что параллельные потоки отправят одни и те же данные.
- Потоков не может быть больше, чем МаксимальноеЧислоПотоковОтправкиКОД.
Поток отправки изменений:
- Сериализует доставшуюся ему порцию изменений с помощью фабрики XDTO.
- Рассчитывает хеш сериализованных объектов и не отправляет те, что уже отправлялись с таким хешем.
- Добавляет к ним данные, которые по ссылкам также требуется отправить в узлы-адресаты.
- Формирует сообщения так, чтобы данные, объединенные ссылками друг на друга, оказались в одном сообщении.
- Записывает сообщения, возвращая диспетчеру отправки сведения о состоявшейся отправке.
Для уменьшения количества файлов в каталоге, снижающего производительность функции НайтиФайлы() в Windows, сообщения записываются в каталоги минут с именами формата YYYYMMDDHHmm.
Выполняется при отправке и гарантирует, что вместе с данными будут отправлены другие необходимые данные, связанные ссылками с отправляемыми. Работает это так:
- Ссылки в отправляемых данных и отправляемые данные ссылочного типа откладываются для контроля.
- Из ИБ выбираются контролируемые данные по ссылкам в отправляемых данных и по ссылкам на отправляемые данные ссылочного типа.
- Из выбранных контролируемых данных исключаются те, что уже отправлялись адресатам с актуальными отметками.
- Контролируемые данные сериализуются, и процесс итеративно повторяется, пока новые контролируемые данные не перестанут появляться.
По умолчанию считается, что все данные по ссылкам, участвующие в обмене, необходимы. Контроль ссылочной целостности можно ослабить, переопределив процедуру ПриОпределенииКонтролируемыхСсылок модуля менеджера. Ей передаются структуры ВОбъекте и НаОбъект, содержащие потенциальные контролируемые ссылки. Все свойства этих структур при переопределении следует установить в Истина (данные по ссылке необходимы) или Ложь (данные по ссылке отправлять не обязательно). Неинициализированное значение (Неопределено) приведет к ошибке.
Конечно же, одновременно с ослаблением контроля ссылочной целостности следует обеспечить нормальное функционирование самих объектов при наличии битых ссылок в них (если отключаются ссылки ВОбъекте) и при отсутствии некоторых ссылающихся данных (если отключаются ссылки НаОбъект).
Нормальная работа механизмов рассмотрения и контроля ссылочной целостности требует сведений о наличии данных в других узлах и о том, с какой отметкой эти данные в последний раз рассматривались. Они хранятся в регистрах сведений НаличиеСсылочныхДанныхВУзлахКОД, НаличиеНаборовЗаписейВУзлахКОД, ОтметкиРассмотренияСсылочныхДанных и ОтметкиРассмотренияНаборовЗаписей.
Сведения об отправке возвращаются из фоновых заданий отправки в диспетчер отправки, дедуплицируются, объединяются со сведениями о рассмотрении и записываются отложенно, параллельными фоновыми заданиями, без ожидания их завершения. Иногда это приводит к повторной отправке уже отправленных данных, что немного ухудшает производительность.
При переводе пользователя в другой узел КОД переносит его данные, порционно, от свежих к более старым. Текущая граница переноса хранится в РС ГраницаПереносаИсторическихДанныхКОД в разрезе узлов (не пользователей) и сбрасывается на текущую каждый раз при переводе пользователя в новый узел. Предполагается, что проход по уже перенесенным данным будет достаточно быстрым.
Переносом занимается регламентное задание ПереносИсторическихДанныхВУзлыКОД, которое:
- Выбирает по отметкам порцию данных назад от границы переноса, такую, чтобы:
- Данные были доступны по правам пользователям узла-адресата
- Данные с текущими отметками еще не отправлялись в узел-адресат
- Отправляет найденные данные в узел-адресат.
- Сдвигает границу переноса исторических данных.
Если отметки времени включены не с самого начала использования ИБ, перед переносом исторических данные следует проставить им отметки. Задание ПереносИсторическихДанныхВУзлыКОД делает это автоматически, если константой ГраницаОтметокВремениИсторическихДанных задана текущая граница установки этих отметок. Константа хранит две границы (доступно редактирование из формы константы):
Текущая граница - граница, с которой отметки времени уже проставлены, и до которой отметки еще предстоит установить; Начальная граница - граница, на которой установку отметок следует закончить, и к которой следует приписать данные без дат или с пустой датой.
Отметки самостоятельных данных устанавливаются по полю даты (для документов, процессов и задач это стандартный реквизит Дата, для периодических регистров - период, для прочих данных требуется переопределение функции модуля менеджера ПолеДанныхДляХронологическойВыборки). Отметки зависимых данных устанавливаются по самостоятельным.
Отметки записываемых данных оказываются доступны диспетчеру отправки КОД только после завершения транзакций, которые могут быть длинными. Кроме того, разница во времени между рабочими серверами может оставить часть данных пропущенными, а граница рассмотрения уйдет вперед. Для отправки пропущенных вследствие этого есть регламентные задания "Отправка пропущенных изменений КОД (ночное)" и "Отправка пропущенных изменений КОД (круглосуточное)".
Круглосуточное выбирает пропущенные изменения в серии увеличивающихся интервалов перед границей рассмотрения. Пропущенными считаются изменения с отметками, которым не соответствуют такие же отметки рассмотрения. Ночное выбирает пропущенные изменения за сутки.
Пропущенные изменения отправляются адресатам обычным образом.
Регламентное задание "Диспетчер получения КОД":
- Выбирает порцию сообщений к получению,
- Сперва выбирая каталоги минут,
- А затем, в хронологическом порядке, выбирая сообщения из каталогов минут до достижения предела порции (предел захардкоден).
- Делит их на потоки для параллельного получения.
- Параллельно принимаются сообщения с одной и той же отметкой начала сеанса отправки, но с разными номерами сообщений.
- Предпринимается попытка равномерно загрузить потоки отправки. За вес сообщения принимается его размер.
- Паралеллизм получения ограничен константой МаксимальноеЧислоПотоковПолученияКОД (0 - получение отключено).
- Запускает фоновые задания получения и дожидается их завершения.
- Удалив пустые каталоги минут вызовом команды "CMD RD", переходит к следующей порции сообщений.
Многие данные требуют обновления других данных после загрузки. Например, после загрузки контрагентов и пользователей обновляется адресная книга, после загрузки писем - регистр сведений КраткиеОписанияПисем и т.д. Кэширующие данные через обмен не передаются.
Такого рода постобработка реализуется переопределением процедур ПередЗаписьюПрочтенногоИзСообщенияКОД() и ПриЗавершенииЧтенияСообщенияКОД() модуля менеджера. Первая процедура вызывается перед записью данных и позволяет сопоставить записываемые данные с версией в ИБ и оптимизировать постобработку с учетом этого. Вторая вызывается после записи всех данных, но до завершения транзакции чтения сообщения и позволяет гарантированно обновить связанные данные. Поскольку порядок объектов в сообщении не гарантирован, рекомендуется сперва запоминать требующие обновления данные вызовом КОДПолучение.ДобавитьДанныеДляОбработкиПриЗавершенииЧтенияСообщения(), а затем пакетно обрабатывать их, получив ДанныеДляПостобработки параметром процедуры ПриЗавершенииЧтенияСообщенияКОД().
Пакетное обновление связанных данных писем, вызываемое при записи множества объектов, сейчас реализовано вызовом общих процедур общего модуля КОДПереопределяемый.
Обновление связанных данных, которое можно выполнить после загрузки, вне транзакции чтения сообщения, реализовано через регистр сведений ДанныеДляОтложеннойОбработки. Сейчас туда помещаются:
- Сведения для отложенного определения дескрипторов, если определение в транзакции завершилось исключением.
- Сведения для обновления веток переписки при загрузке писем и связей между ними.
- Замеры времени КОД.
Данные обрабатываются регламентным заданием ОтложеннаяОбработкаПриПолученииСообщенийКОД.
Для создания многоузловой базы достаточно заполнить справочник УзлыКОД во всех узлах (сам справочник в обмене не участвует). Для этого нужно:
-
Включить функциональные опции ИспользоватьОтметкиВремени и ИспользоватьКОД.
-
В списке справочника УзлыКОД вызвать команду "Инициализировать этот узел", которая удалит существующие элементы и создаст предопределенный узел ЭтотУзел с новым идентификатором. Дать этому узлу говорящее наименование и двузначный код.
-
Создать элементы для узлов-корреспондентов:
- Вставить в формы новых узлов их идентификаторы, скопированные из форм элементов ЭтотУзел в ИБ этих узлов так, чтобы обеспечить соответствие идентификаторов.
- Дать им говорящие наименования и коды, соответствующие кодам в ИБ этих узлов.
- При описании подчиненных узлов в ИБ центрального подчинить создаваемые элементы этому узлу, как родителю; при описании центрального узла в ИБ подчиненного указать его как родителя этого узла.
- Указать каталог обмена (общую папку, доступную всем узлам).
- Установить границу рассмотрения КОД на дату, с которой следует начать синхронизацию (например, на сегодняшнюю дату), и задать паралеллизм константами МаксимальноеЧислоПотоковОтправкиКОД и МаксимальноеЧислоПотоковПолученияКОД. Высокая степень паралеллизма означает быструю синхронизацию, но повышенную нагрузку на сервер.
При добавлении новых объектов метаданных, участвующих в КОД, следует:
- Включить их в состав определяемых типов СсылкиДляКОД, СсылкиДляОтметокВремени, СсылочныеОбъектыДляОтметокВремени, НаборыЗаписейРегистровДляОтметокВремени.
- Включить их в состав плана обмена КОД без авторегистрации.
- План обмена - атавизм, используется исключительно для определения объектов, участвующих в обмене.
- Данные, мигрирующие без отбора, включить в состав подсистемы КОД.НСИ.
- Создать соответствующий объект XDTO в пакете КОД_1.
- Реализовать программный интерфейс КОД в модуле менеджера.
- Например, скопировав у другого объекта метаданных и очистив переопределенный код.
- Для нестандартных зависимых данных (тех, чьим владельцем не является Регистратор или Владелец) переопределить процедуру ПриОпределенииПоляВладельцаДанных().
- Взвести версию конфигурации и запустить обновление ИБ для автоматической проверки.
При изменении существующех объектов следует актуализировать XDTO-пакет КОД. При добавлении новых свойств рекомендуется устанавливать свойство "Минимальное количество" в 0, чтобы получать сообщения, созданные предыдущей версией конфигурации. Для удаления и переименования свойств хороших паттернов, позволяющих сохранить совместимость, сейчас нет, нужно просто актуализировать XDTO-пакет.
В случае несовместимости пакетов предлагается останавливать отправку (например, установив в 0 константу МаксимальноеЧислоПотоковОтправкиКОД), дожидаться получения всех сообщений очереди и лишь после этого обновлять конфигурацию.
При создании пользователей лучше сразу делать это в их родном узле и указывать этот узел в карточке пользователя. При необходимости перевести пользователя в другой узел следует:
- Изменить этот узел в карточке пользователя, вручную или обработкой ПереводПользователейВДругойУзелКОД (доступна по команде в подменю "Еще" списка пользователей), после чего:
- Свежие (вновь записываемые) данные пользователя начнут отправляться в новый узел;
- Граница переноса исторических данных будет установлена на текущую дату, и исторические данные пользователя начнут отправляться в новый узел.
- В новом узле обработкой РазрешениеВходаВЭтотУзелКОД (также доступна по команде в подменю "Еще" списка пользователей):
- Проверить, перенесены ли исторические данные за минимально необходимый пользователю период;
- Разрешить вход в этот узел. При этом пользователю будет выслано письмо с описанием нового узла.
Разрешение входа в узел всего лишь разрешает вход и создает пользователя ИБ лишь при необходимости. КОД пытается автоматически создать пользователей ИБ в других узлах, не разрешая вход, чтобы поддержать работу Системы взаимодействия. Идентификаторы пользователей ИБ при этом отличаются, а вот пароли совпадают. Автоматическое создание пользователей ИБ - функционал, появившийся в июне 2020, и масса ранее созданных пользователей ИБ имеют случаные пароли.
Несколько метрик служат для контроля нормальной работы КОД.
В норме не должна превышать нескольких мегабайт, в пике (рассылки) - нескольких десятков мегабайт. Проблемой является стабильное превышение критического значения.
В норме не должно превышать 10 с. При стабильном превышении следует разобраться с производительностью узла-получателя, особое внимание обратив на блокировки по ТЖ.
В норме должно быть порядка 20 с. Метрика отсчитывает полный путь входящего письма от его создания в узле-отправителе до появления в узле-получателе.
В норме должно быть не более 10 с. Отставание свидетельствует о перегруженности узла-отправителя другими процессами (например, маршрутизацией письма-рассылки) или процессами КОД (например, отправкой большого объема исторических данных).
В норме должно быть не более 10%. Показывает долю данных, которые узел отбрасывает, поскольку ранее уже получил их, и служит мерой эффективности деления отправляемых данных на потоки отправки.
Контроль соответствия метаданных XDTO-пакету не закрывает всех ошибок и не спасает при попытке получить сообщения, созданные конфигурацией другой версии. В этом случае можно подменить схему, загрузив ее из файла по команде в списке узлов КОД. Схема хранится в константе ХранилищеСхемыДанныхКОД. Получение схемы из хранилища и инициализация ею фабрики XDTO - операции затратные, и такой подменой следует пользоваться лишь в критических случаях.
Расширением изменить XDTO-пакет нельзя.
Источники этой проблемы устранены. На случай, если узел-отправитель по каким-то причинам снова создаст множество сообщений с дублирующимися данными, получение которых приводит к блокировкам, следует снизить паралеллизм получения (и, если еще не поздно - паралеллизм отправки).
- Несмотря на то, что ошибки, приводившие к массовому появлению дубликатов в отправляемых данных, исправлены, дубликаты все еще появляются.
Главная причина - это отложенная запись сведений об отправке, из-за чего следующий сеанс может найти по ссылкам и повторно отправить данные, уже отправленные предыдущим сеансом. Отказываться от отложенной записи совсем не хочется. Возможно, следует сразу записывать сведения об отправке самостоятельных данных, а отложенно - все остальные.
Другая причина - это работа заданий отправки пропущенных данных. При внутренней маршрутизации рассылок бывает много параллельных и длинных транзакций, что создает значительный объем пропущенных изменений. Отправка пропущенных изменений работает параллельно с регулярной отправкой и может подхватить отправляемые ею данные.
- Отправка исторических данных идет небыстро.
Каждое изменение узла в карточке пользователя сбрасывает границу переноса на текущую, а даже холостой пробег по историческим данным без их отправки - операция тяжелая. Возможно, все же стоит хранить несколько границ, и вместо сдвига границы добавлять новую на текущую дату. Отправка исторических данных должна работать параллельно со всеми границами.
- Параллельная запись рассылок в узле-получателей идет небыстро (5-7 с).
Причина неясна, анализ ТЖ пока мало что дал. Возможно, что даже до переделки архитектуры почты удастся найти ресурс к оптимизации здесь.
- Последовательность данных в сообщении произвольна, что изредка может приводить ко взаимоблокировкам (сейчас их немного).
Следует сделать сортировку согласно порядку в метаданных в отправителе или в получателе.
Ряд объектов (Справочник.УчетныеЗаписиЭлектроннойПочты, Справочник.Пользователи, Документ.ВходящееПисьмо, Документ.ИсходящееПисьмо) имеет XDTO-описания, не вполне соответствующие метаданным. Это препятствует автогенерации XDTO-пакета. Обработку ОписаниеМетаданныхДляКОД следует научить запрашивать об этих исключения сами объекты метаданных, чтобы генерация XDTO-пакета была полностью автоматической.
Механизм разрешения коллизий сейчас молча жертвует версией подчиненного узла в пользу центрального (исключением являются брони, задачи и процессы со своей логикой разрешения коллизий). Пользователь никак не информируется об этом. Надо бы как-то выводить эти сведения, хотя бы в формах частотных объектов вроде документов и файлов.
Механизм разрешения коллизий по процессам и задачам некритически заимствован из РИБ, и, по словам А.Курушина, недостаточно хорош.
Интерфейс тяжеловат, для типовой его стоит упростить.
Единственный механизм, который КОД сейчас предоставляет для обмена данными с разными версиями метаданных - это совместимость на уровне XDTO-пакета. Например, для новых реквизитов можно поставить "Минимальное количество = 0", и новые версии конфигурации примут сообщения старых версий. Переименование реквизитов также можно поддержать созданием нового реквизита со свойством "Минимальное количество = 0". Пакет также можно подменить в режиме Предприятия, загрузив в константу выгруженную XSD-схему (это несколько замедлит обмен, поскольку каждый сеанс КОД будет создавать фабрику XDTO из тяжелого макета).
Есть, однако, проблемы с более тяжелыми изменениями метаданных, например:
- Новые объекты метаданных. Что узел старой конфигурации должен делать с новыми объектами?
- Изменение структуры регистра сведений. Как реструктуризировать накопленные отметки? Что узел-получатель должен делать с наборами записей иной структуры?
Следует решить, в каком объеме КОД будет поддерживать версионирование: только ли на краткий период обновления всех узлов? Или режим с разными версиями ИБ узлов будет рабочим? Какого рода изменения метаданных мы будем поддерживать, а какие - нет?
КОД первого поколения для конфигурации "Документооборот Почты России" включал в себя механизм восстановления узлов данными других узлов при потере. При разработке второго поколения механизм восстановления не тестировался и, скорее всего, сломан. Для типовой следует принять решение либо о вырезании механизма восстановления, либо о его восстановлении.