Die beiden Komponenten Diagnostics Agent und Host Agent sind beide für das monitoring und die Performance-Analyse in SAP-Systemen zuständig. Sie liefern informationen an das Application Lifecycle Management, also in der Regel an den SAP Solution Manager, von dem aus alle SAP-Systeme in einer Systemlandschaft verwaltet werden, so dass Informationen über die Performance der verwalteten Systeme zur Verfügung stehen, und unterstützt somit die Fehlerursachenanalyse (root cause analysis).

Der Diagnostics Agent ist eine zentrale Komponenten in einer SAP Solution Manager systemlandschaft. Sie wird genutzt, um zentralisierte Analysen und Monitoringaktivitäten für die SAP Netweaver Systemlandschaft berietzustellen. Sie hilft bei Tätigkeiten, die mit der root cause analysis (Fehlerursachenanalyse) zusammenhängen. Der daignostics Agent ist für die Verbindung zwischen Solution manager und managed Systems (verwalteten Systemen)zuständig, um informationen zu sammelön. Diese infomrationen werden von den managed systems an das SAP Solution Manager System zur Analyse gesendet.

Der SAP Host Agent implementiert verschiedene Software Lifecycle Management prozesse, wie etwa Monitoring und Administration, in ein SAP System. Die Hautpaufgabe des Host Agents ist das monitoring und das Mangement auf Betriebssystemebene. Er wird einmal pro physikalischem Host installiert, kann also für mehrere virtuelle SAP-Systeme / virtuelle Hosts zuständig sein, die auf einem physikalischen Host installiert sind. Er liefert daten an die SAP monitoring und Management-Lösungen. Der SAP Host Agent liefert dazu Zugriff auf Betriebssysteminformationen, beispielsweise die nutzung von virtuellem und physikalischem Speicher, CPU-Auislastung, Speicherplatzauslastung auf den Festplatten, die Ressourcennutzung laufebnder Prozesse, Informationen über Betriebssysteme und Datnebanken auf dem Host, und übernimmt auch das Log File Monitoring.

SAP – Diagnostics Agent und Host Agent – kurz angesprochen weiterlesen →

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

In diesem Post geht es um das SAP Master Data Mangement (MDM), einer Komponente / Applikation des SAP NetWeaver. Die Grundbestandteile habe ich bereits einmal in den Posts SAP Basis und SAP Netweaver – eine einführung sowie in SAP ERP: die Anwenderseite erklärt. Hier nochmal ein kurzer Abriss:

Als Master Data bezeichnet man Daten, die einmalig gespeichert werden und in allen SAP-Systemen einer Systemlandschaft abgerufen und verändert werden können. Wichtig dabei ist, dass die Daten nur einmalig abgelegt werden,also nicht jedes System seine eigene Datenquelle braucht, sondern sich alle Systeme von der selben Datenquelle bedienen – und dass die Daten somit konsistent und immer up to date für alle System zur Verfügung stehen. Desweiteren spart dies umständliche doppelte Eingaben in SAP-Systemen, was den Anwendern und Administratoren von SAP-Systemen Arbeitszeit spart.

Als Master data bezeichnet man Daten, die in regelmäßigen Abständen wiederkehrend abegrufen oder verändert werden müssen, oft von mehreren SAP-Systemen (gleichzeitig). Dazu gehören beispielswiese Kunden- und Lieferantendaten, die beim Verkauf und Ankauf von Produkten und Materialien immer wieder abgerufen werden müssen.

Das Master Data Management ist eine Applikationskomponente des SAP NetWeaver und wird standardmäßig mitinstalliert. sie kümmert sich um das Bestimmen der Datenquellen für Master Data, um die Entduplikation von doppelt vorahndenen Einträgen, um die Zusammenführung von verstreut herumliegenden Daten, Datenaustausch mit Geschäftspartnern und Einzelhändlern usw.

Die Master Daten kann man entweder von den einzelnen SAP-Systemen, oder zentralisiert von einem Zentral-System aus, warten. Beides hat vor- und nachteile.

In späteren Posts werde ich detaillierter auf das MDM eingehen.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

