Комментарии по теме

«Настройка фу­нкци­о­на­льно­сти обмена эле­ктро­нных сче­то­в-фа­ктур систем SAP ERP и ИС ЭСФ (ло­ка­ли­за­ция для Ка­за­хста­на)»
Артем Ляхов:
Не совсем понятно,по какой причине,стандартно настроенный журнал содержит информацию только заголовков счетов-фактур (без позиций документов), надеюсь, это будет включено в одну из следующих волн...
«Ре­ко­ме­нда­ции по обе­спе­че­нию бе­зо­па­сно­сти и контроля SAP HANA»
Дмитрий Буслов:
(1) Автор начинает с того, что HANA — это СУБД, позволяющая хранить записи в колонках и работающая в оперативной памяти. Я бы, хотел сделать акцент на том, что HANA — не просто СУБД,...
«Различие между двумя текущими версиями HANA»
Олег Точенюк:
Спасибо конечно... я вот не понимаю как консалт выживает в этом мире, когда есть такой чудесный традиционный сайт help.sap.com/ :-)

Мероприятия

Саммит по локализации решений SAP 2014 Дата проведения: 21 - 22 октября 2014 Все мероприятия
Фильтр      

Новые технологии разработки с использованием SAP HANA

Предыдущая Следующая

Для cкачивания материала, необходимо войти на сайт или зарегистрироваться.

Новые технологии разработки с использованием SAP HANA

Игорь Кашин, старший разработчик отдела локализации FI

Айрат Кугашев, старший разработчик отдела локализации FI

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

Сегодняшняя сессия была запланирована как глубокое погружение, но в результате она скорее получилась обзорной, поскольку в неё должен уместиться рассказ про большое число связанных технологий. Начнем с более подробного рассказа о SAP Fiori, точнее, не о Fiori как таковом, а о том, как выглядят Fiori приложения с точки зрения архитектуры. Потом я расскажу о тех вещах, которые помогают нам создавать приложения на Fiori: это SAP HANA Extended Application Services (XS Engine); виртуальная модель данных, являющаяся частью SAP HANA; SAP Smart Business, фреймворк, который позволяет нам быстро создавать в Fiori приложения аналитического типа, я покажу такое приложение, чтобы вы могли оценить его. Потом будет большая тема Core Data Services, которой я коснусь достаточно поверхностно: это не совсем технология сегодняшнего дня, это то, что мы будем использовать уже завтра. Мы только-только начинаем применять Core Data Services внутри компании, но скоро это будет основой многих наших новых приложений, при этом вы можете начать использовать технологию уже сегодня. После этого мы перейдем к обзору изменений, которые появились в ABAP, обсудим расширенный Open SQL и ABAP Managed Database Procedures.

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

Во вчерашнем докладе нашего главы глобализации Фероза говорилось о симплификации. Симплификация внутри SAP не означает, что мы все упрощаем, и пользователи теряют возможность решать сложные задачи. Симплификация означает, что каждый пользователь, который запускает приложение, использует определенный сценарий, соответствующий его роли в компании и, как правило, он не пользуется большей частью возможностей. Получается, что лишние возможности лишь усложняют его работу. Во Fiori функционал разделятся на приложения не только в соответствии с процессами, но и в соответствии с ролью пользователей в этих процессах, в этом и заключается ключевое отличие подхода. С точки зрения пользователя это выглядит как собственная точа запуска точка запуска для сотрудника с определённой ролью, на которой ему всё понятно и нет ничего лишнего. На сегодня уже доступно более 380 приложений, их могут использовать те, у кого установлены SAP Business Suite и SAP HANA. Среди них 116 приложений транзакционных, все остальное — аналитические и информационные. В основном они относятся к модулю финансов, но разработка продолжается, и с каждым днём SAP покрывает всё большую функциональность.

Начнем с краткого обзора архитектуры Fiori: я уже упомянул, что у нас есть разные типы приложений, направленные на разные задачи. Во-первых, это транзакционные приложения, которые служат для того, чтобы вводить информацию в систему, изменять данные какие‑то, обслуживать какие‑то процессы. Яркий пример транзакционного приложения — проводка документа. Во-вторых, у нас есть аналитические приложения, которые нам нужны, если мы хотим посмотреть на какие‑то агрегированные данные, понять общие показатели, и, возможно, иметь какой‑то путь для дальнейшего анализа. В-третьих, есть информационные приложения, или, если более точно, информационные бюллетени. Например, такое приложение может представлять собой карточку контрагента, из которой пользователь может посмотреть всю информацию о нем, перейти в какие‑то связанные с ним функции и видеть все данные в деталях. На сегодняшний день во Fiori аналитические и информационные приложения доступны только для SAP HANA.

