BPS: история изменений транзакционного куба.

RiTm

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

Неужто приходится "вручную" записывать данные о времени ввода и пользователе в куб?

Ярослав

RiTm написал(а):

Неужто приходится "вручную" записывать данные о времени ввода и пользователе в куб?

Так и делаем. Не вручную, конечно, а деривацией.

Soulsurfer

Когда в транзакционный куб вносятся данные, то в него ложится только дельта. Так что ответить на вопрос что вы можете, а вот кто и когда - это более сложный вопрос. Обычно считается, что каждый участник планирования отвечает за свою область данных, и только он может менять там данные. Но поскольку BPS сплошь и рядом применяют с извращениями, то и появляются такие вопросы - поэтому ABAP вам в помощь.

RiTm

Ярослав написал(а):

RiTm написал(а):

Неужто приходится "вручную" записывать данные о времени ввода и пользователе в куб?

Так и делаем. Не вручную, конечно, а деривацией.

Ярослав, спасибо за ответ. То есть заводите свои признаки в кубе, вроде "дата ввода" и "имя пользователя" и заполняете деривацией при вводе данных? В принципе, я это и имел ввиду под "вручную".

RiTm

Soulsurfer написал(а):

Когда в транзакционный куб вносятся данные, то в него ложится только дельта. Так что ответить на вопрос что вы можете, а вот кто и когда - это более сложный вопрос. Обычно считается, что каждый участник планирования отвечает за свою область данных, и только он может менять там данные. Но поскольку BPS сплошь и рядом применяют с извращениями, то и появляются такие вопросы - поэтому ABAP вам в помощь.

Soulsurfer, дельта - само собой. И разделение доступа - это правильно. Но на это нельзя полагаться для отслеживания изменений, как мне кажется. У меня всегда должна быть возможность узнать, как и когда конкретные данные попали в систему. Пользователи, как показывает практика поддержки, врут. А вот скрин из rsmo не опровергнешь.

Не считаю, что это извращение, скорее нормальная практика в любой системе.

Ярослав

RiTm написал(а):

То есть заводите свои признаки в кубе, вроде "дата ввода" и "имя пользователя" и заполняете деривацией при вводе данных?

Да, так.

Soulsurfer

RiTm написал(а):

Soulsurfer написал(а):

Когда в транзакционный куб вносятся данные, то в него ложится только дельта. Так что ответить на вопрос что вы можете, а вот кто и когда - это более сложный вопрос. Обычно считается, что каждый участник планирования отвечает за свою область данных, и только он может менять там данные. Но поскольку BPS сплошь и рядом применяют с извращениями, то и появляются такие вопросы - поэтому ABAP вам в помощь.

Soulsurfer, дельта - само собой. И разделение доступа - это правильно. Но на это нельзя полагаться для отслеживания изменений, как мне кажется. У меня всегда должна быть возможность узнать, как и когда конкретные данные попали в систему. Пользователи, как показывает практика поддержки, врут. А вот скрин из rsmo не опровергнешь.

Не считаю, что это извращение, скорее нормальная практика в любой системе.

/OFFTOPE MODE ON В нашем форуме не существует

G

Дружно читаем How to Line Items in BW-BPS / Line Items in Business Intelligence (BI) Integrated Planning (PDF 200 KB) и, если вдруг интересно How to Line Items in BW-BPS (PDF 191KB).

2 Soulsurfer (к офтопику).
Все советские привычки немцы давно переняли :lol:

, а мы как обычно, опомнились, и давай все взад возвращать

.

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

RiTm

2 G: отлично, сенкс! Теперь ясно, что стандарта нет, раз сами хаутушку написали. Зато все разжевано уже. )

Только не совсем понял, нафига генерить GUID каждый раз? Можно же по идее просто сохранять время и username.

G

RiTm написал(а):

2 G: отлично, сенкс! Теперь ясно, что стандарта нет, раз сами хаутушку написали. Зато все разжевано уже. )

Только не совсем понял, нафига генерить GUID каждый раз? Можно же по идее просто сохранять время и username.

Да, мы так и делаем, сохраняем только время и пользователя.
GUID же может быть полезен для чистки данных в кубе, тем более, что:

Цитата:

A characteristic of the type Char with length 32 without a check table or text table (for example, 0BBP_OBGUID) is suitable for this, which can be filled with a GUID (globally unique identifier) during characteristic derivation. Alternatively, this unique identification can also be achieved by pulling a number from a number range or similar techniques.

Т.е. в него можно писать все, что угодно. А по производительности, как я понял, для этого признака S-таблица не создается, правда в D-таблицу данные все равно попадут, и основная проблема при ведении логов остается -- рост измерения, по сути 1:1 получается размер таблицы фактов и таблицы измерения.

MakcuM

RiTm написал(а):

2 G: отлично, сенкс! Теперь ясно, что стандарта нет, раз сами хаутушку написали. Зато все разжевано уже. )

Только не совсем понял, нафига генерить GUID каждый раз? Можно же по идее просто сохранять время и username.

Code:

FUNCTION Z_BPS_DERIVE_USERDATETIME.
*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     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
*"  CHANGING
*"     REFERENCE(XS_CHAS) TYPE  ANY
*"  EXCEPTIONS
*"      FAILED
*"----------------------------------------------------------------------

DATA: l_uname(12)   TYPE c,
      l_datum       TYPE D,
      l_uzeit       TYPE T,
      l_timestm(14) TYPE C.

FIELD-SYMBOLS: <uname>,  <datum>, <uzeit>, <timestmp>.

ASSIGN COMPONENT 'ZUSER' OF STRUCTURE xs_chas TO <uname>.
IF sy-subrc <> 0. RAISE FAILED. ENDIF.

ASSIGN COMPONENT 'ZCHDATE' OF STRUCTURE xs_chas TO <datum>.
IF sy-subrc <> 0. RAISE FAILED. ENDIF.

ASSIGN COMPONENT 'ZCHTIME' OF STRUCTURE xs_chas TO <uzeit>.
IF sy-subrc <> 0. RAISE FAILED. ENDIF.

ASSIGN COMPONENT 'ZTIMESTM' OF STRUCTURE xs_chas TO <timestmp>.
IF sy-subrc <> 0. RAISE FAILED. ENDIF.

* derivation
l_uname = sy-uname.
<uname> = l_uname.
l_datum = sy-datum.
<datum> = l_datum.
l_uzeit = sy-uzeit.
<uzeit> = l_uzeit.
concatenate l_datum l_uzeit into l_timestm.
<timestmp> = l_timestm.

ENDFUNCTION.

Вот вам ФМ деривации. Никаких гуидов не нужно.
Всё уже украдено до вас :lol:

BPS: история изменений транзакционного куба.

Кто сейчас на конференции