Automate file‑based integrations without custom schedulers (OIC Gen3 24.10+)
File‑based integrations are still extremely common—daily CSV extracts, XML drops from legacy systems, or batch partner feeds over FTP/SFTP.
Before Oracle Integration Cloud (OIC) Gen3 24.10,
triggering an integration when a file arrived often required:
- Scheduled integrations
- External scripts
- Custom polling logic
Gen3 introduced a native File‑Polling trigger and it simplifies everything.
In this post, I’ll walk through how to use the new FTP File Polling trigger, when to use it, and what to watch out for.
When Should You Use File Polling?
Use this feature if:
- Files are small to medium in size
- You want to trigger immediately on file arrival
- You don’t need manual file download logic
- You prefer a low‑code, native OIC pattern
Typical use cases:
- Daily CSV or XML reports
- Lightweight batch integrations
- Partner file drops
- Staging‑based data ingestion
What’s New in OIC Gen3 24.10+
With the FTP File‑Polling trigger, you can:
- Automatically trigger an integration when a file arrives
- Match files using filename patterns
- Load file content directly as payload
- Control archive, delete, or reject behavior
- Avoid additional adapters or scripts
Step‑by‑Step: Configuring File Polling in OIC
1. Verify OIC Version
Ensure your instance is:
Oracle Integration Cloud Gen3 – 24.10 or later
File polling is not available in earlier Gen3 builds.
2. Configure FTP / SFTP Connection
Create or reuse an FTP adapter connection with Trigger & Invoke role:
- Host, port, credentials
- Source directory permissions
- Optional archive/reject directories
Test the connection before proceeding.
3.Use the File‑Polling Trigger
While creating the integration:
- Select the FTP Adapter as the trigger
- Choose File Polling as the trigger type
You’ll configure:
- Polling frequency (e.g., every 5 minutes)
- Source directory
- Filename pattern (e.g., *.csv)
- Schema type (CSV / XML)
- Optional sample file upload for schema generation This eliminates the need for a separate file‑server read step.
4. Configure File Handling Behavior
You can define what happens after the file is read:
📦 Archive the file
🗑️ Delete after successful read
🚫 Reject invalid files
⚠️ Ignore delete errors to prevent retries
This is extremely useful for idempotency and cleanup.
5. Design the Integration Flow
After the trigger:
Parse file content using the generated schema
Route data to downstream systems
Apply validations and transformations
Handle errors using reject logic
The file content is already available as the payload—no manual streaming required.
6. Test with a Proof of Concept (POC)
Before production:
- Drop a test file matching the pattern
- Confirm the integration triggers immediately
- Validate: *File movement (archive/delete) *Payload parsing *Error handling
7. Deploy & Monitor
Once verified:
- Activate the integration
- Monitor tracking for file runs
- Adjust polling frequency or file rules if required
Top comments (0)