Добро пожаловать обратно, друзья. Если вы читали первую часть, то знаете, как мы выстраивали периметр, прикрывали тылы и готовились к штурму. Теперь переходим к самому интересному – к продукту. К тому самому «цифровому космолету», который должен был перевернуть рынок пассажирских перевозок.

Но как это часто бывает в больших проектах, эпичный концепт столкнулся с не менее эпичной реальностью. Легаси-инфраструктура с которой мы столкнулись и на которой нам предстояло строить этот самый «космолет», в реале оказалась сложнее и неповоротливей, чем мы могли себе представить. Распределённая архитектура, множество стыковочных узлов, кривые сторонние сервисы, языковые и культурные барьеры внутри команд, а главное – жёсткие рамки Waterfall. Всё это требовало не просто инженерной смекалки, а умения балансировать между интересами разных игроков, не теряя фокуса на конечном пользователе.

В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.

Если вы не читали первую часть – рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации - добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.

Приготовьтесь, отправляемся. Следующая станция – «прод».

ВЕБИНАР| 23 сентября в 11:00| РЕГИСТРАЦИЯ

Часто компании начинают с одного направления, например, с нормализации данных или внедрения MDM, но впоследствии вынуждены возвращаться к уже выполненным этапам. Причина в отсутствии комплексного плана развития НСИ и понимания оптимальной последовательности работ.

На вебинаре 23 сентября в 11:00 эксперт SOFROS Яна Журавлёва покажет, как определить оптимальную последовательность внедрения решений в зависимости от текущего состояния данных, ИТ‑ландшафта и задач бизнеса.

На вебинаре разберем:
1. как понять, когда достаточно нормализации данных, а когда уже необходимо внедрение MDM;
2. в каких случаях начинают с интеграционной платформы DATAREON Platform;
3. почему параллельный запуск всех трех компонентов — самый рискованный, но при наличии плана и экспертизы — самый быстрый сценарий;

Вебинар будет полезен: руководителям и специалистам по НСИ, бизнес‑аналитикам и архитекторам данных, руководителям цифровой трансформации, ИТ‑специалистам, участвующим в проектах управления данными

Регистрируйтесь и забронируйте место заранее по ссылке
Количество мест ограничено.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Когда меня спрашивают, как выбрать интеграционную платформу, я обычно советую не ограничиваться сравнением функций и демонстрацией вендора. Гораздо полезнее проверить платформу на конкретной задаче из собственного ИТ-ландшафта.

Недавно для одного из заказчиков мы провели такой пилот: вместо существующей цепочки COM-обменов проверили централизованную схему через DATAREON Platform. Всего три интеграционных потока позволили проверить не только саму платформу, но и ключевую архитектурную гипотезу — может ли одна из систем стать единым источником данных, а зависимость от промежуточной системы быть устранена.

На этом примере разберу, что именно имеет смысл проверять во время пилота ESB и почему пилот не должен превращаться в формальную передачу нескольких сообщений из точки А в точку Б.

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу продуктовым направлением «Интеграционная платформа» в «Диасофт». Той самой Digital Q.Integration, которую вы имеете полное право не покупать.

Под каждой моей статьей появляется один и тот же комментарий. Слова разные, смысл один: зачем вообще нужна интеграционная платформа, если есть Kafka, брокер сообщений? Один сервис положил сообщение, второй забрал. В чем, собственно, проблема?

Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.

Дальше будет про то, где проходит граница между брокером и платформой, почему ее так трудно нащупать, почему настоящая причина «самописа» вообще не техническая и что во всей этой истории изменил ИИ. По последнему пункту спойлер: ничего хорошего.

Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».

За год я делал файловую логику в шести проектах: перелив сделок между порталами, загрузка фотоописей с мобильного, парсинг PDF из карточек, сборка архивов, синхронизация аватаров. Везде подход получился разный.

Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:

два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;

тихий провал: HTTP 200, в ответе result, поле не обновилось;

useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;

downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;

у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.

В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.

Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу направлением интеграции и развитием платформы Digital Q.Integration в «Диасофт».

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg

Есть ошибки, которые невозможно предотвратить внимательностью.

Клиент присылает фотографию заявления на возврат. На ней от руки написан расчётный счёт — двадцать цифр. Сотрудник переносит их в платёжное поручение. В какой-то момент один человек из ста ошибётся: перепутает местами две цифры, примет тройку за восьмёрку, съедет строкой. Платёж уйдёт, банк его развернёт, деньги вернутся, клиент прождёт ещё неделю и напишет злое сообщение.

Виноватых нет. Все старались. Просто задача «безошибочно переписать двадцать цифр с фото» не решается старанием — она решается тем, что её не должно существовать.

Меня зовут Михаил Аймаутов, я отвечаю за ИТ и автоматизацию в Wollmer — компании, которая занимается бытовой техникой. Расскажу, как мы перестроили самый ручной процесс в компании, и почему бо́льшая часть работы оказалась не про код.