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