Общие понятия интеграции. Роль аналитика в интеграциях.

План работы по использованию готового интеграционного решения

План работы по использованию готового решения

Регламент взаимодействия информационных систем

Нефункциональные требования к Подсистеме интеграции

Доменная модель данных Service Desk - Jira

Loose coupling – слабое связывание High cohesion – сильное зацепление

Шаг третий — браузер отправляет HTTP-запрос

Шаг четвёртый — сервер отдаёт HTTP-ответ

Шаг пятый — браузер отображает веб-страницу

Отсутствие сохранения состояния (Stateless)

Жизненный цикл сообщений в системах очередей

Dead Letter Queue (DLQ) — очередь мёртвых сообщений

Как сообщения распределяются по партициям

11.38M

Category:

programming

версия 10 (5) [Автосохраненный]

1. Интеграция информационных систем

2. План курса

1. Общие понятия интеграции. Роль аналитика в интеграциях.
2. Требования к обмену данными между системами.
3. Диаграмма потоков данных.
4. Сценарий интеграции и диаграмма последовательности.
5. Модель данных. Маппинг и преобразование данных при интеграции.
6. Архитектурные паттерны интеграции.
7. Протокол HTTP. REST API
8. Документирование API-методов.
9. SOAP, XML, WSDL.
10.Интеграторы. Шины данных.
2

3. Общие понятия интеграции. Роль аналитика в интеграциях.

4. Интеграция информационных систем

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

5. Пример

Онлайн-магазин по продаже кошачьего корма использует три системы,
которые друг с другом не связаны:
CRM-система —хранение данных о клиентах и заказах;
система учёта товаров на складе — в ней хранится актуальная
информация о количестве, производителях и видах корма;
бухгалтерская система — для финансового учёта.
Системы не обмениваются данными, поэтому сотрудникам, которые с
ними работают, приходится делать много ручной работы. Отдел продаж
готовит копии счётов для бухгалтерии. Бухгалтеры вручную
регистрируют поступления денег на счёт. Сотрудники склада отправляют
накладные в бухгалтерию и не отгружают товар, пока менеджеры по
продажам им не скажут.
5

6. Пример

Система без интеграций
6

7. Интеграция информационных систем

Цели интеграции приложений :
• автоматизировать процессы (уменьшить количество ручного труда и
ускорить процессы)
• улучшить обмен данными (исключить ошибки, связанные с ручным
вводом данных, и обеспечить актуальность информации)
• повышение эффективности бизнеса
• улучшение взаимодействия с клиентами (лояльность пользователей)
• масштабируемость бизнеса
• снижение затрат бизнеса
• единая точка доступа
7

8. Виды интеграции

• Внутренняя
• Внешняя
8

9. По уровню взаимодействия

Вертикальная
• Горизонтальная
9

10. Взаимодействие информационных систем

Диаграмма последовательности показывает генерируемые события
и задает их порядок.
10

11. По типу данных

Синхронная интеграция
• Асинхронная интеграция
11

12. Этапы интеграции

1. Сбор требований
2. Нормализация требований
3. Список требований
4. Постановка задачи на разработку
5. Разработка интеграции
6. Тестирование интеграции
7. Внедрение интеграции
8. Мониторинг интеграции
12

13. Задачи аналитика

1. В чем заключается ценность этой интеграции?
2. Какой целевой бизнес-процесс?
3. Что происходит в каждой системе?
4. Какими данными должна обмениваться система?
5. При каких условиях происходит обмен данными в системах?
6. Каким образом осуществляется обмен данными?
7. Какие функции должны выполняться при обмене данными?
13

14. План работы по использованию готового интеграционного решения

15. План работы по использованию готового решения

Заказчик: мы хотим, чтобы в нашей системы был актуальный
справочник почтовых отделений и чтобы при вводе адреса
осуществлялся поиск нужного отделения
Задача: обеспечить интеграцию с «Почтой России», доработка
алгоритмов при вводе адреса
15

16. Интеграция с «Почта России»

1. Определить интегрируемые системы
Система заказчика и Почта России
16

17. Интеграция с «Почта России»

1. Определить интегрируемые системы
Система заказчика и Почта России
2.Изучить документацию систем в части интеграций
(используемые способы интеграций, способы авторизаций)
17

18. Интеграция с «Почта России»

19.

Идентификация – процедура, в результате выполнения которой
для субъекта выявляется его уникальный признак, однозначно
определяющий его в информационной системе.
Аутентификация – процедура проверки подлинности, например,
проверка подлинности пользователя путем сравнения введенного
им пароля с паролем, сохраненным в базе данных.
Авторизация – предоставление определенному лицу прав на
выполнение определенных действий.
19

20. Интеграция с «Почта России»

Из документации мы узнаем:
1. Каким способом осуществляется интеграция (REST API, SOAP,
FTP и т.д.)
2. Какие данные нужны для авторизации (токен, логин/пароль, не
нужны (OPEN API)
3. Ограничения интеграции (платный доступ, количество
запросов, время жизни авторизации)
4. Формат данных и выходные данные
20

21. Интеграция с «Почта России»

На данном этапе нужно задать вопросы:
1. Устраивает ли нас такой способ интеграции (ограничения со
стороны «нашей» системы)
2. Устраивают ли нас ограничения? (заказчик не готов платить,
мы не вписываемся по количеству запросов)
3. Устраивает ли нас формат данных?
4. Стоит ли рассмотреть другие источники для интеграции?
21

22. План работы по использованию готового интеграционного решения

23. План работы по использованию готового интеграционного решения

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

24. План работы по использованию готового интеграционного решения

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

25. Регламент взаимодействия

26. Регламент взаимодействия информационных систем

Регламент взаимодействия информационных систем определяет правила,
порядок и основные процедуры, связанные с процессами приема и передачи
информации по каналам связи между информационными системами.
Определить регламент взаимодействия между системами:
• Полный объем/только изменения;
• Частота передачи данных;
• Запуск передачи данных: по расписанию (указываются временные
периоды и расписание взаимодействия между системами), по запросу
(системы-приемника), по событию (указываем событие).
Например:
Размещение и обновление записей в таблицах БД выполняется ежемесячно 6
числа с 00-00 до 02-00.
События:
1) внешние (инициируются исполнителями: системами/пользователями)
2) таймерные
3) сбои (исключения)
26

27. 28. Системные требования

Код требования
Требование
Пользователи.AD
Service Desk должна получать данные о пользователях из службы
каталогов Active Directory
Zabbix. Сообщения
Service Desk должна получать сообщения об активации и
деактивации оборудования из системы мониторинга
Jira. Постановка
задач
Интеграционный модуль должен передавать в Jira задачи,
сформированные в Service Desk на основании заявок
пользователей
Jira. Выполнение
задач
Service Desk должна получать из Jira данные о выполнении
разработчиками задач.
Телефония. Звонки
Service Desk должна получать данные звонков из IP-телефонии и
открывать карточку пользователя, если звонок исходит от
пользователя
Почта. Уведомления
Service Desk должна отправлять администратору уведомления об
отказе оборудования
Почта. Задачи
разработчиков
Service Desk должна уведомлять разработчиков о появлении
новых задач
Почта. Заявки
Service Desk должна получать и обрабатывать почтовые
сообщения пользователей
28

29. Нефункциональные требования к Подсистеме интеграции

Надежность
От программного обеспечения, обычно, ожидается следующее:
1) приложение выполняет ожидаемую пользователем функцию;
2) оно способно выдержать ошибочные действия пользователя
или применение программного обеспечения неожиданным
образом;
3) его производительность достаточно высока для текущего
сценария использования, при предполагаемой нагрузке и объеме
данных;
4) система предотвращает любой несанкционированный доступ и
неправильную эксплуатацию.
29

30. Нефункциональные требования к Подсистеме интеграции

Масштабируемость
От программного обеспечения ожидается, что оно продолжит
работать надежно при возросшей нагрузке.
Рост нагрузки -- одна из частых причин снижения надежности:
например, система выросла с 10 тыс. работающих одновременно
пользователей до 100 тыс. или с 1 до 10 млн.
Скорее, обсуждение масштабирования означает рассмотрение
следующих вопросов: «Какими будут наши варианты решения
проблемы, если система вырастет определенным образом?» и
«Каким образом мы можем расширить вычислительные ресурсы в
целях учета дополнительной нагрузки?».
30

31. Масштабируемость

Описание нагрузки на систему:
-
-
количество запросов к веб-серверу в секунду;
отношение количества операций чтения к количеству
операций записи в базе данных;
количество активных одновременно пользователей (в
групповом чате);
частота успешных обращений в кэш и др.
31

32. Производительность

После описания нагрузки на систему, можно выяснить, что произойдет при ее
возрастании:
1) Как изменится производительность системы, если увеличить параметр
нагрузки при неизменных ресурсах системы (CPU, оперативная память,
пропускная способность сети и т. д.)?
2) Насколько нужно увеличить ресурсы при увеличении параметра нагрузки,
чтобы производительность системы не изменилась?
Описание производительности
Для пакетной обработки данных:
- пропускная способность — количество записей, которые мы можем
обработать в секунду, или общее время, необходимое для выполнения
задания на наборе данных определенного размера
Для потоковой обработки данных:
- время отклика — “то, что видит клиент”: фактическое время обработки
запроса + задержки при передаче информации по сети и задержки
сообщений в очереди
Пример: “Время отклика для 95-го процентиля равно 1,5 с”, означает, что 95
из 100 запросов занимают менее 1,5 секунд, а 5 из 100 занимают 1,5 с либо
дольше.
32

33. Нефункциональные требования к Подсистеме интеграции

Код требования
Требование
Нагрузка. Число
пользователей
Система должна поддерживать одновременную работу не
менее 1000 пользователей, подающих заявки
Производительность. Система должна исполнять 80% типовых запросов за
Время отклика
время не более 30 секунд
Надежность. Сбои
Система должна допускать сбои без ущерба безопасности
данных не более чем в 1% обращений
Надежность. Время
восстановления
Система должна восстанавливаться после сбоя не более
чем за 30 сек
Доступность. Время
простоя
Система должна демонстрировать уровень доступности,
при котором допустимое время простоя:
в час не более 3 мин;
в день не более 1 час;
в месяц не более 30 часов.
33

34. Диаграмма потоков данных.

35. 36. Диаграмма потоков данных

DFD (Data Flow Diagram) – диаграмма потоков данных,
предложена Лари Константином в 70-е гг. ХХ века. Это
графическое представление потока данных в
информационной системе. С его помощью можно описывать
входящие и выходящие потоки данных и хранилища этих
данных.
Отображает:
1) пути, по которым циркулируют данные внутри системы, а
также между системой и внешним миром;
2) с какими системами и людьми взаимодействует система и
какого рода данными она обменивается.
36

37. Зачем нужны DFD-диаграммы?

Аналитики используют BPMN и EPC-нотации для того, чтобы
описывать логику выполнения бизнес-процесса. Это отличные
инструменты, но они не позволяют структурно показать, из
каких источников данные поступают, какими процессами
преобразуются и куда направляются.
Обычно такие задачи возникают:
• в проектах управления данными (Data Management)
• при интеграции информационных систем
• в проектах внедрения систем электронного
документооборота
• Там где особенно уделяется внимание безопасности
данных
Диаграмма потоков данных позволяет описать движение и
преобразование данных между внешними сущностями,
хранилищами и процессами. Выходная информация одной
внешней сущности или процесса является входной для
другого процесса или сущности.
37

38. Компоненты DFD-диаграмм

39. Виды DFD-нотаций

Самые распространённые нотации для построения DFD названы в честь их
создателей:
нотация Йордона ― Де Марко;
нотация Гейна ― Сарсона.
Основное различие между ними ― в символах, которые используются для
обозначения процессов. Нельзя сказать, что одна нотация лучше другой, но
нотация Гейна ― Сарсона более распространена.
39

40. Виды DFD-нотаций

41.

Правила построения DFD-диаграмм
✅ Верно собрать требования на начальном этапе.
Нужно найти ответы — как от начала и до конца
происходит процесс и что нужно, чтобы он был
выполнен. От того, насколько точно заданы вопросы,
зависит качество сбора требований, а значит, и
диаграмма потока данных в системе. К тому же это
сокращает вероятность ошибок.
✅ Диаграмма не должна разрастаться до безграничных
размеров. Некоторые данные, например имя, номер
паспорта и телефон, можно сгруппировать в
персональные данные и дать пояснение уже в
техническом задании. Это облегчит восприятие и сделает
диаграмму более читаемой.
41

42.

Уровни и слои DFD-схем
1.Контекстный уровень. (Концептуальная диаграмма)На этом уровне
специалист в общих чертах описывает системы и процессы. Как правило, вся
система представлена как один процесс. Диаграммы контекстного уровня
используются редко, прежде всего они нужны, чтобы в понятном виде
презентовать заказчику проект. Далее эта диаграмма детализируется
логическим и физическим потоками данных.
2. Логический уровень. ( Диаграмма логических потоков данных)
Более подробно описывает процессы, которые происходят в системе, какие
входящие и выходящие данные нужны для каждого из процессов.
3. Физический уровень. (Диаграмма физических потоков данных)
Более детализированный логический уровень, где подробно раскрываются все
входящие и выходящие данные, появляется подробное описание баз данных,
которые используются в работе, и способ реализации всех элементов модели.
Основное отличие от логического – наличие процедур, серверов, баз данных.
42

43.

Уровни и слои DFD-схем
43

44.

Уровни и слои DFD-схем
44

45. Правила построения

Все потоки данных перемещаются между хранилищами через процессы.
DFD — нотация представления структуры процессов, поэтому не
содержит логических операторов (XOR, AND OR) в отличие от
процессно-событийных нотаций BPMN, EPC и UML-activity.
Потоки данных на диаграмме должны быть названы и описаны в
словаре данных. Иными словами, на диаграмме не должно быть
элементов без имени.
В отличие от IDEF0 для диаграммы потоков данных не важно, с какой
стороны стрелка входит в блок «процесс» или «хранилище данных», а
также с какой стороны выходит. Поток данных, выходящий из процесса,
является его выходом или результатом, а входящий — входом.
Как и в IDEF0, проектирование DFD начинается с создания контекстной
диаграммы. Это верхний уровень, который кратко и емко описывает
назначение и границы системы. Контекстная диаграмма относится к
категории диаграмм, описывающих систему на уровне «черного ящика».
Это означает, что на диаграмме отражены только внешние свойства, а
не содержание системы. Потоки данных в нашем случае — это и есть
внешние свойства системы. Дальнейшая декомпозиция этого «черного
ящика» выполняется на следующих уровнях иерархии — вложенных
диаграммах.
45

46. Распространённые ошибки

1.У процесса есть выходящие потоки, но нет входящих.
2.Хранилище и внешний источник связаны напрямую.
3.Поток идет напрямую в двух направлениях.
4.Хранилища связаны напрямую.
46

47. НФТ к интеграции

48. Сценарий интеграции

ID: UC-1.1
Название: Передать данные о новой задаче
Участники: Service Desk, Jira
Предусловия:
Пользователь создал новую заявку в Service Desk.
Триггер
ServiceDesk автоматически назначил Исполнителя.
Постусловия:
1. В Jira создана Задача.
2. Задача назначена на Исполнителя.
Основной поток:
1. Service Desk передает [данные Заявки] в Jira.
2. Jira получает [данные Заявки].
3. Jira создает [Задачу] с данными, полученными из Service Desk.
4. Jira определяет Исполнителя, на которого должна быть назначена Задача.
5. Jira назначает Исполнителя Задачи.
6. Jira отправляет Исполнителю сообщение о назначенной ему Задаче.
7. Сценарий завершен.
Расширение:
4а. Jira обнаруживает, что назначенный Исполнитель не зарегистрирован в Jira.
4а1. Jira создает запись в журнале.
4а2. Jira отправляет Администратору сообщение о невозможности назначения задачи.
4а3. Сценарий завершен.
48

49. Sequence diagram

50. Диаграмма последовательности

Диаграмма последовательности – диаграмма
взаимодействия, в которой основной акцент
сделан на упорядочении сообщений во времени.
Диаграмма последовательности (sequence diagram)
— это способ описания поведения системы "на
примерах".
Диаграмма последовательности (sequence diagram)
— диаграмма, предназначенная для
представления взаимодействия между
элементами модели программной системы в
терминологии линий жизни и сообщений между
ними
50

51. 52. Объекты

В диаграмме объектами выступают участники
системы, такие как акторы (Actor), границы
(Boundary), контроллеры (Control) и сущности
(Entity). Они называются участниками (Participants)
и отображаются в виде пиктограмм или
прямоугольника с названием.
52

