От экспертов «1С-Рарус»: 1С:Конвертация данных 3 и применение расширения формата обмена

Введение

В данной статье мы делимся своим опытом работы с конфигурацией «Конвертация данных, редакция 3.0» и практическими аспектами.

Глоссарий принятых сокращений размещён в конце статьи. Перейти к нему для ознакомления можно по ссылке.

Возникновение нового подхода к обмену в типовых решениях 1С

Начнем с небольшой исторической вводной и некоторых рассуждений в части концепта применения двух конвертаций существующих на данных момент от фирмы «1С». В апреле 2015 года фирма «1С» выпустила новый программный продукт «Конвертация данных 3.0», а также представила новую технологию обменов между типовыми решениями 1С. Эту же технологию можно применять для обмена между приложениями в режиме сервиса, если используются разные сервисы, а также для обмена со сторонними приложениями.

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

При этом уже знакомые нам технологии обмена, такие как обмены по правилам КД2 (1С:Конвертация данных 2.x), обмены между идентичными конфигурациями (выгрузка-загрузка данных XML, РИБ), не ушли в прошлое, а продолжают использоваться для своих задач.

Однако, с развитием программных продуктов 1С возникали новые задачи, для которых ранее известные нам технологии обмена требовали усовершенствования. Немалое значение имел также тот факт, что в результате развития программных продуктов одноприродные (такие как документы закупки, списания, документы движения денег, справочники структуры организации, номенклатуры и т. п.) по смыслу объекты в различных решениях со временем приобретали все более схожую структуру, которую можно было описать с помощью единого формата для этих типов объектов.

Поэтому для новой технологии был разработан формат данных, созданный на основе таких стандартизованных объектов. И конфигурации в формате КД3 (1С:Конвертация данных 3.x) обмениваются между собой именно с помощью этого промежуточного звена — формата Enterprise Data (ED). Это позволяет использовать технологию обмена не только между конфигурациями на платформе «1С:Предприятие», а между базой 1С и любой программой, которая может работать с форматом ED, считывать и загружать данные в нужном формате.

Кроме того, важным преимуществом формата КД3 является то, что при изменении одной из конфигураций в обменной схеме потребуется изменить лишь формат ED, а не каждый xml файл правил на вход/выход для каждой конфигурации по соседству как было бы с измененной в цепи обмена посредством КД2.

Главной особенностью КД3 является концепция конвертации данных. Источник — its.1c.ru/db/metod8dev/content/5846/hdoc

На рисунке выше видно, что основное отличие КД3 от КД2 — наличие промежуточного звена обмена данными, а именно формата EnterpriseData. Данные, подлежащие выгрузке представляются в виде формата XDTO, и база-приемник работает уже с данными, сконвертированными в объект формата.

На стороне конфигуратора 1С формат ED представлен следующими основными объектами:

• Несколькими XDTO-пакетами:

  

• Общим модулем «МенеджерОбменаЧерезУниверсальныйФормат», в котором содержатся правила конвертации и обработки объектов в/из объекты формата.
• Планом обмена «СинхронизацияДанныхЧерезУниверсальныйФормат».
• Общими модулями «ОбменДаннымиXDTOСервер», «ОбменДаннымиПереопределяемый», «ОбменДаннымиСобытия».
• Обработкой «КонвертацияОбъектовXDTO».
• А также подписками на события, регистром сведений «НастройкиОбменаДаннымиXDTO».

Формат ED включают в себя описание бизнес-сущностей из различных областей хозяйственно-экономической деятельности предприятия и является расширяемым. С каждой версией формата ED фирма «1С» добавляет в него описание новых сущностей и расширяет существующие новыми полями.

Номера версий формата ED состоят из X.Y.Z, где X.Y. — это Major версия, Z — это Minor версия.

Как видно, для описания объектов формата уже существует несколько пакетов XDTO под различные версии. Изменение Minor версии не приводит к потери совместимости с предыдущими minor весиями. Major версии не имеют обратной совместимости.

Фирма «1С» гарантирует 1 год поддержки с момента выхода major-версии. По ссылке its.1c.ru/db/metod8dev#content:5934:hdoc можно увидеть все версии и сроки их поддержки детально.

Внимание! Если Вы уже знакомы с алгоритмом синхронизации данных в типовых решениях, то можете пропустить следующий раздел и сразу перейти к описанию решения задачи расширения обмена.

Сейчас типовые конфигурации 1С массово используют новый подход с применением универсального формата ED. Рассмотрим, как выполнить обмен посредством XDTO на примере конфигураций «1С:Управление предприятием общепита» (далее — УПО) и «1С:Бухгалтерия предприятия 3.0» (далее — БП).

Пример настройки синхронизации между типовыми решениями «1С:Управление предприятием общепита» и «1С:Бухгалтерия предприятия 3.0»

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

Аналогичные действия необходимо произвести во второй базе — УПО (1С:Управление предприятием общепита). В этой же форме для обеих баз нам понадобится задать их префиксы (см. рисунок выше), они пригодятся нам при настройке обмена для идентификации узла.

Настройка обмена посредством формата КД3 происходит последовательно:

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

В первую очередь необходимо задать настройки обмена. Для этого перейдем по гиперссылке «Настройки синхронизации данных». Здесь отображается список настроенных обменов с каждой из баз. По кнопке «Создать» откроется форма настройки нового обмена.

Стоит отметить, что помимо возможности создать настройку обмена с типовой конфигурацией 1С из предложенного списка, пользователь может воспользоваться настройкой «Другая программа» для возможности обмена с любой другой конфигурацией или программой, использующей формат ED.

Мы настраиваем в нашем случае обмен между УПО и БП, поэтому выберем пункт «1С:Бухгалтерия предприятия, ред. 3.0». Открывается помощник настройки обмена, который подсказывает пользователю последовательность действий для осуществления корректной настройки обмена:

Сперва необходимо настроить параметры подключения баз друг к другу: можно выбрать прямое подключение, подключение к базе посредством интернета, если база опубликована на веб-сервере, а также подключение посредством файла. Рассмотрим третий вариант — флаг «Загрузить параметры подключения из файла» не устанавливаем, т. к. они пока отсутствуют:

На следующей странице выбираем один из вариантов, посредством которого будем обмениваться файлами. В нашем примере выберем каталог:

На следующем шаге задаем имя файла настроек подключения, который выгрузится из УПО по окончанию работы этого шага, а позже будет считан на стороне БП. Также указываем префикс узла второй программы, мы ранее задали его на стороне базы «1С:Бухгалтерия предприятия 3.0» как БП. Префикс в настройке на стороне УПО и в базе БП должны совпадать и не дублироваться в других синхронизациях. Нажимаем «Далее», и ждем завершения формирования файла настроек.

Следующий этап помощника — чтение файла выгрузки из БП, об этом программа нас предупредит:

Теперь необходимо переключиться на сторону БП и проделать там аналогичные шаги.

Создаем новую настройку синхронизации, теперь выберем пункт «Управление нашей фирмой», поскольку конфигурация УПО разработана на базе УНФ:

Настроим параметры подключения, но теперь укажем файл настроек, который мы заранее сформировали на стороне УПО:

Немного слов о файлах, которые уже сформировал УПО.

Первый файл — ФайлНастроекПодключения.xml — содержит в себе информацию об обменивающихся конфигурациях, префиксах (кодах узлов) и способе обмена:

Второй файл — Message_<код узла>_<код узла>.xml:

Второй файл — это по сути инструкция из УПО для БП о том, с какими объектами «умеет» работать УПО (тег AviableObjectTypes), а также с какими версиями формата ED для загрузки и выгрузки каждого такого объекта (теги Sending, Receiving). «*» — означает любой формат.

Так например, объекты Справочник.Контрагенты, Справочник.ЛицензииПоставщиковАлкогольнойПродукции, Справочник.Номенклатура УПО может как отправлять, так и загружать в любом формате ED, объект Справочник.КонтрагентыГруппа — не загружает, а только отправляет в любом формате, а вот объект Справочник.МаркировкаУпаковки может загрузить или выгрузить только в 7, 8 и 10 формате ED.

После загрузки файла с настройками подключения в БП появится возможность использовать гиперссылку помощника «Настроить правила отправки и получения данных». Эти настройки в уже созданной настройке конвертации мы сможем менять позже, так что настройки отправки НСИ и Документов принимаются на усмотрение пользователя. Мы настраиваем тестовый обмен, поэтому первоначальная выгрузка данных из БП нам не нужна для экономии времени. На вкладке «Служебная информация» указано, что по умолчанию предложена опция обмена в 10-м формате ED.

Записываем настройку и в помощнике переходим по гиперссылке «Начальная выгрузка данных». Поскольку в настройках мы убрали возможность выгрузки НСИ и документов, то в файл никакие объекты выгрузки не попадут:

Настройка на стороне конфигурации БП завершена. Мы можем убедиться, что в папке появился файл выгрузки из БП — Message_БП_УР.xml, который также содержит информацию по возможным объектам и их форматам для обмена:

Если бы мы выгружали НСИ или документы, то они бы находились в теге Body. Атрибутом тега Body, как видим, является пространство имен того формата ED, который был задействован для выгрузки объектов из базы:

Стоит заметить, что секция Header с «инструкциями» другой программе присутствует всегда, и если там возникают изменения, конфигурация дорабатывается, то база-приемник должна «знать», с какими объектами ей взаимодействовать в следующей итерации обмена. Например, при добавлении нового типа объекта в формат обмена, он попадет в AviableObjectTypes внутри тега Header, и тем самым оповестит базу-получатель о возможности обмена с базой-отправителем новыми типами объектов.

Для каждой синхронизации эти настройки хранятся в регистре сведений «Настройки обмена данными XDTO» (рисунок ниже). На основе этих настроек программа принимает решение, отправлять ей какой-то объект конфигурации, в каком формате и какому узлу:

Теперь мы можем вернуться в УПО и завершить настройку:

По нажатию на гиперссылку откроется форма настроек выгрузки и загрузки данных:

Настройки правил можно будет изменить позже в уже созданной синхронизации. Далее выполняем сопоставление и загрузку данных (тех самых данных первоначальной выгрузки из БП):

И в свою очередь выгружаем первоначальные данные в БП. На этом настройка синхронизации завершена и в окне «Настройки синхронизации данных» появилась соответствующая новому обмену строка.

В шапке формы нам доступна кнопка «Изменить настройки», с помощью которой мы можем изменить состав первоначальных настроек для последующих итераций обмена. Выполнение синхронизации можно настроить как по расписанию, так и вручную инициировать обмен нажатием кнопки «Синхронизировать».

Обзор концепта «1С:Конвертация данных 3»

Двухтактный обмен

В отличие от КД2 обмен с применением технологии КД3 не использует файлов правил, все алгоритмы конвертации и обработки объектов, как выгружаемых, так и загружаемых, располагаются в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. При этом в модуле нет информации об объектах базы, с которой мы будем осуществлять обмен. Мы лишь подготавливаем данные в промежуточный объект XDTO, имеющий фиксированную структуру.

Напомним, что благодаря унифицированности объектов в решениях 1С структура формата максимально близка к структуре бизнес-объектов и достаточна для загрузки и выгрузки основной информации по этому объекту. За подготовку текста модуля МенеджерОбменаЧерезУниверсальныйФормат отвечает программный продукт от компании «1С» — «1С:Конвертация данных 3».

В основе реализованной в БСП («1С:Библиотека стандартных подсистем») механики конвертации данных через формат данных EnterpriseData, лежит модель, включающая в себя следующие элементы (функциональные компоненты конвертации):

• Конвертация.
• Правила обработки данных (ПОД).
• Правила конвертации объектов (ПКО), частью которых являются правила конвертации свойств (ПКС).
• Правила конвертации предопределенных данных (ПКПД).
• Алгоритмы.

В совокупности все эти компоненты реализуют функциональность, связанную с обработкой данных в процессе их получения, либо отправки.

Устройство форматов ED

Для реализации обмена посредством КД3 в конфигурации помимо общего модуля присутствуют XDTO пакеты ExchangeMessage, и EnterpriseData_<версия формата>:

С развитием программных решений 1С состав формата расширяется и совершенствуется. Поэтому в дереве конфигурации мы видим несколько XDTO пакетов, описывающих формат ED.

К примеру, для передачи данных в формате 1.10 будет задействован пакет EnterpriseData_1_10_8, 1.8 — EnterpriseData_1_8_6 и т. п. На текущий момент в большинстве решений 1С по умолчанию устанавливается 10 формат передачи данных, как актуальный, поэтому далее будем рассматривать именно его.

Рассмотрим, что представляет собой объект формата ED на примере документа «Поступление товаров и услуг». Для описания документа в формате XDTO используется 3 сущности — тип значения, тип объекта и тип ключевых свойств объекта.

1. Для описания документа в пакете XDTO определен в первую очередь Тип значения ДокументСсылка.ПоступлениеТовароыИУслуг. Он имеет базовый тип Ref, определенный в пакете ExchangeMessage:

2. Также для объекта формата описываются его Ключевые свойства — набор свойств, определяющих его уникальность. Например, для документа «Поступление товаров и услуг» это свойства Ссылка, Дата, Номер, Организация, ДанныеВходящегоДокумента и Контрагент:

Если в описании объекта присутствует свойство ссылочного типа, то оно должно иметь тип КлючевыеСвойства<объект>. Как видим, в качестве типа свойства «Контрагент» указаны ключевые свойства типа объекта Контрагент — КлючевыеСвойстваКонтрагент. Как правило, Ключевые свойства всегда содержат свойство «Ссылка», в которое записывается ГУИД объекта.

3. И наконец третья сущность, с помощью которой документ «Поступление товаров и услуг» представлен в XDTO-формате — это тип объекта — Документ.ПоступлениеТоваровУслуг. Базовый тип для него — Object из пространства имен (1c.ru/SSL/Exchange/Message):

В типе объекта содержатся свойства, соответствующие реквизитам в метаданных объекта, а также табличным частям (ТЧ). Для каждой табличной части объекта создан отдельный тип (как, например, Документ.ПоступлениеТоваровУслуг.Товары, Документ.ПоступлениеТоваровУслуг.Услуги) со свойством строка. Каждая строка табличной части в свою очередь также определяется отдельным типом: Документ.ПоступлениеТоваровУслуг.Товары.Строка, Документ.ПоступлениеТоваровУслуг.Услуги.Строка.

