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

«Подход к выбору системы для ре­а­ли­за­ции отче­тно­сти в S/4 или BW on HANA»
Алексей Рыбин:
Добрый день, Илья! Спасибо, интересная и актуальная публикация! Совсем недавно нами проводился анализ подобного рода. Были найдены схожие с Вашими аргументы для выбора того или иного сценария. В...
«Пе­ре­стро­е­ние систем отчё­тно­сти компании «М.Видео»»
Евгений Ланцев:
"Второе, в оставшихся инфокубах мы не использовали агрегаты." Так в HANA их же и так нет?
«Пе­ре­стро­е­ние систем отчё­тно­сти компании «М.Видео»»
Александр Горбульский:
Спасибо за статью! Такой практический опыт воодушевляет.

База знаний

Методики работы с HANA-объектами в стандартном потоке данных

418

Содержание

Введение

1. Работа с графическим и скриптовыми view в RSA1

1.1. Использование виртуального куба

1.2. Использование композитного провайдера

1.3. Сравнение рассмотренных вариантов

2. Прокси-объекты ABAP словаря

2.1. Использование External View

3. Выполнение Native SQL в среде ABAP

3.1. Обращение к HANA объектам через ADBC

3.2. Обращение к HANA объектам через AMDP

3.3. AMDP в трансформациях

На правах вывода

Синопсис:

«Головокружение от успехов» после миграции BW на HANA рано или поздно проходит, и возникает вопрос – «Что дальше с этим делать?». В данной статье рассмотрены методики интеграции новых возможностей и функций SAP HANA в классическое моделирование хранилища данных для облегчения процесса разработки и построения более комплексной отчетности.

Введение

Миграция систем аналитической отчетности Business Warehouse и даже транзакционных SAP систем, таких как ERP, CRM и TM на in-memory базу данных SAP HANA на текущий момент является уже не столько «модным» трендом, сколько объективной необходимостью. Стихийно растущие объемы обрабатываемых данных и рост потребностей бизнес-заказчика в скорости отклика системы делают переход на in-memory базы данных лишь вопросом времени и готовности инвестировать в «железо».

Но вот миграция прошла успешно и естественного прироста производительности (особенно явного в OLAP системах) начинает не хватать. Кроме того, новые возможности разработки и моделирования в среде самой базы данных являются заманчивой альтернативой классической LSA архитектуре с многоступенчатыми потоками данных и тяжеловесными ABAP-обработчиками. И в этот момент возникает закономерный вопрос, как обратиться к свежесмоделированной view или хранимой БД процедуре из ABAP или инструментальных средств моделирования хранилища данных (RSA1). Возможные варианты достижения «дружбы» между HANA объектами и классическими средствами разработки BW рассматриваются в этой статье.

1. Работа с графическим и скриптовыми view в RSA1

Наиболее простым и органичным методом интеграции HANA объектов (в частности Analytic и Calculation view) является использование виртуальных кубов и (начиная с NW 7.40) композитных провайдеров для обращения. Виртуальный куб или композитный провайдер в данном случае выступают как некая прослойка между реальным провайдером данных (ракурс SAP HANA) и объектами хранилища данных, что позволяет использовать их в потоке данных для загрузки данных или для отчетности.

Первым шагом для реализации данного сценария является создание HANA ракурса (рассмотрим на примере наиболее популярного формата – графическая calculation view), которая и должна послужить источником данных для наших целей (рис. 1).

Рис. 1. Calculation view Z_CUST_COUNT.

Важно помнить, что при создании calculation view, которую планируется использовать в качестве источника для объектов хранилища данных должна иметь тип Data Category: CUBE (рис. 2) и хотя бы один определенный показатель (Measure):

Рис. 2. Data Category.

1.1. Использование виртуального куба

Общая процедура создание виртуального куба на основе HANA ракурса практически не отличается от создания «классического» инфо-куба в RSA1 (рис. 3):

Рис. 3. Создание виртуального инфо-куба.

Далее, в открывшемся окне свойств объекта нужно выбрать пункты «Virtual Provider» и «На основе ракурса SAP HANA» (рис. 4):

