Inbound Integrations (XML)

OTM supports several methods for receiving data from external systems. This topic covers XML-based integrations, which are the most common approach in OTM implementations.

Integration Methods Overview:

GlogXML via Middleware: XML files following the GlogXML schema, posted to OTM from middleware platforms such as Oracle SOA/BPEL, webMethods, or MuleSoft. This is the most common approach for production integrations.
Manual XML Upload: OTM users manually upload a GlogXML-formatted XML file through the OTM Integration Manager screen. Useful for testing, one-time loads, or small data corrections.
CSV Upload: Uploading data using comma-separated value files for supported OTM entities. See the CSV Data Uploads topic for details.
DB.XML Upload: A method for loading data directly using database-level XML files, typically used in implementations or data migrations.
REST API: Newer versions of OTM support REST API-based integrations for querying and updating OTM data without using GlogXML format.
HTTP Post from Code: Custom programs written in PL/SQL, Java, or other languages can post GlogXML directly to the OTM WMServlet endpoint. See the Post Data via HTTP Request topic for details.

GlogXML Schema:

What is OTM ?

OTM stands for Oracle Transportation Management. It is a software product designed to automate various logistics business processes — receiving orders from source ERP systems for freight consolidation, optimizing routes and shipping costs, sending tender requests to carriers, receiving shipment tracking events, processing invoices, allocating freight costs to orders, and more.

Some of the Core Capabilities of OTM:

Order Management: Receive Purchase Orders (Order Base) from source ERP or legacy systems and create Order Releases (Bookings) for full or partial quantities, either manually or through automated release rules.
Bulk Planning: Consolidate Order Releases (Bookings) with common source and destination locations, or build multi-stop shipments. The Bulk Plan algorithm identifies the optimal route (Itinerary), selects the least-cost carrier based on pre-configured rates, optimizes loading of items into equipment, and calculates in-transit times.
Third-Party Rate and Distance Engines: OTM can dynamically fetch LTL rates from third-party engines such as SMC³ RateWare XL, and calculate distances between locations using mileage engines such as PC*MILER or MileMaker.
Tendering: Send Tender Offer requests to the carriers identified during planning. If a carrier cannot accept XML tender files directly, middleware tools such as MuleSoft, Oracle BPEL, or similar integration platforms can be used to translate OTM outbound XML to carrier-readable formats such as EDI.
Tender Response: Receive and process carrier tender responses and update the shipment accordingly.
Shipment Tracking: Receive shipment tracking updates from carriers and update shipment status in OTM.
Invoicing: Receive and process invoices from carriers, match invoice costs against planned costs for approval, create vouchers for approved invoices, and allocate freight costs back to customer orders.

Ease of Implementation:

Order Management Data Structure

OTM models order management across three levels: the Purchase Order (what was ordered), the Order Release (a confirmed booking for movement), and Order Movements (the planned legs of that movement). Understanding this hierarchy and the underlying tables is essential for integration work and troubleshooting.

Purchase Order (Order Base):

A Purchase Order represents the commercial transaction — what items are being moved, from where, to where, and under what terms. POs are typically created in an ERP system (e.g. Oracle E-Business Suite) and sent to OTM via inbound integration. Note that POs often lack exact weight and volume details, which are required for shipment planning — those are defined on the Order Release.

Product Architecture

OTM follows a standard three-tier architecture — a widely used design in enterprise software where the application is split into three distinct layers: Web Tier, Application Tier, and Database Tier. Each tier has a specific responsibility, and together they allow OTM to scale, be maintained, and support many users simultaneously.

Depending on the deployment model — on-premise or SaaS — the underlying infrastructure differs, but the three-tier concept remains the same. In on-premise deployments, your organization manages each tier on its own servers. In SaaS (cloud) deployments, Oracle manages the infrastructure and these tiers are hosted and maintained by Oracle.

Outbound Integrations

OTM can generate outbound XML data for any business object — Order Release, Shipment, Invoice, and more — and send it to an external system such as a carrier platform, ERP, or middleware. This can be triggered manually using the Send Interface Transmission action, or automatically from an OTM Agent (workflow). OTM Agents are covered in a later topic.

There are three things you need to set up before OTM can send outbound data:

Domain, Items, Locations, and Equipment

This is the first in a series of eight posts that walk through a complete OTM end-to-end transaction flow — from initial setup through planning, tendering, invoicing, and cost allocation. Each post builds on the previous one. Use this series as a starting point and refer to OTM Help documentation to explore each topic in depth.

Recommendation for new OTM consultants: If you are early in your OTM career, the single most effective way to build confidence is to complete this entire series hands-on in a non-production environment. Step through each post in order, create every object yourself, and verify the results — rather than just reading through them. You will make mistakes, and that is exactly the point: troubleshooting your own configuration teaches you far more than any documentation can.

You do not need to create a new Domain. Skip the Domain creation step and work inside your existing business domain instead. Everything else — Items, Locations, Equipment, Service Providers, Rates, Itineraries, Bulk Plan, Tender, Invoice, and Voucher Allocation — can be built and tested within your current domain without affecting production data.

Business Scenario:

Business Numbers, Planning Parameter

Business Numbers:

OTM auto-generates IDs for business objects — shipments, order releases, invoices — using Business Number Rules. By default, shipments get a simple sequential number (e.g. 01001). A custom rule lets you embed the date, a prefix, or a domain-specific sequence into the generated ID, making it easier to identify records and align with your organisation’s numbering conventions.

The default shipment number looks like this:

Default OTM shipment number showing sequential ID format

Bulk Plan

Bulk Plan is OTM’s automated planning engine. It reads Order Release or Order Movements, matches them against the Itineraries and Rate Records configured in earlier posts, and creates optimised Shipments with carrier assignments and freight cost.

Create an Order Base:

An Order Base (Purchase Order) represents a buying commitment for a quantity of goods. Order Releases drawn from it represent shipments of specific quantities.

Order Management > Purchase Order > Order Base > New

Enter the following details for the TCRP scenario:

Tender Process

After Bulk Plan creates Shipments, the next step is to notify the carrier — this is called Tendering. The carrier receives the shipment details (pickup time, locations, equipment), then accepts or rejects the tender. If rejected, OTM automatically re-tenders to the next available carrier on the lane.

Shipment status after Bulk Plan:

When shipments are first created by Bulk Plan, their Secure Resources status is SECURE_RESOURCES_NOT_STARTED, meaning no tender has been sent yet.

Invoicing

Once shipment execution is completed, the carrier sends a freight charge invoice for settlement. OTM can validate the invoice cost against the planned shipment cost, approve it, and then allocate that cost back to the originating Order Releases or Purchase Orders.

The three steps are: Match → Approve → Allocate.

Invoice Matching:

A Match Rule identifies which shipment corresponds to an incoming carrier invoice, by comparing reference numbers and the Service Provider. In this scenario the invoice carries the Shipment ID (SID) as a reference number, which is matched to the same reference on the shipment record.