53. Линии жизни

Линия жизни (lifeline) — это вертикальная линия на
диаграмме последовательности UML, которая
представляет объект или участника взаимодействия и
связывает его с сообщениями во времени. Линия жизни
начинается с появления объекта на диаграмме и
продолжается до его удаления или окончания
взаимодействия.
На линии указываются различные элементы, такие как
активности, состояния и метки времени, помогающие
уточнить временные параметры взаимодействия
объектов.
Линия жизни является основным элементом на
диаграмме последовательности, который помогает
визуализировать хронологию взаимодействия в системе.
53

54. Бары активации

Это прямоугольник, расположенный на линии
жизни. Используется для указания на то, что объект
активен во время взаимодействия между двумя
объектами. Длина прямоугольника указывает на
продолжительность пребывания объектов в
активном состоянии.
54

55. Стрелки сообщений

56. Фреймы

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

57. Фрейм Alt

Фрагмент альтернативной комбинации используется, когда
необходимо сделать выбор между двумя или более
последовательностями сообщений. Он моделирует логику
“если, то еще”.
57

58. Фрейм Opt

Фрейм Opt (от
«optional», на русском
«необязательный»)
позволяет указать, что
определенные
сообщения являются
необязательными.
Таким образом, если
условие выполняется,
то сообщение
отправляется, а если
нет, то сообщение не
отправляется
58

59. Фрейм Loop

Фрейм «loop» на диаграмме последовательности используется для описания
повторяющегося процесса или цикла. Он указывает, что определенная
последовательность действий должна быть выполнена несколько раз, пока
не будет выполнено определенное условие. Условие, которое указывается в
квадратных скобках, определяет, когда цикл должен завершиться.
59

60. Журналирование событий

Журналирование — это процесс записи в хронологическом порядке событий,
происходящих в системе.
Примеры журналируемых событий:
успешный или неуспешный вход пользователя в систему; выход пользователя
из системы;
добавление, удаление или изменение пользовательских данных;
добавление, удаление или изменение файлов;
заблокированные сетевые пакеты; разрешенные сетевые пакеты;
передача файлов.
Разработка требований к журналированию
1. Перечислить события, информация по которым должна сохраняться в журнале.
2. Описать формат записи в журнале.
3. Описать создание отчета по событиям. Разработать формат отчета.
4. Описать срок хранения записей в журнале. Ротация журналов.
60

61. Журналирование событий

62. Журналирование событий

63. Как отразить события?

64. Как отразить события?

65. Обработка ошибок, оповещение

1. Описать типы ошибок, которые могут регистрироваться в журнале.
2. Описать, как происходит оповещение об ошибках заинтересованных лиц:
– В интерфейсе системы;
– Отправка почтового сообщения;
– Push-уведомление;
– Иные способы.
65

66. Обработка ошибок, оповещение

67. Обработка ошибок, оповещение

68. Организационные требования

Код требования
Требование
Пользователи.AD
Service Desk должна получать данные о пользователях из службы
каталогов Active Directory
Zabbix. Сообщения
Service Desk должна получать сообщения об активации и
деактивации оборудования из системы мониторинга
Jira. Постановка
задач
Интеграционный модуль Service Desk должен передавать в Jira
задачи, сформированные в Service Desk на основании заявок
пользователей
Jira. Выполнение
задач
Service Desk должна получать из Jira данные о выполнении
разработчиками задач.
Телефония. Звонки
Service Desk должна получать данные звонков из IP-телефонии и
открывать карточку пользователя, если звонок исходит от
пользователя
Почта. Уведомления
Service Desk должна отправлять администратору уведомления об
отказе оборудования
Почта. Задачи
разработчиков
Service Desk должна уведомлять разработчиков о появлении
новых задач
Почта. Заявки
Service Desk должна получать и обрабатывать почтовые
сообщения пользователей
68

69. Сценарий интеграции

ID: UC-1.1
Название: Передать данные о новой задаче
Участники: Service Desk, Jira
Предусловия:
Пользователь создал Новую заявку [ServiceCall] в Service Desk.
Триггер
ServiceDesk автоматически назначил Исполнителя [Employee].
Постусловия:
1. В Jira создана Задача [Issue].
2. Задача назначена на Исполнителя [Actor].
Основной поток:
1. Service Desk передает [данные Заявки] в Jira.
2. Jira получает [данные Заявки].
3. Jira создает Задачу с данными, полученными из Service Desk.
4. Jira определяет Исполнителя, на которого должна быть назначена Задача.
5. Jira назначает Исполнителя Задачи.
6. Jira отправляет Исполнителю сообщение о назначенной ему Задаче.
7. Сценарий завершен.
Расширение:
4а. Jira обнаруживает, что назначенный Исполнитель не зарегистрирован в Jira.
4а1. Jira создает запись в журнале.
4а2. Jira отправляет Администратору сообщение о невозможности назначения задачи.
4а3. Сценарий завершен.
69

70. Сценарий интеграции

1. Атомарность шагов при описании передачи данных.
2. Описание валидации данных.
3. Ветвление при проверке данных. Сообщения об ошибках.
4. Полнота требований - ссылки на алгоритмы и структуры
данных.
5. Выход из альтернативных потоков.
6. Не допускается описание интерфейсных решений.
7. Удерживаемся на уровне функциональных требований,
не опускаясь на уровень технического проекта.
8. Журналирование записей и логирование ошибок.
70

71. Доменная модель данных Service Desk - Jira

72. Объектно-реляционное несоответствие

73. Интеграция

74. Объектно-реляционное несоответствие

https://www.planttext.com/
руководство -- https://plantuml.com/ru/guide
74

75. Объектно-реляционное несоответствие

https://drawsql.app/teams/sa-36/diagrams/orn
75

76.

Типы данных:
https://postgrespro.ru/
docs/postgresql/14/da
tatype
https://clickhouse.com/d
ocs/ru/sqlreference/datatypes/int-uint
76

77. Интеграция Service Desk - Jira

78. Маппинг данных

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

79. 80. Маппинг данных

Система-источник
Система-приемник
Service Desk
Jira
Объект/ атрибут
Тип, значение
Объект/ атрибут
Тип, значение
Заявка
ServiceCall
= *Объект*
Задача
Issue
= *Объект*
id
servicecall_id
= *UID, число*
Id заявки
servicecall_id
=
ФИО
client_name
Пользователя
= *Строка*
Пользователь
reporter
= *Строка*
Дата заявки
request_date
=
*Дата и время*
Дата создания
задачи
due_date
=
*Дата и время*
Ссылка на
Исполнителя
responsible_id
=
<Ссылка на
Employee>
Ответственный
assignee
=
<Ссылка на Actors>
Статус
state
= [Open, In progress,
Closed, Resolved,
Reopened]
Статус
status
= [Open, In progress, Closed,
Resolved, Reopened]
Id задачи в
Jira
jira_id
= *UID, Строка*
Id задачи
key
=
Кем решено
solvedby_id
= <Ссылка на
Employee>
Приоритет
priority
= [0, 1, 2, 3]
Приоритет
priority
= [Critical, Major, Minor,
Blocker, Trivial]
Тип услуги
Service_id
= <Ссылка на
справочник услуг>
Тип задачи
issue_type
= [Sub-task, Technical task, Bug,
Improvement]
-
*UID, число*
*UID, Строка*
-
80

81. Преобразование данных

Преобразование значений атрибута Priority
Service Desk
Jira
0
Critical
1
Major, Blocker
2
Minor
3
Trivial
Проверка обработки данных
Наличие объекта в Системе. Если объект не найден:
▪ Создание сущности;
▪ Журналирование ошибки.
81

82. Loose coupling – слабое связывание High cohesion – сильное зацепление

83. Технологии интеграции

84. Архитектурные паттерны интеграции

1.
Передача файлов.
2.
Общая база данных.
3.
Удаленный вызов процедуры.
Удалённый вызов
процедур (иногда вызов
удалённых процедур; RPC от
англ. remote procedure call) —
класс технологий, позволяющих
программам вызывать функции
или процедуры в другом
адресном пространстве
(на удалённых узлах, либо в
независимой сторонней системе
на том же узле).
4. Обмен сообщениями.
84

85. Передача файлов

