... | ... | @@ -3,21 +3,18 @@ |
|
|
Within the DGT 3.0 platform, the following is implemented:
|
|
|
|
|
|
- An interface that allows providers to send information in real time about their users who are riding bicycles on national roads
|
|
|
|
|
|
- Publication of validated information through the outbox interface so that any third party authorized by DGT can consume the real-time location of cyclists to inform users of their applications / vehicles
|
|
|
|
|
|
- The implementation of a logic to validate the information received to avoid problems derived from the inaccuracy of the GPS of the devices when sending their position and incorrect reception of the data.
|
|
|
|
|
|
The platform has two different functionalities for the **publication (sending)** and for the **subscription (reception)** of information. The first is through a REST API and the second through a real-time MQTT service.
|
|
|
The platform has two different functionalities for the **publication (sending)** and for the **subscription (reception)** of information. The first is through a REST API ~~and the second through a real-time MQTT service~~.
|
|
|
|
|
|
Both the publication and subscription functionality require different access certificates that must be requested and supplied by DGT 3.0. If these certificates have not already been requested, they should be requested from *[soporte@cmobility30.es](mailto:soporte@cmobility30.es)*.
|
|
|
Both the publication and subscription functionality require different access certificates that must be requested and supplied by DGT 3.0. If these certificates have not already been requested, they should be requested from [_soporte@cmobility30.es_](mailto:soporte@cmobility30.es).
|
|
|
|
|
|
Below are the URLs with which each functionality is accessed:
|
|
|
|
|
|
| Mode | URL | Description |
|
|
|
| ------------ | -------------------------------------- | ------------------------------------------------------ |
|
|
|
| Publication | https://pre.cmobility30.es/use-case-13 | Client integration environment endpoint for publishing |
|
|
|
| Subscription | mqtt://mqtt.pre.cmobility30.es:8883 | Integration environment endpoint for subscription |
|
|
|
| Mode | URL | Description |
|
|
|
|------|-----|-------------|
|
|
|
| Publication | <https://pre.cmobility30.es/use-case-13> | Client integration environment endpoint for publishing |
|
|
|
| Subscription | <mqtt://mqtt.pre.cmobility30.es:8883> | Integration environment endpoint for subscription |
|
|
|
|
|
|
The two functionalities are described below.
|
|
|
|
... | ... | @@ -37,79 +34,45 @@ This use case has a REST API for the publication (sending) of the data by the co |
|
|
|
|
|
> [Event](publicacion/Event)
|
|
|
|
|
|
## Subscription
|
|
|
## ~~Subscription~~
|
|
|
|
|
|
This use case also has a subscription service (reception) to the data for the companies that request it through the MQTT protocol. Below you can find the details of this:
|
|
|
~~This use case also has a subscription service (reception) to the data for the companies that request it through the MQTT protocol. Below you can find the details of this:~~
|
|
|
|
|
|
**MQTT (MQ Telemetry Transport)** is a messaging protocol used as a simple and lightweight method to transfer data to / from low-power devices.
|
|
|
**~~MQTT (MQ Telemetry Transport)~~** ~~is a messaging protocol used as a simple and lightweight method to transfer data to / from low-power devices.~~
|
|
|
|
|
|
The protocol supports a single messaging pattern, the **Publish-Subscribe** pattern: each message is published on a topic that must be subscribed to in order to receive the information.
|
|
|
~~The protocol supports a single messaging pattern, the **Publish-Subscribe** pattern: each message is published on a topic that must be subscribed to in order to receive the information.~~
|
|
|
|
|
|
Subscription to the service of this use case must be through the topic:
|
|
|
~~Subscription to the service of this use case must be through the topic:~~
|
|
|
|
|
|
> usecase13/events
|
|
|
> ~~usecase13/events~~
|
|
|
|
|
|
In the topic, the events are published in JSON format. Here you can see an example:
|
|
|
~~In the topic, the events are published in JSON format. Here you can see an example:~~
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"actionId": "CLI_235",
|
|
|
"beaconId": "cff92179-dc0a-47da-bd9e-5e9c5b14d251",
|
|
|
"beaconTypeId": 1,
|
|
|
"timestamp": "2021-06-02T13:34:56.747Z",
|
|
|
"lon": -4.304818,
|
|
|
"lat": 41.312456,
|
|
|
"eventTypeId": 1,
|
|
|
"speed": 85,
|
|
|
"provinceId": 40,
|
|
|
"road": "A-601",
|
|
|
"pk": 64.73,
|
|
|
"direction": "UP"
|
|
|
}
|
|
|
```
|
|
|
|
|
|
- actionId (text): unique identifier of the event
|
|
|
|
|
|
- beaconId (text): unique identifier of the beacon (for example, the MAC)
|
|
|
|
|
|
- beaconTypeId (integer number): beacon type identifier. 1 = Individual, 2 = Group
|
|
|
|
|
|
- timestamp (UTC time): date and time in UTC format of when the event was generated. It must be a maximum of 15 seconds old with respect to UTC time. The date must end with the character 'Z' that marks that it is in UTC
|
|
|
|
|
|
- deviceTypeId (integer number): identifier of the type of device from which the information is sent. 1 = Baliza, 2 = App
|
|
|
|
|
|
- speed (integer number): speed measured in kilometers per hour at which the element is at the moment it sends the event
|
|
|
|
|
|
- provinceId (integer number): identifier of the province where the event is generated according to the [INE](https://www.ine.es/daco/daco42/codmun/cod_provincia_estandar.htm)
|
|
|
|
|
|
- road (integer number): official name of the road where the event is generated
|
|
|
|
|
|
- pk (integer number): kilometer point where the event is generated
|
|
|
|
|
|
- direction (String): direction of the road where the event is generated. UP = Upward direction, DOWN = Downward direction, UNKNOWN = Unknown
|
|
|
|
|
|
- lonStart (decimal number): longitude in WGS 84 coordinate system where the event was generated
|
|
|
|
|
|
- latStart (decimal number): latitude in WGS 84 coordinate system where the event was generated
|
|
|
|
|
|
- lonEnd (decimal number): longitude in WGS 84 coordinate system where the event ended
|
|
|
|
|
|
- latEnd (decimal number): latitude in WGS 84 coordinate system where the event ended
|
|
|
|
|
|
See more information and a connection example [here](https://gitlab.cs.cmobility30.es/dgt3.0_eng/general/-/wikis/MQTT).
|
|
|
|
|
|
|
|
|
- ~~actionId (text): unique identifier of the event~~
|
|
|
- ~~beaconId (text): unique identifier of the beacon (for example, the MAC)~~
|
|
|
- ~~beaconTypeId (integer number): beacon type identifier. 1 = Individual, 2 = Group~~
|
|
|
- ~~timestamp (UTC time): date and time in UTC format of when the event was generated. It must be a maximum of 15 seconds old with respect to UTC time. The date must end with the character 'Z' that marks that it is in UTC~~
|
|
|
- ~~deviceTypeId (integer number): identifier of the type of device from which the information is sent. 1 = Baliza, 2 = App~~
|
|
|
- ~~speed (integer number): speed measured in kilometers per hour at which the element is at the moment it sends the event~~
|
|
|
- ~~provinceId (integer number): identifier of the province where the event is generated according to the~~ [~~INE~~](https://www.ine.es/daco/daco42/codmun/cod_provincia_estandar.htm)
|
|
|
- ~~road (integer number): official name of the road where the event is generated~~
|
|
|
- ~~pk (integer number): kilometer point where the event is generated~~
|
|
|
- ~~direction (String): direction of the road where the event is generated. UP = Upward direction, DOWN = Downward direction, UNKNOWN = Unknown~~
|
|
|
- ~~lonStart (decimal number): longitude in WGS 84 coordinate system where the event was generated~~
|
|
|
- ~~latStart (decimal number): latitude in WGS 84 coordinate system where the event was generated~~
|
|
|
- ~~lonEnd (decimal number): longitude in WGS 84 coordinate system where the event ended~~
|
|
|
- ~~latEnd (decimal number): latitude in WGS 84 coordinate system where the event ended~~
|
|
|
|
|
|
~~See more information and a connection example~~ [~~here~~](https://gitlab.cs.cmobility30.es/dgt3.0_eng/general/-/wikis/MQTT)~~.~~
|
|
|
|
|
|
## Errors
|
|
|
|
|
|
As stated above, all HTTP responses other than **200 – OK**, can be considered **invalid**. The format of the error response is like the following example:
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"status": 401,
|
|
|
"code": 1,
|
|
|
"message": "User not found or valid"
|
|
|
}
|
|
|
```
|
|
|
|
|
|
These errors will have three main categories:
|
... | ... | @@ -117,44 +80,39 @@ These errors will have three main categories: |
|
|
#### Authentication Error
|
|
|
|
|
|
- HTTP Status: **401 - Unauthorized**
|
|
|
|
|
|
| Code | Message |
|
|
|
| ---- | ----------------------- |
|
|
|
| 1 | User not found or valid |
|
|
|
| Code | Message |
|
|
|
|------|---------|
|
|
|
| 1 | User not found or valid |
|
|
|
|
|
|
|
|
|
#### Client Error
|
|
|
|
|
|
- HTTP Status: **400 - Bad Request**
|
|
|
|
|
|
| Code | Message |
|
|
|
| ---- | ------------------------------------------------------------------- |
|
|
|
| 0 | Authenticate |
|
|
|
| 2 | Entity ID not found |
|
|
|
| 3 | Missing required property |
|
|
|
| 4 | The entity received cannot be proccessed |
|
|
|
| 5 | Incorrect token received |
|
|
|
| 6 | Expired token received |
|
|
|
| 7 | There is an error with the token provided. Please request a new one |
|
|
|
| 8 | No token received |
|
|
|
| 9 | Required request body is missing |
|
|
|
| 10 | Event is marked as expired by timestamp |
|
|
|
| 11 | Missing request header |
|
|
|
| 12 | Permission denied. Role assigned to user missing |
|
|
|
|
|
|
In the case of getting an error *3 - Missing required property*, the response obtained will have a value in the message that will indicate the missing fields to send:
|
|
|
| Code | Message |
|
|
|
|------|---------|
|
|
|
| 0 | Authenticate |
|
|
|
| 2 | Entity ID not found |
|
|
|
| 3 | Missing required property |
|
|
|
| 4 | The entity received cannot be proccessed |
|
|
|
| 5 | Incorrect token received |
|
|
|
| 6 | Expired token received |
|
|
|
| 7 | There is an error with the token provided. Please request a new one |
|
|
|
| 8 | No token received |
|
|
|
| 9 | Required request body is missing |
|
|
|
| 10 | Event is marked as expired by timestamp |
|
|
|
| 11 | Missing request header |
|
|
|
| 12 | Permission denied. Role assigned to user missing |
|
|
|
|
|
|
|
|
|
In the case of getting an error _3 - Missing required property_, the response obtained will have a value in the message that will indicate the missing fields to send:
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"status": 400,
|
|
|
"code": 3,
|
|
|
"message": "[deviceTypeId: must not be null, deviceUseTypeId: must not be null, informationQualityId: must not be null]"
|
|
|
}
|
|
|
```
|
|
|
|
|
|
#### Server Error
|
|
|
|
|
|
- HTTP Status: **500 - Internal Server Error**
|
|
|
|
|
|
| Code | Message |
|
|
|
| ---- | -------------- |
|
|
|
| 13 | Internal error | |
|
|
| Code | Message |
|
|
|
|------|---------|
|
|
|
| 13 | Internal error |
|
|
|
|