Beschreiben der Softwarelogistik für AS-ABAP-basierte SAP-Systeme

Es gibt mehrere Gründe für den Aufbau einer Mehrsystemlandschaft. Erstens ist für alle SAP-Systeme eine kontinuierliche Wartung erforderlich. Diese wird entweder durch SAP oder die Kunden selbst angestoßen. Entsprechende Änderungen am Programmcode oder an den Customizing-Daten sind möglicherweise geschäftskritisch und sollten vorher getestet werden. Zweitens erfordern Audits eine detaillierte Protokollierung von Transportaufträgen. Drittens sind ABAP-Repository-Objekte mandantenunabhängig. Das heißt, dass Änderungen, die in einem Mandanten vorgenommen werden, sofort nach der Aktivierung alle weiteren Mandanten desselben SAP-Systems betreffen. Aus diesem Grund sollten Customizing-Einstellungen niemals direkt im Produktivsystem entwickelt oder geändert werden. Mandanteneinstellungen sollten solche Änderungen verhindern. Aus diesem Grund empfehlen wir Ihnen, eine Mehrsystemlandschaft zu verwenden. Mit einer SAP-Lizenz können mehrere SAP-Systeme betrieben werden, wobei jedoch nur eines als produktives SAP-System genutzt werden darf.

Im Folgenden betrachten wir eine Dreisystemlandschaft als Beispiel für eine Mehrsystemlandschaft. Diese drei SAP-Systeme enthalten jeweils einen Arbeitsmandanten sowie, falls erforderlich, weitere Mandanten. Im Hinblick auf die Konsistenz der Customizing-Einstellungen über alle Systeme hinweg würde es einfacher sein, wenn diese drei Arbeitsmandanten den gleichen Namen (dreistellige Nummer) haben.

Eine Dreisystemlandschaft ermöglicht das folgende empfohlene Vorgehen:

• Das erforderliche Customizing der SAP-Standard-Prozesse wird im Entwicklungssystem vorgenommen. Sie können auch eigene Programme entwickeln oder bestehende Programme im Entwicklungssystem ändern.

• Anschließend übertragen Sie die von Ihnen vorgenommenen Customizing-Einstellungen sowie alle Änderungen am Repository (Entwicklungen, Korrekturen und ggf. Modifikationen) in das Qualitätssicherungssystem (kurz auch Testsystem genannt). Im Testsystem können Sie in einer stabilen Umgebung prüfen, ohne den Produktivbetrieb zu beeinträchtigen.

• Nach einem erfolgreichen Test können dann alle in das Testsystem importierten Objekte und Einstellungen in das Produktivsystem übertragen werden.

Die SAP-Systeme in einer Systemlandschaft müssen eindeutige dreistellige Beschreibungen haben, z.B. DEV (Entwicklung), QAS (Qualitätssicherung) und PRD (Produktion). Diese hier und in anderen Schulungen verwendeten Kürzel werden im SAP-Umfeld international genutzt.

Die SAP-System-ID (kurz: SID) beginnt immer mit einem Buchstaben und kann Buchstaben und Ziffern enthalten. SIDs umfassen immer drei Zeichen. Einige SIDs sind von SAP reserviert. So kann die SID SAP beispielsweise nicht zum Installieren eines SAP-Systems verwendet werden. Weitere Informationen sind im Installationsleitfaden zum jeweils zu installierenden SAP-Systemtyp zu finden.

In einer Mehrsystemlandschaft werden Transportaufträge genutzt, um Änderungen an Repository-Objekten (oder neu angelegte Objekte) und kundendefinierte Customizing-Einstellungen aus einem SAP-System in ein anderes zu übertragen.

Der Transport Organizer (Transaktion SE09) unterstützt Sie bei der Protokollierung

• Änderungen an Repository-Objekten und an mandantenunabhängigem Customizing als Workbench-Aufträge
• Änderungen am mandantenabhängigen Customizing analog zu Customizing-Aufträgen

Beide Auftragstypen werden auch unter der Bezeichnung Transportaufträge zusammengefasst.

Der Entwicklungsprojektleiter legt ein Projekt an und aktiviert dessen Integration in die Transportverwaltung, d.h. die Aufzeichnung von Transportaufträgen für dieses Projekt. Danach legt er eine – möglichst geringe – Anzahl von Transportaufträgen zu diesem Projekt an und ordnet die Entwickler den Transportaufträgen zu. Der Entwicklungsprojektleiter ist auch verantwortlich für die spätere Freigabe der Transportaufträge, wenn die entsprechende Entwicklung fertiggestellt wurde.

Der Entwickler wird vom Entwicklungsprojektleiter einem oder mehreren Transportaufträgen zugeordnet. Im Rahmen seiner Transportaufträge, die wiederum einem Projekt zugeordnet sind, führt er Entwicklungen durch. Hierbei kann es sich um das Anlegen oder Ändern von Repository-Objekten oder Customizing-Einstellungen handeln. Der Entwickler arbeitet im Entwicklungssystem.

