Public Fiori and OpenText VIM images on RISE Private Cloud
The symptom AP actually reports
“I can process the invoice, but I cannot see the image.” Or: “It works on VPN, not from the public Fiori URL.” On S/4HANA Cloud Private Edition under RISE, that report is often a path problem, not a VIM configuration fairy tale.
A public SAP Community write-up of a RISE Private Cloud case with OpenText VIM and a public internet-facing Fiori path (via load balancer) describes the pattern clearly: the workplace tries to reach the OpenText archive host; the name resolves inside the network and fails for public users. The fix is not “reinstall VIM.” The fix is intentional internal and external archive locations, host mappings, and routing through the web dispatcher or load balancer you already use for Fiori.
What to treat as separate objects
Keep these distinct on the whiteboard:
VIM workplace / Fiori UI — where AP works.
ArchiveLink link — the SAP object-to-document relationship.
Archive server / Core Archive (or Archive Center) — where bytes live.
Locations and host mappings — how a client finds the right archive endpoint (transactions in the public notes include patterns around OALO, SCMSIP, SCMSHO).
User or foundation parameters — which location a public user should use.
If you collapse those into one “archive is down” ticket, you will waste a week.
Operating choice before cutover
Decide whether public Fiori access to VIM image display is in scope. If it is not, say so in writing so nobody demos it on day one.
If it is, design an external archive endpoint (load balancer / reverse proxy) and an internal endpoint. Do not expose more than the archive paths you need.
Maintain location and host assignments so public clients get the external host and internal clients keep the internal host.
Confirm VIM Foundation general settings and any user-level location parameters for people who will live on the public path.
Test with a real AP user on a network that is not your corporate LAN story.
Who carries it? Basis owns load balancer and host mappings. Archive owner owns the archive listener and certificates. VIM functional lead owns Foundation parameters. AP signs the acceptance screenshot.
What this article is not
This is not a demand to abandon the Windows Validation Client or to force every user onto public Fiori. It is not a capture-product debate. It is the narrow operating problem of image display when the UI is public and the archive was designed as internal-only.
Clean core here means fewer clever exceptions: one documented path for public image retrieval, tested, owned, and monitored and not a pile of personal VPN workarounds.
Cutover evidence
Save three artifacts in the runbook: network diagram of internal vs external archive hosts; transaction screenshots of location/host assignments; AP-signed proof that a DP document opened its image from the public Fiori URL. If any artifact is missing, you are not done.