1. как реализовать автоматический "прогон" транспортного реквеста в тестовой системе (любой другой системе входящей в транспортный домен)?

2. где прочитать про архивацию транспортной очереди которая раздувается и долго перечитывается по сто раз при каждом вызове STMS (или как хотя бы скрыть ненужные старые реквесты) т.к. аудит не приемлет стандартную очистку очереди без возможности восстановления, а дурацкий фильтр работает только до следующего входа в STMS. Что то слышал про ЭНТИ бэкапирование транспортной директории, но не совсем понял как это увязано с восстановлением/очисткой истории очереди...

3. неужели все делают ЭТО ручками по одному запросу и ничего не автоматизируют? просто кошмар какой то

В каком смысле прогон?


Можно скопировать файлики куданть, в другую директорию - а очеред удалить всю как обычно из stms




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

прогон в смысле - импорт

то есть, если я правильно все понимаю, при обратном копировании, очередь перечитается и стертые запросы нарисуются в очереди? звучит не очень убедительно, а экспериментировать не хоца :/
не такие уж тупицы пишут САП... неужели они написав такую громоздкую кучу всякого разного не дотумкались, что можно присобачить к реквестам порядковый номер "автоимпорта"? не верю! а ручной способ при использовании компьютера - это дикость извините за выражение и эмоции, тут ведь искусственного интеллекта не нужно...

Нет конечно. Ничего не перечитывается из транспортной директории. Проще сохранить файл буфера системы из /usr/sap/SID/trans/buffer. А затем его восстановить по надобности. И вообще это бред не чистиь очередь ради аудита, любое неаккуратное действие очистит очередь.


Есть history. Но это в зависимости от версии системы.

Вообще аудиторов надо посылать на... STMS_TRACK

то есть насколько я понимаю - это история (лог-файл) транспортной очереди которая доступна после очистки очереди? если да - "тоже вариант"

Ну и что случится? Во время закрытия второго запроса в транспорт попадут все изменения сделанные над этим объектом.
Если эти настройки действительно нужны, то все в порядке. В очередь они лягут по времени закрытия. В этом порядке и импортировать?
Где проблема? Не вижу

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

Лягут в очередь они в правильном порядке.
С какой радости более полный запрос будет первым? Если только в промежутке между закрытием этих запросов кто-то еще не влезет и не уберет настройки, которые были в первом запросе
Пока запрос не закрыт - он содержит только ссылку на объекты, затронутые в нем. И в момент закрытия эти объекты, в своем текущем состоянии, лягут в физический файл и в очередь нужной системы.

ну, помоему, теоретически может... да и практически помоему тоже



да это ежу ясно, что ссылку.

PS: пример:
Схема - двух-серверная, тоесть разработка и продуктив.
в разработке сделали два объекта О1 и О2. Причем в двух разных реквестах. О1 без О2 не нработает(О1 - АВАР код, О2 - таблица). Протестировали - всё кул. Деблокировали О1. И понесли в продуктив. Получили бонус, ибо таблицы там нет. Потом деблокировали О2.
И перенос уже будет сначала О2 а потом О1.
Помоему, даже если сразу оба деблокируют в этом порядке - О1, О2 - перенос помоему тоже не пойдет. Нужен обратный перенос.

Пойдем с начала
Мы говорим о том, что два человека правят один и тот же объект.
Опустим тот вопрос, что в разных запросах это делать не получится. У второго создастся задача в запросе первого И закрыть их можно будет только вместе.
Пусть их, они так сумели
Они правят одно и тоже! И если после закрытия первым своего запроса второй настройки первого не сбросит, что по исходной задаче не должно иметь места (было сказано, что они правят разные места одного объекта), то второй, при закрытии своего запроса, внесет в него как собственные правки, так и правки, сделаные первым. Не могут они исчезнуть
И в таком случае, чисто теоретически, запрос, который делал первый можно вообще не импортировать, поскольку его изменения есть и в запросе второго.

да я понимаю, не совсем корректный пример я привел в самом начале - ясно что если два чела правят один и тотже объект, то запрос будет 1. И в нём будут две корректуры.

Я говорю о том, что может случиться так, что будет N запросов в которых будут объекты, зависимые от других, и деблокированы они могут быть в других запросах и не в той последовательности. И тогда автоматизации никакой не будет



::: не согласен ну впрочем фиг с ним...

говорю же - ясно уже все

еще раз вспомним, что

При массовой закачке запросов идет для разработок отслеживание версионности, для настроек такого нет. Потом еще: для всего пакета запросов шаги выполняются последовательно, начиная с первого. Иными словами: первый шаг (импорт) делается для всего списка, потом для всего списка выполняется следующий - проверка версий и т.д. и т.п.

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

у когото есть тестовая система, а у когото и нет хорошо если настройки совпадают.

хотя сдается мне, что все, кто начинал с 2ух системного ланшаФта(дев+продакт с последующим копированием манданта), рано или поздно приходят к 3-ёх уровнему.