Коллеги, кто-то решал задачу следующим образом: построить систему отчетности на BW, но данные не закачивать с R/3 периодически, а забирать их оттуда по запросу при выполнении отчета или вообще не забирать, а просто формировать отчет на каких-то промежуточных структурах?

Если делали, то как, хотя бы в общих чертах

На мой взгляд какое-то странное решение. Зачем тащить данные в BW из R/3 в момент выполенния программы, если можно сразу в R/3 показать этот отчет. Смысл реализации хранилища в BW? А на структурах вообще непонятно. Поясните пожалуйста.

В общих чертах это удаленный инфокуб на стороне R3
При выборке данных получите тормоза в исходной системе.

Просто в BI достаточно удобно и быстро можно строить отчеты, а в R/3 - это более трудоемко, но транзакционные данные хочется смотреть сразу

Можно было бы сразу в GUI дать доступ к отчетам BW и не делать грандиозных ABAP-разработок, сразу выдавать отчет в удобоваримом виде, причем любой и быстро

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

лучше так не делать. дистанционные кубы надо использовать только в крайнем случае - иначе сдохнет r\3

- Вы слишком оптимистичны.

В NW2004s - это предлагается делать с помощью FM - и называется технология Direct Access (если не ошибаюсь)

да, ещё учтите, что на ВАС...
- останеться проблема с актуальностью мастер-данных (В NW2004s - они предлагают решение)
- проблема корректности транзакционных данных*

* правда, если смотреть только в одну таблицу, без связки с другими, такой проблемы не будет... Но аппетит приходит во время еды...

Может Вам подумать о Crystal Report's или BO ?

Если я не ошибаюсь, то для получения свежих данных делают так:
1. Делается обычный куб BI, в который закачиваются (например по ночам) данные из R/3
2. Делается дистанционный куб BI, который получает данные за текущий день.
3. Отчеты строятся на мультикубе из двух вышеперечисленных.

именно так по уму и делается, однако если объем "свежих" данных велик, то системе придет кирдык. То есть если отчет агрегированный и для формирования одной строки необходлимо "лопатить" ( агрегировать) тысячи "свежих" документов, то тогда р3 ляжет. К тому же есть еще одни грабли - если в момент выполнения отчета ихоная систиема нагружена - ну например идет закрытие, то можно не дождаться ответа, так как все фоновые процессы будут заняты . А еще грабли - если в исхоной системе ввели в справочник новую запись ( например контрагент) и по нему провели документы, а вы пытаетесь по этим данным пострить отчет - то из за того, что в BW не обновлен справочник, то будет ошибка. Значит надо еще и думать об on-line синхронизации справочников

В общем на мой взгляд это достаточно стремное дело. так как рисков больше чем выгод.

Да, это решение не для больших объемов данных.


О как...
Я думал, что такое начинается с 100 000 - 1 000 000 записей.
Поскипано...

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

Зависит от задачи... Возможность есть...
Но в целом согласен -- применять надо хорошо подумав.

"тысячи" это образно. Для одной системы и 1000 записей будет достаточно, для другой и лимон - не проблема

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

Я призываю к тому, чтобы данный механизм ипользовался только после серьезных размышлений и оценок. Зачастую многие подобные "хотелки" закрываются отчетами в R/3. Очень редко _действительно_ нужно формирования отчета в Хранилище в режиме on-line - то есть если это оправдано бизнесом и необходимостью для принятия решения, а не являются закидонами какого нибудь дурного пользователя.

Вот и я думаю, как же надо написать запрос, чтобы обработка 1000 записей завалила n-процовый сервак


безусловно