🔺 Пример интеграционного Use Case 🔺

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

Из важного:

🔹 Use Case для пользователей и их взаимодействия с мобильными и веб-приложениями (Frontend) пишется отдельно. Это Use Case на Backend, при том достаточно сложный по реализации.
Дополнила статью схемой архитектуры для наглядности. Теперь вы точно поняли, зачем она системному аналитику (без неё сложно воспринимать Use Case, надо много воображать).

🔹В рамках этого Use Case надо сделать 2 API метода и настроить работу очереди. Еще и с БД поработать. Описание Use Case - корневая статья в Confluence, под которую можно сделать отдельные статьи - постановки задач на API методы, БД, очередь и т.д.

🔹Это задача не первая в процессе работы с интеграцией. На практическом вебинаре рассказала, что до неё еще конфигурации, справочники, решение по архитектуре финальное, API протестировать… Много работы 🙂

Не стала постами оформлять. Забирайте выгрузку из Confluence - пересылайте себе это сообщение, чтобы сохранить в закладки 🚀

Прежде чем писать детализированный интеграционный Use Case, настоятельно рекомендую протестировать API, чтобы понять как он работает и убедиться в том, что документация соответствует реальности.

Для интеграции со СДЭК мы будем использовать API, опубликованный на их официальном сайте. Тестировать его можно через Postman:
1. Все запросы POST.
2. Тип данных JSON.

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


Где бы ни была сделана API-документация системы, я всегда проверяю ее. Мне всегда важно увидеть как реально работает API. И это же рекомендую делать и вам, чтобы лучше разобраться с данными внешней системы, с которой мы интегрируемся, и с процессами в ней.

К этому посту я прикрепляю вам видео-урок по работе с Postman. Смотреть с открытым Postman и практиковаться обязательно! 😉

Продолжаем рубрику с историями наших студентов #студентыGetAnalyst.

Мы работаем с обратной связью, благодаря которой стараемся делать внутри GetAnalyst всё лучшее. По возможности стараемся пообщаться с каждым учеником, чтобы узнать как дела, результаты и собрать предложения по улучшению. И я всегда горжусь результатами 🥰

Сегодня рассказываем про достижения Лауры — студентки программы «Интеграции систем».

Лаура — менеджер проектов.

Ранее в GetAnalyst она уже проходила программу «Системный аналитик: с нуля до опыта работы» и другие воркшопы. На обучение по интеграциям в прошлый поток она решила пойти, чтобы углубить знания для новой работы.

После курса девушка поделилась впечатлениями:
«Курс оказался очень объёмный, с большим количеством полезной информации.
Понравилось, что курс был «технический», нацеленный на большое количество практики.

Тема освещается детально, работа ведётся углублённо, а не поверхностно (если сравнивать с другими курсами). Удалось лучше понять и освоить Postman.

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

Ещё всегда приятно, что обучение проходит в небольшой группе, и уделяется время на разбор вопросов».

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

Желаем Лауре реализовать полученные знания в работе и дальше развиваться в профессии! 💛

Привет!

В эту пятницу провели внутреннее обучение на тему "Найм глазами HR и кандидата" с приглашенным HR-директором IT-компании и её старшим сотрудником, кто непосредственно работает с отбором резюме.

На него пригласили всех наших действующих учеников, в том числе тех, кто присоединился к проекту по Интеграциям.

Хочу поделиться с вами интересными моментами, которые обсудили с коллегами:

🔸 Резюме стоит делать по формату, который предлагает hh.ru. Красиво оформленные шаблоны использовать можно, но есть риск, что при загрузке в HR-систему весь ваш красивый текст "уплывёт".

🔸 Фото в резюме вставлять не обязательно. А в США это вообще почти запрещено. Если у вас нет фотографии на нейтральном фоне, то селфи с корпоратива или из путешествия не лучшая идея, лучше уж без фото - это ок.

🔸 Если вы пишете в резюме про хобби или другую дополнительную информацию, то ответьте на вопрос "Зачем?". HR читают резюме по диагонали. Если бы они вчитывались во все, то они бы только и занимались бесконечным чтением. Резюме не должно быть огромным, и всю дополнительную информацию про нерелевантный опыт, хобби и подобное лучше убрать.
Вы должны быстро, в первых строках, вовлечь HR почитать Ваше резюме внимательно. Взгляд бросают в первые секунды на желаемую должность + опыт работы. Это как Reels и посты в запрещенном Instagram.

🔸 Как сделать резюме цепляющим? Сделайте аккуратную и хорошую структуру. Юмор в резюме уже не новинка. Поэтому не зацепит.

🔸 В опыте работы при возможности указывайте какие результаты принесли в проект, особенно в цифрах.

🔸 Софт-скиллы важны! И на них HR смотрят в первую очередь. Работа аналитика напрямую связана с коммуникациями. На первом звонке будут смотреть насколько комфортно общаться с Вами.

Продолжение 👇

🔸 Сейчас идёт мода придумывать опыт в резюме. Как итог - удачно придумавшие вылетают из компании в процессе или к концу испытательного срока. Лучше быть честными.

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

🔸 Со слов HR-директора: практикуйтесь проходить собеседования, это тоже навык! Так что периодически стоит его освежать и не переживать, если первые собеседования неудачны.

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

Даже эта информация достойна сохранения в избранное! 🌟

Круто было то, что нам рассказали новости "с полей" и привели примеры реальных историй!

Также обсуждали вопросы:
- зарплатных вилок,
- как просить повышение,
- что делать, если последние места работы были с периодом до 6 мес,
- принципы составления вакансий,
- нужны ли джуны,
- совмещения нескольких проектов аналитиками,
- процесс найма,
- делали разбор резюме,
- делились полезными книгами
и на самом деле получили много крутой и актуальной сегодня информации!

Крутое мероприятие, которое ученики и эксперты GetAnalyst уже сейчас могут использовать для актуализации своего резюме!


Также хочу напомнить, что сегодня последний день, когда можно посмотреть практический вебинар, который поможет вам в освоении темы Интеграций:

📝 Интеграции: как создавать задачи на разработчиков
🔗 ПОЛУЧИТЬ ДОСТУП К ВЕБИНАРУ

Крутого дня! 🥰

Мем смешной, а ситуация страшная, конечно 😅

Всем отличных выходных, отдыхаем от трудовой недели со всей силы, ребята 😘😘

#GAhahaha

🌟 Маппинг - это процесс сопоставления данных.

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

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


В таблице маппинга организуют несколько основных колонок:

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

Допутима вариативность с колонками.


Теперь перейдем к нашему проекту, чтобы лучше понять маппинг данных.


Есть несколько компонентов системы GetDelivery, которые участвуют в сценарии расчёта стоимости доставки в разных сервисах:

✔️ Мобильное приложение / веб-приложения,
✔️ Backend GetDelivery с его БД, сервисами/микросервисами, REST API,
✔️ СДЭК, Деловые Линии, Возовоз - сервисы доставки, которые предоставят стоимость отправления груза и окажут услуги для конечного клиента.


Данные, которые надо сопоставлять (маппить) для постановок задач:

🟠 Мобильное приложение / веб-приложения:
- что на UI в GetDelivery.

🟠 Backend:
- что в БД GetDelivery,
- что в интеграционном методе REST API, к которому обращаются мобильное или веб-приложение GetDelivery:

🟠 СДЭК, Деловые Линии, Возовоз - внешние системы, поставщики данных:
- что в API внешней системы, для которой пишем сценарий интеграции.

* БД внешних систем для нас закрыты, это неизвестность - “черный ящик”.

Далее 👇👇👇

* БД внешних систем для нас закрыты, это неизвестность - “черный ящик”. Даже если вы по какой-то причине знаете, что в БД внешней системы, т.к. интеграция осуществляется между системами внутри одной компании и секретов нет (NDA - соглашение о неразглашении), то не надо перегружать постановку задачи. Там и так много всего.

Когда и в каких случаях рекомендуется описывать маппинг на примере GetDelivery:

🟢 Для задач на мобильные или веб- приложения GetDelivery:
Маппинг между REST API GetDelivery и UI GetDelivery.

🟢 Для задач на интеграционный REST API GetDelivery c БД GetDelivery, СДЭК, Возовоз, Деловые Линии:
Маппинг между REST API GetDelivery , БД GetDelivery и API внешней системы СДЭК / Возовоз / Деловые Линии (все три внешние системы в один маппинг вставить можно, но тогда нужно очень хорошо подумать над тем, как организовать таблицы.


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

Главный вопрос, с которого начинается любое обучение: «Какая цель?»🎯

Без конкретной цели вы рискуете свернуть не туда или не дойти до финиша.

В коучинге даже есть такой приём — расписать достижение поставленной цели по ощущениям в моменте, когда цель достигнута:
▪️ что я вижу,
▪️ что я слышу,
▪️ что я чувствую.

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

После завершения программы мне всегда приятно фиксировать, что многие пришли к цели уже в процессе, а кто-то даже сделал «за» цель — перевыполнил план))

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

