System Landscape Directory (SLD)

 Eine SAP-Systemlandschaft ist meistens heterogen. Das heißt , in einer Unternehmenslandschaft gibt es unterschiedliche Anwendungssysteme verschiedener Hersteller, die miteinander agieren. Um die Komplexität zu optimieren, hat SAP das System Landscape Directory entwickelt. Diese Landkarte stellt die Topologie der Entwicklungen in der eigenen Systemlandschaft strukturiert und zentral dar.

Das SLD dient als zentrales Systeminformationsverzeichnis der gesamten Landschaft. Es enthält die technischen Beschreibungen der in der Landschaft installierten und installierbaren Systeme, Produkte und Softwarekomponenten.

Das SLD trägt unter anderem dazu bei, wichtige Informaitonen, z.B. die für die Konfiguration benötigten Softwarekomponenten, an den SAP Solution Manager weiterzuleiten. Diese Informaitonen werden als Grundlage für das Landschaftsmanagement des Unternehmenssoftware-Lifecycles benötigt. Das SLD kann somit als Standalone-System, das zentral Landschaftsinformationen für alle beteiligten Systeme zur Verfügung stellt, betrachtet werden.

Common Interface Model

Das Common Interface Model (CIM) sit ein Standard der DMTF (Distributed Management Force) und basiert auf dem objektorientierten Modelierungsansatz. Die DMTF ist ein Konsortium aus verschiedenen Unternehmen zur Organisation einheitlicher Open-Source-Standards, die sich über verschiedene aufkommende und traditionelle IT-Infrastrukturen wie Cloud, Virtualisierung, Netzwerk , Server und Storage erstrecken.

https://www.dmtf.org/about

Der Vorteil dieser Standards ist die einfache Erweiterbarkeit der Beschreibungsschemata zu den einzelnen Elementen in einer Systemlandschaft im Rahmen von Kernklassen. SAP verwendet diese Norm in SAP-spezifischen Klassen. So werden z.B. für unterschiedliche Systeme unterschiedliche Objekte , basierend auf Klassen, erzeugt. Klassen können eine Ansammlung von anderen Objekten als Attribute umfassen. Damit diese Klassen Erweiterungen wie neue Attribute umfassen. Damit diese Klassen Erweiterungen wie neue Attribute erhalten können, lassen sich diese mittels Beschreibungs-schemata einfach vorgeben und auf die jeweilige Klasse übertragen.

Eine Besonderheit des CIM ist die Beschreibung der Verbindung zwischen den Klassen. Über Referenzschlüssel können z.B. zwei Klassen verbunden werden. Eine Assoziation ist eine Klasse , die zwei Referenzschlüssel beinhaltet und eindeutig einer CIM-Instanz zuzuordnen sein soll.

—————————————————————————————————————————-

Definition CIM-Instanz

Eine Instanz ist eine Ausprägung einer Klasse oder ein Objekt der Klasse. Alle in der Klasse definierten Eigenschaften besitzen bei einer Instanz feste Werte.

Beispiel: Die CIM-Klasse SAP_Product kann Instanzen besitzen, wie z.B. mySAP und R/3 Enterprise.

—————————————————————————————————————————

Verständnis von Landschaftsbeschreibung - Produkt , Produktinstanzen und Softwarekomponenten

Die Beschreibung - oder "Modellierung" - von Systemlandschaften basiert auf einigen Entitäten, die Produkte genannt werden.

Produktinstanzen und Softwarekomponenten. Diese Begriffe und die Modell-Entitäten, die sie beschreiben, tauchen in den Management- und Entwicklungssystemen von SAP auf. Was für Sie vielleicht noch wichtiger ist, ist, dass sie die Grundlage für die Beschreibung von Landschaften im SAP Solution Manager sind, die Sie z.B. für die Systemüberwachung oder die Wartung benötigen.

Das Verständnis dieser Instanzen ist also notwendig für ein erfolgreiches Management dieser Landschaften. 

Hier sehen Sie, wie Sie die SAP-Begriffe auf ein Auto übertragen können (natürlich hat ein Auto - wie die Produkte von SAP - viel mehr Teile):

Produkt: Ein Produkt ist das Modell eines Autos in verschiedenen Ausführungen und einschließlich des Fahrzeugbriefs (Ihr Vertrag zur Nutzung des Produkts) und der Garantiebescheinigung (des Wartungsvertrags). Ein Produkt ist also das, was Sie kaufen

Softwarekomponenten (SCs): Softwarekomponenten sind die Elemente, die in einem Stück entwickelt werden und die Sie normalerweise als ein Teil sehen würden - die Karosserie, die Fenster und die Räder. Es gibt optionale Komponenten, wie Add-Ons, wie z.B. Transportkoffer, Antenne, Ersatzrad....

Produktinstanzen: Softwarekomponenten können einzeln betrachtet und gehandhabt werden, aber wenn es darum geht, ein Produkt einzurichten, gehören einige Teile einfach zusammen: Ein Satz Fenster gehört nur zu einem Wagentyp, Vorder- und Hinterrad sind ein passender Satz. Solche Sätze von Softwarekomponenten, die zusammengehören, sind die Produktinstanzen.

Hier sind einige Punkte, die Sie wissen sollten. Über Produktinstanzen Bescheid wissen: Sie

- können in mehreren Produkten wiederverwendet werden - siehe z.B. das Rad-Set

- können eine oder mehrere SCs enthalten

- können optional sein - siehe auch das Add-On

Verwendung: Was Sie am Ende verwenden, ist eine bestimmte Konfiguration eines bestimmten Produkts.

Die Elemente des Produkts - ihr Zweck

Was ist nun der Zweck der oben beschriebenen Elemente?

Produkte definieren einen Gesamtumfang, eine Reihe von Funktionen zur Lösung eines Geschäftsbedarfs. Es wäre nicht hilfreich, in Softwarekomponenten zu denken, wenn es um Geschäftsprozesse insgesamt geht. Das ist auch wichtig, wenn es um die Wartung einer IT-Landschaft geht: Geschäftsprozesse und damit die Produkte sind die Einheiten eines Upgrades, die Sie sehen müssen.

Softwarekomponenten sind die Einheiten, die entwickelt werden, aber wie besprochen, machen aus der Perspektive einer Installation oder eines Updates nur bestimmte Sätze von SCs Sinn - bei der Installation und noch mehr bei der Systemwartung werden Sie also mit diesen Sätzen, den so genannten Produktinstanzen, umgehen.

Produkte und Produktinstanzen werden verwendet, um Software zu beschreiben, die SAP ausliefert. 

Es sind auch diese Entitäten, die Sie verstehen müssen, um Ihre Systeme zu warten.

Diese beiden Dinge sind wichtig, weil sie definieren, was Sie bei der Verwaltung Ihrer Systeme manuell tun müssen.

Produkte, ihre Elemente und die Komplexität, mit der Sie umgehen müssen

Auch wenn sich auch hier mehr Ähnlichkeiten mit Autos finden lassen, werden wir von nun an abstrakter vorgehen.

Während die Grundlagen von Produkten, Softwarekomponenten und Produktinstanzen mit einer einfachen Analogie erklärt werden können, muss die Zuordnung zu Produktsystemen sorgfältig erfolgen - der Grund dafür ist, dass wir es mit Produkten in verschiedenen Versionen zu tun haben und ihre Teile durch Wiederverwendung Abhängigkeiten aufweisen, was große Vorteile hat (offensichtlich weniger Versionen von Objekten insgesamt), aber durch Verschachtelung und Versionierung zu einer gewissen Komplexität führt, die sowohl in den Produktdefinitionen als auch in den Produktsystemen auftaucht, mit denen die Produkte in der Landschaft betrieben werden

Produkte

Produkte sind Anwendungen, die Sie kaufen und betreiben, um Ihre Geschäftsanforderungen zu erfüllen.

=> Produkte werden oft über mehrere technische Systeme hinweg installiert, zum Beispiel um Dual-Stack-Installationen zu vermeiden

=> Produktinstanzen bestehen aus Softwarekomponenten, die - wiederum - in verschiedenen Produktinstanzen wiederverwendet werden können.

=> Produktinstanzen enthalten andere Produktinstanzen auf zwei Arten, die unterschiedlich gehandhabt werden müssen, als explizite Includes oder implizite Includes

Produktsysteme

Ein Produktsystem ist eine Gruppe von einem bis mehreren technischen Systemen, die zur Installation einer Produktversion verwendet werden

=> Technische Systeme können in mehr als einem Produktsystem wiederverwendet werden

=> Die Zuordnung von technischen Systemen zu Produktsystemen erfolgt auf der Ebene der Produktinstanzen.

In einem technischen System finden Sie also Produktinstanzen mehrerer Produktversionen, aber Sie können nur die Produktinstanzen einem Produktsystem zuordnen, die zu diesem einen Produkt gehören:

Abbildung : Die Produktversionen A und J sind mit einigen Überschneidungen auf zwei technischen Systemen ABP und JAP installiert und werden in zwei Produktsystemen ABP und JVP verarbeitet.

Hier ist die Situation in der Abbildung erklärt

=> Ein hypothetisches Produkt A ist in der aktuellen Version AS ABAP und AS Java basiert. Produkt A

=> Hat die Produktinstanzen A1.A2 (als ABAP-basiert) und A3 (als Java-basiert).

=> Es enthält außerdem eine Produktinstanz PI J1

=> Produktinstanzen von Produkt A sind auf dem AS ABAP-basierten technischen System ABP und dem AS Java-basierten technischen System JAP installiert.

Produkt J in der aktuellen Version ist AS Java-basiert und hat

=> Produktinstanz J1 und J2.

Die => PIs J1 und J2 sind auf dem AS Java-basierten technischen System JAP neben der PI A3 installiert.

Die Einbeziehung von Produktinstanzen kann explizit oder implizit erfolgen. Details werden später erklärt.

Wie man mit Produktsystemen umgeht

Auch wenn Produktinstanzen mehrerer Produktversionen auf demselben technischen System installiert sind, sprechen Sie in der Wartung eine Produktversion an, die Sie pflegen wollen.

Versionierung

Produkte bestehen, wie wir gelernt haben, aus Produktinstanzen. Ein Produkt ist etwas abstrakt, zum Beispiel . Im wirklichen Leben werden Sie immer mit einer Produktversion zu tun haben. Daher ist es notwendig und ausreichend, die richtige Produktversion zu wählen. Auch wenn in einem Produktsystem mehr als ein Produkt gehandhabt werden kann, kann in einem Produktsystem nur eine Version jedes Produkts existieren.

Umgang mit Produkten und ihren Bestandteilen

Der Gesamtprozess umfasst die folgenden Instrumente und Schritte:

Abbildung: Prozesse, Landschaftsdaten und Werkzeuge der Landschaftsdatenverwaltung im Anwendungslebenszyklus.

Datenfluss von Landschaftsdaten - Datenquelle und beteiligte Werkzeuge

=> Installationswerkzeuge fügen technische Systeme zu Ihrer Landschaft hinzu.

=> Die Daten der technischen Systeme werden im System Landscape Directory (SLD) gesammelt und an die verschiedenen "Client-Applikationen" weitergegeben:

=> Das SLD erlaubt die Registrierung von technischen Systemen über deren Datenlieferanten.

=> Für neuere Releases enthalten diese Daten bereits das Produkt, die Produktversion und die installierten Produktinstanzen.

=> Bei älteren Releases müssen die Daten zu Product. Produktversion und Produktinstanzen müssen dem technischen System in der LMDB hinzugefügt werden.

=> Das SLD liefert Systemdaten an Anwendungen in der Landschaft, die Systemdaten benötigen, wie z.B. Process Integration, und NWDI benötigen Systeminformationen und lesen diese direkt aus dem SLD. Um diese Informationen in anderen SLD (z.B. im Entwicklungsbereich) verfügbar zu machen, werden die Systemdaten aus dem zentralen SLD durch Weiterleitung in andere SLD-Systeme repliziert.

=> Das SLD liefert Systemdaten für den SAP Solution Manager, der Systemdaten aus dem (zentralen) SLD liest und im SAP Solution Manager zu Landschaftsdaten (z.B. Produktsysteme, Technische Szenarien) anreichert oder aggregiert.

=> Die Landscape Management Database (LMDB) ist mit einer SLD (vorzugsweise nur eine SLD, und in diesem Fall in der Regel die zentrale SLD im produktiven Bereich Ihrer Landschaft) in Ihrer Landschaft verbunden, die als einzige Quelle der Wahrheit für Systemdaten im SAP Solution Manager dient:

- Einlesen des SLD durch vollautomatische Synchronisation

- Anreicherung der Daten der technischen Systeme, wo dies erforderlich ist (einschließlich der manuellen Erstellung neuer technischer Systeme, wo derzeit kein Datenlieferant verfügbar ist)

- Versorgung von Client-Anwendungen im SAP Solution Manager (z.B. SMSY und Monitoring) mit Systemdaten.

=> Basierend auf dem Technischen System wird im SAP Solution Manager folgendes gemacht:

- Produktsysteme für den Maintenance Optimizer (MOpz) und logische Komponenten in der Transaktion SMSY definieren - benötigte technische Systemdaten werden automatisch aus der LMDB synchronisiert (ersetzt diesen Teil des Landscape-Fetch-Jobs, der die Daten aus der LMDB holte)

- Definieren Sie technische Szenarien für die Überwachung von Anwendungen in der LMDB.

=> Verwenden Sie Produktsysteme und technische Szenarien in der Wartung und Überwachung. Änderungen in den technischen Systemen werden automatisch von ihren Datenlieferanten aktualisiert (wo dies nicht möglich ist, muss es manuell erfolgen).

SLD_Objekte in der SAP-Systemlandschaft

Das SLD stellt die Schlüsselrolle in jeder SAP-Process-Orchestration-Landschaft dar. Es beinhaltet alle Informationen über die Softwarekomponenten, Produkte und Systeme, die ebenfalls in unterschiedlichen Phasen des Designs und der Integration benötigt werden. Im SLD lassen sich Entwicklungen bzw. Implementierungen in der Systemlandschaft einer Topologie gleich festhalten und katalogisierung.

Im SLD können Sie zwischen den drei Kategorien Landschaft, Softwarekatalog und Entwicklung unterscheiden. Diese Kategorien erläutern wir näher in den folgenden Abschnitten. 

In der Kategorie Landschaft , auch Systemkatalog genannt, werden alle Informationen der installierten und installierbaren Systeme festgehalten. In dieser Kategorie werden explizit die technischen und die Business-Systeme beschrieben, die ebenfalls in einer „Art“ Landschaft konfiguriert und gruppiert werden.

Technische Systeme sind Anwendungssysteme , die in der Landschaft installiert sind (z.B. SAP Customer Relationship Management [CRM], SAP Solution Manager, SAP Process Orchestration, SAP Hybris E-Commerce etc). Die technischen Systeme im SLD lassen sich in die folgenden fünf Typen unterscheiden:

=> Systeme, die auf dem SAP NetWeaver Application Server (AS) ABAP basieren

=> Systeme, die auf dem SAP NetWeaver Application Server(AS) Java basieren

=> Standalone-Systeme (eigenständige Systeme)

=> Drittanbietersysteme

=> SAP Process Orchestration (PO)

Technisches System, da auf SAP NetWeaver AS ABAP basiert

Ein SAP NetWeaver AS ABAP ist ein Applikationsserver , entwickelt von SAP, der aus mehreren Applikationsserver-Instanzen sowie einer oder mehreren Datenbanken besteht. SAP-Systeme wie SAP ERP, SAP CRM oder SAP Solution Manager basieren auf AS ABAP.

Das Anlegen bzw die Registierung eines technischen System vom Typ ABAP erfolgt in den meisten Fällen komplett automatisch. Dafür müssen das zugehörige SLD und der jeweiligen ABAP-Stack verbunden sein. Dazu werden aufsteigen von SAP NetWeaver AS ABAP Systeminformationen über ein Datenerfassungsprogramm gesammelt und an das SLD weitergeleitet (Transaktion RZ70). Dieser Vorgang wird meistens von der SAP-Basis Abteilung eines Unternehmens durchgeführt.

Es ist nicht zu empfehlen, das technische System vom Typ ABAP manuell anzulegen. Nur wenn eine automatische Registrierung eines technischen ABAP-Systems nicht möglich ist, sollte das manuelle Anlegen angewandt werden.

Technisches System, das auf SAP NetWeaver AS Java basiert

Ein SAP NetWeaver AS Java ist ein Applikationsserver , entwickelt von SAP, der aus mehreren Applikationsserver-Instanzen sowie einer oder mehereren Datenbanken besteht.

Technisches System von Typ Standalone

Wie andere Systeme aus der eigenen Systemlandschaft (ABAP und Java) kann ein technisches SAP-System vom Typ Standalone manuell angelegt werden. Andere technische Systeme vom Typ Standalone, die nicht von SAP zur Verfügung gestellt werden, müssen hingegen generell manuell angelegt werden. Als Standalone-Systeme werden Systeme ohne einen eigenen ABAP-Stack bezeichnet.

Technisches System vom Typ Third-Party

Technische Systeme vom Typ Third-Party (Drittanbietersysteme) sind Systeme , die Drittanbieterprodukte bzw. Drittanbieter-Softwarekomponenten beinhalten.

SLD-Konzept

Jedes Unternehmen kann ein SLD installieren und es in den eigenen Betrieb integrieren. Allerdings muss vorher zur Reduzierung inner-betrieblicher Konflikte ein für die unternehmenseigene IT-Infrastruktur  optimales Konzept erstellt werden.

Mehrere SLD in einer Architektur stellen in einer heterogenen Landschaft keine Seltenheit mehr dar. Basierend auf der Systemverteilung (geografisch oder administrativ) werden Systemgruppen definiert (z.B. wird jede Gruppe einem SLD zugeordnet). Das Konzept , mehrere SLDs einzurichten (Poly.SLD) ist dann sinnvoll, wenn ein Unternehmen seine produktive Umgebung isolieren möchte.

Dann haben nur die Administratoren den Zugriff auf das produktive SLD, wohingegen die Entwickler an einem Designtime SLD arbeiten können.

Ein Vorteil dieser Isolierung und Trennung von SLDs ist die Ausführung von Tests, CIM-Data-Model-Updates und Patches. Mit verschiedenen SLDs lassen sich operative Releases in der Systemlandschaft organisierter umsetzen.

Der richtige Prozess

Sie können das SLD in Ihrer SAP-Landschaft auf unterschiedlichen Wegen implementieren udn ausführen. Jede Option hat Vor- und Nachteile. Deshalb müssen Sie die Installation des SLD gemäß Ihren Landschaftsanforderungen planen.

Das richtige SLD-Konzept zu definieren ist nach wie vor das Grundgerüst der Erstellung einer IT-Strategie. Aus diesem Grund sollten Sie sich mit dem SLD, den SAP-Systemen und deren fundamentalen Konzepten vertraut machen. Stellen Sie daher grundlegende Konzeptfragen , wie z.B.:

=> Benötigen Sie mehrere SLDs? Wenn ja, warum?

=> Wie soll das SLD eingerichtet und ausgeführt werden (als Standalone , auf dem SAP-Solution-Manager-System, auf dem SAP-Process-Orchestration-System etc)?

=> Sollen Daten ausgetauscht werden (nur CIM-Daten oder auch die System- und Softwarekataloge etc.)?

=> Welche Synchronisierungsoptionen wollen Sie planen (unidirectional, volle Synchronisierung etc.)?

=> Wie ist es mit der Releasehomogenität und Kompatibilität (sollen hier für das SLD Systeme gepatscht werden etc.)?

=> Welche Anwendungen können im Fall einer Nichterreichbarkeit betroffen sein?

=> Wie sieht es mit den technischen Einschränkungen aus (Netzwerk, Firewall, Nachrichtenzahl, Hardware, Hochverfügbarkeit etc.)?

SLD und die Systemlandschaft

Nachdem Sie die Anzahl und Typen der SLDs bestimmt haben, sollen Sie jetzt entscheiden, wo die einzelnen SLDs laufen sollen. Es gibt verschiedene Möglichkeiten, und jede Option hat Vor- und Nachteile. In einer normalen Landschaft haben Sie vielleicht eine Mischung aus einem zentralen Laufzeit-SLD, einen zentralen Designzeit-SLD, und einen lokalen SLD .

Nachfolgende zeigt die Vor- und Nachteile eines dedizierten Standalone-SLD-Systems. 

Flexibilität: Es ist einfach, Änderungen in ihrer Systemlandschaft zu planen und durchzuführen , z.B. ist es einfacher, die Ausfallzeiten eines eigenständigen Applikationssystems zu planen, da es keine SLD-Verfügbarkeitsanforderungen für andere Anwendungen mehr gibt, die man berücksichtigen muss.

Darüber hinaus können das SLD-System und die Systeme, die dieses SLD nutzen, verschiedene Releasestände haben. Anwendungen, die dieses SLD verwenden , werden nicht durch das Upgrade des entsprechenden SLD-Systems beeinträchtigt, da das SLD rückwärtskompatibel ist.

Verfügbarkeit: Abhängig von den Verfügbarkeitsanforderungen, die Sie an ein dediziertes SLD stellen würden, könnte ein Hochverfügbarkeits-Setup erforderlich sein.

Kosten: Sie müssen ein zusätzliches System betreiben und warten.

Voriger Post:

https://einsiedlerkreps.blogspot.com/2023/05/der-landschaft-management-prozess-das.html

Der Landschaft Management Prozess - das Big Picture

 Ihre IT-Landschaft besteht aus allen Einheiten, die für den Betrieb Ihres Unternehmens erforderlich sind. Je nach Bereitstellungsmodell handelt es sich dabei um Systeme oder Tenants, Server, Softwareprodukte usw.

Um Ihr Unternehmen am Laufen zu halten und Ihre Prozesse kontinuierlich zu verbessern, ändern sich sowohl Server/Mieter als auch Software ständig.

Wir können von drei Zuständen von IT-Landschaften sprechen:

=> Aktuell verwendete Version - hier läuft idealerweise ein Projekt, in dem die Landschaft analysiert wird, um Input für die Änderungsplanung zu liefern

=> Die nächste Version der Landschaft, die sich in der Phase der detaillierten Planung befindet, gefolgt von der Implementierung auf Systemebene. Oft werden "natürliche" Änderungen eingeführt, wie z. B. das nächste Support Package oder Enhancement Package.

=> Zukunftsvision der Landschaft zur Umsetzung Ihrer Strategie für die langfristige Planung oft mit grundlegenderen Veränderungen, wie z. B. den verwendeten Bereitstellungsmodellen.

Gerade hier ist es wichtig, grundlegend neue Optionen zu erkunden und Empfehlungen für die Umsetzung auf Landschaftsebene zu erhalten.

Der Landschaftsmanagementprozess hilft Ihnen, Ihre IT-Landschaft zu betreiben und weiterzuentwickeln:

=> Informationen über den Status Quo der IT-Landschaft als Grundlage für den Betrieb der Landschaft und die Planung von Änderungen an SAP-zentrischen Lösungen

=> Wege zur Veränderung Ihrer Landschaft umfassen Installationen, Updates, Upgrades und die Umstellung auf SAP S/4HANA und SAP BW/4HANA

=> Informationen, die für die Integration der von Ihnen abonnierten Software erforderlich sind

Die folgende Abbildung zeigt die Entwicklung der Landschaft und ihre Phasen:

Auf dem Bild sehen Sie eine Landschaft, die sich von einer reinen On-Premise-Landschaft zu einer hybriden Landschaft mit Cloud-Systemen entwickelt. Die Frage, wo die Schichten der Landschaft verlaufen und wer für welche Schichten verantwortlich ist, wird in Bereitstellungsmodelle und SAP-Angebote - On-Premise, Cloud und Hybrid beschrieben.

Die Schritte, um von einem Zustand der Landschaft zum nächsten zu gelangen, basieren auf dem Status quo, um die erforderlichen Änderungen zu finden, um die nächste Ebene zu erreichen. Ist diese erreicht, beginnt der Zyklus von neuem. Diese Iterationen sind natürlich nicht klar voneinander getrennt: Im nächsten Schritt wird die "neue Landschaft", die geplant wird, zu derjenigen, die Sie verwenden, und die nächste Stufe geht in die Phase der Detailplanung über.

