Bulk-loading Oracle WebCenter Content with the Batch Loader

Who this is for

The engineer who has to get a large volume of documents into WebCenter Content with their metadata intact — a re-platforming from an older release, an archive being onboarded, a cutover where thousands of records have to land before go-live — and is not going to do it through the check-in screen one file at a time.

What the Batch Loader does

The Batch Loader reads a plain-text batch load file and, for each record in it, performs a content-management action against WebCenter Content: most often a check-in (insert), but also update and delete. Each record carries the metadata for one content item plus a pointer to the file on disk. The utility walks the file top to bottom and executes each record as if it were an individual service call.

That is the whole model, and it is the right one to hold: a batch load file is a script of check-ins. Every metadata field you would fill in on the check-in page has a corresponding line in the record. If you can express one check-in as text, you can express fifty thousand.

We ran this most recently on a WebCenter Content migration for a national home-services company, and the mechanics are worth writing down because the utility is straightforward once you have done it and opaque the first time — the documentation treats the file format and the load run as two disconnected topics.

Step 1 — Build the batch load file

The file is made of records separated by a delimiter line. Each record is a set of name=value pairs, one per line, followed by the end-of-record marker.

# Comment lines are allowed
Action=insert
dDocName=SVC-CONTRACT-00012
dDocType=Document
dDocTitle=Service Agreement 00012
dDocAuthor=batchload
dSecurityGroup=Public
dInDate=7/10/2026
primaryFile=contract_00012.pdf
<<EOD>>

Four fields matter more than they look.

• primaryFile is the path to the file being checked in, resolved relative to the base collection path you give at run time. It is the field that ties a metadata record to an actual document. Get the relative path wrong and the record fails, whatever else is perfect.
• dDocName is the content ID. Supply it and you own the namespace and must keep it unique across the load; omit it and the system generates one. On a migration where downstream systems reference documents by ID, carry the IDs across yourself.
• Custom metadata — the x-prefixed fields defined in Configuration Manager — go in exactly the same way: xDepartment=Field Service, xContractYear=2026. The loader does not distinguish standard from custom fields; it maps names to the item's metadata.
• The end-of-record delimiter (the EOD marker wrapped in double angle brackets in the example) has to be consistent throughout and has to match what the loader expects. A missing or mismatched delimiter does not fail loudly; it merges two records or truncates one, and you find out at validation.

For a real migration you do not hand-author this file. You generate it — from a spreadsheet export, a query against the source system, or a script that walks the source archive and reads its metadata. The generation step is where the engineering lives: mapping source metadata to target fields, normalizing dates to the format WebCenter expects, and making sure every primaryFile points at a file that is staged where the loader will look.

Step 2 — Stage the files and the load file on the host

Copy the documents and the batch load file to a working location on the content server host. On the migration above this meant getting onto the host over SSH, becoming the OS account that owns the domain, and placing the staged content in a directory the server process could read.

• Ownership and permissions. The Batch Loader runs as the domain's OS user. If the files were copied up under a different account, the load user has to be able to read every one of them. A permissions gap produces per-record failures that look like missing-file errors.
• Path discipline. Pick one base collection directory, put everything under it, and make every primaryFile relative to exactly that. Mixing absolute and relative paths across a large file is the single most common reason a load that should have worked comes back with a pile of failed records.

Step 3 — Run the load

WebCenter Content ships the Batch Loader under the content server's bin directory. From that directory on the host:

./BatchLoader

That launches the Batch Loader interface and prompts for the content server administrator credentials. From there:

1. Browse to the batch load file staged in Step 2.
2. Set the maximum number of errors tolerated before the run aborts. On a first pass keep it low — you want the loader to stop and show you the problem, not grind through fifty thousand records making the same mistake. Raise it on a validated production run.
3. Enable the error file for failed revision classes. This writes out a file containing exactly the records that failed, in the same batch-load format. It is the mechanism that makes a large load recoverable: fix the failures, re-run just the error file, and the load reconciles without re-checking-in everything that already succeeded.
4. Load Batch File. A success message confirms the run completed.

The interactive interface is the right tool for a one-time, supervised migration: you watch each run, failures surface as they happen, and there is no scripting layer between you and the loader. For a hands-off or repeatable pipeline, the content server exposes the same capability through its command-line utility, IdcCommand, driven by a command file — which is how you would wire a load into an automated cutover.

Step 4 — Validate

A "load complete" message means the utility finished. It does not mean every document is queryable the way you expect.

• Search and count. Run a broad search in the content server and confirm the count of returned items matches what you loaded. A count short by exactly the number of records in the error file is the good case: it means the error file caught them.
• Spot-check metadata, not just presence. Open a sample of loaded items and confirm the custom fields, security group and content type landed correctly. A load can succeed while silently dropping a field whose name did not match a defined field.
• Work the error file. Read each failure reason, fix the load file for those records, re-run the error file, repeat until it is empty. A migration is not done when the first load finishes; it is done when the error file is empty and the counts reconcile.

Where this fits in a 12c-to-14c re-platforming

If you are moving WebCenter Content between releases — and the December 2026 end of Fusion Middleware 12c Premier Support has a lot of estates looking hard at exactly that — the Batch Loader is the workhorse for the content-migration leg. The out-of-place upgrade moves the server; the Batch Loader is how content gets re-homed, with metadata, in bulk, in a way you can validate and re-run. It is the same tool that carries an archive into a repository on OCI. Understanding the file format and the error-file loop is what turns "we have to migrate 200,000 documents" from a frightening number into a supervised, reconcilable process.

The load run is a few clicks. What makes or breaks a bulk load is the generation of the batch load file — mapping source metadata cleanly, staging files where the loader can read them, building the validation loop that proves the migration landed. Whether a given source field belongs in xDepartment or somewhere else, whether a reconciled count means the right documents landed against the right metadata, whether the source estate has quirks a clean-looking load will carry straight through — those are calls about your specific source system.

How ECMWorks does this

We treat the mapping, not the load, as the deliverable. The engagement starts by reading the source system's metadata model and the target's Configuration Manager definitions side by side, produces the field map and the generator, runs a small validated load first, then scales to the full volume with the error-file loop as the reconciliation mechanism. On a migration that is part of a wider 12c-to-14c programme, the Batch Loader work is sequenced against the clone-for-test rehearsal so the content leg is proven before the cutover window opens.