Настройки подключения и регламент
1. Протокол взаимодействия: FTP, SFTP (с использованием SSH)
2. Настройки подключения.
1. Путь к серверу,
2. Учетные записи подключения к серверу.
3. Регламент передачи файлов.
Требования к источнику данных
1. Структура папок с данными. Шаблоны названий папок (при наличии).
2. Операции после импорта (возможно, удаление файлов из источника).
Анализ данных файлов
1. Проверка файла на актуальность и достоверность.
2. Шаблон названия файлов.
3. Атрибуты файла, их тип, обязательность.
4. Пример файла и схема данных XSD.
Алгоритм обработки файлов, правила валидации
1. Что делать, если в файле не найдена сущность: создать сущность или вывести ошибку.
2. Проверка структуры на целостность.
Журналирование
1. Возможность для администратора просмотреть историю операций.
2. Структура записи:
2. дата и время операции,
3. инициатор,
4. длительность операции,
5. количество обработанных записей,
6. результат обработки,
7. сведения об ошибке.
85

86. Общая база данных

https://mxsmirnov.com/
Недостатки
1.
2.
3.
Изменение структуры базы данных требует согласования со всеми
использующими её приложениями.
Низкий уровень абстракции. Приложения работают не с логическими
объектами, а с конкретными полями и записями.
Совместное использование базы данных требует большого запаса
производительности, так как различные приложения создают различную
нагрузку на сервер и договориться о правилах совместного доступа очень
сложно.
86

87. Удаленный вызов процедуры

Удалённый вызов процедур (Remote Procedure Call, RPC) = класс технологий,
позволяющих ПО вызывать функции или процедуры в другом адресном пространстве
(на удалённых компьютерах, либо в сторонней системе на этом же устройстве).
Обычно реализация RPC включает в себя два компонента: сетевой протокол для
обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для
необъектных RPC).
87

88.

Протокол передачи данных — это набор
правил и соглашений, которые
определяют способ обмена данными
между устройствами и программами в
сети
88

89. RPC

Концепция RPC восходит к ранним дням распределенных
вычислений. Системам требовался способ выполнять процедуры
или функции на удаленных машинах, по сути, выполняя вызов
так, как если бы это была локальная процедура. Системы RPC
начали формироваться в 1980-х годах с появлением SunRPC,
разработанного Sun Microsystems. По мере развития Интернета
возможности RPC росли. Это привело к разработке вариаций,
таких как XML-RPC, которые допускали удаленные вызовы с
использованием XML через HTTP и более поздних версий JSONRPC.
В настоящее время RPC приобрел популярность благодаря таким
протоколам, как gRPC, который сочетает в себе HTTP / 2 и буферы
протокола для доставки высокоэффективных удаленных вызовов.
89

90. RPC

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

91. SOAP

SOAP (от англ. Simple Object Access Protocol —
протокол доступа к объектам) — протокол обмена
структурированными сообщениями в
распределённой вычислительной среде.
Первоначально SOAP предназначался в основном для
реализации удалённого вызова процедур (RPC).
Сейчас протокол используется для обмена
произвольными сообщениями в формате XML, а не
только для вызова процедур. SOAP может работать
через ряд распространённых протоколов, таких как
HTTP, SMTP, TCP или UDP
SOAP является расширением протокола XML-RPC.
91

92.

93. 94. HTTP

HTTP означает «протокол передачи гипертекста»
(или HyperText Transfer Protocol). Он представляет
собой список правил, по которым компьютеры
обмениваются данными в интернете. HTTP умеет
передавать все возможные форматы файлов —
например, видео, аудио, текст. Но при этом
состоит только из текста.
Например, когда вы вписываете в строке
браузера адрес, он составляет запрос и отправляет
его на сервер, чтобы получить HTML-страницу
сайта. Когда сервер обрабатывает запрос,
то он отправляет ответ, в котором написано, что
всё «ок» и вот вам сайт.
94

95.

Кроме HTTP в интернете работает ещё
протокол HTTPS. Аббревиатура
расшифровывается как «защищённый
протокол передачи гипертекста» (или
HyperText Transfer Protocol Secure). Он нужен
для безопасной передачи данных по Сети. Всё
происходит по тем же принципам, как
и у HTTP, правда, перед отправкой данные
дополнительно шифруются, а затем
расшифровываются на сервере.
95

96.

HTTP состоит из двух элементов: клиента
и сервера. Клиент отправляет запросы
и ждёт данные от сервера. А сервер ждёт,
пока ему придёт очередной запрос,
обрабатывает его и возвращает ответ
клиенту.
96

97.

98. 99. Как HTTP-протокол работает

Шаг первый — вписываем URL в браузер
Чтобы отправить HTTP-запрос, нужно
использовать URL-адрес — это
«унифицированный указатель ресурса» (или
Uniform Resource Locator). Он указывает
браузеру, что нужно использовать HTTPпротокол, а затем получить файл с этого адреса
обратно. Обычно URL-адреса начинаются
с http:// или https:// (зависит от версии
протокола).
99

100.

https://yandex.ru/pogoda/
100

101. Шаг второй — браузер находит IP-адрес

Шаг второй — браузер находит IPадрес
Для нас URL-адрес — это набор понятных слов:
Yandex, VK, PIKABU. Но для компьютера эти понятные
нам слова — набор непонятных символов.
Поэтому браузер отправляет введённые вами слова
в DNS, преобразователь URL-адресов в IP-адреса. DNS
расшифровывается как «доменная система имён»
(Domain Name System), и его можно представить как
огромную таблицу со всеми зарегистрированными
именами для сайтов и их IP-адресами.
101

102. Шаг третий — браузер отправляет HTTP-запрос

Шаг третий — браузер отправляет
HTTP-запрос
DNS возвращает браузеру IP-адрес,
с которым тот уже умеет работать. Теперь
браузер начинает составлять HTTP-запрос
с вложенным в него IP-адресом.
102

103.

103

104. Шаг четвёртый — сервер отдаёт HTTP-ответ

Шаг четвёртый — сервер отдаёт
HTTP-ответ
После получения и обработки HTTP-запроса
сервер создаёт ответ и отправляет его
обратно клиенту. В нём содержатся
дополнительная информация (метаданные)
и запрашиваемые данные.
104

105.

105

106.

Здесь три главные части: статус ответа —
HTTP/1.1 200 OK, заголовки ContentType и Content-Length и тело ответа —
HTML-код.
106

107.

107

108. Шаг пятый — браузер отображает веб-страницу

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

109.

109

110.

110

111.

111

112. REST

Доктор Рой Филдинг представил REST в своей
докторской диссертации 2000 года. Вместо того,
чтобы сосредотачиваться на действиях или методах,
как в RPC, REST сосредотачивается на данных.
Филдинг делал упор на использовании
неотъемлемых возможностей Интернета, в частности
запросов HTTP без состояния и стандартизированных
методов.
Благодаря своей простоте и соответствию принципам
web, REST быстро набрал популярность. Он стал
стандартом для общедоступных API в Web.
112

113. REST

REST — это архитектурный стиль
приложений (API). Он не ограничивается
никакими протоколами и не имеет
собственных методов. Но обычно в RESTfulсервисах используют стандарт HTTP, а файлы
передают в формате JSON или XML.
113

114. Клиент-серверная модель

В основе данного ограничения лежит разграничение потребностей.
Данное ограничение повышает переносимость клиентского кода на
другие платформы, а упрощение серверной части улучшает
масштабируемость системы.
Само разграничение на “клиент” и “сервер” позволяет им развиваться
независимо друг от друга. До тех пор, пока каждая сторона знает, какой
формат сообщений следует направлять другой стороне, они могут
храниться модульно и раздельно. Кроме того, разделение позволяет
каждому компоненту развиваться независимо.
114

115. Отсутствие сохранения состояния (Stateless)

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

116. Кэширование

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

117. Единообразие интерфейса

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

118. Слои

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

119. Код по требованию (необязательно)

Код по требованию
(необязательно)
Этот принцип означает, что сервер в ответ
на запрос может отправить исходный код,
который выполняется уже на стороне клиента.
Благодаря этому можно передавать целые
сценарии. Например, динамические элементы
пользовательского интерфейса, написанные
на JavaScript.
В REST API требование необязательно, потому
что не всем сайтам и сервисам нужно умение
работать с готовыми скриптами.
119

120. REST

120

121.

121

122.

122

123.

123

124. Basic Authentication

это один из наиболее простых методов
аутентификации. При использовании данного метода
клиент отправляет свои учетные данные (обычно имя
пользователя и пароль) в заголовке запроса:
Host: example. ru
Authorization: Basic Fkjlcm5hbWU6cGFzc3dvcm1=
В данном примере "Fkjlcm5hbWU6cGFzc3dvcm1=" —
это base64-кодированная строка «username и
password»
124

