GTMS software and supporting resources are implemented using best practices in application development for building highly-scalable, highly-available, highly-secure cloud-based applications.
Agile
Our development process must anticipate frequent updates in order to maintain the level of carrier compliance that our partners and customers expect. For this reason, we follow an Agile development process, scheduling development sprints and releases as needed to stay compliant, building on capabilities to continually add value for our customers. The transportation industry is constantly changing/ evolving and therefore we must make sure we have constant review and prioritization of requests and changes that feed the development process.
Release Schedules
GTMS’s versioning is based on a Version. Revision. Patch numbering scheme. Patches are released as needed to correct any issues found within the software. Revisions are generally released at least once per quarter, but often monthly as carriers dictate changes. Revisions roll up the patches that were released in between the last revision and the current one and provide small feature enhancements or additions to the platform. Versions are reserved for major initiatives and happen maybe once or twice per year depending on the scope of functionality being planned in a particular year.
Maintenance Windows
Our multi-tenant cloud environment is architected to allow us to gradually update customer tenants. When updates are required, we announce maintenance windows at least 30 days ahead of time and schedule them for off hours (normally between a Saturday morning and Sunday evening) and for only the amount of time necessary to perform the update. We also look to avoid using a maintenance window during busy season(s)for our customers to ensure there is no impact to their businesses.
APIs
GTMS provides an XML interface that allows customers and third-party developers to perform transportation functions, such as ship, rate, route, and void. To ensure connectivity to the many disparate platforms we encounter in customer environments, GTMS’s interface is a simple HTTP(s) post of an XML document which results in an XML response message to the requestor. In addition to the functions noted above, there are many more, including but not limited to carbonization, rate shopping, time in transit, etc.
In addition, an API is also available f or administrative functions, allowing for other applications to execute configuration tasks that would otherwise be done using GTMS’s administrative application(s). The functions included allow you to add users, locations, carrier accounts, output configurations, and much more.
Integration Options
GTMS’s extensible architecture provides for options from the simplest integration, to the most complex. As noted above, there are standard APls for systems and developers who wish to integrate transportation functions within their applications. In addition, GTMS can perform real-time integration to other systems. One of the simplest being direct database connectivity for SQL Server, MYSQL, Oracle and others, making for quick and easy integration to databases. Pre built connectors to other systems like NetSuite, Prophet21 and Epicor allow for out-of-the-box integration to these systems. When these options aren’t sufficient, implementation resources can create custom connectors that plug into the platform in the same way as our standard options.
This makes for almost limitless options for integration.
Our HubCapp technology makes this, and more, possible whether GTMS is deployed on premise or hosted in the cloud. Further, it expands the capabilities allowing for integration to data that might be local on a user’s workstation (i.e. Excel spreadsheet) or devices such as scales, dimensioning hardware, and thermal printers.
Architecture
Using .Net and 115 technology, our software is comprised of the following web service components:
Composer
Composer is the presentation layer component of the platform that renders all applications to users. In addition, it provides Com poser Designer, enabling drag-and-drop tools to compose application and widget workflows, business rules, and applies user access rights.
Logistics Server
Logistics Server is the application layer component of the platform that manages transportation functions, connectivity to carriers and logistics service providers for automating rating, shipping, labeling, tracking, and other transportation and logistics functions.
HubCapp
HubCapp is an Internet of Things (loT) component that enables GTMS to connect and communicate in real-time from the cloud to local databases, applications, and other on premise enterprise data sources. HubCapp also integrates with local scales, thermal printers, meters, cameras, and mobile devices. Plug GTMS widgets into your web pages and HubCapp will enable secure page-to-page communication.
Stateless
GTMS is stateless and therefore no persistent connection is established. In addition, no executables or plug-ins are loaded into the browser, but depending on the configuration and functions enabled in the application(s) an executable/application may be loaded on the workstation for the purposes of printing to thermal printers, reading a scale or accessing meters.