Именно в типе <ИмяОбъекта>.<ТияТЧОбъекта>.Строка описываются реквизиты табличной части объекта, а тип <ИмяОбъекта>.<ТияТЧОбъекта> содержит только строку, на которую ссылается, и из которых состоит. При выгрузке объекта «Поступление товаров и услуг» в формате XDTO он сериализуется в следующем виде:

В секциях-реквизитах шапки «Организация» и «Контрагент» представлены ключевые свойства этих объектов, в секции «Услуги» — описания каждой строки табличной части. Аналогично и табличная часть «Товары» содержит секции «Строка», которые в свою очередь наполнены развернутой информацией по реквизитам строки ТЧ:

Устройство регистрации объектов при обмене в формате XDTO

Поскольку обмен в формате XDTO предполагает использование плана обмена «СинхронизацияДанныхЧерезУниверсальныйФормат», то объекты, участвующие в обмене должны входить в состав плана обмена:

По умолчанию авторегистрация объектов состава запрещена. Если бы стояла автоматическая регистрация, то управлять условиями регистрации объекта было бы невозможно, он бы всегда регистрировался безусловно.

При запрещенной авторегистрации необходимо прописывать логику принудительной регистрации объектов, обычно такая логика сосредоточена в подписках на события. В типовых решениях это подписки на события «СинхронизацияДанныхЧерезУниверсальныйФормат...», которые вызызвают процедуру ОбменДаннымиСобытия.МеханизмРегистрацииОбъектовПередЗаписью().

В качестве фильтра, определяющего необходимость отправки объекта, существуют правила регистрации объекта (ПРО), которые хранятся в макете плана обмена и представлены в виде xml-текста:

Настройку правил регистрации объектов удобно производить с помощью программного продукта «Конвертация данных 3», ниже в статье будет приведен пример работы с ПРО в КД3.

Практический пример обмена «1С:Фастфуд 2.3» с «1С:Фастфуд 3.0»

Постановка задачи

Необходимо обеспечить обмен по технологии КД3 между решениями 1С:ФФ 2.3 («1С:Фастфуд. Фронт-офис, ред. 2.3») и 1С:ФФ 3.0 («1С:Фастфуд. Фронт-офис, ред. 3.0») нетиповых для формата ED объектов. Поскольку конфигурации ФФ 2.3 и ФФ 3.0 созданы на базе типовых продуктов 1С, они включают в себя подсистему обмена в формате ED и все обновления/дополнения/изменения схем соответствуют «базовым» решениям. Необходимо обеспечить миграцию общих по структуре, но отраслевых объектов и свойств, описание которых отсутствует в форматах ED типовых решений.

Рассмотрим несколько объектов, которые требуется передавать в формате XDTO.

Во-первых, это объекты, отсутствующие в формате ED. Если изучить структуру передаваемых в формате ED объектов, то близких по структуре мы найти не сможем. Так, например, из ФФ 2.3 справочник «рестМеню» должен попасть в аналогичный справочник в конфигурации ФФ 3.0:

Во-вторых, требуется расширить список передаваемых свойств объектов, которые уже присутствуют в формате ED в типовых решениях 1С. В решениях «1С:Фастфуд» справочник «Номенклатура» был в значительной мере дополнен отраслевыми реквизитами и табличными частями. Свойств объекта «Номенклатура» в типовом формате ED явно будет недостаточно для передачи всей этой информации:

Способы решения задачи расширения формата

Когда список всех дополнительных объектов к переносу определен, встает вопрос, какими же способами можно решать данную задачу:

1. Во-первых, можно доработать сам пакет XDTO EnterpriseData_1_10. Только его, т. к. на данный момент это актуальная версия. Минусы этого подхода очевидны — для его реализации придется снимать с поддержки сам объект и в случае внесения в него каких-либо изменений со стороны вендора поддерживать корректное обновление, учитывая наши доработки. В случае обновления версии обмена, каждый раз переносить все доработки XDTO из предыдущего пакета в пакет новейшей версии. Это поддерживать довольно проблематично. К такому подходу мы ни разу не прибегали и не рекомендуем.

2. Вторым вариантом может стать использование свойства AdditionalInfo. Поскольку каждый объект в схеме (пример в Документ.ПоступлениеТоваровУслуг рассмотрен выше) определен как тип Object из пространства имен 1c.ru/SSL/Exchange/Message, то можно заметить, что в базовой схеме у типа Object предопределено свойство AdditionalInfo с типом AnyType. Это означает, что мы можем в поле AdditionalInfo указать любую структуру, дополняющую объект.

   Но в случае значительных доработок объекта (как в справочнике «Номенклатура»), придется в AnyType записать как все дополнительные реквизиты шапки, так и все строки ТЧ, которые еще должны идентифицировать каждую строку и ее реквизиты. И получится конструкция-монстр, логику считывания и обработки которой будет описывать непросто, но вполне реализуемо:

   

   Однако этот вариант все же не решает задачу передачи новых типов объектов, ранее не определенных в ED.

3. Также можно вовсе отказаться от использования КД3, и решить задачу файлами обмена с применением технологии КД2. Однако в таком случае придется полностью писать правила загрузки и выгрузки объектов.

4. К счастью, есть возможность избежать реализации с использованием вышеописанных способов и обратиться к более прогрессивному решению. Так, начиная с БСП версии 3.1.3 появилась возможность расширения состава данных при обмене в универсальном формате ED. Теперь базовую схему формата можно расширять отсутствующими объектами и их свойствами, включить в обмен дополнительные данные.

   1С поддерживает вариант расширения форматов обмена ED путем добавления отдельного пакета XDTO, который дополнит уже существующий пакет EnterpriseData_<версия>. Это не означает решения задачи с помощью расширений в понимании патча. Нет, расширение формата обмена — это само название технологии, позволяющей неограниченно расширять существующие форматы ED.

   Для решения нашей задачи мы обратились как раз к этому методу. Рассмотрим его более детально. Основным инструментом для настройки и доработок обмена в формате ED является конфигурация «Конвертация данных 3.1», поэтому рассмотрим подробнее основные принципы работы с ней.

Принцип работы с решением «Конвертация данных 3»

Рассмотрим детальнее продукт «1С:Конвертация данных 3.1». Он помогает облегчить труд с изменением общего модуля «МенеджерОбменаЧерезУниверсальныйФормат», отвечающего за обмен в формате XDTO, а также упрощает подготовку XDTO-пакета расширений. На момент написания статьи актуальная версия КД3 — 3.1.2.24, поэтому рассмотрим её возможности.

1. Загрузка структуры конфигурации

В первую очередь в КД3 необходимо загрузить структуру каждой из конфигураций, для которых будем настраивать обмен. Поскольку конфигурации отличаются составом объектов, составом реквизитов объектов, то и правила обработки и конвертации объектов универсального формата ED могут отличаться. Загрузить структуру конфигурации можно двумя способами:

1.1 С помощью внешней обработки выгрузки структуры конфигурации (по аналогии с КД2) — из поставки решения КД3 берем обработку MD83Exp.epf.

Выполняем следующие действия:

1. Открываем информационную базу в режиме «Предприятие».
2. Открываем внешнюю обработку MD83Exp.epf (Меню Файл — Открыть).
3. Задаем имя файла, в который следует сохранить структуру информационной базы.
4. Проверяем настройки в форме обработки (все флаги должны быть сняты).
5. Нажимаем кнопку Выгрузить.

