Transport von XI-Objekten 

Verwendung

Man bezeichnet Objekte des Integration Repository als Designobjekte, Objekte des Integration Directory als Konfigurationsobjekte und beide als XI-Objekte. Der Transport von XI-Objekten besteht aus einem Export aus dem Ausgangs-Repository beziehungsweise Directory und einem Import im Ziel-Repository beziehungsweise Directory. Sie können XI-Objekte für folgende Zwecke transportieren:

·        Um Designobjekte eines Integration Repository in ein anderes Integration Repository zu kopieren. Die Software-Komponentenversion muss dazu bei Ausgangs- und Ziel-Repository die gleiche sein. Sie liefern die Designobjekte des Integration Repository auf diese Weise auch über Exportdateien aus. Hinweis 836200 beschreibt in Kürze, wie Kunden diesen Process Integration Content in ihr Integration Repository importieren.

·        Um Konfigurationsobjekte eines Integration Directory in ein anderes Integration Directory zu kopieren. Auf diese Weise können Sie eine Test-Konfiguration in eine Produktiv-Landschaft kopieren.

Integration

Neben den Transportfunktionen gibt es einige verwandte Funktionen, die nicht in diesem Abschnitt beschrieben sind:

Verwandte Funktionen

Funktion	Verwendung
Release-Übernahme	Übernahme von Designobjekten innerhalb eines Integration Repository von einer Software-Komponentenversion in eine andere.
System-Content-Kopie	Übernahme aller Inhalte einer XI-Lanschaft in eine andere XI-Lanschaft (Integration Repository, Integration Directory und weitere Daten, beispielsweise Konfigurationsdaten des Integration Servers). Siehe hierzu den System Content Copy Guide auf dem SAP Service Marketplace unter der Internet-Adresse service.sap.com\instguidesNW04 ® Operations ® SAP XI.
Release-übergreifende Transporte	Transporte aus einem Repository oder Directory eines älteren Releases. Informationen über Release-übergreifende Transporte finden Sie im Hinweis 834507.

Funktionsumfang

Allgemeines

·        Beim Export von XI-Objekten können Sie die Objektmenge eingrenzen.

·        Sie können nur aktivierte Objekte exportieren. Ist ein Objekt der Objektmenge inaktiv, exportiert der Integration Builder die letzte aktive Version. Ausnahme: Bei einem Export einer Änderungsliste über die Funktion Transportieren auf der Registerkarte Änderungslisten exportiert der Integration Builder die Objektversionen zum Zeitpunkt der Freigabe. Siehe: Transport von Änderungslisten.

·        Für Objekte, die gelöscht worden sind, exportiert der Integration Builder eine Löschversion, damit das Objekt beim Import in ein Ziel-Repository beziehungsweise Ziel-Directory ebenfalls löscht. In Ausnahmefällen kann es sinnvoll sein, den Export von Löschversionen zu deaktivieren. Löschversionen werden exportiert, wenn das Ankreuzfeld Gelösche Objekte berücksichtigen angekreuzt ist.

Integration Repository

Sie haben folgende Auswahlmöglichkeiten für die zu exportierende Objektmenge:

·        Alle Objekte einer Software-Komponentenversion. In diesem Fall exportiert der Integration Builder immer auch die Löschversionen.

·        Alle Objekte einzelner Namensräume einer Software-Komponentenversion.

·        Einzelne Objekte einer Software-Komponentenversion. Die gelöschten Objekte sind in der Auswahlliste an der Ikone Löschversion () zu erkennen. Siehe auch: Einzelobjektauswahl.

Weil bei einem Import immer die Version der Software-Komponente der zu importierenden Objekte geprüft werden muss, enthält die Export-Datei auch bei einem Export von Objekten eines Namensraumes Informationen zur übergeordneten Software-Komponente.