125. API Key Authentication

предполагает использование специального
ключа доступа (API key), который обычно
передается в заголовке запроса. Этот ключ
является уникальным для каждого клиента и
используется для идентификации,
аутентификации и авторизации клиента при
обращении к API Host: example. ru
x-api-key: fkDUekmxinrvddbUBfgyNFO
125

126. Bearer Token Authentication

Bearer Token Authentication
метод, при котором после успешной
аутентификации клиент получает
специальный токен, который затем
включается в заголовок «Authorization»
для каждого запроса к API. Токен может
быть получен через процесс авторизации,
такой как OAuth 2.
126

127.

127

128.

128

129.

129

130.

130

131. SWAGGER

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

132. Два способа создания документации

На основе кода. Инструмент «читает» код API и на его основе генерирует
документацию. Такой способ считается более простым, потому что от
разработчика не требуется знать спецификацию и писать что-то помимо
самого кода. Но его рекомендуют применять только тогда, когда
документация нужна срочно, — потому что второй способ позволяет
создавать более подробные и понятные описания.
На основе спецификации. Второй способ — использовать спецификацию
Swagger, которая называется OpenAPI. Он сложнее, потому что необходимо
знать язык формальных правил — на нем нужно описать сущности кода,
чтобы инструмент понял написанное и сгенерировал документ. Но этот
подход более правильный, потому что такая документация более понятна и
человекочитаема. Писать необходимо с помощью форматов JSON или YAML
либо в специальном редакторе Swagger Editor.
https://practicum.yandex.ru/blog/chto-takoe-swagger/#chto-takoe
132

133.

133

134.

134

135.

135

136.

136

137.

137

138.

138

139.

139

140.

140

141.

141

142. JSON SCHEME

JSON Schema — это язык описания структуры
JSON-данных. Это как «паспортный контроль»
для JSON.
Чтобы отсечь невалидные запросы на границе
API (не пускать мусор внутрь)
Чтобы автоматически генерировать
документацию
Чтобы клиенты знали, какие поля обязательны
и какого они типа
Чтобы генерировать тестовые данные
142

143. JSON SCHEME

143

144. Какие ограничения можно накладывать

Категория
Ключевые слова
Что проверяет
Тип
type
object, array, string, integer,
number, boolean, null
Обязательность
required
Список обязательных полей
Длина строки
minLength, maxLength
Длина строки
Диапазон числа
minimum, maximum, exclusiveM
inimum, xclusiveMaxmum
Значения чисел
Регулярное выражение
pattern
Формат (email, телефон,
индекс)
Специальный формат
format
email, uri, date-time, uuid
Массивы
minItems, maxItems, uniqueItem
s
Размер массива
Элементы массива
items
Тип элементов в массиве
Запрет лишних полей
additionalProperties
Нельзя добавлять поля,
которых нет в схеме
Перечисление
enum
Список допустимых значений
144

145.

Пример схемы + файлики
145

146.

Что проверяем
Ключевое слово
Объект
"type": "object"
Массив
"type": "array"
Обязательные поля
"required": ["id", "name"]
Число от 1 до 100
"minimum": 1, "maximum": 100
Длина строки от 2 до 50
"minLength": 2, "maxLength": 50
Только допустимые значения
"enum": ["active", "inactive"]
Email формат
"format": "email"
Запретить лишние поля
"additionalProperties": false
Тип элементов массива
"items": {"type": "string"}
146

147. XML

XML (eXtensible Markup Language) — это
расширяемый язык разметки,
предназначенный для хранения
и передачи данных в структурированном
виде. Данные находятся внутри тегов,
которые помогают организовать данные
в логической иерархии, понятной человеку
и компьютеру.
147

148.

<person>
<name>Иван Петров</name>
<age>30</age>
<email>ivan@example.com</email>
</person>
148

149. Структура

Декларация XML. Разметка начинается с записи: <? xml version="1.0»
encoding="UTF-8»?>. Эта строка указывает версию XML и кодировку
документа, что помогает правильно интерпретировать содержимое файла.
Элементы. Это основные строительные блоки XML-документа. Они
заключены в теги — например, <book>…</book> — и могут содержать текст,
атрибуты и другие элементы.
Атрибуты. Это дополнительные данные, которые можно добавить
к элементам, чтобы более точно указать их характеристики. Они
записываются внутри открывающего тега и позволяют добавлять
дополнительную информацию без создания новых элементов. Например,
в элементе <book genre="учебник"> атрибут genre указывает на жанр книги,
что помогает более точно описать её содержание.
Текстовое содержимое. К тексту относится всё, что находится между
открывающим и закрывающим тегами элемента. Например, <title>XML для
начинающих</title>.
Комментарии. Это элементы разметки, которые позволяют добавлять
заметки и пояснения в код. Они заключены в <! --… -->, не влияют
на обработку документа и нужны для удобства разработчиков.
149

150.

<?xml version="1.0"?>

<PRODUCTS>
<PRODUCT>
<TITLE> Product #1 </TITLE>
<PRICE> 10.00 </PRICE>
</PRODUCT>
<PRODUCT>
<TITLE> Product #2 </TITLE>
<PRICE> 20.00 </PRICE>
</PRODUCT>
</PRODUCTS>
150

151. Теги

В XML каждый элемент должен быть
заключен в теги. Тег — это некий текст,
обернутый в угловые скобки
Открывающий — текст внутри угловых скобок
• Закрывающий — тот же текст (это важно!), но
добавляется символ «/»
С помощью тегов мы показываем системе
«вот тут начинается элемент, а вот тут
заканчивается».
151

152. Корневой элемент и элементы

В любом XML-документе есть корневой элемент.
Это тег, с которого документ начинается, и
которым заканчивается. В случае REST API
документ — это запрос, который отправляет
система. Или ответ, который она получает.
Называется он как угодно. Он показывает начало и
конец нашего запроса, не более того. А вот внутри
уже идет тело документа — сам запрос. Те
параметры, которые мы передаем внешней
системе. Разумеется, они тоже будут в тегах, но
уже в обычных, а не корневых.
152

153. Атрибуты

У элемента могут быть атрибуты — один
или несколько.
<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
153

154.

<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
154

155.

В первом примере данные о поле хранятся в атрибуте
"sex".
Во втором примере пол указан в дочернем элементе
"sex".
Оба примера предоставляют одну и ту же информацию.
Не существует каких-либо жестких правил когда
использовать атрибуты, а когда элементы. Тем не менее,
опыт показывает, что атрибуты удобны в HTML, однако в
XML следует стараться избегать их. Если информация
представляет данные, то следует использовать элементы.
155

156.

<party type="PHYSICAL" sourceSystem="AL"
rawId="2">
<field name=“name">ООО Ромашка </field>
<field name="birthdate">02.01.1980</field>
<attribute type="PHONE" rawId="AL.2.PH.1">
<field name="type">MOBILE</field>
<field name="number">+7 916
1234567</field>
</attribute>
</party>
156

157. Основной элемент party

Основной элемент party
type = «PHYSICAL» — тип возвращаемых данных.
Нужен, если система умеет работать с разными
типами: ФЛ, ЮЛ, ИП. Тогда благодаря этому атрибуту
мы понимаем, с чем именно имеем дело и какие поля
у нас будут внутри. А они будут отличаться. У физика
это может быть ФИО, дата рождения ИНН, а у юр лица
— название компании, ОГРН и КПП
sourceSystem = «AL» — исходная система. Возможно,
нас интересуют только физ лица из одной системы,
будем делать отсев по этому атрибуту.
rawId = «2» — идентификатор в исходной системе. Он
нужен, если мы шлем запрос на обновление клиента, а
не на поиск. Как понять, кого обновлять? По связке
sourceSystem + rawId
157

158.

Это удобно с точки зрения поддержки,
когда у вас коробочный продукт и 10+
заказчиков. У каждого заказчика будет
свой набор полей: у кого-то в системе есть
ИНН, у кого-то нету, одному важна дата
рождения, другому нет, и т.д.
Но, несмотря на разницу моделей, у всех
заказчиков будет одна XSD-схема
158

159. Пространство имем

