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.
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
Keine Kommentare:
Kommentar veröffentlichen