Интерактивный обмен - ускорение РИБ по магазину

0. Галина idex.rt (idex.rt) 17.03.17 08:55 Сейчас в теме
Интерактивный обмен - это расширение функциональности РИБ по магазину, обеспечивающее онлайн обмен между магазинами и офисом для сети розничных магазинов, автоматизированных на Розница 2.2. Кроме этого, Интерактивный обмен может быть легко адаптирован для обмена данными между узлами любых информационных баз имеющих одну конфигурацию.

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

Комментарии
1. Дмитрий Жичкин (zhichkin) 193 21.03.17 01:31 Сейчас в теме
Сейчас 2017 год.
В 2003 году, 14 лет назад, вышла в свет замечательная книга "Enterprise Integration Patterns": https://en.wikipedia.org/wiki/Enterprise_Integration_Patterns.
Сайт автора этой книги: http://www.enterpriseintegrationpatterns.com/.

В своей книге Грегор Хоп описывает 4 стиля интеграции:
- файловый обмен (эта штука всем знакома);
- общая база данных (РИБ);
- удалённый вызов процедур (web-сервисы в том числе);
- обмен сообщениями (всевозможные MQ).
Так вот ... в последнее время я всё чаще встречаю различные варианты интеграции при помощи web-сервисов. Очень часто эта технология предлагается для обмена данными. Однако она никогда не предназначалась для этого!

Есть два концептуальных уровня интеграции: на уровне данных и на уровне функциональности. Web-сервисы относятся ко второй группе.

Данный продукт, представленный в этой публикации, является очередной попыткой преодолеть проблемы РИБ. Это хорошо, но ...
1. Вероятно, лучше всего было бы обратить внимание на то, что данный продукт решает проблему блокировок при регистрации изменений. Интересно как ... тема слабо раскрыта. Думаю, что она основана на идеях транзакционной репликации.
2. Интересен механизм разрешения коллизий между несколькими базами данных. Тема тоже очень плохо раскрыта. Думаю тем, кому это по настоящему интересно, имеет смысл изучить то, на чём построена платформа синхронизации Microsoft Sync Framework (публикация от 2009 года): https://msdn.microsoft.com/en-us/library/mt763482.aspx. Особенно то, что касается терминов "версия" и "знание".
3. Web-сервисы в данном случае играют роль только транспорта ... и это не самое удачное решение. Особенно при высоко нагруженных системах (я за MQ решения).
2. Галина idex.rt (idex.rt) 21.03.17 09:16 Сейчас в теме
(1)
Спасибо за развернутый комментарий.
По вашим замечаниям:
1. Вы правильно думаете, суть именно в репликации транзакций, но раскрывать подробности смысла не вижу: большинству интересно, что эта штука донесет чек от магазина до офиса за несколько секунд, а не то как она там логирует, транспортирует и накатывает транзакции
2. Я не знаком с Sync Framework, но при беглом прочтении - идея не в том. Идея в том, что каждой транзакции присваивается версия отражающая не количество произведенных изменений над объектом, а время (UTC) изменения. Далее думаю понятно.
3. Вы правы, такой подход позволяет много где сэкономить, но в тоже время он более громоздкий. Суть этой разработки в том, что она не "ломает хребет" РИБ обмену, а естественным образом дополняет его.
3. Дмитрий Жичкин (zhichkin) 193 21.03.17 12:17 Сейчас в теме
(2) UTC время это и есть по сути версия (или фиксация количества произведённых изменений, как Вы это называете). Однако опора на отметку времени делает допущение, что время будет всегда синхронизировано между всеми узлами обмена. Таким образом существует зависимость от служб времени. Sync Framework не зависит от этого. Для этого кроме понятия "версия" вводится понятие "знание". Вкратце суть этого понятия такова: при приёме сообщения приёмник сравнивает версию источника, о которой он уже "знает" с момента последней синхронизации, с той, которая только что получена. Это очень похоже на номера сообщений планов обмена 1С, но дополнительно позволяет синхронизировать "знания" между произвольным количеством узлов обмена.

Да, "хребет" РИБ Вы не ломаете. По сути, как я это вижу, Вы реализуете механизм приоритизации отправки сообщений. Почти все MQ системы имеют этот функционал из коробки.

Что более громоздко установка web-сервера или MQ служб, это вопрос навыков и умения. Примерно одинаково по сложности. Если говорить о MSMQ, то это вообще вопрос нескольких минут настройки операционной системы.
Программирование работы с web-сервисом или очередью сообщений по трудоёмкости примерно одинаковы.
Плюсов в эксплуатации у MQ перед WS в плане гибкости, надёжности и прочее я думаю гораздо больше. Я бы предпочёл WS, а не MQ только в одном случае - необходимость использования функционала (алгоритмов) другого приложения, чтобы их не дублировать.

В любом случае, Вы решаете конкретную проблему, помогаете людям, и это замечательно!
Желаю Вам удачи в развитии Вашего продукта.