Теперь давайте посмотрим на архитектуру этих разных типов приложений и разберемся, почему только часть работает без HANA. Самая простая архитектура у транзакционных приложений, здесь мы видим, что пользователь, используя любое устройство, удобное ему, через http-запрос обращается к front-end серверу. На front-end сервере установлен SAP NetWeaver, который, соответственно, содержит в себе библиотеки для UI5, Fiori, описания UI-приложений и шлюз, на который передается oData-запрос и, соответственно, через oData уже получается результат. Front-end-сервер взаимодействует с back-end-сервером, на котором находится бизнес-логика приложения. Back-end-сервер может работать с любой базой данных.

Когда речь заходит об аналитике, мы хотим использовать все имеющиеся преимущества HANA, а это значит, что у нас появляется другой вариант работы. В зависимости от ситуации аналитическое приложение может работать тем же путём, что и транзакционное, а может использовать SAP HANA XS Engine. Для направления запросов появляется web-диспетчер, который решает, каким способом лучше реализовать каждый конкретный запрос. Сам по себе XS Engine может содержать полностью Fiori приложение, может содержать дополнительные библиотеки. В XS Engine находится виртуальна модель данных, к тому же, например, если мы говорим о Smart Business, то этот фреймворк полностью находится в XS Engine.

Для информационных приложений также нужна HANA, поскольку для них на back-end-сервере устанавливается дополнительная модель поиска, которая обращается к SAP HANA запросами по протоколу INA.

Давайте разберёмся что такое XS Engine и за счёт чего он позволяет использовать HANA более эффективно? Название XS Engine расшифровывается как HANA Extended Application Services, он включает в себя мини-сервер приложений, мини web-сервер и платформу разработки. Физически XS Engine находится непосредственно в SAP HANA, то есть максимально близко к данным и с максимальными возможностями для бесшовной интеграции, нет дополнительных затрат на пересылку данных, а значит использование дешевле. При этом мы можем разрабатывать любые приложения, которые используют web-интерфейс и приложения, которые взаимодействуют напрямую с SAP HANA, другими словами, практически любые приложения. Кроме этого, для того, чтобы было проще писать oData сервис, существует специальное расширение под названием XS oData, позволяющее взять существующий ракурс или calculation view и объявить доступ к нему. При этом в большинстве случаев отпадает необходимость описывать правила доступа, это быстро и очень удобно.

Технологически для работы с данными в XS Engine доступны SQL, SQL-скрипт, доступен SAP HANA Calculation Engine, который позволяет делать базовые вычисления, и доступна библиотека Application Function Library (набор наиболее востребованных стандартных функций). Для того чтобы управлять потоком данных есть возможность использовать специальную модификацию XML для анализа данных и серверный javascript. Соответственно, пользовательские приложения могут использовать что угодно, но их интерфейс должен быть построен на HTML5, использовать javascript и обращаться к серверу через http-запросы, использование http и HTML5 позволяет выполнять приложения на различных устройствах.

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

Перейдем к виртуальной модели данных — VDM. VDM — очень общее название, оно не говорит о том, что это такое, но очень точно определяет, что она делает. VDM — это модель данных, теперь определимся, что такое модель данных. Бизнес-логика описывается экспертами в предметной области, но эксперты не всегда разбираются в технической стороне. Если у нас есть биолог или генный инженер, которому нужно сделать приложение, то ему придётся прийти к программисту и описать на понятном языке что нужно сделать. Проблема в том, что они с программистом говорят на разных языках и донести информацию бывает не так просто. Они оба потратят на общение кучу времени и не факт, что информация будет донесена корректно.

Так как мы хотим использовать по максимуму наших бизнес-экспертов, то заранее договариваемся о терминологии и методологии процессов, это и есть модель данных. Модели данных бывают разных типов: концептуальные, логические и физические. Концептуальная модель подразумевает, что у нас есть какие‑то очень высокоуровневые понятные конструкции, но нет технических ограничений, нет никаких требований к нормализации данных. То есть посмотрел — все понятно, но вот что к чему, как это работает ни малейшего представления. Но детальное понимание и не нужно, такие модели, как правило, предназначены для высшего руководства, людей, которым нужно видеть большую картину на высоком уровне абстракции.

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

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

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

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

