Grundlagen und Praxis - Amazon S3€¦ · Bonn Boston Wolf Hengevoss, Dr. Andreas Linke SAP...

Bonn � Boston

Wolf Hengevoss, Dr. Andreas Linke

SAP NetWeaver System Landscape DirectoryGrundlagen und Praxis

®

1405.book Seite 3 Freitag, 28. August 2009 2:02 14

Auf einen Blick

1 System Landscape Directory .................................. 17

2 Sammlung der Daten für das SLD .......................... 37

3 Datenaustausch zwischen SLD-Systemen .............. 71

4 Nutzung des SLD: Client-Anwendungen ................ 113

5 SLD-Systeme in der Systemlandschaft ................... 137

6 Administration ........................................................ 151

7 Synchronisation im Detail ...................................... 175

8 Datenmodell ........................................................... 195

9 Registrierung von Nicht-SAP-Systemen ................. 225

10 Programmierung ..................................................... 241


7

Inhalt

Vorwort ................................................................................... 13

1 System Landscape Directory ................................... 17

1.1 Schlüsselfunktionen ................................................ 171.1.1 Landschaftsbeschreibung im SLD .................. 181.1.2 Client-Anwendungen des SLD ...................... 201.1.3 Typen von Daten im SLD .............................. 20

1.2 Konzepte des SLD ................................................... 211.3 Architektur ............................................................. 27

1.3.1 Pull- oder Push-Mechanismus: Datenerhebung im SLD ................................ 30

1.3.2 Verbindung von Systemen zum SLD ............. 321.4 Benutzeroberfläche des SLD .................................... 321.5 Anwendungsszenarien ............................................ 33

1.5.1 System-System-Kommunikation .................. 331.5.2 Systembetrieb .............................................. 341.5.3 Software-Entwicklung .................................. 35

2 Sammlung der Daten für das SLD ........................... 37

2.1 Arten von Daten und ihre Erfassung ........................ 392.1.1 Importierte Daten ........................................ 392.1.2 Automatisch erfasste Daten .......................... 402.1.3 Manuell erfasste Daten ................................. 48

2.2 Daten importieren .................................................. 492.2.1 Daten zum Softwarekatalog ......................... 502.2.2 Softwarekatalog-Daten und zugehöriges CIM

importieren .................................................. 532.3 Daten automatisch erfassen .................................... 55

2.3.1 Parameter der Registrierung im Ziel-SLD ...... 562.3.2 SLD Data Supplier in ABAP-basierten

Systemen ...................................................... 582.3.3 SLD Data Supplier in Java-basierten

Systemen ...................................................... 612.3.4 SLD-Registrierung in Drittanbieter-

Systemen ...................................................... 62


Inhalt

8

2.4 Daten manuell anlegen ............................................ 632.4.1 Daten zu Technischen Systemen .................... 632.4.2 Landschaften ................................................. 652.4.3 Business-Systeme manuell anlegen ................ 682.4.4 Software manuell anlegen ............................. 68

3 Datenaustausch zwischen SLD-Systemen .............. 71

3.1 Synchronisationsmechanismen im SLD .................... 713.1.1 SLD-Synchronisation durch Export und

Import .......................................................... 733.1.2 Bridge Forwarding ......................................... 823.1.3 Vollständige Synchronisation ......................... 86

3.2 Erweitertes Change and Transport System ............... 953.2.1 Anbindung des SLD an das

Change and Transport System ....................... 963.2.2 Einrichten der SLD-Transporte im

Transport Management System ..................... 1003.2.3 Durchführung von Transporten zwischen

zwei SLD-Systemen ....................................... 107

4 Nutzung des SLD: Client-Anwendungen ................ 113

4.1 SAP NetWeaver Process Integration: System-System-Kommunikation .............................. 1144.1.1 Integration Broker und Integration Builder .... 1164.1.2 Business-Systeme anlegen ............................. 1174.1.3 Abhängigkeit von SAP NetWeaver PI

und SLD ........................................................ 1234.2 Web-Dynpro-Java-basierte Geschäftsanwendungen:

Kommunikation mit Backend-Systemen ................... 1244.2.1 Verbindungsdefinition im Web Dynpro

Content Administrator .................................. 1254.2.2 Abhängigkeit von Web-Dynpro-Java-

basierten Anwendungen und SLD ................. 1274.3 SAP Solution Manager: Systemwartung und

Monitoring .............................................................. 1274.3.1 Maintenance Optimizer ................................. 1294.3.2 Root-Cause-Analysis ...................................... 130


Inhalt

9

4.3.3 Abhängigkeiten von SLD-Daten in administrativen Systemen ............................. 131

4.4 SAP NetWeaver Development Infrastructure: Entwicklung Java-basierter Anwendungen .............. 1314.4.1 Strukturierung von Softwaredefinitionen

im SLD ......................................................... 1324.4.2 Verwaltung der Entwicklungsumgebung ....... 1334.4.3 Namensreservierung für Softwareprojekte .... 134

5 SLD-Systeme in der Systemlandschaft ................... 137

5.1 SLD-Topologie ........................................................ 1375.1.1 SLD-Systeme in der Produktivlandschaft ....... 1405.1.2 SLD-Systeme in der Administrations-

landschaft ..................................................... 1405.1.3 SLD-Systeme in der Entwicklungs-

landschaft ..................................................... 1415.1.4 Synchronisationsmechanismen in der

Systemlandschaft .......................................... 1435.1.5 Sicherheitseinstellungen für SLD-

Verbindungen ............................................... 1455.2 Installation und Konfiguration eines SLD ................ 145

5.2.1 Installation ................................................... 1465.2.2 Konfiguration ............................................... 146

6 Administration ........................................................ 151

6.1 Wartung ................................................................. 1516.2 Log ......................................................................... 1526.3 Änderungen verfolgen ............................................ 1556.4 Veraltete Daten löschen .......................................... 1586.5 CIM Instance Browser ............................................. 1596.6 Sicherheit ............................................................... 165

6.6.1 SLD-Rollen ................................................... 1656.6.2 Gesperrte Benutzer ....................................... 1676.6.3 Sichere Kommunikation ................................ 169

6.7 Dimensionierung des SLD ....................................... 1696.7.1 SLD-Cache .................................................... 1696.7.2 Speicherverbrauch und Lastverhalten ............ 171


Inhalt

10

6.8 SAP-Support ............................................................ 1726.8.1 Support-Download ....................................... 1726.8.2 Wichtige SAP-Hinweise im SLD-Umfeld ........ 173

7 Synchronisation im Detail ....................................... 175

7.1 Manueller Export/Import ......................................... 1767.1.1 Backup von Daten ......................................... 1767.1.2 Inkrementelle Exporte ................................... 1787.1.3 Softwarekatalog aktualisieren ........................ 1807.1.4 Spezialexporte ............................................... 1817.1.5 Probleme beim Import .................................. 182

7.2 Automatischer Datentransport ................................ 1847.2.1 Data-Supplier-Weiterleitung ......................... 1847.2.2 Automatische vollständige

Synchronisation ............................................. 186

8 Datenmodell ............................................................ 195

8.1 Modellbasierte Datenablage .................................... 1958.2 Common Information Model ................................... 199

8.2.1 Klassen .......................................................... 2008.2.2 CIM Class Browser ........................................ 2058.2.3 Assoziationen ................................................ 2098.2.4 Kompatibilität ............................................... 213

8.3 SLD-Modell ............................................................. 2148.3.1 ABAP-Systeme .............................................. 2148.3.2 Java-Systeme ................................................. 2178.3.3 Weitere Klassen ............................................ 218

8.4 CIM im SAP-Umfeld ................................................ 223

9 Registrierung von Nicht-SAP-Systemen ................. 225

9.1 Data-Supplier-Registrierung mit dem Programm »sldreg« ................................................................... 2259.1.1 Einfaches Beispiel .......................................... 2279.1.2 Verwendung ................................................. 229

9.2 Datenformat zur Registrierung von Third-Party-Systemen ................................................................. 230


Inhalt

11

10 Programmierung ...................................................... 241

10.1 Web-Based Enterprise Management ....................... 24210.2 Java ........................................................................ 248

10.2.1 Instanzen lesen ........................................... 24810.2.2 Assoziationsverfolgung ............................... 251

10.3 ABAP ...................................................................... 25510.3.1 Konfiguration der ABAP-API ...................... 25610.3.2 Instanzen lesen ........................................... 25910.3.3 Assoziationsverfolgung ............................... 261

10.4 Weitere Programmiersprachen ................................ 263

Anhang ............................................................................ 265

A Weiterführende Literatur .................................................. 267

B Die Autoren ...................................................................... 269

Index ....................................................................................... 271


71

Da sich in größeren IT-Landschaften die Daten mehrerer SLDs häufig überlappen, ist ein Datenaustausch zwischen SLD-Systemen sehr wichtig. Einerseits minimiert dies den Aufwand bei der Datenpflege, und andererseits vermeidet man so Inkonsistenzen der Daten durch mehrfache Erhe-bung. Es gibt verschiedene Mechanismen zur Verteilung von SLD-Daten, die hier erläutert werden.

3 Datenaustausch zwischen SLD-Systemen

Gründe für den Betrieb mehrerer SLDs

In den meisten Fällen gibt es in der IT-Landschaft von Firmen meh-rere SLD-Systeme. Die SLDs komplexer Systemlandschaften sindnicht unabhängig voneinander: Die enthaltenen Daten werden inmehreren SLD-Systemen der Landschaft zugleich benötigt und daherzwischen den SLDs ausgetauscht. Neben Daten von Systemen undClient-Anwendungen werden auch manuell gepflegte Daten, diebereits in einem SLD verfügbar sind, in andere SLD-Systeme über-nommen (siehe Kapitel 5, »SLD-Systeme in der Systemlandschaft«).Man spricht hier von der Synchronisation von SLD-Systemen.

Die Verteilung der Daten auf mehrere SLDs resultiert aus der Tren-nung verschiedener Bereiche der IT-Landschaft: Entwicklungsdatenmüssen von Produktivdaten getrennt werden, aus Gründen derSicherheit sollen nur ausgewählte Systeme vor der Firewall stehen,eine Redundanz in der Datenhaltung sichert die Verfügbarkeit vonSLD-Daten in der Systemlandschaft usw. (siehe auch Abschnitt 5.1,»SLD-Topologie«). Die Eigenschaften der verschiedenen Mechanis-men des Datenaustauschs zwischen SLDs zu kennen ist die Voraus-setzung für einen effizienten Betrieb der SLD-Systeme.

3.1 Synchronisationsmechanismen im SLD

Es gibt unterschiedliche Mechanismen der Synchronisation, die anverschiedenen Punkten der Landschaft eingesetzt werden, um den


72

Datenaustausch zwischen SLD-Systemen3

Abgleich so weit wie möglich zu automatisieren und dadurch – ver-glichen mit der wiederholten Eingabe der Daten – kostengünstigerund weniger fehleranfällig zu machen. Die gängigen Methoden zumAbgleich von Daten im SLD sind:

Synchronisations-mechanismen

� Export/ImportHierbei wird der Inhalt eines SLD manuell exportiert und inandere SLDs importiert. Das geschieht über eine Datei oder überdas erweiterte Change and Transport System (CTS+).

� SLD Bridge ForwardingÜber die sogenannte Data Supplier Bridge werden die durch SLDData Supplier gelieferten Daten der Technischen Systeme anandere SLDs weitergeleitet. Einmal eingerichtet, funktioniert dieVerbindung kontinuierlich.

� Vollständige SynchronisationDie vollständige Synchronisation (Content Sync, ab SAP NetWeaver7.1) transportiert alle Daten zwischen SLD-Instanzen, bei denendiese Funktion eingerichtet wurde – in eine Richtung oder wech-selseitig zwischen SLDs. Die vollständige Synchronisation erfolgtautomatisch, wenn sie einmal eingerichtet und aktiviert wurde.

Der Unterschied zwischen den Synchronisationsoptionen besteht nichtnur in der Art der Umsetzung – z.B. automatisch oder manuell –, son-dern auch darin, welche Arten von Inhalten transportiert werden.Tabelle 3.1 fasst noch einmal alle Funktionen und ihre Merkmalezusammen.

Methode Auto-matisch

Transport aller Daten

Filter möglich

Verwendung

Export/Import nein ja ja gelegentlicher Abgleich (auch manu-ell erfasster SLD-Daten)

Bridge Forwarding

ja nein nein regelmäßiger Abgleich von Daten zu Techni-schen Systemen

Vollständige Synchronisa-tion

ja ja nein ständiger Abgleich aller SLD-Daten, uni- oder bidirektional

Tabelle 3.1 Synchronisationsmechanismen im SLD


73

Synchronisationsmechanismen im SLD 3.1

Die folgenden Abschnitte erläutern die Synchronisationsmechanis-men im Einzelnen. Auf die technische Funktionsweise gehen wir inKapitel 7, »Synchronisation im Detail«, noch genauer ein.

3.1.1 SLD-Synchronisation durch Export und Import

Der Export von Daten ist der einfachste Fall des Datenaustauschszwischen SLD-Systemen: Inhalte eines SLD – nennen wir es dasQuell-SLD – werden in einer ZIP-komprimierten XML-Datei expor-tiert, die wiederum in beliebig viele Ziel-SLDs importiert werdenkann. Danach sind die Inhalte des Exports Teil des Inhalts des Ziel-SLD.

Das ZIP-Archiv enthält dabei wesentliche Metadaten, die Prüfungendes Inhalts erlauben, sodass z.B. nur zur CIM-Modell-Version imZiel-SLD passende Daten importiert werden (Einzelheiten finden Siein Abschnitt 7.1, »Manueller Export/Import«). Dieses Verfahren hatden Nachteil, dass es ein rein manueller Prozess ist; es bietet alsonicht die bereits besprochenen Vorteile der Aktualität und Fehlerar-mut eines automatischen Prozesses. Dass dieses Verfahren dennochverwendet wird, liegt an drei wesentlichen Vorzügen:

Vorteile� VollständigkeitEs können Daten eines SLD exportiert werden – das umfasst alleimportierten, automatisch gesammelten und manuell ergänztenDaten.

� FilterbarkeitEs müssen nicht alle Daten exportiert werden – beim Erzeugen derExportdatei können Sie festlegen, welche Arten von Daten dieseenthalten soll.

� KontrolleWegen der manuellen Durchführung und Filterbarkeit kanngenau bestimmt werden, welche Daten zu welchem Zeitpunkt inein SLD übernommen werden.

Diese Eigenschaften erlauben eine genaue Steuerung der verteiltenDaten. Der Exportfilter setzt an Typen von SLD-Daten an – alle Datendieses Typs (z.B. CR-Daten) oder ausgewählte Datensätze (Techni-sches System, Business-System usw.) werden exportiert. Auch einExport aller SLD-Daten ist möglich.


74


Die Vorgehensweise beim Import wird im folgenden Abschnitt»SLD-Daten: Export und Import durchführen« auf Seite 75 gezeigt.Beim Import werden fehlerhafte Objekte nicht übernommen. EinBeispiel für einen Fehler wäre das Laden eines Business-Systems,dessen Technisches System im Ziel-SLD unbekannt ist. Dann wirdzwar das Business-System übernommen, aber nicht die Assoziationzum Technischen System. Eine Anwendungsmöglichkeit der Import-funktion haben Sie mit dem initialen Import von SLD-Daten bereitskennengelernt.

Berechtigungen fürden Export

Für den Export von Daten sind Berechtigungen nötig, die wiederumvon der Art der exportierten Daten abhängen:

� Für den Export von Daten des Softwarekatalogs (Produkte oderSoftwarekomponenten) brauchen Sie mindestens die Rolle LcrIn-stanceWriterCR und ihre Berechtigungen.

� Für den Export von Technischen Systemen und Business-Syste-men brauchen Sie die Rolle LcrAdministrator.

Der Unterschied in den benötigten Rollen liegt darin, dass Produkteund Softwarekomponenten auch in der Entwicklungslandschaft (imder Entwicklungslandschaft zugeordneten »Design-Time SLD«)gepflegt und transportiert werden sollen. Zum Import wird aberimmer ein User LcrAdministrator benötigt (das gilt auch für dieCTS+-Konfiguration des Ziel-SLD, wenn der Export/Import mit demerweiterten Transportwesen des SAP NetWeaver AS gekoppeltwird). Einzelheiten zu diesen Berechtigungen finden Sie in Abschnitt6.6, »Sicherheit«.

Hinweis

Wenn Sie Daten eines beliebigen Typs importieren, werden die Daten, dieim Ziel-SLD bereits zu diesem Typ vorhanden sind, ergänzt. Auf dieseWeise verlieren Sie keine Informationen, jedoch werden fehlerhafteDaten auch nicht korrigiert. Es gibt allerdings folgende Ausnahmen:

� Wenn ein Objekt, das Sie importieren, denselben Namen trägt wieeines, das schon im Namensraum des Ziel-SLD vorhanden ist, wird die-ses Objekt überschrieben. Einzelheiten dazu finden Sie in Abschnitt 7.1,»Manueller Export/Import«.

� Beim inkrementellen Import (siehe Abschnitt 7.1.2, »InkrementelleExporte«) werden auch Löschungen von Objekten transportiert.


75


Ein Anwendungsfall der Synchronisation durch Export/Importwurde bereits in Abschnitt 2.1.1, »Importierte Daten«, beschrieben:Das Master Component Repository, aus dem heraus Daten zu SAP-Produkten exportiert werden, ist nichts anderes als ein zentrales SLDbei SAP, dessen Daten an jedes SLD bei Kunden und Partnern weiter-gegeben werden.

SLD-Daten: Export und Import durchführen

SLD-NamensraumDas Exportieren von Daten erfolgt im SLD selbst, das Importieren imSLD oder über das Change and Transport System (siehe Abschnitt3.2, »Erweitertes Change and Transport System«). Bevor das Vorge-hen bei Export und Import beschrieben wird, soll zunächst das Kon-zept der Namensräume (Namespaces) erläutert werden.

Daten werden im SLD in Namensräumen verwaltet – das erlaubt es,bestimmte Datenmengen voneinander zu isolieren. Jedes SLD ent-hält einen Namensraum sld/active. Um weitere Namensräume anzu-legen oder zu einem anderen Namensraum zu wechseln, genügt es,den Namen des zurzeit aktiven Namensraumes auf der Startseite desSLD zu wählen. Wichtig ist an dieser Stelle, dass Daten, die ins SLDimportiert werden, nur in dem zum Zeitpunkt des Imports ausge-wählten Namensraum sichtbar werden. Die Namensräume in Quell-und Ziel-SLD müssen nicht gleich benannt sein, um denExport/Import durchführen zu können.

Abbildung 3.1 Auswahl und Pflege von Namensräumen im SLD

Über den als Link dargestellten Namen des ausgewählten Namens-raumes oder über Administration � Namespaces gelangt man zu derListe verfügbarer Namensräume (siehe Abbildung 3.1). In der Abbil-dung sind zwei Namensräume dargestellt: sld/active und sld/test.Der Inhalt beider Namensräume kann unterschiedlich sein (z.B.kann ein Testimport neuer Daten in den Namensraum sld/test vor-genommen werden, bevor er im Namensraum sld/active durchge-


76


führt wird). Der hervorgehobene Namensraum ist der aktuell imSLD-UI verwendete Namensraum. Unter Edit Namespaces... findenSie folgende Optionen:

� AddHinzufügen eines Namensraumes

� RemoveLöschen eines Namensraumes und aller enthaltenen Daten

� Remove InstancesLöschen aller Daten eines Namensraumes (das aktuell geladeneDatenmodell wird jedoch behalten)

� Remove Landscape DataLöschen aller technischen Systemdaten (die Informationen desSoftwarekatalogs sowie das Datenmodell werden jedoch behalten)

� FilterEinschränken einer Suche hinsichtlich bestimmter Kriterien (z.B.Namensteile)

Für die Datenverteilung über andere Synchronisationsmechanismenim SLD (Bridge Forwarding und vollständige Synchronisation) gilt dasNamensraumkonzept ebenfalls: So kann z.B. beim Datenaustauschüber die Data Supplier Bridge festgelegt werden, dass Daten der DataSupplier gleichzeitig an mehrere Namensräume in ihrem Ziel-SLDversendet werden. Das wird allerdings im Ziel-SLD und nicht beimAufsetzen der Verbindung der Data Supplier in den Technischen Sys-temen bestimmt (siehe Abschnitt 3.1.2, »Bridge Forwarding«).

Beispiel fürdie Verwendung

des Export-Mechanismus

Wir erläutern den Export nun anhand eines Beispiels: Der Inhalteines Namensraumes soll an ein anderes SLD geliefert werden. Eswird keine Eigenentwicklung betrieben, daher müssen die Datenzum Softwarekatalog nicht ausgetauscht werden (in beiden SLDssind bereits die Daten aus dem Softwarekatalog von SAP vorhanden).Es wurden jedoch Business-Systeme angelegt und mit TechnischenSystemen verknüpft. Diese sollen in das Ziel-SLD übernommen wer-den. Wir benötigen also einen Filter. Der Datentransport soll einma-lig und kontrolliert erfolgen, daher wählen wir als Mechanismus fürden Abgleich den Export/Import der Daten (siehe auch Tabelle 3.1 inAbschnitt 3.1). Der Prozess beginnt mit dem Export im Quell-SLD.Die Exportfunktion steht unter Administration � Content �

Import/Export zur Verfügung. Wie auf den Reitern in Abbildung 3.2zu sehen, gibt es drei verschiedene Arten des Exports:


77


Verschiedene Exportarten

� Back UpHier werden entweder alle Instanzen, das Common InformationModel (CIM), die (CIM-)Instanzen entsprechend den ExportlinienCR (Component Repository), LD (Landscape Directory) oder NR(Name Reservation) oder einzelne Klassen des CIM-Modellsexportiert.

� Incremental ExportDiese Option erlaubt es, bestimmte Stände des SLD-Inhalts zuexportieren. Es können alle oder eine bestimmte Exportlinieexportiert werden (Einzelheiten dazu finden Sie in Kapitel 7, »Syn-chronisation im Detail«).

� Administrate Incremental ExportsDiese Funktion erlaubt das Auflisten, Herunterladen und Löschenvorheriger Exporte.

Abbildung 3.2 Backup von Landschaftsdaten im SLD

ExportlinienAbbildung 3.2 zeigt einen Export zum Zwecke des Backups. AlsExport Line wird das Landscape Directory gewählt. Dessen Datenenthalten auch Business-Systeme, die manuell angelegt wurden.Ebenso wären ein kompletter Export oder der Export anderer Teileder SLD-Daten möglich. Abbildung 3.3 zeigt den Backup-Exportnach dem erfolgreichen Lauf. Eine ZIP-Datei wurde erzeugt, das»LD« in ihrem Namen weist auf die Landscape-Daten hin (siehe Kapi-tel 7, »Synchronisation im Detail«).

Abbildung 3.3 SLD nach erfolgreichem Export von Landschaftsdaten


78


Export-Format Um zu zeigen, dass die Daten zu den Business-Systemen Teil desExports sind, kann man die Exportdatei öffnen. Abbildung 3.4 zeigtden Inhalt der Datei export01.xml, die Teil der ZIP-Datei ist. Ein Teilder Daten der XML-Exportdatei sind Daten zum Business-SystemBSyst_01.

Abbildung 3.4 Daten zu Business-Systemen in der Exportdatei des SLD

In gleicher Weise wie die Daten des Landscape Repositorys könnenauch die Daten des Component Repositorys, die der Name Reserva-tion oder alle SLD-Daten (mit der Option All Instances) exportiertwerden. Alternativ lassen sich auch gezielt einzelne Business-Sys-teme exportieren.

Release-Kompati-bilität bei Export

und Import

Die Exportdatei kann in SLDs aller Releases importiert werden. Dabeimuss die CIM-Modell-Version im Ziel-SLD mindestens der des expor-tierenden SLD-Systems entsprechen. Ist die CIM-Modell-Version imZiel-SLD älter, muss vor dem Import der SLD-Daten eine CIM-Modell-

Hinweis

Im Betrieb des SLD ist es nicht nötig, die ZIP-Dateien des Exports zu öff-nen, denn diese müssen unverändert ins Ziel-SLD importiert werden, dasie Metadaten für die Prüfung des Imports enthalten.

Hinweis

Namenspräfixe, die für die Entwicklung mit der NWDI angelegt wurden(siehe Abschnitt 4.4.3, »Namensreservierung für Softwareprojekte«), kön-nen nicht direkt für den Export ausgewählt werden. Diese Daten sind Teilder Component-Repository-Daten (CR) und müssen zusammen mit die-sen oder in einem kompletten Export (All Instances) exportiert werden.


79


Version importiert werden, die mindestens der im exportierendenSLD entspricht. Ist die CIM-Modell-Version im Ziel-SLD zu alt, zeigtdas SLD beim Import eine entsprechende Warnung an.

Auswahl der Quelle für Dateien zum Import

Der Import von SLD-Daten ist – ebenso wie der Export – Teil derAdministration des SLD. Abbildung 3.5 zeigt den Import einer ZIP-Datei mit SAP-CR-Content. Sie wählen aus, von wo die zu importie-rende Datei geladen wird (From Browser oder From Server). Siekönnen Dateien aus dem Dateisystem des Client-Rechners, auf demder Dateibrowser des Anwenders läuft, manuell auswählen oderDaten automatisch vom SLD-Server laden. Ist die Auswahl erfolgt,wird der Import gestartet (die Information No import suggestions

for this namespace bedeutet, dass auf dem Server keine neuerenDaten vorhanden sind als die im SLD aktiven – in unserem Beispielist diese Option daher nicht aktiv).

Abbildung 3.5 Import einer SLD-Exportdatei im Ziel-SLD

Test-Namens-räume

In der Abbildung ist nicht der Standardnamensraum sld/activegewählt, sondern ein speziell angelegter Namensraum sld/test. Mitsolchen Namensräumen kann z.B. der Import getestet werden, bevorer in den Standardnamensraum übernommen wird. Nachdem einImport gestartet wurde, überprüft das SLD die vorliegenden Parame-ter:

� Liegt das passende CIM vor? (Ist das CIM im Ziel-SLD älter als dasdes Quell-SLD, muss es also aktualisiert werden?)

� Enthält das Ziel-SLD des Imports bereits Daten der Kategorie desExports? Ist dies der Fall, könnten Daten im Ziel-SLD überschrie-ben werden. Der Nutzer hat nun die Möglichkeit, den Importabzubrechen (Cancel Import) oder trotz der Warnung durchzu-führen (Import Anyway), wie Abbildung 3.6 zeigt.


80


Abbildung 3.6 Warnung beim Import überlappender Inhalte

Vorgehen beimImport

Wird der Import gestartet, zeigt das SLD den Fortschritt des Importsan und bietet außerdem die Möglichkeit, den Import über den But-ton Stop Import zu stoppen (siehe Abbildung 3.7).

Abbildung 3.7 Laufender Import-Prozess im SLD

Ist ein Import beendet, zeigt das SLD dies auf der Administrations-seite des SLD an (siehe Abbildung 3.8).

Abbildung 3.8 SLD nach erfolgreichem Import einer Exportdatei

Jedes importierte Objekt ist sofort im SLD aktiv und wird in demNamensraum angezeigt, in dem der Import erfolgt ist. Wenn eine

Hinweis

Wenn beim Import eine Warnung wie die oben gezeigte erfolgt, solltenSie den Import abbrechen, das in der Meldung beschriebene Problembeheben und den Import anschließend durchführen.

Achtung!

Beim Import eines Backups werden bereits existierende Daten ohne War-nung überschrieben.


81


Client-Anwendung des SLD also den Default-Namensraum sld/activeliest, findet sie keine Daten, die in den Namensraum sld/test impor-tiert wurden.

Hinzufügen und Überschreiben von Daten

Im entsprechenden Namensraum werden sowohl die zuvor vorhan-denen Business-Systeme des Ziel-SLD als auch die neu hinzugekom-menen angezeigt. Ein Überschreiben aller vorhandenen Daten einerKategorie durch die importierten Daten findet also nicht generellstatt; es kann bei Namensgleichheit von Objekten allerdings zumÜberschreiben von Daten kommen.

Gründe für den Einsatz von Export und Import

Der Export und Import von SLD-Daten ist also ein Prozess mit fun-dierter Unterstützung durch das SLD, der zudem – im Gegensatz zuden übrigen Synchronisationsmechanismen – eine Datenfilterungerlaubt. Wegen des relativ hohen manuellen Aufwands und deretwas längeren Dauer des Imports größerer Exporte ist diese Funk-tion nur in folgenden Fällen zu empfehlen:

� Sie benötigen eine Filterung der Daten, z.B. sollen für die ProcessIntegration nur Daten zu Business-Systemen transportiert werden.

� Sie wollen (auch) manuell erzeugte SLD-Daten in ein anderes SLDübernehmen, und andere Mechanismen, die alle Daten übertra-gen, sind nicht verfügbar.

Ein Beispiel für den Einsatz von Export und Import ist ein Szenario,in dem ein neues SLD aufgesetzt wird, z.B. als Nachfolger des bisherverwendeten, wobei die erneute Eingabe aller manuellen Daten ver-mieden werden soll. Das neue SLD kann stattdessen durch Exportund Import befüllt werden. Nach dem initialen Abgleich könnten dieData Supplier aller Systeme auf dieses SLD umgesetzt werden, dasdann alle Informationen des ursprünglichen SLD enthält. Die Bedeu-tung dieses Szenarios nimmt allerdings mit der Verfügbarkeit dervollständigen automatischen Synchronisation stark ab, wie inAbschnitt 3.1.3, »Vollständige Synchronisation«, gezeigt wird. Füralle Fälle, in denen weiterhin der Export/Import von SLD-Datengenutzt werden soll, ist die Nutzung des erweiterten Change andTransport Systems (CTS+) eine eingehende Prüfung wert, weil damiteine weit bessere administrative Kontrolle der Transporte von SLD-Daten möglich ist. Einzelheiten erfahren Sie nach der Diskussion derübrigen Synchronisationsmechanismen in Abschnitt 3.2, »Erweiter-tes Change and Transport System«.


175

Im SLD sind verschiedene Mechanismen zum Transport von Daten und zur Synchronisation von Änderungen zwischen verschiedenen SLDs implementiert. In diesem Kapitel beschreiben wir die Funktionsweise im Detail und gehen auf mögliche Probleme und deren Behebung ein.

7 Synchronisation im Detail

Ursprünglich war das SLD als ein einziges Verzeichnis der gesamtenSAP-Landschaft in einer Firma vorgesehen. In der Praxis hat sichjedoch gezeigt, dass je nach Firmenstruktur und Anwendungsszena-rien häufig mehrere SLDs eingesetzt werden. In Kapitel 3, »Daten-austausch zwischen SLD-Systemen«, wurden bereits die verschiede-nen Möglichkeiten der Verteilung von Daten vorgestellt und derenKonfiguration erläutert. In diesem Kapitel gehen wir nun detaillier-ter auf die im Hintergrund verwendeten Mechanismen ein. DiesesWissen kann für die Beurteilung der Vor- und Nachteile der verschie-denen Transportmechanismen hilfreich sein und bei Problemensowie bei der Fehlersuche helfen.

Manueller und automatischer Transport

Für die Synchronisation und Weiterleitung von Daten zwischenSLDs gibt es verschiedene Möglichkeiten. Prinzipiell unterscheidetman dabei zwischen manuellem und automatischem Transport.Manuell können Daten entweder über das Dateisystem als ZIP-Dateien exportiert und importiert oder mit einem CTS zentralgesteuert transportiert werden (siehe Abschnitt 3.2, »ErweitertesChange and Transport System«). Neben der schon seit Langem vor-handenen Möglichkeit, technische Systemdaten automatisch mit derData-Supplier-Weiterleitung zu transportieren, gibt es ab Release 7.1die Möglichkeit, den gesamten Dateninhalt von SLDs komplett, alsoeinschließlich der manuell gepflegten Daten, zu synchronisieren. DieSynchronisation kann dabei uni- oder bidirektional durchgeführtwerden.


176

Synchronisation im Detail7

7.1 Manueller Export/Import

Das SLD bietet zwei unterschiedliche Mechanismen für den manuel-len Datenexport. Daten können entweder als komplette CIM-Instan-zen oder als Änderungen von CIM-Instanzen exportiert werden. Daserste Verfahren wird Backup genannt und ist etwa vergleichbar mitdem klassischen Kopieren von Dateien. Beim Import eines Backupswerden bereits existierende Daten überschrieben. Das zweite Verfah-ren wird im SLD als inkrementeller Export (Incremental Export)bezeichnet. Es entspricht etwa dem Nachführen von Änderungen ineiner Datenbank mit dem Redo-Log. Beim inkrementellen Export wer-den alle Änderungen an den SLD-Daten (Anlegen, Löschen, Modifi-zieren) seit dem letzten Export gespeichert. Im Folgenden gehen wirzunächst auf die verschiedenen Backup-Möglichkeiten ein und wid-men uns dann der Funktionsweise des inkrementellen Exports.

7.1.1 Backup von Daten

Backup-Arten Das SLD-UI bietet verschiedene Backup-Varianten an (siehe Abbil-dung 7.1). All Instances ist die am häufigsten verwendete Backup-Art und sichert alle im SLD enthaltenen Daten (mit Ausnahme desCIM-Modells).

Abbildung 7.1 Backup-Seite im SLD-UI

Das aktuell geladene CIM-Modell lässt sich separat sichern. Umgezielt Teilbereiche der SLD-Daten zu sichern, gibt es zudem die Aus-wahl nach Exportlinien (Instances by Export Line). Tabelle 7.1 zeigtdie verschiedenen Exportlinien und die damit abgedeckten Daten.Einzelheiten zur Unterteilung der Daten im SLD wurden bereits inKapitel 1, »System Landscape Directory«, erläutert. Die zur Verfü-


177

Manueller Export/Import 7.1

gung stehenden Exportlinien korrespondieren mit dem QualifierSAP_SchemaSubset (siehe Kapitel 8, »Datenmodell«).

Schließlich besteht noch die Möglichkeit, Instanzen einzelner CIM-Klassen zu sichern. Diese Backup-Art wird in der Praxis nur sehr sel-ten verwendet und setzt detaillierte Kenntnisse des Datenmodellsvoraus.

Während des Backups ist das SLD für Änderungen gesperrt. Aufdiese Weise wird ein konsistenter Zustand des Backups einschließ-lich aller enthaltenen Verknüpfungen sichergestellt.

Beim Import müssen die zu importierenden Daten vom ObjectManager auf ihre Kompatibilität zum Modell und zu den bereits exis-tierenden Daten geprüft werden (z.B. das Vorhandensein der Assozi-ationsenden und die Einhaltung von Kardinalitätsregeln). Das ist beigroßen Datenmengen relativ zeitaufwendig und führt z.B. dazu, dassein Import normalerweise mit der Zeit (und der damit ansteigendenDatenmenge) immer langsamer wird. Beim Import von in sich kon-sistenten Daten in einen leeren Namensraum sind diese Prüfungennicht notwendig, deshalb erfolgt hier ein sogenannter Fast Import.Dabei wird darauf vertraut, dass die zu importierenden Daten in sichkonsistent sind. Um zusätzlich Zeit zu sparen, wird bei einem initia-len Import kein Change Log geschrieben.

SLD-Daten kopieren

Wenn Sie ein SLD kopieren oder neu aufsetzen und die vorhandenenDaten einmalig übernehmen wollen, verwenden Sie das klassischeBackup der Daten. Dabei genügt es normalerweise, die VarianteBackup All Instances durchzuführen und im Ziel-SLD das aktuelleModell sowie das Backup zu importieren. Auch beim Zusammenfüh-ren der Daten zweier SLDs werden Backups eingespielt. Der SAP-Hinweis 935474 beschreibt die Details.

Exportlinie Inhalt

All Instances (ALL) alle SLD-Daten

Landscape Directory (LD) Technische Systeme, Business-Systeme, Landschaften, Namenspräfixe

Component Repository (CR) Produkte, Softwarekomponenten und deren Beziehungen

Name Reservation (NR) reservierte Namen

Tabelle 7.1 Exportlinien im SLD


178


7.1.2 Inkrementelle Exporte

Sollen zwei SLDs über einen längeren Zeitraum kontrolliert mitein-ander abgeglichen werden, ist ein inkrementeller Export das richtigeVerfahren (Abbildung 7.2). Anders als beim Einspielen eines Back-ups werden dabei alle Arten von Änderungen an den Daten, insbe-sondere auch Löschungen, übertragen. Da ein inkrementeller Exportmit manuellem Aufwand verbunden ist, sollten Sie prüfen, ob nichtauch die weiter unten beschriebenen automatischen Verfahren(Data-Supplier-Weiterleitung bzw. vollständige Synchronisation)angewendet werden können.

Ein großer Vorteil des inkrementellen Exports ist die Möglichkeit,Löschungen und Umbenennungen von Daten im exportierendenSLD identisch im importierenden SLD auszuführen. Beim normalenBackup können im Zielsystem nur Daten hinzugefügt werden. Daskann z.B. zu sogenannten MAX-Verletzungen führen, wennBeschränkungen für die Kardinalität von Assoziationen existieren(siehe Abschnitt 8.2.3, »Assoziationen«).

Die Umbenennung einer Instanz (Änderungen an Schlüsselfeldern)führt beim Einspielen eines Backups zum Neuanlegen einer zweiten,nicht assoziierten Instanz. Ein inkrementeller Export benennt dage-gen die Instanz im Zielsystem um, wobei alle Assoziationen zu dieserInstanz erhalten bleiben.

Abbildung 7.2 Inkrementeller Export im SLD

Hinweis

Das SLD, in das ein Backup importiert wird, muss die gleiche oder einehöhere CIM-Modell-Version wie das gesicherte SLD enthalten.


179


Die für das Nachführen von Änderungen benötigte Änderungshisto-rie wird im Change Log gespeichert und bildet auch die Grundlagefür die weiter unten beschriebene vollständige Synchronisation.Beim Import werden die aufgezeichneten Änderungen dann im Ziel-system ausgeführt. Vor dem ersten inkrementellen Export mussimmer zuerst ein vollständiger Export (Full Export) durchgeführtwerden, damit eine definierte Ausgangsbasis existiert.

FilterungAuch beim inkrementellen Export lassen sich Teilbereiche der SLD-Daten (Exportlinien) exportieren. Dabei wird ein Filter auf dasChange Log angewendet, der nur die für die Exportlinie relevantenÄnderungen an Instanzen und Assoziationen ergibt. Die Berechnungdieses Filters kann je nach Größe des Change Logs relativ aufwendigwerden, daher ist ein inkrementeller Export häufig deutlich langsa-mer als ein normales Backup.

Ein weiterer Nachteil des inkrementellen Exports ist der feste Auf-setzpunkt. Da nur Änderungen seit dem letzten Export aufgezeichnetwerden, muss das Zielsystem genau den richtigen Ausgangszustandhaben, damit die Änderungen angewendet werden können. Inkre-mentelle Exporte müssen streng sequenziell importiert werden; einverlorener Export oder ein zwischengeschalteter anderer Importführen zu Fehlern beim Import. In ein SLD, das per inkrementellemExport der Exportlinie ALL von einem anderen SLD versorgt wird,lassen sich daher keine Backups oder inkrementelle Exporte andererExportlinien (z.B. CR-Content-Updates von SAP) einspielen. Derar-tige Änderungen müssen jeweils im Ausgangs-SLD vorgenommenwerden. Der nächste inkrementelle Export transportiert sie dann insZiel-SLD. Werden nur die Landschaftsdaten (Exportlinie LD) inkre-mentell exportiert, können parallel auch CR-Daten von SAP impor-tiert werden.

KonflikteBei manuellen Änderungen im Ziel-SLD kann es zu Konflikten kom-men, z.B. wenn eine Verknüpfung angelegt werden soll, deren Endeim Ziel-SLD gelöscht wurde. Die Änderung kann dann nicht durch-geführt werden, was zu einer Fehlermeldung im Log führt. Andersals bei der in Abschnitt 7.2.2, »Automatische vollständige Synchroni-sation«, erläuterten vollständigen Synchronisation gibt es für denImport von inkrementellen Exporten prinzipbedingt keine automati-sche Konfliktauflösung.


180


Die Information, welche inkrementellen Exporte aus einem Systemexportiert bzw. in ein SLD importiert wurden, wird im SLD selbstgespeichert, und zwar in Form von Instanzen der Klasse SAP_CIM-Data. Dabei beschreibt die Property SoftwareElementState, ob essich um einen Export (Deployable) oder Import (Executable) han-delt. Wenn ein Import gerade läuft, hat diese Property den WertRunning (siehe Abbildung 7.3).

Abbildung 7.3 Instanzen der Klasse »SAP_CIMData« im CIM Instance Browser

Beim Umzug eines SLD werden diese Daten mit kopiert. Das kann zuProblemen führen, wenn die inkrementellen Exporte im neuen SLDnicht fortgesetzt werden sollen. In diesem Fall sollten Sie die ent-sprechenden Instanzen der Klasse SAP_CIMData im kopierten SLDlöschen.

7.1.3 Softwarekatalog aktualisieren

Ein wichtiger Anwendungsfall des inkrementellen Exports ist dasUpdate des SAP-Softwarekatalogs. Die im SLD enthaltenen Datenüber die ausgelieferte SAP-Software (siehe Abschnitt 1.1, »Schlüssel-funktionen«) werden als inkrementelle Exporte (Deltas) ausgeliefert.Diese Daten werden auch als CR-Content bezeichnet (CR steht für»Component Repository«). Ausschlaggebend für die Wahl des Delta-Verfahrens war neben den bereits genannten Vorteilen die Tatsache,dass Verknüpfungen von Technischen Systemen und Third-Party-Software mit dem Softwarekatalog bei Umbenennungen von Soft-warekomponenten oder Produkten erhalten bleiben.

Aggregierte Deltas Die einzelnen inkrementellen Exporte werden als sogenannte aggre-gierte Deltas zusammengefasst und ausgeliefert. Ein Download ent-hält immer alle bisher erzeugten inkrementellen Exporte seit demletzten vollständigen Export. So enthält z. B. die Datei SAP_CR_


181


Delta_4_1_to_4_12.zip die inkrementellen Exporte 4.1, 4.2 usw. biseinschließlich 4.12. Beim Import werden nur die noch nicht impor-tierten Teile verarbeitet. Um die Kette von inkrementellen Exportenund damit die Ladedauer nicht zu lang werden zu lassen, werdenvon Zeit zu Zeit neue vollständige Exporte (erkennbar an einerneuen führenden Ziffer der Exportversion) gemacht. Für Systeme,die bereits mit inkrementellen Exporten versorgt werden, gibt eseinen speziellen inkrementellen Export, der auf die Version des vol-len Exports aktualisiert. Neu aufgesetzte Systeme können direkt mitdem vollständigen Export starten. Der Wechsel zu einem neuen voll-ständigen Export erfolgt normalweise beim Fertigstellen eines neuenReleases oder Enhancement Packages. Wenn der CR-Content ineinem SLD längere Zeit nicht aktualisiert wurde, sind unter Umstän-den mehrere Importe notwendig, um auf den aktuellen Stand zukommen. Zwischenzeitlich kann sich auch das verwendete CIM-Modell geändert haben. Dann muss zusätzlich vor dem Einspielendes aggregierten Deltas ein Modell-Update durchgeführt werden.

7.1.4 Spezialexporte

Neben Backups und inkrementellen Exporten kennt das SLD nochsogenannte Spezialexporte (Special Exports). Ähnlich wie bei einemBackup werden hier Gruppen von CIM-Instanzen, die zu bestimmtenAnwendungsszenarien gehören, zusammen exportiert. Im Unter-schied zum Backup werden die Daten jedoch nicht nur nach CIM-Klasse oder SLD-Teilbereich ausgewählt, sondern beziehen sich aufganz bestimmte Systeme bzw. Systemgruppen. So lassen sich etwaeinzelne Technische Systeme, Business-Systeme, Produkte und Soft-warekomponenten oder auch Gruppen dieser Daten exportieren.Dabei gibt es häufig Abhängigkeiten (Verknüpfungen) zu anderen,nicht in diesem Spezialexport enthaltenen Daten. Beim Import einessolchen Spezialexports kann es daher zu Fehlermeldungen kommen,wenn die verknüpften Daten im Ziel-SLD (noch) nicht vorhanden

Hinweis

Um den Aufwand für die CR-Content-Aktualisierung gering zu halten,empfiehlt SAP das regelmäßige Einspielen der Updates, auch wenn dieneuen Inhalte des Softwarekatalogs zunächst nicht benötigt werden. Ein-zelheiten zur regelmäßigen Aktualisierung des Softwarekatalogs findenSie im SAP-Hinweis 669669.


182


sind. Tabelle 7.2 listet mögliche Abhängigkeiten der Spezialexporteuntereinander auf.

Um Importfehler zu vermeiden, sollte beim Import in der Reihen-folge der Abhängigkeiten vorgegangen werden: Importieren Sie alsErstes die verwendeten (Nicht-SAP-)Produkte bzw. Komponenten,dann die Technischen Systeme (sofern sie nicht automatisch gemel-det wurden) und schließlich die Business-Systeme. Wurde einemTechnischen System im Quell-SLD manuell ein Produkt zugeordnet,sollte das Produkt auch manuell ins Ziel-SLD importiert werden, dadiese Verknüpfung sonst nicht angelegt werden kann.

CTS-Anschluss Seit SP 12 von NetWeaver 7.0 lässt sich das SLD an ein Change andTransport System (CTS) anschließen. Damit lassen sich zusammenge-hörende Spezialexporte an einen gemeinsamen Transportauftrag hän-gen. Achten Sie auch hier auf die richtige Reihenfolge. Abschnitt 3.2,»Erweitertes Change and Transport System«, beschreibt die Einzelhei-ten der Konfiguration und Verwendung von CTS im SLD-Umfeld.

7.1.5 Probleme beim Import

Kompatibilitäts-prüfungen

Vor dem Einspielen eines Imports führt das SLD verschiedene Prü-fungen auf Kompatibilität durch, insbesondere wird die minimalbenötigte Modellversion oder die Version des eingespielten SAP-Softwarekatalogs geprüft. Werden Unstimmigkeiten festgestellt,wird eine Warnung angezeigt und in bestimmten Situationen derImport ganz verweigert.

Spezialexporte Mögliche Abhängigkeiten

Technische Systeme Produkte, Softwarekomponenten

Business-Systeme Technische Systeme, Produkte, Softwarekompo-nenten

Produkte andere Produkte, Softwarekomponenten

Softwarekomponenten andere Softwarekomponenten

Tabelle 7.2 Mögliche Abhängigkeiten zwischen Spezialexporten

Hinweis

Lesen Sie die Warnung auf jeden Fall sorgfältig durch, und setzen Sie denImport nur fort, wenn Sie sicher sind, dass die zu importierenden Datenzum Ziel-SLD passen.


183


Bei der Verwendung eines CTS wird der Import nur durchgeführt,wenn er kompatibel zu den aktuellen SLD-Daten ist. Sollten sichbestimmte Daten nicht per CTS importieren lassen, prüfen Sie miteinem manuellen Import, ob Kompatibilitätsprobleme die Ursachesind. Auch wenn die Kompatibilitätsprüfungen erfolgreich waren,kann es aufgrund der beschriebenen Abhängigkeiten zwischen denDaten beim Import zu Fehlern kommen, wenn etwa referenzierteDaten nicht (mehr) vorhanden sind oder zwischen dem Einspielenvon Deltas manuelle Änderungen oder andere Importe vorgenom-men wurden. Diese Fehler lassen sich nach erfolgtem Import nursehr mühsam manuell korrigieren. SAP empfiehlt bei produktivenSystemen daher vor dem eigentlichen Import grundsätzlich einenTestimport in eine Kopie des aktuellen Namensraumes (siehe Abbil-dung 7.4).

Abbildung 7.4 Verwaltung von Namensräumen

Testnamensraum anlegen

Legen Sie über Administration � Namespaces � Add einen neuenNamensraum an, etwa sld/importtest, und importieren Sie in diesenzunächst das Modell und ein aktuelles Backup der Produktivdaten.Alternativ können Sie die Daten auch mit einer vollständigen Syn-chronisation in den Zielnamensraum übertragen. Anders als beieinem Backup ist der Namensraum während der Synchronisationnicht gegen Änderungen gesperrt. Anschließend importieren Sie dieneu einzuspielenden Daten testweise in diesen Namensraum; achtenSie dabei auf eventuelle Fehlermeldungen.

Hinweis

Beim Arbeiten mit mehreren Namensräumen kann es leicht zu Verwechs-lungen kommen. Der aktuell vom Benutzer verwendete Namensraumwird auf jeder Seite ganz rechts oben angezeigt.


184


Nicht mehr benötigte Testnamensräume lassen sich über Administ-

ration � Namespaces � Remove wieder löschen. Der Namensraumsld/active ist der Standardnamensraum im SLD. Bei einer Löschungwird er automatisch wieder (leer) angelegt.

CR-Content-Reparatur

Ein häufiger auftretendes Problem entsteht beim irrtümlichen Ein-spielen von Deltas eines anderen Systems, die auch Softwarekatalog-Daten enthalten (z.B. Exportlinie ALL oder CR). Nach einem solchenImport lassen sich – wie oben beschrieben – keine SAP-CR-Deltasmehr importieren, damit es nicht zu Inkonsistenzen kommt. DasSLD enthält ein spezielles Reparaturprogramm, das den CR-Contentkorrigiert, sodass danach weitere Softwarekatalog-Updates einge-spielt werden können. Der SAP-Hinweis 1093168 beschreibt dieVoraussetzungen und das Verfahren.

7.2 Automatischer Datentransport

Um den manuellen Aufwand des Datenabgleichs möglichst gering zuhalten, bietet das SLD zwei verschiedene Mechanismen für den auto-matischen Datentransport an: die Data-Supplier-Weiterleitung unddie automatische vollständige Synchronisation. Beide Verfahrenhaben in bestimmten Situationen ihre Berechtigung. Auf dieseAnwendungsfälle sowie die technischen Hintergründe gehen wir imFolgenden ein.

7.2.1 Data-Supplier-Weiterleitung

Die Weiterleitung von Data-Supplier-Daten erfolgt mit einem einfa-chen Verfahren: Die Data Supplier verschicken Daten in einem SAP-eigenen XML-Format per HTTP bzw. RFC (siehe Abbildung 7.5). DasSLD verarbeitet diese Daten und aktualisiert die Systeminformatio-nen in allen unter Administration � Data Suppliers konfiguriertenlokalen Namensräumen.

Um den Durchsatz der Data Supplier Bridge zu erhöhen, werden dieeingehenden Daten zunächst mit einem Fingerprint (einem Hashüber die Daten) der zuletzt empfangenen Daten für das geradegemeldete System verglichen. Dieser Fingerprint wird pro aktuali-siertem System (genauer für das jeweilige Key-Element, sieheAbschnitt 9.2, »Datenformat zur Registrierung von Third-Party-Sys-


271

Index

A

A2A 117ABAP-API 256ACC 47, 131, 141Adaptive Computing 35, 113, 128Adaptive Computing Controller 47,

131, 141Adaptiver RFC � aRFCAdvanced Adapter Engine 115Aggregiertes Delta 180ALE-Name 261API 28, 241, 256, 263Application Lifecycle 34Application Lifecycle Management

128Application Programming Interface �

APIApplication to Application 117aRFC 49, 124, 126, 218Assoziation 162, 192, 209, 210, 212,

251, 261

B

B2B 117Backup 176, 177Batch Request 245Benutzer 167Breadcrumb 207Bridge Forwarding 56, 72, 76, 82, 85,

144Business to Business 117Business-System 21, 33, 68, 115, 116,

117, 118, 142

C

Cache 124, 127, 169CBS 65Central Processing Unit 45Change and Transport System � CTS

erweitertes � CTS+

Change Log 29, 155, 156, 157, 161, 179, 187, 189, 190

Change Management 65, 130Change Management Server 222Change Request Management 95CIM 23, 27, 32, 73, 78, 79, 198, 225

Basisklasse 210CIM Class Browser 161, 205, 206,

218, 235CIM Client 29CIM Instance Browser 159, 160,

162, 163, 164, 208CIM Object Manager 28, 187CIM Persistence 29Collection 236Datentyp 203Domain 223Indication 204Klasse 203Methode 204

Client-Anwendung 113, 116, 137, 168

Client-API 241Cluster 154CMS 222Common Information Model � CIMCommon Model 199Component Build Service 65Component Repository 78, 180Compound Key 202, 215, 234, 252Configuration Wizard 128Content Maintenance � CIM Instance

BrowserContent Sync � Vollständige Synchro-

nisationContinuous Availability 91Core Dump 230Core Model 199CPU 45CR 78, 180CR-Content 49, 180, 181, 184, 222CTS 95, 182CTS+ 65, 72, 81, 95, 96, 107, 108,

111, 143, 144, 183


272

Index

D

Data Supplier 29, 72, 81, 82, 138, 184Bridge 29, 55, 56, 72, 76, 82, 184,

227Trace 186Weiterleitung 175, 184, 193

Dateilog.properties 155slddest.cfg 229

DatenAbgleich 72Austausch 71Backup 77Export 73, 76, 81, 95, 142, 143,

176Import 74, 80, 109, 142, 176Konsistenz 151

DCOM 242Delta, aggregiertes 180Deploy Web Service 97Design-Time Repository 65Destinations Service 29Development Configuration 36, 133,

222Development-Komponente 134Dispatcher-Port 58Distributed Component Object Model

242Distributed Management Task Force

(DMTF) 27, 198, 202, 205, 241DTR 65Dual-Stack-System 41

E

Ein-Weg-Prinzip 193End-to-End Root Cause Analysis 128Entwicklungsumgebung 133Erweitertes Change and Transport Sys-

tem � CTS+Export, inkrementeller 176, 178, 179,

180Exportlinie 177, 179, 187

F

Fast Import 177Fehler OutOfMemory 156, 170Fingerprint 184, 188, 236Firewall 31, 137, 145Flag 231Full Automatic Synchronisation �

Vollständige SynchronisationFull Export 179Full Sync 87, 188, 189

G

Gateway-Port 56

H

Hauptinstanz 51High Availability 89, 137, 140Host-Name 91, 215, 228Hot-Backup 91, 137, 144HTTP-Destination

SLD_Client 220SLD_DataSupplier 61

HTTP-Header 243HTTPS 145, 169, 258

I

IGS 45Incremental Sync 189Inkrementeller Export 176, 178, 179,

180Instanz

Associator 247Name 161, 200, 242, 245Reference 247Schlüsselfeld 201

Instanziierbarkeit 200Integration Broker 115, 116Integration Builder 122Integration Directory 115, 117Integration Server 46, 115, 116, 118,

121Internet Graphics Service 45


273

Index

Internet Transaction Server 45IP-Adresse, virtuelle 90ITS 45

J

Java Enterprise Edition 166Java Support Package Manager 224Java Virtual Machine 170JavaServer Pages 32JCo Destination 125, 126JEE 166JSP 32JSPM 224JVM 170

K

Kardinalität 211Key-Element 184, 236Klasse

abstrakte 200Instanziierbarkeit 200konkrete 200SAP_AdministrationSystemLandscape

220SAP_AllowedNamespacePrefix 222SAP_ApplicationSystem 214, 219,

233, 234SAP_ApplicationSystemHost 234SAP_AppServerJCoDestination 218SAP_BCClient 215SAP_BCControlInstance 218SAP_BCSystem 59, 214, 261SAP_BCWebDispatcher 218SAP_BusinessSystem 220SAP_ChangeManagementServer 222SAP_CIMData 180SAP_CoherentSoftwareUnit 221SAP_ComputerSystem 59, 206, 219,

228, 233, 234, 242, 248, 261SAP_DatabaseInstance 217SAP_DatabaseSystem 59, 217SAP_DesignTimeConfiguration 222SAP_HTTPServicePort 216SAP_InstalledProduct 156, 212, 217,

221

SAP_InstalledSoftwareComponent 217, 221, 233, 237

SAP_IPServicePort 218SAP_J2EEEngineCluster 217, 251SAP_J2EEEngineClusterNode 217SAP_J2EEEngineInstance 217SAP_LogicalALESystem 215SAP_MsgServJCoDestination 218SAP_Product 212, 220SAP_ProductLine 220SAP_ReservedName 222SAP_SoftwareComponent 221, 238,

252SAP_SoftwareComponentLine 221SAP_SoftwareFeature 221SAP_SuppliedElements 222SAP_Supplier 222, 228SAP_SupportPackage 221SAP_SystemLandscape 220SAP_SystemLandscapeDirectory 220SAP_TREXServer 220SAP_TREXSystem 219SAP_XIAdapterEngine 220SAP_XIIntegrationServer 220

Kompatibilität 152, 182, 214Konflikt 179, 187, 190Kopplung an CTS+ 95, 96, 107

L

Landscape Directory 29Landscape Repository 78Landschaft 21, 66, 129Latenzzeit 95Lifecycle Management 225Load-balanced 126Log 111, 152Log Severity 153Logisches System 68, 119, 204

M

Maintenance Optimizer 128Maintenance Transaction 130Mapping 33, 115, 116, 124, 167Master Component Repository 39, 75MAX-Verletzung 163, 178, 211


274

Index

MD5-Hash 237Mehrfachvererbung 200Meldung, automatische 68Member-Klasse 231Message-Server 126Metamodell 197Methode 246Microsoft 242Middleware 33, 113Modell-Update 181, 187Monitoring 131Multiple Inheritance 200

N

Name Reservation 21, 78, 134Namenspräfix 36, 134Namensraum 30, 75, 164, 183, 223,

245bearbeiten 76Test 183

Namensreservierung 21, 78, 134Nameserver 222Notification 92NWA 146, 148, 152, 207, 223NWDI 21, 35, 69, 78, 95, 131, 132,

133, 135, 143, 222NWDS 133, 222, 224

O

Object Manager 177, 198, 211, 214, 223

Object Server 30, 88, 91, 148, 185, 193, 245

OpenWBEM 241Outdated Data 158OutOfMemory-Fehler 156, 170

P

Page Fault 230Pegasus 263Persistenz 197Polling 190Portal 95Poster 214, 261

PPMS 53, 221Instanz 132, 221

Produktzuordnung 120Programm

saposcol 45, 219, 227sldreg 29, 32, 173, 219, 226

Property 203, 213Pull-Mechanismus 30, 31Push-Mechanismus 30, 31Python 241, 263

Q

Qualifier 202Description 205Max 211SAP_SchemaSubset 177, 203Weak 203, 212, 216

Quell-SLD 73, 76, 98

R

Rang 94, 190Read-only-Modus 89Redo-Log 176Release-Kompatibilität 78Remote Function Call (RFC) 32, 255RFC, adaptiver � aRFCRFC-Destination SAPSLDAPI 256, 258Rolle 165, 166

DataSupplierLD 167, 230InstanceWriterLD 126LcrAdministrator 74LcrInstanceWriterLD 167Rollenname 210SAP_SLD_CONTENT_SYNC 88

Root-Cause-Analysis 130Root-Instanz 231Root-Klasse 231Root-Member-Gruppe 231

S

SAP Java Connector (SAP JCo) 48SAP Management Console (SAP MMC)

170


275

Index

SAP NetWeaver Administrator � NWA

SAP NetWeaver Developer Studio � NWDS

SAP NetWeaver Development Infra-structure � NWDI

SAP NetWeaver Process Integration 33, 114, 117, 123, 141

SAP Product and Production Manage-ment System � PPMS

SAP Solution Manager 20, 34, 47, 113, 129, 130, 140, 141, 225

SAP Solution Manager Maintenance Optimizer 128, 129

SAPSLDAPI 256, 258SBLIM 241, 242, 248, 249Schleife 193Schlüsselfeld 200

CreationClassName 161, 201, 215SoftwareElementID 237

Schmierzeichen 162Schwach verknüpft � Qualifier

weakSecure Network Communication �

SNCSecure Sockets Layer 169, 258Service sapstartsrv 45Service-Oriented Architecture 21Session 245Shared Library 230SID 82, 128Singleton 200SLD Bridge � Data Supplier BridgeSLD Data Supplier 29, 72, 81, 82,

138, 184SLD Planning Guide 139SNC 145, 169, 258SOA 21SOAP 241Software

Entwicklung 35Feature 132, 221Katalog 18, 25, 29, 35, 39, 50, 121,

132, 151, 180, 238Komponente 69, 221Komponentenversion 132manuell anlegen 68Unit 51, 132

Software Distribution Center 53Software Lifecycle Manager 65

Sperren eines Benutzers 167Spezialexport 181, 182SQL-Statement 198SSL 169, 258Standards Based Linux Instrumenta-

tion for Manageability � SBLIMSupport Package 251

Stack 51, 221Support-Download 172Synchronisation 71, 92, 138, 144

bidirektionale 87vollständige 72, 76, 86, 87, 89, 92,

142, 152, 187, 190System

Logisches 68, 119, 204Technisches 20, 33, 68, 217

System-ID 82, 128Systemlandschaft 137System-System-Kommunikation 33,

68, 115, 124Systemtyp auswählen 67

T

Task List 148TCO 190Technisches System 20, 33, 68, 217Third-Party-System 233, 234, 240Time-out 250TMS 100, 105Topologie 112, 192Total Cost of Ownership 190Trace 152, 245Track 133Transaktion

RZ70 29SLDAPICUST 258SM59 256STMS 100

TransportAuftrag 95, 104, 108Route 66, 100, 106, 109

Transport Management System 100, 105

Transport Organizer Web UI 99


276

Index

U

UME 93, 166Unit 69Upgrade 141User Interface 24, 32User Management Engine 93, 166

V

Virtual Private Network 145Vollständige Synchronisation 72, 76,

86, 87, 89, 92, 142, 152Notification 187, 190Polling 190

VPN 145

W

WAN 171

WBEM 27, 29, 241, 245, 246Methode 246Request 29

Weak 218Web Dynpro

Content Administrator 125Java 33, 34, 124, 127

Web-Based Enterprise Management � WBEM

Web-Dispatcher 218Webservice 66Wide Area Network 171Windows-Managed Interfaces (WMI)

242Work Center 127

Z

Ziel-SLD 73, 74, 79


Date post:	17-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Grundlagen und Praxis - Amazon S3€¦ · Bonn Boston Wolf Hengevoss, Dr. Andreas Linke SAP...

Documents