OpenText VIM document archiving: keep the write job honest
Two archiving conversations that get mixed up
In OpenText VIM programs, “archiving” often means two different jobs:
Document / image archiving — storing the invoice image (and related content) through ArchiveLink or the archive path your landscape uses, usually tied to DP / document processing.
Table / data archiving — reducing SAP database growth for VIM and related tables under ILM or classical archiving rules.
They share a word. They do not share an owner story. This article is about keeping the document write path honest so AP can open what was stored. Readiness for table archiving is a separate note already on the site; do not collapse them in the runbook.
What “honest” means for the write job
A write job is honest when:
It finishes in a window Basis can defend.
Failures are visible (not silent partial stores).
The ArchiveLink (or equivalent) link on the business object points at something AP can retrieve.
Volume growth does not depend on one person re-running a job from memory every Friday.
SAP Community Q&A still surfaces a recognizable operating pain: DP / document archiving write work that runs slow, with heavy time associated with log or header access patterns (threads discussing `/OPT/DOC` write behavior and cost around `/OPT/VIM_8LOG`). Treat that as a community-observed pattern and write and log access can become expensive under load—not as a McCloy customer metric and not as invented row counts. The design lesson is general: if your write job spends its life on log/header access, AP will eventually feel delayed images or backlog, and Basis will feel overnight windows slipping.
Operating choices before the job misbehaves
Name the job and the schedule. Which program or process writes documents; which client; which days; who gets the failure mail.
Separate monitoring from folklore. Runtime, error count, and a simple “images retrievable” sample beat a Slack thread saying “archiving seemed slow.”
Watch the log path as a first-class object. If community and your own traces show pressure on VIM log/header tables during write, put that in the health conversation with Basis—index, retention, selection, and volume—without turning it into a blame exercise.
Prove retrieval, not only store. Ten DP documents from the week: open the image from the workplace AP uses. Store-without-serve is a failed archive.
Plan retention with legal and AP together. Deletion and retention are policy. The write job is mechanics. Do not let mechanics invent policy.
Who carries it? Basis and the archive owner operate the write path and the repository. The VIM functional lead confirms document-type and ArchiveLink mapping for the DP types in scope. AP signs that retrieval still works. Finance/legal own retention language. No “the project archived it” sentence without those names.
Clean core reading
Do not park invoice PDFs on a share “until archiving is fixed.” Do not stuff images into the S/4 database to avoid the archive conversation. Keep content in the repository you can retain and delete under policy; keep the link in the interface you standardized. Document archiving stays in the OpenText / ArchiveLink lane you already run.
What this is not
This is not a customer case study and not a claim about your row counts. It is not a demand to buy a new archive product this quarter. It is not the same article as SAP data-archiving readiness or “Content Server when ArchiveLink is not enough.” It is the everyday operating problem of write job health and retrieval proof.
A practical checklist
Job inventory: name, variant, schedule, failure notification, owner.
Weekly sample: ten stores, ten retrievals, signed by AP.
Basis note: runtime trend; any log/header hotspots; open incidents.
Clear line in the runbook: document archiving vs table archiving owners.
After landscape or RISE moves: re-prove write and retrieve in the new network path (internal and public Fiori if in scope).
How the SOW should read
Prefer language like: “Operate and monitor OpenText VIM document / DP archiving write jobs separately from table archiving; define failure alerts; include a weekly AP-signed retrieval sample; investigate log/header access cost if write windows slip; name Basis and archive owners.” If the paper only says “configure archiving,” require the job inventory and retrieval sample.