📝📌 Образец по декомпозиции задач на Интеграции - часть 3 📌📝

⬛️ 5.1. Авторизация - продолжение👇
Нужно подготовить отдельную статью на разработчика, с этим описанием: как проходит авторизация запросов в DaData.

А реализацию он может сделать вместе с реализацией первого интеграционного API-метода (п. 6). Мельчить задачи не нужно.

А для OAuth 2.0 у внешней системы, например, всё сложнее))


⬛️ 5.2. Разработка механизма ре-авторизации (повторной авторизации)
Для DaData это не актуально, так как API-ключ постоянный.
Это, кстати, причина, почему мы не можем напрямую обращаться с frontend в DaData, т.к. этот секретный API-ключ могут отследить через консоль, украсть, и начать расходовать наши лимиты платных запросов((


🟪🟪 6. Интеграционные API-методы
Вызов API будет в трех местах:

6.1. Вызов интеграционного метода REST API GABank на получение организаций по ИНН. После вызова метода необходимо будет проверить внутреннюю базу на наличие организации по ИНН + добавить к ней ответы из внешней системы DaData.

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/findById/party

(документация)

6.2. Вызов REST API GABank на получение банков по БИК. Как в п.1, но под капотом вызов другого API-метода внешней системы.

POST http://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/bank

(документация)


6.3. Вызов внутреннего метода REST API GABank на осуществление перевода между юрлицами одного или разных банков. Метод также интеграционный, отправляет операцию в какую-нибудь очередь или брокер на обработку. Но в его детали мы пока не погружаемся.



Возвращаемся к Frontend

🟪🟪🟪 7. Задача на доработку web-, iOS, Android
Нужно поменять дизайн экрана и его поведение при вводе ИНН + БИК на основе ранее созданных макетов UI/UX (п.1) и подключить интеграционные API-методы (п.6).



Готово!
Получилось 7 полноценных задач для одного простого требования.

Такие вот интеграции: “приключение на час”, которое оборачивается в кучу исследований от аналитика и большие работы со стороны разработки 🙌

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

🧡 Гайд по проверке API через Postman 🧡

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

Для этого нужно:

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

Для #GABank тестовый и боевой доступы к DaData не разделяются. При желании можно создать тестовую учетную запись в DaData и продуктовую.


2. Прочитать документацию "по диагонали" и найти важную информацию:
- Авторизация и аутентификация.
- Рекомендации по использованию API. Примеры сценариев использования. Это не всегда есть в API-документации. Но если есть, то считайте, что задача почти готова.
- Общие требования к обработке ошибок. Коды ответов.
- Список методов, необходимых для реализации интеграционных сценариев. Нужно понять, что методов для реализации бизнес-процессов в нашей системе достаточно.

Для интеграции с DaData все это описано в рамках отдельных документов (веб-страниц) по каждому методу.
🔗 Метод поиска компании по ИНН
🔗 Поиск банка по БИК


3. Протестировать API и понять как он работает. В основном для этого используют инструмент Postman. Для SOAP API - инструмент SOAP UI.

Для интеграции с DaData нам потребуется Postman.
🧡 Ссылка на гайд по тестированию одного из методов API DaData в Postman 🧡


Предлагаю посвятить сегодня 20-30 минут (или даже меньше), чтобы разобраться с двумя нужными нам методами API DaData и получить ваш опыт работы с инструментом Postman 😉🧡

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

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

Она должна быть частью жизни, с соблюдением work-life balance (баланс работа-жизнь), помогая достигать целей и реализовывать мечты.

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

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


Несколько рекомендаций, как развивать карьеру Системным Аналитикам:

🌱 Ставьте перед собой четкие цели:
+ Определите, чего вы хотите достичь в своей карьере.
+ Создайте план развития с конкретными шагами и сроками.

🌱 Постоянно учитесь и развивайте технические навыки, будьте в курсе новых трендов:
+ Участвуйте в конференциях и вебинарах.
+ Изучайте новые технологии, инструменты и методы работы.
+ Следите за экспертами в ИТ.
+ Получайте сертификаты.

🌱 Развивайте мягкие навыки (soft skills):
+ Коммуникационные навыки важны для успешного взаимодействия с командой и заказчиками.
+ Развивайте навыки решения конфликтов и переговоров.

🌱 Создайте личный бренд:
+ Делитесь своими знаниями и опытом на профессиональных платформах, таких как LinkedIn, Habr.
+ Пишите статьи, ведите блог или выступайте на конференциях.

🌱 Нетворкинг:
+ Стройте профессиональные связи с коллегами и экспертами в вашей области.
+ Вступайте в профессиональные сообщества.

🌱 Ищите наставников:
+ Найдите наставников, которые смогут направлять и поддерживать вас в вашем развитии.
+ Учитесь у более опытных коллег.


Главное – ставить цели, постоянно учиться и развиваться, следить за новинками в отрасли и учиться у экспертов. С такими усилиями успех неизбежен.

🔗 Backend: задача на интеграционный API-метод 🔗

В общем случае в интеграциях есть несколько слоев, между которыми "гуляют" данные:

🪄 Пользователь
🪄 Наше UI - приложение пользователя
🪄 Наше Backend-приложение + связанные БД, которое может добавить несколько слоев в сценарий работы системы, если это сервисная или микросервисная архитектура
🪄 Внешняя(-ие) системы.

Backend - самый интересный слой этого взаимодействия. Он пограничное звено между нашими приложениями пользователей и внешними системами, который реализует интеграционные методы и отвечает за:
✔️ Авторизацию запросов во внешнюю систему.
✔️ Алгоритм передачи и получения данных из внешней системы.
✔️ Вызов API-методов внешней системы.
✔️ Обработку данных и сопоставление их с БД системы.
✔️ Предоставление данных клиентам API (мобильным приложениям, сайтам, другим системам, которые могут вызывать нашу).

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


В постановке задачи на Backend для реализации интеграционного API-метода необходимо предоставить разработчику:

1. Название метода на русском
1*. Название API-эндпоинта

2. Общее описание, кратко: что это? для кого? почему мы это делаем?
2*. Архитектура взаимодействия компонентов системы в любой нотации (например, C4)

3. Сценарий работы - алгоритм, интеграционный Use Case для части Backend
3.1. Входные данные и результат (какие данные на выходе)
3.2. Алгоритм, включающий вызовы конкретных API-методов, требования к обработке ошибок и работе с БД
3.3*. UML-диаграмма

4*. Технические требования к методу API.
На примере REST API:
- тип метода (GET, POST…),
- URL (эндпоинт)
- JSON-ы запроса и ответа
- список кодов ответов HTTP

5. Маппинг данных:
+ БД
+ API внешней системы
+ разрабатываемый API-метод (из JSON или названия на русском из Use Case)

6*. Логирование

*Продвинутый уровень или не обязательная часть.


Предлагаю рассмотреть пример постановки задачи 🙂👇

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

🔔 Предзапись на практическую программу Интеграции закрывается сегодня.

Подробности тут.

Предобучение начинаем с 26 июня.

А завтра будет анонс открытого урока 😉

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

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

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

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

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

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

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


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

- название поля на русском;
- название поля в REST API системы банка, который создается для его веб- и мобильных приложений;
- название поля в БД банка, т.к. часть данных из DaData может далее сохраняться в БД;
- название параметра в HTTP API системы DaData, чтобы установить соответствие с её полями в интеграции;
- описание и требования к обработке и проверкам.
- типы данных в API банка, API DaData и БД банка. Я бы добавила только отдельную колонку “Тип данных в БД”. Все остальные типы данных очевидны. Но зависит от опыта команды. Чтобы наверняка не получить вопросы - лучше по всем частям прописать типы данных в таблице маппинга.


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

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

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

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

(П) Проект на интеграции:
Веб-сайт и мобильные приложения для сети зоомагазинов PetCo, интегрированные с собственным Backend-приложением и платежной системой Raif Pay

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

(П) Проект на интеграции: логистический сервис GetDelivery

(В) Опасные интеграции
Про альтернативные сценарии и обработку типовых ошибок.

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

(С) ТОП-5 нотаций моделирования архитектуры
Краткое руководство по основным нотациям моделирования архитектуры.

(С) Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты
Пример работы с нотацией, который сможете использовать как ориентир в своей работе, а также инструменты для создания диаграмм C4. В частности Structurizr.

(В) От «умного дома» до «умного города»: новые челленджи IT-аналитиков
О проектировании интеграций с оборудованием. Доклад про особенности разработки требований для IoT проетов (Интернет вещей). В открытом доступе есть презентация.

(П) Проект на интеграции по GraphQL
#TravelPoints

(В) Доставить и не потерять: синхронизация данных в распределенных системах

(В) Подкаст "gRPC vs REST API - что выбрать для проекта"

(П) Проект на интеграции по интеграции банка с DaData для автозаполнения реквизитов
#GABank

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

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

(В) - Видео
(С) - Статья
(П) - Серия постов по проекту в Telegram-канале
(О) - Обучение

Сохраняйте в избранное, чтобы не потерять 🤍

👀 Ищу копию меня cистемного аналитика 👀

Частичная занятость (плавающая, до 6ч / неделю)

Задачи:
- ведение онлайн-занятий
- помощь в проверке проектов

Грейд:
Middle+ / Senior
Опыт от 3-х лет

Что важно:
- желаение делиться опытом, развивать навык публичных выступлений и любовь к своему делу,
- опыт работы с интеграциями по SOAP API, REST API,
- умение проектировать REST API,
- знание инструментов Postman и/или Swagger,
- Умение проектировать и читать схемы БД (ER-диаграммы),
- Знание архитектуры систем на базовом уровне.

Желательно:
- знание gRPC, GraphQL.
- опыт работы в сервисной или микросервисной архитектуре.
- опыт работы с Kafka / Rabbit.


Буду благодарна, если поделитесь с коллегами, кому это может быть интересно 🙏🙏🙏

Ищу вау-вау-вау специалиста 🙌

Откликаться здесь или можно прислать резюме в ЛС @getanalyst.

Картинка для привлечения внимания прилагается, middle+ и senior аналитики точно поймут 😉

🔥 Последний день регистрации на открытый урок по Интеграциям 🔥

🟢 Интеграции: как создавать задачи на разработчиков
🟢 ЗАРЕГИСТРИРОВАТЬСЯ

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

1️⃣ Познакомимся с задачей на интеграции.
Обсудим проект и вводные требования, разберём особенности по порядку работы.

2️⃣ Попрактикуемся выделять важные части API-документации.
Научимся идентифицировать ключевые аспекты документации, которые помогут в разработке.

3️⃣ Опишем архитектуру проекта и определим порядок вызова методов и обработки данных.
Разберём, как строить архитектуру для обеспечения эффективной работы системы, и как на это влияет системный аналитик.

4️⃣ Создадим интеграционный Use Case и разберем моменты, где могут быть ошибки из-за неучтенных требований.
Получите шаблон документации и узнаете, как избегать распространённых ошибок в интеграционных проектах.

5️⃣ Обсудим задачи на разработку БД, Backend и Frontend в интеграционных проектах.
Применим полученные знания на практике для создания конкретных задач разработки.

Доступ к занятию будет открыт с 30 июня до 2 июля.
Регистрация закрывается сегодня, 29 июня, в 23:59 Мск.

Не пропускайте, и планируйте время для саморазвития 🙌

Отличных выходных! 😉

📝 Пример маппинга данных для #GABank 📝

На прошлой неделе рассказала что такое маппинг данных, а теперь хочу показать пример.

Как я делала сопоставление (оно же маппинг) данных.

1) Во-первых, я ничего не могла маппить без БД. Поэтому тут был пост, где я спроектировала часть БД под нашу задачу.

2) Далее, мне не хватало дизайна JSON для REST API метода. Я не заполнила в шаблоне постановки задачи на интеграционный REST API-метод. Сделала его и добавила на картинку.

3) Посмотрела еще раз на таблицу в шаблоне, уточнила её под удобный вид + добавила колонку с типом данных (сравните) и начала заполнять.

4) Заполнила колонки по порядку:
- JSON GABank,
- Название и всё что могу по комментарию,
- JSON DaData,
- БД GABank,
- комментарий с описанием логики, алгоритмов, ограничений и обязательности, всё, что может быть важно программистом.

P.S. Через . показаны уровни вложенности в JSON-ах и таблица.поле в БД.

Вся эта работа требует тщательного анализа, аккуратности и внимательности от нас - системных аналитиков.

Что могло случиться на этом этапе?
🤨 Я могла не найти нужных данных во внешней системе - DaData.
🤨 Отсутствуют нужные таблицы или поля в БД, которые надо сделать до реализации API-метода.
🤨 Пока проектировала JSON и сразу описывала его в таблице маппинга - вернулась и доработала его 3 раза, потому что упустила часть данных, которые хранятся в БД (например, забыла про признак “свой-чужой” счет, который влияет на комиссии при переводах и не только.

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

Похоже, что из этого получится отличная мини-книга по маппигу, которую можно будет подготовить для вас. А пока картинка 😉

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

Друзья, цените даже маленькие достижения!

Всем желаем получить и зафиксировать крутые результаты на этой неделе☺️

#GAfrindlyreminder

🪲 Ошибки в сценариях работы Интеграций 🪲

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

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

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

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

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

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

📚 Подробности в мини-книге, которую прикрепила к посту 💖

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