SAP S/4 HANA: прогнозирование изменений в среде разработки SAP

Узнайте, как появление SAP Business Suite 4 SAP HANA (SAP S/4HANA) повлияет на среду разработки SAP в ближайшие дни и месяцы.

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

SAP S/4 HANA полностью изменит среду разработки SAP: переработанная архитектура на основе SAP HANA, пользовательский интерфейс Fiori и целый ряд принципов проектирования, направленных на упрощение.

3 февраля 2015 г. компания SAP торжественно объявила о выходе системы нового поколения — SAP Business Suite 4 SAP HANA (SAP S/4HANA). В отличие от выпусков уже существовавших продуктов под новыми (и вводящими в заблуждение) именами, SAP S/4HANA — полностью новая система, которая в конечном итоге вытеснит прежние системы SAP (SAP ERP Central Component [ECC], SAP CRM и т. д.). Не будет преувеличением сказать, что выпуск SAP S/4HANA является самым значимым событием со времен появления SAP R/3 в 1992 г.

После этого объявления у сообщества SAP осталось множество вопросов. В рамках данной статьи будет раскрыт один конкретный вопрос: как выпуск SAP S/4HANA повлияет на среду разработки SAP в ближайшие месяцы и годы?

Что такое SAP S/4HANA?

Во многих отношениях SAP S/4HANA представляет собой вершину ряда стратегических инициатив, предпринятых SAP за последние семь-восемь лет. Сюда относятся: разработка SAP HANA, разработка и приобретение облачных инфраструктур, создание нового пользовательского интерфейса на основе Fiori UX, выпуск AP Business ByDesign и др. В совокупности все эти продукты, инструменты и схемы проектирования позволили SAP пересмотреть SAP Business Suite в сторону упрощения.

В следующих разделах мы рассмотрим некоторые основные особенности обновленной системы.

Технология SAP HANA в качестве основы

Как можно догадаться из названия, система SAP S/4HANA была разработана для работы исключительно с базой данных SAP HANA. Может показаться, что это уловка SAP, направленная на захват большей доли рынка баз данных, где царит высокая конкуренция. В действительности же, использование SAP HANA позволяет упросить процессы разработки. Упрощение достигается благодаря возможности SAP HANA за доли секунд обрабатывать большие массивы данных, а как следствие исключать дублирование данных (например, материализованных ракурсов и сводных таблиц) и создавать упрощенную модель данных.

Пользовательский интерфейс на основе Fiori

Так как система SAP S/4HANA была создана практически с нуля, в SAP использовали эту возможность, чтобы разработать новый пользовательский интерфейс на основе Fiori UX и SAPUI5. Забегая вперед, можно сказать, что принципы проектирования на основе Fiori будут широко применяться как к новым модулям (Core Finance), так и к приобретенным SAP облачным приложениям (SuccessFactors, Concur и Fieldglass). Помимо оптимизации пользовательского интерфейса, технология SAPUI5 обеспечивает возможность доступа с любых устройств (браузеры рабочего стола, планшеты, другие мобильные устройства).

Гибкие опции разработки

Ранее специалисты SAP определили три варианта развертывания SAP S/4HANA: в общедоступном облаке, в частном облаке, локальное развертывание. В долгосрочной перспективе SAP намеревается использовать единый код для всех трех вариантов, чтобы компании могли легко выполнять миграцию данных из локального хранилища в облако или наоборот.

Пошаговая настройка для простого развертывания

В SAP S/4HANA предусмотрена пошаговая настройка и другие варианты настройки, которые позволяют сократить время для перехода к продуктивной эксплуатации системы SAP.

Объединение в рамках Business Suite

В будущем планируется совместить связанные системы, такие как SAP CRM, SAP SCM и другие, в одном упрощенном продукте.

Поддержка отчетности и аналитики в реальном времени

Помимо упрощения модели данных, новый продукт SAP S/4HANA обеспечит прямой доступ в реальном времени непосредственно из системы оперативной обработки транзакций (OLTP). Следовательно, существуют все условия для формирования отчетности и аналитики в реальном времени непосредственно в SAP S/4HANA. При этом нет необходимости передавать данные в отдельную систему для оперативной аналитической обработки (OLAP) используя методы извлечения, преобразования и загрузки данных (ETL).

