READ_TEXT для SAP HANA

Сейчас в моде новый продукт SAP - SAP HANA. Кто-то уже с ним сталкивался, а кому-то еще только предстоит. В моем случае он уже используется, но в качестве акселератора для ERP, т.е. стоит как вторая СУБД. По опыту скажу, что ускорение работы отчетов колоссальное. От части, конечно, это связано с переписыванием уже готовых отчетов, которые писались и дописывались разными людьми. Оптимизация ABAP кода - это тоже хороший способ добавить скорости выполнения отчету, но все равно, достаточно много времени "съедает" обращение к БД за набором данных. Этот момент хорошо ускоряет SAP HANA.
Столкнулся с проблемой, которую не может решить ABAP оптимизация, а SAP HANA может, но не понятно как - это вызов ФМ READ_TEXT. Как показывает практика, этот ФМ кушает очень много времени для получения текстов и унести его на SAP HANA можно, но сложно, отчасти из-за логики выбора текста, а от части того, что тексты в базе хранятся не текстом. Последнее решается, в любом случае, только ABAP кодом.
Итак, предлагаемое решение не идеально и, возможно, описывает только вырожденный случай, но зато хорошо показывает принцип работы.
Самое важное, что нужно знать - имя таблицы с текстами. На сколько я знаю, в большинстве случаев это STXL. Все, что нужно сделать - прочитать из нее данные и преобразовать в текст. Итак, исходник по порядку:

1. Описание данных

* Описание типа получаемых данных
TYPES: BEGIN OF gty_stxl
  , clustr TYPE stxl-clustr
  , clustd TYPE stxl-clustd
  , END OF gty_stxl.
 
* Параметр - Номер заявки
PARAMETERS: p_banfn TYPE eban-banfn DEFAULT '0010086875'.
* Параметр - Позиция заявки
PARAMETERS: p_bnfpo TYPE eban-bnfpo DEFAULT '00050'.
 
* Строка соединения с HANA DB
DATA: gv_connection TYPE STRING.
* Структура полученных данных
DATA: ls_text TYPE gty_stxl.

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

2. Подготовка параметров для выборки данных и вызова ФМ READ_TEXT

  DATA: tdobject TYPE thead-tdobject VALUE 'EBAN'.
  DATA: tdid TYPE thead-tdid VALUE 'B02'.
  DATA: tdspras TYPE thead-tdspras VALUE 'R'.
  DATA: tdname TYPE thead-tdname.
  CONCATENATE p_banfn p_bnfpo INTO tdname.

Опять же, для примера я взял уже все готовые параметры.

3. Получаем данные из SAP HANA и вызываем ФМ READ_TEXT для сравнения полученных данных

* Получаем данные
  SELECT SINGLE clustr clustd FROM stxl
    INTO ls_text
    CONNECTION (gv_connection)
    WHERE tdobject EQ tdobject
      AND tdid EQ tdid
      AND tdspras EQ tdspras
      AND tdname EQ tdname
      AND srtf2 EQ '0'
    .
 
  IF sy-subrc EQ 0.
*    Таблица с текстами
    DATA: lt_tline TYPE STANDARD TABLE OF tline.
*    Таблица с бинарными данными
    DATA: lt_stxl_raw TYPE STANDARD TABLE OF gty_shtx.
 
*    Добавляем полученную запись в таблицу
    APPEND ls_stxl TO lt_stxl_raw.
 
*    Импортируем таблицу текстов из бинарного представления в текстовое
    IMPORT tline = lt_tline FROM INTERNAL TABLE lt_stxl_raw.
 
*    Для наглядности выполним вызов READ_TEXT с теми же параметрами
    DATA lt_comm_lines TYPE TABLE OF tline WITH HEADER LINE.
    CALL FUNCTION 'READ_TEXT'
      EXPORTING
        ID       = tdid
        LANGUAGE = tdspras
        NAME     = tdname
        object   = tdobject
      TABLES
        LINES    = lt_comm_lines[]
      EXCEPTIONS
        OTHERS   = 4.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.
 
  ENDIF.

После всех манипуляций у меня получились одинаковые тексты для SAP HANA и для ФМ READ_TEXT.

Заключение

Да, на таком примере оценить скорость доступа к данным не удастся, но при наличии нескольких сотен тысяч записей, для каждой из которых вызывается ФМ READ_TEXT разница ощутима.