Versionshistorie

Eine sehr nützliche Funktion in SAP ist die "Versionshistorie". Die Versionshistorie steht vor allem bei den Transaktionen zur Verfügung, die mit ABAP-Code arbeiten, wie dem Object Navigator (Transaktion SE80), Transaktion SE38 (ABAP Editor), Transaktion SE24 (Class Builder) oder Transaktion SE37 (Function Builder).

Versionsunterschiede

Bei jedem Transport eines Entwicklungsobjekts wird eine Version gezogen, selbst wenn zur vorhergehenden Version keine Änderungen vorgenommen wurden.
Zwischen verschiedenen Versionen können Änderungen am Entwicklungsobjekt vorliegen, aber müssen nicht. Es ist schade, dass in der Versionshistorie nicht die Versionen mit Versionsunterschieden kenntlich gemacht werden. Daher ist es dann immer etwas try&error passende Versionen mit Versionsunterschiedenen zu identifizieren. Es wäre ohne weiteres denkbar, dass SAP für jedes Entwicklungsobjekt einen Hashwert bestimmt und bei Unterschieden zwischen Hashwerten bei Versionen dann auch z. B. farblich erkennbar Versionen ohne/mit Unterschieden gekennzeichnet werden.

Bei Transporte von Kopien wird nicht der eigentliche Transportauftrag, der irgendwann ins Produktivsystem transportiert, sondern lediglich eine Referenz auf den Transportauftrag oder auf eine Transportaufgabe, bzw. mehrere referenzierende Transportaufträge oder Transportaufgaben.
Die Transporte von Kopien lassen sich nur ins Qualitätssystem transportieren, aber lassen sich nicht ins Produktivsystem transportieren.
Alle Objekte, die in einem "Transporte von Kopien" enthalten sind, ziehen eine Version - sofern das Entwicklungsobjekt grundsätzlich Versionen zulässt.

Manchmal wird über einen längeren Zeitraum ein Entwicklungsobjekt nicht transportiert, wenn z. B. eine Entwicklung komplex und zeitaufwendig ist und gleichzeitig im Entwicklungssystem Testdaten bereitstehen, sodass kein Transport ins Qualitätssystem nötig ist.
Es kann dann auch eine Version manuell vom Entwickler gezogen werden. Das macht Sinn als Backup der bisher vorgenommenen Entwicklungen. Manchmal greift man auch tiefer in ein Entwicklungsobjekt ein und ist sich nicht sicher, ob die vorgenommen Änderungen erfolgreich sein werden und man möchte ein Backup haben, um auf den Stand vor der Änderung zurückgehen zu können. Dann ist es gut manuell eine Version zu ziehen.

Jede alte Version in der Versionshistorie kann wieder zur aktuell gültigen Version gemacht werden.
Dieser Fall tritt manchmal auf, wenn Änderungen am Entwicklungsobjekt vorgenommen wurden, die sich nicht bewährt haben. Die Änderungen manuell zu identifizieren und zu korrigieren ist zeitaufwendiger (oder nicht möglich) und daher wählt man eine Version aus, die einen stabileren Zustand verspricht als die vorher aktuelle Version. Von der zuletzt aktuellen Version wird automatisch eine Version gezogen. Bewährt es dann also nicht die ältere Version zur aktuellen Version gemacht zu haben, kann man immer auf die vorherige Version (oder jede andere Version in der Versionshistorie) zurückkehren.
Man markiert die alte Version und drückt dann (in neueren SAP-GUI-Versionen) auf die wenig intuitive Schaltfläche "abrufen".

Die vollständige Versionshistorie steht im Allgemeinen nur im Entwicklungssystem zur Verfügung.
Im Qualitäts- oder Produktivsystem, bzw. anderen Systemen als dem Entwicklungssystem sieht man nur die aktuelle Version und an welchem Tag sie in das entsprechende System transportiert wurde.
Man kann jedoch auch andere Systeme als das Entwicklungssystem so konfigurieren, dass eine Versionshistorie geführt wird durch den Profilparameter VERS_AT_IMP, der auf den Wert ALWAYS gestellt wird. Das kann im Produktivsystem durchaus Sinn machen, da man so auch über einen längeren Zeitraum unkompliziert sieht wann Versionen ins Produktiv gelaufen sind. Es ist mir nicht bekannt, ob diese Einstellung beträchtliche Nebenwirkungen hat (wie z. B. großer Speicherbedarf), da ich das im Projektalltag noch bei keinem Kunden gesehen habe.

Sehr häufig ist es nützlich die Versionen zwischen Entwicklungssystem und Produktivsystem zu vergleichen. So erkennt man z. B. sofort wenn ein anderer Entwicklung an einem Entwicklungsobjekt gearbeitet hat und diese Entwicklung noch nicht im Produktiv ist. Findet man keine Versionsunterschiede, dann kann man entspannter die eigenen Änderungen am Entwicklungsobjekt vornehmen.
Abhängig von den Einstellungen im Kundensystem werden beim systemübergreifenden Versionsvergleich die Zugangsdaten zum Zielsystem abgefragt.