Рис. 4. Свойства инфо-куба.

После внесения этих настроек станет доступной кнопка «Подробно», где нужно указать пакет (или последовательность вложенных пакетов), созданного ранее calculation view и его имя (рис. 5):

Рис. 5. Ссылка на calculation view.

После чего в полученном инфо-кубе можно вручную добавить признаки и показатели, а потом указать их связь с полями HANA ракурса. Если в ракурсе, с которым ведется работа, итоговые имена атрибутов соотносятся с именами признаков и показателей, уже созданных в системе, можно воспользоваться функцией «Присвоить поля ракурсу SAP HANA» (рис. 6):

Рис. 6. Функция «Присвоить поля ракурсу SAP HANA».

В открывшемся окне будет отображен список доступных для считывания атрибутов созданного ракурса. Необходимые поля можно либо вручную отметить в поле «предложить мэппинг», либо выделить все атрибуты, для которых еще нет присвоенных признаков или показателей в виртуальном инфо-кубе (рис. 7). Поле чего системой, в соответствии с именами атрибутов, будут предложены инфо-объекты хранилища данных (рис. 8).

Рис. 7. Мэппинг полей ракурса – 1

Рис. 8. Мэппинг полей ракурса – 2.

При необходимости или при неполном соответствии именований атрибутов ракурса SAP HANA и целевого инфообъекта, он может быть добавлен вручную, а присвоение осуществлено через пункт меню «Специфические для провайдера свойства» (рис. 9-10):

Рис. 9. Меню объекта инфо-куба.

Рис. 10. Присвоение атрибута ракурса SAP HANA.

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

1.2. Использование композитного провайдера

Начиная с версии NetWeaver 7.40 среди инструментов моделирования хранилища данных стали доступны новые объекты, в т.ч. и композитные провайдеры (CompositeProvider). Этот объект предлагается как замена MultiProvider с расширенными функциями и списком доступных для объединения объектов, среди которых есть и ракурсы SAP HANA. Работа с композитными провайдерами ведется в рамках инструмента HANA Studio в BW Modeling Perspective (рис. 11):

Рис. 11. Запуск BW Modeling Perspective в HANA Studio.

BW-системы ландшафта подключаются как новые проекты типа BW Project, после чего в их рамках можно вести работу с новыми объектами моделирования хранилища данных, включая композитные провайдеры. Важно помнить, что для возможности доступа к объектам и ракурсам HANA, к BW-проекту должно быть присвоено соответствующее подключение к HANA системе (рис. 12):

Рис. 12. Присвоение HANA системы проекту.

После описанных манипуляций можно переходить к созданию самого композитного провайдера. Делается это из контекстного меню New в необходимой инфо-области BW репозитория (рис. 13):

Рис. 13. Создание CompositeProvider.

В открывшемся окне редактирования композитного провайдера на вкладке Scenario можно указать необходимые для объединения провайдеры данных. Доступны все стандартные провайдеры (DSO, Инфо-куб, инфообъекты), новые провайдеры (advanced DSO, Open ODS view, CompositeProvider) и интересующие нас ракурсы SAP HANA. Для того, чтобы добавить провайдер данных к объединению, необходимо выбрать пункт меню Add и в окне поиска указать инфопровайдер или HANA ракурс (рис. 14-15):

Рис. 14. Добавление провайдера данных в CompositeProvider – 1.

Рис. 15. Добавление провайдера данных в CompositeProvider – 2.

Указанный ракурс добавляется к объединению композитного провайдера. Возможности данного объекта позволяют также объединять несколько ракурсов в одном композитном провайдере или делать комбинированные сценарии с использованием классических провайдеров данных и HANA ракурсов.

Еще одной особенностью композитных провайдеров является то, что он позволяет возвращать данные (в т.ч. и для отчетности) без привязки к инфообъектам. Но если есть необходимость ассоциации полей композитного провайдера с существующими инфообъектами (например, для использования общего описания и настроек или доступа к атрибутам просмотра и навигации), это можно сделать на вкладке Output (рис. 16):

Рис. 16. Ассоциация полей CmpositeProvider с инфообъектами.

