Das SLD – nicht jeder mag es, aber alle brauchen es. Vermutlich ist letzteres der Grund, weshalb die SAP es geschafft hat, das SLD im Rahmen seiner jüngeren Produktpalette zu einem integralen Bestandteil jeder SAP Systemlandschaft zu machen. Hier ein Kurzüberblick über Hintergrund und Konzepte.
SLD – wozu eigentlich
Das SLD wurde eingeführt, um zentral Informationen zur SAP Landschaft und zu Ihren Systemen bereitzustellen. Dazu gehören neben technischen Namen, Hosts und Releases auch Anwendungsnamen und Komponentenversionen. Als konsumptives System erhält das SLD die Daten von seinen Systemkomponenten zugesandt. Sogenannte SLD Data Provider sammeln in regelmäßigen Abständen Daten in den einzelnen Subsystemen und senden diese an das Directory.
Das SLD stellt diese Informationen wiederum anderen Anwendungen bereit, bspw. dem Solution Manager, der Integrationsplattform PI oder der Netweaver Development Infrastructure.
Und die LMDB im SolMan..
.. ist so eine Sache. Die SAP entwickelt Ihre Produkte kontinuierlich weiter – einerseits erfreulich, andererseits sorgt das auch für immer neue Überraschungen, schließlich richtet man sich ja ein Stück weit im Status Quo ein. Der Königsweg zwischen dem SolMan-eigenen Systemlandschaftsüberblick (heute : LMDB) und dem SLD ist jedoch nach wie vor nicht gefunden.
Von der SAP wird empfohlen, das SLD trotz LMDB nach den gängigen Empfehlungen weiter zu verwenden, und die Daten vollautomatisch in die LMDB zu synchronisieren. Wenn kein SLD existiert (auch weil bspw. keine PI existiert) soll das SolMan SLD verwendet werden, um einen Endpunkt für die SLD Supplier zu haben.
Es kann nur einen geben?
Ein SLD allein ist oft nicht genug, um die Systemlandschaft sinnvoll abzubilden. Daher drängen sich zahlreiche integrative und infrastrukturelle Überlegungen an, wenn ein SLD aufgesetzt werden muss.
Trennung der SLD-Funktion in Ihrem Unternehmen
– nach Regionen (ein SLD für APA, eines für EMEA, usw.)
– nach Systemtyp (eines nur für nicht-produktive Systeme, eines nur für produktive)
– nach Funktion (ein Test-SLD, ein Produktions-SLD)
– nach Verfügbarkeitsanforderung (Stichwort SLD Data Clients)
Verteilung von SLD Daten
– vollautomatische Synchronisation (gelieferte und manuell gepflegte Daten, ab NW7.1)
– Bridge Forwarding der Data Supplier (nur gelieferte Daten)
– Manuell über Export oder CTS+
Die vollautomatische Synchronisation wäre bspw. ein schöner Weg, um das SLD Release zu wechseln. Nach Sync muss nur noch die Verbindung der Data Supplier zum neuen SLD hergestellt werden (Rekonfiguration / Hostnamenschwenk mit flushdns).
Platz ist in der kleinsten Hütte..
Die einfachste Konfiguration ist : keine PI, kein NWDI – nur ein wird SLD benötigt, und das gern integriert in eine bestehende Anwendung. Es bietet sich an, in kleinen SAP Infrastrukturen eine Möglichkeit zu suchen, ein weiteres dediziertes SAP System zu vermeiden. Gern verwendet wird hier der Solution Manager, natürlich SLD-fähig und selbst Landschaftsverwalter der ersten Stunde – oft sogar schon hoch verfügbar ausgelegt.
Ab einer gewissen Größe jedoch macht es Sinn, ein dediziertes SLD bereitzustellen. Dies hängt zum einen mit der Verfügbarkeit und zum anderen mit den SLD Service Consumern zusammen – wer die ganze SAP Produktpalette einsetzt (NWDI, SAP PI, Java WebDynpro, ACC), wird eher höhere Anforderungen an SLD-Verfügbarkeit stellen, und nicht bei jedem (der sehr häufigen) SolMan Patches ein Wartungsfenster einlegen können.
Die Vorteile des dedizierten SLD im Einzelnen :
- o die Hardwarekosten (und –anforderungen) sind überschaubar (selbst HA)
- o Sie sind unabhängig von Downtimes und Störungen einer anderen Anwendung
- o Können SLD-Downtimes flexibel einplanen
- o Sie müssen den SLD Release-Stand nicht mit einer Anwendung synchron halten
Ordnung muss sein – Struktur von mehreren SLD-Instanzen
Der Aufbau einer „SLD-Landschaft“ ist von verschiedenen Überlegungen geprägt. Es gibt bspw. die Empfehlung, für non-PI-Landschaften eine existierende Design-Time (bspw. für NWDI) SLD-seitig von der Runtime (für die Produktion, dann auf dem SolMan) abzukoppeln. So beeinflusst das nicht-produktive Entwicklungs-SLD nicht die produktiven Prozesse.
Die beiden Directories werden dann mit Automatic Forwarding zur Design Time zu synchronisiert.
Existiert eine PI, müssen die Data Supplier alle an einen PI-Runtime-SLD melden, da die PI immer aktuelle und vollständige Landschaftsinformationen lesen muss. SolMan SLD und DesignTime SLD werden dann von der Runtime „rückwärts über Forwarding“ mit aktuellen Daten versorgt. Sollten fallweise in den zwei Empfängern neue Objekte anfallen, werden diese manuell in die Runtime SLD gebracht.
Die SLD Planung birgt also die ein oder andere tiefergehende Überlegung. Sich im Kundenkreis (Stichwort DSAG und andere Kundenvereinigungen) und natürlich mit betroffenen Fachabteilungen / Entwicklern abzustimmen kann Ihnen wertvolle Impulse liefern.
Dies betrifft sowohl die gegenwärtige Situation, als auch den Blick in die Perspektive – stellen Sie sich auf die (absehbare) Zukunft ein.
Das Obligatorische
Diese Dokumentation ist eine Sammlung von Erfahrungswerten, und in keiner Form von den Produktherstellern (SAP, Oracle, ..) geprüft oder freigegeben worden. Es kann keine Haftung für Schäden übernommen werden, die aus dem (teilweisen oder vollständigen) Befolgen dieser Dokumentation entstehen.
Selbstverständlich freue ich mich über Fragen, Anmerkungen oder Ergänzungen.