SAP vertreibt verschiedene Produkte wie etwa den SAP NetWeaver, SAP Solution Manager etc. online über sein Software Download Center (http://service.sap.com/SWDC). Dort kann man sich die Installationsmedien für dieses Produkt herunterladen.

In diesen Installationsmedien sind alle Softwarekomponenten (software units) dieses SAP-produkts enthalten – ganz gleich, ob man diese später in seinem speziellen System braucht, oder nicht.

 

Es wäre natürlich kontraproduktiv, alle Softwarekomponenten zu installieren, ganz gleich ob man sie braucht oder nicht. Denn das würde zu unnötigen Performanceeinbußen durch Hardwarebelastung sowie durch unvorhergesehene Komplikationen zu Fehlern im System führen. Das wollen wir vermeiden.

Weil SAP-Berater Experten in ihrem Fach sind, installieren sie SAP-Produkte nicht einfach so drauf los. Sondern sie gehen mit einem Plan vor (erklärt in meinem Post SAP: Die PDf-Guides erklärt). Für jedes SAP-Produkt gibt es einen sogenannten Master Guide, der den SAP-Berater beim Planen der Implementierung eines SAP-Produkts unterstützen soll.

In diesen Master Guides geht es also darum, die Implementierung eines SAP-produktes zu planen – also sowohl in betriebswirtschaftlicher, als auch in informationstechnischer Sicht. Dabei stößt man auf die Frage, welche Softwarekomponenten man denn nun installieren soll, und welche nicht.

Um diese Entscheidung einfacher zu machen, hat SAP die Definition der sogenannten USage Types erstellt. Usage Types beschreiben einen ganz speziellen Zweck, den man mit diesem SAP-Produkt abbilden kann, etwa einen Service Desk, ein Central-SLD, oder ähnliches. SAP bindet an diese Usage Types, also an diese Nutzungsszenarien, einen Umfang an Softwarekomponenten (Installable Sotware Units), der installiert werden muss, um dieses Nutzungsszenario leisten zu können.

Das bedeutet: der SAP Systemadministrator plant seine Installation nur nach anhand von Usage Types, also daran, wie er das SAP-Produkt später nutzen will – und erfährt dadurch die zu installierenden Softwarekomponenten.

Die Usage Types, die der Administrator im Master Guide geplant hat, findet er später beim Installieren des SAP-.Produkts auch in der Installationsroutine wieder. hier kann er einfach die Usage Types auswählen, das Setup erkennt dann automatisch, welche Softwarekomponenten für diesen Usage Type installiert werden müssen.

Das, kurz gesagt, ist der Sinn von Usage Types. sie sind in jedem Master Guide in der Regel im Kapitel 4 beschrieben.

Neben den Usage Types spricht man im Master Guide auch von Processes – Prozessen. hier ist nicht von den Prozessen die Rede, die im Hintergrund auf einem Betriebssystem ablaufen, sondern sozusagen von Geschäftsprozessen, die betriebswirtschaftlich gesehen immer wieder im Unternehmen auftauchen.

diese Prozesse können beispielsweise das Rechnungsmanagement, die Materialverwaltung oder die Kundenbetreuung in einem Unternehmen sein, oder etwa der Service-Desk, der sich um die Probleme von Anwendern unserer SAP-Produkte kümmert und als Hotline zur Verfügung gestellt wird.

Diese Prozesse wiederum sind mit Usage Types verknüpft. Es kann sein, dass man für einen bestimmten Prozess mehrere Usage Types einplanen muss. Wenn man weiß, für welchen Prozess man welche Usage Types vorsehen muss, weiß der Administrator später, welche Usage Types er bei der installation eines Systems auswählen muss. Wählt er diese aus, werden dann automatisch die richtigen Softwarekomponenten installiert, um diesen Prozess abzubilden.

Bei der installation von Enhancement Packages in einem SAP-System begegnet man noch einer anderen Begrifflichkeit: Business Functions (BFs). im Endeffekt sind Business Functions neue, mit einem Enhancement Package hinzugekommene Funktionen in einem SAP-System. Diese Business Functions updaten bestimmte Softwarekomponenten eines SAP-Systems, um diese mit neuen Funtkionen zu bereichern.

So, wie bei der installation eines SAP-Systems Usage Types zu Prozessen zusammengefasst werden, werden Business Functions beim Update eines SAP-Systems zu sogenannten Technical Usages zusammengefasst.

Ein Technical Usage ist eine Zusammenfassung von Business Functions für eine bestimmte Produktinstanz.

So kann es etwa sein, dass man für eine bestimmtes technisches Nutzungsszenario verschiedene Business Functions installieren muss, die in der Regel zusammen in einem Erweiterungspaket ausgeliefert werden. Die einzelnen Business Functions werden dann auf diejeweiligen Softwarekomponenten anghewandt, die durch diese upgedatet werden.

 

Was sind Produkte und Softwarekomponenten?

ein produkt ist eine Applikation die bestimmte Geschäftsanforderungen eines Unternehmens erfüllt. Solche Produkte sind beispielsweise SAP ERP, SAP CRM usw. Produkte werden dabei unterteilt in Softwarekomponenten. So hat SAP ERP beispielsweise eine Softwarekomponente für sein HR-Modul, für sein FIN-Modul, aber auch Basismodule, die für den Netweaver zuständig sind – der sich wiederum darum kümmert, dass das produkt überhaupt läuft.

Zunächst einmal muss man verstehen, dass ein SAP-System aus verschiedenen Komponenten besteht. Es gibt sogenannte Basis-Komponenten, die für den Betrieb der Grundplattform, auf welcher alle SAP-Produkte laufen, zuständig sind. Das sind also die Softwarekomponenten für den Betrieb der netWeaver-plattform. Und es gibt Application-based Softwarekomponenten, die sich je nach installiertem SAP-produkt und -Release unterscheiden und für die Bereitstellung der Funktionen dieser Applikationen zuständig sind.

eine Softawrekomponente ist die kleinste verwaltbare Einheit im SAP-Softwaremodell. Sie sind deshalb auch die Basis für die anwendung von Support Packages. Eine Softwarekomponente wird dabei einer oder mehreren Produktinstanzen zugeordnet.

Was ist eine Produktinstanz?

Eine Produktinstanz ist ein Bündel aus Softwarekomponenten die sich gegenseitig brauchen, um auf einem System lauffähig zu sein. Sie müssen auf einem einzigen technischen System installiert werden. Ein technisches System ist dabei sozusagen SAP-Software, die sich auf einem einzigen Host befindet (die Datenbank darf heirbei noch auf einem anderen Host liegen). Das gesamte Produkt / SAP-System an sich kann auf mehrere Hosts verteilt sein, es können auch mehrere produkte auf einem einzigen physikalischen Host installiert sein. Aber die Softwarekomponenten in einer Produktinstanz müssen zusammen auf einem einzige tecnischen System installiert sein, damit sie laufen.

Produktinstanzen sind beispielsweise die TREX-Suchengine, die beim Suchen von Begriffen in einem SAP-System zum Einsatz kommen, oder einer der jeweiligen Applikationssofwtarekomponetnen wie beispielsweise SAP_HR, die wiederum abhängig davon sind, dass auf dem selben technischen System die Komponente SAP_APPL läuft. Dann machen SAP_HR und SAP_APPL zusammen eien Produktinstanz aus. Dabei wird auch ersichtlich, dass eine einzige Softwarekomponente bestandteil mehrerer Produktinstanzen sein kann. SAP_APPL wäre beispielsweise Bestandteil sowohl von der Produktinstanz Human REsources – zu welcher SAP_HR und SAP_APPL gehören, als auch der Produktinstanz Retail, zu der SAP_Retail und SAP_APPL gehören.

Heutzutage werden produktinstanzen dazu genutzt, um Usage Types und Technical Usages zu ersetzen (siehe unten). Eine Produktinstanz ist also ein neuerer Begriff für diese beiden älteren Definitionen.

Wenn man im Maintenance Optimizers updates für ein System durchführt, dann kann man diese Produktinstanzen auswählen, um diese getrennt voneinander zu updaten.

Was sind technical systems und product systems?

Wie bereits angeschnitten, kann eine bestimmte  Produktinstanz eines SAP-produkts auf verschiedenen Systemen installiert sein. Man muss nicht ein SAP-produkta uf einem einzigen physikalischen Host installieren. Man aknn beispielsweise die Produktinstanz TREX, also die Suchengine für die Suchfunktion, auf einem anderen Host haben. Ein Technical System enthält also eine oder mehrere Produktinstanzen eines SAP-produkts, welches der SAP-Kunde in seiner Systemalandschaft einsetzt. Dabei können auf einem physikalischen Host mehrere technische Systeme sein – soll heißen: auf eniem physikalsichen Host können die Produktinstanzen verschiedener SAP-Produkte installiert sein. So kann man auf einem Server beispeilsweise sowohl produktinstanzen für SAP ERP, als auch für SAP CRM installieren.

Unter dem Begriff Product Systems fasst man nun alle technischen Systeme zusammen, die zusammengenommen ein installiertes SAP-Produkt formen. So kann man ein SAP ERP Product System beispielsweise aus einem technischen Ssytem für die Scuhengine TREX, einem Technischen Sytem für Human Resources und einem technischen System für Retail bestehen. Auf jedem technischen System läuft dabei die entsprechende Produktinstanz.

Was ist eine Produktversion?

Wie wir bereits gelernt haben, macht ein Product System ein bestimmtes installiertes SAP-Gesamtprodukt aus, welches ein SAP-Kunde einsetzt. Dieses product System als ganzes amcht also ein installiertes SAP-produkt aus, welches wiederum eine bestimmte Version hat. Bei der Version gibt man in der Regel den Release des SAP-rpodukts an, also beispielsweise SAP R/3, SAP ERP 2005, SAP ERP 6.0 – das sind jeweils aufeinanderfolgende Releaseversionen.

Releases sind sogenannte standalone Versions. Diese Produkte laufen ohne irgendwelche Zusatzprodukte von sich aus. Zu diese standalone produktversionen gibt es noch Add-on Produktversionen. :Das heißt, man kann bestimmte Erweiterungspakete (Enhancement Packages) installieren, die ein bestimmtes Release nochmal um einige funktionen erweitern. Die aktuelle Add-on-Version von SAP ERP 6.0 beispielsweise wäre

SAP ERP 6.0 and SAP EHP 7 for SAP ERP 6.0 – und sagt aus, dass auf den Release SAP ERP 6.0 das Erweiterungspakete EHP 7 aufgespielt wurde.

eien kleine besonderheit hierbei ist, dass EHP-Versionen des SAP Netweaver als standalone-Produktversion gelten. Die Produktversion SAP EHP1 for SAP NetWeaver 7.3 beispielsweise wäre eine standalone Produktversion.

Was ist eine Technical usage und was ist eien Business Function (BF) / Business Scenarios?

eine Business Function ist eine geschäftsbezogene Funktion in einem SAP-Produkt, die durch ein Bündel aus produktinstanzen oder einzelnen Softwarekomponenten bereitgestellt werden. Dabei kann eine Business Function auch einfach nur von einer einzigen Softwarekomponente oder von einer einzigen Produktinstanz bereitgestellt werden. Business Functions können auch neu dazu gekommen, wenn man ein Enhancement Package in eine Produktversio einspielt. Dann werden eine oder mehrere bestehende Softwarekomponenten so geupdatet, dass die entsprechende Business Function bereitgestellt werden kann. Wenn eine Business Function durch eine Transaktion im SAP-System abgebildet werden kann, bezeichnet man sie auch als Business Scenario. In der Regel ist es Aufgabe des sogeannnten Business project experts, die benötigten Business Functions und Business Scenarios, die innerhalb des SAP-Systems für das jeweilige Unternehmen gebraucht werden, zusammenzuführen. Der SAP-Systemadministrator muss dann auf der technischen Setie dafür sorgen, dass den Usern später diese Business Functions oder Business Scenarios zur Verfügung stehen.

Eine Technical Usage ist eine Art und Weise, verschiedene Produktinstanzen eines SAP-produkts auf technische Art und Weise zu verwenden. Alle für idese Technical Usage notwendigen produktinstanzen müssen installiert sein, damit diese angewandt werden aknn Jede Business Function ist einer technical usage zugeordnet – eine technical usage kanna us mehreren Business Functions bestehen. Eine Technical Usage muss installiert werden, um diese mit ihr verbundenen Business Functions bereitstellen zu können. Man kann dann beispielsweise im Solution Manager auswählen, welche Technical Usages man in seinem System haben möchte, um bestimmte Business Functions nutzen zu können – wenn man ein System updatet. Der soMan schlägt dann vor, welche Erweiterungspakete und Support Packages eingespielt werden müssen, damit diese technical usages bereitgestellt werden können. Aber auch bei der Neuinstallation eines SAP-Systems kann der Systemadministrator diese Technical Usages auswählen.

In der folgenden Abbildung sehen wir, dass mit dem SAP EHP7 eine neue Business Function namnes GEneral Ledger Account hinzugekommen ist. damit wir diese BF nutzen können, müssen wir die Technical Usage Central Application auswählen, wodurch dann der MOPZ des Solution Managers für uns die benötigten Updates (darunter das EHP7) auswählt. Dadurch werden die benötigten Softwarekomponenten wie beispielsweise SAP_APPL aktualsiiert, so dass im Endeffekt die gewünschte Business Function genutzt werden kann.

zunächst einmal muss man natürlich immer wissen, welche Business Functions man braucht. Dazu liefert SAP unter service.sap.com/erp-ehp / Business Functions in detail eine Liste aller Business Functions von EHP 1 zu EHP 7. Wenn man nur die Business Functions wissen möchte, die in einem bestimmten EHP dazu gekommen sind, dann guckt man am besten in die Release notes unter services.sap.com/erp-ehp / Release notes. Das ist jedoch in der Regel Aufgabe des Business Process Experts – es schadet jedoch nicht, grundsätzlich einen Einblick in die thematik zu haben.

Damit wir dann wissen, welche Technical Usages wir für diese Business Functions installieren müssen, können wir ebenfalls in services.sap.com/erp-ehp / Business Functions nachsehen oder uns die SAP Note 1818596 durchlesen.

Was sind Enterprise Services?

Na, raucht der Kopf schon? Das ganze geht noch komplizierter.

Mit der einführung der serviceorientierten Architektur (SOA) hat SAP begonnen, mit seinen Produkten sogeannnte Enterprise-Services auszuliefern. Enterprise-SErvices sind sozusagen Dienste, die mit Hilfe von SAP-Produkten angeboten werden. Die Diente sind in der ES-Wiki aufgezeichnet. Für jeden Dienst braucht man verschiedene Softwarekomponenten in einer bestimmten Version und bestimmte Business Functions, die aktiviert werden müssen.

Was wir zu diesem Zeitpunkt haben ist, welche Softwarekomponenten in welcher Version und welche Business Functions wird brauchen, um einen bestimmten Enterprise Service nutzen zu können. Aber wie wir ja wissen, brauchen wir zum updaten eines Systems über MOPZ die sogenannten TEchnical Usages. Deswegen muss man in einer SAP-note, aktuell die SAP Note 1818596 schauen, welche technical usages für diese sofwtarekompoennten / business functions notwendig sind.

Was sind Usage TypeS?

Usage Types definieren wie bestimmte Installationen einer SAP produktversion genutzt werden sollen und welche Möglichkeiten welcher Usage Type der IT-Systemlandschaft bietet. Sie sind daher im wesentlichen vergleichbar mit Business Functions. softwarekomponenten werden mit Usage Types verbunden, ähnlich wie sie andernorts auch mit bestimmten Business Functions und somit mit Technical Usages verbunden werden. Usage Types können auch mit produktinstanzen verbunden sein, die für diesen Usage Type installiert werden müssen.

Was sind installable software units?

installable software units sind produktinstanzen, die beim upgrade oder bei der installation einer SAP-produktversion mitinstalliert werden müssen, damit bestimmte Usage Types durch das System realisiert werden können. Usage Types sind also im Wesentlichen vergleichbar mit Technical Usages. Aber auch Standalone-Engines, die ohne ein übergeordnetes SAP-produkt lauffähig sind, also nicht von einem anderen SAP-produkt abhängig sind (etwa die Suchengine TREX), sind installable Software Units. Diese können (oder müssen) zusätzlich zum eigentlichen SAP-produkt installiert und eigenständig betrieben werden.

Installable Software Units können also sowohl Produktinstanzen sein, die von einem bestehenden SAP Produkt abhängig sind und in einer extra Instanz dieses Produkts betribeen werden, aber auch Standalone Engines, die keine Instanznummer bekommen und daher nicht vom System des Hauptprodukts abhängig sind.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Die Amazon Web Services sind Dienste, die in Partnerschaft zwischen SAP und Amazon entwickelt wurden, um SAP-Systeme per Cloud on-demand zu mieten und diese dann in seine eigene SAP-Landschaft zu integrieren.

Nehmen wir beispielsweise an, Sie sind ein Unternehmen und haben bereits selber einige SAP-Systeme am LAufen. Wenn Sie jetzt feststellen, dass Sie noch ein SAP System brauchen, auf welchem der aktuelle Release des SAP Solution Managers läuft, könnten Sie jetzt selber ein Projekt starten – einen Server anschaffen und dort den SolMan drauf installieren, was unter Umständen mehrere Tage dauert.

Mit Amazon Web Services wäre es ihnen jetzt möglich, in einem Web-Wizard, den Sie ganz einfach per Browseroberfläche bedienen können, ein Solution manager system einer beliebigen Hardwarestärke binnen weniger Minuten aufzusetzen und bereitzustellen. Mit dem Server können sie sich dann mittels Cloud verbinden und ihn so in Ihre bestehende SAP-Systemlandschaft integrieren.

Ein Administraot kann sich dann ganz einfach per VNC / SSH auf den Server einloggen, nachdem dieser aufgesetzt ist, und dann noch kleinere Konfigurationsschritte vornehmen.

Das Betrieben eines Medium-Sized Servers kostet etwa  0,15 US-D pro stunde, also etwa 8 Dollar pro Monat. Ein Large Sized Server kostet 50 Cent pro Stunde.  Angesichts dieser geringen Kosten wird schnell klar, dass die Amazon Web Services als cloud-basierte hostinglösung für SAP-Dienste auf jeden Fall in Frage kommt. Denn die kosten sind im Vergleich zum Eigenbetrieb sehr niedrig. Nachteil ist, dass man den Server nicht vor Ort hat und deswegen mit einigen Hürden des Cloud-Computings umgehen muss.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

SAP Basis war oder ist ein Begriff der die allgemeinen Administrationstätigkeiten in einer SAP-Produktumgebung beschreibt. BASIS ist eigentlich eine softwarekomponente, auf der andere Technologien von SAP aufsetzen, um letztendlich die SAP-produkte, die in der Wirtschaft so heiß begehrt sind, darauf zu betreiben. Basis war lange Zeit das Synonym für diejenigen Tätigkeiten, die sich nicht nur um die softwarekomponente BASIS, sondern um das umfassende Fundament von SAP-Software kümmern.

SAP hat den Begriff BASIS für die Disziplin der SAP-Systemadministration abgelöst und nennt es heutzutage SAP NetWeaver Sytsem ADministration.

Was ist SAP NetWeaver?

SAP NetWeaver ist sozusagen die Plattform, welche alle Komponenten mit sich bringt, die notwendig sind, um SAP-Produkte zu betreiben. Dazu gehören beispielsweise der SAP Kernel, die SAP Basis-Softwarekomponenten, die grafische Benutzeroberfläche SAPGui usw.

Die Idee hinter SAP NetWeaver ist, dass die SAP-Produkte, also beispielsweise SAP SRM, CRM, SCM, PLM, oder SAP ERP, die wir allesamt in meinem post SAP – Geschichte und einführung kennengelernt haben, auf Basis von einem Web Application Server laufen und dabei plattformunabhängige Programmiersprachen wie ABAP oder JAVA nutzen. Der Vorteil bei diesen beiden Technologien ist, dass  sie auf allen Betriebssystemen laufen – da der Code von einem Interpreter erst während der Laufzeit des Programms in Maschinencode übersetzt wird – das bedeutet: dem ABAP- oder Java-Code ist es grundsätzlich egal, ob er gerade auf einem Windows-, Linux- oder Unix-System ausgeführt wird. Der interpreter weiß, wie er für die jeweilige Plattform den Code interpretieren muss, damit die Befehle ausgeführt werden. Das einzige Plattform, welches betriebssystemabhängig kompiliert, heruntergfeladen und installiert werden muss, ist also der SAP NetWeaver selbst, aber nicht mehr die wirklichen SAP Produkte. Das verringert den administrativen Aufwand sowie Hürden bei der Umsetzung.

SAP Basis und SAP NetWeaver – eine Einführung weiterlesen →

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

In meinem Post SAP – Geschichte und Einführung, der bei vielen Lesern auf gute Zustimmung gestoßen ist, habe ich eine theoretische Einführung darüber geliefert, was für die Dienste SAP mit seinen Produkten anbietet und weshalb sie auf dem Markt sind.

Sowohl für Berater und Administratoren, als auch für Anwender selbst ist es interessant, die Anwenderseite eines SAP ERP-Systems kennenzulernen. Schließlich will man ja auch als Administrator wissen, welche Dienste man seinen Anwendern letztendlich anbietet.

Desweiteren ist dieser Beitrag auch für Administratoren interessant, die das erste mal mit der grafischen Benutzeroberfläche SAP EasyAccess unter SAP Logon arbeiten und daher eine kleine Starthilfe haben wollen.

In diesem Post möchte ich eine kleine Einführung darüber bieten.

SAP ERP: Die Anwenderseite erklärt weiterlesen →

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!

Was ist ein SLD?

Eine SLD steht für System Landscape Directory. Sie dient als zentrale Qeulle für infomrationen über die SAP-Systemlandschaft. Dadurch stehen immer informationen zur Verfügung, welche Produkte auf welchen Systemen installiert wurden, sodass man diese Produkte über beispielsweise den Solution Manager warten zentralisiert warten kann.  Damit können Software-Lifecycle-Aufgaben geplant werden, beispielsweise das Update bestimmter SAP-Produkte auf den neuesten SP-Level.

Das SLD basiert dabei af einem nicht-proprietären standard der Distirbuted mangement Task Force, genannt Common Information model (CIM).

Das System Landscape Directory unterscheidet zwischen technischen Systemen – also Serverhardware, auf denen später SAP-Lösungen installiert werden können – und den Applikationen, die darauf alfuen. Diese Daten werden automatisch geupdatet – wird eine neue SAP-Kompoenten auf einem technischen System installiert oder entfernt, wird diese information von diesen Produkten an das SLD und von dort automatisch an die anderen Bestandteile der landschaft verbreitet.

Das SLd enthält zwei Warten von Informationen über die Landschaftstopolige:

• Landschaftsbeschreibung: welche Sfotwarekompoenten sind gerade in der Landschaft installiert. dazu werden detaillierte informationen über die Version, das Patch- / SP-Level, die Verbindungen zwischen den Systemen und die informationen über die Hosts (Betriebssytem, Hostname, Datenbank usw.) gespeichert.
• Komponenten information: welche softwarekompoenten können theoretisch in der Landschaft installiert werden? Hier werden die möglcihen Abhängigkeiten und Kombinationen der Lösungen beschirben. Das SLD weiß ganz genau, welches produkta uf welcher Plattform mit welcher Datenbank laufen kann, und bildet hierbei genau die Abhängigkeiten ab, die dazu erfüllt sein müssen.

Alle SAP-Komponenten – und unterstützte Drittanbietrkomponenten – haben Funktionen eingebaut, welche informationen über sich selbst an das SLD schicken und dort hinterlegen.

Das SLD ist eine Komponente von SAP NetWeaver und ist komplett mit Java-technologie implementiert. Sie wird ausgeliefert als jva-komponente auf einem Application Server java. Bei jeder installation eines NetWeaver mit Usage Type Application Server java ist das SLD autoamtisch mit installiert. Da beim SAP Solution Manager auch ein NetWEaver AS Java implementiert ist, aknn man auf dem Solution Manager auch ein lokales SLD betreiben.

Die Clients, welche Infomrationen an das SLD senden, werden Data supplier genannt. Jedes SAP-Produkt und auch unterstüzte Drittanbieterprodukte können als Data supplier für ein SLD dienen, indem man einfach den Hostnamen  und Port eingibt.

Clients können – und müssen logischerweise auch – Daten vom SLD lesen können – biespielsweise der solution Manager, wenn er wissen will, welchen SP-Level eine bestimmte SAP-Komponente gerade hat.

 

Hier ein nützliches Dokument von SAP über das SLD

SLD Topologien

Man kann ein SLD auf verschiedene Arten und Weisen betrieben. Jnede option hat verschiedene Vor- und Nachteile.

Grundsätzlich ist gleich vorweg zu sagen, dass es nicht ein SLD pro Systemlandschaft gibt, sondern mehrere. Es gibt immer ein sogenanntes Central SLD, welches alle informationen sammelt, und mehrere local SLDs.

Dafür gibt es ehrere Gründe. Stellt euch tmal ein großes Unternehmen mit vielen Niederlassungen in verschiedenen Ländern vor. Es wäre verständlich, dass die einzelnen Länder oder sogar Bundesländer ihre Systeme einzeln warten wollen und daher nur informationen über IHRE SAP-Systeme sehen wollen, und nicht auch noch über die SAP-Systeme in Indien oder sonst wo. Dafür braucht man ein dediziertes SLD werlches verschiedene Views auf die Daten des Gesamt-SLds bereitstellen kann.

In meinem post SAP: geschichte und Einführung habe ich außerdem die sogenannte Drei-Stufen-Landschaft vorgestellt. Dabei gibt es eine Landschaft zum Entwickeln neuer SAP-Systemlandschaten, eine zum Testen der zuvor entwickelten Landschaften, und eine zum produktivbetrieb. Natürlich wollen diejenigen, die ein System entwickeln oder testen, ebenfalls ein SLD haben, da die Systeme später im Produktivbetrieb ja auch mit einem SLD betrieben werden. Es wäre also schwachsinn, bie der Entwicklung und beim Test eines Systems ohne SLD zu arbeiten. ES amcht aber keinen Sinn, dafür das selbe SLd wie für den produktivbetrieb zu wählen, da dies zusätzliche Laust auf dem produktiv-SLD erzeugt, zu möglichen Fehlern führen kann, die die produktivlandschaft schädigen können, und weil die Entwickler und Tester nicht unbedingt den selben Vertrauensstatus haben wie ide Administratoren des produktivsystems. Deswegen sollte mana uch hier gesonderte SLDs haben.

Und desweiteren möchte man natürlich die Verfügbanrkiet des SLDs erhöhen, indem man mehrere SLDs aufsetzt, falls eines mal ausfällt.

Wenn es aber nun mehrere SLDs in einer Systemlandschaft gibt, muss es möglich sein, SLD-Daten zwischen diesen SLDs auszutauschen – denn wenn sie sich nicht unterhalten, hat jeder nur einen Teil der Gesamtinformationen über eine Systemalndschaft.

Deswegen gibt es verschiedene Methoden, SLD-Daten zwischen den SLDs auszustauschen:

• Vollautomatische Synchronisation. Wenn in einem SLD Daten geändert werden, werden diese änderungen autoamtisch an die anderen SLds weitergelietet. Die Synchronisation kann uni- oder bidirektional erfolgen. Sinn macht in den meisten Fällen bidirektional, das heißt immer das SLD, bei dem sich etwas an den SLD-Daten änder,t gibt diese an ein anderes SLD weiter. Bei unidirektional würden infomrationen nur weitergegeben werden, wenn sich bei dem SLD etwas ändert, welches als Data supplier definiert würde. Ändert sich was beim empfangenden SLD, sendet diese die informationen nicht weiter. Ausnahme: Man hat eine Art ring-Topologie gebaut, bei welchem im Stille-post-Prinzip ein SLD unidirektional seine Änderungen immer an einen Nachbarn weitergibt, dieser an den nächsten, usw. – bis ein _Kreis geschlossen wird. Die Synchornisation kann asynchron stattfinden. Ist ein SLD also beispielsweise mal down oder wird neugestartet, kann es sich währenddessen stattfindende Änderungen nachträglich von einem Partner-SLD abholen. Diese Synchronisation ist sehr wichtig, wenn man die Verfügbanrkit des SLDs erhöhen will, indem man zusätzliche SLDs hinzufügt, da somit ein automatisches Backup stattfindet. Desweiteren wird diese Synchronisation oft genutzt, wenn man ein SLD mit neuerem Release in die Landschaft integrieren will – man hotl sich die Daten vom alten SLD – ist das abgeschlossen, kann man das alte SLD ebenfalls upgraden oder ausschalten.Wichtig bie der automatischen Synchronisation ist, dass das unique path principle nicht verletzt wird. DAs bedeutet: Daten können immer nur auf einem Weg von einem SLD zum anderen gesendet werden.
• Automatische Weiterleitung von Data Suppliers (Birdge Forwarding). Funktioniert leider nur für bestimmte Daten. Manuell vorgenommene Äönderungen am SLD, etwa Businesssysteme, die für NetWeaver PI gebruacht werden), können nicht weitergeleitet werden. Diese option wird deshalb oft nur dann genutzt, wenn die  vollautomatische Snychronisation nicht geht.
• Manueller Datenexport und Datenimport, kombiniert mit dem Transport von SLD objekten mit dem Change and Transport System (CTS+). Eines der SLDs wird als Master SLD ausgewählt – von diesem aus kann man die anderen SLD Instanzen updaten.

in der Praxis werden immer mehrere dieser Mechanismen zur Synchronisation in kobmination genutzt. Dabei darf man aber nicht mehrere Mechanismen für die selben SLD Daten auf dem selben synchornisationspfad nehmen. Man synchronisiert also nicht von SLD A nach SLD B einmal vollautoamtisch und einmal mit automatischer Weiterleitung. Das macht ja schließlich auch keinen Sinn und erzeugt nur unnötigen Datenoverhaead. Es macht aber beispielsweise sinn, mit automatischer Weiterleitung zu synchroniisieren, und manuelle Än derungen, die so nicht wietergeleitet werden könnten, mit Import/Export zu synchronsiieren.

Nun gibt es einige Entscheidungen zu treffen

• wie viele SLD instanzen wollen wir in unserer SLD Landschaft haben
• Wo sollen wir diese SLD Instanzen laufen haben – entweder als dedizierte SLD Systems, die nur idese eine Aufgabe haben, oder verwaltete Systeme wie beim Solution Manager, oder eine Application Systeme, also einem NetWeaver, wo Applikationen drauf laufen

eine sehr wichtige Basis abhängig davon, wie man seine SLD-landschaft pülant, ist die Tatsache, ob man in seiner SAP-Gesamtsystemlandschaft die beiden Lösungen SAP NetWeaver PI und/oder Web Dynpro java applications nutzen möchte.

