Планы обмена. Квитировать или гарантировать?

22.12.16

Интеграция - Обмен между базами 1C

Планы обмена предлагают использовать две стратегии удаления обработанных изменений: квитирование и гарантированная доставка сообщений. Как сделать правильный выбор?

Для лучшего понимания того, о чём пойдёт речь в этой статье, необходимо ознакомиться с моей предыдущей публикацией "Планы обмена. Управляемый режим блокировок".

Рассмотрим работу плана обмена на небольшом примере. Зарегистрируем изменение. Таблицы плана обмена и регистрации изменений будут выглядеть следующим образом:

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел NULL
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 NULL

Теперь выполним выгрузку этого изменения. Вид этих таблиц изменится следующим образом:

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел 1
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 1

Номер сообщения изменился. Это означает, что наше изменение было успешно отправлено в сообщении номер 1. Теперь зарегистрируем изменение другого объекта того же типа.

Таблица плана обмена Таблица регистрации изменений
Узел Номер отправленного
Мой узел 1
Узел Ссылка Номер сообщения
Мой узел Моя ссылка 1 1
Мой узел Моя ссылка 2 NULL

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

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

Квитирование.

Эта стратегия заключается в том, что мы, прежде чем удалять отправленные изменения, ждём от узла-получателя квитанцию о получении нашего сообщения. Как только мы получаем эту квитанцию, мы удаляем изменения с подтверждённым номером сообщения. Повторной отправки этих изменений больше не происходит. Несмотря на простую логику и надёжную работу такого механизма, у него есть один большой недостаток. Он требует фактически синхронного ответа о получении сообщения от узла получателя. К сожалению это не всегда возможно. Таким образом, чем интенсивнее обмен данными, тем выше вероятность повторных выгрузок одних и тех же данных. Посчитать количество повторно отправленных объектов в разрезе узлов плана обмена можно следующим запросом:

Запрос = Новый Запрос();
Запрос.Текст = "
|ВЫБРАТЬ
|	Т1.Ссылка КАК Узел,
|	СУММА(Т1.НомерОтправленного - Т2.НомерСообщения) КАК Количество
|ИЗ
|	ПланОбмена.Тестовый КАК Т1
|	ЛЕВОЕ СОЕДИНЕНИЕ
|		Справочник.Номенклатура.Изменения КАК Т2
|	ПО Т1.Ссылка = Т2.Узел
|	 И Т1.НомерОтправленного <= Т2.НомерСообщения
|	 И НЕ Т2.НомерСообщения ЕСТЬ NULL
|СГРУППИРОВАТЬ ПО
|	Т1.Ссылка
|";

Гарантированная доставка сообщений.

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

Однако у этой стратегии есть один нюанс: как понять, что изменение успешно попало в канал гарантированной доставки? Оказывается, что для этого планы обмена реализуют своеобразный проткол двухфазной фиксации транзакции. По сути своей это распределённая транзакция. Давайте посмотрим как это работает:

1-ая фаза помечает новые изменения для выгрузки при помощи метода ПланыОбмена.ВыбратьИзменения(), который записывает очередной номер сообщения для новых изменений. Блок № 4 на диаграмме ниже.

НомерСообщения > НомерОтправленного (мы находимся в открытой транзакции)

2-ая фаза фиксирует успешное завершение выгрузки при помощи метода ЗаписьСообщенияОбмена.ЗакончитьЗапись(), который записывает номер отправленного сообщения для узла плана обмена. Блок № 7 на диаграмме ниже.

НомерСообщения = НомерОтправленного (транзакция завершилась успешно)

Схематично весь этот процесс я постарался сделать наглядным при помощи следующей диаграммы:

На этой диаграмме состояние одного изменения показано при помощи блоков 2, 5 и 8. Блоки 3 - 7 являются одним сеансом обмена данными. Независимо от того какую стратегию удаления обработанных изменений мы используем, диаграмма будет одной и той же. Разница заключается только в методике удаления изменений.

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

Обратите внимание, что, в случае использования стратегии гарантированной доставки сообщений, в контексте очередного сеанса обмена данными, нас интересуют только новые изменения (блок 2) и изменения, которые возникли в результате сбоев прошлых сеансов обмена (блок 5). Это является существенным отличием от стратегии квитирования.

