Добрый день!

В тестовой системе два манданта: тестовый и учебный.
Необходимо, чтобы все уходящие из тестового манданта в продуктив манданто-зависимые запросы запросы автоматически переносились в учебный мандант.
Подскажите, как отсеивать автоматически именно такой тип запросов?
Настроен ETC. Сейчас в очереди тестовой системы появляются ВСЕ ушедшие в продуктив настроечные запросы (с целью -- учебный мандант).

R/3 4.7
трёхсистемный ландшафт

Странный вопрос. У Вас не все запросы из тестовой системы уходят в продуктив? Или Вы в тестовой системе создаете запросы?

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




ir
В одном запросе могут быть манданто-зависимые и манданто-независимые данные, поэтому этот вопрос не имеет смысла.
Более того, правильнее импортировать только в той последовательности, в которой выполнялось деблокирование.

Да, в очередь учебного манданта должны приходить только зависимые от манданта запросы (и только после переноса в прдуктив). А в продуктив уходят все запросы.

Но с другой стороны, соглашусь с Tetty, в одном настроечном запросе зачастую могут быть манданто-зависимые и манданто-независимые данные.
Как же тогда поддерживать актуальными настройки учебного манданта (такими же как в продуктиве)?

Если нести в учебный мандант все настроечные запросы, то запрос ZZZ может затереть настройки, выполненные за промежуток времени между переносами этого запроса ZZZ в тест и продуктив (а это может быть пара недель)...

Обычно используется трёх- и более системный ландшафт. Обучение пользователей проходит в дополнительном манданте/клиенте системы качества (QAS). Данные в неё попадают копированием ВСЕГО манданта/клиента из продуктива.

Ну, это Вы загнули. Сомневаюсь, что подобное описано в теории. А на практике в учебном манданте хранятся учебные данные, которые будут затерты полным копированием =) Да и продуктивных данных могут быть терабайты и под большим вопросом, должны ли они в учебной системе светиться. Вот с профилем копирования SAP_CUST, например, вполне актуальность учебной системы можно поддерживать.

И второй вариант, _любой_ запрос, перенесенный в продуктив, сразу переносить в учебный мандант.

Обычно происходит к сожалению так. Сап рекомендует все совсем по другому, чтоб в тестовой Системе был Минимальный набор продуктивных данных, необходимых только для тестирования.
А запросы которые переносятся в продуктив обязательно должны быть в тестовой системе. Темболее при трех системных ландшафтах Если только вы вручную не переносите запросы в Продуктив.

Что касается данных, то пользователь после обучения получит к ним доступ уже в продуктиве. Создать хороший учебный набор данных - достаточно трудоёмкая задача, проводить же обучение на IDES тоже нельзя.

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


Вопрос о регламенте наполнения учебной системы данными в чём-то похож на вопрос использование ARIS на проектах - есть "правильный" путь, есть много "плохих", а есть компромиссные варианты.

Tetty, у нас так и сделано. Под обучение отдельный мандант в тестовой системе.
Действительно, можно (как мы прежде и делали) периодически выполнять копирование манданта. Но это менее оперативное обновление настроек, чем запросами...

sapzvezda, а при втором варианте не будут затираться изменения?

"Если нести в учебный мандант все настроечные запросы, то запрос ZZZ может затереть настройки, выполненные за промежуток времени между переносами этого запроса ZZZ в тест и продуктив (а это может быть пара недель)..."

DV, мы конечно сначала в тест переносим запросы, а потом в продуктив.
Не хотелось нести в учебный мандант непротестированные мандантно-зависимые настройки.

Правильно ли я понимаю, что чаще всего делается так: все запросы из разработки несутся и в тестовый, и в учебный манданты тестовой системы?

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

Сделано. Но как-то нужно отфильтровать так, чтобы не переносить заново в тест мандантно-независимые запросы... Мне уже думается, что это желание абсурдно и не имеет смысла...

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

UPD: В общем без синхронизации переносов не обойтись =)

я говорю про настройки, приехавшие в тестовую систему из разработки запросами

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

sapzvezda, Tetty, DV спасибо за помощь!

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

Если в QA будут более поздние транспорта с теми же клиенто-независимые объектами, что и транспорта развернутые из PROD, то QA будет испорчен.

Все равно копию PROD в QA получить не удасться из-за разницы клиенто-независимых объектов. Нужна еще одна система.