Пространство имён в XML (англ. XML namespace) —
это стандарт, описывающий именованную группу
имён элементов и атрибутов, служащую для
обеспечения их уникальности в XML-документе.
(значение которого ссылка URI)
Все имена элементов в пределах пространства имён
должны быть уникальны.
XML-документ может содержать имена элементов и
атрибутов из нескольких словарей XML.
159

160. Пространство имён xml

160

161.

161

162.

162

163.

163

164. Well Formed XML

Есть корневой элемент. И он только один
• У каждого элемента есть закрывающийся
тег.
• Теги регистрозависимы!
• Соблюдается правильная вложенность
элементов.
• Атрибуты оформлены в кавычках.
164

165. XSD схема

какие типы данных у каждого поля;
• какие поля обязательны для заполнения, а
какие нет;
• есть ли у поля значение по умолчанию, и
какое оно;
• есть ли у поля ограничение по длине;
• есть ли у поля другие параметры;
• какая у запроса структура по вложенности
элементов;
165

166. XSD

XSD — это язык описания структуры XML
документа. Его также называют XML Schema.
166

167.

Теперь, когда к нам приходит какой-то
запрос, он сперва проверяется на
корректность по схеме. Если запрос
правильный, запускаем метод,
отрабатываем бизнес-логику.
Валидация по схеме помогает быстро
отсеять явно невалидные запросы, не
нагружая систему.
167

168. Как это работает в реальности?

Мы выступаем в качестве системы источника
данных. Описываем XSD-схему для запроса: нужно
передать элемент такой-то, у которого будут такието дочерние, с такими-то типами данных. Эти
обязательные, те нет.
Система, которая интегрируется с нашей, читает
эту схему и строит свои запросы по ней.
Система-заказчик отправляет запросы нам.
Наша система проверяет запросы по XSD — если
что-то не так,то возвращаем ошибку
Если по XSD запрос проверку прошел — включаем
бизнес-логику
168

169. Структура xsd

Элемент XSD
Что делает
<xs:schema>
Корневой элемент схемы
<xs:element>
Объявляет элемент (глобальный)
<xs:complexType>
Определяет сложный тип (содержит вложенные
элементы)
<xs:simpleType>
Определяет простой тип (ограничения для
строк/чисел)
<xs:sequence>
Элементы должны идти в указанном порядке
<xs:choice>
Можно выбрать только один из перечисленных
<xs:all>
Любой порядок, но каждый элемент не более
одного раза
<xs:attribute>
Объявляет атрибут
<xs:restriction>
Ограничение для простого типа (длина,
диапазон, enum)
169

170. Виды элементов по структуре

Простые элементы – содержат только текст различных типов (boolean,
string, date и т.п.) и имеют фиксированные значения:
<xs:element name="имя элемента" type="тип данных"/>
Cложные элементы – содержат другие элементы и/или атрибуты.
<xs:element name="имя элемента" type="ИмяКомплексногоТипа"/>
<xs:complexType name="ИмяКомплексногоТипа">
<xs:sequence>
<xs:element name="имя элемента1" type="xs:string"/>
<xs:element name="имя элемента2" type="xs:string"/>
</xs:sequence>
</xs:complexType>
170

171. Индикаторы

Для контроля использования элементов используются
индикаторы
• "all" – устанавливает, что дочерние элементы могут появляться
в любом порядке и что каждый из них должен появляться
всего один раз;
<xs:element name="имя сложного элемента">
<xs:complexType>
<xs:all>
<xs:element name="имя элемента1" type="xs:string"/>
<xs:element name="имя элемента2" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:element>
171

172.

"choice" – устанавливает, что появляться может либо один
дочерний элемент, либо другой;
<xs:element name="имя сложного элемента">
<xs:complexType>
<xs:choice>
<xs:element name="имя элемента1" type="ТипЭлемента1"/>
<xs:element name="имя элемента2" type="ТипЭлемента2"/>
</xs:choice>
</xs:complexType>
</xs:element>
172

173.

"sequence" – устанавливает, что дочерние элементы
должны появляться в заданном порядке.
<xs:element name="имя сложного элемента">
<xs:complexType>
<xs:sequence>
<xs:element name="имя элемента1" type="xs:string"/>
<xs:element name="имя элемента2" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
173

174.

"maxOccurs" – устанавливает максимальное количество
появлений элемента;
• "minOccurs" – устанавливает минимальное количество
появлений элемента.
<xs:element name="имя сложного элемента">
<xs:complexType>
<xs:sequence>
<xs:element name="имя элемента1" type="xs:string"/>
<xs:element name="имя элемента2" type="xs:string"
maxOccurs="10" minOccurs="0/>
</xs:sequence>
</xs:complexType>
</xs:element>
174

175. Атрибуты

В xsd атрибуты представлены тегом <xs:attribute> и
предоставляют дополнительную информацию об
элементе.
Атрибуты должны быть заданы для каждого сложного
элемента xsd-схемы (complexType). Простые элементы не
могут иметь атрибуты.
Все атрибуты декларируются, как простые типы
<xs:attribute name="имя атрибута" type="тип данных
атрибута"/>
175

176.

По умолчанию атрибуты являются
необязательными для использования.
Чтобы декларировать обязательный
атрибут, следует воспользоваться
атрибутом "use" . В этом случае в xmlпакете этот атрибут должен быть указан
176

177.

<xs:attribute name="имя атрибута"
type="xs:string" use="required"/>
177

178.

Пример xsd + файлы
178

179. SOAP

SOAP (Simple Object Access
Protocol) — это протокол обмена
структурированными сообщениями в
распределённой среде.
SOAP — это протокол, а не
архитектурный стиль. Он
определяет формат сообщения, а не
то, как его передавать.
179

180.

Любое сообщение в протоколе SOAP — это XML
документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент.
Определяет начало и окончание сообщения. Говорит
«это SOAP-сообщение»
Header. Необязательный элемент — заголовок.
Содержит элементы, необходимые для обработки
самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную
информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках,
возникающих в процессе обработки сообщения.
Необязательный.
180

181.

181

182.

Обязательные элементы:
Envelope — корневой, говорит «это SOAP-сообщение»
Body — тело, основное содержимое
Опциональные:
Header — метаинформация (авторизация, транзакции)
Fault — сообщение об ошибке
182

183.

183

184. Протоколы

Протокол
Где используется
HTTP / HTTPS
90% случаев (современные веб-сервисы)
SMTP
Почтовые серверы (редко)
FTP
Файловый обмен (редко)
JMS
Java Message Service (корпоративные
системы)
TCP
Напрямую (для производительности)
184

185. WSDL — контракт SOAP-сервиса

WSDL — контракт SOAPсервиса
WSDL (Web Services Description
Language) — это XML-файл, который
описывает: что умеет сервис, какие
операции есть, какие типы данных, где
сервис находится
185

186. WSDL отвечает на 3 вопроса

Вопрос
Как в WSDL
Что?
types — типы данных, message —
структура сообщений
Как?
portType — операции
Где?
service — URL сервиса
186

187. Задание

188

188.

Протокол gRPC
gRPC (gRPC Remote Procedure Call) —
это высокопроизводительный RPCфреймворк от Google.
189

189. Протокол gRPC

Почему gRPC быстрый?
Protocol Buffers (protobuf)
В REST мы обычно
передаёте JSON (текст). В gRPC мы
передаём
бинарный
protobuf
Критерий
JSON
Protobuf
Формат
Текст (читаемый)
Бинарный (не читаемый)
Размер
Большой
Маленький (в 3-5 раз
меньше)
Скорость парсинга
Медленнее
Намного быстрее
Типизация
Слабая (нет схемы)
Строгая
(есть .proto контракт)
190

190. Почему gRPC быстрый?

Пример proto
syntax = "proto3";
package ecommerce.v1;
option java_package = "com.example.ecommerce";
import "google/protobuf/timestamp.proto";
service CustomerService {
rpc GetCustomer (GetCustomerRequest) returns (Customer);
rpc CreateCustomer (CreateCustomerRequest) returns (Customer);
rpc ListCustomers (ListCustomersRequest) returns (stream Customer);
}
message GetCustomerRequest {
int32 customer_id = 1;
}
message CreateCustomerRequest {
string name = 1;
string email = 2;
optional int32 age = 3;
}
message Customer {
int32 id = 1;
string name = 2;
string email = 3;
int32 age = 4;
repeated string tags = 5;
google.protobuf.Timestamp created_at = 6;
}
191

191. Пример proto

