.png)
Oracle Transportation Management Integration Guide
Integrate Oracle Transportation Management with enterprise applications through REST APIs, SOAP/XML services, event-based transmissions, and file-oriented workflows.
Oracle Transportation Management integration options at a glance
Oracle Transportation Management provides REST resources for current application-to-application integrations and established SOAP/XML web services for operations that depend on legacy or resource-specific interfaces. OTM also supports configured event, agent, and transmission-based outbound integration for selected scenarios, together with bulk XML and file-oriented exchanges. Authentication can use Basic Authentication, OAuth 2.0, Oracle application users, roles, and endpoint-specific security headers over HTTPS. Martini can consume these interfaces, transform XML and JSON, coordinate asynchronous processing, expose intermediary APIs, and combine scheduled reconciliation with event-driven workflows.
| Integration point | Supported by Oracle Transportation Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve and manage OTM resources such as Order Releases, Shipments, Locations, and related transportation data where the required operation is available. | Martini can consume OTM REST resources from workflows, transform responses, apply business rules, and expose intermediary APIs. |
| SOAP APIs | Yes | Use established OTM SOAP/XML web services for resource-specific operations and integrations based on existing XML transaction models. | Martini can consume SOAP services, send XML requests, parse responses, and transform XML into JSON, files, database records, or messages. |
| Webhooks / outbound callbacks | Limited | OTM supports selected event-, agent-, and transmission-based outbound scenarios, but not universal webhook coverage. | Martini can receive supported outbound messages or configured delivery through an API or workflow and route them using event-specific rules. |
| Bulk / async / batch APIs | Limited | Bulk XML or file exchanges and resource-specific asynchronous processing support high-volume transportation transactions. | Martini can batch requests, retain OTM identifiers, poll asynchronous status, reconcile results, and route partial failures. |
| File / attachment APIs | Limited | XML and file-oriented exchanges support bulk order imports, shipment updates, carrier or rate data, and legacy integrations. | Martini can retrieve or deliver files through a confirmed transport, validate and transform them, archive payloads, and invoke OTM APIs. |
| Authentication | Yes | OTM integrations can use Basic Authentication, OAuth 2.0, Oracle application users and roles, endpoint-specific security headers, and HTTPS. | Martini stores environment-specific credentials and token settings securely and applies authorization when invoking OTM endpoints. |
| Database / analytics access | No | Direct access to the Oracle-managed OTM SaaS database is not the normal integration path. | Martini should use OTM APIs, configured transmissions, reports, or approved exports rather than direct database access. |
How Oracle Transportation Management exposes data and business events
Oracle Transportation Management REST APIs
OTM Cloud provides REST resources for transportation objects and operations. REST is the preferred application-to-application mechanism when the required resource and operation are available.
Martini implementation pattern
Martini implementation pattern: a workflow or Martini API authenticates to OTM, retrieves or submits a resource, transforms the response, applies business rules, and persists identifiers and checkpoints for later reconciliation.
Implementation sequence
Oracle Transportation Management SOAP/XML
OTM has established SOAP/XML web services for operations that are not available through REST or that depend on existing XML transaction models and transmissions.
Martini implementation pattern
Martini implementation pattern: a workflow invokes the OTM SOAP service, handles endpoint-specific security headers, parses XML, maps the result to a canonical model, and routes SOAP faults or business errors for review.
Implementation sequence
OTM event and transmission integrations
OTM supports selected event-, agent-, and transmission-based outbound scenarios. Coverage is event-specific and should not be treated as universal webhook support.
Martini implementation pattern
Martini implementation pattern: receive the configured OTM outbound message or delivery, validate its event and correlation data, retrieve the current resource when necessary, and update downstream systems with a safety-net reconciliation workflow.
Implementation sequence
Bulk and file-based OTM integration
OTM supports bulk XML and file-oriented exchanges for order imports, shipment updates, carrier or rate data, and legacy-system scenarios. The exact file transport must be confirmed for the deployment.
Martini implementation pattern
Martini implementation pattern: retrieve or receive a file through the confirmed transport, validate and transform each transaction, invoke OTM or create an outbound file, archive the source, and report row-level exceptions.
Implementation sequence
Common Oracle Transportation Management integration patterns
Pattern 1: Create Order Releases from order systems
When to use this pattern
Use this pattern when Oracle Fusion Cloud Order Management, Oracle Fusion Cloud ERP, SAP S/4HANA, or another order system must create transportation demand in OTM. Validation is important because missing locations, quantities, units, or planning attributes can make an order unplannable.
Integration direction
Example Mapping
| Oracle Transportation Management Field | Canonical Field | Target Field |
|---|---|---|
| Source order number | externalOrderReference | Order Release external reference |
| Ship-from location | originLocation | Order Release source location |
| Requested quantity | transportQuantity | Order Release line quantity |
| Requested ship date | requestedShipDate | Order Release date |
Martini implementation pattern
Martini receives the source order through an API, file, or workflow trigger, validates required transportation data, maps lines and locations to an Order Release, submits the OTM request, and stores the response identifier. Idempotency checks prevent duplicate Order Releases, while validation and transient-failure paths separate business errors from retryable errors.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
- secure environment configuration
Pattern 2: Synchronize shipment status to downstream applications
When to use this pattern
Use this pattern when downstream teams or customer-facing applications need current OTM Shipment milestones, tracking information, or delivery status. Event-based transmissions can provide selected notifications, while scheduled incremental retrieval provides a reconciliation path.
Integration direction
Example Mapping
| Oracle Transportation Management Field | Canonical Field | Target Field |
|---|---|---|
| Shipment identifier | shipmentReference | Shipment reference |
| Shipment status | transportStatus | Fulfillment status |
| Stop milestone | deliveryMilestone | Latest milestone |
| Estimated delivery time | estimatedDeliveryAt | Estimated delivery |
Martini implementation pattern
A scheduled Martini workflow retrieves Shipments using documented filters, timestamps, or configured transmissions, handles pagination and overlap windows, maps statuses and time zones, and upserts Salesforce data using stable references. Duplicate detection, checkpoint persistence, and replayable error records protect against missed or repeated updates.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination handling
- data mapping
- deduplication
- monitoring
Pattern 3: Route carrier tender and execution messages
When to use this pattern
Use this pattern when OTM must exchange tender, acceptance, rejection, tracking, or delivery information with carrier-facing systems, visibility platforms, or warehouse applications through configured messages.
Integration direction
Example Mapping
| Oracle Transportation Management Field | Canonical Field | Target Field |
|---|---|---|
| Service provider identifier | carrierReference | Carrier code |
| Shipment identifier | shipmentReference | External shipment ID |
| Tender status | executionStatus | Tender response |
| Tracking event | trackingMilestone | Carrier event |
Martini implementation pattern
Martini receives or produces the configured XML or JSON message, routes by carrier and shipment state, converts XML and JSON as required, validates identifiers and units, and records each transmission. Exponential backoff is used for transient delivery failures, while validation and duplicate responses are routed without blind retries.
Martini capabilities used
- event-driven workflows
- XML and JSON transformation
- routing
- business rules
- retry handling
- audit logging
Pattern 4: Reconcile freight invoices and transportation costs
When to use this pattern
Use this pattern when approved OTM shipment costs, invoices, or settlement information must be transferred to Oracle Fusion Cloud Financials, NetSuite, SAP S/4HANA, or a warehouse for reconciliation.
Integration direction
Example Mapping
| Oracle Transportation Management Field | Canonical Field | Target Field |
|---|---|---|
| Shipment identifier | shipmentReference | Transportation reference |
| Transportation charge | freightAmount | Freight amount |
| Currency | currencyCode | Transaction currency |
| Carrier identifier | serviceProviderReference | Supplier or carrier reference |
Martini implementation pattern
A scheduled workflow extracts approved cost and invoice data, validates shipment references, currencies, and financial dimensions, maps the result to the target system, and persists a reconciliation key. Duplicate prevention and exception routing protect financial systems from repeated submissions or incomplete transportation data.
Martini capabilities used
- scheduled workflows
- API consumption
- data transformation
- validation
- duplicate prevention
- exception routing
Applications commonly integrated with Oracle Transportation Management
Oracle Transportation Management commonly participates in multi-system supply-chain and financial architectures. The following applications represent practical integration targets based on OTM’s transportation-planning, execution, shipment, and settlement role; exact objects and directions depend on the deployed interfaces.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Oracle Fusion Cloud ERP | Exchange suppliers, purchase orders, financial dimensions, invoices, and transportation charges across the Oracle application estate. | Oracle Fusion Cloud ERP → Martini → Oracle Transportation Management | Martini receives ERP order or financial data, validates identifiers and dimensions, maps the payload to OTM REST or SOAP/XML structures, and returns approved shipment-cost or settlement information through a separate workflow with correlation and duplicate controls. |
| Oracle Fusion Cloud Order Management | Send fulfillment demand to transportation planning and return transportation or execution status to order-management processes. | Oracle Fusion Cloud Order Management → Martini → Oracle Transportation Management | A Martini API or workflow accepts fulfillment information, maps lines and locations to Order Releases, submits the OTM request, persists the OTM identifier, and synchronizes resulting shipment milestones back to Order Management. |
| Oracle Warehouse Management Cloud | Coordinate packing, dispatch, shipment execution, and warehouse transportation status. | Oracle Warehouse Management Cloud → Martini → Oracle Transportation Management | Martini orchestrates bidirectional API or message exchanges, normalizes locations, equipment, quantities, and status codes, and routes invalid or delayed transactions to retry and operational-review paths. |
| SAP S/4HANA | Exchange orders, deliveries, shipment data, carrier information, and freight costs in mixed Oracle and SAP estates. | SAP S/4HANA → Martini → Oracle Transportation Management | Martini transforms SAP payloads into OTM REST, SOAP/XML, or approved file transactions, applies cross-system identifier mapping, and performs scheduled reconciliation for asynchronous or delayed OTM processing. |
| Salesforce | Expose customer-facing shipment status, delivery milestones, and fulfillment information to service and account teams. | Oracle Transportation Management → Martini → Salesforce | A scheduled or event-assisted Martini workflow retrieves changed Shipments, maps milestones and tracking details to Salesforce fields, upserts using stable references, and records failures for replay. |
| ServiceNow | Create operational cases for failed tenders, delivery exceptions, integration failures, or transportation incidents. | Oracle Transportation Management → Martini → ServiceNow | Martini evaluates OTM status or transmission outcomes, applies exception rules, and calls ServiceNow with a normalized incident payload while retaining OTM and correlation identifiers. |
| NetSuite | Exchange order, fulfillment, vendor, and freight-cost information when NetSuite is the financial or order-management system. | NetSuite → Martini → Oracle Transportation Management | Martini maps NetSuite transactions to OTM Order Releases and maps approved OTM charges back to NetSuite, using validation, checkpointing, and duplicate prevention for retries. |
How to build a Oracle Transportation Management integration in Martini
Objective
Establish environment-specific access to OTM without embedding credentials in workflows or code.
Instructions in Martini
- Configure the OTM base URL and endpoint settings as environment values
- Store Basic Authentication credentials or OAuth 2.0 client details in secrets
- Apply the least-privilege Oracle user, roles, and data-security policies
- Use HTTPS and verify the applicable endpoint security configuration
Objective
Select an integration trigger that matches the required latency and OTM capability.
Instructions in Martini
- Use an API request for synchronous order or status operations
- Use a configured OTM event, agent, or transmission for selected outbound scenarios
- Use a scheduler for incremental retrieval and reconciliation
- Use a file trigger only when the OTM deployment confirms the required transport
Objective
Acquire OTM data while preserving identifiers, pagination state, and source context.
Instructions in Martini
- Call the documented REST resource or SOAP service
- Receive and validate configured outbound XML or message transmissions
- Apply narrow filters such as update time, status, organization, or identifier
- Persist continuation state for large or asynchronous operations
Objective
Coordinate calls, transformations, business decisions, and asynchronous follow-up in a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, transformation, and target-write logic
- Retain OTM request or object identifiers for asynchronous processing
- Use conditional routing for business exceptions and response states
- Add a reconciliation path when event coverage is incomplete
Objective
Convert OTM transportation structures into the target model with explicit handling for XML, JSON, units, and time zones.
Instructions in Martini
- Map Order Release lines, Shipment stops, locations, carrier identifiers, and statuses
- Normalize timestamps while retaining required OTM time-zone context
- Validate quantities, weights, volumes, distances, currencies, and required references
- Apply stable external identifiers for idempotent writes
Objective
Deliver the transformed result to the target application, API, file, database, or message endpoint.
Instructions in Martini
- Call the target API or produce the approved file or message
- Use upsert or equivalent duplicate-safe behavior where available
- Store target acknowledgements with OTM and Martini correlation identifiers
- Route rejected records separately from successfully processed records
Common Oracle Transportation Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Order Release | Represents freight demand that must be planned and transported. | Oracle Fusion Cloud Order Management, Oracle Fusion Cloud ERP, SAP S/4HANA, warehouse systems | Martini validates locations, lines, quantities, units, and external references before submitting through REST, SOAP/XML, or approved bulk exchange. |
| Shipment | Represents a planned or executed transportation movement with stops, equipment, costs, and status. | Salesforce, ServiceNow, Oracle Order Management, warehouse systems, visibility platforms | Martini retrieves changed Shipments, maps milestones and identifiers, applies incremental checkpoints, and upserts downstream data. |
| Location | Defines ship-from, ship-to, supplier, customer, terminal, or warehouse points. | ERP, order management, warehouse, carrier, and master-data applications | Martini normalizes location identifiers, qualifiers, addresses, time zones, and units before cross-system synchronization. |
| Itinerary | Defines transportation routing or planning structures for moving an Order Release through a network. | Planning, order management, warehouse, and transportation applications | Martini maps applicable routing attributes and preserves OTM identifiers when sharing planning context with other systems. |
| Rate Offering | Represents a carrier or service offering used during rating and transportation planning. | Carrier systems, procurement, planning, and financial applications | Martini transforms carrier and service identifiers, validates effective data, and routes changes through REST, SOAP/XML, or file workflows. |
| Rate Record | Contains detailed rate structures used to calculate transportation costs. | Oracle Fusion Cloud ERP, SAP S/4HANA, NetSuite, data warehouses | Martini extracts or receives rate data, maps currencies and units, applies validation rules, and supports reconciliation of calculated costs. |
Authentication and security considerations
Authentication and security
OTM integrations commonly use Basic Authentication or OAuth 2.0, with access governed by Oracle application users, roles, privileges, and data-security policies. SOAP services may require endpoint-specific security headers or credentials.
- Store OTM URLs, credentials, OAuth client details, and token settings in Martini environment configuration or secrets.
- Use HTTPS and a dedicated least-privilege Oracle integration user.
- Do not embed credentials in mappings, workflow definitions, or custom code.
- Rotate credentials and review Oracle roles according to organizational security policy.
Operational considerations for Oracle Transportation Management integrations
Reliability and operations
Design for OTM release changes, pagination, asynchronous processing, service limits, and event-specific coverage. Resource names, fields, and required attributes can change across Oracle Cloud updates.
- Use narrow filters, persisted checkpoints, overlap windows, and pagination for large Shipment or Order Release datasets.
- Use stable external identifiers and correlation IDs to prevent duplicate submissions.
- Apply bounded concurrency and exponential backoff for transient failures and rate limits.
- Distinguish authentication, validation, duplicate, business, and temporary service errors.
- Retain request payloads, OTM response bodies, HTTP status, transaction identifiers, and Martini correlation IDs.
- Regression-test mappings after OTM releases and validate time zones, units, currencies, and status codes.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Direct scripts and point-to-point integrations often couple OTM payloads, credentials, retries, and target-specific mappings in code that is difficult to govern. Martini separates these concerns into workflows, APIs, mappings, environment configuration, and reusable integration logic.
- Coordinate REST, SOAP/XML, event transmissions, files, and scheduled reconciliation in one integration layer.
- Transform XML and JSON into canonical models without requiring every target to understand OTM structures.
- Apply validation, routing, idempotency, retry, and exception-handling policies consistently.
- Expose controlled API façades and reuse integration assets across ERP, order, warehouse, carrier, and financial processes.
- Provide operational logging and clearer deployment boundaries than isolated scripts.
Frequently asked questions
OTM can be integrated through REST APIs, SOAP/XML web services, configured event-, agent-, and transmission-based outbound messages, and bulk or file-oriented exchanges. REST is generally preferred when the required resource and operation are available; SOAP/XML and file patterns remain useful for established or resource-specific interfaces.
Yes. Martini can integrate with OTM by consuming its REST APIs and SOAP/XML services, receiving supported outbound messages, orchestrating file-based exchanges, transforming XML and JSON, and coordinating scheduled or event-assisted workflows.
No. A dedicated Oracle Transportation Management connector is not required. Martini can use OTM’s confirmed native REST, SOAP/XML, event-based transmission, file, and authentication mechanisms through workflows, APIs, mappings, and reusable integration logic.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Oracle Transportation Management with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Oracle, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
Use REST when the required OTM resource and operation are available. Use SOAP/XML for established web services or XML transaction models, and use event transmissions or files when the deployment and transaction type support those mechanisms. OTM GraphQL support was not confirmed.
OTM supports selected event-, agent-, and transmission-based outbound integration scenarios, but this is not universal webhook coverage. Confirm the specific event, transmission type, destination, and any Oracle integration service requirement. A scheduled reconciliation workflow can supplement event processing.
Use documented OTM filters, update timestamps, status criteria, or event transmissions. Martini can paginate results, persist checkpoints, use overlap windows for delayed updates, deduplicate by stable identifiers, and poll or reconcile asynchronous operations.
Martini maps OTM XML or JSON into canonical and target models, validates transportation fields and business rules, and routes errors by type. Transient network, timeout, and rate-limit failures can be retried with backoff, while authorization, validation, duplicate, and business errors should be preserved for correction or controlled replay. Martini can also expose an API façade for controlled access to OTM workflows.
Related Martini documentation
Integrate Oracle Transportation Management with Martini
Use Martini to connect OTM APIs, SOAP services, transmissions, and file exchanges with the applications that support transportation planning, execution, and financial reconciliation.