ORACLE OTM → SNOWFLAKE
Replicate Oracle Transportation Management shipments, orders, costs, and locations into Snowflake without custom extraction code.
OTM data is difficult to extract well: large operational tables, incomplete metadata, late-arriving updates, sparse date fields, and long-running exports all create failure modes for one-off pipelines. Supaflow handles direct exports for ordinary tables, async exports for large-volume tables, OAuth refresh during long runs, and compound keys in Snowflake. Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume.
Used by 3PLs, shippers, and supply-chain finance teams that need OTM shipment, cost, and order data in Snowflake for analytics and freight reconciliation — with no per-row fees.
Every row below is an actual capability in the Oracle Transportation Management connector, not a forward-looking promise.
| Feature | How it works | Limit / caveat |
|---|---|---|
| Object coverage | Eighteen supported OTM tables out of the box: SHIPMENT, ORDER_RELEASE, ALLOCATION, SHIPMENT_COST (and four cost children), SHIPMENT_STATUS, SHIPMENT_STOP, SHIP_UNIT, LOCATION (plus LOCATION_ADDRESS / LOCATION_REFNUM), ITEM, CONTACT, ADJUSTMENT_REASON, AUDIT_TRAIL, ORDER_RELEASE_STATUS. | Additional OTM tables can be added on request. Supaflow also has a fallback schema path for supported tables where OTM metadata is incomplete. |
| Authentication | Basic Auth and OAuth 2.0 through Oracle Identity Cloud Service are supported. OAuth tokens are refreshed during long exports so large backfills do not fail halfway through authentication expiry. | Long-running async exports may outlive a single OAuth token; Supaflow handles refresh without additional user configuration. |
| Direct vs async export | Use direct export for ordinary tables and async export for large operational tables or full historical backfills. Async export stages results through Oracle Cloud Object Storage and then loads the files into Snowflake. | Async export requires an Oracle Cloud Object Storage target with read/write access and an expiration date that your team manages. |
| Incremental sync | Incremental sync uses OTM update timestamps, accounts for server clock differences, and rechecks a short overlap window for late EDI or rating updates. | OTM workflows can stamp update times after the actual business event; the overlap window protects against missing those late-arriving records. |
| Schema discovery | Supaflow uses OTM metadata when available and falls back to data-driven type inference when a supported table has incomplete metadata. | — |
| Composite primary keys | Several OTM tables use compound keys. Supaflow preserves those keys into Snowflake so merges and reconciliation stay tied to the source model. | — |
| Cancellation safety | Long-running exports can be cancelled cleanly without leaving abandoned async work consuming OTM capacity. | — |
| Destination | Lands directly in Snowflake with generated tables, Snowflake-ready types, compound keys preserved, and incremental merges. | — |
Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees.
OTM exports include metadata gaps, inconsistent temporal values, direct-export size limits, and OAuth token expiry during long-running jobs. Supaflow handles those cases in the connector. The companion OTM integration guide linked below covers the full engineering detail.
Direct export handles most sources quickly. Async export handles large operational tables such as SHIPMENT, ORDER_RELEASE_STATUS, and AUDIT_TRAIL without response-size cliffs. The same destination schema lands in Snowflake either way.
Every one of these is something our connector handles specifically. A generic pipeline built in Airflow or a basic ELT tool will hit at least three of them in production.
Failure mode: Some supported OTM tables return incomplete or unusable metadata. A naive pipeline treats that as fatal and skips the table.
Evidence: Observed across OTM Cloud and on-prem instances.
Fix: Supaflow falls back to data-driven type inference so supported tables stay in the schema rather than disappearing.
Failure mode: Unset OTM date and datetime fields can arrive as sentinel values rather than clean nulls. Pipelines that coerce those values as real dates can create misleading timestamps.
Evidence: Verified across production OTM exports with populated and unset temporal fields.
Fix: Supaflow normalizes unset temporal values to null while preserving populated timestamps.
Failure mode: Some OTM fields described as dates still carry timezone-aware values. Pipelines that force them into date-only columns lose information.
Evidence: Verified empirically across populated OTM temporal fields.
Fix: Supaflow preserves timezone context for populated temporal values instead of stripping it during load.
Failure mode: Large direct exports can return partial results if the pipeline treats a short response as the end of the table.
Evidence: Common on wide operational tables such as SHIPMENT and ORDER_RELEASE.
Fix: Supaflow continues paging until the export is actually complete, and async export is available for large-volume tables.
Failure mode: A long-running async export can outlive a single OAuth token. Refreshing only after a failure can leave the export in an uncertain state.
Evidence: Standard behavior for long-running Oracle Identity Cloud Service OAuth flows.
Fix: Supaflow refreshes OAuth tokens proactively during schema discovery, export, pagination, and async polling.
Provide the OTM server URL and either Basic Auth credentials or OAuth through Oracle Identity Cloud Service. Choose direct export for ordinary tables or async export for large-volume tables.
Oracle TM source docs→Eighteen supported OTM tables out of the box. Pick the subset that matches your use case — most teams sync 5–10 tables: SHIPMENT, ORDER_RELEASE, ALLOCATION, SHIPMENT_COST, LOCATION, CONTACT.
Per-table reference→Connect your Snowflake warehouse. Each OTM table becomes a Snowflake table with compound keys preserved and Snowflake-ready types.
Snowflake destination docs→Run on a cron or interval schedule. Incremental sync uses OTM update timestamps with clock-difference handling and an overlap window for late-arriving updates.
Schedules docs→Supaflow authenticates with OTM using Basic Auth or OAuth, exports supported table data directly or through async Oracle Cloud Object Storage, and lands it in Snowflake. Schema metadata is used when available, with data-driven inference as a fallback. Incremental sync uses OTM update timestamps with clock-difference and overlap-window handling.
Eighteen tables are supported out of the box: SHIPMENT, ORDER_RELEASE, ALLOCATION, SHIPMENT_COST and four cost children, SHIPMENT_STATUS, SHIPMENT_STOP, SHIP_UNIT, LOCATION plus LOCATION_ADDRESS and LOCATION_REFNUM, ITEM, CONTACT, ADJUSTMENT_REASON, AUDIT_TRAIL, and ORDER_RELEASE_STATUS. Additional tables can be added on request, and per-table references are linked from the OTM source docs in Resources below.
Direct export is simpler and fits ordinary tables. Async export stages results in Oracle Cloud Object Storage and is better for large operational tables such as SHIPMENT, ORDER_RELEASE_STATUS, and AUDIT_TRAIL, especially during historical backfills. If your workload mixes small and large tables, configure separate sources for each strategy.
Both. The connector works with Oracle OTM Cloud and on-premises OTM installations reachable over HTTPS. Authentication options and export behavior are the same in both topologies.
Fivetran does not offer a managed OTM connector. Hevo prices by row volume. Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 compute-hour on a Small node). No per-row fees. See the pricing page for the credit packages and free tier.
Supaflow falls back to data-driven type inference when OTM metadata is incomplete. Supported tables stay in the schema rather than disappearing. The full quirk list, including temporal edge cases and direct-export limits, is documented in the OTM integration guide linked in Resources below.
Yes. The sync agent runs in your own VPC if you want OTM credentials, OAuth tokens, and OTM data to stay in your network. The control plane is managed; the data plane can be managed or self-hosted.
The Oracle Transportation Management source and Snowflake destination, plus other Supaflow connectors you can pair into a Snowflake pipeline.
Source connector overview, supported objects, and configuration.
Destination connector overview and capabilities.
The complete guide to OTM data integration: export modes, quirks, and architecture.
Per-table reference for all 18 supported OTM tables.
For shipment master data that lives alongside transactional SQL Server systems.
Browse the full catalog of sources and destinations.
Server URL configuration, Basic Auth and OAuth setup, direct and async modes, troubleshooting.
Connect your Snowflake warehouse, role requirements, type mapping, and sync semantics.
The complete pillar: export modes, OTM quirks, incremental sync, async export, and architecture.
Every connector is included on every plan. Pay only for compute consumed (Supaflow Credits).
Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume. Direct or async export, OAuth or Basic Auth, reliable incremental sync, and all 18 supported OTM tables.