Wenn Sie nur die Objekte eines Namensraumes exportiert haben, sind trotzdem die Namensräume der gleichen Software-Komponentenversion nach dem Import im Ziel-Repository sichtbar. Diese Namensräume sind allerdings leer, weil sie ja nicht exportiert worden sind. SAP empfiehlt den Export von kompletten Software-Komponentenversionen, um Verwirrungen zu vermeiden.

Die Versionsverwaltung prüft beim Import, ob im Ziel-Repository zu importierende Objekte bereits vorhanden sind und welchen Versionsstand diese haben (siehe: Versionierung bei Transporten). Versionskonflikte können auftreten, wenn Objekte sowohl im Ausgangs- wie auch im Ziel-Repository geändert worden sind. Diese Konflikte können Sie beim Import auflösen (siehe: Konflikte beim Import von Objekten).

Integration Directory

Sie können für den Export alle Objekte eines Konfigurationsszenarios, eines Partners oder Services auswählen. Der Integration Builder exportiert dann das Konfigurationsszenario (beziehungsweise den Partner oder Service) und alle untergeordneten Objekte. Außerdem können Sie einzelne Objekte über die Einzelobjektauswahl selektieren.

Die Objekte des Integration Directory verweisen auf Objekte des Integration Repository. SAP empfiehlt daher, zuerst die notwendigen Objekte des Integration Repository zu transportieren und dann die Objekte des Integration Directory. Verweist das Integration Directory auf Objekte im Integration Repository, die dort noch nicht importiert wurden, ist die Konfiguration unvollständig. Sie können die fehlenden Objekte auch nachträglich in das Integration Repository importieren.

Umsetzungen und Zusammenführungen beim Import

SAP empfiehlt die Verwendung eines System Landscape Directory (SLD), in dem sowohl die Test- als auch die Produktiv-Landschaft hinterlegt ist. Um Konfigurations-Objekte aus dem Test-Directory in das Produktiv-Directory importieren zu können, müssen Sie im SLD Transport-Targets definieren. Dadurch werden Services des Test-Directories, die im SLD als Business-Systeme eingetragen sind, den Services des Produktiv-Directories zugeordnet und abhängige Objekte umgesetzt. (Siehe Hinweis 764393 für alternative SLD-Szenarien).

Siehe auch: Konfigurieren von Gruppen und Transport Targets.

Bei Kommunikationskanälen gibt es eine Besonderheit: Um zu vermeiden, dass Messages aus einem Produktivsystem an Systeme der Testlandschaft geschickt werden, exportiert der Integration Builder nur eine Auswahl der Attribute. Adressdaten (Host, Port) und Zugangsdaten (Benutzer, Passwort) sind daher nicht im Export enthalten. In  den Adapter-Metadaten im Integration Repository sind solche Attribute als nicht transportierbar gekennzeichnet (sie hängen also vom Adaptertyp ab und sind fix). Nach einem Import von neuen Objekten müssen die nicht transportierten Attribute im Zielsystem ergänzt werden. Diese Ergänzungen bleiben bei jedem weiteren Import des Objekts erhalten.

Es gibt auch Attribute, die umgesetzt werden: Die Adresse einer dezentrale Adapter Engine setzt der Integration Builder beim Import beispielsweise auf die Adresse der zentralen Adapter Engine um, da die Adresse der dezentralen Adapter Engine in der Produktiv-Landschaft voraussichtlich nicht mehr gültig ist.

Versionierung

Im Gegensatz zu Importen in das Integration Repository legt die Versionsverwaltung im Ziel-Directory stets eine neue Version für das zu importierende Objekt an. Objektversionen des Ausgangs- und des Ziel-Repository sind also unabhängig voneinander, so dass Sie auch Konfigurationsobjekte importieren können, deren Version älter ist als die aktuell im Directory vorhandene (siehe auch: Versionierung bei Transporten).

Aktivitäten

...

       1.      Führen Sie den Transport über das Filesystem durch.

       2.      Führen Sie alternativ den Transport über den Change Management Service durch.

       3.      Sie können nach bereits durchgeführten Transporten suchen (siehe: Suchen von Transporten).