Transporte nach Systemkopie

[ewx]

Hallo zusammen!

ich würde gerne mal wissen, wie und mit welchen Tools ihr nach einer Systemkopie die notwendigen Transporte ins das kopierte System bekommt...

In der Regel gibt es die Systeme DEV, TEST und PROD.
Normalerweise wird im TEST-System getestet; hier müssen also aktuelle Daten als auch die aktuellen Programmstände vorhanden sein.
Das erreicht man, indem man das PROD auf's TEST kopiert. Danach müssen aber noch die Transporte, die zwar vorher ins TEST-System aber noch nicht ins PROD importiert wurden, nachträglich ins TEST eingespielt werden.

Dies kann man machen, in dem man alle Transportaufträge zusammen sucht, die noch nicht ins PROD importiert wurden, bzw. zwischenzeitlich ins PROD eingespielt wurden und diese dann ins TEST importiert. Das geht aber meines Wissens nur einzeln, oder?

Die zweite Möglichkeit ist, dass man über die Objekte der ermittelten Transporte einen "Transport von Kopien" macht und dann diesen einen Transport einspielt. Dabei werden aber die aktuellen Sourcen aus dem DEV-System genommen. Diese können aber einen "unfertigen" Status haben, der gar nicht ins TEST-System soll...

Wie löst ihr den NAchtransport nach einer Systemkopie??

Danke!

[Alessio37]

Hallo,

bei uns bekommt jeder Enttwickler den Auftrag die selber zu erledigen.

Auf die STMS Transaktion hat kein Entwickler Berechtigungen. Der Transport erfolgt über ein Transportmanagementtool. Darin wird verwaltet, welcher Transport gerade wo in der der Kette D --> Q --> P ist. Man geht auf die Q-Ebene und löst den Import nochmals aus.
Ein Entwickler hat auch keine Berechtigung nach P zu transportieren, hierzu muss der Transport von 2 unterschiedlichen Personen im Transportmanager genemigt werden und diese stellen sicher, dass der Auftrag vorher im gespiegelten Q gelandet ist (manuell per Importprotokoll).

Grüße
Alex

[ewx]

Hi Alex!
Danke für deine Info!
realtech Transportmanager?
Ich finde es ziemlich unsinnig, das jeden Entwickler selbst machen zu lassen.
Zumal bei dem Transportmanager IMHO der Import nicht "einfach noch mal ausgelöst" werden kann, sondern "zurück gestuft" werden muss. Damit sind sämtliche vorher erteilten Genehmigen wieder fällig.

[Alessio37]

Hallo,

ja, realtech Transportmanager.

Ein zurückstufen ist nicht erforderlich, es recht die letzte Unterschrift zu löschen und neu zu setzten.

Ich finde es ziemlich unsinnig, das jeden Entwickler selbst machen zu lassen.

--> ist nicht optimal
--> OK, aber funktioniert immer noch besser als alle Transporte die noch nicht ist P gewandert sind auszuwerten. Da wären dann ggf. auch Transporte mit drin, die das frische Q System gleich mal wieder "vernichten".

Grüße
Alex

[ewx]

ICh habe gerade gesehen, dass es bei dem Transportmanager unter "Tools" ein Programm gibt, mit dem man die Transporte zwischen Systemen vergleichen kann. Da stand auch was, was darauf hindeutet, dass man es zum Abgleich nach einer Systemkopie benutzen kann, aber das habe ich nicht einordnen können.

/Nachtrag:
Transaktion /RTC/TM_TOOLS
Importtracking: Systemvergleich

Verwenden Sie die Option 'Importtracking: Systemvergleich' zum Vergleich der Importhistorie von 2 verschiedenen Zielsystemen. Die Ergebnismenge kann durch die Angabe zusätzlicher Filterkriterien eingeschränkt werden.


Geben Sie im Selektionsbild die betreffenden Systeme/Mandanten und den Analysezeitraum an, sowie ggfls. weitere Filterkriterien.


Handelt es sich um Dual Stack Systeme, deren Java Stack unter einer eigenen SID im TMS, bzw. TransportManager verwaltet werden, so geben Sie diese SID zusätzlich im Feld 'Non ABAP System' ein um die komplette Importhistorie beider Systeme zu erhalten.


Wollen Sie diese Option nach einer homogenen Systemkopie verwenden, um das Transportdelta zu ermitteln, dass vor der Kopie vorhanden war, so muss als Startzeitpunkt ein Zeitpunkt angegeben werden, an dem dieses Delta Null war,inder Regel also der Zeitpunkt der vorletzten Systemkopie. Die Historie und damit das Delta ist jedoch nur dann vollständig, wenn seit diesem Startzeitpunkt bereits der TransportManager im Einsatz war.


In der Ergebnisliste werden auch die kritischen Transporte ausgewiesen. Ein Transport gilt als kritisch, wenn:


er auf einem anderen System als auf dem TM-Server angelegt wurde
der Importmandant nicht bestimmt werden konnte
es sich um einen Mandantentransport handelt
der Returncode größer als '0004' ist
der Auftragstyp nicht bestimmt werden konnte
das TM Projekt nicht bestimmt werden konnte

Bitte prüfen Sie, ob die Läufe des Importscanners das komplette Analyseintervall abdecken!


Das Deltatracking bietet spezielle Filteroptionen um z.B. nur die Aufträge anzuzeigen, die in genau eines der beiden Systeme importiert wurden. Markieren Sie alle Einträge, die für einen Reimport vorgesehen sind und stellen Sie diese in Ihre persönliche Queue.


Achtung: Dabei wird die persönliche Queue komplett überschrieben!


Geben Sie für jeden Zielmandanten der Selektionsmenge einen Zielmandanten für den entsprechenden Eintrag in der persönlichen Queue an.


Bevor Sie dann diese Queue starten, sollten Sie sich durch einen Vergleich der Queue mit der Selektionsliste davon überzeugen, dass das generierte Ergebnis Ihrer Intention entspricht.