Transport
Tansportmanagement und Transportkonzept der CLARC Infinity Plattform
Das Transportmanagement in der CLARC Infinity Plattform bildet das zentrale Rückgrat zur systematischen, nachvollziehbaren und konsistenten Übertragung von Konfigurationsdaten und Customizing-Objekten zwischen den verschiedenen Systemstufen eines Mandanten. Es dient der Sicherstellung, dass alle Änderungen kontrolliert und dokumentiert erfolgen – unabhängig davon, ob sie technischer, fachlicher oder organisatorischer Natur sind.
1. Systemlandschaft (Mandantenstruktur)
Jeder Mandant verfügt standardmäßig über eine dedizierte Systemlandschaft bestehend aus folgenden Umgebungen:
System | Zweck |
|---|---|
Development | Entwicklung, Konfiguration, Customizing |
Test | QS, Abnahme und Integrationstests |
Productive | Produktiver Betrieb |
Sandbox | Freie Umgebung für Tests und Experimente |
Training | Schulungssystem mit Echtnähe |
1.1 Datenarchitektur und Speichertrennung
Ergänzend zur funktionalen Trennung der Mandantenlandschaft in Development, Test, Productive, Sandbox und Training erfolgt auch eine technische Trennung der zugrunde liegenden Datenhaltung. Jeder Mandant verfügt über eine eigenständige, logisch isolierte Datenbankinstanz, um maximale Datensicherheit, Mandantentrennung und Skalierbarkeit zu gewährleisten.
Strukturierung der Datenebene
Die Plattform unterscheidet dabei zwischen zwei zentralen Speicherbereichen:
Bereich | Beschreibung |
|---|---|
Datenbank | Hier werden alle konfigurierbaren Systemdaten abgelegt, z. B. Businessobjekte, Benutzer, Workflows, Customizing-Elemente, Logs, Transaktionen und Statusinformationen. Die Daten liegen relational in einer mandantenspezifischen Datenbankstruktur vor. |
BLOB-Speicher | Binärdaten wie Dokumente, Bilder, OCR-Ergebnisse oder Konvertierungsausgaben werden in einem separaten, performanten Objektspeicher (Blob Storage) verwaltet. Dieser ist ebenfalls mandantenspezifisch segmentiert. |
Diese Trennung erlaubt eine optimierte Verarbeitung und Skalierung, da strukturierte Daten und Massendaten (z. B. Scans, PDF-Dateien) unabhängig voneinander gespeichert und ausgelagert werden können – z. B. in cloudbasierte Speicher, Netzlaufwerke oder hochperformante Datencontainer.
Vorteile dieser Architektur
✅ Mandantentrennung auf Datenebene: Keine Vermischung von Systemzuständen, Konfigurationen oder Dokumenten
✅ Skalierbarkeit und Performance: Datenbanklast und Dateispeicherung werden getrennt skaliert
✅ Sicherheits- und Backup-Konzept: sind granular auf diesen Ebenen angewendet
2. Transportkonzept – Ablauf und Prinzipien
2.1 Standardprozess: Transportkette
Der typische Ablauf bei der Überführung neuer Prozesse oder Anpassungen verläuft in folgender Reihenfolge:
Development → Test → Productive
Development: Einrichtung und Entwicklung neuer Prozesse
Test: Prüfung, Qualitätssicherung, Integrationstests
Productive: Freigabe und Inbetriebnahme für Endanwender
2.2 Transportwege
Die Transportziele und -quellen sind je System frei definierbar. So kann z. B. das Testsystem übersprungen werden, falls gewünscht (nicht empfohlen):
Beispiel:
Development → Productive(bei dringenden Hotfixes)Auch Importe von externen Quellsystemen sind möglich (z. B. Partner-Mandant oder Vorlage-Mandant)
3. Transportarten
3.1 Systeminterner Transport
Direkt über die Transportfunktion zwischen den konfigurierten Zielsystemen
Unterstützt Standardobjekte, Benutzerdefinierte Objekte, sowie Benutzer- und Gruppeninformationen
3.2 Export/Import über Datei
Transporte können als Datei exportiert werden
Import in andere Mandanten möglich (z. B. Migration, Mandantenkopien)
Pro Transport ist konfigurierbar, in welche Zielsysteme ein Import erlaubt ist (White-List)
4. Objektarten im Transport
Objekttyp | Transportfähig | Besonderheiten |
|---|---|---|
Customizing-Objekte | ✅ | inkl. Transaktionen und Historie |
Benutzer / Gruppen | ✅ | Technisch möglich, aber empfohlen ist die lokale Verwaltung |
Systempfade unter | 🟡 | Nur "Customizing-Hülle" (Node), keine Konfigurationen wie z. B. ERP-Verbindungen |
ERP- oder Drittsystem-Verbindungen unterscheiden sich je System (z. B. abweichende URLs, Credentials) und müssen lokal im Zielsystem gepflegt werden.
5. Change Lock & Change History
5.1 Change Lock
Pro System konfigurierbar
Verhindert Änderungen an Customizing-Objekten außerhalb von Transportvorgängen
Standardmäßig im Produktivsystem aktiv
Sicherstellung konsistenter Zustände über alle Umgebungen
5.2 Change History
Aktivierbar je System
Alle Änderungen an Customizing-Objekten werden in Transaktionen aufgezeichnet
Ermöglicht:
Rollback auf frühere Stände
Vergleich von Versionen
Einsicht über:
Zugehörige Transporte
Kontextmenü des jeweiligen Customizing-Objekts
6. Steuerung und Nachvollziehbarkeit
Jeder Transport wird systemseitig protokolliert
Informationen enthalten:
Zeitpunkt
Quelle & Zielsystem
Inhalt / Objekttypen
Benutzer
Rückverfolgbarkeit über Change Logs und Transaktionsverweise
7. Simulation von Transporten (Pre-Check)
Vor dem tatsächlichen Transportvorgang bietet die CLARC Infinity Plattform eine Simulationsfunktion, mit der der gesamte Transport trocken durchgespielt werden kann, ohne dass Änderungen am Zielsystem vorgenommen werden.
Zweck der Simulation
Validierung der Transportinhalte
Prüfung auf Konflikte, Inkonsistenzen oder Versionsprobleme
Ermittlung der betroffenen Objekte, Abhängigkeiten und Systemreaktionen
Vorschau der entstehenden Logmeldungen und Systemaktionen
Ergebnis der Simulation
Die Simulation erzeugt ein detailliertes Logprotokoll, das unter anderem folgende Informationen enthält:
Typ | Beschreibung |
|---|---|
Objekttypen | Welche Objekte im Zielsystem betroffen wären |
Versionskonflikte | Hinweis bei Downgrade oder abweichenden Zeitstempeln |
Abhängigkeitsfehler | Falls verknüpfte Objekte fehlen |
Gültigkeit | Prüfung, ob Zielsystem für Import freigegeben ist |
Sperrstatus | Prüfung auf aktiven Change Lock |
Customizing-Konflikte | Differenzen bei systemabhängigen Einstellungen |
8. Transportoptionen
Bei der Anlage eines Transports kann die Option Include Metadata gesetzt werden. Dies führt dazu, dass Objekt-Informationen wie Beschreibung und Icons mit transportiert werden.
Beim tatsächlichen Transport können drei erweiterte Optionen gesetzt werden, um abweichende Anforderungen oder Sonderfälle abzudecken:
Option | Beschreibung |
|---|---|
Allow Downgrade | Erlaubt das Einspielen von älteren Objektversionen als jene, die im Zielsystem bereits vorhanden sind. Standardmäßig verhindert das System Downgrades zum Schutz vor Datenverlust. |
Overwrite | Überschreibt vorhandene Objekte im Zielsystem auch dann, wenn keine Versionierungskonflikte vorliegen. Sinnvoll bei bewusst redundanten Deployments. |
Force | Erzwingt den Transport unabhängig von Change Locks, Systemfreigaben oder Gültigkeitsprüfungen. Diese Option sollte ausschließlich für Notfälle verwendet werden und ist standardmäßig deaktiviert. |
Wichtig: Der Einsatz von Allow Downgrade und Force sollte sorgfältig geprüft und nur nach Rücksprache mit dem verantwortlichen Systembetreuer erfolgen.
9. Best Practices
Thema | Empfehlung |
|---|---|
Benutzer- und Gruppenverwaltung | Lokal im Zielsystem pflegen |
ERP-Verbindungen (z. B. RFC-Settings) | Im Zielsystem neu konfigurieren |
Produktivsystem | Immer mit aktiviertem Change Lock arbeiten |
Rücksicherung | Change History aktivieren, regelmäßige Snapshots exportieren |
Tests vor Produktivsetzung | Transporte zuerst in Testsystem prüfen (CI/CD Prinzip) |
10. Fazit
Das Transportmanagement der CLARC Infinity Plattform stellt eine strukturierte, nachvollziehbare und sichere Methode zur Übertragung von Customizing und Konfiguration dar. Es unterstützt agile Entwicklungsprozesse ebenso wie hochregulierte Betriebsumgebungen. Durch Features wie Change Lock, Historisierung und systemübergreifende Transportwege wird ein kontrollierter und dokumentierter Lebenszyklus von Prozessen und Konfigurationen sichergestellt – über alle Systemebenen hinweg.
- 1 Tansportmanagement und Transportkonzept der CLARC Infinity Plattform
- 1.1 1. Systemlandschaft (Mandantenstruktur)
- 1.2 2. Transportkonzept – Ablauf und Prinzipien
- 1.3 3. Transportarten
- 1.4 4. Objektarten im Transport
- 1.5 5. Change Lock & Change History
- 1.5.1 5.1 Change Lock
- 1.5.2 5.2 Change History
- 1.6 6. Steuerung und Nachvollziehbarkeit
- 1.7 7. Simulation von Transporten (Pre-Check)
- 1.7.1 Zweck der Simulation
- 1.7.2 Ergebnis der Simulation
- 1.8 8. Transportoptionen
- 1.9 9. Best Practices
- 1.10 10. Fazit