⚪🔮 [Только 27-30 сентября] Интеграции по REST, GraphQL и WebSocket ⚪🔮

Хотите быть на шаг впереди своих коллег и разбираться в нестандартных API?
Планируйте время на обучение в эти выходные!

👉 Бесплатный практикум:

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

План:
1. Интеграции: порядок работы над задачами
2. Знакомство с задачей и анализ API-документации
3. Практика в Postman: REST API, GraphQL, WebSocket
4. Разработка интеграционного Use Case
5. UML-диаграммы и архитектурные схемы
6. Формирование постановки задачи в Confluence


------------------------
Подготовка:
+ Должен быть аккаунт в Postman.
+ Лучше скачать Desktop версию
+ Если работаете через браузерную версию, то перед началом практики установите и запустите фоновую программу Postman Agent (синий Postman)
+ Если ни разу не работали с Postman, попробуйте выполнить шаги по созданию Workspace и коллекции по этой инструкции для API ВТБ
------------------------


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

🔖 Чек-лист требований к обработке ошибок в Интеграциях 📚

Написание требований к обработке ошибок является важной частью обязанностей Системного Аналитика. Я всегда начинаю описание работы системы с прямого сценария, а затем сразу же перехожу к поиску подвохов и отклонений на каждом его шаге.

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

Также не хочется получать разочарования на этапе тестирования, когда довольный тестировщик нашел очередной баг, что ведет к “уточнениям по аналитике”, очередным кругам доработок, задержкам релизов и отвлечению от новых задач.

😄👉 Я абсолютно уверена, что работа аналитика - победить тестировщика,
то есть первым найти все потенциальные ошибки и сбои, которые может создать пользователь. Поэтому круто, когда в Системный Анализ переходят Тестировщики.

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

1. Аутентификация
2. Доступ
3. Тайм-аут
4. Ошибки по документации внешней системы
5. Неизвестные ошибки, которых не было в документации и не планировалось их обрабатывать (новые коды, неизвестные форматы тела ответа)
6. Новые статусы или значения справочников, которые не совпадают с нашими перекодировочными таблицами, описанными в маппинге данных

Подробности в мини-книге к посту 📚

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

🎆 С днём системного аналитика! 🎆

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

Но на деле их деятельность гораздо шире и охватывает не только техническую, но и организационную часть IT.

Итог их труда - это качественное техническое задание и аналитические отчеты, адаптированные под требования и интересы заказчика. 📑


✨ 24 сентября мы отмечаем День системного аналитика! Праздник празднуют не только аналитики, но и системные администраторы, специалисты IT, технические директора и многие другие!

🔍 Немного истории: 20 сентября 2000 года в пригороде Чикаго на пикнике Т. Кекатос предложил отмечать этот день в знак благодарности системным аналитикам за их вклад. Россия поддержала эту традицию, признав день профессиональным праздником!

🧠 Системный аналитик – это человек, способный творить, созидать и преобразовывать идеи в реальные проекты. Успешный аналитик должен быть грамотным, профессиональным и всегда быть на шаг впереди!

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

Команда GetAnalyst и я, Екатерина Ананьева, подздравляем вас с профессиональным праздником! Пусть работа приносит удовлетворение, карьера растет, а проекты будут интересными и успешными! 💼🎉🥂

💥 Открыта запись на практическую программу для БА и СА:

💥 Интеграции систем
🗓 Старт: 8 октября 2025
🗓 Окончание: 17 декабря 2025

👉 Подробности и регистрация


Ключевые темы и навыки к освоению:
🔸 определение точек интеграций в сложной системе,
🔸 REST API, GraphQL, SOAP API и другие способы интеграции систем,
🔸 работа в Postman,
🔸 архитектура систем, нотация C4,
🔸 интеграционные Use Case,
🔸 нотация UML,
🔸 маппинг данных,
🔸 основы проектирования REST API методов,
🔸 основы работы с брокерами RabbitMQ и Kafka,
🔹 ведение документации в Confluence,
🔹 создание и распределение задач на разработчиков.


------------------------

Бесплатный вводный урок к программе

🟢 Интеграции по REST, GraphQL и WebSocket: от Postman до требований в Confluence
🔗 Зарегистрироваться

будет доступен 27–30 сентября [сб-вт].

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

------------------------


Получайте новый опыт сейчас, чтобы уже в конце 2025 или в начале 2026 году открывать для себя новые возможности! 🙌


Вопросы?
Пишите @getanalyst или на почту info@getanalyst.ru
Поможем оценить текущие навыки и ответим на вопросы 🤝

⭐️ Шаблон задачи на Интеграцию для Confluence:
📌 Пример интеграции Kafka + Backend + БД + Внешняя система ⭐️

В этом месяце мы разбираем интеграционный процесс в системе #CityGA:

автоматическая рассылка мероприятий для города, получаемых из #KudaGoAPI, с отправкой email пользователям через #DashaMailAPI.

Прежде чем поставить задачу на интеграцию, мы:
✅ Описали архитектуру в C4
✅ Изучили API-документацию внешних систем
✅ Выполнили исследовательское тестирование API в Postman
✅ Сделали черновой Use Case по процессу
✅ Показали процесс на UML-диаграмме


❗️ Несмотря на то, что в Use Case рассылка email и сбор данных были объединены, на самом деле это два разных процесса и две разных задачи на разработку.

Почему?
Kafka используется, чтобы вынести отправку email в отдельный асинхронный поток. Основная джоба перебирает связки город + категории и готовит данные, а затем отправляет их в Kafka. Уже после этого сервис уведомлений независимо обрабатывает события (сообщения) и рассылает письма.

Так мы не блокируем работу основного Backend и делаем процесс более надёжным и масштабируемым: сбор данных и рассылка работают параллельно, каждый в своей зоне ответственности.



⭐️ Подготовила для вас заполненный шаблон постановки задачи на интеграцию с внешней системой KudaGo и внутренней интеграцией с Kafka.

Внутри:
▫️ общее описание процесса
▫️ схема архитектуры в C4 — только часть, относящаяся к автоматизации этого процесса
▫️ детальный технический Use Case с альтернативными сценариями
▫️ пример JSON-сообщения для Kafka
▫️ UML Sequence для описанного Use Case с исходным кодом для PlantUML
▫️ маппинги данных: БД–Kafka–API KudaGo
▫️ требования к логированию.



🔖 Cохраняйте образец требований на интеграцию в личный архив. Примеры всегда полезны 😉

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

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

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

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



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

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

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