Another important aspect about 'real time development' is the usage of the provided timestamps in chronological order: fixTime, deviceTime and serverTime. The GPS Fixtime describes, when the Position was calculated, fixed and saved into the devices memory. This fixtime is calculated by the GPS Unit hardware and chip in the field with the most precise atomic clocks available. The calculation has to be relativistic and be aware of the satelites positions and much more. The fix is usually made when the parameters provide a result with best accuracy and this can differ due to the environmental conditions.

The deviceTime is the point in time when the position and event are sent.
Consecutive messages can have the same fixTime.
The serverTime is the time, when the position and event are persisted.
It can provide clues about the connectivity and network latency.

The RealTimeManager is a thread-safe Singleton class to manage the concurrent real-time state of the Traccar client, also known as StateManager in RealTime context.

Note that there is no API involved.

The RealTimeManagerIT test is holding the private RealTimeManager in order to test it’s methods.

The RealTimeController is the subsequent implementation keeping the RealTimeManager private to control it’s state by synchronizing the server updates. The Controller encapsulates all the logic for communicating with the Traccar server. It handles authentication, fetches the initial state via the REST API, and then connects to the WebSocket to receive and process live updates, feeding everything into the thread-safe state manager.

Basic RealTimeController design:

We will look at the TraccarWebSocketRoute soon.
For now you can run the RealTimeControllerIT which basically executes the line

where the authentication, loading of initial server Entities and establishing a live connection via WebSocket.

To keep a distributed systems integrity you need to have all models in mind.

The Model for Tracker Development defines a GPS message from a unique device.
The REST yml file provides a bigger model for a complete GTS.
These models deviate and must be mapped to each other.

The following devices and positions messages in json format look like this.

Note the difference of the devices database id=554 and the uniqueId=10. The database Id is technical and can change in a different environment, while the uniqueId always refers to a unique tracker. The latter must be used in a scenario to track the device.

Anyhow the database Ids are important for referencing.
The above device references the positionId=198,
vice versa the position has the reference deviceId=554.

Let’s break down the websocket spec above towards an implementation.

As this repository is based on Spring Boot with Camel integration,
i.e. we are building a Camel Spring Boot WebSocket Client for Traccar.

Besides Spring Boot and Camel we need to choose a websocket component.
Most popular choices are the Eclipse Vert.x and the Eclipse Jetty WebSocket Client.

Jetty is actually a traditional servlet-container with a thread based architecture in Java. As Traccar works with a Jetty Server it could be chosen for symetrie reasons. Anyhow we only want to rely on the specifications and not on proprietary implementations.

Vert.x is a modern event driven non blocking implementation comparable to netty, which we have analyzed in depth in the jeets project. Vert.x has a better scalability for a larger number of connections and a lower latency. It also offers http, database drivers and smooth integration with other technologies.

… and the winner is … Vert.x
Of course we will use the camelized version with a Spring Boot Starter in Maven to abstract the WS component (in case we revise the decision later):

With Camel we can configure the appropriate security settings,
leverage Camel’s asynchronous nature to handle multiple WebSocket connections and messages efficiently
and implement a backpressure mechanisms in case of high message volumes.

A basic route implementation looks like this:

But first we need to extract the JSESSIONID from a http POST and create a Cookie,
while using the http context from Spring Boot for the ws connection.

Note that we will not use the traccar-api-client for the http POST, since we clearly want to separate the two clients for API and WebSocket. Our architecture does not want any dependencies between them for isolated testing etc. Each client represents a software Unit and can be tested, developed and used alone. And like every Unit it should be replaceble.

Anyhow we can combine the two in a higher level traccar-java-client.

The initial traccar-ws-client implementation is kept as simple as it gets. This allows a better understanding and makes it easier to expand the component inside the application lifecycle development.

Nevertheless networking is alway a challenge and in this case you might experience problems with (reverse) proxies, firewalls, closed ports, URL / URI resolution, cloud installation, docker, port forwarding, Traccar server settings and beware of misleading AI assistance.

Therefor you can execute the most simple test with two cammand lines, before you drill deeper.

If you run into any problems apply the command line tools curl for the http POST and wscat for the websocket connection. In addition you should create an account on one of the graciously sponsered Traccar Demo Servers and test with https and email/password.

Here’s a simple example code to demo how to add the Traccar API Service to your company software.
First you need these prerequesites:

and then the coding is straight forward:

And that is all you need to create users, devices etc. and manage them in your code!
For more examples check the integration tests, i.e. UsersIT and others.

For convenience you can use the application.properties file and grab the @Value in your source code, depending on your security concepts. Check the *.*IT integration test files for demo code.