Scheduling Incremental Data Interface using `fnd_concurrent_requests`

You can restrict your query to records modified since the previous scheduled request run by utilizing a parameterized SQL clause that references the execution history of the concurrent program itself. The core logic involves comparing the record’s modification timestamp (e.g., `rctla.last_update_date`) against the start time of the *previous* request run. The required SQL pattern uses self-referencing joins on `fnd_concurrent_requests` to dynamically retrieve the `actual_start_date` of the last completed parent request.

Certainly. The SQL required, which should be set up as a parameter SQL text, would look similar to this structure: `rctla.last_update_date >= (select fcr0.actual_start_date from fnd_concurrent_requests fcr, fnd_concurrent_requests fcr0 where fcr.request_id = fnd_global.conc_request_id and fcr.parent_request_id = fcr0.request_id)`. This snippet dynamically identifies the current request ID and then looks up its parent request (the previously scheduled job) to retrieve the required `actual_start_date` for filtering.

The easiest way to schedule the report is to first run it from the Blitz Report run window with all parameters set correctly, and then copy the resulting submitted concurrent request. You navigate to ‘View > Requests’, find the request, use ‘Copy’, update the schedule frequency, and then configure the Oracle standard delivery options. Oracle’s delivery options natively allow the report output to be sent as an email attachment, uploaded to a WebDAV cloud storage, or sent to an FTP location, which is ideal for an outbound interface.

If submitting manually, you select the ‘Blitz Report’ concurrent program and must populate arguments 16 onwards with the report parameters. These parameters must be entered in exactly the same order as they appear on the Blitz Report run window. For example, if ‘Operating Unit’ is the third parameter on the form, its value must be entered into Parameter3 of the concurrent request.