ohne NetWeaver PI und Webdynpro Java applications

Generell ist es empfohlen, ein SLD für die Entwicklungs- und Testlandschaft (Desing-time-SLD) zu haben, und ein SLD auf dem SAP Solution Manager, welches für die proudktivlandschaft zuständig ist.

Solltet ihr – aus welchem Grund auch immer, eure bestehende SLD-Topologie irgendwann einmal ändern müssen, liefern folgende SAP-notes Infos darüber, wie man bestimmte änderungen an der SLD-landschaft durchführt.

Die SLD data suppliers aller Systeme – also die Komponenten der vom SLD verwalteten Systeme sowohl in der entwicklungs-, Test- als auch in der Produktivumgebung, die ihre Daten an das SLD schicken, schicken diese na das SLD vom Soltuion manager.  Somit können bestimmte operationen für alle Komponetnen sämtlicher Landschaften durchgeführt werden. Und desweiteren kann man die Daten ssämtlicher Landschaften von einem einzigen SLD aus administrieren.

Bisher ist das Desing-Time-SLD noch nicht genutzt worden. Wir haben bisher die Data supplier so konfiguriert, dass sie alle das SLD auf dem Solution manager nutzen, egal ob die systeme in einer Produktivumgebung sind oder nicht.

Die SLD-Clients werden so konfiguriert: Die SLD-cleitns aller produktivsteme nutzen das SLD auf dem Solution Manager.

