• Отчетность/Reporting ;
• Разработка на ABAP/ABAP Development ;
• Извлечение, преобразование, загрузка/ETL ;
• SAP BusinessObjects Explorer/BEx ;
• SAP NetWeaver BW

Время чтения: 14 мин.

Уровень: продвинутый

Вывод в отчётную форму подробного описания значения признака – частое бизнес-требование, возникающее при реализации отчетности в BEx Analyzer. При этом зачастую заказчик никак не ограничивает длину описания, резонно считая, что если потребовалось создать подробное описание, то оно содержит важную бизнес информацию, помогающую принимать взвешенные решения.

Реализация такого требования (вывод в отчет текста произвольной длины) в SAP BW сложна, т.к. существуют технические ограничения на длину выводимого (подробного) текста – не более 60 символов (до версии SAP BW 7.4). Предлагаемое решение, обеспечивает реализацию  названного выше требования в полном объёме.

Типичные приёмы отображения длинных текстов в отчетах SAP BW

При необходимости отобразить тексты большей длины обычно прибегают к разбиению текста на несколько частей. Для этого создают нескольких дополнительных атрибутов признака, где хранятся составные части полного текста. Например, при добавлении четырех дополнительных атрибутов удается увеличить длину строки текста на дополнительные 4 ´ 60 = 240 символов. Перед выводом данных в отчет части строки объединяют, используя для этого язык VBA. Наиболее полный перечень соответствующих решений приведен на портале SCN в статье «The 60 Character Restriction for BW Data Models».

Однако такое обходное решение не позволяет решить исходную проблему – отображение текстов произвольной длины.

Примечание Начиная с версии SAP BW 7.4 SP02 длина подробного текста была увеличена до 1333 символов. Изменение было реализовано следующим образом:

• в домене RSCHAVL тип данных CHAR 60 заменен на SSTRING 1333;
• добавлена новая структура с текстами RSTXTSMXL, в которой для поля TXTLG указан элемент данных RSTXTXL определенный как SSTRING 1333.

Для более детальной информации см. ноту 1823174 «BW 7.4 changes and customer-specific programs for details».

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

Первый компонент решения

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

Второй компонент решения

Но прикрепление  документов к значениям признака необходимый но не достаточный компонент решения (проблемы). В отчетных формах, по умолчанию, текст документа не отображается. Указывается лишь наличие документов. Прикреплённых к  значению признака – перед значением признака располагается пиктограмма документа . Просмотр документов осуществляется в web-приложении в отдельном окне браузера. Переход в web-приложение доступен непосредственно из отчетной формы. Изменить стандартную функциональность позволяет применение ноты 1355233 «BExAnalyzer: display document comments as Excel comments». В результате  становится доступным отображение текста документа в примечании к ячейке со значением признака. Для удобства просмотра текст примечания можно выводить в отдельную колонку отчетной формы при помощи пользовательской функции Excel.

Третий компонент решения

Cледующий компонент решения – непосредственное извлечение текста подробных описаний. Традиционно в системе SAP ECC подробные описания документов (или других объектов) ведутся при помощи SAPscript текстов. Для каждого объекта в системе отчётов существует «собственный» текстовый объект (описание) и несколько текстовых идентификаторов, уточняющих назначение описания. Например, для документа кредитора используется текстовый объект с идентификатором BELEG, для документа закупки – EKKO. Перечень текстовых идентификаторов может быт расширен, а потому отличается от системы к системе.

Четвертый компонент решения

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

Поскольку в структуре SAP BW хранилище/источник данных для текстов SAPscript отсутствует, потребуется собственная разработка хранилища/источник данных. При инкорпорировании хранилища данных текстов SAPscript необходимо учесть и разнообразные правила формирования ключа текстового объекта.

Пятый компонент решения

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

Примечание Ведение текстовых объектов и идентификаторов осуществляется в транзакции SE75 или через ракурсы:

• V_TTXOBI – текстовые объекты;

• V_TTXIDI - ид текста.
  Для определения кода текстового объекта и идентификатора необходимо при просмотре текста в редакторе SAPscript выбрать в меню Перейти к \ Заголовок…

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

• загрузка подробных описаний из SAPscript текстов системы SAP ECC при помощи пользовательского источника данных;
• формирование документов значений признака из загруженных подробных описаний текстов. При этом длинные тексты признака не используются;
• отображение текста документа значения признака в отчете реализуется расширением стандартной функциональности установкой ноты.

Техническая реализация решения

Построение решения разбивается на следующие этапы:

• Разработка источника данных текстов SAPscript в системе SAP ECC;
• Моделирование хранилища данных и настройка потока данных в системе SAP BW;
• Разработка программы для создания документов;
• Конфигурирование функционала отображения документов в примечаниях Excel;
• Настройка отображения текстов документов в отчетных формах.

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

Разработка источника данных текстов SAPscript в системе SAP ECC

К источнику данных текстов SAPscript предъявляются следующие требования:

• Возможность фильтрации данных по типу текстового объекта, его идентификатору и коду;
• Выгрузка текстов должны производится на языке системного пользователя выполняющего экстракцию данных;
• Высокая производительность экстракции;

Заголовки текстов SAPscript хранятся в таблице STXH, строки текста – в таблице STXL. Но поскольку в таблице строк текста хранятся не сами тексты, а ссылки на записи в кластере, то невозможно создать источник данных на ракурсе таблиц STXH и STXL. По этой причине потребуется разработка транзакционного источника данных на функциональном модуле.

При разработке экстракторов для источников данных производительность играет ключевую роль. Необходимо стремиться  максимально уменьшить время экстракции, при этом извлекая только необходимый набор данных, а постобработку данных производить уже после экстракции непосредственно в системе SAP BW. Соответственно этому принципу, предъявляемые к источнику данных требования были дополнены следующими:

• условия выбора для полей текстового объекта, текстового идентификатора и ключа текста должна быть ограничены условиями «Равно» (EQ) и «Между» (BT);
• извлекались тексты напрямую из кластера при помощи по инструкции IMPORT;
  (Отказ от использования стандартного функционального модуля для чтения текстов READ_TEXT позволило сократить время экстракции в »4 раза)
• не извлекать составные компоненты ключа на стадии экстракции.
  Известные правила формирования ключей текстовых объектов использовались для определения компонентов ключа уже на этапе загрузки данных в хранилище данных

При разработке источника данных было сделано лишь одно допущение: было принято, что в документе не может быть более 999 строк текста (131 868 символов при полном заполнении строки из 132 символов).

Для реализации указанных выше требований был создан источник данных ZCA_SCR_TX_TRAN, извлекающий данных через функциональный модуль ZBC_BIW_GET_SCR_STX_TRAN со структурой экстракта ZCA_SCR_TX_LINE.

Спецификация на структуру экстракта ZCA_SCR_TX_LINE приведены в Табл. 1. Листинг функционального модуля ZBC_BIW_GET_SCR_STX_TRAN см. в приложении.

Табл. 1 Структура экстракта ZCA_SCR_TX_LINE

№	Компонент	Тип компонента	Краткое описание
1	TEXT_OBJ	TDOBJECT	Тексты: объект приложения
2	TEXT_NAME	TDOBNAME	Имя
3	TEXT_ID	TDID	Идентификатор текста
4	NUM_REC	NUM_REC	Текущий номер записи данных
5	LINE	TDLINE	Строка текста

Создание источника данных ZCA_SCR_TX_TRAN с экстракцией через функциональный модуль в SAP ECC производится стандартными средствами в транзакции RSO2. Параметры источника данных приведены в Табл. 2 и Табл. 3.

Табл. 2 Параметры источника данных ZCA_SCR_TX_TRAN

Параметр	Значение параметра
Источник данных	ZCA_SCR_TX_TRAN
Прикладной компонент	0CA
Описание	SAPscript texts
Функциональный модуль	ZBC_BIW_GET_SCR_STX_TRAN
Структура экстракта	ZCA_SCR_TX_LINE

