Соответствие объектов для обмена 1с как работает
Общие правила обмена объектами метаданных между конфигурациями
В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:
- Копирование объектов метаданных через буфер обмена
- Объединение конфигурации с файлом
- Загрузка конфигурации из файла
- Хранилище конфигурации
- Обновление конфигурации, находящейся на поддержке
- Обновление конфигурации базы данных
В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по "цепочкам" конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.
Сопоставление объектов. Имя и идентификатор объекта метаданных
При перемещении объектов между конфигурациями важную роль играет вопрос их сопоставления. Необходимо иметь возможность определить, являются ли два данных объекта разными объектами или копиями одного и того же объекта. Предположим, что мы тем или иным способом скопировали объект из одной конфигурации в другую, а затем выполнили объединение этих конфигураций. Естественно ожидать, что платформа определит соответствие двух объектов, а не будет считать их разными объектами с одинаковыми именами. Для сопоставления объектов используются имя и внутренний идентификатор объекта. И если имя в процессе перемещения объекта, как правило, не изменяется (в любом случае мы можем его контролировать и, при необходимости, модифицировать), то внутренний идентификатор объекта ведет себя по-разному в зависимости от используемого механизма. В приведенной ниже таблице описываются способы сопоставления объектов и поведение внутренних идентификаторов при использовании разных механизмов.
При отключенной возможности изменений – сопоставление по идентификаторам. При включенной возможности изменений – сопоставление по идентификаторам, которые в некоторых случаях могут отличаться. В некоторых ситуациях возможна ручная установка соответствия.
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:
- Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
- Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при включенной возможности изменений.
- Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.
Можно определить следующее правило:
Например, имеются две конфигурации: одна, в которой ведется разработка и вторая - в "рабочей" базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для "старых" объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в "рабочую" базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов "восстановятся" с точки зрения конфигурации разработки, но изменятся с точки зрения "рабочей" конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.
Примеры
Параллельное создание объектов
Используется одна конфигурация в двух разных базах: в базе разработки и в базе заказчика. При обновлении конфигурации заказчика, была на месте произведена доработка, в результате которой в базу был добавлен новый объект. Затем в конфигурации разработки этот объект был добавлен вручную. Фактически мы воспользовались механизмом третьего уровня (поскольку идентификаторы у объектов получились разные). Для дальнейшей синхронизации конфигураций без потери данных можно применять только объединение (механизм третьего уровня). Для того, что бы избежать подобных проблем, следует после доработки у заказчика сохранить конфигурацию в файл, а затем загрузить ее в базу разработки.
Восстановление автоматической поддержки конфигурации поставщика
Конфигурация находится на поддержке в полностью автоматическом режиме (с отключенной возможностью изменений). Предположим, что в какой-то момент возможность изменений была включена. Например, это понадобилось для срочного исправления ошибки. После исправления ошибки поставщиком, возникла необходимость отключить возможность изменений для облегчения последующих обновлений. Но это приведет к понижению уровня механизма, а следовательно гарантированного сохранения данных информационной базы при этом добиться будет невозможно. Следует создать новую базу из дистрибутива конфигурации поставщика (с выключенной возможностью изменений) и программно перенести в нее данные.
Примеры анализа цепочки изменений конфигурации
Приведем несколько примеров анализа цепочки изменений конфигурации с точки зрения возможности потери данных.
Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.
Другой пример. Мы ведем разработку конфигурации в некоторой базе и готовим в ней файлы поставки. Кроме того, у нас есть подготовленная демонстрационная база, которую мы поставляем пользователям. После создания файла поставки очередной версии мы загружаем его в демонстрационной базе. Все использованные механизмы работают на первом уровне, поэтому расхождения идентификаторов и потери данных не произойдет.
Для получения более подробной информации по поведению идентификаторов и сопоставлению объектов, мы рекомендуем ознакомиться с циклом статей "Поставка и поддержка конфигураций".
Просветите, пожалста.
Типовой обмен УТ-БП с немного подкорректированными правилами. Когда-то был кем-то настроен.
Сейчас возникла такая ситуация, что в БП при обмене задваивается или неправильно выгружается некоторая номенклатура (в совершенно левые позиции или из нескольких в одну), в частности по которой ведется учет по характеристикам. Обмен односторонний.
В правилах настроен поиск номенклатуры по коду+коду характеристики.
1. Как вообще работает механизм поиска в этом регистре?
2. Какой приоритет поиска при загрузке объектов? Сначала в этом регистре, потом по полям поиска? Или еще каким-то образом?
к слову, чтоб не наступил. у меня был прикол, когда в регистре лежали две записи с одинаковым УИДом, но с разными _типами_ объекта (номенклатура и номенклатурные группы). представления одинаковые, отловил только с помощью ТипЗначения. весёлые соединения бывали в консоли
(0) Утверждать не берусь, но вроде как эти соответствия заполняются при первом обмене. При следующих обменах правила поиска не используются, если найдены ссылки в этом регистре. Но может и ошибаюсь.
(1) Спасиб. Я пока не хочу ловить, хочу понять логику.
(2) Посмотрел код, при выгрузке объектов, там записи тоже создаются, если не найдены.
А если попробовать сделать так: в правилах зафигачить очистку регистра перед выгрузкой и перед загрузкой данных, по идее тогда объекты должны всегда искаться по полям поиска и все.
Никто не против? :)
(4) если номенклатура меняется (добавился символ в наименовании, перенесли в другую группу) - у тебя старый останется и новый создастся. Так что я против.
(2) новые объекты туда тоже добавляются
к тому же, если потом не используется, то регистр можно просто очистить
(7) + регламент: под страхом смерти не менять значений ключевых полей. И чтоб доказать серьезность намерений - прострелить одному из бухов ногу ))))
(8) Так если будут чиститься регистры - как узнаешь какой гуид с каким элементом связан. Тут конечно можно поизвращаться на тему регистров сведений и в них хранить, но в итоге получится тот же "Соответствие объектов". Вроде и все работает, и бюджет освоен
(11) А по идентификаторам не получится искать, поскольку в УТ учет по характеристикам ведется, а в бухне - нет.
(4) А теперь и я против.
Если одна и та же номенклатура с разными характеристиками будет загружаться, то схлопнется в одну, если не очищать регистр после записи каждого объекта.
Но это же капец как затормозит работу. Так что не вариант.
У кого еще какие мысли, чтобы выйти из этой ситуации, по возможности не трогая конфу?
В блоке БСП, есть регистр сведений, хранящий информацию о связях между объектами баз, участвующими в обмене.
Случаются ситуации, когда возникают неверные связи. Они влекут за собой ошибки при обмене - к примеру - " (132:a459000e0c4e596e11e41917c6dc8625)"
А связано это с тем, что в базе источнике, в этом регистре, есть связь с объектом базы приемника, и поэтому он выгружается по ссылке.
И в случае отсутствия соответствующей записи в базе приемника, случаются проблемы.
Данная обработка упрощает поиск и удаление неверных записей.
Как работать (Будем называть базу источник - БИ, базу приемник БП):
1. В БИ открываем обработку и выбираем узел обмена. ТЧ заполняется всеми записями по данному узлу.
2. Выгрузка данных ТЧ, для анализа в БП возможен двумя способами:
а) В файл (указываем в шапке обработки) - команда "Выгрузить в файл"
б) В строку (пользуемся в том случае, если работа с файловой системой невозможна - безопасный режим, например) - команда "Выгрузить таблицы в строку"
3. Открываем обработку в БП, выбираем узел
4. Указываем путь к файлу, либо вставляем в поле "Текст строки", значение из БИ.
5. Выполняем соответствующую команду "Загрузить из файла" или "Загрузить таблицу из строки".
6. Выполняем команду "Удалить неверные записи", в этот момент происходит анализ таблиц регистров баз.
В случае, если для текущей записи из БП (текущей базе) не обнаружено соответствие из БИ, запись удаляется.
7. Проверяем результат выполнения, выполняем команду "Сохранить изменения" - производится перезапись данных регистра.
Далее, возвращаемся к пункту 2 и делаем все операции для БИ (базы источника).
В итоге в обеих базах мы получим полностью соответствующие друг другу регистры "Соответствия объектов информационных баз".
ДОПОЛНЕНИЕ
Появилась потребность не только вычищать РС от ненужных записей, но и научиться быстро сопоставлять объекты разных БД.
Из структуры регистра, понятно что добавив к определенному объекту сведения (ГУИД) объекта из другой базы, можно избежать проблем сопоставлении объектов на лету.
Алгоритм работы с эти блоком очень похож на ранее описанный для очистки записей.
1. В БИ запускаем обработку, переходим на закладку "Сопоставление объектов".
2. Выбираем узел, выбираем тип данных которые хотим сопоставить, нажимаем "Заполнить данными БД" и получаем таблицу со всеми записями.
3. Выгружаем таблицу в файл или строку.
4. В БП открываем обработку, переходим на соответствующую закладку, выбираем узел, тип данных и загружаем таблицу.
5. В процессе загрузки таблицы, обработка проверяет наличие записей в регистре сведений по УИДу приемника.
6. В итоге, получаем таблицу данных из БИ для каждой записи которой, нужно выбрать соответствие из текущей базы. Лишние строки можно удалить.
6. Завершив сопоставление, необходимо добавить записи в регистр сведений, выполнив команду "Сохранить соответствия".
Основной функционал и дополнительный, доступен в обработке под номером 2.
Предназначена для заполнения соответсвия элементов справочников в разных базах 1С при стандартном обмене (синхронизация), например если в двух базах сделали похожий элемент справочника и надо чтобы он при обмене из одной базы выгружался в нужный элемент приемник, или несколько элементов в одной базе соответствуют одному элементу в другой базе.
Есть типовая похожая обработка "Сопоставление объектов информационных баз", которая имеет мало возможностей.
1. На закладке настройки:
- выбрать "Вид справочника" из списка
- выбрать нужный "План обмена"
2. На закладке "Основная"
- В таблице "Источники" нажать "Заполнить"
заполнится список всех элементов справочника текущей базы 1С в таблицу "Источники".
На закладке настройки заполнится "Приемник Вид справочника", оставить или изменить на нужный.
- В Таблице "Приемники" нажать "Заполнить"
заполнится список всех элементов справочника базы 1С приемника в таблицу "Приемники".
Имя базы 1С, имя сервера, логин и пароль берутся из сохранённых в 1С настроек синхронизации, по которым обработка подключится к другой базе 1С и прочитает данные.
- "Найти приемник" - кнопка для поиска соответсвующего приемника в таблице "Приемники", а также раскрашиваются зелёным цветом соответствующие элементы
- "Найти источник" - кнопка для поиска соответсвующего источника в таблице "Источники", а также раскрашиваются зелёным цветом соответствующие элементы
- чтобы установить соответствие - выделите элемент в таблицах "Источники" и "Приемники" и нажмите "Установить соответствие"
- чтобы удалить соответствие - выделите элемент в таблице "Источники" и нажмите "Удалить соответствие"
В таблицах есть невидимые колонки "Источник ГУИД", "Приемник ГУИД" и др., видимость можно включить через "Ещё - Изменить форму"
Сделал чтобы сделать соотвествия справочников ПодразделенияОрганизация в базах БП и ЗУП.
В результате работы изменяется регистр сведений: "СоответствияОбъектовИнформационныхБаз" и при синхронизации данных в другую базу учитываются эти настройки соответствия.
Тестировал в:
1С:Предприятие 8.3 (8.3.15.1565)
Зарплата и управление персоналом, редакция 3.1 (3.1.12.142)
Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.75.58)
Планы:
сделать кнопку для сохранения изменений в базу приёмник.
Язык: Русский
Лицензия: Сохранять имя автора и сайт.
Версия от 16.03.2020
- Добавлены поля: Имя сервера, Имя базы, Логин, пароль для подключения через COM-соединение,
если не заполнено то берутся из сохранённых в 1С настроек синхронизации
Механизм сопоставления данных при обмене через универсальный формат
Механизм сопоставления данных предназначен для решения задачи синхронизации данных между базой источника и базой приемника при обмене
Внутренние идентификаторы объектов
В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.
На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.
В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).
Публичные идентификаторы объектов
Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ).
Рис. 1 Регистр сведений Публичные идентификаторы синхронизируемых объектов
Структура регистра представлена в таблице:
Для сопоставления данных двух программ предназначена в БСП 2.3 обработка “Сопоставление объектов информационных баз” для непосредственного использования при синхронизации данных
Рис 2. Основная форма обработки “Сопоставление объектов информационных баз”
Список открывается по команде Выполнить сопоставление на странице Сопоставление данных Помощника интерактивной синхронизации данных. Также можно дважды щелкнуть мышью по строке, в которой обнаружены проблемы сопоставления данных.
Список состоит из двух колонок, каждая из которых соответствует информационной базе, участвующей в обмене. Данные сгруппированы по объектам программы (документы, списки). В нижней части списка выводится информационная строка: сколько элементов сопоставлено, сколько не сопоставлено.
В поле Выводить можно выбрать, какие данные показывать в списке. По умолчанию выводятся Несопоставленные данные.
Сопоставление объектов
- Нажмите Сопоставить автоматически (рекомендуется), выберите поля для сопоставления с помощью флажков. Некоторые поля выбраны программой по умолчанию. Для того чтобы подтвердить свой выбор, нажмите Выполнить сопоставление. После поиска программа выводит на просмотр сопоставленные ею данные. Для подтверждения нажмите Применить.
- После автоматического сопоставления можно оставшиеся объекты сопоставить вручную или изменить сопоставление объектов. Выделите нужные объекты двух баз, нажмите Отменить соответствие, для того чтобы попытаться сопоставить объекты вручную, нажмите Установить соответствие для того чтобы сопоставить объекты.
- Для подтверждения нажмите Записать и закрыть.
Настройка полей таблицы сопоставления
- Нажмите Колонки, чтобы добавить поля в колонки списка. С помощью флажков можно отметить дополнительные поля, для подтверждения нажмите Применить.
Получение данных из другой программы
- Для того чтобы получить данные из другой программы, нажмите Еще –Загрузить данные из другой программы.
Порядок сопоставления объектов
Варианты идентификации объектов при получении
Порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных. Правила ПКО находятся в общем модуле МенеджерОбменаЧерезУниверсальныйФормат
Рис 3 Разделы общего модуля МенеджерОбменаЧерезУниверсальныйФормат
Отметим, что в общем модуле МенеджерОбменаЧерезУниверсальныйФормат находятся все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки . Программный код этого модуля создается автоматически с помощью приложения “Конвертация данных, редакция 3.0” на основе настроенных правил обмена. Программный код модуля можно создавать вручную, но требует от разработчика большого мастерства.
Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО
Рис 4. Настройки идентификации в модуле менеджера
Существуют 3 варианта ( 3 значения) идентификации объекта
- ПоУникальномуИдентификатору –идентификация по GUID,
- СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска– идентификация по GUID и полям поиска,
- ПоПолямПоиска –идентификация по полям поиска,
Рис 5. Настройки идентификации в КД3.0.
Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.
Алгоритм поиска по полям
Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.
Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска – ПоУникальномуИдентификатору
Переход к следующему варианту осуществляется в двух случаях:
- У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
- Вариант поиска не дал результата.
Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта “По GUID” или “По GUID и полям поиска”, то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.
В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.
Особенности.
При сопоставлении на этапе анализа данных у загружаемых объектов не проверяется заполнение полей, участвующих в поиске.
На этапе анализа данных соответствие будет установлено только в том случае, когда для одного объекта отправителя был найден один объект получателя.
На этапе загрузки данных соответствие будет установлено и в том случае, когда для одного объекта отправителя нашлось несколько объектов получателя. В такой ситуации соответствие будет установлено с одним из них.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.
Читайте также: