Hana

CAP-теорема является краеугольным камнем теории распределённых систем. Конечно, споры вокруг неё не утихают: и определения в ней не канонические, и строгого доказательства нет Тем не менее, твёрдо стоя на позициях бытового здравого смысла, мы интуитивно понимаем, что теорема верна.



Единственное, что не очевидно, так это значение буквы P. Когда кластер разделился, он решает то ли не отвечать, пока не будет набран кворум, то ли отдавать те данные, которые есть. В зависимости от результатов этого выбора система классифицируется либо как CP, либо как AP. Cassandra, например, может вести себя и так и так, в зависимости даже не от настроек кластера, а от параметров каждого конкретного запроса. Но если система не P, и она разделилась, тогда что?

Ответ на этот вопрос несколько неожиданный: CA-кластер не может разделиться.
Что же это за кластер, который не может разделиться?

Непременный атрибут такого кластера общая система хранения данных. В подавляющем большинстве случаев это означает подключение через SAN, что ограничивает применение CA-решений крупными предприятиями, способными содержать SAN-инфраструктуру. Для того, чтобы несколько серверов могли работать с одними и теми же данными, необходима кластерная файловая система. Такие файловые системы есть в портфелях HPE (CFS), Veritas (VxCFS) и IBM (GPFS).

Oracle RAC

Опция Real Application Cluster впервые появилась в 2001 году в релизе Oracle 9i. В таком кластере что несколько экземпляров сервера работают с одной и той же базой данных.
Oracle может работать как с кластерной файловой системой, так и с собственным решением ASM, Automatic Storage Management.

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

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



Но что произойдёт, если одному из экземпляров потребуется изменить данные?

Особенность Oracle в том, что у него нет выделенного сервиса блокировок: если сервер хочет заблокировать строку, то запись о блокировке ставится прямо на той странице памяти, где находится блокируемая строка. Благодаря такому подходу Oracle чемпион по производительности среди монолитных баз: сервис блокировок никогда не становится узким местом. Но в кластерной конфигурации такая архитектура может приводить к интенсивному сетевому обмену и взаимным блокировкам.

Как только запись блокируется, экземпляр оповещает все остальные экземпляры о том, что страница, в которой хранится эта запись, захвачена в монопольном режиме. Если другому экземпляру понадобится изменить запись на той же странице, он должен ждать, пока изменения на странице не будут зафиксированы, т.е. информация об изменении не будет записана в журнал на диске (при этом транзакция может продолжаться). Может случиться и так, что страница будет изменена последовательно несколькими экземплярами, и тогда при записи страницы на диск придётся выяснять, у кого же хранится актуальная версия этой страницы.

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

Правильное использование Oracle RAC физическое деление данных (например, при помощи механизма секционированных таблиц) и обращение к каждому набору секций через выделенный узел. Главным назначением RAC стало не горизонтальное масштабирование, а обеспечение отказоустойчивости.

Если узел перестаёт отвечать на heartbeat, то тот узел, который обнаружил это первым, запускает процедуру голосования на диске. Если и здесь пропавший узел не отметился, то один из узлов берёт на себя обязанности по восстановлению данных:

• замораживает все страницы, которые находились в кэше пропавшего узла;
• считывает журналы (redo) пропавшего узла и повторно применяет изменения, записанные в этих журналах, попутно проверяя, нет ли у других узлов более свежих версий изменяемых страниц;
• откатывает незавершённые транзакции.

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

IBM Pure Data Systems for Transactions

Кластерное решение для СУБД появилось в портфеле Голубого Гиганта в 2009 году. Идеологически оно является наследником кластера Parallel Sysplex, построенным на обычном оборудовании. В 2009 году вышел продукт DB2 pureScale, представляющий собой комплект программного обеспечения, а в 2012 года IBM предлагает программно-аппаратный комплект (appliance) под названием Pure Data Systems for Transactions. Не следует путать его с Pure Data Systems for Analytics, которая есть не что иное, как переименованная Netezza.

Архитектура pureScale на первый взгляд похожа на Oracle RAC: точно так же несколько узлов подключены к общей системе хранения данных, и на каждом узле работает свой экземпляр СУБД со своими областями памяти и журналами транзакций. Но, в отличие от Oracle, в DB2 есть выделенный сервис блокировок, представленный набором процессов db2LLM*. В кластерной конфигурации этот сервис выносится на отдельный узел, который в Parallel Sysplex называется coupling facility (CF), а в Pure Data PowerHA.

PowerHA предоставляет следующие сервисы:

• менеджер блокировок;
• глобальный буферный кэш;
• область межпроцессных коммуникаций.

Для передачи данных от PowerHA к узлам БД и обратно используется удалённый доступ к памяти, поэтому кластерный интерконнект должен поддерживать протокол RDMA. PureScale может использовать как Infiniband, так и RDMA over Ethernet.



Если узлу нужна страница, и этой страницы нет в кэше, то узел запрашивает страницу в глобальном кэше, и только в том случае, если и там её нет, читает её с диска. В отличие от Oracle, запрос идёт только в PowerHA, а не в соседние узлы.

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

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

Грязные, то есть изменённые, страницы могут быть записаны на диск как с обычного узла, так и с PowerHA (castout).

При отказе одного из узлов pureScale восстановление ограничено только теми транзакциями, которые в момент сбоя ещё не были завершены: страницы, изменённые этим узлом в завершившихся транзакциях, есть в глобальном кэше на PowerHA. Узел перезапускается в урезанной конфигурации на одном из серверов кластера, откатывает незавершённые транзакции и освобождает блокировки.

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

Внутренние тесты IBM на нагрузке, состоящей из 90% чтения и 10% записи, что очень похоже на реальную промышленную нагрузку, показывают почти линейное масштабирование до 128 узлов. Условия тестирования, увы, не раскрываются.

HPE NonStop SQL

Своя высокодоступная платформа есть и в портфеле Hewlett-Packard Enterprise. Это платформа NonStop, выпущенная на рынок в 1976 году компанией Tandem Computers. В 1997 году компания была поглощена компанией Compaq, которая, в свою очередь, в 2002 году влилась в Hewlett-Packard.

NonStop используется для построения критичных приложений например, HLR или процессинга банковских карт. Платформа поставляется в виде программно-аппаратного комплекса (appliance), включающего в себя вычислительные узлы, систему хранения данных и коммуникационное оборудование. Сеть ServerNet (в современных системах Infiniband) служит как для обмена между узлами, так и для доступа к системе хранения данных.

В ранних версиях системы использовались проприетарные процессоры, которые были синхронизированы друг с другом: все операции исполнялись синхронно несколькими процессорами, и как только один из процессоров ошибался, он отключался, а второй продолжал работу. Позднее система перешла на обычные процессоры (сначала MIPS, затем Itanium и, наконец, x86), а для синхронизации стали использоваться другие механизмы:

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

Начиная с 1987 года на платформе NonStop работает реляционная СУБД сначала SQL/MP, а позже SQL/MX.

Вся база данных делится на части, и за каждую часть отвечает свой процесс Data Access Manager (DAM). Он обеспечивает запись данных, кэшировние и механизм блокировок. Обработкой данных занимаются процессы-исполнители (Executor Server Process), работающие на тех же узлах, что и соответствующие менеджеры данных. Планировщик SQL/MX делит задачи между исполнителями и объединяет результаты. При необходимости внести согласованные изменения используется протокол двухфазной фиксации, обеспечиваемый библиотекой TMF (Transaction Management Facility).



NonStop SQL умеет приоритезировать процессы так, чтобы длинные аналитические запросы не мешали исполнению транзакций. Однако её назначение именно обработка коротких транзакций, а не аналитика. Разработчик гарантирует доступность кластера NonStop на уровне пять девяток, то есть простой составляет всего 5 минут в год.

SAP HANA

Первый стабильный релиз СУБД HANA (1.0) состоялся в ноябре 2010 года, а пакет SAP ERP перешёл на HANA с мая 2013 года. Платформа базируется на купленных технологиях: TREX Search Engine (поиска в колоночном хранилище), СУБД P*TIME и MAXDB.

Само слово HANA акроним, High performance ANalytical Appliance. Поставляется эта СУБД в виде кода, который может работать на любых серверах x86, однако промышленные инсталляции допускаются только на оборудовании, прошедшем сертификацию. Имеются решения HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Некоторые конфигурации Lenovo допускают даже эксплуатацию без SAN роль общей СХД играет кластер GPFS на локальных дисках.

В отличие от перечисленных выше платформ, HANA СУБД в памяти, т.е. первичный образ данных хранится в оперативной памяти, а на диск записываются только журналы и периодические снимки для восстановления в случае аварии.



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

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

Узел-координатор дублирован, поэтому в случае выхода координатора из строя в работу немедленно вступает резервный узел. А вот если выходит из строя узел с данными, то единственный способ получить доступ к его данным перезапустить узел. Как правило, в кластерах HANA держат резервный (spare) сервер, чтобы как можно быстрее перезапустить на нём потерянный узел.

Продолжаем эксперименты по установке различных SAP систем в Яндекс Облаке.

В первой части (статья была опубликована в блоге Яндекс Облака) был рассмотрена установка платформы SAP Netweaver ABAP AS, которая является основой для большинства SAP систем. В этой публикации мы перейдем от сервера приложений к уровню базы данных.

Изначально SAP Netweaver работал на широком спектре баз данных, среди которых были как принадлежащие компании SAP (SAP MaxDB, SAP ASE) так и базы данных от сторонних производителей (DB2, Oracle и MS SQL Server). Ситуация кардинально начала меняться в 2015 году с выходом SAP HANA (High-performance Analytic Appliance). Эта база данных позиционировалась компанией SAP как революционный для рынка продукт:

• обработка всех запросов осуществляется исключительно в оперативной памяти
• совмещение построчного и поколоночного хранение данных
• встроенные библиотеки PAL (Predictive Analytics Library), BFL (Business Function Library), Text Analysis, SAP HANA SQLScript и другие инструменты для подготовки данных на стороне базы данных и таким образом уменьшения обмена данными с сервером приложений.

Чтобы максимально использовать потенциал новой БД в SAP перерабатывают свою флагманскую ERP-система, которая выходит в 2015 году под названием S/4HANA и уже работает исключительно на базе SAP HANA. В последствии глубоко переработанные HANA версии появляются у других популярных продуктов хранилища данных BW (Business Warehouse) решение выходит на рынок под названием SAP BW/4HANA и у CRM-системы решение выходит на рынок под названием SAP C/4HANA.

Остальные SAP ABAP и JAVA системы, например, шина данных SAP Process Orсhestration теперь могут использовать SAP HANA, как одну из доступных для установки баз данных, наряду с Oracle, DB2 и другими.

Поскольку SAP HANA является мультиконтейнерной базой данных, типичный корпоративный SAP ландшафт выглядит следующим образом:



в этом скриношоте каждый тенант это изолированная база данных какой-либо SAP системы (SAP Process Orсhestration, SAP EWM, SAP ATTP, SAP S/4HANA и т.д) внутри одной инсталляции SAP HANA.

Со временем у SAP появились также и коммерческие продукты которые представляют собой связку веб-приложение + база данных SAP HANA.

Например, SAP Medical Research Insights. Данная система должна помочь врачам выработать правильный план лечения, опирающийся на огромный массив данных, в том числе и о генетических исследованиях.



Еще один важный момент это наличие в архитектуре SAP HANA встроенного веб сервера (SAP HANA Extended Application Service). Данный сервер имеет привилегированный доступ к базе данных и позволяет выполнять приложения на Java, Python, Node.js и множестве других языков программирования. В версии сервиса Advanced Model (XSA) в ландшафте SAP HANA появляется такой функционал, как интегрированная среда разработки с веб-интерфейсом (SAP WEB IDE), Codereview (Gerrit) планировщик зданий (SAP XS JOB SCHEDULER) и многое другое.

Архитектура SAP HANA XSA:



Появление и постоянное развитие SAP HANA требует новых знаний у администраторов и разработчиков приложений. Возможность установить и экспериментировать со своей собственной базой и средой разработки в облаке представляется в этом случае далеко не лишней.

Однако SAP HANA будет интересна не только в Enterprise-среде, и не только среди разработчиков SAP. Благодаря гибкой лицензионной политики этот продукт можно бесплатно установить и использовать, в том числе и в коммерческих целях (размер в этом случае ограничен 32 GB) Возможно приведённый ниже пример установки и использования даст идею о том какое место может занять база данных SAP HANA и SAP HANA Extended Application Service в Вашем проекте.

Шаг 1. Скачиваем установочные файлы SAP HANA

Заходим на страницу загрузки SAP HANA, express edition и если у Вас нет учетной записи в SAP необходимо пройти простую регистрацию



Скачиваем и запускаем SAP HANA Express Edition Download Manager



В Download Manager укажем следующие варианты загрузки
Платформа Linux/x86 64
Image Binary Installer
Package Applications*



* Под Applications подразумевается база данных SAP HANA, сервер приложений и среда разработки SAP HANA Extended Application Services, Advanced Model (XSA)

Шаг 2. Создаём виртуальную машину в Яндекс Облаке

На этом шаге нам понадобится следующий бесплатный софт:

• PuTTY SSH-клиент.
• PuTTYgen Генератор Public/Private ключей.
• WinSCP SFTP-клиент.

Как альтернативу для данных приложений можно также рассмотреть приложение MobaXTerm
Создадим связку Public-Private ключ с помощью PuTTYgen.



