Implementation Guide
0 mins to read
MyGeotab API Adapter — Solution and Implementation Guide
Implementation Guide
0 mins to read
Learn more about the MyGeotab API Adapter, which allows streaming of data from the MyGeotab platform into external systems via the Geotab API. This is accomplished using the data feed, a highly-scalable incremental polling mechanism.
Solution and Implementation Guide
Latest Update: 2024-05-24
Table of Contents
Refer to the Change Log section for information about changes to the MyGeotab API Adapter solution and this document.
Streaming of data from the MyGeotab platform into external systems via the Geotab API is accomplished using the data feed - a lightweight and highly-scalable incremental polling mechanism. Building a full-scale integration typically involves utilizing numerous data feeds to pull various types of data from a MyGeotab database. There are many complexities inherent in developing a solid integration.
The MyGeotab API Adapter solution serves as both an example of proper integration via data feeds and the potential foundation for those seeking to develop new integrations with the Geotab platform. Essentially, it uses data feeds to pull the most common data sets from a MyGeotab database and stream the data into tables within a SQL Server, PostgreSQL or Oracle database; this could account for half the work in terms of a unidirectional integration where the data from the database is further processed for integration into an external system.
This document provides detailed information about the MyGeotab API Adapter solution along with instructions related to its deployment.
As detailed in the Database Maintenance section of this guide, the adapter database has been designed as a staging database, serving as an intermediary between the Geotab platform and the final repository where the extracted data will ultimately be stored for further processing and consumption by downstream applications.
The Data Optimizer is another application that takes the adapter solution to the next level, following the Suggested Strategy outlined in this guide. It migrates data from the adapter database into an “optimizer database” which can then be queried directly by applications. The Data Optimizer includes additional services that enhance the data and overcome certain challenges such as linking data points with different timestamps from different tables. For example, the StatusData and FaultData tables have added Latitude, Longitude, Speed, Bearing and Direction columns that can optionally be populated using LogRecords and interpolation techniques.
Full details pertaining to the Data Optimizer can be found in the MyGeotab API Adapter - Data Optimizer - Solution and Implementation Guide.
The following demonstration shows the near real-time flow of data into the adapter database. In this demo, the adapter output is shown on the left while a query to obtain record counts from certain tables in the adapter database is executed repeatedly on the right. A full-resolution version of this demo can be found here.
When contemplating a new MyGeotab integration, there are many potential options. This section identifies some key features of the MyGeotab API Adapter solution which may serve both to highlight the benefit of its use as well as to identify likely requirements for a new integration being built from scratch.
In contrast to starting a brand new integration from the ground up, the most obvious benefit of utilizing the adapter solution is that it’s already available and open source on GitHub. So, it can be used as-is, or modified as necessary to meet specific requirements. A custom-built solution will most likely need to incorporate many of the features that are built into the MyGeotab API Adapter. Thus, at a bare minimum, the solution can serve to demonstrate ways by which such requirements may be implemented.
Highlights of the MyGeotab API Adapter solution are as follows:
This section provides a quick summary of the steps required to download and deploy the MyGeotab API Adapter. While it is no substitute for all of the detail provided in this guide, the most important steps are highlighted and this section may serve as a high-level deployment checklist. Additionally, a demo video is provided to illustrate the deployment process and give developers an understanding of the inner workings of the solution.
✱ NOTE: The steps outlined below are for one of several possible ways the solution can be deployed. Information relating to other deployment possibilities can be found throughout this guide. For instance, the MyGeotab API Adapter can
The steps to download and deploy the latest release of the MyGeotab API Adapter in a Windows-based environment with SQL Server as the database are as follows:
1 | Download the latest release of the MyGeotab API Adapter from GitHub (i.e. following Steps 1-3 in the Using Published Release from GitHub section). The files to download are:
Once downloaded, extract the contents of the zip files. |
2 | Setup the database (following Steps 1-3 in the SQL Server database setup section):
|
3 | Configure and deploy the MyGeotab API Adapter application (following Steps 1-4 in the Deploy section):
✱ NOTE: In a production environment, it is best to setup a process to run the adapter using a system account. On a Windows Server, for example, Windows Task Scheduler can be used to create a task that runs MyGeotabAPIAdapter.exe on server startup. |
A step-by-step demo video has been created to assist those looking to get started quickly with the MyGeotab API Adapter. The following is a list of start times of various topics within the recording:
Start Time | Topic |
1:23 | Intro to the MyGeotab API Adapter |
5:41 | How to Download and Deploy a Published Release of the Adapter (with SQL Server) |
22:38 | Database Maintenance & Suggested Strategy |
25:40 | Understanding the Database Through Examples |
26:35 | Logging - Example Showing How to Use Logging to Debug a Configuration Issue |
31:15 | Download Source Code and Code Walk-Through (for developers) |
31:49 | Download/Clone the Git Repository |
33:54 | Open the Solution in Visual Studio |
35:07 | Solution Architecture |
37:12 | Application Logic |
39.06 | Code Walk-Through for Developers |
1:14:58 | Publishing the MyGeotab API Adapter |
1:18:18 | DVIRLog Manipulator (Bi-Directional Workflow) |
This section provides detailed information about the architecture, logic and data models of the MyGeotab API Adapter solution. Usage and deployment-related instructions can be found in the Solution Usage and Implementation section of this guide.
The following diagram provides an overview of the MyGeotab API Adapter solution architecture.
The solution consists of two components - the adapter and a database - both of which are deployed in the partner/reseller environment. The adapter is a collection of NET 8.0 Background Services (C#) that interface between the MyGeotab API and the database, essentially pulling data from the former and writing to tables in the latter. Each customer MyGeotab database must have a dedicated adapter and database pair; it is not possible to mix data from multiple MyGeotab databases. The Geotab partner/reseller is responsible for integrating between the database and partner/reseller databases/applications - potentially with assistance from a third-party solutions integrator.
Out-of-the-box, the MyGeotab API Adapter supports SQL Server, PostgreSQL and Oracle for use as the adapter database into which data retrieved via the MyGeotab API is written. The solution uses a repository pattern and an Object-Relational Mapper - Dapper ORM - making it easy to add support for different types of databases. See the Adding Support for Other Database Types section for specifics.
The following table lists all of the tables contained in the database along with descriptions that include the associated MyGeotab API objects, where applicable. Further detail relating to the structure and fields of individual tables can be found in the Data Dictionary section.
✱ NOTE: Each table is assigned to one of the following categories:
WARNING! It is possible for the database to grow very large very quickly, resulting in potential disk space and performance issues. In particular, the feed data tables can accumulate vast quantities of records within short periods of time. See the Database Maintenance section for more information.
Table Name | Category | Description |
Feed data | Contains data corresponding to MyGeotab BinaryData objects. | |
Feed data | Contains data corresponding to MyGeotab ChargeEvent objects. | |
Reference data | Contains data corresponding to MyGeotab Condition objects. | |
Feed data | Contains data corresponding to MyGeotab DebugData objects. | |
Reference data | Contains data corresponding to MyGeotab Device objects. | |
Reference data | Contains data corresponding to MyGeotab DeviceStatusInfo objects. | |
Reference data | Contains data corresponding to MyGeotab Diagnostic objects. | |
Feed data | Contains data corresponding to MyGeotab DriverChange objects. | |
Reference data | Contains data corresponding to MyGeotab DutyStatusAvailability objects. | |
Feed data | Contains data corresponding to MyGeotab DutyStatusLog objects. | |
Reference data | Contains data corresponding to MyGeotab DefectRemark objects. | |
Reference data | Contains data corresponding to defects associated with DVIRLogs. It includes data derived from MyGeotab DVIRLog, DVIRDefect, Defect and Group objects. | |
Commands | May be used to send DVIRDefect updates to the MyGeotab database with which the adapter is configured to communicate. See the DVIRLog Manipulator section for more information. | |
Feed data | Contains data corresponding to MyGeotab DVIRLog objects. | |
Feed data | Contains data corresponding to MyGeotab ExceptionEvent objects. | |
Command exceptions | Contains copies of any records that were inserted into the DVIRDefectUpdates table and did not result in successful updates of DVIRDefects in the MyGeotab database. The FailureMessage column provides details about the reason why a given command failed. See the DVIRLog Manipulator section for more information. | |
Feed data | Contains data corresponding to MyGeotab FaultData objects. | |
Feed data | Contains data corresponding to MyGeotab LogRecord objects. | |
System info | Contains software version information (obtained from MyGeotab API VersionInformation) about the MyGeotab server and database that the subject adapter database is associated with via the MyGeotab API Adapter. | |
System info | System table used by the MyGeotab API Adapter. | |
Reference data | Contains data corresponding to MyGeotab Rule objects. | |
Feed data | Contains data corresponding to MyGeotab StatusData objects. | |
Feed data | Contains data corresponding to MyGeotab Trip objects. | |
Reference data | Contains data corresponding to MyGeotab User objects. | |
Reference data | Contains data corresponding to MyGeotab ZoneType objects. | |
Reference data | Contains data corresponding to MyGeotab Zone objects. |
SQL Server is the main supported database and any database-specific references such as data types will relate to the SQL Server version of the schema. For information such as schema details related to other supported database types, refer to the Database Setup section. The tables and views included in the adapter database schema are detailed in the following subsections.
Most of the tables in the adapter database have “GeotabId” and “id” columns.
The GeotabId is the unique identifier for the specific Entity object in the Geotab system; it must be used when relating objects to each other or back to the Geotab system. For example the DeviceId in the LogRecords table is associated with the GeotabId in the Devices table.
The id is the unique identifier for the record in the adapter database table and is entirely unrelated to the Geotab system. It is of bigint data type, indexed and defined as the primary key. Its purpose is to allow downstream processes to delete records (from the feed data tables) as part of the suggested strategy while maintaining optimal performance and avoiding database concurrency/contention issues that could arise (if the GeotabId were to be used) when trying to delete records while the adapter is actively inserting/updating records.
The BinaryData table contains data corresponding to MyGeotab BinaryData objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
BinaryType | nvarchar(50) | Yes | The BinaryDataType. |
ControllerId | nvarchar(50) | No | The Id of the Controller associated with the subject BinaryData. |
Data | nvarchar(1024) | No | The binary data for the subject BinaryData object. |
DateTime | datetime2(7) | Yes | The date and time of the logging of the data. |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject BinaryData. |
Version | nvarchar(50) | Yes | The version of the entity. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The ChargeEvents table contains data corresponding to MyGeotab ChargeEvent objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ChargeIsEstimated | bit | No | Indicates whether the charge values were estimated. |
ChargeType | nvarchar(50) | No | The ChargeType provided by the external power source. |
StartTime | datetime2(7) | No | The date and time at which the ChargeEvent started. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject ChargeEvent. |
DurationTicks | bigint | No | The length of time the vehicle was charging as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
EndStateOfCharge | float | Yes | The ending state of charge for this ChargeEvent. |
EnergyConsumedKwh | float | Yes | The energy consumed during the ChargeEvent. |
EnergyUsedSinceLastChargeKwh | float | Yes | The amount of energy drawn from the battery since the last ChargeEvent. |
Latitude | float | Yes | The latitude of the location where the ChargeEvent occurred. |
Longitude | float | Yes | The longitude of the location where the ChargeEvent occurred. |
MaxACVoltage | float | Yes | The maximum AC Voltage over the ChargeEvent. |
MeasuredBatteryEnergyInKwh | float | Yes | The amount of energy in measured during charging. |
MeasuredBatteryEnergyOutKwh | float | Yes | The amount of energy out measured during charging. |
MeasuredOnBoardChargerEnergyInKwh | float | Yes | The total amount of energy in measured on board during charging. |
MeasuredOnBoardChargerEnergyOutKwh | float | Yes | The total amount of energy out measured on board during charging. |
PeakPowerKw | float | Yes | The peak power used during the ChargeEvent. |
StartStateOfCharge | float | Yes | The starting state of charge for this ChargeEvent. |
TripStop | datetime2(7) | Yes | The time of the Trip.Stop from the Trip this ChargeEvent occurred in. |
Version | bigint | No | The version of the entity. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The Conditions table contains data corresponding to MyGeotab Condition objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ParentId | nvarchar(50) | Yes | The Id of the parent Condition, if the subject Condition has a parent. |
RuleId | nvarchar(50) | Yes | The Id of the Rule (in the Rules table), with which the subject Condition is associated. |
ConditionType | nvarchar(50) | No | The ConditionType of the subject Condition. |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject Condition. |
DiagnosticId | nvarchar(100) | Yes | The Id of the Diagnostic associated with the subject Condition. |
DriverId | nvarchar(50) | Yes | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject Condition. |
Value | float | Yes | The specified value that the subject Condition evaluates against. |
WorkTimeId | nvarchar(50) | Yes | The Id of the WorkTime that the event must occur inside/outside of for the violation to occur. |
ZoneId | nvarchar(50) | Yes | The Id of the Zone associated with the subject Condition. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DebugData table contains data corresponding to MyGeotab DebugData objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
Data | nvarchar(max) | No | The binary data for the subject DebugData object. |
DateTime | datetime2(7) | Yes | The date and time of the logging of the data. |
DebugReasonId | bigint | Yes | The numeric value of the enumerator representing the reason for the DebugData record. Used for troubleshooting/debugging purposes only. |
DebugReasonName | nvarchar(255) | Yes | The alphanumeric value of the enumerator representing the reason for the DebugData record. Used for troubleshooting/debugging purposes only. |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject DebugData. |
DriverId | nvarchar(50) | Yes | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject DebugData. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The Devices table contains data corresponding to MyGeotab Device objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ActiveFrom | datetime2(7) | Yes | The date the device is active from. |
ActiveTo | datetime2(7) | Yes | The date the device is active to. |
Comment | nvarchar(1024) | Yes | Free text field where any user information can be stored and referenced for this entity. |
DeviceType | nvarchar(50) | No | Specifies the GO or Custom DeviceType. |
LicensePlate | nvarchar(50) | Yes | The vehicle license plate details of the vehicle associated with the device. |
LicenseState | nvarchar(50) | Yes | The state or province of the vehicle associated with the device. |
Name | nvarchar(100) | No | The display name assigned to the device. |
ProductId | int | Yes | The product Id. Each device is assigned a unique hardware product Id. |
SerialNumber | nvarchar(12) | Yes | The serial number of the device. |
VIN | nvarchar(50) | Yes | The Vehicle Identification Number (VIN) of the vehicle associated with the device. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DeviceStatusInfo table contains data corresponding to MyGeotab DeviceStatusInfo objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
Bearing | float | No | The bearing (heading) in int degrees. Valued between 0 and 359 inclusive. 0 represents North, 90 represents East, and so on. -1 represents unknown bearing. |
CurrentStateDuration | nvarchar(50) | No | The duration between the last Trip state change (i.e. driving or stop), and the most recent date of location information. |
DateTime | datetime2(7) | No | The most recent DateTime of the latest piece of status, GPS or fault data. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject DeviceStatusInfo. |
DriverId | nvarchar(50) | No | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject DeviceStatusInfo. |
IsDeviceCommunicating | bit | No | A value indicating whether the Device is communicating. |
IsDriving | bit | No | A value indicating whether the current Device state. If set true, is driving. Otherwise, it is stopped. |
IsHistoricLastDriver | bit | No | Indicates whether the Device has been assigned to "UnknownDriver" and the last Trip Driver is represented in the DriverId column. |
Latitude | float | No | The last known latitude of the Device. |
Longitude | float | No | The last known longitude of the Device. |
Speed | real | No | The current vehicle speed (in km/h). NaN represents an invalid speed. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The Diagnostics table contains data corresponding to MyGeotab Diagnostic objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(100) | No | The unique identifier for the specific Entity object in the Geotab system. |
GeotabGUID | nvarchar(100) | No | The underlying Globally Unique Identifier (GUID) of the Diagnostic. In the event that the GeotabId changes as a result of the assignment of a KnownId, this GeotabGUID will remain unchanged and can be used for reconciliation of Diagnostic Ids in any downstream integrations. |
HasShimId | boolean | No | Indicates whether the Diagnostic is one that has a KnownId on the MyGeotab server side, but is unknown in the MyGeotab .NET API client (Geotab.Checkmate.ObjectModel NuGet package) used at the time of download. |
FormerShimGeotabGUID | nvarchar(100) | Yes | If there is an earlier version of the Diagnostic where HasShimId is true, this value lists the GeotabGUID of that earlier Diagnostic so that the two, along with any associated data, can be logically related. |
ControllerId | nvarchar(100) | No | The Id of the Controller related to the diagnostic; if applicable. |
DiagnosticCode | int | Yes | The diagnostic parameter code number. |
DiagnosticName | nvarchar(255) | No | The name of this entity that uniquely identifies it and is used when displaying this entity. |
DiagnosticSourceId | nvarchar(50) | No | The Id of the Source of the Diagnostic. |
DiagnosticSourceName | nvarchar(255) | No | The Name of the Source of the Diagnostic. |
DiagnosticUnitOfMeasureId | nvarchar(50) | No | The Id of the UnitOfMeasure used by the Diagnostic. |
DiagnosticUnitOfMeasureName | nvarchar(255) | No | The Name of the UnitOfMeasure used by the Diagnostic. |
OBD2DTC | nvarchar(50) | Yes | The OBD-II Diagnostic Trouble Code (DTC), if the Diagnostic is from an OBD Source. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DriverChanges table contains data corresponding to MyGeotab DriverChange objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
DateTime | datetime2(7) | No | The date and time of the driver change. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject DriverChange. |
DriverId | nvarchar(50) | No | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject DriverChange. |
Type | nvarchar(50) | No | The DriverChangeType. |
Version | bigint | No | The version of the entity. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The DutyStatusAvailabilities table contains data corresponding to MyGeotab DutyStatusAvailability objects. Return to List of Tables.
WARNING! Duration values in the DutyStatusAvailability table are inaccurate (out-of-date). The amount of inaccuracy can be defined as the duration between the value of the RecordLastChangedUtc field and the current time, in Coordinated Universal Time (UTC). This offset must be applied to the duration values in order to improve currency of the data upon consumption. See the Maintaining Currency of Values Via Time Offsets section for more information.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
DriverId | nvarchar(50) | No | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject DutyStatusAvailability record. |
CycleAvailabilities | nvarchar(max) | Yes | Cycle available to the driver in the future. Presented in the form of a JSON array (e.g. [{"DateTime":"2021-01-14T05:00:00Z","Available":"00:00:00"},{"DateTime":"2021-01-15T05:00:00Z","Available":"00:00:00"},{"DateTime":"2021-01-16T05:00:00Z","Available":"00:00:00"},{"DateTime":"2021-01-17T05:00:00Z","Available":"00:00:00"},{"DateTime":"2021-01-18T05:00:00Z","Available":"20:18:55.6430000"},{"DateTime":"2021-01-19T05:00:00Z","Available":"1.20:18:55.6430000"},{"DateTime":"2021-01-20T05:00:00Z","Available":"2.12:00:00"}]). |
CycleTicks | bigint | Yes | The duration of cycle hours left as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
CycleRestTicks | bigint | Yes | The duration left before cycle rest must be taken. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
DrivingTicks | bigint | Yes | The duration left for driving. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
DutyTicks | bigint | Yes | The duration of total on-duty time left in the day. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
DutySinceCycleRestTicks | bigint | Yes | The duty hours left since Cycle Rest. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
Is16HourExemptionAvailable | bit | Yes | Indicates whether 16 hour exemption is available. |
IsAdverseDrivingExemptionAvailable | bit | Yes | Indicates whether adverse driving exemption is available. |
IsOffDutyDeferralExemptionAvailable | bit | Yes | Indicates whether off-duty deferral exemption is available. |
Recap | nvarchar(max) | Yes | Chronological array representing each day's On-duty time since the beginning of cycle. Presented in the form of a JSON array (e.g. [{"DateTime":"2021-01-07T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-08T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-09T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-10T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-11T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-12T05:00:00Z","Duration":"1.00:00:00"},{"DateTime":"2021-01-13T05:00:00Z","Duration":"15:41:04.3570000"}]). |
RestTicks | bigint | Yes | The duration left before rest break must be taken. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
WorkdayTicks | bigint | Yes | The duration of workday left in a day. Workday is a consecutive window that begins with first on-duty. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DutyStatusLogs table contains data corresponding to MyGeotab DutyStatusLog objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
Annotations | nvarchar(max) | Yes | The list of AnnotationLog(s) which are associated with this log. |
CoDrivers | nvarchar(max) | Yes | The list of the co-driver User(s) (in the Devices table) for this log. |
DateTime | datetime2(7) | No | The date and time the log was created. |
DeferralMinutes | int | Yes | The deferral minutes. |
DeferralStatus | nvarchar(50) | Yes | |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject DutyStatusLog. |
DistanceSinceValidCoordinates | real | Yes | The distance since last valid coordinate measurement. |
DriverId | nvarchar(50) | Yes | The Id of the User (corresponding to the Id in the Users table) who created this log. |
EditDateTime | datetime2(7) | Yes | The date and time the log was edited. If the log has not been edited, this will not be set. |
EditRequestedByUserId | nvarchar(50) | Yes | The Id of the User (corresponding to the Id in the Users table) that requested an edit to this log. |
EngineHours | float | Yes | The engine hours for the DeviceId at the DateTime of this log. The unit is seconds (not hours). |
EventCheckSum | bigint | Yes | The event checksum of this log. |
EventCode | int | Yes | The event code of this log (Table 6; 7.20 of the ELD Final Rule). |
EventRecordStatus | int | Yes | The record status number of this log 1 = active 2 = inactive - changed 3 = inactive - change requested 4 = inactive - change rejected. |
EventType | int | Yes | The event type number of this log 1 = A change in driver's duty-status 2 = An intermediate log 3 = A change in driver's indication of authorized personal use of CMV or yard moves 4 = A driver's certification/recertification of records 5 = A driver's login/logout activity 6 = CMV's engine power up / shut down activity 7 = A malfunction or data diagnostic detection occurrence (Table 6; 7.25 of the ELD Final Rule). |
IsHidden | bit | Yes | Indicates whether the log is hidden. |
IsIgnored | bit | Yes | If the log is ignored. True means it will not affect the Driver's HOS availability. |
IsTransitioning | bit | Yes | A value indicating whether the log is in transitioning state. |
Location | nvarchar(max) | Yes | An object with the location information for the log data. |
LocationX | float | Yes | The longitude of the Location. |
LocationY | float | Yes | The latitude of the Location. |
Malfunction | nvarchar(50) | Yes | The DutyStatusMalfunctionTypes of this DutyStatusLog record. As a flag it can be both a diagnostic and malfunction state which is used to mark status based records (e.g. "D", "SB") as having a diagnostic or malfunction present at time of recording. |
Odometer | float | Yes | The odometer in metres for the DeviceId at the DateTime of this log. |
Origin | nvarchar(50) | Yes | The DutyStatusOrigin from where this log originated |
ParentId | nvarchar(50) | Yes | The Id of the parent DutyStatusLog. Used when a DutyStatusLog is edited. When returning history, this field will be populated. |
Sequence | bigint | Yes | The sequence number, which is used to generate the sequence ID. |
State | nvarchar(50) | Yes | The DutyStatusState of the DutyStatusLog record. |
Status | nvarchar(50) | Yes | The DutyStatusLogType representing the driver's duty status. |
UserHosRuleSet | nvarchar(max) | Yes | The linked UserHosRuleSet. Only used to link rulesets to log events that affect the driver's operating zone and/or cycle. (Canadian ELD) |
VerifyDateTime | datetime2(7) | Yes | The date and time the log was verified. If the log is unverified, this will not be set. |
Version | bigint | No | The version of the entity. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The DVIRDefectRemarks table contains data corresponding to MyGeotab DefectRemark objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
DVIRDefectId | nvarchar(50) | No | The Id of the DVIRDefect (in the DVIRDefects table) that the remark applies to. |
DateTime | datetime2(7) | Yes | The date and time the remark was created. |
Remark | nvarchar(max) | No | The remark text. |
RemarkUserId | nvarchar(50) | Yes | The Id of the User (in the Users table) who created the remark. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DVIRDefects table contains data corresponding to defects associated with DVIRLogs. It includes data derived from MyGeotab DVIRLog, DVIRDefect, Defect and Group objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the DVIRDefect object in the Geotab system. |
DVIRLogId | nvarchar(50) | No | The Id of the DVIRLog (in the DVIRLogs table) with which the subject DVIRDefect is associated. |
DefectListAssetType | nvarchar(50) | Yes | The asset type of the defect list. |
DefectListId | nvarchar(50) | Yes | The Id of the defect list (Group) that the defect belongs to. |
DefectListName | nvarchar(255) | Yes | The Name of the defect list (Group) that the defect belongs to. |
PartId | nvarchar(50) | Yes | The Id of the part (Group) that has the defect. |
PartName | nvarchar(255) | Yes | The Name of the part (Group) that has the defect. |
DefectId | nvarchar(50) | Yes | The Id of the Defect. |
DefectName | nvarchar(255) | Yes | The Name of the Defect. |
DefectSeverity | nvarchar(50) | Yes | The DefectSeverity of the Defect. |
RepairDateTime | datetime2(7) | Yes | The date and time the DVIRDefect was repaired. |
RepairStatus | nvarchar(50) | Yes | The RepairStatusType of this DVIRDefect. |
RepairUserId | nvarchar(50) | Yes | The Id of the User (in the Users table) who repaired this DVIRDefect. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The DVIRDefectUpdates table may be used to send DVIRDefect updates to the MyGeotab database with which the adapter is configured to communicate. If a record is inserted into this table and it fails to result in the subject DVIRDefect update being propagated to the MyGeotab database, a copy of the record will be inserted into the FailedDVIRDefectUpdates table and the reason for the failure will be provided in the FailureMessage column. Once a record has been processed, it will be deleted from the DVIRDefectUpdates table. For more detail, refer to the DVIRLog Manipulator section of this guide. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
DVIRLogId | nvarchar(50) | No | The Id of the DVIRLog with which the subject DVIRDefect is associated. |
DVIRDefectId | nvarchar(50) | No | The Id of the DVIRDefect that is to be updated in the Geotab system. |
RepairDateTime | datetime2(7) | Yes | The date and time the DVIRDefect was repaired. |
RepairStatus | nvarchar(50) | Yes | The RepairStatusType of this DVIRDefect. |
RepairUserId | nvarchar(50) | Yes | The Id of the User who repaired this DVIRDefect. |
Remark | nvarchar(max) | Yes | The remark text. |
RemarkDateTime | datetime2(7) | Yes | The date and time the remark was created. |
RemarkUserId | nvarchar(50) | Yes | The Id of the User who created the remark. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The DVIRLogs table contains data corresponding to MyGeotab DVIRLog objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
CertifiedByUserId | nvarchar(50) | Yes | The Id of the User (in the Users table) who certified the repairs (or comments, if no repairs were made) to the Device or Trailer. |
CertifiedDate | datetime2(7) | Yes | The date and time that the Device or Trailer was certified. |
CertifyRemark | nvarchar(max) | Yes | The remark recorded by the User who certified the repairs (or no repairs made) to the Device or Trailer. |
DateTime | datetime2(7) | No | The date and time the log was created. |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject DVIRLog. |
DriverId | nvarchar(50) | Yes | The Id of the User (in the Users table) who created the log. |
DriverRemark | nvarchar(max) | Yes | The remark recorded by the driver for this log. |
IsSafeToOperate | bit | Yes | Indicates whether the Device or Trailer was certified as safe to operate. |
LocationLatitude | float | Yes | The latitude of the location of the log. |
LocationLongitude | float | Yes | The longitude of the location of the log. |
LogType | nvarchar(50) | Yes | The DVIRLogType of the log. |
RepairDate | datetime2(7) | Yes | |
RepairedByUserId | nvarchar(50) | Yes | The Id of the User (in the Users table) who repaired the Device or Trailer. |
TrailerId | nvarchar(50) | Yes | The Id of the Trailer associated with the log. |
TrailerName | nvarchar(255) | Yes | The Name of the Trailer associated with the log. |
Version | bigint | No | The version of the entity. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The ExceptionEvents table contains data corresponding to MyGeotab ExceptionEvent objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ActiveFrom | datetime2(7) | Yes | The start date and time of the ExceptionEvent; at or after this date and time. |
ActiveTo | datetime2(7) | Yes | The end date and time of the ExceptionEvent; at or before this date and time. |
DeviceId | nvarchar(50) | Yes | The Id of the Device (in the Devices table) associated with the subject ExceptionEvent. |
Distance | real | Yes | The distance (in KMs) travelled since the start of the ExceptionEvent. |
DriverId | nvarchar(50) | Yes | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject ExceptionEvent. |
DurationTicks | bigint | Yes | The duration of the ExceptionEvent as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
LastModifiedDateTime | datetime2(7) | No | The last time this ExceptionEvent was updated (in the MyGeotab database). |
RuleId | nvarchar(50) | Yes | The Id of the Rule (corresponding to the Id in the Rules table) that was broken to trigger the subject ExceptionEvent. |
State | int | No | The ExceptionEventState of the subject ExceptionEvent. 0 = Valid. 1 = Invalid. 2 = Dismissed. |
Version | bigint | Yes | The version of the entity. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The FailedDVIRDefectUpdates table is associated with the DVIRDefectUpdates table. If a row is inserted into the DVIRDefectUpdates table and it does not pass data validation checks, or if an exception occurs when the adapter attempts to execute the command, a copy of the original row in the DVIRDefectUpdates table will be added to the FailedDVIRDefectUpdates table along with the related error message which will appear in the FailureMessage column. For more detail, refer to the DVIRLog Manipulator section of this guide. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
DVIRDefectUpdateId | bigint | No | The value of the id field for the original row in the DVIRDefectUpdates table that resulted in the failure. |
DVIRLogId | nvarchar(50) | No | The Id of the DVIRLog with which the subject DVIRDefect is associated. |
DVIRDefectId | nvarchar(50) | No | The Id of the DVIRDefect that was to be updated in the Geotab system. |
RepairDateTime | datetime2(7) | Yes | The date and time the DVIRDefect was repaired. |
RepairStatus | nvarchar(50) | Yes | The RepairStatusType of this DVIRDefect. |
RepairUserId | nvarchar(50) | Yes | The Id of the User who repaired this DVIRDefect. |
Remark | nvarchar(max) | Yes | The remark text. |
RemarkDateTime | datetime2(7) | Yes | The date and time the remark was created. |
RemarkUserId | nvarchar(50) | Yes | The Id of the User who created the remark. |
FailureMessage | nvarchar(max) | Yes | The reason why this record failed to result in an update of the subject DVIRDefect in the MyGeotab database. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The FaultData table contains data corresponding to MyGeotab FaultData objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
AmberWarningLamp | bit | Yes | Indicates whether the amber warning lamp is on. |
ClassCode | nvarchar(50) | Yes | The DtcClass code of the fault. |
ControllerId | nvarchar(100) | No | The Id of the Controller related to the fault code; if applicable. |
ControllerName | nvarchar(255) | Yes | The Name of the Controller related to the fault code; if applicable. |
Count | int | No | The number of times the fault occurred. |
DateTime | datetime2(7) | Yes | The date and time at which the event occurred. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject FaultData. |
DiagnosticId | nvarchar(100) | No | The Id of the Diagnostic (in the Diagnostics table) associated with the subject FaultData. |
DismissDateTime | datetime2(7) | Yes | The date and time that the fault was dismissed. |
DismissUserId | nvarchar(50) | Yes | The Id of the User (in the Users table) associated with the subject FaultData entity. |
FailureModeCode | int | Yes | The Failure Mode Identifier (FMI) associated with the FailureMode. |
FailureModeId | nvarchar(50) | No | The Id of the FailureMode associated with the subject FaultData entity. |
FailureModeName | nvarchar(255) | Yes | The Name of the FailureMode associated with the subject FaultData entity. |
FaultLampState | nvarchar(50) | Yes | The FaultLampState of a J1939 vehicle. |
FaultState | nvarchar(50) | Yes | The FaultState code from the engine system of the specific device. |
MalfunctionLamp | bit | Yes | Indicates whether the malfunction lamp is on. |
ProtectWarningLamp | bit | Yes | Indicates whether the protect warning lamp is on. |
RedStopLamp | bit | Yes | Indicates whether the red stop lamp is on. |
Severity | nvarchar(50) | Yes | The DtcSeverity of the fault. |
SourceAddress | int | Yes | The source address for enhanced faults. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The LogRecords table contains data corresponding to MyGeotab LogRecord objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
DateTime | datetime2(7) | No | The date and time the log was recorded. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject LogRecord. |
Latitude | float | No | The latitude of the log record. |
Longitude | float | No | The longitude of the log record. |
Speed | real | No | The logged speed or an invalid speed (in km/h). |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The MyGeotabVersionInfo table contains software version information (obtained from MyGeotab API VersionInformation) about the MyGeotab server and database that the subject adapter database is associated with via the MyGeotab API Adapter. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
DatabaseName | nvarchar(58) | No | The name of the MyGeotab database. |
Server | nvarchar(50) | No | The server on which the MyGeotab database resides. |
DatabaseVersion | nvarchar(50) | No | The current version of the MyGeotab databases on the server. |
ApplicationBuild | nvarchar(50) | No | The MyGeotab application build. |
ApplicationBranch | nvarchar(50) | No | The MyGeotab application branch. |
ApplicationCommit | nvarchar(50) | No | The MyGeotab application commit. |
GoTalkVersion | nvarchar(50) | No | The Text to Speech firmware version provided by the server. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The OServiceTracking table is a system table used by the MyGeotab API Adapter. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
ServiceId | nvarchar(50) | No | An identifier for the subject service. |
AdapterVersion | nvarchar(50) | Yes | The version of the MyGeotab API Adapter that the subject service is a part of. |
AdapterMachineName | nvarchar(100) | Yes | The name of the machine/server that is hosting the MyGeotab API Adapter instance that the subject service is a part of. |
EntitiesLastProcessedUtc | datetime2(7) | Yes | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject service processed any entities (data). |
LastProcessedFeedVersion | bigint | Yes | If applicable and the subject service uses the GetFeed method, the ToVersion of the last batch of records retrieved by the subject service. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The Rules table contains data corresponding to MyGeotab Rule objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ActiveFrom | datetime2(7) | Yes | Start date and time of the Rule's notification activity period. |
ActiveTo | datetime2(7) | Yes | End date and time of the Rule's notification activity period. |
BaseType | nvarchar(50) | Yes | The ExceptionRuleBaseType of the Rule. |
Comment | nvarchar(max) | Yes | Free text field where any user information can be stored and referenced for this entity. |
Name | nvarchar(255) | Yes | The name of the rule entity that uniquely identifies it and is used when displaying this entity. |
Version | bigint | No | The version of the entity. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The StatusData table contains data corresponding to MyGeotab StatusData objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
Data | float | Yes | The recorded value of the diagnostic parameter. |
DateTime | datetime2(7) | Yes | The date and time of the logged event. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject StatusData. |
DiagnosticId | nvarchar(100) | No | The Id of the Diagnostic (in the Diagnostics table) associated with the subject StatusData. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The Trips table contains data corresponding to MyGeotab Trip objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
AfterHoursDistance | real | Yes | The distance the vehicle was driven after work hours (in km). |
AfterHoursDrivingDurationTicks | bigint | Yes | The duration the vehicle was driven after work hours as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
AfterHoursEnd | bit | Yes | Whether the trip ends after hours. |
AfterHoursStart | bit | Yes | Whether the trip starts after hours. |
AfterHoursStopDurationTicks | bigint | Yes | The duration the vehicle was stopped after work hours as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
AverageSpeed | real | Yes | Average speed in km/h. This only includes the average speed while driving. |
DeviceId | nvarchar(50) | No | The Id of the Device (in the Devices table) associated with the subject Trip. |
Distance | real | No | The distance the vehicle was driven during the trip (in km). |
DriverId | nvarchar(50) | No | The Id of the Driver (corresponding to the Id in the Users table) associated with the subject Trip. |
DrivingDurationTicks | bigint | No | The duration between the start and stop of the trip as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
IdlingDurationTicks | bigint | Yes | Total end-of-trip idling (idling is defined as speed being 0 with ignition on). It is calculated from the beginning of the current trip to the beginning of the next trip. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
MaximumSpeed | real | Yes | The maximum speed of the vehicle during this trip (in km/h). |
NextTripStart | datetime2(7) | No | The start date and time of the next trip. |
SpeedRange1 | int | Yes | The number of incidents where the vehicle reached the first range of speeding triggers. |
SpeedRange1DurationTicks | bigint | Yes | The duration where the vehicle drove in the first range of speeding triggers as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
SpeedRange2 | int | Yes | The number of incidents where the vehicle reached the second range of speeding triggers. |
SpeedRange2DurationTicks | bigint | Yes | The duration where the vehicle drove in the second range of speeding triggers as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
SpeedRange3 | int | Yes | The number of incidents where the vehicle reached the third range of speeding triggers. |
SpeedRange3DurationTicks | bigint | Yes | The duration where the vehicle drove in the third range of speeding triggers as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
Start | datetime2(7) | No | The date and time that the trip started. |
Stop | datetime2(7) | No | The date and time the trip stopped. |
StopDurationTicks | bigint | No | The duration the vehicle was stopped at the end of the trip. This also includes any idling done at the end of a trip. Measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
StopPointX | float | Yes | The longitude of the Coordinate at which the Trip stopped. |
StopPointY | float | Yes | The latitude of the Coordinate at which the Trip stopped. |
WorkDistance | real | Yes | The distance the vehicle was driven during work hours (in km). |
WorkDrivingDurationTicks | bigint | Yes | The duration the vehicle was driven during work hours as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
WorkStopDurationTicks | bigint | Yes | The duration the vehicle was stopped during work hours as measured in ticks. A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. |
RecordCreationTimeUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating when the subject record was added to the adapter database. |
The Users table contains data corresponding to MyGeotab User objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ActiveFrom | datetime2(7) | No | The date the user is active from. |
ActiveTo | datetime2(7) | No | The date the user is active to. |
EmployeeNo | nvarchar(50) | Yes | The employee number or external identifier. |
FirstName | nvarchar(255) | Yes | The first name of the user. |
HosRuleSet | nvarchar(255) | Yes | The HosRuleSet the user follows. Default: None. |
IsDriver | bit | No | Indicates whether the user is classified as a driver. |
LastAccessDate | datetime2(7) | Yes | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject user accessed the MyGeotab system. |
LastName | nvarchar(255) | Yes | The last name of the user. |
Name | nvarchar(255) | No | The user's email address / login name. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The ZoneTypes table contains data corresponding to MyGeotab ZoneType objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(100) | No | The unique identifier for the specific Entity object in the Geotab system. |
Comment | nvarchar(255) | Yes | A free text field where any user information can be stored and referenced for this entity. |
Name | nvarchar(255) | No | The name of this entity that uniquely identifies it and is used when displaying this entity. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
The Zones table contains data corresponding to MyGeotab Zone objects. Return to List of Tables.
Field Name | Data Type | Nullable | Description |
id | bigint | No | The unique identifier for the record in the adapter database table. Entirely unrelated to the Geotab system. |
GeotabId | nvarchar(50) | No | The unique identifier for the specific Entity object in the Geotab system. |
ActiveFrom | datetime2(7) | Yes | The date the zone is active from. |
ActiveTo | datetime2(7) | Yes | The date the zone is active to. |
CentroidLatitude | float | Yes | The latitude of the geographic centre of the zone. |
CentroidLongitude | float | Yes | The longitude of the geographic centre of the zone. |
Comment | nvarchar(500) | Yes | A free text field where any user information can be stored and referenced for this entity. |
Displayed | bit | Yes | A value indicating whether this zone must be displayed when viewing a map or it should be hidden. |
ExternalReference | nvarchar(255) | Yes | Any type of external reference to be attached to the zone. May be used to link zones with corresponding entities in other systems. |
MustIdentifyStops | bit | Yes | Indicates whether this zone name must be shown when devices stop in this zone. If true, a "zone stop rule" (Rule with BaseType: ZoneStop) will automatically be created for this zone. This is to facilitate reporting on zone stops. The rule is not visible via the MyGeotab UI. |
Name | nvarchar(255) | No | The name of this entity that uniquely identifies it and is used when displaying this entity. |
Points | nvarchar(max) | Yes | The list of points (see Coordinate) that make up the zone. A zone should be closed (i.e. the first point should consist of the same set of coordinates as the last point). Presented in the form of a JSON array (e.g. [{"X":-79.68085479736328,"Y":43.517887115478516},{"X":-79.6830825805664,"Y":43.51841354370117},{"X":-79.6854019165039,"Y":43.5172004699707},{"X":-79.68214416503906,"Y":43.51369857788086},{"X":-79.6794204711914,"Y":43.51435470581055},{"X":-79.68085479736328,"Y":43.517887115478516}]). |
ZoneTypeIds | nvarchar(max) | No | The Id(s) of the ZoneType(s) that this zone belongs to. Presented in the form of a JSON array (e.g. [{"Id":"ZoneTypeOfficeId"},{"Id":"ZoneTypeCustomerId"}]). Ids correspond to GeotabId values in the ZoneTypes table. |
Version | bigint | Yes | The version of the entity. |
EntityStatus | int | No | Indicates whether the subject corresponding object is active or deleted in the MyGeotab database. 1 = Active. 0 = Deleted. |
RecordLastChangedUtc | datetime2(7) | No | A timestamp, in Coordinated Universal Time (UTC), indicating the last time that the subject record was updated in the adapter database. |
Two files, explained below, are used to configure the MyGeotab API Adapter - appsettings.json and nlog.config.
Individual MyGeotab API Adapter services can be enabled or disabled using the Enable<EntityType>Cache
settings for reference data tables and the Enable<EntityType>Feed
settings for feed data tables. This provides the flexibility to download only the desired Geotab data, thereby affording potential cost savings in terms of CPU, memory and storage consumption. However, there are certain logical dependencies that must be enforced in order to make the Geotab data usable. For example, the LogRecord object has a Device property that contains the Id of the Device object with which it is associated. The LogRecord on its own is useless without knowing which Device it came from. Therefore, someone wishing to enable the LogRecordProcessor should also enable the DeviceProcessor.
To ensure that appropriate combinations of services are enabled, certain service interdependencies are enforced as shown in the following table. For each service, the list of direct service dependencies is provided. When a given service starts-up, checks are performed to ensure that any services on which it depends are already running. If not, warning messages will be written to the log file and the target service will keep checking intermittently until the services on which it depends are running. For example, if the StatusDataProcessor has been enabled, but the DeviceProcessor and DiagnosticProcessor have not been enabled, the log file will contain messages like the following:
2022-10-30 22:16:28.9799|INFO|"******** PAUSING SERVICE: MyGeotabAPIAdapter.StatusDataProcessor (v2.0.0.0) because of the following: > The prerequisite DeviceProcessor and DiagnosticProcessor have never been run. > The prerequisite DeviceProcessor and DiagnosticProcessor are not currently running. Please ensure that all prerequisite processors are running. The MyGeotabAPIAdapter.StatusDataProcessor (v2.0.0.0) will check again at 2022-10-31 2:16:38 AM (UTC) and will resume operation if all prerequisite processors are running at that time. |
✱ NOTE: There is a service orchestration process that occurs on application startup. Because all of the services start at the same time and some take longer than others to initialize, it is normal to see messages such as that in the above example when the MyGeotab API Adapter first starts. If services have been enabled, appropriately based on the table below, then these messages will stop appearing after the first few minutes of operation, once all of the services have come online.
In the above example, if the DeviceProcessor and DiagnosticProcessor have not been enabled, enable them both and restart the MyGeotab API Adapter to resolve the issue.
The following table lists the direct service dependencies for each service. Note that the dependencies might also have their own direct service dependencies.
Service | Direct Service Dependencies |
BinaryDataProcessor | DeviceProcessor |
ControllerProcessor | |
DeviceProcessor | |
DeviceStatusInfoProcessor | DeviceProcessor, UserProcessor |
DiagnosticProcessor | |
DriverChangeProcessor | DeviceProcessor, UserProcessor |
DutyStatusAvailabilityProcessor | UserProcessor |
DVIRLogManipulator | DVIRLogProcessor |
DVIRLogProcessor | DeviceProcessor, UserProcessor |
ExceptionEventProcessor | DeviceProcessor, RuleProcessor, UserProcessor |
FailureModeProcessor | |
FaultDataProcessor | ControllerProcessor, DeviceProcessor, DiagnosticProcessor, FailureModeProcessor |
GroupProcessor | |
LogRecordProcessor | DeviceProcessor |
RuleProcessor | |
StatusDataProcessor | DeviceProcessor, DiagnosticProcessor |
TripProcessor | DeviceProcessor, UserProcessor |
UnitOfMeasureProcessor | |
UserProcessor | |
ZoneProcessor | |
ZoneTypeProcessor |
Aside from log-related items, all configuration settings governing operation of the MyGeotab API Adapter are found in the appsettings.json file, which is located in the same directory as the executable (i.e. MyGeotabAPIAdapter.exe). Individual settings are organized into sections for readability. The following tables provide information about the settings contained within each of these sections.
In some cases, it may be necessary to store database connection strings and MyGeotab login credentials in environment variables rather than in the appsettings.json file itself. To do so, simply leave the appsettings.json settings as-is (i.e. do not change or delete the subject settings) and create the corresponding environment variables as in the following (Windows) example (note the double underscores “__”):
The OverrideSettings section contains settings used to override certain aspects of application logic.
Setting | Description |
DisableMachineNameValidation | Indicates whether machine name validation should be disabled. In most cases, the value should be false. It can be set to true only in cases where the application is deployed to a hosted environment in which machine names are not guaranteed to be static. WARNING! Extreme caution must be used when setting this value to true! Improper deployment could lead to application instability and data integrity issues! |
The DatabaseSettings section contains settings used to connect to the adapter database that is paired with the MyGeotab API Adapter.
Setting | Description |
DatabaseProviderType | The database provider. Must be one of SQLServer, PostgreSQL or Oracle. |
DatabaseConnectionString | The database connection string (e.g. |
The LoginSettings section is used to configure the credentials that the internal MyGeotab API object will use to authenticate to the MyGeotab database with which the current MyGeotab API Adapter instance is paired.
Setting | Description |
MyGeotabServer | The MyGeotab server (e.g. my.geotab.com). |
MyGeotabDatabase | The name of the MyGeotab database to authenticate against. WARNING! It is not possible to mix data from multiple MyGeotab databases within a single MyGeotab API Adapter database. Once data has been added to the adapter database, it is not possible to change the MyGeotabDatabase setting. |
MyGeotabUser | The username to be used for authentication. |
MyGeotabPassword | The password associated with the MyGeotab user. |
The GeneralSettings section under AppSettings includes settings that do not fall into any of the other categories.
Setting | Description |
TimeoutSecondsForDatabaseTasks | The maximum number of seconds allowed for an individual adapter database operation (select, insert, update, delete) to complete. If a database operation does not complete within this amount of time, it will be assumed that there is a loss of connectivity, the existing operation will be rolled-back and the MyGeotab API Adapter will resume normal operation after establishing that there is connectivity to the adapter database (e.g. 30). Minimum: 10. Maximum: 3600. |
TimeoutSecondsForMyGeotabTasks | The maximum number of seconds allowed for a MyGeotab API call to wait for a response. If a response is not received within this amount of time, it will be assumed that there is a loss of connectivity, the existing operation will be rolled-back and the MyGeotab API Adapter will resume normal operation after establishing that there is connectivity to the MyGeotab database via API (e.g. 30). Minimum: 10. Maximum: 3600. |
The Caches section under AppSettings includes sections that govern the timing and frequency by which the MyGeotab API Adapter updates and refreshes caches of entities obtained from the MyGeotab database configured in the LoginSettings section.
✱ NOTE: In order to provide ultimate flexibility, each entity type has its own cache configuration section consisting of the following four settings which include the subject entity type name:
Enable<EntityType>Cache:
Indicates whether the cache for the subject entity type should be enabled. Must be set to either true or false. <EntityType>
CacheIntervalDailyReferenceStartTimeUTC: An ISO 8601 date and time string used to specify a time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings. Only the time portion of the string is used; the date entered is irrelevant. To avoid time-zone related issues, Coordinated Universal Time (UTC) should be used (e.g. 2020-06-23T06:00:00Z).<EntityType>
CacheUpdateIntervalMinutes: The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week).<EntityType>
CacheRefreshIntervalMinutes: The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week).As an example of cache configuration, in order to refresh the User cache at 2:00am EDT every day and update it every six hours (i.e. at 8:00am, 2:00pm and 8:00pm), the settings in the User cache section would be configured as follows:
! IMPORTANT: Cache refreshes and updates may occur slightly after the configured times due to the amount of time required to process cache and feed data during each iteration.
The Controller section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Controller objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableControllerCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
ControllerCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
ControllerCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
ControllerCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The Device section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Device objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDeviceCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DeviceCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
DeviceCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
DeviceCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The Diagnostic section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Diagnostic objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDiagnosticCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DiagnosticCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
DiagnosticCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
DiagnosticCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The DVIRDefect section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of DVIRDefect objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
DVIRDefectListCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The FailureMode section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of FailureMode objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableFailureModeCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
FailureModeCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
FailureModeCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
FailureModeCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The Group section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Group objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableGroupCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
GroupCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
GroupCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
GroupCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The Rule section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Rule objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableRuleCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
RuleCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
RuleCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
RuleCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The UnitOfMeasure section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of UnitOfMeasure objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableUnitOfMeasureCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
UnitOfMeasureCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
UnitOfMeasureCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
UnitOfMeasureCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The User section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of User objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableUserCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
UserCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
UserCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
UserCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The Zone section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of Zone objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableZoneCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
ZoneCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
ZoneCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
ZoneCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The ZoneType section under AppSettings > Caches includes settings that govern the MyGeotab API Adapter cache of ZoneType objects obtained from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableZoneTypeCache | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
ZoneTypeCacheIntervalDailyReferenceStartTimeUTC | The UTC time of day to serve as the basis upon which cache update and refresh times are calculated using the associated interval settings (e.g. 2020-06-23T06:00:00Z). |
ZoneTypeCacheUpdateIntervalMinutes | The frequency, in minutes, by which the subject cache should be "updated" - capturing new and changed objects (e.g. 360). Minimum: 1. Maximum: 10080 (1 week). |
ZoneTypeCacheRefreshIntervalMinutes | The frequency, in minutes, by which the subject cache should be "refreshed" - dumped and repopulated to make identification of deleted entities possible, since deletes do not propagate from MyGeotab through the MyGeotab API data feeds (e.g. 1440). Minimum: 60 (1 hour). Maximum: 10080 (1 week). |
The GeneralFeedSettings section under AppSettings contains settings that apply to all data feeds.
Setting | Description |
FeedStartOption | Alternate ways that polling via data feeds may be initiated. Must be set to one of the following values:
CAUTION! If any data has already been captured for a given feed, as determined by the existence of a corresponding entry in the OServiceTracking table in the adapter database, the FeedStartOption will automatically switch to FeedVersion - overriding any other value that may have been set. This mechanism is in place to avoid issues related to data duplication or gaps. |
FeedStartSpecificTimeUTC | Only used if the FeedStartOption parameter is set to SpecificTime. The UTC time (formatted as yyyy-MM-ddTHH:mm:ssZ) at which to start all data feeds (e.g. 2020-06-23T06:00:00Z). |
DevicesToTrack | A comma-separated list of device IDs that correspond to devices to be tracked. The default value of * indicates that data will be captured for all devices. Alternatively, if a comma-separated list of device IDs is provided (e.g. b1,b2), any feed data with relations to devices will be filtered such that only the data associated with the specified devices will be persisted to the adapter database. WARNING! In order to capture data related to all devices, the value of this setting must be *. |
DiagnosticsToTrack | A comma-separated list of diagnostic IDs that correspond to diagnostics (StatusData or FaultData) to be tracked. The default value of * indicates that data will be captured for all diagnostics. Alternatively, if a comma-separated list of diagnostic IDs is provided (e.g. DiagnosticOdometerAdjustmentId,DiagnosticFuelLevelId,DiagnosticFuelUnitsId,DiagnosticCrankingVoltageId,DiagnosticInvalidGpsMessagesReceivedId), any feed data with relations to diagnostics will be filtered such that only the data associated with the specified diagnostics will be persisted to the adapter database. WARNING! In order to capture data related to all diagnostics, the value of this setting must be *. |
ExcludeDiagnosticsToTrack | Indicates whether the DiagnosticsToTrack should be excluded, effectively inverting functionality. If false, only the data associated with the specified diagnostics will be persisted to the adapter database. If true, all data EXCEPT for the data associated with the specified diagnostics will be persisted to the adapter database. Must be set to either true or false. |
EnableMinimunIntervalSamplingForLogRecords | Indicates whether minimum interval sampling should be applied to the LogRecord feed. Only works if EnableLogRecordFeed is true. If set to true, a minimum interval defined by MinimumIntervalSamplingIntervalSeconds will be applied between LogRecords that are written to the LogRecords table. Must be set to either true or false. See the Minimum Interval Sampling section for more information. |
EnableMinimunIntervalSamplingForStatusData | Indicates whether minimum interval sampling should be applied to the StatusData feed. Only works if EnableStatusDataFeed is true. If set to true, a minimum interval defined by MinimumIntervalSamplingIntervalSeconds will be applied between StatusData entities with a Diagnostic Id included in the MinimumIntervalSamplingDiagnostics list that are written to the StatusData table. All StatusData entities with a Diagnostic Id included in the DiagnosticsToTrack list but not in the MinimumIntervalSamplingDiagnostics list will be persisted to the StatusData table. Must be set to either true or false. See the Minimum Interval Sampling section for more information. |
MinimumIntervalSamplingDiagnostics | A comma-separated list of diagnostic IDs for which minimum interval sampling will be applied to the StatusData feed. Only works if EnableStatusDataFeed is true. If set to true, a minimum interval defined by MinimumIntervalSamplingIntervalSeconds will be applied between StatusData entities with a Diagnostic Id included in this list that are written to the StatusData table. This list must be equal to the list provided in the DiagnosticsToTrack setting or a subset thereof. ExcludeDiagnosticsToTrack must be set to false. The placeholder wildcard value (*) cannot be used for the DiagnosticsToTrack setting nor this setting. See the Minimum Interval Sampling section for more information. |
MinimumIntervalSamplingIntervalSeconds | The minimum duration, in seconds, that should be applied between the DateTime values of entities that are written to their respective table(s) in the adapter database for any entity type that has minimum interval sampling enabled. Minimum: 1. Maximum: 3600 (1 hour). See the Minimum Interval Sampling section for more information. |
The Feeds section under AppSettings includes sections that govern the use of data feeds for the various MyGeotab entity types that the MyGeotab API Adapter supports.
✱ NOTE: In order to provide ultimate flexibility, each supported entity type has its own feed configuration section consisting of the following settings which include the subject entity type name:
Enable<EntityType>Feed:
Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false.<EntityType>FeedIntervalSeconds:
The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week).The BinaryData section under AppSettings > Feeds includes settings that govern the use of the BinaryData data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableBinaryDataFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
BinaryDataFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The ChargeEvent section under AppSettings > Feeds includes settings that govern the use of the ChargeEvent data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableChargeEventFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
ChargeEventFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The DebugData section under AppSettings > Feeds includes settings that govern the use of the DebugData data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDebugDataFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DebugDataFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The DeviceStatusInfo section under AppSettings > Feeds includes settings that govern the use of the DeviceStatusInfo data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDeviceStatusInfoFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DeviceStatusInfoFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The DriverChange section under AppSettings > Feeds includes settings that govern the use of the DriverChange data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDriverChangeFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DriverChangeFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The DutyStatusAvailability section under AppSettings > Feeds includes settings that govern the use of the DutyStatusAvailability pseudo data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDutyStatusAvailabilityFeed | Indicates whether the pseudo data feed for the subject entity type should be enabled. Must be set to either true or false. |
DutyStatusAvailabilityFeedIntervalSeconds | The minimum number of seconds to wait after retrieving DutyStatusAvailability information for all Drivers before starting the retrieval process again (e.g. 300). Minimum: 2. Maximum: 604800 (1 week). |
DutyStatusAvailabilityFeedLastAccessDateCutoffDays | Used to reduce the number of unnecessary Get calls when retrieving DutyStatusAvailability information for all Drivers. Data is not queried for Drivers who have not accessed the Geotab system for more than this many days in the past. This value should be set to approximately twice the longest possible cycle for a HOS ruleset (e.g. 30). Minimum: 14. Maximum: 60. |
The DutyStatusLog section under AppSettings > Feeds includes settings that govern the use of the DutyStatusLog data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDutyStatusLogFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DutyStatusLogFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The DVIRLog section under AppSettings > Feeds includes settings that govern the use of the DVIRLog data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableDVIRLogFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
DVIRLogFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The ExceptionEvent section under AppSettings > Feeds includes settings that govern the use of the ExceptionEvent data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableExceptionEventFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
ExceptionEventFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
TrackZoneStops | Only used if EnableExceptionEventFeed is set to true. Indicates whether exceptions with an ExceptionRuleBaseType of ZoneStop are to be persisted to the adapter database. Must be set to either true or false. |
The FaultData section under AppSettings > Feeds includes settings that govern the use of the FaultData data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableFaultDataFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
FaultDataFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The LogRecord section under AppSettings > Feeds includes settings that govern the use of the LogRecord data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableLogRecordFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
LogRecordFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The StatusData section under AppSettings > Feeds includes settings that govern the use of the StatusData data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableStatusDataFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
StatusDataFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The Trip section under AppSettings > Feeds includes settings that govern the use of the Trip data feed pulled from the MyGeotab database configured in the LoginSettings section.
Setting | Description |
EnableTripFeed | Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false. |
TripFeedIntervalSeconds | The minimum number of seconds to wait between GetFeed() calls for the subject entity type (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The Manipulators section under AppSettings includes sections that govern services responsible for issuing data manipulation commands to the Geotab platform. Manipulators may be used in conjunction with feeds to facilitate bidirectional integration between the Geotab platform and external systems.
The DVIRLog section under AppSettings > Manipulators includes settings that govern the use of the DVIRLogManipulator service which provides the capability to update DVIRLogs in the MyGeotab database configured in the LoginSettings section. See the DVIRLog Manipulator section for more information.
Setting | Description |
EnableDVIRLogManipulator | Indicates whether the DVIRLogManipulator service should be enabled. Must be set to either true or false. |
DVIRLogManipulatorIntervalSeconds | The minimum number of seconds to wait between starts of iterations of the DVIRLogManipulator processing logic (e.g. 30). Minimum: 2. Maximum: 604800 (1 week). |
The VSS section under AppSettings > AddOns includes settings related to the Vehicle Signal Specification (VSS) Add-On. Unless this capability is being used, ensure that EnableVSSAddOn is set to false. For more information about the settings in this section, refer to the MyGeotab API Adapter - Vehicle Signal Specification (VSS) Add-On - Solution and Implementation Guide.
The MyGeotab API Adapter utilizes the NLog LoggerProvider for Microsoft.Extensions.Logging to capture information and write it to log files for debugging purposes. NLog configuration settings are found in the nlog.config file, which is located in the same directory as the executable (i.e. MyGeotabAPIAdapter.exe).
Below is the content of the nlog.config file that is included with the MyGeotab API Adapter. It is followed by instructions that indicate how the highlighted settings may be adjusted.
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" internalLogFile="LOG-MyGeotab_API_Adapter-internal.log" internalLogLevel="Error" >
maxArchiveFiles="100" archiveAboveSize="5120000" archiveEvery="Day">
layout="${date}|${level:uppercase=true}|${message} ${exception}|${logger}|${all-event-properties}" />
minlevel="Info" writeTo="target1,target2" />
|
WARNING! Only the settings that are highlighted in the above content should be modified as described in the following table. Changing anything else could lead to unpredictable consequences
The following table lists the NLog settings, highlighted above, that may be adjusted as required.
Setting | Description |
autoReload | Indicates whether the nlog.config file should be watched for changes and reloaded automatically when changed. Must be set to either true or false. |
maxArchiveFiles | Maximum number of archive files that should be kept. If maxArchiveFiles is less or equal to 0, old files aren't deleted. Default: 100. |
archiveAboveSize | Size in bytes above which log files will be automatically archived. Default: 5120000 (5 MB). |
archiveEvery | Indicates whether to automatically archive log files every time the specified time passes. Default: DAY. Possible values:
|
minlevel | Indicates the log level, which is the amount of detail to be written to log files. Default: Debug. Possible values:
|
The high-level application logic of the MyGeotab API Adapter solution is represented in the following exhibit:
This section provides usage and deployment-related instructions for the MyGeotab API Adapter solution. Information related to solution architecture, logic and data models can be found in the Solution Information section of this guide.
The MyGeotab API Adapter requires:
The MyGeotab API Adapter solution can be obtained by cloning the Git repository. Once downloaded, open the solution — MyGeotabAPIAdapter.sln — using Microsoft Visual Studio or Visual Studio Code.
Out-of-the-box, the MyGeotab API Adapter supports SQL Server, PostgreSQL and Oracle for use as the database into which data retrieved via the MyGeotab API is written, as described in the Database section. Database setup procedures differ depending on the type of database and are outlined below.
WARNING! Regardless of database type, it is possible for the database to grow very large very quickly, resulting in potential disk space and performance issues. For example, running the adapter against a MyGeotab database with a fleet of ~20,000 devices and pulling data for all supported feeds could result in an empty associated PostgreSQL database growing to ~40 GB in size within 7 days. In such a scenario, the database might include ~225,000,000 StatusData, ~65,000,000 LogRecord and ~10,000,000 Trip records.
See the Database Maintenance section for more information.
If PostgreSQL is to be used with the adapter, it is necessary to have access to a PostgreSQL server on which to set-up the adapter database. Steps are as follows:
1 | Create the geotabadapter_owner user using the following script (first replacing CREATE ROLE geotabadapter_owner WITH LOGIN NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION
|
2 | Create the geotabadapter_client user using the following script (first replacing CREATE ROLE geotabadapter_client WITH LOGIN NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION
|
3 | Execute the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\PostgreSQL folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file). |
If SQL Server is to be used with the adapter, it is necessary to have access to a SQL Server instance on which to set-up the adapter database. Using SQL Server Management Studio, steps are as follows:
1 | Create a database named geotabadapterdb. |
2 | Create a login named geotabadapter_client along with a user by the same name using the following script (first replacing USE [master]; CREATE LOGIN [geotabadapter_client] WITH
DEFAULT_DATABASE=[geotabadapterdb], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF; USE [geotabadapterdb]; CREATE USER [geotabadapter_client] FOR LOGIN [geotabadapter_client] WITH DEFAULT_SCHEMA=[dbo]; ALTER ROLE [db_datareader] ADD MEMBER [geotabadapter_client]; ALTER ROLE [db_datawriter] ADD MEMBER [geotabadapter_client]; |
3 | Ensure that the database collation is set to be case-sensitive by executing the following: USE [geotabadapterdb] GO ALTER DATABASE [geotabadapterdb] COLLATE SQL_Latin1_General_CP1_CS_AS; GO |
4 | Execute the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\SQLServer folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file). |
If Oracle is to be used with the adapter, it is necessary to have access to an Oracle instance on which to set-up the adapter database. Using Oracle SQL Developer, steps are as follows:
1 | Identify or create an Oracle database that will be used. |
2 | If running Oracle Database XE, it may be necessary to execute the following statement prior to running any of the subsequent scripts: alter session set "_ORACLE_SCRIPT"=true; |
3 | Create a user named GeotabAdapter_Client and set grants using the following script (first replacing
DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP; GRANT CONNECT, RESOURCE TO GeotabAdapter_Client; GRANT UNLIMITED TABLESPACE TO GeotabAdapter_Client; GRANT CREATE SESSION TO GeotabAdapter_Client; GRANT CREATE TABLE, CREATE VIEW TO GeotabAdapter_Client; |
4 | Execute the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\Oracle folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file). |
CAUTION! When using Oracle as the adapter database, any field values greater than 4,000 characters in length will be substituted with the message “Entity value exceeds 4000 character limit and would be truncated. Please use other means to obtain and update this placeholder with the actual value.” before being inserted or updated. This is to avoid arbitrary truncation of data and is necessary due to Oracle’s usage of the non-standard NCLOB data type to store strings greater than 4,000 characters in length.
If another database type is to be used, steps will vary depending on the database provider, but will be similar to those outlined for PostgreSQL. See the Adding Support for Other Database Types section for more information.
WARNING! Regardless of database type, it is possible for the database to grow very large very quickly, resulting in potential disk space and performance issues. For example, running the adapter against a MyGeotab database with a fleet of ~20,000 devices and pulling data for all supported feeds could result in an empty associated PostgreSQL database growing to ~40 GB in size within 7 days. In such a scenario, the database might include ~225,000,000 StatusData, ~65,000,000 LogRecord and ~10,000,000 Trip records.
The database has been designed to allow data streamed through the adapter to be written to tables as quickly as possible. As such, no physical relationships have been implemented between tables where logical relationships exist. Additionally, the GeotabId columns - which represent object identifiers in the Geotab system - are not indexed. Furthermore, no data clean-up mechanisms have been implemented. Consequently, the database will continually grow in size if left unattended and queries against the tables will take increasing amounts of time to execute.
CAUTION! Regardless of database type, the database has been designed to be transactional in nature to allow for data streamed through the adapter to be written as quickly as possible. As such, the database will continually grow in size if left unattended and queries against the tables will take increasing amounts of time to execute.
One might consider options such as adding indexes to some of the fields in the database tables to support query performance once record counts become significant. However, this would slow-down the writing of data being streamed from the MyGeotab database - potentially making the data less near real-time than would otherwise be the case. A better approach would be to implement a strategy wherein this database serves as an intermediary between the Geotab platform and the final repository where the extracted data will ultimately be stored for further processing and consumption by downstream applications.
One possible strategy for working with and managing the database is outlined as follows:
1 | Utilize the adapter database for its designed purpose as an intermediary transactional database. |
2 | Create another database to serve as a data warehouse (DWH).
|
3 | Build an ETL or polling mechanism that continually monitors the adapter database to capture new data and add it to the DWH.
|
4 | Take advantage of the available adapter configuration options. For example, if only LogRecord, StatusData and FaultData feed information is required, then the other feeds such as those for DVIRLogs, ExceptionEvents and Trips can be disabled, thereby eliminating unnecessary processing and database growth. See the AppSettings - Feeds section for more information. |
The Data Optimizer is another application that is part of the overall solution and can be paired with the adapter in order to implement the strategy suggested above. Additionally, the optimizer includes capabilities to enhance the data and overcome certain challenges such as linking data points with different timestamps from different tables. For example, the StatusData and FaultData tables have added Latitude, Longitude, Speed, Bearing and Direction columns that can optionally be populated using LogRecords and interpolation techniques.
Full details pertaining to the Data Optimizer can be found in the MyGeotab API Adapter - Data Optimizer - Solution and Implementation Guide.
✱ NOTE: For testing and monitoring purposes, the script named CleanDatabaseScript.sql provides handy queries to delete data from all adapter database tables or return a list of record counts per table. The PostgreSQL version of the script can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\PostgreSQL folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file). The SQL Server version of the script can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\SQLServer folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file). The Oracle version of the script can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\Oracle folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file).
LogRecord and StatusData entities typically account for a very large proportion of the data volume in a MyGeotab database - hundreds of millions of records per day for fleets of over 100K devices, for example. In some cases, this massive data volume may be deemed excessive and there may be a preference to reduce data volume such that data points are no more frequent than one per device every x number of seconds. To address this need, “minimum interval sampling” capability has been added to the MyGeotab API Adapter via the EnableMinimunIntervalSamplingForLogRecords, EnableMinimunIntervalSamplingForStatusData, MinimumIntervalSamplingDiagnostics and MinimumIntervalSamplingIntervalSeconds settings in the AppSettings - GeneralFeedSettings section of the appsettings.json file.
CAUTION! Be careful before deciding to utilize the minimum interval sampling capability of the MyGeotab API Adapter. There is no way to later back-fill data if minimum interval sampling has been used other than clearing the adapter database, adjusting the appsettings.json file and re-running the extraction process.
✱ NOTE: Minimum interval sampling does not ensure that LogRecord or StatusData entities are are captured at a regular “polling interval” of one record every n seconds. Rather, it ensures that a minimum of n seconds exists between the DateTime values of LogRecord or StatusData entities that are written to the adapter database. Entities that fall within the interval are discarded instead of being written to the adapter database.
With regard to LogRecords, minimum interval sampling is applied on a per-Device basis and can be enabled based on the following rules:
Take the following example highlighting a specific combination of values in the appsettings.json file:
...
"EnableDeviceCache": true,
"EnableDiagnosticCache": true,
...
"FeedStartOption": "SpecificTime",
"FeedStartSpecificTimeUTC": "2024-04-01T08:00:00Z",
"DevicesToTrack": "*",
"DiagnosticsToTrack": "DiagnosticOilPressureId,DiagnosticIgnitionId,DiagnosticEngineRoadSpeedId",
"ExcludeDiagnosticsToTrack": false,
"EnableMinimunIntervalSamplingForLogRecords": true,
"EnableMinimunIntervalSamplingForStatusData": true,
"MinimumIntervalSamplingDiagnostics": "DiagnosticOilPressureId,DiagnosticEngineRoadSpeedId",
"MinimumIntervalSamplingIntervalSeconds": 300
...
"EnableLogRecordFeed": true,
...
"EnableStatusDataFeed": true,
Based on the above setting configuration:
With regard to StatusData, minimum interval sampling is applied on a per-Device + Diagnostic basis and can be enabled based on the following rules:
Take the following example highlighting a specific combination of values in the appsettings.json file:
...
"EnableDeviceCache": true,
"EnableDiagnosticCache": true,
...
"FeedStartOption": "SpecificTime",
"FeedStartSpecificTimeUTC": "2024-04-01T08:00:00Z",
"DevicesToTrack": "*",
"DiagnosticsToTrack": "DiagnosticOilPressureId,DiagnosticIgnitionId,DiagnosticEngineRoadSpeedId",
"ExcludeDiagnosticsToTrack": false,
"EnableMinimunIntervalSamplingForLogRecords": true,
"EnableMinimunIntervalSamplingForStatusData": true,
"MinimumIntervalSamplingDiagnostics": "DiagnosticOilPressureId,DiagnosticEngineRoadSpeedId",
"MinimumIntervalSamplingIntervalSeconds": 300
...
"EnableLogRecordFeed": true,
...
"EnableStatusDataFeed": true,
Based on the above setting configuration:
The DVIRLog Manipulator is a service that runs in parallel with the main Worker service and provides the ability to update DVIRLogs in the MyGeotab database.
Using the DVIRLog Manipulator, it is possible - without directly using the MyGeotab API - to:
A practical example where the DVIRLog Manipulator could be used is an integration between Geotab and an enterprise asset management (EAM) system. In this scenario:
1 | Using the Geotab Drive app, drivers completing vehicle inspection reports (DVIRs) log any defects that they discover. |
2 | The MyGeotab API Adapter’s Worker service captures the DVIRLogs and writes any defect information to the adapter database. |
3 | A third-party integration service extracts the defect information from the adapter database and generates repair work orders in the EAM system. |
4 | As repair remarks are added to the work orders in the EAM and when the repair orders are closed upon completion of corrective maintenance activities, the third-party integration service writes these remarks and updates to the DVIRDefectUpdates table in the adapter database. |
5 | The DVIRLog Manipulator service captures the repair remarks and status updates as they are written to the DVIRDefectUpdates table and makes the appropriate updates to the corresponding DVIRLogs in the Geotab system. |
6 | Drivers using the Geotab Drive app as well as supervisors and fleet managers using the MyGeotab web-based application are able to keep up-to-date on the status of repairs as updates flow from the EAM system into the Geotab system via this workflow. |
The above workflow is illustrated with diagrams in the DVIRLog Manipulator section of the MyGeotab API Adapter presentation.
To use the DVIRLog Manipulator, simply ensure that the EnableDVIRLogFeed and EnableDVIRLogManipulator settings are both set to true before starting the adapter.
Repair remarks can be added to existing DVIRDefects and the repair status of existing DVRDefects can be updated in the Geotab system by simply inserting records into the DVIRDefectUpdates table in the adapter database.
To ensure that updates can be successfully processed, the following rules must be adhered to when inserting these records into the DVIRDefectUpdates table:
1 | Values must always be provided for the DVIRLogId, DVIRDefectId and RecordCreationTimeUtc fields. |
2 | The value provided for the DVIRLogId field must correspond to the Id of a DVIRLog in the MyGeotab database with which the adapter is configured to interact with. |
3 | The value provided for the DVIRDefectId field must correspond to the Id of a DVIRDefect associated with the subject DVIRLog. |
4 | To add a remark to a DVIRDefect:
|
5 | To update the repair status of a DVIRDefect:
|
6 | To add a remark to a DVIRDefect and update the repair status of the DVIRDefect at the same time:
|
7 | The repair status of a DVIRDefect cannot be changed once it has been set to “Repaired” or “NotNecessary”. |
8 | The only values that may be supplied for the RepairStatus field are “Repaired” or “NotNecessary” (other than null, when only a repair remark is to be added). |
9 | User Ids provided for the RepairUserId and RemarkUserId fields must be valid User Ids in the MyGeotab database with which the adapter is configured to interact. The same User Id can be provided for both fields; separate fields are provided for added flexibility. Additionally, the subject Users must have appropriate clearances in the MyGeotab database:
|
DVIRLog updates made by the DVIRLog Manipulator service are captured by the main Worker service and written to the adapter database as updates to the DVIRLogs, DVIRDefects and DVIRDefectRemarks tables. Records that have been processed by the DVIRLog Manipulator service are deleted from the DVIRDefectUpdates table in the adapter database.
Any rows in the DVIRDefectUpdates table that do not pass validation checks or for which exceptions are encountered while attempting the associated DVIRLog updates will be copied to the FailedDVIRDefectUpdates table before being deleted from the DVIRDefectUpdates table. The FailureMessage column provides details about the reason why a given command failed. This is to assist in debugging and to provide feedback that would otherwise be provided in the responses to commands issued via the MyGeotab API.
CAUTION! Rows are never deleted from the FailedDVIRDefectUpdates table. It is up to the integrator to delete rows from this table once the error messages have been evaluated and appropriate actions have been taken.
If the capabilities offered by the DVIRLog Manipulator are not required, simply disable the service by adjusting the EnableDVIRLogManipulator setting to be false. This will prevent the service from starting and avoid unnecessary resource utilization.
This section provides information related to publishing and deployment of the MyGeotab API Adapter solution.
The latest version of the MyGeotab API Adapter solution is available on GitHub as a pre-published release for one or more target runtimes. If there is a published release version for the desired runtime, it can be downloaded per the instructions in this section and it will then be possible to skip to the Deployment instructions (ensuring first that Deployment Prerequisites are met).
Instructions for obtaining the pre-published release are as follows:
1 | Using a web browser, navigate to https://github.com/Geotab/mygeotab-api-adapter/releases. |
2 | Files associated with the latest release are listed under the Assets heading. Self-contained deployments are packaged in zip files - the names of which are prefixed with "MyGeotabAPIAdapter_SCD_" followed by the target Runtime Identifier (e.g. "win-x64"). In the following example, release packages are available for Ubuntu and Windows. If using PostgreSQL for the adapter database, the PostgreSQL.zip file contains the scripts associated with this release. If using SQL Server for the adapter database, the SQLServer.zip file contains the scripts associated with this release. If using Oracle for the adapter database, the Oracle.zip file contains the scripts associated with this release. |
3 | Download the appropriate files, extract the contents and proceed with deployment. |
If any changes are made to the solution that result in database schema changes, such as new tables added to support additional MyGeotab data feeds, it will be necessary to provide an updated database or database creation script, depending on the database type.
CAUTION! The instructions in this section assume that the deployed solution will be starting with an empty database. If the solution has already been deployed and changes are being made, but it is necessary to maintain the existing data, steps will need to be modified accordingly.
For PostgreSQL, the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\PostgreSQL folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file) should be updated. This can be accomplished using the Backup utility in pgAdmin. Steps used to create the out-of-the-box script are as follows:
1 | Ensure that the database is empty. The commented-out lines at the beginning of the CleanDatabaseScript.sql script can be used to delete data from the tables and reset the sequences so that the first id value for each table will be 1. |
2 | In pgAdmin, right-click on geotabadapterdb in the tree control and select Backup… from the context menu. |
3 | On the General tab, set the Filename to overwrite the geotabadapterdb-DatabaseCreationScript.sql file (or write it to a different location) and set the Format to Plain. |
4 | On the Dump options tab, set everything to No except for the following, which should be set to Yes:
|
5 | Click the Backup button. A dialog box will appear and should indicate that the backup was successfully completed. |
6 | Using a text editor, open the updated geotabadapterdb-DatabaseCreationScript.sql file and add the following lines to the end of the file:: -- Manual additions not captured by backup procedure: GRANT ALL ON SEQUENCE public."DVIRDefectRemarks_id_seq" TO geotabadapter_client; GRANT ALL ON SEQUENCE public."DVIRDefectRemarks_id_seq" TO geotabadapter_owner; GRANT ALL ON SEQUENCE public."FailedDVIRDefectUpdates_id_seq" TO geotabadapter_client; GRANT ALL ON SEQUENCE public."FailedDVIRDefectUpdates_id_seq" TO geotabadapter_owner; |
WARNING! DO NOT include data in the script. This is to avoid potential issues related to unauthorized access to customer data.
For SQL Server, the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\SQLServer folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file) should be updated. This can be accomplished using SQL Server Management Studio (SSMS). Steps used to create the out-of-the-box script are as follows:
1 | In SSMS, right-click on geotabadapterdb in the Object Explorer and select Tasks > Generate Scripts… from the context menu. |
2 | Click the Next> button, if necessary, to get to the Choose Objects step of the Generate Scripts dialog. Then, choose the Select specific database objects option, check the Tables, Views, and Stored Procedures checkboxes, and click the Next> button. |
3 | On the Set Scripting Options step of the Generate Scripts dialog:
|
4 | On the Summary step of the Generate Scripts dialog, click the Next> button. |
5 | On the Save Scripts step of the Generate Scripts dialog, once processing has completed, click the Finish button. |
WARNING! DO NOT include data in the script. This is to avoid potential issues related to unauthorized access to customer data.
For Oracle, the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found along with the source code in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter\Oracle folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file) should be updated. This can be accomplished using Oracle SQL Developer. Steps used to create the out-of-the-box script are as follows:
1 | In Oracle SQL Developer, with a connection to the database established, click the Tools menu, followed by the Database Export... menu item. |
2 | On the Source/Destination screen (Export Wizard - Step 1 of 5):
|
3 | On the Types to Export screen (Export Wizard - Step 2 of 5):
|
4 | On the Specify Objects screen (Export Wizard - Step 3 of 5):
|
5 | On the Export Summary screen (Export Wizard - Step 4 of 4): |
WARNING! DO NOT include data in the script. This is to avoid potential issues related to unauthorized access to customer data.
If another database type is being supported, steps will vary depending on the database provider, but will be similar to those outlined for PostgreSQL.
Ensure that the appsettings.Publish.json and nlog.config files have appropriate values set for the various items. Both files will be included with the deliverable package as part of the publishing process. They can be found in the ..\mygeotab-api-adapter\MyGeotabAPIAdapter folder (where mygeotab-api-adapter is the folder containing the MyGeotabAPIAdapter.sln solution file).
WARNING! For security purposes, take care to avoid including login credentials and database connection information in the appsettings.Publish.json file as it will be included in the published package that may be delivered to others. The Database Settings and Login Settings sections should use placeholders instead of actual values and should appear as follows:
"DatabaseSettings": {
"DatabaseProviderType": "PostgreSQL",
"DatabaseConnectionString": "Server=<Server>
;Port=<Port>
;Database=geotabadapterdb;User Id=geotabadapter_client;Password=<password>
"
//"DatabaseProviderType": "SQLServer",
//"DatabaseConnectionString": "Server=<Server>;Database=geotabadapterdb;User Id=geotabadapter_client;Password=<password>"
},
"LoginSettings": {
"MyGeotabServer": "<MyGeotabServer>
",
"MyGeotabDatabase": "<MyGeotabDatabase>
",
"MyGeotabUser": "<MyGeotabUser>
",
"MyGeotabPassword": "<MyGeotabPassword>
"
},
Prior to publishing, it is a good practice to ensure that all NuGet packages used in the solution are updated to the latest stable versions. Use NuGet Package Manager to update the packages for each of the projects in the solution:
Prior to building and publishing the solution, the assembly version information should be changed. This may be accomplished by editing the MyGeotabAPIAdapter.csproj, MyGeotabAPIAdapter.Database.csproj and MyGeotabAPIAdapter.Tests.csproj files. In each of these files, modify the values of the Version and InformationalVersion elements. For example, the Version element might be set to 1.0.0.6-beta and the InformationalVersion might correspondingly be set to 1.0.0.6-beta: This is a prerelease build.
After completing the preparation steps detailed in the previous sections, it is possible to move-on to the publishing process. Note that the steps outlined here are based on using Microsoft Visual Studio Professional 2019 and that they may differ somewhat if using another IDE or publishing method.
✱ NOTE: In this example, the target runtime is ubuntu.18.04-x64. The chosen target runtime will depend on the server on which the published MyGeotab API Adapter is intended to be deployed. It is possible to create multiple publish profiles to allow the solution to be published for multiple target runtimes. This link from Microsoft contains more information.
Publishing steps are as follows:
1 | In the Solution Explorer, select the MyGeotabAPIAdapter project. |
2 | Use the main menu to navigate to Build > Publish MyGeotabAPIAdapter. |
3 | Configure the Target Location, Configuration, Target Framework, and Target Runtime options similar to the following: |
4 | Click one of the edit pencils in the previous screenshot to reveal the Profile Settings dialog. Then, configure it similar to the following and click the Save button: |
5 | Click the Publish button shown in Step 3. |
6 | The published solution will appear, in this case, as a folder containing all of the files and dependencies needed to run the adapter on a server with the target runtime: |
7 | The published output in the previous step will include the appsettings.json file (which is actually the appsettings.Publish.json file from the solution) and the nlog.config file. However, the SQL Server, PostgreSQL and Oracle database creation scripts are not included and would need to be manually packaged along with the published folder. |
To provide for a smooth deployment, the following steps should be taken beforehand:
1 | Ensure that permission has been granted by the owner of the MyGeotab database with which the adapter will be interacting. |
2 | A service account should be established for use by the adapter. See the Service Account Guidelines document for more details. |
3 | Take appropriate steps (networking, firewall, etc.) to ensure connectivity between the server on which the adapter will be deployed and the MyGeotab platform (https://my.geotab.com). |
4 | Make sure that the adapter database setup has been completed per the instructions in the Database Setup section. |
5 | Make sure that the server hosting the adapter database has enough disk space and that a database maintenance strategy is implemented to prevent unlimited growth. WARNING! It is possible for the database to grow very large very quickly, resulting in potential disk space and performance issues. In particular, the feed data tables can accumulate vast quantities of records within short periods of time. See the Database Maintenance section for more information. |
Because the MyGeotab API Adapter solution has been published using the Self-contained deployment mode (see this link from Microsoft for more information) in this example, it is quite simple to deploy:
1 | Copy the published folder that was generated in Step 6 of the Publish section to the server on which the adapter is to reside. |
2 | Modify the appsettings.json file as needed. See the appsettings.json section for more information. ✱ NOTE:Take advantage of the available adapter configuration options. For example, if only LogRecord, StatusData and FaultData feed information is required, then the other feeds such as those for DVIRLogs, ExceptionEvents and Trips can be disabled, thereby eliminating unnecessary processing and database growth. See the AppSettings - Feeds section for more information. |
3 | Review the nlog.config file and make any necessary changes. See the nlog.config section for more information. |
4 | Run the adapter executable (“MyGeotabAPIAdapter” or “MyGeotabAPIAdapter.exe”, depending on the target runtime) in the published folder that was copied in Step 1. ✱ NOTE: It is best to setup a process to run the adapter using a system account. On a Windows Server, for example, Windows Task Scheduler can be used to create a task that runs MyGeotabAPIAdapter.exe on server startup. |
With the growing prevalence of cloud computing platforms, questions may arise from those seeking to build integrations that bring Geotab data into such platforms. Although this guide provides instructions that can be used to deploy the MyGeotab API Adapter solution within any number of different cloud computing platforms, integrators may strive to automate such deployments to the greatest extent possible.
In order to demonstrate semi-autonomous deployment of the MyGeotab API Adapter solution into a cloud platform environment, an example has been created using Microsoft Azure as the cloud platform host. For more information, refer to the MyGeotab API Adapter - Guide for Deploying to Microsoft Azure guide.
Adding support for additional database types should be very straightforward as a result of the fact that the MyGeotab API Adapter solution incorporates a repository pattern to abstract database interaction from business logic (see the Solution Architecture section for more detail). To add support for another type of database:
1 | Replicate the PostgreSQL adapter database schema for the subject database type. Refer to the Data Dictionary section for schema information. Note that data types may differ between database providers and it is important to assign field data types based on the closest match. |
2 | For the MyGeotabAPIAdapter.Database project, use NuGet Package Manager to incorporate the .NET data provider for the subject database type. |
3 | Modify the ConnectionInfo class in the MyGeotabAPIAdapter.Database project:
|
4 | Modify the DatabaseProviderType and DatabaseConnectionString settings in the DatabaseSettings section of the appsettings.json file. Note that the value supplied for the DatabaseProviderType setting should be one of the constants defined for the DataAccessProviderType enum in the ConnectionInfo class (detailed in the previous step). |
5 | In the SqlMapperExtensions class in the MyGeotabAPIAdapter.Database project (under DataAccess > Dapper), modify the ... string connectionProviderType = connection.GetType().Namespace; switch (connectionProviderType) { case "Npgsql": sql = $"select * from \"{name}\" limit {resultsLimit}"; break; case "Microsoft.Data.SqlClient": case "System.Data.SqlClient": sql = $"select top ({resultsLimit}) * from \"{name}\""; break; default: throw new NotImplementedException($"Support for the '{connectionProviderType}' connection provider type has not been implemented in this method."); } ... |
After completing these steps, the adapter should have no issues utilizing an instance of the target database type; there should be no need to modify any code within the solution.
Since the MyGeotab API Adapter solution essentially extracts data from a MyGeotab database and writes it to the adapter database, the MyGeotab SDK and API Reference pages along with the Data Dictionary section of this document should provide the information needed to understand the data. This section includes some examples to augment the aforementioned documentation and provide some insight into ways that data may be queried from the adapter database to address common questions.
Keeping in mind the fact that the adapter database is intended to be an intermediary rather than the actual data warehouse to be queried by applications (as described in the Database Maintenance and Suggested Strategy sections), the queries in these examples have been kept very simple.
This example demonstrates how to find ExceptionEvents associated with a specific Rule. In this case, the objective is to find all occurrences of hard acceleration.
In the MyGeotab database with which the adapter is associated, the target Rule is named Hard Acceleration as shown in this screenshot from the MyGeotab user interface:
Knowing that the target Rule is named “Hard Acceleration”, query the Rules table to find the Id of the subject Rule.
Query:
select * from "Rules"
where "Name" = 'Hard Acceleration';
Result:
The result reveals that:
CAUTION! Customers often create custom Rules - either by modifying stock Rules or by creating entirely new Rules. Custom Rules have unique Ids on a per MyGeotab database basis. As such, when developing an integration, it is important to verify with the customer which Rules are to be used; do not assume that the stock Rules are the ones being used by the customer.
Having identified the Rule Id, it is possible to discover exactly which Conditions form the Rule.
Query:
select * from "Conditions"
where "RuleId" = 'RuleJackrabbitStartsId';
Result:
The result reveals that:
In the previous section, the condition is based on a value of 4.05995315167102, but the UnitOfMeasure is still unknown. It can be obtained by retrieving the subject Diagnostic.
Query:
select * from "Diagnostics"
where "GeotabId" = 'DiagnosticAccelerationForwardBrakingId';
Result:
The result reveals that:
With the information gathered in the previous steps, it is now possible to find all occurrences of Hard Acceleration Rule violations that have been written to the adapter database and have the detail needed for display in a dashboard or consumption by an external application.
Query:
select * from "ExceptionEvents"
where "RuleId" = 'RuleJackrabbitStartsId';
Result:
With the result set, in addition to the times and durations of Hard Acceleration Rule violations, it is possible to use the DeviceId and DriverId values for a given ExceptionEvent to find the associated Device/Vehicle and Driver/User by querying the Devices table and Users table, respectively.
ExceptionEvents do not include location information to indicate where they have occurred. This is because location information is available through LogRecord (GPS data) objects which come through a separate data feed. To find the location of an ExceptionEvent (or locations, if the ExceptionEvent occurred over an extended period of time), the LogRecords table can be queried using the DeviceId, ActiveFrom and ActiveTo values of the subject ExceptionEvent.
Query:
select * from "LogRecords"
where "DeviceId" = 'b2'
and "DateTime" >= '2017-07-21 23:15:44.033'
and "DateTime" <= '2017-07-21 23:15:46.12';
Result:
In this example, a single LogRecord is returned showing the location and speed of the vehicle at the time of the ExceptionEvent.
This section demonstrates how to obtain the OBD-II Diagnostic Trouble Code (DTC) associated with a record in the FaultData table.
The following example of a record from the FaultData table will be used to demonstrate how to retrieve the OBD-II DTC.
Query the Diagnostics table to retrieve the Diagnostic associated with the subject FaultData.
Query:
select * from "Diagnostics" where "GeotabId" = 'aq0_bgE84UkqEYS3Q3W4bfQ';
Result:
If the DiagnosticSourceId is “SourceObdId” or “SourceObdSaId”, which it is in this case, the OBD-II DTC can be found in the OBD2DTC field: P0135 in this example.
This section demonstrates how to obtain the J1939 Failure Mode Identifier (FMI) and Suspect Parameter Number (SPN) associated with a record in the FaultData table.
The following example of a record from the FaultData table will be used to demonstrate how to retrieve the J1939 FMI and SPN.
Query the Diagnostics table to retrieve the Diagnostic associated with the subject FaultData.
Query:
select * from "Diagnostics" where "GeotabId" = 'awwZOakD61kWrgEiPnuKQ2g';
Result:
If the DiagnosticSourceId is “SourceJ1939Id”, which it is in this case:
This example demonstrates how information related to DVIRLogs may be queried from the adapter database.
The DVIRLogs table can be queried to retrieve DVIRLogs that have been obtained from the MyGeotab database.
Query:
select * from "DVIRLogs";
Result:
The result above is for a single DVIRLog record and reveals that:
A list of all defects associated with the DVIRLog examined in the previous section can be retrieved from the DVIRDefects table.
Query:
select * from "DVIRDefects"
where "DVIRLogId" = 'ataVQAlKkJECxathrw3valg';
Result:
The result reveals that:
Any comments that are associated with the DVIRDefect identified in the previous section can be retrieved from the DVIRDefectRemarks table.
Query:
select * from "DVIRDefectRemarks"
where "DVIRDefectId" = 'a88gGjG0ye0KFs3DamizpWA'
order by "DateTime";
Result:
The result shows that the user provided some additional information about the DVIRDefect:
This section demonstrates usage of the DutyStatusAvailabilities table in the adapter database.
The Geotab API's GetFeed method does not support the DutyStatusAvailability entity type and the results for DutyStatusAvailability Get requests are calculated dynamically, resulting in longer response times than are typical for pre-calculated data. It is also necessary to retrieve DutyStatusAvailability on a per-driver basis using batches of Get requests wrapped in MultiCall requests (in order to support larger fleets where the number of Get<DutyStatusAvailability> requests required to cover all drivers could not be made in a single MultiCall request). The result of the combination of these factors is that it can take some time for DutyStatusAvailability to be retrieved for all drivers in a fleet.
In order to avoid slowing the flow of data for other feeds, DutyStatusAvailability is handled by a separate worker service running in parallel to the main worker service and acting as a pseudo data feed to populate the DutyStatusAvailability table in the adapter database. This service runs in parallel to the main Worker service if the enableDutyStatusAvailabilityDataFeed setting in appsettings.json is set to true.
WARNING! Duration values in the DutyStatusAvailability table are inaccurate (out-of-date). The amount of inaccuracy can be defined as the duration between the value of the RecordLastChangedUtc field and the current time, in Coordinated Universal Time (UTC). This offset must be applied to the duration values in order to improve currency of the data upon consumption. See below for details.
As a result of the pseudo data feed and inherent time required to update DutyStatusAvailability records for all drivers, by the time the last driver’s record is being updated, minutes may have elapsed since the first driver’s record was updated. The amount of time elapsed since a record was last updated will depend on a number of factors - particularly the number of drivers in the fleet.
The following example of a record from the DutyStatusAvailabilities table will be used to demonstrate how to work with data in this table. For this scenario, the objective is to determine how much driving and on-duty time a particular driver has remaining in the day.
Let’s assume that the current UTC date and time is 2021-01-15 14:35:00. Driving and on-duty time remaining can be determined using the following steps:
1 | Convert the DrivingTicks and DutyTicks values into corresponding durations. The manner by which this is accomplished depends on the technology being used (e.g. in .NET, the TimeSpan.FromTicks method can be used). ✱ NOTE: A tick is equal to 100 nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond and 10 million ticks in a second. For brevity, only the calculated durations will be shown. This .NET Fiddle demonstrates conversion of ticks to TimeSpans (hours:minutes:seconds.milliseconds here).
|
2 | Calculate the elapsed time since the subject record was updated.
|
3 | Subtract the calculated offset from the Driving and Duty durations.
|
As determined above, in this example, the subject driver has twelve hours and thirty minutes of driving time and twelve hours and thirty-five minutes of on-duty time remaining in the day.
WARNING! Even if time offsets are calculated as noted above, availability values may occasionally still be inaccurate due to driver status changes that may occur in between successive updates.
This section demonstrates usage of the Trips table in the adapter database.
CAUTION! Unlike other entity types, with the MyGeotab Trip entity, the Id field is also used to store the Version of the entity. As a result, the Id of a given Trip will change with each update. What this means, from a MyGeotab API Adapter perspective, is that a single physical trip may be represented by multiple records in the Trips table - each with a different GeotabId. Read below for further details.
Unlike other entity types, with the MyGeotab Trip entity, the Id field is also used to store the Version of the entity. As a result, the Id of a given Trip will change with each update. Since the MyGeotab API Adapter can be configured to start at the current time or at some point in the past, there are some implications:
1 | When the adapter retrieves data for Trips that have already been completed (i.e. historical Trip data), each physical Trip will be represented by one record in the Trips table in the adapter database. |
2 | For an ongoing Trip that occurs while the adapter is running (i.e. live Trip data), each data update will be captured via the data feed and result in a new record being added to the Trips table in the adapter database. Each of the database records for the subject Trip will have a unique GeotabId. |
The MyGeotab API Adapter - Trips Table - Comparison of Live vs Historical Data [PUBLIC] spreadsheet will be used to illustrate the above-noted points because the Trips table contains too many columns to be adequately displayed directly in this document. Notes about the content of the spreadsheet:
Based on the information above, the following sections provide some insights to assist in using the Trips table.
A unique Trip can be identified by using the combination of DeviceId and Start. Bear in mind that Trips that occur while the MyGeotab API Adapter is running will have multiple records (as updates are reported during the ongoing Trip) - all with the same combination of DeviceId and Start. Therefore, if consolidating these into an external system where each Trip has a single record, it will be necessary to use the combination of DeviceId and Start to determine whether to insert a new Trip or update an existing one.
A completed trip will have a StopDurationTicks value greater than zero. This is because the StopDurationTicks is the duration (measured in ticks) the vehicle was stopped at the end of a Trip and can only be calculated once the next Trip starts.
Certain types of objects, such as LogRecord, StatusData and FaultData, contain Device information that can be used to identify the vehicle (using the VIN) to which they apply. However, it is often desirable to also know which Driver was associated with the Device at the time. This example demonstrates how data from the Trips table may be used to accomplish this objective.
In this scenario, the StatusData table contains a record with a DeviceId of b9F and a DateTime of 2020-07-20 19:32:07.039Z. The following query can be used to find the DriverId associated with the StatusData record.
Query:
select "DriverId" from "Trips"
where "DeviceId" = 'b9F' and "Start" <= '2020-07-20 19:32:07.039Z'
order by "Start" desc
limit 1;
Result:
Notes about the result:
As a member of the Connected Vehicle Systems Alliance (COVESA), Geotab is engaged in a project which facilitates alignment between automakers and data-oriented vendors. To support this initiative, the MyGeotab API Adapter has been modified to include the capability to translate LogRecord and StatusData records into a universal Vehicle Signal Specification (VSS) format and send them to an Open Vehicle Data Set (OVDS) server. This capability will benefit members of the Connected Vehicle Systems Alliance (COVESA) and related organizations, but will not be of interest to others. As such, it has been integrated in the form of an “Add-On'' that separates the code and functionality to the extent possible from the main solution.
For more information, refer to the MyGeotab API Adapter - Vehicle Signal Specification (VSS) Add-On - Solution and Implementation Guide.
This section tracks changes to the MyGeotab API Adapter solution over time by version number in reverse chronological order.
Any time a new release of the MyGeotab API Adapter is published to GitHub, an update will be posted to Geotab’s Integrator’s Hub. Click the Join Group button on the page to join and then choose the desired notification frequency (Every Post, Daily Digest, Weekly Digest, etc.)
Version 2.0.0 of the MyGeotab API Adapter solution introduces numerous under-the-hood enhancements aimed at dramatically boosting performance, throughput and resiliency while minimizing changes to database structures and application configuration files. Changes included in this version are listed below.
Significant enhancements to the MyGeotab API Adapter solution over the previous version are listed below.
When pairing the MyGeotab API Adapter and/or Data Optimizer applications with a SQL Server database, records are now automatically inserted, updated and deleted using bulk operations. This dramatically increases throughput capability of the system. For example, whereas it may have previously taken 15-20 seconds to insert a batch of 50,000 records into the StatusData table, that same operation might now be accomplished in 1-2 seconds. When using any of the other supported database types, the traditional insert, update and delete methods are used.
Previously, the API Adapter application managed all caches and data feeds through a single physical service. While Geotab API calls were executed in parallel, performance of the overall service was limited to that of the slowest data feed. In this new release, each cache or feed processor is separated into its own physical service, providing a much greater degree of parallelism, better performance and options for splitting the application across multiple servers.
With the massive amounts of data being written to databases by the API Adapter and Data Optimizer, transient exceptions may be encountered. These include things such as occasional timed-out database commands or deadlocks when multiple services attempt to operate on the same records at the same time. Additional resilience has been built into the MyGeotab API Adapter solution to handle these sorts of situations - allowing the API Adapter and Data Optimizer to continue running uninterrupted. This has been accomplished through the incorporation of Polly to provide timeout and retry capabilities for database commands and transactions.
Indexes have been added to the columns in the adapter database tables that are used to identify record age (i.e. "Date", "RecordLastChangedUtc" or "RecordCreationTimeUtc", depending on the table). This was done to facilitate greater performance of deletion operations when moving data to the optimizer database - fueling greater overall performance and throughput. It also serves to benefit those who may be moving data to their own data lakes or external systems, following the Suggested Strategy outlined in the Database Maintenance section of this document.
It is now possible to enable or disable individual “cache” services using the Enable<EntityType>Cache
settings in the AppSettings - Caches section of the appsettings.json file. This is useful in cases such as the example where there is only an interest in obtaining LogRecords and the Device cache is the only cache that needs to be enabled.
A State property was recently added to the ExceptionEvent object to provide the ability to know when ExceptionEvents have become invalidated. New State and LastModifiedDateTime columns have been added to the ExceptionEvents table in the adapter database to capture this information.
This section provides information related to changes that may impact existing implementations. These include database schema changes, configuration file changes and source code changes.
As a result of increased parallelism introduced in this version, the MyGeotab API Adapter can no longer support SQLite as one of the database options as attempts to use it would result in database locking exceptions. See https://www.sqlite.org/whentouse.html for more details on SQLite suitability. Note that SQL Server, PostgreSQL and Oracle databases all have free options available for development/testing purposes.
The following changes were made to the appsettings.json configuration file associated with the MyGeotab API Adapter application:
An extensive refactoring exercise was undertaken in order to achieve the Major Enhancements noted above. This resulted in many changes to the source code. A best effort has been made to categorize these changes below:
With the introduction of the Data Optimizer in version 1.5.0.0, overall complexity of the solution increased and instead of largely writing data to one database table at a time, it became necessary to execute multiple inserts, updates and deletes in a single “batch”. To facilitate management of database transactions and ensure data integrity, a Unit of Work (UOW) pattern was introduced into the Data Optimizer project within the solution. This UOW approach has now been extended to include the API Adapter project as well.
Adoption of the UOW approach facilitated related changes that have combined to simplify data access. These include:
In order to simplify the overall solution and facilitate easier modification and enhancement in the future, a Dependency Injection (DI) pattern was implemented. This resulted in numerous additional supporting projects being added to the solution with functionality split-out into smaller classes with associated interfaces.
Previously, there was a single Worker service that handled retrieval and processing of Geotab data for all caches and feeds configured in the appsettings.json file. While data retrieval and write tasks were executed in parallel tasks, the speed of each execution loop of the Worker service was limited by the slowest object type to complete processing. Each Geotab object type, whether classified as “feed type” or “cache type”, now has its own dedicated service that operates autonomously from the others. This provides for a much greater degree of parallelism and throughput.
While these services are able to run independently, there are certain logical interdependencies related to the Geotab objects being processed. For example, the LogRecord has a Device property which indicates which Device a LogRecord is from. Therefore, if LogRecords are being extracted, it is also necessary to extract Devices. As such, the LogRecordProcessor includes logic that prevents it from running if the DeviceProcessor is not running. In the event that the LogRecordProcessor is enabled but the DeviceProcessor is disabled, warning messages are written to the log file to make it abundantly clear that the DeviceProcessor also needs to be enabled. This type of logic is applied across all of the services.
In order to reduce duplication of code while increasing reusability and maintainability of the overall solution, generic classes have been developed and incorporated extensively. These include, but are not limited to:
Given the decoupled design inherent in the implementation of the Dependency Injection (DI) pattern and the splitting-out of the Worker service into multiple Geotab object-focused services, there are many instances where classes need to be used by multiple other classes throughout the application. In order to maximize efficiency and avoid unnecessary duplication (and resource utilization), the Singleton pattern has been implemented where warranted. These can be identified via the “.AddSingleton” calls in the CreateHostBuilder method of the Program.cs file (in the MyGeotabAPIAdapter or the MyGeotabAPIAdapter.DataOptimizer projects).
To illustrate, caches of Geotab objects and corresponding database objects for “reference data” types are set-up as singletons. For example, a single OptimizerGenericDbObjectCache class is instantiated to hold an in-memory cache of DbDeviceT objects. This single instance is then shared by the BinaryDataProcessor, DeviceProcessor, DriverChangeProcessor, FaultDataProcessor, LogRecordProcessor and StatusDataProcessor classes.
Other source code changes, many of which are related to the changes outlined in the previous sections, include the following: