--- title: How Systems Integrate with Oracle Transportation Management description: How external systems connect to Oracle OTM: GLogXML transmissions, HTTP POST, SOAP web services, the REST API, automation agents, and where EDI fits. canonical: https://otmdirectory.com/guides/otm-integration-methods updated: 2026-09-11 site: OTM Tools --- # How Systems Integrate with Oracle Transportation Management Almost every Oracle Transportation Management deployment ends up talking to something else. Orders arrive from an ERP, rates come from a carrier, tracking events flow in from a visibility platform, and freight invoices flow out to a payment provider. OTM offers several distinct mechanisms for those conversations, and they are not interchangeable. Choosing the wrong one is a common reason integrations become slow, brittle, or impossible to troubleshoot. This guide explains the main integration methods available in OTM and OTM Cloud: the GLogXML document format, the transports that carry it, the REST API, automation agents, and the role EDI translators and middleware play around the edges. It is written for the person who has to decide how two systems will actually exchange data. ## Key takeaways - GLogXML is OTM's native integration vocabulary; Transmission is the main inbound and outbound XML document, and most interfaces are ultimately a GLogXML document moving in one direction or the other. - The transport is a separate decision from the format: the same GLogXML can arrive by HTTP POST, by SOAP web service, or by manual upload through Integration Manager. - The REST API is resource-oriented and best for targeted reads and lightweight updates, not for high-volume document exchange. - Automation agents are not a transport; they are OTM reacting to its own events, and they are usually what triggers outbound integration. - EDI translators and iPaaS middleware sit outside OTM and exist to map partner formats into GLogXML and to add retry, monitoring, and orchestration. ## GLogXML: OTM's native document format GLogXML is the XML vocabulary OTM uses to describe its own objects: order releases, shipments, locations, items, invoices, and the rest. It is defined by a set of schemas, and the element that wraps everything is Transmission, described in the schema as the main inbound and outbound XML document. A Transmission carries a TransmissionHeader plus a body containing one or more transactions, so a single message can move a batch of related objects rather than one record at a time. The format is deliberately verbose. Each transaction identifies the object type, the action being taken, and the full set of fields being sent. That verbosity is what makes GLogXML self-describing and auditable, and it is also why high-volume interfaces need batching and compression thinking that a simple REST call does not. Acknowledgment is part of the design rather than an afterthought. TransmissionAck is a response to an inbound or outbound Transmission, and it is also supported as an inbound message in its own right, meaning an external system can acknowledge what OTM sent it, and OTM records that acknowledgment. If you are building anything where delivery matters, plan for the acknowledgment leg from the start. ## Getting GLogXML into OTM: HTTP POST, SOAP, and manual upload The format and the transport are separate choices. The most common transport is a plain HTTP POST of the XML document to the OTM application URL, which on OTM Cloud follows the provisioned pattern for your identity domain and data center. It is simple, it is stateless, and almost any system can produce it. OTM also exposes SOAP web services for the same purpose. The TransmissionService WSDL describes the contract, and callers supply a SOAP Action defined by that WSDL as part of the message. SOAP is the better fit when the calling platform already speaks it natively or when you need the formal contract for governance reasons; it carries more ceremony for no functional gain otherwise. Security is not optional on either path. Inbound web services default to a Web Service Security policy that requires a Username Token passed over HTTPS, so credentials and transport security need to be settled before any integration testing begins. There is also a manual route worth knowing: XML files can be uploaded directly through the Integration Manager user interface. Nobody should build a production interface on it, but it is genuinely useful for testing a new interface or diagnosing a functional problem that normally only occurs inside an automated flow. ## The REST API Alongside the transmission-based interfaces, OTM exposes a REST API organized around resources. Endpoints follow a predictable resource-and-identifier shape (a collection such as serviceParameters, and an individual record addressed by its GID) and support the query conventions you would expect: selecting fields, expanding related records, paging with limit and offset, ordering, filtering, and returning total counts. That design makes REST an excellent fit for targeted work. Looking up a single record, letting an application read reference data, powering a screen in a custom front end, or making a small update are all cleaner over REST than over a full transmission. It is a poor fit for bulk document exchange. Pushing thousands of order releases through per-record REST calls trades away the batching, acknowledgment, and error-handling structure that transmission-based integration gives you for free. The practical rule is that REST is for reading and touching individual records, while GLogXML transmissions are for moving business documents at volume. ## Automation agents: OTM reacting to its own events Automation agents are frequently described as an integration method, which is misleading but understandable. An agent is not a transport. Built in the Automation Agent Manager, a workflow agent listens for an OTM event, evaluates a user-defined condition, and then performs a sequence of actions when that condition is met. The reason agents belong in an integration discussion is that they are usually what decides when integration happens. A shipment reaching a particular status fires an event, an agent's condition confirms it is the right kind of shipment, and one of the agent's actions sends an outbound message to an external system. Without the agent, the data would sit in OTM waiting for someone to ask for it. This makes agents the piece most likely to be the real cause when an integration mysteriously does not fire. The transport is often fine and the document is often fine. The event never matched the condition. Anyone debugging an OTM interface should learn to read the agent before suspecting the network. ## Outbound integration and external systems Outbound traffic is configured around external system definitions that tell OTM where to send messages and how. Once that plumbing exists, agents and other processes can direct documents to it, and OTM tracks the outbound message volume and sizing per external system. Outbound processing supports receiving and processing synchronous responses to outbound messages, so a receiving system can return a functional acknowledgment in the same exchange rather than through a separate inbound interface. That is worth designing for, because it collapses a two-interface round trip into one. For testing, OTM provides an External System Servlet that emulates an HTTP POST to an external system. Pointing a test external system at that servlet on the same application server lets you exercise the full outbound path before the real endpoint exists, which is useful when the partner side of an integration is not ready yet, which is most of the time. ## Where EDI and middleware fit Neither EDI nor middleware is an OTM integration method in a strict sense. Both are things that sit outside OTM and translate into the methods above. Carriers and trading partners typically exchange standard EDI documents, ANSI X12 or EDIFACT, rather than GLogXML. A translator, whether run by a dedicated EDI provider or by your own middleware, converts between those partner formats and the GLogXML that OTM expects, and manages the partner-specific quirks that every trading relationship accumulates. The value of a specialist provider here is rarely the translation itself; it is the connectivity and the ongoing maintenance of dozens of partner maps. Middleware and iPaaS platforms serve a different need. OTM's interfaces are perfectly capable of point-to-point exchange, but they do not give you cross-system orchestration, centralized retry logic, unified monitoring across every interface, or a place to hold routing rules that span more than one application. Teams generally introduce middleware when the number of interfaces grows past the point where point-to-point connections can be reasoned about, not because OTM lacks a transport. ## Frequently asked questions ### What is GLogXML in Oracle OTM? GLogXML is the native XML format Oracle Transportation Management uses to represent its business objects, such as order releases, shipments, and invoices. The Transmission element is the main inbound and outbound document, wrapping a header and one or more transactions. Most OTM integrations are ultimately GLogXML documents moving into or out of the system. ### Should I use the OTM REST API or GLogXML transmissions? Use REST for targeted operations (reading a single record, retrieving reference data, or making a small update) where its resource-oriented endpoints and query parameters are a natural fit. Use GLogXML transmissions for moving business documents at volume, because they provide batching and a built-in acknowledgment model that per-record REST calls do not. ### How do external systems send data into OTM? The most common method is an HTTP POST of a GLogXML document to the OTM application URL. OTM also accepts the same documents through SOAP web services described by the TransmissionService WSDL. Inbound web services default to requiring a Username Token over HTTPS, so credentials and transport security must be configured first. XML files can also be uploaded manually through Integration Manager for testing. ### Are automation agents an integration method? Not strictly. An automation agent listens for an OTM event, checks a user-defined condition, and runs actions when it matches. Agents matter to integration because they usually determine when an outbound message is sent. When an interface fails to fire, the agent condition is often the cause rather than the transport. ### Do I need middleware to integrate with OTM? No. OTM's own interfaces support direct point-to-point integration. Middleware becomes worthwhile when you need orchestration across several systems, centralized retry and error handling, or unified monitoring of many interfaces at once. The decision is usually driven by the number of interfaces you maintain rather than by any gap in OTM. ### How does EDI work with OTM? Trading partners generally exchange standard EDI documents rather than GLogXML, so a translator converts between the two. That translation may run in a dedicated EDI provider's platform or in your own middleware. The ongoing work is rarely the translation itself but the maintenance of partner-specific maps and connectivity across many carrier relationships. --- Canonical: https://otmdirectory.com/guides/otm-integration-methods HTML version: https://otmdirectory.com/guides/otm-integration-methods