Die für einen Zyklus der Planung und Umsetzung von Änderungen dargestellten Schritte werden von verschiedenen Personen in einem Unternehmen in unterschiedlichen Rollen ausgeführt. In diesem Dokument finden Sie die beteiligten Rollen und eine Liste der wichtigsten Komponenten und Werkzeuge, die sie für ihre Aufgaben benötigen.

Rollen, ihre Aufgaben, Werkzeuge und Einrichtungen im Landschaftspflegeprozess

An der Bewältigung der erforderlichen Veränderungen sind Menschen in unterschiedlichen Rollen beteiligt. Die wichtigsten Rollen in der Landschaftspflege sind aus den Bereichen:

Business

IT Architektur

Basis Administration

Entwicklung

Daher müssen Business, IT-Architektur und Basisadministration bei der Planung von Änderungen an der Unternehmenslandschaft eng zusammenarbeiten, um erforderliche Änderungen zu identifizieren, sie auf der Grundlage der aktuellen Landschaftsbeschreibung zu planen und zu bewerten und die Implementierung neuer oder zusätzlicher Softwareproduktversionen vorzubereiten.

Abbildung 2: Hauptrollen und ihre Aufgaben im Prozess der Landschaftspflege - das große Bild.

Das Bild beschreibt die am Landschaftsmanagementprozess beteiligten Rollen und ihre Aufgaben auf der Ebene der Funktionsbereiche: Geschäft, IT-Architektur, Basisverwaltung und Entwicklung.

Der innere Kreis beschreibt die Aufgaben in der bestehenden Landschaft, der äußere Kreis beschreibt die Phasen der Planung und Umsetzung von Änderungen.

Entitäten, Schritte und Werkzeuge im Detail

In diesem Abschnitt finden Sie Details zu den in den Abbildungen 3 und 4 gezeigten Elementen: Bereitstellungsmodelle, Landschaftsentitäten, Werkzeuge für beteiligte Rollen und Dienste in oder im Zusammenhang mit SAP Solution Manager werden erläutert.

Die Abschnitte sind als Aufgaben beschrieben und folgen einer "natürlichen" Abfolge, die vom Verstehen und Beschreiben hybrider Landschaften über die Suche nach neuen Optionen, deren Abbildung auf Ihre Bedürfnisse bis hin zur Definition einer neuen Landschaftsversion, dem Erhalt von Empfehlungen und der detaillierten Planung und Implementierung der Ergebnisse führt.

Projekt-Setup & Vorwissen

Die SAP Activate-Methodik wurde entwickelt, um Projektteams bei der Neuimplementierung oder Konvertierung etc. von SAP-Lösungen vor Ort oder in der Cloud-Umgebung zu unterstützen.

Über SAP Activate werde ich in einem weiteren Post berichten

Die Beschreibung Ihrer IT-Landschaft ist eine Voraussetzung für die Planung von Änderungen, deren Wartung und Überwachung.

Folgende Post’s soll Ihnen helfen, Ihre Landschaftsdaten besser zu handhaben, die eine Voraussetzung für den Betrieb von Geschäftsanwendungen, Systemen und Application Lifecycle Management-Prozessen gleichermaßen sind.

Analyse des Status Quo

Abrufen des Status Ihrer IT-Landschaft - Daten in SLD, LMDB, deren Verifizierung

Daten, die den aktuellen Status Ihrer Landschaft beschreiben, sind für die Verwaltung laufender Prozesse und die Planung von Landschaftsänderungen erforderlich.

Die Tools, die Daten, die Sie erhalten, und der Zweck, für den Sie sie verwenden müssen, hängen von den Bereitstellungsmodellen ab, die Sie in Ihrer Landschaft verwenden.

 Abrufen des Status Ihrer IT-Landschaft - Daten in SLD, LMDB, deren Verifizierung

h

Eine IT-Landschaft, die Systeme verschiedener Bereitstellungsmodelle mit Werkzeugen und Schritten des Landschaftsmanagementprozesses umfasst.

Ich werde versuchen , aufzuzeigen wie die verschiedenen Methoden, Tools und Werkzeugen helfen die Landschaftstransformation vorzunehmen.

Zukünftige Posts:

System Landscape Directory 

Solution Manager 

SAP Activate 

In-Memory Data Management Teil I

 Die Zukunft von Enterprise Computing

Es stellt sich die Frage ob ein neues Datenbank-Management-System wirklich notwendig ist. Die Antwort lautet: Ja! Moderne Unternehmen haben sich dramatisch verändert. Unternehmen basieren auf Informationen mehr als je zuvor. 

Es gibt zwei dominierende Anforderungen an ein modernes Datenbank-Management-System:

=> Daten aus verschiedenen Quellen müssen in einem einzigen Datenbank-Management-System kombiniert werden.

=> Diese Daten müssen in Near- Echtzeit analysiert werden , um eine interaktive Entscheidungsfindung zu unterstützen.

Die folgenden Anforderungen an ein neues Enterprise-Datenbank-Management-System  leiten sich von den Anforderungen für moderne Unternehmen ab.

Verarbeitung von Ereignisdaten

Ereignisdaten beeinflussen Unternehmen heute mehr und mehr. Sie zeichnen sich durch folgende Eigenschaften aus:

=> Jeder Ereignisdatensatz ist im Vergleich zur Größe traditioneller Unternehmensdaten, wie beispielsweise allen Daten, die in einem einzigen Kundenauftrag enthalten sind , klein (einige Bytes oder Kilobytes).

=> Verglichen mit der Menge an Entitäten ist die Anzahl der erzeugten Ereignisse pro Enität hoch, z.B. werden hunderte oder tausende Ereignisse für ein einzelne Produkt erzeugt.

Im Folgenden werden einige Anwendungsfälle von Ereignisdaten in modernen Unternehmen kurz vorgestellt.

Sensordaten

Heutzutage werden Sensoren eingesetzt, um die Funktion einer zunehmenden Anzahl von Systemen zu überwachen. Ein Beispiel ist das Tracking und Tracing von sensiblen Gütern wie Arzneimitteln, Kleidung oder Ersatzteilen. Dabei werden Pakete mit Radio-Frequency Identification (RFID)-Tags oder zweidimensionalen Barcodes, sogenannten QR-Codes, ausgestattet.

Tracking von Arzneimitteln

In Europa werden jährlich ca. 15 Milliarden verschreibungspflichtige Arzneimittel produziert. Diese werden an wichtigen Stellen in der Lieferkette getrackt. Das Tracking der Arzneimittelpackungen führt zu ca. 8.000 Leserereignismeldungen pro Sekunde.  Die In-Memory - Technologie ermöglicht Rückverfolgung von 10 Milliarden Ereignissen in weniger als 100 ms.

Formel-1-Rennwagen

Auch Formel-1-Rennwagen produzieren ein Übermaß an Sensordaten. Diese Sportwagen sind mit bis zu 600 Sensoren ausgestattet, die jeweils hunderte von Ereignissen pro Sekunden aufzeichnen. Abhängig von der Granularität der Datenaufzeichnung werden bei einem zweistündigen Rennen Sensordaten im Giga-oder Terabyte-Bereich erzeugt und erfasst. Die Herausforderung besteht darin, die gewonnenen Daten während des Rennens zu erfassen, zu verarbeiten und zu analysieren, um die Fahrzeugparameter sofort zu optimieren, um beispielsweise Bauteilfehler zu erkennen, den Kraftstoffverbrauch oder die Höchstgeschwindigkeit zu optimieren.

Analyse von Spiel-Ereignissen

personalisierte Inhalte in Online-Spielen sind ein Erfolgsfaktor für die Spiele-Industrie . Die deutsche Firma Bigpoint ist ein Anbieter von Browser-Spielen mit mehr als 200 Millionen aktiven Nutzern.

Ihrer Browser Spiele erzeigen einen stetigen Strom von mehr als 10 000 Ereignissen pro Sekunde, wie aktuelle Level, virtuelle Güter , Spielzeit usw. Bigpoint verfolgt mehr als 800 Millionen Ereignisse pro Tag. Traditionelle Datenbanken unterstützen  keine Verarbeitung solch großer Datenmengen in einer interaktiven Art und Weise. Beispielsweise erfordern Joins oder vollständige Tabellenscans komplexe Indexstrukturen oder optimierte Data-Warehouse-Systeme, um einige ausgewählte Informationen schnell zurückzuliefern. Allerdings können individuelle und flexible Anfragen von Entwicklern oder Marketing-Experten hierbei nicht interaktiv beantwortet werden.