После активации композитного провайдера он доступен для построения отчетности или использования в дальнейшем потоке данных хранилища.

1.3. Сравнение рассмотренных вариантов

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

К преимуществам виртуального куба можно отнести функциональность автоматического мэппинга атрибутов HANA ракурса и инфообъектов, однако для ее корректной работы разработчику ракурса надо изначально вести правильное именование возвращаемых полей, т.к. поиск соответствий производится по имени и типу данных. Также к преимуществам можно отнести возможность генерации внешнего источника данных, в отличие от композитного провайдера, (если есть потребность в обращении к данным ракурса из внешних систем) и более привычный интерфейс работы в SAP GUI.

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

2. Прокси-объекты ABAP словаря

Перечисленные выше варианты доступа к данным из ракурсов SAP HANA удобны для классических задач построения отчетности или загрузки данных в рамках потока данных, однако они не решают задачи доступа к данным из HANA ракурсов из ABAP. В виду некоторых ограничений функциональности графического редактора или SQL Script не всегда предоставляется возможность полностью вынести все расчеты на уровень SAP HANA, и тогда предварительно сформированные в ракурсе данные требуется дополнительно обработать средствами разработки ABAP. Для этого можно использовать прокси-объект ABAP словаря – External View.

2.1. Использование External View

ABAP External View является оберткой над HANA ракурсом на уровне ABAP словаря. Она доступна для просмотра в транзакциях SE16/SE11 и для обращения к ней на OpenSQL. Создания и работа с прокси-объектами и external view ведется в HANA Studio в ABAP Perspective (рис. 17):

Рис. 17. Запуск ABAP Perspective в HANA Studio.

По аналогии с работой в BW Perspective, системы ландшафта подключаются как новые проекты, только в данном случае уже как ABAP Project. После создания подключения к необходимой системе в System Library становится доступен список всех созданных в системе пакетов. Для создания external view из контекстного меню выбранного пакета нужно выбрать New -> Other ABAP Repository Object (рис. 18):

Рис. 18. Создание нового ABAP объекта в HANA Studio.

В списке доступных объектов в папке Dictionary нужен объект Dictionary View (рис. 19):

Рис. 19. Выбор объекта Dictionary View.

В свойствах создаваемого объекта отмечаем, что это External View и в поле HANA View указываем имя HANA ракурса с указанием пакета, в котором он находится (рис. 20):

Рис. 20. Свойства External View.

Важное замечание – имена атрибутов HANA ракурса, для которого делается external view, должны начинаться с букв. Спец. символы и цифры не допустимы, т.к. имена поле в external view в ABAP словаре копируются с имен атрибутов ракурса и не должны вступать в противоречие с правилами именования ABAP структур.

После создания external view он становится доступен в ABAP словаре (рис. 21) и к нему можно обратиться в коде.

Рис. 21. External View в ABAP словаре.

Важной особенностью external view является отсутствие присвоения элементов данных ABAP словаря к атрибутам ракурса. Это может вызвать ошибки при попытках создания экстракторов на базе external view. Также при выводе неформатированных результатов в ALV буду отсутствовать заголовки столбцов и свойства выводимых элементов (рис. 22):

Рис. 22. Пример вывода в ALV таблицы типа Z_PROXY_TAB.

Пример считывания и вывода данных из external view:

DATA: lc_alv  TYPE REF TO cl_salv_table.
DATA: lv_text TYPE string.
DATA: lc_msg  TYPE REF TO cx_salv_msg.
DATA: lt_prx TYPE TABLE OF z_proxy_tab.

SELECT * FROM z_proxy_tab INTO CORRESPONDING FIELDS OF TABLE lt_prx
  WHERE country = 'DE'.

  IF sy-subrc = 0.
    TRY.
        cl_salv_table=>factory(
            IMPORTING
              r_salv_table = lc_alv
            CHANGING
              t_table      = lt_prx ).
        lc_alv->display( ).
      CATCH cx_salv_msg INTO lc_msg.
        lv_text = lc_msg->get_text( ).
        MESSAGE lv_text TYPE 'E'.
    ENDTRY.
  ENDIF.

В случае внесения

Ограниченный доступ

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


Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»