Opening the invoice PDF from inside Oracle EBS Forms: signed URLs done right

A clerk in the Oracle EBS AP Invoice Workbench is looking at an invoice that's been imported and is awaiting a decision. The obvious next question — can I see the actual invoice? — has a frustrating answer in most setups: go somewhere else. Open a separate document system, search by invoice number, hope the link still works. The image and the transaction live in two different worlds, and the user bridges them by hand.

Closing that gap is a small feature with an outsized effect on AP's day-to-day: a "View Invoice" button right in the Forms screen that opens the source PDF in the browser. Doing it well — securely, durably, without exposing the document store to the open internet — takes a bit of plumbing worth understanding.

The two hard parts

There are two independent problems to solve.

First, how do you serve the PDF without making the bucket public? The invoice images sit in object storage (S3). You can't make that bucket world-readable, and you can't hand Oracle long-lived credentials. The answer is CloudFront signed URLs: a CDN distribution in front of the private bucket, configured to require a signature. A short-lived, cryptographically signed URL grants access to exactly one object for a fixed window — typically 15 minutes — then expires.

Second, the part teams underestimate: Oracle has to know where the PDF is. It's not enough to store the S3 path in your AP application's own database. When the invoice posts into EBS, that path has to ride along onto the Oracle record — otherwise the EBS user has the transaction but no pointer back to the document.

Persisting the path onto the Oracle record

This is the gap that breaks the feature if you miss it. Invoice image lands in S3, path is recorded in the AP platform's database, invoice is approved and posted into EBS — but unless you do something deliberate, the S3 path stops at your application boundary and never reaches Oracle.

The clean place to carry it is one of EBS's standard header flexfields — attribute15 on the invoice interface is a natural choice. Three things have to line up:

The staging insert that writes the invoice header into the EBS interface tables must include the S3 path in attribute15.
The import package that moves rows from staging into the live AP invoice tables must copy attribute15 through.
The column has to exist on the staging table in the first place.

Get those three right and every posted invoice carries its own document pointer on the Oracle record — no separate lookup table, no fragile join between systems. The invoice is the link to its image.

The request flow, end to end

Once the path is on the record, click-to-view is a clean chain of single-purpose hops:

The user clicks "View Invoice" in the AP Invoice Workbench; a Forms library procedure fires.
It reads the stored S3 path from the invoice record and calls a PL/SQL package — EZCLOUD_DOCUMENT_PKG — to turn it into a viewable link.
The package makes an HTTP call (via UTL_HTTP) to a small signing service, passing the S3 path.
The signing service authenticates the request, loads the CloudFront private key, and generates a signed URL valid for 15 minutes.
The URL returns through PL/SQL to Forms, which calls WEB.SHOW_DOCUMENT to open it in a new tab.
The browser fetches the PDF from CloudFront, which verifies the signature and serves it from S3. After 15 minutes the URL is dead.

Each layer does one job, and the trust boundaries are explicit.

The security model is layered, not bolted on

The reason to build it this way rather than, say, presigning a URL and pasting it somewhere is that each hop has its own authentication:

EBS → signing service: a shared API key in an X-Api-Key header. System-to-system; no user login is involved or needed.
Signing service → CloudFront: a 2048-bit RSA signature with a 15-minute expiry. The private key lives in a secrets manager, never in code or config files.
CloudFront → S3: Origin Access Control. The bucket is private and only reachable through the CDN, never directly.

The PDF is never publicly addressable. A signed URL that leaks is useless within the quarter-hour, and the bucket behind it stays sealed regardless.

A couple of Oracle-specific gotchas

Two things bite teams doing this on EBS for the first time. Oracle 19c's UTL_HTTP enforces SSL hostname verification — over HTTPS, the certificate's SAN must contain the hostname Oracle dials, not just an IP, or you'll hit ORA-24263. And the UTL_HTTP access-control list must explicitly grant the APPS schema network access to the signing service's host and port. Neither is hard; both fail silently if missed.

Where this fits

Keeping the invoice image one click from the transaction is part of what makes AP automation feel native to Oracle rather than bolted alongside it — the principle behind ERP-native AP automation generally. And it relies on integrating the supported way: standard flexfields, the documented AP import path, no custom writes to base tables — the posture described on our Oracle EBS and Fusion integration page, which is what keeps the feature surviving EBS patches and upgrades.

Where EZ Cloud fits

EZ Cloud captures the invoice, posts it into Oracle EBS through the supported import path, and persists the document's S3 location onto the Oracle record itself — so a Forms user opens the source PDF straight from the AP Invoice Workbench. Access runs over CloudFront signed URLs with a short expiry, a private bucket, and layered system-to-system authentication. Image and transaction stay together; the document store stays locked down.

If your AP team leaves Oracle every time they need to eyeball an invoice, that round trip is pure friction — and it's a gap that's straightforward to close.