Что такое кд 1с
Механизм сопоставления данных при обмене через универсальный формат
Механизм сопоставления данных предназначен для решения задачи синхронизации данных между базой источника и базой приемника при обмене
Внутренние идентификаторы объектов
В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.
На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.
В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).
Публичные идентификаторы объектов
Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ).
Рис. 1 Регистр сведений Публичные идентификаторы синхронизируемых объектов
Структура регистра представлена в таблице:
Список открывается по команде Выполнить сопоставление на странице Сопоставление данных Помощника интерактивной синхронизации данных. Также можно дважды щелкнуть мышью по строке, в которой обнаружены проблемы сопоставления данных.
Список состоит из двух колонок, каждая из которых соответствует информационной базе, участвующей в обмене. Данные сгруппированы по объектам программы (документы, списки). В нижней части списка выводится информационная строка: сколько элементов сопоставлено, сколько не сопоставлено.
В поле Выводить можно выбрать, какие данные показывать в списке. По умолчанию выводятся Несопоставленные данные.
Сопоставление объектов
- Нажмите Сопоставить автоматически (рекомендуется), выберите поля для сопоставления с помощью флажков. Некоторые поля выбраны программой по умолчанию. Для того чтобы подтвердить свой выбор, нажмите Выполнить сопоставление. После поиска программа выводит на просмотр сопоставленные ею данные. Для подтверждения нажмите Применить.
- После автоматического сопоставления можно оставшиеся объекты сопоставить вручную или изменить сопоставление объектов. Выделите нужные объекты двух баз, нажмите Отменить соответствие, для того чтобы попытаться сопоставить объекты вручную, нажмите Установить соответствие для того чтобы сопоставить объекты.
- Для подтверждения нажмите Записать и закрыть.
Настройка полей таблицы сопоставления
- Нажмите Колонки, чтобы добавить поля в колонки списка. С помощью флажков можно отметить дополнительные поля, для подтверждения нажмите Применить.
Получение данных из другой программы
Порядок сопоставления объектов
Варианты идентификации объектов при получении
Порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных. Правила ПКО находятся в общем модуле МенеджерОбменаЧерезУниверсальныйФормат
Рис 3 Разделы общего модуля МенеджерОбменаЧерезУниверсальныйФормат
Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО
Рис 4. Настройки идентификации в модуле менеджера
Существуют 3 варианта ( 3 значения) идентификации объекта
Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.
Алгоритм поиска по полям
Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.
Переход к следующему варианту осуществляется в двух случаях:
- У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
- Вариант поиска не дал результата.
В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.
Особенности.
При сопоставлении на этапе анализа данных у загружаемых объектов не проверяется заполнение полей, участвующих в поиске.
На этапе анализа данных соответствие будет установлено только в том случае, когда для одного объекта отправителя был найден один объект получателя.
На этапе загрузки данных соответствие будет установлено и в том случае, когда для одного объекта отправителя нашлось несколько объектов получателя. В такой ситуации соответствие будет установлено с одним из них.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.
Механизм сопоставления данных при обмене через универсальный формат
Логично ожидать, что при синхронизации данных, как начальной, так и основанной на регулярной основе, одинаковые данные в приложениях будут сопоставлены между собой.
Для решения этой задачи как раз и предназначен механизм сопоставления данных.
В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.
На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.
В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).
Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ ). Структура регистра представлена в таблице:
ПланВидовХарактеристикСсылка,
ДокументСсылка
При получении данных записи в регистре могут появляться на нескольких этапах (см. рисунок 1). Подробное описание самих алгоритмов сопоставления см. далее.
Рисунок 1. Этапы, на которых могут быть сделаны записи в РПИ
Этапы, помеченные пунктиром, опциональные: при выполнении сеанса обмена в автоматическом режиме отсутствуют этапы 1 и 2, при выполнении в интерактивном режиме этап 2 может быть пропущен пользователем.
В процессе обмена данные РПИ обеспечивают следующую функциональность:
- Сопоставление объектов при получении данных (см. рисунок 2-а).
- Обработка получаемых данных (замена ссылок) с целью обеспечения ссылочной целостности (см. рисунок 2-b).
- Обработка отправляемых данных (замена ссылок) для исключения повторного сопоставления на стороне приложения-корреспондента уже сопоставленных данных (см. рисунок 2-b).
Рисунок 2. Использование данных РПИ при получении и при отправке данных.
Прикладная логика, определяющая порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных.
Все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки (подробнее в статье Методика работы с конфигурацией "Конвертация данных 3.0" ) формируют так называемый менеджер обмена . Код менеджера обмена разрабатывается в общем модуле (подробное описание см. в документации по БСП , в разделе Обмен через универсальный формат ). Модуль создается автоматически с помощью КД3.0 на основе настроенных правил обмена либо вручную в конфигураторе (см. пример - общий модуль _ДемоМенеджерОбменаЧерезУниверсальныйФормат демо-конфигурации БСП ).
Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО и может принимать одно из трех значений:
- ПоУникальномуИдентификатору - идентификация по GUID,
- СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска - идентификация по GUID и полям поиска,
- ПоПолямПоиска - идентификация по полям поиска,
Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.
Рисунок 3. Настройки идентификации в модуле менеджера и в КД3.0.
В таблице 1 представлено описание использования данных настроек при автоматическом сопоставлении на разных этапах получения данных:
Этап анализа данных (при загрузке через помощник синхронизации данных)
Ручное сопоставление (при загрузке через помощник синхронизации данных)
Идентификация по РПИ .
Идентификация по GUID.
Запись соответствий в РПИ: делается, если соответствие нашлось при выполнении п.3.
Сопоставлять можно со всеми объектами соответствующего типа, для которых нет соответствий в РПИ .
Запись соответствий в РПИ: делается по результатам сопоставления.
Идентификация по РПИ .
Идентификация по GUID среди объектов, отсутствующих в РПИ .
Запись соответствий в РПИ: делается для либо с исходным GUID, либо с вновь сгенерированным, п. 1 не дал результата но объект с таким GUID уже есть в РПИ .
Аналогично варианту "По GUID".
Идентификация по РПИ .
Идентификация по GUID.
Запись соответствий в РПИ: см. выше.
См. колонку "Загрузка данных"
Запись соответствий в РПИ: не делаются.
Таблица 1. Правила работы настроек идентификации.
Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.
Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска.
Переход к следующему варианту осуществляется в двух случаях:
- У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
- Вариант поиска не дал результата.
Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта "По GUID" или "По GUID и полям поиска", то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.
В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.
Особенность.
При сопоставлении на этапе анализа данных у загружаемых объектов не проверяется заполнение полей, участвующих в поиске.
Особенность.
На этапе анализа данных соответствие будет установлено только в том случае, когда для одного объекта отправителя был найден один объект получателя.
На этапе загрузки данных соответствие будет установлено и в том случае, когда для одного объекта отправителя нашлось несколько объектов получателя. В такой ситуации соответствие будет установлено с одним из них.
Особенность.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.
Многие специалисты работали с обменами данных в КД 2.0/2.1. Конвертация 3.0 представляет совершенно новую технологию. Сейчас мы расскажем её суть.
В чем суть Конвертации данных 3.0
Конфигурация «Конвертация данных» впервые была выпущена фирмой 1С для платформы 7.7, и с тех пор механизмы обменов данными развивались в рамках одного подхода.
Все обмены между различными по структуре базами 1С требовали написания правил обмена.
При таком подходе в базе-Источнике каждый объект проходит ряд преобразований, которые описаны в правилах, созданных для этой пары баз.
Xml-узел, в который выгружается этот объект, по структуре аналогичен объекту в базе-Приемнике. При загрузке его остается только преобразовать в объект информационной базы.
Для того, чтобы создать правила, нужно знать структуру метаданных базы-Источника и базы-Приемника, и описать преобразование объектов всех нужных типов. Правила выгружаются во внешний xml-файл, который используется каждый раз при выгрузке.
Одна из проблем этого подхода заключается в том, что после каждого изменения конфигурации баз Источника или Приемника необходимо проверять правила на актуальность, что является долгим и не всегда простым процессом.
Тем более, что, если обмен выполняется в обе стороны, то таких правил двое.
В октябре 2014 года была выпущена первая версия «Конвертации данных», редакция 3.0, предназначенная для тестирования.
Новая технология, реализованная в «Конвертации данных 3.0», призвана обособить процессы выгрузки и загрузки, сделать их независимыми. Для этого создана совершенно другая концепция обмена.
Данные будут выгружаться в формат EnterpriseData, который не зависит напрямую от структуры баз Источника и Приемника.
Он предоставляется в виде xsd схемы, на основании которой формируется механизм преобразования объектов между этим форматом и любыми объектами информационных баз. Для упрощения этих преобразований формат EnterpriseData содержит объекты, аналогичные объектам метаданных типовых конфигураций.
При обмене через универсальный формат в каждой из баз содержится только код для преобразования объектов из базы в универсальный формат EnterpriseData и обратно.
При выгрузке не используется информация о том, какую структуру имеют базы-получатели. Поэтому при изменении конфигурации каждой из баз, участвующих в обмене, нужно будет изменить этот код только в этой базе.
Этот код находится в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Там же находятся и все обработчики событий, и весь механизм преобразования объектов, благодаря чему значительно упрощается процесс отладки. Там же могут быть описаны параметры, с помощью которых можно использовать единожды описанную там логику преобразования объектов для обмена с разными базами.
При необходимости разработчик может изменить структуру формата EnterpriseData для решения более широкого круга задач.
В процессе настройки обмена сама конфигурация «Конвертация данных 3.0» выполняет на данный момент только одну функцию — на базе структуры метаданных баз, участвующих в обмене, и схемы универсального формата она формирует тексты общих модулей МенеджерОбменаЧерезУниверсальныйФормат для каждой из баз.
Удобным будет сформировать эти модули на начальных этапах настройки обмена, а дальнейшие доработки выполнять непосредственно в тексте модулей в конфигураторе.
Новый механизм обмена не исключает также использования правил регистрации. Их настройка в настоящий момент выполняется с помощью конфигурации «Конвертация данных 2.0».
Таким образом, новая технология имеет ряд преимуществ:
- Для обмена между тремя и более базами не нужно создавать отдельные правила для каждой пары баз
- Упрощается поддержка обменов данными в случае изменения конфигураций баз
- Создан новый универсальный формат, который может быть использован, в частности, для обмена со сторонними базами
- Упрощается отладка алгоритмов, используемых при выгрузке-загрузке объектов.
В ближайшей перспективе планируется постепенный перевод всех обменов между типовыми конфигурациями на новый стандарт.
Однако обмен через Универсальный формат не рассматривается как полная замена технологии обменов по правилам. «Конвертация данных» редакции 2.0/2.1 будет поддерживаться и дальше, так как для решения определенного круга задач она остается более удобным и гибким механизмом.
PDF-версия статьи для участников группы ВКонтакте
Рис 1 Общий модуль менеджера обмена
Поставка КД3.0 содержит следующие внешние обработки
1. Подготовка к настройке правил
Для загрузки структуры формата нужно сначала открыть конфигурацию базу данных в режиме конфигуратора и выгрузить пакеты XDTO из конфигурации в файлы *.xsd.
Необходимо выгружать все пакеты, которые связаны с форматом. Имена файлов при этом принципиального значения не имеют. Необходимо также выгружать XDTO-пакет ExchangeMessage
Данная обработка выполняет загрузку структуры метаданных конфигурации в информационную базу Конвертация данных ред.3.
Для выгрузки информации о структуре информационной базы используется обработка MD83Exp.epf, входящая в комплект поставки конфигурации КД3.0
Для информационной базы, структуру которой необходимо выгрузить, следует выполнить следующие действия:
После выполнения выгрузки структуры конфигурации заполняются справочники
- Объекты метаданных
- Свойства объектов
- Значения объектов .
Справочник Объекты метаданных содержит информацию об объектах метаданных конфигурации. Тип объектов фиксируется в соответствующем реквизите. В зависимости от значения реквизита Тип, заполняются реквизиты, описывающие свойства объекта метаданных. Реквизиты объектов метаданных описываются в подчиненном справочнике Свойства объектов . Значения объектов (значения перечислений и имена предопределенных элементов) описываются в подчиненном справочнике Значения объектов.
1.3. Загрузка правил синхронизации через универсальный формат из файлов
Перед загрузкой правил синхронизации через универсальный формат из файлов быть загружен формат данных( с помощью обработки Загрузка структуры формата (см.пункт 1.1), а также должна быть загружена конфигурация, для которой настраиваются правила синхронизации. Загрузка конфигурации выполняется с помощью обработки Загрузка структуры конфигурации (см.пункт 1.2). Отметим также, что быть создан элемент справочника Конвертации . Для конвертации должна быть указана конфигурация и одна или несколько версий формата, для которых конвертация предназначена.
1.3.1 Подготовка файлов для загрузки правил
Подготовка файлов выполняется в информационной базе, для которой будет выполняться обмен в универсальном формате (например, Бухгалтерия предприятия ред.3.0).
Для подготовки файлов правил необходимо войти в информационную базу в режиме Предприятие и запустить обработку Выгрузка правил синхронизации через универсальный формат, которая входит в состав поставки конфигурации Конвертация данных ред.3.
Для подготовки файла с модулем менеджера необходимо войти в информационную базу в режиме Конфигуратор и сохранить общий модуль МенеджерОбменаЧерезУниверсальныйФормат в текстовый файл. Имя файла можно указать любое.
Все подготовленные файлы должны располагаться в одном каталоге.
1.3.2 Загрузка правил синхронизации
Выполняется в информационной базе Конвертация данных ред.3 с помощью обработки Загрузка правил синхронизации из файлов.
Читайте также:
- Как в макбуке сохранить документ в ворде
- Ворд жокей что такое
- Каких данных нет в экспорте статистики excel записи в сообществах рекламного кабинета
- Как в excel в 1 ячейке
- Ashampoo ru toolbar что это за программа