ArchiveLink on RISE with SAP: keep the link, redesign the path

The archive is not in the subscription by default

E3 Magazine’s July 2026 note on Rise and the SAP archive put the practical point in plain language: Rise commonly bundles infrastructure and operation of the SAP Basis system; the archive (including ArchiveLink integration) is generally a separate landscape decision. Companies that assume “archive is included” often discover the gap late, near cutover.

That is not an argument against RISE. It is an argument for naming the archive as its own workstream.

ArchiveLink still belongs in the conversation

ArchiveLink remains a supported, proven interface for linking SAP business objects to stored documents on S/4 and in Rise contexts. CMIS is establishing itself as an open standard for newer content integrations. In practice many programs keep existing ArchiveLink integrations for current document flows and introduce CMIS for new content over time. Hybrid is normal. Panic is optional.

For OpenText VIM, ArchiveLink is still the everyday bridge between the DP / invoice document and the image AP must see. The link is not the storage. The repository and the network path are.

Redesign the path, keep the link

On RISE / private cloud the archive usually sits outside the SAP tenant. The connection crosses defined networks. That means:

  • Content repository configuration (for example OAC0) still matters.

  • Document types and object links (OAC2 / OAC3 patterns) still matter.

  • HTTP services and host resolution matter more than they did when everything lived on one LAN story.

  • Who operates the archive software, the storage, and the certificate chain must be named—RISE operations will not invent that owner for you.

Operating choice: keep ArchiveLink for VIM invoice images if that is your current, working model. Redesign the path so retrieval works from the workplaces you will actually expose. Do not “replace ArchiveLink” as a slogan because the project logo changed.

Retrieval is the acceptance test

A repository that stores is not a repository that serves. Before cutover:

  • Store a known invoice image through the real inbound path.

  • Open it from the VIM workplace the AP team will use.

  • Open it again from any public or load-balanced Fiori path in scope.

  • Fail deliberately (wrong host, internal-only DNS) once in a lower environment so the runbook has a real symptom.

Who carries it? Basis and the archive owner build the path. AP signs that the image opened. The VIM lead confirms the ArchiveLink document type mapping on the DP type still matches.

Clean core reading

Do not shove invoice images into the S/4 database to “simplify RISE.” Do not open a second unofficial share drive for “temporary” PDFs. Keep the link in the interface you standardized; keep content in the repository you can retain and delete under policy. ILM and retention remain their own conversation—this article is about the path AP uses on Tuesday.

What to write in the cutover plan

One short block is enough: “Archive remains out of RISE scope unless separately contracted. Interface: ArchiveLink for VIM invoice images. Network path and certificates owned by [role]. Retrieval test signed by AP. CMIS evaluated only for [named new content], not as an unplanned cutover surprise.”

Jason

I talk about hope and faith. I like to be with family, friends, laugh, and live. Jesus is King. ✝️

https://www.mccloyhall.com
Previous
Previous

Public Fiori and OpenText VIM images on RISE Private Cloud

Next
Next

Rebuild the OpenText VIM Chart of Authority after a landscape move