Kurzantwort
ArchiveLink und CMIS sind keine austauschbaren Etiketten für dieselbe Aufgabe. ArchiveLink ist eine SAP-Schnittstelle, mit der SAP-Systeme an Content Repositories angebunden werden; die Repository-ID, Verknüpfungen und Berechtigungen sind dabei eigenständige Konfigurations- und Testgegenstände.1 CMIS ist ein herstellerneutraler Standard für Web-Services- und Web-2.0-Schnittstellen, um Inhalte zwischen unterschiedlichen Content-Management-Repositories auszutauschen.2
Die richtige Entscheidung beginnt deshalb nicht mit der Frage „Welche Schnittstelle ist moderner?“, sondern mit fünf konkreten Fragen: Welches SAP-Produkt und welcher Release? Welches Geschäftsobjekt? Welcher Abruf- und Ablageprozess? Welches Repository? Welche Test- und Betriebsnachweise werden benötigt?
Bestehende, funktionierende ArchiveLink-Szenarien sind kein Grund für einen unkontrollierten Wechsel. Umgekehrt sollte ein neues Szenario nicht automatisch aus einem früheren Integrationsmuster abgeleitet werden. Entscheidend ist, ob der vorgesehene Integrationsweg für den konkreten Use Case unterstützt, testbar und langfristig betreibbar ist.
Geltungsbereich und Grenze
| Dieser Leitfaden behandelt | Dieser Leitfaden behandelt nicht |
|---|---|
| Die technische Auswahl einer Integrationsrichtung für SAP-nahe Dokument- und Content-Repositories | Eine pauschale Aussage, dass eine Schnittstelle für alle SAP-Editionen oder Objekte geeignet ist |
| Repository, Verknüpfung, Metadaten, Berechtigung und Retrieval als gemeinsame Entscheidungsobjekte | Produkt-, Zertifizierungs-, SLA-, Kosten- oder Compliance-Zusagen einzelner Anbieter |
| Den Übergang von einer bestehenden zu einer weiterentwickelten Architektur | Einen Ersatz für aktuelle SAP-Release-, Business-Object- und Security-Prüfungen |
Was bei ArchiveLink fachlich entschieden wird
SAP beschreibt ArchiveLink als Schnittstelle zwischen SAP-Systemen und Speichersystemen. In der SAP-Konfiguration wird eine Content Repository Identification (ContRepID) einem Archiv zugeordnet. Die Konfiguration entscheidet damit unter anderem, wo Dateien zur Archivierung gelesen und für den Abruf wiedergefunden werden.1
In einem dokumentierten ArchiveLink-Szenario müssen Projektteams mindestens diese Bausteine getrennt betrachten:
| Baustein | Entscheidungs- und Testfrage |
|---|---|
| Content Repository | Ist das Zielrepository für den konkreten Ablage- und Retrievalfall erreichbar und korrekt konfiguriert? |
| Repository-ID | Referenzieren Konfiguration, Tests und Betrieb dieselbe Repository-Identität? |
| SAP-Verknüpfung | Führt der Zugriff vom relevanten SAP-Geschäftsobjekt zum korrekten Dokument? |
| Metadaten | Bleiben Such- und Zuordnungsmerkmale fachlich nutzbar? |
| Berechtigung | Können berechtigte Rollen archivieren und abrufen, während unberechtigte Rollen ausgeschlossen bleiben? |
| Aufbewahrung und Betrieb | Sind die fachlichen Regeln, Protokolle, Fehlerpfade und Verantwortlichkeiten definiert? |
Praxisregel: Ein Test „Dokument wurde gespeichert“ reicht nicht. Der Nachweis muss auch Retrieval, Geschäftsobjekt-Link, Metadaten, Berechtigung und den Fehlerfall abdecken.
Was CMIS standardisiert – und was nicht
CMIS steht für Content Management Interoperability Services. Der OASIS-Standard beschreibt eine herstellerneutrale Schnittstelle für den Austausch von Content zwischen Dokumentensystemen, Publishern und Repositories über Internet-Protokolle.2 Das ist wertvoll, wenn ein Integrationsszenario bewusst auf eine standardisierte Repository-Schnittstelle ausgerichtet wird.
CMIS ersetzt jedoch keine Architekturentscheidung. Auch bei einer CMIS-basierten Anbindung müssen Verantwortliche festlegen und testen:
- welches Repository und welcher Endpoint verwendet werden,
- welche Content- und Objektarten tatsächlich abgebildet werden,
- welche Metadaten verbindlich sind,
- wie Identitäten, Rollen und Berechtigungen durchgesetzt werden,
- wie Fehler, Wiederanlauf, Monitoring und Support funktionieren,
- wie Dokumente aus dem relevanten SAP-Geschäftsprozess wieder auffindbar bleiben.
Die Bezeichnung „CMIS-fähig“ ist daher noch kein Abnahmeergebnis. Relevant ist ein dokumentierter End-to-End-Test für den vorgesehenen SAP-Use-Case.
Entscheidungstabelle: Welcher Integrationsweg passt zum Vorhaben?
| Projektfrage | Eher ArchiveLink-orientierte Prüfung | Eher CMIS-orientierte Prüfung | Nachweis vor der Freigabe |
|---|---|---|---|
| Bestehender Prozess soll unverändert weiterlaufen | Prüfen, ob Repository, Links, Rollen und Abruf im Ist-Szenario stabil dokumentiert sind | Nur ergänzen, wenn ein abgegrenzter neuer Use Case dies erfordert | Reproduzierbarer Retrieval- und Berechtigungstest im Ist-Szenario |
| Neues Dokumenten- oder Repository-Szenario | Prüfen, ob der konkrete SAP-Use-Case dafür vorgesehen und unterstützt ist | Prüfen, ob der konkrete SAP-Use-Case eine CMIS-Anbindung vorsieht und der Repository-Umfang passt | Release-, Geschäftsobjekt- und Schnittstellenfreigabe aus der aktuellen Dokumentation |
| Cloud- oder Transformationsprojekt | Bestehende Links und Repository-Abhängigkeiten vollständig inventarisieren | Endpoint, Identitätsmodell, Metadaten und Betriebsmodell als Zielarchitektur beschreiben | Freigegebenes Zielbild mit Migrations- und Rückfallpfad |
| Mehrere Content-Repositories oder ECM-Systeme | Prüfen, ob die bestehende SAP-Verknüpfung die benötigten Repositorys abdeckt | Prüfen, ob standardisierte Interoperabilität tatsächlich den gewünschten Repository-Austausch ermöglicht | Objekt-, Metadaten- und Berechtigungsmatrix je Repository |
| Übergang aus einem Bestandsarchiv | Linktabellen, Dokument-IDs und Retrieval-Pfade als eigene Migrationsobjekte behandeln | Zielmodell erst nach einem repräsentativen Pilot technisch abnehmen | Mengen-, Integritäts-, Retrieval- und Rechteprotokoll |
Entscheidung nicht nach SAP-Name, sondern nach Use Case treffen
Die Kurzformeln „ECC = ArchiveLink“, „Cloud = CMIS“ oder „S/4HANA = automatischer Schnittstellenwechsel“ sind für eine belastbare Planung zu grob. Innerhalb einer Systemlandschaft können sich Geschäftsobjekte, eingesetzte Komponenten, Release-Stände, Erweiterungen und Dokumenttypen unterscheiden.
Ein belastbarer Architekturentscheid beantwortet deshalb pro Szenario diese Fragen:
- Geschäftsobjekt: Welcher Beleg, Auftrag, Vertrag, Anhang oder Fachprozess erzeugt beziehungsweise benötigt das Dokument?
- SAP-Produkt und Release: Welche aktuelle Produktdokumentation ist für dieses Objekt und die geplante Edition maßgeblich?
- Ablage und Abruf: Wo wird gespeichert, wie wird gesucht und aus welchem Prozess wird wieder abgerufen?
- Metadaten und Verknüpfung: Welche Werte müssen für Suche, Audit, Folgeprozess und Migration erhalten bleiben?
- Identität und Berechtigung: Welche Rollen dürfen ablegen, anzeigen, exportieren und administrieren?
- Betrieb: Wie werden Fehler erkannt, bearbeitet, protokolliert und wiederholt?
Erst wenn diese Fragen beantwortet sind, ist eine technische Auswahl prüfbar. Für die Planung einer kontrollierten Überführung eines Bestandsarchivs ergänzt die Migrations-Checkliste für SAP-Archive diesen Leitfaden.
Übergangsstrategie: Bestehendes sichern, Neues bewusst entscheiden
Eine Übergangsstrategie muss nicht bedeuten, dass alle Altbestände sofort auf einen neuen Integrationsweg umgestellt werden. Sinnvoller ist häufig eine Trennung von drei Arbeitsströmen:
| Arbeitsstrom | Ziel | Typische Ergebnisse |
|---|---|---|
| Bestand sichern | Bestehende Prozesse, Repositorys und Verknüpfungen verlässlich betreiben | Inventur, Monitoring, bekannte Sonderfälle, dokumentierte Retrieval-Tests |
| Zielarchitektur definieren | Neue Anforderungen als eigene, freigegebene Szenarien beschreiben | Use-Case-Matrix, Schnittstellenentscheidung, Rollenmodell, Testkatalog |
| Migration steuern | Nur geprüfte Bestände in nachvollziehbaren Wellen überführen | Pilot, Fehlerklassen, Abnahmeprotokoll, Rückfall- und Betriebsübergabe |
Diese Trennung verhindert zwei typische Fehler: Erstens wird ein funktionierender Altprozess ohne ausreichenden Nachweis verändert. Zweitens wird ein neues Cloud-Szenario lediglich aus Gewohnheit nach einem alten Muster gebaut.
End-to-End-Testkatalog vor Go-live
Unabhängig vom Integrationsweg sollte die Abnahme nicht nur technische Erreichbarkeit bestätigen. Die folgende Liste macht Architekturentscheidungen im Projekt überprüfbar:
- Ablage: Ein Dokument wird im vorgesehenen SAP-Prozess korrekt abgelegt.
- Verknüpfung: Das relevante Geschäftsobjekt referenziert genau das erwartete Dokument.
- Retrieval: Berechtigte Rollen können das Dokument wiederfinden, anzeigen und bei Bedarf exportieren.
- Metadaten: Fachlich relevante Such- und Zuordnungswerte sind vollständig und korrekt vorhanden.
- Berechtigung: Positive und negative Rollentests sind dokumentiert.
- Fehlerfall: Timeout, nicht erreichbares Repository, fehlerhafte Metadaten und Wiederanlauf wurden getestet.
- Betrieb: Monitoring, Logging, Ownership, Supportweg und Änderungsprozess sind vereinbart.
- Migration: Bei Bestandsübernahme sind Menge, Inhalt, Metadaten, Links und Rechte gegen den Quellbestand validiert.
Fazit
ArchiveLink und CMIS stehen nicht für „alt“ gegen „neu“, sondern für unterschiedliche Integrationskonzepte. Ein bestehendes ArchiveLink-Szenario wird anhand von Repository, Verknüpfungen, Berechtigungen und Retrieval bewertet. Ein CMIS-Szenario wird anhand des konkret unterstützten Use Cases, der Repository-Schnittstelle, des Identitäts- und Betriebsmodells bewertet.
Die beste nächste Entscheidung ist daher nicht die pauschale Wahl einer Technologie, sondern eine Use-Case-Matrix mit aktuellen SAP-Quellen und einem End-to-End-Testkatalog. So bleiben Altbestand, Transformationsprojekt und Zielarchitektur nachvollziehbar voneinander getrennt.
Quellen und fachliche Grenze
Dieser Beitrag bietet technische Orientierung und keine verbindliche Aussage über die Eignung einer konkreten SAP-Edition, eines Releases, eines Geschäftsobjekts oder eines Produkts. Diese Eignung muss im jeweiligen Projekt anhand der aktuellen SAP-Dokumentation und der vorgesehenen Architektur geprüft werden.
SAP Help: Configuring ArchiveLink (Version 2025 FPS01, abgerufen am 30. September 2026). ↩↩
OASIS: Content Management Interoperability Services sowie OASIS CMIS 1.1 Specification (abgerufen am 30. September 2026). ↩↩