In Memory-Technologie verbessert die Erkennung von Zielgruppen und das Testen von Beta-Funktionen, Echtzeit-Vorhersagen und die Auswertung von Anzeigen-Platzierungen.

Merkmale von Unternehmensanwendungen

Ein Enterprise-Datenbank-Management-System sollte in der Lage sein, Daten zu bearbeiten, die aus mehreren unterschiedlichen Quellen stammen.

=> Transaktionale Daten stammen aus verschiedenen Anwendungen, wie z.B. Enterprise Resource Planning (ERP)-Systemen.

=> Den Ursprung von Event-Processing - und Stream-Daten bilden Maschinen und Sensoren, in der Regel stark ausgelastete Systeme.

=> Echtzeitanalysen stützen sich in der Regel auf strukturierte Daten für Transaktions-Reporting , klassische Vorhersagen, Planung und Simulation.

=> Textanalyse schließlich basiert in der Regel auf unstrukturierten Daten aus dem Web, sozialen Netzwerken, Log-Dateien, Hilfesystemen etc.

OLTP versus OLAP

Ein Enterprise-Datenbank-Management-System sollte in der Lage sein, transaktionale und analytische Abfragetypen, die sich in mehreren Dimensionen unterscheiden , zu verarbeiten.

Die Erstellung von Kundenaufträgen , von Rechnungen, von Abbrechnungsdaten, die Anzeige eines Kundenauftrags für einen einzelnen Kunden oder die Anzeige von Kundenstammdaten stellen typische Abfragen im Online Transaction Processing (OLTP) dar. Das Online Analytical Processing (OLAP) besteht hingegen aus analytischen Abfragen. Typische OLAP-Produkte oder Dienstleistungen an einen Kunden), operatives Reporting oder die Analyse von Trends , die auf früheren Absatzdaten basieren. 

Nachteile der Trennung von OLAP und OLTP

Obwohl die Trennung der Datenbank in zwei Systeme Workload-spezifische Optimierungen in beiden Systemen ermöglicht, hat sie auch eine Reihe von Nachteilen:

=> Das OLAP-System verfügt nicht über die aktuellsten Daten, weil die Latenz zwischen den Systemen von Minuten bis zu Stunden oder sogar Tagen reichen kann. Folglich werden viele Entscheidungen auf veraltenden Daten getroffen, weil die aktuellsten Informationen zum Abfragezeitpunkt zur Verfügung stehen.

=> Im eine akzeptable Leistung zu erreichen , arbeiten OLAP-Systeme mit vordefinierten materialisierten Aggregaten, die jedoch die Flexibilität der Abfragen des Anwenders verringern.

=> Die Redundanz der Daten ist hoch. In beiden Systemen werden gleiche , nur unterschiedlich optimierte Informationen gespeichert.

=>Die Schemata der OLTP- und OLAP-Systeme sind unterschiedlich. Das führt einerseits zu einer erhöhten Komplexität von Anwendungen, die beide Systemtypen nutzen, und anderseits zu einer hohen Komplexität des ETL-Prozess , der die daten zwischen den Systemen synchronisiert.

Kombinieren von OLTP- und OLAP-Daten

Der Hauptvorteil dieser Kombination besteht darin , das sowohl transaktionale als auch analytische Abfragen auf denselben Server mit demselben Satz von Daten ausgeführt werden können. Diese kombinierte Datenquelle stellt eine sog. „Single Source of Truth“ dar, jegliche ETL-Verarbeitung wird damit überflüssig.

Durch den Einsatz moderner Hardware können zusätzlich vorberechnete Aggregate und materialisierte Sichten eliminiert werden, weil Daten-Aggregationen nach Bedarf vorgenommen und virtuelle Sichten auf Daten  (sogenannte Views) zur Verfügung gestellt werden können. Mit einer erwarteten Antwortzeit bei Analyseabfragen von unter einer Sekunden ist es möglich , den analytischen Abfrageprozess der transaktionalen Daten jederzeit und überall direkt durchzuführen. Durch Verzicht auf die Vorausberechnung von Aggregaten und die Materialisierung von Sichten können außerdem Anwendungen  und Datenstrukturen vereinfacht werden, da die Verwaltung von Aggregaten und materialisierten Views (d.h. Deren Aufbau, Pflege und Speicherung ) nicht länger notwendig ist.

Der entstehende gemischte Workload kombiniert die Eigenschaften von OLAP- und OLTP-Workloads . Die Abfragen können sowohl volle Zeilenoperationen aufweisen als auch nur eine kleine Anzahl von Spalten erfassen. Abfragen können einfach oder komplex sein, vorgegeben oder ad hoc. Dies umfasst analytische Abfragen , die mit den aktuellsten Transaktionsdaten laufen und in der Lage sind, Änderungen in Echtzeit zu verwerten.

Folgende Teile werden folgen:

Teil II: in-Memory Datenbank Theorie und Algorithmen

Teil III: SAP HANA Datenbank

Teil IV: SQL Script für SAP HANA

SAP Data Intelligence .- Connection Management

 Eine der grundlegendsten Funktionen einer IT-Unternehmensarchitektur ist die Fähigkeit, die Daten aller relevanten Systeme und die Informationen aus den verschiedensten Bereichen des Unternehmens zusammen zu bringen. Im Idealfall können diese Systeme direkt miteinander kommunizieren. Man spricht hier von einer unternehmensweiten Datenintegration. Über entsprechende Schnittstellen ließe sich das bekannte und in der Vergangenheit viel zu oft praktizierte Verfahren des Exports und Imports von Daten aus den und in die verschiedenen Systeme vermeiden. Die Einführung einer übergreifender Integrationsplattform ist lange überfällig, da die Export- und Importverfahren nur allzu oft mit Problement zu kämpfen haben, wie beispielsweise abweichenden Formatierungen, zeitlichem Verzug oder einfach auch nur beschädigten oder unvollständigen Datenbeständen bzw. Nichtverfügbarkeit eines Speichermediums. 

SAP Data Intelligence bietet die geforderte Möglichkeit, die Systeme direkt anzubinden und miteinander kommunizieren zu lassen. Um zu verstehen, welchen Funktionsumfang SAP Data Intelligence bietet und welche Szenarien damit möglich sind, ist es essenziell, zu wissen welche Arten von Quellsystemen innerhalb des Systems verarbeitet werden können und vor allem auch, wie diese Datan in das System gelangen. Um Daten grundsätzlich strukturiert und ohne Umwege in das System zu integrieren, sind Schnittstellen mit standardisierter Funktionalität nötig. Diese sollen es auf einfachste Weise ermöglichen, Datenquellsysteme anzubinden, deren Informationen auszulesen, zu verstehen und so letztendlich auch zu verarbeiten. 

Funktionen auf Basis der Verbindungstypen

Bevor ich auf die einzelnen Verbindungstypen eingehe , will ich in diesem Abschnitt einen grundsätzlichen Blick auf die über die Verbindungen bereitgestellten Funktionen werfen. Diese können in den weiteren Applikationen von SAP Data Intelligence, wie beispielsweise dem Metadata Explorer oder dem Modeler, genutzt werden.

Eine der einfachsten Funktionen im Connection Management ist die Anzeige der Verbindungsstatus , um einen Überblick über die noch aktiven und laufenden Verbindungen zu erhalten. Im Zweifelsfall können Sie so korrigierend eingreifen, damit die laufenden Prozesse ungefährdet ausgeführt werden können. 

Über die Verbindungen besteht im Modeler und im Metadata Explorer die Möglichkeit , Ordner , Dateien, Bereiche, Objekte, Schemas und Datensätze auf den jeweiligen Zielsystemen zu durchsuchen oder Daten in Dateien, Tabellen und Views zu lesen und zu schreiben.  Darüber hinaus können Inhalte wie Dateien kopiert , aber auch gelöscht werden.