Табл. 3 Свойства полей структура экстракта ZCA_SCR_TX_LINE источника данных ZCA_SCR_TX_TRAN

Поле	Описание	Выбор поля	Скрыть поле
LINE	Строка текста	Нет	—
NUM_REC	Текущий номер записи данных	Нет	—
TEXT_ID	Идентификатор текста	Да	—
TEXT_NAME	Имя	Да	—
TEXT_OBJ	Тексты: объект приложения	Да	—

Моделирование хранилища данных и настройка потока данных в системе SAP BW

К объекту потока данных (Рис. 1) предъявлялись следующие требования:

• Высокая производительность загрузки данных;

• Извлечение компонентов строкипо ключу текстового объекта;
• Сохранение полной строки текста с учетом регистра (при необходимости разбиение на составные части);
• Возможность использования хранилища данных текстов в ABAP отчетах.

Рис. 1 Схема потока данных

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

Длина поля LINE структуры экстракта составляет 132 символа, что больше, чем допустимая длина значения признака (60 символов), поэтому в хранилище данных были добавлены три признака с суммарной длиной, превышающей длину поля LINE. Для сохранения регистра букв для признаков был установлен соответствующий атрибут.

Примечание В описанном решении активация хранилища данных не производится, поэтому ошибок активации, связанных с недопустимыми в тексте символами, не возникает. Если ваши требования не позволяют использовать хранилище данных с оптимизацией записи, то из каждой текстовой строки необходимо удалить недопустимые символы. Сделать это можно воспользовавшись функциональным модулем ZBI_REMOVE_INVALID_CHARACTERS (см. листинг в приложении). Особенность данного функционального модуля состоит в корректной обработке всех разрешенных символов (см. транзакцию RSKC), а также высокой скорости работы за счет отсутствия посимвольной проверки входной строки

На данном этапе загрузки данных, необходимо по ключу текстового объекта извлечь его составные части. Для этого было создано дополнительно четыре признака – этого достаточно для хранения компонентов большинства текстовых объектов SAP ECC. Извлечение компонентов по ключу текстового объекта соответственно признаку производится с трансформацией полей. Для таких операций был использован тип правила «подпрограмма», т.к. это правило позволяет эффективно использовать ABAP инструкцию «CASE», в отличии от формул, где доступны только вложенные функции «IF». Были реализованы правила извлечения для 10 распространенных текстовых объектов – см. в Табл. 4. Все неизвестные текстовые объекты должны быть пропущены, с занесением информации в журнал процесса переноса данных.

Табл. 4 Перчень текстовых объектов

Текстовый объект	Описание
BELEG	Текст документа
BUT000	Деловой партнер
DOC_ITEM	Тексты позиций документа
EINE	Тексты закупочной организации
EKKO	Тексты заголовка документа закупки
EKPO	Тексты позиций документа закупки
LFB1	Поставщики
MATERIAL	Материал
VBBK	Тексты заголовка документа сбыта
VBBP	Тексты позиций документа сбыта

К процессу переноса данных из источника данных в хранилище предъявлялись следующие требования:

• Ошибки в нескольких записях (до 500 ошибочных записей) не должны проводить к остановке процесса загрузки;
• Возможность ручной обработки ошибочных записей;
• Автоматическое восстановление потока данных после загрузки данных содержащих ошибки.

Для реализации требований был создан объект хранилища данных ZCA_O01. Параметры хранилища ZCA_O01, семантический ключ и поля данных хранилища приведены в Табл.5 и Табл.6.

Табл. 5 Параметры настройки хранилища данных ZCA_O01

Параметр настройки	Значение параметра
Тип объекта хранилища данных	С оптимизацией записи
Создание SIDs	Во время отчета
Допустить двойные записи данных	Нет
Проверить дельта-непротиворечивость	Нет

Табл. 6 Группы полей хранилища данных ZCA_O01

Группа полей	Признак	Описание признака
Семантический