Технически виртуальная модель данных устроена следующим образом: в базе данных есть физические таблицы, поверх которых выстроен частный слой (private layer), по большому счету это системные ракурсы (view), которые более-менее напрямую отображают содержимое. Поверх этого построен переиспользуемый слой (reusable layer), с которым могут взаимодействовать все те, кто стремится воспользоваться той частью виртуальной модели данных, которую поставляет SAP, именно на этом уровне объявляются бизнес-сущности, там происходят сложные объединения таблиц и ракурсов частного слоя, а на выходе получается что‑то осознанное, с названиями, которые понятны уже не только тому, кто все это делал, но и эксперту в предметной области. Поверх всего этого построен слой запросов (query layer) SAP, в котором находятся ракурсы запросов (query view), которые непосредственно достают какие‑то данные. Другими словами, стандартные запросы к модели данных формулирующие бизнес-сущности представлены в виде ракурсов запроса в слое запросов.

Часть модели поставляется SAP, но логично, что модель данных нужно расширять. Разработчики могут расширять любые запросы с переиспользуемого слоя и поверх этих расширений нужно построить свои ракурсы запросов. Данных, которые лежат в базе, бывает недостаточно для построения полноценной модели, поэтому, чтобы удобнее было потреблять эти данные, мы можем дополнять нашу модель семантическими данными, например, читаемыми заголовками. Можно добавлять туда агрегативные функции, заголовки и связи между колонками. На самом деле там очень много разных вещей — мы можем разделять наши ракурсы на пакеты, мы можем присваивать им ответственных людей, это уже более технические вещи. Если в ракурсе запроса заполнены семантические данные, то приложение сразу знает откуда можно взять дополнительную информацию.

Есть разные инструменты для того, чтобы использовать эту модель данных для дальнейшей разработки, например, SAP HANA Analytics Foundation Explorer, который поставляется вместе с SAP HANA, это инструмент, который позволяет просматривать модель данных. Он показывает все данные разделенными на категории, что упрощает процесс поиска, а также отображает любые расширения, любые дополнения, которые сделал пользователь, показывая не то, что поставил SAP, а то, что реально есть в системе в данный момент.

Разработка расширений модели данных ведется в SAP HANA Studio с использованием визуального редактора.

Фреймворк SAP Smart Business позволяет быстро создавать аналитические приложения, предназначенные для просмотра данных, полученных из системы в различных разрезах, и перехода в связанные приложения. Для примера можно взять приложение, показывающее все открытые платежи поставщикам для того, чтобы разобраться, почему они такие — либо были выплачены авансы, либо мы не выровняли платёжный документ, либо чего‑то недопоставили.

Приложения на SAP Smart Business имеют определённую структуру. Всё основано на ключевом показателе. Ключевой показатель (или KPI) — это именно то значение, которое требуется отслеживать. В приведённом примере ключевой показатель — это количество выплаченных денег. Любой ключевой параметр нужно каким‑то образом оценивать, для оценки количества выплаченных денег нужно точно знать, какой период оценивается, кому выплачены деньги, возможно необходимо выбрать каких‑то определённых поставщиков или валюты документов, и при этом определить откуда брать данные. В SAP Smart Business для этих целей заводится оценка (или Evaluation). Для каждой из оценок можно настроить виды (или Views), которые определяют каким образом данные должны отображаться — колонками, таблицей — все настраивается именно здесь. После этого к каждой оценке привязываются плитки (или Tile), которые представляют собой ярлычок, содержащий «живую» информацию. На сегодня доступно несколько видов плиток, позволяющие вывести сравнительные значения, тренд, цифру и т. д. Пользователь добавляет плитки на точку запуска и сразу же видит необходимые значения оценок ключевых показателей.

В соответствии с официальными переводами, которые можно найти в SAPterm: Ключевой показатель — это KPI, оценка — это evaluation, виды — это views, а плитки — это tiles. Для создания приложения необходимо пройти несколько этапов. Во-первых, нужно было создать ракурс запроса виртуальной модели. В идеале требуется лишь небольшое дополнение того, что уже доступно на переиспользуемом слое. Кроме этого нужно заполнить семантические данные — если мы говорим о деньгах, то мы должныуказать, где брать валюту и где брать название этой валюты и подобные значения.

После этого необходимо объявить ракурс для oData, для того, чтобы можно было обращаться к этим данным. Ракурс при использовании XS Engine объявляется в xsodata файле непосредственно в SAP HANA. Для этих целей в созданном проекте сущестует специальная папка. Для объявления сервиса необходимо указать путь и псевдоним для ракурса, описать применяемые агрегации и ключи. Так же нужно создать дополнительную сущность для передачи входящих параметров. После этого специальном графическом интерфейсе создаётся ключевой показатель и оценки. Далее конфигурируются виды — это тоже делается в графическом интерфейсе — у пользователя есть выбор что он хочет отображать, как он хочет это отображать и как необходимо фильтровать результаты. Создание плитки так же происходит в графическом интерфейсе — можно указать какой‑то подзаголовок, можно выбратьк в каком виде будут выводиться данные, а после, когда плитка создана и активирована, её можно добавлять на точку запуска пользователя. Кроме того, может понадобиться прописать доступ к плитке в роли для пользователя.

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

