Implementation Guide

0 mins to read

Solution and Implementation Guide

Latest Update: 2024-05-24

Table of Contents

Revision History

Refer to the Change Log section for information about changes to the MyGeotab API Adapter solution and this document.

Introduction

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.

Data Optimizer - Taking the Adapter to the Next Level!

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.

Demo - Near Real-Time Flow of Data Into the Adapter Database

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.

document Image

MyGeotab API Adapter Highlights

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:

Efficiency

  1. The number of MyGeotab API calls being made has been minimized via use of data feeds and caching to the extent possible.
  2. Chattiness with the MyGeotab API Adapter database has also been minimized.
  3. Asynchronous methods and parallel processing have been incorporated where possible.

Data Integrity

  1. Feed tokens are tracked and persisted to the MyGeotab API Adapter database.
  2. Write operations are executed within transactions to ensure all-or-none processing of FeedResult batches and tokens for individual feeds are persisted to the database only upon successful commit.
  3. Feeds will continue from the last feed versions upon restart of the MyGeotab API Adapter for any reason.
  4. Safeguards are in-place to prevent missing or duplicating data or inadvertently mixing data from multiple MyGeotab databases.

Database-Agnosticity

  1. The Dapper ORM (https://github.com/StackExchange/Dapper, https://dapper-tutorial.net/) is used to map .NET objects to rows in corresponding database tables.
  2. A repository pattern has been used - separating data-access code from application logic.
  3. A MyGeotab API Adapter database schema has been created for SQL Server (also Azure SQL), PostgreSQL and Oracle and it is possible to switch between them by simply changing the database connection information in appsettings.json.

Resilience

  1. Mechanisms are in place to allow the MyGeotab API Adapter to continue operation if connectivity is lost either to the MyGeotab API or to the adapter database (e.g. planned maintenance, network issue, etc.) - in such events, the MyGeotab API Adapter will continuously try reconnecting and will resume where it left off once connectivity is re-established. Any partially completed operations are rolled-back and re-executed as noted under the Data Integrity point.

Configurability

  1. Via appsettings.json, it is possible to configure the MyGeotab API Adapter at a very granular level:
    1. Feeds can be configured for individual object types (LogRecord, StatusData, FaultData, Trip, ExceptionEvent, DVIRLog).
    2. Feed intervals can be set at a per-feed level.
    3. Individual feeds can be enabled or disabled as required.
    4. Update and refresh intervals can be set for individual caches of various object types (which also utilize feeds where available), including Controller, Device, Diagnostic, Defect, FailureMode, Group, Rule, UnitOfMeasure, User and Zone.
    5. Feed results may be filtered for specific devices and/or diagnostics so that only the data required for a given instance will be persisted to the adapter database.
    6. Feeds can be started at the current time, a specific time or based on feed version, thereby enabling consumers to pull as little or as much data as desired into the adapter database.
    7. The above configuration options allow the MyGeotab API Adapter to reduce the number of MyGeotab API calls to only those that are required to meet the needs of a specific end-customer implementation, thereby easing the load on the MyGeotab platform as the solution is deployed for many customers.

Deployment Model

  1. The MyGeotab API Adapter can be published using the self-contained deployment model targeting any supported runtime.
  2. The solution is intended to be deployed on the basis of having one copy of the MyGeotab API Adapter with a paired adapter database per MyGeotab database.

Logging

  1. NLog has been incorporated as the logging mechanism.
  2. Log messages have been added strategically to assist with debugging issues once the solution has been deployed.
  3. Additional logging tools could be utilized for monitoring purposes.

Code Readability and Reusability

  1. One of the primary objectives in developing this solution was to ensure maximum reusability.
  2. In addition to creating this document, effort has been made to ensure extensive code commenting throughout in order to assist integrators.

Quick Start Guide

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.

Quick Start: Download and Deploy the MyGeotab API Adapter

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

  1. be deployed to various operating systems (Windows and Linux-based packages are included with each release published to GitHub);
  2. utilize a number of different database types (e.g. SQL Server, PostgreSQL, Oracle, etc.); and
  3. be modified to include new or altered capabilities.

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:

  1. MyGeotabAPIAdapter_SCD_win-x64.zip
  2. SQLServer.zip
  3. Once downloaded, extract the contents of the zip files.

2

Setup the database (following Steps 1-3 in the SQL Server database setup section):

    1. Create a SQL Server database named geotabadapterdb.
    2. Create a login named geotabadapter_client along with a user by the same name using the script provided in Step 2 of the SQL Server database setup section.
    3. Execute the database creation script, geotabadapterdb-DatabaseCreationScript.sql, which can be found in the SQLServer folder extracted from the SQLServer.zip file that was downloaded in Step 1.
  • 3

    Configure and deploy the MyGeotab API Adapter application (following Steps 1-4 in the Deploy section):

    1. Copy the MyGeotabAPIAdapter_SCD_win-x64 folder extracted from the MyGeotabAPIAdapter_SCD_win-x64.zip file that was downloaded in Step 1 to the machine on which the MyGeotab API Adapter application is to reside.
    2. Modify the appsettings.json file, contained in the above application folder, as needed. See the appsettings.json section for more information. Important settings are as follows:
      1. The DatabaseProviderType and DatabaseConnectionString settings in the DatabaseSettings section must be set so that the adapter application can connect to the adapter database using the login created in Step 2 of the database setup, above.
      2. The MyGeotabServer, MyGeotabDatabase, MyGeotabUser and MyGeotabPassword settings in the LoginSettings section must be set (ideally with the credentials of a service account) so that the adapter application can connect to the target MyGeotab database.
      3. In the AppSettings - GeneralFeedSettings section:
        1. Adjust the FeedStartOption setting, if desired (as well as the FeedStartSpecificTimeUTC setting, if FeedStartOption is set to SpecificTime).
        2. If there is a desire to limit data extracted from the MyGeotab system to a specific set of devices, adjust the DevicesToTrack setting. Note that MyGeotab Groups functionality may be used to achieve the same result.
        3. If there is a desire to extract StatusData and/or FaultData only for specific diagnostics, adjust the DiagnosticsToTrack setting.
      4. Enable or disable specific data feeds to pull only the desired data by adjusting the settings for individual feeds in the AppSettings - Feeds section.
    3. Review the nlog.config file, contained in the above application folder, and make any necessary changes. See the nlog.config section for more information.
      1. It should not be necessary to modify the nlog.config file; this step is only included to highlight the fact that modification of logging behaviour is possible.
    4. Start the MyGeotab API Adapter by running the MyGeotabAPIAdapter.exe file contained in the above application folder.
    5. 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.

  • Quick Start: Step-by-Step Demo Video

    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)

    Solution Information

    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.

    Solution Architecture

    The following diagram provides an overview of the MyGeotab API Adapter solution architecture.

    document Image

    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.

    Database

    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.

    List of Tables

    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:

    1. Feed data: Records in feed data tables generally consist of data points collected using data feeds and are not modified once written to the database. These tables can accumulate vast quantities of records within short periods of time. It is highly recommended to have a data management strategy - especially for tables in this category.
    2. Reference data: These tables generally contain user-added data. Values are referenced by GeotabId in the feed data tables. Records in reference data tables can change over time and only the latest version of each record is maintained. Record counts in reference data tables tend to be small and relatively stable over time.
    3. Commands: These tables are utilized for issuing data manipulation commands to the Geotab platform - for example, updating the repair status of DVIRDefects after related work orders have been completed in an external system. Rather than using the MyGeotab API Adapter to extract data from a MyGeotab database and then having to use the MyGeotab SDK to send updates back to the MyGeotab database, the details of these updates can simply be inserted as rows into the relevant commands tables and the adapter will take care of the SDK-related work.
    4. Command exceptions: For each commands table, there will be an associated command exceptions table. If a row is inserted into the commands 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 commands table will be added to the command exceptions table along with the related error message. This is to assist in debugging and to provide feedback that would otherwise be provided in the responses to commands issued via the MyGeotab SDK.
    5. System info: These tables are used by the adapter and do not offer any other specific benefit.
  • 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

    BinaryData

    Feed data

    Contains data corresponding to MyGeotab BinaryData objects.

    ChargeEvents

    Feed data

    Contains data corresponding to MyGeotab ChargeEvent objects.

    Conditions

    Reference data

    Contains data corresponding to MyGeotab Condition objects.

    DebugData

    Feed data

    Contains data corresponding to MyGeotab DebugData objects.

    Devices

    Reference data

    Contains data corresponding to MyGeotab Device objects.

    DeviceStatusInfo

    Reference data

    Contains data corresponding to MyGeotab DeviceStatusInfo objects.

    Diagnostics

    Reference data

    Contains data corresponding to MyGeotab Diagnostic objects.

    DriverChanges

    Feed data

    Contains data corresponding to MyGeotab DriverChange objects.

    DutyStatusAvailabilities

    Reference data

    Contains data corresponding to MyGeotab DutyStatusAvailability objects.

    DutyStatusLogs

    Feed data

    Contains data corresponding to MyGeotab DutyStatusLog objects.

    DVIRDefectRemarks

    Reference data

    Contains data corresponding to MyGeotab DefectRemark objects.

    DVIRDefects

    Reference data

    Contains data corresponding to defects associated with DVIRLogs. It includes data derived from MyGeotab DVIRLog, DVIRDefect, Defect and Group objects.

    DVIRDefectUpdates

    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.

    DVIRLogs

    Feed data

    Contains data corresponding to MyGeotab DVIRLog objects.

    ExceptionEvents

    Feed data

    Contains data corresponding to MyGeotab ExceptionEvent objects.

    FailedDVIRDefectUpdates

    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.

    FaultData

    Feed data

    Contains data corresponding to MyGeotab FaultData objects.

    LogRecords

    Feed data

    Contains data corresponding to MyGeotab LogRecord objects.

    MyGeotabVersionInfo

    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.

    OServiceTracking

    System info

    System table used by the MyGeotab API Adapter.

    Rules

    Reference data

    Contains data corresponding to MyGeotab Rule objects.

    StatusData

    Feed data

    Contains data corresponding to MyGeotab StatusData objects.

    Trips

    Feed data

    Contains data corresponding to MyGeotab Trip objects.

    Users

    Reference data

    Contains data corresponding to MyGeotab User objects.

    ZoneTypes

    Reference data

    Contains data corresponding to MyGeotab ZoneType objects.

    Zones

    Reference data

    Contains data corresponding to MyGeotab Zone objects.

    Data Dictionary

    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.

    “GeotabId” and “id” Columns

    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.

    BinaryData

    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.


    ChargeEvents

    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.


    Conditions

    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.

    DebugData

    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.

    Devices

    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.

    DeviceStatusInfo

    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.

    Diagnostics

    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.

    DriverChanges

    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.

    DutyStatusAvailabilities

    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.


    DutyStatusLogs

    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

    The DutyStatusDeferralType.

    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.


    DVIRDefectRemarks

    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.

    DVIRDefects

    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.

    DVIRDefectUpdates

    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.

    DVIRLogs

    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

    The date and time the Device or Trailer was repaired.

    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.

    ExceptionEvents

    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.

    FailedDVIRDefectUpdates

    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.

    FaultData

    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.

    LogRecords

    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.

    MyGeotabVersionInfo

    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.


    OServiceTracking

    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.

    Rules

    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.

    StatusData

    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.

    Trips

    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.

    Users

    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.

    ZoneTypes

    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.

    Zones

    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.

    Configuration Files

    Two files, explained below, are used to configure the MyGeotab API Adapter - appsettings.json and nlog.config.

    Service Interdependencies

    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

    appsettings.json

    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.

    Environment Variables for DatabaseSettings and LoginSettings

    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 “__”):

    document Image

    OverrideSettings

    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!


    DatabaseSettings

    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. Server=<Server>;Database=geotabadapterdb;User Id=geotabadapter_client;Password=<password>;MultipleActiveResultSets=True;TrustServerCertificate=True).

    LoginSettings

    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.

    AppSettings - GeneralSettings

    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.

    AppSettings - Caches

    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:

    1. Enable<EntityType>Cache: Indicates whether the cache for the subject entity type should be enabled. Must be set to either true or false.
    1. <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).
    2. <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).
    3. <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).

    Cache Configuration Example

    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:

    1. EnableUserCache: true
    1. UserCacheIntervalDailyReferenceStartTimeUTC: 2020-06-23T06:00:00Z
    2. UserCacheUpdateIntervalMinutes: 360
    3. UserCacheRefreshIntervalMinutes: 1440

    ! 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.

    AppSettings - Caches - Controller

    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).

    AppSettings - Caches - Device

    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).

    AppSettings - Caches - Diagnostic

    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).

    AppSettings - Caches - DVIRDefect

    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).

    AppSettings - Caches - FailureMode

    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).

    AppSettings - Caches - Group

    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).

    AppSettings - Caches - Rule

    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).

    AppSettings - Caches - UnitOfMeasure

    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).

    AppSettings - Caches - User

    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).

    AppSettings - Caches - Zone

    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).

    AppSettings - Caches - ZoneType

    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).

    AppSettings - GeneralFeedSettings

    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:

    1. CurrentTime: Data feeds will be started from the current point in time.
    2. SpecificTime: Data feeds will be started at the specific point in time (in the past) specified by the FeedStartSpecificTimeUTC parameter.
    3. FeedVersion: Each data feed will be started at the specific version captured in the OServiceTracking table in the adapter database. If the data feed for a specific object type has not yet been run, it will start at version zero, effectively allowing the feed to pull all of the respective data from the database.
    4. 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.

    AppSettings - Feeds

    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:

    1. Enable<EntityType>Feed: Indicates whether the data feed for the subject entity type should be enabled. Must be set to either true or false.
    2. <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).
  • AppSettings - Feeds - BinaryData

    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).


    AppSettings - Feeds - ChargeEvent

    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).

    AppSettings - Feeds - DebugData

    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).

    AppSettings - Feeds - DeviceStatusInfo

    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).

    AppSettings - Feeds - DriverChange

    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).

    AppSettings - Feeds - DutyStatusAvailability

    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.


    AppSettings - Feeds - DutyStatusLog

    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).


    AppSettings - Feeds - DVIRLog

    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).

    AppSettings - Feeds - ExceptionEvent

    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.

    AppSettings - Feeds - FaultData

    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).

    AppSettings - Feeds - LogRecord

    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).

    AppSettings - Feeds - StatusData

    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).

    AppSettings - Feeds - Trip

    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).

    AppSettings - Manipulators

    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.

    AppSettings - Manipulators - DVIRLog

    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).

    AppSettings - AddOns - VSS

    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.

    nlog.config

    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" >

    <targets>

    maxArchiveFiles="100" archiveAboveSize="5120000" archiveEvery="Day">

    <layout xsi:type="CsvLayout" delimiter="Pipe" withHeader="true">

    <column name="Time" layout="${longdate}" />

    <column name="Level" layout="${level:upperCase=true}"/>

    <column name="Message" layout="${message}" />

    <column name="Exception" layout="${exception}"/>

    <column name="Logger" layout="${logger}" />

    <column name="All Event Properties" layout="${all-event-properties}" />

    </layout>

    </target>

    layout="${date}|${level:uppercase=true}|${message} ${exception}|${logger}|${all-event-properties}" />

    </targets>

    <rules>

    minlevel="Info" writeTo="target1,target2" />

    </rules>

    </nlog>

    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:

    1. Day: Archive daily.
    2. Hour: Archive every hour.
    3. Minute: Archive every minute.
    4. Month: Archive every month.
    5. None: Don't archive based on time.
    6. Year: Archive every year.
    7. Sunday: Archive every Sunday.
    8. Monday: Archive every Monday.
    9. Tuesday: Archive every Tuesday.
    10. Wednesday: Archive every Wednesday.
    11. Thursday: Archive every Thursday.
    12. Friday: Archive every Friday.
    13. Saturday: Archive every Saturday.
  • minlevel

    Indicates the log level, which is the amount of detail to be written to log files. Default: Debug.

    Possible values:

    1. Trace: Very detailed logs, which may include high-volume. information such as protocol payloads. This log level is typically only enabled during development.
    2. Debug: Debugging information, less detailed than trace, typically not enabled in a production environment.
    3. Info: Information messages, which are normally enabled in a production environment.
    4. Warn: Warning messages, typically for non-critical issues, which can be recovered or which are temporary failures.
    5. Error: Error messages - most of the time these are Exceptions.
    6. Fatal: Very serious errors!
  • Application Logic

    The high-level application logic of the MyGeotab API Adapter solution is represented in the following exhibit:

    document Image

    Solution Usage and Implementation

    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.

    Prerequisites

    The MyGeotab API Adapter requires:

    1. .NET 8.0 SDK (https://dotnet.microsoft.com/download) or higher. Note: If simply deploying a published release, the deployment package is self-contained (including all dependencies), so .NET version(s) of the host machine should not be a concern.
    2. The following (included via NuGet packages):
      1. Geotab.Checkmate.ObjectModel
      2. Dapper
        1. FastMember
    3. Microsoft.Data.SqlClient
    4. NLog.Extensions.Logging
    5. Npgsql
    6. Oracle.ManagedDataAccess.Core
    7. Polly
  • MyGeotab credentials with all “View” clearances enabled on any MyGeotab database with which the MyGeotab API Adapter is to be used. It is recommended that a Service Account be set-up for this purpose. See the Service Account Guidelines document for more details. Specific clearances required by the service account used by the MyGeotab API Adapter include:
    1. List devices
    2. List Users/Drivers
    3. View Asset Inspection logs
    4. View binary data
    5. View device status information
    6. View engine diagnostics
    7. View engine failure modes
    8. View engine measurement related features
    9. View engine units of measurement
    10. View exception rules
    11. View exceptions
    12. View groups
    13. View trailers
    14. View zones
  • If the DVIRLog Manipulator is going to be used, the following clearances are also required:
    1. Administer Asset Inspection logs
    2. Mark Asset Inspection logs as certified
    3. Mark Asset Inspection logs as repaired
    4. Perform Asset Inspections
  • If PostgreSQL is the chosen database provider, access to a PostgreSQL 16 (or greater) server on which the adapter database is deployed.
    1. If the adapter and database will reside on separate servers, it may be necessary to ensure that appropriate security and networking steps are undertaken to ensure the ability of the adapter to interact with the database.
    2. Although not a strict requirement, it is recommended to have access to a tool such as pgAdmin to view data that the adapter writes to the database.
  • If SQL Server is the chosen database provider, access to a MS SQL Server instance on which the adapter database is deployed. While developed using SQL Server 2019 Developer (version 15.0.2000.5), given that the solution uses only simple tables and views, it is likely to work on other SQL Server versions without any issues.
    1. If the adapter and database will reside on separate servers, it may be necessary to ensure that appropriate security and networking steps are undertaken to ensure the ability of the adapter to interact with the database.
    2. Although not a strict requirement, it is recommended to have access to a tool such as SQL Server Management Studio to view data that the adapter writes to the database.
  • If Oracle is the chosen database provider, access to an Oracle instance on which the adapter database is deployed. Note that Oracle Database XE (18c) was initially used for MyGeotab API Adapter development.
    1. If the adapter and database will reside on separate servers, it may be necessary to ensure that appropriate security and networking steps are undertaken to ensure the ability of the adapter to interact with the database.
    2. Although not a strict requirement, it is recommended to have access to a tool such as Oracle SQL Developer to view data that the adapter writes to the database.
  • Getting Started

    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.

    Database Setup

    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.

    PostgreSQL

    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 <Password> with the desired password):

    CREATE ROLE geotabadapter_owner WITH

    LOGIN

    NOSUPERUSER

    INHERIT

    NOCREATEDB

    NOCREATEROLE

    NOREPLICATION

    PASSWORD '<Password>';

    2

    Create the geotabadapter_client user using the following script (first replacing <Password> with the desired password):

    CREATE ROLE geotabadapter_client WITH

    LOGIN

    NOSUPERUSER

    INHERIT

    NOCREATEDB

    NOCREATEROLE

    NOREPLICATION

    PASSWORD '<Password>';

    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).

    SQL Server

    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 <Password> with the desired password):

    USE [master];

    CREATE LOGIN [geotabadapter_client] WITH

    PASSWORD=N'<Password>',

    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).

    Oracle

    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 <password> with the desired password):

    CREATE USER GeotabAdapter_Client IDENTIFIED BY "<password>"

    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.

    Other

    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.

    Database Maintenance

    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.

    Suggested Strategy

    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).

    1. It should have a set of tables similar to those in the adapter database where the “raw data” from the adapter database may be inserted.
    2. Additional tables and views can then be created to support indexing, aggregation and merging with data from other systems.

    3

    Build an ETL or polling mechanism that continually monitors the adapter database to capture new data and add it to the DWH.

    1. For tables in the Reference data category in the List of Tables, the RecordLastChangedUtc field can be used to compare values in the adapter database with those in the DWH to identify changed records.
      1. NOTE: The EntityStatus field indicates whether the corresponding object is active (1) or deleted (0) in the Geotab system; if objects are deleted on the Geotab side, it may require action to be taken.
    2. For tables in the Feed data category in the List of Tables, the RecordCreationTimeUtc field can be tracked on a per-table basis. A single timestamp is applied to all records in a batch of data being written to a given table. Once the new records have been added to the DWH, the records with the subject timestamp can be deleted from the table in the adapter database without risk of deleting any new records that may be added during processing.
      1. WARNING! When deleting records from tables in the adapter database, the id column values (NOT the GeotabId) should be used to identify the records to be deleted. This is both to maintain optimal performance and to avoid database concurrency/contention issues that could otherwise arise when trying to delete records while the adapter is actively inserting/updating records. See the GeotabId” and “Id” Columns section for more information.
      2. ! IMPORTANT: By deleting records from the adapter database once they have been added to the DWH, it is possible to avoid the potential disk space and performance issues that may arise when the feed data tables grow to contain millions of records.
  • 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.

    Data Optimizer to the Rescue!

    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).

    Minimum Interval Sampling

    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.

    Minimum Interval Sampling for LogRecords

    With regard to LogRecords, minimum interval sampling is applied on a per-Device basis and can be enabled based on the following rules:

    1. EnableLogRecordFeed must be set to true.
    2. EnableDeviceCache must be set to true. This is because the LogRecordProcessor requires the DeviceCache to be operational.
    3. EnableMinimunIntervalSamplingForLogRecords must be set to true. Otherwise, normal processing of LogRecords will occur.
    4. MinimumIntervalSamplingIntervalSeconds must be set to a value ranging from 1 through 3600.
    5. [Optional] DevicesToTrack can be used to limit the collection of LogRecords to a specific set of devices.

    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:

    1. The LogRecords table in the adapter database will be populated with data for all devices (that the MyGeotab user configured in the LoginSettings section of appsettings.json has access to).
    2. The minimum interval between successive LogRecords for a given device will be 300 seconds (5 minutes).
    3. Minimum Interval Sampling for StatusData

      With regard to StatusData, minimum interval sampling is applied on a per-Device + Diagnostic basis and can be enabled based on the following rules:

      1. EnableStatusDataFeed must be set to true.
      2. EnableDeviceCache and EnableDiagnosticCache must both be set to true. This is because the StatusDataProcessor requires the DeviceCache and DiagnosticCache to be operational.
      3. EnableMinimunIntervalSamplingForStatusData must be set to true. Otherwise, normal processing of StatusData will occur.
      4. MinimumIntervalSamplingIntervalSeconds must be set to a value ranging from 1 through 3600.
      5. DiagnosticsToTrack must be set to a comma-separated list of Diagnostic Ids. The default wildcard (*) value cannot be used if EnableMinimunIntervalSamplingForStatusData is set to true.
      6. ExcludeDiagnosticsToTrack must be set to false if EnableMinimunIntervalSamplingForStatusData is set to true.
      7. MinimumIntervalSamplingDiagnostics must be set to a comma-separated list of Diagnostic Ids that is either the same as the list provided in DiagnosticsToTrack, or a subset thereof. Minimum interval sampling will only be applied to StatusData records with Diagnostic Ids that are in this list. Normal processing will occur for StatusData records with Diagnostic Ids that are in the DiagnosticsToTrack list but not in the MinimumIntervalSamplingDiagnostics list.
      8. [Optional] DevicesToTrack can be used to limit the collection of LogRecords to a specific set of devices.

      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:

    4. The StatusData table in the adapter database will be populated with data for all devices (that the MyGeotab user configured in the LoginSettings section of appsettings.json has access to).
    5. Only StatusData records with the DiagnosticOilPressureId, DiagnosticIgnitionId and DiagnosticEngineRoadSpeedId Diagnostic Ids will be collected.
    6. All StatusData records with the DiagnosticIgnitionId Diagnostic Id will be collected.
    7. For StatusData records with the DiagnosticOilPressureId and DiagnosticEngineRoadSpeedId Diagnostic Ids, the minimum interval between successive StatusData records for a given device will be 300 seconds (5 minutes).

    DVIRLog Manipulator

    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.

    Capabilities

    Using the DVIRLog Manipulator, it is possible - without directly using the MyGeotab API - to:

    1. Add repair remarks to existing DVIRDefects
    2. Change the repair status of existing DVIRDefects

    End-to-End Bidirectional Workflow Scenario

    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 correcti