Durch die im Connection Management angelegten Verbindungen können vordefinierte und standardisierte Integrationsflüsse, sogenannte iFlows, ausgeführt werden. Solche iFlows können etwa aus über SAP Cloud Platform Integration angebundenen Systemen über eine obligatorische , gesicherte HTTPS-Verbindung ausgeführt werden, um beispielsweise eine Serviceanfrageformular im Zielsystem SAP Service Cloud oder SAP SAles Cloud (vormals SAP Cloud for Customer) anzulegen.

—————————————————————————————————————————-

SAP Cloud Platform Integration

SAP Cloud Platform Integration ist eine Entwicklungs- und Integrationsplattform, die auf der SAP Cloud Platform angeboten wird. Sie ermöglicht den Austausch von Daten zwischen Cloud- und On-Premise-Systemen, wozu iFlows modelliert werden. Daneben bietet SAP Cloud Platform Integration vorgefertigte Adapter und Integrationsszenarien an.

—————————————————————————————————————————-

Verbindungen bilden darüber hinaus die Grundlage für die Ausführung von Ablaufdiagrammen oder Ablaufdiagrammaufgaben, ABAP-Operatoren, Jobs, Prozessketten oder SQL-Anweisungen, um damit die Prozesse der angeschlossenen Systeme zentral steuern und orchestrieren zu können. Neben den Ablaufdiagrammen können auch Jobs aus SAP Data Services, einer Software zur Datenbewirtschaftung von Data-Warehouse-Lösungen durchsucht und in der SAP-Data-Intelligence-Umgebung dargestellt werden.

In Machine-Learning-Szenarien können die im Connection Management definierten Verbindungen im Rahmen des Trainings von maschinell lernenden Modellen verwendet werden. Sie ermöglichen so das Experimentieren mit Daten unter Verwendung von Jupyter-Lab. JupyterLab ist eine interaktive Entwicklungsumgebung , die Coding , die grafische Darstellung sowie die Dokumentation der Programmierung mithilfe von sogenannten Notebooks unterstützt. Die Bezeichnung Jupyter leitet sich von den drei im Wesentlichen verwendeten Programmiersprachen Julia, Python und R ab. 

Verbindungen zu SAP-Systemen

Als SAP-Tool ermöglicht SAP Data Intelligence die typischen Systemverbindungen zu SAP-Lösungen. Für diese Verbindungstypen sind unterschiedliche Funktionalitäten in SAP Data Intelligence verfügbar. 

Der Verbindungstyp ABAP ermöglicht den Zugriff auf die klassischen ABAP-basierten SAP-Systeme wie beispielsweise SAP R/3, SAP ERP oder SAP S/4HANA. Verbindungen dieses Typs werden über die Protokolle Remote Function Call (RFC), HTTPS oder WebSocket RFC hergestellt. Es kann auf Tabellen, ABAP-Dictionary-Objekte und CDS-Views zugegriffen werden.

Änderungen an Verbindungen dieses Typs werden nicht immer gleich erkannt, da die Verbindungsdetails im Cache des Browsers abgelegt werden und daher immer leicht verzögert greifen. Bei der Nutzung eines HTTPS- oder WebSocket-RFC-Verbindung ist darauf zu achten, dass ein entsprechendes Zertifikat zur Verfügung steht.

Der Verbindungstyp BW ermöglicht den Aufbau von Verbindungen zu SAP-BW-Systemen, SAP BW-Systemen auf SAP HANA oder SAP BW/4HANA-Systemen. Es werden allerdings nur Systeme ab Version 7.4 unterstützt.

—————————————————————————————————————————

Cloud Connector

Der Cloud Connector von SAP verbindet Cloudanwendungen mit On-Premise-Systemen. Er wird über die SAP Cloud Platform bereitgestellt. Mit dem Cloud Connector können Sie beliebig viele Backend-Systeme mit der SAP Cloud Platform verbinden.

—————————————————————————————————————————

Über den Verbindungstyp CLOUD_DATA_INTEGRATION können diverse SAP-Cloudlösungen mithilfe von OData-basierten APIs angebunden werden. Zu nennen wären hier etwa die Lösungen SAP Fieldglass, SAP Sales Cloud, SAP Service Cloud oder SAP S/4HANA Cloud.

Der Verbindungstyp CPI nutzt HTTPS als obligatorisches Verbindungsprotokollen und stellt eine Verbindung zur Middleware SAP Cloud Platform Integration her. Diese Middleware unterstützt Daten- und Prozessintegrationsszenarien und stellt hierzu verschiedene vorgefertigte Integrationspakete zur Verfügung. Darüber hinaus verfügt SAP Cloud Platform Integration über eine Entwicklungsplattform, eine Laufzeitumgebung sowie vorgefertigte Funktionsbausteine . Aus SAP Data Intelligence heraus können Sie die Integrationsflüsse (iFlows), die in SAP Cloud Platform Integration modelliert werden, auf der SAP Cloud Platform steuern. Deren Rückmeldungen können Sie wiederum innerhalb von SAP Data Intelligence verarbeiten.

Über den Verbindungstyp HANA_DB kann der Zugriff auf eine klassische SAP-HANA-Datenbank erfolgen, sodass die SAP-HANA-Objekte durchsucht. Metadaten ausgelesen , ein Data Profiling erstellt und eine Datenvorschau innerhalb von SAP Data Intelligence angezeigt werden können. Zur Einschränkung auf nur notwendige Schemas stellt dieser Verbindungstyp eine Blacklistfunktion zur Verfügung, die nicht benötigte Schemas der Datenbank ausblendet. Diese Einschränkung stellt aber keine direkte Berechtigungseinschränkung dar, da sie mit dem Zugriff auf die Verbindungen aufgehoben werden kann.

Weitere Verbindungen sind:

Verbindungen zu Datenbanken

Verbindungen zu cloudbasierten Systemen

Erster Artikel zur SAP Data Intelligence:

https://einsiedlerkreps.blogspot.com/2023/04/sap-data-intelligence-ein-moglicher.html

SAP Systeme absichern

Risiko = Bedrohnung x Verletzung x Konsequenz 

Der ehemalige General und NSA-Direktor Michael Hayden hat es auf einem SAP-CRM Kongress in Richtung der anwesenden SAP-Kunden direkt formuliert:

Jedes Risiko ist letztlich das Produkt aus einer Wahrscheinlichkeit ihres Eintretens, multipliziert mit den Kosten des Schadens, wenn sie eintritt.

Open Web Applikation Security Projekt

Die Organisation Open Web Applikation Sekurity Projekt (OWASP) beschreibt ihr Selbstverständnis in einem Wiki-Beitrag folgendermaßen:

„Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern. Durch Schaffung von Transparenz sollen Endanwender und Organisationen fundierte Entscheidungen über wirkliche Sicherheitsrisiken in Software treffen können. An der OWASP-Community sind Firmen, Bildungseinrichtungen und Einzelpersonen aus aller Welt beteiligt. Innerhalb der Gemeinschaft werden frei verfügbare Informationsmaterialien, Methoden, Werkzeuge und Technologien erarbeitet.“

Eine Funktion , die jedes Jahr mit Spannung erwartet wird, ist die Top-10-Liste der in dem entsprechenden Jahr erkannten Schwachstellen von Webanwendungen genießt unter Sicherheitsexperten und Webentwicklern einen hohen Stellenwert. Für die neue Rankliste wurden über 500.000 Schwachstellen in mehreren Hundert Unternehmen und Tausend von Applikationen beobachtet. 2013 waren dies z.B. die folgenden (die Zahlen in Klammern zeigen die Vorjahresplatzierung):

1. Injection (1)

2. Broken Authentication und Session Management (3)

3. Cross-Site Scripting (XSS) (2)

4. Insecure direct Object References (4)

5. Security Misconfiguration (6)

6. Sensitive Data Exposure (7/9)

7. Missing Funktion Level Access Control (8)

8. Cross-Site Request Forgery (CSFR) (5)

9. Using Known Vulnerable Components(…)

10. Unvalidated Redirect and Forwards (10)

SAP-Sicherheit in der klassischen Sicht

Im Gegensatz zu früher stehen heute SAP-Systeme und SAP-Landschaften im Fokus der Cyber-Angriffe. Den hier findet man den „Schatz“ der Unternehmen in Form von Unternehmensdaten.

