🧩 Маппинг в интеграциях - что это и зачем 🧩

Маппинг - это процесс сопоставления полей (данных) из одной системы с соответствующими полями в другой системе.
Это нужно, так как разные системы могут описывать один и тот же объект данных по-разному.

➡️ Этот процесс всегда необходим в задачах на интеграции.



Маппинг описывают в виде таблицы.
Допустимо делать и в виде структурированного списка, но по опыту - таблицы удобнее.

➡️ В таблице с маппингом делают несколько основных колонок:

▫️ название параметра на разговорном языке;
▫️ описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
▫️ названия параметра в API каждой системы (например, поле из JSON, поле из xml или другого формата сообщения, query из URL и др);
▫️ название параметра в БД системы, если она есть в описании Use Case.
▫️ типы данных в каждой системе / БД.

Допустима вариативность с колонками.
Их может быть больше, а может быть и меньше.


Для задачи #CityGA в примере постановки задачи есть два маппинга:

👉 1. БД CityGA - API KudaGo
При запросе данных из KudaGo необходимо брать часть параметров из БД и подставлять в #KudaGoAPI.

Чтобы наглядно показать это разработчикам, сделали соответствующую таблицу в требованиях.

👉 2. БД CityGA - API KudaGo - Kafka (json)
🖼 На картинке к посту показала наглядно
После получения ответа от #KudaGoAPI, формируется сообщение для Kafka, на основе которого сервис уведомлений затем будет делать рассылку.

Видно, что данные в JSON-ответе от #KudaGoAPI расходятся с JSON-сообщением для Kafka. Часть данных в сообщении Kafka из БД CityGA.

Чтобы показать разработчикам на основе каких данных формируется JSON для Kafka, мы сделали соответствующую таблицу маппинга.



Маппинг помогает разработчикам понять, какие данные нужно получать из внешней системы, с которой интеграция, что важно сохранить в БД или получить из неё, а что нужно подставлять по умолчанию из "прибить в коде".

Это обязательная часть требований в задачах на интеграции 🙌

#ИнтеграцииGA

🔮 Доступ к обучению открыт на 4 дня: Интеграции по REST, GraphQL и WebSocket 🔮

Сегодня всем зарегистрированным отправили письмо с доступом на почту 📩

Если узнали о занятии только сейчас, то подключайтесь:

🔮 Интеграции по REST, GraphQL и WebSocket: от Postman до требований в Confluence
🗓 Доступ 27–30 сентября [сб-вт]
🔗 Подробности и регистрация


В результате:
✅ Освоите порядок работы с интеграциями и научитесь быстро разбираться в любом API
✅ Попрактикуетесь в Postman: отправите запросы, проанализируете ответы и составите сценарии тестирования
✅ Познакомитесь с особенностями GraphQL и WebSocket
✅ Поймёте, какие диаграммы нужны при проектировании интеграций
✅ Получите шаблон постановки задачи в Confluence и разберёте типичные ошибки


Не упускайте шанс прокачать свои навыки и сделать шаг в карьере уже сейчас.

Продуктивных выходных! 🚀

⏰ Кроны, шедулеры и таймеры: что это и когда применять | Отложенные задачи ⏰

При работе с отложенными задачами в системе, которые выполняются по определённому расписанию, используются 3 ключевых термина, которые вы могли слышать от разработчиков или других коллег.



📌 Крон (cron)
Это механизм для запуска задач по расписанию в операционных системах.

Примеры:
+ Каждый понедельник очищать временные данные из БД
+ Каждую среду в 03:00 Мск собирать информацию о предстоящих мероприятиях из внешней системы и формировать рассылку для пользователей
+ В банках: формирование ежедневных отчётов по транзакциям в 10:00 и рассылка ответственным
+ В системах аналитики: пересчёт метрик каждые 5 минут.

Технически cron-выражение описывает календарное расписание (минуты, часы, дни, месяцы, дни недели). Некоторые движки cron позволяют указывать секунды, но не во всех реализациях.

Cron как служба ОС запускает внешние скрипты/программы, а не внутренние методы приложения в отличие от встроенных шедулеров.



📌 Шедулер (scheduler)
Это любой механизм, который умеет запускать задачи по расписанию. Более общий термин в отличие от крона.

Шедулер может быть встроенным в приложение или инфраструктурным.

▫️ Cron — это конкретная реализация шедулера на уровне ОС.
▫️ В приложениях шедулеры встроены как часть фреймворков и позволяют описывать расписания внутри системы.

Примеры:

+ в корпоративных системах: Quartz Scheduler (Java) или Hangfire (.NET) запускают задачи внутри приложений

+ в микросервисах: инфраструктурный шедулер Kubernetes CronJob — запускает контейнеры по расписанию

Ограничения шедулеров:
при горизонтальном масштабировании, т.е. при запуске множества копий приложения - они могут запускаться параллельно и дублировать выполнение задач, если не сделаны механизмы лидерства.



📌 Таймер (относительный запуск - delay, timer)
Иногда нужно выполнить задачу не по календарю, а через определённое время после события. Это и есть delay (отложенный запуск) или таймер.

Примеры:
+ Через 15 минут после регистрации отправить напоминание, если пользователь не подтвердил email
+ Повторить запрос через 30 секунд, если система недоступна
+ Отправить уведомление через час после бронирования

Как реализуется:

▫️ Через оперативную память приложения - проще, но ненадёжно, т.к. задача пропадёт при перезапуске.

▫️ Через очередь сообщений - RabbitMQ с плагином для отложенных сообщений, Redis-очереди или др

▫️ Через базу данных - таблица заданий с колонкой execute_at, воркер регулярно проверяет и выполняет



➕ Очереди (queue)
Для задач с большими объёмами «одноразовых» запусков лучше использовать очереди.

Когда выбирать очереди:
▫️ очень много динамических одноразовых задач «через N» (email-напоминания, повторные попытки запросов),
▫️ нужны горизонтальное масштабирование и устойчивость к сбоям,
▫️ гарантии обработки задач важнее точности расписания.

Пример:
Пользователь регистрируется на сайт. Нужно через 30 минут, если он не подтвердил email, отправить ему напоминание.

➡️ При этом регистрируются тысячи пользователей в час.

Решение через очередь с delay:

1. При регистрации создаётся сообщение с инструкцией «отправить напоминание» и параметром задержки delay = 30 минут.

2. Сообщение кладётся в очередь (например, RabbitMQ с плагином Delayed Message Exchange или TTL + DLX).
Важно: RabbitMQ не идеален для очень долгих задержек (дни, недели) — его основная область — секунды/минуты/часы.

3. Через 30 минут брокер отпустит сообщение в потребительскую очередь - т.е. в оперативную обработку.



👉 Правила выбора:

✅ Регулярные задачи по календарю (например, ежедневно в 10:00)
= cron / scheduler

✅ Отложенные одноразовые задачи (выполнить один раз через N времени от текущего момента)
= таймер / delay

✅ Массовые задачи - с большим объемом однотипных действий
= очереди

✅ Подходы могут комбинироваться


Работа с отложенными задачами встречается часто, и термины в разговоре с программистами теперь будут до конца понятны 🤝

#ИнтеграцииGA #АрхитектураGA