PI-Transporte über den Change Management Service (CMS) 

Allgemein

Bei PI-Transporten mit Hilfe des Change Management Services (CMS) arbeiten Sie mit den folgenden Werkzeugen:

●      Landscape Configurator, um die Transportlandschaft mit Hilfe von XI-Tracks festzulegen.

●      Enterprise Services Builder, um ESR-Content des Entwicklungssystems oder des Konsolidierungssystems (bei Notkorrekturen) zu exportieren und um durchgeführte Transporte nachzuverfolgen.

●      Integration Builder für Integration-Directory-Transporte, um Konfigurationsinhalte des Entwicklungssystems oder des Konsolidierungssystems (für kurzfristige Änderungen) zu exportieren und um durchgeführte Transporte nachzuverfolgen.

●      Transport Studio, um Transporte mit dem CMS durchzuführen.

Dieser Abschnitt beschränkt sich auf die Darstellung der grundlegenden Schritte und Möglichkeiten bei CMS-Transporten. Auf detailierte Vorgehensweisen wird an den jeweiligen Stellen verwiesen.

Konfiguration der Transport-Landschaft

Das CMS unterstützt die Definition unterschiedlicher Transportlandschaften über die Definition von XI-Tracks im Landscape Configurator. Folgende Szenarios werden unterstützt:

Bei den Transport-Szenarios mit verketteten Tracks müssen die Objektversionen aus PROD1 mit denen aus DEV2 übereinstimmen. Sie dürfen nur XI-Tracks unterschiedlicher Systemlandschaften verketten (weitere Informationen: Tracks verbinden), das heißt: wenn Sie zwei Tracks A und B verketten, darf kein System von Track A erneut in Track B auftauchen. Sie können die Systeme beider Systemlandschaften in einem System Landscape Directory erfassen.

PI-Transporte innerhalb einer Transportlandschaft

Im CMS-Modus führen Sie Transporte mit Hilfe des ES Builders (bei Designobjekten) beziehungsweise des Integration Builders (bei Konfigurationsobjekten) und dem Transport Studio des CMS durch. Die Werkzeuge konzentrieren sich auf folgende Bereiche des Transports:

Transportfunktionen im ES Builder/Integration Builder und im Transport Studio

ES Builder/ Integration Builder	Festlegen der Objektmenge für den Transport
	Statusanzeige
	Konfliktauflösung bei Importen
	Suchen von Transporten
Transport Studio:	Import von Änderungsaufträgen in das Zielsystem (Development, Consolidation, Assembly)
	Zusammenstellen von Software-Komponentenversionen (Assembly)
	Qualitätssicherungsschritt (Approval)

Im folgenden wird davon ausgegangen, dass die Software-Komponentenversion der Objekte, die transportiert werden sollen, für den Transport über das CMS freigeschaltet sind. Für den gesamten Inhalt des Integration Directory gibt es eine von SAP vorgegebene Software-Komponentenversion.

Transporteinheiten im ES Builder/Integration Builder

Sie legen die Objektmenge eines Transportes für Designobjekte im ES Builder und für Konfigurationsobjekte im Integration Builder fest. Sie können dazu entweder Änderungslisten oder Transportlisten an das CMS übergeben. Nach dem Export aus dem ES Builder oder Integration Builder erscheint die Änderungs- oder Transportliste als Änderungsauftrag im Transport Studio.

Änderungslisten

Sowohl der ES Builder als auch der Integration Builder sammelt alle Änderungen von Objekten in einer Änderungsliste. Daher liegt es nahe, genau diese Änderungen (beispielsweise aus dem Entwicklungssystem) transportieren zu wollen. Nach deren Freigabe wechselt der Status der Änderungsliste von offen auf transportierbar. Um sie an das CMS zu übergeben, wählen Sie Transportieren… im Kontextmenü auf der Registerkarte Änderungslisten. Mit Änderungslisten transportieren Sie alle Änderungen zum Zeitpunkt der Freigabe.

Transportlisten

Um eine Liste von Objekten unabhängig von Änderungslisten zusammenzustellen, erzeugen Sie Transportlisten über den Transport-Wizard. Um eine Transportliste zu erzeugen, gehen Sie folgendermaßen vor:

...

       1.      Wählen Sie Werkzeuge → Designobjekte exportieren (Enterprise Services Builder) beziehungsweise Werkzeuge → Konfigurationsobjekte exportieren (Integration Builder).

       2.      Wählen Sie den Modus Transport durch CMS und legen Sie im nächsten Schritt die Objektmenge fest.

Beim Festlegen der Objektmenge im Transport-Wizard können Sie auch Änderungslisten als Filter verwenden. Nichtsdestotrotz hat auch in diesem Fall die auf diese Weise zusammengestellte Liste von Objekten alle normalen Eigenschaften einer Transportliste.

Sowohl der ES Builder als auch der Integration Builder zeigt die Transportliste auf der Registerkarte Änderungslisten an. Sie wird direkt an das CMS übergeben und hat den Status Auf Export wartend… bis dieser Vorgang abgeschlossen ist. Mit Transportlisten transportieren Sie die zum Zeitpunkt der Zusammenstellung der Transportliste aktiven Versionen der Objekte.