Bei der Umstellung auf die R/3 Architektur die aus einer klassischen 3-Tier-Landschaft besteht, also einen klassischen Client-Server-Umgebung. Und auf die basiert bis heute die SAP-NetWeaver-Architektur - auch wenn SAP HANA diese Welt nun wieder grundlegend verändert.

Tier 1: SAP-GUI-Client

Der Hauptzugang zu SAP-Systemen basiert in allen Systemen auf dem SAP GUI. Dieser Zugang basiert auf einem Rich-Client.Konzept, das ein proprietären Netzwerkprotokolle verwendet. Das Konzept ,das das SAP GUI verwirklicht , kommt ursprünglich aus der Terminal-Steuerung.

Aus Sicht eines Angreifers ist das SAP GUI sehr interessant. Zum einen bietet die auf dem Client liegende SAPINI-Datei einen hohen Informationswert, denn dort sind SAP-Systeme mit Adressen und Zielrouten hinterlegt. Zum anderen kann man sicher sein, das die Strecke vom Client zum SAP-System für diesen Desktop freigeschaltet ist.

Tier 1: Zugang aus dem Internet und Übergang ins Intranet

Dieses Netzwerksegment ist der Übergang vom Benutzer im anonymen Internet zum authentifizierten Internet-Benutzer und kennzeichnet auch die Grenze zum Unternehmensnetzwerk. Traditionall nennt man eine solche Zone auch Demilitarisierte Zone (DMZ), abhängig von der jeweiligen Architektur.

Für die Kommunikation zwischen SAP GUI und dem Anwendungsserver wurde das Dynamic Information and Action Gateway Protocol (kurz DIAG) entwickelt. Es ist ein proprietären Protokoll, dessen Spezifikation nicht veröffentlicht wurde - einige Details sind jedoch inzwischen bekannt geworden. DIAG übertragt binär Daten , die im Standard komprimiert sind, es findet jedoch ohne die zusätzliche Verschlüsselung per SNC keine Absicherung des Datenverkehrs gegen Sniffing statt.

Tier 2: Übergang von Intranet zur SAP-Tier

Der Übergang von Tier 1 (der DMZ) nach Tier 2 funktioniert in der Regel wieder durch eine Firewall, die das DMZ-Intranet gegen das interne Netzwerk, manchmal auch Campusnetzwerk genannt, abgrenzt. In Tier 2 liegen oft die Mitarbeiter-Systeme, auf denen dann auch der SAP Rich Client (SAP GUI) läuft. Aber auch externe Programme und nicht unternehmenskritische Anwendungen  können hier laufen. Aus dieser Ebene 2 werden dann die Verbindung zu den SAP-Systemen im inneren Tier 3 aufgebaut.

Tier 3: Die SAP-Systeme

Bis zur Einführung von SAP HANA hatte SAP zu Datenbanken eine ähnliche Haltung wie zu den Netzwerken. SAP wollte weitestgehend unabhängig von Datenbanken sein und implementierte nur eine Schnittstelle zu den Datenbanken hin und nannte diese Open SQL. Es war letztlich eine klassische Implementierung einer Datenbankschnittstelle, wie man sie auch im Bereich ODBC kennt, einem Protokoll, das letztlich von und zu Datenbanken redet.

Komponenten:

Schutz von SAProuter und SAP Web Dispatcher

SAProuter ist eine der ältesten Peripherie-Komponenten in der Welt der SAP-Kommunikation und war ursprünglich dazu gedacht, dem SAP-Support-Zugang zu den Kundeninstallationen zu ermöglichen.

Der Einsatzzweck hat sich im Laufe der Zeit deutlich gewandelt. Aus diesem Grund ist auch der Umfang der Sicherheitsthemen rund um den SAProuter mit den Jahren gewachsen.

Wann wird der SAProuter eingesetzt?

Der SAPRouter wird - neben der Rolle als Verbindung zu den Kundendiensten der SAP im SAP Help Portal - hauptsächlich zur Kontrolle und zur Protokollierung von Verbindungen von SAP-GUI.-Clients zu SAP-Servern eingesetzt. Hier ist es wichtig zu beachten, dass der SAProuter keine Funktion im Sinne einer Firewall oder als ein Paketfilter hat. Der SAProuter kann nur Verbindungen von und zu SAP-Systemen Verbindungen entweder zulassen (Allow) oder verweigern (Deny).

SAProuter und Secure Network Communications SNC

SNC ist in den letzten Jahren als Verschlüsselung auf Netzwerkebene immer wichtiger geworden, die Forderungen der Auditoren nach Verschlüsselung in Produktivnetzwerken sind immer häufiger in aktuellen Prüfberichten zu sehen.

Der SAP Web Dispatcher im SAP-Netzwerk

Der SAP Web Dispatcher steht zwischen dem Internet und Ihrem SAP-System und dient als eine SAP-spezifische Trennung von dem „Außen“ des Internets und dem „Innen“ einer Zone wie der Dermilitarisierten Zone (DMZ). Er ist ein Einstiegspunkt für HTTP-Requests an Ihr System, das aus einem oder mehreren SAP NetWeaver Application Servern besteht. In diesem Sinne ist der SAP WebDispatcher auch ein optionaler Terminator für HTTPS-Verbindungen. Als „Software-Web-Switch“ kann er Verbindungen abweisen oder annehmen und nimmt dann die Request-Verteilung für eine gleichmäßige Serverauslastung vor. Diese Last-Steuerung, die auch in einer klassischen SAP-Landschaft von spezifischen Load Balancern als Hardware-Appliance realisiert ist, kann hier softwareseitig realisiert werden.

Den SAP Web Dispatcher können Angreifer als Brücke verwenden, da hier SSL-Verbindungen terminiert sind und der SAP Web Dispatcher Zugriff auf die Backend-Systeme und SAP Gateway hat. Die Brücke ist ein Übergang, der es erlaubt , von einer gesicherten Kommunikation auf eine ungesicherte zu wechseln, ohne dass man selbst die verschlüsselte Verbindung auflösen oder terminieren muss. Wenn man beabsichtigt, den Netzverkehr unerlaubt mitzuschneiden, also zu sniffen, braucht man nur den Datenverkehr vom SAP Web Dispatcher zum SAP-System mitzuschneiden. Die verschlüsselte Verbindung davor kann man unangetastet lassen. Ähnlich dem SAProuter fungiert der SAP Web Dispatcher als Router und Load Balancer für alle angeschlossenen SAP-Systeme und adressiert diese meistens unverschlüsselt, das heißt ohne SSL-Zertifikate. Diese Verbindungen können auch gut mitgeschnitten , also gesnifft werden.

SAP-Prozesse und Dienste

Alle Applikationsserver eines SAP-Systems bilden eine logisch geschlossene Einheit Einheit. Daher müssen die Aufgaben der jeweiligen Server genau definiert werden. Die Aufgaben, die in einem SAP-System anfallen und die auf die einzelnen Applikationsserver verteilt werden müssen, werden Prozesse und Dienste genannt.

In einem SAP-System mit genau einem Applikationsserver werden diese Prozesse und Dienste von diesem einen Server ausgeführt. Wenn sich die SAP-Anwendung aus mehreren Applikationsserver zusammensetzt , werden sie auf die einzelnen Server verteilt. MIt Transaktion SM50 können Sie einsehen, welche Prozesse aktiv laufen.

Zu dern einzelnen Prozessen und Diensten gehören:

Dialogprozess - Der Dialogprozess nimmt die Anforderungen der laufenden Benutzersitzungen entgegen. Es sind mehrere Dialogprozesse pro SAP-System erforderlich. Auf jeder Instanz laufen mindestens zwei Dialogprozesse.

Ein Dialogprozess wird nicht genau einem Benutzer zugeordnet . Der Prozess nimmt immer genau eine Anforderung entgegen und wartet dann auf die nächste Anforderung, egal von welchem Benutzer sie ist. Der Dialogprozess wird von der jeweiligen Instanz mit Anforderungen versorgt. Ein Dialogschritt im SAP-System stellt genau eine Bildschirmmaske dar.

Verbuchungsprozess

