Обмен данными между программами
Интеграция информационных систем и разработка API
Интеграция нужна, когда каждая программа решает свою задачу, но сведения между ними приходится переносить вручную. GradientPrime разрабатывает обмен данными и API под согласованные правила работы: какие записи передавать, кто отвечает за их актуальность и как проверить результат.
Начинаем с существующих систем и доступных способов подключения. Определяем, достаточно ли готового коннектора, где нужен отдельный компонент и что должно происходить при задержке, ошибке или повторной передаче.
Какие системы и данные требуется связать
Для обсуждения интеграции нужен конкретный путь данных: где запись появляется, кому она нужна и какое действие должен выполнить получатель. Список названий программ сам по себе ещё не определяет объём работ.
Условный пример: поставщик принимает заказ в CRM, ведёт исполнение в учётной системе и показывает клиенту статус в личном кабинете. Для обмена нужно связать номер заказа, состав позиций и подтверждённое состояние. Внутренние комментарии менеджера могут оставаться только в CRM.
По каждой системе выясняем её назначение, версию, доступные интерфейсы и ответственного за подключение. Затем перечисляем данные и направления: новый заказ передаётся в учёт, сведения об исполнении возвращаются в CRM и кабинет. Отдельно отмечаем перенос старых записей, если он нужен.
Для обследования: какое действие сотрудника или клиента должно стать возможным после передачи данных? Ответ помогает исключить поля и подключения, которые не нужны выбранному сценарию.
Определить границы систем
Если вместе с обменом нужны новые рабочие места или самостоятельные действия клиента, их следует описать отдельно. Интерфейс кабинета и внутренняя система имеют свои роли, права доступа и критерии приёмки.
Когда достаточно готового коннектора
Перед разработкой проверяем штатные средства обмена и доступные коннекторы. Готовое подключение подходит, если оно поддерживает нужные версии систем, состав данных, направления передачи и условия эксплуатации.
Проверить готовое подключение
Коннектор стоит проверить на обезличенном примере из реального процесса: создание записи, изменение состава, отмена и повтор отправки. Важно понять, как он сопоставляет справочники, показывает ошибки и позволяет сверить результат.
В условном примере стандартной передачи заказа может быть достаточно, если все нужные поля поддерживаются. Вопрос для проверки: что произойдёт с заказом, если получатель не знает один из кодов товара?
Определить недостающую часть
Отдельный компонент можно обсуждать, когда готовый обмен не поддерживает существенное правило: например, разбиение одного заказа на несколько заданий или согласованное преобразование статусов. Сначала проверяем возможность настройки или расширения существующего подключения.
При сравнении вариантов учитываем ограничения поставщиков, сопровождение, изменения версий и доступ к журналу обмена. Наличие коннектора не подтверждает, что он подходит конкретному процессу.
Правила передачи и синхронизации данных
До реализации согласуем правила обмена с владельцами данных. Они должны объяснять, где разрешено менять запись, как получатель узнаёт её и что делать при противоречии между системами.
Источник для каждого вида данных
Основной источник определяют по ответственности за сведения, а не назначают одну программу главной для всего. Например, CRM может подтверждать контакт клиента, а учётная система — состояние исполнения заказа.
Если одно поле меняют в двух местах, нужен порядок разрешения конфликта. Какое изменение имеет приоритет и кто разбирает спорную запись?
Сопоставление записей и полей
Определяем устойчивые идентификаторы и соответствия справочников. Для каждого поля согласуем смысл, формат, обязательность и допустимые значения. Совпадение названия ещё не означает совпадение смысла.
В условном примере статус «готов» может означать готовность к сборке либо к выдаче. Правило преобразования должен подтвердить участник процесса.
Частота и порядок обновлений
Выбираем передачу по событию, расписанию или запросу с учётом доступных интерфейсов и допустимой задержки. Описываем порядок связанных изменений: например, как получатель узнает клиента до загрузки его заказа.
Для обследования: какие сведения допустимо обновлять периодически, а без каких нельзя продолжать работу?
Автоматизация отчётностиИсправления, отмены и доступ
Согласуем передачу исправлений и отмен, доступ к полям и видимость истории. Получатель должен различать отсутствие нового значения и явное удаление сведений.
Например, отмена заказа после начала исполнения может требовать решения сотрудника. Такое событие нельзя превращать в бесконтрольное удаление всех связанных записей.
Разработка API и интеграционных компонентов
Состав разработки определяется разрывом между доступными интерфейсами и нужным сценарием. Это может быть API для приложения, преобразование форматов или отдельный компонент передачи и контроля данных.
Описать договорённости об обмене
Для API определяем операции, поля запроса и ответа, правила доступа, ограничения и понятные сообщения об ошибках. Фиксируем, какой ответ означает приём сообщения, а какой — завершение нужного действия.
В примере с заказом подтверждение получения ещё не означает, что все позиции приняты в исполнение. Кабинету может понадобиться отдельное подтверждённое состояние.
Связать существующие интерфейсы
Интеграционный компонент может сопоставлять идентификаторы, преобразовывать согласованные поля и передавать данные в нужной последовательности. Выбор размещения и способа подключения зависит от ограничений систем.
До реализации полезно проверить один обмен в тестовой среде. Вопрос для обследования: доступны ли документация, разрешённый способ подключения и представитель владельца каждой системы?
Если подходящего API нет, рассматриваем предусмотренные системой выгрузки, загрузки или расширения. Допустимость и надёжность выбранного способа нужно проверить до обещания автоматического обмена. Для будущих обновлений согласуем описание интерфейса и порядок проверки совместимости.
Обработка сбоев, повторов и расхождений
Корректный обмен должен иметь проверяемое поведение при отклонениях. В требования включаем временную недоступность, неполные данные, повторную доставку и изменения, пришедшие в неожиданном порядке.
Сбой и повторная передача
Определяем, какие ошибки допускают повтор, как ограничиваются попытки и когда нужна помощь сотрудника. Если ответ потерялся после создания заказа, повтор не должен создавать незаметную копию.
Для этого обсуждаем идентификатор операции и проверку уже принятого результата. Возможность такого поведения зависит от интерфейса получателя и проверяется отдельно.
Ошибка данных и конфликт
Неизвестный товар, отсутствующее обязательное поле или спорное изменение требуют понятной причины и ответственного за исправление. Повтор той же записи без исправления не устраняет такую ошибку.
В условном примере заказ с неподтверждённым кодом товара остаётся доступен для разбора. Согласуем, можно ли передать остальные позиции или нужен целый подтверждённый заказ.
Сверка и наблюдение
Для контроля полезны состояние передачи, время последнего успешного обмена и связь сообщения с записью получателя. В журнал включают сведения, нужные для разбора, с учётом ограничений доступа.
Периодическая сверка может находить пропущенные записи и различия состава. Заранее определяем, кто получает уведомление, что проверяет и как подтверждает устранение расхождения.
Обследование, проверка обмена и сопровождение
Предлагаем начать с одного законченного сценария и согласовать этапы под ограничения проекта. До рабочего запуска должны быть понятны критерии успешной передачи, порядок перехода и ответственность за дальнейшую работу.
1
Собрать карту обмена
Перечисляем системы, записи, направления, допустимые задержки и владельцев данных. В условном примере начинаем с одного типа заказа и его подтверждённого статуса; историческую загрузку оцениваем отдельно.
2
Проверить доступные интерфейсы
Изучаем документацию и обезличенные примеры, согласуем тестовую среду и права. Уточняем ограничения, которые влияют на выбор коннектора, разработку и предварительную оценку.
3
Пройти обычные и ошибочные сценарии
Сверяем поля и связи в обеих системах. Проверяем создание, изменение, отмену, повтор, недоступность получателя и восстановление. Приёмка опирается на результат процесса, а не только на ответ API.
4
Согласовать рабочий переход
Определяем включение обмена, начальную сверку, условия остановки и обработку накопленных сообщений. Заранее обсуждаем ответственных, порядок обновления интерфейсов и условия сопровождения.
Для предварительного обсуждения подготовьте перечень систем и версий, доступную документацию интерфейсов, обезличенный пример записи и описание нужного результата. На объём работ влияют качество исходных данных, двусторонние изменения, ограничения API и требования к обработке ошибок. Неизвестные параметры сначала выносим на обследование.
Частые вопросы
Вопросы перед организацией обмена данными
Обсудим, какие системы нужно связать
Расскажите, откуда приходят данные, куда их нужно передавать и какое действие сейчас выполняется вручную. Перечень систем и обезличенный пример записи помогут определить вопросы для обследования и границы интеграции.
Обсудить задачу