A robust Application Programming Interface for communicating data directly to various customer and vendor integrations |
DriverTech offers an API to allow Clients to use their own back end systems instead of or in addition to the FleetWatcher Web Portal. This API, known as the FleetWatcher API, is comprised of secure enterprise ready Web Services hosted by servers and networks designed for high availability. The services included in the FleetWatcher API are based upon the same core types as defined in the XSD/WSDL ensuring consistency. Also included is verbose error and exception reporting to speed initial development and enhance the ability to resolve problems programmatically. Service Detail |
Release History | Service | Version | Rev. Date |
---|
Administration | 2.0.80 | 02/02/2015 | Data v2.1 | 2.1.40 | 02/02/2015 | Data v2.0.Test | 2.0.80 | 05/21/2013 | Data v2.0 | 2.0.76 | 12/12/2013 | Data v1.4 | 1.4.50 | 05/20/2013 | Reports | 2.0.75 | 05/20/2013 | PreRelease | 2.0.75 | 05/20/2013 |
|
|
Should you have any questions regarding the services or need assistance please contact Web Service Support via Email
Feel free to contact us for assistance in getting the most out of these Services!
Documentation is provided in the following locations:
- On each service page - Top Level Operation Information
- Within the XSD via annotations - Low Level Detail
You may find this XSD Primer XSD Primer helpful - Other documents referenced by the service pages - White papers, etc
Tools and Utilities
Applications which can display an XSD Graphically:
During development of web services it can be very valuable to issue test requests before writing any code:
Data Sourcing Strategies
To prevent disruption by both intentional and unintentional DOS type of 'attacks' your requests will be rate limted as follows:
- Inbound (from Device->DataCenter->You) data requests by Company+User+Operation to not more than 1 every 1000ms
- Outbound (from You->DataCenter->Device) is rate-limited by Company+User+Operation to not more than 1 every 300ms
Guidelines for continual polling of various data types
Type | Recommended | Maximum Frequency | Notes |
DataService: InboundMessages | 5 minutes | 1 minutes | Drain Queue processing may be applied |
DataService: InboundFiles | 10 minutes | 1 minutes | Drain Queue processing may be applied |
DataService: TrailerEvents | varies | 1 minutes | Drain Queue processing may be applied |
DataService: HosTotals | 1 hours | 1 minutes | HosTotals can be continually calculated on the client between polling intervals Its possible to retreive only those which have been updated since the last request |
DataService: HosLogs | 6 hours | 1 hours | Drain Queue processing may be applied |
DataService: HosUnassignedDriving | 30 minutes | 5 minutes | |
ReportsService: ALL | 6 hours | 1 hours | Drain Queue processing may be applied |
Drain Queue Processing is recommended when continually polling for new data
shortPollSleep = 5 //Required sleep amount when polling again immediately
longPollSleep = Storage.GetLongPollSleep("operationName") //3hours - Configurable long wait period
batchSize = Storage.GetBatchSize("operationName") //1000 - Configurable batch size per operation/request type
currentMaxIndexReceived = Storage.GetLastPollingValue("operationName") //Storage area to keep track of last polled value
While(true)
{
response = X_GetByIndex(currentMaxIndexReceived, batchSize)
currentMaxIndexReceived = MAX(response.Items.Id) //Get MAX(object) for query type (i.e. Int for ByIndex, DateTime for other types)
Storage.SetLastPollingValue("operationName", currentMaxIndexReceived) //Persist the value to durable storage to allow the app to continue after a restart
if(COUNT(response.Items) >= batchSize) //Are there more records?
sleep(shortPollSleep) //Immediately call again to get next batch to catch up as there are more 'in the queue'
else
sleep(longPollSleep)
} |
|