Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 6 · Reports at scale: scheduling, delivery, performance
What breaks: the 2am report
Lesson 61 of 177 · 2 min
Four failures that only happen unattended, which is why they are all found in production. ONE: A PARAMETER DEFAULTING TO TODAY. You built it interactively, so the date defaulted to the day you tested and everything looked right. Scheduled, it defaults to the run date — which for a report meant to cover last month, submitted on the first, produces an empty file. Every date parameter on a scheduled job needs an explicit relative definition, and "it worked when I ran it" is exactly the evidence that hides this. TWO: A LOCKED FILE. The destination still holds yesterday's file open, or the receiving process is mid-read. Delivery fails, or worse, writes over a file being consumed. Lesson 3's temporary-name-and-rename is the fix. THREE: AN EXPIRED CREDENTIAL. The SFTP key or password that was set at implementation, eighteen months ago, on a system nobody in the project team administers. The extract…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 6 · Reports at scale: scheduling, delivery, performance
- 1The scheduler, and what a job really is
- 2Scheduling patterns that survive
- 3Delivery: email, FTP and content server
- 4Knowing a scheduled report failed
- 5Volume: when the extract stops fitting
- 6Incremental extracts and high-water marks
- 7What breaks: the 2am report
- 8Lab briefing · Schedule, deliver, and prove it ran