|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Зачастую одна система готова принять информацию не в том виде, в котором другая систем готова её отправить. Например, ей нужно больше информации, больше полей. Вопрос, где правильно расположить "оркестратор"? Т.е. программулину, которая будет заниматься обогащением и преобразованием данных, передаваемых через брокер сообщений? Как реализовывается подобный шаблон в реальности? Можно размазать логику по всем системам, типа, если системе "C" нужны какие-то поля, то пусть сама и запросит - но правильно ли это? лишняя нагрузка на брокер сообщений, плюс сложность управления из-за того, что логика обработки конкретной заявки размазана по всем системам. И ради одной заявки постоянно придётся напрягать всех владельцев систем, чтобы они там что-то у себя доработали. Как такое решается в реале? Кто с этим работает? Модератор: Вложение удалено. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2020, 16:31 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Блин. прозрачность по-дурацки воспринимается и уже хрен заменишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2020, 16:33 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Charles Weyland, Нужно что бы входящий запрос обрабатывался параллельно или последовательно(с условиями перехода)? По хорошому нужно для каждой системы создавать сервис по обраработке запросов с шаблоном Reply-to. Если нужна параллельная обработка - посмотрите в сторону шаблона fan-in/fan-out ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2020, 17:40 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
w31, последовательно. Система А обладает малой частью информации, которую готова передать системе C. Но система С для обработки заявки и выдачи ответа нуждается в гораздо большем количестве полей. И то, что выдаёт А - недостаточно. Вот и получается, что есть какой-то бизнес-процесс, в ходе выполнения которого заявка
1. "размазать" бизнес процесс по всем системам - т.е. каждая система, которая получает данные, сразу дозапрашивает дополнительные в соответствии с логикой обработки заявки 2. Какая-то система-оркестратор, в которой описаны все эти правила в едином месте. Она знает, какие поля как соединить и куда передать, как сконвертировать, сама всё дозапрашивает необходимое и т.д. Какой шаблон более правильный? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2020, 03:51 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Charles Weyland Какой шаблон более правильный? такой, где есть общая модель предметной области и разные представления модели ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2020, 13:29 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Все должно работать в одной системе (с) Тогда и сабжевых проблем не будет. Зоопарк трудноинтегрируемых систем - злейшее зло. Как минимум должна быть главная система с возможностями ее доработок. В ней должны рождаться все ключи справочников. Вспомогательные системы же системы не должны существенно влиять на бизнес-процессы. По возможности конеш... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2020, 09:04 |
|
Оркестровка данных через брокер сообщений
|
|||
---|---|---|---|
#18+
Такой "оркестратор" называется ESB (Enterprise Service Bus) . ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2020, 12:54 |
|
|
start [/forum/topic.php?fid=33&msg=39968741&tid=1547100]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 161ms |
0 / 0 |