Содержание
- Сравнение КД 2.1 и КД3.0
- Про XDTO
- Общая схема работы с КД 3.0
- Порядок создания конвертации
- Настройка обмена в 1С:Предприятие для обмена через локальный каталог
Вступление:
— ChatGPT, а напиши-ка мне статью про КД 3.0.
— Да не проблема: «Заголовок: Первый Шаг в Мире Конвертации Данных 3.0: Откровения Новичка. Введение: Сквозь Густой Лес Курсов в Мир Конвертации Данных 3.0. Начинающий в мире программирования, я чувствовал себя, как путник в густом лесу, полном терминов и инструментов. Мир конвертации данных 3.0 предоставил мне мачете в виде онлайн-курсов, и я решил пробежаться по ним»
Это бесподобно! В своей версии материала расскажу про личный опыт в КД3.0 после изучения пары курсов и пары выполненных задач. Материал будет состоять из двух частей, в первой рассмотрим минимальные требования к КД 3.0.
Минимальные требования к КД 3.0:
- Платформа 8.3.
- БСП 2.2.5
Сравнение КД 2.1 и КД3.0
| КД 3.0 | КД 2.1 |
|---|---|
| Наличие формата (пакет XDTO) | Отсутствие формата |
| Обязательное наличие БСП не ниже 2.2.5 | Можно работать как с использованием БСП, так и без нее |
| Настраиваются правила по обмену с объектами формата, как бы с XDTO пакетом (ниже будет приведено технически более верная формулировка)* | Отдельно настраиваются правила обмена с каждой конфигурацией, участвующей в обмене, т.е. правила чувствительны к изменению конфигурации |
| Результатом работы является код общего модуля | Результатом работы является XML файл правил. |
| Трудоемкость создания правил выше. Преимущественно используется при создании постоянного обмена | Трудоемкость создания правил ниже. Преимущественно используется для разовых выгрузок данных, для переходов на другую конфигурацию и т.д. |
* Мы настраиваем правила по сопоставлению объектов 1С и объектов формата (пакет XDTO), а в результате получаем код, по которому согласно схеме (XSD), описанной в формате выгружаем данные в файл XML.
Главное отличие КД 3.0 от прошлых версий – это наличие формата (XDTO пакет). Если в КД 2.1 настраиваются правила именно для пары конфигураций, то в КД 3.0 мы настраиваем правила как бы с мифической конфигурацией, а на самом деле, как бы с пакетом XDTO (технически более верно – см.* выше).
Например, у нас есть 2 базы данных БД 1 и БД 2. Для настройки обмена через КД 2.1 нам нужно прописать правила для каждой из этих баз, но, если добавляется еще одна база данных БД 3, тогда нам нужно прописать правила еще и для нее, а если предполагается обмен БД3 с БД1 и БД2 одновременно, тогда необходимо прописывать правила для каждой из них. Если для какой-то базы данных меняется конфигурация, тогда правила также необходимо изменить для всех баз участвующих в обмене. В КД 3.0 же мы описываем правила обмена только для текущей базы данных с объектами формата (пакета XDTO). При этом нам вообще не важны конфигурации баз, с которыми мы обмениваемся. В пакете XDTO может не быть подходящих полей, но добавить эти поля – не такая трудоемкая задача, как поменять правила обмена с несколькими БД.
Это похоже на некую шину данных или на интегратор API курьерских служб (APIShip или что-то подобное, если кто-то сталкивался). Когда есть несколько систем с разными форматами обмена и разными объектами и полями, и мы вместо того чтобы, «дружить» эти все системы между собой настраиваем обмен только с одной системой – центральной (в нашем случае XDTO пакет). Технически не верно сказать, что мы обмениваемся с XDTO пакетом, просто этот пакет будет присутствовать в каждой из наших систем. В результате работы с КД 3.0 мы получим код, который создает XML файл согласно схеме этого пакета, а без КД 3.0 мы писали бы этот код сами.
Про XDTO
Про XDTO написано уже много статей, но все же затрону некоторые моменты. Будем оперировать терминами Тип Объекта XDTO и Объект XDTO. Тип Объекта XDTO – это сущность, которую мы определяем в пакете XDTO, а Объект XDTO – это то, что мы используем затем в коде при создании XML документа. Объект XDTO создается из типа XDTO. Это можно сравнить с классом и объектом в ООП. Класс – Тип Объекта XDTO, а Объект, соответственно – Объект XDTO, т.е. это как чертеж и изготовленная по нему деталь. В конце раздела, я еще напишу про это. Будет понятнее.
Если коротко, то XDTO пакет — это набор возможных полей и их типов. Это не объекты 1С, не ссылки, структуры, таблицы значений, а преимущественно поля простых типов (строка, число, булево и т.д.), объединенные в Тип Объекта XDTO. А Объект XDTO, в конечном итоге – это всего лишь узел XML документа (всего лишь еще одна строка в этом документе, которая объединяет под собой заданные нами поля). В качестве типа поля в XDTO могут выступать УУИД, base64 (используется, например, для передачи файлов) и др. Или более сложный тип — другой Тип Объекта XDTO, но в результате все равно получим файл, где будет текст в формате XML c данными, заполненными согласно XDTO пакету с описанием типов полей согласно тому же XDTO пакету. Конечно, можно использовать XDTO пакет без XML документа, когда осуществляется обмен по веб-сервису, но это отдельная тема.
Если посмотреть историческую справку, то в более ранних версиях 1С не было XDTO, а XML документы разработчики создавали вручную при помощи кода, что довольно трудоемко. Затем появилась технология XDTO, которая сильно упростила данный процесс. XDTO позволяет создавать XML документ быстрее, обеспечивает валидацию данных (на соответствие типу, на заполненность и т.д.), а самое главное – мы можем передать схему XSD разработчикам той системы, с которой мы обмениваемся. С ее помощью они уже будут разрабатывать обмен на своей стороне. При этом не важно, какая у них будет система – формат XSD понятен всем.
Некоторые особенности работы с XDTO пакетами
Если нужно задать поле обязательным для заполнения, то устанавливаем в свойствах этого поля «Минимальное количество» в 1 (вместо 0 по умолчанию). Тогда во время выполнения кода будет выдана ошибка, если это поле не заполнено.
Если нужно задать поле, так, чтобы в него можно было бы «положить» к примеру табличную часть или любой другой список, т.е. чтобы в поле могла храниться больше, чем 1 строка, то делаем это следующим образом. Например, у нас есть Тип Объекта XDTO «Документ.ЗаказКлиента» и нам нужно добавить к нему поле «Товары». Сначала добавим новый Тип Объекта XDTO «Документ.ЗаказКлиента.Товары.Строка» и в нем добавим поля, которые нам нужны (колонки ТЧ). Затем создадим Тип Объекта XDTO «Документ.ЗаказКлиента.Товары» с единственным полем «Строка». Установим в свойствах поля тип «Документ.ЗаказКлиента.Товары.Строка», только что созданный нами. Свойство «Минимальное количество» устанавливаем в 1 (почему 1 расскажу на следующем шаге), а свойство «Максимальное количество» (—1), это значение для указания того, что это поле имеет тип «Список», т.е. мы будем писать несколько строк и можем записать сколько угодно строк (ограничения на максимум нет).
Тут мы установили «Минимальное количество» в 0, чтобы иметь возможность передать заказ без товаров. Но в поле «Строка» на предыдущем шаге мы установили это свойство в 1, т.к. если мы заполняем поле «Товары» в «Документ.ЗаказКлиента.Товары», то строки товаров нужно заполнять обязательно. Видел реализации, когда так не делают, но думаю, что такая реализация менее надежная, оставляет пространство для ошибок.
О пространстве имен применительно к XDTO пакетам.
Пространство имен (URI) – это некий УУИД, который задается в первой строке пакета XDTO и идентифицирует данный пакет в рамках конфигурации. В рамках этого URI задаются все Типы Объектов XDTO в этом пакете. Имена типов должны быть уникальны в рамках этого пакета (этого пространства имен). У другого пакета свое пространство имен и уже в рамках него задаются типы этого пакета.
Код по созданию Типов XDTO и Объектов XDTO, где необходимо указать пространство имен. Становится понятна разница между Типом XDTO и Объектом XDTO, о чем я говорил в начале раздела.
//URI пространства имен пакета, как бы УУИД пакета
URIИмен = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.6";
//Создаем Тип из пакета XDTO, это непосредственно тот тип, который мы описали в пакете
ТипДокументЗаказКлиентаXDTO = ФабрикаXDTO.Тип(URIИмен, "Документ.ЗаказКлиента");
// Создаем из этого типа ОбъектXDTO
ДокументЗаказКлиентаXDTO = ФабрикаXDTO.Создать(ТипДокументЗаказКлиентаXDTO);
// Делаем тоже самое с Товарами
ТипТоварыXDTO = ФабрикаXDTO.Тип(URIИмен, "Документ.ЗаказКлиента.Товары");
ТоварыXDTO = ФабрикаXDTO.Создать(ТипТоварыXDTO);
// И присваиваем полю "Товары" значение Объект XDTO из нашей переменной ТоварыXDTO
ДокументЗаказКлиентаXDTO.Товары = ТоварыXDTO;
Затем можно также создать Объект XDTO с типом «Документ.ЗаказКлиента.Товары.Строка» (это обычно делается в цикле, т.к. строк может быть больше, чем 1) и заполнить его данными из объектов 1С. Добавление новой строки происходит так:
ТоварыXDTO.Строка.Добавить(СозданнаяИЗаполненнаяСтрокаXDTO)
В качестве типов значения полей в пакете можно выбрать типы из стандартных пространств имен. Например, поле «АдресДоставки» имеет тип значения строка из стандартного пространства имен. string (http://www.w3.org/2001/XMLSchema)
Если XDTO – это надстройка над XML, то КД 3.0 – это надстройка над XDTO. Чтобы создать документ XML через XDTO, необходимо программно создать и заполнить объекты XDTO, а с помощью КД 3.0 этого делать не нужно. Чаще мы просто сопоставляем объект 1С и объект XDTO.
Общая схема работы с КД 3.0
КД 3.0 для работы использует стандартный механизм обмена в 1С. По умолчанию используется План обмена «СинхронизацияДанныхЧерезУниверсальныйФормат». В его состав нужно включить все объекты конфигурации, для которых предполагается настраивать обмен. Затем нужно создать и настроить узлы Плана обмена в 1С:Предприятие. Затем выполнить предварительные действия в КД 3.0, которые будут описаны во второй части статьи, в пункте «Порядок создания конвертации» (загрузка конфигураций, формата, создание конвертаций и т.д.).
По окончании разработки правил нажимаем на кнопку «Сохранить модуль менеджера обмена». При этом создается код и копируется в буфер обмена. Этот код необходимо вставить в конфигурацию, для которой мы разрабатываем правила, в общий модуль «МенеджерОбменаЧерезУниверсальныйФормат» (по умолчанию, при необходимости можно настроить другой). Результатом работы данного кода будет XML файл для обмена.
Основные сокращения и термины КД 3.0
ПОД - правило обработки данных.
Это некий головной объект, отвечающий за выборку данных и за формирование дальнейшей обработки данных в ПКО. В ПОД мы выбираем какое ПКО будет использоваться для данного ПОД. Для одного ПОД может быть одно или несколько ПКО
ПКО - правило конвертации объекта.
Здесь мы делаем сопоставление объекта конфигурации и объекта формата (пакета XDTO). И далее прописываем все, необходимые ПКС для данного ПКО.
ПКС - правило конвертации свойства.
Здесь происходит сопоставление реквизитов объекта конфигурации и полей объекта формата (пакета XDTO). Типы полей могут быть как простыми, так и сложными, на которые должно быть прописано свое ПКО или ПКПД, и тогда мы должны выбрать это в поле «Правило конвертации свойства».
ПКПД - правило конвертации предопределенных данных.
ПКПД используются тогда, когда необходимо обмениваться данными для которых важно лишь соответствие значений полей. Самым ярким примером являются перечисления. Допустим в нашей конфигурации есть некое перечисление с какими-то значениями и ТипЗначения из формата (пакета XDTO). Например, ЮридическоеФизическоеЛицо и мы каждому из 2-х значений этого ТипаЗначения из формата прописываем соответствие значений перечисления из конфигурации.
Бывает так, что у нас разное количество значений в формате и в объекте конфигурации, тогда мы либо какие-то значения не используем, либо прописываем соответствие один к нескольким.
ПРО – правила регистрации объектов.
Правила регистрации объектов доступны с версии конвертации 3.1. Этот механизм перешел из 2.1 и используется, когда для объекта выгрузки нужно задать условия регистрации к выгрузке. Например, Склад = &Склад или Объект.Статус = Выполнено, также можно задать и более сложные условия.
Порядок создания конвертации
Для работы с КД 3.0 нам необходима версия платформы не ниже 8.3 и БСП не ниже 2.2.5. Подготовительные действия перед началом работы с КД 3.0:
- Загрузка конфигураций баз, с которыми предстоит настраивать обмен. Для выгрузки конфигурации в файл необходимо открыть сеанс 1С:Предприятие для нашей базы и открыть обработку MD83Exp.epf из поставки КД 3.0. Дальше там все просто. Для загрузки конфигурации в конвертацию заходим «Конфигурации / Загрузка структуры конфигурации»
- Загрузка формата (пакета XDTO). Для стандартного обмена используется пакет EnterpriseData. У меня на проектах встречались свои доработанные пакеты на основе EnterpriseData, поэтому вам нужно узнать какой пакет используется. И если вы создаете конвертацию с нуля, то правый клик по пакету «Экспорт XML-схемы». Затем в конвертации выбрать «Формат данных / Загрузка структуры формата» и загрузить только что выгруженный файл xsd. Раньше нужно было выгружать еще пакет ExchangeMessage и потом загружать оба пакета сразу. Но сейчас только один (EnterpriseData).
- Создаем новую конвертацию, даем ей имя и выбираем для нее загруженную конфигурацию и ниже в таблице выбираем формат (загруженный ранее XDTO пакет). На этом этапе стоит обратить внимание на переключатель «Версия формата менеджера обмена». Значения 1 или 2 нужно выбрать в зависимости от вашей версии БСП (можно кликнуть на «?» и посмотреть подробнее).
- Теперь мы можем приступить к настройке правил конвертации. «Конвертации / Настройка правил конвертации» И здесь выбираем созданную до этого конвертацию и начинаем работать.
Настройка обмена в 1С:Предприятие для обмена через локальный каталог
Обмен настраиваем в той базе, для которой пишем правила.
Перед настройкой обмена в 1С:Предприятие, необходимо зайти в конфигуратор и определить состав нашего Плана обмена. Авто регистрацию ставим в значение «Запретить». План обмена, который используется по умолчанию: «СинхронизацияДанныхЧерезУниверсальныйФормат». Важно: на каждый объект, который присутствует в составе плана обмена, заводить ПОД (Правило обработки данных) в конвертации. Должно быть строгое соответствие между составом Плана обмена и вкладкой ПОД в КД 3.0. В противном случае будут ошибки.
Для первоначальной настройки обмена в базе, для которой предстоит писать конвертацию, необходимо в сеансе 1С:Предприятие зайти «Обмен / Настройки синхронизации данных», нажать в настройках кнопку «Настроить синхронизацию данных / Полная синхронизация».
Дальше «Указать настройки вручную», кликнуть «Далее», «Другие каналы связи», кликнуть «Далее», установить галку «Настроить подключение через локальный или сетевой каталог» и задать сам каталог.
Кликнуть «Далее», еще раз кликнуть «Далее» и будет такое окно:
Задаем префикс базы, с которой предстоит обмениваться и нажимаем «Далее».
Снимаем галку «Выполнить отправку данных…», т.к. при настройке обмена были зарегистрированы к отправке все объекты, включенные в состав Плана обмена. Нам этого не нужно, потому что мы еще не настроили правила конвертации.
Для остальных баз, участвующих в обмене можно настроить обмен еще проще. На первом шаге выбрать не «Указать настройки ручную», а загрузить файл с настройками, созданными в другой программе. И выбрать файл настроек из папки, которую мы задали в качестве каталога обмена.
Во второй части материала рассмотрим
- Описание разработки правил и некоторые приемы работы.
- Разработку правил для простого справочника.
- ПКПД. Передача Родителя иерархического справочника. Как заполнять поля, которые есть в формате, но их нет в объекте конфигурации. Алгоритмы. Обработчик события «При отправке».
- Передача табличной части документа. Передача реквизитов, которых нет в приемнике. Отложенное заполнение реквизитов. Отложенное проведение документов. Параметры конвертации.
Автор: Александр Д., разработчик 1С.
