Добрый день!

Возможно ли в момент при создании записи в BPS при помощи деривации получить имя уровня и функции планирования?


Спасибо.

Интересно как это вы планируете создавать записи при деривации?
При деривации лишь заполняются незаполненные явно поля. И она отрабатывает после создания записи. А если вы создаете запись с помощью функции планирования типа user-exit, то там есть параметр I_PLEVEL и I_METHOD.

Вы определитесь, что вам надо-то

Да, речь идет об использовании при деривации user-exit.
На sdn.sap.com есть примеры деривации имя пользователя и времени создания записи.
А где "там" есть параметры I_PLEVEL и I_METHOD?

Для деривации имени пользователя и времени создания записи, как я понимаю, можно использовать системные поля sy-uname и sy-datum (sy-uzeit).
А в интерфейсе функции деривации
*" REFERENCE(I_AREA) TYPE UPC_Y_AREA
*" REFERENCE(ITO_CHA) TYPE UPC_YTO_CHA
*" REFERENCE(ITO_SOURCE) TYPE UPC_YTO_CHA
*" REFERENCE(ITO_TARGET) TYPE UPC_YTO_CHA

Как видите ничего здесь напоминающего уровень и функцию планирования здесь нет.

Можете попробовать пойти длинным путем введения каких-нибудь вспомогательных признаков куба в деривации для определения уровня и функции.

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

Из общих соображений понятно, что контекст выполнения где-то хранится (уровень есть например в BPS-статистике, отображается при ошибке и т.п.).
Вот где конкретно - вот в чем вопрос.

Я так понимаю Soulsurfer предложил вам добавить еще один признак в кубик, который будет чисто техническим. Заполнятся он будет юзер ексит функцией при сохранении. В значение этого признака будет писаться информация о пакете и уровне, на котором делались записи(скажем, если значение этого признака будет равна BP01, то это значит, что уровень будет BP, а пакет будет первым(01) ). Далее в деривации вы читаете значение этого признака и делаете деривацию как вам будет угодно... Извращение конечно!! Но весело.

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

Как говорится ABAP вам в помощь

ЗЫ Неделя до продуктива, тут и не такие перлы выдавать приходится

Изменение структуры кубов исключено.
Заполнение кубов, таблиц и т.п. при помощи внесения доп. функционала - исключено вдвойне.

Изменение данных осуществляется не вручную, а через запуск N-го кол-ва BPS-последовательностей. Последовательности в свою очередь состоят из N-го числа вызовов функций планирования.
Функции очень сильно зависят от настроек - N-го количества признаков и ODS.
Расчеты не всегда бывают корректными (с точки зрения ожидаемого результата), как правило из-за некорректных настроек и справочников.

Для ускорения постановки "диагноза" хотелось бы иметь механизм трассировки - в результате работы какого уровня/функции/пакета появилась та или иная запись в кубе.

Иного способа, как включить на базовых областях деривацию, которая через user-exit тащит контекст выполнения в уже существующие признаки в кубах, я пока не вижу.

А транзакция BPS_TRACE не спасает?
Есть еще RFC-трассировка... транзакцию не помню точно, но по запросу найду .

Можно еще последовательно исключать элементы из последовательности планирования, и выяснить на каком этапе появляются ошибки.
Ну или вообще выполнить вручную все последовательно используя встроенную трассировку в BPS0.

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

Я что-то не соображу, если результаты трассировки никуда записать нельзя, то что и как потом анализировать?

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

В каждом кубе уже предусмотрен признак USERNAME.
Предполагается писать туда USERNAME+PA+PF+PP.


Есть такая идея. Хотелось на все готовенькое.