👩‍💻 AI-интеграция выглядит как магия ровно до тех пор, пока не открываешь Postman 👨‍💻

Задача «подключить AI-ассистента» — это не одна строка в требованиях. Это полноценный интеграционный сценарий.

И пока одни аналитики описывают её как «AI должен ответить пользователю» — другие уже разбирают её на слои: системный промпт, выбор tool, формат ответа и маппинг, streaming (SSE), требования для Backend.

Чтобы перейти во вторую группу, подготовила практическое руководство:


🟠 Groq AI API + Postman
Исследовательское тестирование API искусственного интеллекта.

🕘 Время на практику:
20 минут

👉 Что разбираем:
1️⃣ Создаём Workspace и Collection в Postman
2️⃣ Получаем API-ключ Groq
3️⃣ Отправляем первый запрос с пользовательским промптом
4️⃣ Добавляем системный промпт и тестируем его работу
5️⃣ Добавляем tools — смотрим, как AI просит вызвать функцию
6️⃣ Тестируем стриминг через SSE


📌 После этой практики вы сможете описывать AI-интеграцию не как «магию нейросети», а как понятный сценарий: Use Case → API → prompt → tools → request/response → задача на Backend.

Скачивайте руководство, открывайте Postman и проходите практику 🤝


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

📱 Tg | 💙 ВК | 💬 Max

⚡ Синхрон, асинхрон, стриминг — в чём разница и когда что выбирать? ⚡

Про эти виды обмена данными постоянно спрашивают СА и БА на собеседованиях.


Разбираю на примерах #MedAssistGA.

📌 Синхронный обмен
Отправили запрос — ждём ответа, только потом идём дальше.

Когда нужен:
результат нужен прямо сейчас, чтобы продолжить сценарий.

Примеры:
▫️ GET /doctors — запросили список врачей, ждём, показываем пользователю
▫️ GET /schedule — запросили слоты, ждём, показываем пользователю расписание
▫️ POST /appointments — создали запись, ждём подтверждения от сервиса, показываем пользователю

Здесь нельзя идти дальше без ответа.
Синхрон — единственный вариант.


📌 Асинхронный обмен
Отправили сообщение — не ждём ответа, продолжаем работу.
Результат получим позже.

Когда нужен:
результат не нужен мгновенно,
запрос "тяжелый" (занимает много времени) и важна надёжность обработки.

Пример из #MedAssistGA:
1. Врач запрашивает сводный отчёт по приёмам за месяц POST /reports/appointments
2. Система принимает запрос, кладёт задачу в очередь к обработке (RabbitMQ/Kafka) и сразу возвращает HTTP-201 со статусом "отчет формируется" и id будущего отчета.
3. Врач продолжает работу в системе.
4. Когда отчёт готов, Сервис Уведомлений присылает push или email со ссылкой на скачивание.

Суть: мы не "крутим кружок" и не держим соединение открытым, пока система собирает данные. Пользователь может делать что угодно. А по готовности просто зайти и скачать итоговый результат.


📌 Стриминг (SSE и WebSocket — API реального времени)
Данные передаются не одним ответом, а потоком.
Соединение остаётся открытым на время передачи ответа.

SSE (Server-Sent Events) — однонаправленный поток сервер → клиент. Работает поверх обычного HTTP.

Пример из #MedAssistGA:
1. Пользователь задал вопрос в чате
2. AI Chat Service направил его в Groq
3. Groq генерирует ответ токен за токеном (слово за словом) и возвращает по SSE
4. AI Chat Service получает поток и передаёт его дальше во фронт, тоже через SSE
5. Пользователь видит текст по мере появления, не ждёт полного ответа.


📌 WebSocket — двусторонний канал, обе стороны инициируют сообщения.
В #MedAssistGA его нет — но если добавим онлайн-чат врач–пациент, появится WebSocket.
Пользователь сможет писать сообщения в чат и сразу получать новые сообщения от сервера без обновления страницы. Соединение между Frontend и Backend будет оставаться открытым, поэтому сервер сможет доставлять новые сообщения на экран в реальном времени.



