Ich will es mal etwas vorsichtig ausdrücken: Der technische Aspekt von SAP ist für Anfänger nicht ganz überschaubar und auch nicht sonderlich einladend. Es gibt zwar einige Ähnlichkeiten mit anderen IT-Systemen, aber auch viele Besonderheiten. Ich wurde kürzlich an diese Tatsache erinnert, als ich mit einigen SAP-Einsteigern hier bei Basis Technologies sprach. Am Ausdruck ihrer Gesichter konnte ich ablesen, dass ich zu viel an technischem Wissen voraussetzte.

Nach diesen Erfahrungen dachte ich, es wäre hilfreich für die Menschen, die erst kürzlich in die SAP-Welt eingetaucht sind, zur Einführung einige Informationen zusammenstellen. Gleichzeitig hoffe ich, dass auch andere Interessierte ein paar Anregungen mitnehmen können. Im ersten Teil (weitere folgen in Kürze) werde ich mich mit SAP-Systemen, Mandanten, Transporten, Landschaften und allgemeinen Design-/Architekturmustern befassen, die auf die Anwendungsentwicklung von Unternehmen mit SAP-Software Einfluss haben. Teil 2 wird sich auf fortgeschrittenere Aspekte der Einrichtung und Gestaltung von Landschaften konzentrieren, und in Teil 3 werde ich Möglichkeiten darstellen, mit denen sich die Verwaltung komplexer SAP-Systeme vereinfachen lässt.

Inhalt

Beginnen wir also mit den Grundlagen und arbeiten uns von dort aus vor. Bevor wir eine Landschaft aufbauen können, müssen wir uns mit SAP-Systemen, Mandanten, Arten von Objekten/Daten und dem Konzept von Transporten vertraut machen.

SAP-System

Unter einem SAP-System versteht man eine Installation eines SAP-Produkts. Die Rolle, die das System übernimmt (Entwicklungssystem, Produktivsystem usw.), kann konfiguriert werden und wird in der Regel über die System-ID (SID) per Namenskonvention referenziert. Beispiel:

GFD wäre also das Entwicklungssystem der globalen Landschaft für Finanzwesen, während EHP das europäische Produktivsystem für Personalwesen wäre.

Datentypen und Mandanten

Der Mandant ist definiert als eine für sich handelsrechtlich, organisatorisch und datentechnisch abgeschlossene Einheit innerhalb eines SAP-Systems. Einige Daten werden nur unter bestimmten Mandanten (mandantenabhängige Daten) abgelegt. Dazu gehören z. B. Anwendungsdaten, Benutzerkonten und mandantenspezifisches Customizing. Die Geschäftsdaten innerhalb eines Mandanten sind vor allen anderen Mandanten geschützt.

Andere Daten wiederum werden systemübergreifend gespeichert und stehen allen Mandanten im System zur Verfügung (mandantenunabhängige Daten). Dazu gehören das mandantenübergreifende Customizing und die zugrunde liegenden Repository-Objekte, die die Funktionsweise des Systems bestimmen, einschließlich des Data-Dictionary (z. B. Tabellen und Strukturen) und der Workbench (Berichte, Programme usw.).

Zwischen den Customizing-Tabellen bestehen häufig starke Abhängigkeiten. Aus diesem Grund werden Tabellen nicht einzeln gepflegt, sondern als Customizing-Objekte. Ein Customizing-Objekt kann sowohl mandantenspezifische als auch mandantenübergreifende Tabellen enthalten.

Zu einer Standardinstallation gehören die Mandanten 000, 001 und 066. Der Mandant 000 wird grundsätzlich nur als Arbeitsmandant für Aufgaben wie z. B. Support-Package-Upgrades oder die Implementierung zusätzlicher Sprachen verwendet. Für andere Aufgaben sollte Mandant 000 nicht als Arbeitsmandant verwendet werden. Mandant 066 dient bestimmten Remote-Services von SAP.

Über die Standardmandanten hinaus können Kunden auch Mandanten im Bereich 002–999 zur eigenen Verwendung anlegen. null

Systemlandschaft

Eine Systemlandschaft ist eine logische Gruppe von Systemen mit unterschiedlichen Zwecken, die auf demselben SAP-Produkt/-Release basieren.

Die am häufigsten verwendete Landschaft ist die 3-Systemlandschaft. Das bedeutet, dass drei Systeme in der Landschaft vorhanden sind. In der Regel sind dies Entwicklungs-, Qualitätssicherungs- und Produktivsystem. Welche Funktionen haben die Systeme?

Das Produktivsystem hat höchste Priorität. Es wird von Hunderten, wenn nicht Tausenden von Benutzern „produktiv“ verwendet und muss daher immer verfügbar, funktionsfähig und stabil sein. Dies ist auch das System, in dem Audits durchgeführt werden, sodass hier nur Produktionstransaktionen ausgeführt werden sollten. Am anderen Ende steht das Entwicklungssystem. Dies ist das System, in dem Änderungen, Korrekturen und Projekte bearbeitet werden (außer bei mehrgleisiger Konfiguration, die in Teil 2 behandelt wird). Es wird häufig von Hunderten von Entwicklern oder Funktionsberatern genutzt. Manchmal müssen Arbeiten rückgängig gemacht oder Dummy-Daten erstellt werden, um neue Funktionen zu testen. Solche Aktivitäten dürfen nicht im Produktivsystem selbst stattfinden. Es ist „gesperrt“, um direkte Änderungen an Customizing- oder Repository-Objekten zu unterbinden (siehe Abschnitt über Transporte weiter unten) und das Risiko unerwarteter Zwischenfälle zu minimieren.