Я стараюсь помочь каждому определить цели и дать рекомендации, которые помогут достичь желаемого результата.


Какие цели ставят студенты GetAnalyst:

✅️ сменить работу и/или повысить доход,

✅️ перейти в системный анализ,

✅️ углубиться в техническое проектирование,

✅️ получить практический опыт по интеграциям, чтобы пополнить портфолио
(+++ моя цель, чтобы на собеседовании вы рассказывали про наш проект, который ведём в ходе курса, а не про «сферического коня в вакууме»)

Мы уже провели встречу по карьере, собираем точки А и цели, смотрели предобучение и первый теоретический модуль. А завтра я увижу коллег на первом онлайн-вебинаре по знакомству с проектом и выделению интеграционных Use Case! 🔥

В эти моменты старта мне ценно осознавать, что обучение от GetAnalyst будет для вас одной из точек в осуществлении целей и потенциальным карьерным ростом уже на старте 2024! 🎄

Спасибо за доверие! И вперёд к результатам 🚀♥️

🟠 Тестирование API - зачем это надо системному аналитику? 🟠


Системный аналитик встречается с тестированием API (программный интерфейс) в следующих случаях:



✅️ Мобильные приложения

Когда аналитик ставит задачи на разработку мобильных приложений, то, как правило, ему необходимо описать маппинг между тем, что есть на экране - UI (пользовательский интерфейс), и тем, что можно отправить или получить от сервера (Backend) через API.

Чтобы это сделать, аналитик знакомится с API-документацией, которую ему предоставляют Backend-разработчики. Возможно он сам ставил им задачи, возможно это были другой аналитик и отдельная команда, которые сделали API.

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



✅️ Backend

Во многих компаниях малого и среднего бизнеса, в крупных компаниях-интеграторах, которые делают IT-проекты на заказ, выделяют отдельную Backend-команду под проект. У крупных IT-проектов это просто необходимость. В такие компании ищут системного аналитика в Backend-команду. Тут сразу хочу заметить, что бизнес-аналитику такую роль выполнять будет почти невозможно, либо сразу можно назвать его системным.

Системный аналитик в Backend-команде должен уметь не только проверить API, но и спроектировать его с нуля, создать документацию для него.



✅️ Интеграции

Системы взаимодействуют друг с с другом по API. Это могут быть как подсистемы внутри одного проекта, так и системы других компаний. Пример - проектирование GetDelivery.

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



Тестирование API позволяет глубже погрузиться в технические особенности, что невозможно сделать на уровне чтения API-документации.

🟢 Зачем системному аналитику инструменты для тестирования API?

1. Проверка Функциональности:
Системный аналитик убеждается, что API выполняет заданные функции в соответствии с документацией. Он проверяет как ведет себя в нестандартных ситуациях, чтобы учесть их и обработать в сценариях работы системы.

2. Обеспечение Безопасности:
В первую очередь это помогает понять механизмов защиты данных в обычных запросах, научиться писать интеграционные сценарии с учетом соблюдения требований к непрерывному удержанию авторизации. Но в некоторых задачах аналитики погружаются глубже, но это скорее исключительные истории.

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

Какими инструментами на работе пользуетесь вы, делитесь в комментариях? Интересно посмотреть на статистику 🙂

👉✅ Тестирование API: обязательные инструменты к освоению для системного аналитика

🟠 Postman

Возможности:
> Отправка запросов к API - HTTP, GraphQL, WebSocket, gRPC, MQTT, Socket.IO,
> Создание и управление коллекциями запросов под разные проекты.
> Тестирование API с помощью написания тестовых сценариев на JavaScript.
> Возможность имитации сервера (Mock Servers) для тестирования без реального API.
> Поддержка автоматизированного тестирования.
> Есть онлайн и десктоп версии, не обязательно устанавливать.

Преимущества:
+ Удобен для новичков.
+ Используется в большинстве компаний. Поэтому именно его я даю на программах по проектированию Интеграций и REST API.
+ Легко интегрируется с другими инструментами и системами.
+ Отличное сообщество и документация: Обширные руководства и активное сообщество пользователей.
+ Бесплатной версии достаточно для работы на небольших проектах.

Недостатки:
- Высокое потребление ресурсов: Может быть ресурсоемким на некоторых компьютерах.


🟡 SoapUI

Возможности:
> Тестирование REST и SOAP веб-сервисов.
> Возможность создания сложных тестовых сценариев без программирования.
> Автоматизация тестирования.
> Мокирование веб-сервисов для тестирования в изолированной среде.
> Поддержка асинхронного тестирования.
> Расширенные возможности отчетности и аналитики..

Преимущества:
+ Поддержка различных типов API: Включая SOAP и REST.
+ Мощные функции для сложного тестирования. Подходит для разработчиков, которым нужны продвинутые возможности.
+ Детальная отчетность, удобная для анализа результатов.

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


Это два главных инструмента, которые используют для проверки API и компании ценят, когда системные аналитики их знают! Postman в большей степени.

Есть ещё два инструмента, которые здесь появятся. Есть идеи? Пишите в комментарии! 😉

🟢 Swagger

Возможности:
> Генерация интерактивной API-документации с использованием OpenAPI спецификации.
> Подходит для проектирования API с нуля, с возможностью визуального редактирования.
> Тестирование API прямо из создаваемой документации.
> Автогенерация API-документации на основе кода приложения благодаря OpenAPI спецификации.
> Поддержка OAuth и других механизмов аутентификации.

Преимущества:
+ Автоматическая документация AP на основе кода.
+ Поддержка OpenAPI Specification, что дает универсальность и стандартизацию для документирования API. OpenAPI сегодня также поддержан и в Postman.
+ Интерактивное тестирование API непосредственно из документации.
+ Сообщество и экосистема предоставляют множество плагинов и инструментов.

Недостатки:
- Начинающим может быть сложно разобраться во всех возможностях, и в целом с OpenAPI.
- Для тестирования API его почти не используют, в основном для написания документации.


🟣 insomnia - больше подходит для тестировщиков.

Возможности:
> Тестирование REST, SOAP, gRPC, GraphQL и др
> Загрузка проектов из Swagger.
> Возможность настройки окружений для тестирования (разработка, тестирование, прод и др.).
> Испольование переменных для упрощения и автоматизации тестов.
> Поддерживает автоматизацию тестов.
> Поддержка версионирования и совместной работы.
> Возможность расширения функциональности с помощью плагинов.

Преимущества:
+ Легок в освоении даже для начинающих.
+ Вся необходимая функциональность бесплатна.
+ Удобен для работы с GraphQL.
+ Активное сообщество: Множество руководств и поддержка сообщества.
+ Возможность создавать и прогонять тест-кейсы - полезно для тестировщиков.
+ Возможность поддержки версионности кейсов с подключением их к Git.

Недостатки:
- Может быть менее подходящим для очень сложных тестовых сценариев: В сравнении с такими инструментами как SoapUI, функционал Insomnia может показаться ограниченным.
- Недостаток интеграций по сравнению с Postman: Хотя Insomnia поддерживает плагины, общее количество интеграций и расширений может быть меньше.

Нагрузочное тестирование 🥲

А еще рекомендуют знать про JMeter. Стоит взять на заметку, если вдруг придется столкнуться с анализом нагрузок на систему и надо будет что-то подсказать разработчикам.

Возможности:
> Нагрузочное и стрессовое тестирование.
> Тестирование производительности веб-приложений.
> Поддержка многопоточности и симуляция одновременного доступа множества пользователей.
> Запись и воспроизведение тестовых сценариев.
> Графическое представление результатов тестирования.


Заключение:

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

Из опыта скажу, что в 90% работы я использую Postman.

Для тестирования SOAP API я обращаюсь к SOAP UI.

Для разработки API-документации тоже использую Postman, но и Swagger в этом деле идеальный помощник, просто более сложный.

Insomnia использовали коллеги-тестировщики, а JMeter однажды разработчики 🙂


Выбор определенного инструмента зависит от конкретных требований и целей тестирования.

Зачем быть частью сообщества, если можно и без этого жить? 🧐

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

Если ваша цель — прокачивать себя и выстраивать сильное окружение вокруг, то стоит об этом помнить 😏

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

Они помогают нам раскрыться, посмотреть на мир под другим углом. А ещё это классный шанс увидеть свои точки роста 💫

Я искренне радуюсь, когда подсвечиваю эти «точки» студентам GetAnalyst. Мне нравится говорить о том, как можно достигнуть новых высот, ставить новые цели в карьере, планировать новые проекты. Безумно приятно потом узнавать, что для кого-то общение стало судьбоносным и повлияло на жизнь.

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

Особенно я люблю живые вебинары и воркшопы ❣️Мне важно быть живой, видеть вашу реакцию, получать обратную связь. После таких встреч я настолько заряжаюсь, что уверена — моей энергии хватит, чтобы поддерживать в тепле как минимум один большой мегаполис! Или запустить ракету в космос 🚀

Спасибо Вам, что вы стали частью GetAnalyst. Спасибо всем, кто прошел с нами путь роста в этом году! ❤🦭