Из приложений Smart Business можно переходить во внешние приложения или использовать внутреннюю навигацию по разрезам. При этом в правом верхнем углу всегда доступно значение ключевого показателя.. Так же есть ряд дополнительных опций: можно поделиться результатами, либо поставить их в наблюдение добавив на точку запуска «Save as tile» (сохранить как плитку).

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

Входящие параметры для приложения настраиваются ключевым пользователем или администратором и если требуется, чтобы какой‑нибудь параметр (например, дату) пользователь указывал самостоятельно при каждом запуске, тогда, к сожалению, SAP Smart Business в текущей его версии этого сделать не позволяет, и придется разрабатывать полноценное Fiori. Фреймворк очень прост и удобен, но за такое удобство приходится расплачиваться гибкостью.

Fiori приложение способно работать с любыми данными, и с «горячими», и с «холодными», подход остаётся абсолютно таким же, как и для обычных приложений. Если мы говорим о SAP Smart Business, то по умолчанию на сегодняшний день он получит только «горячие» данные.

Давайте поговорим о том, чем мы будем пользоваться завтра, Core Data Services. Если быть кратким, это инфраструктура для определения использования модели данных в SAP HANA, то есть мы снова возвращаемся к модели данных. В CDS используются четыре языка, которые основаны на SQL, за счет этого они достаточно просты и понятны программисту. Data Definition Language служит для определения модели данных, Query Language служит для его считывания и дополнительные языки позволяютуправлять записью данных и разграничивать права доступа.

Сейчас подробнее остановимся на объявлении и получении данных из модели. Давайте представим, что работаем над информационной системой для книжного магазина и нам необходимо описать книгу как сущность. У книги есть какие‑то собственные характеристики, а есть ещё и издатель. Допустим, что мы не ведём каталог издателей, а все необходимые данные входят в описание самой книги.. Если для этих целей использовать ABAP, то можно сделать include в таблицу, но при этом в результатах запроса этот include был развернут. С использованием CDS результат запроса может иметь вложенности.

Для ведения дополнительной семантики и технической информации используются аннотации. Аннотаций огромное количество, они позволяют, например, задать тип хранения данных (колоночное или строчное), читаемое описание поля или связь между кодом валют и суммами.. Кроме того, есть понятие контекста. Определено несколько типов контекста: модуль, подмодуль, namespace, все они предназначены для одной простой цели — локализации модели данных, Например модель данных может быть использована только в определённом приложении или модуле. При создании исходной модели это редко бывает нужно, но при расширении бывает необходимо. С использованием контекстов можно расширять таблицу в ограниченной области видимости, в то время как вне контекста это расширения не будет использоваться.

Ракурс объявляется путём получения данных из сущностей.

Самое интересное, что дает CDS — это ассоциации (динамические связи). Если в VDM такая связь означала наличие JOIN сразу, при любом запросе, если оптимизатор не подумает иначе, то в случае CDS оператор JOIN будет выполнен только в случае явного обращения к необходимым данным. Ассоциации доступны как в ракурсах, так и в сущностях.

Несмотря на явные преимущества CDS и тот факт, что CDS доступен в SAP HANA уже достаточно давно, мало кто о нем знает, потому что на самом деле это основа для языка программирования River, предназначенного для быстрого программирования бизнес приложений.

Принципиальное изменение — появление подмножества HANA CDS, так называемого Open CDS, который включает в себя только ракурсы, аннотации и ассоциации, но при этом доступен на уровне сервера приложений. Необходимые объекты SAP HANA автоматически генерируются на сервере БД при активации исходного кода. По умолчанию в качетсве БД должна быть использованоSAP HANA, но теоретически есть возможность использования любой базы данных с некоторыми оговорками и ограничениями.

То есть появилась возможность использовать view с аннотациями и ассоциациями, а при можно использовать объекты ABAP словаря, и все это можно делать непосредственнона сервере приложений Самое интересное не в том, что мы можем объявить эту модель, а в том, как мы ее можем использовать. Язык запросов расширяется тремя достаточно простыми вещами, это, во‑первых, навигация через ассоциации, во‑вторых, стал доступен XPath подобный поиск, в‑третьих, появилась возможность получать не плоские результаты запроса.

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

Функциональная область : SAP HANA / SAP HANA
Ролевое назначение : SAP Консультант / Consultant, Руководитель / Manager
Ключевые слова: SAP HANA , Локализация