Ситуация.
В последнее время значительно возросли размеры баз данных.
Уже никого не удивляют размеры таблиц в десятки или даже сотни миллионов записей.
И, когда сумма, складывающаяся из этих диких количеств записей, отличается от правильной на сотые и тысячные доли процентов (например, на несколько тысяч рублей при общей сумме под миллиард), задача найти те записи, из-за которых баг, превращается буквально в «Найти иголку в стогу сена».
При этом SAP не предоставляет адекватных инструментов для тестирования.

Для новых отраслевых решений (например, для ритэйла), очень мало эталонных отчетов.
А те старые стандартные отчеты, которые есть – уже не подходят из-за возросших объемов данных (например, банально падают в дамп из нехватки памяти, при попытке просмотреть данные движений хотя бы за 1 день).

Что остается? Тупая SE16?
Даже если сделать ракурс БД – во-первых, возможности бедные (например, нет возможностей аутер джойнов и агрегатных функций), во-вторых, его еще в продуктив протащить надо.

А спецы заказчика, из смежных систем, просто ставят у себя какую-нибудь незатейливую SQL-приблуду, с помощью которой лихо напрямую коннектятся к SAP’овской базе данных, находят с помощью нее ошибки и тыкают нас, как котят.

Млин, надо че-то с этим делать.
Придумать какую-то технологию, тулзу.
Какие, на ваш взгляд, наиболее типовые баги существуют и какие технологии их поиска вы могли бы предложить? Я говорю о числовых багах в отчетах.

Есть у кого какие мысли?

У меня появилась пока только одна дельная - сделать отчет, с помощью которого можно захватить (с помощью "дальнего" FIELD-SYMBOLS) внутреннюю таблицу другой программы (например, сразу после выборки из БД), и развернуть ее для анализа (это уже отдельная тема, как анализировать).

Какая БД? Может, действительно, стоит использвать внешнюю тулу, которая смотрит напрямую в базу, строит отчеты на отдельном сервере и не нагружает рабочий сервер. OLAP Express для Oracle или MS Analisys server для MS SQLя.

Подойдет?

С Уважением,
Георгий

Да я уже последовал примеру 1С-ников заказчиков, и юзаю то же, что и они - TOAD for Oracle .
Вот и пытаюсь решить - ограничится этим (в этом подходе тоже есть свои недостатки и ограничения), или замутить что-то покруче?
Не сейчас, конечно (сейчас не до жиру, быть бы живу, обойдусь пока TOAD'ом), а на перспективу.

Использовать BW?

Или я не понял проблемы?

В теории - возможно.
На практике... мягко говоря, далеко не всегда.

Вот у вас, есть личный опыт участия в проекте, не связанном с внедрением самой BW, когда все участники (и представители заказчика, и консульты, и программеры) полноценно, эффективно и в полной мере использовали бы BW для тестирования, всех разработок?

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

Видел примеры использования BW интегрировано , с ERP так и с IS-U. Великолепно работают отчеты и числовые так и с разными значениями. При большом кол-ве данных погрешности практически не бывает. Мне кажеться для построения отчетности лучше всего подходит BW

Это больше проблема проектирования ПО. Надо сразу закладывать сверки, возможность коррекций... Данные должны быть целостными. И тот же BW или Toad - это всего лишь инструмент, а не решение.

Вот такая приблуда не подойдет?
http://www.pdm.lu/

Это и ежу понятно. Но только тестировать как-то придется в любом случае. Даже если делал мегамонстр.



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

К сожалению в подобном проекте не участвовал, зато к еще большему сожалению участвовал в проектах, где зачем-то изобретали на ABAP'е функционал аналогичный BW (к стати retail - яркий пример таких изобретений )

Если выбирать из инструментов, то ИМХО BW ставить выгоднее всего. Какая разница какой инструмент OLAP изучать и "прикручивать" к системе : BW либо иной, однако большая разница в том, что BW - родной струмент, со всеми "вытекающими".

Подожди-ка... Лягушонок - это же приблуда для управления оракулом. Типа Enterprise Manager для скуля. А есть специальные OLAP - тулы. В свое время (на 8ке и, по-моему на 9ке) для Oracle был именно OLAP Express. Хотя, все идет все меняется, возможно и в тоде что-то появилось..

Но все-таки склоняюсь к варианту с BW. Действительно, родной инструмент получше будет, я думаю. Да и икпириенс приобретешь - не лишний

С Уважением,
Георгий

Согласен с вой инструмент всегда лучше, тем более уже проверенный и надежный . Так что я за BW

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



Ну, хотелки и причуды заказчика - это отдельная большая тема, которую мне не хотелось бы сейчас поднимать.
Мой вопрос - ИНСТРУМЕНТ ДЛЯ ТЕСТИРОВАНИЯ. Чтобы перед заказчиками меньше краснеть.



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

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

Именно так
Хотя, согласен, что разворачивание BW для тестирования разработки звучит несколько смешно.

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

Ну, на правах варианта, насоздавать материализованных представлений на уровне СУБД, копирующих выборку в отчетах.
И дергать их для проверки через Native SQL.