Die meisten verändernden Zugriffe auf die Datenbank erfolgen asynchron. Das bedeutet , dass die Daten nicht direkt von einem Dialogprozess in die Datenbank geschrieben, sondern in Tabellen zwischengespeichert werden . Der Verbuchungsprozess übernimmt die Aufgabe , diese Tabellen auszulesen und die Daten in die Datenbank zu übertragen. Durch dieses Prinzip werden große Performanceverbesserungen erzielt.

Enqueue-Prozess/Enqueue-Server

Der Enque-Prozess stellt die Sperrverwaltung des SAP-Systems dar. Innerhalb eines SAP-Systems kann es nur einen einzigen Enqueue-Prozess geben, was häufig bei älteren ABAP-Systemen so konfiguriert wurde. Enqueue-Server kann er in einer eigenen Instanz installiert werden. Als Standalone-Enqueue-Server bildet er zusammen mit dem Message-Server die ASCS-Instanz (ABAP Server Central Services). Durch Einrichtung eines Enqueue Replication Servers kann er Hochverfügbarkeit ausgelegt werden.

Der Enqueue-Prozess verwaltet die Sperrtabelle. Bearbeitet ein Benutzer z.B.den Stammsatz des Debitors, wird in der Tabelle ein Eintrag vom Enqueue-Prozess auf die Anforderung eine negative Antwort. somit werden Inkonsistenzen in der Datenbank vermieden. Das Entsperren einer logischen Tabelle oder eines logischen Datensatzens übernimmt der Dequeue-Prozess.

Diese Sperre ist ein rein logische Sperre; es werden von diesem Prozess keine Tabellen in der Datenbank gesperrt. So ist es durch einen direkten Zugriff auf die Datenbanktabellen möglich, einen Datensatz zu ändern, der über das SAP-System durch den Enqueue-Prozess gesperrt ist.

Batchprozess

Der Batchprozess ist zuständig für die Hintergrundverarbeitung. Wiederkehrende Aufgaben, die keiner Dialogeingabe bedürfen, sollten im Hintergrund ausgeführt werden. Sie werden als Jobs eingeplant. Diese Jobs können von einem Benutzer ereignisgesteuert oder zu einem bestimmten Zeitpunkt ausgeführt werden. Auf jeder Instanz können mehrere Batchprozesse gestartet werden.

Message-Server

Der Message-Server ist für die Kommunikation der verschiedenen Instanzen untereinander verantwortlich. In jedem SAP-System gibt es genau einen Message-Server-Dienst, der auf der ASCS-Instanz (ABAP Server Central Services) läuft. Im Wesentlichen ist der Message-Server für das Routen von Mitteilungen zwischen den Servern verantwortlich. Bei diesen Mitteilungen kann es sich z.B. um das Starten von Batch-Jobs, das Starten einer Verbuchung oder um Enqueue- oder Dequeue-Prozesse handeln. Er übernimmt auch die Lastverteilung bei Anmeldung über SAP GUI und RFC mit Logon-Gruppen.

Gateway

Das Gateway (vormals SAP NetWeaver Gateway) übernimmt die Kommunikation zwischen Anwendungen auf verschiedenen SAP-Systemen oder zu Nicht-SAP-Systemen über das Protokoll Transmission Control Protocol/Internet Protocol (TCP/IP). Er ist auch zuständig für die Protokolle Remote Function Call (RFC) und Common Programming Interface for Communications (CPI-C). Es nutzt das Open Data Protocol (OData) und wird von allen Systemen benötigt, in denen SAP-Fiori-Applikationen und SAP-UI5-Oberflächen verwendet werden. Es ist somit die zentrale Komponente für die Anbindung eines SAP-Fiori-Frontend-Systems an ein SAP-S/4HANA-Backend.

Spool-Prozess

Der Spool-Prozess übernimmt die Verwaltung der Ausgabeaufträge eines SAP-Systems. Die Druckaufträge werden bis zur Ausgabe in den TemSe-Objekten (temporäre sequenzielle Objekte) zwischengespeichert. Die TemSe-Objekte können entweder in der Datenbank (unter Verwendung der RDBMS-Sicherheitsmechanismen) oder im Betreibssystem abgelegt werden. Es können beliebig viele Spool-Prozesse je Server gestartet werden.

Allgemeine Systemsicherheit

In der allgemeine Systemsicherheit fließen die Themen ein, die im Rahemen jeder Prüfung eines SAP-Systems zu betrachten sind.

Folgende Fragen können zum Thema allgemeine Systemsicherheit gestellt werden.

- Welches SAP-Release wird eingesetzt? Wie ist der aktuelle Stand der Support Packages?

- Existieren Vorgaben für die Einstellungen der Systemparamter?

- Entsprechen die aktuellen Paramaterwerte den Unternehmensverbände?

- Existieren Vorgaben für die Kontrolle der Parametereinstellungen nach Releasewechsel, Kernel-Updates usw?

- Wurden Änderungen an Parameterwerten nur von berechtigten Personen durchgeführt?

- Wurden Parameter sowohl im Instanz- als auch im Default-Profil gesetzt?

- Wurden für Parameter auf verschiedenen Instanzen unterschiedliche Werte gesetzt?

Die Zukunft der Integration mit SAP S/4HANA

 Ich beschäftige mich schon länger mit Integration, aber jetzt ist die Zeit gekommen wieder einmal zu reflektieren wie es in Zukunft weiter gehen könnte. 

Deswegen habe ich mich einwenig mit SAP S/4HANA Architektur und in welche Richtung es in Zukunft gehen soll.

Also um gleich etwas klarzustellen die herkömlichen Technologien gibt es alle noch, ( IDocs, BAPIs und RFCs). Aber in Zukunft werden wohl SOAP und OData die Technologien der Wahl werden.

SAP hat in der Cloud die in allem die Marschrichtung vorgibt , folgende Strategie verwendet.

Bei Neuentwicklungen konzentriert sich SAP auf SOAP und OData - Service und verzichtet in derZukunft auf die Weiterentwicklung der BAPIs , IDocs und RFC.  

Wie schaut die Verwendung nun im Detail aus :

SOAP - Dienste werden für asynchrone Dienste (wo früher IDOCs verwendet worden wären) genutzt:

 

Kurz zur Erklärung: SOAP Dienste sind Dienste die das http-Protokoll und das XML -basierte SOAP Nachrichtenformat verwendet. 

Es werden typischerweise asynchrone , transaktionale Kommunikation verwendet, mit einweg Nachrichten die keine Antwort haben. Hier geht es einfach darum blockierung zu vermeiden.

Synchrone SOAP-Dienste werden nur in Ausnahmefällen verwendet. 

Der zweite Player bei Integrations-Technologien ist OData-Service , sie übernehmen den Part den früher die BAPI übernommen haben. 

OData - API sind resourcenbasierte API's das ergebnis der operation wird sofort im BODY der http -Antwort zurückgegeben wird.

 

Gemeinsam mit ABAP RESTful Application Programming Model  (werde spätern noch mehr darüber schreiben ist es eine gute Abstraktionsschicht 

Hier ist auch wichtig zu sagen das auch diese API über das Open API Spezifikation auf einem API Getway zur verfügung gestellt werden kann. Um diese API zur verfügung zu stellen.

 

Fazit: 

Für mich war es etwas ein Aha Erlebnis auf der einen Seite leichtgewichtige asynchrone  SOAP Service, weiter OData Service die Business Logik kapselt. Die Trennung der layer passiert noch effizienter,  es geht wie immer um Entkopplung und Austauschbarkeit.  

Natürlich wird man nicht jede bestehende Schnittstelle ändern, aber bei neuen Schnittstellen ist es schon anzudenken diese Vorgehensweise zu wählen.

Es ist auch zu überlegen welchen Stellenwert SAP PO einnimmt, sofern eine solche  verwendet wird.

Diese Fragen wann verwende ich eine API wann macht es Sinn SAP PO zu verwenden sind wichtig und sollten auch im Unternehmen besprochen werden.

Um diese Fragen klären , wird es wichtig sein auch zu definieren mit welche Integration Domain , Integration Style haben wir im Unternehem und welche technischen Möglichkeiten haben wir hier.

 Das SAP System ist nicht isoliert , sondern eingebettet in den Gesamtkontext der Unternehmens-Architektur.