Versionierung bei Transporten 

Allgemeines

Man transportiert XI-Objekte innerhalb der Exchange Infrastructure aus folgenden Gründen:

·      Um Objekte aus dem Integration Repository auszuliefern.

·      Um eine Entwicklung im Integration Repository oder eine Konfiguration des Integration Directory getrennt testen zu können.

Sie können XI-Objekte über den Export und Import von Dateien transportieren (siehe: Transport über das Filesystem) oder über den Change Management Service (siehe : Transport über den Change Management Service).

Transport-Logistik

Integration Repository

Objekte des Integration Repository haben stets ein Original-Repository, das heißt, ein Integration Repository, aus dem ein Objekt ursprünglich stammt. Innerhalb eines Integration Repository unterscheiden Sie die originalen Objekte von den Kopien über ein Attribut der zugehörigen Software-Komponentenversion.

Wegen des Originalitätsprinzips sind Transportlandschaften für Integration Repositories sternförmig:

Änderungen an einem Objekt sollten nur in dem Integration Repository vorgenommen werden, aus dem das Objekt ursprünglich stammt. Die neuen Versionen dieses Objektes werden dann beim Import in das Ziel-Repository angelegt, so dass das Objekt in beiden Repositories die gleiche Version hat, siehe Grafik:

Wie hier dargestellt ist, sind die Objektversionen in den verschiedenen Repositories stets konsistent. Folgende Mechanismen stellen dies sicher:

·      Generell sollten Sie Objekte im Ziel-Repository gegen Eingabe sperren (siehe Objekteigenschaften in Software-Komponentenversionen). Dennoch können Sie vorübergehend Objekte lokal im Ziel-Repository ändern, was allerdings zu einem Konflikt beim Import führen kann (siehe: Konflikte beim Import von Objekten).

·      Beim Import älterer Objektversionen in ein Ziel-Repository werden dort schon vorhandene neuere Objektversionen nicht überschrieben. Die importierte ältere Version ist nach dem Import in der Objekt-Historie sichtbar, die neuere bleibt die als die aktuelle Version gültig.

Letzteres bedeutet insbesondere, dass mehrere Importe in ein Repository unabhängig von ihrer Reihenfolge zum gleichen Ergebnis führen.

Integration Directory

Zur Konfigurations-Zeit bietet es sich an, die Konfiguration zunächst in einem Test-Directory zu testen. Nach erfolgreichen Tests können Sie dann die Konfigurations-Objekte im Test-Directory in das Directory der Produktivlandschaft transportieren.

SAP empfiehlt, bei dieser Prozedur mit einem System Landscape Directory (SLD) zu arbeiten, in dem sowohl die Systeme der Test- als auch die Systeme der Produktivlandschaft erfasst sind. Über Gruppen und Transport-Targets im SLD setzen Sie die Systemnamen des Test-Systems automatisch in Systemnamen des Produktivsystems um. (Siehe Hinweis 764393 für alternative SLD-Szenarien).

Zur Konfigurations-Zeit geht es bei Transporten also nicht darum, Objekte auszuliefern, sondern vor dem produktiven Einsatz von der Exchange Infrastructure die Konfiguration getrennt von der Produktivlandschaft testen zu können:

·      Im Integration Directory gibt es keine Software-Komponentenversionen. Sie können alle Objekte eines Scenarios, Partners, Services oder einzelne Objekte exportieren.

·      Es wird keine große Transportlandschaft mit vielen Directories benötigt. In der Regel reicht ein Test-Directory und ein Produktiv-Directory aus. Parallel dazu gibt es ein Test-Repository und ein Produktiv-Repository. Falls erwünscht, können Sie natürlich auch eine drei- oder vierstufige Testlandschaft aufbauen.

Die Objekte des Integration Directory verweisen auf Objekte des Integration Repository. SAP empfiehlt daher, zuerst die notwendigen Objekte Integration Repository zu transportieren und dann die Objekte des Integration Directory. Veweist 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.

In den Test-Szenarien während der Konfigurations-Zeit geht es zudem nicht darum, dass immer die aktuellste Version aus dem Test-Directory in das Produktiv-Directory transportiert wird – möglicherweise erweist sich ja eine ältere Version als die geeignetere. Im Gegensatz zu Importen beim Integration Repository erzeugt die Versionsverwaltung daher beim Import von Objekten in ein Directory immer eine neue Version für die Objekte:

In dem Beispiel wurde die initiale Version V1 eines Objektes aus dem Test-Directory exportiert. Weil beim Import im Produktiv-Directory stets eine neue Versionskennung erzeugt wird (hier V3’ für V1), können Sie Version V1 in das Produktiv-Directory importieren, obwohl vorher bereits die neueren Versionen V2 und V3 importiert wurden.