Logistics systems require large amounts of data, including information about locations, geography, service providers, rates, itineraries, as well as transactional data such as orders and shipment status. Much of this data comes from traditional Enterprise Resource Planning (ERP) systems; however, some of this information now comes from the internet. In either case, OTM uses the following tools and techniques for data integration:
XML-based business-to-business (B2B) integration
Support for XML and EDI-based integration for carrier and other partner communications
HTML to communicate with non-EDI, non-XML partners
Configurable, automated notification engine for intelligent alerting
Hosted data server for cleansing and downloading key internet data
OTM uses XML to integrate with other systems through several interfaces that perform inbound and outbound processing.
XML documents are sent to OTM using an integration tool such as WebMethods, via HTTPS over the Internet.
To send or receive interface transmissions, a programmer creates an XML schema that matches the GLogXML schema. GLogXML Schema is the format in which you send interface transmissions to OTM. Each type of interface transmission you want to send to OTM or receive from OTM has a specific XML schema that must be used. This documentation describes the information that must appear in a particular schema, defines the pieces of the different schemas, and lists the data that must already exist in OTM for the transmission to function properly.
You can read the Integration Guide online on the OTN website. Note that you can view the interface diagrams directly through the GLogXML.xsd file. They are not part of the Integration Guide.
An interface is a program that sends and receives properly formatted information from one application to another. OTM has separate interfaces that process different types of data. For example, the Transportation Orders interface (TransOrder) can import transportation order information from a foreign system into OTM. This type of interface is called inbound since data is imported into OTM. Outbound interfaces transmit data from OTM to other systems. For example, shipments planned in OTM can be exported to another system for additional processing.
To send and receive transmissions from OTM, you need to understand:
The underlying OTM database schema. This schema defines the data elements you want to import and export.
The rules that govern how OTM processes data.
How workflow can be used to automate interface processing in OTM.
The OTM XML schema defines the data elements that OTM sends or receives for each type of interface. Schema diagrams display the OTM data elements including their parent-child relationships. By viewing the schema, you can create XML documents (using data from other systems) that can be imported into OTM. Outbound data from OTM is saved in XML documents that follow the same schema.
The XML schema describes each element. The XML Element Dictionary contains definitions of each element to help you construct the appropriate XML documents.
There are two versions of the
GLog XML schema file to correspond to the different W3C schema standards
from 2000 and 2001. The GLogXML.xsd schema file conforms to the following
And the GLogXML-v2001.xsd schema file conforms to the following namespace:
Depending on the capabilities or constraints of your integration platform or utilities, you may be restricted to using one or the other.
In XML, you must create documents that follow the structure and rules of the OTM XML schema. The GLogXML.xsd file documents the OTM XML schema. We recommend that you use an XML management tool to view the GLogXML.xsd file and understand the OTM data elements and relationships.
The contents of the GlogXML.xsd file is subject to change as new versions of OTM are released. Contact Technical Support to ensure that you are using the appropriate file for constructing your interfaces.
The following is an example of an XML diagram with unexploded elements. Elements such as ShipmentHeader and ShipmentStop can be expanded to show the parent-child relationships to other elements in the schema.
A few basics to help you understand the diagram notations are shown below:
A question mark ( ? ) indicates that the element is optional
An asterisk ( * ) indicates 0 or more (optional)
A plus sign ( + ) indicates 1 or more (required)
A double sided arrow ( <-> ) indicates that the element has relationships to other elements
The following diagram shows a "branch" indicating a choice of one, but not both. For example, a Location Ref is either a Location GID (existing location information), or a Location (new location information), but not both.
An element with the following notation is a leaf. It is the lowest level element on the tree, and cannot be exploded any further.
GIDs are global identifiers that OTM uses to define various types of information (e.g., orders, shipments, locations, payment vouchers, etc.). A GID consists of the following three parts:
Domain name - Typically identifies a company, separates data and secures it from other data in a shared, Web-based environment. For example, if you are using OTM in an environment where many companies may be using the same OTM installation, the domain allows you to isolate data in OTM for each company. Therefore, many users from different companies can work in the same OTM installation (or Web site) and use data that is private and specific to their company. If you do not include a domain name in a GID, it can be viewed across all domains in your system.
External ID (XID) - The ID that defines the item on the external system. An external system is any system other than OTM.
XID qualifier - An optional element that provides a category for the XID. For example, the XID Qualifier may indicate that a particular XID is a Purchase Order.
You should not create GIDs with trailing spaces. These records will not be able to be looked up via the interface.
The transmission template wrapper takes plain XML and turns it into a valid OTM transmission. To send an actual shipment to OTM, it must include a wrapper surrounding the XML transmission. You can then send the actual shipment back to OTM.