Наконец-то написал функционал извлечение данных куба соединенного с ODS в нативном SELECT-е для сторнирования данных.
Жизнь налаживается...

Ммм...
А зачем?
да еще на нативном селекте?
1. Update Rules чем не проканали?
2. Open SQL чем не проканал?

Native все же опасен...

Угу, +1... Если не секрет - опишите плз Вашу ситуацию...

IMO, Nothing personal...

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

Отвечаю по порядку

Сначала о ситуации. В BW поступают данные по документу, которые сохраняются в итоге в кубе (или нескольких кубах). Документ может быть изменен, удален и т.п. и все эти изменения должны быть отражены в BW.Из внешней системы приходят не дельты, а новые данные по документу. Чтобы их сохранить надо удалить старые и загрузить новые, то есть выполнить операцию сторнирования.
Если сторнирование выполнять через ODS, то в ODS должна фиксироваться вся информация попадающая в куб. То есть практически данные в кубе и ODS идентичны + журнал обновления ODS, который конечно можно периодически чистить, но это административные расходы. К тому же, если возникнет необходимость удалить выборочно данные из куба, то надо удалять их и из ODS. Поддерживать согласование двух целей куба и ODS не слишком приятно. Если в кубе хранить ид. документа, то можно конечно воспользоваться стандартным ФМ (имя сейчас не помню, но он есть)для удаления данных из куба и ODS бы не понадобился. Однако, если документов много, то придется вызывать его многократно, передавая каждый раз несколько ид. в SELECT-OPTIONS-таблицах, чтобы не переполнить SQL-запрос. В принципе и это было бы нестрашно, но ид. документа в исходной системе составной, а в SELECT-OPTIONS парные условия задать не получится. В результате использование модуля отпадает... Я СТУПИЛ, БЛИН, ДО МЕНЯ ТОЛЬКО СЕЙЧАС ДОШЛО... я же могу склеивать поля и ПОЛУЧИТЬ ИД. ДОКУМЕНТА в ВИДЕ ОДНОГО ПОЛЯ.... и использовать стандартный ФМ удаления данных из куба по одному полю

Да, а я тут почти неделю писал свой код... а оказывается зря. Самое теперь неприятное, что написать-то я его написал, но чего теперь с ним делать???

Так что прошу прощения, сам виноват

PS: А насчет Open SQL

- ограничивается соединением не более 25 таблиц (я уже писал)

Ничего не понял. Может я туплю на конец недели, НО:



Все операции: удаление, изменение поддерживаются ОДС, параметр 0RECORDMODE, см. Хелп.




ОДС автоматически генерит нужную дельту для куба, при изменении/удалинии записи в ОДС



Зачем ?



Здесь тоже не понятно. Аналогично тому, что я описал выше.



А здесь вообще тёмный лес. Это какой же должен быть запрос, чтобы понадобилось объединение более 25-ти таблиц ?

2 RSA1 +1

2 perishkin
ИМХО если написать 25 запросов будет быстрее работать, чем объединение 25 таблиц, ибо декартово произведение 25 таблиц - жуть (с поправкой на оптимизатор, просто страшновато), поэтому, думаю 25 - это предел разумного помноженный на 2-3

2 RSA1

1.

Предположим в кубе находится три строки с данными по одному документу. Затем документ редактируют, удаляя одно из значений.
Из исходной системы в BW приходит не удаленная запись с 0RECORDMODE = D, а две записи оставшиееся, то есть новое состояние документа и именно эти две строки должны заменить три ранее сохраненные в кубе. Простой способ сделать это - удалить из
куба три строки и записать в него две пришедших (посредством полного обновления). 0RECORDMODE в данной ситуации не поможет.

2.

Поскольку данные из куба мы удалили через ФМ и залили две строки применив полное обновление никакие дельты для куба нам не нужны.


3.

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

4. см. 3

5.

Читаю куб, в котором даже на слишком много признаков... соединения куба, DIM-таблиц, SID-таблиц, атрибутов и т.п. с легкостью перекрывает число 25. BW генерит в этом случае либо Native SQL, либо временные вьюхи, а затем на базе них Open SQL.

2 g

Почитайте основы SQL. Декартово произведение!!!

Читал не раз.
Где я не прав?

http://help.sap.com/saphelp_46b/helpdat ... ameset.htm

Если join не определён - в этом случае будет декартово произведение

Это в результате оно будет без указания условий...
Но будет ли оно возникать временно (в мозгах машины), зависит от СУБД и индексов.
В любом случае, практика показывает, что лучше больше 2-5 таблиц в одном запросе не джойнить, а сделать несколько отдельных запросов.

(зря я полез в специфику исполнения объединяющих запросов, такое качественно решается только с помощью практических тестов)

Ну хорошо.

Вся проблема в том, что источник - не R/3. И кoличество позиций документа может быть различным в старой и новой версиях документа.

По-моему, гораздо проще было бы сделать цепочку сделать цепочку КУБ -> ОДС -> КУБ. При загрузке в первый КУБ установить опцию полного удаления данных перед загрузкой. Затем реализовать программу на UPDATE RULES, которая читала бы данные из ODS, и если количество позиций документа в ОДС не совпадало с количеством позиций в кубе, то анализировала бы. Если надо удалить позицию - то в DATA PACKAGE APPEND-ом можно добавить запись, где установить RECORDMODE = D.

2 RSA1

Сразу замечания. Читать данные из ODS в правилах обновления не самая удачная затея. Например данные по документу частично попадают в один пакет, а частично в другой. Сразу возникает вопрос
как читать из ODS? Добавление количества записей в DATA_PACKAGE тоже заранее неопределено. Так, при определенных условиях, можно добавить записей свыше допустимого и цепочка загрузки неожиданно даст сбой. Я как раз искал надежный способ.

1.

Загрузить данные в PSA, загрузить в ODS ид. документов из PSA. Написать ABAP-отчет и в нем просмотреть ODS и через ФМ RSDRD_DELETE_FACTS группами (по 100 штук, например) по ид. документа удалить данные из куба. Загрузить данные из PSA в куб полным обновлением. Вместо PSA можно использовать еще какой-нибудь ODS для хранения поступивших из исх. системы данных

2.

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

То есть я изобрел велосипед во втором способе, потратив много сил на реализацию извлечения куба. Можно было бы использовать стандартный модуль удаления из цели RSDRD_DELETE_FACTS (правда в этом случае придется в кубе хранить лишний склеенный ключ, например, если ключ документа состоит из DEP_ID, CALDAY, DOCTYPE, то в кубе надо будет хранить DEP_ID, CALDAY, DOCTYPE и слеенный DEP_ID, CALDAY, DOCTYPE).

Эти два метода надежнее вашего

"Элементарно, Ватсон(с)"

У нас интерфейс с APO построен на цепочках, аналогичных тем, что я описал. И записи в DATA PACKAGE добавляются без проблем.

В продуктиве год.