Пвиветствую, хотел поинтересоваться у сообщества, как делали перенос в продуктив наработок BW когда запросов очень много?
p.s.: Имеется 580 запросов в тесте

Сочувствую..

В ручную, исключительно по очереди. Анализируя результаты каждого запроса. Потому как частенько в больших запросах бывают различные варианты. Гарантировано запрос упадет, когда в нем содержится как правило обновление, так и отдельные ФМ с сылкой на структуру переноса. Гарантировано навернется запрос когда в нем содержится экстарктор и поток данных для загрузки из "самой себя". И так неспешно постепенно переносить

Для переноса в продуктив n-го количества запросов заранее составлялся план переноса (по результатам переноса в тест) для ускорения данной процедуры.
Что-то вроде:
Запрос1, Запрос2, Запрос3 - одновременно
Запрос4 - 2 раза
и т.д.

угу. но тогда для запрос4 надо так:
перенос
тиражирование
перенос

только для этого надо четко составлять и продумывать порядок помещения объектов в запросы... тогда и планировать будет легче. в противном случае - планирование по трудоемкости будет равно половине работы по переносу....

а так - согласен с автором. планирование при таких объемах нужно.

У нас проблема периодически возникала при переносе трансформаций. Запрос ложился после повторного импорта.


Именно так и поступали, по крайней мере стремились к недостижимому идеалу.

Ок, собственно пришел к тому же...
Ради интереса попробовал поставить все запросы сразу - нифига путевого не вышло часть трансформаций и ППД просто отсутствуют.
А скопировать продуктив из теста заказчик отказался придется теперь по очереди ставить все это безобразие...

Касательно проблемы тиражирования, упомянутой уважаемым BW - ником.
Тиражирование приводит к изменению источников данных, но не помещает измененные объекты в запрос на перенос.
Чтобы не заниматься тиражированием в тесте и продуктиве в промежутках между импортом запросов, источники данных после тиражирования ручками добавлялись в запросы через связь с переносом.

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

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

А что мешает сделать следующий финт ушами: закидываем все запросы в один, делаем его уплотнение и удаление в нем дубликатов. Потом начинаем этот запрос резать на части в новые запросы в порядке очереди:
1) только инфо-объекты
2) ODS (DSO), кубы, структуры переноса, связи и т.д. - т.е. все, что создает объекты ABAP Dictionary
3) Все абаповские разработки (ФМы, группы функций, инклюды)
4) Потом далее по потоку загрузки даннных (источники данных, правила переноса, правила обновления и т.д.)
5) bex-запросы
6) рабочие книги, вебовские приблуды.

Это грубое описание (возможны нюансы для конкретной реализации), но думаю идея понятна.

Для этого необходимо иметь как минимум открытую для изменения тестовую систему чтобы по новой все не тащить с разработки, по факту тест часто закрывают от любых изменений.

Ну понятно, что проблемы с системным ландшафтом должны решаться в контакте с базисниками. Телодвижения, которые должны делать биви-консультанты, я описал. Добиваться выполнения этих задач нужно с привлечением специалистов по другим областям.

Навскидку варианты:
1) сделать копию тестовой системы на время и все резки-склейки делать там
2) все-таки открыть систему для изменения для подготовки этих транспортов, а потом закрыть

В любом случае - это уже административные проблемы, а не технические.

Надо пытаться тащить всё вместе, потом дотаскивать неактивное новыми запросами. Один человек сидит на продуктиве, мониторит запросы и неактивные объекты, шлет информацию по группе, остальные формируют запросы и дотаскивают неактивное. Процесс медленный, кропотливый, нервный. В зависимости от объема объектов в хранилище процесс займет 3-х дней, до 2-х недель.
Видел "деятелей", которые тащили всё, потом отдельно запускали всё красное. В результате попутались версии объектов и было очень весело всё проверять.