Номера полей
message Customer {
int32 id = 1; // номер 1
string name = 2; // номер 2
string email = 3; // номер 3
}
Номера полей не меняются в жизни
контракта!
Можно добавить новое поле с новым
номером
Можно удалить поле (но его номер больше
нельзя использовать)
192

192. Номера полей

Поверх какого протокола
работает gRPC
gRPC работает поверх HTTP/2. Это
ключевое отличие от REST (чаще
HTTP/1.1).
Что даёт HTTP/2 для gRPC:
Мультиплексирование — много
запросов по одному соединению
• Бинарный протокол — быстрее
текстового
• Server Push — сервер может отправлять
данные без запроса
• Сжатие заголовков (HPACK)
193

193. Поверх какого протокола работает gRPC

Обмен сообщениями
Развитие архитектуры с монолита до
микросервисов
194

194. Обмен сообщениями

Архитектуры
• Монолитная архитектура
(Монолитное приложение относится к программной архитектуре, в которой
все компоненты от серверного кода до пользовательского интерфейса и БД
представляют собой единый объект)
• SOA
(модульный подход к разработке программного обеспечения,
базирующийся на обеспечении удаленного использования по
стандартизированным протоколам распределённых, слабо
связанных[англ.], легко заменяемых компонентов (сервисов) со
стандартизированными интерфейсами зачастую идет с шиной)
• Микросервисная архитектура
(Микросервисы развились на основе SOA, но в отличие от нее позволяют
разрабатывать приложения, представляющие собой набор сервисов, а не
единый монолитный код. Каждый из них является независимым ПО со
своей функциональностью и базой данных. Такой подход упрощает
модификацию приложений и их обслуживание. )
195

195. Архитектуры

Enterprise Service Bus
Интеграционная шина данных –это программное
решение, объединяющее различные информационные
системы в единое информационное пространство и
обеспечивающее унифицированный и гибкий обмен
данными. Шина выполняет роль посредника, позволяя
приложениям взаимодействовать без необходимости
в прямом подключении друг к другу, что значительно
упрощает IT-архитектуру и делает её более гибкой. В
условиях цифровой трансформации интеграционная
шина становится незаменимым инструментом для
оптимизации управления данными и процессами на
предприятии.
196

196. Enterprise Service Bus

Что такое ESB?
Это не один программный продукт, а целый слой
систем, обеспечивающий их взаимодействие.
Студия (Low code система, код, job) Обеспечивает
коннектор к системы, интерфейс взаимодействия
Брокер сообщения. Отвечаем за сообщения и обработку их.
Логирование. Показывает как шел обмен вчера, позавчера.
Мониторинг. Показывает текущие проблемы, вот сейчас нет
сообщений
Хостинг. Свое клауд решение, Kubernetes, докер контейнеры.
197

197. Что такое ESB?

Выбор шины данных (ESB)
Факторы
1.
2.
3.
4.
5.
Стоимость и возможность расширить функциональность
(OpenSource).
Производительность (10 000 vs 1 000 000 rps (запросов в секунду)) .
Масштабируемость, возможность наращивать производительность
горизонтальным увеличением мощностей
Возможность преобразования форматов данных и их обогащение
Управляемость
Oracle ESB
198

198. Выбор шины данных (ESB)

Система обмена сообщениями
199

199. Система обмена сообщениями

Зачем нужны очереди?
1. Разгрузка системы. Клиент не ждёт, пока
обработается отчёт. Сообщение в очередь →
клиенту «Принято», а отчёт генерируется в
фоне.
2. Надёжность. Если получатель недоступен,
сообщение не теряется. Оно лежит в очереди
и дождётся.
3. Нагрузка (load leveling). В «Чёрную пятницу»
заказов в 10 раз больше, но обработчик может
вычитывать их со своей скоростью — очередь
растёт, но не падает.
4. Асинхронность. Системы не блокируют друг
друга.
200

200. Зачем нужны очереди?

Система обмена сообщениями
Message oriented middleware - MOM
Процедура передачи сообщения:
1. Создание. Отправитель создает сообщение.
2. Отправка. Отправитель помещает сообщение в канал.
3. Доставка. Система обмена сообщениями доставляет сообщение с компьютера
отправителя на компьютер получателя.
4. Получение. Получатель извлекает сообщение из канала.
5. Обработка. Получатель считывает полезную информацию.
2 концепции обмена сообщениями:
1. Отправить и забыть.
2. Передача с промежуточным хранением.
201

201. Система обмена сообщениями

Системы очередей обычно состоят из трёх базовых
компонентов:
1) сервер,
2) продюсеры, которые отправляют сообщения в
некую именованную очередь, заранее
сконфигурированную администратором на
сервере,
3) консьюмеры, которые считывают те же самые
сообщения по мере их появления.
202

202.

pull-модель — консьюмеры сами отправляют запрос раз в n секунд на
сервер для получения новой порции сообщений. При таком подходе
клиенты могут эффективно контролировать собственную нагрузку. Кроме
того, pull-модель позволяет группировать сообщения, таким образом
достигая лучшей пропускной способности. К минусам модели можно
отнести потенциальную разбалансированность нагрузки между разными
консьюмерами, а также более высокую задержку обработки данных.
push-модель — сервер делает запрос к клиенту, посылая ему новую порцию
данных. По такой модели, например, работает RabbitMQ. Она снижает
задержку обработки сообщений и позволяет эффективно балансировать
распределение сообщений по консьюмерам. Но для предотвращения
перегрузки консьюмеров в случае с RabbitMQ клиентам приходится
использовать функционал QS, выставляя лимиты.
203

203.

Жизненный цикл сообщений в
системах очередей
1.Продюсер отправляет сообщение на сервер.
2.Консьюмер фетчит (от англ. fetch — принести) сообщение и его
уникальный идентификатор сервера.
3.Сервер помечает сообщение как in-flight. Сообщения в таком
состоянии всё ещё хранятся на сервере, но временно не
доставляются другим консьюмерам. Таймаут этого состояния
контролируется специальной настройкой.
4.Консьюмер обрабатывает сообщение, следуя бизнес-логике.
Затем отправляет ack или nack-запрос обратно на сервер,
используя уникальный идентификатор, полученный ранее — тем
самым либо подтверждая успешную обработку сообщения, либо
сигнализируя об ошибке.
5.В случае успеха сообщение удаляется с сервера навсегда
(Rabbit). В случае ошибки или таймаута состояния in-flight
сообщение доставляется консьюмеру для повторной обработки.
204

204. Жизненный цикл сообщений в системах очередей

205

205.

Гарантии доставки
Гарантия
Не более одного
раза
Не менее одного
раза
Ровно один раз
Английское название
Что обещает
Риски
At most once
Сообщение не будет
доставлено более
одного раза. Может
не доставиться
вообще.
RabbitMQ autoAck=
true
Kafka acks=0
Потеря данных
At least once
Сообщение будет
доставлено минимум
один раз. Может быть
дублировано.
RabbitMQ autoAck=
false
Kafka commit = false
Дубликаты
Exactly once
Сообщение будет
доставлено один раз
и без дублей. Ни
потерять, ни
Высокая сложность,206
низкая

206. Гарантии доставки

Dead Letter Queue (DLQ) —
очередь мёртвых сообщений
Вариант
Описание
Когда применять
Ручной разбор
Администратор
смотрит,
исправляет ошибку,
пересылает
обратно
Редкие ошибки,
критичные данные
Автоматический
редрафт
Специальный
сервис читает DLQ,
чинит сообщение,
отправляет в
основную очередь
Частые,
исправимые
ошибки (например,
не хватает поля,
можно добавить)
Оповещение
При попадании в
DLQ отправить
алерт в Telegram
Требует
немедленного
внимания
Просто удалить
сообщение
Некритичное,
битое, нет
возможности
исправить
Удаление
207

207. Dead Letter Queue (DLQ) — очередь мёртвых сообщений

Брокер сообщений RabbitMQ
RabbitMQ – приложение для работы с очередями сообщений (message-queueing), брокер
(message broker) или менеджер очередей (queue manager).
Поток сообщений в RabbitMQ
(Consumer) получатель подключается к очереди и подписывается на сообщение
которые должно обработать.
Поставщик (Producer) публикует сообщение в обработчик.
Обработчик получает сообщение и отвечает за его перенаправление.
Создается связь между обработчиком и очередью
Сообщение остается в очереди до тех пор пока не будет обработано получателем.
AMQP (Advanced Message Queuing Protocol) — открытый протокол для передачи
сообщений между компонентами системы. Отдельные подсистемы (или независимые
приложения) могут обмениваться произвольным образом сообщениями через AMQPброкер, который осуществляет маршрутизацию, возможно гарантирует доставку,
распределение потоков данных, подписку на нужные типы сообщений.
208