Далее необходимо подготовленный таким образом xml файл загрузить в КД3. Делается это следующим образом — в подсистеме «Конфигурации» переходим в список «Конфигурации», и создаем новый элемент справочника. Если этого не сделать, то последующая загрузка структуры произойдет в предопределенный элемент «Неизвестная конфигурация». Это не страшно, но лучше создать конфигурацию предварительно, чтобы потом поддерживать релизы и структурировать работу с КД3. Затем необходимо открыть обработку загрузки структуры:

Затем выбрать вариант загрузки — в существующую версию конфигурации (т. е. перегружаем в существующий релиз), либо в новую.

1.2. Второй способ не предполагает использования обработки MD83Exp.epf для выгрузки. В КД3 переходим в «Конфигурации» → «Сервис» → «Загрузка структуры конфигурации из файлов XML/EDT». Открывается форма с возможностью загрузки из файлов xml или EDT:

Мы можем выгрузить структуру из Конфигуратора, либо указав каталог проекта EDT. В случае, если конфигурация разрабатывается при помощи EDT, удобно загружать по настройке «Файлы EDT». В этом случае для загрузки структуры конфигурации будут прочитаны файлы *.mdo в папке src проекта.

Поскольку разработка ФФ ведется в Конфигураторе, выберем загрузку из файлов xml.

Структуру предварительно выгрузим из Конфигуратора. Для этого перейдем в подменю «Конфигурация» → «Выгрузить конфигурацию в файлы»:

В КД3 выбираем подготовленный каталог с выгруженными из конфигуратора файлами и нажимаем «Загрузить». В результате загрузки появится заполненный элемент справочника Релизы:

Аналогичные действия проделываем и для второй конфигурации. После того как обе конфигурации загружены в КД3, нам необходимо загрузить модули менеджера обмена этих конфигураций. Поскольку именно модуль мененджера содержит в себе все правила, по которым объекты будут сконвертированы для выгрузки или загрузки и как они должны быть обработаны.

2. Загрузка модулей менеджера

Создаем элемент справочника «Конвертации» — мы настраиваем обмен в формате XDTO, поэтому создадим конфигурацию в этой группе:

Указываем наименование конвертации, версии формата ED, под который настраиваем конвертацию и записываем.

Далее необходимо загрузить новую версию формата (или обновить существующую). Для этого переходим в подсистему «Формат данных» → «Версии формата» → «Загрузка структуры формата»:

Предварительно нужно эту версию экспортировать из Конфигуратора — в контекстном меню для XDTO-пакета ED выбрать «Экспорт XML-схемы». Эту же процедуру проделываем с родительским пакетом ExchangeMessage:

Теперь можем загрузить модуль менеджера для созданной конвертации — в подсистеме «Конвертации» выбираем команду «Загрузка модуля менеджера»:

Для загрузки указываем ранее созданную конвертацию, состав загружаемых данных и способ загрузки. Грузить можно из буфера обмена, поэтому перейдем в конфигуратор базы и скопируем Ctrl+C текст общего модуля. После этого возвращаемся в КД и нажимаем «Загрузить». Результат загрузки модуля мы сможем увидеть, перейдя в «Конвертации» → «Настройка правил конвертации».

Перед нами откроется форма настроек правил обмена:

Эта форма отображает ровно то, что написано в модуле МенеджерОбменаЧерезУниверсальныйФормат, и представляет собой инструмент для удобной корректировки и доработки правил обмена. На форме вкладками разделены правила обработки данных (далее — ПОД), правила конвертации объектов (далее — ПКО), правила конвертации предопределенных данных (далее — ПКПО), а также вспомогательные алгоритмы, вызываемые из правил.

После работы с правилами обмена есть возможность их проверить по некоторым параметрам:

Обработку проверки можно вызвать как из самой формы настроек обмена, так и из подсистемы «Конвертации» → «Сервис» → «Проверка конвертации».

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

Создавать конвертацию и загружать правила из модуля менеджера необходимо для каждой конфигурации, участвующей в обменной схеме. Поэтому те же действия проделаем для второй конфигурации. Пример настройки правил обмена для конвертации с помощью КД3 описан ниже.

3. Создание ПРО с помощью КД3

Настроить правила регистрации можно в КД3 в подсистеме «Регистрации». Для настройки ПРО через КД3 их необходимо создать или загрузить из макета в справочник «Регистрации», используя обработку «Загрузка регистрации»:

Далее перейдя в «Регистрации» — «Правила регистрации объектов», попадаем в форму настройки правил. Как видим, после загрузки регистрации из макета, список ПРО заполняется автоматически. Мы можем как создать новое правило, так и внести коррективы в существующие:

Для элемента настройки есть возможность задать отборы плана обмена, чтобы определить, по каким условиям будут определены узлы обмена, для которых объект зарегистрируется, а также отборы по свойствам самого объекта. К примеру, можно выгружать только объекты определенной организации или не помеченные на удаление:

На следующей вкладке «Обработчики событий» можно определить тексты обработчиков, которые позволяют задать ограничения, которые не поддерживаются функционалом отборов по свойствам объекта либо по свойствам плана обмена:

После завершения работы с правилами, их можно выгрузить из КД3:

Выгруженный файл загружается в макет плана обмена «Правила регистрации объектов», однако с версии БСП 3.6.1 добавилась возможность отладить ПРО без загрузки в Конфигуратор. В форме настройки синхронизации в подменю «Параметры синхронизации данных» можно выбрать подменю «Загрузить правила регистрации объектов»:

Данный инструмент позволяет переключиться с использования типовых правил на правила регистрации, описанные в файле xml, ранее выгруженном из КД3:

Помимо программной регистрации существует возможность принудительной регистрации объекта в режиме «Предприятия» в списке «Настройки синхронизации данных»:

Вручную можно зарегистрировать как одиночный объект, так и несколько объектов разных типов, а также снять регистрацию с выбранных объектов.

Реализация задачи расширения

Теперь рассмотрим реализацию задачи по расширению формата обмена. Процесс реализации будет состоять из нескольких шагов:

• Подготовительные действия — создание расширяющего XDTO пакета.
• Наполнение расширяющего XDTO пакета свойствами согласно постановке задачи (2 способа решения задачи).
• Создание конвертации под расширяющий формат и наполнение ее правилами.
• Выгрузка модуля менеджера обмена через универсальный формат из КД3 в конфигурацию.
• Доработка модулей конфигурации для обеспечения работы с механизмом расширений.
• Доработка правил регистрации (ПРО).

1. Создание расширяющего XDTO пакета

Основой механизма расширений является дополнительный, т. н. «расширяющий» XDTO-пакет, который дополняет уже существующий. В нашем примере будем расширять 10-ю версию ED, а значит пакет EnterpriseData_1_10_3.

