Как стать автором
Обновить

Как сделать хорошую интеграцию? Часть 2. Идемпотентные операции – основа устойчивой интеграции

Время на прочтение 13 мин
Количество просмотров 13K
Всего голосов 23: ↑23 и ↓0 +23
Комментарии 4

Комментарии 4

Очень важный и хороший цикл. Разбирая проблемы плохих интеграций, как раз пытаюсь сформировать для себя ответ обозначенный в теме. С нетерпением жду продолжения. Большинство утверждений плюсую со страшной силой.
Хочу обратить внимание на другой аспект проблемы — неравнозначность систем, стимулирующих разработчиков более важных, решать свои проблемы за чужой счет. Выталкивая реализацию или заведомо плохие решения в другие — менее важные системы. Что усугубляется желаением руководства быстрее получить результат, оставив тех долги будущим поколениям.
Спасибо за отзыв, рад, что статьи вызывают такую оценку. Вопрос неравнозначности — да, важен. Но тут сталкивается политика, сила ответственных в разных системах, с вопросами компетентности персонала и техническими возможностями в принципе. Потому что если речь идет о легаси-системе, то ее возможности могут быть принципиально ограничены. Иногда — очень сильно, например, нельзя получить журнал изменений, только выгрузить витрину целиком…
Можно обернуть такой сервис таким образом, что бы он соотвествовал требованиям. Для этих задач есть же целый класс систем (не могу вспомнить название) детектирующих изменения и ведущих историю изменений за теми системами, что этого сделать не могут.
Да, примерно так и делаем. В одном из проектов было — выгрузка витрин полных документов с окном в 1.5 года — потому что была практика изменений так далеко в прошлом, и хорошо, что выгрузка с таким окном была допустима по производительности, а потом — сравнение двух ежедневных выгрузок.
И решение технических проблем, которые возникают при выгрузке витрин, а не изменений — решения для перекрестных ссылок и неконсистентности разных витрин, из-за которых, например, может придти продажа несуществующего товара, если продажи выгружают после приходов, и т.д.

Или другая интересная задача. В складскую систему передавалась накладные на отгрузку, и передающая система ожидала ответа: что из этой накладной отгружено, а что — не смогли по каким-то причинам. А складская система была устроена так, что накладная рассыпалась на строки, а строки — на множество заданий, если товар забирали с разных мест хранения, каждое исполнялось независимо, и там были сложные пути, например, чтобы взять 2 штуки из коробки, находящейся в зоне хранения целых коробов сначала исполнялось внутреннее задание по перемещению этого короба в зону хранения вскрытых коробов. Или если кладовщик фиксировал отсутствие единицы товара в конкретном месте, то формировалось задание взять ее из другого места (а эта недостача уходила на разбор). Поэтому для формирования ответа надо было вести внутренний баланс по каждой строке исходной накладной — был ли получен ответ по каждой единицы, и периодически заглядывать в складскую систему на предмет наличия неоконченных заданий…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий