<div class="hzweiwrapper"><span class="circled-number">1</span><h2 class="c-blog_head" id="1. Warum macht eine mehrstufige Systemlandschaft Sinn?">Warum macht eine mehrstufige Systemlandschaft Sinn?</h2></div>
- Trennung von Entwicklungs-/Test- und Produktionsumgebung: Durch die Verwendung mehrerer Systeme können Produktionsdaten von Entwicklungs- und Testdaten getrennt werden. Neue Entwicklungen beeinflussen nicht laufende Tests oder gar den Produktivbetrieb. Genehmigungs- und Freigabeszenarien können beim Go-Live berücksichtigt werden.
- Skalierbarkeit & Leistung: Bei der Verarbeitung von großen Datenmengen und Durchführung komplexer Analysen kann die Leistung verbessert werden. Entwicklungs- und Testsysteme können ressourcenschonender skaliert werden.
- Sicherheit: Eine mehrstufige Systemlandschaft kann zur Verbesserung der Sicherheit beitragen, indem der Zugriff auf sensible Daten nur für autorisierte Benutzer gewährleistet wird.
<div class="hzweiwrapper"><span class="circled-number">2</span><h2 class="c-blog_head" id="2. Was für Optionen einer mehrstufigen Systemlandschaft bestehen in SAP Datasphere?">Was für Optionen einer mehrstufigen Systemlandschaft bestehen in SAP Datasphere?</h2></div>
In der SAP Datasphere hat man zwei Möglichkeiten eine mehrstufige Systemlandschaft aufzubauen:
- Option 1: Verwendung der Entwicklungs-/Test-und Produktionsumgebung auf unterschiedlichen Tenants der SAP.
- Option 2: Verwendung der Entwicklungs-/Test-und Produktionsumgebung auf einem Tenant in Form von unterschiedlichen Spaces. Ein Space ist ein sicherer Bereich, in dem die Datenbereitstellung sowie -modellierung stattfindet. Auf den Inhalt eines Spaces kann nicht von außerhalb zugegriffen werden, es sei denn dieser wird mit einem anderen Space geteilt.
Bei Option 1 hat man mehrere Datasphere Tenants vorliegen, beispielsweise einen Tenant für die Entwicklungs- und einen weiteren Tenant für die Produktivumgebung. Dabei kann zwischen den unterschiedlichen Tenants über die Transport-App (ACN =Analytics Content Network) exportiert sowie importiert werden.
Dafür ist die Rolle Administrator oder Space-Administrator notwendig. Über die Transport-App können alle gewünschten Objekte transportiert werden, u.a.:
- Lokale Tabellen
- Remote-Tabellen
- Views
- Datenflüsse
- Intelligente Suchen
- Analysemodelle
- ER-Modelle
- Aufgabenketten
- Geschäftsentitäten / Geschäftsentitätsversionen
- Faktenmodelle
- Verwendungsmodelle
- Berechtigungsszenarios
Hier ist zu beachten, dass bei Objekten, wie z.B. Remote-Tabellen, die entsprechende Verbindung mit identisch technischem Namen im Ziel-Space vorhanden sein muss. Zudem werden bei Auswahl eines Objektes alle davon abhängigen Objekte ebenfalls automatisch für den Transport vorgesehen.
Bei Option 2 liegt eine mehrstufige Systemlandschaft auf nur einem Datasphere Tenant vor. Dabei werden beispielsweise für die Entwicklung, Test- und Produktionsumgebung verschiedene Spaces angelegt.
Der Transport zwischen den Spaces kann nicht über die Transport-App erfolgen. Dazu muss das entsprechende Objekt im Quell-Space geöffnet und dann in eine JSON-File exportiert werden. Auch hier gilt, alle abhängigen Objekte werden automatisch mit exportiert. Diese JSON-File kann dann in dem Ziel-Space importiert werden.
<div class="hzweiwrapper"><span class="circled-number">3</span><h2 class="c-blog_head" id="3. Welche Option ist zu wählen?">Welche Option ist zu wählen?</h2></div>
Eine generelle Empfehlung zu geben ist schwierig. Dies hängt vielmehr von den Umständen und Projektanforderungen eines Unternehmens ab. Beide Optionen einer mehrstufigen Systemlandschaft haben ihre Vor- und Nachteile.
<div class="hzweiwrapper"><span class="circled-number">4</span><h2 class="c-blog_head" id="4. Auswirkungen auf die Anbindung einer SAC">Auswirkungen auf die Anbindung einer SAC</h2></div>
Viele Unternehmen binden die SAP Analytics Cloud (SAC) als Frontend an die SAP Datasphere an. In der SAC kann eine Verbindung zu einem Datasphere Tenant angelegt werden. Wenn in der SAC ein Modell erstellt wird, kann der jeweilige Datasphere Tenant als Datenquelle und anschließend der entsprechende Space vom Datasphere Tenant und das darin gewünschte Objekt ausgewählt werden. Es ist daher unproblematisch, wenn in verschiedenen Spaces Objekte mit gleichem technischen Namen vorhanden sind. Vom Aufwand her macht es also keinen großartigen Unterschied ob Option 1 oder 2 gewählt wird.
