Ясно, интересный вариант.

Но несколько не то, - если лезем напрямую в rdbms, то это фактически мы должны алгоритм сборки отчёта с нуля написать. А хотелось бы ещё и минимизировать затраты не только на выборку, но и на дальнейшее сопровождение решения (например выдёргиваем данные из Z-отчёта, в котором логика построения аналитики может изменяться, - придётся тогда постоянно отслеживать актуальность двух алгоритмов).

То что выше пример приводил с листингами, он нам тогда локально понравился чем - один и тотже нехитрый алгоритм-вызывальщик (экстрактор по сути, в терминах биая) может вызывать и извлекать из системы Б практически любые ALV-отчёты, листинги, квери, которые на выходе (при вызове через submit) дают AbapList с плоской таблицей установленного формата. Если не требуется конечно input-представления извлекать. И при этом совершенно не важно, какой там алгоритм выборки, кто его сопровождает, как часто меняют - тупо экстрактируешь данные с листинга.

Не хватает только межсистемного интерфейса "запрос (транзакция и параметры сел.экрана)-ответ(листинг отчёта или сразу внутренняя таблица)".
И какогото единообразного подхода к впиливанию "ответа" в отчёт в системе А. Так чтобы вызывающий отчёт в системе А не только отобрал данные, но и дождался "ответа" от Б.

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

задача изначально и была про велосипед

Если речь идет, про один конкретный отчет, который показывает конкретные данные из двух систем, с четкой постановкой, то почему нет? Можно написать выборку отдельно и дергать ее. В зависимости от ситуации, допускаю, что разворачивать BI может быть не целесообразным или проблемным, компании разные бывают (кривой менеджмент, отсутствие специалистов, проблемы с финансами, отсутствие саппорта от сапа и тд). Я за использование инструментов(решений) которые наиболее соответствуют цели, но бывают разные условия

Лично, BI не разворачивал, не уже ли это так просто? Наверное как минимум нужно:
1 - решение руководства, хотя бы ИТ директора, которые понимает что у него в ландшафте появится еще одна система
2 - как минимум один специалист который хоть что-то понимает в BI
3 - какую-никакую железку под это дело и базисник(у которого в "хозяйстве" появится еще одна система, а точнее три)
4 - наверное иметь валидный entrprise support как минимум, чтобы это все выкачать и установить соответственно, даже если BI и его лицензии бесплатны.
5 - запустить туда, пользователей, и научить их минимальным действиям, хотя бы запускать отчеты, раздать полномочия соответствено и тд.

Или все намного проще?

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

В конце концов выкинут этот велосипед и сделают отчёт в bi. Уже проходили. Ну или будет велосипед с сидением в виде кола, которого все будут бояться и кривить нос.

насчёт велика - вполне возможный сценарий

А если биай - как лучше сделать сбор такого отчёта максимально user-френдли? Чтобы при минимуме телодвижений он начинал строиться без задержек?
RSA-шные транзакции пользователям раздавать? Или сбор обновлений кубика инициировать по событию, а пользователю дать только кнопку инициирования такого события?

Лучше отдать задачку бийщикам...

спасибо, Кэп

Но всётаки?