Интеграции: вторая сторона стыка вам не подчиняется
Обмен между двумя конкретными системами — работа понятная: она разобрана на странице про Битрикс24 и 1С, вместе с картой полей и вопросом, у какого поля какой хозяин. Эта страница про другое: про стык как предмет, который живёт после запуска и ломается не от ваших действий. Чужой сервис меняет интерфейс, ограничивает частоту обращений, уходит на обслуживание и однажды переименовывает поле — не спросив вас и не предупредив вашего подрядчика.
- Очередь и повторы: падение одной системы не роняет вторую и не теряет данные
- Журнал и уведомление ответственному — поломка не живёт неделю незамеченной
- Схема обмена передаётся документом: следующий подрядчик не начинает с нуля
Интеграция — это не работа, а объект, у которого есть хозяин
Обмен сдают как проект и дальше ведут себя так, будто он закончился. Он не заканчивается: с этого дня у вас в хозяйстве появилась вещь, которая живёт, стареет и ломается без вашего участия.
Всё, что ломает обмен, приходит со стороны, которой вы не управляете. Обновилась учётная система — реквизит переименовали. Сервис доставки выпустил новую версию интерфейса, а старую отключит через квартал. Платёжный шлюз ужесточил проверку и стал отказывать в том, что вчера проходило. Маркетплейс ввёл ограничение на частоту обращений. Ни одно из этих событий не связано с качеством написанного кода, и ни одно нельзя предотвратить — можно только заметить вовремя.
Поэтому главный вопрос обмена — не «как передать», а «как узнать, что перестало передаваться». Данные ходят молча; отсутствие данных выглядит точно так же, как отсутствие данных по естественной причине. Заказов нет — то ли их нет, то ли обмен встал. Именно так поломки живут неделями и обнаруживаются в тот день, когда клиент звонит спросить, почему его заказ никто не видел.
Отсюда три вещи, без которых мы обмен не сдаём. Журнал операций: видно каждую отправку, её содержимое и ответ второй стороны. Уведомление ответственному при превышении порога ошибок — человеку, а не в общий чат, где оно потеряется. И имя этого человека, названное до запуска: не должность, а конкретный сотрудник, который знает, что делать с сообщением «обмен встал».
Про повторы и дубли. Вторая сторона может не ответить, ответить с задержкой или ответить дважды — и обмен обязан вести себя правильно во всех трёх случаях. Повторная отправка не должна создавать второй заказ; отправка, ответ на которую потерялся, не должна считаться неудачной навсегда. Это делается тем, что у каждой операции есть свой признак, по которому вторая сторона узнаёт уже принятое. Звучит мелко, стоит недорого и спасает от целого класса ситуаций, которые потом разбирают руками по одной записи.
Если систем у вас ровно две и это CRM с учётной системой, начните со страницы про обмен Битрикс24 и 1С: там та же логика разобрана на конкретной паре, с картой полей и тестовым контуром. Здесь — про случай, когда систем больше или когда вторая сторона вам не подконтрольна вовсе.
Пять вещей, которые решает не ваш подрядчик
Список того, что придёт со стороны чужого сервиса. Мы перечисляем его до договора: половина неприятных разговоров про обмен начинается с фразы «но вы же делали, почему сломалось».
-
Версия интерфейса меняется, а старую однажды выключают
Крупные сервисы объявляют об этом заранее, мелкие — постфактум. Практический вывод один: обмен нужно кому-то вести, а письма от сервиса должны приходить на адрес, который читают. Мы просим завести такой адрес и оформить доступ на вашу компанию, а не на личную почту сотрудника.
-
Есть ограничение на частоту обращений
Почти у всех, и заметно оно становится не сразу, а когда данных стало больше. Обмен, написанный без учёта ограничения, работает на тестовом объёме и начинает получать отказы на боевом. Лечится очередью и равномерной отправкой, но закладывать это надо сразу — переделка означает переписывание всего обмена.
-
Сервис уходит на обслуживание, когда ему удобно
Обмен обязан пережить это без потери данных и без вашего участия: сложить неотправленное, повторить позже, не создать дублей. Если вторая сторона недоступна долго, система должна сказать об этом человеку, а не молча копить очередь до бесконечности.
-
Формат ответа меняется без предупреждения
Поле переименовали, тип значения стал другим, добавилось обязательное поле. Обмен, который доверяет ответу и не проверяет его, начинает записывать в вашу систему мусор — а это хуже остановки, потому что заметно не сразу. Поэтому ответ проверяется, а неожиданное складывается в журнал и не уезжает дальше.
-
У самописной системы может не быть автора
Самый частый случай на российском рынке: систему писали несколько лет назад, документации нет, разработчик ушёл. Тогда первый этап — чтение того, что есть, и он закладывается в срок честно. Обещать дату обмена с системой, которую никто не читал, — значит назвать её наугад.
Правила чужих сервисов меняются не по нашей воле, и приводить их здесь цитатой мы не станем: к моменту, когда вы это читаете, часть из них уже другая. Что именно действует для ваших систем, сверяется на старте проекта.
Семь вопросов о стыке, на которые отвечают до сметы
Отмечайте то, на что ответ у вас есть. Ничего никуда не отправляется. Половину этих вопросов задаёт любой подрядчик на первом созвоне — разница только в том, что здесь они собраны до разговора.
Вердикт появится после первой отметки. Ничего никуда не уходит: это список вопросов к вашей стороне, а не заявка.
Есть ответ на 0 из 7
Седьмой пункт самый дешёвый и самый недооценённый. Обмен без адресата уведомлений технически работает так же, как обмен с адресатом, — ровно до первой поломки, о которой узнают от клиента.
Спросить про свои системы
Перечислите свои системы — нарисуем схему стыкаНапишите, что у вас стоит и что с чем должно разговаривать. Скажем, у каких систем есть программный доступ, где понадобится очередь, что решать про расхождения и с какой пары начинать. Без счёта и без созвона.
Спросить в Telegram Если это пара CRM и 1СЧто происходит, когда что-то пошло не так
Блок для вашего разработчика или подрядчика. Пять ситуаций, которые случаются у всех, и то, чем отличается обмен, который живёт, от обмена, который однажды тихо встал.
| Ситуация | Как бывает чаще всего | Как делаем мы |
|---|---|---|
| Вторая сторона не ответила | Прямой вызов из обработчика: не ответили — операция упала, данные потеряны, пользователь увидел ошибку | Операция кладётся в очередь и повторяется по нарастающему интервалу. Пользователь своё действие завершил, система досылает сама |
| Ответ потерялся, отправили повторно | На той стороне появился второй заказ. Ищут и удаляют руками, обычно после жалобы клиента | У каждой операции свой признак; повторная отправка с тем же признаком не создаёт вторую запись, а возвращает результат первой |
| Обмен встал совсем | Никто не знает. Выясняется через неделю, когда заметили, что заказы не приходят | Порог ошибок и уведомление названному человеку. Отдельно — сигнал о тишине: данных нет дольше обычного, это тоже событие |
| Пришло не то, чего ждали | Значение записывается как есть; в системе появляется мусор, и замечают его нескоро | Ответ проверяется до записи. Неожиданное складывается в журнал с пометкой и не уезжает дальше по цепочке |
| Надо понять, что случилось месяц назад | Логов нет или они перезаписались. Разбирательство заканчивается версиями | Журнал операций: что отправляли, что получили, когда и чем закончилось. Он передаётся вам вместе со схемой обмена |
Про окружение. Проект собирается в контейнерах, чтобы обмен вёл себя одинаково на машине разработчика, на тестовом контуре и в бою, — расхождение окружений даёт самые изматывающие ошибки в этой работе. Долгие и повторяемые операции живут в очередях, а не в обработчике запроса. Схема базы меняется только миграциями, решения записываются с обоснованием. Всё это описано и на странице веб-сервисов: правила у студии общие, и для обмена они те же.
Как идёт работа
Пять шагов. Последний — тот, из-за которого обмен вообще имеет смысл заказывать у подрядчика, а не собирать связкой готовых сервисов на скорую руку.
-
01
Схема: кто с кем и зачем
Рисуем все системы и связи между ними, отмечаем, у каких есть программный доступ и кто за них отвечает. Часто на этом шаге половина связей отпадает: данные, которые «нужны везде», на деле нужны одному отчёту раз в месяц.
-
02
Правила: свежесть, направление, поведение при расхождении
По каждому потоку: как часто ходит, в какую сторону, что побеждает при конфликте и что делать, если вторая сторона недоступна. Согласуется документом до разработки — спорить о правилах дешевле, чем разбирать перезаписанные данные.
-
03
Сборка на тестовом контуре
На копии или в песочнице сервиса, с отдельной проверкой краевых случаев: вторая сторона молчит, ответила ошибкой, ответила дважды, вернула неожиданный формат, документ отменён после отправки.
-
04
Узкий боевой запуск
Одна группа данных, одно направление, ограниченный объём. Смотрим сутки, потом расширяем. Так расхождение находится на десятке записей, а не на всём справочнике, и исправляется до того, как расползётся по остальным системам.
-
05
Передача хозяину стыка
Схема, журнал, настройка уведомлений и имя того, кому они приходят. Плюс документ о том, что делать при типовых сбоях. С этим разберётся и ваш специалист, и любой следующий подрядчик, — и это ваша страховка от зависимости от нас.
Своего срока у этой страницы нет. 2–3 недели — срок первой сметы направления для одного процесса; связка нескольких систем относится ко второй смете, и срок там другой. Пока не посмотрели, какие у вас системы и есть ли у них программный доступ, честный ответ — вилка, а не дата.
Условия, при которых мы сами предложим остановиться
Четыре строки. Первая — самая важная: обмен не наводит порядок, он разносит существующий по всем системам сразу.
| Когда | Что обнаруживается | Что делаем |
|---|---|---|
| На разборе | В источнике беспорядок: справочник ведётся в трёх местах, дубли контрагентов, у половины позиций нет кодов | Не начинаем. Обмен размножит этот беспорядок по всем системам и закрепит его. Сначала порядок в источнике — это работа вашей стороны, и она дешевле любой интеграции |
| На разборе | Нет человека, который решит, какая система главная по спорному полю | Останавливаемся до появления такого человека. Без него правила согласуются неделями, а объём работ при этом не меняется — платить за ожидание нет смысла |
| На разборе | У нужного сервиса интерфейс закрыт, нестабилен или требует условий, которых у вас нет | Говорим это до договора и предлагаем обходной путь: выгрузка по расписанию, промежуточный файл, ручной ввод на первое время. Либо честно отказываемся |
| В работе | Список связей растёт: к двум системам добавляются третья и четвёртая «пока делаем» | Останавливаемся и режем до одной пары, которую доводим до конца. Четыре наполовину работающих обмена хуже одного работающего: искать причину расхождения придётся сразу во всех |
Про деньги при остановке — общее для студии и написано на странице оплаты и гарантий. Остановка на разборе не стоит ничего: разбор бесплатный.
От чего зависит цена
Своей сметы у формата нет. Одна связка — первая смета направления, от 60 000 ₽; несколько систем, собранных в один поток, — вторая, от 140 000 ₽. Разброс внутри задают четыре вещи, и количество полей среди них не значится.
-
Есть ли у системы программный интерфейс и насколько он живой
Документированный интерфейс готового сервиса — предсказуемая работа. Самописная система без документации означает этап чтения кода до начала разработки. Полное отсутствие интерфейса — файловые выгрузки по расписанию: делается, но данные тогда не свежие, и это решение принимается сознательно, а не всплывает потом.
-
Как часто должны ходить данные
Раз в сутки — самый дешёвый вариант и самый устойчивый. В тот же момент — дороже: нужны очередь, обработка отказов и запас по частоте обращений, который позволит чужой сервис. Обычно выясняется, что мгновенность нужна двум потокам из десяти, а остальным достаточно расписания.
-
В одну сторону или в обе
Односторонний поток — это передача. Двусторонний — это договорённость: по каждому полю нужно решить, какая система главная и что происходит, когда обе изменили значение. Разговор не технический и занимает больше календаря, чем сама разработка. На конкретной паре систем он разобран здесь
-
Сколько стыков в проекте
Считаются не системы, а пары, которые действительно обмениваются. Четыре системы могут дать один стык, а могут пять. И каждый стык — это свои правила, свои сбои и своё место, где однажды что-то разойдётся; поэтому мы почти всегда предлагаем делать их по одному, а не все разом.
Три сметы направления с составом и сроками — на странице автоматизации. Сопровождение обмена после сдачи считается часами: 3 000 ₽ по факту, 2 000 ₽ в абонементе. Процента «на поддержку интеграций в год» мы не называем — такого числа у студии нет.
Эта страница — один из форматов направления
Здесь написано только про стык и его жизнь после запуска. Как считать окупаемость операции, с чем мы связываем системы и что остаётся у вас — на странице направления.
Список того, с чем мы связываем системы, и калькулятор окупаемости операции — на странице направления. Второй калькулятор здесь не ставим намеренно: он один и живёт наверху. Автоматизация процессов
Когда интеграция вам не нужна
Четыре случая. В первых двух обмен обойдётся дороже проблемы, которую решает; в третьем строить рано, в четвёртом задача называется иначе.
-
Если операций в день единицы
Несколько заказов в день человек переносит быстрее, чем вы согласуете правила обмена. Обмен здесь не только не окупится — он добавит вам новую вещь, которая может сломаться. Считать это стоит в часах: сколько операция съедает сейчас и сколько будет стоить её поддерживать. Калькулятор для этого — на странице направления
-
Если нужна разовая выгрузка
Перенести остатки один раз, загрузить каталог при запуске, сдать данные в отчёт. Это выгрузка, а не интеграция: делается быстрее, стоит меньше и не требует ни очереди, ни мониторинга, ни хозяина. Путать эти две работы дорого — и, к сожалению, легко, потому что называют их одинаково.
-
Если одну из систем меняют в ближайшие месяцы
Переезжают на другую CRM, обновляют учётную систему, переходят в облако. Обмен, написанный под уходящую систему, придётся делать заново — и это будет второй счёт за ту же работу. Лучше подождать и сделать один раз; мы говорим это прямо, хотя это означает отложенный заказ.
-
Если нужно связать ровно CRM и учётную систему
Это самая частая пара, и у неё есть свои особенности: штатные механизмы обмена, сопоставление справочников, поведение при обновлении конфигурации. Разобрано это подробно на отдельной странице, и начинать стоит оттуда, а не отсюда.
Куда идти, если задача уже, чем стык
Четыре страницы. Первая — про самую частую пару систем, вторая — если данные нужны не для работы, а для отчёта, третья и четвёртая — если обмен нужен внутри продукта, а не между готовыми системами.
Интеграция систем и работа с API: что стоит знать до заказа
Интеграцию заказывают как разовую работу — «связать сайт с CRM», «завести обмен со складом». Сделанной она бывает действительно один раз, а живёт годами, и всё это время её ломает то, чем вы не управляете: обновления чужих систем, новые версии программных интерфейсов, ограничения на частоту обращений, плановые работы поставщика сервиса. Поэтому у обмена должен быть хозяин — человек, которому приходит сигнал, что данные перестали ходить.
Почему главный вопрос — не «как передать», а «как узнать о поломке»
Передать данные умеет любой разработчик, и на тестовых объёмах это выглядит одинаково хорошо у всех. Разница проявляется в аварийных ситуациях: вторая сторона не ответила, ответила с задержкой, ответила дважды, вернула неожиданный формат. Плохо написанный обмен в этих случаях теряет данные или создаёт дубли, а главное — делает это молча. Отсутствие заказов выглядит точно так же, как отсутствие заказов по естественной причине, поэтому поломки живут неделями.
Устойчивый обмен устроен иначе. Операции кладутся в очередь и повторяются с нарастающим интервалом; у каждой есть признак, по которому вторая сторона узнаёт уже принятое, и повтор не создаёт дубль; ответ проверяется до записи, а неожиданное складывается в журнал. Плюс два сигнала человеку: при превышении порога ошибок и при подозрительной тишине.
Чего нельзя ожидать от интеграции
Обмен не наводит порядок в данных — он разносит существующий по всем системам сразу. Если справочник ведётся в трёх местах, а у контрагентов не заполнены идентификаторы, интеграция начнёт создавать двойников вместо обновления существующих записей. Поэтому работа начинается с проверки источника, и иногда честный ответ — «сначала порядок, потом обмен». Это работа вашей стороны, и она дешевле любой интеграции.
Второе ожидание, которое не оправдывается, — что обмен переживёт обновления автоматически. Не переживёт: новая версия учётной системы переименовывает реквизиты, а чужой сервис выключает старую версию интерфейса по своему расписанию. Это не дефект работы, а свойство стыка, и закладывать сопровождение надо сразу.
Сколько стоит интеграция и от чего зависит срок
Одна связка — первая смета направления автоматизации, от 60 000 ₽, срок 2–3 недели. Несколько систем, собранных в один поток, — вторая смета, от 140 000 ₽. Разброс внутри ступени задают четыре вещи: есть ли у системы живой программный интерфейс, как часто должны ходить данные, односторонний обмен или двусторонний и сколько в проекте стыков — а стыки считаются по парам, которые действительно обмениваются, а не по числу систем.
Самый непредсказуемый случай — самописная система без документации и без автора. Тогда в срок закладывается этап чтения кода, и называется он вилкой, а не датой. Обещать точный срок обмена с системой, которую никто не читал, нельзя.
Что остаётся у вас после работы
Код обмена, схема связей документом, журнал операций и настройка уведомлений. Ключи доступа к сервисам оформляются на вашу компанию, а не на подрядчика. Это не жест доброй воли: описанная схема — ваша страховка от зависимости, потому что следующий подрядчик не начинает с нуля. Сопровождение после сдачи считается часами — 3 000 ₽ по факту, 2 000 ₽ в абонементе.
Вопросы про обмен между системами
Шесть вопросов, которые задают именно про стык. Про договор, этапы оплаты и гарантии — на странице оплаты и гарантий.
Остался вопрос?
Написать в Telegram, отвечаем за 30 минутРаботаем с тем, что есть. Варианты по убыванию удобства: штатный механизм обмена, файловая выгрузка по расписанию, чтение из базы напрямую с согласия владельца системы, промежуточный сервис. Последний вариант — ручной ввод на первое время и обмен вторым этапом: он выглядит неспортивно, но иногда это единственный честный способ запуститься. Что возможно в вашем случае, видно на разборе, и говорим мы это до договора.
Двумя способами, и оба настраиваются до запуска. Первый — порог ошибок: если доля неудачных операций выросла, уведомление уходит названному человеку. Второй — сигнал о тишине: данных нет дольше обычного, и это тоже событие, потому что «ничего не приходит» выглядит одинаково при поломке и при затишье. Адресат уведомлений — конкретный сотрудник, а не общий чат: в чате такие сообщения теряются в первый же день.
Может не случиться ничего, а может измениться поле или формат ответа. Автоматически обмен это не переживает, и обещать обратное было бы неправдой. Что мы делаем со своей стороны: проверяем ответ до записи, чтобы неожиданное не расползалось по системам, и ведём журнал, по которому видно, что именно изменилось. Что нужно с вашей: чтобы письма от поставщиков сервисов приходили на адрес, который читают, и чтобы обновления не выкатывали на боевую систему без предупреждения.
Часто да, и мы сами это предложим. Для простых потоков — форма в CRM, уведомление в чат, запись в таблицу — готовая связка делается за часы и стоит подписку. Границы известны: слабо с повторами и порядком операций, тяжело с большими объёмами, почти нет журнала для разбирательств и всё ломается, когда нужна нестандартная логика. Мы говорим, где проходит эта граница для вашей задачи, и берёмся только за то, что за ней.
Дороже, но не столько из-за кода, сколько из-за согласований. По каждому полю нужно решить, какая система главная и что происходит, когда обе изменили значение. Этот разговор идёт внутри вашей компании и занимает больше календаря, чем разработка. Практический совет: начните с односторонних потоков там, где это возможно, а двусторонними делайте только те поля, которые действительно правят с обеих сторон. Обычно таких меньше, чем кажется вначале.
Вам. Код лежит в вашем репозитории, ключи и учётные записи в сервисах оформлены на вашу компанию, схема обмена и журнал передаются документами. Проверить это легко: попросите показать схему и спросите, на чьё имя зарегистрирован доступ к платёжному сервису или службе доставки. Описанная схема — ваша главная страховка: другой подрядчик по ней разберётся, а не будет читать чужой код с нуля.
Перечислите системы — скажем, что с чем связывать и с какой пары начать
- Разбор 30 минут: какие системы, есть ли у них доступ, что при расхождении
- Нарисуем схему стыка и скажем, где хватит готовой связки без разработки
- Если сначала нужен порядок в источнике, услышите это первым и бесплатно
Заявка принята
Вернёмся в течение рабочего дня. Если срочно — напишите в Telegram.
Или напишите сразу:
Telegram · отвечаем лично за 30 минут