Обновлено: 04.07.2024

Механизм сопоставления данных при обмене через универсальный формат

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

Для решения этой задачи как раз и предназначен механизм сопоставления данных.

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

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

В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).

Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ ). Структура регистра представлена в таблице:

Узел информационной базы ПланОбменаСсылка Ссылка на узел плана обмена (настройку обмена), для которой хранится соответствие. Ссылка

СправочникСсылка,
ПланВидовХарактеристикСсылка,
ДокументСсылка Ссылка на объект текущего приложения. Идентификатор Строка (36) GUID объекта, полученного от приложения-корреспондента.

При получении данных записи в регистре могут появляться на нескольких этапах (см. рисунок 1). Подробное описание самих алгоритмов сопоставления см. далее.

Рисунок 1. Этапы, на которых могут быть сделаны записи в РПИ

Этапы, помеченные пунктиром, опциональные: при выполнении сеанса обмена в автоматическом режиме отсутствуют этапы 1 и 2, при выполнении в интерактивном режиме этап 2 может быть пропущен пользователем.

В процессе обмена данные РПИ обеспечивают следующую функциональность:

1. Сопоставление объектов при получении данных (см. рисунок 2-а).
2. Обработка получаемых данных (замена ссылок) с целью обеспечения ссылочной целостности (см. рисунок 2-b).
3. Обработка отправляемых данных (замена ссылок) для исключения повторного сопоставления на стороне приложения-корреспондента уже сопоставленных данных (см. рисунок 2-b).

Рисунок 2. Использование данных РПИ при получении и при отправке данных.

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

Все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки (подробнее в статье Методика работы с конфигурацией "Конвертация данных 3.0" ) формируют так называемый менеджер обмена . Код менеджера обмена разрабатывается в общем модуле (подробное описание см. в документации по БСП , в разделе Обмен через универсальный формат ). Модуль создается автоматически с помощью КД3.0 на основе настроенных правил обмена либо вручную в конфигураторе (см. пример - общий модуль _ДемоМенеджерОбменаЧерезУниверсальныйФормат демо-конфигурации БСП ).

Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО и может принимать одно из трех значений:

1. ПоУникальномуИдентификатору - идентификация по GUID,
2. СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска - идентификация по GUID и полям поиска,
3. ПоПолямПоиска - идентификация по полям поиска,

Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.

Рисунок 3. Настройки идентификации в модуле менеджера и в КД3.0.

В таблице 1 представлено описание использования данных настроек при автоматическом сопоставлении на разных этапах получения данных:

Этап анализа данных (при загрузке через помощник синхронизации данных)

Ручное сопоставление (при загрузке через помощник синхронизации данных)

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: делается, если соответствие нашлось при выполнении п.3.

Сопоставлять можно со всеми объектами соответствующего типа, для которых нет соответствий в РПИ .

Запись соответствий в РПИ: делается по результатам сопоставления.

Идентификация по РПИ .

Идентификация по GUID среди объектов, отсутствующих в РПИ .

Запись соответствий в РПИ: делается для либо с исходным GUID, либо с вновь сгенерированным, п. 1 не дал результата но объект с таким GUID уже есть в РПИ .

По GUID и полям поиска

Аналогично варианту "По GUID".

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: см. выше.

См. колонку "Загрузка данных"

Запись соответствий в РПИ: не делаются.

Таблица 1. Правила работы настроек идентификации.

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

Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска.

Переход к следующему варианту осуществляется в двух случаях:

1. У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
2. Вариант поиска не дал результата.

Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта "По GUID" или "По GUID и полям поиска", то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.

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

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

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

Особенность.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.

3) Периодически (тут надо подумать) чистим наш вспомогательный РС (блокируя в этот момент таблицу справочника).

Ессно, в файловой версии это работать не будет. Да и в постгри, наверное, тоже.

(19) да, с одним измерением круче, можно прямо в ПриИзменении реквизита на форме проверять.