Der Tester ist für die fachliche Abnahme zuständig. Diese fachliche Abnahme wird im Qualitätssicherungssystem durchgeführt. Das Qualitätssicherungssystem ist eine Kopie des Produktivsystems, sodass mit realistischen Daten und realistischen Prozessabläufen getestet werden kann.

Der Transportadministrator ist für das Aufsetzen eines Transportkonzepts zuständig. Er führt die Importe der Transportaufträge strukturiert durch.

Für jeden Mitarbeiter, dem der Transportauftrag zugeordnet ist, legt der Transport Organizer automatisch eine Aufgabe zu diesem Transportauftrag an. Wenn ein Entwickler dem Transportauftrag ein neu angelegtes oder geändertes Repository-Objekt zuordnet, wird das Anlegen bzw. die Änderung dieses Repository-Objekts in der Aufgabe dieser Person protokolliert.

Workbench-Aufträge sind Transportaufträge für den Transport mandantenabhängiger Customizing- und Repository-Objekte.

Customizing-Aufträge sind Transportaufträge für den Transport aus mandantenunabhängigem Customizing.

Betrachten wir die Änderungen von Repository-Objekten (die zu Workbench-Aufträgen führen) als Beispiel.

Wenn ein Repository-Objekt von einem Entwickler bearbeitet und in einen Transportauftrag aufgenommen wird, ist die Bearbeitung des Objekts ausschließlich für die Entwickler möglich, die diesem Transportauftrag zugeordnet sind. Dazu wird eine Objektsperre angelegt.

Jeder Entwickler, der dem Transportauftrag zugeordnet ist und das Objekt bearbeitet, legt automatisch einen entsprechenden Eintrag in der Objektliste seiner Aufgabe an. So lässt sich auch nachträglich feststellen, welche Entwickler das Objekt tatsächlich bearbeitet haben.

Bei der Freigabe des Transportauftrags löscht das System die Objektsperren. Infolgedessen können andere Entwickler die Objekte erneut bearbeiten (und die Änderungen in einem anderen Transportauftrag aufzeichnen, das System sperrt die Objekte dann wieder entsprechend).

Bei der Freigabe eines Transportauftrags legt der Transport Organizer auch Versionen der Repository-Objekte an, die einen Vergleich und Zugriff auf frühere Versionen von Repository-Objekten ermöglichen. Ältere Versionen von Repository-Objekten können auf diese Weise angezeigt und zurückgeholt werden.

In diesem Video erfahren Sie mehr über die Schritte im Entwicklungsprozess:

Sobald die Entwicklungsarbeiten bezüglich einer testbaren Einheit aus Sicht der Entwickler abgeschlossen sind, geben sie die zugehörige Aufgabe frei. Diese Aktion überträgt die Objektliste der Aufgabe in den Transportauftrag. Haben alle Entwickler ihre Aufgabe freigegeben, kann der Entwicklungsprojektleiter den Transportauftrag freigeben. Auf diese Weise fasst ein Transportauftrag Customizing-Objekte oder Repository-Objekte zusammen, die eine testbare Einheit bilden.

Transportaufträge können transportierbar oder lokal sein. Der Transport Organizer klassifiziert automatisch anhand der im Transportauftrag enthaltenen Objekte und der konfigurierten Transportlandschaft. Nur bei transportierbaren Transportaufträgen wird nach der Freigabe der Export angestoßen. Export bedeutet, dass das System die Objekte des Transportauftrags aus der Datenbank des Entwicklungssystems in eine Datei auf dem Dateisystem kopiert (siehe folgende Abbildung).

Der Transport von Transportaufträgen gliedert sich in die Phasen Export und Import: Die Objekte des Transportauftrags werden aus dem Entwicklungssystem exportiert und dann – in einem separaten Schritt – in das Zielsystem importiert, z.B. in das Qualitätssicherungssystem und das Produktivsystem.

• Export: Nach der Freigabe eines transportierbaren Transportauftrags werden die Customizing-Objekte und Repository-Objekte von der Quelldatenbank in ein zentrales Transportverzeichnis auf Dateisystemebene kopiert. Diese Schritte werden im Transportprotokoll des Transportauftrags aufgezeichnet.
• Import: Der Import in das Zielsystem erfolgt im Allgemeinen nicht automatisch, sondern wird vom Transportadministrator im Transport Management System (TMS) ausgelöst. Dabei werden die Customizing- und Repository-Objekte aus dem zentralen Transportverzeichnis auf Dateisystemebene in die Datenbank des Zielsystems kopiert. Die Importprotokolle, die automatisch angelegt werden, können dann geprüft werden.

Das zentrale Transportverzeichnis liegt physisch in einem Dateisystem, auf das alle SAP-Systeme, die zu der Systemlandschaft gehören, Lese- und Schreibzugriff haben müssen.