Die SLD-Cleitns der QA- und Entwicklungssysteme nutzen das Design-time-SLD.

Jetzt werdne sich einige von euch vielleicht denken: Ok…. wait what?

Also: Zurzeit ist es so: die Data suppliers aller Systeme senden technische informationen (beispielsweise überinstallierte SAP-Produkte und Drittanbieterprodukte auf dem System, installierte datenbankinstanzen auf dem System, Datenbankparameter usw.) nur an das SLD des SAP Solution Managers. Nur das SLD des SAP Solution managers verfügt also zurzeit über Landschaftsinformationen. Und derzeit sind auch nur die SLD-Clients der proudktivsyteme dazu in der Lage, Daten vom SLD des solution managers zu lesen, da nur sie auf das SLD des SolMan zugreifen. Die Qa- und Entwicklungssysteme greifne auf das noch leere SLD in der Design-Time zu.

Damit die QA- und Entwicklungssysteme mit dem Design-Time-SLD nun was anfangen können, müssen wir eine Art Synchronisation zwischen dem SolMan-Central-SLd und dem Design-Time-SLD hinkriegen. Dazu nutzen wir eine unidirektionale vollautomatische Synchronisation vom Central-SLD des SolMan zum Desing-Time-SLD. Das heißt: Alle Informationen und Änderungne im Solman SLD werden in das Design-Time-SLD übernommen.

