🏆 Маппинг данных - что это и зачем? 🏆

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

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

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


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

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

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


Если говорить про задачу на интеграцию системы #BookingGA с Unisender для подписки пользователей на рассылку, то 👉 таблица маппинга под часть задачи "чтение сообщения из топика Kаfka и добавление пользователя в лист контактов Unisender" 👉 будет содержать колонки:

- название поля на русском
- название поля в сообщении Kafka (JSON)
- название поля в БД Сервиса Уведомлений BookingGA, т.к. туда будет сохранена информация о подписке пользователя на город
- название параметра в API системы Unisender, куда будем отправлять данные о новом пользователе для листа контактов
- общее описание поля, требования к его обработке и проверкам
- типы данных в сообщении Kafka (JSON), API Unisender и БД. Я бы добавила только отдельную колонку “Тип данных в БД Уведомлений”. Все остальные типы данных не так важны или очевидны.


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

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

💎 Заполненный шаблон реального интеграционного Use Case 💎

Готов итоговый файл Confluence с примером интеграционного Use Case:
👉 Авторассылка email по расписанию через интеграцию с Unisender

Внутри:
✅ микросервисная архитектура
✅ есть брокер Kafka
✅ задача запускается по cron (автоматически, по расписанию).

Всё на уровне системы, без участия пользователей.
Максимально подробный и детальный пример.


👉 Шаги для его создания:

1️⃣ Анализ API-документации внешней системы Unisender.

2️⃣ Тестирование API через Postman (можно другой инструмент),
чтобы понять, как API Unisender реально работает и его "подводные камни".

3️⃣* Обсудили алгоритмы авторизации запросов во внешние системы.
В случае Unisender можно отправить все настройки подключения в конфигурационный файл, а API-ключ туда же или в Key Store (хранилище ключей).

4️⃣ Встроили новую функциональность в архитектуру проекта
и показали это на схеме архитектуры C4/Container:
+ какие сервисы / микросервисы задействованы (если это не монолит)
+ какие БД используются
+ нужны ли брокеры в процессе
+ и другие детали

5️⃣ Знаем, что нужны задачи на доработку БД в МС Уведомлений,
чтобы хранить информацию о:
+ соответствии городов и их list_id в Unisender
+ какие пользователи (email) и на какие города подписаны для рассылки

6️⃣ Описали интеграционный Use Case (вер1),
используя полученный опыт работы с API, понимание архитектуры: зафиксировали, как будут перетекать данные между микросервисами системы.

7️⃣ Дополнили его UML Sequence диаграммой
и узнали, как её строить (в статье оставила ссылку на специальный AI-бот от GetAnalyst по генерации идеального кода PlantUML 😎).

8️⃣ Узнали что такое маппинг данных.
Добавила несколько таблиц маппинга в статью.

9️⃣ Зафиналила список задач на разработку.
В идеале ещё доделать предложенный список вложенных статей, но уже в этом виде разработчики могут начинать работу над задачей и остатки важной документации формировать сами!


Полезный образец для развития насмотренности и получения опыта 💎

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

📌 Подборка полезных материалов по Интеграциям от GetAnalyst 📚


Послушать и посмотреть:

🎧 Postman: навык тестирования REST API за вечер

🎧 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок

🎧 Подкаст "Проблемы в работе с задачами на интеграции"

🎧 Доставить и не потерять: синхронизация данных в распределенных системах - основы очередей сообщений

🎧 Подкаст "Идемпотентность и коммутативность API: что это и как применяют на практике"

🎧 Подкаст "Kafka: что нужно знать Системному аналитику" - глубже в понимание очередей и брокером


Познакомиться с теорией:

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

📝 Отличия между обычными и интеграционными Use Case

📝 Инструменты системного аналитика для тестирования в API

📝 Работа Kafka - что надо знать для работы СА



Практические руководства по Postman:

📚 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

📚 Практическое руководство по Postman - тестирование API ChatGPT

📚 Практическое руководство по Postman - тестирование API Unisender


Шаблоны постановок задач:

💎 Полный интеграционный Use Case - рассылка email через Unisender (с брокерами и микросервисами)

💎 Полный интеграционный Use Case - автоматическое создание задач во внутренней системе ToDoist для сотрудников компании после оплаты заказов

💎 Интеграционный REST API-метод - поиск структурированных адресов



Ещё больше про интеграции:

🎓 Практический курс Интеграции Систем - работа онлайн с Екатериной Ананьевой и экспертами программы

🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)

Всё по интеграциям от GetAnalyst вы всегда можете найти в канале по хэштегу #ИнтеграцииGA 🙌


Прекрасных выходных!

Бывают моменты, когда теряешь ориентиры в карьере.

Не понимаешь, куда расти, в каком направлении двигаться. Вроде всё умеешь — но хочется большего, хочется развиваться и в навыках, и в деньгах. Но как и куда?

⭐️ В такие моменты помогает одна простая, но мощная практика — написать "резюме мечты".

Не текущее.
А такое, где ты — тот, кем хочешь стать.

Почти как в детстве про "я хочу стать космонавтом", но уже с позиции взрослого человека 🙃


Садишься и честно придумываешь себе будущий опыт работы (наконец-то можно!) 😊

✅ Навыки:
+ проектирование архитектуры
+ нотация С4
+ проектирование REST API
+ интеграции
+ микросервисы
+ Kafka
+ RabbitMQ
+ Postman на продвинутом уровне
+ ...

✅ Опыт работы:
+ Убрал хаос в компании по работе с REST API и ввёл корпоративные стандарты проектирования
+ Работал с высоконагруженной системой и проектировал внутренний обмен данными
+ Продумывал сложные цепочки интеграций микросервисов с участием брокеров, gRPC, REST API
+ Проектировал архитектуру для переезда с монолита на микросервисы
+ Управлял командой из 12 аналитиков распределенных по командам продукта
+ Работал в Германии на позиции ведущего системного аналитика более 3-х лет
+ ...

✅ ЗП:
от 100 000 $ /год


Пишем всё, что когда-то и где-то слышали от более опытных коллег. Мечтаем. Ищем вдохновение в статьях на хабре, в цифрах ЗП в вакансиях на LinkedIn. Для вдохновения еще полезно посещать митапы, конференции и обучения))


Это может показаться странным. Как будто ты приписываешь себе несуществующий опыт. Кто-то это ради "лишь бы взяли" делает 😅
Но у вас другая история. Вы к этому опыту планируете прийти.

Магия в том, что такой практикой ты даёшь себе чёткий вектор: куда я хочу расти 📈🔮

Появляется фокус. А вместе с ним — план.
После этой практики ты даже неосознанно начинаешь движение к цели 🙌 (а если опубликовать, так вообще можно случайно "сесть на ракету" и ускориться...😅)


У меня вообще всё, что записано на бумаге, обычно через время сбывается. Такой вот ритуал исполнения желаний 🪄

Попробуйте 😉
Это работает!

🤖 Как эффективно использовать ChatGPT для проектирования БД и SQL-запросов | 17 Апреля, 19:00 Мск 🤖

Использование ChatGPT и аналогичных нейросетей для работы аналитика всё еще может вызывать вопросы. Где-то это помогает, а где-то наоборот - отнимает время 📉

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

Но в то же время, если вы используете нейросеть:
✔️ Умея решать задачи самостоятельно
✔️ Зная алгоритмы работы и последовательности команд
✔️ Используя правильные связки инструментов
то она может стать вашим помощником! 🤝


👉 Если вы умеете проектировать БД на логическом уровне, ищите возможность развиваться в темах БД и SQL, и хотите ускорять свою работу с использованием нейросетей, то приглашаю вас на онлайн-практику:

🤖 Использование ChatGPT для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
👉 Подробности и запись

План:
1. Знакомство с ChatGPT (и не только)
2. Проектирование физической модели БД PostgreSQL
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов
4. Создание реальной БД и SQL-запросы в DBeaver

✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎


По вопросам можно писать через сайт или @getanalyst 💬

💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

