Ключевое понятие

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

Следующее решение предполагает облачную реализацию проекта и разработано на основе SAP HANA Cloud Platform. Рассмотрим архитектуру и основные возможности для использования бизнес-данных локальной системы в облачной вычислительной среде. Кроме того, в статье уделено внимание сквозной структуре облачного внедрения. В заключении подведем итоги по приобретенным знаниям.

Принципы работы облачных приложений

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

1. Инфраструктура как сервис (IaaS) предоставляет виртуализированные вычислительные ресурсы через сеть Интернет.
2. Платформа как сервис (PaaS) обеспечивает оборудование и программные приложения, необходимые для разработки новых приложений.
3. Программное обеспечение как сервис (SaaS) представляет собой модель лицензирования и поставки программного обеспечения, в которой программное обеспечение лицензируется по подписке и размещается централизованно.

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

Архитектура сервисов

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

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

Отказоустойчивость

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

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

Безопасность

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

Независимость от местоположения

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

Итак, я перечислил различные сервисы, которые предоставляет облачная вычислительная платформа. Различия между ними диктуют выбор конкретных сервисов для использования при реализации облачных вычислений. Теперь выделим основные структурные принципы облачных приложений. Эти элементы образуют корневую карту для проектирования приложения в облачной вычислительной среде. В следующем разделе рассматривается влияние этих элементов на процесс внедрения приложения в SAP HANA Cloud Platform1.

Проектирование и внедрение облачного решения

Пример использования: Компании требуется создать приложение, которое будет использовать данные, хранящиеся в локальной системе. Эти данные предоставляют пользователям информацию, доступ к которой они могут получить в любое время и с любого устройства через сеть Интернет. С точки зрения компании важно, чтобы приложение имело удобный и понятный интерфейс и могло быстро обрабатывать запросы пользователей. Из этого следует, что необходимо обеспечить доступность данных из локальной системы в облаке. В этом сценарии в качестве среды PaaS была выбрана система SAP HANA Cloud Platform.

Стек технологий: SAP HANA Cloud Platform является сервисом PaaS от SAP и позволяет компаниям разрабатывать, развертывать и выполнять приложения в облачной вычислительной среде. SAP HANA Cloud Platform предлагает три пакета:

• Сервисы инфраструктуры SAP HANA (IaaS) предоставляют инфраструктуру SAP HANA по подписке для компаний, которые уже имеют лицензию и хотят быстро получить работающую систему без инвестиций в оборудование.
• Сервисы базы данных SAP HANA (DBaaS) предоставляют инфраструктуру и лицензию по подписке для SAP HANA. Клиент получает собственные средства разработки: SQLScript и Extended Application Services (SAP HANA XS).
• Сервисы приложения SAP HANA (PaaS) предоставляют все возможности из пакета сервисов базы данных, а также сервисы общих приложений и возможности и средства, необходимые для разработки новых мультиклиентских облачных приложений или расширений к существующим решениям в локальных или облачных средах.

С помощью собственных средств разработки SAP HANA (SQL Script и SAP HANA XS) разработчики могут создавать бизнес-функции, выполняемые через различные устройства. Используя собственные ракурсы SAP HANA (например, аналитические ракурсы или ракурсы расчета) и переместив бизнес-логику обработки больших объемов данных на уровень базы данных, вы можете создавать интеллектуальные приложения2 полностью внутри SAP HANA.

Архитектура решения

Архитектура решения для проекта в моем примере состоит из трех уровней, созданных с помощью SAP HANA Cloud Platform:

• Уровень интеграции данных на базе SAP HANA Cloud Integration для Data Services (HCI-DS) позволяет использовать логику экстракции, трансформации и загрузки (ETL) для перемещения данных между локальными системами и SAP HANA Cloud Platform.
• Уровень управления данными и вычислений на базе SAP HANA Cloud Platform обеспечивает гибкость при проектировании схем базы данных и логики вычисления через модели SAP HANA.
• Уровень визуализации на базе SAPUI5, развернутый в SAP HANA Cloud Platform, поставляется с возможностями сервиса SAP HANA XS Engine. С помощью этого сервиса SAP HANA Cloud Platform можно разрабатывать и развертывать современные приложения HTML5 на базе библиотеки SAPUI5.

Подробнее компоненты архитектуры решения рассматриваются в следующих разделах.

Уровень интеграции данных

Первым шагом при создании архитектуры решения для приложения стал анализ локальных исходных систем и поиск оптимального способа интеграции данных из локальной системы в базу данных SAP HANA Cloud Platform. Исходная система включала в себя базу данных Oracle и веб-сервисы Simple Object Access Protocol (SOAP) для получения доступа к локальным данным. Ключевым требованием была ежедневная экстракция данных для обеспечения постоянной доступности в облачном приложении актуальных релевантных данных. Решение HCI-DS было использовано для внедрения уровня интеграции данных проекта.

Решение HCI-DS состоит из двух основных компонентов:

• веб-приложения для проектирования и календарного планирования заданий ETL;
• агент SAP Data Services (агент HCI-DS), развернутый в локальной среде организации, для выполнения заданий ETL и защищенного обмена данными с SAP HANA Cloud Platform.

Веб-приложение решения HCI-DS является средой для создания заданий ETL и управления ими. Задания ETL сгруппированы в проекты. Проект может состоять из нескольких задач. Задача состоит из одного или нескольких потоков данных, которые реализуют логику ETL для извлечения данных из источника и их загрузки в целевую систему. Можно запланировать регулярное выполнение задачи.

На рис. 1 отображается ракурс проекта веб-приложения HCI-DS. В этом ракурсе представлен список задач, присвоенных проекту, с указанием их статуса.

Рис. 1. Ракурс проекта в веб-приложении HCI-DS

Ракурс проекта веб-приложения HCI-DS можно открыть после входа в веб-приложение HCI-DS по ссылке https://hcids.hana.ondemand.com/DSoD/session/logon/<номер клиента, выбрав пункт меню Projects (Проекты).

В пользовательском интерфейсе веб-приложения HCI-DS можно изменять задачи и потоки данных, которые относятся к проекту. Логику ETL для потока данных можно проектировать с помощью перетаскивания в веб-приложении.