📄 Статьи

Интеграции: как я связываю то, что не хочет дружить

Или: почему «передай файлик» — это не интеграция, а способ потерять деньги.

1. Интеграция — это не «сделать, чтобы работало»

Большинство бизнесов думают, что интеграция — это «ну там программист что-то настроит, и всё заработает».

Нет. Интеграция — это соглашение между системами. Это договор о том, какие данные, в каком формате, куда и когда передаются.

Без этого договора системы будут «дружить» криво. Данные будут теряться. Заказы будут дублироваться. Менеджеры будут перепроверять всё руками.

2. С чего я начинаю интеграцию

Я не лезу в код. Сначала я понимаю, что куда идёт.

2.1. Я спрашиваю

Какие системы у вас есть (1С, CRM, склад, платежи)?
Какие данные из них нужны на сайте?
Какие данные с сайта должны попадать в них?
Кто этими данными управляет?

Но есть и другой сценарий. Бывает, что данные живут в Excel-файлах, которые кто-то вручную заполняет и загружает на сайт или в 1С. Это тоже интеграция. Только ручная. И она требует отдельного разбора:

Что загружают?
В каком формате?
Откуда берут эти данные?
Кто их проверяет перед загрузкой?

Это не «нормально». Это «так сложилось». Но я могу это описать и автоматизировать.

2.2. Я рисую схему

Я рисую карту движения данных. Где живут данные, куда они идут, в каком формате, с какой периодичностью.

Без схемы интеграция — это «сделаем как-нибудь». Со схемой — это проект.

3. Что я проектирую в интеграции

3.1. Форматы данных

Я описываю, в каком виде данные передаются:

JSON, XML, CSV?
Какие поля обязательны?
Какие поля опциональны?
Как обрабатывать ошибки?

Если данные загружаются вручную (например, из Excel)
Формат файла должен быть фиксированным. Но на практике колонки в Excel часто меняются. Или данные
        заполняют по-разному. Поэтому на странице загрузки файла я проектирую предпросмотр:
    
— Пользователь загружает файл.
— Система показывает его содержимое в виде таблицы.
— Пользователь вручную сопоставляет колонки с полями в системе: «вот это — артикул, вот это —
        цена, вот это — остаток».
    
— Только после подтверждения данные загружаются.

Это не «удобство». Это единственный способ гарантировать, что данные загружены правильно.

3.2. Методы обмена

Я описываю, как системы общаются:

REST API?
SOAP?
Файловый обмен?
Очереди сообщений?

Каждый метод — под свою задачу. Я выбираю тот, который подходит именно вам.

3.3. Безопасность

Я описываю, как защищены данные:

Какая авторизация?
Какое шифрование?
Как логируются запросы?

Безопасность — это не «дополнительная опция». Это база.

Но бывает и сложнее.

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

Звучит сложно. Но для некоторых бизнесов это единственный способ защитить данные.

3.4. Обработка ошибок

Я описываю, что происходит, если интеграция упала:

Что видит пользователь?
Что видит менеджер?
Что пишется в лог?

Интеграция без обработки ошибок — это «работает, пока работает».

4. Самые частые интеграции в моей практике

4.1. 1С + сайт (личный кабинет, остатки, заказы)

Это классика. Сайт показывает остатки, принимает заказы, отдаёт их в 1С. 1С возвращает статусы.

Сложность: 1С — это не «гибкая» система. Она живёт по своим правилам. Нужно согласовать форматы и методы обмена.

Отдельная боль 1С: не все поля и не всегда заполнены. Это не проблема 1С. Это проблема сотрудников, которые заполняют данные. Кто-то вводит артикул, кто-то нет. Кто-то заполняет цену, кто-то оставляет пустой.

С этим нужно работать программно: