четверг, 7 апреля 2016 г.

WBS headshot

Нежданно отжег WBS элемент.
В общем понятно что есть внешнее, типа R.0000050.11 и внутренне представление WBS элемента, которое храниться в таблице PRPS поле PSPNR.

Все BI'щики привыкли что видеть WBS во внешнем формате - типа R.0000050.11, ну в крайнем случае R000005011 (см.сюда) PRPS-POSID & POSKI

Короче, в текущих настройках ERP у нас можно было тупо поменять внешнее представление (CJ20N). Данная операция соответственно ничего не генерировала, и только когда по потоку документов MM и FI пошли данные тут то и начался расколбас в отчетах.

Блин, 4 года никому из пользователей не приходила идея переименовать WBS элемент... Красоту решили навести :(

пятница, 29 января 2016 г.

Вкусняшка RSZTREE

Наткнулся тут на транзакцию - RSZTREE

Теперь можно красиво организовать ограниченные и вычисляемые признаки на уровне куба.

понедельник, 9 ноября 2015 г.

Виртуальные признаки и атрибуты

Попробовал тут сделать виртуальный признак с атрибутами...

В общем пока атрибуты display - всё ок
При попытке сделать атрибут навигационным - дамп при попытке выполнить отчет.

RSROA_OLAP_BADI - кстати прикольная вещь, но только в 7.3
RSR_OLAP_BADI


воскресенье, 8 ноября 2015 г.

Оптимизация запроса ABAP

[ABAP] Учимся правильно использовать FOR ALL ENTRIES IN

По мотивам статьи...

Да, сам видел в ST04N как данные куба считываются по кусочкам (по 5 значений).

Количество значений передаваемых в оператор IN регулируется настроченным параметром SAP - max_in_blocking_factor

Но чем больше параметр, тем больше нужно памяти для хранения результата.

Хинты для "локального" преодоления параметра
%_hints db2 '&max_in_blocking_factor 500&' или 
%_hints oracle '&max_in_blocking_factor 500&'

Пример:
select * from (table) appending corresponding fields of table lt_table for all entries in lt_tmp where x = lt_tmp-x
%_hints db2 '&max_in_blocking_factor 500&'.

Альтернатива - RANGE 
Вместо for all entries использовать range, но есть ньюансы:
- Если range будет содержать более 2000 строк, то он выйдет за размер SQL запроса передаваемого в базе. Результат - DBIF_RSQL_INVALID_RSQL
- т.о. возникает потребность следить за range

среда, 30 сентября 2015 г.

Сообщения в 7.30

После обновления до 7.3 обнаружился неожиданные эффект, пропали сообщения которые возвращали функции планирования на клиент (у меня вызов через BEx, в GUI всё в норме).

Поиск выдал радостную ноту - 1653610 - Planning function on the Web: Messages are suppressed которая сообщала, что да, жизнь это боль, и вообще всё сделано по просьбе трудящихся.

Due to repeated customer requests, the issuing of messages when you execute planning functions was restricted as of Release SAP NetWeaver BW 7.30. The system now issues only error messages of the type A, X, and E and the message for successful processing. Information and warnings are suppressed

Но SAP не забыл, о тех людям, которые любят когда им система пишет :)

SAP Note 1244421 describes how, for the purpose of analysis, you can also display these suppressed messages using the user parameter 'RS_DEBUGLEVEL'.

1244421 - Too many messages displayed

Ага, сказал я радостно.И поставил значение 2, ибо пользователь хотел сообщений и побольше, побольше. Хрена ответила система.

В общем, долго ли коротко, но оказалось что при значение сообщения радостной толпой возвращаются к пользователю.
Прошел до 8 - ничего не поменялось. Поставил 100 - сообщения пропали.

Да, ещё момент. Надо чтобы в Bex стояла галка - Display Messages for Troubleshootingиначе не взлетит.

И на закуску...

RRMS_MESSAGES_OUTPUT  - фм который читает сообщения из лога в BEx
RSPLFR_SERVICE_LOG_ADD - фм добавляет сообщения в лог при работе функции планирования







четверг, 24 сентября 2015 г.

Параллельная экстракция

Дано: Экстра тор на FM, без дельты - т.с. ежедневный пакет счастья. Внутри него другой FM который последовательно вызывается по материалам. Время загрузки ~ 7 часов и растет.

Идея: Используя параллельный запуск FM внутри, ускорить выборку данных.

        CALL FUNCTION 'MD_STOCK_REQUIREMENTS_LIST_API'
          STARTING NEW TASK taskname
          DESTINATION IN GROUP DEFAULT
          PERFORMING check_return ON END OF TASK

Результат.. Мимо. Оказалось что при таком вызове, курсор открытый в экстракторе, закрывается, ибо происходит COMMIT WORK. Соответственно, получаем дамп.
Да можно без курсора, но тогда не слишком красиво получается.

понедельник, 22 июня 2015 г.

raise exception CX_RSROUT_SKIP_VAL \ CX_RSROUT_SKIP_RECORD vs Rule Group

Два момента..

CX_RSROUT_SKIP_VAL: If an exception type cx_rsrout_skip_val is triggered in the routine, the target field is deleted.
В общем понятие deleted можно трактовать по разному, но если подебажить то можно увидеть что поле очищается, см. по коду:

      CATCH cx_rsrout_skip_val.
          CLEAR _G_1-/BIC/ZPRJOECT.
      ENDTRY.


CX_RSROUT_SKIP_RECORD: If a raise exception type cx_rsrout_skip_record is triggered in the routine, the system stops processing the current row and continues with the next data record.

Неожиданно CX_RSROUT_SKIP_RECORD сыграл в Rule Group. Обработка текущего Rule Group прерывалась, и переход был не к следующему Rule Group, а к следующей строке... т.е. к 1му Rule Group (Standard Group) следующей строки.

Просто пытался сделать красиво траспонирование данных, но обломался.