Die Menge an gleichzeitigen Aktivitäten macht eine zusätzliche Umgebung zwischen Entwicklungs- und Produktivsystem notwendig, die in der Regel als Qualitätssicherungssystem (QA-System) bezeichnet wird. Dieses System hat folgende Aufgaben:

• Bereitstellung einer Arbeitsumgebung mit „produktionsähnlichen“ Daten (kann durch Aktualisierungen oder Bereitstellung von Testdaten erreicht werden)
• Verbindung zu anderen SAP- und Nicht-SAP-Systemen, um Schnittstellen zu testen
• Bereitstellung einer stabilen Abbildung dessen, was mit dem nächsten „Release“ im Produktivsystem vorhanden sein wird
  

Temporäre und optionale Systeme

Neben dieser typischen Landschaft kann es zahllose andere Varianten geben. Im Folgenden sind einige Beispiele genannt:

Wie Sie sehen, gibt es viele Gründe, warum zusätzliche Systeme entweder temporär oder permanent in die Landschaft aufgenommen werden können.

Systemaktualisierung

Über eine Systemaktualisierung können die Daten, das Customizing und das Repository eines Systems abgeglichen werden, damit sie nicht im Laufe der Zeit auseinander driften (z. B. durch abgebrochene Änderungen). Für Testzwecke kann sichergestellt werden, dass die Daten im System aktuell sind. Eine Aktualisierung ist im Grunde eine Kopie aus einem anderen System, die den Inhalt des zu aktualisierenden Systems überschreibt. Dazu gehören in der Regel Aufgaben zum Umbenennen des Systems nach dem Aktualisieren und das Einrichten von Schnittstellen und Benutzerkonten mit demselben Status, den sie vor der Aktualisierung hatten. Die Entscheidung, ob und von wo aus ein System aktualisiert werden soll, hängt vom jeweiligen Systemtyp ab. Hier eine Zusammenfassung verschiedener Optionen:

Transporte: Änderungen in der Landschaft verschieben

Über SAP-Transportaufträge (oder kurz „Transporte“) werden Änderungen erfasst und zwischen Systemen oder Mandanten verschoben. Ein Transport kann Customizing- und/oder Workbench-Inhalte enthalten und durchläuft den folgenden Lebenszyklus:

1. Transportauftrag anlegen: erstellt einen leeren Transport als Container
2. Änderungen erfassen: speichert Änderungen am Customizing oder das Anlegen/Ändern von Repository-Objekten
3. Transport freigeben: sperrt den Transportinhalt und ermöglicht den Export und Import in andere Systeme/Mandanten
4. Importieren: Prozess, mit dem die in einem Transport enthaltenen Änderungen in das Zielsystem überführt werden

Ursprünglich wurden Transporte in SAP zur Handhabung von Änderungen an ABAP-Objekten angelegt. Inzwischen ist das Konzept der Transporte auf HANA-, BW-, Java-Objekte usw. zur Erfassung von Änderungen über das Enhanced Change and Transport System (CTS+) erweitert worden.

Im Rahmen von großen und komplexen Projekten ist es vorstellbar, dass Teams von Entwicklern und Beratern Hunderte oder Tausende von Transporten anlegen. Alle Transporte müssen kontrolliert, verwaltet und koordiniert werden, damit immer die richtigen Änderungen zur richtigen Zeit und in der richtigen Reihenfolge in die nachgelagerten Systeme der Landschaft gelangen.

Fazit

Damit sind wir am Ende von Teil 1 angelangt. Ich hoffe, Sie fanden die Informationen hilfreich – entweder als Grundlage für Ihre bevorstehende Arbeit mit SAP oder als Anregung für die zukünftige Verwaltung Ihrer SAP-Landschaft. In Teil 2 der Blogreihe werde ich auf diesen Grundlagen aufbauen und über Erweiterungen des Landschaftsdesigns wie zweigleisige Setups, „1-to-many“-Konfigurationen und Mehrmandantensysteme sprechen.

Wenn Sie möchten, können Sie sich in Bezug auf Ihr Unternehmen mit folgenden Fragen befassen:

• Wie viele Systeme brauchen wir in unserer Landschaft?
• Wann brauchen wir ein separates Sandbox-System und nicht nur einen Sandbox-Mandanten im Entwicklungssystem?
• Wie viele Mandanten brauchen wir in welchen Systemen?
• Welche temporären Systeme könnten sinnvoll sein, und was wären mögliche Auslöser dafür?
• Brauchen wir separate Tracks für bestimmte Projektentwicklungen?

Möchten Sie mehr darüber wissen, wie Sie mit Automatisierungssoftware von Basis Technologies die beschriebenen Mandanten und Systeme sicherer und effektiver verwalten? Dann sprechen Sie uns einfach an. Wir helfen Ihnen gerne weiter.