Der Grund dafür, dass man die QA- und Entwicklungssysteme nun nicht direkt auf das Central-SLD zurgeifen lässt, ist der, weil es dadurch zu Problemen auf dem produktiven Central-SLD kommen könnte. So werden alle kritischen Prozeduren und Transaktionen der QA- und Entwicklungssysteme praktisch nur auf dem Design-Time-SLD durchgeführt und das Central-SLD ist sicher.

Mit NetWeaver PI und webdynpro Java applications

Die nutzung von NetWeaver PI und Webdynpro Java Applications verändern das Design ein wenig. Wir haben auch hier ein Design-Time-SLd für Entiwkclungs- und WA-Systeme. Wir hjaben auch hier ein SLD auf dem SAP Solution Manager. Was neu hinzukommt ist, dass wir nun zusätzlich ein SLD für unsere produktivsysteme haben.

in diesem Szenario ist das Central SLD nicht das SLD auf dem SolMan, sondern das SLD für die Produktivumgebungen. Alle Systeme in der Landschaft schicken mit ihren data supplieren ihre informationen an das Central-SLd. Auch die Data supplier des SLD auf dem Solution Manager schicken ihre Daten an das Central SLD der produktivumgebung.

Die SLD-Cleints werden dann wie folgt konfiuguriert: der SAP Solution manager nutzt sein eigenes SLD. die produktivsystem holen sich ihre SLD-Daten vom Central-SLD, und die Test- und QA-Systeme nutzen das Desing-time SLD.