Заключение.

На основании анализа работы планов обмена я позволю себе дать следующие рекомендации по их использованию в высоко нагруженных системах:

1. Используйте стратегию гарантированной доставки сообщений, а не квитирование.

2. Для того, чтобы доставка была действительно гарантированной, не изобретайте велосипедов - используйте проверенные MQ-решения, например, MSMQ, ActiveMQ или RabbitMQ.

Основные конфликты (см. диаграмму выше) возникают между блоками 1 и 4 за изменение состояния блока 2. Отсюда следующая рекомендация:

3. Постарайтесь сделать транзакции блока 4 как можно короче. Помечайте на выгрузку не все изменения сразу. Разделите их на какие-то адекватные вашей ситуации порции. В качестве одной из идей реализации этой задачи можно посмотреть мою публикацию "Многопоточная выгрузка одного сообщения обмена".

В особо тяжёлых случаях вместо "ВыбратьИзменения" вполне можно использовать две отдельные команды.

Первая - код SQL вида (псевдокод, как идея)

UPDATE TOP 1000 SET _MessageNo = _SentNo + 1 WHERE _MessageNo IS NULL,

а вторая - выборка изменений кодом 1С с отбором вида

ГДЕ НомерСообщения > НомерОтправленного ИЛИ НомерСообщения ЕСТЬ NULL.

Почему код SQL? Дело в том, что "ВыбратьИзменения" помимо обновления номера сообщения возвращает выборку, которая может быть сразу и не нужна ... Ну и потом одна хорошая команда SQL никогда не помешает =)

Вторым по значимости конфликтом (см. диаграмму выше) является конфликт между блоками 1 и 9 за изменение состояния блоков 8. Здесь рекомендация такая же, как и в пункте 3. Короткие транзакции - хорошие транзакции.

планы обмена обмен данными интеграция

См. также

SALE! 20%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 36520 руб.

04.08.2015    159680    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134933    722    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

34650 27720 руб.

15.04.2019    68417    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 34760 руб.

03.12.2020    34169    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 25200 руб.

23.07.2020    46290    196    64    

158

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

Обмен между базами 1C Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

50722 45650 руб.

31.10.2014    231404    124    327    

296

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9207    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    20247    132    38    

90
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. herfis 498 12.12.16 11:07 Сейчас в теме
ИМХО, гораздо интереснее была бы статья, описывающая "живой" опыт построения РИБ с гарантированной доставкой на сервисах очередей и описанием проблем, с которыми пришлось столкнуться.
А так, 90% статьи - невнятное описание стандартных механизмов и потрясающее заключение: лучше быть богатым и здоровым, оказывается.
Merkalov; MarinaLed; zakiap; user712426; Anthon; Irwin; ineshyk; +7 Ответить
2. charushkin 104 13.12.16 10:53 Сейчас в теме
Обычно вместо использования сторонних сервисов (RabbitMQ, MSMQ и т.д.) изобретаю свой велосипед решаю задачу средствами самой же 1С: делаю очередь сообщений, например, в виде регистра сведений: туда пишу сообщение обмена и сразу удаляю регистрацию изменений.
user712426; WellMaster; +2 Ответить
7. zhichkin 1438 22.12.16 13:02 Сейчас в теме
(2) Приведу пример из своей практики.
Для одного очень тяжёлого обмена, тестовый пакет XML которого "весил" 100 Мб, мы делали так :
1. Своя регистрация изменений в регистре сведений в хронологическом порядке (по сути очередь).
2. Свой компактный формат XML, имеющий только те данные, которые изменились (гранулярность регистрации изменений - поле таблицы, реквизит объекта).
3. Использование для доставки SQL Server Service Broker (транспорт).
4. Загрузка пакетов XML в 1С средствами C# с генерацией T-SQL кода (для работы с XML на уровне SQL Server писались свои CLR хранимые процедуры).
Целевым временем загрузки XML пакета "весом" 1 Гб считалось 10 минут. Это без учёта выгрузки и транспорта. Мы укладывались в это время. Даже с запасом.
В результате была полностью решена проблема блокировок при регистрации и выгрузке изменений. Загрузка в общем-то тоже не доставляла каких-то особенных проблем. Удаление регистрации изменений никому не мешало, так как удалялись уже обработанные сообщения из очереди (регистра сведений) по дате последней выгрузки. Все традиционные проблемы РИБ были полностью решены.
Проблемы, с которыми столкнулись: сложность программирования всего этого. Три человека в течение одного-полутора месяцев всё это делали: программист 1С, программист C# и программист SQL. В процессе эксплуатации проблем не было вообще. Мы даже иногда забывали, что обмен работает =) Вспоминали только когда сеть "ложилась" и какие-то данные не долетали до нужных баз - пользователи напоминали. Админы "шевелили" сеть и всё снова работало.
В обмене участвовало 4 базы: оперативная (торговля), web-портал B2B, база для отчётов и диспетчерская база для маршрутизации пакетов при помощи Service Broker. Как-то так.
dsdred; eeeio; user712426; ipoloskov; +4 Ответить
3. bulpi 215 15.12.16 15:08 Сейчас в теме
"ГДЕ НомерСообщения > НомерОтправленного И НомерСообщения ЕСТЬ NULL"

