#мирвокруг #гарантированнаядоставка #системныйаналитик #системныйанализ #аналитик #шса
Гарантированная доставка.
Что ж теперь я официально могу сказать, что являюсь преподавателем "Школы системного анализа и проектирования" и веду курс по основам проектирования интеграций информационных систем. Так что ввожу новый хештег #интеграция и буду писать интересные вопросы по этой популярной теме. И надеюсь, многим будет интересна эта тема, так как интеграция это не только маппинг данных, хотя менеджмент часто видит интеграцию, как что-то простое, решаемое одной таблицей маппинга.
Хочется рассказать про гарантированную доставку данных.
Что же это такое? Из названия понятно, что это некий механизм, который должен включаться и стопудово доставить данные потребителю. Данные не должны потеряться и точно должны быть доставлены. Ну например, как повестка в суд. Только под вашу подпись, лично в руки.
Как его можно организовать? Самое простое это повторные вызовы системы приёмника до тех пор, пока она не ответит, что приняла данные и их зафиксировала.
С помощью очередей в Брокере, также можно посредством ещё одной очереди, создать гарантированную доставку, куда можно кидать сообщения, по которым не получили отбивку принято и отправлять повторно.
Зачем же это всё нужно? И для каких данных?
Приведу супер пример.
Мои знакомые однокурсники из авиационного института работают в авиационной отрасли. Да, есть ещё такие люди. И вот, как-то их отправили в Австралию тестировать приложение. Это приложение обеспечивает диспетчеров информацией по самолёту. То есть один диспетчер передаёт другому самолет. Диспетчер ведёт этот самолёт по определённой зоне. Например, над Москвой есть зоны аэропорта и есть круг, по которому крутятся самолёты. И вот, чтобы из одной зоны и коридора, перевести самолёт в другую зону и коридор, нужно передать данные от одного диспетчера другому. При такой передачи идёт искажение данных и конечно возможно не все данные будут переданы сразу.
Такая НЕ передача данных увеличивает вероятность аварии, например самолёты окажутся в одном коридоре. И диспетчер не поймёт все нюансы местонахождения самолёта и неправильно будет принимать решение.
Мурашки побежали по коже... Не очень хочется попадать в такую ситуацию. Данные являются критичными, и при такой интеграции механизм гарантированной доставки практически, жизненно необходим.
Что тут важно помнить аналитику. Что стоит проанализировать бизнес критичность данных при передачи от одной системы в другую, и обсудить с архитектором или главным разработчиком для каких данных и в каком варианте стоит сделать механизм гарантированной доставки. Даже если разработчик будет махать рукой в ответ и говорить "Вася отвали, Я уже всё продумал". И ты в ответ "Петя прости, у меня работа такая задавать неудобные вопросы".
По опыту могу сказать, что у нас механизм гарантированной доставки включался при отправке данных по проведённому платежу. Клиент расстроится если за его штраф гибдд не получит информацию об оплате.
Гарантированная доставка.
Что ж теперь я официально могу сказать, что являюсь преподавателем "Школы системного анализа и проектирования" и веду курс по основам проектирования интеграций информационных систем. Так что ввожу новый хештег #интеграция и буду писать интересные вопросы по этой популярной теме. И надеюсь, многим будет интересна эта тема, так как интеграция это не только маппинг данных, хотя менеджмент часто видит интеграцию, как что-то простое, решаемое одной таблицей маппинга.
Хочется рассказать про гарантированную доставку данных.
Что же это такое? Из названия понятно, что это некий механизм, который должен включаться и стопудово доставить данные потребителю. Данные не должны потеряться и точно должны быть доставлены. Ну например, как повестка в суд. Только под вашу подпись, лично в руки.
Как его можно организовать? Самое простое это повторные вызовы системы приёмника до тех пор, пока она не ответит, что приняла данные и их зафиксировала.
С помощью очередей в Брокере, также можно посредством ещё одной очереди, создать гарантированную доставку, куда можно кидать сообщения, по которым не получили отбивку принято и отправлять повторно.
Зачем же это всё нужно? И для каких данных?
Приведу супер пример.
Мои знакомые однокурсники из авиационного института работают в авиационной отрасли. Да, есть ещё такие люди. И вот, как-то их отправили в Австралию тестировать приложение. Это приложение обеспечивает диспетчеров информацией по самолёту. То есть один диспетчер передаёт другому самолет. Диспетчер ведёт этот самолёт по определённой зоне. Например, над Москвой есть зоны аэропорта и есть круг, по которому крутятся самолёты. И вот, чтобы из одной зоны и коридора, перевести самолёт в другую зону и коридор, нужно передать данные от одного диспетчера другому. При такой передачи идёт искажение данных и конечно возможно не все данные будут переданы сразу.
Такая НЕ передача данных увеличивает вероятность аварии, например самолёты окажутся в одном коридоре. И диспетчер не поймёт все нюансы местонахождения самолёта и неправильно будет принимать решение.
Мурашки побежали по коже... Не очень хочется попадать в такую ситуацию. Данные являются критичными, и при такой интеграции механизм гарантированной доставки практически, жизненно необходим.
Что тут важно помнить аналитику. Что стоит проанализировать бизнес критичность данных при передачи от одной системы в другую, и обсудить с архитектором или главным разработчиком для каких данных и в каком варианте стоит сделать механизм гарантированной доставки. Даже если разработчик будет махать рукой в ответ и говорить "Вася отвали, Я уже всё продумал". И ты в ответ "Петя прости, у меня работа такая задавать неудобные вопросы".
По опыту могу сказать, что у нас механизм гарантированной доставки включался при отправке данных по проведённому платежу. Клиент расстроится если за его штраф гибдд не получит информацию об оплате.