Из этого можно сделать вывод, что с технической точки зрения SAP S/4HANA является переработанной версией модуля Business Suite, развернутого в ABAP-стеке SAP NetWeaver Application Server (AS), которая работает на основе базы данных SAP HANA. Рассматривая SAP S/4HANA с этого угла, можно понять, что большая часть технических предпосылок для такой технологии существовала уже давно. Не хватало только готовности SAP объединить все технологии в одну и приступить к трудной задаче переноса более чем 400 миллионов строк кода из приложений Business Suite в новую архитектуру SAP S/4HANA. Конечно, это долгий процесс. Тем не менее, в SAP твердо намерены идти выбранным путем. Во время обсуждения стратегии продукта глава и основатель SAP Хассо Платнер так сказал о первом запуске S/4 HANA: «Если это не сработает, нам конец».

Изменения на начальном этапе

Теперь, когда вы имеете какое-то представление о SAP S/4HANA, оценим изменения и их влияние на разработчиков и поставщиков ИТ-услуг. Сначала рассмотрим краткосрочную перспективу.

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

SAP HANA – задача с множеством решений

Вычислительная платформа SAP HANA серьезно изменила ИТ-индустрию и принципы работы с Большими данными, в десятки раз сократив время их обработки. Высокая скорость работы объясняется тем, что SAP HANA является настоящей «in-memory» СУБД, все данные которой хранятся и обрабатываются непосредственно в оперативной памяти сервера. Такой дизайн СУБД предъявляет серьезные и специфические требования к используемому программному и аппаратному обеспечению. Сегодня мы поговорим о вариантах аппаратной поддержки платформы SAP HANA.

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

Технологические партнеры SAP имеют в своем продуктовом портфеле широкий набор преднастроенных решений для работы с платформой SAP HANA (appliance). Это готовые, сконфигурированные и полностью собранные по принципу “все в одном” решения. Appliance включает в себя сервер, систему хранения данных для SAP HANA, а также операционную систему. Подобные решения могут быть использованы как для продуктивных, так и для непродуктивных сред. По состоянию на март 2017 года у компании Fujitsu имеется наиболее обширный портфель appliance — 168 сертифицированных SAP решений, включая серверы на базе процессоров Intel Xeon E7-x8xxv4. Все приложения на базе HANA, работающие на appliance, обеспечиваются полноценной поддержкой со стороны SAP, в том числе и в вопросах, касающихся производительности.

Портфель решений для SAP

Если говорить о решениях класса appliance, то их можно разделить на две категории: Scale-up, рассчитанные на работу базы данных HANA на одном сервере, и Scale-out, предусматривающие работу базы на нескольких серверных узлах с общей системой хранения данных persistence layer. Помимо очевидных достоинств, у appliance есть и ряд недостатков. Во-первых, высокая стоимость для заказчика. Во-вторых, недостаточная гибкость, не позволяющая заказчику использовать уже установленную у него СХД.

Поэтому сегодня все больший интерес завоевывают другие решения — “конструкторы” из сертифицированных компонентов. Данный подход называется Tailored Datacenter Integration (TDI). Он позволяет заказчику собрать нужное решение, выбрав необходимые составляющие из списка сертифицированных продуктов. К примеру, можно приобрести только серверное оборудование, если подходящая система хранения уже имеется. Причем эта СХД может использоваться несколькими серверами HANA. Но если ответственность за работу appliance-решения целиком лежит на поставщике железа, то в случае с TDI-решением она смещается в сторону заказчика. Компания SAP никогда не проверяет и, тем более, не сертифицирует TDI-конфигурации, всю ответственность возлагая на заказчика. За дизайн такого решения отвечает он сам, либо привлеченные им консультанты. В роли последних могут выступать поставщики и разработчики аппаратного обеспечения, особенно международных компаний, поскольку последние обладают не только локальными, но и глобальными компетенциями по разработке дизайна TDI-систем. Можно сказать, что компания SAP тоже будет поддерживать TDI-конфигурацию, но при соблюдении таких условий, как использование в ее составе сертифицированных серверов, сертифицированной СХД, а также установка SAP HANA сертифицированным специалистом, либо специалистом компании-производителя данного сервера. Отклонения от рекомендованной вендором конфигурации СХД для SAP HANA допускаются, но в этом случае соответствие выдвигаемым SAP KPI по производительности находится в зоне ответственности заказчика. Конечно, достижение KPI по работе СХД не является обязательным условием для поддержки SAP HANA в целом, но может стать обязательным в случае возникновения проблем с производительностью.

Если речь идет об установке непродуктивных систем на базе HANA, то требования компании SAP будут еще мягче. Заказчик может устанавливать в сертифицированную модель сервера любые, даже младшие модели процессоров семейства Intel Xeon E7 и максимальный объем оперативной памяти. Также есть возможность использовать любую систему хранения данных со стандартной файловой системой, объем полезного пространства которой, как минимум, вдвое больше объема оперативной памяти.

Существует отдельный класс решений для SAP HANA — так называемые “поддерживаемые” серверы. В эту категорию, как правило, входят младшие модели на базе процессоров Intel Xeon E5 с объемом ОЗУ от 128 Гб до 1,5 Тб. Эти модели компания SAP не сертифицировала и не тестировала на достижение требуемого уровня производительности, однако гарантирует поддержку как непродуктивных, так и продуктивных систем на данных конфигурациях.

Насущным вопросом, особенно для продуктивных систем на платформе SAP HANA, является обеспечение отказоустойчивости. Проще всего эту задачу можно решить, используя вариант работы базы данных на нескольких серверах (Scale-out), о чем мы говорили выше. В этом случае необходимо выделить один резервный узел. В случае отказа одного из основных серверов, содержимое его памяти с общей СХД будет загружено в память резервного сервера. Если у заказчика работает Scale-up решение на базе одного сервера, рекомендуется использовать технологию HANA System Replication. Это встроенная в SAP HANA технология, предусматривающая создание копии всех данных с основного на резервном сервере. В случае отказа основного сервера возможно переключение на резервный. При этом база данных HANA может быть как уже загружена в оперативную память резервного сервера, так и быть записана на его диске. Технология HANA System Replication не обеспечивает автоматического переключения на резервный сервер. Для решения этой задачи необходимо использовать кластерный агент, который сможет реализовать автоматическое переключение в подобной ситуации. Такой кластерный агент входит в число стандартных компонентов операционной системы SUSE Linux Enterprise Server (SLES).

Резервное копирование в SAP HANA реализуется несколькими способами. Во-первых, за счет внутренних инструментов самой платформы, когда данные резервируются непосредственно на диск. Это самый недорогой и эффективный вариант. Единственный серьезный недостаток — отсутствие каких-либо средств управления жизненным циклом резервных копий. По мере потери ими актуальности администратору придется удалять устаревшие копии вручную. Второй вариант резервного копирования можно организовать с помощью специализированного ПО, в котором имеются агенты, сертифицированные для работы с SAP HANA. В этом случае резервное копирования выполняется по аналогии с бэкапом любой другой СУБД, с записью на ленточные или другие накопители, а функции управления жизненным циклом резервных копий возлагаются на специализированное ПО. Третий вариант предусматривает использование аппаратных снимков (snapshot), если оборудование их поддерживает.

Резервное копирование в SAP HANA

Системный ландшафт SAP включает в себя не только HANA, но и классические базы данных с серверами приложений. Для управления ими можно использовать решение Fujitsu FlexFrame Orchestrator, предназначенное для работы в смешанных средах, где работают продукты на SAP HANA и других платформах, таких как, например, VMware, NetApp, SUSE и другие. В состав FlexFrame Orchestrator входят аппаратные и программные компоненты, которые обеспечивают распределение ресурсов между системами и высокую доступность по целому ряду схем. Применение данного решения позволяет заказчику снизить операционные и капитальные расходы на поддержку ИТ-инфраструктуры в объеме до 50%.

Если говорить об использовании SAP HANA на виртуальных машинах, то необходимо учесть тот факт, что поддерживается только платформа виртуализации VMware vSphere, для которой также существует целый ряд ограничений. Например, для VMware vSphere 5.5 объем оперативной памяти виртуальной машины не может превышать 1 Тб, для старших версий планка выше — до 4 Тб.

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

При подготовке материала использовались источники:
https://sappro.sapland.ru/kb/articles/spj/sap-s4-hana-prognozirovanie-izmenenii-v-srede-razrabotki-sap-2.html
https://habr.com/ru/companies/fujitsu/articles/327312/