В результате такого условия выберется ровно НИЧЕГО.

Эта статья в целом написана неряшливо и непонятно.
5. zhichkin 1438 22.12.16 12:19 Сейчас в теме
(3) Спасибо. Логическую ошибку в условии отбора исправил.
4. WellMaster 104 22.12.16 11:17 Сейчас в теме
Вопрос к знатокам, берем модификацию имеющегося примера:

"Номер сообщения изменился. Это означает, что наше изменение было успешно отправлено в сообщении номер 1. Теперь зарегистрируем изменение другого объекта того же типа.
Если теперь снова попытаться выполнить выгрузку, то в выборку изменений попадут оба изменения. Это означает, что изменение, отправленное ранее в сообщении номер 1, будет отправлено ещё раз."

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

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

Поправьте меня, если я не прав.
6. zhichkin 1438 22.12.16 12:26 Сейчас в теме
(4) Если Вы измените тот же самый объект после его выгрузки в пакет, то получите новую регистрацию того же самого объекта со значением реквизита "НомерСообщения" равным NULL. Когда квитанция "прилетит" она будет искать кого бы снять с регистрации по номеру, а он будет равен NULL, то есть квитанция никого не найдёт и новые изменения попадут в следующий пакет обмена.
Подробнее здесь: http://infostart.ru/public/561460/
8. WellMaster 104 22.12.16 15:11 Сейчас в теме
(6)
Да, статью по ссылке я читал, причем еще тогда, когда она впервые вышла. Довольно познавательно.
Но нужен был именно ответ на такой вопрос, за что спасибо.
В той статье этот момент не очевиден (или я плохо читал?), хотя читал ее неоднократно.
10. M.Nikitin 2 16.12.20 20:41 Сейчас в теме
(6)
Когда квитанция "прилетит" она будет искать кого бы снять с регистрации по номеру, а он будет равен NULL, то есть квитанция никого не найдёт и новые изменения попадут в следующий пакет обмена.


А если используем снятие с регистрации не по номеру сообщения, а по ссылке - в таком случае объект будет снят с регистрации и новое состояние объекта другая база так и не увидит.
zhichkin; +1 Ответить
11. alexander-lubich 26 14.07.22 15:27 Сейчас в теме
(6) Дмитрий , интересно Ваше мнение по вопросу "Когда заканчивается Enterprise Data и начинается RabbitMQ ?"

http://forum.infostart.ru/forum15/topic284494/message2848287/#message284828

парни из 1с мне ответили
- Пропускная способность ED ими не тестирована .
- достоинство шины - сама определяет получателя и доставку сообщение ему те задача источника только выплюнуть сообщение в шину и тут резко снижается риск блокировок таблиц изменений. потому что узел обмена у центральной базы будет только один - шина.

да книжка классная , сейчас читаю.
Прикрепленные файлы:
PROGRAMMING_Shablony_integratsii_korporativnykh_prilozhenii_774.pdf
9. kuzyara 1900 12.02.18 10:25 Сейчас в теме
За одну только картинку схемы +.
Оставьте свое сообщение