damit das ganze funktioniert, müsen auch hier die Daten aus dem Central-SLd an die bieden anderen SLDs weitergegeben werden.  Das geschieht auch hier meist über eine undirektionale vollautomatishce Snchronisation. Das Central-SLd braucht aber manchjaml zusätzlich informationen über Business Syteme, Produkte und Softwarekompontenen aus der Testumgebung, weil diese Daten von NetWeaver PI gebraucht werden. Dazu exportiert man die Daten aus dem Design-Time-SLD auf das Central-SLD ü+ber das CTS+.

Landschaften in der Praxis

Die beiden oben gezeigten Szenarien zeigen uns also, dass wir mehrere SLDs brauchen. DAbei müssen diese SLds aber nicht extra auf einem besonderen Serverhost installier sein. die SLDs sind hierbi als logische Systeme zu sehen. Diese logischen Systeme können auch mit anderen logischen Systemen auf einem einzigen physikalischen Server laufen. Beispielsweise wäre es im Szenario mit NetWeaver PI und/oder Web/Dynrpo-applikationen möglich, dass das Design-time-SLD auf dem selben Host läuft, der NetWeaver PI zur Verfügung stellt.

Meistens wird zusätzlich zu den hier aufgezeigten SLDs ein sogenanntes Backup-SLD eingerichtet. dieses Basckup-SLD erhält die Datena us dem jeweiligen Central-SLD per unidirektionalem vollautomatischen Backup. Unter zuHilfenahme von virtuellen IP-Adressen (VIPA) ist es möglich, bei Bedarf sofort auf das Backup-SLD zu wechseln, wenn das Central-SLD mal Probleme hat.

