Пришло время часть проекта перенести на продуктив.
Это пока только одна часть, но которая может работать самостоятельно.
Характер проекта: Расчеты стоимости. Причем расчеты достаточно сложные. Входных данных может быть > 200.

Суть вопроса такая. Расчеты проверены. Но учитывая, что они достаточно сложные и входящих данных очень много. Говорить о том, что все 100% проверено нельзя.
Учитывая прошлый опыт этой программы в другой системе ошибки находились и через год, 2а года, и 3и года после внедрения.
А расчеты еще могут меняться со временем. и. т. д.
Соответственно проект переносится на продукив. Все это Z таблицы. Пока проект со стандартными модулями никак не связан.Можно работать спокойно. Возникает ситуация когда на продуктиве делается некий расчет и находится ошибка.
Для исправления этой ошибки я должен взять этот расчет на сервер разработки, там найти ошибку, исправить ее и протестировать, после чего исправленный АБАП код “положить”
на продуктив.

А вот вопрос как его (запись с подчиненными таблицами и т д) взять обратно на тест.. проверить и оттестить.. (Ручками повторить, исключено. Параметров ОЧЕНЬ много)
Возвращать на продуктив ненужно. После исправления абап кода его просто пересчитают на продуктиве.


Мне прочитали небольшую лекцию о том как это делается в самом сапе по всем правилам.
Но это правило не предусматривает возврата определенных данных с продуктива на тест кроме поднятия базы продуктива на тесте.

Предварительно было решено сделать мне некий сервис (средстваит оракла или другими.. пока не знаю, админы решают. ) Который будет с продуктива перегонять мне полные копии определенных таблиц и на которых я буду тестится. Меня это устроит.

А как делаете ВЫ?
Может есть что-то о чем я не знаю. Поделитесь опытом.

Если железо позволяет, то можно скопировать всю продуктивную систему в тест либо в псевдо-тест, перенести туда же исправления из разработки и "зазырить" что не так... Это как вариант, ИМХО

Это не правильно - вначале идёт перенос в систему качества(тестовую) - выполняется тестирование, выявленые ошибки исправляются в разработке, и цикл по новой до приемлемого результата, после чего уже переноситься в продуктив.
Впрочем про это, насколько я понимаю, Вам уже рассказали.Это конечно не совсем классическая схема, но что поделать - тестироваться на данных, максимально приближенных к реальным (как по объёму, так и по разнообразию) нужно много кому, так что это не самый плохой вариантКак-бы возможно положить в запрос в продуктивонй системе данные и перенести их в разарботку или в тест, но это как правило единичные разовые действия, выполняемые базисом крайне неохотно.
у SAP-а для организации тестирования есть целая система - eCATT называется, правда встречать тех, кто этим пользуется не приходилось, хотя было-бы интересно и, возможно, полезно осовить данные возможности.

На разработку "всеобъемлющего" скрипта уйдет много времени и, главное, не факт что получится ошибку поймать. На мой взгляд до 90% ошибок случается из-за недокументированного функциональным объемом ввода/использования данных. А скрипт пишешь по нормальной (так сказать нужной и правильной) схеме...

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

Не вижу ничего плохого в том, что в разработке специальный мандант и копировать туда содержимое избранных таблиц. Это можно сделать и стандартными средствами, но возможны ограничения по классу ведения и классу данных таблиц, а можно и написать собственную программу для перекачки, хоть через файлы, хоть через RFC.

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

ну.. на то мы и программеры. Если все продумать настроить и отладить сразу.. то на продуктив можно не ходить вообще. Данные забрал и проверяй.

Как говаривал один наш базисник: настоящий программист должен уметь писАть работоспособные программы вообще без данных

ну да.. а еще писать программы неиспользуя оператор IF

но это уже философия программирования