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

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

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



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

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

▫️ название параметра на разговорном языке;
▫️ описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
▫️ названия параметра в 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