При настройке обмена через Универсальный формат (EnterpriseData) с использованием Конвертации данных 3.0 (КД 3.0) нередко возникают ситуации, когда структуры баз источника и приемника не совпадают. Разберем интересную задачу: в базе-источнике (База 1) есть справочник Номенклатура с дополнительными реквизитами, но справочника ХарактеристикиНоменклатуры физически не существует. В базе-приемнике (База 2) присутствуют оба справочника, и доп. реквизиты должны стать свойствами характеристики. Посмотрим, как создать и выгрузить несуществующий (виртуальный) объект, чтобы при синхронизации в Базе 2 обновились и номенклатура, и ее характеристика.
Стандартными средствами сопоставления объектов решить эту задачу не получится, так как выгружать из Базы 1 банально нечего. Рассмотрим, как можно обойти это ограничение. Мы можем программно сформировать структуру на стороне источника, заполнить её необходимыми данными и принудительно отправить в файл обмена так, словно этот объект реально существует в базе.
Проанализируем процесс отправки. В Базе 1 нам необходимо перехватить момент выгрузки номенклатуры. Для этого отлично подойдет обработчик ПОД_Номенклатура_ПриОбработке. В нем мы создадим структуру, которая будет имитировать данные для справочника характеристик.
В эту структуру необходимо поместить все свойства формата этого справочника, которые являются обязательными (наименование, владелец и другие ключевые поля). После того как структура сформирована, мы передаем её в типовую процедуру выгрузки XDTO:
ОбменДаннымиXDTOСервер.ВыгрузкаОбъектаВыборки(КомпонентыОбмена, СтруктураДляХарактеристики, КомпонентыОбмена.ПравилаОбработкиДанных.Найти("ПОД_Характеристика_Отправка", "Имя"));
Таким образом, механизм КД 3.0 обработает нашу структуру по правилам выгрузки характеристик (ПКО) и поместит её в XML-файл обмена как полноценный объект.
При создании «виртуальных» объектов крайне важно обеспечить постоянство их уникальных идентификаторов. Если каждый раз генерировать новый GUID (например, через функцию Новый УникальныйИдентификатор()), то в базе-приемнике при каждой синхронизации будут плодиться дубли характеристик.
Разберем, как этого избежать. Идентификатор виртуальной характеристики должен формироваться по жесткому алгоритму, опирающемуся на неизменные данные. Например, можно вычислять хэш от GUID самой номенклатуры и значений дополнительных реквизитов. В КД 3.0 сгенерированный GUID необходимо поместить в поле КлючОбъекта нашей структуры перед передачей её в процедуру выгрузки.
Чтобы КД 3.0 корректно превратила переданную структуру в XDTO-пакет, проанализируем настройки Правил Конвертации Объектов (ПКО). В ПКО для характеристики в качестве типа данных источника следует указать Структуру. Механизм конвертации автоматически сопоставит ключи этой структуры с именами свойств XDTO-пакета, что избавит вас от написания лишнего кода.
Выясним причину возможных ошибок загрузки связанных объектов. При программной генерации характеристики важно правильно заполнить свойство Владелец. В структуре для выгрузки это должна быть либо ссылка на саму номенклатуру (которую алгоритм КД 3.0 сам преобразует в форматную ссылку), либо структура поиска. Если проигнорировать этот момент, характеристика в базе-приемнике будет создана без привязки к элементу номенклатуры.
Иногда дополнительные реквизиты (ПВХ) отказываются загружаться стандартным механизмом EnterpriseData из-за различий во внутренних идентификаторах свойств. Рассмотрим, что делать в этом случае.
AdditionalInfo (или ДополнительныеРеквизиты формата обмена).ПКО_Характеристика_ПослеЗагрузкиДанных (в модуле менеджера обмена).ДополнительныеСвойства загружаемого объекта. Распарсив переданную структуру, мы программно записываем нужные значения дополнительных реквизитов в характеристику.В качестве альтернативы программному вызову выгрузки выборки можно рассмотреть механизм ИнформацияОбОбъекте. Этот функционал позволяет встроить данные подчиненного объекта непосредственно в сообщение об основном объекте (владельце). Однако подход с ВыгрузкаОбъектаВыборки является более универсальным и прозрачным, так как формирует самостоятельный узел в пакете EnterpriseData, который стандартно читается любыми типовыми правилами принимающей стороны.