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!

SAPROuter ist ein Programm, das eine Art Zwischenstation in einer Netzwerkvebrindung zwischen SAP-Systemen oder zwischen einem SAP-System und der außenwelt, also beispielsweise dem SAP-Support, darstellt. SAPRouter dietn dabei dazu, den Zugagn zum Netzwerk zu Regeln, und stellt dazu ein Application level Gateway bereit – und ist daher nicht zu verwechseln mit einem Netzwerkrouter, der ein Network Level Gateway darstellt. Ein SAPRouter stellt somit eine Ergänzung zu einem gewöhnlichen Firewall-System dar.

Die Firewall, aus Heimnetzwerken kennen wir sie als Bestandteil unseres DSL-Routers, bildet eine undurchdringliche Mauer um unser Netzwerk. Da aber gewisse Verbindungen durch diese Wand hindurch kommen sollche,n  muss ein Loch in die Firewahll gemacht werden – beispielsweise könnten wir wollen, dass die Ports für unsere SAP-dienste offen sind. Damit geben wir den Verkehr aber für jede x-beliebige Anfrage frei, auch wenn ungebetene Gäste auf unsere SAP-Diesnte zugreifen wollen. Deswegen brauchen wir für dieses Loch in unserer Firewall einen Schließmechanismus, eine Art Tor, die das Loch bei Bedarf öffnen und wieder schließen kann. Dafür ist der SAPRouter da.

Der SAPRouter ermöglicht also die kontrolle des Zugangs zum SAP-System. Er kann desweiteren Verbindungen zum SAP-System protokollieren und ermöglicht somit eine Verfolgung und Analyse möglicherweise schädlicher Angriffe.-

Man kann mit SAProuter beispielsweise festlegen, dass auf ein SAP-System nur von bestimmten anderen Systemen mit SAPRoutern möglich sein soll. Wir können unsere Daten durch ein Kennwort gegen unberechtigten Zugriff schützen lassen, und wir können mit SAPRouter einstellen, dass wir nur geschützte SNC-Verbindungen auf unser SAP-system zulassen, die verschlüselt sind.

SAP Router kann dabei festlegen, welche Routen zum zielsystem erlaubt sind und welche Kennwörter für welche Route eingegeben werden müssen. mit einer sogenannte Route-permission-Tabelle überprüft er, welche Routen und Kennwörter gültig sind, und welche nicht.

Um einer SAP-Anwendung mitzuteilen, wie man über SAPROuter auf ein anderes SAP-System zugreift, benötigt men einen SAPRouter-String. In diesem String sind die informationen über den SAProuter, welcher den Zugriff zum gewünshcten SAP-Sstem regelt, hinterlegt, also beispielsweise entweder seine Ip-Adresse mit Port oder sein logischer NI-Name sowie das Passwort für die Router-Verbindung.

Ein Route String hat dabei die Syntax

/H/host/S/service/W/pass, wobei H, S und W Großbuchstsbaen sein mpssen.

H steht für den Hostnamen, S für den Port des dienstes, den man erriechen will (standard 3299), und W steht für das Kennwort.

Es können mehrere SAPRouter-Strings zusammengeschrieben werden, um eine komplette route zu definieren, sofern mehr als ein SAPRouter an der Route beteiligt ist. beispielsweise

/H/<host1>/S/<service1>/W/<passwort1>/H/<host2>/S/<service2>/W/<password2>

In diesem Fall spricht man bei jedem String, der einen Host bezeichnet, von einem Substring, in diesem Fall sind die bieden Subtrings

/H/<host1>/S/<service1>/W/<passwort1>

und

/H/<host2>/S/<service2>/W/<password2>

ein Route string beschirebt dabei eine gewünschte verbidnung zweier Hosts über einen oder mehrere SAPRouter. jeder dieser für die Verbindung involvierten SAProuter prü+ft dann anhand seiner route-Permission-Tabelle, ob die verindng zwischen seinem Vorgänge und seinem nachfolger erlaubt ist und stellt sie in diesem Fall her.

Im folgenden ein Beispiel. Ein SAP-Support-mitarbeiter arbeitet an einem Rechner namens sappc, und er möchte einen Rechner yourapp betreuen, der in einem Kundennetzwerk angesiedelt ist. Zwischen den beiden Rechnern sind zwei SAPRouter, einmal der SPARouter von SAP selbst, mit dem namen sap_rout, und einmal der SAProuter des Kunden, mit dem Namen your_rout. Der SAP-mitarbeiter möchte auf dem PC yourapp auf den Dienst mit der Portnummer 3298 zugreifen. Er muss in seinem SAPRouter-String alle beteiligten Hostnamen auf seinem Weg angeben. .Der SAPRouter-String sieht so aus

