Всем привет!

В методологии заявляется следующее: для разработки/настройки нужен трехсистемный ландшафт. Тестирование ведем в системе QAS на реальных (продуктивных) данных. Эти данные следует регулярно (раз в 1-2 месяца) обновлять из продуктивного манданта.

Некоторые товарищи утверждали, что для этого следует целиком копировать продуктивный мандант (с профилем SAP_ALL) в систему обеспечения качества (или копировать систему целиком). Здесь возникают следующие моменты:
1. По количеству импортированных запросов QAS всегда более новая по сравнению с PRD. При копировании манданта все эти "новые" мандантозависимые настройки (или любые настройки и объекты репозатария в случае копирования системы) будут утрачены. Необходимо отслеживать, какие запросы импортировать заново.
2. Необходимо ограничивать доступ к критичным бизнес-данным (например, финансовые документы, зарплаты и т.п.).

Как правильно выполнить обновление данных тестового манданта? Как это делается у вас?

Может через ALE тогда обновляться?

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

Немного не понятно зачем иметь тестовую среду, максимально похожую на продуктив, но отличающуюся от него на определенное количество запросов ??? Вопрос несколько ставит в тупик, потому что "обычно так НЕ делается" у нас...

Однако, также обычно в тестовой системе имеется целый набор мандантов для различных целей. Если уж очень нужно, могу предложить следующий вариант:
1. Копируем настройку в какой то доп. мандант по SAP_CUST.
2. Переносим/Удаленно копируем мантант из продуктива по SAP_ALL/SAP_APPL (первый способ предпочтительнее, если имеется существенная разница словаря с продуктивом, в вашем случае - реально)
3. Копируем настройку назад.

2Вася!:

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

Предложенный вариант не решит задачу, т.к. последний третий шаг, прежде всего, удалит содержимое тестового манданта, а затем скопирует в него исходные настройки (шаг 1).

2 All
Может сама задача на проектах не возникает? Тогда каким образом тесовый мандант наполняется данными (это огромная работа по подготовке "корректных" тестовых данных - отсюда и идея - взять хорошие данные из продуктива)?

1. Принимается административное решение закрыть на время перенос из разработки в тест. И докатываются все транспорты в продуктив.
Вообще мне кажется не очень правильным держать висящие транспорты в тесте без переноса в продуктив дольше недели. Особенно если исходить из рекомендованного цикла разработки, когда к концу недели все транспорты из теста должны быть перенесены в продуктив
Если разработчики не могут за неделю проверить свои транспорты в тесте, пусть предварительно тестируются в системе разработки в отдельном манданте.
2. В тесте держим два манданта. Через один несем транспорты, в другом держим данные для тестирования, туда и будем заливать данные с продуктива. При переносе транспортов в тест гоним их в оба манданта.
3. Периодически копируем по sap_all продуктивный мандант в тестовую систему.
4. Тестеров пускаем в тестовую систему в тот мандант, куда заливали данные с продуктива.
5. Если есть проблема с обеспечением безопасности данных, напрягаем абаперов, чтобы писали проги по переделки реальных данных в таблицах во что-нибудь левое. Но тогда будет проблема, что полного тестирования мы не получим, поскольку нельзя результаты сверить с реальными данными.

Спасибо за подсказанное решение.
Единственное, что не понял - зачем нам отдельный мандант только с настройками (фактически копия манданта настройки и разработки CUST - системы разработки)?
Без данных мандант в системе обеспечения качества интереса не представляет. Держать его как чистую копию (эталон, pristine) настроек - зачем - на это есть система разработки с незапорченным никакими данными мандантом настройки?

Это все конечно хорошо, но... есть небольшое НО! Когда объем данных уйдет за сотню гиг, то процедура копирования будет длиться сутками...

Mне так было удобнее.
Да и remote копирование еще отладить надо
Кроме того у манданта с данными желателен статус "Продуктивный", чтобы некоторые транзакции работали в другом режиме. В частности ведение курсов валют.

А кто сказал, что будет легко?
В пределах 70-80 гиг за ночь проходило. В пятницу вечером запускаем, в субботу утром проверяем на ошибки, к понедельнику имеем рабочую версию.
Гораздо более забавно предварительно стирать предыдущую версию манданта. Когда таблички в роллбэк не лезут. И нет никакого желания (да и места) для его расширения до офигительных размеров.

Ну значит - все еще впереди

В ситуации со большими объемами (порядка 100 Гб и более) советовали копировать систему из резервной копии вместо копирования манданта.

Эт' точно...
Одна радость, что не слишком часто просили копировать. Хотя на отладке некоторых вещей доблестные абаперы убивали данные за один прием А потом опять просили

А с резервной копии какой системы? Продуктива? А не советовали при этом как менять потом имя системы?
Есть еще вариант с экспортом/импортом манданта. Только опять же надо иметь хороший запас свободного дискового пространства. Да и по времени не сильно быстрее, чем remote copy будет.

Тут маааленькое неудобство - в ландшафте будет два манданта с одним номером. Криминала особого нет, но провоцируется ситуация, когда человек что-то вкатит в тестовой в полной уверенности, что работает в продуктиве.