(21) Хитрый алгоритм, насколько он оптимален с точки зрения производительности? Особенно такие моменты как "ПередЗаписью - пробегаемся по всему справочнику ".

(22) Меня больше интересует программная запись)

Насчет регистра сведений - это вы загнули. А с учетом многопользовательского режима работы - совсем уж лишнее. Пятое колесо в телеге :)
(24) Дело в том, что только использование регистра сведений позволяет на уровне платформы гарантированно контролировать уникальность набора измерений записи.
(24) почему? Зато уникальность сама по себе будет контролироваться. На уровне платформы. И как раз это для многопользовательской версии, для однопользовательской это не нужно.
(28) все-таки вводить регистр сведений для уникальности будет избыточно. Даже если открыто одновременно две формы у разных пользователей. Можно в код ПослеЗаписи поставить запрос по этому реквизиту, если выдаст более одного значения в результат, то вот и получишь поиск неуникального. Если же искать среди не записанных, в том числе и без самого себя, то гарантированного результата не достигнуть, имхо
+ имхо, потому что это все методы самой 1С. Если работать с транзакциями без 1С, то вполне допускаю мысль, что где-то они в решении такой задачи смогут помочь
(23) В любом случае понадобится таблица, хранящая все значения. Хоть тот же справочник, хоть отдельный РС (в том случае, если реквизитов в справочнике ну очень много, чтобы таблица была меньше).
Речь вообще про какие объемы? Сколько элементов в секунду будет вводиться?
(29) ПослеЗаписи, когда транзакция уже зафиксирована и данные внесены в БД, в случае не уникальности реквизита, придется удалять записанные данные, кроме того в этом случае возможна ситуация когда оба одновременно записываемых элемента (в случае 2-х конкурентных потоков) с одинаковыми реквизитами будут удалены
Чем типовое решение, с показом возможных дублей, не годится?
+ кстати, для объекта справочник события ПослеЗаписи нет)
(33) насчет типового решения не могу ничего сказать, т к не видел его
(26) Хм. на "уровне платформы". Это об той самойплатформе речь, где функционал распределенной информационной базы встроен. Риб-база - и все ваши "навороты" для обеспечения уникальности становятся бессмысленными.
(36) В случае распределенной базы данных, да и в общем случае распределенных систем, использующих общие данные, должна быть отдельная база с так называемыми мастер-данными, для контроля уникальности и синхронизации общих элементов со всеми системами использующими эти данные.

(28) Можно подробнее, что хранится в этом реквизите?

Технически, гарантированно обеспечить уникальность реквизита при многопользовательской работе можно только двумя способами:

1) Сериализовать все изменения сущности (будь то справочник, регистр и т.д.). То есть блокировать некий общий ресурс перед записью, проверить уникальность, записать, снять блокировку. Платформа позволяет это сделать несколькими способами.

2) Ввести ограничение уникальности на уровне СУБД (unique constraint или unique index). Тут есть такие варианты:
а) хранить данные, требующие уникальности, в реквизите, для которого платформа сама создает в БД такое ограничение (например код справочника, единственное измерение РС (19));
б) создать дополнительное ограничение самостоятельно через SQL (и самому же его поддерживать, платформа о нем не знает и может его снести)

Добрый день, есть вопрос
Как сделать чтобы реквизит табличной части документа получал данные из реквизита справочника.
Т.е. при изменении "ФИО" в табличной части документа подставлялись значения (ДатаРождения, Должность)из справочника (Сотрудники)

Есть справочник Сотрудники, реквизиты "Должность", "Дата рождения"

Есть документ в нем табличная часть "Налоги" и его реквизиты "ФИО" "Должность" "ДатаРождения"

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

Прошу в поиск не посылать, т.к. пробывал уже много вариантов в т.ч. программно через функции

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

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

Получение реквизита из справочника в табличную часть документа
Доброе время суток!Скорее всего мой вопрос очень глупый , но прошу помочь. имеем справочник.

