21
Anand Systems
ASI
PMS
1-Way
Reservations
Certified
Implemented
Available
Anand Systems
ASI
PMS
1-Way
Profiles
Certified
Implemented
Available
Anand Systems
ASI
PMS
1-Way
Stay Revenue
Certified
Roadmap
Not Available
Anand Systems
ASI
PMS
2-Way
Rate Update
Certified
Implemented
Pilot
Anand Systems
ASI
PMS
1-Way
Allotments
Certified
Roadmap
Not Available
Anand Systems
ASI
PMS
1-Way
Inventory
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
1-Way
Reservations
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
1-Way
Profiles
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
1-Way
Stay Revenue
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
2-Way
Rate Update
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
1-Way
Allotments
Certified
Roadmap
Not Available
RoomKey
RoomKey
PMS
1-Way
Inventory
Certified
Roadmap
Not Available
WebRezPro
WebRezPro
PMS
1-Way
Reservations
Certified
Implemented
Available
WebRezPro
WebRezPro
PMS
1-Way
Profiles
Certified
Implemented
Available
WebRezPro
WebRezPro
PMS
1-Way
Stay Revenue
Certified
Roadmap
Not Available
WebRezPro
WebRezPro
PMS
1-Way
Allotments
Certified
Roadmap
Not Available
WebRezPro
WebRezPro
PMS
1-Way
Inventory
Certified
Roadmap
Not Available
LogusPMS
LogusPMS
PMS
1-Way
Reservations
Certified
Implemented
Available
LogusPMS
LogusPMS
PMS
1-Way
Profiles
Certified
Implemented
Available
LogusPMS
LogusPMS
PMS
1-Way
Stay Revenue
Certified
Roadmap
Not Available
LogusPMS
LogusPMS
PMS
1-Way
Allotments
Certified
Roadmap
Not Available
LogusPMS
LogusPMS
PMS
1-Way
Inventory
Certified
Roadmap
Not Available
Потоки данных
HAPI управляет задачами интеграции данных через потоки данных.
Поддерживаются следующие типы потоков данных:
• API потоковой передачи (уведомления о событиях)
• API команд (асинхронный запрос-ответ)
• Репозиторий API
22
Основные термины и компоненты:
• Organization — организация клиентов, которая использует HAPI, как
правило, гостиничную компанию.
• Chain — сеть отелей, определенная в HAPI организацией. Организации
могут иметь несколько цепочек, определенных в их конфигурации HAPI.
Цепочки могут использоваться для дифференциации брендов в гостиничной
компании.
• Property — собственность отеля, определенная в HAPI организацией,
принадлежащая одной сети. Недвижимость принадлежит одной цепочке. Для
гостиничных компаний с маркой недвижимости название сети устанавливается
как название гостиничной компании.
• Flow — конвейер, который определяет поток данных через набор
конечных точек.
• Kafka [5] — масштабируемая, надежная и отказоустойчивая система
публикации-подписки, используемая HAPI для потоковой передачи, обработки
и хранения данных.
• Connector — компонент адаптера, предназначенный для обработки
сообщений определенного типа с определенной внешней системой или
приложением. Разъемы могут быть производящими или потребляющими,
односторонними или двусторонними, двухтактными или двухтактными.
• Producer Connection — экземпляр Producer Connector,
сконфигурированный для извлечения данных из внешней системы в начале
потока (в зависимости от того, какой внешний соединитель системы может быть
на основе извлечения или на основе нажатия)
• Consumer Connection — экземпляр Consumer Connector, настроенный
для отправки данных в конечную точку в конце потока
• Processor — пайплайн обработки — компонент, который соединяет
одну или несколько входящих конечных точек с одной или несколькими
исходящими конечными точками в зависимости от его типа. Процессоры - это
предварительно определенные компоненты, предназначенные для решения
23
конкретной проблемы обработки — они могут иметь дополнительные
параметры конфигурации в дополнение к конечным точкам
• Репозиторий — сервис репозитория данных, предоставляемый HAPI.
Репозитории заполняются потоками данных либо в качестве целевого
соединителя, либо через потоковый процессор. Добавление репозиториев в
качестве процессоров среднего потока гарантирует, что все сообщения,
поступающие в конечную конечную точку, будут храниться в репозитории до
отправки в систему назначения. Это позволяет подключенным системам
запрашивать хранилище сразу после получения сообщения в тех случаях, когда
может потребоваться получение дополнительных данных.
API потоковой передачи (уведомления о событиях)
Потоковые потоки реализуют шаблон обмена сообщениями уведомления
о событиях в реальном времени (MEP). Такие потоки лучше всего подходят для
приложений реального времени и случаев использования, когда службы
отделены от действий пользователя. Например, потоковые потоки могут
поддерживать синхронизацию данных между системами PMS и хранилищами
данных, аналитическими платформами или приложениями CRM, которые
должны синхронизировать данные.
Потоковые процессоры (Stream Processors), которые могут быть
размещены в середине таких потоков, позволяют выполнять дополнительные
действия с данными, включая обогащение сторонними источниками, запись в
репозиторий или фильтрацию и маршрутизацию.
Потоки данных (Streaming flows) могут быть односторонними потоками
уведомлений о событиях (one-way) или двусторонними (two-way)
уведомлениями о событиях (устойчивые потоки, robust flows), когда ответное
сообщение генерируется принимающей системой и отправляется обратно через
HAPI Producer.
24
HAPI имеет возможность хранить сообщения, которые обрабатываются
потоком в хранилище данных. Таким образом, многие дополнительные бизнес-
сценарии могут быть обработаны, включая, но не ограничиваясь следующими
возможностями:
1. Загрузка и предоставление доступа к историческим данным для
сторонних систем для выполнения анализа больших данных или OLAP (онлайн-
аналитическая обработка)
2. Поддержка актуальной информации о текущих наборах данных
(резервирование, профили, инвентарь, тарифы), позволяя внешним
приложениям получать доступ к этим данным по требованию.
Доступ к репозиторию HAPI (Repository HAPI) обеспечивается через
REST API. Репозиторий имеет эластичную структуру разрешений для
преобразования данных резервирования в определенный формат и
предоставления доступа только к обязательным полям.
Потоки асинхронных запросов-ответов
Для бизнес-случаев, когда системе необходимо получить ответ для
начальной операции, HAPI предоставляет возможность конфигурировать потоки
запрос-ответ.
Полный бизнес-сценарий для потока выглядит следующим образом:
1. Если система A хочет интегрироваться с PMS, она отправляет
некоторый запрос в систему с использованием HAPI API
2. Система HAPI берет на себя ответственность за связь с системой
PMS и получает ответ от системы PMS.
Рисунок 7 Потоковый API (Streaming API) с репозиториями
25
3. Ответ переводится обратно в систему A. Он может содержать статус
операции (успех, сбой) или расширенную информацию (номер комнаты и т. д.).
Рисунок 8. Потоки асинхронных запросов-ответов
26
Полный цикл потока данных
Давайте рассмотрим полный цикл движения данных от клиента, затем
внутри HAPI платформы и далее обратно к клиенту, как представлено на схеме
Рисунок 9. Схема движения данных в платформе HAPI
Как мы видим, сообщения из PMS клиента попадают в специальный
роутер, где определяется, по какому пути будут двигаться данные внутри
платформы HAPI, затем данные передаются в соответствующего продюсера,
который их парсит и складывает в топики журналов Kafka. Затем данные
забираются сервисом Producer-converters, где данные нормализуются и
отправляются с помощью Flow-topic-decoder в сервис Flow-topics, который
27
определяет дальнейшее движение данных: они либо складываются в
документно-ориентированную базу данных MongoDB, непосредственно обратно
в PMS или CMS или в платформу, предназначенную для анализа данных,
например, Salesforce.
1.2 Характеристика комплекса задач, задачи и обоснование
необходимости автоматизации
1.2.1 Выбор комплекса задач автоматизации и характеристика
существующих бизнес процессов
Схема инфраструктуры, в которой работает платформа HAPI выглядит
следующим образом:
Рисунок 10. Схема инфраструктуры внутри частного облака AWS [3]
28
Amazon представляет сервис, который называется Elastic Container
Service [7], который позволяет запускать наши Docker [8] контейнеры в Fargate
кластере, абстрагировавшись от поддержки и обслуживания сетевой настройки,
настройки автоскейлинга и поддержки контейнерной платформы, что сильно
удешевляет процесс настройки и поставки программного обеспечения. Из
коробки ECS предоставляет достаточно много инструментов для гибкой
настройки деплоймента. Вначале необходимо создать Docker образ, в который
мы помещаем бинарные артефакты после сборки с помощью Maven [9] —
фреймворка для автоматизации сборки проектов на основе описания их
структуры в файлах на языке POM, являющемся подмножеством XML, из кода,
который написан разработчиками на языках Java и Kotlin:
Листинг сборки Docker образа
FROM alpine:3.10
ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'
LC_ALL='en_US.UTF-8'
ENV JAVA_VERSION jdk-12.0.1+12
ENV JAVA_HOME=/opt/java/openjdk \
PATH="/opt/java/openjdk/bin:$PATH"
ADD target/service-distribution/lib /usr/share/jvmservice/lib
ADD target/service-distribution/analytics-api-0.31.0.jar
/usr/share/jvmservice/service.jar
CMD java $JAVA_OPTS -jar /usr/share/jvmservice/service.jar
В примере выше мы берём Docker образ OS Alpine (я не привожу полный
листинг), устанавливаем Java 12.0.1 и затем добавляем внутрь образа артефакт,
который был создан на предыдущем шаге, в данном случае это «ADD
target/service-distribution/analytics-api-0.31.0.jar». Затем мы билдим наш образ при
помощи команды docker build, добавляем теги номера версии и хеша последнего
коммита в гите, чтобы отличать контейнеры друг от друга, и затем отправляем
образ в наше хранилище контейнеров Amazon Container Registry [10].
29
Рисунок 11. Приватное хранилище контейнеров Amazon Container
Registry [7]
Затем полученный образ нам необходимо развернуть на Elastic Container
Service [7]. Для этого нужно пойти в интерфейс ECS и добавить Task Definition.
Рисунок 12. Интерфейс добавления Task Definition
30
Рисунок 13. Конфигурирование опций запуска сервисов в Task
Definition
Здесь мы видим, что необходимо вручную заполнить много полей, что
чревато большим количеством ошибок и потерей времени.