Что такое кд2 в 1с
В статье описан порядок действий при подключении нетиповых документов к механизму «Синхронизация данных через универсальный формат» (КД 3.0).
В контексте данной статьи термин «нетиповой» означает, что документ не описан ни в одном из XDTO-пакетов механизма «Синхронизация данных через универсальный формат».
Если же документ описан в типовом XDTO-пакете, то порядок его подключения к обмену можно посмотреть в статье «Обмен через универсальный формат (КД 3.0): подключение типового документа».
1. Зачем изменять типовой XDTO-пакет?
Основной смысл технологии КД 3.0 (обмен через универсальный формат) – это добиться «универсальности» правил обмена, чтобы правила выгрузки/загрузки объектов не зависели от того, какая конфигурация (или ее релиз) находятся на том «конце провода». И если мы корректируем типовой XDTO-пакет, то мы эту «универсальность» разрушаем.
Но в полной мере преимуществом «универсальности» может воспользоваться только сама 1С (и ее партнеры – разработчики конфигураций), которая таким образом упрощает себе процедуры обновления правил обмена при переходе от одного релиза типовых конфигураций 1С 8.3 к другим, а также упрощает подключения к обменам новых конфигураций.
На стороне пользователя выгоды от «универсальности» гораздо меньше, ведь он работает с конкретной конфигурацией-источником и конкретной конфигурацией-приемником. Все изменения правил обмена между этими конфигурациями (в т.ч. структура XDTO-пакетов) согласованы внутри его «корпорации». А то, что его правила обмена становятся несовместимы с правилами обмена, принятыми в других «корпорациях», его в большинстве случаев не волнует. Поэтому изменить структуру XDTO-пакета обычно некритично.
Более того, если речь идет о добавлении в обмен новых объектов, то технически это проще сделать через технологию КД 2.0:
· Там нужно писать всего один комплект правил обмена вместо двух для КД 3.0.
· Включение в обмен КД 3.0 промежуточного «универсального формата» сильно повышает уровень абстракции (он уже не связан напрямую с прикладной областью) и избыточности (он же «универсальный»). А это, в свою очередь, повышает требования к квалификации специалистов, которые этот обмен будут настраивать.
Но в последних конфигурациях 1С продвигается обмен именно по технологии КД 3.0. И чтобы для своих нетиповых объектов не строить параллельно еще и второй механизм обмена (на КД 2.0), приходится корректировать типовые XDTO-пакеты.
Есть описания примеров, когда для нетиповых объектов создаются отдельные XDTO-пакеты, а для работы с ними в 1С запускается отдельная 1С 8.3 XDTO-фабрика. Но это опять-таки – построение параллельного механизма обмена (два механизма на КД 3.0), а этого хочется избежать.
Итак, если мы хотим остаться внутри единого механизма «Синхронизация данных через универсальный формат», и для нас некритичен факт изменения типового XDTO-пакета, то изменим типовой XDTO-пакет.
2. Образцы описания документа в XDTO-пакете
Объекты обмена, которые включены в состав механизма «Синхронизация данных через универсальный формат», описаны в XDTO-пакетах, наименования которых начинаются с «EnterpriseData». Например, EnterpriseData_1_2_3 … EnterpriseData_1_6_20, где 1_2, … 1_6 – это номера «версий форматов».
Добавлять описание своего объекта необязательно во все XDTO-пакеты EnterpriseData_1_2_3 … EnterpriseData_1_6_20. Достаточно это сделать только для того номера версии формата, на котором обмениваются наши конкретные конфигурации. Узнать его можно в настройках синхронизации данных.
Т.е. в нашем примере достаточно скорректировать пакет EnterpriseData_1_5_20.
Корректировать XDTO-пакет можно либо вручную, либо с использованием специализированного редактора.
Посмотрим на образец описания документа. В примере добавляем описание нетипового документа «экзРапортФ114». Вносим описание типа значения:
Вносим описание его структуры (реквизиты шапки, в т.ч. ключевые свойства, табличную часть «Сырье» и реквизиты строки табличной части:
Такую настройку необходимо выполнить в обеих обменивающихся конфигурациях. Поскольку одноименные XDTO-пакеты во всех конфигурациях одинаковы, то настройку достаточно произвести в одной из них, а во вторую – перенести настройки через «сравнение и объединение».
3. Обновление 1С 8.3 записей регистра сведений НастройкиОбменаДаннымиXDTO
После добавления описания документа в XDTO-пакет есть один тонкий момент. Даже если Вы включили свой документ (в примере - это «экзРапортФ114» синоним «Рапорт на выработку комбикорма») в состав плана обмена «СинхронизацияДанныхЧерезУниверсальныйФормат», и он появится на форме регистрации изменений, этот документ еще не включен в механизм обмена. Об этом свидетельствует его отсутствие на ветке «AvailableObjectTypes» файла обмена.
Дело в том, что механизм обмена содержит в себе описание «доступных объектов», которое среди прочего хранится в регистре сведений НастройкиОбменаДаннымиXDTO. «Доступные объекты» в этом регистре заполняются:
А) Из состава XDTO-пакет при первичной настройке плана обмена à определяются объекты, которые «в принципе могут обмениваться».
Б) При анализе правил обмена текущей конфигурации à уточняется перечень объектов, доступных на «прием» и «отправку» относительно текущей базы.
В) При анализе ветки AvailableObjectTypes полученного файла обмена от конфигурации-корреспондента à уточняется перечень объектов, доступных на «прием» и «отправку» относительно конфигурации-корреспондента.
Объект становится «доступным на отправку», если он «в принципе может обмениваться» (выполнен п.А), имеет правила «на отправку» в текущей базе (п.Б) и имеет правила «на приемку» в базе-корреспонденте (п.В). Аналогично «доступен на приемку», если есть п.А, есть правила «на приемку» у текущей (п.Б) и правила «на отправку» у корреспондента (п.В).
Для того, чтобы выполнить п.Б и п.В достаточно настроить правила обмена (инструкции и примеры можно найти в интернете оп запросу «1С:Конвертация данных 3»).
А вот с п.А сложнее. Как уже сказано, он выполняется при первичной настройке плана обмена 1С 8.3. Когда Вы добавляете свой объект, как правило, первичная настройка обмена уже произведена. Как быть?
Можно, например, в настройку синхронизации добавить команду «Обновить настройку синхронизации», которая перечитывает состав XDTO-пакетов. Текст модуля этой команды приведен в прил.1.
Данную команду необходимо настроить и выполнить в обеих обменивающих конфигурациях.
После того как Вы включили свой нетиповой документ в состав «доступных объектов», в т.ч. выполнили настройку правил обмена, Ваш документ появится на ветке AvailableObjectTypes.
В примере выполняется односторонний обмен документом «экзРапортФ114» из конфигурации Бухгалтерия 3.0 в конфигурацию «1С:ERP Управление предприятием 2». Поэтому в файле, выгруженном из «1С:Бухгалтерия 3.0» документ прописан на ветке «Sending».
А в файле, выгруженном из «1С:ERP Управление предприятием 2», документ прописан на ветке «Receiving»/
Нетиповой документ готов к обмену через типовой механизм.
Если документ не описан в XDTO-пакете, то для его включения в обмен посредством механизма «Синхронизация данных через универсальный формат» необходимо выполнить следующие процедуры:
1. Описать документ в XDTO-пакете обеих обменивающихся конфигураций.
2. Обновить записи регистра сведений НастройкиОбменаДаннымиXDTO обеих обменивающихся баз.
3. Выполнить действия для «типовых» документов (см. статью «Обмен через универсальный формат (КД 3.0): подключение типового документа», - ссылка в начале):
a. В конфигурации-источнике подключить документ в состав плана обмена «СинхронизацияДанныхЧерезУниверсальныйФормат».
b. Настроить правила обмена (КД 3.0) в обеих конфигурациях
Данный способ универсален и пригоден для любых конфигураций и любых видов объектов (Документов, Справочников и т.п.).
Правила конвертации. "Конвертация данных" (далее "КД") - это конфигурация/база 1С, где описываются правила, по которым данные из базы-источника (далее "источник") должны преобразовываться в данные базы-приемника (далее "приемник"). Эти правила выгружаются в xml-файл. И все. Больше КД не делает ничего. Несмотря на название, сама конвертация данных - это уже не ее забота. Это просто "конфигуратор" (или если хотите - IDE для разработки правил). Кто же выполняет саму конвертацию? Изначально за это отвечали внешние обработки выгрузки/загрузки, входящие в комплект поставки КД.
Выгрузка. Обработка выгрузки запускается в источнике, ей указывается файл с правилами из КД, некоторые дополнительные настройки выгрузки (типа отборов данных) и обработка формирует файл обмена. И тут важный момент - в файл обмена пишутся УЖЕ КОНВЕРТИРОВАННЫЕ согласно правилам конвертации данные (фактически это готовые образы объектов для загрузки в приемник) плюс информация из правил обмена о поиске нужных объектов в приемнике, плюс тексты программных обработчиков, которые должны быть выполнены при загрузке данных в приемнике (они будут выполняться в нужных местах с помощью банального "Выполнить"). Теперь повторю важный момент с другого ракурса - в нормальной ситуации ВСЯ КОНВЕРТАЦИЯ ВЫПОЛНЯЕТСЯ В ИСТОЧНИКЕ. То есть и все правила конвертации с их взаимосвязями анализируются в источнике и почти все самые важные с точки зрения конвертации программные обработчики - также выполняются в источнике. Этот момент нужно держать в голове, когда вы пишите код программных обработчиков в КД. Это обычный код 1С, который будет исполнен в источнике с помощью инструкции "Выполнить" в контексте алгоритма выгрузки данных. И, соответственно, в этом контексте вы имеете полный доступ к базе источника и можете писать любой корректный для нее код 1С. А как же упомянутые обработчики "при загрузке", спросите вы? Скажу, что в 99% случаев обработчики на стороне приемника не нужны. Но новички часто ими злоупотребляют по банальной причине - они еще не знают, как настроить правила конвертации правильно, а обработчики в приемнике как-то проще для понимания. Код - он и в Африке код :) Но такой стиль ущербен по многим причинам, так как идет в разрез с неявной идеологией КД. Плюс использование обработчиков при загрузке часто сильно замедляет эту самую загрузку. В нормальной конвертации загрузка сводится просто к поиску/созданию нужного объекта и загрузке в него готовых данных, конвертированных еще в источнике. Но если обработчики "при загрузке" вам все-таки нужны, в них, естественно, вы пишите код уже для приемника. Прямого доступа к источнику там уже нет.
Кстати! Многие не сразу понимают этот ньюанс. Ни в один момент времени не существует одновременного доступа к данным и источника и приемника. Даже для случаев обмена через COM остается четкая модель разделения процесса на выгрузку и загрузку. В обычной ситуации, данных источника и метаданных приемника вполне достаточно для правильной конвертации данных (т.е. для выполнения всей конвертации в источнике). Эта идея и заложена в основу идеологии КД. Но бывают редкие случаи, когда нужных для правильной конвертации данных в источнике нет и также нет ни одного способа их вычислить на основании имеющихся в источнике данных. Вот для таких редких случаев на выручку и приходят обработчики на стороне приемника (при загрузке).
Загрузка. В базе-приемнике запускается обработка загрузки данных, указывается файл обмена и. все. Выполняется загрузка :) Вся необходимая информация уже содержится в файле обмена. И так получилось, что почти все про загрузку я уже сказал, когда говорил про выгрузку :)
Итак, первоначально обмен данными между разными конфигурациями производился через внешние обработки. Но потребностей и задач обмена данными становилось все больше, какие-то части алгоритмов обработок выгрузки/загрузки стали засовывать в универсальные модули типовых конфигураций (предтеча БСП) плюс добавляли дополнительный функционал обмена в типовых (вроде использования планов обмена, работы через COM и прочее), потом появилась БСП где это все выделили в отдельную подсистему и навешали сверху еще плюшек, но основа остается неизменной. Просто правила конвертации, сделанные в КД, теперь засовываются в нужные места типовых на базе БСП и поверх этого накручено еще много полезных настроек, которые делаются уже в рамках подсистемы БСП "Обмен данными" (подробнее про все богатство ее функционала читайте на ИТС в документации по БСП в описании подсистемы "Обмен данными").
КОНЦЕПЦИИ РАЗРАБОТКИ ПРАВИЛ КОНВЕРТАЦИИ
Теперь, когда с процессом обмена данными с высоты птичьего полета должно быть примерно понятно, вернемся к собственно разработке правил конвертации.
Конфигурации. Очевидно, что КД должна обладать знаниями о метаданных источника и приемника. Они загружается в служебные справочники (главный из них - "Конфигурации") через xml-файлы (которые выгружаются из баз источника/приемника специальными обработками, входящими в состав поставки КД). Соответственно, если конфигурации баз источника/приемника изменяются, то описание их метаданных в КД тоже нужно обновлять. Или не нужно, если изменения не затрагивают конвертацию :)
Конвертации. В одной базе КД можно настраивать множество правил обмена между разными конфигурациями. Они идентифицируются элементами справочника "Конвертации", в каждом из которых выбираются конфигурации источника и приемника. Каждая конвертация - это по сути набор.
Правил конвертации объектов (далее ПКО). ПКО - сердце КД. Как следует из названия, каждое ПКО отвечает за конвертацию какого-то вида объекта (справочника, документа и пр). Нужно понимать, что само по себе ПКО - штука пассивная. Ему надо каким-то образом на вход подать данные, а на выходе оно "выплюнет" образ объекта-приемника для записи в файл обмена. Я обтекаемо написал про "данные" на входе, потому что не всегда в источнике есть подходящий объект (если конфигурации сильно отличаются). Это может быть и программная структура. Если случай простой, и выполняется конвертация "объект-объект", то тогда прямо в свойствах ПКО указывается исходный объект источника и это облегчает дальнейшую настройку. Но в общем случае объекта-источника может и не быть - тогда данные на вход формируются программно. Может быть несколько разных ПКО для одного и того же объекта приемника, но для разных целей.
Вернемся к основной цели ПКО - "выплюнуть" образ данных объекта приемника для записи в файл обмена. Из этого вытекает то, что у ПКО заранее и железно предопределено - это вид объекта приемника и его поля. И так как эти поля имеют смысл только вместе с правилами их заполнения/конвертации, то они называются.
Правила конвертации свойств (далее ПКС). Суть у ПКС такая же, как у ПКО, только уровнем ниже - "выплюнуть" на выход конвертированное поле объекта приемника для записи в файл обмена. Так как в процессе отработки ПКО у самого ПКО так или иначе поданы на вход какие-то данные, то по умолчанию на вход ПКС также подается одноименное свойство из этих данных. Если у ПКО явно задан источник, то можно параметрически выбрать поле источника, которое будет подано на вход (это самый простой случай). Также данные на вход можно подать программно. Итак, данные на входе есть, нужно теперь их при необходимости конвертировать. Если поле имеет примитивный тип и на вход подан такой же - то красота. Вообще ничего делать не надо. А если не примитивный? Тогда. можно параметрически выбрать готовое ПКО, по которому оно будет конвертировано! Вот ради этого красивого жеста и был весь сыр-бор. Единожды оформленное ПКО можно переиспользовать во всех ПКС всех ПКО, где это необходимо. КД по умолчанию поддерживает конвертацию по ссылкам. Это означает, что при конвертации объекта по ПКО входные данные из его ПКС будут переданы на вход указанным в них ПКО и все это рекурсивно повторяется вниз-вниз-вниз. В результате будут автоматически конвертированы и выгружены ВСЕ связанные объекты (это поведение можно изменить). Правда, красота нечеловеческая? Как-то мне пришлось самому писать похожую систему для тесной интеграции 1С с одним внешним продуктом и конвертацией по ссылкам. С тех пор я нежно люблю КД.
У ПКС, так же как и у ПКО, есть собственный набор обработчиков со своими "ручечками" и "кнопочками". Про важность этих обработчиков уже было написано выше, но для ПКС они еще важнее, чем для ПКО, так как по сути собственно конвертация часто выполняется именно на уровне ПКС. Например, в этих обработчиках можно динамически менять ПКО, по которому будет конвертироваться свойство (в зависимости от каких-то условий). Там есть доступ ко всему объекту, поданному на вход ПКО (параметр "Источник"). Можно прямо в обработчике программно назначить данные, которые будут поданы на вход ПКС (параметр "Значение") - это часто используется для конвертации примитивных типов и не только. И многое, многое другое (читайте справку по обработчикам).
Правил выгрузки данных (ПВД). Задача ПВД предельно проста - выбрать данные источника, "скормить" их на вход какого-нить ПКО и умыть руки. Можно сказать, что в отличие от пассивных ПКО, ПВД - активны. Они выбирают данные, передают их ПКО и дают отмашку на конвертацию.
В самом своем примитивном виде, при выгрузке "объект-объект" для вида выборки "стандартная выборка" достаточно параметрически указать вид объекта источника и ПКО для него. И все. В обработке выгрузки можно будет активировать это правило и указать для него стандартные отборы (при необходимости).
Для более сложных случаев предусмотрен вид выборки "произвольный алгоритм" и. правильно! ОБРАБОТЧИКИ! :) Можно, например, запросом сформировать нужную выборку данных и подать ее на вход ПКО без источника. Для произвольных выборок будут недоступны стандартные отборы обработки выгрузки, но внутри можно использовать параметры конвертации.
Вот и все. Очень многое в этой статье осталось за кадром. Конвертация значений, свойства, параметры и обработчики самой конвертации (и как их можно использовать), особенности настройки ПКГС (правил конвертаций групп свойств для табличных частей, например), приоритеты правил, особенности настроек и приоритетов правил поиска объекта в приемнике, алгоритмы (куда можно выносить повторяющийся код используемый в обработчиках), интересные приемы решения типовых задач и многое, многое другое. Но владея основными принципами, с остальным вам будет разобраться намного проще. Надеюсь :)
ЗЫ. В качестве практической части для новичков, со скриншотами и подробным руководством куда и зачем тыкать начинающему, могу порекомендовать вот эту статью.
Это пособие предназначено для тех, кто только начинает знакомиться с «Конвертация данных». С его помощью Вы сможете быстро освоить основные приемы работы с конвертацией данных и сразу приступить к делу.
Для чего нужна эта программа
Существуют различные подходы к организации обмена данными между различными информационными базами. Один из таких подходов - организация обмена данными при помощи правил обмена. Для организации обмена данными достаточно разработать правила по которым необходимо переносить данные из одной информационной базы в другую. Когда правила обмена готовы, с их помощью из информационной базы источника можно выгрузить необходимую информацию в файл обмена из которого в свою очередь эти данные можно загрузить в информационную базу приемник.
На схеме видно, что при помощи внешней обработки и правил обмена данными из информационной базы-источника выгружается файл с данными. Этот файл с данными поступает на вход внешней обработке и в информационную базу-приемник загружаются необходимые данные.
Таким образом, обмен данными можно разделить на две стадии – стадию подготовки правил обмена и стадию обмена данными. Самый сложным и ответственным этапа безусловно является подготовка правил обмена. Данная программа как раз и пердназначена для разработки правил обмена данными.
Правила обмена представляют собой задание определенного соотвествия между объектами источника и объектами приемника. Но для того, чтобы задать это соответствие нам необходимо знать информацию о структуре метаданных двух информационных баз, участвующих в обмене данными. Зная структуру метаданных мы сможем задать и соответствие типов объектов.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Как мы уже знаем, правила конвертации свойств используются для сопоставления реквизитов обменивающихся объектов. Естественно, что в правиле конвертации задаются реквизит из объекта источника и объекта приемника.
Кроме того, для ссылочных реквизитов можно указать правило конвертации объектов, которое необходимо применить для переноса значения данного реквизита.
Поиск объекта при загрузке по данному свойству - флаг определяющий нужно ли по данному свойству производить поиск объектов в информационной базе приемнике. Если сразу у нескольких реквизитов установлено свойство поиска данных, то условия поиска объединяются по "И". В этом случае правило поиска звучит следующим образом: Найти объект у которых все реквизиты поиска совпадают с источником. (ВНИМАНИЕ. Поиск по уникальному идентификатору, который может быть установлен у правила конвертации объектов более приоритетный, то есть если он установлен то поиск будет выполнен по этому идентификатору).
Отключить обработку данного правила - флаг, позволяет отключить обработку данного свойства, не удаляя его из правил конвертации объектов.
Не замещать значение данного свойства у существующих объектов ИБ - флаг, позволяет отключить обработку данного для объектов информационной базы приемника, которые были найдены по уникальному идентификатору или по полям поиска.
Автоматически приводить значение к длине приемника - флаг, позволяет включить автоматическое приведение Номера или Кода справочника соответствующему значению в приемнике по длине. При этом префиксы сохраняются, а числовые части преобразуются под длину поля в приемнике.
ТОЛЬКО ДЛЯ ОБМЕНА V8 - V8
Функционал, позволяющий передавать дополнительные параметры в информационную базу приемник из источника.
Передавать данные в приемник - флаг определяет куда будут помещены данные при загрузке. Непосредственно в найденный для изменения объект.
Передавать данные в параметр - флаг определяет куда будут помещены данные при загрузке. В отдельное соответствие для данного объекта, но не в сам объект. Этот подход удобен когда нужно передать какое либо значение в приемник, но нет реквизита куда нужно его поместить. Впоследствии анализируя дополнительные параметры можно изменить логику заполнения объекта приемника. В правилах необходимо указать имя параметра куда нужно поместить данные. Для табличных частей и наборов движений для каждой строки формируется отдельная структура в которой хранится информация.
Доступ к этим данным возможен в событии правила конвертации объекта "После загрузки". Например, так:
Выгружать элементы группы через промежуточный файл - флаг определяет как выгружать объекты данного типа, через промежуточный файл (экономично с точки зрения оперативной памяти) или напрямую через память (оптимально по скорости, но при больших объемах передаваемых данных оперативная память может закончится).
На закладке "Дополнительно" можно редактировать вхождение правила в определенную группу, а так же его описание. Наименование правила формируется автоматически и недоступно для изменения.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Читайте также: