ArchiveLink connector: SAP filing on Azure, SharePoint and S3
ArchiveLink is the route SAP has used to file documents for decades — and the reason many companies are still tied to an archive system that now costs more than the storage underneath it.
The content server SAP expects — with modern storage behind it
From SAP’s point of view nothing changes: the connector registers as a content repository and answers the calls SAP makes to a content server — store, read, append, update, delete, search and the status queries. It is set up in the familiar transactions of SAP archive administration. The applications that file documents notice nothing of the change; no program is touched and no process rebuilt.
Behind it, however, sits not an appliance in your own basement but Azure Blob Storage, SharePoint Online, AWS S3 or STACKIT. That is the actual lever: storage today is a commodity with a clear price list, an archive system is not. Detach filing from the archive product and you pay for storage instead of paying for the fact that somebody else owns the interface.
A number of operational realities are already taken care of: access can be verified as signed, reading and writing can be enabled separately, a protection flag per document is enforced, and the folder structure can be spread across many subdirectories so that no directory becomes unwieldy at archiving volumes. That layout is decided at setup and afterwards verified by the service itself — changing it later would make existing documents unfindable.
Retention works exactly as on the CMIS route: holds and periods are checked on every change, including when whole subtrees are deleted. More depth on the individual storage targets: blob-connector.com, sharepoint-archivelink.com and cloud-connector-online.com.
At a glance
- Registers as a content repository with SAP
- Storage: Azure Blob, SharePoint Online, AWS S3, STACKIT
- No change to SAP applications or processes
- Signed access, reading and writing enabled separately
- Protection flag per document is enforced
- Holds and retention periods apply as on the CMIS route
Why this matters
What a legacy archive system does to your estate.
- Maintenance and licences cost the same whether anything is added or not
- Filing depends on a product, not on storage — and therefore on that product’s roadmap
- Hardware at end of life forces a decision under time pressure
- Changing storage without changing the interface saves half the project
- When a legacy system is retired, somebody has to touch the documents anyway
What SAP sees
From SAP’s side it is an ordinary content repository.
- Setup in the familiar archive administration transactions
- Store, read, append, update, delete, search
- Individual components of a document addressable separately
- Range reads for large files
- No adaptation of the filing applications
Access security
What is allowed to happen between SAP and storage.
- Signed access is verified, not merely accepted
- Only released certificates are trusted
- Unsigned access refused by default — reading and writing switchable separately
- A newly deposited certificate becomes valid only after an administrator releases it
- A protection flag on the document overrides any general permission
Folder layout at high volumes
The point at which naive solutions fall over.
- A flat root directory becomes a bottleneck at archiving volumes
- Optional distribution across several directory levels
- No directory grows beyond a manageable number of entries
- The layout is decided at setup and afterwards verified by the service itself
- A later change is deliberately refused rather than silently performed
ArchiveLink and CMIS on one data set
Two protocols, one body of data.
- Documents are addressed by their path, not through a mapping table
- So what was filed on the other route is visible too
- Each protocol can be switched off individually
- A disabled protocol is unreachable, not merely blocked
- More on the CMIS route
The way there
How a switch works in practice.
- Survey: which repositories, which document types, what volumes
- Target picture and storage decision, including region and encryption
- Parallel operation: new filings to the new target, legacy content stays for now
- Migration of the legacy content with logging and reconciliation
- The old system is switched off only after the cross-check
Frequently asked questions
Do our SAP applications have to be adapted?
No. The connector presents itself to SAP as a content repository and is set up in the familiar archive administration transactions. The programs that file or display documents keep speaking ArchiveLink and never notice what sits behind it.
Which storage targets are possible?
Azure Blob Storage, SharePoint Online, AWS S3 or S3-compatible storage, and STACKIT. The choice is a configuration matter; several repositories in one process can point at different targets — legacy content on one, new filings on another, for example.
What happens to the existing archive content?
It moves too — as a separate, logged step. The usual approach is parallel operation: new filings go to the new target immediately, the legacy content follows in waves, and only after reconciliation is the old system switched off. For the migration we use a dedicated tool that logs the mapping of old and new identifiers.
Can we use ArchiveLink and CMIS at the same time?
Yes. Both routes work on the same body of data, because documents are addressed by their filing path rather than through a separate mapping table. A document filed via one route is therefore visible through the other. If you only need one route, the other is switched off — it is then unreachable, not merely blocked.
How secure is access?
Access can be signed, and the signatures are actually verified — with a release list of trusted certificates. Unsigned access is refused by default, with reading and writing enabled separately. A protection flag on an individual document overrides any general permission.
Is this designed for retention requirements?
Holds and retention periods are checked on every change, including when whole subtrees are deleted. The honest limit: what is protected is what passes through the connector. Anyone with direct access to the storage bypasses it — which is why we combine this with the storage’s own locking features where required. The procedural documentation remains your task; we supply the technical basis for it.
Does this match your project?
Talk directly to our consultants — no detours.