Получение реквизита из справочника в табличную часть документа
Здравствуйте, полный нуб в 1с. Прошу больно не пинать. Вопрос самый простой и глупый. Есть документ.

Mujinin, пропишите заполнение этих полей при изменении ФИО. Какая форма? Если управляемая, то значения получать придется на клиенте. Иначе - можно все в одной процедуре.
Пример для управляемой:

о мой спаситель. почему мне раньше этого никто не мог подсказать. я начал пол года назад и все время обходил это автозаполнение.

делал все тоже самое только "ФИО" в

Не подскажите, а как сделать все тоже самое, но только у меня это не строки в ТЧ а реквизиты дока.

Anmut, я бы лучше изменял реквизиты объекта на сервере. Думаю так будет правильнее

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

Лучше серверный вызов делать в один раз, получать маленькие данные и заполнить на клиенте. Т.к. объет на форме уже заблокирован вами.

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

В итоге чаще всего используется 2 варианта:

1. Простой способ. Прямо в объекте добавляется таблица, а затем либо программно либо жестко(вручную) выводится на форму.

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

2. Нормальный вариант, но тоже с доработкой конфигурации.
Добавляется объект с таблицей значений и реквизитом с ссылкой на объект родитель, данная таблица значений выводится, к примеру, через расширение конфигурации на форму основного объекта.

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

Есть, конечно, еще другие варианты к примеру с хранилищем, но статья не об этом…

Статья, о том, как все-таки хранить таблицу значений в доп. реквизитах, ну или в доп. сведениях.

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

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

Пример продемонстрирую на конфигурации Документооборот 2.1.6.8. Буду использовать дополнительный реквизит, но можно использовать дополнительные сведения. Весь код будет написан в Расширении конфигурации.

Задача:
Сразу говорю задачка больше шуточная для демонстрации метода. Например, нам понадобилось добавить табличную часть «Адекватность контактных лиц», она должна присутствовать в справочнике Контрагенты и содержать колонки: Контактное лицо, Совет (некая рекомендация по общению с контактным лицом), Тип контакта.

1 Добавляем доп. реквизит и называем его к примеру «ТЗ_АдекватностьКонтактныхЛиц».
Я этот реквизит делаю общим для всех видов контрагентов. Тип его будет строка неограниченной длины.

2 Создаем Расширение конфигурации и Дорабатываем форму Контрагентов.
Добавляем реквизиты формы:

— «ДопТЗ» тип ПланВидовХарактеристикСсылка.ДополнительныеРеквизитыИСведения
— ТЗ_АдекватностьКонтактныхЛиц тип ТаблицаЗначений:
КонтактноеЛицо тип СправочникСсылка.КонтактныеЛица
ТипКонтакта тип Строка
Совет тип Строка

Добавляем на форму страницу «ГруппаАдекватностьКонтактныхЛиц» и снимаем видимость.
В данную группу выводим «ТЗ_АдекватностьКонтактныхЛиц»

3 Пишем код.
ПриСозданииНаСервере. Необходимо считать сам доп реквизит напомню мы его обозвали «ТЗ_АдекватностьКонтактныхЛиц», далее прочитать его значение и построить по его значению таблицу значений.

Значение доп реквизита я предлагаю хранить в формате JSON, у кого более старая платформа можно использовать XML.

ПриОткрытии. Программно прячем доп. реквизит. Он хранит JSON, поэтому пользователю особо неинтересен.

ПередЗаписьюНаСервере. Если ТЗ изменилась сохраняем ее в виде строки JSON в доп. реквизит.

Читайте также:

  
• Как в 1с оформить возврат неиспользованных подотчетных сумм
  
• Автоматическая заглавная буква в ворде
  
• Объединение с помощью внешней программы не настроено 1с
  
• Как посмотреть историю в ми браузере
  
• Схема подключения гранит 16 в автокаде