Всем привет

Ситуация такая. Создали мы систему, оттестировали, поехали внедрять в филиал за 2 тыс км и наткнулись на грабли - Бексовые отчеты выполняются по 4 минуты с половиной. все остальное хоть и притормаживает, но не критично (5-10 секунд задержка). ВЕБ отчеты, снгенерированные из бексовых летают за 6-20 секунд. так что дело не в модели куба. Базисники разводят руками, тычут разными книжками сетуя на то что БЕКС не будет работать удаленно.

Где правда?

Не врут
Сами на это напоролись

как выворачивались??

ЗЫ. аватарка симпатичная =)), особенно глядя на сугробы за окном

У нас не стояла задача обеспечить удаленным пользователям работу с отчетами. Только демонстрация сделанного для пользователей в мск тем, которые за N тыс.км.
Совет - ведите разговор о разворачивании хотя бы продуктивного сервера там...

З.Ы. спасибо

Или пусть юзают web-отчёты.

Мы юзаем склеенные и доведенные до ума макросами рабочие книги

Покажите plz на что ссылаются базисники, нота how to или что еще?
Bex работает также, как и сама система, через одно и то же соединение, если оно у вас в принципе медленное, то не стоит ожидать от построителя отчетов, который тянет большие объемы данных быстрой работы. Тут нужно понимать что Web отчеты работают на стороне сервера. Выборка, подготовка, обработка данных происходит там (у клиента) на его сервере, вы получаете только html страницу с готовыми цифирями. Bex, в свою очередь, все массивы запрошенных данных тянет к себе, колбасит их, делает расчеты и отображает в экселе, отрабатывая при этом кучу VBA кода. Работать будет в зависимости от толщины канала.
Если ошибаюсь, поправьте.

У меня есть серьезные сомнения насчет такого утверждения.
Объем данных должен быть примерно тот же.
Т.е. передаются таблицы:
Номер комбинации признаков (10)| Имя признака (9)| значение признака (60) /(79)

Номер комбинации признаков (10)| Имя показателя (9)| значение показателя (60) / (79)

с атрибутами таблица аналогичная признаку.

т.е. 2 показателя и 300 комбинаций 3 признаков дадут:
2 * 300 * 79 + 3 * 300 * 79 = 1500 * 79 = 118 500 байт

и это маленький отчет...
дело даже не в объеме данных, а в количестве RFC-вызовов, вот тут даже не подскажу ничего.
BEx Analyzer, конечно, дебажил, но знаю о его работе слишком мало, чтобы что-то утверждать.

Повторюсь, что могу довольно уверенно сказать - BEx Analyser "лишнего" не тянет т.к. он обрабатывает результаты запроса выполненного на сервере с учетом фильтров и переменных.

И еще один момент - передаваемые данные могут быть существенно сжаты с помощью того же gzip и у SAPа возможность к RFC его прикрутить, по-моему, есть. Т.е. если причина задержки в толщине канала, разумно будет потрясти базисников.

Есть такой документик "BEx Front end Performance"




Тоже не соглашусь. =)) Куда по вашему мнению тянет бекс все данные?? на машину клиента?? миллионы записей?? и там же их обрабатывает??

Согласно доку представленному выше - количество RFC-вызовов в случае с БЕКСом - 37 какихто "предварительных" и потом на каждые 1000 строк отчета еще по 5. В случае с Вебом - не более 10 кажется (не помню точно).

Ping канала - 800 мсек. С R/3 все достаточно неплохо работают и апгрейдить канал тока ради отчетов БЕКС - расходы на которые никто не пойдет.

Проблема не в том, что бекс СОВСЕМ не работает, а в том, что работает ОЧЕНЬ медленно

Существует простой способ оттрассировать RFC Транзакция ST01.

Но суть в том, что BEx вызывает некоторую RFC-функцию и тянет внутреннюю таблицу как параметр. Вот здесь и находится bottleneck.

Я даже догадываюсь какая это функция. RRY_GRID_CMD_PROCESS

Все разумно.
37 (предварительных RFC) * 0,8 + 5 (на каждую 1000 записей) * 0,8 это
33,6 сек; злой минимум т.к.:

-- 1000 записей в один пакет сто пудов не влезет.
-- все-таки сервер обрабатывает запросы не мгновенно (т.е. 33,6 к обычному времени выполнения прибавить надо).

ЗЫ А документик интересный. Щас выверяю умозаключительные расчеты с ним.

Не совсем так... Лаг (имхо) - на RFC-вызовах (точнее на их большом кол-ве)


Да, ее интерфейс построен несколько иначе, чем объект запроса, опираясь на который я выше прикидывал объем данных (и, кстати, ошибся в длине имени IO, оно 30 а не 9). Но дело в том, что он получается не такой уж и большой. Там структура 188 байт размером. Все равно объем не тот.

OFF: Есть примеры вызова этого ФМ?

ЗЫ Кажись левелап.

Результаты выполнения запроса тянутся на машину, под обработкой имелось в виду форматирование и отображение на клиенте

Блин, я пароль забыл, чтобы в BEx открыть VBA макросы. Там все вызовы. И поиск ничего не дал. Кто-нить пароль помнит ?