Услуги · обмен данными между системами
Строим обмен, который переживает падение любой из сторон: событие пишется в одной транзакции с данными, доставка повторяется, дубли не проходят, а каждое сообщение видно в журнале.
Знакомая картина
Четыре ситуации, с которыми к нам приходят чаще всего. Под каждой — одна и та же инженерная причина, а не невезение.
Заказы
Клиент оплатил на сайте, а в 1С заказа нет — и узнаём мы об этом от клиента
Причина почти всегда одна: отправка события живёт отдельно от транзакции, в которой заказ записался. Мы пишем событие в ту же транзакцию, а публикуем отдельным процессом — терять его между коммитом и очередью просто негде.
Остатки
На маркетплейсе висит пять штук, на складе давно ноль
Остаток расходится, когда его считают в двух местах и синхронизируют «когда получится». Мы фиксируем источник истины, отдаём остальным проекции и добавляем регулярную сверку, которая показывает расхождение раньше покупателя.
Расписание
Обмен падает примерно раз в неделю, и никто не понимает почему
Потому что от обмена не остаётся ни журнала, ни метрик — только «файлы не пришли». Мы заводим журнал обмена: сообщение, попытка, ответ приёмника, причина отказа. Разбор падения занимает минуты, а не рабочий день.
После сбоя
Сбой прошёл, а что доехало и что догружать руками — непонятно
Ручная догрузка — самый дорогой способ потерять данные ещё раз. При идемпотентных обработчиках повтор безопасен: можно перезалить весь интервал, дубли не появятся, а журнал покажет, что именно изменилось.
С чем связываем
Коробочного коннектора не существует: каждый поток проектируется под формат, лимиты и режим работы конкретной стороны — включая случаи, когда документации на API нет.
Системы, где живут заказы, клиенты и документы.
Товары, цены, остатки и заказы в обе стороны.
Контур, в котором ошибка обмена стоит дороже всего.
Всё, у чего есть хоть какой-то интерфейс.
Механика
Обмен теряет данные не потому, что «сеть плохая». Ломается он в четырёх предсказуемых местах, и на каждое есть конкретный механизм, который мы ставим по умолчанию.
Событие пишется в таблицу outbox в той же транзакции, что и сам документ. Отдельный процесс читает её и публикует в Kafka или дёргает приёмника. Состояния «заказ есть, а сообщения нет» не существует.
commit → outbox → relay → приёмник
Ключ сообщения вычисляется из данных источника, а не из времени отправки. Приёмник делает upsert по внешнему идентификатору и помнит обработанные ключи. Повторная доставка меняет ноль строк, поэтому повтор после сбоя — штатная операция.
at-least-once доставка + идемпотентный приём
Каждая попытка сохраняется со статусом, телом запроса и ответом стороны. Повторы идут с растущими паузами, исчерпавшие лимит уходят в очередь разбора. Алерт приходит на застрявшую очередь раньше, чем о проблеме сообщит клиент.
попытка · статус · причина · возраст очереди
Читающие системы получают не собственную версию правды, а проекцию источника: read-модель обновляется событиями по схеме CQRS, а раз в сутки идёт сверка сумм и количеств. Расхождение попадает в отчёт, а не в претензию от покупателя.
источник истины → проекция → ночная сверка
Опыт
Три разных класса задач: операционная логистика, интеграция хранилищ данных и обмен финансовыми сообщениями в чужом формате.
Логистика · микросервисы
Восемь масштабируемых микросервисов за централизованным API-шлюзом, версионированные миграции, логирование Vector → Elasticsearch. Процессы перестали зависеть от того, успел ли человек перенести данные руками.
16 ч → 9 минвремя обработки ключевых процессов
Разбор проекта →Данные · ETL
Отказоустойчивая интеграция пяти баз данных и полный цикл внедрения Airflow: от настройки до динамических DAG, которые разворачиваются под новые источники без правки кода пайплайна.
5 баз данныхв одной интеграции
Опыт студии →Финансы · форматы
Интеграционное решение в Murex с преобразованием MxML → FIXML. Чужой формат и жёсткие требования к каждому полю: сообщение либо валидно, либо не уходит.
MxML → FIXMLпреобразование форматов
Опыт студии →С чего начинаем
Прежде чем что-то переписывать, нужно понять, что именно уже ходит между вашими системами. Это отдельная работа с фиксированным сроком и результатом.
Собираем список систем, точек обмена и ответственных с обеих сторон. Отдельно отмечаем то, что переносится руками или файлами на общем диске: обычно теряется именно там.
Формат, транспорт, периодичность, гарантия доставки и поведение при ошибке. Читаем код обмена и настройки, а не описания в вики: расхождение между ними и есть источник сбоев.
Поднимаем логи за период, ищем потерянные и задвоенные сообщения, проверяем, что произойдёт при недоступности приёмника и повторной загрузке одного и того же файла.
Отдаём документ: схема обмена, места потери данных, оценка работ по каждому и порядок, в котором их разумно чинить. Разбираем документ на созвоне с вашей командой.
Диагностика обмена3–5 дней
Фиксированная стоимость — считаем после короткого созвона, когда понятен состав систем. На выходе карта потоков, список мест потери данных и оценка работ. Отчёт остаётся у вас в любом случае — даже если чинить возьмётся другой подрядчик.
Саму интеграцию оцениваем после диагностики. Фиксированного прайса на такие работы нет: цена зависит от количества систем, объёма данных и предсказуемости чужих API.
Информация на сайте не является публичной офертой. Сроки и стоимость фиксируются в договоре после уточнения состава систем и объёма данных. Гарантия — 2 недели на исправление ошибок, связанных с реализацией по техническому заданию.
Результат
Интеграцию должно быть видно и понятно без нас — иначе через год это снова чёрный ящик, который «падает раз в неделю».
Кто кому что отправляет, в каком формате, с какой периодичностью и гарантией доставки. Одна диаграмма, по которой новый разработчик въезжает в обмен за полчаса.
контекстная схема + таблица потоков
Таблица сообщений с фильтрами по системе, типу, статусу и периоду: тело запроса, ответ стороны, число попыток. Доступ у поддержки, а не только у разработчика.
поиск по внешнему id и по интервалу
Возраст очередей, доля ошибок и время последнего успешного обмена по каждому потоку. Ответ на вопрос «обмен живой?» занимает один взгляд, а не переписку с подрядчиком.
метрики и алерты по порогам
Описание форматов, коды ошибок, правила повторов и инструкция на случай, когда поток встал. Код и миграции — в вашем репозитории с первого дня работ.
контракты · инструкция · миграции
Фиксированного прайса на интеграции нет: цена зависит от числа систем, объёма данных и того, что удастся выяснить про чужие API. Поэтому первым шагом идёт диагностика существующего обмена — 3–5 рабочих дней, фиксированная стоимость, считаем после короткого созвона. На выходе карта потоков, список дыр и оценка работ, с которой можно идти дальше — к нам или к другому подрядчику.
Со стороны 1С нужен человек, который отвечает за конфигурацию: мы не переписываем чужие доработки в чужой базе. Мы проектируем контракт обмена, поднимаем сервис-посредник, забираем и отдаём данные через HTTP-сервисы или файловый обмен и отвечаем за доставку. Если специалиста по 1С нет, объём его работ описываем в задании — так его проще нанять точечно.
Тогда обмен строится на опросе по расписанию с курсором по времени изменения и на очереди с ограничением скорости. Лимиты — это не помеха, а параметр: под них настраиваются размер пачки, интервал и приоритет очереди. Важно другое — чтобы повторный запуск не создавал дубли, и это решается идемпотентностью, а не аккуратностью расписания.
Отдельным проектом: профилирование источника, правила сопоставления справочников, тестовые прогоны на копии, сверка контрольных сумм и только потом перенос в согласованное окно. Миграцию держим обратимой — версионированные скрипты и возможность откатиться, — потому что подход «перенесём и разберёмся на ходу» стоит дороже любого подготовительного этапа.
Ничего не теряется. Событие уже записано в базу-источник в одной транзакции с данными, а отправка идёт отдельным процессом с повторами и растущими паузами. Пока приёмник лежит, сообщения копятся; когда поднимается — разбираются по порядку. В журнале обмена видно каждую попытку, а на застрявшую очередь приходит алерт.
Код интеграции ваш: репозиторий заводится на вашей стороне, исключительные права передаются по договору. Гарантия — 2 недели на исправление ошибок, связанных с реализацией по техническому заданию. Схемы потоков и описание контрактов отдаём вместе с кодом, чтобы обмен мог поддерживать любой ваш разработчик.
Контакты
Полезно сразу указать: какие системы участвуют, что передаётся сейчас, где и как часто рвётся. Ответим по существу — с планом диагностики и оценкой. maincode — инженерная студия ИП Диденко М. С.
Куда дальше
Интеграция помогает, когда системы уже есть и они по существу верные. Если строить нужно саму учётную систему, начинать с обмена бессмысленно: сначала должен появиться источник истины.
Развилка
Нужна не связка систем, а сама учётная система: документооборот, склад, финансы и закупки в одном контуре.
Смежное
Данные из систем нужно не только перевозить, но и складывать в хранилище и считать отчёты, которые успевают к утру.
Смежное
Сервис-посредник, очереди и API — та же инженерия, что и в интеграциях, только под ваш собственный продукт.