Унифицированный глобальный идентификатор (URI) пространства имен пакета (v8.1c.ru/edi/edi_stnd/EnterpriseData/1.10) — это пространство имен, а также пространство имен второго базового пакета для формата обмена ED (http://www.1c.ru/SSL/Exchange/Message) необходимо прописать в директивах импорта создаваемого пакета-расширения. А для самого XDTO-пакета URI пространства имен должно выглядеть следующим образом:

http://v8.1c.ru/edi/edi_stnd/<уникальное_наиименование_расширенияформата>/<номер_версии_расширения>

Рассмотрим основные особенности расширяющего пакета:

1.1. Для нового объекта, отсутствующего в базовом пакете ED, например, справочника «рестМодификаторы», необходимо добавить тип значения СправочникСсылка.<имя_объекта> с базовым типом Ref:

Также необходимо описать тип объекта Ключевые свойства с рядом определяющих свойств, в данном случае Ссылка должна иметь тип, который мы только что определили в типах — СправочникСсылка.рестМодификаторы:

И наконец тип объекта Справочник.рестМодификаторы с базовым типом Object, и с обязательным свойством КлючевыеСвойства, которые мы ранее для него определили — КлючевыеСвойстарестМодификаторы:

1.2. Если в объекте присутствует свойство, тип которого уже определен в родительском формате ED, то дублировать его в XDTO-пакете расширении нет необходимости. Указываем тип из базового пространства имен.

Например, в новом объекте расширенного формата Справочник.рестМодификаторы мы добавляем свойство ЕдиницаИзмеренияМодификатора. В базовом пакете 10 формата уже присутствует описание типа КлючевыеСвойстваЕдиницаИзмерения, поэтому в качестве типа укажем тип объекта родительского формата, переопределять в расширенном пакете КлючевыеСвойстваЕдиницаИзмерения нет необходимости, если мы не планируем их изменять:

Важно! Тип ссылочного реквизита всегда КлючевыеСвойства, а не сам объект Справочник.<Имя_объекта>.

1.3. Для расширения объекта типа, который уже присутствовал в базовом XDTO-пакете, например, справочника «Номенклатура», не нужно добавлять в расширяющий пакет тип и ключевые свойства. Добавляется только тип объекта Справочник.Номенклатура, у которого заполнен базовый тип из пакета ED 10 формата:

1.4. Если есть необходимость передавать в формате обмена не только элементы справочника, но и его группы, чтобы передавать всю многоуровневую структуру, то для них должны быть определены отдельные типы объектов и типы объектов для ключевых свойств. Например, для справочника «рестМеню» создаем 2 типа объектов Ключевых свойств и 2 типа объекта под сами объекты элементов и групп:

Особенно внимательно следует указывать тип Ключевых свойств, и проставлять соответствующие для элемента КлючевыеСвойстварестМеню, для группы КлючевыеСвойстварестМенюГруппа:

1.5. Для расширения состава передаваемых реквизитов табличной части следует в расширенном пакете связать тип объекта (для которого расширяем ТЧ) с типом объекта базового пакета ED.

Например, мы хотим передавать табличную часть Товары документа ПоступлениеТоваровИУслуг вместе с дополнительным реквизитом «рестЭтоБлюдо». В таком случае в пакете-расширении должен быть определен тип значений ДокументСсылка.ПоступлениеТоваровУслуг с базовым типом ДокументСсылка.ПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/EnterpriseData/1.10) из родительского пакета «1.10».

Кроме того, необходимо «подтянуть» в расширенный пакет не только тип объекта «Документ.ПоступлениеТоваровУслуг.Товары.Строка», но и все вышестоящие типы:

• КлючевыеСвойстваПоступлениеТоваровУслуг. Базовый тип здесь не указываем, свойство Ссылка имеет тип расширенного пакета — ДокументСсылка.ПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• Документ.ПоступлениеТоваровУслуг, базовы тип не определяем, свойство КлючевыеСвойства с типом КлючевыеСвойстваПоступлениеТоваровУслуг (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• Документ.ПоступлениеТоваровУслуг.Товары, также без базового типа, свойство Строка имеет внутренний тип Документ.ПоступлениеТоваровУслуг.Товары.Строка (v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10).
• И наконец тип для самой строки Документ.ПоступлениеТоваровУслуг.Товары.Строка (базовый тип не заполняем), который наполняем необходимыми расширенными реквизитами:

6. XDTO-пакет должен быть одинаковым во всех решениях, которые участвуют в обменной схеме с расширениями. Таким образом, не забываем импортировать этот же пакет во вторую конфигурацию, и в случае каких-либо правок в пакете, обновлять все пакеты, чтобы они повторяли друг друга.

Готовый XDTO-пакет экспортируем в КД3 (процедура экспорта описана ранее).

2. Наполнение XDTO-пакета свойствами

После создания XDTO-пакета его следует наполнить, определив в нем свойства объектов и типы объектов. Сделать это можно средствами конфигуратора (вручную добавить каждый новый тип объекта, тип значения для него и ключевые свойства, затем добавить свойства объектов), а затем выгрузить расширяемый пакет в КД3 для дальнейшей настройки обмена.

Важно! При создании XDTO-пакета в конфигураторе следует учитывать ряд особенностей, рассмотренных ранее.

Однако программный продукт КД3 может упростить процесс редактирования и наполнения созданного пакета, рассмотрим как именно.

Для этого выгрузим расширяющий пакет в КД3: в конфигураторе экспортируем пакет ExchangeMessage, оригинальный пакет EnterpriseData_1_10_3 и только что созданный расширяющий XDTO-пакет в каталог на ПК для дальнейшей загрузки их в КД3.

Переходим в КД3, в справочник «Версии формата»:

Стандартные версии ED располагаются в предопределенной группе Enterprise data, версии расширений хранятся в отдельной группе справочника. Отдельную группу создавать вручную нет необходимости, она будет создана автоматически при импорте пакетов. В списке справочника «Версии формата» нажимаем кнопку «Загрузка структуры формата». В форме выбора выбираем сразу все 3 пакета, которые ранее экспортировали из конфигурации, и нажимаем «Загрузить»:

Программа создаст новый элемент справочника версии с признаком «Расширение», а также новый каталог с признаком «Расширение» и заполненным шаблоном пространства имен (версия ED в шаблоне не указывается):

Ничего править не нужно, убедимся лишь в корректности загрузки. Далее перейдем в регистр сведений «Взаимосвязи версий форматов и расширений» и добавим запись для того, чтобы КД3 могла распознать, какой версии ED какое расширение соответствует:

На основании записи в этом регистре КД3 сможет дополнять типовой формат 1.10 расширяющими свойствами и объектами из пакета-расширения. Теперь переходим к наполнению самого расширяющего формата свойствами и объектами, для этого воспользуемся обработкой «Дерево объектов формата» («Формат данных» → «Сервис» → «Дерево объектов формата»):

Выбираем в поле «Версия формата» расширяющую версию, а в подменю «Еще» → «Редактировать структуру формата». Теперь с деревом структуры появляется возможность работать. Однако, наше дерево пустое и со строкой «Общее» никаких действий произвести не получается. Если же мы посмотрим на структуру 10 версии ED, то увидим, что она содержит и перечисления, и описания типов, общих ТЧ, справочников и документов:

Есть небольшая хитрость, к которой мы и прибегнем, чтобы наполнить наше дерево минимальной структурой. Вернемся в конфигуратор, и добавим в расширяющий пакет 1 тестовый тип, 1 тестовый тип под перечисление (базовый тип у него String, атомарный) и 2 тестовых типа объектов (Справочник.<любое наименование> и Документ.<любое наименование>).

Затем вновь экспортируем пакет и загрузим для уже существующей версии-расширения с отметкой, что грузить будем только дополнительные свойства:

И хоть в подсказке написано, что следует выбрать 2 файла, выберем все 3 вместе с оригинальным пакетом, иначе невозможно будет произвести корректный импорт. Вновь вернемся к обработке «Дерево объектов формата» и увидим уже каркас, с которым появляется возможность работать:

Рассмотрим пример добавления справочника — разрешаем редактирование объектов дерева (подменю «Еще») и выделим строку «Справочники», нажимаем «Добавить», открывается форма создания нового объекта формата:

Как видим, есть вариант указать, что мы создаем «Общую табличную часть», «Общие свойства», либо «Ключевые свойства». Для нового справочника оставляем переключатель в положении «Объект не является общим».

Наименование уже содержит подсказку того, как оно должно быть заполнено — начинается со «Справочник.». Допишем только название нашего справочника, например, рестГруппыМодификаторов, нажимаем «Записать и закрыть», Обновляем дерево в форме и видим, что КД3 автоматически создала новый ссылочный тип для нашего справочника и подчиненную строку КлючевыеСвойства (свойство объекта формата):

Посмотрим, как выглядит описание Ключевых свойств на стороне КД3:

Пока Ключевые свойства пустые. Добавим в них свойство Ссылка («Добавить строку» в дереве объектов формата) и попробуем загрузить такой пакет обратно в 1С — для этого перейдем «Формат данных» → «Сервис» → «Выгрузка объектов формата», сохраним пакет в xsd файл, а на стороне 1С импортируем его в наш пакет-расширение:

Мы можем увидеть, что корректно создались тип значений СправочникСсылка.рестГруппыМодификаторов, типы объектов КлючевыеСвойстварестГруппыМодификаторов и Справочник.рестГруппыМодификаторов с необходимыми созависимостями.

Единственное, стоит обратить внимание на то, что, в типе объекта Справочник.рестГруппыМодификаторов не проставлен базовый тип, он должен быть Object, сделаем это вручную:

Также у типа значений не проставился (сбился) базовый тип Ref — дополним его:

Если посмотреть на выгруженный xsd , то базовые типы в нем были определены:

Также как и директива импорта с базовым пространством имен:

Но при импорте базовые типы слетают, и этот важный момент следует учитывать и не забывать сразу указывать корректные базовые типы. Также неприятный момент заключается в том, что КД3 выгружает пакет без директивы импорта с URI базового формата ED, так что на стороне конфигуратора ее придется добавить заново:

Несмотря на это, КД3 все же облегчает и ускоряет процесс наполнения структуры пакета, т.к. объекты визуально представлены в удобном формате дерева. Кроме того, создание XDTO-пакета в КД3 позволяет избежать лишних действий по созданию типов объектов и типов значений для сложных объектов (справочники и документы).

3. Создание конвертации для расширяющего формата и наполнение ее правилами

Следующая задача — доработать правила конвертации для работы с расширениями, поэтому доработаем модуль МенеджерОбменаЧерезУниверсальныйФормат с помощью КД3. Поскольку структуру конфигураций ФФ 2.3 и ФФ 3.0 мы загружали в КД3 ранее, эти действия не повторяем. Создаем новую конвертацию:

В табличной части «Версии формата» обязательно указываем 10-й формат обмена. Затем загружаем модуль менеджера для созданной конвертации:

Теперь можем перейти в его настройку: «Конвертации» → «Настройка правил конвертации». На форме обработки настроек правил конвертации видим, что текущие правила загружены и представлены по вкладкам ПОД, ПКО и ПКПД:

Удобнее всего начинать доработку правил именно с ПКПД, поскольку далее они будут использованы в ПКО, а ПКО в свою очередь — в ПОД. Поэтому следуем такой последовательности:

3.1. Добавление ПКПД

Рассмотрим на примере перечисления рестТипыНоменклатуры:

В расширении формата ему соответствует тип с добавленными элементами перечислений:

В КД3 на вкладке ПКДП создаем новый элемент и заполняем его в следующей последовательности:

1. Выбираем объект формата:

   

   В списке выбора он появился благодаря тому, что в самой конвертации указана версия формата 1.10, а в РС «Взаимосвязи версий и форматов расширений» указана связь с расширяющим форматом:

   

2. Выбираем объект конфигурации, который при обмене будет сконвертирован в/из объект формата:

   

3. Выбираем область применения правила: только для отправки, только для получения или для обоих случаев. В нашем случае с перечислением оно будет сконвертировано в обе стороны одинаково, поэтому выберем «для отправки и получения»:

   

4. И только после предыдущий этапов заполним поле «Идентификатор» по кнопке «Заполнить». В таком случае идентификатор заполнится автоматически по шалблону:

   

5. Осталось настроить сопоставление элементов перечисления элементам перечисления формата. Если наименования повторяют друг друга, можно воспользоваться кнопкой «Сопоставить автоматически»:

   

   Также можно добавлять/изменять соответствия вручную. Для каждого значения перечисления необходимо обязательно задать сопоставление, как и для каждого значения формата. Это нужно для избежания ошибок при выгрузке/загрузке перечисления согласно правилу.

3.2. Добавление ПКО

Следующий этап — создание правил конвертаций объектов для таких типов объектов как справочники и документы. Для этого перейдем на вкладку настроек ПКО.

Важный момент! Настройку ПКО лучше начинать в первую очередь с тех объектов, которые состоят из простых реквизитов или не имеют ссылочных реквизитов на другие пока не определенные в правилах объекты. А после уже переходить к тем объектам, которые зависимы от них. Если планируется выгружать справочник с полной иерархией, то сперва удобнее создавать правило для группы справочника, а затем для элемента. Это также обусловлено тем, что в ПКО элемента справочника для свойства Родитель необходимо будет заполнить ПКО для группы справочника. Таким образом не потребуется возвращаться к настройке ПКО дважды, если правило для родителя уже будет определено.

Пример: в ПКО для справочника «рестВидыМеню» для свойств Бренд, ВидЦены и Родитель необходимо указать, по какому правилу будут сконвертированы данные свойства при отправке.

Поэтому логика «от меньшего к большему» очень удобна при настройке правил.

Рассмотрим доработки ПКО для новых объектов формата и уже существующих. Для новых объектов формата ПКО пока не созданы, поэтому добавляем новое правило.

Добавление нового правила 

Рассмотрим пример создания правил ПКО для загрузки и выгрузки справочника рестМодификаторы (будем обмениваться полной иерархией). Нам потребуется создать 2 правила «Для отправки» (ПКО для элемента и ПКО для группы справочника), а также 2 правила «Для получения» (также элемента и группы). Начнем с создания правил для группы — рестМодификаторы:

Заполняем ПКО в следующей последовательности: «Объект формата», «Объект конфигурации», «Область применения», затем генерируем «Идентификатор».

Важно! Чтобы различать идентификаторы элемента и группы справочника, а они заполнятся автоматически одинаковые, для ПКО группы удобнее идентификатор вручную чуть видоизменить, дописав «Группа».

Записываем и переходим на вкладку «Правила конвертации свойств». Здесь настроим правила обмена реквизитами и табличными частями. Если не требуется обрабатывать свойства в обработчике «При отправке», то можно создать правила автоматически, воспользовавшись кнопкой «Настройка ПКС»:

Перед нами откроется форма настроек правил конвертации:

Для автоматического создания ПКС нажмем сперва «Автоматическое сопоставление», а затем «Создать правила конвертации свойств».

В релизе КД3 форма автоматического сопоставления свойств к сожалению не подхватила свойства расширения формата, а они нам очень нужны, поэтому пока не вышел релиз с исправлениями, снимем с поддержки Обработку настройки ПКС и исправим запрос в процедуре ЗаполнитьТаблицуНеСопоставленныхСвойствXDTO() так, чтобы он учитывал наше расширение:

А также строку 160:

Перезапустим базу КД3 и убедимся, что в форме автоматического сопоставления представлены свойства расширения формата.

Для группы справочника мы определяли в формате только ключевые свойства, которые заполнились автоматически:

Далее создаем ПКО для отправки элемента справочника:

Заполним его в той же последовательности, что и правило для Группы. Затем на вкладке ПКС настроим конвертацию свойств — откроем форму «Настройка ПКС» и нажмем кнопку «Автоматическое сопоставление». После нажимаем «Создать правила конвертации» и видим, что реквизиты конфигурации сопоставлены со свойствами формата автоматически, кроме того, для ссылочных реквизитов автоматически подставилось правило конвертации:

Рассмотрим редактирование свойства на примере свойства «ЕдиницаИзмеренияКлассификатора»:

При необходимости в форме редактирования строки можно выбрать другое подходящее ПКО для конвертации ссылочного свойства объекта. Его можно выбрать из списка, если такое ПКО уже определено, или заполнить вручную идентификатор, который будет определен позже.

Конечно, удобнее не заботиться о правильности написания идентификатора, а создать такое ПКО заранее. Поэтому сперва мы определили ПКО для группы, а после для элемента справочника. И теперь, как видим, для свойства формата «Родитель» ПКО автоматически заполнилось:

В том случае, когда какие-то свойства объекта должны быть обработаны определенным образом до помещения в пакет XDTO (при отправке) или при чтении из XDTO в базу (при получении), вариант автоматической настройки ПКС для этих свойств не подходит. В таком случае в ПКС устанавливается флаг «Используется алгоритм конвертации», а в обработчике ПриОтправке (в случае ПКО для отправки объекта) прописывается алгоритм обработки реквизита и помещения его в структуру XDTO:

При этом возможен комбинированный подход, т. е. часть свойств можно конвертировать «автоматически» (сработает логика БСП), а остальные помещать в XDTO «самостоятельно» в алгоритме ПКО:

Для разработчиков обменов в КД3 напротив каждого обработчика есть подробная справка по нажатию на знак «?»:

Рассмотрим еще одну задачу, для решения которой используем обработчик ПКО «При отправке».

Допустим, при выгрузке требуется выгружать не только текущий объект, для которого вызывается ПКО, но и его владельца (да и любой другой объект в полном виде, даже не зависящий никаким образом от текущего объекта ИБ). В таком случае нам нужно принудительно выгрузить объект ИБ в текущей итерации обмена. Для этого вызовем метод общего модуля ОбменДаннымиXDTOСервер.ВыгрузкаОбъектаВыборки():

Изменение существующего правила типового объекта

Рассмотрим расширение формата типового справочника «Номенклатура». Объект XDTO мы дополнили отраслевыми свойствами для справочника «Номенклатура»:

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

Как видим, таких правил 2 — для элемента справочника для отправки и для получения (флаги «Отправка» и «Получение» в таблице).

Рассмотрим корректировку правила для получения. Перейдем на вкладку ПКС и убедимся, что пока созданы ПКС только для типовых свойств. Затем как и в случае с настройкой в отраслевом объекте нажимаем «Настройка ПКС» → «Автоматическое сопоставление». Существующие ПКС при этом не пропадут, а будут только дополнены новыми ПКС для отраслевых свойств объекта. В завершении обработки автоматического создания ПКС создались как реквизиты «шапки»:

Так и ПКС для табличной части рестГастрономическиеТеги:

В обработчики ПКО также можно вносить коррективы. Но для нашей задачи доработки не понадобятся:

Отключение правила типового и замена на доработанное правило

Такой вариант также имеет место быть. Для того, чтобы правило не удалять из КД3, а использовать, допустим, в качестве примера для вновь созданного правила можно установить флаг «Отключить»:

В таком случае правило не будет сохранено в измененный модуль менеджера обмена, выгружаемого из КД3, но в самом КД3 останется. В дальнейшем можно его будет обратно включить, отключив альтернативное при необходимости.

3.3. Создание ПОД для новых объектов формата

Здесь также важна последовательность заполнения. В первую очередь указываем «Область применения», «Объект выборки» и только после этого автоматически заполняем «Идентификатор правила».

Рассмотрим настройку ПОД для иерархического справочника «рестСклады». Для этого справочника мы определили 2 ПКО на отправку — Правило для группы и Правило для элемента. Поэтому в переключателе «Количество правил конвертации» выберем «Несколько» и укажем все определенные для объекта ПКО. Для того чтобы при выгрузке объекта БД система поняла, какое правило следует использовать для какого объекта, пропишем дополнительную логику определения ПКО. Выполняется это на вкладке «Обработчики событий»:

В данном случае в структуру ИспользованиеПКО мы записали значения ключей (они соответствуют именам ПКО, определенным на первой вкладке ПОД) . Значение ключа Истина будет означать, что выгрузка будет произведена по ПКО, указанному в ключе структуры.

Обработчик ПОД «Выборка данных» предназначен для реализации произвольной выборки данных из базы и должен на выходе формировать массив для выгрузки данных. Элементами массива могут быть как ссылки на объекты БД, так и структура с данными для выгрузки. В случае регулярного обмена с использованием планов обмена алгоритм БСП в процедуру «Выборка данных» не заходит, а выбирает к выгрузке только зарегистрированные в узле обмена данные.

Для того, чтобы появилась возможность использовать обработчик «Выборка данных», необходимо доработать структуру «КомпонентыОбмена». Она содержит такие компоненты для осуществления обмена, как правила и параметры обмена. Инициализируется данная структура в общем модуле «ОбменДаннымиXDTOСервер».

Для реализации нетипового механизма выборки данных следует изменить значение свойства структуры «ЭтоОбменЧерезПланОбмена» на «Ложь», а также задать свойство «СценарийВыгрузки». СценарийВыгрузки должен быть определен как таблица значений (либо массив структур) с колонкой «ИмяПОД». В строках необходимо указать имена ПОД, которые будут обрабатываться при выгрузке.

Следует отметить, что параметр «ЭтоОбменЧерезПланОбмена» влияет на много показателей, и его нужно держать всегда либо включенным, либо выключенным.

4. Выгрузка модуля менеджера из КД3 и загрузка в конфигурацию

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

Ранее мы определили путь сохранения модуля менеджера в карточке «Конвертации»:

В указанный для конвертации каталог будет выгружен модуль, сформированный КД3:

Скопируем текст модуля из файла и перенесем в конфигурацию 1С, для которой создавалась конвертация:

Мы выгрузили модуль менеджера конвертации для ФФ 2.3. Аналогичные действия по настройке правил конвертации, сохранению модуля и загрузке модуля в конфигурацию необходимо будет проделать и для второй конфигурации, участвующей в обмене.

Что касается загрузки модуля менеджера в конфигурацию, то возможны следующие варианты — определить новый общий модуль менеджера, либо откорректировать существующий. В случае с добавлением нового модуля, необходимо будет заменить использование типового модуля «МенеджерОбменаЧерезУниверсальныйФормат» в соответствии ВерсииФормата. Например:

ВерсииФормата.Вставить("1.10", МенеджерОбменаЧерезУниверсальныйФормат_Расш);

Однако модуль, на базе которого мы дорабатывали правила обмена, часто изменяется и дорабатывается фирмой «1С». Для корректного обмена изменения придется каждый раз отслеживать и переносить в добавленный модуль менеджера обмена. Поэтому решение использовать дополнительный модуль или вносить правки в существующий взвешивается и остается за разработчиком. Поскольку в нашем примере объем изменений не велик, то мы будем дорабатывать типовой модуль менеджера.

5. Доработки конфигурации для обеспечения работы с механизмом расширений

Доработки силами 1С разработчика

Для включения возможности работы с расширенным форматом ED разработчику потребуется изменить процедуру «ПриПолученииДоступныхРасширенийФормата» общего модуля ОбменДаннымиПереопределяемый . В процедуре следует определить соответствие РасширенияФормата — указать Ключ = URI пространству имен расширяющего пакета, а значение — номер расширяемой версии формата:

Доработки модуля менеджера, полученные из КД3 (автоматически сформированные)

Рассмотрим, как изменился МенеджерОбменаЧерезУниверсальныйФормат, сформированный автоматически из КД3 после доработки правил обмена расширенных объектов и свойств формата.

Во-первых, в ПКО расширяемых объектов формата добавился вызов процедуры ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта:

Во-вторых, в ПКО расширяемых объектов для свойств, которые характерны для расширенного формата, определен шестой параметр с пространством имен расширенного пакета «v8.1c.ru/edi/edi_stnd/ED_Ext_rarus/1.10»:

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

Аналогично дополнены тексты процедур ЗаполнитьПравилаКонвертацииОбъектов, ЗаполнитьПравилаКонвертацииПредопределенныхДанных. Если мы определяли в правилах обработчики ВыборкаДанных, ПриОбработке, ПриОтправкеДанных, ПриКонвертацииДанныхXDTO и т. д., то условия их вызова добавятся в процедуры ВыполнитьПроцедуруМодуляМенеджера и ВыполнитьФункциюМодуляМенеджера. И, конечно, модуль менеджера будет содержать все процедуры ПКО и ПОД для новых объектов расширенного формата.

6. Доработка правил регистрации

Поскольку обмен в формате ED выполняется с помощью плана обмена, то для того чтобы можно было зарегистрировать новые объекты формата для узла, нам необходимо доработать состав плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат:

Правила регистрации объектов на узле находятся в макете ПравилаРегистрации. Сперва загрузим в КД3 те правила, которые уже определены в конфигурации для типовых объектов:

В результате создастся элемент справочника «Регистрации». В элементе есть возможность выгрузить правила регистрации, а также есть выбор, куда производить выгрузку — в файл xml или в общий модуль:

Перейдем в «Регистрации» → «Правила регистрации объектов» и добавим правила для новых объектов расширенного формата. При необходимости в ПРО пропишем условия отбора для выгрузки:

После выгрузки правила перенесем в макет плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат.

Посмотрим, как будет выглядеть выше созданное правило для справочика рестВидыМеню:

И, конечно, для регистрации нужно не забыть добавить новые объекты в источники подписок на события, например, СинхронизацияДанныхЧерезУниверсальныйФорматРегистрация.

Примеры выгруженных объектов расширенного формата

Рассмотрим несколько отличительных особенностей объектов расширенного формата в файле выгрузки.

Во-первых, в <msg:AvailableObjectTypes> мы увидим добавленные в расширенном пакете типы объектов наряду с объектами базового 10 формата:

Во-вторых, в тэге Body добавится атрибут с расширенным пространством имен:

Типовой объект ED с расширенными свойствами будет выглядеть по своей структуре следующим образом: свойства типового объекта Справочник.Номенклатура не будут ничем отличаться от классической выгрузки в универсальном формате; свойства же расширенного формата будут дополнены «ext1»:

Если посмотреть на новый объект формата (рассмотрим Справочник.рестСтолы), добавленный в XDTO-пакет-расширирение, то мы увидим, что теги как всех свойств объекта, так и сам объект, содержат конструкцию «ext1».

Заключение

Прежде всего следует отметить, что описанная технология расширения формата ED решила самое большое ограничение в применении этого замечательного подхода, а именно, что же делать, если среди объектов формата нет подходящего для нашего случая.

Знания в части конвертации данных могут сильно повысить вашу профессиональную стоимость и, конечно, помогут решить огромное число задач по взаимодействию программ самого разного класса: от доработки типовых решений 1С до взаимодействия со сторонними программными продуктами.

Мы хотели, но не сумели вместить в материалы экспертной статьи сравнительный анализ производительности обменов с применением расширений, а также ряд деталей по демонстрации приемов обмена с использованием событийной модели конвертации. Попытаемся для этого организовать отдельную публикацию.

Обратную связь по нашим экспертным статьям читатель может дать в чате нашего Telegram-канала.

Глоссарий принятых сокращений

ИБ — информационная база.

ТЧ — табличная часть.

КД2 — программный продукт «1С:Конвертация данных 2.x».

КД3 — программный продукт «1С:Конвертация данных 3.x».

Выгрузка-загрузка данных XML — обработка для полной или частичной выгрузки и загрузки данных информационной базы в файл в формате XML. Обработка может использоваться только в тех случаях, когда информационная база, в которой осуществлялась выгрузка данных, и та, в которой данные загружаются, являются однородными (конфигурации идентичны, данные могут различаться), либо все выгружаемые объекты практически полностью идентичны по составу и типам реквизитов и табличных частей, свойствам «ведущего» объекта метаданных и т. д. Внешняя обработка Выгрузка и загрузка данных XML.epf для запуска в «1С:Предприятии» версии 8.3 находится в каталоге EXE/EXTREPS/UNIREPS83/UploadToXML.

ED — формат обмена данными Enterprise Data. Это формат, позволяющий описать объект информационной базы (контрагента, накладную и т. п.) или сообщить о факте удаления этого объекта.Формат ED включают в себя описание бизнес-сущностей из различных областей хозяйственно-экономической деятельности предприятия и является расширяемым.

УПО — программный продукт «1С:Управление предприятием общепита» , разработан на базе «1С:Управление нашей фирмой 3.0».

БП — программный продукт «1С:Бухгалтерия предприятия».

Обмен данными ED — это обмен с помощью «Конвертации данных 3.x». Эту технологию называют по-разному — «Обмен через XDTO», «Обмен в формате EnterpriseData», «Обмен с помощью Конвертации данных 3.0», «Обмен через Универсальный формат», каждый из вариантов правильный.

ФФ2.3 — программный продукт от компании «1С-Рарус» «1С:Фастфуд. Фронт-офис, ред. 2.3». Создан на базе типового решения «1С:Розница, ред. 2.3».

ФФ3.0 — программный продукт от компании «1С-Рарус» «1С:Фастфуд. Фронт-офис, ред. 3.0 ». Создан на базе типового продукта «1С:Розница, ред. 3.0». На момент выхода статьи находится на этапе разработки.

ПОД — правила обработки данных.

ПКО — правила конвертации объектов.

ПКПД — правила конвертации предопределенных данных.

ПКС — правила конвертации свойств.

ПРО — правила регистрации объектов.

БСП — программный продукт «1С:Библиотека стандартных подсистем».

Перейти к началу статьи »