Zusammenspiel mit dem Transport Studio

Innerhalb eines XI-Track können Sie Objekte vom Entwicklungsystem (DEV) ins Konsolidierungssystem (CONS) und schließlich vom Konsolidierungssystem (CONS) ins Produktivsystem (PROD) transportieren. Sowohl der ES Builder als auch der Integration Builder bietet abhängig vom Zielsystem unterschiedliche Möglichkeiten zum Festlegen der Transporteinheiten:

Transporteinheiten abhängig vom Typ des XI-Tracks und vom Transport-Szenario

Typ des XI-Tracks	Unterstützte Transporteinheiten (abhängig vom Transport-Szenario)
	Von DEV nach CONS	Von CONS nach PROD
ES Repository	Änderungs- und Transportlisten	Regelfall: Software-Komponentenversionen (im Transport Studio)
		Änderungs- und Transportlisten (Notkorrekturen im ES Builder)
Integration Directory	Transportlisten (Objekte eines Partners, Service oder Konfigurationsszenarios)	Regelfall: Änderungslisten (nach ihrem Import und ihrer manuellen Freigabe im Integration Builder beziehungsweise bei weiteren Änderungen im Konsolidierungssystem) Sie können auch neue Transportlisten anlegen.
		Komplettabzug (im Transport Studio; beispielsweise für eine initiale Verteilung des gesamten Directory-Inhalts)

Wie die Tabelle zeigt, sind die üblichen Transporteinheiten und die durchzuführenden Schritte zum einen vom Typ des XI-Tracks abhängig (Enterprise Services Repository oder Integration Directory) und zum anderen vom Transport-Szenario.

Im Transport Studio des CMS gibt es für jeden Track eine Reihe von Registerkarten, die bei Transporten einer nach dem anderen durchlaufen werden. Abhängig davon, mit welchem Integration Builder beziehungsweise ES Builder Sie arbeiten (eines Entwicklungs-, Konsolidierungs- oder Produktivsystems), landen ihre exportierten Änderungs- beziehungsweise Transportlisten auf einer anderen Registerkarte. In der folgenden Grafik ist der Ablauf für den Integration Builder dargestellt. Er gilt genauso für den ES Builder:

In der Regel exportieren Sie aus dem Entwicklungssystem Transportaufträge, die in der Import-Queue des Transport Studio für das Konsolidierungssystems erscheinen. Dort steuern Sie den weiteren Verlauf des Transports. Ausnahmen:

●      Im Integration Directory des Konsolidierungssystems werden beim Import von Änderungen Änderungslisten erzeugt. Diese Änderungslisten müssen Sie im Integration Builder prüfen und freigeben, bevor Sie sie mit dem Transport Studio weitertransportieren können.

●      Wenn Sie Notkorrekturen im ES Repository des Konsolidierungssystems vornehmen müssen, exportieren Sie Änderungs- oder Transportlisten, die ebenso wie im Directory-Fall im Transport Studio erscheinen. Sie können dann entweder die ganze Software-Komponentenversion erneut zusammenstellen (im Assembly-Schritt) oder nur ein Paket mit den Änderungen für das Produktivsystem erzeugen.

Weitere Informationen: Transport von Designobjekten und Transport von Konfigurationsobjekten

Die folgende Tabelle beschreibt zusammenfassend den Ablauf von Transporten im CMS. Die Reihenfolge der Registerkarten im Transport Studio entspricht dabei dem Transportweg innerhalb eines Tracks.

Entwicklungszustände des XI-Tracks im Transport Studio

Schritt	Registerkarte	Verwendung
	Check-In	Mit dem Check-In machen Sie Archiv-Dateien mit der Endung .PRA, die Sie von einer externen Quelle erhalten haben, dem Change Management Service bekannt und stellen Sie für den Transport durch die Entwicklungslandschaft zur Verfügung. Eingecheckte Archive wandern in die Import-Queue auf der Registerkarte Development. Bislang machen Verwender des ES Builder beziehungsweise Integration Builder von dieser Funktion keinen Gebrauch, da dort eine eigene Importfunktion zur Verfügung steht (filesystem-basierter Import).
0	Development	In dieser Import-Queue landen eingecheckte Archive oder Exporte aus anderen XI-Tracks, die mit diesem Track verbunden sind (weitere Informationen: Tracks verbinden).
1	Consolidation	Nach dem Export eines Transportauftrages im ES Builder / Integration Builder der Entwicklung finden Sie hier Änderungsaufträge für jede Software-Komponentenversion wieder, um sie in das Konsolidierungssystem (ES Repository oder Integration Directory) zu importieren.
2	Assembly	Nach dem Import im Konsolidierungssystem stellen Sie hier Abzüge von Software-Komponentenversionen zusammen.
3	Approval	Zusammengestellte Software-Komponentenversionen finden Sie auf dieser Registerkarte. Zur Qualitätssicherung können Sie in diesem Schritt entscheiden, welche Änderungen in das Produktivsystem importiert werden sollen.
4	Production	Nach dem Approval steht der Transport zu Import in das Produktivsystem bereit. Die zugehörige Registerkarte wird nur angezeigt, wenn Sie im zugehörigen Track ein Produktivsystem eingetragen haben.