0. zhichkin 409 11.12.16 21:17 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. herfis 276 12.12.16 11:07 Сейчас в теме
ИМХО, гораздо интереснее была бы статья, описывающая "живой" опыт построения РИБ с гарантированной доставкой на сервисах очередей и описанием проблем, с которыми пришлось столкнуться.
А так, 90% статьи - невнятное описание стандартных механизмов и потрясающее заключение: лучше быть богатым и здоровым, оказывается.
Irwin; ineshyk; +2 Ответить
2. hulio 51 13.12.16 10:53 Сейчас в теме
Обычно вместо использования сторонних сервисов (RabbitMQ, MSMQ и т.д.) изобретаю свой велосипед решаю задачу средствами самой же 1С: делаю очередь сообщений, например, в виде регистра сведений: туда пишу сообщение обмена и сразу удаляю регистрацию изменений.
WellMaster; +1 Ответить
7. zhichkin 409 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. Как-то так.
ipoloskov; +1 Ответить
3. bulpi 143 15.12.16 15:08 Сейчас в теме
"ГДЕ НомерСообщения > НомерОтправленного И НомерСообщения ЕСТЬ NULL"

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

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

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

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

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

Поправьте меня, если я не прав.
6. zhichkin 409 22.12.16 12:26 Сейчас в теме
(4) Если Вы измените тот же самый объект после его выгрузки в пакет, то получите новую регистрацию того же самого объекта со значением реквизита "НомерСообщения" равным NULL. Когда квитанция "прилетит" она будет искать кого бы снять с регистрации по номеру, а он будет равен NULL, то есть квитанция никого не найдёт и новые изменения попадут в следующий пакет обмена.
Подробнее здесь: http://infostart.ru/public/561460/
8. WellMaster 98 22.12.16 15:11 Сейчас в теме
(6)
Да, статью по ссылке я читал, причем еще тогда, когда она впервые вышла. Довольно познавательно.
Но нужен был именно ответ на такой вопрос, за что спасибо.
В той статье этот момент не очевиден (или я плохо читал?), хотя читал ее неоднократно.
9. kuzyara 678 12.02.18 10:25 Сейчас в теме
За одну только картинку схемы +.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии


Специалист техподдержки 1С
Иркутск
зарплата от 28 000 руб. до 34 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 48 000 руб. до 96 000 руб.
По совместительству

Программист 1С
Ставрополь
зарплата от 40 000 руб. до 60 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб. до 150 000 руб.
Полный день