Интеграция начинается с процесса
До выбора протокола нужно понять, какое бизнес-событие передаётся и кто отвечает за результат. Заказ, остаток и карточка контрагента имеют разные правила изменения. Схема должна показывать источник истины, получателя, момент передачи и допустимую задержку. Иначе системы начинают по очереди исправлять данные друг друга.
Явный контракт
Формат сообщения, обязательные поля, версия и правила ошибок составляют контракт интеграции. Его фиксируют рядом с кодом и примерами, не включая реальные персональные данные или ключи. Изменение контракта согласуют с обеими сторонами. Совместимость версий особенно важна, когда обновление 1С и сайта происходит в разное время.
Повторяемость операций
Сеть и приложения дают временные ошибки, поэтому сообщение может быть отправлено повторно. Принимающая сторона должна распознавать повтор по устойчивому идентификатору и не создавать второй документ. Повторная попытка имеет предел и паузу. Бесконечный цикл скрывает проблему и увеличивает нагрузку, а молчаливый отказ приводит к расхождению данных.
Наблюдаемость
Для каждой операции нужен технический статус без раскрытия лишнего содержимого: идентификатор, направление, время, версия и категория ошибки. Оператор должен отличить задержку от окончательного отказа и безопасно повторить обработку. Метрика количества очередей и ошибок полезнее журнала, который читают только после жалобы пользователя.
Безопасность границы
Интеграционной учётной записи дают только необходимые методы и объекты. Секреты не размещают в коде, URL или журналах. Входные данные проверяют по размеру, формату и допустимым значениям. Транспортное шифрование защищает канал, но не заменяет авторизацию и контроль действий внутри приложений.
Тестовый контур
Изменения проверяют на обезличенных примерах в отдельном контуре. Внешние уведомления, платежи и реальные адресаты там отключают. Набор включает нормальный обмен, повтор, частичные данные, недоступность стороны и смену версии. Важно проверить не только отправку, но и итоговое состояние во всех участвующих системах.
Ввод и возврат
Запуск начинают с ограниченного потока и наблюдают сверку. План возврата отвечает, как остановить обмен, что делать с очередью и как восстановить согласованность. Простое выключение нового компонента не отменяет уже переданные изменения. Поэтому точка переключения и обработка промежуточного состояния описываются заранее.
Управляемая эволюция
Интеграция живёт дольше первого релиза. Ей нужны владелец, документация зависимостей и порядок изменения контракта. Регулярная сверка выявляет накопленные расхождения, а архив решений объясняет, почему действует конкретное правило. Простая наблюдаемая схема обычно надёжнее универсальной платформы, введённой без реальной необходимости.