die oben dargestellten Szenarien sind natürlich immer nur eine Stndardempfehlung. Man kann diese Szenarien jeweils nach eigenen Bedürfnissen customizen. Beispielsweise könnte es sinnvoll sein, dass eine Web Dynpro Anwendung ihr eigenes SLD nutzt und dazu Daten vom Central-SLD eingespeist bekommt.

Desiweteren kann es ja möglich sein, dass ein Beratungshaus oder ein Hosting Provider die SAP-Systemlandschaften mehrerer Kunden betreut. Hier könnte es beispielsweise sinnvoll sein, für jeden Kunden eines der besprochenen szenarien zu installieren, und von diesen Central-SLDs die Daten an ein Master-SLD ´weiterzuleiten, welches die SLD-.Daten aller Kunden enthält.

Daten in einem SLD, welche manuell erstellt wurden, werden nicht automatisch synchronisiert. diese müssen über die import-/Exportfunktion verteilt werden.

SAP-Note-Nummer	Titel	Beschreibung
9355474	Grupieren von SLD INstanzen	Diese Note beschreibt das zusammenführen von zwei SLD instanzen indem man den inahtl von einem in ein anderes SLD importiert
936318	Teilen von SLD instanzen	Diese Note beschreibt wie man eine SLD Instanz in zwei oder mehrere aufteilt
935245	Bedeutung des Object Server SLD PAramters	diese Note beschreibt die konsequenzen von Änderungen an einem SLD Server, die notwendig sein köntnen, wenn man ein SLD teilt
720717	Reduzieren der Anzahl von SLDs	Diese Note beschreibt was man in netWeaver PI machen muss, wenn man mehrere SLDs zusammenführt

 

Was ist die LMDB?

Die LMDB ist eine Komponenten vom SAP Solution M;anager, die mit dem Release 7.1 eingeführt wurde. die LMDB ist das Tool zur zentralisierten Verwlatung von Landschaftsdaten im SAP Solution Manager. die LMDB holt sich die informationen aus dem SLD durhc vollautoamtische Synchronisation. Der dadurch erworbene Inhalt enthält sowohl (technische Systeme, Business Systeme, manuell erstelle Produkte, Softwarekomponenten usw.)

Statt also auf dem Solution manager ein eigenes SLD zu haben, löäuft auf diesem die LMDB.

Für die Empfehlungen des Szenarios ohne NetWeaver PI und ohne Web Dynpro Anwendungen ändert isch nichts – hier sollte man weiterhin das oben beschriebene Szenario mit SLD anwenden.

Wenn man jedoch NetWeaver PI bzw. web Dynpro Anwendungen nutzen möchte, sollte man im unteren Szenario etwas ändern. statt einem SLD läuft auf dem Solution Manager die LMDB, welche sich die Daten vom Central SLD holt. Das Central Runtime SLD schickt seine Daten an die LMDB des SolMan durhc vollatuatomsiche Synchronisation.

Ein Hosting Provider hätte hier wieder die Central SLDs von zwei verschiedenen Kundenlandchaften. Anstelle eines Master SLDs kann er sich die daten an das LMDB einex zentralen SolMans schicken lassen.

Dabei muss aber auch hier das unique path principle erfüllt werden. Wenn sich die beiden SLDs untereinander bereits synchronisieren, dann darf nur eines der beiden SLDs mit dem LMDB verbunden sein, weil sonst die Daten der beiden SLDs auf zwei verschiedenen Wegen zum LMBD laufen können.

Der umgekehrte Weg: meherere LMDBs von einem einzigen central SLD speisen zu lassen, ist hingegen zulässig.

 

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!