208. Брокер сообщений RabbitMQ

209

209.

210

210.

211

211.

Графическое представление потока сообщений
Direct exchange — используется, когда нужно доставить сообщение в определенные
очереди. Сообщение публикуется в обменник с определенным ключом маршрутизации и
попадает во все очереди, которые связаны с этим обменником аналогичным ключом
маршрутизации. Ключ маршрутизации — это строка. Поиск соответствия происходит при
помощи проверки строк на эквивалентность.
212

212.

213

213.

214.

Графическое представление потока сообщений:
Topic exchange – аналогично direct exchange дает возможность осуществления
выборочной маршрутизации путем сравнения ключа маршрутизации. Но, в данном случае,
ключ задается по шаблону. При создании шаблона используются 0 или более слов (буквы
AZ и az и цифры 0-9), разделенных точкой, а также символы * и #.
* — может быть заменен на ровно 1 слово
# — может быть заменен на 0 или более слов
215

215.

Графическое представление потока сообщений:
Headers exchange — направляет сообщения в связанные очереди на основе сравнения
пар (ключ, значение) свойства headers привязки и аналогичного свойства сообщения.
headers представляет собой Dictionary<ключ, значение>.
Если в словарь добавить специальный ключ x-match со значением any, то сообщение
маршрутизируется при частичном совпадении пар (ключ, значение). Данное поведение
аналогично оператору or.
216

216.

Графическое представление потока сообщений:
Fanout exchange – все сообщения доставляются во все очереди даже если в
сообщении задан ключ маршрутизации.
Особенности:
1) RabbitMQ не работает с ключами маршрутизации и шаблонами что положительно
влияет на производительность. Это самый быстрый exchange;
2) все потребители должны иметь возможность обрабатывать все сообщения;
217

217.

Брокер сообщений Apache Kafka
Apache Kafka — распределенный программный брокер сообщений,
поддерживающий транзакционность при работе с потребителями и
поставщиками событий.
Apache Kafka обычно используется как Event Processing System (система
обработки событий) в следующих задачах:
• интерактивный обмен данными между распределенными приложениями и
микросервисами;
• считывание информации из распределенных файловых систем ( Amazon);
• прием технологической информации
из интеллектуальных устройств;
• обработка событий из журналов
корпоративных информационных систем;
• анализ логов пользовательского
поведения на сайтах и в соцсетях.
218

218. Брокер сообщений Apache Kafka

Сообщения в Kafka не
удаляются брокерами по мере их
обработки консьюмерами — данные в
Kafka могут храниться днями, неделями,
годами.
• Благодаря этому одно и то же сообщение
может быть обработано сколько угодно
раз разными консьюмерами и в разных
контекстах.
219

219.

Из чего состоит брокер?
Broker
• Consumer
• Message
• Topic/ Partition
• Producer
220

220. Из чего состоит брокер?

221

221.

Структура данных сообщения
Каждое сообщение (event или message) в
Kafka состоит из ключа, значения,
таймстампа и опционального набора
метаданных (так называемых хедеров).
222

222. Структура данных сообщения

223

223.

224

224.

225

225.

Сообщения в Kafka
организованы и хранятся в
именованных топиках (Topics),
каждый топик состоит из одной
и более партиций (Partition),
распределённых между
брокерами внутри одного
кластера. Подобная
распределённость важна для
горизонтального
масштабирования кластера, так
как она позволяет клиентам
писать и читать сообщения с
нескольких брокеров
одновременно.
Когда новое сообщение
добавляется в топик, на самом
деле оно записывается в одну из
партиций этого топика.
Сообщения с одинаковыми
ключами всегда записываются в
одну и ту же партицию, тем
самым гарантируя очередность
или порядок записи и чтения.
Для гарантии сохранности
данных каждая партиция в Kafka
может быть реплицирована n
раз, где n — replication factor.
Таким образом гарантируется
наличие нескольких копий
сообщения, хранящихся на
разных брокерах.
226

226.

Как сообщения
распределяются по партициям
Сообщение попадает в конкретную
партицию на основе ключа (key)
1. Producer отправляет сообщение с
key = "customer_123 "
2. Брокер вычисляет:
hash("customer_123") mod
количество_партиций = 2
3. Сообщение попадает в Партицию 2
227

227. Как сообщения распределяются по партициям

Правила
Формула: partition = hash(key) MOD
partitions_count
• Все сообщения с одинаковым
ключом всегда попадают в одну и ту
же партицию и
сохраняют порядок отправки.
• Если нет ключа, то по очереди, нет
гарантии доставки.
228

228. Правила

Offset
Offset — это порядковый номер
сообщения внутри партиции
Самое первое сообщение – offset 0
• Offset уникален только внутри одной
партиции. В другой партиции тоже будут
сообщения с offset 0, 1, 2...
• Consumer сохраняет offset последнего
прочитанного сообщения. После
перезапуска он говорит Kafka: «Я
остановился на offset=100, давай
дальше».
229

229. Offset

Offset позволяет перечитать сообщения
• Offset хранится во внутреннем топике
самой Кафки (__consumer_offsets)
• Consumer сам сохраняет offset. Если
consumer не сохранил offset (упал), то
после перезапуска он использует
стратегию auto.offset.reset:
earliest — начать с самого
первого сообщения (offset=0)
latest — начать с новых
сообщений (пропустить старые)
230

230. Offset

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

231. Consumer Groups

232

232.

233

233.

Отличия. Архитектура
Kafka ориентирована на обработку потоков данных и
является распределенной системой потоковой
обработки. Подходит для сценариев, где данные
передаются между компонентами в виде непрерывных
потоков событий, а также для аналитики в реальном
времени (больше похожа на шину, чем на очередь).
RabbitMQ — это брокер сообщений, который
реализует паттерн «очереди». Он предоставляет
механизм для отправки, обработки и хранения
сообщений в виде очередей. RabbitMQ хорошо
подходит для сценариев, где необходимо
гарантировать доставку сообщений в определенном
порядке и обеспечить независимость компонентов
друг от друга.
234

234. Отличия. Архитектура

Отличия. Сохранение сообщений
Kafka сохраняет сообщения на определенное
время (или скорее на любое время в объеме,
на который хватит размера хранилища). Это
позволяет обрабатывать и анализировать
данные в любой момент времени, даже после
их передачи.
• RabbitMQ хранит сообщения в очередях до
тех пор, пока получатель их не обработает и
подтвердит. После сообщение удаляется.
235

235. Отличия. Сохранение сообщений

Отличия. Сложность настройки
Kafka может быть сложна в настройке из-за
распределенной архитектуры и
конфигураций. Решение обеспечивает более
высокую масштабируемость и
отказоустойчивость, но требует более
глубокой экспертизы провайдера услуги и
понимания нюансов работы технологии.
• RabbitMQ значительно проще в настройке и
понимании, особенно для начинающих
пользователей. БД хорошо подходит для
небольших, тестовых проектов
236

236. Отличия. Сложность настройки

Отличия. Производительность
Kafka обеспечивает высокую производительность
и низкую задержку благодаря оптимизированной
структуре хранения и обработки потоков данных.
Такая услуга представляет собой серьезное
enterprise-решение.
Считается, что RabbitMQ имеет более низкую
производительность и отказоустойчивость по
сравнению с Kafka, особенно при больших объемах
сообщений. С другой стороны, Rabbit обеспечивает
меньшее латенси при доставке сообщений,
другими словами — переварит меньше, зато
быстрее.
237

237. Отличия. Производительность

238

238.

Что надо сделать при интеграции систем
1. Проанализированы бизнес-требования. Пользовательские требования.
2. Разработаны (меж)системные функциональные требования к обмену
данными.
3. Разработаны требования к качеству передачи и обработки данных.
4. Построена диаграмма потоков данных.
5. Разработана модель данных.
6. Определена система-владелец данных.
7. Разработана таблица маппинга данных.
8. Описаны алгоритмы преобразований атрибутов.
9. Разработан сценарий интеграции в формате юскейсов.
10. Разработаны требования к журналированию интеграционных обменов.
11. Разработаны требования к конкретным вызовам, включая параметры
вызовов и ответов.
239

English Русский Rules