Регистрируемся / заходим в Яндекс Облако (http://personeltest.ru/aways/cloud.yandex.ru/). Переходим в раздел Compute Cloud и приступаем к созданию виртуальной машины.

Имя виртуальной машины: saphana2

Зададим подходящие характеристики ВМ. В руководстве по установке для SAP HANA Express Edition (Server + Application) видим следующие рекомендуемые параметры:



Зададим их при создании нашей виртуальной машины.

vCPU 2,
RAM 32GB,
15 GB + 150 GB, где
15 GB (загрузочный диск SSD)
150 GB (данные * HDD)

* т.к. SAP HANA все операции проводит в оперативной памяти в качестве носителя для снепшота данных мы можем выбрать более медленный HDD

В качестве операционной системы выберем последнюю стабильную ОС OpenSUSE, на момент написания статьи это версия ОС OpenSUSE 42.3



Укажем Логин и Public SSH-ключ, сгенерированный с помощью PuTTYgen

Шаг 3. Подготавливаем виртуальную машину к установке SAP HANA XSA

Находим в настройках Публичный IPv4 адрес:



Подключаемся к созданной ВМ с помощью Putty-клиента, указав в подключении публичный IPv4, заданный логин и путь к Private ключу



Подготовим файловую структуру к установке.

lsblk
vda boot диск, vdb диск, созданный под данные.



SAP рекомендует следующую файловую структуру:



/usr/sap + /usr/sap/distr 35 GB
/hana/shared/data 60 GB
/hana/shared/log 10 GB
/hana/shared 40 GB

Реализуем такую структуру с помощью утилиты fdisk:

fdisk /dev/vdb`

Проверим ещё раз структуру и создадим файловую систему ext4 на всех созданных разделах:

lsblk

mkfs.ext4 /dev/vdb1mkfs.ext4 /dev/vdb2mkfs.ext4 /dev/vdb3mkfs.ext4 /dev/vdb4

Создадим директории под дистрибутивы и базу данных SAP HANA, а также примонтируем к ним созданные на предыдущем шаге разделы. Также обновим файл /etc/fstab, чтобы монтирование восстанавливалось при перезагрузке:

mkdir /usr/sapmkdir /hanamkdir /hana/sharedmkdir /hana/shared/datamkdir /hana/shared/logmount /dev/vdb1 /usr/sapmount /dev/vdb2 /hana/shared/datamount /dev/vdb3 /hana/shared/logmount /dev/vdb4 /hana/sharedmkdir /usr/sap/distrvi /etc/fstab

Установим разрешение на папку с установочными файлами SAP:

chmod -R 777 /usr/sap/distr

Импортируем в WinSCP настройки из Putty. Подключимся к ВМ и загрузим в /usr/sap/distr архивы SAP HANA Server (hxe.tgz), SAP HANA Extended Application Services XSA (hxeesa.tgz) и shine.tgz (Учебный контент)



Распакуем архивы:

cd /usr/sap/distr tar -xvzf hxe.tgztar -xvzf hxexsa.tgztar -xvzf shine.tgz

Добавим репозиторий:

sudo zypper ar -c https://download.opensuse.org/tumbleweed/repo/oss/ openSUSE-Tumbleweed-Oss-HTTPS

Установим требуемые для работы библиотеки libstdc++, libnuma1, libatomic и libgcc_s1:

zypper install libstdc++6zypper install libatomic1zypper install libgcc_s1zypper install libnuma1

Шаг 4. Устанавливаем SAP HANA XS

Первое с чего стоит начать установку это определением понятия SID
SID (SAP System Identificator) представляет собой комбинацию трех символов и должен быть уникальным в рамках ландшафта. В рамках установки SAP HANA Express Edition значение SID по-умолчанию HXE. Предполагается, что мы не будем выбирать в качестве SID что-то другое.

Запускаем скрипт инсталляции с правами root пользователя:

cd /usr/sap/distr ./setup_hxe.sh

В меню установки требуется несколько раз нажать Enter.

Таким образом мы установим предложенные значения по умолчанию:
Дистрибутивы лежат в /distr/HANA_EXPRESS_20

SID HXE
Номер инстанции 90
Установка всех компонентов all*
* В данном случае это значит, что мы установим набор библиотек Application Function Library (AFL), куда входят Predictive Analysis Library (PAL), Business Function Library (BFL), Optimization Function Library (OFL).

Плагин SAP HANA EPMMDS предназначен для получения данных из различных OLAP источников, а подсистема расширенных сервисов (Extended Services, XS) это встроенный веб-сервер и набор различных компонентов, имеющих привилегированный доступ к базе данных.



Указываем мастер-пароль для пользователей, которые создаются во время инсталляции SAP HANA.

Поскольку мы выбрали SID HXE, adm пользователь на уровне операционной системы будет hxeadm. Указанный мастер-пароль также применится и к пользователю SYSTEM на уровне базы данных.



В процессе установки XSA потребуется также задать мастер-пароль от пользователей XSA_ADMIN, XSA_DEV, TEL_ADMIN

Процесс инсталляции.



База SAP HANA Express Edition установлена.

Шаг 5. Проверка работы SAP HANA XSA

Проверим что база данных SAP HANA установлена и работает:

su  hxeadmHDB info

Пример сервисов, которые будут запущены:



Пройдём авторизацию в SAP HANA Extended Application Services, Advanced Model:

xs-admin-login

Пользователь: XSA_ADMIN
Пароль: Мастер-пароль, который мы задали при установке
Проверим версию SAP HANA Extended Application Services, Advanced Model:

xs -v

Шаг 6. Пост-инсталляционные действия

Для того чтобы использовать веб-инструменты разработки и администрирования SAP HANA XSA необходимо отредактировать файл hosts на локальной Windows-мшине.

1. Открываем блокнот от имени Администратора

2. Открываем в блокноте файл C:\Windows\System32\drivers\etc\hosts



3. Вносим строку вида:
<внешний ip-адрес>

Шаг 7. Начало работы

Существует несколько способов администрирования и разработки для SAP HANA XSA
Администрирование: SAP HANA Cockpit. В настоящее время SAP позиционирует его, как основной инструмент управления базой данных. Также возможно управление базой данных из Eclipse (Перспектива SAP HANA Administration Console)



Разработка: Через веб-интерфейс, через инструмент SAP Web IDE или через Eclipse (Перспектива SAP HANA Development)

Поскольку HANA Cockpit и WebIDE были установлены во время процесса инсталляции именно их как средства управления и администрирования мы и будем рассматривать.

Получим url для интересующих нас приложений xsa-cockpit, webide и cockpit-web-app:

xs app xsa-cockpit --urlsxs app webide --urlsxs app cockpit-web-app --urls

Скопируем https адрес и откроем его в браузере для каждого из этих приложений.

XSA Cockpit

XSA Cockpit это браузерная система управления сервером приложений SAP HANA Extended Application Services, Advanced Model.
XSA Cockpit позволяет управлять пользователями и ролями, организациями и пространствами.
В разделе User Management можно проверить, и при необходимости назначить, для пользователя XSA_DEV роли DEVX_ADMINISTRATOR, DEVX_DEVELOPER.
В разделе Tenant Databases можно расширить возможности XSA на новый тенант, в нашем случае HXE и связать с ним пространство разработки development

HANA Cockpit

HANA Cockpit это система управления базой данных SAP HANA.

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

Скрипт регистрации ресурсов базы данных в HANA Cockpit выполняется при установке, если скрипт по каким-либо причинам не выполнился его необходимо запустить вручную до первого использования Cockpit-ом.

su  hxeadm/usr/sap/distr/HANA_EXPRESS_20/register_cockpit.sh

WebIDE

WebIDE это интегрированная с GitHub-ом браузерная среда разработки.

В разделе Development можно разрабатывать, тестировать и публиковать модули на NodeJS, Java, HTML5.

В разделе Database Explorer можно создавать и управлять объектами на уровне базы данных (таблицы, представления, хранимые процедуры и т.д).

Подключение к тенанту и обзор объектов в нём:

Шаг 8. Первое Node.js приложение

Откроем WebIDE и создадим простое UI5/Node.js приложение Hello World!

Для этого выберем
Workspace Git Clone Repository
В качестве репозитория укажем Repository github.com/basisteam-io/SAPHANAXS_helloworld.git

Таким образом мы получим копию простого приложения Hello world!, разобраться или модифицировать которое не составит никакого труда.

Установим пространство где будет развернуто данное приложение.

В нашем случае это пространство development.



Последовательно сделаем Вuild приложения и проекта.

Результатом билдинга будет .mtar файл в папке mta_archives, которая расположена в верхней части меню с иерархией проекта.

Необходимо выбрать содержащийся в папке .mtar файл и сделать для него операцию Deploy to XS Advanced.





Вернёмся к командной строке и переключимся на пространство development:

xs target -o HANAExpress -s development

Выведем список всех запущенных приложений в этом пространстве:

xs apps

Отроем наше приложение в браузере:

Заключение

Установить базу данных SAP HANA с сервером приложений HANA Extended Application Services, Advanced Model и написать своё первое приложение оказалось не сложно. В следующей статье рассмотрим более сложный пример, включающий в себя взаимодействие с базой данных SAP HANA.

Роман Горбенко, консультант SAP EWM / SAP BASIS