Предлагаю чек-лист, который вы всегда можете применить, чтобы оценить свой текущий круг обязанностей и то, что может ожидать вас в будущих проектах 📈


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#RestApiGA

✨ Дизайн REST API с 6 мая - открыта запись в новый поток практической программы ✨

Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:

+ Знание REST API / JSON
+ Опыт проектирования и документирования API
+ Понимание принципов работы мобильных приложений
+ Знание OpenAPI / Swagger для создания REST API документации
+ Навык тестирования API Backend (Postman)

Все эти навыки, в разных формулировках, ожидают от Middle и Senior Системных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.


Мы осваиваем их в рамках одного большого проекта, на практической программе:

💻 Дизайн REST API
🗓 Старт 6 мая 2025
✅ Первая онлайн-встреча: 13 мая

🔗 Узнать подробности и записаться

В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты СА 🛠



В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩

👉 Это самая весомая и “программистская” часть вашего профессионального портфолио.



🎁 По заявкам до 22 апреля дарим дополнительное обучение по БД+SQL в подарок + самые выгодные условия.


Есть вопросы?
Пишите @getanalyst,
на почту info@getanalyst.ru
или заполняйте анкету предзаписи на сайте.
Мы поможем оценить ваши текущие навыки, пришлем дополнительную информацию и ответим на все вопросы 🤝

🤖 Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать 🤖

В новом эпизоде подкаста GetAnalyst вы найдёте обзор основных AI-инструментов для системных аналитиков. Разберётесь, чем они отличаются, какие возможности предлагают, что и для каких задач подходит лучше всего.

Ключевые нейросети в обзоре:
🤖 ChatGPT
🤖 DeepSeek
🤖 Gemini
🤖 YandexGPT

Также расскажем про дополнительные инструменты со встроенными AI-возможностями и про вспомогательное ПО, которое помогает системным аналитикам использовать нейросети с максимальной пользой.


Здесь мы даём готовые инструкции, как системный аналитик может применять нейросети на практике, чтобы оставаться конкурентоспособным в быстро меняющемся мире IT.

🔗 Статья к эпизоду с дополнительными материалами


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

👉 Реальные кейсы, примеры и личный опыт.

Подкаст, который точно стоит послушать сегодня!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Получай самые актуальные знания с GetAnalyst — сообществом, где системные аналитики растут каждый день 📈

🐞 Виды HTTP-методов: не повторяйте эти ошибки 🐞

GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.

Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).


Основные HTTP-методы, которые нужно знать при проектировании REST API 👇


✅ POST: создание нового ресурса
Добавить новый товар в Интернет-магазин
Зарегистрировать пользователя
Создать заказ товаров
👉 Иногда POST может использоваться для получения данных:
+ асинхронные запросы
+ слишком много query-параметров (фильтров) для списков


✅ GET: получение ресурсов
Посмотреть список товаров
Получить информацию о выбранном товаре
Проверить статус заказа


✅ PUT: обновление ресурса целиком или создание нового
для полной замены данных ресурса

Вызываем PUT (изменить/создать) для товара со штрихкодом 0123456789, на вход передаём все-все данные о нём:
👉 если товар с таким штрихкодом уже был создан, то обновить данные по нему в БД целиком, даже если какие-то параметры, как название или стоимость менять сейчас не нужно
👉 если товар с таким штрихкодом еще не создан, то создать новый

Штрихкод здесь будет выступать как ключ идемпотентности - уникальный идентификатор, по которому проверяем, есть запись о ресурсе в системе или нет, чтобы выполнить нужное действие.



✅ PATCH: частичное обновление ресурса
для обновления только некоторых полей ресурса - частичное редактирование.
Изменить описание товара и передать на вход методу только его.
При этом действии в БД поменяется только описание товара, и не будет полной перезаписи всех полей, как это происходит при использовании PUT.


✅ DELETE — удаление ресурса
Удалить выбранный товар из магазина
Удалить выбранный товар из заказа


🐞 Распространенные ошибки при выборе HTTP-методов для REST API на картинке к посту


Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.

#RestApiGA