/H/sap_rout/H/your_rout/W/<Passwort>/H/yourapp/S/3298

Da in den ersten beiden /H/-Strings kein Passwort und kein Port angegebn wurden, werden hier die Standardwerte 3299 und ein leeres Kennwort benutzt.

Die Verbindung wird in folgenden Schritten hergestellt: Das Frontend des SAP-Support-mitarbeiters, beispielsweise SAP Logon, baut eine Verbindung zum SAProuter sap_rout gemäß dem ersten Substring auf und gibt die Routeninformation weiter. sap_rout prüft nun anhand der route-Permission-TRabelle, ob die Route „sappc zu your_rout Port 3299“ erlaubt ist, baut die Verbindung zum Kunden-SAP-Router your_rout auf und übergibt Substring 2 und 3. your_rout prüft jetzt anhand seiner Route-Permission-Tabelle, ob die Route „sap_rout zu your_app 3298″ erlaubt und das Kennwort gültig ist. SAProuter baut dann die Verbindung zum Awnendungsserver auf.

Ein SAProuter prüft also immer nur den vorherigen Hostnamen und en den nächsten Substring. Er prüft also in der regel nie die komplette route, es sei denn es gibt nur einen Substring insgesamt.

Wer sich über den technischen Aufbau einer Route-Kommunikation installiert, also den PRotokoll-Teil, kann hier gucken.

sie müssen also beispielsweise einen SAPRouter installieren, wenn Sie dem SAP-Support erlauebn wollen, auf ihr System zuzugreifen, aber keinen anderen.

Was macht SAPRouter? SAPRouter setzt auf der OSI-Schicht 4 auf und arbeitet dort mit dem SAP-proprietären Protokoll NI (Network interface). In der umgangssprahce wird das protokoll auch als SAP-protokoll bezeichnet. NI setzt dabei auf TCP oder UDP auf, das bedeutet, NI ist ebenfalls auch der OSI-Schicht 4, ist aber anwendungsnäher als TCP/UDP.

Was ändert sich mit der einführung von NI? Nun, wir wissen, dass UDP und TCP mit Portnummern arbeiten, beispielsweise Port 80 für HTTP-Verbindungen. Das NI-protokoll kann sowohl mit Ports aus UDP/TCP umgehen, als auch mit einer eigenen implementierung – sogenannte logische Namen. anstelle von hostname und Portnummer kann man beim NI-protkoll einen logischen Namen schreiben, etwa saposs für eine Verbindung zum SAP Support.

ein weiterer Clou ist, dass mitHilfe von SAPROUTEr und NI es möglich ist, zwischen zwei Local Area networks ohne routing über das WAN (Internet) eine Verbindung herzustellen – auch dann, wenn die bieden SAP-Systeme beispielsweise eine identische IP-Adresse haben (beiuspielswqeise 10.10.10.1 auf beiden Seiten).

download von SAPROuter

SAPRouter findet man im Software Download Center und Support Packages & Patches, also unter service.sap.com/patches und dann im Pfad Entry by Application Group / Additional Components /( SAPROUTER / SAPROUTER 7.00 / <Plattform>.

installation von SAPRouter

unter UNIX

Wir legen das Verzeichnis /usr/sap/saprouter an und downloaden die neuste Version von SAPROUTER. Wir extrahieren mit dem Tool SAPCAR das PAket saproouter*.SAR und kopieren und die dort enthatlenen Binaries niping und saprouter in das Verzeichnis /usr/sap/saprouter.

Falls der SAProuter auf der selben Maschien laufen soll wie eine SAP-instanzn, fügt man in die Datei /usr/sap/<SID>/SYS/exe/run/startspa folgende Zeilen ein

#

# Start saprouter

#

SRDIR=/usr/sap/saprouter

if [ -f $SRDIR/saprouter ]  ; then

    echo “\nStarting saprouter Daemon “ | tee -a $LOGFILE

    echo “—————————-“ | tee -a $LOGFILE

$SRDIR/saprouter -r -R $SRDIR/saprouttab  \

  | tee -a $LOGFILE &

fi

Im, normalfall jedoch läuft SAPRouter auf einem extra Rechner.

unter Linux

unter Windows

Wir müssen das Verzeichnis <Laufwerk>:\usr\sap\ anlegen. Wir extrahieren das saprouter*.SAR paket und kopieren die saprouter.exe und die niping.exe in das Verzeicznis.

Falls der SAPROUTER Esxervice in der vergangenheit bereits als srvany.exe eingetragen wurd,e entfernens eid ie Definition des SErviecs aus der registry und booten den REchner neu

Nun defnieren wir den Service mit folgendem Befehl

ntscmgr install SAProuter -b …\saprouter\saprouter.exe -p “service -r <parameter>“. Die punkte stehne für <laufkwerk>:\usr\sap

parameter steht für PAramter, mit denen saprouter gestartet werden soll.

Im Dienste-control-Panel sollte man noch einstellen, dass SAPRouter-Service nicht mit dem SYSTEM-Account läuft, sondern mt einem anderen User

Um die Fehlermeldung “The description for Event ID (0)” im Windows NT Eventlog zu vermeiden, müssen Sie in der Registry noch folgendes eintragen: Legen Sie unter HKEY_LOCAL_MACHINE →  SYSTEM → CurrentControlSet → Services → Eventlog → Application den Key saprouter an und definieren darunter die folgenden Values:

EventMessageFile (REG_SZ): ….\saprouter\saprouter.exe

TypesSupported (REG_DWORD): 0x7

Die Route-Permission-Tabelle

Die Route-Permission-Tabell bestimmt, welche Verbindungen SAPROUter später zulassen wird, und wird im Ordner /usr/sap/saprouter gepflegt. Die Datei sollte saprouttab heißen, also legen wir diese Datei an

touch /usr/sap/saprouttab

Unter Windows wird die saprouttab stnadarmdäßig im C:\WINDOWs\system32\-Ordern gepflegt. Das ist etwas umständlich und sollte mit einem anderen Pfad passieren. den anderen Pfad kann man beim Starten von SAprouter mit der Option -R angeben.

die Route-permission-Tabelle enthält die Hostnamen und Portnummern des vorgänger- und Nachfolgerpunktes der route aus Sicht des Saprouters sowei die Kennwörter, die für die herstellung der Verbindung erforderlich sind. Mit der tabelle wird festgelegt, welche Verbidnungen über den SAPROUTEr erlaubt sind und welche verboten sind. Desweiteren wird festgelegt, ob und welche SNC-verbindungen aufgebaut werden.

Standardeinträge in der Route-Permission-Tabelle sehen so aus:

<P|S|D> <quell-host> <zielhost> <zielport> <Passwort>

Quellhost und Zielhost können jeweils SAProuter sein.

Der erste ausdruck sagt etwas darüber aus, was mit der Verbindung passieren soll

• P = Permit – Verbindung erlauben. Permit Einträge können ein Kennwort enthalten. SAPRoute prüft dann, ob das Kennwort mit dem vom Client gesendeten übereinstimmt. Direkt nach dem P kann man noch eingeben, wie viele SAProuter höchsten vor und nach diesem auf der route sein dürfen, damit die Verbidnung gezulssen wird: P<v>,<n>, wobei v für die maximael Anzahl vor dem Route rsteht und n für died maximale Anzahl danach.
• S – Secure – elraubt nur Verbindungen mit SAP-Rptokoll (NI) verwendedn. Verbindungen mit Anderen Protokollen, etwa TCP, werden nicht zugelassen. mit S<v>,<n> können wieder maximale Anzahl von Vorgänger und nachfolgeroutern angegebenm werden
• D = Deny – Verbindung ablehnen.

Der Quellhost its dedr Rechner, von dem die Verbindung aus Sicht des SAPRouter skommt. Da kann ein Hostname, eine Ip-ADresse oder ein IP-Subnetz stehen.

Bei Zielhost kommt der rechner hin, an den aus Sciht des SAProuters die Verbindung hingegen soll. Auch hier kann ein Hostname, eine IP oder ein IP-subnetz stehen.

beim Zielport kommt der Port des dienstse ein, der erreicht werden soll. Hier kann man auch Port-Ranges angeben, indem man den die beiden grenzen des Portbereichs im Format <Anfang>.<Ende> hinschreibt, also z. B. 3200.3298.

Neben den STandardeinträgen gibt es noch sogenannte SNC-Einträge. Diese fangen mit dem Buchstbaen K an.

Es gibt zwei Arten von SNC-Einträgen

• KT-Einträge (Key Target). Hier wird entschiedne, wleche Verbidnungen SNC-verbindungen sein sollen. Das kann sowhl für eingehende als auch für ausgehende verbindungen vom SAProuter aus gesehen festgelegt werden. Die Syntax für eingehende Verbidnungen ist KT <SNCName Quellhost> <Quellhost> <Quelldienstport>. Das heißt, dass Verbidnugnen, die von dem Quellhost mit dem Quellport durch den SNCNamen <SNCName Quellhost> kommen, SNC-Verbidnugnen sein sollen. hiermit kann der Kunde z. b festlegen, dass Servicevebrindunge von SAP zu ihm SNC-Verbindungen sein müssen.Für ausgehnde Verbindungen ist die Syntax KT <SNCname zielhost> <Zielhost> <Zieldienst>.

Damit SNC-vebrindugnen überhaupt möglich sind, muss der SAPRouter mit der Option -K gestaretet worden sein, und die Route-permission-Tabelle muss entsprechende KT-Eitnmräge enthalten.

• KD, KP und KS-Einträge. sie haben die snytax K<D|P|S> <SncName quellhost> <zielhost> <zieldienst> <Kennwort>. das beduetet, dass die verschlüssellte SNC-Vebrindung von <SNCName quell<host> über SAProuter nach <Zielhost> <Zieldienstport> genua dann afugbeaut wird, wenn im Route String das korrkete Kennwort enthalten ist.

Der SAPROuter wertet die Route-permission-Tabelle nach bestimmten Regeln aus, die es bei der Erstellung der tabelle zu beachten gibt.

First Match

der erste eintrag in der route-permission-Tablele, für den Quell-Adresse, ziel-aDresse und zielport passen, ist maßgebend. auch wenn es danach noch Einträge gäbe, die auch auf die Route passen würden.

No match

Existiert für einen Route String kein passender eintra gin der tbaelle, wrid ide vebirndung zurückgewiesen, das vehralten sit aso, als wäre die letzte Zeile ein

D * * *

ausnahem bei Wildcards

Wenn nach dem SAprouter kein weiterer Saprouter auf der route kommt und der service kein SAp-Service (kein SAP-rpotkoll) ist, funktioniert die wildcard („*“) bei dem SErvice nicht. Dei Verbidnugn wird nur erlaubt, wenn der nicht-SAP-Service explizit angegeben wird. Um bspw. eine telnet verbindung zu erlauben, muss beim zielport ein telnet stehen – oder eine 23, weil das der port wäre.

Btw: aus sicherheitsgründen ist es Empfohen, in P- oder S-Zeilen keine Widlcards für Zielrechner und zielport zu verwenden.

Subnetze

Subnetze funktoinieren nach folgendem schema

156.56.*.*	Alle Hostadressen, die mit 156.56 beginnen
133.27.17.*	Alle Hostadressen, die mit 133.27.17 beginnen
133.27.16.0/24	Alle Hostadressen, die mit 133.27.16 beginnen (0/24 am Ende bedeutet, dass sie ersten 24 Bit relevant sind, also die ersten drei Blöcke)
156.56.1011xxxx.*	Alle Hostadressen von 156.56.176.* bis 156.56.191.*. (Binäre Interpretation des dritten Byte der Adresse. ‘x’ ist ein frei wählbarer binärer Wert (1 oder 0).)

Hier ein Beispiel einer route-permission-Tabelle

hier ein Beispiel mit SNC

die SAP Infoseite über SAPRouter befindet sich hier

Starten von SAProuter

Vor dem Starten von SAPROUTEr sollte man Testen, ob es Netzwerkprobleme gibt. Folgendermaßen kann man die Funktoinalität testen, um zu prüfen ob die SAPROUTER Grundkonfiguration passt.

	Fenster 2 (host2)	Fenster 1 (host1)	Fenster 3 (host3)
ohne SAProuter	niping -s		niping -c -H host2
mit SAProuter	niping -s	saprouter -r	niping -c -H /H/host1/H/host2

Wenn über 800 Verbidnugne aufrecht erhatlen werden sollen, empfeihlt SAp das Nachstarten von neuen Saprouter-Prozessen mit der Option -Y <n>. Damit werdden die Verbindungen auf mehrere Prozesse aufgeteilt – womit eventuell die CPU des Systems besser ausgereizt wird. Und: wenn ein Prozess abstürzt, betrifft es nicht gleich alle Verbindungen. Grundsätzlich gilt: ein SAPRouter pro500 Verbidnungen. Für 3000 Benutzer werden also 6 SAPRouter-Prozesse

host 1: SAPROUTEr-Rechner

host 2: Testserver

host 3: Testclient

ein Selbsttest für einen lokalen Host kann man mit niping -t durchführen.

Jeder dieser Prozesse benötigt etwa 4, MB speicher und 9% einer 2-Wege-HTT-3-Ghz-CPU, also insgesamt würden die Prozesse 30 MB speicher und 55% der CPU beanspruchen. Die empfohlene hardware für einen SAProuter mit 3000 paralllelen Verbindungen und etwa 8 kB Datentransfer pro Verbindung (Bildschirmwechsel in der SAPGui) were empfohlen:

• schnelle netzwerkadapter
• 2 Hyper-threading (HTT) CPUs mit 2 GHz Taktfrequenz
• 512 MB RAM
• 50 MB freier Festpalttenspeicherplatz

mit der option -C klönnen wir die Anztahl der maximalen Verbindungen auf 500 setzen. Dann wird bei der 501. Verbindung automatisch ein neuer SAPROUTER gestartet.

Unsere Startzeile schaut bisher so aus

saprouter -r -Y 0 -C 500

mit der Option -K erlaubven wir SNC-Verbindungen

saprouter -rK -Y 0 -C 500

 Einen OSS-Zugang beantragen

Damit der SAP Support auf ihr System kommt, müssen Sie für ihren SAPROUTEr ein OSS-Zertifikat beantragen. sie können SAP mit dem SAP Meldungsassistenten kontaktieren und darum bitten.

Der Wortlaut könnt sein

Sehr geehrte damen und Herren,

hiermit beantrgen wir ein SAProuter-zeritfikat für einen SNC-OSS-Zugang.

Hier die Daten unserer SAProuter-installation

<IP-Adresse des SAProuters>

<Hostname des SAProuters>

Der SAP Support antwortet ihnen dann, indem er ihnen die nötigen Ip-Adressen mitteilt.

Jetzt müsst ihr, damit die SNC-Verbdnung klappt,die sapcrypto Library in den SAPRouter integrieren.

https://websmp208.sap-ag.de/internetconnection

Zuerst müssen wir die Software herunterladen. Das geht über https://websmp208.sap-ag.de/saprouter-sncadd im Punkt SAP crypotgraphic Software. Bevor man die Software herunterlädt müssen folgende Voraussetzungen erfüllt sein:

• SAP hat in seiner Antwort die Genehmigung erteilt, die Software herunterzuladen. Dazu braucht SAP wiederum die Genehmigung des bundesausfuhramtes, das SAPRouter unter einer Exportbeschränkugen besteht. SAP braucht erst die Genehmig des Bundesausfuhramtes und kann dann erst die Cryptolib-Software auf dem Firmenaccount eures Unternehmens freischalten. Dementsprechend ist es auch untersagt, die sapcryptolib unterlaubt weiterzugeben.
• Man muss den Bestimmungen zustimmen

danach wird man weitergeleitet und kann die Datei sypcrypto.car herunterladen. diese kopieren wir in das Verzeihcnis, in welchem die saprouter-binary liegt. wir entapcken das Paket mit SAPCAR oder CAR.exe mittels car -xvf SAPCRYPOT.CAR. es erscheinten die Dateien [lib]sapcrypto[.so|dll|sl], sapgenpse[.exe] und die Datei ticket.

 

Jetzht müssen wir einen Zertifikatsrequest erstellen.

Dazu setzen wir als user <snc>adm die Ujmgebungsvariablen

SECUDIR = <SAprouter-Verzeichnis>

wir wechseln nun zu dem Alias SAPROUTER-SNCADD. Hier kann man asu einer Lsite, der für unsere installation registrieren SAProuter den Distinguides nmame auswählen. Man findet den Distinguished name in der spalte mit der übnerschrift Parameter.

Jetzt generieren wir mit folgendem Befehl das Zertifikatsrequest.

sapgenpse get_pse -v -r certreq -p local.pse "<Dinstinguished Name>"

Wir werden hier zweimal nach einer PIN gefragt. Wenn wir eine PIN genutzen wollen können wir diese frei wählen. Jedesmla, wenn wir died PSe benutzen wollen müssen wir dann diese PIN eingeben. Oder wir können die PIN-Afbrage mit Enter überspringen, dann kann die PSe ohne Pin benutzt werden.

alternativ kann man die foglenden Befehle zusammen verwenden.

sapgenpse get_pse -v -noreq  -p local.pse "<Distinguished Name>"

sapgenpse get_pse -v -onlyreq -r certreq -p local.pse 

Wir ezigen den inhalt der Datei certreq an und übernehmen ihn per copy&paste ion den vorgesehenn Beriehce auf er Seite, von der wir den Distinguished name kopier thaben.

Als Antwort erhatle wir eine Seite mit einem Zeritifkat, das von der CAim Service Marketplace signiert wurde. wir kopieren diesen Text in eine lokale Datei mit dem Namen srcert

Wir können jetzt durhc foglendne Afuruf das Zertifikat in den SAProuter installierne

sapgenpse import_own_cert -c srcert -p local.pse

Mimt demsleben Programm müssen wir jetzt die Credentials für dne SAProuter erstellen. Die Kommandozeilenoptoipn -o dient der angabe eines Benutzernamens, für den man die Credentials erstellen will. Lassen wir die optionw eg, dann generiert da sprogramm die Credentials für den bnuetzer, mit dem man beim Aufruf des Programms angemldet ist

sapgenpse seclogin -p local.pse -O <username>

Wenn wir etwa als Bneuzter ServerAdmin angemeldet sind, und saprouter aber unter dem Benutzerkonto saprouter_admin laufen soll, müssen wir saprouter_admin als Benutzernamen angeben.

Nun wird eine Datei n amens cred_v2 erzeugt. Diese Datie sollte nur für den user unter dem SAProuter läuft zugreifbar sein, also chmod 600.

wir überprüfen, ob das Zeritfikat erfoglreich importiert wurde

sapgenpse get_my_name -v -n Issuer

Der name des ausstellers sollte dann als „CN=SAProuter CA,OU=SAProuter,O=SAP,C=DE“ angezeigt werden.

fallsd as nicht der fall ist, die Datei cred_v2 und local.pse löschen und nochmal anfangen.

gut, jetzt müssen wir noch ein paar Schritte zum Abschluss durchführen.

Auf dem user, unbter dem SAprouter später läuft, müssen wir die Umgebungsvariable SNC_LIB setzen.

UNIX	<pfad_zu_libsecude>/<name_der_sapcrypto_library>
Windows NT, Windows 2000	<drive>:\<pfad_zu_libsecude>\<name_der_sapcrypto_library>

Wir müssen dann überprüfen, ob die umgebugn dieses Users die Umgebungsvariabel SNC_LIB enthält. Unter unix geht das mit dem Befehl printenvi.

mwir m,üssen SAProuter mit deme ntpsrechenden Befehl starten.

saprouter -r -S <port> -K „p:<Distingushed Name>“

Die zugehröige saprouttab sollte zumindest die folgenden Einträge enthatlen.

# inbound connections MUST use SNC

KP "p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE" <your_server1> <port_number>

# repeat this for the servers and port_numbers you will need to allow,

# please make sure that all explicit ports are inserted in front of a

# generic entry '*' for port_number

# outbound connections to <sapservX> will use SNC

KT "p:CN=sapserv2 OU=SAProuter, O=SAP, C=DE" <sapservX> <sapservX_inbound_port>

# permission entries to check if connection is allowed at all

P <IP address of a local host> <IP address of sapserv2>

# all other connections will be denied

D  * * *

die SAProutertab für eine SNc-verschlüsselte Verbidnugn zu SAProuter auf sapserv2 194.39.131.34 sähe dann bspw. so aus

# SNC-connection from and to SAP
KT „p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE“ 194.39.131.34 *

# SNC-connection from SAP to local R/3-System for Support
KP „p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE“ <R/3-Server> <R/3-Instance>

# SNC-connection from SAP to local R/3-System for NetMeeting, if it is needed
KP „p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE“ <R/3-Server> 1503

# SNC-connection from SAP to local R/3-System for saptelnet, if it is needed
KP „p:CN=sapserv2, OU=SAProuter, O=SAP, C=DE“ <R/3-Server> 23

# Access from the local Network to SAPNet – R/3 Frontend (OSS)
P <IP-addess of a local PC> 194.39.131.34 3299

# deny all other connections
D * * *

 

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!