👉 Как выбирать
▫️ Результат нужен сейчас → синхронный REST
▫️ Задача долгая или результат не нужен мгновенно → асинхронный (Kafka, RabbitMQ)
▫️ Сервер передаёт данные клиенту потоком → SSE
▫️ Обе стороны обмениваются в реальном времени → WebSocket


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

📱 Tg | 💙 ВК | 💬 Max

🔴 [4–7 июля] GraphQL возвращает 200 OK. Даже когда ошибка.

В REST такого не бывает.
В GraphQL — норма.
Ошибки живут внутри тела ответа JSON, в поле errors, а не в HTTP-статусе. Пока не знаешь — теряешься.

Это только одна из неожиданностей при первом знакомстве с GraphQL. У gRPC тоже свои особенности.


👉 На этой неделе разбираем все три вида API руками в Postman — без теории в вакууме, сразу с практикой:


🧡 Интеграции по REST, GraphQL и gRPC: знакомство через Postman
🗓 4–7 июля
📹 Формат: запись, смотрите в удобное время

🔗 Зарегистрироваться

————————-—————

💎 Хотите системно разобраться с интеграциями по API и брокерам?
Новый поток «Интеграции систем» стартует на следующей неделе.

Впервые этим летом — максимальный набор подарков и скидок на предзаписи за всю историю GetAnalyst 🎁

🎓 Подробнее о программе

————————-—————

📱 Tg | 💙 ВК | 💬 Max

🔥 Разбор с тех собеса на СА: задача на интеграцию по API 🔥

«Вам дали задачу на интеграцию с платёжной системой по API. Ваш порядок действий?» — и тишина.

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


Разобрала одну такую задачу от начала до конца: интеграция ЭДО с DaData и Т-Банком:
✅ архитектура,
✅ интеграционные Use Case,
✅ маппинг,
✅ эндпоинты,
✅ постановки задач команде.


👉 Смотрите демо решения на удобной площадке:
⏯ YouTube
⏯ RuTube
⏯ VK Video
⏯ Telegram

🎧 Аудио-формат:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Звук
⏯ Spotify

🔗 Статья с доп. материалами по задаче


📱 Tg | 💙 ВК | 💬 Max

🧐 Интеграционный Use Case — другой документ 🧐

Не как обычная задача с описанием поведения пользователя.

У него своя структура: API-вызовы, маппинг данных, технические детали по каждому шагу. Без этого разработчик получает половину информации.


👉 Обычный Use Case:
▪ Предусловие
▪ Роли пользователей
▪ Приложения и системы
▪ Входные данные
▪ Основной сценарий - алгоритм работы
▪ Обработка ошибок и альтернативные сценарии
▪ Ожидаемый результат


👉 Интеграционный Use Case дополняется:
▪ техническими деталями по вызовам API методов, которые аналитику важно прописать в постановке задачи,
▪ маппингом данных.


Важно понимать, что Интеграции — это не просто "еще одна задача".

Это серьезная работа по анализу взаимосвязей
+ БД
+ Функций
+ UI/UX
+ API нашей и внешних систем,
которая требует нашего опыта, внимания и профессионализма 🙌


Мини-книгу про отличия обычных Use Case от интеграционных прикрепила к посту 🤝


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

📱 Tg | 💙 ВК | 💬 Max

🔔 Завтра закрываем лучшие условия на Интеграции 🔥

3 июля завершается предзапись на программу по самым сильным условиям за всю историю GetAnalyst.


🎁 До завтра можно закрепить:

✔️ доступ 8/12 месяцев вместо стандартных 6/9
✔️ курс «БД и SQL: продвинутый уровень» в подарок
✔️ мини-курс «REST API для аналитиков 3.0» в подарок
✔️ закрытую встречу по задачам с собеседований


Предзапись — это заявка, а не оплата.
Она закрепляет за вами условия предзаписи до дня старта потока.


📚 Интеграции систем
🟣 Старт программы — 8 июля

👉 Оставить заявку



А если сейчас хочется начать с бесплатной практики — приходите на вводный практикум 😌

Это полноценное практическое занятие на 3,5 часа, а не просто презентация программы.

Вы сможете уже сейчас:

+ разобраться, чем REST, GraphQL и gRPC отличаются на практике;
+ попробовать работу с API в Postman;
+ понять, как аналитику читать API-документацию;
+ забрать практические навыки, которые можно применить в рабочих задачах.


🧡 Интеграции по REST, GraphQL и gRPC: знакомство через Postman
📅 Доступ 4–7 июля
🕘 3,5 часа практики

🟢 В записи, можно смотреть в удобное время

🔗 Зарегистрироваться


Можно просто прийти за знаниями и уже сейчас получить практические навыки по интеграциям 🙌

🧠 Проектируем AI-чат: где заканчивается нейросеть и начинается обычная автоматизация? 💡🤖

Разбираю на примере AI-чата #MedAssistGA для записи к врачу.


На первый взгляд всё просто.

💬 Пользователь:

«У меня болит горло третий день, к кому идти?»

💬 AI:

«Вам нужен ЛОР»

🔎 и дальше показывает врачей.

👉 Но в реальном продукте так делать технически криво.

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

❗️ Это не автономный AI-агент.



👉 Как обычно разделяют ответственность:

🧠 AI помогает понять смысл сообщения пользователя.
⚙️ Backend+UI управляют бизнес-сценарием.



1️⃣ Что делает AI

AI нужен там, где есть неопределённость.

Пользователь может написать:
▫️ «Болит горло и температура»
▫️ «У ребёнка сыпь»
▫️ «Мне нужен врач по спине»
▫️ «У меня уже есть диагноз, к кому записаться?»

То есть пользователь пишет не структурированные данные, а обычный человеческий текст.

И вот здесь AI полезен.

Он должен:

✅ понять намерение пользователя
✅ аккуратно уточнить симптомы
✅ не ставить диагноз
✅ не назначать лечение
✅ определить подходящую специализацию врача
✅ распознать потенциально опасные симптомы
✅ вернуть структурированное решение для Backend


📌 Например:

💬 Пользователь:

«Третий день болит горло, температура 37.8, заложен нос»

💬 AI:

«По описанию вам может подойти консультация ЛОР-врача. Уточните, пожалуйста, есть ли сильная боль при глотании, налёт на миндалинах или затруднение дыхания?»

После уточнения AI возвращает не просто текст, а структурированное решение:

{
  "intent": "find_doctor",
  "specialty": "ENT",
  "specialtyName": "ЛОР",
  "urgency": "planned",
  "reason": "Пользователь описал боль в горле, насморк и температуру",
  "nextStep": "ASK_CITY"
}

И всё.

На этом интеллектуальная часть закончилась.



2️⃣ Что делает автоматизация

Дальше не нужно заставлять AI «думать», какую кнопку показать.

Это уже обычный backend/UI-flow.

После того как AI определил специализацию, система ведёт пользователя по понятному сценарию:

1. Спросить город
2. Подтвердить город
3. Показать клиники в этом городе
4. Дать выбрать клинику ИЛИ сразу показать врачей по найденной специализации
5. Дать отсортировать врачей по рейтингу/стажу/ближайшему слоту
6. Перейти к записи


📌 Например:

AI определил:

{
  "specialty": "ENT",
  "specialtyName": "ЛОР"
}

Дальше Backend переводит чат в состояние ASK_CITY.

UI показывает:

«В каком городе хотите найти врача?»

Пользователь выбирает город через виджет или пишет город текстом.

После на UI можно спросить что для пользователя более важно: выбрать клинику или врача?

Если клиника, то потом Backend переводит чат в состояние SELECT_CLINIC.
UI показывает клиники.

Потом Backend показывает врачей по параметрам:
▫️ город = Москва
▫️ клиника = выбранная клиника
▫️ специализация = ЛОР
▫️ сортировка = по рейтингу / ближайшему слоту

И далее обычная автоматизация для записи к врачу, без AI.



👉 А если пользователь пишет текст вместо выбора в виджете?

📌 Например:

Система ждёт выбор клиники, а пользователь пишет:

«А до скольки работает клиника на Ленина?»

Тогда это уже событие clinic_info.

Система должна:
1. понять, о какой клинике речь;
2. получить часы работы из справочника;
3. ответить пользователю;
4. не потерять текущий сценарий записи.


📌 Ещё пример.

Система уже показала ЛОР-ов, а пользователь пишет:

«А можно лучше к терапевту?»

Тогда это событие change_specialty.

Система должна изменить специализацию и обновить список врачей.



👉 Почему не надо отдавать всё AI

❌ Сложнее контролировать бизнес-процесс
❌ Сложнее тестировать сценарии
❌ Сложнее обрабатывать ошибки
❌ Сложнее объяснить разработчикам, что именно должно происходить
❌ Сложнее защититься от странных пользовательских сообщений
❌ Сложнее обеспечить стабильный UX

AI может хорошо понять смысл текста.

Но запись к врачу — это уже не «магия нейросети», а обычный процесс, подлежащий автоматизации.



В следующем посте покажу, как под такой сценарий написать системный промпт 🤝


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

🩵🩷 Открыли бесплатный доступ к 3-х часовой практике по REST API, GraphQL, gRPC через Postman 🧡💙

Не мини-урок на 30 минут и не “послушать про API в целом”.

Разбираем то, где у аналитиков обычно начинается путаница: как подступиться к новой интеграции, как читать API-документацию и как руками работать с REST, GraphQL и gRPC через Postman.


👉 Интеграции по REST, GraphQL и gRPC: знакомство через Postman

📅 Доступ до 7 июля (вт)

🕘 3,5 часа практики
🟢 В записи, можно смотреть в удобное время


📌 План:
1. Интеграции: порядок работы над задачами
2. Основы REST API + практика в Postman
3. Основы GraphQL + практика в Postman
4. Основы gRPC + практика в Postman
5. Порядок изучения новых API


🔗 Забрать бесплатный доступ*

*Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно.


Продуктивной практики! 🧡

📱 Tg | 💙 ВК | 💬 Max

💎 Подборка требований на Интеграции [выгрузка задач из Confluence] 💎

Нужно описать интеграцию с внешней системой, но у вас нет опыта и не знаете с чего начать? 🧐

Этот пост для вас! 👇

Собрала:
✔️ Универсальный шаблон постановки задачи на интеграцию для Confluence (шаблон интеграционного Use Case)
✔️ Примеры готовых задач на интеграцию для разных проектов


Выгрузки требований из Confluence:

🔗 Рассылка email через внешнюю систему Unisender

🔗 Создание задач во внешней системе Todoist по итогам оплаты заказа клиентом компании

🔗 Получение компании по ИНН через DaData - популярная интеграция

🔗 Поиск структурированных адресов через DaData - популярная интеграция

🔗 Интеграция по GraphQL - синхронизация справочника стран

🔗 Пример интеграции Kafka + Backend + БД + Внешняя система

🔗 Подробный пример интеграционного Use Case с ВТБ для оплаты экскурсии в TravelGA

🔗 Интеграция с участием крона, воркера, брокера Kafka для регулярной рассылки email по мероприятиям (одновременная интеграци к двум системам)

🔑 "Войти через Госуслуги / Google / Mail ru" (постановка задачи на OAuth 2.0 интеграцию)


Эти документы помогут:
✅ Быстро сориентироваться в структуре задачи
✅ Увидеть реальные примеры работы с требованиями на интеграцию
✅ Экономить время на поиске информации и сосредоточиться на анализе именно вашей задачи с пониманием, что искать, чтобы сделать требования


Изучайте, сохраняйте и пользуйтесь 🔖


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


📱 Tg | 💙 ВК | 💬 Max