В первый день подключение фида поставщика выглядит тривиальным - загрузить файл, пройтись по продуктам в цикле, готово. Проблемы начинаются на тридцатый день, когда цены расходятся, продукт переименован, и никто не может объяснить, почему тур исчез с вашего сайта. Интеграция фида - это в основном про неприметные вещи: сопоставление, планирование, валидацию и сверку. Вот как сделать это так, чтобы оно продолжало работать.
1. Сопоставляйте со своей моделью, а не с моделью поставщика
Самое важное решение - сразу преобразовывать фид в вашу внутреннюю модель продукта, вместо того чтобы позволять полям поставщика растекаться по всей вашей кодовой базе. Постройте тонкий адаптер, который преобразует каждый продукт из фида в вашу каноническую форму:
supplier product -> adapter -> your canonical Product
{ code, title, (mapping) { id, name, durationISO,
duration, net, priceNet, currency,
pickup, rules } pickupPolicy, cancelRules }
Когда поставщик добавляет поле или переименовывает одно из них, вы меняете адаптер - а не пятьдесят мест вызова.
2. Честно определите частоту обновления
Фид - это снимок, а не поток. Согласуйте частоту загрузки с тем, насколько быстро данные на самом деле меняются:
- Описания и структура продукта меняются редко - ежедневной загрузки более чем достаточно.
- Нетто-тарифы меняются чаще - загружайте их чаще или подтверждайте цену в момент бронирования.
- Доступность - это единственное, чему фиду нельзя доверять в реальном времени - проверяйте её живым вызовом, прежде чем подтверждать.
Используйте фид для того, что стабильно (каталог), и живой вызов для того, что изменчиво (доступность и финальная цена).
3. Валидируйте перед публикацией
Никогда не позволяйте фиду писать напрямую в продакшен. Прогоняйте каждую загрузку через валидацию и относитесь к сбоям как к сигналу, а не как к неожиданности:
- Отклоняйте продукты с отсутствующими обязательными полями вместо того, чтобы публиковать половину записи.
- Помечайте подозрительные изменения - цена, которая за ночь сдвинулась на 80%, скорее всего, является ошибкой.
- Выявляйте исчезновения: пропавший продукт мог быть снят с продажи, или фид мог быть обрезан.
- Храните последний корректный снимок, чтобы плохая загрузка никогда не стёрла ваш каталог.
4. Сверяйте то, что вы продали, с тем, что вы забронировали
Поскольку фид - это снимок, всегда существует промежуток, в котором ваши данные и данные поставщика расходятся. Закройте его шагом подтверждения: когда вы оформляете бронирование, источником истины для цены и подтверждения является ответ поставщика, а не ваш закэшированный фид. Сохраняйте этот референс и сверяйтесь с ним.
5. Сделайте интеграцию наблюдаемой
Нельзя исправить то, чего не видишь. Логируйте каждую загрузку: сколько продуктов, сколько изменилось, сколько было отклонено и сколько времени это заняло. Простая панель с "последней успешной синхронизацией" экономит часы отладки, когда что-то выглядит не так.
Разумная целевая архитектура
[supplier feed] --pull--> [validator] --ok--> [adapter] --> [your catalogue]
| |
reject log live availability
check at checkout
Сделанный таким образом фид туров и трансферов становится не требующим больших затрат на обслуживание костяком вашего каталога, в то время как тонкий вызов в реальном времени обрабатывает изменчивую последнюю милю. Именно вокруг этого паттерна построен Mokan Travel Connect: чистый инвентарный фид для синхронизации каталога и живой эндпоинт для доступности и подтверждения, о которых фид никогда не должен гадать.